Agent Decision Commitments for Payments

1.1. Scope

This document specifies the decision record, the context receipt, the commitment, the holder chain and anchoring, outcome and erasure entries, disclosure and verification, bindings, and the witnessed reciprocal exchange between parties. It does not specify how an agent decides, how content is selected for a model, how dispute participants are credentialed, or what consequence follows from a verification result.¶

1.2. Liability Neutrality

ADC produces evidence. It does not allocate liability among principals, holders, merchants, issuers, acquirers, networks, or model providers, and it does not define the consequence of a missing, withheld, or failed record. Those consequences are matters for the applicable scheme rules, contracts, and law. Verifiers report the attestation level and step results defined in Section 6.5, not a verdict.¶

1.3. What ADC Does Not Establish

ADC establishes the integrity and timing of evidence, not its truth. It does not establish that recorded inputs were authentic or accurate, that the model's answer was correct, that the action reflected the principal's intent beyond what the mandate states, which item caused an outcome, that the context receipt is complete, or that the holder recorded honestly at decision time. ADC imports no facts about the world and therefore relies on no external oracle; facts enter only as recorded content whose stated origin a verifier can assess. Every verification step is a finite computation over released data (hash recomputation, signature verification, and comparison) and terminates. ADC does not evaluate properties of the agent's program or behavior.¶

1.4. Requirements Language

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

5.1. Conventions

• All objects are JSON [RFC8259]. Before hashing, every string member name and value MUST be normalized to NFC [UAX15], and the object MUST be serialized with JCS [RFC8785]. The result is denoted CANON(object).¶
• Digests are SHA-256 [SHS] unless the object's "alg" member states otherwise, and are encoded as base64url without padding [RFC4648]. DIGEST(x) denotes BASE64URL(SHA-256(x)), where x is CANON(x) when x is a JSON value and the octets themselves otherwise. Verifiers MUST reject objects whose "alg" value they do not support.¶
• Every salt defined by this document is exactly 32 octets from a cryptographically secure random number generator, fresh for each use. (SD-JWT disclosure salts are governed by [RFC9901].) The fixed length makes the concatenation salt || CANON(object) unambiguous.¶
• Timestamps are strings in the format of [RFC3339] with a "Z" offset.¶
• Each top-level object (receipt, record, statement payload, release) carries "type" and "v"; the decision context claim carries "v"; nested objects carry neither. This document defines version 1. A verifier that does not support a version MUST report the object as unsupported.¶
• Unknown members MUST be included when an object is canonicalized and hashed, and MUST be ignored when interpreting it. An object that contains duplicate member names, before or after NFC normalization, MUST be rejected.¶
• Amounts are strings containing a non-negative decimal integer in the smallest unit of the asset on the rail (minor units for fiat currencies, base units for tokens), so that large values survive JCS.¶
• Numbers are canonicalized by JCS, which can change their textual form. Where the exact bytes returned by a model provider matter, they are recorded as a context item with role "response" (Section 5.2).¶

5.2. Context Items and the Context Receipt

For each context item i, in the order in which items were provided to the model, the holder constructs an item descriptor D_i and a fresh salt s_i, and computes the item digest:¶

   item_digest_i = BASE64URL(SHA-256(s_i || CANON(D_i)))

An item descriptor has the following members:¶

content_digest (REQUIRED):

BASE64URL(SHA-256(item bytes)).¶

media_type (REQUIRED):

The media type of the item bytes.¶

role (REQUIRED):

One of "instructions", "tool_definition", "prior_turn", "as_sent", "original", "request", "response", "exchange", "witness", or an extension value in the form of a URI. Role "request" denotes the complete request body as sent to the provider. Roles "exchange" and "witness" denote an exchange object body and a witness statement (Section 8.6).¶

calls (REQUIRED):

The array of zero-based indexes, into the record's "models" array, of the model calls to which the item was input or, for role "response", from which it was returned; empty for an item with role "original".¶

derived_from (OPTIONAL):

The zero-based index of the item from which this item was derived.¶

transform (OPTIONAL):

A string identifying the transformation and the implementation and version that performed it.¶

source (REQUIRED):

An object with "kind" and, where applicable, "uri" and "fetched_at".¶

The holder MUST list every input to every model call covered by the decision, including instructions, tool definitions, prior turns, retrieved content, and media, and MUST include the raw provider response for each call with role "response". Where the agent transformed an item, the item as provided to the model has role "as_sent" and a "derived_from" member giving the index of its source item. The source item SHOULD also be listed; it has role "original" if it was not itself provided to the model, and role "as_sent" otherwise. Agents SHOULD perform media transformations themselves and stay within provider limits, so that the bytes recorded are the bytes the model received.¶

The context receipt is:¶

type, v, alg (REQUIRED):

"adc-receipt", 1, and the digest algorithm.¶

items (REQUIRED):

The non-empty array of item digests, in model-input order.¶

item_count (REQUIRED):

The number of items, at least 1.¶

retention_until (REQUIRED):

The time until which the holder commits to retain the descriptors, salts, and items (Section 12).¶

selector (OPTIONAL):

An object naming the component that selected the items and a digest of its configuration.¶

receipt_digest = BASE64URL(SHA-256(CANON(receipt))). Because each descriptor is hidden behind its own salt, the receipt reveals neither the content digests nor the origins of the items, and a descriptor and its salt can later be deleted without changing receipt_digest (Section 5.6).¶

5.3. Decision Record

type, v, alg (REQUIRED):

"adc-record", 1, and the digest algorithm.¶

chain (REQUIRED):

An object with "id", an opaque identifier of the holder chain that is independent of any signing key; "seq", this record's sequence number in the chain; and "prev", the commitment of the record with sequence number seq - 1, or 32 zero octets encoded in base64url for the first record of a chain (Section 5.5).¶

receipt_digest (REQUIRED):

As defined in Section 5.2.¶

question (REQUIRED):

An object with "name", "kind" (for example "choice", "score", "probability", or "freeform"), and "schema_digest", DIGEST of the question definition (a JSON object).¶

profile (OPTIONAL):

The URI of the profile under which the record was made.¶

models (REQUIRED):

An array with one entry per model call, each with "provider", "id" (a resolved model version, not an alias), "request_id", "request_digest" (DIGEST of the request body as sent to the provider), and optionally "params_digest" (digest of the decoding parameters, if the interface exposes them) and "attestation", a provider-issued attestation over the request and response, for example an Attested Inference Receipt [I-D.tsyrulnikov-rats-attested-inference-receipt], encoded as the base64url encoding of the attestation token (Section 6.5).¶

