Contestability Bindings for Authorized Agent Actions

1.1. Running example: an affected party outside the authorization

A platform authorizes an agent to suspend Alice's account after a policy event. The Authorization Artifact is valid, action-bound, time-bounded, and signed. The executor verifies it, suspends the account, and produces a valid receipt.¶

Alice is materially affected but is not the authorization principal, agent, issuer, executor, approver, or relying party. The Authorization Artifact and receipt can provide evidence that the platform's authorization and recording checks were satisfied for the supplied artifacts. They do not necessarily allow Alice or an independent verifier to determine:¶

• where the suspension can be contested;¶

• which standing policy and procedure governed at execution time;¶

• when the filing window closes;¶

• whether a filing changes execution state;¶

• whether the named forum agreed to receive that class of contestation;¶

• who selected the forum;¶

• whether the forum or procedure was substituted after the suspension.¶

The interoperability failure is not that every deployment chooses a different forum. The failure is that two implementations receiving the same Authorization Artifact can validate the authorization and still reach incompatible or non-reproducible conclusions about the contestation path bound to it.¶

1.2. Minimum interoperable result

Section 6.2 defines the authoritative structured-result contract. Given the same Authorization Artifact, action, CPO, verification time, selected profiles, and trust inputs, conforming implementations are expected to agree on every field that those inputs make deterministically derivable. The following abstract-protocol example illustrates one complete result:¶

{
  "binding": "valid",
  "pre_execution_evidence": "executor_attested",
  "discoverability": "complete",
  "forum_acknowledgement": "valid_class",
  "forum_operational_status": "not_checked",
  "selection_provenance": "unilateral",
  "access_binding": "valid",
  "notice_evidence": "delivered",
  "retrievability": "not_checked",
  "filing_window_status": "open",
  "policy_freshness": "indeterminate",
  "declared_effect": "none",
  "effect_acceptance": "not_required",
  "effect_trigger": "not_applicable",
  "effect_ordering": "not_applicable",
  "effect_application": "not_applicable",
  "reasons": []
}

They are not expected to agree that the forum is fair, independent, affordable, competent, or legally authoritative. Those conclusions remain outside the protocol.¶

1.3. Protocol requirements

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

The mechanism is designed to satisfy the following requirements.¶

R1 — Pre-execution binding: A cryptographically valid Contestability Binding does not by itself establish pre-execution presentation or ordering. A deployment or profile claiming pre-execution presentation or enforcement of the Contestability Binding MUST bind the contestation parameters to the Authorization Artifact and MUST present them to the enforcing executor before execution. A self-asserted issued_at value is insufficient evidence of ordering. To support that pre-execution claim, the selected profile MUST bind the CPO digest into an executor-signed verification or execution record, or supply equivalent authenticated ordering evidence. A post-execution declaration cannot retroactively satisfy the pre-execution claim.¶

R2 — Exact action and authorization binding: The binding MUST identify one Authorization Artifact or authorization instance and the canonical action it covers. It MUST NOT be reusable across different actions or authorization instances.¶

R3 — Substitution resistance: The forum, submission mechanism, Standing Policy, procedure, filing window, effect policy, and selection policy MUST be integrity-protected. A mutable locator without a bound digest is insufficient.¶

R4 — Forum acknowledgement: A profile claiming a forum-acknowledged contestation path MUST carry authenticated evidence that the named forum accepted the forum identifier, submission mechanism, procedure, and class of actions or authorizations covered. An issuer naming an unconsenting forum is disclosure, not a forum-acknowledged path.¶

R5 — Selection provenance: A verifier MUST derive forum-selection provenance from authenticated evidence and local trust inputs. The object MUST NOT turn an issuer's self-asserted claim of independence into a protocol result.¶

R6 — Affected-party delivery or discovery: A profile claiming affected-party access to the contestation binding MUST define how a person or organization that did not participate in the authorization obtains the CPO and the evidence needed to verify its binding. Availability only to the issuer, agent, or executor is insufficient. The filing clock MUST be based on an authenticated event defined by the profile; an issuer-asserted notice time alone MUST NOT shorten the affected party's window.¶

R7 — Structured, non-collapsed result: Verification MUST return and keep separate the structured-result fields defined in Section 6.2, which is the authoritative result contract. It MUST NOT collapse them into a bare contestable: true result.¶

R8 — Effect acceptance and application separation: An issuer-declared active effect MUST NOT be reported as executor-accepted unless the named executor authenticated the same authorization, CPO, effect-policy, and forum-acceptance digests before execution. Executor acceptance MUST NOT be reported as application. A filing or other trigger MUST be authenticated under the bound trigger profile. Application MUST be reported only from separately verified executor evidence and ordering MUST be verified under the bound serialization profile. None of those records proves physical state or authorizes a remedy.¶

R4 and R6 are profile requirements rather than universal claims about every Authorization Artifact. A deployment can use the base object only for disclosure, but it cannot claim a forum-acknowledged path or a path conforming to the affected-party access profile without satisfying the corresponding requirements.¶

1.4. Adversarial survival tests for R4 and R6

R4 and R6 are deliberately tested against claims that a signature or URI cannot establish.¶

1.5. Signature-topology survival test

A naive construction in which the forum signs the final CPO fails three tests:¶

1. If the final CPO contains the forum signature, signing the final CPO creates a circular signature input.¶

2. If the forum signs every authorization instance, the construction requires an online forum interaction per action and discloses instance metadata before execution.¶

3. If the forum signs only a free-text action class, class membership is not interoperably decidable.¶

The base design therefore separates:¶

• Contestation Terms: the canonical per-authorization facts to which every signature ultimately refers;¶

• Forum Acceptance Evidence: either an exact signature over a closed forum-relevant projection of the Contestation Terms or a reusable Forum Acceptance Manifest for one or more closed authorization-profile digests;¶

• Selection Evidence: signatures over the Contestation Terms digest and Forum Acceptance Evidence digest;¶

• CPO Envelope: the terms and evidence, signed by the CPO issuer;¶

• Authorization Binding: a digest of the completed CPO Envelope covered by the Authorization Artifact or companion binding statement.¶

This ordering is acyclic: the forum first signs either a reusable manifest or an exact forum-terms digest; selectors then sign the complete terms and acceptance-evidence digests; the CPO issuer signs the resulting envelope; finally, the Authorization Artifact or companion statement binds the completed CPO digest.¶

An active effect extends, but does not alter, that graph. The executor signs an Effect Acceptance Statement over the completed Authorization Artifact and CPO. A forum filing receipt later binds the CPO digest. An Effect Application Record binds both the acceptance and receipt digests. For a pre-execution hold, the executor's hold or refusal record then binds the application record; for a post-execution fence, the earlier execution record binds the acceptance and the later application record binds the receipt. No signer is required to sign bytes containing its own signature.¶

For class acceptance, the forum signs accepted ABP and Authorization Trust Profile digest pairs, not an open expression language. A verifier returns valid_class only after it has independently verified and projected the Authorization Artifact under one of those exact pairs. Merely carrying profile identifiers is insufficient.¶

4.1. Closed structure

Every map in the mandatory executable profile is closed. A verifier MUST reject an unknown map member, duplicate map key, unsupported object type or version, non-deterministic encoding, or value outside the profile's CDDL. Payload-level crit processing is therefore unnecessary in CBAP-1. COSE protected-header processing remains governed by Section 4.14.¶

4.2. Forum information

forum.id, submission_endpoint, and verification_key_id MUST be present. A human-readable name alone is insufficient. The endpoint MUST use an authenticated transport profile. Successful network access does not establish forum independence.¶

forum_acceptance identifies either an Exact Forum Acceptance Statement or a Forum Acceptance Manifest by digest. The accepted input covers only the facts to which the forum commits: accepted authorization scope, forum identity and key, submission endpoint, Standing Policy, procedure, filing-window rule, filing-receipt profile, and withdrawal or continuity policy. Selection provenance and the issuer's declared effect policy remain separately signed facts; a forum acknowledgement does not authenticate either one.¶

A valid acknowledgement authenticates a signed commitment under the accepted forum key to receive the declared scope under the bound parameters. It does not prove availability, neutrality, legal jurisdiction, or performance.¶

An exact acknowledgement binds the forum_terms_digest for one authorization instance. A class acknowledgement binds one or more closed ABP and Authorization Trust Profile digest pairs. A verifier MUST refuse a class acknowledgement when the Authorization Artifact has not itself been verified and projected under one of those exact pairs.¶

For exact acceptance, the signed_at value authenticated by the forum signature MUST be no later than the authenticated lower bound of the authorization's executable validity interval, valid_from MUST be no later than that same boundary, and valid_until MUST be no earlier than the end of the declared filing window, unless the bound withdrawal policy provides verifiable continuity through a replacement forum. For class acceptance, the Authorization Artifact MUST bind the manifest during may_bind_from through may_bind_until, and the instantiated filing obligation MUST remain within maximum_filing_horizon_seconds. A withdrawal after execution MUST be evaluated under the bound policy and MUST NOT silently erase the historical acknowledgement. The filing-receipt profile identifies the authenticated response a conforming forum returns after accepting or refusing a filing; this document does not otherwise define the filing exchange.¶

4.3. Policies by digest

The Standing Policy, procedure, and selection policy MUST be bound by digest. A mutable URI without a digest MUST be refused. A verifier MAY apply a stricter local policy than the referenced procedure or filing window.¶

4.4. Effect policy

An effect_policy declares whether an authenticated contestation filing is intended to support a protocol-visible transition result for the named executor. The base modes are:¶

• none: filing has no automatic execution effect under this binding;¶

