FideX Application Statement 5 (AS5) Protocol

1.1. Purpose

FideX (Fast Integration for Digital Enterprises eXchange) defines a secure, reliable message exchange protocol for B2B electronic data interchange. The protocol ensures:¶

• Non-repudiation: Cryptographic proof of message origin¶
• Integrity: Detection of message tampering¶
• Confidentiality: End-to-end encryption¶
• Reliability: Asynchronous acknowledgments with retry semantics¶

1.2. Scope

This specification defines:¶

• Message format and structure¶
• Cryptographic operations (sign-then-encrypt using JOSE)¶
• Partner discovery and registration¶
• State management and acknowledgments (J-MDN)¶
• Error codes and handling¶

This specification does NOT define:¶

• Business document formats (the protocol is payload-agnostic)¶
• Application-specific processing logic¶
• Implementation details or code examples¶
• Deployment or operational procedures¶

1.3. AS Naming Lineage

FideX adopts the "AS" (Application Statement) naming lineage from established B2B interchange standards:¶

• AS2 ([RFC4130]) -- MIME/S/MIME over HTTP (2005)¶
• AS4 ([OASIS-ebMS]) -- SOAP/WS-Security over HTTP (2013)¶
• AS5 (FideX) -- REST/JSON/JOSE over HTTPS (2026)¶

The designation signals evolutionary continuity while marking a generational leap to modern web-native architecture. AS5 is implementable by any developer with knowledge of REST APIs and standard JOSE libraries, without requiring specialized B2B middleware.¶

1.4. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

Additional terms used in this document:¶

Node

A FideX-compliant server capable of sending and receiving messages.¶

Partner

A trading partner with an established trust relationship.¶

Message

A business document wrapped in a FideX envelope.¶

J-MDN

JSON Message Disposition Notification -- a signed receipt acknowledging receipt and processing of a FideX message.¶

JWKS

JSON Web Key Set -- a JSON structure representing a set of public keys.¶

AS5 Configuration

A JSON document published by a node describing its endpoints, supported algorithms, and identity.¶

2.1. Required Transport

Nodes MUST support HTTP/1.1 over TLS 1.3 as defined in [RFC8446]. TLS 1.2 ([RFC5246]) MAY be supported with Perfect Forward Secrecy (ECDHE key exchange) as fallback for backward compatibility.¶

Transport requirements:¶

• Port 443 (HTTPS)¶
• Valid certificate from a trusted Certificate Authority (CA)¶
• Server Name Indication (SNI) per [RFC6066]¶
• Full certificate chain validation¶

2.2. Optional Transports

Nodes MAY additionally support:¶

• HTTP/2 ([RFC9113]): For multiplexed connections and improved throughput.¶
• HTTP/3 ([RFC9114]): For connection resilience using QUIC.¶

2.3. Request Method

All FideX message transmissions MUST use the HTTP POST method to the receiving endpoint specified in the partner's AS5 configuration (see Section 6).¶

2.4. Content Type

FideX message envelopes MUST use Content-Type: application/json. Registration requests MUST use Content-Type: application/jose (see Section 6.3).¶

2.5. Message Size Limits

Implementations MUST accept messages up to 10 megabytes (10,000,000 octets in the complete HTTP request body, including the JSON envelope and all JOSE serialization overhead). This is not a limit on the unencoded business document. Implementations MAY accept larger messages by prior bilateral agreement. Senders MUST NOT assume support above 10 MB without prior explicit agreement. Implementations SHOULD reject oversized messages with HTTP 413 and the error code PAYLOAD_TOO_LARGE (see Section 8.3).¶

3.1. Message Envelope

A FideX message envelope consists of exactly two top-level JSON fields:¶

{
  "routing_header": { ... },
  "encrypted_payload": "eyJhbGc..."
}

The routing_header is cleartext JSON containing message metadata readable by intermediate infrastructure without decryption. The encrypted_payload is a JWE compact serialization that wraps the signed business document. These two fields are the ONLY top-level fields in a FideX message envelope.¶