answer (REQUIRED):

The model output, as a JSON object.¶

action (REQUIRED):

An object with "taken", the action decided: "pay", "decline", or an extension value in the form of a URI. It MUST NOT reference the mandate, which does not yet exist when the record is committed.¶

transaction (REQUIRED when the action initiates a payment):

An object with "rail", "payee", "amount", "currency", and, where the rail defines one, "checkout_digest", each encoded and compared as defined for the rail in Section 7. "currency" is an ISO 4217 [ISO4217] code for fiat currencies and a CAIP-19 asset identifier [CAIP19] for tokens.¶

issued_at (REQUIRED):

The time the record was completed.¶

One decision record MUST correspond to at most one transaction. Outcomes and erasures are not part of the record; they are separate entries (Section 5.6).¶

5.4. Commitment and Decision Context Claim

   C = BASE64URL(SHA-256(salt || CANON(record)))

The decision context claim is:¶

{"v":1,"alg":"sha-256","commitment":"<C>","receipt_uri":"<uri>",
 "profile":"<uri>"}

"receipt_uri" is an https URI at which disclosure requests for this record are made; its path is an opaque value chosen by the holder. It MUST NOT embed content, digests, or identifiers that link the principal across transactions. "profile" (OPTIONAL) identifies the profile; if it is absent, the verifier obtains the applicable profile out of band, and without one reports no level above A1. Rails that cannot carry the claim object carry only C, as defined in Section 7. In JWT-based mandates, the claim is carried as an ordinary SD-JWT disclosure [RFC9901]: it is not canonicalized, its member order is whatever the issuer serialized, and its digest is computed over the base64url-encoded disclosure string as RFC 9901 specifies. Verifiers MUST use the received disclosure string and MUST NOT re-serialize the claim. On rails that are not JWT-based, the claim is carried as a plain JSON object or reduced to C, as defined in Section 7. The commitment salt is distinct from any SD-JWT disclosure salt and is released only under Section 6.¶

5.5. Holder Chain and Anchoring

The holder MUST create a decision record for every covered decision, including decisions whose action is "decline", and MUST assign consecutive sequence numbers per chain. The "prev" member links each record to its predecessor, so that a missing record appears as a gap. Hash chains are common in audit-log designs (Section 9); the chain here is kept per chain id, independent of signing keys, and covers declined decisions, so that a verifier can detect a withheld decision, not only a withheld payment.¶

A chain is not tied to a signing key. The key that signs a chain's first anchor is the chain's initial key. To rotate, the holder registers a rotation statement of type "adc-rotation", signed with the current key, that names the chain and the successor key; statements signed with the successor key then continue the same chain id and sequence. Verifiers MUST consider only statements whose signing key is the chain's initial key or a successor established by such rotation statements; statements by any other issuer that use the same "sub" are ignored. The holder MUST NOT start a new chain to replace an existing one except under the profile's rules, and a new chain's first anchor MUST be reported to verifiers on request. A deletion at the tail of a chain, after the last anchor a verifier sees, is not detectable by the chain alone.¶

Unless the profile permits late registration, the holder MUST register an anchor statement with at least one transparency service [RFC9943] before the mandate or payment payload that carries the claim is signed. The anchor is a Signed Statement as defined in [RFC9943]: a COSE_Sign1 message [RFC9052] whose protected header carries a "kid" identifying the signing key (unless "x5t" or "x5chain" is present) and CWT claims [RFC8392] with "iss" identifying the holder and "sub" set to the chain id, and whose payload, of content type application/adc-anchor+json, is:¶

{"type":"adc-anchor","v":1,"commitment":"<C>","chain":"<id>",
 "seq":<n>,"prev":"<C(n-1)>","issued_at":"<time>"}

The holder MUST retain the transparency receipt. Level A2 requires that the registration time can be established from the receipt or from the transparency service under the profile; [RFC9943] does not itself require receipts to carry a registration time. Profiles MAY require registration with two transparency services operated by different organizations, SHOULD prefer services that provide consistency proofs, and MAY set the maximum interval between issued_at and registration (300 seconds if unspecified). Where the profile permits late registration, a holder that cannot reach a transparency service registers as soon as it can, and the anchor is reported as late (Section 6.5). Outcome, erasure, and rotation statements (Section 5.6) use the same envelope and "sub" but carry no sequence number. A batch format for anchors is out of scope.¶

Failure handling:¶

• Before registering an anchor, the holder MUST durably store the record, the salts, the items, and the sequence number it consumes. A sequence number MUST NOT be reused, including after recovery from backup; the holder MUST determine the highest sequence number already anchored before resuming a chain.¶
• If registration times out, the holder retries with the identical signed statement bytes. Verifiers treat byte-identical statements as one. Re-signing a statement for the same chain and seq produces different bytes and is reported as equivocation.¶
• If the agent does not complete an anchored action whose "taken" is "pay", for example because the process failed before the mandate was signed, the holder MUST register an outcome statement with status "abandoned".¶
• A chain is a total order. A holder that makes concurrent decisions SHOULD operate several chains; each covered decision belongs to exactly one chain.¶
• Holders keep issued_at on a synchronized clock. Verifiers allow the clock tolerance set by the profile (60 seconds if unspecified) when comparing issued_at, registration times, and mandate issuance times.¶

5.6. Outcome and Erasure Entries

After the decision, the holder can register further signed statements that reference the commitment:¶

• "adc-outcome" (OPTIONAL), with "status" (for example "settled", "disputed", "refunded", "reversed", or "abandoned"; see Section 5.5) and, when known, "reference_digest", a digest of the mandate or payment identifier. Rails and settlement-record formats may already carry this information; profiles decide whether outcome entries are used.¶
• "adc-erasure", which the holder MUST register when it deletes evidence before retention_until, listing in "items" the zero-based indexes of items whose descriptors, salts, and content were deleted, in "erased_at" the time of deletion, and in "reason" one of "principal_request", "legal_obligation", "lost", or an extension value in the form of a URI. Loss of evidence before retention_until is registered with reason "lost". Deleting a descriptor and its salt leaves receipt_digest and the commitment valid and makes the item digest unlinkable to the content, without the per-record key management of cryptographic erasure. An erasure entry records that evidence is no longer available; this document attaches no consequence to it (Section 1.2).¶

5.7. CDDL