• hold_before_execution: selects a hold result that is satisfied only when an accepted filing is authenticated and ordered before the bound execution boundary and the bound executor evidence records the required hold state rather than an execution transition for that boundary;¶

• fence_after_execution: selects a fence result that is satisfied only when an accepted filing is authenticated and ordered after action execution but before the bound finality boundary and the bound executor evidence records the required fence transition.¶

An active-effect profile using hold_before_execution MUST NOT select execution_time as its filing-window basis. It MUST select an authenticated filing-window event that can occur before the execution boundary, such as conforming delivery or transparency-publication evidence or another profile-defined pre-execution event.¶

The base protocol deliberately has no profile_defined escape value. An unexamined extension cannot be assigned the semantics of a hold or fence. A future mode requires a standards-defined value or a versioned extension understood by every verifier making a claim about it.¶

For none, no effect parameters are present and effect_acceptance is not_required. For either active mode, the policy MUST contain:¶

{
  "mode": "fence_after_execution",
  "executor": {
    "id": "https://executor.example/",
    "verification_key_id": "https://executor.example/keys/8"
  },
  "executor_trust_profile": {
    "uri": "https://platform.example/trust/effect-executors/2",
    "digest": { "alg": "sha-256", "value": "base64url..." }
  },
  "trigger_profile": {
    "event": "accepted_filing_receipt",
    "uri": "https://forum.example/profiles/filing-receipt/1",
    "digest": { "alg": "sha-256", "value": "base64url..." }
  },
  "state_machine_profile": {
    "uri": "https://platform.example/profiles/account-finality/2",
    "digest": { "alg": "sha-256", "value": "base64url..." }
  },
  "target_state_digest": { "alg": "sha-256", "value": "base64url..." },
  "application_deadline": {
    "basis": "authenticated_trigger_time",
    "duration_seconds": 30
  },
  "idempotency_profile": {
    "uri": "https://platform.example/profiles/contest-trigger-idempotency/1",
    "digest": { "alg": "sha-256", "value": "base64url..." }
  },
  "serialization_profile": {
    "uri": "https://platform.example/profiles/account-action-serialization/3",
    "digest": { "alg": "sha-256", "value": "base64url..." }
  }
}

trigger_profile MUST identify an authenticated event and its complete verification rules. For accepted_filing_receipt, its digest MUST equal the submission-receipt profile authenticated by the verified forum acceptance evidence. The receipt time MUST fall within the verified filing window and the effect mode's transition interval, unless the bound procedure and effect policy define the same deterministic grace rule. An authenticated successful receipt records acceptance of a filing under the bound forum key and profile. It does not prove standing, merits, fairness, or entitlement to a remedy.¶

executor_trust_profile binds the trust anchors, key-authority rules, rotation rules, and compromise semantics used to authenticate the named executor; a relying party can apply stricter local policy. state_machine_profile defines the states, transition preconditions, finality boundary, and interpretation of the state commitments carried in effect records. target_state_digest commits to the exact hold or fence transition. application_deadline is computed only from the authenticated time established by the trigger profile; an executor or issuer timestamp cannot silently replace it. idempotency_profile defines how duplicate triggers are detected. serialization_profile defines the authenticated sequence number, compare-and-swap rule, transaction boundary, or equivalent mechanism that orders the trigger against execution and finality transitions.¶

The Effect Executor MAY differ from the executor that performs the authorized action only when the serialization profile authenticates the cross-system boundary and assigns each required transition to a named signer. For hold_before_execution, the Effect Executor MUST control or atomically gate the action's execution boundary. For fence_after_execution, it MUST control or atomically gate the bound finality transition. Merely receiving events from the system of record is insufficient.¶

hold_before_execution is satisfied only when the trigger is ordered before the execution boundary and the bound executor evidence records the hold state rather than an execution disposition for that boundary. It cannot retroactively characterize an already executed action as held. fence_after_execution is satisfied only when the trigger is ordered after execution and before the bound finality boundary and the bound executor evidence records the fence state. These are protocol-state results over authenticated evidence; a fence does not undo the action, restore prior state, or constitute a remedy.¶

The policy is an issuer-signed declaration inside the CPO terms. It does not bind the executor merely because the issuer named an executor key. Active modes require the separate Executor Effect Acceptance Statement in Section 5.4. Acceptance is not application, and an Effect Application Record is still only a signed claim by the executor key about the protocol state it controls. No object defined here compels a court, human, physical process, or external system.¶

4.5. Selection evidence

The CPO MUST NOT contain a self-asserted boolean such as independent: true. A verifier derives selection provenance from authenticated signatures and its local trust profile.¶

The authorization issuer's signature is necessary to bind the CPO to the authorization but is not evidence of independent selection. An issuer-only object is classified as unilateral.¶

4.6. Affected-party access

affected_party_access is an ordered set of declared methods for delivery or discovery of the CPO and its verification material by a party that may be absent from the authorization exchange. The initial methods under consideration are:¶

• effect_notice: delivered with the notice of the action's effect;¶

• authenticated_lookup: retrievable from a bound discovery URI after authenticating an eligible party;¶

• public_transparency: retrievable from a named transparency service without disclosing private filing evidence.¶

The access objects MUST be covered by the CPO issuer signature. A profile claiming affected-party access to the contestation binding MUST define at least one mandatory delivery or discovery method, its retention period, and the behavior when the affected party cannot authenticate before the filing window closes.¶

Where the action disables, suspends, revokes, or controls a credential, at least one access method MUST remain usable without relying solely on that credential. The authentication profile is digest-bound so a verifier can apply a local credential-survivability policy; the profile's presence does not by itself prove that access will succeed.¶

4.7. Contestability Notice

An affected-party profile using effect_notice carries or references a signed notice with the following minimum members:¶

{
  "type": "agent-contestability-notice-v1",
  "authorization_id": "urn:uuid:...",
  "action_digest": { "alg": "sha-256", "value": "base64url..." },
  "effect_digest": { "alg": "sha-256", "value": "base64url..." },
  "cpo_digest": { "alg": "sha-256", "value": "base64url..." },
  "issued_at": "2026-08-11T00:00:00Z",
  "access": {
    "mode": "by_reference",
    "uri": "https://platform.example/contestability/urn:uuid:..."
  },
  "issuer": "https://issuer.example/keys/3",
  "signature": "base64url..."
}

The notice signature MUST cover the authorization, action, effect, CPO digest, issue time, and access method. A valid signature yields notice_evidence: issued. It MUST NOT yield delivered unless a selected transport profile supplies authenticated delivery evidence. It MUST NOT yield read or understood.¶

An effect_notice profile SHOULD deliver the notice no later than the effect notification. A filing-window profile claiming affected-party recourse MUST define how late notice affects the closing time. The base protocol does not infer receipt from issuance.¶

4.8. Contestation Terms and signature inputs

terms is the only per-authorization object over which the forum, selectors, issuer, and authorization binding need to converge. Let:¶

terms_digest = HASH("agent-contestation-terms-v1" || canonical(terms))
effect_policy_digest = HASH("agent-contestation-effect-policy-v1" ||
                            canonical(terms.effect_policy))
forum_terms = project(terms, authorization_id, authorization_binding_profile,
                      authorization_trust_profile,
                      authorization_issuer, authorization_validity,
                      action_digest, forum, standing_policy, procedure,
                      filing_window)
forum_terms_digest = HASH("agent-contestation-forum-terms-v1" ||
                          canonical(forum_terms))
acceptance_digest = HASH(canonical(forum_acceptance_evidence))
selection_input = HASH("agent-contestation-selection-v1" || terms_digest || acceptance_digest)
cpo_tbs = canonical(type, terms, forum_acceptance, selection_evidence, issuer)
cpo_digest = HASH("agent-contestation-cpo-v1" || canonical(signed_CPO))

The domain-separation strings are part of the hash input. These equations describe the abstract signature topology. CBAP-1 instantiates them with the exact deterministic encoding and SHA-256 derivations in Sections 4.13 through 4.16. Another application profile MUST define an equally complete and non-ambiguous instantiation.¶

An Exact Forum Acceptance Statement signs forum_terms_digest plus its validity, filing-receipt profile, and withdrawal policy. A Forum Acceptance Manifest is independently signed and reusable; the CPO references its digest. Each selector signs selection_input, which still covers the complete terms. The CPO issuer signs cpo_tbs. The completed cpo_digest is then covered by the Authorization Artifact or companion binding statement.¶

No signature input contains the signature being computed. effect_policy_digest is used only by records created after the signed CPO and Authorization Artifact exist; it does not enter forum_terms_digest and does not make the forum authenticate the issuer's effect declaration. A producer or signer MUST construct each signature input from the exact profile-defined input. A verifier MUST verify the received object against that exact profile-defined signature input.¶

4.9. Exact Forum Acceptance Statement

Exact acceptance is represented diagnostically as:¶

{
  "type": "agent-forum-exact-acceptance-v1",
  "forum_terms_digest": { "alg": "sha-256", "value": "base64url..." },
  "valid_from": "2026-08-11T00:00:00Z",
  "valid_until": "2026-09-10T00:00:00Z",
  "submission_receipt_profile": {
    "uri": "https://forum.example/profiles/filing-receipt/1",
    "digest": { "alg": "sha-256", "value": "base64url..." }
  },
  "withdrawal_policy": {
    "uri": "https://forum.example/policies/withdrawal/1",
    "digest": { "alg": "sha-256", "value": "base64url..." }
  },
  "forum_key_id": "https://forum.example/keys/2026-1",
  "signed_at": "2026-08-11T00:00:00Z",
  "signature": "base64url..."
}

