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

]> Invoice Trust Protocol (ITP): Discovery, Delivery, and Verification of Electronic Invoices BeeL. (Honey Solutions, S.L.)

Tarragona Spain carlos@martinezgv.com

electronic invoicing verification transparency discovery This document specifies the core of the Invoice Trust Protocol (ITP). ITP lets a business in any country find where and in which syntaxes another business receives invoices, deliver a signed invoice to it over HTTP, and obtain a signed acknowledgment. It also lets any later holder of the invoice, such as the buyer, a bank, or an auditor, check who issued it, that it was not altered, and which tax or network registrations exist for it. ITP carries invoices in existing syntaxes, defines no invoice data model, and works alongside the channels that tax authorities and networks make mandatory. Commercial statuses, payment information, and agent mandates are specified in companion documents. About This Document Status information for this document may be found at . Discussion of this document takes place on the DISPATCH Working Group mailing list (), which is archived at . Subscribe at .

Introduction Business-to-business invoices travel as PDF files attached to email, through supplier portals, through four-corner networks such as Peppol and the Digital Business Networks Alliance , through EDI value-added networks, and through clearance or reporting platforms run by tax authorities. The OECD describes these platforms and how tax administrations use them. None of these channels gives the parties a common way to:

find where, and in which syntaxes, a given legal entity receives invoices, unless both are in the same network;
check, without trusting the channel that delivered it, that an invoice comes from the entity named in it and was not modified, including the account it gives for payment; and
check which tax registration, clearance, or network acknowledgment exists for that invoice.

Payment redirection through forged invoices or changed bank details is a common fraud. The FBI's Internet Crime Complaint Center attributes about 2.8 billion US dollars of reported losses in 2024 to business email compromise , a category that includes requests to change payment details. Mandatory structured electronic invoicing is spreading in every region : in Latin America, where it started, in Asia, the Middle East, Africa, and Europe. In the European Union, Directive (EU) 2025/516 makes it the rule for most intra-EU business-to-business supplies from 1 July 2030. This will increase the number of structured invoices exchanged across networks and borders. This document defines:

participant identifiers that reuse existing schemes ();
discovery of receiving capabilities through DNS and a well-known URI ();
a trust model for participant keys ();
a signed envelope that carries an invoice in its original syntax, plus evidence added after signing ();
an HTTP binding for delivery, copies for the issuer, and status messages ();
the format of status messages and the two statuses that delivery needs ();
registration of commitments to envelopes in transparency services (); and
a verification procedure ().

Two companion documents build on it. specifies commercial and payment statuses, payment information, and models of jurisdictions and networks. lets a business authorize a software agent to act within limits. This document can be implemented without the companion documents.

Scope ITP carries invoices in syntaxes defined elsewhere: national formats prescribed by tax authorities, syntaxes based on or Peppol PINT , such as and , , and EDI standards such as ASC X12 and UN/EDIFACT . ITP assumes no semantic model; 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 ().

Relationship to Existing Work Peppol and the Digital Business Networks Alliance locate a recipient's access point through U-NAPTR records in a zone run by the network, as specified by OASIS BDXL , and through a service metadata publisher. The Digital Business Networks Alliance profiles OASIS SMP 2.0 and the OASIS AS4 profile ; Peppol uses its own SMP specification and AS4 profile . 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. 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 (), their endpoints as channel types (), and an ITP envelope can be carried over any of them that carries arbitrary documents. The IETF EDIINT working group defined AS1 , AS2 , and AS3 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 (), 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 addressed parties by email address and was not pursued. Registered delivery services , including registered electronic mail , give evidence of sending and receipt and can complement ITP's signed acknowledgments. UN/CEFACT and OASIS define the Exchange Header Envelope , 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 (). 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 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 , and the UN Transparency Protocol , 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 (), 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 in the European Union, and certificates issued under the laws of other jurisdictions, for which the UNCITRAL Model Laws on Electronic Signatures and on identity management and trust services give a basis for recognition across borders), the verifiable LEI , verifiable credentials , or business wallets such as the European Business Wallet proposal . Certificates are used directly under rule 3 of , and attestation issuers can rely on the other sources when they issue ITP attestations (). ITP does not define a new identity scheme.

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 , 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.

The Experiment This document is Experimental. The experiment is whether:

at least two independent implementations interoperate on discovery, delivery, signature verification, and transparency receipts, using the test vectors in ;
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
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.

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

JSON JSON texts defined by this document MUST be I-JSON . 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) before signing (). 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.

Amounts Monetary amounts are strings that match the "amount" rule below, paired with a currency code : An amount has at most 18 digits before the decimal point and no more decimals than the minor unit of its currency in , 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.

Text and Language Strings that identify documents, such as "invoice_number", are UTF-8 strings in Unicode Normalization Form C that conform to the FreeformClass of . The issuer writes them in the core after removing leading and trailing spaces, after applying the width mapping described in , 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 that applies to all of them; gives details.

Other Conventions Timestamps are "date-time" values of 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" (). Identifiers of ITP objects are UUID version 7 values . Base64url encoding follows without padding. SHA-256 is specified in and HMAC in . URIs follow . ABNF follows and . Examples fold long lines as described in . All identifiers of legal entities in examples are fictitious and have no valid check digits. Domain names are taken from . Values in examples that are not in the initial contents of a registry are illustrative.

Terminology The terms Signed Statement, Transparency Service, Receipt, Transparent Statement, Registration Policy, Auditor, and Relying Party are used as defined in . "Origin" and "same-origin" are used as in . 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 .
Envelope:: The signed ITP object that carries one commercial document, plus unsigned evidence about it ().
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 ().
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 ().
Trust list:: A signed list of parties that a relying party accepts for given roles ().
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 ().
Node Document:: A signed document in which a node publishes its endpoints and keys ().

Overview

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 . A recipient whose suppliers do not use ITP can publish its own receiving endpoint and can verify envelopes that reach it through other channels.

Message Flow

Main message flow (TS: transparency service) | | 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 | |<----------------------------------------------| ]]>

Conformance Classes

Sending node:: Implements discovery (), acceptance of Participant Documents (), envelope creation (), and the HTTP binding as a client (), including copies to the issuer's archive node (). Because status messages are sent to "issuer_node", it also publishes a Node Document and accepts status messages as a server ().
Receiving node:: Publishes Participant and Node Documents, implements the HTTP binding as a server, steps 1 to 4 of , duplicate detection (), the "copies" endpoint when a participant names it in "archive" (), and the "delivered" and "technical-rejected" statuses (). 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" (). So that any two participants share at least one syntax, a receiving node MUST accept invoices and credit notes in UBL 2.1 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 PINT , the specifications of the Digital Business Networks Alliance in the United States , and several national formats. Other syntaxes are optional.
Verifier:: Implements all of . A verifier need not implement the HTTP binding.
Directory:: Answers exact-match queries for Participant Documents () and does not alter the documents it returns.

Participant Identifiers A participant identifier (PID) has the following syntax: Characters outside this set, such as "&" or non-ASCII letters that some tax identifiers contain, are percent-encoded as UTF-8 octets, as in , with uppercase hexadecimal digits. Each scheme defines a normalization that MUST be applied before two PIDs are compared. After normalization, two PIDs are equal only if they are identical octet strings. PIDs of different schemes, or of different types of the "tax" scheme, are never equal, even when they contain the same identifier; a relation between them is established only by attestations (). Schemes are registered in the ITP PID Schemes registry (). The initial schemes are:

tax:: A tax identifier of any jurisdiction, as "tax:" followed by a jurisdiction code in uppercase, a colon, a type from the ITP Tax Identifier Types registry, a colon, and the identifier. The jurisdiction code is an alpha-2 country code or, for identifiers issued by a subdivision, its code, for example "CA-QC"; "XK", a user-assigned code under , is used for Kosovo. The jurisdiction is the one whose register the identifier belongs to, as recorded in the registry entry, written with its code even where documents use another prefix (). A type MAY define further colon-separated qualifiers before the identifier, such as a municipality code. Unless the registry entry for the type defines another normalization, the identifier is written without separators or spaces, in Unicode Normalization Form C, with letters in uppercase (letters outside ASCII by their Unicode simple uppercase mapping) before percent-encoding, fullwidth characters mapped to their ASCII equivalents, any check digit included, and without the country prefix that documents add to some identifiers, such as the prefix of VAT identification numbers in the European Union. An identifier that the authority derives from a base identifier for an establishment or a subdivision, such as a GSTIN per Indian state or an Indonesian NITKU per branch, is a separate type whose registry entry says how it relates to the base identifier. The registry entry lists the prefixes and suffixes that documents and validation services use for the type (), so that two spellings of one identifier normalize to the same PID; for example "ESB00000000" in a document maps to "tax:ES:vat:B00000000". Examples are "tax:JP:qualified-invoice:T0000000000000", "tax:ES:vat:B00000000", "tax:GB:vat:000000000", and "tax:MX:rfc:AAA010101AA0". lists the initial types. A party can hold several tax identifiers, for example one per state or one for income tax and one for consumption tax; each is a separate PID. A party registered for tax in a jurisdiction other than its own holds a PID of that jurisdiction, for example "tax:FR:vat:..." for a Spanish company registered for VAT in France, and "seller" and "buyer" carry the PID that the document uses for the transaction. Some tax identifiers are shared by several legal entities, such as the number of a group registration for VAT or another consumption tax; the registry entry for such a type says so. A participant MUST NOT use a shared tax identifier as its primary PID; it lists it in "aliases", covered by an attestation that names the member by another PID. A relying party MUST NOT accept a Participant Document under on the basis of a shared tax identifier alone.
eas:: A Peppol Electronic Address Scheme code , a colon, and the identifier, for example "eas:0009:00000000000000" (French SIRET) or "eas:0088:0000000000000" (Global Location Number). Values are normalized to lowercase, except the hexadecimal digits of percent-encoded octets, since Peppol participant identifiers are case-insensitive . "eas" is an initial scheme because its code list is public. The list includes international schemes, such as 0088 (Global Location Number) and 0060 (D-U-N-S Number), and national ones, such as 0151 (Australian Business Number). "eas" has no precedence over other schemes. Other networks, exchange platforms that tax authorities run or designate, and EDI value-added networks that address participants by identifiers of their own register PID schemes on the same terms.
lei:: A Legal Entity Identifier in uppercase.
domain:: A DNS name controlled by the participant, as an A-label in lowercase without a trailing dot. A "domain" PID does not identify a legal entity on its own ().