3.2. Routing Header

The routing header is a cleartext JSON object conveying message routing metadata. It MUST contain the following fields:¶

fidex_version

(string, REQUIRED) Protocol version in semantic "major.minor" format, e.g., "1.0".¶

message_id

(string, REQUIRED) Globally unique message identifier. UUID v4 ([RFC9562]) with an "fdx-" prefix is RECOMMENDED (e.g., "fdx-550e8400-e29b-41d4-a716-446655440000").¶

sender_id

(string, REQUIRED) URN of the sending organization. See Section 3.2.1 for valid formats.¶

receiver_id

(string, REQUIRED) URN of the receiving organization. See Section 3.2.1 for valid formats.¶

document_type

(string, REQUIRED) Business document type identifier. MUST match the pattern ^[A-Z0-9_]+$. See Section 3.3.¶

timestamp

(string, REQUIRED) ISO 8601 UTC timestamp with millisecond precision. Format: YYYY-MM-DDTHH:mm:ss.SSSZ. The UTC designator "Z" MUST be used; no local timezone offsets are permitted.¶

receipt_webhook

(string, OPTIONAL) HTTPS URL where the J-MDN receipt SHOULD be delivered. HTTP (non-TLS) is NOT allowed. When omitted, the receiver MUST deliver the J-MDN to the sender's receive_receipt endpoint from the sender's AS5 configuration (see Section 7.3.5).¶

payload_digest

(string, OPTIONAL) SHA-256 digest of the encrypted_payload field value. Computed as "sha256:" followed by the lowercase hexadecimal encoding of SHA-256 applied to the UTF-8 byte representation of the encrypted_payload string as it appears in the JSON envelope. Enables routing-layer integrity checks without decryption.¶

Extension fields MAY be included and MUST use the prefix "x-" to avoid collision with future standard fields. Implementations MUST ignore unknown extension fields without error.¶

3.3. Document Type Registry

The document_type field uses a two-tier naming system to accommodate both standardized inter-organization document types and organization-specific custom types.¶

3.4. Encrypted Payload

The encrypted_payload field contains a JWE (JSON Web Encryption) token in compact serialization as defined in [RFC7516]. The JWE encrypts a JWS (JSON Web Signature) token as defined in [RFC7515], creating a nested "sign-then-encrypt" structure:¶

JWE( JWS( business_document ) )

This pattern ensures both authenticity (the signature is inside the encryption envelope, protecting it from substitution) and confidentiality (the business content is encrypted end-to-end).¶

4.1. Signature (JWS)

Messages MUST be signed using the sender's private key before encryption.¶

The REQUIRED signing algorithm is RS256 (RSASSA-PKCS1-v1_5 with SHA-256) as defined in [RFC7518].¶

The following signing algorithms are OPTIONAL:¶

• RS384, RS512 -- stronger RSA variants¶
• PS256, PS384, PS512 -- RSA-PSS variants¶
• ES256 (ECDSA with P-256 and SHA-256) -- RECOMMENDED for new deployments¶
• ES384 (ECDSA with P-384 and SHA-384)¶

Minimum key sizes: 2048 bits for RSA (4096 bits RECOMMENDED); P-256 minimum for ECDSA (P-384 RECOMMENDED).¶

The JWS Protected Header MUST include:¶

{
  "alg": "RS256",
  "kid": "{sender-key-id}"
}

4.2. Encryption (JWE)

Signed messages MUST be encrypted using the receiver's public key.¶

The REQUIRED algorithms are:¶

• Key Encryption: RSA-OAEP as defined in [RFC7518]¶
• Content Encryption: A256GCM (AES-256-GCM)¶

Implementations SHOULD also support RSA-OAEP-256, which uses SHA-256 for both OAEP and MGF1, as defined in [RFC7518], Section 4.3. Algorithm selection follows Section 6.2.1. RSA-OAEP remains the REQUIRED interoperability baseline for protocol version 1.0.¶

