Invoice Trust Protocol (ITP): Discovery, Delivery, and Verification of Electronic Invoices

1.1. Scope

ITP carries invoices in syntaxes defined elsewhere: national formats prescribed by tax authorities, syntaxes based on [EN16931] or Peppol PINT [PEPPOL-PINT], such as [UBL] and [CII], [GOBL], and EDI standards such as ASC X12 [X12] and UN/EDIFACT [EDIFACT]. ITP assumes no semantic model; Appendix A is informative. Tax treatment and the execution of payments are out of scope. Where law or a network agreement mandates a channel, ITP runs alongside it, and the invoice produced or validated by that channel is the legal invoice (Section 7.3).¶

1.2. Relationship to Existing Work

Peppol and the Digital Business Networks Alliance [DBNA] locate a recipient's access point through U-NAPTR records [RFC4848] in a zone run by the network, as specified by OASIS BDXL [BDXL], and through a service metadata publisher. The Digital Business Networks Alliance profiles OASIS SMP 2.0 [SMP2] and the OASIS AS4 profile [BDX-AS4]; Peppol uses its own SMP specification [PEPPOL-SMP] and AS4 profile [PEPPOL-AS4]. Those networks admit access points by contract and certificate. ITP reuses their identifiers; an ITP envelope can be carried over them, and a Participant Document can point to a Peppol endpoint. Appendix D.8 explains why ITP does not reuse BDXL for discovery.¶

EDI value-added networks and exchange platforms that tax authorities run or designate address participants by their own identifiers. ITP treats them as it treats Peppol: their identifiers can be registered as PID schemes (Section 4), their endpoints as channel types (Section 5.5), and an ITP envelope can be carried over any of them that carries arbitrary documents.¶

The IETF EDIINT working group defined AS1 [RFC3335], AS2 [RFC4130], and AS3 [RFC4823] for signed EDI exchange with signed receipts. Their S/MIME signatures cover the transferred payload, but keys are exchanged when the trading partnership is established and certificates may be self-signed (Section 8 of [RFC4130]), so a party outside that partnership cannot tie a signature to a legal entity. ITP signs the invoice itself, independently of any transfer, and binds the key to the legal entity through attestations, so that third parties that later hold it, such as banks, auditors, or factors, can check it. An earlier individual draft [I-D.jaakola-simple-invoicing-protocol] addressed parties by email address and was not pursued. Registered delivery services [ETSI-ERDS], including registered electronic mail [ETSI-REM], give evidence of sending and receipt and can complement ITP's signed acknowledgments.¶

UN/CEFACT and OASIS define the Exchange Header Envelope [XHE], the successor of the UN/CEFACT Standard Business Document Header, which references or contains business documents without changing them and can be signed. ITP defines a JSON envelope so that it can be signed with JOSE, registered in SCITT transparency services, and carry evidence added after signing (Section 7). An XHE envelope can be carried as the document of an ITP envelope.¶

Two current efforts address parts of the same problem. The FIDES Direct e-invoicing track [FIDES-DEI] tests business wallets, decentralized identifiers, verifiable credentials, and qualified seals for identifying the parties to an invoice and for federated discovery alongside Peppol. UN/CEFACT is specifying verifiable trade documents, including the commercial invoice [UNVTD], and the UN Transparency Protocol [UNTP], in which an authoritative register, such as a business register, issues a credential that binds a registered entity to its identifier and optionally to a decentralized identifier. ITP does not require wallets or decentralized identifiers: it uses DNS, HTTPS, JOSE, and SCITT, and adds delivery, status messages, and transparency. An attestation issuer can rely on credentials from business wallets when it issues ITP attestations (Section 6.3), and documents defined by UNVTD can be carried in an ITP envelope.¶

Organizational identity can come from several sources: business and tax registers, certificates issued under electronic signature laws (for example qualified certificates under [EIDAS2] in the European Union, and certificates issued under the laws of other jurisdictions, for which the UNCITRAL Model Laws on Electronic Signatures [UNCITRAL-MLES] and on identity management and trust services [UNCITRAL-MLIT] give a basis for recognition across borders), the verifiable LEI [VLEI] [ISO17442-3], verifiable credentials [W3C-VC], or business wallets such as the European Business Wallet proposal [EU-BW]. Certificates are used directly under rule 3 of Section 6.2, and attestation issuers can rely on the other sources when they issue ITP attestations (Section 6.3). ITP does not define a new identity scheme.¶

1.3. Why the IETF

This document specifies a DNS node name, a well-known URI, an HTTP binding, JOSE and COSE profiles, and a use of SCITT transparency services. No single IETF working group covers all of these. The closest are SCITT (transparency), KEYTRANS (key transparency), HTTPAPI (idempotency), WEBBOTAUTH (HTTP signatures for automated clients), and, for the credentials used by ITP and by [I-D.martinez-itp-agent-mandates], OAUTH (SD-JWT VC and status lists). The author asks DISPATCH whether this document fits an existing group or needs a BoF. The meaning of invoice fields and lifecycle codes stays with CEN, OASIS, UN/CEFACT, OpenPeppol and other network operators, and tax authorities.¶

1.4. The Experiment

This document is Experimental. The experiment is whether:¶

1. at least two independent implementations interoperate on discovery, delivery, signature verification, and transparency receipts, using the test vectors in Appendix C;¶

2. at least two recipients verify envelopes that reach them over channels other than ITP, for example as email attachments, over Peppol or an EDI value-added network, or from a tax authority platform, and publish the share of envelopes that failed verification and why; and¶

3. at least one operator of an existing network or regulated platform publishes ITP discovery data for its participants.¶

Results will be reported on the mailing list where this document is discussed and in later revisions of it. The experiment ends 24 months after publication, when the author expects either to propose a Standards Track revision or to declare the experiment concluded.¶

2.1. JSON

JSON texts [RFC8259] defined by this document MUST be I-JSON [RFC7493]. Receivers MUST reject ITP JSON texts that contain duplicate member names, unpaired surrogates, or nesting deeper than 32 levels, before any canonicalization or signature check. Signed objects are serialized with the JSON Canonicalization Scheme (JCS) [RFC8785] before signing (Appendix D.1). To keep JCS output stable across implementations, ITP objects MUST NOT contain non-integer numbers or integers whose absolute value exceeds 2^53 - 1, and receivers reject objects that do.¶

2.2. Amounts

Monetary amounts are strings that match the "amount" rule below, paired with a currency code [ISO4217]:¶

amount = ["-"] ( "0" / %x31-39 *DIGIT ) ["." 1*DIGIT]

An amount has at most 18 digits before the decimal point and no more decimals than the minor unit of its currency in [ISO4217], which is 0 for some currencies and 3 for others. A receiver rejects an envelope whose amounts break these rules with "envelopeInvalid". The value "-0", and any value equal to zero with a minus sign, is invalid. Amounts are compared as numbers, not as strings. The amount syntax is a wire format, independent of the decimal separator used in documents and displays. A verifier does not reject an envelope because its currency code was withdrawn after the issue date; the minor unit is then that of the code at the issue date.¶

2.3. Text and Language

Strings that identify documents, such as "invoice_number", are UTF-8 strings in Unicode Normalization Form C [UAX15] that conform to the FreeformClass of [RFC8264]. The issuer writes them in the core after removing leading and trailing spaces, after applying the width mapping described in Section 5.2.1 of [RFC8264], which maps fullwidth and halfwidth characters (common in Chinese, Japanese, and Korean input) to their decomposition mappings, and after any further mapping, such as case mapping, that a profile in "profiles" defines for the numbering scheme. Digits SHOULD be ASCII digits. Where the tax authority records a number with other decimal digits, such as Arabic-Indic digits, the core carries it as recorded, and a receiver that checks for duplicates first maps characters of General Category Nd to the ASCII digits with the same value. Bidirectional formatting characters, such as U+200F RIGHT-TO-LEFT MARK, are not allowed by the FreeformClass and are removed from a value taken from the document. Receivers compare these strings code point by code point, and check consistency with the document after applying the same mappings to the value in the document. Other strings are compared after Normalization Form C; general compatibility normalization (NFKC) is not applied, because it changes meaningful characters in some scripts.¶

Members that hold human-readable text, such as names and reason texts, are UTF-8 strings. An object that contains such members MAY contain "lang", a language tag [RFC5646] that applies to all of them; Section 16 gives details.¶

2.4. Other Conventions

Timestamps are "date-time" values of [RFC3339] in UTC. Calendar dates, such as the issue date of an invoice, are "full-date" values in the time zone determined as described for "issue_tz" (Section 7.2). Identifiers of ITP objects are UUID version 7 values [RFC9562]. Base64url encoding follows Section 2 of [RFC7515] without padding. SHA-256 is specified in [RFC6234] and HMAC in [RFC2104]. URIs follow [RFC3986]. ABNF follows [RFC5234] and [RFC7405]. Examples fold long lines as described in [RFC8792].¶

All identifiers of legal entities in examples are fictitious and have no valid check digits. Domain names are taken from [RFC2606]. Values in examples that are not in the initial contents of a registry are illustrative.¶

2.5. Terminology

The terms Signed Statement, Transparency Service, Receipt, Transparent Statement, Registration Policy, Auditor, and Relying Party are used as defined in [RFC9943]. "Origin" and "same-origin" are used as in [RFC6454]. In addition:¶

Participant:

A legal entity, or a natural person acting in business, that issues or receives invoices.¶

Seller, buyer:

The parties to the supply that an invoice documents.¶

Issuer:

The party that issues a given document and signs its envelope. It is the seller, except in self-billing (the buyer) and in issuance by a third party on the seller's behalf. Where a tax authority platform, an authorized provider, or a fiscal device generates or numbers the invoice, the issuer is still the party in whose name it is issued, and the platform's or device's role is recorded as evidence.¶

Node:

An HTTP server that sends and receives ITP messages for one or more participants.¶

Operator:

The organization that runs a node.¶

Directory:

A service that answers queries for Participant Documents. Directory answers are used only if they are accepted under Section 6.¶

Envelope:

The signed ITP object that carries one commercial document, plus unsigned evidence about it (Section 7).¶

Envelope core:

The JSON object that the issuer signs.¶

Document:

The invoice or other commercial document in its original syntax.¶

Legal original:

The representation of the invoice that the applicable law treats as the invoice (Section 7.3).¶

Evidence:

Signed objects added after the issuer signature: renditions, stamps, and Receipts.¶

Stamp:

Evidence produced by a tax authority, a network, a fiscal device, or a timestamping service about an envelope.¶

Bridge:

A component that exchanges documents with a non-ITP channel, such as a tax platform, on behalf of a node.¶

Attestation:

A credential in which an attestation issuer asserts an attribute of a participant (Section 6.3).¶

Trust list:

A signed list of parties that a relying party accepts for given roles (Section 6.1).¶

Profile:

A specification, maintained outside this document, of how ITP is used with a given jurisdiction or network.¶

Participant Document:

A signed document in which a participant publishes its identifiers, keys, and receiving and sending nodes (Section 5.5).¶

Node Document:

A signed document in which a node publishes its endpoints and keys (Section 5.6).¶

3.1. Deployment Model

A participant normally uses a node run by its invoicing or accounting software provider. The participant publishes, or lets its operator publish, a Participant Document that names its receiving endpoints and its keys. An attestation issuer binds the participant's tax identifier to those keys.¶

When the participant issues an invoice, its node signs an envelope, obtains any stamp that the issuer's tax regime requires through a bridge, registers a commitment to the envelope in a transparency service, and delivers the envelope to the recipient's node. The recipient's node checks the envelope and answers with a signed "delivered" status. Later statuses are specified in [I-D.martinez-itp-lifecycle].¶

A recipient whose suppliers do not use ITP can publish its own receiving endpoint and can verify envelopes that reach it through other channels.¶

3.2. Message Flow

 Issuer node                    Recipient's DNS, web, directory, node
     |                                               |
     |  1. DNS _itp TXT, /.well-known/itp            |
     |---------------------------------------------->|
     |  2. Participant Document, Node Document       |
     |<----------------------------------------------|
     |  3. sign envelope; stamp via bridge;          |
     |     register Signed Statement --> TS          |
     |  4. GET nonce                                 |
     |---------------------------------------------->|
     |  5. Replay-Nonce                              |
     |<----------------------------------------------|
     |  6. POST envelope (HTTP Message Signature)    |
     |---------------------------------------------->|
     |  7. 201 + "delivered" status                  |
     |<----------------------------------------------|

3.3. Conformance Classes

Sending node:

Implements discovery (Section 5), acceptance of Participant Documents (Section 6), envelope creation (Section 7), and the HTTP binding as a client (Section 8), including copies to the issuer's archive node (Section 8.5). Because status messages are sent to "issuer_node", it also publishes a Node Document and accepts status messages as a server (Section 8.8).¶

Receiving node:

Publishes Participant and Node Documents, implements the HTTP binding as a server, steps 1 to 4 of Section 11, duplicate detection (Section 8.4), the "copies" endpoint when a participant names it in "archive" (Section 8.5), and the "delivered" and "technical-rejected" statuses (Section 9). A receiving node carries documents as octets and does not need to interpret them, so it MUST NOT reject a document only because it cannot interpret its syntax, and it answers "unsupportedDocument" only when the document matches no entry of the recipient's "accepts" (Section 5.5). So that any two participants share at least one syntax, a receiving node MUST accept invoices and credit notes in UBL 2.1 [UBL21] or a later version, that is, documents with "media_type" "application/xml" whose root element is in the namespace "urn:oasis:names:specification:ubl:schema:xsd:Invoice-2" or "urn:oasis:names:specification:ubl:schema:xsd:CreditNote-2", whatever their customization, and deliver them to the recipient, even when the recipient's "accepts" does not list them; it MUST NOT answer "unsupportedDocument" for them. It SHOULD also accept the syntax that the registered profile of each jurisdiction in which its participant holds a "tax" PID designates as the legal original, such as CFDI in Mexico. UBL is the common base of Peppol BIS Billing 3.0 [PEPPOL-BIS], Peppol PINT [PEPPOL-PINT], the specifications of the Digital Business Networks Alliance in the United States [DBNA], and several national formats. Other syntaxes are optional.¶

Verifier:

Implements all of Section 11. A verifier need not implement the HTTP binding.¶

Directory:

Answers exact-match queries for Participant Documents (Section 5.7) and does not alter the documents it returns.¶

5.1. Starting Point

ITP discovery starts from a DNS name that the sender already knows, for example from a "domain" PID, from a previous invoice, or from the recipient's email address when the recipient controls that domain. Addresses at shared mailbox providers do not identify a participant. Finding a domain from another kind of PID is outside the scope of this document. Directories that offer such lookups are caches whose answers are accepted only under Section 6 (Section 5.7). In many economies most small businesses have no domain name of their own and are known to their counterparties by a tax identifier, a business registration number, or a telephone number. For them, a directory run by a network, an operator, or a tax authority is the usual starting point, and a profile can designate one. The Participant Document it returns is accepted under rule 1 or rule 3 of Section 6.2, which do not require a domain.¶

5.2. Channels Required by Law or by Network Agreements

Some jurisdictions designate the channel or registry through which invoices are delivered to a recipient, and some require clearance by the tax authority before delivery. This document does not change those obligations. ITP discovery can be used in addition, for example to obtain the recipient's keys or to send a copy. An envelope sent through ITP in addition to a designated channel is marked as a copy (Section 7.2); a copy is not a separate payable.¶

5.3. DNS Record

A participant that controls a domain announces ITP support with a TXT record at the underscored name "_itp" [RFC8552] of that domain. The record signals presence and a version, as the "_mta-sts" record of [RFC8461] does; all other data is retrieved over HTTPS.¶

itp-record  = %s"v=ITP1" 1*( *WSP ";" *WSP itp-field ) *WSP [";"]
itp-field   = field-name "=" field-value
field-name  = 1*( ALPHA / DIGIT / "_" )
field-value = 1*( %x21-3A / %x3C-7E )

_itp.acme.example. 3600 IN TXT (
  "v=ITP1; id=20261028T0900; pid=tax:ES:vat:B00000000" )

v:

The version. It MUST be the first field and MUST be "ITP1".¶

id:

Required. An opaque value of 1 to 32 alphanumeric characters that changes whenever the participant's metadata changes.¶

pid:

Optional. The participant's primary PID. This is a claim, verified only as described in Section 6. Participants that are natural persons SHOULD omit it (Section 15).¶