Exact acceptance gives the strongest instance binding but requires the forum to process instance metadata before authorization. It SHOULD be used only when the deployment requires instance-specific forum acceptance and has addressed metadata disclosure, traffic analysis, latency, and forum availability in the authorization path.¶

4.10. Forum Acceptance Manifest

A Forum Acceptance Manifest (FAM) is a reusable, signed acceptance statement:¶

{
  "type": "agent-forum-acceptance-manifest-v1",
  "manifest_id": "https://forum.example/manifests/2026-08",
  "forum": {
    "id": "https://forum.example/",
    "submission_endpoint": "https://forum.example/cases",
    "verification_key_id": "https://forum.example/keys/2026-1"
  },
  "accepted_authorization_classes": [
    {
      "abp_digest": { "alg": "sha-256", "value": "base64url-abp-digest..." },
      "authorization_trust_profile_digest": {
        "alg": "sha-256",
        "value": "base64url-trust-profile-digest..."
      }
    }
  ],
  "standing_policy": {
    "uri": "https://example/policies/standing/7",
    "digest": { "alg": "sha-256", "value": "base64url..." }
  },
  "procedure": {
    "uri": "https://example/procedures/agent-actions/4",
    "digest": { "alg": "sha-256", "value": "base64url..." }
  },
  "filing_window_rule": {
    "permitted_bases": [
      "authenticated_delivery_time",
      "transparency_publication_time"
    ],
    "minimum_duration_seconds": 2592000
  },
  "submission_receipt_profile": {
    "uri": "https://forum.example/profiles/filing-receipt/1",
    "digest": { "alg": "sha-256", "value": "base64url..." }
  },
  "withdrawal_policy": {
    "uri": "https://forum.example/policies/withdrawal/1",
    "digest": { "alg": "sha-256", "value": "base64url..." }
  },
  "may_bind_from": "2026-08-01T00:00:00Z",
  "may_bind_until": "2027-08-01T00:00:00Z",
  "maximum_filing_horizon_seconds": 7776000,
  "issued_at": "2026-07-20T00:00:00Z",
  "key_id": "https://forum.example/keys/2026-1",
  "signature": "base64url..."
}

The base profile does not define a general predicate language for accepted actions. Class membership is established only by an exact pair consisting of an ABP digest and an Authorization Trust Profile digest, followed by successful verification and projection of the Authorization Artifact under that pair. A profile label, URI, or locally substituted trust store MUST NOT establish membership.¶

The CPO's forum, Standing Policy, procedure, filing-window rule, and forum key MUST satisfy the manifest exactly or under a deterministic constraint explicitly defined by the manifest profile. may_bind_from and may_bind_until bound when a new Authorization Artifact may reference the manifest; they do not terminate a filing window already instantiated by a valid binding. maximum_filing_horizon_seconds bounds the latest filing obligation created by an authorization bound during that interval. A mismatch yields invalid_scope.¶

A FAM removes the forum from the per-authorization critical path and does not require disclosure of each authorization instance to the forum. It does not prove capacity or continued availability. The full FAM can be distributed with the CPO; only a digest need be transparency-registered to support equivocation detection.¶

4.11. Authorization Binding Profile

An ABP composes this document with a native authorization system without replacing that system. A conforming ABP MUST define:¶

• the native Authorization Artifact type and mandatory encoding;¶

• the native signature, time, audience, replay, and critical-member verification rules, and the interface through which a digest-bound Authorization Trust Profile supplies trust anchors and issuer-authority constraints;¶

• how to extract or derive authorization_id;¶

• how to canonicalize the authorized action and compute action_digest;¶

• how to identify the authorization issuer and validity interval;¶

• how the direct contestability_digest is covered, or how a companion binding statement is authorized;¶

• the exact closed output tuple and every refusal or indeterminate condition.¶

The minimum successful projection is:¶

{
  "abp_digest": { "alg": "sha-256", "value": "base64url..." },
  "authorization_trust_profile_digest": {
    "alg": "sha-256",
    "value": "base64url..."
  },
  "authorization_id": "urn:uuid:...",
  "authorization_issuer": "https://issuer.example/keys/3",
  "authorization_validity": {
    "not_before": "2026-08-11T00:00:00Z",
    "not_after": "2026-08-12T00:00:00Z"
  },
  "action_digest": { "alg": "sha-256", "value": "base64url..." },
  "binding_mode": "direct"
}

An ABP digest identifies the complete adapter specification, not executable code supplied by the issuer. The Authorization Trust Profile digest identifies the exact trust inputs and issuer-authority rules accepted by the forum class. Two conforming implementations applying the same pair to the same authenticated inputs MUST either produce the same tuple or refuse. A lossy, ambiguous, unpinned, unsupported, or locally substituted mapping or trust input yields indeterminate and MUST NOT establish FAM membership.¶

Successful ABP projection establishes only, under that profile, that the native artifact verified and mapped to the required tuple. It does not mean the forum accepts the profile; that is established separately by the FAM.¶

4.12. Selection signatures are not forum signatures

The forum's signature acknowledges a scope. It MUST NOT be counted as evidence that the forum was selected non-unilaterally. Selection evidence signs selection_input, which includes both the Contestation Terms and the exact acceptance evidence used. This prevents a selector's signature for one forum acceptance from being replayed with another.¶

An entity can perform multiple roles, but role co-location remains visible in the result. When the issuer, forum operator, and external selector resolve to the same controlling trust domain under local policy, the verifier MUST NOT upgrade selection provenance solely because three keys signed.¶

4.13. Mandatory encoding: CBAP-1 Core Deterministic CBOR

The Contestability Binding Application Profile 1 (CBAP-1) is the mandatory-to-implement encoding and executable base profile for this document. CBAP-1 uses the Core Deterministic Encoding Requirements in Section 4.2.1 of [RFC8949]. It does not use the length-first map key ordering in Section 4.2.3 of [RFC8949], historically called canonical CBOR by [RFC7049].¶

A CBAP-1 encoder and verifier MUST enforce all of the following:¶

• preferred and shortest serialization for every integer, length, and tag argument;¶

• definite-length byte strings, text strings, arrays, and maps only;¶

• bytewise-lexicographic ordering of the deterministic encodings of map keys;¶

• rejection of duplicate map keys before conversion to a host-language map;¶

• rejection of floating-point values, simple values other than false, true, and null, and tags other than the required outer COSE_Sign1 tag 18;¶

• well-formed UTF-8 text strings, compared as encoded bytes without Unicode, URI, case, or percent-encoding normalization;¶

• unsigned-integer member labels exactly as specified by the closed CDDL below.¶

Before allocating, slicing, advancing an input cursor, or iterating a declared collection length, a decoder MUST verify with checked arithmetic that the length is representable by the host and does not exceed the remaining input. A declared length or count that cannot be consumed from the received bytes MUST be rejected at the enclosing encoding boundary. It MUST NOT wrap an offset, panic, abort the process, or attempt an allocation based only on the received length.¶

Every uri value in CBAP-1 MUST satisfy the generic URI syntax of [RFC3986] and the https URI scheme requirements in Section 4.2.2 of [RFC9110], with these additional profile restrictions:¶

• the scheme is the exact lowercase ASCII string https;¶

• an authority introduced by // is present and contains a non-empty host;¶

• user information is absent;¶

• if a port delimiter is present, the port is a non-empty decimal integer in 0..65535;¶

• every percent-encoded triplet is syntactically complete; and¶

• a fragment component is absent.¶

Conformance is determined by the complete component grammar, not by a prefix test or a character allowlist. In particular:¶

• authority, host, IP-literal, IPv6address, IPvFuture, path-abempty, segment, pchar, and query have the meanings and ABNF defined by [RFC3986];¶

• a bracketed host MUST contain exactly one syntactically valid [RFC3986] IPv6address or IPvFuture value;¶

• [ and ] are permitted only as the delimiters of that IP-literal and MUST be rejected in a registered name, path, or query;¶

• a registered name is validated as reg-name; accepting the characters of a putative hostname without parsing its component boundaries is insufficient; and¶

• IPv6 zone identifiers, including a percent-encoded zone suffix inside an IP-literal, are not supported by CBAP-1 and MUST be rejected.¶

[RFC9844] obsoletes [RFC6874] and does not define a replacement URI syntax for zone identifiers. CBAP-1 deliberately excludes them because a locally scoped zone identifier is not a stable signed identifier across verifiers.¶

Path and query components are permitted only when their complete [RFC3986] grammar matches. CBAP-1 performs no URI normalization: the exact ASCII bytes are the identifier and signature input. A different but allegedly equivalent spelling is a different value. A prefix test such as starts_with("https://"), a search for forbidden delimiters, or a component-wide character allowlist is not URI validation.¶

The following examples are normative CBAP-1 URI conformance probes. Each value is evaluated as written, without normalization or network resolution.¶

The following conformance probe distinguishes Section 4.2.1 ordering from length-first ordering. A conforming CBAP-1 encoder MUST encode the diagnostic map {100: -1, -1: 100} as hexadecimal a2186420201864. An encoder that places key -1 before key 100 is not conformant even if a library describes its output as canonical.¶

CBAP-1 fixes SHA-256 as specified by [RFC6234] as its only digest function. A digest is a 32-byte byte string; an algorithm identifier is not carried beside each digest. Algorithm substitution is therefore impossible inside the profile. Adding another hash function requires a new application-profile version.¶

Let dCBOR(x) be the exact CBAP-1 deterministic encoding of data item x. Domain-separated hashes are computed as:¶

H(domain, value) = SHA-256(dCBOR([domain, value]))