The JWE Protected Header MUST include:¶

{
  "alg": "RSA-OAEP",
  "enc": "A256GCM",
  "cty": "JWT",
  "kid": "{receiver-key-id}"
}

The cty (content type) header parameter MUST be set to "JWT" to indicate the JWE payload contains a nested JWS/JWT token, per [RFC7516] Section 4.1.12. This is required for correct processing of nested tokens.¶

4.3. Payload Encoding

The JWS payload MUST be the UTF-8 encoding of the JSON-serialized business document. Binary payloads (images, PDFs, etc.) MUST be base64-encoded before JWS signing.¶

4.4. Sender Identity Verification

Receivers MUST verify that the JWS signing key identified by kid in the JWS header belongs to the partner identified by sender_id in the routing header. Specifically:¶

• The kid MUST resolve to a public key in the sender's JWKS.¶
• The sender's JWKS MUST be fetched from the public_domain associated with the sender_id in the local partner registry.¶

This prevents cross-partner key substitution attacks where an attacker uses a valid key from one partner to impersonate another.¶

4.5. Prohibited Algorithms

Implementations MUST NOT use:¶

• The none algorithm (unsigned tokens)¶
• Symmetric signature algorithms (HS256, HS384, HS512)¶
• RSA keys smaller than 2048 bits¶
• Deprecated algorithms: MD5, SHA-1-based signatures¶

5.1. JSON Web Key Set (JWKS) Endpoint

Nodes MUST publish their public keys via a JWKS endpoint at the well-known URI:¶

https://{public_domain}/.well-known/jwks.json

This endpoint:¶

• MUST be publicly accessible without authentication.¶
• MUST return Content-Type: application/json.¶
• SHOULD include Cache-Control headers (1 hour RECOMMENDED).¶

5.2. JWKS Format

Per [RFC7517], keys MUST include at minimum the following fields. An RSA signing key example:¶

{
  "keys": [
    {
      "kty": "RSA",
      "use": "sig",
      "kid": "acme-sign-rsa-2026-01",
      "alg": "RS256",
      "n": "{base64url-encoded-modulus}",
      "e": "AQAB"
    }
  ]
}

An EC signing key example:¶

{
  "keys": [
    {
      "kty": "EC",
      "use": "sig",
      "kid": "acme-sign-ec-2026-01",
      "alg": "ES256",
      "crv": "P-256",
      "x": "{base64url-x-coordinate}",
      "y": "{base64url-y-coordinate}"
    }
  ]
}

Field semantics:¶

kty

Key type: "RSA" or "EC".¶

use

"sig" for signing keys; "enc" for encryption keys.¶

kid

Unique key identifier used in JWS/JWE headers.¶

alg

Algorithm for this key (RS256, ES256, RSA-OAEP, etc.).¶

5.3. Key Rotation

Implementations SHOULD rotate keys annually. During rotation, the following procedure MUST be followed to ensure uninterrupted partner communication:¶

1. Publish the new key alongside the old key in the JWKS.¶
2. Maintain both keys for a transition period (30-60 days RECOMMENDED).¶
3. Begin signing new outbound messages with the new key after partners have had time to cache it.¶
4. Remove the old key from the JWKS after the transition period.¶

The kid value SHOULD encode the purpose and date to aid key management, e.g., "org-sign-rsa-2026-01".¶

6.1. Discovery Overview

Partner discovery enables automated trading partner onboarding without manual certificate exchange. The process consists of four phases:¶

1. Configuration discovery¶
2. Key retrieval¶
3. Signed registration¶
4. Mutual confirmation¶

The AS5 configuration URL MAY be distributed via QR code, email, or a trading partner portal. The protocol is designed so that scanning a QR code initiates fully automated mutual trust establishment.¶

6.2. AS5 Configuration Endpoint

Nodes MUST expose an AS5 configuration document at an HTTPS URL. This URL:¶

• MAY be at any path (no required well-known location).¶
• MAY include a single-use security token as a query parameter.¶
• SHOULD be shareable via QR code.¶