kt:

Optional. A comma-separated list of base64url-encoded SHA-256 JWK Thumbprints [RFC7638] of keys that may sign Participant Documents published for the domain. When the record is validated with DNSSEC, this binds those keys to the domain (Section 6.2). Several thumbprints can be listed, for example for several participants under one domain or during a key change.¶

issuers:

Optional. A comma-separated list of attestation issuer identifiers, as they appear in trust lists, that the participant authorizes to issue attestations for its PIDs. When the field is present, an attestation issuer MUST NOT issue an attestation that binds a key or a domain to a PID of the participant unless its own identifier is listed. This is analogous to the CAA record [RFC8659].¶

The strings of one TXT record are concatenated. TXT records at the name that do not match "itp-record" are ignored. If more than one TXT record at the name starts with "v=ITP1", the client MUST treat discovery as failed for that domain. Unknown fields MUST be ignored.¶

The record is optional; a client can use the well-known URI directly. The "id" field signals a change of metadata, the presence of the record distinguishes a withdrawn participant from a temporary HTTP failure, and, with DNSSEC [RFC4033], the "kt" field binds keys to the domain. DNSSEC is RECOMMENDED (Section 14.3).¶

5.4. Well-Known URI

The URI "https://{domain}/.well-known/itp" returns a JSON object of media type "application/itp-metadata+json" that links to the documents published for that domain:¶

{
  "id": "20261028T0900",
  "participants": [
    {"pid": "tax:ES:vat:B00000000",
     "document": "https://node.example.com/p/7f3a9c2e41d8b605"}
  ]
}

id (required, string):

The same value as the "id" field of the DNS record, if one exists. A client that finds different values treats the resource as not yet updated and retries later.¶

participants (required, array):

Objects with "pid" and "document", the URL of a Participant Document.¶

Participant Document URLs SHOULD contain at least 64 bits of randomness, and nodes MUST NOT offer an index of the documents they host, so that an operator's participants cannot be listed by following URLs.¶

Clients MUST NOT follow redirects to other origins when retrieving this resource. HTTP caching follows [RFC9111]. The resource is not signed; trust decisions use only the signed Participant Document.¶

5.5. Participant Document

A Participant Document is a JWS [RFC7515] in the Flattened JSON Serialization, or in the General JSON Serialization during a key change (Section 6.4), with "typ" "itp-participant+jws". Its payload is:¶

{
  "pid": "tax:ES:vat:B00000000",
  "aliases": ["eas:9920:esb00000000", "domain:acme.example"],
  "name": "Example Logistics S.L.",
  "lang": "es",
  "seq": 7,
  "inbound": [
    {"channel": "itp",
     "node": "https://node.example.com/itp",
     "kids": ["FtIu-VbGrfe_KB6CH7GNwODB72MNxj_ml11dEvO-7kk"],
     "accepts": [
       {"media_type": "application/xml",
        "customization": "urn:cen.eu:en16931:2017"}]},
    {"channel": "peppol",
     "id": "iso6523-actorid-upis::9920:esb00000000"}
  ],
  "senders": [
    {"node": "https://node.example.com/itp",
     "kids": ["FtIu-VbGrfe_KB6CH7GNwODB72MNxj_ml11dEvO-7kk"]}],
  "jwks": {"keys": ["<participant key>", "<operator-held key>"]},
  "delegates": [
    {"kid": "<thumbprint of the operator-held key>",
     "node": "https://node.example.com/itp"}],
  "attestations": [],
  "pin_max_age": 604800,
  "predecessors": [],
  "superseded_by": null,
  "updated": "2026-10-28T09:00:00Z"
}

pid (required, string):

The participant's primary PID.¶

aliases (optional, array of strings):

Other PIDs of the participant, including other tax identifiers.¶

name (optional, string or array):

The registered name, or the registered names in several languages and scripts as described in Section 16, for example in Arabic and in English. It SHOULD be omitted when the participant is a natural person (Section 15).¶

seq (required, integer):

Increases with every new version of the document.¶

inbound (required, array):

Receiving channels. For "itp", "node" is the URL of a Node Document, "kids" lists the thumbprints of the node keys the participant accepts for that node, and "accepts" lists accepted syntaxes as a media type plus, where applicable, the customization identifier of the syntax (for UBL, the content of the CustomizationID element; for ASC X12 and UN/EDIFACT, carried as "application/EDI-X12" and "application/EDIFACT" [RFC1767], the transaction set or message type, its version, and any implementation guide, for example "810:005010"). A document matches an "accepts" entry if its "media_type" is equal to that of the entry and, when the entry has "customization", the document's "customization" is equal to it or starts with it followed by "#". For "peppol", "id" is the Peppol participant identifier including its scheme. Channel types are registered (Section 17.7), and each registration states the members that identify the participant in that channel. Other four-corner networks, exchange platforms that tax authorities run or designate, and EDI value-added networks register channel types on the same terms as "peppol". Until a type is registered for a channel, an entry MAY use the type "network", with "profile", an identifier from the ITP Profiles registry that describes the channel, and "id", the participant's identifier in it. An entry MAY contain "address", an object with "buyer_endpoint" (a PID, matched against "buyer" and "party_ids.buyer") or "buyer_reference" (a string, matched against "references.buyer_reference") or both; the entry applies only to documents in which every member present matches. A legal entity can use this to route invoices for different establishments or departments to different endpoints. Entries are evaluated in order, and a sender uses the first entry that matches the document and whose channel type it supports.¶

senders (required, array of objects):

The nodes authorized to send envelopes and status messages on behalf of the participant, each with "node" (a Node Document URL) and "kids" (thumbprints of the node keys accepted for it). A node key not listed in "kids" is not accepted for that node, so control of the node's web origin alone does not let an attacker replace its keys.¶

archive (optional, object):

The node that keeps the participant's own copy of every envelope issued in its name, with "node" (a Node Document URL) and "kids" (thumbprints of the node keys accepted for it), as in "senders". Nodes listed in "senders" send copies to it as described in Section 8.5. A participant that issues through several nodes, for example from several software products, can name the node of its "itp" entry in "inbound", so that one node holds both the documents it issues and those it receives.¶

jwks (required, object):

The JWK Set [RFC7517] with the participant's signing keys (Section 6.4). Keys are carried by value so that they are covered by the signature on the document.¶

delegates (optional, array):

Keys in "jwks" that an operator holds rather than the participant, each with "kid" and "node", the Node Document URL of that operator. Only these keys produce "delegated-issuer" signatures.¶

attestations (optional, array):

Attestations about the participant (Section 6.3). Each entry is the attestation as a string, or an object with "attestation", the string, and "receipts", an array of objects with the structure of "itp_evidence.receipts" (Section 10) for its registration.¶

pin_max_age (optional, integer):

Seconds, at most 31536000, during which a client that has accepted this document keeps it and treats payment details received through other channels as unverified (Section 14.3). The value 0 removes an existing pin.¶

predecessors (optional, array of objects):

Former PIDs of the participant after a merger, a conversion, or a change of tax identifier, each with "pid", "until" (a "full-date"), and "attestation", a "kyb" attestation whose "pids" claim contains both the former and the current PID.¶

superseded_by (optional, string or null):

Set in the last document published by a former operator to the URL of the participant's new document. This is a hint; the new document is accepted only under Section 6.2.¶

updated (required, string):

Time of the last change.¶

A Participant Document MUST be signed with a key in "jwks" that is not listed in "delegates". Elsewhere in this document, "listed in senders" means listed as "node" in an entry of "senders". An operator that holds only delegated keys cannot change the participant's identity, keys, senders, archive node, or pin.¶

5.6. Node Document

A Node Document is a JWS in the Flattened JSON Serialization with "typ" "itp-node+jws", signed with a key in its own "jwks". As recommended by [RFC9205] and [RFC8820], this specification does not fix endpoint paths; they are published here:¶

{
  "node": "https://node.example.com/itp",
  "versions": ["1"],
  "endpoints": {
    "nonce": "https://node.example.com/itp/nonce",
    "inbox": "https://node.example.com/itp/in",
    "envelope": "https://node.example.com/itp/env/{id}",
    "status": "https://node.example.com/itp/env/{id}/status"
  },
  "jwks": {"keys": [
    {"kty": "OKP", "crv": "Ed25519", "alg": "Ed25519",
     "kid": "FtIu-VbGrfe_KB6CH7GNwODB72MNxj_ml11dEvO-7kk",
     "x": "PUAXw-hDiVqStwqnTRt-vJyYLM8uxJaMwM1V8Sr0Zgw"}]},
  "max_envelope_size": 10485760,
  "storage": {"jurisdictions": ["ES"]},
  "meta": {"terms_of_service": "https://node.example.com/tos"}
}

"node" is the URL of the Node Document itself. "versions" lists the major versions of the envelope core that the node accepts. Endpoint values are URI Templates [RFC6570] of level 1; {id} is an envelope id. The "inbox" endpoint is the same for all participants of the node: the recipient is taken from the signed envelope core, so that identifiers do not appear in URLs or in access logs. A node named in "archive" of a Participant Document also publishes a "copies" endpoint (Section 8.5). A signed GET request to "envelope" returns the envelope as received and all status messages the node holds for it. The node answers such a request, and a GET request to a location returned with status 202, only if it is signed by a node listed in "senders" of the accepted Participant Document of the issuer or of the recipient of that envelope; otherwise it answers 404, as for an envelope it does not hold. "jwks" holds the keys that the node uses for HTTP Message Signatures, operator seals, and the statuses it signs as a node. A Node Document is trusted only because a participant lists it in "senders", "inbound", or "archive", or because an "operator" entry of an accepted trust list has the Node Document URL as its "id", and only its keys listed in that entry's "kids" (or in the trust list entry's "jwks") are accepted. "max_envelope_size" is in octets. "storage" describes where the node stores envelopes: "jurisdictions" lists [ISO3166] alpha-2 codes, and "authority_access" (optional, array of strings) names tax authorities that have online access to them. "meta" holds informational links and is not processed.¶

5.7. Directories

A directory returns Participant Documents unchanged. It answers exact-match queries on a PID only; it MUST NOT offer search by name or by partial identifier, and it applies rate limits per client (Section 15). A directory is identified by a URI Template [RFC6570] of level 1 with the variable "pid", configured locally or named by a profile; a GET request to its expansion with the PID in URN form returns the Participant Document with media type "application/itp-participant+jws", or status 404. A directory MAY answer only requests signed as in Section 8.2 by nodes of operators on a trust list it accepts, and rate-limit per operator, so that bulk queries are attributable. Answers from a directory carry no more trust than the signatures and attestations in the documents returned.¶

6.1. Trust Lists

A trust list is a JWS with "typ" "itp-trust-list+jws". Its payload has "issuer", "seq", "updated", "exp" (after which the whole list is no longer used), and "entries", an array of objects with: "id" (an HTTPS URL that identifies the entry), "role" (from the ITP Trust List Roles registry, Section 17.7), "jwks", "types" (attestation types it may issue, for attestation issuers), "schemes" (values of the ITP Bridge Schemes registry, for bridges), "jurisdictions" ([ISO3166] codes), "nbf", and "exp". The initial roles are "attestation-issuer", "operator", "transparency-service", "witness", and "bridge".¶

"jurisdictions" contains [ISO3166] alpha-2 codes or [ISO3166-2] subdivision codes. A relying party MUST NOT accept an attestation that binds a "tax" PID, in "sub" or in a claim such as "pids", or a PID of another scheme whose registry entry ties the identifier to one jurisdiction (for "eas", an EAS code that designates a national identifier), unless that jurisdiction, or the country of that subdivision code, is in the "jurisdictions" of the issuer's entry. An entry that lists a subdivision covers only PIDs with that subdivision code. An entry without "jurisdictions" covers no such PID. "issuer", "seq", "exp", and "entries" are required, as are "id", "role", and "jwks" in each entry, and a trust list replaces an earlier one from the same issuer only if its "seq" is greater.¶

How relying parties obtain trust lists, and which they accept, is a matter of local configuration, as for other trust anchors. Trust lists can be derived from existing registers, such as the trusted lists of qualified trust service providers [ETSI-TL], registers of Peppol service providers, or national registers of accredited platforms. Section 14.2 discusses the consequences.¶

6.2. Accepting a Participant Document

A relying party MUST NOT accept a Participant Document unless one of the following holds:¶

1. A "kyb" or "tax-registration" attestation from an issuer on an accepted trust list binds the PID to the key that signs the document.¶

2. The "_itp" record of the participant's domain was validated with DNSSEC and its "kt" field lists the key that signs the document, and a "domain-control" attestation from an accepted issuer binds that domain and that key to the PID.¶

3. The document is signed with a key bound to an X.509 certificate [RFC5280] that identifies the participant, is carried with its chain as "x5c" of the signing key's JWK in "jwks", and chains to a trust anchor carried as "x5c" of a key in the "jwks" of an "attestation-issuer" entry of an accepted trust list, for example a qualified certificate for electronic seals under [EIDAS2], a certificate issued under the electronic signature law of another jurisdiction, or a certificate issued to the taxpayer by a certification authority that a tax authority runs or licenses for invoicing. Trust anchors are local configuration and can include certification authorities accredited in only one jurisdiction. Some certificates identify a billing device or software installation rather than the taxpayer; local configuration or the applicable profile states which certificate profiles identify the participant.¶

Rules 1 and 3 are of higher assurance than rule 2. When a relying party holds an accepted document for a PID and obtains another one:¶

• A document accepted under rule 2 MUST NOT replace one accepted under rule 1 or rule 3.¶

• A document that adds a key not present in the accepted document MUST be signed with a non-delegated key of the accepted document (Section 6.4), or the attestation that covers the new key MUST carry a Receipt from a transparency service in an accepted trust list. In the second case the new key is "recently bound" for 72 hours after the registration time of that Receipt.¶

• A document that omits a key present in the accepted document MUST be rejected.¶

• Otherwise, the document with the greater "seq" replaces the other. If two different documents have the same "seq", the one registered first in a transparency service accepted by the relying party prevails. If neither is registered, the relying party MUST NOT deliver to that participant through ITP until a document with a greater "seq" is accepted.¶

A key bound to a PID for the first time through an attestation registered less than 72 hours earlier is also "recently bound" until 72 hours after registration; this rule applies to first contact. A key that a relying party accepts for the first time under rule 3 is recently bound until 72 hours after the "notBefore" time of its certificate. Participants accepted under rule 3 SHOULD register their Participant Documents (Section 6.5), since certificates are not registered in ITP transparency services. Companion documents that carry payment details, such as [I-D.martinez-itp-lifecycle], say how recently bound keys affect them.¶

6.3. Attestations

Attestations are SD-JWTs [RFC9901] with "typ" "itp-attestation+sd-jwt". The issuer-signed JWT contains "iss" (the "id" of the attestation issuer's trust list entry), "sub" (the subject's PID in URN form, Section 4), "type" (from the ITP Attestation Types registry), and the claims of that type. The initial types are:¶

kyb:

The entity exists and is active and a representative was verified. Claims: "pids" (all PIDs covered, in URN form) and "keys" (thumbprints of the participant keys the entity confirmed).¶

tax-registration:

The PID in "sub" is a valid tax identifier of the entity. Claims: "keys", and "check" with the source and date of the check, for example a query to the validation service of a tax authority or to a service that covers several jurisdictions, such as [VIES].¶

domain-control:

The legal entity identified by "sub" controls the domain in "domain", as verified by the attestation issuer both for the domain (for example with a technique from [I-D.ietf-dnsop-domain-verification-techniques]) and for the entity. Claims: "domain" and "keys". Its validity period is at most 90 days.¶

issuance-authorization:

The seller in "sub" authorizes another party to issue documents on its behalf. Claims: "authorized_issuer" (the authorized PID in URN form), "role" ("buyer" or "third-party"), and "period", an object with "start" and optional "end" ("full-date" values); the authorization covers documents whose "issue_date" falls in that period.¶

The attestation type "tax-registration" is distinct from the stamp type of the same name (Section 7.5); text that uses the name says which one it means.¶

Claims not registered by [RFC7519] are private claim names (Section 4.3 of [RFC7519]) whose meaning is given by this section for the "typ" value "itp-attestation+sd-jwt" only.¶