The following CDDL [RFC8610] describes the objects. JSON encodings apply; "digest" is a base64url string, "timestamp" is an RFC 3339 string, and salts, content, nonce_random, and statements are base64url strings. Each entry of "statements" is a Transparent Statement [RFC9943]: an anchor, entry, or rotation statement with its transparency receipts. The exchange objects of Section 8 are described by adc-exchange, adc-witness, and exchange-receipt.¶

adc-receipt = {
  type: "adc-receipt", v: 1, alg: hash-alg,
  items: [+ digest], item_count: uint .ge 1,
  retention_until: timestamp,
  ? selector: { name: tstr, version: tstr, ? config_digest: digest },
  * tstr => any
}
item-descriptor = {
  content_digest: digest, media_type: tstr, role: item-role,
  calls: [* uint], ? derived_from: uint, ? transform: tstr,
  source: { kind: tstr, ? "uri": tstr, ? fetched_at: timestamp,
            * tstr => any },
  * tstr => any
}
item-role = "instructions" / "tool_definition" / "prior_turn" /
            "as_sent" / "original" / "request" / "response" /
            "exchange" / "witness" / tstr
adc-record = {
  type: "adc-record", v: 1, alg: hash-alg,
  chain: { id: tstr, seq: uint, prev: digest, * tstr => any },
  ? profile: tstr,
  receipt_digest: digest,
  question: { name: tstr, kind: tstr, schema_digest: digest,
              * tstr => any },
  models: [+ model-call],
  answer: { * tstr => any },
  action: { taken: tstr, * tstr => any },
  ? transaction: transaction,
  issued_at: timestamp,
  * tstr => any
}
model-call = {
  provider: tstr, id: tstr, request_id: tstr, request_digest: digest,
  ? params_digest: digest, ? attestation: tstr,
  * tstr => any
}
transaction = {
  rail: "vi" / "ap2" / "x402" / "iso20022" / tstr,
  payee: tstr, amount: tstr, currency: tstr,
  ? checkout_digest: digest,
  * tstr => any
}
decision-context-claim = {
  v: 1, alg: hash-alg, commitment: digest, receipt_uri: tstr,
  ? profile: tstr,
  * tstr => any
}
adc-anchor = {
  type: "adc-anchor", v: 1, commitment: digest, chain: tstr,
  seq: uint, prev: digest, issued_at: timestamp,
  * tstr => any
}
adc-outcome = {
  type: "adc-outcome", v: 1, commitment: digest, status: tstr,
  ? reference_digest: digest, issued_at: timestamp,
  * tstr => any
}
adc-erasure = {
  type: "adc-erasure", v: 1, commitment: digest,
  items: [+ uint], erased_at: timestamp,
  reason: "principal_request" / "legal_obligation" / "lost" / tstr,
  * tstr => any
}
adc-rotation = {
  type: "adc-rotation", v: 1, chain: tstr, successor_kid: tstr,
  issued_at: timestamp,
  * tstr => any
}
adc-request = {
  type: "adc-request", v: 1, request_id: tstr, verifier: tstr,
  presentation_digest: digest, issued_at: timestamp,
  * tstr => any
}
adc-release = {
  type: "adc-release", v: 1, request_id: tstr, verifier: tstr,
  issued_at: timestamp, record: adc-record,
  commitment_salt: tstr, receipt: adc-receipt,
  statements: [* tstr],
  items: [+ released-item / withheld-item],
  ? nonce_random: tstr,
  * tstr => any
}
released-item = { index: uint, salt: tstr,
                  descriptor: item-descriptor, content: tstr }
withheld-item = { index: uint, status: "withheld" / "erased",
                  ? erasure_reference: tstr }
adc-error = {
  type: "adc-error", v: 1, ? request_id: tstr,
  code: "invalid_request" / "invalid_credential" /
        "replayed_request" / "not_found" / "policy_denied" /
        "too_large" / "temporarily_unavailable" / tstr,
  ? retry_after: uint, ? description: tstr,
  * tstr => any
}
adc-report = {
  type: "adc-report", v: 1, verifier: tstr, verified_at: timestamp,
  ? profile: tstr, level: "A0" / "A1" / "A2" / "A3" / "none",
  signer: "agent" / "principal" / "payer" / "none",
  steps: [8*8 step-result],
  inputs: { presentation: digest, release: digest,
            statements: [* digest], attestations: [* digest],
            trust_anchors: [* digest], revocation: [* digest] },
  ? late_anchor_seconds: uint, ? equivocation: bool,
  * tstr => any
}
adc-exchange = {
  exchange-common, exchange-step,
  * tstr => any
}
exchange-common = (
  type: "adc-exchange", v: 1, exchange_id: tstr, seq: uint,
  prev: digest, issued_at: timestamp
)
exchange-step = (
  x-offer // x-held // x-key-release // x-key-received //
  x-received // x-mismatch // x-answer // x-arbiter-delivery //
  x-non-ack // x-close
)
x-offer = (
  step: "offer", intent: "deliver" / "offer",
  sender_key: tstr, recipient_key: tstr,
  payload_commitment: digest, aead: tstr,
  ciphertext_hash: digest, key_hash: digest,
  ? escrow: adc-escrow, response_window: uint,
  expires_at: timestamp
)
x-held = (step: "held", envelope_hash: digest,
          ? arbiters_accepted: digest)
x-key-release = (
  step: "key_release",
  hpke: { kem_id: uint, kdf_id: uint, aead_id: uint },
  wrapped_key: tstr
)
x-key-received = (step: "key_received", key_release_hash: digest)
x-received = (step: "received", envelope_hash: digest)
x-mismatch = (
  step: "mismatch", envelope_hash: digest,
  check: "ciphertext_hash" / "unwrap" / "key_hash" / "decrypt" /
         "payload_commitment"
)
x-answer = (step: "accepted" / "refused", envelope_hash: digest)
x-arbiter-delivery = (
  step: "arbiter_delivery", envelope_hash: digest,
  key_matched: bool, commitment_matched: bool,
  ? delivered_at: timestamp
)
x-non-ack = (
  step: "non_ack", envelope_hash: digest, awaited: tstr,
  attempts: [* delivery-attempt]
)
x-close = (step: "close", state: exchange-state, reason: tstr)
delivery-attempt = {
  transport_digest: digest, witnesses: [+ witness-statement],
  * tstr => any
}
adc-escrow = {
  scheme: tstr, arbiters: [3* tstr], threshold: uint .ge 2,
  shares: [3* tstr], proof: tstr,
  * tstr => any
}
exchange-state = "NOT_ACKNOWLEDGED" / "VOID" /
                 "KEY_UNACKNOWLEDGED" / "DELIVERED_VIA_ARBITER" /
                 "CONTENT_UNACKNOWLEDGED" / "DELIVERED" /
                 "ACCEPTED" / "REFUSED" / "NOT_ACCEPTED" /
                 "FAULT_SENDER" / "FAULT_RECIPIENT" / "CLOSED"