The AS5 configuration document structure:¶

{
  "fidex_version": "1.0",
  "supported_versions": ["1.0"],
  "conformance_profile": "core",
  "node_id": "urn:gln:1234567890123",
  "organization_name": "Example Corp",
  "public_domain": "fidex.example.com",
  "supported_document_types": ["GS1_ORDER_JSON", "GS1_INVOICE_JSON"],
  "endpoints": {
    "receive_message": "https://fidex.example.com/api/v1/receive",
    "receive_receipt": "https://fidex.example.com/api/v1/receipt",
    "register": "https://fidex.example.com/api/v1/register",
    "jwks": "https://fidex.example.com/.well-known/jwks.json"
  },
  "security": {
    "signature_algorithm": "RS256",
    "encryption_algorithm": "RSA-OAEP",
    "supported_encryption_algorithms": ["RSA-OAEP", "RSA-OAEP-256"],
    "content_encryption": "A256GCM",
    "minimum_key_size": 2048
  }
}

Required fields in the AS5 configuration:¶

fidex_version

Current active protocol version (string, REQUIRED).¶

supported_versions

Array of all protocol versions this node supports (array, REQUIRED).¶

node_id

URN identifier for this node (string, REQUIRED).¶

organization_name

Human-readable organization name (string, REQUIRED).¶

public_domain

Public-facing domain name hosting JWKS and endpoints (string, REQUIRED).¶

endpoints

Object containing service endpoint URLs (object, REQUIRED). MUST include: receive_message, receive_receipt, register, jwks.¶

security

Cryptographic algorithm declarations (object, REQUIRED).¶

conformance_profile

"core", "enhanced", or "edge" (string, OPTIONAL).¶

supported_document_types

Array of document_type identifiers this node processes (array, OPTIONAL).¶

6.3. Discovery Handshake

The four-phase discovery handshake proceeds as follows:¶

Phase 1 -- Initiator Discovers Responder:¶

1. Initiator obtains the responder's AS5 configuration URL.¶
2. Initiator fetches the responder's AS5 configuration document.¶
3. Initiator fetches the responder's JWKS from the well-known endpoint.¶

Phase 2 -- Initiator Registers:¶

The initiator constructs and submits a signed registration payload:¶

{
  "fidex_version": "1.0",
  "initiator_node_id": "urn:gln:...",
  "initiator_as5_config_url": "https://...",
  "security_token": "...",
  "timestamp": "2026-03-09T19:00:00.000Z"
}

1. Initiator constructs the registration payload as shown above.¶
2. Initiator signs the payload with its private key (JWS compact serialization).¶
3. Initiator POSTs the JWS to the responder's register endpoint with Content-Type: application/jose.¶

Phase 3 -- Responder Validates:¶

1. Responder validates the security token (if configured).¶
2. Responder fetches the initiator's AS5 configuration from the URL in the request.¶
3. Responder fetches the initiator's JWKS and verifies the JWS signature.¶
4. Responder stores the initiator's details and returns HTTP 200.¶

Phase 4 -- Completion:¶

1. Initiator receives HTTP 200 confirmation.¶
2. Initiator stores the responder's details.¶
3. Both parties MAY immediately exchange FideX messages.¶

6.4. Registration Security Requirements

Registration requests MUST:¶

• Be signed with the initiator's private key (RS256 minimum).¶
• Be transmitted with Content-Type: application/jose.¶
• Include a timestamp within +/-15 minutes of current time.¶
• Include the security token if the responder has configured one.¶

Security tokens MUST contain at least 128 bits of entropy, generated using a cryptographically secure pseudo-random number generator (CSPRNG). For example, encode 16 CSPRNG-generated octets as 32 hexadecimal characters or 22 unpadded base64url characters. A UUID v4 has only 122 random bits and does not meet this security-token requirement.¶

Responders MUST:¶

• Validate the JWS signature before trusting any payload content.¶
• Reject registrations with timestamps outside +/-15 minutes.¶
• Reject invalid or previously used security tokens.¶