Where a PID appears in a claim that requires a URI, such as the "iss" or "sub" claim of a JWT, it is written as the URN "urn:ietf:params:itp:pid:" followed by the PID, for example "urn:ietf:params:itp:pid:tax:MX:rfc:AAA010101AA0". A participant MAY hold several PIDs. A PID is "verified" for a relying party only if an attestation that the relying party accepts binds it to the participant's keys, or if the relying party accepted the Participant Document under rule 3 of and the certificate identifies the participant by that PID.

Discovery

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 (). 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 , which do not require a domain.

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 (); a copy is not a separate payable.

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

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 . Participants that are natural persons SHOULD omit it ().
kt:: Optional. A comma-separated list of base64url-encoded SHA-256 JWK Thumbprints 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 (). 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 .

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 , the "kt" field binds keys to the domain. DNSSEC is RECOMMENDED ().

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 (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 . The resource is not signed; trust decisions use only the signed Participant Document.

Participant Document A Participant Document is a JWS in the Flattened JSON Serialization, or in the General JSON Serialization during a key change (), with "typ" "itp-participant+jws". Its payload is: ", ""]}, "delegates": [ {"kid": "", "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 , for example in Arabic and in English. It SHOULD be omitted when the participant is a natural person ().
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" , 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 (), 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 . 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 with the participant's signing keys (). 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 (). 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" () 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 (). 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 .
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.

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 and , this specification does not fix endpoint paths; they are published here: "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 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 (). 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 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.

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 (). A directory is identified by a URI Template 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 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.

Trust and Keys DNS, web servers, and directories only distribute ITP documents. A document is bound to a legal entity by attestations from issuers that the relying party accepts.

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, ), "jwks", "types" (attestation types it may issue, for attestation issuers), "schemes" (values of the ITP Bridge Schemes registry, for bridges), "jurisdictions" ( codes), "nbf", and "exp". The initial roles are "attestation-issuer", "operator", "transparency-service", "witness", and "bridge". "jurisdictions" contains alpha-2 codes or 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 , registers of Peppol service providers, or national registers of accredited platforms. discusses the consequences.

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

A "kyb" or "tax-registration" attestation from an issuer on an accepted trust list binds the PID to the key that signs the document.
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.
The document is signed with a key bound to an X.509 certificate 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 , 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 (), 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 (), since certificates are not registered in ITP transparency services. Companion documents that carry payment details, such as , say how recently bound keys affect them.

Attestations Attestations are SD-JWTs 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, ), "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 .
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 ) 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 (); text that uses the name says which one it means. Claims not registered by are private claim names () whose meaning is given by this section for the "typ" value "itp-attestation+sd-jwt" only. defines an attestation type for payment accounts. Every attestation includes "iat", "exp", and a status reference in the format of . Attestation issuers MUST register each attestation they issue in a transparency service (), so that participants, or monitors acting for them (), 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 only if it is within its validity period and not revoked at that time.

Keys The "kid" of each JWK MUST be its JWK SHA-256 Thumbprint , 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 . 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" , "ES256", and "PS256" . Ed25519 public keys are JWKs with "kty" "OKP" and "crv" "Ed25519" . Ed25519 signatures are verified with the checks of , 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 ; the envelope core lists every algorithm used in "sig_algs" (). 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 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" (); 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 . Implementations SHOULD support verification with "RS256" , 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 () 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 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 (). If the old key is compromised, an attestation issuer instead attests the new key ().

Key Transparency and Monitoring Each Participant Document SHOULD be registered in a transparency service (). 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 : 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.

The Envelope

Serialization An envelope is a JWS in the General JSON Serialization , with one additional member, "itp_evidence": ", "signatures": [ {"protected": "", "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 ; "sha-256" MUST be supported. Over HTTP, an envelope uses the media type "application/itp-envelope+jws" ().

Envelope Core Members are listed with their requirement level and JSON type. The correspondence with and PINT business terms is given in 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". gives the properties of each initial value.
type_code (optional, string):: The 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 () 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 () 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 ().
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 , and the rules for dereferencing URLs in 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 ().
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 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 code of the invoice currency.
tax_currency (optional, string):: The 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 or 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 ().
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 ().
document_languages (optional, array of strings):: Language tags 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" ().
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 (). Required for fiscal documents.
required_evidence (optional, array of strings):: Stamp types () 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 . A receiver that does not implement that document ignores it.
transparency_salt (string):: 32 random octets, base64url-encoded. Required if the envelope is registered ().
agent (optional, object):: Present when a software agent produced the envelope; defined in .

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.

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 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 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 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 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 on UBL, CAdES , or JAdES , and is declared in "native_signature".

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" (). 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 ).

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 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 ; a verifier that does not implement ignores "agent" signatures. A protected header MAY contain "x5c" when the key is accepted under rule 3 of . A key in "jwk" or "x5c" MUST NOT be used unless its JWK SHA-256 Thumbprint equals a "kid" accepted under for the signing time.

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 . A "timestamp" stamp has the scheme "rfc3161" and carries in "evidence_token" a time-stamp token 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 (). A rendition also contains "media_type" and "content_b64" with the legal original. For example: "}, "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 (). 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 .

HTTP Transport

General ITP uses HTTPS with TLS 1.3 , following , and servers are authenticated as described in . 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 or , but MUST support the mandatory-to-implement cipher suite, signature algorithms, and key exchange groups of , so that nodes in different jurisdictions can connect. HTTP semantics follow . 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 , 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 .

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 , in a profile similar to the one in :

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" , "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 (). 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 () 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 . 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 . 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" (). 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 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 with sender-constrained access tokens ( or ), as recommended in , is one option.

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 ; the content, shown truncated, is the 1365-octet envelope described there: The receiving node validates the request and the envelope as in steps 1 to 4 of . 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 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 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 (). A receiving node processes a delivery request in this order: it checks the size, the nonce, and "content-digest"; it performs step 1 of ; 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 (); 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.

Idempotency and Duplicates ITP uses the Idempotency-Key field defined in 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".

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 (). 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. and 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 . Where the processing order of 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 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 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 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.

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.

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

Type	Status	Meaning
badNonce	400	Nonce unknown or already used
badSignature	400	HTTP Message Signature invalid
unauthorizedSender	403	Sending node not authorized by the party concerned
unknownRecipient	404	No participant with that PID at this node
envelopeInvalid	422	Envelope signature, digest, or structure invalid
untrustedIssuer	422	Issuer keys not accepted under the trust model
inconsistentCore	422	Core contradicts the document
unsupportedDocument	422	Document type or syntax not accepted by the recipient
unsupportedExtension	422	A member listed in "crit" is not understood
unsupportedVersion	422	Major version not listed in "versions"
storageJurisdiction	422	The recipient cannot store the envelope where the applicable rules require
invalidTransition	409	Status not allowed in the current state
channelRequired	409	The recipient must be reached through another channel
idempotencyKeyMissing	400	Idempotency-Key field missing on a delivery or status request
idempotencyKeyReused	422	Idempotency key reused with different content
requestInProgress	409	A request with the same idempotency key is being processed
envelopeTooLarge	413	Envelope larger than "max_envelope_size"

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.

Status Messages over HTTP Status messages () 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 () 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.

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".

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.

Status Messages A status message is a JWS with "typ" "itp-status+jws", in the Flattened JSON Serialization, or in the General JSON Serialization when it carries several signatures (for example with an "agent" member, ). Its protected header contains "alg", "kid", "typ", "itp_role", and "crit" including "itp_role". Its payload is: "}, "status": "delivered", "effective_date": "2026-10-28", "by": "https://node.example.net/itp", "seq": 1 } ]]>

id (required, string):: A UUIDv7 assigned by the signer.
envelope_id, envelope_digest (required):: The envelope the message is about.
status (required, string):: A value from the ITP Statuses registry.
reason (optional, object):: "code", from the ITP Status Reason Codes registry or, for "technical-rejected", the name of an ITP error type (); "text"; and optional "lang".
effective_date (required, string):: The "full-date" on which the event took place, which can differ from the date of the message.
by (required, string):: The signer: the PID of a participant; the Node Document URL of a node, for statuses that a node signs; or the "id" of a bridge's trust list entry, for statuses that a bridge signs.
seq (required, integer), prev (object):: "seq" counts the messages of one signer for one envelope, starting at 1, and "prev" is the digest of that signer's previous message; it is absent from the first.
agent (optional, object):: Present when a software agent produced the message ().

A status message MAY have an "itp_evidence" member next to "payload" and "signatures", with stamps bound to the status message digest, for example a timestamp. A participant MUST sign the status messages for one envelope through a single node, so that its "seq" chain does not fork. The digest of a status message is the SHA-256 hash of its JWS Payload octets. A status message is signed by the party named in "by": a participant with a key covered by its accepted Participant Document, including a "delegated-issuer" key; a node with a key listed in "kids" of the recipient's "inbound" entry for that node; a bridge with a key from its trust list entry. This document defines two statuses, both signed by the receiving node with "itp_role" "node":

delivered:: The envelope reached the recipient's node and passed steps 1 to 4 of .
technical-rejected:: The envelope was refused, or could not be passed to the recipient, for technical or regulatory reasons; "reason" is required and gives the cause. It is final for delivery; defines its effect on other statuses.