[I-D.martinez-itp-lifecycle] defines an attestation type for payment accounts. Every attestation includes "iat", "exp", and a status reference in the format of [I-D.ietf-oauth-status-list]. Attestation issuers MUST register each attestation they issue in a transparency service (Section 10), so that participants, or monitors acting for them (Section 6.5), can detect attestations issued without their knowledge. An attestation issuer that learns that a key listed in "keys" is compromised, or that an attestation was issued in error, MUST revoke the attestation through its status reference. When it obtains a Participant Document in order to deliver, a relying party uses an attestation under Section 6.2 only if it is within its validity period and not revoked at that time.¶

6.4. Keys

The "kid" of each JWK MUST be its JWK SHA-256 Thumbprint [RFC7638], and each JWK MUST contain "alg". A verifier MUST reject a signature whose algorithm differs from the "alg" of the key. The validity of a key is given by the "nbf" and "exp" JWK parameters and its revocation by the "revoked" JWK parameter, all registered by [OPENID-FED]. A key whose "revoked" member has the reason "compromised" is treated as compromised from its "revoked_at" time.¶

Keys are never removed from "jwks"; a key that is no longer used is expired or revoked. Revocation is monotonic: once a relying party has seen a key revoked in an accepted document, it treats the key as revoked even if a later document omits the "revoked" member, and it keeps the earliest "revoked_at" it has seen.¶

Implementations MUST support verification with "Ed25519" [RFC8032] [RFC9864], "ES256", and "PS256" [RFC7518]. Ed25519 public keys are JWKs with "kty" "OKP" and "crv" "Ed25519" [RFC8037]. Ed25519 signatures are verified with the checks of Section 5.1.7 of [RFC8032], rejecting non-canonical encodings. Every envelope MUST carry at least one "issuer" or "delegated-issuer" signature with one of these algorithms. An issuer MAY add signatures with other algorithms, including ML-DSA as specified for JOSE in [RFC9964]; the envelope core lists every algorithm used in "sig_algs" (Section 7.2). Keys certified for tax purposes can use other algorithms, such as RSASSA-PKCS1-v1_5 ("RS256") on hardware tokens, or national algorithms such as GOST R 34.10-2012 [RFC7091] or SM2 with SM3. A signature with such a key is added as an additional signature, once a JOSE identifier exists for its algorithm, or is applied inside the legal original and declared in "native_signature" (Section 7.3); the envelope still needs a signature with one of the mandatory algorithms, which can be a "delegated-issuer" signature, so that any verifier can check it. The values "none" and "EdDSA", and symmetric algorithms, MUST be rejected [RFC8725]. Implementations SHOULD support verification with "RS256" [RFC7518], which keys certified for tax purposes often use.¶

A signature is valid only if the key was within its validity period at the signing time, and the signing time precedes any compromise time. The signing time is established by a Receipt (Section 10) or by a timestamp stamp; a time asserted by the signer alone is not sufficient. Where the profile for its scheme allows it, a "fiscal-device-signature", "tax-registration", or "tax-clearance" stamp from a signer accepted under Section 7.5 also establishes it; this serves issuers whose certified devices or tax platforms are reachable when a transparency service is not. When neither is yet available, a relying party MAY use the time at which it received the envelope, provided the key is valid and not revoked at that time, and it re-evaluates the signature when evidence is added later.¶

To change keys, the participant publishes a Participant Document with a greater "seq" in the General JSON Serialization, signed with both the old and the new non-delegated key, so that it proves possession of both, as ACME account key rollover does (Section 7.3.5 of [RFC8555]). If the old key is compromised, an attestation issuer instead attests the new key (Section 6.2).¶

6.5. Key Transparency and Monitoring

Each Participant Document SHOULD be registered in a transparency service (Section 10). Participants, or monitors acting for them, can then detect keys or attestations that an operator or attestation issuer added without their consent. This is a simpler form of the key transparency systems described in [I-D.ietf-keytrans-architecture]: registrations are logged for monitoring, without the verifiable lookups that those systems provide.¶

A participant can rely on a monitor: a service that watches the logs for registrations that name its PIDs or keys and alerts the participant. Monitors have no role in the protocol, and any party can operate one.¶

7.1. Serialization

An envelope is a JWS in the General JSON Serialization [RFC7515], with one additional member, "itp_evidence":¶

{
  "payload": "<base64url of JCS(envelope core)>",
  "signatures": [
    {"protected": "<base64url of header>",
     "signature": "<base64url of signature>"}
  ],
  "itp_evidence": {
    "renditions": [],
    "stamps": [],
    "receipts": []
  }
}

The payload is the octet string that JCS produces from the envelope core. Verifiers check signatures over the payload octets as received and MUST NOT re-serialize the core before verification. Signatures MUST NOT have an unprotected "header" member. "itp_evidence" is not covered by the issuer signature; each item in it is a separately signed object bound to the envelope digest.¶

The envelope digest is the SHA-256 hash of the payload octets. Where this document writes a digest as a JSON value, it is an object with "alg" and "value" (the base64url-encoded hash). Values of "alg" are taken from the "Hash Algorithms for HTTP Digest Fields" registry [RFC9530]; "sha-256" MUST be supported.¶

Over HTTP, an envelope uses the media type "application/itp-envelope+jws" (Section 17.3).¶

7.2. Envelope Core

Members are listed with their requirement level and JSON type. The correspondence with [EN16931] and PINT business terms is given in Appendix A for information; mappings to other models are left to profiles.¶

itp (required, string):

The major version, "1".¶

crit (optional, array of strings):

Names of members of the core that a receiver MUST understand. A receiver that does not understand a listed member rejects the envelope with "unsupportedExtension". Members defined in this document are never listed.¶

id (required, string):

A UUIDv7 assigned by the issuing node.¶

type (required, string):

A value from the ITP Document Types registry. The initial values are "invoice", "credit-note", "debit-note", "prepayment-invoice", "simplified-invoice", "consolidated-invoice", "sales-receipt", "payment-receipt" (a fiscal document that records a payment, such as a Mexican CFDI of type P), "withholding-certificate", "transport-document", "correction-letter", and "proforma". All of them except "proforma" are fiscal documents. A "proforma" document has no fiscal effect and MUST NOT carry stamps of type "tax-registration", "tax-clearance", or "tax-report". Table 5 gives the properties of each initial value.¶

type_code (optional, string):

The [UNTDID1001] document name code, for example "380" or "381". It SHOULD be present where such a code applies to the document.¶

native_type (optional, object):

The document type code of the applicable regime, with "scheme" (from the ITP Bridge Schemes registry) and "code", where numbering depends on it, as when sequences run per national document type. Duplicate detection (Section 8.4) treats documents with different "native_type" as different.¶

issuer_role (required, string):

"seller", "buyer" (self-billing), or "third-party".¶

issuer (required, string):

The PID of the party that issues the document and signs the envelope.¶

seller (required, string):

The PID of the seller.¶

buyer (string):

The PID of the buyer. It is omitted only for documents addressed to consumers or to unidentified buyers. Generic identifiers that some tax authorities prescribe for consumers, unidentified buyers, or foreign parties identify no party; they MUST NOT be used as PIDs and appear only in the document.¶

party_ids (optional, object):

Additional PIDs of the parties, as arrays under "seller" and "buyer", for jurisdictions where a party has several tax identifiers.¶

recipient (string):

The PID of the party the envelope is delivered to: normally the buyer, and the seller in self-billing. Required when the envelope is delivered through ITP.¶

authorization (string):

Required when "issuer_role" is not "seller" and the document is issued on the seller's behalf: an "issuance-authorization" attestation (Section 6.3) in which the seller authorizes the issuer. Document types that the buyer issues in its own right, such as "withholding-certificate", are marked as such in the ITP Document Types registry; they need no authorization, and "issuer" MUST equal "buyer".¶

issuer_node (required, string):

The URL of the issuing node's Node Document. Status messages from the recipient's side are sent to it (Section 8.8).¶

issuer_participant_document (optional, string):

The HTTPS URL of the issuer's current Participant Document, so that a recipient that has not dealt with the issuer before can obtain it. It carries no trust: the document is accepted only under Section 6.2, and the rules for dereferencing URLs in Section 8 apply. It SHOULD be present.¶

invoice_number (string):

The identifier that the issuer assigned to the document, including any series, unique within that series. Required for fiscal documents unless the number is assigned by a tax authority, in which case it appears in "fiscal_codes" of the core or of a stamp or rendition (Section 7.5).¶

issue_date (required, string):

The date of issue as stated in the document, a "full-date".¶

issue_tz (optional, string):

The time zone name from the IANA Time Zone Database [RFC6557] in which "issue_date" is expressed. It SHOULD be present when the issuer's country has more than one time zone or the issuer is not the seller. If it is absent, the time zone of the place of issue stated in the document applies or, if the document states none, verifiers treat "issue_date" as uncertain by one day when they compare it with other times.¶

issued_at (optional, string):

The "date-time" at which the document was generated, where a jurisdiction gives legal effect to a time of issue.¶

issuance_mode (optional, string):

"normal" (the default), "contingency" when the document was issued under a procedure that the tax authority defines for periods in which its system cannot be reached, or "offline" when the issuing device or software was not connected. Both require later regularization under the applicable rules.¶

tax_point_date (optional, string):

The date on which the tax becomes chargeable, if different from the issue date.¶

invoice_period (optional, object):

"start" and "end" dates of a summary or periodic invoice.¶

currency (required, string):

The [ISO4217] code of the invoice currency.¶

tax_currency (optional, string):

The [ISO4217] code in which tax is accounted, when it differs from "currency".¶

exchange_rate (optional, object):

"rate" (a decimal string, the number of units of "tax_currency" per unit of "currency"), "date", and "source", when amounts are converted for tax purposes.¶

total_with_tax, amount_due (strings):

The invoice total including taxes, and the amount due for payment, as "amount" values. Required for document types that the ITP Document Types registry marks as stating an amount, and omitted otherwise, for example in correction letters and transport documents.¶

tax_summary (optional, array):

One object per tax, component, category, and jurisdiction, with "scheme" (for example "vat", "gst", "sales-tax", or a national scheme registered in the ITP Tax Schemes registry), optional "component" (for taxes split between levels of government, such as the central, state, and integrated components of Indian GST, as the profile names them), "category", "percent" (a percentage as a decimal string), "base", and "amount"; optional "jurisdiction" (an [ISO3166] or [ISO3166-2] code, or a code that the tax scheme defines for a county, city, or municipality); and optional "withheld" (true when the buyer withholds the tax and pays it to the authority, so that it is not part of "amount_due"). A tax levied per unit has "unit_amount" and "unit" in place of "percent". A verifier can use it to compare tax totals with tax authority records without parsing the document.¶

fiscal_codes (optional, array):

Codes that identify the document for tax purposes, each with "scheme" (from the ITP Bridge Schemes registry), "type" ("number", "uuid", "hash", or a value that the specification of the bridge scheme defines), "value", "assigned_by" ("issuer", "authority", or "device" for a certified fiscal device or control unit), and optional "qr_payload". Codes assigned by an authority are usually not known when the core is signed; they are then carried in the stamp or rendition that the authority's response produces (Section 7.5).¶

chain (optional, object):

For regimes that chain documents: "scope" (the series, device, or establishment the chain belongs to), "counter", and "prev_digest" (a digest object over the previous document as the regime defines it).¶

fiscal_device (optional, object):

For documents produced by a certified fiscal device: "scheme" (from the ITP Bridge Schemes registry), "serial", and "registration_id".¶

native_signature (optional, object):

Declares a signature or seal inside the document that the applicable regime requires: "format" (for example "xades", "cades", "jades", "xmldsig" for XML Signature without AdES properties, or a seal format defined by a bridge scheme, such as a signature over a canonical string of the document), "level" (where the format defines levels), and "cert_scheme" (the certification framework of the signing certificate, such as a national public key infrastructure or certificates issued by a tax authority). The signature itself stays in the document (Section 7.3).¶

document_languages (optional, array of strings):

Language tags [RFC5646] of the human-readable text in the document.¶

profiles (optional, array of strings):

Identifiers of the profiles that apply to the document, from the ITP Profiles registry. They tell the recipient which jurisdiction rules, such as deadlines and cancellation policies, apply.¶

delivery_role (required, string):

"primary" or "copy" (Section 5.2).¶

document (required, object):

The document, given as "content_b64" (base64url of its octets) or "href" (an HTTPS URL), together with "media_type", optional "customization" and "profile" identifiers, and "digest", computed over the octets. "content_b64" is RECOMMENDED. An "href" URL MUST be same-origin with "issuer_node" or with a node listed in "senders" of the issuer's Participant Document. A recipient that receives "href" MUST retrieve the document when it accepts the envelope and store it with the envelope. JSON documents are also carried as octets, so the digest never depends on canonicalization.¶

attachments (optional, array):

Supporting documents, each with "name", "media_type", "digest", and "content_b64" or "href", processed like "document".¶

legal_original (string):

"document", or "rendition" when the legal original is produced by a clearance channel (Section 7.3). Required for fiscal documents.¶

required_evidence (optional, array of strings):

Stamp types (Section 7.5) that the issuer has obtained or will obtain for this envelope. Verifiers report any that is missing.¶

sig_algs (required, array of strings):

The algorithms of all issuer and delegated-issuer signatures that the issuer applied. For each algorithm in "sig_algs" that a verifier supports, it MUST find a valid issuer or delegated-issuer signature with that algorithm, so that removing a signature cannot downgrade verification. An "issuer" or "delegated-issuer" signature whose algorithm is not listed in "sig_algs" is reported as failed and is not used to validate the envelope.¶

references (optional, object):

"order", "buyer_reference", "contract", "project", "receiving_advice", "despatch_advice" (an array), "prepayments" (an array of references to prepayment documents settled by this one), "public_buyer" (an object with administrative codes of a public buyer, as a profile defines them), and "replaces", the id of an envelope that this one replaces after a clearance rejection.¶

correction (optional, object):

For corrective documents: "corrects", an array of references to corrected documents, each an object with "envelope_id", with "invoice_number" and "issue_date", or, for a document whose number an authority assigned, with "fiscal_code", an object with "scheme", "type", and "value" as in "fiscal_codes"; "method" ("substitution" or "difference"); optional "period" for corrections that cover a period; and "code", a code of the applicable jurisdiction.¶

payment (optional, object):

Payment terms, as defined in [I-D.martinez-itp-lifecycle]. A receiver that does not implement that document ignores it.¶

transparency_salt (string):

32 random octets, base64url-encoded. Required if the envelope is registered (Section 10).¶

agent (optional, object):

Present when a software agent produced the envelope; defined in [I-D.martinez-itp-agent-mandates].¶

Members that repeat content of the document MUST be consistent with it, and the document prevails. A receiving node that interprets the document and finds a contradiction rejects the envelope with "inconsistentCore". XML documents MUST be parsed with document type definitions and external entities disabled.¶

7.3. Legal Original

Where the issuer's own document is the invoice, the legal original is "document". In clearance regimes, the invoice is the artifact that the tax authority, or a provider it accredits, accepts, stamps, or delivers. A bridge adds that artifact to "itp_evidence.renditions". Because the core is signed before the rendition exists, the issuer sets "legal_original" to "rendition", and the verifier takes as legal original the rendition from a signer accepted under Section 7.5 for the applicable scheme. If there is more than one such rendition for the same scheme, the verifier reports the conflict and does not choose. The envelope core is not modified after signing; renditions are carried only in "itp_evidence".¶

A human-readable rendition, such as a PDF produced from the document, is never the legal original unless the applicable profile says so. Renditions produced for people are expected to be accessible, for example by following [WCAG22] for HTML renditions.¶

Where the tax authority's platform issues the invoice and assigns its number, the data that the issuer submits is not an invoice until the platform issues it. The issuer sets "legal_original" to "rendition" and omits "invoice_number", and a bridge adds the platform's output as a rendition. The same applies where the law makes a code added by the authority part of the invoice.¶

The issuer signature is an envelope-level signature. It is not by itself an advanced or qualified electronic signature or seal under [EIDAS2] or under any other regime, and a "delegated-issuer" signature identifies the operator, not the participant. Whether ITP evidence contributes to the controls that establish authenticity of origin and integrity of an invoice under the applicable tax law, for example Article 233 of [EU-VAT-DIR] in the European Union, is for the issuer and its tax authority to determine. Where a signature or seal on the invoice itself is required, it is applied in the native syntax of the legal original, for example XAdES [XADES] on UBL, CAdES [CADES], or JAdES [JADES], and is declared in "native_signature".¶