6.5. Partner De-Registration

De-registration is a local, unilateral operation. There is no protocol-level de-registration handshake.¶

Partner states:¶

De-registration procedure:¶

1. The initiating party sets partner status to INACTIVE locally.¶
2. The initiating party SHOULD notify the partner via out-of-band channel.¶
3. The initiating party MUST continue accepting J-MDNs for in-flight messages.¶
4. After a 24-hour grace period, new inbound messages MUST be rejected with HTTP 401.¶
5. Partner records SHOULD be retained for audit purposes (7 years RECOMMENDED).¶

7.1. Message State Machine

Messages transition through the following states:¶

These are protocol state semantics. Implementations MAY use different internal database or API labels, such as ACKNOWLEDGED for DELIVERED, provided they preserve these semantics. The status field in a transmitted J-MDN MUST still use DELIVERED or FAILED. A verified FAILED receipt MUST NOT transition the original message to DELIVERED. Conformance assessment MUST check receipt verification and correlation, not require a particular internal storage label.¶

7.2. Synchronous HTTP Response

Upon receiving a message, nodes MUST perform structural validation and return:¶

• HTTP 202 Accepted: Message is structurally valid and queued for processing.¶
• HTTP 4xx/5xx: Immediate rejection (see Section 8).¶

HTTP 202 indicates structural acceptance only. It does NOT indicate successful decryption, business document processing, or J-MDN generation.¶

Idempotency: Receivers MUST handle duplicate message_id values idempotently. If a receiver encounters a message_id it has already accepted, it MUST return HTTP 202 again and MUST NOT process the message a second time. This ensures safe sender retries when HTTP responses are lost.¶

7.3. Asynchronous Receipt: J-MDN

The J-MDN (JSON Message Disposition Notification) is the legally most significant artifact in the FideX protocol. It provides cryptographic proof that a specific message was received, decrypted, and accepted or rejected by the trading partner.¶

After processing a message, the receiver MUST send a J-MDN to the sender. The delivery target is determined as follows:¶

1. If receipt_webhook is present in the routing header, deliver to that URL.¶
2. Otherwise, deliver to the sender's receive_receipt endpoint from the sender's AS5 configuration.¶
3. If neither is available, the J-MDN MUST be stored and the failure logged; J-MDNs MUST NOT be discarded.¶

{
  "original_message_id": "fdx-a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "status": "DELIVERED",
  "receiver_id": "urn:gln:9876543210987",
  "hash_verification": "sha256:9f86d08...b0f00a08",
  "timestamp": "2026-03-09T19:30:02.000Z",
  "error_log": null,
  "signature": "eyJhbGciOiJSUzI1NiIs..."
}

{
  "original_message_id": "fdx-a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "status": "FAILED",
  "receiver_id": "urn:gln:9876543210987",
  "hash_verification": "sha256:0000...0000",
  "timestamp": "2026-03-09T19:30:02.000Z",
  "error_log": {
    "error_code": "DECRYPTION_FAILED",
    "error_message": "Unable to decrypt payload",
    "details": "Key ID mismatch"
  },
  "signature": "eyJhbGciOiJSUzI1NiIs..."
}

hash_verification =
    "sha256:" || hex( SHA-256( raw_business_payload_bytes ) )

{
  "alg": "RS256",
  "kid": "{receiver-signing-key-id}"
}

POST {receipt_webhook} HTTP/1.1
Host: {sender_host}
Content-Type: application/json
X-FideX-Original-Message-ID: {original_message_id}

{J-MDN JSON body}

{
  "receipt_acknowledged": true
}

7.4. Sender Retry Semantics

Senders SHOULD retry failed transmissions with exponential backoff:¶

• Attempt 1: Immediate¶
• Attempt 2: +1 minute¶
• Attempt 3: +5 minutes¶
• Attempt 4: +15 minutes¶
• Attempt 5: +30 minutes¶
• Attempt 6: +1 hour¶