defines further statuses, their signers, and how a state is derived from the set of messages. A node that does not implement that document stores and returns such messages but does not interpret them.

Transparency

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 (). After signing an envelope, the issuing node computes the commitment where the HMAC key is the 32 octets obtained by decoding "transparency_salt", and registers C in a transparency service in one of two ways:

Per envelope:: A Signed Statement, which is a COSE_Sign1 message , 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 , and -37 ("PS256") as registered by . 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 with "iss" set to "urn:ietf:params:oauth:jwk-thumbprint:sha-256:" followed by the key's thumbprint , 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 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 ().

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 (). The node registers the Signed Statement, for example with , and adds to "itp_evidence.receipts" an object with: "statement", the base64url encoding of the Signed Statement; "receipt", the base64url encoding of the Receipt ; 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 . The Registration Policy of a transparency service used for ITP MUST verify that the Signed Statement is signed with a key accepted under 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 , and MUST include the registration time as the "iat" claim of a CWT Claims header parameter 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.

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 () 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.

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 and , and verifiers that can check such checkpoints SHOULD keep the latest one they have seen for each log and check consistency against it.

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 sets for certain intra-EU transactions from July 2030; profiles say which deadlines apply.

Verification Any holder of an envelope can verify it locally:

Check size limits, I-JSON conformance including the rejections in , and the structure of the JWS.
Obtain the issuer's Participant Document, from a document already accepted, from "issuer_participant_document", or from a directory, and accept it as described in . Check that "issuer", and "seller" when "issuer_role" is "seller", are PIDs verified () for the Participant Document that lists the signing key; "aliases" alone do not verify a PID. If "issuer_role" is not "seller", check "authorization", unless the ITP Document Types registry marks the document type as issued by the buyer in its own right, in which case check that "issuer" equals "buyer". If an "agent" member is present and the verifier implements , apply it.
Verify the signatures as described in , including "crit", "typ", "itp_role", and "sig_algs", with keys valid at the signing time.
Retrieve the document if needed and recompute its digest. A verifier that interprets the document syntax also checks that the core is consistent with the document (); a receiving node that does not interpret the syntax omits this check.
Recompute C and verify each Receipt and, in batch mode, the inclusion proof, and check that the key that signed the batch statement is listed in "kids" of a "senders" entry of the issuer's Participant Document. In per-envelope mode, check that the Signed Statement is signed with the key of a valid "issuer" or "delegated-issuer" signature on the envelope.
Verify each rendition and stamp, and report any stamp type listed in "required_evidence" that is missing. Where the authority offers public verification, query it and check that its record matches the issuer, the number or fiscal code, the issue date, and, where the document type states an amount, the total.
Check whether the envelope duplicates one already held.
Verify the chain of status messages ().

A failure in steps 1 to 4 makes the envelope invalid. A receiving node then answers "envelopeInvalid" for steps 1 and 3 and for a digest mismatch in step 4, "untrustedIssuer" for step 2, and "inconsistentCore" for a contradiction found in step 4 (). The results of steps 5 to 8 are reported and do not by themselves make the envelope invalid. Authenticity is judged with the status of attestations at the signing time. A verification result covers the origin and integrity of an envelope. It does not establish that the issuer is a known supplier or that the amount is owed, and is not an authorization to pay. Envelopes signed with a recently bound key () are reported as such. A receiving node also reports to the recipient an envelope from an issuer from which that recipient has not received an envelope before. A node MAY offer verification as a service. The result is a JWS with "typ" "itp-verification+jws", signed with a node key, whose payload has "envelope_digest", "verified_at", "verifier" (the Node Document URL), and "results", an array with one object per step above, each with "step" (the step number), "result" ("pass", "fail", or "not-applicable"), and optional "detail" and "lang". Sending an envelope to a third party discloses its content, so local verification is RECOMMENDED. A verification service MUST NOT return commercial status, duplicate information, or account numbers except to the issuer, the recipient, or parties they authorize.

Operational Considerations Signing keys of participants and nodes need non-exportable storage, such as hardware security modules or equivalent cloud services. Operators need a procedure to tell participants and counterparties about a key compromise. Networks and jurisdictions set their own requirements on platforms, for example certification to ISO/IEC 27001. A node that also acts in a designated channel holds whatever accreditation that channel requires, and trust lists can record such accreditations. Retention periods for invoices and accounting records are set by each jurisdiction and can span decades. Recipients SHOULD store, with each envelope, the Participant Document, attestations, status list snapshots, trust lists, the keys and latest checkpoints of the transparency services, and Receipts used at verification, so that the verification can be repeated after the issuer's domain or operator has changed or ceased. Long-term validity of signatures can be preserved with evidence records , with JAdES archival signatures , or by a preservation service, for example one that follows . Signatures inside the legal original ("native_signature") are validated, and validated again later, with the procedures of their own format, for example for AdES signatures. The transparency salt is kept as long as the envelope; deleting it breaks the link between the envelope and its commitment. Some jurisdictions require that invoices be stored in their territory, or that the place of storage be notified or accessible online to the tax authority. Nodes describe their storage in the "storage" member of their Node Document, and a node that cannot meet the requirements that apply to a recipient answers "storageJurisdiction". Network access across borders is not uniform. In some jurisdictions connections to hosts abroad can be slow, filtered, or blocked, public web sites need a local filing, and DNSSEC validation is uncommon. Participants there are expected to use nodes, transparency services, status list endpoints, and trust list distribution points that are reachable from within the jurisdiction, and a sending node abroad can deliver through a node in the recipient's jurisdiction that the recipient lists in "inbound". When a participant changes operator, the former operator publishes a last document with "superseded_by", and keeps serving its last Participant Document for at least the pin period it announced. When a participant changes PID through a merger or re-registration, the successor lists the former PID in "predecessors". Envelopes issued under the former PID remain verifiable with the former keys. Pinning () restricts the use of payment details that arrive through unlisted channels. It never prevents an invoice from being issued through a channel that the law requires, so an outage of a participant's node does not stop invoicing within legal deadlines. Participants with low bandwidth or intermittent connectivity, and fiscal devices that work offline, usually rely on a node hosted by their operator, which queues envelopes and registrations and retries as described in . Nodes cache Participant Documents, trust lists, and status lists within their validity, and senders avoid "href" documents and large attachments for recipients that announce a small "max_envelope_size". Transparency services and witnesses have to run for as long as invoices are retained. Operators of nodes are expected to choose services with published policies on availability and retention, and to register with at least one service that is independent of themselves. Sanctions, controls on cryptography, and data localization rules can prevent a participant in one jurisdiction from using a transparency service, witness, trust list, or attestation issuer operated in another, or can end that use while invoices are retained. ITP names no global operator: relying parties configure these services per jurisdiction, an envelope can carry Receipts from several transparency services, and verification uses the evidence that the recipient stored with the envelope. For manageability (), nodes are expected to log, for each envelope, the result of each verification step and the evidence used, to count deliveries, rejections by error type, and verification failures by step, and to warn their operators before trust lists, attestations, Participant Documents, or node keys expire. These counts are the data that the experiment asks recipients to publish.

Implementation Status Note to the RFC Editor: please remove this section before publication, as described in .

Test vector generator:: Organization: the author. Description: a Python program that produces the values in from the RFC 8032 test keys, using the "cryptography" library. Maturity: prototype. Coverage: envelope core serialization, envelope digest, issuer signature, Content-Digest, HTTP Message Signature, and transparency commitment. License: to be published under the Apache License 2.0 with the reference implementation. Contact: the author. Date: October 2026.
Reference implementation:: Organization: BeeL. (Honey Solutions, S.L.). Description: an open source node covering discovery, Participant and Node Documents, envelope signing and verification, delivery, status messages, and registration with a transparency service. Maturity: in development. License: Apache 2.0 (intended). Contact: the author.

No independent implementation is known at the time of writing.

Security Considerations

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 ().

Impersonation and Trust Signatures identify a legal entity only through the trust model of , 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 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.

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 , 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 (), pinning does not protect the first contact.

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 () 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 . 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 (). 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 (), 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 () and is then accepted like any other key, so this rule protects only participants that watch transparency services, themselves or through a monitor (). 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 (). Recipients match them against their own orders and supplier records, and payment details in them are handled as described in .

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 . "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.

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 , and signatures inside documents are verified with the rules of their own format.

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.

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. 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 derives the state from that set, so that the two sides cannot end up with different states because messages arrived in a different order.

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 ).

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 ().

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 (). 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 () says where it keeps them.

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.

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.

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

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; 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.

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 (), 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" (). 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.

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.

Privacy Considerations This section follows .