exchange-receipt = {
  object: tstr / { payload: tstr, signatures: [+ any] },
  witnesses: [+ witness-statement],
  * tstr => any
}
witness-statement = {
  format: "rfc3161" / "scitt" / tstr, token: tstr,
  * tstr => any
}
adc-witness = {
  type: "adc-witness", v: 1, object_hash: digest,
  * tstr => any
}
step-result = ("pass" / "fail" / "not_applicable" /
               "not_checked" / "unsupported")
hash-alg = "sha-256" / tstr
digest = tstr
timestamp = tstr

6.1. Disclosure Request

A verifier sends the holder, at "receipt_uri", the mandate presentation that carries the claim and a credential issued by the party administering the dispute. The credential types, their trust anchors, and the request transport are defined by the profile; this document defines the properties they need. The credential MUST be audience-restricted to the holder, sender-constrained (for example with DPoP [RFC9449]), short-lived, and bound to the transaction, for example by including the "sd_hash" of the presentation, so that a holder or an attacker controlling "receipt_uri" cannot replay it elsewhere. The verifier MUST dereference only https URIs, MUST apply request-forgery protections to "receipt_uri" (for example refusing private and link-local addresses and redirects to other hosts), and MUST NOT dereference "source.uri" values found in released descriptors. The holder MUST authenticate the credential, MUST log the request, and MUST limit release to the records bound to the transaction in the request.¶

The request is an object of type "adc-request" (Section 5.7) carrying "request_id", at least 16 octets from a cryptographically secure random number generator encoded in base64url; "verifier", an identifier of the verifier; "presentation_digest", the digest of the mandate presentation; and "issued_at". The holder MUST reject a request whose request_id it has already accepted within the lifetime of the credential, and a request whose issued_at lies outside the profile's tolerance (60 seconds if unspecified).¶

6.2. Release

Release is governed by an authorization policy that the principal sets in advance. When the policy permits, the holder returns a release object of type "adc-release" (Section 5.7) containing the decision record, the commitment salt, the context receipt, the anchor statement and any rotation statements needed to authorize its key, each with its transparency receipts, and, for each item, either the descriptor, its salt, and the item bytes, or a statement that the item is withheld or was erased (with a reference to the erasure entry). The release echoes the request's "request_id" and "verifier" and carries its own "issued_at", so that it cannot be presented as the answer to a different request. For the x402 binding, the release also includes "nonce_random" (Section 7.3). The holder MUST sign the release as a JWS [RFC7515] with a key that the profile associates with the holder, so that what was released, and what was withheld, is attributable. Withheld items remain listed by digest, so the omission is visible. Because the holder is typically the party whose conduct is in question, profiles MAY require the holder to deposit an encrypted copy of the release material with the principal or a custodian at decision time.¶

6.3. Transfer Confidentiality

A release contains personal data and the salts that protect it. It MUST be transferred over TLS 1.3 [RFC8446] or later, following [RFC9325], with the holder authenticated for the host named in "receipt_uri" and the verifier's credential presented within that session. If any party other than the holder and the verifier relays, queues, or stores the release, the release SHOULD additionally be encrypted to the verifier as a JWE [RFC7516]; HPKE-based JWE [I-D.ietf-jose-hpke-encrypt] and post-quantum or hybrid key encapsulation [I-D.ietf-hpke-pq] are suitable as they become available. Salts MUST NOT be sent in any message that is not confidentiality-protected. A verifier MUST NOT retain released content beyond the dispute and any retention obligation that applies to it.¶

6.4. Verification Procedure

1. Verify the mandate or payload according to its own specification and extract the decision context claim.¶
2. Verify the holder's signature on the release. Recompute C from the record and salt; it MUST equal the claim's commitment.¶
3. Check that record.transaction matches the transaction in the mandate or payload, field by field, using the mapping and comparison rules for the rail (Section 7). For x402, check that the signed nonce equals SHA-256(BASE64URL-DECODE(C) || nonce_random); if "nonce_random" is not released, the x402 binding is level A0.¶
4. Recompute receipt_digest; it MUST equal record.receipt_digest, and item_count MUST equal the length of items.¶
5. For each released item, recompute its item digest from descriptor and salt and check that it appears at the stated index, then check content_digest against the bytes. For derived items, the verifier MAY re-apply the transformation; a mismatch is reported, and its significance depends on whether the transformation is deterministic.¶
6. Verify each transparency receipt against trust anchors for the transparency service defined by the profile, and check that every receipt covers the same anchor statement. Check that the anchored commitment, chain, seq, and prev match the record, that the registration time is not more than the profile's interval after issued_at, and that it is not later than the issuance time of the mandate or payload (for example its "iat") where the rail provides one. Only statements signed by keys authorized for the chain (Section 5.5) are considered. The verifier MAY request from the holder the anchors for neighboring sequence numbers; [RFC9943] defines no query interface for this, so the means are set by the profile. Two different anchor statements for the same chain and seq MUST be reported as equivocation.¶
7. For each model call with an attestation, verify the attestation and check that it binds the call's request_digest and the content_digest of the call's "response" item. If an item with role "request" is released for the call, check that its content_digest equals the call's request_digest.¶
8. Report the attestation level and the result of each step.¶

6.5. Attestation Levels

A late or missing anchor caps the level at A1, and the verifier reports the delay; a timely anchor for an A0 commitment is reported alongside A0. No level asserts that the receipt lists every input to the model. At A3, a provider attestation binds what the provider received and returned; if the holder also releases the item with role "request", the verifier can check that the listed items are the parts of that request. The strength of A3 depends on the attestation format; some formats bind hashes of a request and response without proving that the response was produced from that request. Profiles define which levels they accept for which purposes.¶

6.6. Errors

A holder that does not release returns an error object of type "adc-error" (Section 5.7) with one of the following codes; the profile maps them to its transport.¶

invalid_request:

The request is malformed or names an unsupported version or algorithm.¶

invalid_credential:

The credential is missing, expired, not sender-bound, or not issued under a trust anchor of the profile.¶

replayed_request:

The request_id was already used, or issued_at is outside the tolerance.¶

not_found:

No record is bound to the presented transaction.¶

policy_denied:

The principal's authorization policy does not permit release to this verifier.¶

too_large:

The release would exceed the limits set by the profile; the profile may define partial release.¶

temporarily_unavailable:

The holder cannot serve the request now; the error carries "retry_after" in seconds.¶

Where distinguishing not_found from policy_denied would reveal that a record exists, the profile MAY require holders to return not_found for both. An error is not evidence about the decision; verifiers report it as received.¶

Verifiers fail closed. Each step in Section 6.4 yields one of "pass", "fail", "not_applicable", "not_checked", or "unsupported". If any of steps 1 to 5 yields "fail" or "unsupported", no level is reported. A step that is not checked never counts as passed, and partial results never raise the level.¶

6.7. Verification Reports and Their Audit

The verifier records its result as a verification report of type "adc-report" (Section 5.7). The report states the level or its absence, the result of each step, the profile, the verifier, the time of verification, and the digests of every input: the mandate presentation, the signed release, each transparent statement, each attestation, and the trust anchors and revocation information used. The verifier MUST sign the report as a JWS [RFC7515].¶

Given the same inputs, every step except the evaluation of revocation status is a deterministic computation, so any other party holding those inputs can repeat the procedure and must obtain the same result. Revocation status is evaluated as of the recorded time against the recorded sources. A verifier is therefore checked by repetition, not by another authority. Profiles MAY require verification by more than one independent verifier for a given purpose.¶

7.1. Verifiable Intent

In Autonomous mode, the agent includes "decision_context" as an additional selectively disclosable claim in both the Layer 3a payment payload and the Layer 3b checkout payload [VI], with the same claim value, so that its disclosure digest appears under the agent's signature in what the network and the merchant each receive. Payee and amount are compared against Layer 3a and checkout_digest against Layer 3b. Verifiable Intent does not profile additional claims of this kind; a holder that presents the payload to a party that does not process the claim can omit its disclosure. The claim MUST NOT be expressed as a constraint, because unknown constraint types in open mandates are rejected. In Immediate mode no agent-signed layer exists and the principal confirms the final values; the claim MAY be placed in the principal-signed Layer 2 mandate only if the signing interface shows the principal that a decision commitment is included, and the verifier reports the principal as signer. checkout_digest is the Verifiable Intent "checkout_hash" value.¶

7.2. Agent Payments Protocol

The agent includes "decision_context" as a selectively disclosable claim of the closed Checkout Mandate ("mandate.checkout.1") [AP2]. The merchant-signed Checkout Receipt's "reference" covers the commitment only if the claim's disclosure is included in the presentation the merchant receives. The claim MUST NOT appear in open mandates or constraints. In human-present mode the principal signs the closed mandate, and the claim SHOULD be included only if the trusted surface shows the principal that a decision commitment is included. The claim MAY also be included in the Payment Mandate, which carries the payee, payment instrument, and amount to the payment processor and issuer; payee, amount, and currency are compared against the Payment Mandate where present and otherwise against the checkout object bound by "checkout_hash". Implementations MUST compute digests over the raw disclosure strings, since some libraries discard unknown members when parsing. checkout_digest is the closed mandate's "checkout_hash".¶

7.3. x402