After 5-6 failed attempts, the message SHOULD transition to FAILED state requiring manual operator intervention.¶

7.5. Evidence Delivery to Non-FideX Participants

A business participant need not operate a FideX node to obtain evidence about its transactions. For example, a pharmaceutical distributor without FideX support can receive transaction evidence through email, a management portal, or an HTTPS webhook. A FideX node or application gateway MAY provide this capability. When it serves a non-FideX participant, it MUST provide at least one evidence delivery or retrieval channel agreed with that participant. Support for all three channels is not required.¶

This capability distributes evidence already held by the node and records additional channel events. It does not change the J-MDN wire format or require the non-FideX participant to implement JOSE. Business document delivery over a non-FideX channel is a separate application function; delivering evidence alone does not establish delivery of that document.¶

8.1. HTTP Status Codes

Implementations SHOULD include a Retry-After header on HTTP 429 responses, per [RFC9110] Section 10.2.3.¶

8.2. Error Response Format

All error responses MUST use the following JSON structure:¶

{
  "error": {
    "code": "INVALID_ROUTING_HEADER",
    "message": "Missing required field: message_id",
    "timestamp": "2026-03-09T19:00:00.000Z"
  }
}

8.3. Standard Error Codes

Message transmission errors:¶

• INVALID_ROUTING_HEADER -- Missing or malformed routing header¶
• UNKNOWN_RECEIVER -- receiver_id not recognized in partner registry¶
• UNKNOWN_DOCUMENT_TYPE -- document_type not supported¶
• PAYLOAD_TOO_LARGE -- Message exceeds the 10 MB size limit¶

Cryptographic errors:¶

• DECRYPTION_FAILED -- Cannot decrypt JWE¶
• SIGNATURE_INVALID -- JWS signature verification failed¶
• UNKNOWN_KEY_ID -- Key ID not found in JWKS¶

Discovery errors:¶

• INVALID_TOKEN -- Security token invalid or expired¶
• DUPLICATE_REGISTRATION -- Partner already registered¶
• CONFIG_UNREACHABLE -- Cannot fetch AS5 configuration¶

9.1. Threat Model

FideX addresses the following threats:¶

Man-in-the-Middle (MitM)

Mitigated by TLS 1.3 transport encryption combined with JWE application-layer encryption. An attacker who intercepts the TLS session cannot read the encrypted payload.¶

Message Tampering

Mitigated by JWS digital signatures. Any modification to the signed payload invalidates the signature, detected during verification.¶

Replay Attacks

Mitigated by unique message IDs combined with timestamp validation. Receivers MUST maintain a replay cache and reject duplicate message_id values.¶

Repudiation

Mitigated by cryptographic signatures on both messages (JWS) and receipts (J-MDN signature), creating a legally auditable chain of custody.¶

Key Compromise

Mitigated by key rotation procedures and JWKS-based distribution. Compromised keys can be revoked by removing them from the JWKS.¶

Cross-Partner Key Substitution

Mitigated by sender identity verification (Section 4.4): the receiver verifies the signing key belongs to the claimed sender_id.¶

9.2. Implementation Security Requirements

Implementations MUST:¶

• Validate TLS certificates against a trusted CA store on all outbound connections.¶
• Use constant-time comparison for signature verification to prevent timing attacks.¶
• Maintain a cache of recently seen message IDs to detect replay attacks.¶
• Reject messages with timestamps outside a +/-15-minute window of current time.¶
• Maintain the message ID replay cache for at least 24 hours.¶
• Synchronize system clocks using NTP ([RFC5905]) or equivalent.¶
• Generate cryptographically secure random message IDs using a CSPRNG.¶
• Never expose private keys in logs, error messages, or API responses.¶

Implementations SHOULD:¶

• Implement per-partner rate limiting on all endpoints.¶
• Use separate key pairs for signing and encryption (different use values).¶
• Rotate keys annually following the procedure in Section 5.3.¶
• Monitor for anomalous patterns (repeated authentication failures, invalid signatures).¶