Data:: Invoices contain commercially sensitive data and, when a party is a natural person, personal data. The fact that two parties exchange invoices is sensitive too.
Public and non-public data:: Anyone can obtain, without authentication: the "_itp" record and well-known resource of a domain; any Participant Document whose URL or PID it knows, with the participant's PIDs, name, keys, attestations, and the URLs of the nodes that receive, send, and keep copies for it, which usually identify its operator; Node Documents, which do not list participants; and the registrations in transparency services described below, which do not identify recipients. A party that knows or guesses a PID can therefore learn whether that participant uses ITP and through which operator. ITP does not publish envelopes, documents, attachments, status messages, payment details or "payment-account" attestations, an operator's list of participants, or a participant's counterparties. Nodes return envelopes and status messages only to the nodes of the parties (), and the inbox does not reveal whether a PID is a participant to clients that fail authentication ().
Natural persons:: A sole trader's tax identifier is often a national identity number, is derived from one, or encodes the holder's name and date of birth (an Indonesian resident's NPWP is the national identity number, and an Indian GSTIN contains the holder's PAN), so publishing it discloses personal data. Participants that are natural persons SHOULD NOT publish a PID in DNS, SHOULD omit "name", and SHOULD be reachable only through exact-match queries. PIDs do not appear in URLs (), so they do not reach access logs.
Enumeration:: Tax identifier spaces are small enough to enumerate. Directories answer only exact queries and rate-limit them (), which slows enumeration by one client but does not prevent it by many; a directory that answers only authenticated operators makes bulk queries attributable. PID digests of legal entities are unkeyed hashes, so a reader of a transparency log can test every identifier of a jurisdiction and learn which legal entities use ITP and when their documents or attestations changed. ITP therefore does not keep confidential which legal entities use it, and an operator's customer list can be rebuilt by querying directories for those PIDs. PID digests of natural persons are keyed () to prevent this for them.
Observers:: Resolvers see "_itp" queries, and directories and verification services see who looks up whom. Clients SHOULD fetch status lists whole and cache them, and SHOULD verify locally. They can also use encrypted DNS transports and Oblivious HTTP for third-party directories and verification services. Retrieving a document from "href" tells its host when the recipient processed it, which is one reason "content_b64" is RECOMMENDED.
Transparency:: In per-envelope mode the key thumbprint in "iss" links each registration to the issuer's published keys, so readers of the log learn how many envelopes each issuer registers and when; this can reveal sales volume. In batch mode they learn only per-node volumes. Registrations of Participant Documents and attestations reveal that a given legal entity uses ITP. Signed Statements MUST NOT contain identifiers of natural persons in clear.
Identifiers and correlation:: PIDs are stable public identifiers of legal entities and ITP does not hide them. UUIDv7 identifiers reveal their creation time.
Confidentiality:: Nodes SHOULD encrypt stored envelopes. Envelopes MAY also be encrypted end to end to a recipient key with JWE ; a bridge that needs the content then acts on behalf of the party that uses it.
Retention and erasure:: Invoices are kept for the periods the law requires. Data protection laws commonly allow such retention, for example Article 17(3) of in the European Union. Many of them also restrict transfers of personal data abroad or require a copy in the country. Registering in a transparency service, querying a directory, or using a node, bridge, or verification service in another country can be such a transfer when a party is a natural person. Operators state where they process data, as nodes do in "storage" (). Logs are append-only, so data that could identify a natural person is not registered in them, as recommended, for example, in . Each component (node, directory, transparency service, verifier, attestation issuer, bridge) needs a documented role under the data protection law that applies to it.

Internationalization Considerations This section follows and . All ITP JSON texts are UTF-8. Members that hold text for people (such as "name" in a Participant Document, "reason.text" in a status message, and "detail" in problem details and verification results) are not used for matching. Their language is given by a "lang" member, a language tag , in the same object, and their base direction by an optional "dir" member ("ltr", "rtl", or "auto"); without "lang", the language is unknown. A sender MAY provide the same text in several languages by using an array of objects, each with "lang", "text", and optional "dir", in place of a string, where a member's definition allows it. Some jurisdictions require names and other text in a given language and allow a second one, for example Arabic with English. Receivers display such text with its language and direction, each value in its own bidirectional isolate (for example between U+2068 FIRST STRONG ISOLATE and U+2069 POP DIRECTIONAL ISOLATE), so that right-to-left text does not reorder neighboring identifiers or amounts, and do not interpret it. Text that nodes generate, such as "detail" in problem details, follows the Accept-Language field of the request when possible (). Identifiers that are matched (PIDs, invoice numbers, URLs, codes) are restricted to ASCII or percent-encoded UTF-8 (), or are NFC strings under the PRECIS FreeformClass (), so that matching does not depend on how text was entered. Documents carry their own language information, and "document_languages" in the core lets a recipient know, without parsing the document, in which languages it is written, for example where a jurisdiction requires a given language. Calendar dates are Gregorian "full-date" values. Where a document uses another calendar, the core still carries the Gregorian date, and the document keeps its original date.

IANA Considerations

Well-Known URI IANA is requested to register the following in the "Well-Known URIs" registry :

URI Suffix:: itp
Change Controller:: IETF
Specification Document(s):: of this document
Status:: permanent
Related Information:: None

Underscored DNS Node Name IANA is requested to add the following to the "Underscored and Globally Scoped DNS Node Names" registry : Underscored DNS node name

RR Type	_NODE NAME	Reference
TXT	_itp	of this document

Media Types IANA is requested to register the following media types in the "Media Types" registry, following : Media types (type name: application)

Subtype name	Content	Section
itp-metadata+json	Well-known metadata
itp-commitment	32-octet commitment
itp-batch-head	32-octet Merkle tree head
itp-participant+jws	Participant Document
itp-node+jws	Node Document
itp-trust-list+jws	Trust list
itp-envelope+jws	Envelope
itp-rendition+jws	Rendition
itp-stamp+jws	Stamp
itp-status+jws	Status message
itp-verification+jws	Verification result
itp-attestation+sd-jwt	Attestation

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 and 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

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

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):: of this document

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

Registry name:: itp
Specification:: This document
Repository:: The ITP URN Values registry (). The values "error" and "pid" are reserved there: URNs under "urn:ietf:params:itp:error:" are assigned by the ITP Error Types registry (), and URNs under "urn:ietf:params:itp:pid:" are formed from PIDs as described in .
Index value:: Values are assigned by the registries above.

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 . 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 , with this document as the reference.

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: ITP registries

Registry	Fields	Initial contents
ITP PID Schemes	name, normalization rule, issuing authority, jurisdiction of the identifiers or of each code where the scheme ties them to one, reference
ITP Tax Identifier Types	jurisdiction code, type, prefixes and suffixes used in documents, issuing authority, format and check digit, qualifiers, normalization, base identifier and relation to it, shared by several entities (yes/no), personal identifier (yes/no), reference
ITP Document Types	name, fiscal (yes/no), states an amount (yes/no), issued by the buyer in its own right (yes/no), reference
ITP Statuses	name, emitted by, final (yes, no, or conditional with the condition), reference	"delivered" (final: no) and "technical-rejected" (final: yes) ()
ITP Status Reason Codes	code, description, reference	none
ITP Stamp Types	name, description, reference
ITP Bridge Schemes	name, jurisdiction or network, description, reference	"rfc3161" ()
ITP Tax Schemes	name, jurisdiction, description, reference	"vat", "gst", "sales-tax"
ITP Signer Roles	name, description, reference
ITP Trust List Roles	name, description, reference
ITP Attestation Types	name, description, reference
ITP Channel Types	name, description, members that identify the participant, reference	"itp", "peppol", and "network" ()
ITP Profiles	identifier, jurisdiction or network, maintaining organization, reference	none
ITP URN Values	URN suffix, description, reference	"error", "pid" (reserved, this document)

The initial contents of the ITP Document Types registry are given in , with this document as the reference. Initial ITP document types

Name	Fiscal	States an amount	Issued by the buyer in its own right
invoice	yes	yes	no
credit-note	yes	yes	no
debit-note	yes	yes	no
prepayment-invoice	yes	yes	no
simplified-invoice	yes	yes	no
consolidated-invoice	yes	yes	no
sales-receipt	yes	yes	no
payment-receipt	yes	yes	no
withholding-certificate	yes	no	yes
transport-document	yes	no	no
correction-letter	yes	no	no
proforma	no	yes	no

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.