The server advertises the extension "adc" in its payment-required response with an empty "info" object and a schema; the client echoes the extension in its payment payload and appends the claim as "info.decision_context", which the x402 extension rules permit (clients may append to, but not alter, the server's info) [X402]. The payer's EIP-3009 or Permit2 signature does not cover extensions. To bring the commitment under the payer's signature, the client SHOULD set the 32-octet nonce to SHA-256(BASE64URL-DECODE(C) || r), where r is 16 random octets that the holder retains with the record and returns, as "nonce_random", in the release (Section 6.2); the 32-octet value is encoded as the payment scheme requires (for example as a decimal string for Permit2). Without this construction, the binding is level A0. checkout_digest is BASE64URL(SHA-256(CANON(accepted payment requirements))). Payee is the "payTo" value and amount the authorized value in base units; currency is the CAIP-19 identifier [CAIP19] of the asset, lowercased before use. Hexadecimal addresses are compared case-insensitively. Because payment requirements can repeat, reuse of a claim is detected by the nonce construction and the holder chain, not by step 3 alone.¶

7.4. Account-to-Account Credit Transfers

For ISO 20022 credit transfers [ISO20022], including instant schemes, the holder places "ADC1:" followed by the lowercase hexadecimal encoding of the 32 octets of the commitment in the unstructured remittance information (69 characters), where the scheme and the payer's provider permit payer-supplied remittance text. Hexadecimal is used because some schemes restrict remittance text to a limited character set. No receipt_uri is carried; the verifier obtains it from the payer's provider or the principal under the profile. Payee is the creditor account identifier, amount the instructed amount in minor units, and currency its ISO 4217 code. checkout_digest is BASE64URL(SHA-256(end-to-end identifier)) when that identifier is known before submission and is otherwise absent. This field is not signed by the agent, so the binding is level A0, anchoring (Section 5.5) provides the time bound, and reuse is detected only through the holder chain.¶

7.5. Card Authorization Messages

Card authorization and authentication messages do not carry the claim. An issuer can obtain it only through a mandate presented by the rail's agent program. This document defines no binding for authorization messages.¶

8.1. Common Rules

• Each exchange object has a body: a JSON object with "type" set to "adc-exchange", "v" set to 1, and the members defined below. The body is signed as a JWS [RFC7515] whose payload is CANON(body) and whose protected header carries "alg", "kid", and "typ" set to "adc-exchange+json". The object hash is object_hash = DIGEST(CANON(body)); it does not depend on the signature.¶
• "alg" is "Ed25519" [RFC9864] or "ES256" [RFC7518]. ES256 signatures MUST be in low-S form, with s no greater than half the order of the group; verifiers MUST reject ES256 signatures whose s is greater. Verifiers MUST reject other algorithms unless the profile permits them.¶
• Every body carries "exchange_id", an opaque string chosen by the sender and unique for the pair of sender and recipient keys; "seq", 0 for the offer and one more than the previous object otherwise; "prev", the object_hash of the previous object, or 32 zero octets encoded in base64url for the offer; "step", the kind of object; and "issued_at". One exchange is one linear chain.¶
• The offer identifies the parties by "sender_key" and "recipient_key", the JWK Thumbprints [RFC7638] of their signing keys. Objects signed by any other key are not part of the exchange, except witness statements (Section 8.3) and arbiter_delivery (Section 8.5).¶
• Equivocation is two different bodies signed by the same key with the same exchange_id and seq. Different signatures over the same body are not equivocation. A verifier that observes equivocation reports it and attributes it to the holder of the signing key.¶
• Deadlines and ordering are judged by witness time (Section 8.3), not by issued_at or by either party's clock. Where objects signed by different parties carry the same seq, the one with the earlier witness time is part of the chain and the other is void.¶

8.2. Objects

intent:

"deliver", when the sender seeks proof of receipt, or "offer", when the sender also seeks acceptance.¶

Payload and payload_commitment:

The payload is a JSON value. The sender chooses a fresh 32-octet salt s and computes payload_commitment = BASE64URL(SHA-256(s || CANON(payload))), the construction of Section 5.4. The plaintext is CANON({"payload": payload, "salt": BASE64URL(s)}). A payload that is not JSON is carried as an object with "media_type" and "content", the base64url encoding of its octets.¶

Ciphertext, aead, ciphertext_hash, and key_hash:

The sender chooses a fresh 256-bit key K, used for one exchange only, and encrypts the plaintext with the AEAD algorithm named in "aead" ("A256GCM" [RFC7518] unless the profile permits others), a fresh random 96-bit nonce, and, as associated data, the UTF-8 octets of exchange_id. The ciphertext is the nonce followed by the AEAD output. ciphertext_hash = DIGEST(ciphertext) and key_hash = DIGEST(K).¶

Envelope and envelope_hash:

The envelope is the signed offer together with the ciphertext. envelope_hash is the object_hash of the offer.¶

hpke and wrapped_key:

K encrypted to the recipient with HPKE [RFC9180] in base mode, with info set to the UTF-8 octets of "adc-exchange" followed by the 32 octets of envelope_hash, and empty associated data. wrapped_key is the base64url encoding of the encapsulated key followed by the HPKE ciphertext; "hpke" carries "kem_id", "kdf_id", and "aead_id". How the sender obtains the recipient's HPKE public key is a matter for the profile.¶

key_release_hash:

The object_hash of the key_release. key_received acknowledges that the key_release arrived; it does not attest that K is correct.¶

escrow:

An object with "scheme", a URI identifying a publicly verifiable secret sharing scheme and its encoding, for example one based on [SCHOENMAKERS]; "arbiters", the array of N arbiter identifiers; "threshold", M; "shares", the N encrypted shares in base64url, each encrypted to one arbiter; and "proof", the base64url encoding of the proof that the shares are consistent, which any party can verify. Where the scheme shares a group element rather than an octet string, K is derived from the shared secret with HKDF [RFC5869] as the scheme specifies. escrow MUST be present when intent is "offer" or when the exchange carries a payment obligation, and then MUST have M at least 2 and N at least 3, with arbiters operated by different organizations.¶

arbiters_accepted:

DIGEST(CANON(escrow)), sent only after the recipient has verified the proof.¶

response_window and expires_at:

response_window is a number of seconds. The deadline for each expected object is the witness time of the preceding object plus response_window, and is never later than expires_at.¶

check:

The check that failed: "ciphertext_hash", "unwrap", "key_hash", "decrypt", or "payload_commitment".¶

awaited and attempts:

awaited is the step that did not arrive by its deadline. attempts lists the delivery attempts, each with "transport_digest", a digest of the transport receipt for the attempt, and the witness statements obtained at the time of the attempt.¶

key_matched, commitment_matched, and delivered_at:

The results of the arbiters' checks (Section 8.5) and, when K was delivered, the time of delivery.¶

state and reason:

The terminal state that the closing party asserts (Section 8.4) and a human-readable reason.¶

8.3. Witnesses

A witness is an independent service that countersigns an object_hash with its own time. Witnesses see hashes only, never content. A witness statement takes one of two forms:¶

"rfc3161":

A TimeStampToken [RFC3161] whose messageImprint uses SHA-256 and whose hashedMessage is the 32 octets of object_hash, that is, SHA-256(CANON(body)). Qualified electronic time stamps issued by qualified trust service providers [EIDAS] take this form.¶

"scitt":

A Transparent Statement [RFC9943]: a Signed Statement, in the envelope of Section 5.5, whose payload, of content type application/adc-anchor+json, is the witness payload shown below, with its transparency receipt. The witness time is the registration time, established as for level A2 (Section 5.5). The "sub" of such a statement MUST NOT link different exchanges.¶

{"type":"adc-witness","v":1,"object_hash":"<object_hash>"}

Each party's agent procures witness statements for every object it signs and for every object it receives, and carries them with the object as an exchange receipt: {"object": the signed object, "witnesses": [{"format", "token"}, ...]}. A receipt for a step is therefore three things together: the object, the counterparty's signature on the object that answers it, and the witness statements. Neither party needs to trust the other's clock or storage.¶

At least one witness MUST be independent of both parties. Exchanges that carry a payment or other obligation SHOULD use two witnesses operated by different organizations. The witness time of an object is the earliest time among its valid witness statements from witnesses accepted by the profile. Witness time is authoritative for deadlines and for ordering across parties. The anchor of Section 5.5 is itself a witness statement over the decision commitment.¶

A witness statement proves that an object existed at a time. It does not prove delivery. Delivery is proven by the counterparty's acknowledgement. Without one, a non_ack stands on delivery attempts whose transport receipts were witnessed at the time of each attempt.¶

8.4. State Machine

A verifier determines the state of an exchange by verifying each object's signature, its exchange_id, seq, and prev, and its witness statements, and then applying the transitions below in order of witness time.¶

For intent "deliver", received moves the exchange directly to the terminal state DELIVERED. For intent "offer", accepted and refused move it to ACCEPTED and REFUSED. Either party MAY close an exchange in a non-terminal state with a stated reason, which moves it to CLOSED. The terminal states are NOT_ACKNOWLEDGED, VOID, KEY_UNACKNOWLEDGED, DELIVERED_VIA_ARBITER, CONTENT_UNACKNOWLEDGED, DELIVERED, ACCEPTED, REFUSED, NOT_ACCEPTED, FAULT_SENDER, FAULT_RECIPIENT, and CLOSED.¶

An object whose earliest witness time is after the deadline or expiry that governs it, or after the exchange reached a terminal state, is void. A state that results from a passed deadline is established against the objects presented; a party rebuts it by presenting an object of the awaited step whose witness time precedes the deadline.¶

Recomputation: because the sender signed both ciphertext_hash and key_hash, any party given K and the ciphertext can repeat the recipient's checks. If DIGEST(ciphertext) equals ciphertext_hash and DIGEST(K) equals key_hash, but decryption fails or the decrypted payload does not match payload_commitment, the failure is confirmed and the state is FAULT_SENDER. If every check passes, the state is FAULT_RECIPIENT. Where escrow is present, arbiters perform the recomputation with the reconstructed K. A recipient that relies on recomputation discloses K and the ciphertext to the party that performs it, which can then read the payload. If the K or the ciphertext presented does not match the hash the sender signed, recomputation cannot attribute the failure, because HPKE decryption and transport are not publicly verifiable. This covers the checks "ciphertext_hash", "unwrap", and "key_hash"; where escrow is present, the arbiters instead check the reconstructed K as described in Section 8.5. Otherwise the verifier reports the cause as not determinable, and the exchange remains in MISMATCH until it is closed.¶

FAULT_SENDER and FAULT_RECIPIENT identify the party whose signed values are inconsistent with the recomputation. Like every other result of this document, they are evidence and not a verdict (Section 1.2).¶

Implementations MUST present held, received, delivered via arbiter, and accepted to users as distinct states. Treating delivery as agreement is the most likely misuse of this mechanism.¶

8.5. Arbiters

Arbiters are named in the offer and bind only once the recipient accepts them through arbiters_accepted in held. Publicly verifiable secret sharing lets the recipient check the encrypted shares before it sends held. A recipient MUST NOT send held with arbiters_accepted unless the proof verifies; where escrow is required and the proof does not verify, the recipient closes the exchange.¶

An arbiter MUST open its share only for an exchange whose chain and witness statements show KEY_RELEASED past its deadline, or MISMATCH, and MUST verify the chain before doing so. Every opening is itself witnessed and registered with a transparency service.¶

When M arbiters have opened their shares, they reconstruct K, check it against key_hash, check that it decrypts the ciphertext to a payload matching payload_commitment, deliver K to the recipient in the manner of key_release, and each sign the same arbiter_delivery body; the signatures are carried in the JWS JSON General Serialization (Section 7.2.1 of [RFC7515]). arbiter_delivery never implies received, acceptance, or refusal. Arbiters never issue received, accepted, or refused on the recipient's behalf.¶

If the reconstructed K does not match key_hash, or does not decrypt the ciphertext to a payload matching payload_commitment, the arbiters sign arbiter_delivery with "key_matched" or "commitment_matched" false and deliver nothing, and the inconsistency is attributed to the sender, who signed both values (FAULT_SENDER).¶

8.6. Binding to Decision Records

When an agent decides on the basis of a received payload, its context receipt (Section 5.2) lists, as items with role "exchange", the bodies of the exchange objects up to and including received, each with media type application/adc-exchange+json, and, as items with role "witness", their witness statements, in addition to the payload itself. The decision record therefore proves both what arrived and what the agent did with it.¶

A counterparty MAY countersign a decision commitment: the holder sends an exchange with intent "deliver" whose payload is the decision context claim, and the counterparty's received object is the countersignature. In the Agent Payments Protocol, the merchant-signed Checkout Receipt has the same effect when the claim's disclosure is included in the presentation the merchant receives (Section 7.2).¶

8.7. Security and Privacy of the Exchange

Fairness:

Neither party can obtain the other's acknowledgement without leaving evidence, but a party can still stop at any step. The state machine turns stopping into a recorded state; it does not prevent it [PAGNIA].¶

Metadata:

Witnesses see hashes only. Pairwise keys limit linking across exchanges. Arbiters see the metadata of exchanges that name them and SHOULD be rotated.¶

Low-entropy payloads:

The 32-octet salt in the plaintext prevents a party that sees payload_commitment from confirming a guessed payload.¶

Replay:

exchange_id, seq, prev, and expires_at together prevent a replayed object from being accepted as new.¶

Key compromise:

Witness time bounds when a signature could have been made.¶

Witness collusion:

A party colluding with every witness it uses can misstate time. The requirement for a witness independent of both parties, and two witnesses for obligations, mitigates this.¶

Arbiter collusion:

M colluding arbiters can read the payload. Fewer than M learn nothing about K.¶

Griefing:

A non_ack carries weight only through its witnessed delivery attempts, not through the sender's assertion. A recipient MAY answer with a signed close stating a reason.¶

Key and nonce reuse:

K is fresh for each exchange, so a random AEAD nonce is safe. Reusing K across exchanges is prohibited.¶

Legal effect:

This section produces evidence. The legal presumption that Article 43 of [EIDAS] gives to qualified electronic registered delivery services requires a qualified provider. A qualified trust service provider acting as both witness and delivery service is the route to that effect and is outside the scope of this document.¶

10.1. Trust Assumptions

• The holder's signing key and the agent's signing key are not compromised at decision time.¶
• At least one transparency service used is append-only, presents a consistent view, and records registration times honestly. Collusion between a holder and every transparency service it uses defeats the time bound.¶
• SHA-256 is collision-resistant and second-preimage-resistant.¶
• For level A3, the attesting model providers are honest.¶
• For exchanges, at least one witness used is independent of both parties and records time honestly, and fewer than M arbiters collude (Section 8.7).¶

10.2. Threats and Mitigations

Fabrication after the fact:

A record created after a dispute does not match the commitment in the signed mandate or the anchored statement.¶

Fabrication at decision time:

Not prevented. A holder can commit to a misleading record before signing. Level A3 narrows this by having providers attest to what each model call received and returned.¶

Omission of records:

The holder chain and anchoring make a missing interior sequence number detectable, and a verifier that obtains neighboring anchors can detect equivocation. Deletion after the last anchor a verifier sees, and abandonment of a chain, are not detectable from the chain alone (Section 5.5).¶

Omission of items within a record:

A verifier cannot prove that the receipt lists every input; it can prove only that the receipt has not changed since anchoring. At A3 with a released "request" item, it can check that the listed items are the parts of the attested request. Verifiers MUST NOT report completeness.¶

Back-dating:

Bounded by the registration time, where it can be established (Section 5.5).¶

Split view and service collusion:

A transparency service that presents different logs to different parties can mislead a verifier that checks only the receipts the holder presents. Profiles mitigate this with services that provide consistency proofs, with registration at independent services, and by distributing service trust anchors out of band.¶

Malicious receipt_uri:

A holder can direct verifiers to a host it controls. The credential properties in Section 6.1 prevent replay of the verifier's credential, and the restriction on dereferencing limits request forgery.¶

Reuse of a claim in another transaction:

Detected by step 3 where the record's transaction fields are unique to the transaction (for example through checkout_digest); on rails where they can repeat, detected through the x402 nonce construction or the holder chain.¶

Stripping or substitution of the claim:

Substitution is prevented where the claim is covered by a signature. Omission of the claim's disclosure from a presentation is not prevented; a verifier that sees an undisclosed digest can request the disclosure from the holder. Where no signature covers the claim, the binding is level A0.¶

Guessing record contents:

Prevented by the 32-octet commitment salt and per-item salts.¶

Model substitution:

The record names a resolved model version; only level A3 proves which model ran.¶

Canonicalization divergence:

Addressed by mandatory NFC normalization and JCS; numbers are canonicalized by JCS, and raw provider output is a separate item.¶

Key compromise:

Anchoring bounds when a commitment existed, not when a signature over it was made. Holders publish key validity periods and revocations under their profile.¶

Replay of a disclosure request:

Prevented by the single-use request_id, the issued_at tolerance, and the sender-constrained, transaction-bound credential (Section 6.1).¶

Replay of a release:

A release echoes the request_id and verifier and is signed by the holder, so it cannot be passed off as the answer to another request. Anyone who holds a release can still show it to others; verifiers MUST NOT pass releases to parties outside the dispute.¶

Collusion:

A holder colluding with every transparency service it uses defeats the time bound; independent services and consistency proofs mitigate this. A holder colluding with a model provider defeats level A3. A principal and holder acting together can still commit to a misleading record before a payment, though not alter it afterwards. A holder colluding with a verifier is exposed when another party repeats the verification (Section 6.7). This document does not address collusion among dispute participants beyond that.¶

Hash collisions:

Binding depends on the collision resistance of SHA-256. A party able to find collisions could open one commitment to two records. Fixed-length salt prefixes and canonical serialization remove ambiguity in how inputs are formed. Length extension does not apply, because ADC uses no secret-prefix authentication and verifiers recompute every digest over its complete input. The "alg" member allows migration.¶

Canonicalization attacks:

Objects containing invalid Unicode (such as unpaired surrogates), non-finite numbers, numbers outside the range JCS represents exactly, or duplicate member names MUST be rejected before hashing. Amounts are strings for this reason.¶

Weak randomness and salt reuse:

Predictable or reused salts allow guessing of hidden content and linking of equal descriptors. Salts MUST come from a cryptographically secure generator and MUST NOT be reused.¶

Malicious released content:

Released items are untrusted input and may contain malware, prompt injection aimed at review tools, or decompression bombs. Verifiers MUST treat items as data, MUST enforce the profile's size and count limits before processing, and SHOULD isolate any replay or automated review of item content.¶

Denial of service:

Holders rate-limit disclosure requests, which require credentials. Unavailability of a transparency service is handled by alternate services or late registration; unavailability of the holder is reported as temporarily_unavailable and does not by itself change any level.¶

State rollback:

A holder restored from backup could reuse sequence numbers, which verifiers report as equivocation. The failure-handling rules in Section 5.5 prevent this for honest holders.¶

10.3. Replay and Attribution

Re-submitting recorded items to the named model shows what the model received and how it may respond. It does not establish what caused the original output, whether that output was correct, or that a given item was responsible. Model outputs may vary between calls, and models may be withdrawn. The committed answer is the record of what happened.¶

10.4. Cryptographic Considerations

Salts have a fixed length so that concatenation is unambiguous. The "alg" member allows other digest algorithms in future versions; verifiers reject algorithms they do not support. Item digests and commitments are salted with fixed-length salts, and receipts, records, and statement payloads carry distinct "type" members; an item descriptor carries no "type" but is always hashed with a salt, whereas receipts are not. SD-JWT disclosure digests are computed as specified in [RFC9901].¶

This document does not depend on the quantum resistance of any signature. SHA-256 commitments retain their binding property against known quantum attacks, and the 32-octet salts keep generic quantum search for the hidden content impractical. The signatures on mandates, signed statements, and transparency receipts are another matter: a party able to forge them could fabricate evidence of when a commitment existed. Holders SHOULD support ML-DSA for anchor statements [RFC9964] as transparency services deploy it, MAY use composite signatures [I-D.ietf-jose-pq-composite-sigs], and MAY re-register earlier commitments under a stronger algorithm while retaining the original receipts. Verifiers MUST report the signature algorithm used at each step.¶

13.1. JSON Web Token Claims Registration

IANA is requested to register the following claim in the "JSON Web Token Claims" registry established by [RFC7519]:¶

• Claim Name: decision_context¶
• Claim Description: Commitment to the decision context of an agent-initiated payment¶
• Change Controller: Author (to be changed to IETF if this document is adopted in the IETF stream)¶
• Specification Document(s): Section 5.4 of this document¶

13.2. Media Type Registrations

IANA is requested to register the following media types [RFC6838], all using the "+json" structured syntax suffix [RFC6839]. application/adc-anchor+json is the payload content type of anchor, outcome, erasure, and witness statements (Section 5.5, Section 8.3); application/adc-release+json is the payload of a signed release (Section 6.2); application/adc-exchange+json is the body of an exchange object (Section 8).¶

Type name:

application¶

Subtype names:

adc-anchor+json; adc-release+json; adc-exchange+json¶

Required parameters:

N/A¶

Optional parameters:

N/A¶

Encoding considerations:

binary; as for application/json¶

Security considerations:

See Section 10 and Section 11 of this document.¶

Interoperability considerations:

Objects are canonicalized as described in Section 5.1 before hashing.¶

Published specification:

This document¶

Applications that use this media type:

Agent platforms, payment dispute systems, and agents exchanging payloads with counterparties¶

Fragment identifier considerations:

As for application/json¶

Additional information:

Deprecated alias names for this type: 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:

Fernando Henrique Damasceno Milan, milan@nordqubit.com¶

Intended usage:

COMMON¶

Restrictions on usage:

None¶

Author:

Fernando Henrique Damasceno Milan¶

Change controller:

Author (to be changed to IETF if this document is adopted in the IETF stream)¶