9.3. Key Management

Private keys:¶

• MUST be generated using a cryptographically secure random number generator.¶
• MUST be stored encrypted at rest.¶
• MUST NOT be transmitted over any network.¶
• SHOULD be stored in a Hardware Security Module (HSM) for high-security deployments.¶

Public keys:¶

• MUST be distributed exclusively via the JWKS endpoint.¶
• SHOULD include a kid value encoding purpose and date (e.g., "org-sign-rsa-2026-01").¶
• MAY be cached by consuming parties for up to 24 hours.¶

9.4. Compliance Considerations

FideX is designed to support compliance with:¶

• Non-repudiation requirements for legally binding electronic transactions.¶
• FDA 21 CFR Part 11 (electronic signatures in regulated industries).¶
• GDPR and similar data protection frameworks (via encrypted payloads).¶
• GS1 and UN/CEFACT EDI standards (via payload-agnostic design).¶

Recommended audit trail retention periods:¶

• Message metadata: 7 years¶
• Cryptographic signatures (JWS): 7 years¶
• J-MDN receipts: 7 years¶

9.5. Deployment Note

FideX is designed to operate on standard web infrastructure. A conforming node can be implemented as a standard HTTPS web application behind any reverse proxy (Nginx, Apache, Caddy, cloud load balancers). No specialized B2B middleware, message broker, or gateway software is required. This is a key differentiator from AS2 (which required dedicated gateway software) and AS4 (which required SOAP stacks and ebMS processing engines).¶

C.1 FideX Core

An implementation claiming FideX Core conformance MUST support all requirements listed in Sections 2 through 8 of this specification, including:¶

• HTTP/1.1 over TLS 1.3¶
• Sign-then-encrypt: JWE(JWS(payload))¶
• RS256 signatures; RSA-OAEP + A256GCM encryption¶
• RSA key size >= 2048 bits¶
• JWKS endpoint at /.well-known/jwks.json¶
• AS5 configuration endpoint¶
• 4-phase discovery handshake¶
• Message state machine (QUEUED, SENT, DELIVERED, FAILED)¶
• J-MDN generation, signing, and delivery¶
• J-MDN fallback delivery via AS5 config receive_receipt endpoint¶
• Standard error codes and HTTP status codes¶
• Replay detection via message_id cache (>= 24 hours)¶
• Timestamp validation (+/-15-minute window)¶

C.2 FideX Enhanced

An implementation claiming FideX Enhanced conformance MUST satisfy FideX Core AND additionally support:¶

• HTTP/2 for multiplexed connections¶
• Separate signing and encryption key pairs (different kid and use values)¶
• RSA key size >= 4096 bits¶
• Key rotation support (overlapping key publication)¶
• J-MDN delivery retry per the schedule in Section 7.3.6¶
• Per-partner rate limiting on all endpoints¶
• Structured JSON logging with security event correlation IDs¶
• Health endpoints (/health and /ready)¶

C.3 FideX Edge

An implementation claiming FideX Edge conformance MUST satisfy FideX Enhanced AND additionally support:¶

• HTTP/3 over QUIC for connection resilience¶
• Mutual TLS (mTLS) -- client certificate authentication¶
• HSM-based private key storage¶

E.1 Routing Header Schema

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "$id": "https://fidex-protocol.org/schemas/v1/routing-header.json",
  "title": "FideX Routing Header",
  "type": "object",
  "required": [
    "fidex_version", "message_id", "sender_id",
    "receiver_id", "document_type", "timestamp"
  ],
  "additionalProperties": true,
  "properties": {
    "fidex_version": {
      "type": "string", "pattern": "^\\d+\\.\\d+$"
    },
    "message_id": {
      "type": "string", "minLength": 1, "maxLength": 256
    },
    "sender_id": {
      "type": "string",
      "pattern": "^urn:(gln|duns|lei|tin|custom):.+$"
    },
    "receiver_id": {
      "type": "string",
      "pattern": "^urn:(gln|duns|lei|tin|custom):.+$"
    },
    "document_type": {
      "type": "string", "pattern": "^[A-Z0-9_]+$",
      "minLength": 1, "maxLength": 128
    },
    "timestamp": { "type": "string", "format": "date-time" },
    "receipt_webhook": {
      "type": "string", "format": "uri",
      "pattern": "^https://"
    },
    "payload_digest": {
      "type": "string",
      "pattern": "^sha256:[a-f0-9]{64}$"
    }
  },
  "patternProperties": { "^x-": {} }
}