References Normative References Codes for the representation of currencies ISO Codes for the representation of names of countries and their subdivisions - Part 1: Country code ISO Codes for the representation of names of countries and their subdivisions - Part 2: Country subdivision code ISO Financial services - Legal entity identifier (LEI) - Part 1: Assignment ISO UN/EDIFACT code list 1001: Document name code, directory D.16B UN/CEFACT Unicode Normalization Forms The Unicode Consortium n.d. Peppol Code Lists - Participant identifier schemes, version 9.7 OpenPeppol AISBL Peppol Policy for use of Identifiers, version 4.4.0 OpenPeppol AISBL Universal Business Language Version 2.1 OASIS OpenID Federation 1.0 The Idempotency-Key HTTP Header Field The HTTP Idempotency-Key request header field can be used to make non-idempotent HTTP methods such as POST or PATCH fault-tolerant. An Architecture for Trustworthy and Transparent Digital Supply Chains Traceability in supply chains is a growing security concern. While Verifiable Data Structures (VDSs) have addressed specific issues, such as equivocation over digital certificates, they lack a universal architecture for all supply chains. This document defines such an architecture for single-issuer signed statement transparency. It ensures extensibility and interoperability between different transparency services as well as compliance with various auditing procedures and regulatory requirements. Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. The JavaScript Object Notation (JSON) Data Interchange Format JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. The I-JSON Message Format I-JSON (short for "Internet JSON") is a restricted profile of JSON designed to maximize interoperability and increase confidence that software can process it successfully with predictable results. JSON Canonicalization Scheme (JCS) Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results. This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation of JSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to the Internet JSON (I-JSON) subset, and by using deterministic property sorting. PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols Application protocols using Unicode code points in protocol strings need to properly handle such strings in order to enforce internationalization rules for strings placed in various protocol slots (such as addresses and identifiers) and to perform valid comparison operations (e.g., for purposes of authentication or authorization). This document defines a framework enabling application protocols to perform the preparation, enforcement, and comparison of internationalized strings ("PRECIS") in a way that depends on the properties of Unicode code points and thus is more agile with respect to versions of Unicode. As a result, this framework provides a more sustainable approach to the handling of internationalized strings than the previous framework, known as Stringprep (RFC 3454). This document obsoletes RFC 7564. Tags for Identifying Languages This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Date and Time on the Internet: Timestamps This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar. Universally Unique IDentifiers (UUIDs) This specification defines UUIDs (Universally Unique IDentifiers) -- also known as GUIDs (Globally Unique IDentifiers) -- and a Uniform Resource Name namespace for UUIDs. A UUID is 128 bits long and is intended to guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System (NCS), later in the Open Software Foundation's (OSF's) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms. This specification is derived from the OSF DCE specification with the kind permission of the OSF (now known as "The Open Group"). Information from earlier versions of the OSF DCE specification have been incorporated into this document. This document obsoletes RFC 4122. JSON Web Signature (JWS) JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF) Federal Information Processing Standard, FIPS HMAC: Keyed-Hashing for Message Authentication This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind Uniform Resource Identifier (URI): Generic Syntax A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] Augmented BNF for Syntax Specifications: ABNF Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] Case-Sensitive String Support in ABNF This document extends the base definition of ABNF (Augmented Backus-Naur Form) to include a way to specify US-ASCII string literals that are matched in a case-sensitive manner. The Web Origin Concept This document defines the concept of an "origin", which is often used as the scope of authority or privilege by user agents. Typically, user agents isolate content retrieved from different origins to prevent malicious web site operators from interfering with the operation of benign web sites. In addition to outlining the principles that underlie the concept of origin, this document details how to determine the origin of a URI and how to serialize an origin into a string. It also defines an HTTP header field, named "Origin", that indicates which origins are associated with an HTTP request. [STANDARDS-TRACK] Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves Formally, any DNS Resource Record (RR) may occur under any domain name. However, some services use an operational convention for defining specific interpretations of an RRset by locating the records in a DNS branch under the parent domain to which the RRset actually applies. The top of this subordinate branch is defined by a naming convention that uses a reserved node name, which begins with the underscore character (e.g., "_name"). The underscored naming construct defines a semantic scope for DNS record types that are associated with the parent domain above the underscored branch. This specification explores the nature of this DNS usage and defines the "Underscored and Globally Scoped DNS Node Names" registry with IANA. The purpose of this registry is to avoid collisions resulting from the use of the same underscored name for different services. JSON Web Key (JWK) Thumbprint This specification defines a method for computing a hash value over a JSON Web Key (JWK). It defines which fields in a JWK are used in the hash computation, the method of creating a canonical form for those fields, and how to convert the resulting Unicode string into a byte sequence to be hashed. The resulting hash value can be used for identifying or selecting the key represented by the JWK that is the subject of the thumbprint. DNS Security Introduction and Requirements The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK] HTTP Caching The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages. This document obsoletes RFC 7234. JSON Web Key (JWK) A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. URI Template A URI Template is a compact sequence of characters for describing a range of Uniform Resource Identifiers through variable expansion. This specification defines the URI Template syntax and the process for expanding a URI Template into a URI reference, along with guidelines for the use of URI Templates on the Internet. [STANDARDS-TRACK] Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] Selective Disclosure for JSON Web Tokens This specification defines a mechanism for the selective disclosure of individual elements of a JSON data structure used as the payload of a JSON Web Signature (JWS). The primary use case is the selective disclosure of JSON Web Token (JWT) claims. JSON Web Token (JWT) JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. Token Status List (TSL) MATTR Bundesdruckerei SPRIND This specification defines a status mechanism called Token Status List (TSL), data structures and processing rules for representing the status of tokens secured by JSON Object Signing and Encryption (JOSE) or CBOR Object Signing and Encryption (COSE), such as JWT, SD-JWT, CBOR Web Token, and ISO mdoc. It also defines an extension point and a registry for future status mechanisms. Edwards-Curve Digital Signature Algorithm (EdDSA) This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. Fully-Specified Algorithms for JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) This specification refers to cryptographic algorithm identifiers that fully specify the cryptographic operations to be performed, including any curve, key derivation function (KDF), and hash functions, as being "fully specified". It refers to cryptographic algorithm identifiers that require additional information beyond the algorithm identifier to determine the cryptographic operations to be performed as being "polymorphic". This specification creates fully-specified algorithm identifiers for registered JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) polymorphic algorithm identifiers, enabling applications to use only fully-specified algorithm identifiers. It deprecates those polymorphic algorithm identifiers. This specification updates RFCs 7518, 8037, and 9053. It deprecates polymorphic algorithms defined by RFCs 8037 and 9053 and provides fully-specified replacements for them. It adds to the instructions to designated experts in RFCs 7518 and 9053. JSON Web Algorithms (JWA) This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers. CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE) This document defines how to use the Diffie-Hellman algorithms "X25519" and "X448" as well as the signature algorithms "Ed25519" and "Ed448" from the IRTF CFRG elliptic curves work in JSON Object Signing and Encryption (JOSE). JSON Web Token Best Current Practices JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas. This Best Current Practices document updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs. Automatic Certificate Management Environment (ACME) Public Key Infrastructure using X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities (CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. As of this writing, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation. Digest Fields This document defines HTTP fields that support integrity digests. The Content-Digest field can be used for the integrity of HTTP message content. The Repr-Digest field can be used for the integrity of HTTP representations. Want-Content-Digest and Want-Repr-Digest can be used to indicate a sender's interest and preferences for receiving the respective Integrity fields. This document obsoletes RFC 3230 and the Digest and Want-Digest HTTP fields. Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP) This document describes the format of a request sent to a Time Stamping Authority (TSA) and of the response that is returned. It also establishes several security-relevant requirements for TSA operation, with regards to processing requests to generate responses. [STANDARDS-TRACK] The Transport Layer Security (TLS) Protocol Version 1.3 This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document obsoletes RFC 8446, which specified TLS 1.3. This document obsoletes RFC 5246 (specifying TLS 1.2) and RFCs 5077, 6961, 7627, and 8422, all of which pertain to TLS 1.2 or earlier, and updates RFCs 5705 and 6066. This document also specifies new requirements for TLS 1.2 implementations. Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are used to protect data exchanged over a wide range of application protocols and can also form the basis for secure transport protocols. Over the years, the industry has witnessed several serious attacks on TLS and DTLS, including attacks on the most commonly used cipher suites and their modes of operation. This document provides the latest recommendations for ensuring the security of deployed services that use TLS and DTLS. These recommendations are applicable to the majority of use cases. RFC 7525, an earlier version of the TLS recommendations, was published when the industry was transitioning to TLS 1.2. Years later, this transition is largely complete, and TLS 1.3 is widely available. This document updates the guidance given the new environment and obsoletes RFC 7525. In addition, this document updates RFCs 5288 and 6066 in view of recent attacks. Service Identity in TLS Many application technologies enable secure communication between two entities by means of Transport Layer Security (TLS) with Internet Public Key Infrastructure using X.509 (PKIX) certificates. This document specifies procedures for representing and verifying the identity of application services in such interactions. This document obsoletes RFC 6125. HTTP Semantics The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. Special-Purpose IP Address Registries This memo reiterates the assignment of an IPv4 address block (192.0.0.0/24) to IANA. It also instructs IANA to restructure its IPv4 and IPv6 Special-Purpose Address Registries. Upon restructuring, the aforementioned registries will record all special-purpose address blocks, maintaining a common set of information regarding each address block. Updates to the Special-Purpose IP Address Registries This memo updates the IANA IPv4 and IPv6 Special-Purpose Address Registries to address issues raised by the definition of a "global" prefix. It also corrects several errors in registry entries to ensure the integrity of the IANA Special-Purpose Address Registries. This memo updates RFC 6890. HTTP Message Signatures This document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message. This mechanism supports use cases where the full HTTP message may not be known to the signer and where the message may be transformed (e.g., by intermediaries) before reaching the verifier. This document also describes a means for requesting that a signature be applied to a subsequent HTTP message in an ongoing HTTP exchange. Problem Details for HTTP APIs This document defines a "problem detail" to carry machine-readable details of errors in HTTP response content to avoid the need to define new error response formats for HTTP APIs. This document obsoletes RFC 7807. JavaScript Object Notation (JSON) Pointer JSON Pointer defines a string syntax for identifying a specific value within a JavaScript Object Notation (JSON) document. CBOR Object Signing and Encryption (COSE): Structures and Process Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. CBOR Web Token (CWT) Claims in COSE Headers This document describes how to include CBOR Web Token (CWT) claims in the header parameters of any CBOR Object Signing and Encryption (COSE) structure. This functionality helps to facilitate applications that wish to make use of CWT claims in encrypted COSE structures and/or COSE structures featuring detached signatures, while having some of those claims be available before decryption and/or without inspecting the detached payload. Another use case is using CWT claims with payloads that are not CWT Claims Sets, including payloads that are not CBOR at all. JWK Thumbprint URI This specification registers a kind of URI that represents a JSON Web Key (JWK) Thumbprint value. JWK Thumbprints are defined in RFC 7638. This enables JWK Thumbprints to be used, for instance, as key identifiers in contexts requiring URIs. Certificate Transparency Version 2.0 This document describes version 2.0 of the Certificate Transparency (CT) protocol for publicly logging the existence of Transport Layer Security (TLS) server certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. This document obsoletes RFC 6962. It also specifies a new TLS extension that is used to send various CT log artifacts. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. CBOR Object Signing and Encryption (COSE) Receipts CBOR Object Signing and Encryption (COSE) Receipts prove properties of a Verifiable Data Structure (VDS) to a verifier. VDSs and associated Proof Types enable security properties, such as minimal disclosure, transparency, and non-equivocation. Transparency helps maintain trust over time and has been applied to certificates, end-to-end encrypted messaging systems, and supply chain security. This specification enables concise transparency-oriented systems by building on Concise Binary Object Representation (CBOR) and COSE. The extensibility of the approach is demonstrated by providing CBOR encodings for Merkle inclusion and consistency proofs. Well-Known Uniform Resource Identifiers (URIs) This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry. Media Type Specifications and Registration Procedures This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice. An IETF URN Sub-namespace for Registered Protocol Parameters This document describes a new sub-delegation for the 'ietf' URN namespace for registered protocol items. The 'ietf' URN namespace is defined in RFC 2648 as a root for persistent URIs that refer to IETF- defined resources. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Guidelines for Writing an IANA Considerations Section in RFCs Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. Informative References Invoice Trust Protocol (ITP): Lifecycle Status and Payment Information Invoice Trust Protocol (ITP): Agent Mandates The Simple Invoicing Protocol This memo specifies a protocol for transferring invoices automatically between companies. The receiver can read invoice data automatically into accounts payables and possibly into approval work flow. This eliminates the costly and error-prone manual typing of invoice data. Main design goal was simplicity in order to make implementation easy. The parties involved identify themselves using e-mail addresses, which makes addressing simple and flexible. Electronic invoicing - Part 1: Semantic data model of the core elements of an electronic invoice European Committee for Standardization (CEN) Peppol Specifications for PINT OpenPeppol AISBL n.d. Peppol BIS Billing 3.0 OpenPeppol AISBL n.d. Universal Business Language Version 2.5 OASIS Cross Industry Invoice, D16B UN/CEFACT GOBL: Go Business Language Invopop SL n.d. Business Document Metadata Service Location Version 1.0 OASIS Service Metadata Publishing (SMP) Version 2.0 OASIS AS4 Interoperability Profile for Four-Corner Networks Version 1.0 OASIS Digital Business Networks Alliance Exchange Framework Digital Business Networks Alliance n.d. Tax Administration 3.0 and Electronic Invoicing: Initial Findings OECD UNCITRAL Model Law on Electronic Transferable Records United Nations Commission on International Trade Law Electronic Signatures and Infrastructures (ESI); Electronic Registered Delivery Services; Part 1: Framework and Architecture ETSI Electronic Signatures and Infrastructures (ESI); Trusted Lists ETSI n.d. Electronic Signatures and Infrastructures (ESI); XAdES digital signatures; Part 1: Building blocks and XAdES baseline signatures ETSI Electronic Signatures and Infrastructures (ESI); CAdES digital signatures; Part 1: Building blocks and CAdES baseline signatures ETSI n.d. Electronic Signatures and Trust Infrastructures (ESI); JAdES digital signatures; Part 1: Building blocks and JAdES baseline signatures ETSI Verifiable Credentials Data Model v2.0 W3C FIDES Innovation Track: Direct e-invoicing - Phase 3: Key findings, recommendations & proposed next steps UN Verifiable Trade Documents (UNVTD) UN/CEFACT UN Transparency Protocol (UNTP) UN/CEFACT Exchange Header Envelope (XHE) Version 1.0 OASIS Peppol Service Metadata Publishing (SMP), version 1.4.0 OpenPeppol AISBL Peppol AS4 Profile, version 2.0.3 OpenPeppol AISBL Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail (REM) Services; Part 1: Framework and architecture 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 Electronic Signatures and Trust Infrastructures (ESI); Procedures for Creation and Validation of AdES Digital Signatures; Part 1: Creation and Validation ETSI UNCITRAL Model Law on Electronic Signatures United Nations Commission on International Trade Law UNCITRAL Model Law on the Use and Cross-border Recognition of Identity Management and Trust Services United Nations Commission on International Trade Law Financial services - Legal entity identifier (LEI) - Part 3: Verifiable LEIs (vLEIs) ISO Web Content Accessibility Guidelines (WCAG) 2.2 W3C verifiable Legal Entity Identifier (vLEI) Global Legal Entity Identifier Foundation n.d. VIES VAT number validation European Commission n.d. tlog-checkpoint: Transparency Log Checkpoints, version 1.1.0 C2SP n.d. tlog-witness: Transparency Log Witness Protocol, version 1.1.0 C2SP n.d. Council Directive 2006/112/EC of 28 November 2006 on the common system of value added tax 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 Council of the European Union Regulation (EU) 2024/1183 amending Regulation (EU) No 910/2014 as regards establishing the European Digital Identity Framework European Parliament and Council of the European Union Proposal for a Regulation on the establishment of European Business Wallets, COM(2025) 838 final, 2025/0358(COD) European Commission Regulation (EU) 2016/679 (General Data Protection Regulation) European Parliament and Council of the European Union Guidelines 02/2025 on processing of personal data through blockchain technologies, version 2.0 European Data Protection Board IANA IPv4 and IPv6 Special-Purpose Address Registries IANA n.d. Internet Crime Report 2024 Federal Bureau of Investigation, Internet Crime Complaint Center ASC X12 Standards Accredited Standards Committee X12 n.d. Electronic data interchange for administration, commerce and transport (EDIFACT) - Application level syntax rules ISO n.d. Unicode Bidirectional Algorithm The Unicode Consortium n.d. Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS) The purpose of this document is to define a new, straightforward Dynamic Delegation Discovery Service (DDDS) application to allow mapping of domain names to URIs for particular application services and protocols. Although defined as a new DDDS application, dubbed U-NAPTR, this is effectively an extension of the Straightforward NAPTR (S-NAPTR) DDDS Application. [STANDARDS-TRACK] MIME-based Secure Peer-to-Peer Business Data Interchange over the Internet This document describes how to exchange structured business data securely using SMTP transport for Electronic Data Interchange, (EDI - either the American Standards Committee X12 or UN/EDIFACT, Electronic Data Interchange for Administration, Commerce and Transport), XML or other data used for business to business data interchange. The data is packaged using standard MIME content-types. Authentication and privacy are obtained by using Cryptographic Message Syntax (S/MIME) or OpenPGP security body parts. Authenticated acknowledgements make use of multipart/signed replies to the original SMTP message. MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2) This document provides an applicability statement (RFC 2026, Section 3.2) that describes how to exchange structured business data securely using the HTTP transfer protocol, instead of SMTP; the applicability statement for SMTP is found in RFC 3335. Structured business data may be XML; Electronic Data Interchange (EDI) in either the American National Standards Committee (ANSI) X12 format or the UN Electronic Data Interchange for Administration, Commerce, and Transport (UN/EDIFACT) format; or other structured data formats. The data is packaged using standard MIME structures. Authentication and data confidentiality are obtained by using Cryptographic Message Syntax with S/MIME security body parts. Authenticated acknowledgements make use of multipart/signed Message Disposition Notification (MDN) responses to the original HTTP message. This applicability statement is informally referred to as "AS2" because it is the second applicability statement, produced after "AS1", RFC 3335. [STANDARDS-TRACK] FTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet This Applicability Statement (AS) describes how to exchange structured business data securely using the File Transfer Protocol (FTP) for XML, Binary, Electronic Data Interchange (EDI - ANSI X12 or UN/EDIFACT), or other data used for business-to-business data interchange for which MIME packaging can be accomplished using standard MIME content types. Authentication and data confidentiality are obtained by using Cryptographic Message Syntax (S/MIME) security body parts. Authenticated acknowledgements employ multipart/signed replies to the original message. This memo provides information for the Internet community. Handling Long Lines in Content of Internet-Drafts and RFCs This document defines two strategies for handling long lines in width-bounded text content. One strategy, called the "single backslash" strategy, is based on the historical use of a single backslash ('\') character to indicate where line-folding has occurred, with the continuation occurring with the first character that is not a space character (' ') on the next line. The second strategy, called the "double backslash" strategy, extends the first strategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy. Both strategies use a self-describing header enabling automated reconstitution of the original content. Reserved Top Level DNS Names To reduce the likelihood of conflict and confusion, a few top level domain names are reserved for use in private testing, as examples in documentation, and the like. In addition, a few second level domain names reserved for use as examples are documented. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. SMTP MTA Strict Transport Security (MTA-STS) SMTP MTA Strict Transport Security (MTA-STS) is a mechanism enabling mail service providers (SPs) to declare their ability to receive Transport Layer Security (TLS) secure SMTP connections and to specify whether sending SMTP servers should refuse to deliver to MX hosts that do not offer TLS with a trusted server certificate. DNS Certification Authority Authorization (CAA) Resource Record The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain name. CAA Resource Records allow a public CA to implement additional controls to reduce the risk of unintended certificate mis-issue. This document defines the syntax of the CAA record and rules for processing CAA records by CAs. This document obsoletes RFC 6844. MIME Encapsulation of EDI Objects Since there are many different EDI specifications, the current document defines three distinct categories as three different MIME content-types. [STANDARDS-TRACK] Building Protocols with HTTP Applications often use HTTP as a substrate to create HTTP-based APIs. This document specifies best practices for writing specifications that use HTTP to define new application protocols. It is written primarily to guide IETF efforts to define application protocols using HTTP for deployment on the Internet but might be applicable in other situations. This document obsoletes RFC 3205. URI Design and Ownership Section 1.1.1 of RFC 3986 defines URI syntax as "a federated and extensible naming system wherein each scheme's specification may further restrict the syntax and semantics of identifiers using that scheme." In other words, the structure of a URI is defined by its scheme. While it is common for schemes to further delegate their substructure to the URI's owner, publishing independent standards that mandate particular forms of substructure in URIs is often problematic. This document provides guidance on the specification of URI substructure in standards. This document obsoletes RFC 7320 and updates RFC 3986. Domain Control Validation using DNS Brave Software Salesforce Aiven Akamai Technologies Cox Communications Many application services on the Internet need to verify ownership or control of a domain in the Domain Name System (DNS). The general term for this process is "Domain Control Validation", and it can be done using a variety of methods such as email, HTTP/HTTPS, or the DNS itself. This document focuses only on DNS-based methods, which typically involve the Application Service Provider requesting a DNS record with a specific format and content to be visible in the domain to be verified. There is wide variation in the details of these methods today. This document provides some best practices to avoid known problems. ML-DSA for JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) This document specifies JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for the Module-Lattice-Based Digital Signature Standard (ML-DSA), a Post-Quantum Cryptography (PQC) digital signature scheme defined in US NIST FIPS 204. GOST R 34.10-2012: Digital Signature Algorithm This document provides information about the Russian Federal standard for digital signatures (GOST R 34.10-2012), which is one of the Russian cryptographic standard algorithms (called GOST algorithms). Recently, Russian cryptography is being used in Internet applications, and this document provides information for developers and users of GOST R 34.10-2012 regarding digital signature generation and verification. This document updates RFC 5832. Key Transparency Architecture This document defines the terminology and interaction patterns involved in the deployment of Key Transparency in a general secure group messaging infrastructure, and specifies the security properties that the protocol provides. It also gives more general, non- prescriptive guidance on how to securely apply Key Transparency to a number of common applications. Procedures for Maintaining the Time Zone Database Time zone information serves as a basic protocol element in protocols, such as the calendaring suite and DHCP. The Time Zone (TZ) Database specifies the indices used in various protocols, as well as their semantic meanings, for all localities throughout the world. This database has been meticulously maintained and distributed free of charge by a group of volunteers, coordinated by a single volunteer who is now planning to retire. This memo specifies procedures involved with maintenance of the TZ database and associated code, including how to submit proposed updates, how decisions for inclusion of those updates are made, and the selection of a designated expert by and for the time zone community. The intent of this memo is, to the extent possible, to document existing practice and provide a means to ease succession of the database maintainers. This memo documents an Internet Best Current Practice. ShangMi (SM) Cipher Suites for TLS 1.3 This document specifies how to use the ShangMi (SM) cryptographic algorithms with Transport Layer Security (TLS) protocol version 1.3. The use of these algorithms with TLS 1.3 is not endorsed by the IETF. The SM algorithms are becoming mandatory in China, so this document provides a description of how to use the SM algorithms with TLS 1.3 and specifies a profile of TLS 1.3 so that implementers can produce interworking implementations. GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.3 The purpose of this document is to make the Russian cryptographic standards available to the Internet community for their implementation in the Transport Layer Security (TLS) Protocol Version 1.3. This document defines the cipher suites, signature schemes, and key exchange mechanisms for using Russian cryptographic standards, called GOST algorithms, with TLS Version 1.3. Additionally, this document specifies a profile of TLS 1.3 with GOST algorithms to facilitate interoperable implementations. The IETF has not endorsed the cipher suites, signature schemes, or key exchange mechanisms described in this document. HTTP Message Signatures for automated traffic Cloudflare Google This document describes a protocol for identifying automated traffic using [HTTP-MESSAGE-SIGNATURES]. The goal is to allow automated HTTP clients to cryptographically sign outbound requests, allowing HTTP servers to verify their identity with confidence. It defines the Signature-Agent header field for in-band key discovery, a key directory format based on JWKS, and a well-known URI at which that directory is served. The OAuth 2.0 Authorization Framework The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] OAuth 2.0 Demonstrating Proof of Possession (DPoP) This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens This document describes OAuth client authentication and certificate-bound access and refresh tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual-TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. Best Current Practice for OAuth 2.0 Security This document describes best current security practice for OAuth 2.0. It updates and extends the threat model and security advice given in RFCs 6749, 6750, and 6819 to incorporate practical experiences gathered since OAuth 2.0 was published and covers new threats relevant due to the broader application of OAuth 2.0. Further, it deprecates some modes of operation that are deemed less secure or even insecure. Using RSA Algorithms with CBOR Object Signing and Encryption (COSE) Messages The CBOR Object Signing and Encryption (COSE) specification defines cryptographic message encodings using Concise Binary Object Representation (CBOR). This specification defines algorithm encodings and representations enabling RSA algorithms to be used for COSE messages. Encodings are specified for the use of RSA Probabilistic Signature Scheme (RSASSA-PSS) signatures, RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) encryption, and RSA keys. Supply Chain Integrity, Transparency, and Trust (SCITT) Reference APIs Fraunhofer SIT Bowball Technologies Ltd Microsoft Research This document specifies a REST API with the HTTP resources, request and response messages, and error handling needed for an interoperable implementation of a SCITT Transparency Service, as defined by the Supply Chain Integrity, Transparency, and Trust (SCITT) Architecture. Evidence Record Syntax (ERS) In many scenarios, users must be able prove the existence and integrity of data, including digitally signed data, in a common and reproducible way over a long and possibly undetermined period of time. This document specifies the syntax and processing of an Evidence Record, a structure designed to support long-term non-repudiation of existence of data. [STANDARDS-TRACK] Guidelines for Considering Operations and Management in IETF Specifications Everything OPS & Arrcus Cisco Old Dog Consulting Nokia Blue Fern Consulting ZTE New Protocols and Protocol Extensions are best designed with due consideration of the functionality needed to operate and manage them. Retrofitting operations and management considerations is suboptimal. The purpose of this document is to provide guidance to authors and reviewers on what operational and management aspects should be addressed when writing documents in the IETF Stream that document a specification for New Protocols or Protocol Extensions or describe their use. This document obsoletes RFC 5706, replacing it completely and updating it with new operational and management techniques and mechanisms. It also updates RFC 2360 to obsolete mandatory MIB creation. Finally, it introduces a requirement to include an "Operational Considerations" section in new RFCs in the IETF Stream that define New Protocols or Protocol Extensions or describe their use (including relevant YANG Models), while providing an escape clause if no new considerations are identified. Improving Awareness of Running Code: The Implementation Status Section This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. Privacy Considerations for Internet Protocols This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content. Specification for DNS over Transport Layer Security (TLS) This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS. This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic. DNS Queries over HTTPS (DoH) This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange. Oblivious HTTP This document describes Oblivious HTTP, a protocol for forwarding encrypted HTTP messages. Oblivious HTTP allows a client to make multiple requests to an origin server without that server being able to link those requests to the client or to identify the requests as having come from the same client, while placing only limited trust in the nodes used to forward the messages. JSON Web Encryption (JWE) JSON Web Encryption (JWE) represents encrypted content using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries defined by that specification. Related digital signature and Message Authentication Code (MAC) capabilities are described in the separate JSON Web Signature (JWS) specification. IETF Policy on Character Sets and Languages This document is the current policies being applied by the Internet Engineering Steering Group (IESG) towards the standardization efforts in the Internet Engineering Task Force (IETF) in order to help Internet protocols fulfill these requirements. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Terminology Used in Internationalization in the IETF This document provides a list of terms used in the IETF when discussing internationalization. The purpose is to help frame discussions of internationalization in the various areas of the IETF and to help introduce the main concepts to IETF participants. This memo documents an Internet Best Current Practice. Design Choices When Expanding the DNS Internet Architecture Board This note discusses how to extend the DNS with new data for a new application. DNS extension discussions too often focus on reuse of the TXT Resource Record Type. This document lists different mechanisms to extend the DNS, and concludes that the use of a new DNS Resource Record Type is the best solution. This memo provides information for the Internet community. Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records) This document specifies the "SVCB" ("Service Binding") and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics"). By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 4.0. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 5751. DomainKeys Identified Mail (DKIM) Signatures DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay, or one of their agents. DKIM separates the question of the identity of the Signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature. This memo obsoletes RFC 4871 and RFC 5672. [STANDARDS-TRACK] Using Secure DNS to Associate Certificates with Domain Names for S/MIME This document describes how to use secure DNS to associate an S/MIME user's certificate with the intended domain name, similar to the way that DNS-Based Authentication of Named Entities (DANE), RFC 6698, does for TLS.