domain is the exact lowercase ASCII text string defined at each use. Digests of signed artifacts are SHA-256 over the complete tagged COSE_Sign1 byte sequence, including the tag, protected-header bytes, payload, and signature. Policy and action digests are SHA-256 over the exact supplied bytes. A verifier MUST NOT hash a decoded and reconstructed signed object in place of its received conforming bytes.¶

4.14. Mandatory signature envelope

Every signed CBAP-1 object is an embedded-payload, tagged COSE_Sign1 object as defined by [RFC9052]:¶

18([protected, unprotected, payload, signature])

The protected header map MUST contain exactly:¶

{ 1: -19, 4: kid }

Header label 1 is alg; value -19 is the fully specified Ed25519 algorithm registered by [RFC9864]. CBAP-1 MUST NOT use the deprecated polymorphic EdDSA value -8. Header label 4 is kid, encoded as a byte string of 1 through 64 bytes. The unprotected header map MUST be empty. The payload MUST be present as a byte string containing one closed CBAP-1 payload. Detached payloads, countersignatures, critical headers, and additional protected or unprotected headers are not supported by CBAP-1.¶

The signature is computed over the [RFC9052] Sig_structure with context Signature1, the received protected-header bytes, an empty external AAD byte string, and the embedded payload bytes. Ed25519 is defined by [RFC8032]. The signature MUST be 64 bytes. The public key is an Ed25519 COSE_Key as defined by [RFC9053], with kty = 1, crv = 6, and a 32-byte x coordinate. If its alg member is present, it MUST be -19.¶

kid is a key-selection hint, not a trust assertion. The verifier's local trust profile MUST resolve it to exactly one authorized public key for the required role and controlling trust domain. Zero matches, multiple matches, an unauthorized role, or a key/profile mismatch yields invalid or indeterminate as specified by the calling verification step. Each payload also carries the signer's key identifier as a text string; its UTF-8 bytes MUST equal the protected kid.¶

4.15. CBAP-1 closed data model

CBAP-1 intentionally implements the smallest end-to-end path that exercises the load-bearing claims: direct authorization binding, exact forum acceptance, issuer-only selection provenance, by-value policy verification, executor-attested pre-execution evidence, an execution-time filing clock, and effect_policy = none. Class manifests, companion bindings, notices, active execution effects, multiparty selection, and external selection remain part of the abstract protocol but are unsupported by CBAP-1 and require another named profile.¶

In CBAP-1, epoch is an unsigned integer counting seconds from 1970-01-01T00:00Z UTC on the POSIX numeric timeline described for nonnegative epoch-based date/time values in Section 3.4.2 of [RFC8949]. CBAP-1 encodes this integer directly as the untagged CDDL uint; it does not use CBOR tag 1. Fractional and negative epoch values are therefore outside the profile. Leap seconds follow POSIX-time handling: they are not represented as an additional distinct counted second, and comparisons and deadline arithmetic use the resulting POSIX timeline, including its one-second discontinuity at an inserted leap second.¶

The diagnostic CDDL [RFC8610] is:¶

digest = bstr .size 32
id16 = bstr .size 16
epoch = uint
key-id = tstr
uri = tstr

policy-ref = [uri, digest]
validity = [not-before: epoch, not-after: epoch]
forum = [forum-id: uri, submission-endpoint: uri, forum-key-id: key-id]
filing-window = [basis: 1, duration-seconds: uint]
effect-policy = [mode: 0]
affected-party-access = [method: 3, discovery-uri: uri, available-until: epoch]

cbap1-terms = {
  1: id16,                       ; authorization-id
  2: digest,                     ; abp-digest
  3: digest,                     ; authorization-trust-profile-digest
  4: key-id,                     ; authorization-issuer-key-id
  5: validity,                   ; authorization-validity
  6: digest,                     ; action-digest
  7: forum,
  8: policy-ref,                 ; standing-policy
  9: policy-ref,                 ; procedure
  10: filing-window,
  11: effect-policy,
  12: policy-ref,                ; selection-policy
  13: [1* affected-party-access],
  14: epoch,                     ; issued-at
  15: epoch,                     ; expires-at
  16: id16                       ; nonce
}

cbap1-cpo = {
  1: 1,                         ; profile version
  2: 1,                         ; object type: CPO
  3: cbap1-terms,
  4: [mode: 0, exact-acceptance-digest: digest],
  5: [],                        ; no selection statements: unilateral
  6: key-id                     ; issuer-key-id
}

cbap1-exact-acceptance = {
  1: 1,
  2: 2,                         ; exact forum acceptance
  3: digest,                    ; forum-terms-digest
  4: epoch,                     ; valid-from
  5: epoch,                     ; valid-until
  6: policy-ref,                ; submission-receipt-profile
  7: policy-ref,                ; withdrawal-policy
  8: epoch,                     ; signed-at
  9: key-id                     ; forum-key-id
}

cbap1-authorization = {
  1: 1,
  2: 3,                         ; CBAP-1 test Authorization Artifact
  3: id16,                      ; authorization-id
  4: key-id,                    ; issuer-key-id
  5: tstr,                      ; agent-id
  6: digest,                    ; action-digest
  7: epoch,                     ; not-before
  8: epoch,                     ; not-after
  9: digest,                    ; cpo-digest
  10: id16                      ; nonce
}

cbap1-executor-verification = {
  1: 1,
  2: 4,                         ; executor verification record
  3: digest,                    ; authorization-digest
  4: id16,                      ; authorization-id
  5: digest,                    ; action-digest
  6: digest,                    ; cpo-digest
  7: 1,                         ; decision: execute
  8: epoch,                     ; verified-at
  9: id16,                      ; nonce
  10: key-id                    ; executor-key-id
}

cbap1-execution-record = {
  1: 1,
  2: 5,                         ; execution record
  3: digest,                    ; authorization-digest
  4: digest,                    ; verification-record-digest
  5: id16,                      ; authorization-id
  6: digest,                    ; action-digest
  7: 1,                         ; disposition: executed
  8: epoch,                     ; executed-at
  9: id16,                      ; nonce
  10: key-id                    ; executor-key-id
}

cbap1-bundle = {
  1: 1,
  2: bstr,                      ; cpo-cose
  3: bstr,                      ; exact-acceptance-cose
  4: bstr,                      ; authorization-cose
  5: bstr,                      ; executor-verification-cose
  6: bstr,                      ; execution-record-cose
  7: bstr,                      ; action-bytes
  8: [+ [digest, bstr]]         ; policy-digest, policy-bytes
}

The following member-label registry is normative. The names identify protocol semantics, not merely implementation variables. An implementation that assigns a listed semantic value to another label is not CBAP-1 conformant even when its producer and verifier agree with each other.¶

cbap1-terms
   1 authorization-id
   2 abp-digest
   3 authorization-trust-profile-digest
   4 authorization-issuer-key-id
   5 authorization-validity
   6 action-digest
   7 forum
   8 standing-policy
   9 procedure
  10 filing-window
  11 effect-policy
  12 selection-policy
  13 affected-party-access
  14 issued-at
  15 expires-at
  16 nonce

cbap1-cpo
   1 profile-version
   2 object-type
   3 terms
   4 exact-acceptance-reference
   5 selection-statements
   6 issuer-key-id

cbap1-exact-acceptance
   1 profile-version
   2 object-type
   3 forum-terms-digest
   4 valid-from
   5 valid-until
   6 submission-receipt-policy
   7 withdrawal-policy
   8 signed-at
   9 forum-key-id

cbap1-authorization
   1 profile-version
   2 object-type
   3 authorization-id
   4 issuer-key-id
   5 agent-id
   6 action-digest
   7 not-before
   8 not-after
   9 cpo-digest
  10 nonce

cbap1-executor-verification
   1 profile-version
   2 object-type
   3 authorization-digest
   4 authorization-id
   5 action-digest
   6 cpo-digest
   7 decision
   8 verified-at
   9 nonce
  10 executor-key-id

cbap1-execution-record
   1 profile-version
   2 object-type
   3 authorization-digest
   4 executor-verification-digest
   5 authorization-id
   6 action-digest
   7 disposition
   8 executed-at
   9 nonce
  10 executor-key-id

cbap1-bundle
   1 profile-version
   2 cpo-cose
   3 exact-acceptance-cose
   4 authorization-cose
   5 executor-verification-cose
   6 execution-record-cose
   7 action-bytes
   8 policy-pairs

In particular, executor-verification member 5 is always action-digest and member 6 is always cpo-digest. Execution-record member 5 is authorization-id and member 6 is action-digest. Reusing a semantic label number across different maps is not a CBAP-1 design rule; only the registry above assigns meaning.¶

The integer values have the following fixed meanings in CBAP-1: filing-window basis 1 is execution_time; effect mode 0 is none; affected-party access method 3 is public_transparency; forum-acceptance mode 0 is exact; executor decision 1 is execute; and execution disposition 1 is executed. An unknown integer is unsupported, not an extension point.¶

The filing-window duration-seconds value MUST be in the inclusive range 1..18446744073709551615. A zero-duration contestation window is not valid in CBAP-1 and fails at profile_binding_mismatch rather than being interpreted as an instantaneous window.¶

Policy pairs in bundle member 8 MUST be sorted in ascending bytewise order of policy-digest and MUST NOT repeat a digest. This makes the by-value bundle unique rather than treating arbitrary array order as a new encoding of the same evidence set.¶

cbap1-authorization is a deliberately small test Authorization Artifact and the mandatory ABP used only to make the base profile executable. It is not proposed as a universal agent-authorization format. Production authorization systems compose through their own ABPs.¶

4.16. CBAP-1 digest and construction rules