7.4. Signature Header Parameters

The protected header of every signature on an envelope contains "alg", "kid", "typ" with the value "itp-envelope+jws", "itp_role", and "crit" with a value that includes "itp_role" (Section 4.1.11 of [RFC7515]). A JOSE library that does not know "itp_role" therefore rejects the signature instead of ignoring the role.¶

itp_role:

A value from the ITP Signer Roles registry: "issuer" (a key of the participant that signs the object: the issuer of an envelope, or the party in "by" of a status message), "delegated-issuer" (a key listed in "delegates" of that participant's Participant Document), "node" (a node key, for the statuses that a node signs), "operator-seal" (a node stating that it validated the envelope), "bridge" (a key of a bridge, for renditions, stamps, and the statuses a bridge emits), or "agent" (see [I-D.martinez-itp-agent-mandates]).¶

A verifier MUST reject an "issuer" signature whose key is listed in "delegates", and a "delegated-issuer" signature whose key is not. An envelope is valid if at least one "issuer" or "delegated-issuer" signature verifies with a key valid at the signing time, and the "sig_algs" rule in Section 7.2 is met. Other signatures that fail are reported and ignored, so that a signature added by a third party cannot invalidate an envelope. An "operator-seal" or "agent" signature is never accepted in place of an "issuer" or "delegated-issuer" signature. An "operator-seal" signature is made with a key listed in "kids" of the "senders" entry for that node in the issuer's Participant Document or, on a status message, in the Participant Document of the party in "by". Keys for "agent" signatures come from the mandate in the "agent" member, and not from Section 6; a verifier that does not implement [I-D.martinez-itp-agent-mandates] ignores "agent" signatures.¶

A protected header MAY contain "x5c" when the key is accepted under rule 3 of Section 6.2. A key in "jwk" or "x5c" MUST NOT be used unless its JWK SHA-256 Thumbprint equals a "kid" accepted under Section 6 for the signing time.¶

7.5. Evidence Objects

Each rendition and stamp is a JWS in the Flattened JSON Serialization signed by the bridge that obtained it from the authority, network, fiscal device, or timestamping service, or by the issuer's node where the profile for the scheme lets that node act as bridge. Its protected header has "typ" "itp-rendition+jws" or "itp-stamp+jws", "itp_role" "bridge", and "crit" including "itp_role". Any signature of the authority, device, or service itself is carried in "evidence_token". The JWS payload contains "type" (required, a stamp type, or "rendition"), "scheme" (required, from the ITP Bridge Schemes registry), "envelope_digest" (required), "issued_at" (required), optional "authority_reference" (the identifier that the authority or network assigned), optional "response_digest" (the digest of the authority's or network's response), optional "evidence_token" (base64url of a token that the scheme defines), and optional "fiscal_codes" with the same structure as in Section 7.2. A "timestamp" stamp has the scheme "rfc3161" and carries in "evidence_token" a time-stamp token [RFC3161] over the envelope digest or, in a status message, over the status message digest. A verifier uses the genTime of the token as a trusted time only if the token validates to a time-stamping authority accepted by local configuration or whose certificate is for a key in the "jwks" of the bridge's trust list entry, and its messageImprint equals, under the same hash algorithm, the envelope digest or, for a stamp in the "itp_evidence" of a status message, the status message digest (Section 9). A rendition also contains "media_type" and "content_b64" with the legal original. For example:¶

{
  "type": "tax-registration",
  "scheme": "example-registration",
  "envelope_digest": {"alg": "sha-256",
    "value": "<envelope digest>"},
  "issued_at": "2026-10-28T10:15:03Z",
  "authority_reference": "A-0000000000000000",
  "response_digest": {"alg": "sha-256",
    "value": "RBNvo1WzZ4oRRq0W9-hknpT7T8If536DEMBg9hyq_4o"}
}

Stamp types and scheme names are registered (Section 17.7). The initial stamp types are "tax-registration", "tax-clearance", "tax-report", "network-ack", "fiscal-device-signature", and "timestamp". The bridge retains the response whose digest is in "response_digest". Verifiers accept a rendition or a stamp only if its signer is a bridge on an accepted trust list for the scheme concerned, or a node listed in "senders" of the issuer's Participant Document when the profile for that scheme allows the issuer's own node to act as bridge. Unknown stamp types are reported and otherwise ignored.¶

Stamps can also be attached to envelopes that are never delivered, for example when a jurisdiction requires reporting of a transaction but no exchange of the invoice through ITP.¶

Receipts are described in Section 10.¶

8.1. General

ITP uses HTTPS with TLS 1.3 [RFC9846], following [RFC9325], and servers are authenticated as described in [RFC9525]. The TLS trust anchors that a node uses are local configuration and need not be limited to those of web browsers. Nodes MAY also offer TLS 1.3 cipher suites with national algorithms, such as those of [RFC8998] or [RFC9367], but MUST support the mandatory-to-implement cipher suite, signature algorithms, and key exchange groups of Section 9.1 of [RFC9846], so that nodes in different jurisdictions can connect. HTTP semantics follow [RFC9110]. Clients obtain endpoint URLs from Node Documents.¶

When a node dereferences a URL while processing ITP objects, including status list and trust list URLs, it MUST use HTTPS, MUST NOT follow redirects to other origins, and MUST apply limits on size, time, and the number of retrievals caused by one inbound request. It MUST check the address it actually connects to, after DNS resolution and for every connection, and MUST NOT connect to addresses whose "Globally Reachable" value is "False" in the IANA special-purpose address registries [IANA-SPECIAL] [RFC6890] [RFC8190], such as loopback, private, or link-local addresses. This prevents DNS rebinding. A node MUST NOT obtain verification keys from URLs found in an inbound envelope; keys come only from documents accepted under Section 6.¶

8.2. Request Authentication and Replay Protection

Every request between nodes, and every response that a node generates for such a request, MUST be signed with HTTP Message Signatures [RFC9421], in a profile similar to the one in [I-D.ietf-webbotauth-httpsig-protocol]:¶

• The signature label is "itp" and the "tag" parameter is "itp".¶

• The "keyid" parameter is the "kid" of a key in the sending node's Node Document. The algorithm is determined by that key and not by an "alg" parameter. Node keys are "Ed25519" keys, used with "ed25519", or "ES256" keys, used with "ecdsa-p256-sha256".¶

• Requests with content cover "@method", "@target-uri", "content-digest" [RFC9530], "content-type", and "idempotency-key". Requests without content cover "@method" and "@target-uri". All requests include the "created", "expires", and "nonce" parameters, and "expires" is at most 300 seconds after "created".¶

• Responses cover "@status" and, if there is content, "content-digest", plus the request components "@method", "@target-uri", and, where present, "idempotency-key", with the "req" parameter (Section 2.4 of [RFC9421]). They include the "created" and "keyid" parameters.¶

• Requests to the "nonce" endpoint use HEAD or GET and are not signed, since the client has no nonce yet.¶

A client MUST verify the signature of each response with a key listed in "kids" of the "inbound" or "senders" entry, or for copies (Section 8.5) the "archive" entry, through which it found that node. A client treats an unsigned response, or one whose signature does not verify, such as a 413 or 502 response from an intermediary, as a transport failure and retries according to Section 8.4.¶

A receiver MUST verify "content-digest" against the content received and MUST reject a signature whose "created" time is more than 60 seconds in the future. A request whose HTTP Message Signature or "content-digest" does not verify is rejected with "badSignature".¶

Nonces are issued by the receiving node and carried in the Replay-Nonce response field defined in Section 6.5.1 of [RFC8555]. A client obtains a first nonce from the "nonce" endpoint, and every response from a node includes a fresh one. A node MUST accept each nonce at most once and MUST reject a request with an unknown or used nonce with the error "badNonce" (Section 8.7). Nonces SHOULD be generated so that the node can check them without keeping state for unused nonces, for example by authenticating an expiry time with a node secret, so that the nonce endpoint cannot be used to exhaust memory.¶

For delivery, the sending node MUST be listed in "senders" of the issuer's Participant Document. For status messages, it MUST be listed in "senders" of the issuer's or the recipient's Participant Document, or be the node of the recipient's "itp" "inbound" entry that accepted the envelope; the status message itself is verified separately, as Section 9 describes. The receiving node resolves "keyid" among the "kids" of those entries, and otherwise rejects the request with "unauthorizedSender".¶

How software authenticates to its own node is outside this specification; OAuth 2.0 [RFC6749] with sender-constrained access tokens ([RFC9449] or [RFC8705]), as recommended in [RFC9700], is one option.¶

8.3. Delivery

A node delivers an envelope with a POST request to the "inbox" endpoint of the recipient's node. It takes that endpoint only from a Node Document that it has verified with a key listed in "kids" of the recipient's "inbound" entry for that node, so that a party that controls only the node's web origin, for example after its domain has expired, does not receive envelopes. The recipient is the "recipient" member of the signed core. The values below are those of Appendix C; the content, shown truncated, is the 1365-octet envelope described there:¶

NOTE: '\' line wrapping per RFC 8792

POST /itp/in HTTP/1.1
Host: node.example.net
Content-Type: application/itp-envelope+jws
Content-Length: 1365
Idempotency-Key: "01a18201-84a0-7b2a-9d41-6c1f0e8a5b77"
Content-Digest: \
  sha-256=:tGM8fHYi3ZCow6CDlj142ehZqwBn0THA+Lw0u7U3zMc=:
Signature-Input: itp=("@method" "@target-uri" "content-digest" \
  "content-type" "idempotency-key");created=1793182503;\
  expires=1793182803;nonce="dG9rZW4tMDAx";\
  keyid="FtIu-VbGrfe_KB6CH7GNwODB72MNxj_ml11dEvO-7kk";tag="itp"
Signature: itp=:bOzCUemhJyw3eBk8Wy/00zxlzv773K0IBmEaFL5e6LkQqP2W8rDR\
  dAK9uujlKF8hzCc1KwTj57eziXc3ysvjDA==:

{"itp_evidence":{"receipts":[],"renditions":[],"stamps":[]},...}

The receiving node validates the request and the envelope as in steps 1 to 4 of Section 11. If it accepts the envelope, it responds with status 201, a Location field with the envelope URL, and content of type "application/itp-status+jws" holding a "delivered" status message. Otherwise the response is a problem details object [RFC9457] with an ITP error type, for example "unknownRecipient" when the node serves no participant with the PID in "recipient", or "untrustedIssuer" when step 2 of Section 11 fails. An envelope larger than "max_envelope_size" results in status 413 with "envelopeTooLarge". A receiving node that learns, after a 201 response, that it cannot pass the envelope to the recipient sends a "technical-rejected" status (Section 9).¶

A receiving node processes a delivery request in this order: it checks the size, the nonce, and "content-digest"; it performs step 1 of Section 11; it obtains and accepts the issuer's Participant Document as in step 2; it resolves "keyid" among the "kids" of the issuer's "senders" entries and verifies the HTTP Message Signature (Section 8.2); it completes steps 2 and 3; and only then does it look up the recipient and perform step 4. The time it takes to fail one of the checks before the recipient lookup does not depend on the recipient. It returns "unknownRecipient" only to a sending node that has passed these checks, and it rate-limits such answers per issuer. A client that has not passed them therefore cannot learn from the inbox whether a PID is a participant of the node.¶

8.4. Idempotency and Duplicates

ITP uses the Idempotency-Key field defined in [I-D.ietf-httpapi-idempotency-key-header] for its syntax and registration; the processing rules below replace those of that document for ITP requests. The field is required on delivery and status requests. Its value is the id of the envelope or status message. The scope of a key is the authenticated sending node. Two requests have the same content if they carry the same envelope digest, for envelopes, or the same status message digest, so a retry that adds evidence to "itp_evidence" is not a conflict. The receiving node verifies new evidence items, adds them to its stored envelope, and returns them on a GET request to "envelope". A missing key results in status 400 with "idempotencyKeyMissing", reuse of a key with different content in status 422 with "idempotencyKeyReused", and a concurrent request with the same key in status 409 with "requestInProgress". A repeated request with the same content receives the original response. Nodes MUST retain keys for at least 7 days.¶

Independently of HTTP idempotency, a receiving node keeps track of the envelopes it has received for as long as it retains them:¶

• An envelope with the same envelope digest as one already received is a duplicate. The node returns the original "delivered" status and MUST NOT present it to the recipient as a new payable.¶

• An envelope with an "id" already seen and a different digest is rejected with "envelopeInvalid", unless the Idempotency-Key rules already reject it with "idempotencyKeyReused".¶

• An envelope with a different "id" from one already received, but with the same issuer (any PID verified for the same Participant Document) and the same "invoice_number" within the same numbering scope, where both envelopes contain "invoice_number" and either neither contains "native_type" or both contain equal "native_type" values, or with a "fiscal_codes" entry assigned by an authority or a device (in the core or in an accepted stamp or rendition) that has the same "scheme", "type", and "value", is delivered and flagged to the recipient as a possible duplicate, unless its "references.replaces" names an envelope that was rejected in clearance. The numbering scope is defined by the applicable profile, for example a fiscal year from 1 April to 31 March; without a profile it is the calendar year of "issue_date".¶

8.5. Copies for the Issuer

A participant can name in "archive" of its Participant Document a node that keeps a copy of every envelope issued in its name (Section 5.5). When the issuer's accepted Participant Document contains "archive", a node listed in its "senders" that creates an envelope MUST send a copy of it to the archive node, whether or not it delivers the envelope through ITP, unless it is itself that node. The copy is the envelope as signed, with the evidence the sending node holds. It is sent with a POST request to the "copies" endpoint of the archive node, which the sending node takes only from a Node Document that it has verified with a key listed in "kids" of the "archive" entry. Section 8.2 and Section 8.3 apply to the request and the response, with these differences:¶

• The archive node accepts a copy only if the sending node is listed in "senders" of the issuer's accepted Participant Document and the archive node is the node named in "archive" of that document; otherwise it rejects the request with "unauthorizedSender". It validates the envelope as in steps 1 to 4 of Section 11. Where the processing order of Section 8.3 looks up the recipient, the archive node looks up the participant named in "issuer", and it does not answer "unknownRecipient"; "recipient" can be absent from a copy.¶

• The envelope is not changed for the copy. Its "delivery_role" keeps the meaning given in Section 5.2 and refers to delivery to the recipient. What marks the request as a copy is the endpoint to which it is sent, which the HTTP Message Signature covers. The archive node therefore holds an envelope with the same envelope digest as the one the recipient holds.¶

• On success the archive node responds with status 201 and a Location field, without content. It signs no status message about a copy, so a copy never produces a "delivered" or "technical-rejected" status.¶

• Idempotency keys of requests to "copies" have a scope of their own, separate from that of requests to "inbox" and "status" at the same node. The duplicate rules of Section 8.4 apply among the copies held for one participant, separately from the envelopes received for it: a copy with an envelope digest already held receives the original response, and new evidence is added to the stored copy. A possible duplicate is flagged to the participant, which can show that two of its senders used the same number.¶

The sending node also sends to the "copies" endpoint, with media type "application/itp-status+jws", each status message for the envelope that it signs or receives, including the "delivered" status from the recipient's node and messages signed by the counterparty. The archive node stores each status message whose signature is valid with the copy named by its "envelope_id" and "envelope_digest", and answers 404 for an envelope it does not hold. It does not send copies or their status messages to any other node; the forwarding rule of Section 8.8 does not apply to them. It presents copies to the participant as documents issued in the participant's name and MUST NOT present them as documents received from another party.¶

8.6. Asynchronous Results

Bridges to clearance platforms can take minutes or hours to produce a result. A node that cannot complete processing synchronously responds with status 202, a Location field identifying the envelope, and a Retry-After field. The client obtains the result with a signed GET request to that location. Until processing completes, the node answers again with status 202 and Retry-After; afterwards it answers with status 200 and the "delivered" status message, or with the problem details object that the POST request would have received.¶

8.7. Errors

Errors are problem details objects [RFC9457] whose "type" is a URN of the form "urn:ietf:params:itp:error:{name}", registered in the ITP Error Types registry (Section 17.6). When several checks fail, the object contains a "subproblems" array whose elements have "type", "detail", and, where applicable, "pointer" (a JSON Pointer [RFC6901] into the envelope core), as in Section 6.7.1 of [RFC8555]. "detail" is text for people; a problem details object MAY contain "lang" (Section 16).¶

A "channelRequired" problem includes a "channel" member naming the channel, for example "peppol", or a channel type registered for a tax authority platform or another network. Because node responses are signed, an intermediary cannot inject it.¶

8.8. Status Messages over HTTP

Status messages (Section 9) are sent with a POST request to the "status" endpoint, expanded with the envelope id, with the same authentication and idempotency rules as delivery. Messages signed by the issuer, by a bridge used by the issuer, or, when "issuer_role" is "seller", by the payee ([I-D.martinez-itp-lifecycle]) go to the node that returned the "delivered" status. All other messages go to the issuer's node, found through "issuer_node"; a node MUST NOT send them there unless that URL is listed in "senders" of the issuer's accepted Participant Document. A node MUST forward to the counterparty's node every status message for the envelope that it holds and that the counterparty has not received, including those signed by nodes, bridges, or third parties. A party that is not a participant in the envelope, such as an assignee, sends its messages through the seller's node, which relays them. Each node stores every status message whose signature is valid and returns all of them on a GET request to the "envelope" endpoint, so that both sides hold the same set. Clients MAY send Accept-Language; nodes SHOULD take it into account for text they generate and set Content-Language.¶

8.9. Caching

Participant Documents and Node Documents are cacheable; servers SHOULD send Cache-Control with a "max-age" of at most 86400 seconds. Responses that contain envelopes or status messages are private and SHOULD carry "Cache-Control: no-store".¶

8.10. Versioning and Extensibility

The "itp" member of the envelope core carries the major version, and the "versions" member of a Node Document lists the versions a node accepts; a receiving node rejects an envelope whose "itp" value is not listed with "unsupportedVersion". Receivers MUST ignore unknown members in ITP objects, except those listed in "crit", and unknown fields in the DNS record. Each member whose values come from a registry says what a receiver does with an unknown value; for registries where this document says nothing, an unknown value is reported to the user and otherwise ignored. A change that existing receivers cannot safely ignore requires either a "crit" entry or a new major version.¶

10.1. Signed Statements

An issuing node SHOULD register each envelope it signs; without a Receipt or a timestamp stamp an envelope has no trusted signing time (Section 6.4). After signing an envelope, the issuing node computes the commitment¶

C = HMAC-SHA256(transparency_salt, envelope digest octets)

where the HMAC key is the 32 octets obtained by decoding "transparency_salt", and registers C in a transparency service [RFC9943] in one of two ways:¶

Per envelope:

A Signed Statement, which is a COSE_Sign1 message [RFC9052], signed with the key that produced the "issuer" or "delegated-issuer" envelope signature. The COSE algorithm corresponds to the "alg" of the key: -19 ("Ed25519") and -9 ("ESP256") as registered by [RFC9864], and -37 ("PS256") as registered by [RFC8230]. Its protected header contains the "kid" (the UTF-8 octets of the key's JWK "kid" value), the content type "application/itp-commitment", and the CWT Claims header parameter [RFC9597] with "iss" set to "urn:ietf:params:oauth:jwk-thumbprint:sha-256:" followed by the key's thumbprint [RFC9278], and "sub" set to the base64url encoding of C. The payload is C.¶

In batches:

The node collects the commitments it creates during an interval of at most 3600 seconds, builds a Merkle tree over them as defined in Section 2.1 of [RFC9162] with the commitments as leaf inputs in creation order, and registers one Signed Statement whose payload is the tree head, with content type "application/itp-batch-head", signed with a key listed in "kids" of the issuer's "senders" entry for the node, with "iss" set to the Node Document URL and "sub" set to the base64url encoding of the tree head. Each envelope receives the inclusion proof of its commitment (Section 2.1.3 of [RFC9162]).¶

Batched registration is RECOMMENDED because it does not reveal to the transparency service, or to readers of the log, how many envelopes each issuer key produces (Section 15).¶

The node registers the Signed Statement, for example with [I-D.ietf-scitt-scrapi], and adds to "itp_evidence.receipts" an object with: "statement", the base64url encoding of the Signed Statement; "receipt", the base64url encoding of the Receipt [RFC9942]; and, in batch mode, "batch", an object with "tree_size", "leaf_index", and "path" (the inclusion proof as an array of base64url values). The Signed Statement together with its Receipt is a Transparent Statement in the sense of [RFC9943].¶

The Registration Policy of a transparency service used for ITP MUST verify that the Signed Statement is signed with a key accepted under Section 6 for the role concerned (participant, node, or attestation issuer). The submitter provides the Participant Document, Node Document, or trust list entry that lists the key; the transparency service uses it only for this check and does not register it. The transparency service MUST use the RFC9162_SHA256 verifiable data structure of [RFC9942], and MUST include the registration time as the "iat" claim of a CWT Claims header parameter [RFC9597] in the protected header of each Receipt; that is the "registration time" used in this document. An attestation for which no Receipt is available is treated as registered when the relying party first sees it.¶

10.2. Participant Documents and Attestations

Participant Documents and attestations are registered in the same way, with two differences. The commitment is the SHA-256 hash, without a salt, of the JWS Compact Serialization of the Participant Document payload and the signature whose "kid" sorts first in lexicographic order, or of the issuer-signed JWT of the attestation. The CWT "sub" claim is the "PID digest": the base64url encoding of the SHA-256 hash of the US-ASCII octets of the normalized PID in URN form, so that a participant or its monitor (Section 6.5) can find every registration about a PID without learning other PIDs. For a participant that is a natural person, the PID digest is instead an HMAC-SHA256 of the PID in URN form with a secret that the participant gives to the attestation issuer and to its monitor, so that the log does not let others test guesses of the identifier.¶

10.3. Receipts and Their Verification

A verifier checks a Receipt with the key of a transparency service that is listed with the role "transparency-service" in an accepted trust list. Receipts alone do not prevent a transparency service from showing different logs to different parties. Transparency services SHOULD therefore publish checkpoints of the same tree that their Receipts refer to, cosigned by independent witnesses, for example with [C2SP-CHECKPOINT] and [C2SP-WITNESS], and verifiers that can check such checkpoints SHOULD keep the latest one they have seen for each log and check consistency against it.¶

10.4. What Transparency Provides

Registration shows that an envelope existed no later than the registration time, and lets participants or their monitors detect keys, attestations, or envelopes signed with a stolen key while they watch the log. Registration does not detect duplicates or check invoice content, and a missing registration is not evidence of forgery. Duplicates are detected by recipients and by the registration systems of tax authorities.¶

Verifiers compare the registration time with "issue_date" and "invoice_period". A gap larger than the issuance deadline of the applicable jurisdiction is reported as a risk signal. Envelopes with "issuance_mode" "offline" or "contingency", and envelopes from fiscal devices that synchronize later, are registered when connectivity returns; for them verifiers compare the earliest trusted time in their stamps with the regularization period that the profile gives. Issuance deadlines differ between jurisdictions and kinds of transaction, for example the ten days that [VIDA] sets for certain intra-EU transactions from July 2030; profiles say which deadlines apply.¶

14.1. Threat Model

The attacker can read, modify, and inject network traffic; control a supplier's or a buyer's email account; register look-alike domains and shell companies; run a malicious directory or control an authoritative DNS server; compromise a participant's key, an operator, or an employee of an attestation issuer; and place text in invoice content that software processing it may act on. ITP aims to let a recipient detect forged or altered invoices and changed payment details, and to let participants detect keys and attestations issued without their consent. It does not protect against a participant that issues false invoices with its own valid key, including unsolicited invoices to parties it has never dealt with, against a buyer that gives another party's tax identifier, or against compromise of the recipient's own systems (Section 14.4).¶

14.2. Impersonation and Trust

Signatures identify a legal entity only through the trust model of Section 6, and their assurance is limited by that of the attestation issuers in the trust lists that a relying party accepts. A relying party that accepts an inadequately vetted trust list, or obtains one over an unauthenticated channel, accepts any key its issuers attest. Trust lists are signed and expire, and relying parties are expected to obtain the signing keys of the lists they use out of band, as they do for other trust anchors. Restricting each issuer to its jurisdictions limits the damage a single issuer can do.¶

Envelopes from look-alike domains, re-registered expired domains, and shell companies with genuine registrations verify. The damage is limited because "domain-control" attestations cover the legal entity and the key and expire after 90 days; a document accepted under rule 2 cannot replace one accepted under rules 1 or 3; recently bound keys are flagged for 72 hours; and verification does not authorize payment. Recipients still need to match the issuer's PID against their own supplier records.¶

A compromised or dishonest attestation issuer can bind an attacker's key to a victim's PID. The "issuers" field of the DNS record limits which honest issuers will do so, although without DNSSEC an attacker can strip it from the responses an issuer sees. Registration of attestations under the PID digest lets the victim's monitor detect a mis-issued attestation, and the 72-hour rules in Section 6.2 give a participant that watches the logs, itself or through a monitor, time to react before payment details change. A participant that does not watch them learns of a mis-issued attestation only from its counterparties.¶

14.3. Discovery and Downgrade

Without DNSSEC, an attacker that controls DNS responses can remove the "_itp" record or serve a different well-known resource. That alone does not let it impersonate a participant, because acceptance requires the rules of Section 6.2, and rule 2 requires DNSSEC. It can, however, make a participant look absent and push a sender to another channel. Pinning is carried in the signed Participant Document, not in DNS or in the unsigned well-known resource, so an attacker who controls only those cannot set or extend it. Clients that have accepted a participant's document keep it for "pin_max_age", and payment details that arrive through other channels during that time are not used automatically. As with MTA-STS (Section 10.2 of [RFC8461]), pinning does not protect the first contact.¶

14.4. First Contact

A typical first contact starts when a buyer gives a seller its tax identifier, for example at checkout. The seller's node normalizes the identifier to a PID (Section 4) and SHOULD check its format and check digit and, where the tax authority offers a validation service, that it is registered. It obtains a Participant Document for the PID from a directory that it is configured to use or that a profile designates, or from the "_itp" record and well-known resource of a domain that the buyer gave, and accepts it only under Section 6.2. For a buyer without a domain this means rule 1 or rule 3, which do not depend on DNS. If no document is accepted, the seller uses another channel. The seller's node verifies the Node Document of the "itp" inbound entry with a key listed in "kids" of that entry and delivers (Section 8.3). The receiving node obtains the seller's Participant Document from "issuer_participant_document" or from a directory, accepts it under the same rules, and checks that the sending node is listed in "senders".¶

A party that controls DNS, a directory, or the network cannot direct the envelope to a node of its choosing, or have its own envelope accepted in the name of a participant, unless an attestation issuer or certification authority that the relying party accepts binds its key to that participant's PID. It can make a participant look absent, so that the seller uses another channel, and it can serve an older document that is still validly signed; attestations that cover compromised keys are revoked (Section 6.3), so such a document is then no longer accepted.¶

At first contact ITP does not protect against the following. It does not check that the buyer that gave the tax identifier is entitled to use it: the envelope is delivered to the holder of the PID, so a wrong or misused identifier discloses the invoice to a third party and gives that party an invoice it did not order. Pinning does not apply, because no document has been accepted before. A key that an attestation issuer binds to a PID by mistake or fraud is flagged as recently bound for 72 hours (Section 6.2) and is then accepted like any other key, so this rule protects only participants that watch transparency services, themselves or through a monitor (Section 6.5). Any legal entity with an accepted attestation, including a shell company, can deliver envelopes to a participant whose PID it knows; there is no step in which the recipient consents to a new sender. Such envelopes verify, are reported as coming from a new issuer, and do not authorize payment (Section 11). Recipients match them against their own orders and supplier records, and payment details in them are handled as described in [I-D.martinez-itp-lifecycle].¶

14.5. Tampering, Type Confusion, and Algorithm Confusion

The envelope core, including the document digest, the list of signature algorithms, and payment details, is covered by the issuer signature. Every signed object defined by ITP has a distinct "typ", and verifiers check it, so a signature made for one kind of object cannot be presented as another [RFC8725]. "itp_role" is listed in "crit", so a generic JOSE library cannot silently ignore it. Each key carries "alg", and verifiers do not take the algorithm from the message. Keys embedded in headers are used only when they match an accepted "kid". Extra signatures that fail are ignored, so they cannot be used to invalidate a valid envelope, and "sig_algs" makes the removal of a signature detectable.¶

14.6. Parser Differentials and Canonicalization

Two JSON parsers can read the same text differently, for example when member names are duplicated, and this can make a signer and a verifier see different values. ITP requires I-JSON and requires rejection of duplicate names and unpaired surrogates before any other processing. Verification is done over the octets received, so differences between JCS implementations affect only the signer's ability to reproduce its own payload. Non-integer numbers are excluded because their serialization is where JCS libraries differ most. Documents are carried as octets. XML documents bring their own risks, such as external entities and signature wrapping when XAdES is used; parsers are configured as required in Section 7.2, and signatures inside documents are verified with the rules of their own format.¶

14.7. Delegated Keys and Misbehaving Operators

An operator that holds delegated signing keys can sign envelopes for its participants. It cannot change the participant's keys, senders, archive node, or pin, because Participant Documents are signed only with keys the participant holds. New keys need the old key or a logged attestation, revocation is monotonic, and participants or their monitors can watch transparency services. Participants that need stronger guarantees keep their own keys, for example in qualified signature creation devices.¶

14.8. Status Forgery and Divergent State

Statuses can have legal and tax consequences, and several jurisdictions report them to the tax administration. Without further rules, a receiving operator, or an attacker that compromises it, could sign them in a participant's name. Section 9 therefore requires the signature of the party named in "by", and nodes can sign only "delivered" and "technical-rejected". Both nodes keep and exchange the complete set of messages, and [I-D.martinez-itp-lifecycle] derives the state from that set, so that the two sides cannot end up with different states because messages arrived in a different order.¶

14.9. Evidence Stripping and Substitution

"itp_evidence" is not signed by the issuer. An intermediary can remove a stamp or a Receipt, or add a rendition. "required_evidence" lets verifiers notice removal, renditions are accepted only from bridges accepted for the scheme, and conflicting renditions are reported to the user (see Section 7.3).¶

14.10. Replay and Duplicates

Requests carry server-issued nonces and short validity periods. Envelopes and status messages carry identifiers, status messages are chained with "seq" and "prev", and receiving nodes detect duplicate envelopes by digest, also when they arrive from two authorized nodes or after the idempotency window (Section 8.4).¶

14.11. Copies for the Issuer

Copies go only to the node named in "archive" of the issuer's accepted Participant Document, which only a non-delegated key of the participant can change (Section 5.5). Content of an envelope, a directory, or DNS cannot direct copies to another node. The "copies" endpoint is covered by the HTTP Message Signature, so an intermediary cannot turn a delivery into a copy, which would leave the recipient without the envelope, or a copy into a delivery. The archive node signs no status message about a copy and sends nothing to other nodes, so a copy is never counted as delivery, and the counterparty receives nothing from the archive node and is not told that a copy exists. A participant that names an archive node run by another operator gives that operator the content of every document issued in its name; the "storage" member of that node's Node Document (Section 5.6) says where it keeps them.¶

14.12. Key Compromise and Back-Dating

An attacker with a stolen key can sign envelopes with any stated date. Validity is therefore judged against registration time in a transparency service or a trusted timestamp, and revocation records the time of compromise. Envelopes signed with a compromised key and lacking earlier trusted time evidence are rejected. Some risk remains for the interval between compromise and its detection.¶

14.13. Log Equivocation

A transparency service could show different logs to different parties. Witness cosigning and checked consistency proofs address this, as long as the witnesses do not collude with the log. Verifiers that only check Receipts depend on the honesty of the transparency service.¶

14.14. Server-Side Request Forgery

ITP objects contain URLs that a node retrieves. The rules in Section 8 restrict them to HTTPS, to the expected origins for documents, and to public addresses checked at connection time, which also covers DNS rebinding.¶

14.15. Untrusted Content

Line descriptions, reason texts, and attachments are written by the counterparty. Software that acts on invoices, including software agents, needs to keep such text apart from its own instructions; [I-D.martinez-itp-agent-mandates] discusses this for agents.¶

A document can carry an image for people besides its structured data, as in hybrid PDF and XML formats, and attachments can include a PDF of the invoice. The two can differ, for example in the payment account shown; in Germany, for example, the structured part prevails. Software that shows invoices to people is expected to show a rendering generated from the structured data of the verified document, or to mark an embedded image as not checked against it.¶

14.16. Denial of Service

Nodes check size, nesting depth, and the number of signatures before canonicalization or cryptographic operations, verify the HTTP Message Signature before any signature check on the envelope (Section 8.3), limit the retrievals caused by one request, and rate-limit by sending node. Envelopes whose issuer has no accepted Participant Document are refused with "untrustedIssuer" (Section 11). Where the law that applies to the recipient allows it to refuse invoices delivered through ITP, a receiving node MAY also refuse, with the same error, envelopes from issuers that do not meet a policy set by the recipient, for example issuers it has not listed or that hold no attestation of a given type.¶

14.17. Algorithm Lifetime

Invoices and accounting records are retained for periods that can outlast the security of current signature algorithms if a large quantum computer is built. ITP allows additional signatures with other algorithms on the same envelope, and "sig_algs" prevents those signatures from being stripped. Evidence records can renew protection of archived envelopes. A later revision is expected to say when envelopes with only classical signatures stop being accepted for new issuance.¶

17.1. Well-Known URI

IANA is requested to register the following in the "Well-Known URIs" registry [RFC8615]:¶

URI Suffix:

itp¶

Change Controller:

IETF¶

Specification Document(s):

Section 5.4 of this document¶

Status:

permanent¶

Related Information:

None¶

17.2. Underscored DNS Node Name

IANA is requested to add the following to the "Underscored and Globally Scoped DNS Node Names" registry [RFC8552]:¶

17.3. Media Types

IANA is requested to register the following media types in the "Media Types" registry, following [RFC6838]:¶

The values with the "+jws" or "+sd-jwt" suffix, without the "application/" prefix, are the "typ" values of the corresponding objects. The registration template is the same for all of them, except where noted:¶

Type name:

application¶

Required parameters:

N/A¶

Optional parameters:

N/A¶

Encoding considerations:

binary. The "+jws" types use the JWS JSON Serialization, which is UTF-8 JSON; "itp-attestation+sd-jwt" uses the SD-JWT serialization; "itp-metadata+json" is UTF-8 JSON; "itp-commitment" and "itp-batch-head" are 32 octets.¶

Security considerations:

The "+jws" and "+sd-jwt" types carry signed JSON. They contain no active content. Integrity and origin come from the signatures, which are checked as described in Section 6 and Section 11 of this document; the content is otherwise untrusted. Envelopes and status messages can contain commercially sensitive and personal data and are not to be cached by shared caches. "itp-metadata+json" is unsigned and carries no trust on its own. "itp-commitment" reveals nothing about the envelope without its salt. See the Security and Privacy Considerations sections of this document.¶

Interoperability considerations:

N/A¶

Published specification:

This document¶

Applications that use this media type:

Implementations of the Invoice Trust Protocol¶

Fragment identifier considerations:

For "itp-metadata+json", as for "application/json"; N/A for the other types.¶

Additional information:

Deprecated alias names: N/A; Magic number(s): N/A; File extension(s): N/A; Macintosh file type code(s): N/A¶

Person and email address to contact for further information:

IETF (iesg@ietf.org)¶

Intended usage:

COMMON¶

Restrictions on usage:

N/A¶

Author:

Carlos Martinez Garcia-Villarrubia¶

Change controller:

IETF¶

17.4. JSON Web Signature and Encryption Header Parameters

IANA is requested to register the following in the "JSON Web Signature and Encryption Header Parameters" registry [RFC7515]:¶

Header Parameter Name:

itp_role¶

Header Parameter Description:

Role of the signer of an Invoice Trust Protocol object¶

Header Parameter Usage Location(s):

JWS¶

Change Controller:

IETF¶

Specification Document(s):

Section 7.4 of this document¶

17.5. URN Sub-namespace

IANA is requested to register the following in the "IETF URN Sub-namespace for Registered Protocol Parameter Identifiers" registry [RFC3553]:¶

Registry name:

itp¶

Specification:

This document¶

Repository:

The ITP URN Values registry (Section 17.7). The values "error" and "pid" are reserved there: URNs under "urn:ietf:params:itp:error:" are assigned by the ITP Error Types registry (Section 17.6), and URNs under "urn:ietf:params:itp:pid:" are formed from PIDs as described in Section 4.¶

Index value:

Values are assigned by the registries above.¶

17.6. ITP Error Types

IANA is requested to create the "ITP Error Types" registry within a new "Invoice Trust Protocol (ITP)" registry group. Registrations follow the "Specification Required" policy [RFC8126]. Each entry contains the type name (the last component of "urn:ietf:params:itp:error:"), the HTTP status code, a description, and a reference. The initial contents are the rows of the table in Section 8.7, with this document as the reference.¶

17.7. Other ITP Registries

IANA is requested to create the following registries in the "Invoice Trust Protocol (ITP)" registry group, each with the "Specification Required" policy:¶

The initial contents of the ITP Document Types registry are given in Table 5, with this document as the reference.¶

Instructions to the designated experts:¶

• A new value must not duplicate an existing one, and its meaning must be defined precisely in a publicly available specification.¶

• A PID scheme or tax identifier type must name the authority that issues the identifiers, give a normalization rule that makes comparison unambiguous, and point to a public description of the format and check digits. Types whose identifiers are commonly derived from national identity numbers need a note on privacy.¶

• A bridge scheme must name the jurisdiction or network, the authority or organization that runs it, and the public specification of its interface.¶

• A status must say who emits it, whether it is final, and how it maps to the statuses of existing networks where such a mapping exists.¶

• A signer role or attestation type affects security. Its specification must say what it may and may not substitute for and what a relying party checks before accepting it, and must have Security Considerations. Experts are encouraged to seek review on the mailing list where this document is discussed.¶

• Experts are encouraged to consult the organizations responsible for the network or jurisdiction concerned, such as OpenPeppol for Peppol identifiers, the operators of other networks for their identifiers, and the tax administration for national codes.¶

• Identifier formats change. Experts can approve updates to an existing PID scheme or tax identifier type, such as a new format or prefix, and keep the earlier rules in the entry while identifiers issued under them can still appear in retained envelopes.¶

18.1. Normative References

[I-D.ietf-httpapi-idempotency-key-header]

Jena, J., Dalal, S., and D. Tishkin, "The Idempotency-Key HTTP Header Field", Work in Progress, Internet-Draft, draft-ietf-httpapi-idempotency-key-header-08, 22 October 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-httpapi-idempotency-key-header-08>.

[I-D.ietf-oauth-status-list]

Looker, T., Bastian, P., and C. Bormann, "Token Status List (TSL)", Work in Progress, Internet-Draft, draft-ietf-oauth-status-list-21, 21 June 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-status-list-21>.

[ISO3166]

ISO, "Codes for the representation of names of countries and their subdivisions - Part 1: Country code", ISO 3166-1:2020, 2020.

[ISO3166-2]

ISO, "Codes for the representation of names of countries and their subdivisions - Part 2: Country subdivision code", ISO 3166-2:2020, 2020.

[ISO4217]

ISO, "Codes for the representation of currencies", ISO 4217:2015, 2015.

[ISO17442]

ISO, "Financial services - Legal entity identifier (LEI) - Part 1: Assignment", ISO 17442-1:2020, 2020.

[OPENID-FED]

Hedberg, R., Jones, M.B., Solberg, A.Å., Bradley, J., De Marco, G., and V. Dzhuvinov, "OpenID Federation 1.0", 17 February 2026, <https://openid.net/specs/openid-federation-1_0-final.html>.

[PEPPOL-EAS]

OpenPeppol AISBL, "Peppol Code Lists - Participant identifier schemes, version 9.7", 2 July 2026, <https://docs.peppol.eu/edelivery/codelists/>.

[PEPPOL-IDS]

OpenPeppol AISBL, "Peppol Policy for use of Identifiers, version 4.4.0", 6 February 2025, <https://docs.peppol.eu/edelivery/policies/Peppol-EDN-Policy-for-use-of-identifiers-4.4.0-2025-02-06.pdf>.

[RFC2104]

Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, <https://www.rfc-editor.org/rfc/rfc2104>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC3161]

Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", RFC 3161, DOI 10.17487/RFC3161, August 2001, <https://www.rfc-editor.org/rfc/rfc3161>.

[RFC3339]

Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/rfc/rfc3339>.

[RFC3553]

Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June 2003, <https://www.rfc-editor.org/rfc/rfc3553>.

[RFC3986]

Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/rfc/rfc3986>.

[RFC4033]

Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <https://www.rfc-editor.org/rfc/rfc4033>.

[RFC5234]

Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/rfc/rfc5234>.

[RFC5280]

Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/rfc/rfc5280>.

[RFC5646]

Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, <https://www.rfc-editor.org/rfc/rfc5646>.

[RFC6234]

Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, <https://www.rfc-editor.org/rfc/rfc6234>.

[RFC6454]

Barth, A., "The Web Origin Concept", RFC 6454, DOI 10.17487/RFC6454, December 2011, <https://www.rfc-editor.org/rfc/rfc6454>.

[RFC6570]

Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, "URI Template", RFC 6570, DOI 10.17487/RFC6570, March 2012, <https://www.rfc-editor.org/rfc/rfc6570>.

[RFC6838]

Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <https://www.rfc-editor.org/rfc/rfc6838>.

[RFC6890]

Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, "Special-Purpose IP Address Registries", BCP 153, RFC 6890, DOI 10.17487/RFC6890, April 2013, <https://www.rfc-editor.org/rfc/rfc6890>.

[RFC6901]

Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed., "JavaScript Object Notation (JSON) Pointer", RFC 6901, DOI 10.17487/RFC6901, April 2013, <https://www.rfc-editor.org/rfc/rfc6901>.

[RFC7405]

Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC 7405, DOI 10.17487/RFC7405, December 2014, <https://www.rfc-editor.org/rfc/rfc7405>.

[RFC7493]

Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI 10.17487/RFC7493, March 2015, <https://www.rfc-editor.org/rfc/rfc7493>.

[RFC7515]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://www.rfc-editor.org/rfc/rfc7515>.

[RFC7517]

Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, <https://www.rfc-editor.org/rfc/rfc7517>.

[RFC7518]

Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, <https://www.rfc-editor.org/rfc/rfc7518>.

[RFC7519]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <https://www.rfc-editor.org/rfc/rfc7519>.

[RFC7638]

Jones, M. and N. Sakimura, "JSON Web Key (JWK) Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 2015, <https://www.rfc-editor.org/rfc/rfc7638>.

[RFC8032]

Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, <https://www.rfc-editor.org/rfc/rfc8032>.

[RFC8037]

Liusvaara, I., "CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE)", RFC 8037, DOI 10.17487/RFC8037, January 2017, <https://www.rfc-editor.org/rfc/rfc8037>.

[RFC8126]

Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/rfc/rfc8126>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8190]

Bonica, R., Cotton, M., Haberman, B., and L. Vegoda, "Updates to the Special-Purpose IP Address Registries", BCP 153, RFC 8190, DOI 10.17487/RFC8190, June 2017, <https://www.rfc-editor.org/rfc/rfc8190>.

[RFC8259]

Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/rfc/rfc8259>.

[RFC8264]

Saint-Andre, P. and M. Blanchet, "PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols", RFC 8264, DOI 10.17487/RFC8264, October 2017, <https://www.rfc-editor.org/rfc/rfc8264>.

[RFC8552]

Crocker, D., "Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves", BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019, <https://www.rfc-editor.org/rfc/rfc8552>.

[RFC8555]

Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Kasten, "Automatic Certificate Management Environment (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, <https://www.rfc-editor.org/rfc/rfc8555>.

[RFC8615]

Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, <https://www.rfc-editor.org/rfc/rfc8615>.

[RFC8725]

Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best Current Practices", BCP 225, RFC 8725, DOI 10.17487/RFC8725, February 2020, <https://www.rfc-editor.org/rfc/rfc8725>.

[RFC8785]

Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, <https://www.rfc-editor.org/rfc/rfc8785>.

[RFC9052]

Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, <https://www.rfc-editor.org/rfc/rfc9052>.

[RFC9110]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/rfc/rfc9110>.

[RFC9111]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Caching", STD 98, RFC 9111, DOI 10.17487/RFC9111, June 2022, <https://www.rfc-editor.org/rfc/rfc9111>.

[RFC9162]

Laurie, B., Messeri, E., and R. Stradling, "Certificate Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162, December 2021, <https://www.rfc-editor.org/rfc/rfc9162>.

[RFC9278]

Jones, M. and K. Yasuda, "JWK Thumbprint URI", RFC 9278, DOI 10.17487/RFC9278, August 2022, <https://www.rfc-editor.org/rfc/rfc9278>.

[RFC9325]

Sheffer, Y., Saint-Andre, P., and T. Fossati, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November 2022, <https://www.rfc-editor.org/rfc/rfc9325>.

[RFC9421]

Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP Message Signatures", RFC 9421, DOI 10.17487/RFC9421, February 2024, <https://www.rfc-editor.org/rfc/rfc9421>.

[RFC9457]

Nottingham, M., Wilde, E., and S. Dalal, "Problem Details for HTTP APIs", RFC 9457, DOI 10.17487/RFC9457, July 2023, <https://www.rfc-editor.org/rfc/rfc9457>.

[RFC9525]

Saint-Andre, P. and R. Salz, "Service Identity in TLS", RFC 9525, DOI 10.17487/RFC9525, November 2023, <https://www.rfc-editor.org/rfc/rfc9525>.

[RFC9530]

Polli, R. and L. Pardue, "Digest Fields", RFC 9530, DOI 10.17487/RFC9530, February 2024, <https://www.rfc-editor.org/rfc/rfc9530>.

[RFC9562]

Davis, K., Peabody, B., and P. Leach, "Universally Unique IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May 2024, <https://www.rfc-editor.org/rfc/rfc9562>.

[RFC9597]

Looker, T. and M.B. Jones, "CBOR Web Token (CWT) Claims in COSE Headers", RFC 9597, DOI 10.17487/RFC9597, June 2024, <https://www.rfc-editor.org/rfc/rfc9597>.

[RFC9846]

Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 9846, DOI 10.17487/RFC9846, July 2026, <https://www.rfc-editor.org/rfc/rfc9846>.

[RFC9864]

Jones, M.B. and O. Steele, "Fully-Specified Algorithms for JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE)", RFC 9864, DOI 10.17487/RFC9864, October 2025, <https://www.rfc-editor.org/rfc/rfc9864>.

[RFC9901]

Fett, D., Yasuda, K., and B. Campbell, "Selective Disclosure for JSON Web Tokens", RFC 9901, DOI 10.17487/RFC9901, November 2025, <https://www.rfc-editor.org/rfc/rfc9901>.

[RFC9942]

Steele, O., Birkholz, H., Delignat-Lavaud, A., and C. Fournet, "CBOR Object Signing and Encryption (COSE) Receipts", RFC 9942, DOI 10.17487/RFC9942, June 2026, <https://www.rfc-editor.org/rfc/rfc9942>.

[RFC9943]

Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains", RFC 9943, DOI 10.17487/RFC9943, June 2026, <https://www.rfc-editor.org/rfc/rfc9943>.

[UAX15]

The Unicode Consortium, "Unicode Normalization Forms", Unicode Standard Annex 15, n.d., <https://www.unicode.org/reports/tr15/>.

[UBL21]

OASIS, "Universal Business Language Version 2.1", 4 November 2013, <https://docs.oasis-open.org/ubl/os-UBL-2.1/UBL-2.1.html>.

[UNTDID1001]

UN/CEFACT, "UN/EDIFACT code list 1001: Document name code, directory D.16B", 2016.

18.2. Informative References

[BDX-AS4]

OASIS, "AS4 Interoperability Profile for Four-Corner Networks Version 1.0", OASIS Committee Specification 01, 12 November 2021, <https://docs.oasis-open.org/bdxr/bdx-as4/v1.0/bdx-as4-v1.0.html>.

[BDXL]

OASIS, "Business Document Metadata Service Location Version 1.0", 1 August 2017, <https://docs.oasis-open.org/bdxr/BDX-Location/v1.0/BDX-Location-v1.0.html>.

[C2SP-CHECKPOINT]

C2SP, "tlog-checkpoint: Transparency Log Checkpoints, version 1.1.0", n.d., <https://c2sp.org/tlog-checkpoint@v1.1.0>.

[C2SP-WITNESS]

C2SP, "tlog-witness: Transparency Log Witness Protocol, version 1.1.0", n.d., <https://c2sp.org/tlog-witness@v1.1.0>.

[CADES]

ETSI, "Electronic Signatures and Infrastructures (ESI); CAdES digital signatures; Part 1: Building blocks and CAdES baseline signatures", ETSI EN 319 122-1, n.d..

[CII]

UN/CEFACT, "Cross Industry Invoice, D16B", 2016.

[DBNA]

Digital Business Networks Alliance, "Digital Business Networks Alliance Exchange Framework", n.d., <https://dbnalliance.org/>.

[EDIFACT]

ISO, "Electronic data interchange for administration, commerce and transport (EDIFACT) - Application level syntax rules", ISO 9735, n.d..

[EDPB-BC]

European Data Protection Board, "Guidelines 02/2025 on processing of personal data through blockchain technologies, version 2.0", 7 July 2026, <https://www.edpb.europa.eu/system/files/2026-07/edpb_guidelines_202502_blockchain_v2_en.pdf>.

[EIDAS2]

European Parliament and Council of the European Union, "Regulation (EU) 2024/1183 amending Regulation (EU) No 910/2014 as regards establishing the European Digital Identity Framework", 11 April 2024, <https://eur-lex.europa.eu/eli/reg/2024/1183/oj/eng>.

[EN16931]

European Committee for Standardization (CEN), "Electronic invoicing - Part 1: Semantic data model of the core elements of an electronic invoice", EN 16931-1:2026, 2026.

[ETSI-ERDS]

ETSI, "Electronic Signatures and Infrastructures (ESI); Electronic Registered Delivery Services; Part 1: Framework and Architecture", ETSI EN 319 522-1 V1.2.1, January 2024.

[ETSI-PRES]

ETSI, "Electronic Signatures and Trust Infrastructures (ESI); Policy and security requirements for trust service providers providing long-term preservation of digital signatures or general data using digital signature techniques", ETSI TS 119 511 V1.2.1, October 2025.

[ETSI-REM]

ETSI, "Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail (REM) Services; Part 1: Framework and architecture", ETSI EN 319 532-1 V1.1.1, September 2018.

[ETSI-TL]

ETSI, "Electronic Signatures and Infrastructures (ESI); Trusted Lists", ETSI TS 119 612, n.d..

[ETSI-VAL]

ETSI, "Electronic Signatures and Trust Infrastructures (ESI); Procedures for Creation and Validation of AdES Digital Signatures; Part 1: Creation and Validation", ETSI EN 319 102-1 V1.4.1, June 2024.

[EU-BW]

European Commission, "Proposal for a Regulation on the establishment of European Business Wallets, COM(2025) 838 final, 2025/0358(COD)", November 2025, <https://data.consilium.europa.eu/doc/document/ST-15701-2025-INIT/en/pdf>.

[EU-VAT-DIR]

Council of the European Union, "Council Directive 2006/112/EC of 28 November 2006 on the common system of value added tax", 28 November 2006, <https://eur-lex.europa.eu/eli/dir/2006/112/oj/eng>.

[FIDES-DEI]

Crooijmans, R. and H. van der Kooij, "FIDES Innovation Track: Direct e-invoicing - Phase 3: Key findings, recommendations & proposed next steps", March 2026, <https://fides.community/app/uploads/2026/04/FIDES-Direct_eInvoicing_v1.0.pdf>.

[GDPR]

European Parliament and Council of the European Union, "Regulation (EU) 2016/679 (General Data Protection Regulation)", 27 April 2016, <https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng>.

[GOBL]

Invopop SL, "GOBL: Go Business Language", n.d., <https://github.com/invopop/gobl>.

[I-D.ietf-dnsop-domain-verification-techniques]

Sahib, S. K., Huque, S., Wouters, P., Nygren, E., and T. Wicinski, "Domain Control Validation using DNS", Work in Progress, Internet-Draft, draft-ietf-dnsop-domain-verification-techniques-13, 21 June 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-domain-verification-techniques-13>.

[I-D.ietf-keytrans-architecture]

McMillion, B., "Key Transparency Architecture", Work in Progress, Internet-Draft, draft-ietf-keytrans-architecture-10, 7 October 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-keytrans-architecture-10>.

[I-D.ietf-opsawg-rfc5706bis]

Claise, B., Clarke, J., Farrel, A., Barguil, S., Pignataro, C., and R. Chen, "Guidelines for Considering Operations and Management in IETF Specifications", Work in Progress, Internet-Draft, draft-ietf-opsawg-rfc5706bis-09, 6 October 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-rfc5706bis-09>.

[I-D.ietf-scitt-scrapi]

Birkholz, H., Geater, J., and A. Delignat-Lavaud, "Supply Chain Integrity, Transparency, and Trust (SCITT) Reference APIs", Work in Progress, Internet-Draft, draft-ietf-scitt-scrapi-11, 26 June 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-scitt-scrapi-11>.

[I-D.ietf-webbotauth-httpsig-protocol]

Meunier, T. and S. Major, "HTTP Message Signatures for automated traffic", Work in Progress, Internet-Draft, draft-ietf-webbotauth-httpsig-protocol-00, 1 September 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-webbotauth-httpsig-protocol-00>.

[I-D.jaakola-simple-invoicing-protocol]

Jaakola, J., "The Simple Invoicing Protocol", Work in Progress, Internet-Draft, draft-jaakola-simple-invoicing-protocol-00, 11 November 2009, <https://datatracker.ietf.org/doc/html/draft-jaakola-simple-invoicing-protocol-00>.

[I-D.martinez-itp-agent-mandates]

Martínez García-Villarrubia, C., "Invoice Trust Protocol (ITP): Agent Mandates", Work in Progress, Internet-Draft, draft-martinez-itp-agent-mandates-00, October 2026, <https://datatracker.ietf.org/doc/html/draft-martinez-itp-agent-mandates-00>.

[I-D.martinez-itp-lifecycle]

Martínez García-Villarrubia, C., "Invoice Trust Protocol (ITP): Lifecycle Status and Payment Information", Work in Progress, Internet-Draft, draft-martinez-itp-lifecycle-00, October 2026, <https://datatracker.ietf.org/doc/html/draft-martinez-itp-lifecycle-00>.

[IANA-SPECIAL]

IANA, "IANA IPv4 and IPv6 Special-Purpose Address Registries", n.d., <https://www.iana.org/assignments/iana-ipv4-special-registry/>.

[IC3-2024]

Federal Bureau of Investigation, Internet Crime Complaint Center, "Internet Crime Report 2024", 2025, <https://www.ic3.gov/AnnualReport/Reports/2024_IC3Report.pdf>.

[ISO17442-3]

ISO, "Financial services - Legal entity identifier (LEI) - Part 3: Verifiable LEIs (vLEIs)", ISO 17442-3:2024, 2024.

[JADES]

ETSI, "Electronic Signatures and Trust Infrastructures (ESI); JAdES digital signatures; Part 1: Building blocks and JAdES baseline signatures", ETSI TS 119 182-1 V1.2.1, 2024.

[OECD-TA3]

OECD, "Tax Administration 3.0 and Electronic Invoicing: Initial Findings", 2022, <https://www.oecd.org/en/publications/tax-administration-3-0-and-electronic-invoicing_2ffc88ed-en.html>.

[PEPPOL-AS4]

OpenPeppol AISBL, "Peppol AS4 Profile, version 2.0.3", 22 April 2024, <https://docs.peppol.eu/edelivery/as4/specification/>.

[PEPPOL-BIS]

OpenPeppol AISBL, "Peppol BIS Billing 3.0", n.d., <https://docs.peppol.eu/poacc/billing/3.0/>.

[PEPPOL-PINT]

OpenPeppol AISBL, "Peppol Specifications for PINT", n.d., <https://docs.peppol.eu/poac/pint/>.

[PEPPOL-SMP]

OpenPeppol AISBL, "Peppol Service Metadata Publishing (SMP), version 1.4.0", 6 February 2025, <https://docs.peppol.eu/edelivery/smp/Peppol-EDN-Service-Metadata-Publishing-1.4.0-2025-02-06.pdf>.

[RFC1767]

Crocker, D., "MIME Encapsulation of EDI Objects", RFC 1767, DOI 10.17487/RFC1767, March 1995, <https://www.rfc-editor.org/rfc/rfc1767>.

[RFC2277]

Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, DOI 10.17487/RFC2277, January 1998, <https://www.rfc-editor.org/rfc/rfc2277>.

[RFC2606]

Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999, <https://www.rfc-editor.org/rfc/rfc2606>.

[RFC3335]

Harding, T., Drummond, R., and C. Shih, "MIME-based Secure Peer-to-Peer Business Data Interchange over the Internet", RFC 3335, DOI 10.17487/RFC3335, September 2002, <https://www.rfc-editor.org/rfc/rfc3335>.

[RFC4130]

Moberg, D. and R. Drummond, "MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2)", RFC 4130, DOI 10.17487/RFC4130, July 2005, <https://www.rfc-editor.org/rfc/rfc4130>.

[RFC4823]

Harding, T. and R. Scott, "FTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet", RFC 4823, DOI 10.17487/RFC4823, April 2007, <https://www.rfc-editor.org/rfc/rfc4823>.

[RFC4848]

Daigle, L., "Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS)", RFC 4848, DOI 10.17487/RFC4848, April 2007, <https://www.rfc-editor.org/rfc/rfc4848>.

[RFC4998]

Gondrom, T., Brandner, R., and U. Pordesch, "Evidence Record Syntax (ERS)", RFC 4998, DOI 10.17487/RFC4998, August 2007, <https://www.rfc-editor.org/rfc/rfc4998>.

[RFC5507]

IAB, Faltstrom, P., Ed., Austein, R., Ed., and P. Koch, Ed., "Design Choices When Expanding the DNS", RFC 5507, DOI 10.17487/RFC5507, April 2009, <https://www.rfc-editor.org/rfc/rfc5507>.

[RFC6365]

Hoffman, P. and J. Klensin, "Terminology Used in Internationalization in the IETF", BCP 166, RFC 6365, DOI 10.17487/RFC6365, September 2011, <https://www.rfc-editor.org/rfc/rfc6365>.

[RFC6376]

Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, DOI 10.17487/RFC6376, September 2011, <https://www.rfc-editor.org/rfc/rfc6376>.

[RFC6557]

Lear, E. and P. Eggert, "Procedures for Maintaining the Time Zone Database", BCP 175, RFC 6557, DOI 10.17487/RFC6557, February 2012, <https://www.rfc-editor.org/rfc/rfc6557>.

[RFC6749]

Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <https://www.rfc-editor.org/rfc/rfc6749>.

[RFC6973]

Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/rfc/rfc6973>.

[RFC7091]

Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.10-2012: Digital Signature Algorithm", RFC 7091, DOI 10.17487/RFC7091, December 2013, <https://www.rfc-editor.org/rfc/rfc7091>.

[RFC7516]

Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015, <https://www.rfc-editor.org/rfc/rfc7516>.

[RFC7858]

Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, <https://www.rfc-editor.org/rfc/rfc7858>.

[RFC7942]

Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, <https://www.rfc-editor.org/rfc/rfc7942>.

[RFC8162]

Hoffman, P. and J. Schlyter, "Using Secure DNS to Associate Certificates with Domain Names for S/MIME", RFC 8162, DOI 10.17487/RFC8162, May 2017, <https://www.rfc-editor.org/rfc/rfc8162>.

[RFC8230]

Jones, M., "Using RSA Algorithms with CBOR Object Signing and Encryption (COSE) Messages", RFC 8230, DOI 10.17487/RFC8230, September 2017, <https://www.rfc-editor.org/rfc/rfc8230>.

[RFC8461]

Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A., and J. Jones, "SMTP MTA Strict Transport Security (MTA-STS)", RFC 8461, DOI 10.17487/RFC8461, September 2018, <https://www.rfc-editor.org/rfc/rfc8461>.

[RFC8484]

Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, <https://www.rfc-editor.org/rfc/rfc8484>.

[RFC8551]

Schaad, J., Ramsdell, B., and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification", RFC 8551, DOI 10.17487/RFC8551, April 2019, <https://www.rfc-editor.org/rfc/rfc8551>.

[RFC8659]

Hallam-Baker, P., Stradling, R., and J. Hoffman-Andrews, "DNS Certification Authority Authorization (CAA) Resource Record", RFC 8659, DOI 10.17487/RFC8659, November 2019, <https://www.rfc-editor.org/rfc/rfc8659>.

[RFC8705]

Campbell, B., Bradley, J., Sakimura, N., and T. Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens", RFC 8705, DOI 10.17487/RFC8705, February 2020, <https://www.rfc-editor.org/rfc/rfc8705>.

[RFC8792]

Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, "Handling Long Lines in Content of Internet-Drafts and RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020, <https://www.rfc-editor.org/rfc/rfc8792>.

[RFC8820]

Nottingham, M., "URI Design and Ownership", BCP 190, RFC 8820, DOI 10.17487/RFC8820, June 2020, <https://www.rfc-editor.org/rfc/rfc8820>.

[RFC8998]

Yang, P., "ShangMi (SM) Cipher Suites for TLS 1.3", RFC 8998, DOI 10.17487/RFC8998, March 2021, <https://www.rfc-editor.org/rfc/rfc8998>.

[RFC9205]

Nottingham, M., "Building Protocols with HTTP", BCP 56, RFC 9205, DOI 10.17487/RFC9205, June 2022, <https://www.rfc-editor.org/rfc/rfc9205>.

[RFC9367]

Smyshlyaev, S., Ed., Alekseev, E., Griboedova, E., Babueva, A., and L. Nikiforova, "GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.3", RFC 9367, DOI 10.17487/RFC9367, February 2023, <https://www.rfc-editor.org/rfc/rfc9367>.

[RFC9449]

Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, September 2023, <https://www.rfc-editor.org/rfc/rfc9449>.

[RFC9458]

Thomson, M. and C. A. Wood, "Oblivious HTTP", RFC 9458, DOI 10.17487/RFC9458, January 2024, <https://www.rfc-editor.org/rfc/rfc9458>.

[RFC9460]

Schwartz, B., Bishop, M., and E. Nygren, "Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)", RFC 9460, DOI 10.17487/RFC9460, November 2023, <https://www.rfc-editor.org/rfc/rfc9460>.

[RFC9700]

Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett, "Best Current Practice for OAuth 2.0 Security", BCP 240, RFC 9700, DOI 10.17487/RFC9700, January 2025, <https://www.rfc-editor.org/rfc/rfc9700>.

[RFC9964]

Prorock, M. and O. Steele, "ML-DSA for JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE)", RFC 9964, DOI 10.17487/RFC9964, May 2026, <https://www.rfc-editor.org/rfc/rfc9964>.

[SMP2]

OASIS, "Service Metadata Publishing (SMP) Version 2.0", 14 February 2021, <https://docs.oasis-open.org/bdxr/bdx-smp/v2.0/bdx-smp-v2.0.html>.

[UAX9]

The Unicode Consortium, "Unicode Bidirectional Algorithm", Unicode Standard Annex 9, n.d., <https://www.unicode.org/reports/tr9/>.

[UBL]

OASIS, "Universal Business Language Version 2.5", 12 August 2026, <https://docs.oasis-open.org/ubl/UBL-2.5.html>.

[UNCITRAL-MLES]

United Nations Commission on International Trade Law, "UNCITRAL Model Law on Electronic Signatures", 2001, <https://uncitral.un.org/en/texts/ecommerce/modellaw/electronic_signatures>.

[UNCITRAL-MLETR]

United Nations Commission on International Trade Law, "UNCITRAL Model Law on Electronic Transferable Records", 2017, <https://uncitral.un.org/en/texts/ecommerce/modellaw/electronic_transferable_records>.

[UNCITRAL-MLIT]

United Nations Commission on International Trade Law, "UNCITRAL Model Law on the Use and Cross-border Recognition of Identity Management and Trust Services", 2022, <https://uncitral.un.org/en/mlit>.

[UNTP]

UN/CEFACT, "UN Transparency Protocol (UNTP)", 2026, <https://spec-untp-fbb45f.opensource.unicc.org/>.

[UNVTD]

UN/CEFACT, "UN Verifiable Trade Documents (UNVTD)", 2026, <https://spec-unvtd-790c10.opensource.unicc.org/>.

[VIDA]

Council of the European Union, "Council Directive (EU) 2025/516 of 11 March 2025 amending Directive 2006/112/EC as regards VAT rules for the digital age", 11 March 2025, <https://eur-lex.europa.eu/eli/dir/2025/516/oj/eng>.

[VIES]

European Commission, "VIES VAT number validation", n.d., <https://ec.europa.eu/taxation_customs/vies/>.

[VLEI]

Global Legal Entity Identifier Foundation, "verifiable Legal Entity Identifier (vLEI)", n.d., <https://www.gleif.org/en/organizational-identity/introducing-the-verifiable-lei-vlei>.

[W3C-VC]

W3C, "Verifiable Credentials Data Model v2.0", 15 May 2025, <https://www.w3.org/TR/vc-data-model-2.0/>.

[WCAG22]

W3C, "Web Content Accessibility Guidelines (WCAG) 2.2", 12 December 2024, <https://www.w3.org/TR/WCAG22/>.

[X12]

Accredited Standards Committee X12, "ASC X12 Standards", n.d., <https://x12.org/>.

[XADES]

ETSI, "Electronic Signatures and Infrastructures (ESI); XAdES digital signatures; Part 1: Building blocks and XAdES baseline signatures", ETSI EN 319 132-1, 2016.

[XHE]

OASIS, "Exchange Header Envelope (XHE) Version 1.0", 25 April 2021, <https://docs.oasis-open.org/bdxr/xhe/v1.0/os/xhe-v1.0-os-oasis.html>.

C.1. Test Keys

The issuer key is the Ed25519 key of Section 7.1 (TEST 1) of [RFC8032]. The node key is TEST 2 of the same section.¶

NOTE: '\' line wrapping per RFC 8792

Issuer private key (hex):
9d61b19deffd5a60ba844af492ec2cc44449c5697b326919703bac031cae7f60
Issuer public key (hex):
d75a980182b10ab7d54bfed3c964073a0ee172f3daa62325af021a68f707511a
Issuer JWK:
{"alg":"Ed25519","crv":"Ed25519","kid":"kPrK_qmxVWaYVA9wwBF6Iuo3vV\
zz7TxHCTwXBygrS4k","kty":"OKP","x":"11qYAYKxCrfVS_7TyWQHOg7hcvPapi\
MlrwIaaPcHURo"}
Issuer kid (JWK SHA-256 Thumbprint):
kPrK_qmxVWaYVA9wwBF6Iuo3vVzz7TxHCTwXBygrS4k

Node private key (hex):
4ccd089b28ff96da9db6c346ec114e0f5b8a319f35aba624da8cf6ed4fb8a6fb
Node public key (hex):
3d4017c3e843895a92b70aa74d1b7ebc9c982ccf2ec4968cc0cd55f12af4660c
Node kid (JWK SHA-256 Thumbprint):
FtIu-VbGrfe_KB6CH7GNwODB72MNxj_ml11dEvO-7kk

C.2. Envelope Core and Digest

The document octets are the 26 ASCII octets <Invoice>example</Invoice>. They stand in for a real invoice so that the vectors stay short. The transparency salt is the octets 0x00 to 0x1f. The JCS serialization of the core is:¶

NOTE: '\' line wrapping per RFC 8792

{"amount_due":"300.00","buyer":"tax:IT:vat:00000000000","currency"\
:"EUR","delivery_role":"primary","document":{"content_b64":"PEludm\
9pY2U-ZXhhbXBsZTwvSW52b2ljZT4","digest":{"alg":"sha-256","value":"\
6ZiIe1OpebitCF67KQnVf06-IzrttxbUipK7v8hX2yg"},"media_type":"applic\
ation/xml"},"id":"01a18201-84a0-7b2a-9d41-6c1f0e8a5b77","invoice_n\
umber":"F2026-000184","issue_date":"2026-10-28","issuer":"tax:ES:v\
at:B00000000","issuer_node":"https://node.example.com/itp","issuer\
_role":"seller","itp":"1","legal_original":"document","recipient":\
"tax:IT:vat:00000000000","seller":"tax:ES:vat:B00000000","sig_algs\
":["Ed25519"],"total_with_tax":"300.00","transparency_salt":"AAECA\
wQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8","type":"invoice","type_cod\
e":"380"}

The envelope digest (SHA-256 of the octets above, base64url) is:¶

tCMfh_UTadlM5gJmJ8Y5ofvUrCrSjeBSrnNJ7jd3I60

C.3. Issuer Signature

The JWS Protected Header, before base64url encoding, is:¶

NOTE: '\' line wrapping per RFC 8792

{"alg":"Ed25519","crit":["itp_role"],"itp_role":"issuer","kid":"kP\
rK_qmxVWaYVA9wwBF6Iuo3vVzz7TxHCTwXBygrS4k","typ":"itp-envelope+jws\
"}

The encoded protected header and the signature are:¶

NOTE: '\' line wrapping per RFC 8792

protected:
eyJhbGciOiJFZDI1NTE5IiwiY3JpdCI6WyJpdHBfcm9sZSJdLCJpdHBfcm9sZSI6Im\
lzc3VlciIsImtpZCI6ImtQcktfcW14VldhWVZBOXd3QkY2SXVvM3ZWeno3VHhIQ1R3\
WEJ5Z3JTNGsiLCJ0eXAiOiJpdHAtZW52ZWxvcGUrandzIn0

signature:
35u_aepY5agb9gPxHHk-hawtK6n9d6riRQEApwz8_G5wFw7Q3cVhBarDgiVmp2Js1S\
2K3u1KNYdehcGAO93vCA

C.4. Content-Digest and HTTP Message Signature

The envelope is sent as the JCS serialization of the JWS General JSON Serialization object, with empty "itp_evidence" arrays (1365 octets). Its Content-Digest field value is:¶

sha-256=:tGM8fHYi3ZCow6CDlj142ehZqwBn0THA+Lw0u7U3zMc=:

The signature base, signed with the node key, is:¶

NOTE: '\' line wrapping per RFC 8792

"@method": POST
"@target-uri": https://node.example.net/itp/in
"content-digest": sha-256=:tGM8fHYi3ZCow6CDlj142ehZqwBn0THA+Lw0u7U\
3zMc=:
"content-type": application/itp-envelope+jws
"idempotency-key": "01a18201-84a0-7b2a-9d41-6c1f0e8a5b77"
"@signature-params": ("@method" "@target-uri" "content-digest" "co\
ntent-type" "idempotency-key");created=1793182503;expires=17931828\
03;nonce="dG9rZW4tMDAx";keyid="FtIu-VbGrfe_KB6CH7GNwODB72MNxj_ml11\
dEvO-7kk";tag="itp"

The resulting Signature field value is:¶

NOTE: '\' line wrapping per RFC 8792

itp=:bOzCUemhJyw3eBk8Wy/00zxlzv773K0IBmEaFL5e6LkQqP2W8rDRdAK9uujlK\
F8hzCc1KwTj57eziXc3ysvjDA==:

C.5. Transparency Commitment

With the salt above, the commitment HMAC-SHA256(salt, envelope digest octets), base64url-encoded, is:¶

Q-LudrMZas2xSKx7SNj9ZiJK4Da-nc8r7QPoOpF0Ooc

C.6. Second Envelope

This envelope tests a currency without minor unit and an issuer outside Europe. The issuer key is TEST 3 of Section 7.1 of [RFC8032]; the node key and the HTTP request are not repeated. The document octets are the 28 ASCII octets <Invoice>example 2</Invoice>, and the transparency salt is the octets 0x20 to 0x3f.¶

NOTE: '\' line wrapping per RFC 8792

Issuer private key (hex):
c5aa8df43f9f837bedb7442f31dcb7b166d38535076f094b85ce3a2e0b4458f7
Issuer public key (hex):
fc51cd8e6218a1a38da47ed00230f0580816ed13ba3303ac5deb911548908025
Issuer kid (JWK SHA-256 Thumbprint):
FVV5umTuau890q59V-4Ga_R6qWb7ON_ivJc4EjvCwTM

JCS serialization of the core:
{"amount_due":"110000","buyer":"tax:JP:qualified-invoice:T00000000\
00001","currency":"JPY","delivery_role":"primary","document":{"con\
tent_b64":"PEludm9pY2U-ZXhhbXBsZSAyPC9JbnZvaWNlPg","digest":{"alg"\
:"sha-256","value":"fbnyJCUK9dWDESGpFm-3y-CdrHSI4_4JnOg5pPXSE6Q"},\
"media_type":"application/xml"},"id":"01a18201-9c40-7d3e-8f21-0a1b\
2c3d4e5f","invoice_number":"INV-2026-000057","issue_date":"2026-10\
-28","issue_tz":"Asia/Tokyo","issuer":"tax:JP:qualified-invoice:T0\
000000000000","issuer_node":"https://node.example.com/itp","issuer\
_participant_document":"https://node.example.com/p/2c81e4a7930f5db\
6","issuer_role":"seller","itp":"1","legal_original":"document","r\
ecipient":"tax:JP:qualified-invoice:T0000000000001","seller":"tax:\
JP:qualified-invoice:T0000000000000","sig_algs":["Ed25519"],"total\
_with_tax":"110000","transparency_salt":"ICEiIyQlJicoKSorLC0uLzAxM\
jM0NTY3ODk6Ozw9Pj8","type":"invoice","type_code":"380"}

Envelope digest:
MCh55C_d9tpKjjPhLNxcFof7XY7aF_4cqfJog_Tqdp8

JWS Protected Header:
{"alg":"Ed25519","crit":["itp_role"],"itp_role":"issuer","kid":"FV\
V5umTuau890q59V-4Ga_R6qWb7ON_ivJc4EjvCwTM","typ":"itp-envelope+jws\
"}

protected:
eyJhbGciOiJFZDI1NTE5IiwiY3JpdCI6WyJpdHBfcm9sZSJdLCJpdHBfcm9sZSI6Im\
lzc3VlciIsImtpZCI6IkZWVjV1bVR1YXU4OTBxNTlWLTRHYV9SNnFXYjdPTl9pdkpj\
NEVqdkN3VE0iLCJ0eXAiOiJpdHAtZW52ZWxvcGUrandzIn0

signature:
fsn_hHpYonvn5YGp9CU2nLSg5pTVHMrxHv89ud9zH3Z2Y25fgXB0BG8B6nVyMhnqxc\
V9MbidwVz2xln4_HMgCA

Transparency commitment:
n0AiEB_AxKljb-gPVkuRTs6_vBXDePBbQYIsNzJluL8

C.7. Negative Test Cases

Implementations are expected to produce the following results. Each case starts from the first envelope of Appendix C and changes one thing.¶

1. A second signature with a random 64-octet value and a valid protected header is appended to "signatures". The envelope is valid; the extra signature is reported as failed and ignored (Section 7.4).¶

2. The protected header of the issuer signature omits "crit". The signature is rejected, and the envelope is invalid.¶

3. The core lists "sig_algs" with the values "Ed25519" and "ML-DSA-65", only the Ed25519 signature is present, and the verifier supports ML-DSA-65. The envelope is invalid. A verifier that does not support ML-DSA-65 accepts it.¶

4. The core contains "total_with_tax": "300.000" with "currency": "EUR". The envelope is invalid, because EUR has two decimals. "1000" with "JPY" and "1.000" with "KWD" are valid; "-0" and "-0.00" are invalid in any currency.¶

5. The core contains the member "total_with_tax" twice. The envelope is rejected before any signature check.¶

6. The issuer signature has "itp_role" "issuer" but its key is listed in "delegates" of the Participant Document. The signature is rejected.¶

7. A Participant Document with a greater "seq" omits a key that the accepted document contained. The new document is rejected.¶

8. The same envelope is delivered twice with different "itp_evidence" contents. The second delivery receives the original "delivered" status, and the new evidence is added to the stored envelope.¶

D.1. JOSE for Envelopes, COSE for Transparency

Invoice software is built around JSON and HTTP, so envelopes use JOSE. Transparency services standardized by SCITT use COSE, so commitments are registered as COSE Signed Statements. JCS is used so that the signer can reproduce the envelope core for audit; verifiers do not depend on it, because they verify the octets received, and documents are carried as octets. JCS is an Informational RFC, so a Standards Track successor of this document would need a downward reference or a different serialization.¶

D.2. Registered Media Types for Signed Objects

Explicit typing prevents cross-object substitution [RFC8725]. The "typ" values are registered as media types with the "+jws" structured syntax suffix, as listed in the IANA "Structured Syntax Suffixes" registry with reference to [RFC7515], so that each value has a single owner and meaning.¶

D.3. TXT Record

[RFC5507] discourages overloading TXT records. ITP follows the precedent of MTA-STS [RFC8461]: the record signals presence and a version, plus a key thumbprint that is useful only with DNSSEC, and all other data is retrieved over HTTPS. An SVCB record [RFC9460] was considered and not used, because no connection parameters need to be conveyed.¶

D.4. An Opaque Inbox

Earlier designs put the recipient's PID in the inbox URL. The recipient is already in the signed core, and a PID in a URL ends up in access logs and can be altered by frameworks that decode percent-encoding, which would break HTTP Message Signatures. The inbox is therefore one URL per node.¶

D.5. No Invoice Model of Its Own

ITP does not define an invoice model, and does not make one mandatory. Tax authorities prescribe the content and often the syntax of the legal original, and they change them more often than an Internet protocol can follow; a model of its own would compete with EN 16931, Peppol PINT, and the national formats instead of carrying them. The envelope core holds only the members that transport, duplicate detection, and verification need, the way an email header does for its body. UBL is the one syntax that every receiving node accepts, because it is the common base of Peppol, PINT, and several national formats. Canonical models such as GOBL [GOBL] are useful for converting between formats and can be carried as documents or renditions, but a model maintained by one organization is not made mandatory.¶

D.6. One Scheme for Tax Identifiers

A separate scheme for VAT identification numbers of the European Union was considered and not adopted, because it would treat one region as the default. All tax identifiers use the "tax" scheme with the [ISO3166] code of the jurisdiction that issued them; prefixes such as "EL" or "XI" are presentation details recorded in the registry.¶

D.7. Generic Fiscal Members

Tax regimes differ in what they require: identifiers assigned by the authority, signatures inside the document, hash chains, fiscal devices, contingency modes, several taxes on one invoice, currencies with zero or three decimals. The core carries these as generic members ("fiscal_codes", "native_signature", "chain", "fiscal_device", "issuance_mode", "tax_summary") backed by registries, and leaves the rules of each regime to profiles. As a result, no normative requirement names a country; examples do, and identifiers, codes, and rules specific to a jurisdiction are registry entries and profiles.¶

D.8. Why Not BDXL

BDXL [BDXL] resolves a hashed participant identifier in a DNS zone run by the network, which then points to an SMP. This suits a network with a central register of participants. ITP discovery is controlled by the participant from its own domain, without a central register, so it uses a record under that domain. The two can coexist: a Participant Document can list a Peppol endpoint, and a BDXL zone could list ITP endpoints.¶

D.9. Why Not Signed Email

Invoices sent by email can be signed with S/MIME [RFC8551], and DKIM [RFC6376] lets a receiving mail system check the domain that sent a message. A DKIM signature is checked when the message is received and binds the message to a sending domain, not to the legal entity named in the invoice. S/MIME certificates identify a mailbox and, in some certificate profiles, an organization, and their discovery through DNS [RFC8162] starts from an email address. Neither finds a receiving endpoint from a tax identifier, binds a payment account, or defines statuses. An ITP envelope can be sent as an email attachment and verified like any other (Section 11).¶

D.10. Why Not Only an Existing Network

Four-corner networks such as Peppol and the Digital Business Networks Alliance [DBNA], exchange platforms that tax authorities run or designate, and EDI value-added networks provide addressing and transport among their admitted members. ITP adds verification that does not depend on the delivering channel, transparency, and addressing for entities outside those networks. ITP envelopes can travel over them, and the identifiers of a network that registers a PID scheme, such as Peppol identifiers, are ITP PIDs.¶

In clearance regimes, the legal original often already carries a signature or seal of the issuer and a stamp of the tax authority that any holder can check, for example through a public verification service of the authority. ITP carries those artifacts as renditions and stamps (Section 7.5) and verifies them under the rules of their scheme. It adds discovery, the binding of keys to legal entities across jurisdictions, attested payment accounts ([I-D.martinez-itp-lifecycle]), and one verification procedure for invoices from different regimes.¶