Mapping to EN 16931 and Peppol PINT This appendix is informative. Peppol PINT numbers its business terms as IBT-nnn with the same numbers as the BT-n terms of , so one table serves both. Other semantic models, such as national formats prescribed by tax authorities, ASC X12 810, and UN/EDIFACT INVOIC, map to the same members, and the profiles for the networks and jurisdictions that use them are expected to give those mappings. This table is included because EN 16931 business terms are numbered and publicly listed. It does not make EN 16931 the reference model for ITP. Business term mapping

Business term	Name	ITP
BT-1	Invoice number	invoice_number
BT-2	Invoice issue date	issue_date
BT-3	Invoice type code	type_code
BT-5	Invoice currency code	currency
BT-6	VAT accounting currency code	tax_currency
BT-7	Value added tax point date	tax_point_date
BT-10	Buyer reference	references.buyer_reference
BT-11	Project reference	references.project
BT-12	Contract reference	references.contract
BT-13	Purchase order reference	references.order
BT-15	Receiving advice reference	references.receiving_advice
BT-16	Despatch advice reference	references.despatch_advice
BT-23	Business process type	document.profile
BT-24	Specification identifier	document.customization
BG-3	Preceding invoice reference	correction.corrects
BG-14	Invoicing period	invoice_period
BG-23	VAT breakdown	tax_summary
BT-29, BT-46	Seller and buyer identifier	party_ids ("eas" when the scheme identifier is a Peppol EAS code)
BT-30, BT-47	Seller and buyer legal registration identifier	party_ids ("eas" when the scheme identifier is a Peppol EAS code)
BT-31, BT-48	Seller and buyer VAT identifier	seller, buyer ("tax" of the type whose registry entry lists the prefix, prefix removed; without a prefix, the jurisdiction is the country in BT-40 or BT-55)
BT-32	Seller tax registration identifier	seller, or party_ids.seller when BT-31 is present ("tax")
BT-63	Seller tax representative VAT identifier	not mapped
BT-34, BT-49	Seller and buyer electronic address	seller, buyer ("eas")
BT-112	Invoice total amount with VAT	total_with_tax
BT-115	Amount due for payment	amount_due
BG-24	Additional supporting documents	attachments