CBAP-1 uses these exact derivations:¶

action_digest = SHA-256(action_bytes)
policy_digest = SHA-256(policy_bytes)
terms_digest = H("agent-contestation-terms-v1", cbap1-terms)
forum_terms = [terms[1], terms[2], terms[3], terms[4], terms[5],
               terms[6], terms[7], terms[8], terms[9], terms[10]]
forum_terms_digest = H("agent-contestation-forum-terms-v1", forum_terms)
acceptance_digest = SHA-256(exact_acceptance_cose_bytes)
cpo_digest = SHA-256(cpo_cose_bytes)
authorization_digest = SHA-256(authorization_cose_bytes)
verification_record_digest = SHA-256(executor_verification_cose_bytes)

The construction order is fixed:¶

1. Fix the action bytes, policy bytes, trust inputs, identifiers, validity, forum, filing window, access method, times, and nonces.¶

2. Compute the action and policy digests and construct cbap1-terms.¶

3. Project forum_terms, compute its digest, and obtain the forum-signed exact acceptance.¶

4. Hash the complete signed acceptance and place that digest in the CPO payload.¶

5. Sign the CPO and hash the complete tagged COSE_Sign1 bytes.¶

6. Place the CPO digest in the CBAP-1 Authorization Artifact and sign it.¶

7. Hash the signed Authorization Artifact and construct the executor verification record. Place authorization-digest at label 3, authorization-id at label 4, action-digest at label 5, and cpo-digest at label 6.¶

8. Sign that record, hash it, and construct the execution record. Place authorization-digest at label 3, executor-verification-digest at label 4, authorization-id at label 5, and action-digest at label 6.¶

9. Sign the execution record and assemble the unsigned by-value bundle.¶

No step signs or hashes a placeholder for an object that is completed later. Reversing steps 3 through 8 or reconstructing a signed artifact from decoded fields changes the relevant digest and MUST fail verification.¶

4.17. CBAP-1 trust and verification inputs

The bundle is evidence, not a trust store. A CBAP-1 verifier receives separately:¶

• the expected CBAP-1 ABP digest;¶

• the expected Authorization Trust Profile digest;¶

• one issuer Ed25519 public key authorized for the kid and authorization scope;¶

• one forum Ed25519 public key authorized for the forum identifier and kid;¶

• one executor Ed25519 public key authorized for the executor kid;¶

• the controlling trust domain for each role;¶

• a verification-time input presented at the verifier boundary as an integer and validated before conversion to the CBAP-1 unsigned range.¶

The expected ABP digest is H("cbap1-authorization-binding-profile-v1", 1). The Authorization Trust Profile digest is supplied by local policy and MUST equal terms member 3; untrusted bytes carried in the bundle cannot replace it. Policy bytes in the bundle establish discoverability and digest equality only. They do not become trusted merely because the issuer supplied them.¶

The valid verification-time range is 0..18446744073709551615. A negative integer, an integer above that range, or an external representation that is not an integer fails with verification_time_invalid before any bundle byte is parsed. A public adapter MAY use a textual or wider host representation to expose this boundary, but parse and range failures MUST be converted to the closed reason. They MUST NOT cause an unhandled exception, panic, process abort, clamping, wrapping, or substitution. An internal API whose type cannot represent an invalid value does not by itself satisfy the externally observable conformance boundary.¶

CBAP-1 returns selection_provenance: unilateral, forum_acknowledgement: valid_exact, pre_execution_evidence: executor_attested, and declared_effect: none only after every corresponding signature, digest, identifier, validity, ordering, and role check succeeds. The execution record's authenticated executed-at value starts the filing window. This is an executor-signed clock claim under the supplied Executor Trust Profile, not an external wall-clock proof.¶

5.1. Direct binding

An extensible Authorization Artifact carries:¶

contestability_digest = HASH(signed_CPO_bytes)

The Authorization Artifact's signature MUST cover contestability_digest, authorization_id, and action_digest.¶

The CPO terms carry the same authorization_id, action_digest, ABP digest, and Authorization Trust Profile digest. They do not carry the final Authorization Artifact digest, avoiding a circular digest dependency.¶

The construction order is: select or create valid forum acceptance evidence; construct and sign the CPO; place the completed CPO digest in the Authorization Artifact; sign the Authorization Artifact. An executor MUST NOT accept a direct binding when the Authorization Artifact was signed before the CPO it purports to bind.¶

5.2. Companion binding statement

Where the Authorization Artifact cannot be extended, the issuer signs a Contestability Binding Statement containing:¶

{
  "type": "agent-contestability-binding-v1",
  "authorization_digest": { "alg": "sha-256", "value": "..." },
  "authorization_id": "urn:uuid:...",
  "authorization_binding_profile_digest": { "alg": "sha-256", "value": "..." },
  "authorization_trust_profile_digest": { "alg": "sha-256", "value": "..." },
  "action_digest": { "alg": "sha-256", "value": "..." },
  "cpo_digest": { "alg": "sha-256", "value": "..." },
  "issued_at": "...",
  "issuer": "...",
  "signature": "..."
}

For a deployment or profile claiming pre-execution presentation of a companion binding, the statement MUST exist before execution and MUST be presented with the authorization evidence. A post-execution statement cannot retroactively satisfy that pre-execution claim.¶

5.3. Pre-execution evidence profiles

The base verifier recognizes evidence classes rather than returning a boolean proof of enforcement.¶

An executor_attested profile uses an executor-signed verification record containing at least the Authorization Artifact digest, authorization_id, action_digest, CPO digest, verification-result digest, executor decision, nonce, claimed verification time, executor key identifier, and signature. The corresponding execution or refusal record MUST bind the verification-record digest. This establishes a signed protocol sequence under the executor key; it does not prove the physical placement or honesty of the executor's checks.¶

A transparency_prior profile uses registration evidence verified under the selected temporal profile for the CPO digest and an authenticated execution-time event. The selected temporal profile MUST establish that registration preceded the execution event under its stated clock and consistency assumptions. A timestamp copied into either object is insufficient.¶

If neither profile is present, or if its assumptions cannot be verified, the result is absent, invalid, or indeterminate as applicable. The CPO binding can remain valid.¶

5.4. Executor Effect Acceptance Statement

An active effect policy becomes executor-accepted only through a separate statement created after the Authorization Artifact and CPO are complete but before the action executes:¶

{
  "type": "agent-executor-effect-acceptance-v1",
  "authorization_digest": { "alg": "sha-256", "value": "base64url..." },
  "authorization_id": "urn:uuid:...",
  "action_digest": { "alg": "sha-256", "value": "base64url..." },
  "cpo_digest": { "alg": "sha-256", "value": "base64url..." },
  "effect_policy_digest": { "alg": "sha-256", "value": "base64url..." },
  "forum_acceptance_digest": { "alg": "sha-256", "value": "base64url..." },
  "decision": "accepted",
  "valid_until": "2026-08-12T00:00:00Z",
  "accepted_at": "2026-08-11T00:00:01Z",
  "nonce": "base64url...",
  "executor": "https://executor.example/",
  "key_id": "https://executor.example/keys/8",
  "signature": "base64url..."
}

The signature MUST verify under the exact executor key named by the effect policy and under the digest-bound Executor Trust Profile. It MUST cover every member shown above. The digests MUST resolve to the same verified Authorization Artifact, action, CPO, effect policy, and forum acceptance evidence. valid_until MUST cover the action's execution boundary and the interval during which the accepted transition can be triggered.¶

The corresponding execution or refusal record MUST bind the acceptance-statement digest. This prevents an issuer from attaching an acceptance created for a different action, policy, CPO, or forum. It also places the statement outside the CPO signature graph: the executor can accept a completed authorization without its signature being recursively included in the object it signs. accepted_at alone is not ordering evidence. The record linkage establishes an executor-signed protocol sequence; without independently authenticated ordering, it does not prove when the physical checks or action occurred.¶

A valid statement yields effect_acceptance: executor_accepted. Absence, expiry, key mismatch, digest mismatch, or signature failure MUST NOT invalidate the underlying Contestability Binding. It changes only the effect-acceptance result. Executor acceptance is an authenticated commitment under the accepted executor key to implement the bound state transition under the selected profile; it is not evidence that any trigger occurred or transition was applied.¶

5.5. Filing triggers and effect application

An accepted_filing_receipt trigger profile MUST authenticate at least the following closed projection from the forum's receipt:¶

{
  "type": "agent-contestation-filing-receipt-v1",
  "filing_id": "urn:uuid:...",
  "authorization_digest": { "alg": "sha-256", "value": "base64url..." },
  "authorization_id": "urn:uuid:...",
  "action_digest": { "alg": "sha-256", "value": "base64url..." },
  "cpo_digest": { "alg": "sha-256", "value": "base64url..." },
  "submission_digest": { "alg": "sha-256", "value": "base64url..." },
  "disposition": "accepted",
  "received_at": "2026-08-11T00:10:00Z",
  "nonce": "base64url...",
  "forum_key_id": "https://forum.example/keys/2026-1",
  "signature": "base64url..."
}

The receipt signature, time, replay, and key-continuity rules are those of the digest-bound trigger profile. The verified forum acceptance evidence MUST authenticate that same profile and forum key. authorization_digest binds the receipt to the completed signed Authorization Artifact and prevents a receipt created before issuance from triggering a later artifact that reuses the same identifier, action, and CPO. A receipt with disposition: refused is evidence of refusal, not an effect trigger. An accepted receipt yields effect_trigger: valid only for the exact Authorization Artifact, action, CPO, filing, profile, and effect policy to which it is applied.¶

After verifying a valid trigger, the executor can issue an Effect Application Record:¶