E.2 J-MDN Schema

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "$id": "https://fidex-protocol.org/schemas/v1/jmdn.json",
  "title": "FideX J-MDN",
  "type": "object",
  "required": [
    "original_message_id", "status", "receiver_id",
    "hash_verification", "timestamp", "error_log", "signature"
  ],
  "additionalProperties": false,
  "properties": {
    "original_message_id": { "type": "string", "minLength": 1 },
    "status": {
      "type": "string", "enum": ["DELIVERED", "FAILED"]
    },
    "receiver_id": {
      "type": "string",
      "pattern": "^urn:(gln|duns|lei|tin|custom):.+$"
    },
    "hash_verification": {
      "type": "string",
      "pattern": "^sha256:[a-f0-9]{64}$"
    },
    "timestamp": { "type": "string", "format": "date-time" },
    "error_log": {
      "oneOf": [
        { "type": "null" },
        {
          "type": "object",
          "required": ["error_code", "error_message"],
          "properties": {
            "error_code": {
              "type": "string",
              "enum": [
                "DECRYPTION_FAILED",
                "SIGNATURE_INVALID",
                "UNKNOWN_DOCUMENT_TYPE",
                "PAYLOAD_TOO_LARGE",
                "INTERNAL_ERROR"
              ]
            },
            "error_message": { "type": "string" },
            "details": { "type": "string" }
          }
        }
      ]
    },
    "signature": { "type": "string", "minLength": 1 }
  }
}

E.3 AS5 Configuration Schema

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "$id": "https://fidex-protocol.org/schemas/v1/as5-config.json",
  "title": "FideX AS5 Configuration",
  "type": "object",
  "required": [
    "fidex_version", "supported_versions", "node_id",
    "organization_name", "public_domain",
    "endpoints", "security"
  ],
  "properties": {
    "fidex_version": {
      "type": "string", "pattern": "^\\d+\\.\\d+$"
    },
    "supported_versions": {
      "type": "array",
      "items": { "type": "string" },
      "minItems": 1
    },
    "conformance_profile": {
      "type": "string",
      "enum": ["core", "enhanced", "edge"]
    },
    "node_id": { "type": "string", "pattern": "^urn:" },
    "organization_name": { "type": "string", "minLength": 1 },
    "public_domain": { "type": "string" },
    "supported_document_types": {
      "type": "array",
      "items": {
        "type": "string", "pattern": "^[A-Z0-9_]+$"
      }
    },
    "endpoints": {
      "type": "object",
      "required": [
        "receive_message", "receive_receipt",
        "register", "jwks"
      ],
      "properties": {
        "receive_message": { "type": "string", "format": "uri" },
        "receive_receipt": { "type": "string", "format": "uri" },
        "register": { "type": "string", "format": "uri" },
        "jwks": { "type": "string", "format": "uri" }
      }
    },
    "security": {
      "type": "object",
      "required": [
        "signature_algorithm", "encryption_algorithm",
        "content_encryption", "minimum_key_size"
      ],
      "properties": {
        "signature_algorithm": { "type": "string" },
        "encryption_algorithm": { "type": "string", "minLength": 1 },
        "supported_encryption_algorithms": {
          "type": "array",
          "items": { "type": "string", "minLength": 1 },
          "minItems": 1,
          "uniqueItems": true
        },
        "content_encryption": { "type": "string" },
        "minimum_key_size": {
          "type": "integer", "minimum": 2048
        }
      }
    }
  }
}