Payment terms (BT-9, BG-10, BT-83, BT-84, BT-113) are mapped in .

Initial Tax Identifier Types These are the initial entries of the ITP Tax Identifier Types registry. "Prefixes" are those that documents and validation services put before the identifier; they are removed in the PID. Formats summarize the authority's rules and are not a substitute for its check-digit algorithms. Entries whose identifier can be a personal identification number of a natural person are marked "P". Initial tax identifier types

Jurisdiction	Type	Prefixes	Identifier in the PID
AT	vat	AT	"U" and 8 digits
BE	vat	BE	10 digits
BG	vat	BG	9 or 10 digits (P)
CY	vat	CY	8 digits and a letter
CZ	vat	CZ	8 to 10 digits (P)
DE	vat	DE	9 digits
DK	vat	DK	8 digits
EE	vat	EE	9 digits
ES	vat	ES	9 characters (P)
FI	vat	FI	8 digits
FR	vat	FR	2 characters and 9 digits
GR	vat	EL	9 digits
HR	vat	HR	11 digits (P)
HU	vat	HU	8 digits
IE	vat	IE	8 or 9 characters (P)
IT	vat	IT	11 digits
LT	vat	LT	9 or 12 digits
LU	vat	LU	8 digits
LV	vat	LV	11 digits (P)
MT	vat	MT	8 digits
NL	vat	NL	9 digits, "B", and 2 digits
PL	vat	PL	10 digits
PT	vat	PT	9 digits (P)
RO	vat	RO	2 to 10 digits
SE	vat	SE	12 digits (P)
SI	vat	SI	8 digits
SK	vat	SK	10 digits
GB	vat	GB, XI	9 digits, 12 digits (the last 3 identify a branch of the same registration), or "GD" or "HA" and 3 digits; "XI" for Northern Ireland
CH	uid	none	"CHE" and 9 digits; the suffix MWST, TVA, or IVA is removed
NO	orgnr	NO	9 digits; the suffix MVA is removed
MX	rfc	none	12 characters, or 13 for natural persons (P)
BR	cnpj	none	14 characters; identifies an establishment, and the first 8 characters are the root of the legal entity
JP	qualified-invoice	none	"T" and 13 digits
IN	gstin	none	15 characters, one per state
AU	abn	none	11 digits
SA	vat	none	15 digits
AE	trn	none	15 digits
US	ein	none	9 digits
CA	bn	none	9 digits
CA	gst-hst	none	the "bn", "RT", and 4 digits
CA-QC	qst	none	10 digits, "TQ", and 4 digits
CO	nit	none	the NIT (9 digits for legal persons) and its check digit (P)
CL	rut	none	the number and its check digit, a digit or "K" (P)
PE	ruc	none	11 digits (P)
AR	cuit	none	11 digits (P)
CN	uscc	none	18 digits or uppercase letters
KR	brn	none	10 digits
VN	mst	none	10 digits, or for individuals and household businesses the 12-digit personal identification number (P)
VN	mst-unit	none	the "mst" of the parent and 3 digits
ID	npwp	none	16 digits (P)
ID	nitku	none	the "npwp" of the head office and 6 digits
SG	gst	none	the UEN (9 or 10 characters), or "M" and 9 characters
NZ	gst	none	9 digits (P)
TR	vkn	none	10 digits, or 11 digits for citizens who are natural persons (P)
IL	tin	none	9 digits (P)
EG	rin	none	9 digits
NG	tin	none	13 digits (P)
KE	pin	none	"A" (individuals) or "P" (others), 9 digits, and a letter (P)
ZA	vat	none	10 digits, the first of which is "4"
any EU member state	oss	none (prefix kept)	"EU" and 9 characters
any EU member state	ioss	none (prefix kept)	"IM" and 10 characters