{
  "type": "agent-effect-application-record-v1",
  "authorization_digest": { "alg": "sha-256", "value": "base64url..." },
  "authorization_id": "urn:uuid:...",
  "action_digest": { "alg": "sha-256", "value": "base64url..." },
  "cpo_digest": { "alg": "sha-256", "value": "base64url..." },
  "effect_policy_digest": { "alg": "sha-256", "value": "base64url..." },
  "effect_acceptance_digest": { "alg": "sha-256", "value": "base64url..." },
  "filing_receipt_digest": { "alg": "sha-256", "value": "base64url..." },
  "idempotency_key": "base64url...",
  "previous_state_commitment": { "alg": "sha-256", "value": "base64url..." },
  "new_state_commitment": { "alg": "sha-256", "value": "base64url..." },
  "sequence": 418,
  "disposition": "applied",
  "reason": "bound-fence-entered",
  "recorded_at": "2026-08-11T00:10:01Z",
  "executor": "https://executor.example/",
  "key_id": "https://executor.example/keys/8",
  "signature": "base64url..."
}

The disposition is one of applied, refused, too_late, already_applied, or failed. reason is a closed code defined by the state-machine profile, not free text. applied MUST carry the previous and new state commitments and the authenticated sequence at which the transition committed. already_applied MUST carry a prior_application_digest that resolves to the first valid application record for the same idempotency key. Other dispositions MUST follow the profile's closed rules for whether a current-state commitment is present and MUST NOT manufacture a new-state commitment. An application after the authenticated deadline MUST be too_late unless the bound policy defines a deterministic exception. The record MUST bind the same Authorization Artifact, CPO, policy, acceptance, and receipt; MUST verify under the accepted executor key; and MUST satisfy the policy's idempotency and serialization profiles. For the same idempotency key, at most one application record can contribute a successful transition result under the bound profile; a later valid record MUST resolve to already_applied or to an equivocation condition rather than a second successful application. Conflicting validly signed records are equivocation evidence and yield effect_application: indeterminate unless the selected profile deterministically resolves them.¶

For hold_before_execution, the application record and its sequence MUST precede the execution boundary, and the subsequent executor record MUST carry the bound hold or refusal disposition and MUST bind the application-record digest. For fence_after_execution, the application sequence MUST follow action execution and precede the bound finality boundary. A wall-clock comparison alone is insufficient where concurrent transitions are possible. Without verified serialization evidence, a verifier MUST NOT report the transition as ordered even if all timestamps and signatures validate.¶

An Effect Application Record proves that the accepted executor key made the signed claim. It does not prove physical state, performance by another system, or legal effect. applied means only that the record and its state transition verify under the bound state-machine and serialization profiles. It MUST NOT be translated into reversed, remedied, or restored.¶

6.1. Selection provenance

The verifier derives exactly one value:¶

• unilateral: only the authorization issuer selected or authenticated the forum;¶

• multiparty: every selector role required by the local selection profile signed the same selection_input;¶

• external: a locally trusted external Selection Authority selected or authenticated the forum under the referenced policy;¶

• indeterminate: evidence is missing, invalid, ambiguous, or unsupported.¶

multiparty and external describe authenticated selection provenance. Neither means independent.¶

6.2. Structured result

{
  "binding": "valid | invalid",
  "pre_execution_evidence": "executor_attested | transparency_prior | absent | invalid | not_claimed | indeterminate",
  "discoverability": "complete | incomplete",
  "forum_acknowledgement": "valid_exact | valid_class | invalid_scope | invalid | absent | indeterminate",
  "forum_operational_status": "reachable | unreachable | not_checked | indeterminate",
  "selection_provenance": "unilateral | multiparty | external | indeterminate",
  "access_binding": "valid | invalid | not_claimed | indeterminate",
  "notice_evidence": "issued | delivered | invalid | absent | not_claimed | indeterminate",
  "retrievability": "available | unavailable | not_checked | indeterminate",
  "filing_window_status": "not_open | open | closed | indeterminate",
  "policy_freshness": "current | stale | indeterminate",
  "declared_effect": "none | hold_before_execution | fence_after_execution | invalid | unsupported",
  "effect_acceptance": "executor_accepted | absent | invalid | not_required | indeterminate",
  "effect_trigger": "valid | refused | invalid | not_observed | not_applicable | indeterminate",
  "effect_ordering": "verified | invalid | not_evidenced | not_applicable | indeterminate",
  "effect_application": "executor_claimed_applied | executor_claimed_refused | too_late | already_applied | failed | invalid | not_observed | not_applicable | indeterminate",
  "reasons": ["closed reason codes"]
}

access_binding reports the integrity and selected-profile status of the declared affected-party access methods. It is valid when the required access declarations are present, covered by the verified CPO binding and signature, and satisfy the selected access-profile constraints; invalid when a required declaration or binding fails; not_claimed when the selected profile makes no affected-party access claim; and indeterminate when required evidence or profile interpretation cannot be completed. It does not report delivery or current retrievability.¶

policy_freshness is current only when a selected policy-freshness profile supplies authenticated freshness, version, or expiry rules and all required policy material satisfies them; stale only when such a profile is evaluable and its bound rule classifies required material as stale; and indeterminate when no selected freshness profile exists or its required evidence cannot be evaluated. CBAP-1 defines no policy-freshness profile and therefore returns indeterminate on its positive path.¶

Every named profile that instantiates the Section 6.2 structured result MUST define a closed vocabulary for reasons and a deterministic rule for populating and ordering that array on negative results. CBAP-1 defines its closed reason vocabulary and first-failure precedence in the CBAP-1 failure-precedence section below, and requires reasons: [] on its positive path.¶

A conforming implementation MUST NOT collapse this result into contestable: true or independent: true without applying an explicitly identified local policy. In particular, forum_acknowledgement: valid_exact does not imply forum_operational_status: reachable; notice_evidence: issued does not imply human receipt; effect_acceptance: executor_accepted does not imply that a filing occurred; effect_trigger: valid does not imply application; and effect_application: executor_claimed_applied does not prove physical state or remedy. An effect failure does not invalidate the contestation path unless a separate local policy expressly requires the effect as a condition of reliance.¶

6.3. Effect-result derivation

The effect fields are derived independently. At minimum, a verifier applies the following rules:¶

The penultimate positive row is intentionally non-collapsed: it reports what the executor key claimed while refusing to report that the claim was correctly ordered against execution or finality. A user interface MUST NOT present that tuple as an effective hold or fence. Evidence supplied for an active transition when the declared mode is none is ignored for effect semantics. An implementation SHOULD retain an unexpected_effect_evidence operator diagnostic outside the reasons array; it does not alter the bound declaration.¶

6.4. CBAP-1 verification procedure

In addition to the generic algorithm, a CBAP-1 verifier performs the following closed procedure in order:¶

1. Validate the verification-time input as an integer in 0..18446744073709551615. Return verification_time_invalid on a parse, type, sign, or range failure without parsing the bundle.¶

2. Parse the outer bundle without accepting duplicate keys, indefinite-length items, non-shortest arguments, disallowed tags or simple values, floats, invalid UTF-8, unknown members, values outside cbap1-bundle, or any declared length that cannot be consumed with checked cursor arithmetic. Re-encode the parsed bundle under Section 4.13 and require byte-for-byte equality.¶

3. Require every policy pair to contain exactly one 32-byte digest and one byte string. Reject duplicate policy digests. Recompute SHA-256 over each policy byte string and require equality. At this step only the internal shape, order, uniqueness, and digest integrity of the policy set are evaluated; referenced-policy presence is evaluated after the signed payloads are validated.¶

4. Parse each object byte string as exactly one tagged COSE_Sign1 object. Require the protected and unprotected header rules of Section 4.14, an embedded deterministic payload, a recognized profile version and object type, and exact kid equality between the protected header and payload signer field.¶

5. Resolve each kid in the supplied trust profile to exactly one Ed25519 public key authorized for the required issuer, forum, or executor role. Verify every signature over the received protected and payload bytes with empty external AAD.¶

6. Recompute action_digest from the bundle's action bytes. Require the same digest at terms label 6, Authorization Artifact label 6, executor-verification label 5, and execution-record label 6.¶

7. Require the CPO terms to use the expected CBAP-1 ABP digest and Authorization Trust Profile digest. Require effect policy [0], filing-window basis [1, duration] with duration in 1..18446744073709551615, at least one public-transparency access entry, an empty selection-statement array, by-value bytes for every policy referenced by the CPO and Exact Forum Acceptance, conforming HTTPS URIs, and all other single-object CBAP-1 profile constraints not assigned below to a cross-object boundary. Do not compare the Authorization Artifact projection or any signed-artifact digest at this step.¶

8. Require the Authorization Artifact's authorization identifier, issuer key, action digest, and validity projection to equal the corresponding CPO terms. Do not compare its CPO digest at this step.¶

9. Project forum_terms exactly as Section 4.16 specifies. Verify its digest in the forum's exact acceptance, the forum signature and key, and the equality of the CPO forum key and acceptance signer key.¶

10. Hash the complete signed exact acceptance and require equality with the CPO acceptance reference.¶

11. Hash the complete signed CPO and require equality with the Authorization Artifact's CPO digest.¶

12. Hash the complete signed Authorization Artifact and require equality at executor-verification label 3 and execution-record label 3.¶

13. Verify the executor verification record, require decision execute, and require its authorization identifier at label 4, action digest at label 5, CPO digest at label 6, executor key, nonce, and verified-at value to match the bound objects and profile.¶