For every entry: the issuing authority is the tax administration of the jurisdiction; the format and check-digit reference is that administration's published specification; the normalization is the default of plus the prefix and suffix rules in the table; "personal identifier" is "yes" for entries marked "P" and "no" otherwise; and the reference is this document. Some entries need more detail. "CN uscc" is the unified social credit code, which registration authorities assign to legal persons and other organizations; it replaced the codes that departments, including the tax administration, assigned separately. An "SG gst" number is either the UEN, which the agency that registered the entity assigns, or a number that IRAS assigns, for example to a GST group, whose members then share it. The "NZ gst" number is the IRD number; an IRD number of 8 digits is written with a leading "0". "NG tin" is the Tax ID that the Nigeria Revenue Service and the Joint Revenue Board issue jointly, which replaced earlier tax identification numbers from 1 January 2026. In DIAN's electronic invoice the NIT is written without its check digit, which is carried in a separate attribute; the "CO nit" PID includes the check digit. For natural persons, "CO nit", "CL rut", "PE ruc", "AR cuit", "TR vkn", "IL tin", "VN mst", and "ID npwp" are or contain a national identity number. "CA gst-hst", "VN mst-unit", and "ID nitku" are derived from the base identifiers "CA bn", "VN mst", and "ID npwp". The table has more entries for the member states of the European Union because their VAT identification numbers share one structure and one validation service, which made them easy to check. It sets no priority among jurisdictions, and entries for any jurisdiction are registered on the same terms (). The jurisdiction of a "tax" PID is the one whose register the identifier belongs to, written with its code: a Greek VAT number written "EL000000000" in a document is "tax:GR:vat:000000000". VAT numbers that the Isle of Man issues in the register of the United Kingdom use "GB", and those that Monaco issues in the register of France use "FR". For the member states of the European Union, the "vat" type is the VAT identification number assigned under Article 214 of Directive 2006/112/EC, written without its prefix. Whether the number is valid in at a given time is checked by a "tax-registration" attestation and does not change the PID. Where the national tax identifier has the same value as the VAT identification number without its prefix, as in Spain or Portugal, the "vat" type is used for both, so that one entity has one PID. National identifiers with another value, such as the German Steuernummer or the French SIREN, have types of their own. "XI" identifies traders in Northern Ireland for supplies of goods under the Windsor Framework, with the same number as "GB". "XI" numbers are validated by ; "GB" numbers are not. Both spellings map to the same PID, so the PID does not say which prefix a document requires; software that writes a document from a PID takes the prefix from the transaction, and a "tax-registration" attestation for a trader in Northern Ireland records the "XI" check in "check". Identification numbers of the special schemes of the European Union for distance sales are issued by the member state of identification, whose numeric code they contain: "EU" and 9 characters under the non-Union scheme and "IM" and 10 characters under the import scheme. They are "tax" PIDs with that member state as jurisdiction and the types "oss" and "ioss", with the prefix kept in the identifier, for example "tax:IE:ioss:IM3720000000". "EU" is not a jurisdiction code. The Union scheme uses the "vat" PID of the trader. does not validate these numbers.

Test Vectors These values were computed with the program listed in Implementation Status and can be reproduced from the inputs given. The first envelope core contains the required members, the members required for a fiscal document delivered through ITP and registered in a transparency service, and "type_code". It omits "issuer_participant_document" and "issue_tz", which recommends; a production envelope from an issuer in mainland Spain would carry "issue_tz" "Europe/Madrid".

Test Keys The issuer key is the Ed25519 key of Section 7.1 (TEST 1) of . The node key is TEST 2 of the same section.

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: The envelope digest (SHA-256 of the octets above, base64url) is:

Issuer Signature The JWS Protected Header, before base64url encoding, is: The encoded protected header and the signature are:

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: The signature base, signed with the node key, is: The resulting Signature field value is:

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

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 ; 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.

Negative Test Cases Implementations are expected to produce the following results. Each case starts from the first envelope of and changes one thing.

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 ().
The protected header of the issuer signature omits "crit". The signature is rejected, and the envelope is invalid.
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.
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.
The core contains the member "total_with_tax" twice. The envelope is rejected before any signature check.
The issuer signature has "itp_role" "issuer" but its key is listed in "delegates" of the Participant Document. The signature is rejected.
A Participant Document with a greater "seq" omits a key that the accepted document contained. The new document is rejected.
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.

Design Rationale

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.

Registered Media Types for Signed Objects Explicit typing prevents cross-object substitution . 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 , so that each value has a single owner and meaning.

TXT Record discourages overloading TXT records. ITP follows the precedent of MTA-STS : 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 was considered and not used, because no connection parameters need to be conveyed.

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.

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 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.

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 code of the jurisdiction that issued them; prefixes such as "EL" or "XI" are presentation details recorded in the registry.

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.

Why Not 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.

Why Not Signed Email Invoices sent by email can be signed with S/MIME , and DKIM 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 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 ().

Why Not Only an Existing Network Four-corner networks such as Peppol and the Digital Business Networks Alliance , 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 () and verifies them under the rules of their scheme. It adds discovery, the binding of keys to legal entities across jurisdictions, attested payment accounts (), and one verification procedure for invoices from different regimes.

Open Issues

Stream. The registrations in assume the IETF stream. On the Independent Submission stream, the URN sub-namespace and the standards-tree media types would have to change.
Mandatory syntax. This document requires receiving nodes to accept UBL 2.1 or later. Several regimes use other syntaxes, such as CFDI in Mexico, NF-e and NFS-e in Brazil, DTE in Chile, FatturaPA in Italy, the JSON schema INV-01 in India, and national XML schemas in China, South Korea, Taiwan, Viet Nam, and Indonesia, and invoicing between large trading partners in the United States relies mostly on ASC X12 810. Malaysia uses UBL 2.1 in XML or JSON, so whether the UBL requirement covers the JSON syntax of UBL is also open. Options are a second mandatory syntax, or a rule that a receiving node accepts the legal-original syntax of each registered profile for a jurisdiction in which its participant holds a "tax" PID. This document takes the second option as a SHOULD ().
Initial entries of the ITP Tax Identifier Types, Tax Schemes, and Bridge Schemes registries, which need input from the authorities concerned.
Alignment of "kyb" attestations with SD-JWT VC types, verifiable credentials , and the European Business Wallet .
Relationship with electronic transferable records for invoices that are traded as receivables.
Whether the transparency profile () should become a separate document for the SCITT working group.
Governance and funding of shared transparency services, witnesses, and monitors.
Event notifications to software that consumes a node, which this version leaves out.

Acknowledgments The author used AI-based tools while drafting and reviewing this document. The author checked all text, references, and test vectors and is responsible for the content.