14. Hash the complete signed executor verification record. Verify the execution record and require that digest at label 4, the authorization digest at label 3, authorization identifier at label 5, action digest at label 6, executor key, nonce, and disposition executed all match.¶

15. Require not-before <= verified-at <= executed-at <= not-after.¶

16. Compute filing_deadline = executed-at + duration-seconds with checked unsigned arithmetic. Require the Exact Forum Acceptance signed-at <= not-before, valid-from <= not-before, and valid-until >= filing_deadline; require CPO issued-at <= verified-at and expires-at >= filing_deadline; and require at least one declared access method with available-until >= filing_deadline. Compare the supplied verification time with executed-at and the deadline to derive not_open, open, or closed.¶

17. Return every Section 6.2 field independently. The positive CBAP-1 path yields binding: valid, pre_execution_evidence: executor_attested, discoverability: complete, forum_acknowledgement: valid_exact, forum_operational_status: not_checked, selection_provenance: unilateral, access_binding: valid, notice_evidence: not_claimed, retrievability: not_checked, policy_freshness: indeterminate, declared_effect: none, effect_acceptance: not_required, effect_trigger: not_applicable, effect_ordering: not_applicable, effect_application: not_applicable, and reasons: []; filing_window_status is derived as not_open, open, or closed from the supplied verification time. It does not yield forum reachability, delivery, independence, policy fairness, or physical execution order.¶

A deterministic-encoding, COSE structure, signature, required role, action digest, CPO digest, authorization digest, verification-record digest, identifier, validity, or ordering failure MUST produce a closed reason code identifying the first failed boundary. The implementation MUST continue to keep unrelated higher-level results separate where the failed input still permits them to be evaluated safely.¶

6.5. CBAP-1 failure precedence and reason codes

CBAP-1 closes the externally observable failure boundary. On the positive path, reasons MUST be the empty array. On a negative path, reasons MUST contain exactly one of the codes in the table below: the first failing boundary under the stated precedence. An implementation MAY retain more detailed diagnostics for operators, but it MUST NOT place implementation-specific strings in reasons or substitute a later, more specific failure for the first one.¶

The verifier evaluates local input 1 first, then the outer item, the policy set, and the five signed objects in table order. Within a signed object it evaluates: tagged COSE_Sign1 shape; protected and unprotected headers; embedded deterministic payload; closed payload schema; protected-to-payload kid equality; unique role-authorized trust resolution; and signature. Within a closed map, member constraints are evaluated in ascending numeric-label order. Within a list, items are evaluated from index zero upward. Cross-object checks then follow precedence 10 through 21.¶

The first-reason rule is a reproducibility rule, not permission to collapse the Section 6.2 result. A verifier still evaluates independently derivable fields when doing so is safe. Fields that depend on the failed boundary take their existing invalid, incomplete, indeterminate, or not_checked value. In particular, policy_set_invalid does not by itself prove binding: invalid, and a reachability failure is outside this closed CBAP-1 byte-verification procedure.¶

8.1. Maturity and coverage

As of 12 August 2026, CBAP-1 has a Python reference implementation, an oracle-blind Rust reconstruction produced with AI-based coding assistance in a context-isolated session, and a JavaScript cross-check. The cross-check re-encoded the positive bundle byte-for-byte and verified all five Ed25519 signatures. The shared positive bundle has SHA-256:¶

8a47e89abb2c77a9de27ffb59a5bc89a7226509236e35b0f11cf6819fd1b6646¶

The reconstruction received the specification and its declared public inputs without evaluator answers. The evidence record distinguishes mechanical byte access for integrity hashing from semantic evaluator access: before the relevant implementation freeze, no evaluator case was decoded, semantically inspected, or executed, and expected outcomes and reasons remained withheld.¶

The first frozen reconstruction assigned two digest labels differently from the retained evaluator and failed bidirectional verification at that boundary. The supplied challenge text had typed both members without assigning their labels in normative prose. That divergence was recorded before repair, and the original submission remains frozen at SHA-256:¶

956b88d2832e4265913cb73f93e69b960ef6f1d860f8acbc5b50ea453cbab2f0¶

After the assignment and other attributable ambiguities were repaired in the specification, the final A3 source-and-artifact package was frozen at SHA-256:¶

f2b9b0745ca8b751322f416ed62e73769b2396934b8beb811d5f71b4fc88b129¶

The reconstruction passed 56 local tests. It matched the retained evaluator outcomes for the positive byte vector, the closed failure-precedence corpus, and all 28 URI cases. The URI result comprised eight valid acceptances and 20 profile_binding_mismatch rejections, with each case invoked once. Additional differential checking of 255,022 generated IPv6 candidates found no divergence.¶

8.2. Provenance and limits

Automated tools could propose source, test, and analysis candidates, but did not assign evaluator outcomes. Recorded outcomes were determined under pinned rules and inputs after the corresponding implementation state had been frozen. The document author controlled the specification, evaluator design, retained inputs, and adjudication. The experiment therefore tests specification reconstructibility, ambiguity detection, and bounded behavioural agreement; it does not establish independence of authorship or evaluation.¶

The results do not constitute an independent human implementation, external review, interoperability certification, production deployment evidence, exhaustive parser safety, or a security audit.¶

8.3. Availability, license, and contact

A stable public location and an explicit software license for the implementation and evidence packages are to be designated as part of the verifiable release publication that follows this submission. Until then, this section records development evidence but does not claim public implementation or evidence-package availability.¶

Implementation and test-package contact: Tiago Pinto tiago@donttrustverify.pt.¶

9.1. Issuer-controlled forum

A discoverable forum can still be captured. An issuer-only signature therefore yields unilateral, never external or multiparty.¶

9.2. Forum substitution

The forum identifier, endpoint, verification key, procedure, and selection policy are digest- or signature-bound. A verifier MUST refuse substitution after authorization.¶

9.3. Policy equivocation

Serving different CPOs or policy documents to different audiences can move the fork from the authorization to the contestation layer. Deployments claiming cross-audience consistency SHOULD register CPOs or their digests in a transparency service and MUST define how readers detect split views.¶

9.4. Dead or selective endpoint

Cryptographic binding and forum acknowledgement do not prove availability. A forum can refuse connections, selectively deny classes of filers, or disappear after signing. Availability evidence and service-level enforcement are deployment concerns. Discoverability MUST become incomplete when required material cannot be obtained within local policy. A failed reachability check MUST NOT retroactively invalidate a historically valid acknowledgement; the results remain separate.¶

9.5. Deadline capture

An issuer can declare a filing window too short to use. Verification authenticates the declared filing-window inputs and computes the window; it does not establish fairness. Relying parties SHOULD apply minimum-window policy and MUST NOT infer legitimacy from syntactic validity.¶

9.6. Standing capture

A Standing Policy can exclude the person most affected by an action. This document makes the policy identity stable and, when the policy bytes are available, inspectable; it does not make the policy legitimate. Profiles claiming affected-party recourse MUST specify how affected parties are represented without requiring them to have participated in the original authorization.¶

9.7. Privacy

Enumerating affected persons in a public CPO can create a privacy and safety risk. Standing SHOULD be expressed by role or policy where possible. Personally identifying evidence SHOULD be disclosed only to the forum under an appropriate confidentiality mechanism.¶

9.8. Contestation as denial of service

Attackers can submit repetitive or fabricated filings. Anti-replay, rate limiting, authentication, and abuse controls MUST NOT silently alter the bound standing policy or filing window.¶

9.9. Credential self-revocation trap

An action can disable the only credential accepted by the contestation lookup or forum. An account-suspension action followed by an account-login-only contestation path is the canonical case. Profiles claiming affected-party access MUST define a surviving method, such as a separately delivered capability, an alternate verified identity, or a privacy-preserving public lookup. Merely declaring an authentication profile does not prove survivability.¶

9.10. Acknowledgement replay and class confusion

An issuer can replay genuine forum acceptance evidence issued for a different ABP, Authorization Trust Profile, policy version, binding interval, or submission endpoint. Exact acknowledgements MUST match the forum_terms_digest. A FAM MUST bind accepted ABP and Authorization Trust Profile digest pairs, and the Authorization Artifact MUST be successfully verified and projected under a listed pair. Matching labels or URIs are insufficient. Failure to establish membership yields invalid_scope, not valid_class.¶

9.11. Notice issuance versus delivery

A signer can generate a valid Contestability Notice and never transmit it. The base result is therefore issued, not delivered. A delivered result requires an authenticated transport-specific receipt that identifies the same notice digest and intended delivery context. No protocol receipt proves that a human read or understood the notice.¶

9.12. Notice phishing and correlation

A malicious notice can direct an Affected Party to an attacker-controlled endpoint or can use predictable authorization identifiers to expose sensitive actions. The notice MUST bind the CPO digest and authenticated access method. Deployments SHOULD use unguessable lookup capabilities or privacy-preserving authenticated retrieval when public correlation would reveal sensitive information.¶

9.13. Backdating and enforcement illusion

An issuer can construct a valid CPO after execution and backdate issued_at. Signatures establish integrity and signer attribution, not when an executor possessed an object. A profile claiming pre-execution enforcement MUST carry authenticated ordering evidence from the enforcement path. Without it, the binding can remain cryptographically valid while pre_execution_evidence is absent. Even executor_attested proves only the executor key's signed claim and digest bindings, not the physical order of events inside the executor.¶

9.14. Exact-acceptance disclosure

Exact acceptance exposes at least a stable terms digest and interaction timing to the forum before authorization. Depending on the action space, an unsalted action digest can also permit dictionary attacks. Deployments SHOULD prefer a class manifest when instance-specific acceptance is unnecessary, SHOULD register only a CPO or manifest digest in public transparency infrastructure, and SHOULD use profile-defined salted commitments for low-entropy action data where cross-artifact verification remains possible.¶

9.15. Manifest equivocation and downgrade

A forum can issue different FAMs to different audiences or replace a restrictive manifest with a broader one. The CPO and selection signatures bind one exact manifest digest, so substitution fails locally. Cross-audience detection requires transparency or gossip under a selected profile. A verifier MUST NOT select a newer, broader, or more available manifest in place of the digest bound by the CPO.¶

9.16. Forum-key rotation and compromise

Key rotation MUST NOT permit a new forum key to rewrite old acceptance evidence. Historical verification requires the key that signed the exact statement or manifest, its validity evidence at signing time, and the selected compromise policy. A successor key can sign a new manifest or a continuity statement only under the previously bound withdrawal policy. A current key-discovery response alone is insufficient to validate a historical signature.¶

9.17. Signature multiplicity and common control

Multiple signatures do not necessarily represent multiple independent parties. An issuer can operate separate issuer, forum, and selector keys. Selection provenance therefore depends on role authorization and controlling trust domains supplied by local policy, not signature count. Three keys under one controlling party MUST NOT be reported as multiparty merely because all three signatures verify.¶

9.18. False automatic-effect advertising

An issuer can publish an active effect policy while naming an executor that never agreed to implement it. The CPO signature authenticates that advertisement but not executor acceptance. Without a valid Executor Effect Acceptance Statement, effect_acceptance is absent or invalid; an implementation MUST NOT display the action as automatically held, fenced, stayed, or reversible. If the executor accepted and later ignores a valid trigger, the acceptance remains valid while application is not_observed, failed, or indeterminate as the evidence permits. Nonperformance MUST NOT be rewritten as a binding failure.¶

9.19. Trigger replay and profile substitution

A valid filing receipt can be replayed against another authorization, CPO, policy, executor, or state transition. All identifiers and digests in Sections 5.4 and 5.5 MUST match, and the bound idempotency profile MUST make repeated processing deterministic. A receipt created under a different forum key or submission-receipt profile is not a trigger even if the bytes describe the same filing. Reusing a valid trigger to create multiple transitions yields already_applied or an equivocation condition, not multiple applications.¶

9.20. Race with execution or finality

An attacker or merely concurrent system can cause the filing trigger and the execution or finality transition to cross between verification and application. Signed timestamps do not solve this time-of-check/time-of-use race. An active effect profile MUST bind a serialization mechanism enforced by the system of record, such as an authenticated monotonic sequence, compare-and-swap precondition, or atomic transaction. If the verifier cannot establish the required ordering, effect_ordering is not_evidenced or indeterminate, even when the executor signed disposition: applied.¶

9.21. Filing-trigger denial of service

An automatic hold can let inexpensive filings block expensive or urgent actions. The trigger profile can authenticate submissions, rate limits, deposits, or eligibility gates, but those controls MUST be bound before execution and MUST NOT silently change the Standing Policy or filing window. A forum receipt authenticates a record that the filing was accepted under the forum profile; it does not prove that the filer deserved to stop the action. Deployments SHOULD prefer fence_after_execution or none where pre-execution holds create unacceptable safety or availability risk.¶

9.22. Ambiguous state commitments

An executor can claim applied while committing to a state encoding whose meaning is mutable, partial, or compatible with both fenced and unfenced outcomes. The state-machine profile and target-state digest MUST define the committed state and transition unambiguously. Unsupported, lossy, or non-deterministic state projection yields effect_application: indeterminate or invalid; signature validity alone is insufficient.¶

9.23. Effect is not remedy

A hold result is satisfied only when the bound evidence records the profile-defined hold state and the required ordering places that record before the execution boundary. A fence result is satisfied only when the bound evidence records the profile-defined fence state and the required ordering places that record after execution and before the finality boundary. Neither result proves reversal of earlier observations, compensates an Affected Party, determines liability, or authorizes a new action. Implementations MUST NOT label an Effect Application Record as an award, reversal, restoration, refund, or remedy unless a separate protocol and authorization establish that result.¶

9.24. Executor equivocation and common control

An executor can sign conflicting application records or share control with the issuer and forum. Conflicting records for the same idempotency key and sequence are equivocation evidence. Common control does not invalidate the signatures, but it weakens the governance inference a relying party may draw from them. This protocol reports authenticated role statements and never upgrades them to independent enforcement.¶

9.25. Split-control illusion

An Effect Executor can accept a hold or fence while lacking authority over the action executor or finality state. A message bus subscription or advisory callback is not control of the transition. When the parties differ, the serialization profile MUST bind the cross-system state machine, signer roles, and atomic or fail-closed handoff. Without that evidence, effect_acceptance can remain executor_accepted, but effect_ordering is not_evidenced or invalid and no effective hold or fence can be reported.¶

10.1. EMILIA Protocol artifacts

EP authorization receipts [I-D.schrock-ep-authorization-receipts] bind human evidence to an action and record authorization lifecycle facts. Other EP artifacts describe outcome, revocation, remedy, and reliance evidence.¶

This document specifies a transport-independent, pre-execution binding from an authorization to the contestation path, with a derived statement of forum-selection provenance. It neither replaces nor requires EP.¶

10.2. Agentic Dispute Protocol and ADRP

The Agentic Dispute Protocol [I-D.kotecha-agentic-dispute-protocol] defines filing, evidence, adjudication, awards, and arbitrator discovery. ADRP [I-D.stone-adrp] defines an Arbitration Mandate, dispute state machine, arbitrator pool, rulings, appeals, and remedy directives.¶

This document does none of those things. A CPO can identify an ADP or ADRP endpoint and procedure. Its contribution is the binding and verification layer that exists before either dispute protocol begins, including the distinction between issuer-declared and non-unilateral forum selection.¶

10.3. OAuth and agent authorization frameworks

OAuth Rich Authorization Requests [RFC9396], WIMSE-based guidance, and agent authorization frameworks such as [I-D.liu-ai-agent-authorization-integration] address request scope, identity, delegation, policy, consent, and lifecycle. A future profile can carry a CPO digest in an OAuth authorization detail or token. This document does not extend OAuth in its base version.¶

10.4. SCITT

A CPO or companion binding statement can be registered as a SCITT Signed Statement [RFC9943]. SCITT registration can improve discoverability and equivocation detection but does not prove forum independence, policy fairness, or legal validity.¶

10.5. RATS and COSE

The reusable FAM has a role analogous to an endorsement in the RATS architecture [RFC9334]: a role-specific signer vouches for defined capabilities or scope, while the relying party applies its own policy. It is not attestation evidence and does not appraise a runtime. CBAP-1 selects tagged COSE_Sign1 with embedded payloads and fully specified Ed25519 signatures. It does not use COSE_Sign multi-signatures: each role emits a separate signed statement so that signature topology and failure attribution remain explicit.¶

12.1. Normative References

[RFC2119]

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

[RFC3986]

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

[RFC6234]

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

[RFC8032]

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

[RFC8174]

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

[RFC8610]

Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, <https://www.rfc-editor.org/rfc/rfc8610>.

[RFC8949]

Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://www.rfc-editor.org/rfc/rfc8949>.

[RFC9052]

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

[RFC9053]

Schaad, J., "CBOR Object Signing and Encryption (COSE): Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053, August 2022, <https://www.rfc-editor.org/rfc/rfc9053>.

[RFC9110]

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

[RFC9864]

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

12.2. Informative References

[I-D.kotecha-agentic-dispute-protocol]

Kotecha, V., "Agentic Dispute Protocol", Work in Progress, Internet-Draft, draft-kotecha-agentic-dispute-protocol-00, 13 October 2025, <https://datatracker.ietf.org/doc/html/draft-kotecha-agentic-dispute-protocol-00>.

[I-D.liu-ai-agent-authorization-integration]

Liu, D., Zhu, J., Krishnan, S., Parecki, A., and H. Xue, "AI Agent Authorization Integration Framework", Work in Progress, Internet-Draft, draft-liu-ai-agent-authorization-integration-00, 6 July 2026, <https://datatracker.ietf.org/doc/html/draft-liu-ai-agent-authorization-integration-00>.

[I-D.schrock-ep-authorization-receipts]

Schrock, I., "Authorization Receipts for High-Risk Agent Actions", Work in Progress, Internet-Draft, draft-schrock-ep-authorization-receipts-12, 16 August 2026, <https://datatracker.ietf.org/doc/html/draft-schrock-ep-authorization-receipts-12>.

[I-D.stone-adrp]

Stone, B. E. N. S. S. T. O. N., "ADRP: Agent Dispute Resolution Protocol", Work in Progress, Internet-Draft, draft-stone-adrp-00, 25 April 2026, <https://datatracker.ietf.org/doc/html/draft-stone-adrp-00>.

[RFC6874]

Carpenter, B., Cheshire, S., and R. Hinden, "Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers", RFC 6874, DOI 10.17487/RFC6874, February 2013, <https://www.rfc-editor.org/rfc/rfc6874>.

[RFC7049]

Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, <https://www.rfc-editor.org/rfc/rfc7049>.

[RFC7942]

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

[RFC9334]

Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, <https://www.rfc-editor.org/rfc/rfc9334>.

[RFC9396]

Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, May 2023, <https://www.rfc-editor.org/rfc/rfc9396>.

[RFC9844]

Carpenter, B. and R. Hinden, "Entering IPv6 Zone Identifiers in User Interfaces", RFC 9844, DOI 10.17487/RFC9844, August 2025, <https://www.rfc-editor.org/rfc/rfc9844>.

[RFC9943]

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