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

1.4. Protocol requirements

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.5. Adversarial survival tests for R4 and R6

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

1.6. 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 identifier 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. CPO time terms

issued_at is the CPO issuer's authenticated claimed issuance time for the terms. It does not establish external ordering, delivery, publication, or executor possession. expires_at is the issuer-declared expiration bound for those terms.¶

An executable profile that uses either field in a validity decision MUST identify the authenticated comparison event or time, the exact comparison predicate, and the failure classification. A profile MUST NOT treat issued_at as a filing-window event class unless that event class is separately authenticated under the selected filing-window profile. CBAP-1 defines its concrete comparisons in Section 6.4.¶

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

4.3. Forum information

forum.id, submission_endpoint, and verification_key_id MUST be present. A human-readable name alone is insufficient. A deployment that sends a filing to submission_endpoint MUST use authenticated transport. This is an operational transport requirement, not by itself a verification predicate; successful network access does not establish forum independence. For generic evaluation of forum_operational_status, the base document explicitly delegates an optional Forum Operational Status Profile selected and accepted by trusted local verifier policy, not by the CPO issuer; the authenticated CPO supplies only the exact forum.submission_endpoint target. The selected profile MUST completely define the exact observation/evidence object, its integrity or authentication and trusted observation authority, URI/redirect/DNS/transport handling, observation time and freshness relative to verification_time, the exact predicates that distinguish reachable from unreachable, and a deterministic reduction rule when multiple observations exist. A verifier MUST NOT silently perform network I/O or substitute another endpoint, probe convention, timeout, retry rule, trust source, or success criterion. forum_acknowledgement and retrievability are separate result dimensions and MUST NOT by themselves establish forum_operational_status. No selected operational-status profile yields forum_operational_status: not_checked; a selected profile with admissible evidence proving its success predicate yields reachable, admissible evidence proving its failure predicate yields unreachable, and a selected profile whose required evidence or semantics are absent, invalid, stale, ambiguous, unsupported, non-reducible, or otherwise not deterministically evaluable yields indeterminate. Missing evidence alone MUST NOT be classified as unreachable. CBAP-1 defines and selects no Forum Operational Status Profile and therefore forum_operational_status remains not_checked on every CBAP-1 path.¶

forum_acceptance has exactly three base modes: none, exact, and class_manifest. The none mode is the closed object { "mode": "none" } and MUST contain no acceptance-evidence digest member; it means this authenticated CPO names a forum but binds no Forum Acceptance Evidence. The exact mode identifies an Exact Forum Acceptance Statement by digest and the class_manifest mode identifies a Forum Acceptance Manifest by digest. For none, no acceptance_digest or forum_acceptance_digest exists and forum_acknowledgement is absent; missing, invalid, unsupported, or otherwise unevaluable evidence required by exact or class_manifest MUST NOT be reclassified as absent. The accepted input in the evidence-bearing modes 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. For exact acceptance, inclusion of authorization issuer, authorization validity, and action digest in forum_terms means only that those projected values are within the forum's acknowledged scope; the forum signature does not authenticate the Authorization Artifact that supplied them or establish issuer authority for the action. A CPO signed with forum_acceptance.mode = none cannot be upgraded in place by attaching later acceptance evidence: changing the mode or adding an acceptance digest changes the signed CPO and therefore requires a new CPO and corresponding authorization binding.¶

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 identifier 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. The base verifier defines no replacement-forum continuity exception to that valid_until predicate. A bound withdrawal policy MAY describe an intended operational handoff or replacement-forum continuity procedure, and deployments SHOULD plan for continuity when a forum withdraws, becomes unavailable, or transfers responsibility, but that operational guidance does not satisfy, extend, or replace the base valid_until requirement. A future extension MAY make replacement continuity verifier-relevant only by defining authenticated predecessor and replacement identities, authorization/scope linkage, continuity and ordering semantics, trust inputs, a deterministic verifier predicate, and a failure classification. For class acceptance, the verifier MUST require the executable authorization-validity interval from successful ABP projection to be wholly contained within may_bind_from through may_bind_until, inclusive, as specified in Section 4.11. Those FAM bounds do not establish the creation, signing, binding, or first-reference time of the Authorization Artifact or companion binding statement. The CPO filing-window duration admitted by a FAM MUST NOT exceed the FAM maximum_filing_horizon_seconds; that field is a duration bound, not an absolute deadline. A later withdrawal MUST NOT by itself erase or rewrite a historical forum acknowledgement: if the original Exact Forum Acceptance or FAM still verifies under the applicable historical trust and compromise semantics, forum_acknowledgement MUST retain the result established by that original evidence. Evidence that the original acceptance key was not valid or authorized at the relevant signing time is a failure of the historical acceptance evidence and is distinct from a later withdrawal. The bound withdrawal-policy URI+digest identifies the policy under which a deployment MAY evaluate withdrawal or continuity; that reference alone does not establish that a withdrawal occurred. The exact verified policy MAY define or identify the versioned withdrawal or continuity profile to be used; a verifier MUST NOT substitute an unbound local profile for one selected by the bound policy. A profile that claims verifier-evaluated withdrawal or continuity MUST verify the exact bound withdrawal-policy bytes and digest and MUST completely define the withdrawal or continuity evidence object, event type and closed schema, signer or key authority, binding to the affected forum and acceptance evidence, authenticated event time or ordering evidence, ordering relative to execution when an after execution claim is made, predecessor/successor linkage where continuity is claimed, a closed profile-specific result vocabulary, and deterministic failure classification for missing, invalid, ambiguous, conflicting, stale, unsupported, or non-comparable evidence. Without such a supported profile and its required evidence, the base verifier makes no withdrawal or continuity-status claim and MUST NOT alter forum_acknowledgement, filing, effect, or replacement-forum semantics merely from the policy reference. Any profile-specific withdrawal or continuity result is separate from the Section 6.2 base structured result and MUST NOT overwrite forum_acknowledgement, forum_operational_status, or retrievability. The filing-receipt profile identifies the authenticated response a conforming forum returns after accepting or refusing a filing; for FAM class acceptance it is authenticated forum metadata, not a CPO class-comparison operand. This document does not otherwise define the filing exchange.¶

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

In the base protocol, a CPO with forum_acceptance.mode = none MUST use effect_policy.mode = none; a disclosure-only CPO cannot claim a base active effect because no authenticated forum-acceptance digest or forum-authenticated filing-receipt profile exists for the R8 active-effect binding. For effect_policy.mode = 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://pf.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://pf.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://pf.example/profiles/trigger-idempotency/1",
    "digest": { "alg": "sha-256", "value": "base64url..." }
  },
  "serialization_profile": {
    "uri": "https://pf.example/profiles/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, trigger_profile.event MUST select that event class, and the profile reference formed by trigger_profile.uri and trigger_profile.digest MUST equal, as one exact URI+digest pair, the submission_receipt_profile URI+digest pair authenticated by the verified forum acceptance evidence. Both components MUST match exactly; a verifier MUST NOT use digest-only equality, URI-only equality, URI normalization, a local alias, or another profile identifier in place of that bound pair. The receipt time MUST fall within the verified filing window and the effect mode's transition interval. The base active-effect profile defines no grace exception; a procedure document alone and the closed base Effect Policy do not extend either interval. 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 Executor Trust Profile identifier selected by the Effect Policy. The verifier MUST require that identifier to be accepted through trusted local policy and MUST resolve the named executor under that profile's trust inputs and authority rules. Carrying the identifier does not itself authorize the 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.¶

For Executor Effect Acceptance validity, the selected active-effect profiles MUST provide or deterministically derive authenticated temporal values in one common totally ordered comparison domain. Let E be the authenticated action execution-boundary time and W the verified filing-window closing time. For fence_after_execution, let F additionally be the authenticated finality-boundary time. If any source profile can yield multiple authenticated candidate values for E, W, or F, it MUST first apply an explicit deterministic selection or aggregation rule that reduces that source to exactly one value; a verifier MUST NOT invent an unstated earliest, latest, arrival-order, array-order, or other local reduction convention. If the values originate from different temporal bases, profiles, or evidence classes, the selected profile composition MUST additionally define a deterministic conversion or comparison rule that places them in one common totally ordered domain before any min, max, <=, or >= operation is evaluated.¶

For hold_before_execution, the trigger interval is the verified filing window intersected with the interval before E, its upper bound is min(W, E), and effect_acceptance_required_until = E. For fence_after_execution, the trigger interval is the verified filing window intersected with the interval after E and before F, its upper bound is min(W, F), and effect_acceptance_required_until = max(E, min(W, F)). These formulas define validity coverage only; they do not make an otherwise-exclusive trigger boundary inclusive. A profile that defines only relative ordering such as before execution or before finality, but cannot expose or deterministically derive the required authenticated E or F value in the common comparison domain, cannot satisfy this validity-horizon rule and yields effect_acceptance: indeterminate unless another already-defined earlier failure classification applies. The same result applies when a required reduction or cross-profile comparison rule is undefined, or when authenticated evidence cannot produce exactly one comparable value for every boundary required by the selected mode. A signed wall-clock field, local receipt time, recorded_at, issuer time, or other clock MUST NOT silently substitute for a required authenticated boundary.¶

For the base active-effect profile, application_deadline.basis MUST be the exact value authenticated_trigger_time. Let T be exactly one authenticated trigger-time value, let Delta be application_deadline.duration_seconds, let D be the application deadline derived from T and Delta, and let U be exactly one authenticated application-transition value. The selected trigger profile MUST derive exactly one authenticated T; if its evidence can produce multiple authenticated candidate times, it MUST define a deterministic selection or aggregation rule before deadline construction, and a verifier MUST NOT invent earliest, latest, arrival-order, array-order, or another local reduction convention. The selected active-effect profile composition MUST define the exact representation of T, the interpretation of Delta as seconds, and one deterministic checked construction of D, including the order of conversion versus duration addition, any unit or scale conversion, precision and rounding where applicable, overflow behavior, and non-representable-result behavior. A numeric, monotonic, sequence, transaction-position, ledger-height, or other ordered representation MUST NOT be treated as seconds-capable merely because it is comparable. The selected active-effect profile composition MUST additionally identify exactly one selected state-machine or serialization profile as the authenticated source/owner of U, or, if multiple selected profiles can supply authenticated candidate transition values, define a deterministic authenticated reconciliation or reduction rule that yields exactly one U; the verifier MUST NOT choose a source by local preference. Before evaluating the application timing predicate, the composition MUST place D and U in one common totally ordered comparison domain, or define an exact deterministic direct-comparison rule with equivalent ordering semantics, including every required cross-profile conversion. A verifier MUST NOT invent an epoch mapping, clock substitution, unit conversion, coercion, rounding, clamping, wrapping, arithmetic order, source-profile choice, or comparison convention. A signed recorded_at, issuer time, local receipt time, process clock, file modification time, or other clock MUST NOT silently replace U. For the base profile, U <= D satisfies the timing predicate and U > D yields effect_application: too_late; equality is on time and the base profile defines no grace interval. If exactly one authenticated T, a representable D, exactly one authenticated U, or any required reduction, duration, conversion, representation, or comparison rule cannot be established deterministically, effect_application is indeterminate unless another already-defined earlier classification applies. 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. For an issuer-declared active effect, that profile MUST additionally define or unambiguously reference authenticated ordering evidence for the exact Executor Effect Acceptance Statement relative to the bound action execution boundary. Let A denote the authenticated ordering position or event value of that exact signed acceptance statement and E the authenticated execution-boundary position or event value. The profile MUST define a deterministic strict-before relation under which the verifier can evaluate A < E. The relation MAY be temporal, monotonic-sequence, transaction-position, or another authenticated total or profile-defined strict order; it need not be wall-clock time. A local receipt time, process clock, file modification time, unsigned event, or the signed accepted_at value by itself MUST NOT supply this ordering evidence.¶

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

A profile that supports selection evidence MUST define the exact selection profile identified by terms.selection_policy.digest and MUST apply that profile when verifying selection evidence and deriving selection provenance. A verifier MAY reject an unsupported selection-profile identifier or apply stricter local acceptance policy, but it MUST NOT silently substitute a different selection profile while reporting provenance for the same CPO.¶

CBAP-1 carries the selection-policy URI and digest as authenticated, digest-bound policy metadata, but it supports no selection statements and always derives selection_provenance: unilateral on the successful path. CBAP-1 therefore verifies policy-set integrity and presence for that reference but does not execute the referenced selection-policy bytes to upgrade provenance. Multiparty or external selection requires another named profile.¶

4.7. Affected-party access

affected_party_access is an ordered list 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 declared methods 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.¶

In this base protocol, public_transparency is a signed discovery declaration, not a network retrieval protocol. CBAP-1 does not define the dereferencing procedure, response contract, or success criterion needed to turn that declaration into retrievability: available; it therefore leaves retrievability: not_checked.¶

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.8. 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://pf.example/contest/urn:uuid:..."
  },
  "issuer": "https://issuer.example/keys/3",
  "signature": "base64url..."
}

For agent-contestability-notice-v1, the Contestability Notice access.mode MUST be by_reference; no other access.mode value is valid under this Notice profile. The Notice access.uri MUST equal the discovery_uri value of at least one authenticated_lookup declaration authenticated in the verified CPO's affected_party_access set. The selected affected-party access profile still MUST validate that declaration and its constraints. A valid Notice signature does not authorize an arbitrary URI.¶

The Notice issuer MUST equal the authenticated signed-CPO issuer identifier exactly. The Notice signature MUST be verified under the same locally trusted issuer-role public key that authenticated the signed CPO issuer. The signed Notice MUST NOT make a different key trusted merely by naming it in issuer; Notice-v1 defines no implicit delegated Notice signer.¶

The Notice-v1 signature input is the exact profile-defined canonical representation of every Notice member other than signature, including type, authorization_id, action_digest, effect_digest, cpo_digest, issued_at, access, and issuer. A verifier MUST verify the received Notice against that exact input.¶

Before a Notice can yield notice_evidence: issued, the verifier MUST require:¶

• Notice type to select agent-contestability-notice-v1;¶

• Notice authorization_id to equal the verified CPO terms authorization identifier;¶

• Notice action_digest to equal the verified CPO terms action digest;¶

• Notice effect_digest to equal the verified CPO effect_policy_digest;¶

• Notice cpo_digest to equal the digest of the verified complete signed CPO;¶

• Notice issuer and signature to satisfy the issuer-role rule above; and¶

• the Notice-qualified access.mode and access.uri constraints above.¶

A valid signature with any failed cross-object binding or Notice-v1 access constraint yields notice_evidence: invalid, not issued.¶

The Notice issued_at value is the Notice signer's authenticated claimed issuance time. It does not by itself establish delivery, reading, external publication, or filing-clock time.¶

A valid Notice yields notice_evidence: issued. It MUST NOT yield delivered unless a selected transport profile supplies authenticated delivery evidence bound to the same notice_digest. 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.9. Contestation Terms and signature inputs

terms is the only per-authorization object over which the forum, selectors, issuer, and authorization binding need to converge. In the constructions below, acceptance_digest, forum_acceptance_digest, and the existing selection_input are defined only for forum_acceptance.mode equal to exact or class_manifest; selection_input_none is defined only for none. 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 = signed_artifact_digest(forum_acceptance_evidence)
forum_acceptance_digest = acceptance_digest
selection_input = HASH("agent-contestation-selection-v1" ||
                       terms_digest || acceptance_digest)
selection_input_none =
    HASH("agent-contestation-selection-no-acceptance-v1" ||
         terms_digest)
cpo_tbs = canonical(type, terms, forum_acceptance,
                    selection_evidence, issuer)
cpo_digest = signed_artifact_digest(signed_CPO)
notice_tbs = canonical(type, authorization_id, action_digest,
                       effect_digest, cpo_digest, issued_at,
                       access, issuer)
notice_digest = signed_artifact_digest(signed_Contestability_Notice)
authorization_digest =
    signed_artifact_digest(signed_Authorization_Artifact)
effect_acceptance_tbs = canonical(
    type, authorization_digest, authorization_id, action_digest,
    cpo_digest, effect_policy_digest, forum_acceptance_digest,
    decision, valid_until, accepted_at, nonce, executor, key_id)
effect_acceptance_digest =
    signed_artifact_digest(signed_Executor_Effect_Acceptance)
filing_receipt_digest =
    signed_artifact_digest(signed_Filing_Receipt)
application_record_tbs =
    canonical(application_record_without_signature)
application_record_digest =
    signed_artifact_digest(signed_Effect_Application_Record)

The domain-separation strings shown above are part of the corresponding structured hash inputs. signed_artifact_digest(x) denotes the application-profile-defined digest of the complete signed artifact x; it does not imply an additional domain-separation prefix. These equations describe the abstract signature topology. CBAP-1 instantiates structured hashes and signed-artifact digests 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.¶

authorization_digest is the signed_artifact_digest of the exact complete signed native Authorization Artifact accepted under the selected ABP. The acceptance_digest and forum_acceptance_digest equations above apply only when forum_acceptance.mode is exact or class_manifest; in those evidence-bearing modes forum_acceptance_digest is exactly the already-defined acceptance_digest, an active-effect context name for the same digest rather than a second digest construction. In none mode neither digest exists, and because the base protocol requires effect_policy.mode = none, effect_acceptance_tbs is not applicable and is not weakened or given a reduced field set. filing_receipt_digest is the signed_artifact_digest of the exact complete signed filing receipt that established the verified trigger. application_record_without_signature is the exact closed profile-defined Effect Application Record with only the signature member omitted. Every other member required by the selected state-machine, idempotency, or serialization profile is part of application_record_tbs. application_record_digest is instead the digest of the complete received signed Effect Application Record.¶

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. In exact and class_manifest modes each selector signs the existing selection_input, which covers the complete terms and the exact acceptance evidence digest. In none mode each selector instead signs selection_input_none, which covers the complete terms under its distinct no-acceptance domain. The two domain-separation strings are different protocol constants, so the structured hash inputs cannot alias syntactically across modes; equality of the resulting hash values for distinct cross-domain inputs would require a collision in the selected hash. The CPO issuer signs cpo_tbs. The completed cpo_digest is then covered by the Authorization Artifact or companion binding statement.¶

For agent-contestability-notice-v1, Notice effect_digest MUST equal the already-defined effect_policy_digest; it is therefore the structured commitment to terms.effect_policy, not a digest of a separately signed artifact. The Notice signer signs notice_tbs. notice_digest is the signed_artifact_digest of the complete received signed Contestability Notice and is the digest bound by transport-specific delivery evidence.¶

For agent-executor-effect-acceptance-v1, the executor signs effect_acceptance_tbs. effect_acceptance_digest is the signed_artifact_digest of the complete received signed Executor Effect Acceptance Statement and is the digest that later execution/refusal and Effect Application records bind where required.¶

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.10. 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.11. 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 authenticated type value agent-forum-acceptance-manifest-v1 selects the FAM-v1 comparison and verification rules defined by this section. A verifier MUST NOT silently substitute different local comparison semantics for that same type. A future FAM profile with different comparison semantics requires a distinct authenticated type/version or another explicitly specified profile-selection mechanism.¶

For FAM-v1, key_id MUST equal forum.verification_key_id exactly. The FAM signer MUST be verified under the verifier's local forum-role trust abstraction, and the signed FAM MUST NOT make its own signer trusted merely by naming that key. Where local forum-role trust scopes keys to forum identifiers, the resolved signer MUST be authorized for forum.id. FAM-v1 defines no implicit delegation to a different manifest-signing key.¶

The base profile does not define a general predicate language for accepted actions. Class membership is established only by an accepted ABP and Authorization Trust Profile identifier pair 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.¶

For FAM-v1, a successfully verified Authorization Artifact and CPO satisfy the manifest only when all of the following are true:¶

• the successfully applied ABP and Authorization Trust Profile identifier pair appears exactly in accepted_authorization_classes;¶

• CPO forum.id equals FAM forum.id;¶

• CPO forum.submission_endpoint equals FAM forum.submission_endpoint;¶

• CPO forum.verification_key_id equals FAM forum.verification_key_id;¶

• the CPO Standing Policy equals the FAM standing_policy as an exact URI+digest pair;¶

• the CPO procedure equals the FAM procedure as an exact URI+digest pair;¶

• CPO filing_window.basis is a member of FAM filing_window_rule.permitted_bases;¶

• FAM filing_window_rule.minimum_duration_seconds <= CPO filing_window.duration_seconds <= FAM maximum_filing_horizon_seconds;¶

• may_bind_from <= authorization_validity.not_before; and¶

• authorization_validity.not_after <= may_bind_until.¶

A FAM-v1 object MUST require 1 <= filing_window_rule.minimum_duration_seconds <= maximum_filing_horizon_seconds. A FAM whose signed bounds do not define a non-empty permitted duration interval is invalid acceptance evidence and MUST NOT establish valid_class.¶

Membership of filing_window.basis in permitted_bases does not by itself define the filing clock. If the selected event class can yield multiple authenticated candidate times, the selected filing-window profile MUST still define the deterministic selection or aggregation rule required by Section 4.4.1 before a deadline can be computed.¶

The FAM submission_receipt_profile and withdrawal_policy are authenticated forum-acceptance parameters. They are not CPO class-comparison operands in FAM-v1. The submission-receipt profile is consumed by later receipt/trigger verification where applicable; the withdrawal policy governs continuity or withdrawal semantics where this document invokes it.¶

For class acceptance, may_bind_from and may_bind_until define only the inclusive interval within which the executable authorization-validity interval produced by successful ABP projection MUST be wholly contained. They do not establish when the Authorization Artifact or companion binding statement was created, signed, bound to the CPO, or first referenced the manifest. An authorization whose executable validity extends outside the FAM interval is outside the accepted class even if its contestability binding was created or attached during that interval. The FAM interval does not terminate a filing window already instantiated by a valid class binding.¶

maximum_filing_horizon_seconds is the inclusive upper bound on the CPO's declared filing-window duration, not an absolute timestamp or an offset from may_bind_until or the authorization-validity interval.¶

The FAM issued_at value is the forum signer's authenticated claimed issuance time for the FAM statement. It does not by itself establish external publication time, first availability, freshness, non-backdating, authorization binding time, class eligibility, or the filing-window start. A profile that uses FAM issuance time for freshness or temporal eligibility MUST define the authenticated comparison event or evidence and the exact predicate.¶

A mismatch between a valid FAM and the verified Authorization Artifact/CPO class constraints yields invalid_scope. Failure to authenticate the FAM itself, failure of the FAM signer/key relation, or invalid FAM-v1 self-constraints is invalid acceptance evidence rather than a successful class statement with a scope mismatch.¶

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.12. 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 exact complete signed Authorization Artifact representation and the signed-artifact digest construction used to derive authorization_digest;¶

• the native signature, time, audience, replay, and critical-member verification rules, and the interface through which an identified 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_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"
}

The authorization_digest value is signed_artifact_digest(signed_Authorization_Artifact) for the exact complete signed native Authorization Artifact accepted by the ABP. The ABP MUST define the exact signed-artifact representation and digest instantiation so that two conforming implementations applying the same ABP to the same authenticated artifact derive the same authorization_digest or refuse.¶

The abp_digest and authorization_trust_profile_digest values are bound profile identifiers. Carrying or matching an identifier does not by itself prove that corresponding profile bytes were obtained, content-hashed, or successfully applied. The profile that defines an identifier MUST define how the verifier obtains and applies the identified specification. If that identifier is intended to be a content digest, the profile MUST additionally define the canonical bytes, digest algorithm, and verification rule.¶

For CBAP-1, the expected ABP identifier is fixed by this application profile as H("cbap1-authorization-binding-profile-v1", 1); it is not derived from external ABP source bytes. The expected Authorization Trust Profile identifier is an opaque 32-byte value pinned by trusted local policy and compared with terms member 3; CBAP-1 does not define external profile bytes from which that identifier is derived. CBAP-1 instantiates authorization_digest as SHA-256(authorization_cose_bytes), the digest of the exact received Authorization COSE_Sign1 bytes.¶

Two conforming implementations applying the same identified ABP and Authorization Trust Profile 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.13. 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 the mode-specific input: selection_input for exact or class_manifest, which includes both the Contestation Terms and the exact acceptance evidence used, or selection_input_none for none, which covers the same complete Contestation Terms under a distinct no-acceptance domain. The evidence-bearing construction prevents a selector's signature for one forum acceptance from being replayed with another, and the distinct no-acceptance domain prevents syntactic reuse of a disclosure-only selector input as an acceptance-bearing input.¶

A controlling trust domain is a relying-party local-policy equivalence class used to decide whether selector or role credentials represent independent controlling authorities for selection-provenance purposes. It MUST NOT be inferred solely from DNS names, URI hosts, kid spelling, certificate subject strings, or the number of signing keys. A selection profile that claims non-unilateral provenance MUST declare exactly one provenance class, either multiparty or external, and MUST define the required selector roles and how trusted credentials or authorities are mapped to controlling trust domains. A profile that declares both classes is invalid or unsupported for provenance derivation; a profile that declares neither class cannot establish either non-unilateral result. The verifier MUST NOT infer a second provenance class merely because evidence satisfying that other class is also present.¶

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. Distinct keys mapped to one controlling trust domain MUST NOT be counted as independent parties merely because each key produced a valid signature.¶

4.14. 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 and simple values other than false, true, and null; at the bundle outer-item boundary, rejection of every CBOR tag, including tag 18; for each signed COSE_Sign1 object carried inside a bundle bstr, requirement of the object's outer COSE_Sign1 tag 18 and rejection of any other tag;¶

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

The closed CBAP-1 CDDL uses none of the simple values false, true, or null. Their allowance at the Core Deterministic CBOR layer does not make them valid where the closed CDDL requires another type; such a mismatch fails at the relevant closed-schema boundary.¶

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

CBAP-1 additionally fixes these resource ceilings:¶

MAX_BUNDLE_BYTES         = 8388608
MAX_BSTR_BYTES           = 1048576
MAX_TSTR_UTF8_BYTES      = 4096
MAX_COLLECTION_MEMBERS   = 64
MAX_NESTING_DEPTH        = 32
MAX_POLICY_PAIRS         = 5
MAX_KEY_ID_UTF8_BYTES    = 64

After verification-time validation and before parsing the outer CBOR item, a verifier MUST require the complete received bundle to be no more than MAX_BUNDLE_BYTES bytes. A larger bundle fails at outer_encoding_invalid without parsing the bundle.¶

At each CBOR decoding boundary, before allocation or iteration, the decoder MUST require every definite-length byte string to be no more than MAX_BSTR_BYTES, every definite-length text string to contain no more than MAX_TSTR_UTF8_BYTES received UTF-8 bytes, every array or map to contain no more than MAX_COLLECTION_MEMBERS members, and nesting depth to be no more than MAX_NESTING_DEPTH. For the nesting-depth predicate at each independently decoded CBOR boundary, the root item has depth 0; descending from an item to the data item carried by a tag, to an array element, or to a map key or map value increments depth by one, and the decoder MUST reject before descending when the resulting child depth would exceed MAX_NESTING_DEPTH. A byte string is opaque for nesting-depth accounting at the boundary that decodes it; when bytes carried in a byte string are subsequently decoded as CBOR by this profile, that parse is a new independent CBOR boundary whose root again has depth 0. Thus depth 32 is permitted and an attempted descent to depth 33 is rejected. The text-string ceiling is measured on received UTF-8 bytes, not Unicode scalar values.¶

A resource-ceiling predicate belongs to the boundary currently decoding the item. At the outer-item boundary it yields outer_encoding_invalid. At signed-object boundaries 5 through 9 it is part of that object's complete validation pipeline and yields that object's existing invalid reason. Resource predicates are evaluated before allocation, iteration, closed-schema predicates, and later cross-object or profile predicates that require the decoded value.¶

For example, a 5000-byte payload signer key-id text string or CPO forum key-id text string exceeds MAX_TSTR_UTF8_BYTES while the signed payload is decoded and therefore fails at the enclosing signed-object boundary; a later 1-through-64-byte key rule or step 13 forum-key length predicate is not evaluated. A 5000-byte URI text string inside a signed payload likewise fails at that signed-object boundary before the step 13 HTTPS-URI predicate. A 5000-byte protected kid byte string does not exceed MAX_BSTR_BYTES, but it still fails the existing protected-kid 1-through-64-byte constraint at the same signed-object boundary.¶

The existing 64-byte key-identifier rules remain stricter than the generic string ceilings wherever they apply and MUST NOT be weakened by these resource limits. Because CBAP-1 carries action bytes and by-value policy bytes as byte strings, each such byte string is limited to MAX_BSTR_BYTES.¶

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 contains only ASCII digits, begins with a digit in 1..9, is the shortest decimal representation of its value, and has a numeric value in 1..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. An explicit port MUST be validated in its received lexical form before numeric conversion; a verifier MUST NOT strip leading zeros and then validate the resulting number. 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. In particular, https://forum.example/ and https://forum.example:443/ remain distinct signed URI values even when a deployment routes both to the same HTTPS service. 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.15. 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]. CBAP-1 Ed25519 verification MUST apply Section 5.1.7 of [RFC8032] in full, including decoding R as a point and checking 0 <= S < L, and MUST use the uncofactored equation [S]B = R + [k]A, where A is the decoded public-key point and the remaining notation is as in that section. The received signature byte string MUST be exactly 64 bytes; this length constraint belongs to the tagged COSE_Sign1 shape predicate and MUST be evaluated before trust resolution or signature verification. The public key is an Ed25519 COSE_Key as defined by [RFC9053], with kty = 1, crv = 6, and a 32-byte x public-key value. In particular, as part of signature verification, that x value MUST decode successfully under Section 5.1.3 of [RFC8032]; a decoding failure is a signature-verification failure at the current signed-object boundary. CBAP-1 adds no separate small-order or weak-key rejection rule beyond RFC 8032 point decoding and the uncofactored verification equation above.¶

kid is a key-selection hint, not a trust assertion. The verifier's local trust set MUST resolve the exact protected kid bytes to exactly one authorized public key for the required role. Zero matching entries, multiple matching entries, or no entry authorized for the required role fails trust resolution at the current signed-object boundary as specified by the calling verification step. Within that same trust-resolution predicate, the verifier first matches entries by the exact protected kid and required role and requires exactly one matching entry; only then, on that uniquely resolved COSE_Key, if its alg member is present, it MUST be -19. The alg check MUST NOT filter entries before the exactly-one cardinality decision and MUST be completed before signature verification. Each payload also carries the signer's key-id as a text string. The protected kid MUST equal the UTF-8 encoding of that key-id byte-for-byte; no Unicode normalization or other transformation is applied. A protected kid that is not exactly such an encoding is invalid in CBAP-1.¶

4.16. 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: CBAP-1 does not assign an inserted leap second an additional distinct integer value, and comparisons and deadline arithmetic use that same POSIX numeric timeline.¶

The normative 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,                    ; executor-verification-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-profile
   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

Each nonce in CBAP-1 is an object-local opaque id16 member authenticated by the signature of its enclosing signed object. CBAP-1 defines no equality or inequality relation among CPO terms label 16, Authorization Artifact label 10, Executor Verification label 9, and Execution Record label 9. A verifier MUST NOT reject a bundle merely because any two of those nonce values are equal or different, and MUST NOT infer freshness, uniqueness, single use, replay resistance, or protocol ordering from their presence or value. Cross-object binding in the base profile is established by the authorization identifier, action digest, CPO digest, Authorization Artifact digest, Executor Verification digest, and the required signer/key relations. A profile that claims replay resistance MUST separately define the nonce/challenge or sequence issuer, comparison rule, scope, retained state, acceptance window, and duplicate or reuse handling.¶

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. For every fixed CBAP-1 integer vocabulary, any value other than a listed fixed value is outside the CBAP-1 CDDL and fails at the containing object's closed-schema boundary; it is not an extension point. Such a pre-semantic closed-schema failure does not itself establish an unsupported structured-result value. In particular, a CPO effect-mode integer other than 0 fails the B5 closed-schema predicate before declared_effect is completed, so declared_effect remains indeterminate under the closed transition table.¶

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. After the five signed payloads have been validated, the set of policy-digest values in bundle member 8 MUST equal exactly the set referenced by CPO terms labels 8, 9, and 12 and Exact Forum Acceptance labels 6 and 7. Missing or additional policy digests fail at profile_binding_mismatch; malformed, unsorted, duplicate, or internally digest-inconsistent policy pairs continue to fail at policy_set_invalid.¶

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

CBAP-1 permits action_bytes to be a zero-length byte string. In that case, action_digest is SHA-256 of the zero-length byte string.¶

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 changes the required digest dependency and MUST fail verification. A verifier MUST hash each signed artifact from its exact received conforming bytes rather than substitute a decoded-and-reconstructed representation. A reconstruction that differs by one or more bytes changes the relevant digest and MUST fail verification; a byte-identical reconstruction has the same digest.¶

4.18. CBAP-1 trust and verification inputs

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

• the expected Authorization Trust Profile identifier supplied by trusted local policy;¶

• a local trust set containing zero or more role-authorized Ed25519 public-key entries, each associated with exact kid bytes; a forum-role entry can additionally carry the forum-identifier authorization consumed by the separate forum-terms check;¶

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

The expected CBAP-1 ABP identifier is fixed by this profile as H("cbap1-authorization-binding-profile-v1", 1) and MUST be derived by the verifier rather than replaced by a caller-supplied alternative. The expected Authorization Trust Profile identifier 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 CBAP-1 signed-object role table is closed:¶

For each signed CBAP-1 object, trust resolution matches the role assigned in the CBAP-1 signed-object role table and the exact protected kid bytes. Zero matching entries or more than one matching entry fails at that signed-object boundary; exactly one matching entry supplies the public key used for signature verification. Additional entries under the same role with different kid values are allowed. CBAP-1 resolves the Executor Verification and Execution Record independently and MUST NOT require their protected kid values or resolved trust entries to be equal; different kid values are conforming when each object independently resolves to exactly one executor-role trust entry and all remaining predicates pass. Independent role authorization plus the required Execution Record binding to the exact signed Executor Verification record does not by itself establish that the two signer keys belong to the same legal, organizational, physical, or logical executor identity. An entry carrying the same kid under a different role does not satisfy the assigned role. For the Exact Forum Acceptance signer, authorization for the CPO terms forum-id is evaluated separately at the forum-terms boundary and MUST NOT be folded into signed-object trust resolution. In CBAP-1, absence of explicit forum-id authorization on the resolved forum-role trust entry means authorization for no forum identifier; omission MUST NOT be interpreted as wildcard authorization.¶

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

After the complete successful CBAP-1 procedure through boundary 21 passes, the final structured result contains selection_provenance: unilateral, forum_acknowledgement: valid_exact, pre_execution_evidence: executor_attested, and declared_effect: none. During evaluation, each field completes only where Section 6.5 assigns its positive transition; this descriptive successful-path sentence neither delays nor advances any field completion. The execution record's authenticated executed-at value starts the filing window. This is an executor-signed clock claim authorized through the executor-role entries of the local trust set and local policy, not an external wall-clock proof. The CBAP-1 local trust set is the CBAP-1 form of the generic local trust profile; CBAP-1 does not use the active-effect Executor Trust Profile for signed-object trust resolution or filing-clock authority.¶

5.1. Direct binding

An extensible Authorization Artifact carries:¶

contestability_digest = cpo_digest

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 identifier and Authorization Trust Profile identifier. 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.¶

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, executor decision, nonce, claimed verification time, executor key identifier, and signature. The corresponding execution or refusal record MUST bind the verification-record digest. When an active effect is also selected, the exact authenticated evidence-object identity of the corresponding execution or refusal record accepted for this executor_attested path MUST be reused as the action-boundary record identity for the effect-acceptance linkage in Section 5.4 and step 16; a different execution or refusal record identity MUST NOT satisfy that linkage. This establishes a digest-linked signed protocol sequence under keys each independently authorized for the executor role required by the selected profile; it does not by itself establish that the signer keys belong to the same legal, organizational, physical, or logical executor identity, and it does not prove the physical placement or honesty of the executor's checks. A selected pre-execution evidence profile that additionally claims same-executor continuity across the linked records MUST define and verify a complete authenticated relation between the signer keys. That relation MAY require the same exact kid, or MAY define authenticated key rotation, delegation, or a common executor identity or authority binding; in every case the profile MUST define the relation authority and evidence, validity and compromise semantics, temporal or ordering rules where applicable, and deterministic failure behavior for missing, ambiguous, conflicting, expired, revoked, unsupported, or otherwise unevaluable relation evidence. The base verifier MUST NOT invent such a relation.¶

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 no pre-execution evidence profile is selected, the verification path makes no pre-execution presentation or enforcement claim and the verifier MUST derive pre_execution_evidence: not_claimed; it MUST NOT require or consume a pre-execution evidence object for that classification. If a pre-execution evidence profile is selected, the path makes the corresponding pre-execution claim: absence of evidence required by that selected profile yields pre_execution_evidence: absent; supplied or applicable evidence that deterministically fails a required closed-schema, authentication, trust, digest-binding, identifier-binding, ordering, or other profile predicate yields pre_execution_evidence: invalid; and a selected profile whose required assumptions, evidence, temporal or trust semantics, or authenticated comparisons cannot be evaluated deterministically yields pre_execution_evidence: indeterminate unless invalidity has already been established. A fully verified executor_attested or transparency_prior path yields the correspondingly named positive result. The CPO binding can remain valid in every one of these cases. Profile selection is the unique signal that this verification path makes a pre-execution claim; a profile or deployment MUST NOT introduce a second boolean claim flag or equivalent duplicate claim owner.¶

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

For agent-executor-effect-acceptance-v1, the signature MUST verify over the exact effect_acceptance_tbs defined in Section 4.9; the signature member is excluded from that projection. The verifier MUST require executor to equal the Effect Policy executor identifier and key_id to equal the Effect Policy executor verification-key identifier. The signature MUST verify under that executor key after it has been resolved under the locally accepted Executor Trust Profile selected by the Effect Policy. The digests MUST resolve to the same verified Authorization Artifact, action, CPO, effect policy, and forum acceptance evidence.¶

The verifier MUST derive effect_acceptance_required_until from authenticated profile evidence using the active-effect temporal rules above, and MUST require both accepted_at <= valid_until and valid_until >= effect_acceptance_required_until. These two validity-coverage comparisons are inclusive. Their inclusivity does not alter the separate ordering predicates that require a hold trigger before execution or a fence trigger after execution and before finality. If either validity-coverage comparison is false, effect_acceptance is invalid. If a required authenticated execution, filing-window, or finality boundary cannot be established, cannot be deterministically reduced to one value, or cannot be placed into the required common totally ordered comparison domain, effect_acceptance is indeterminate unless another already-defined earlier failure classification applies. A verifier MUST NOT supply a missing reduction, conversion, comparison, or clock convention locally.¶

The complete received signed acceptance statement has effect_acceptance_digest as defined in Section 4.9. The corresponding execution or refusal record MUST bind that exact digest. When the selected pre-execution evidence profile has established pre_execution_evidence: executor_attested, this corresponding record MUST be the same exact authenticated evidence-object identity accepted for that executor_attested path, and the shared object MUST bind both the exact verification-record digest required by Section 5.3 and this exact effect_acceptance_digest. This same-record identity requirement does not require equality of signer kid values and does not establish that the signers represent one legal, organizational, physical, or logical executor identity. 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.¶

After all earlier acceptance signature, trust, digest, identifier, and validity-horizon checks pass, the verifier MUST apply the bound serialization profile to the exact signed acceptance statement and execution boundary and require the authenticated strict-before predicate A < E. If authenticated evidence establishes A < E, the acceptance-ordering predicate passes. If authenticated evidence establishes that A < E is false, effect_acceptance is invalid. If the required acceptance or execution ordering evidence is absent, ambiguous, unsupported, non-reducible, or not deterministically comparable under the selected serialization profile, effect_acceptance is indeterminate unless another already-defined earlier failure classification applies. An implementation MUST NOT upgrade that indeterminate result because accepted_at happens to be numerically earlier than an execution timestamp.¶

A statement that satisfies all required acceptance checks, including the authenticated A < E predicate, yields effect_acceptance: executor_accepted. Absence, invalid validity coverage, invalid or indeterminate pre-execution acceptance ordering, unavailable or non-comparable required temporal evidence, 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 selected trigger profile. The verified forum acceptance evidence MUST authenticate the same exact URI+digest submission-receipt profile pair selected by trigger_profile and the same forum key. For every receipt carrying submission_digest, the selected trigger profile MUST define the exact filing or submission representation committed by that digest; whether the digest input is the exact received submission bytes or a completely defined profile-canonical representation; every canonicalization rule when canonicalization is used; the digest algorithm and the meaning of the receipt alg member; the exact digest comparison rule; and any filing or submission material that the verifier must receive to recompute or otherwise validate the digest. Open descriptions such as "canonical JSON", "normalized request", or "semantic contents" are insufficient unless the selected profile completely defines the resulting digest input. The base protocol does not otherwise define a universal filing-submission representation or add the filing contents as a universal verifier input. For an accepted receipt that successfully authenticates the trigger, the verifier MUST compute filing_receipt_digest = signed_artifact_digest(signed_Filing_Receipt) over the exact complete received signed receipt. The selected trigger profile MUST define the exact signed receipt representation and signed-artifact digest instantiation. 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..."
}

Before treating an Effect Application Record signature as valid over a conforming record, the verifier MUST require the received member set to satisfy the selected closed state-machine, idempotency, and serialization-profile rules. The signature MUST verify over the exact application_record_tbs defined in Section 4.9; the signature member is excluded from that projection and every other profile-required member is included.¶

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 equals the application_record_digest of the first valid Effect 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.¶

Effect Application Record verification uses staged classification. First, the verifier MUST establish record admissibility: the closed record/profile shape, signature, accepted executor key, Authorization Artifact/action/CPO/policy/acceptance/receipt bindings, idempotency identity, and the state-machine and serialization-profile predicates required to identify the exact authenticated application transition. A failure at this stage yields effect_application: invalid; a verifier MUST NOT derive too_late from an unauthenticated or misbound transition. Second, for an admissible record, the verifier compares the exact authenticated application-transition time with the derived application deadline. Under the base active-effect profile, authenticated_application_time > application_deadline yields effect_application: too_late, regardless of the signed record's claimed disposition; the base profile defines no deterministic grace exception. A signed applied claim in that case is non-conforming executor evidence and MAY be retained as an operator diagnostic or equivocation/conformance signal, but it does not change the derived too_late result. If the required authenticated application-transition time cannot be derived deterministically after record admissibility has been established, effect_application is indeterminate unless another already-defined earlier classification applies. Third, only for an admissible on-time transition does the verifier evaluate the remaining closed disposition/state semantics. If those semantics validate, disposition: applied yields effect_application: executor_claimed_applied, disposition: refused yields effect_application: executor_claimed_refused, disposition: already_applied yields effect_application: already_applied, and disposition: failed yields effect_application: failed. An admissible on-time record with disposition: too_late contradicts the authenticated timing predicate and yields effect_application: invalid; the signed claim MAY be retained as an operator diagnostic or equivocation/conformance signal. Any other deterministic mismatch in the remaining disposition/state semantics yields effect_application: invalid unless another already-defined earlier classification applies.¶

After successful record verification, the verifier MUST compute application_record_digest from the complete received signed Effect Application Record. 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 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 and no accepted selection profile establishes a non-unilateral class;¶

• multiparty: the selected profile declares multiparty as its single non-unilateral provenance class and every selector role required by that profile signed the same applicable mode-specific selection input (selection_input for exact or class_manifest, selection_input_none for none);¶

• external: the selected profile declares external as its single non-unilateral provenance class and a locally trusted external Selection Authority selected or authenticated the forum under the referenced policy;¶

• indeterminate: evidence is missing, invalid, ambiguous, unsupported, does not satisfy the single non-unilateral class declared by the selected profile, or the selected profile declares both non-unilateral classes.¶

The verifier MUST evaluate only the non-unilateral provenance class declared by the selected profile. For a multiparty profile, participation by an external Selection Authority as one selector role does not reclassify the result as external. For an external profile, additional selector signatures do not reclassify the result as multiparty. Evidence that fails the declared class MUST NOT fall through to the other non-unilateral class. A profile declaring neither multiparty nor external cannot establish either result.¶

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

6.2. Structured result

The following JSON example uses the line-wrapping convention from [RFC8792].¶

{
  "binding": "valid | invalid | indeterminate",
  "pre_execution_evidence": "executor_attested | \
    transparency_prior | absent | invalid | not_claimed | \
    indeterminate",
  "discoverability": "complete | incomplete | indeterminate",
  "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 | indeterminate",
  "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"]
}

For binding, discoverability, and declared_effect, indeterminate means that the verifier has not established enough validated input to select one of the other values in that field's closed vocabulary. It MUST NOT replace a known invalid, incomplete, or unsupported result.¶

Before evaluating CBAP-1 failure-precedence boundary 1, a verifier MUST initialize the Section 6.2 result exactly as follows:¶

{
  "binding": "indeterminate",
  "pre_execution_evidence": "indeterminate",
  "discoverability": "indeterminate",
  "forum_acknowledgement": "indeterminate",
  "forum_operational_status": "not_checked",
  "selection_provenance": "indeterminate",
  "access_binding": "indeterminate",
  "notice_evidence": "indeterminate",
  "retrievability": "not_checked",
  "filing_window_status": "indeterminate",
  "policy_freshness": "indeterminate",
  "declared_effect": "indeterminate",
  "effect_acceptance": "indeterminate",
  "effect_trigger": "indeterminate",
  "effect_ordering": "indeterminate",
  "effect_application": "indeterminate",
  "reasons": []
}

The two not_checked initial values mean that CBAP-1 has not performed an operational reachability or retrievability check. Every other semantic field begins as indeterminate because no validated protocol input has yet established a more specific value. The reasons array begins empty.¶

CBAP-1 evolves this result monotonically under the closed boundaries in Sections 6.4 and 6.5:¶

• For boundaries 1 through 4, a positive semantic-field completion occurs only where Section 6.5 lists it explicitly after the whole boundary passes. No other semantic field completes in those boundaries.¶

• For signed-object boundaries 5 through 9, no positive semantic-field completion assigned to a boundary occurs unless the complete signed-object validation pipeline passes. On failure, only the negative transition explicitly assigned to the first failed predicate may occur.¶

• For cross-object boundaries 10 through 21, a predicate that passes earlier in the current boundary may complete a semantic field before a later predicate in that boundary fails only where Section 6.5 explicitly lists that completion. There is no open-ended post-failure derivation.¶

• A semantic field MUST transition from its initial value at most once. Once completed, it MUST retain that value for the remainder of CBAP-1 verification.¶

• On a negative path, reasons MUST transition exactly once from [] to an array containing the first failure-precedence reason code. On the positive path, reasons remains [] and transitions zero times.¶

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, their CPO authentication succeeds, and they satisfy the selected access-profile constraints. It is invalid when, after the containing CPO has reached the predicate that establishes the relevant authenticated declaration set, a required access declaration is absent under the selected access profile or an authenticated declaration fails an access-profile constraint; it is also invalid when the CPO signature predicate fails, when an authenticated CPO signer key-id conflicts with the authorization-issuer key-id declared in the CPO terms, or when an existing later access-specific predicate has the closed transition to invalid. A CPO closed-schema failure that occurs before an authenticated access declaration set has been established does not by itself prove an access declaration invalid and leaves access_binding at its prior value unless the closed transition table says otherwise. It is not_claimed when the selected profile makes no affected-party access claim. It is indeterminate when the access declarations have not been established as invalid but their authenticated applicability cannot be established, including an upstream Authorization Artifact-to-CPO binding failure, a pre-authentication CPO closed-schema failure, or inability to reach the CPO signature predicate after an earlier signed-object failure. 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:¶

For this table, Valid acceptance means an Executor Effect Acceptance Statement that has passed all required acceptance checks, including the authenticated strict-before acceptance-ordering predicate A < E. Evidence about later trigger or application ordering does not substitute for that acceptance predicate. A deterministic step-15 coupling failure in which forum_acceptance.mode = none is paired with an active effect mode yields declared_effect: invalid; the dependent effect fields remain indeterminate because the invalid declaration blocks active-effect evaluation.¶

not_evidenced and indeterminate are disjoint ordering results. not_evidenced means the required authenticated ordering evidence was not supplied or not observed. indeterminate means ordering evidence was supplied or otherwise selected for evaluation but the verifier cannot derive one supported result because the evidence is ambiguous, conflicting, unsupported, non-reducible, non-comparable, or the selected profile lacks a deterministic evaluation rule. A verifier MUST NOT choose between those values by local policy, user-interface preference, or implementation convention. The late-application row reports the derived temporal fact after record admissibility has been established; a signed disposition: applied does not override too_late. Conversely, an admissible on-time record with signed disposition: too_late contradicts the authenticated timing predicate and yields effect_application: invalid; the signed claim MAY be retained as an operator diagnostic or equivocation/conformance signal. A user interface MUST NOT present an application claim with unverified, invalid, or indeterminate ordering 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. Steps 1 through 9 establish the local-input, outer-item, policy-set, and signed-object boundaries in the same order as Section 6.5. Resource ceilings from Section 4.14 are predicates of the boundary currently decoding the item and are evaluated before allocation, iteration, closed-schema checks, or later predicates that require the decoded value. For each signed object in steps 5 through 9, the verifier completes that object's entire validation pipeline before examining the next signed object: CBAP-1 resource ceilings and Core Deterministic CBOR conformance under Section 4.14 of the complete tagged COSE_Sign1 item; tagged COSE_Sign1 shape, unprotected-header constraints, and the 64-byte received-signature length constraint; resource ceilings and Core Deterministic CBOR conformance of the CBOR encoded in the protected-header byte string and the protected-header constraints; resource ceilings and Core Deterministic CBOR conformance of the CBOR encoded in the payload byte string; closed payload schema, profile version, and object type; protected kid equality to the UTF-8 encoding of the payload signer key-id; unique role-authorized trust resolution, evaluating exact protected-kid and required-role matching and exactly-one cardinality before requiring the uniquely resolved COSE_Key alg, when present, to equal -19; and signature verification over the received protected and payload bytes with empty external AAD. For failure-precedence purposes, the closed payload schema includes every constraint expressed directly by the CBAP-1 CDDL, including fixed integer values, CDDL cardinality constraints, and fixed empty arrays; a fixed CDDL constraint that fails at steps 5 through 9 MUST NOT be re-evaluated at steps 13, 17, or 18. Within a closed map, member constraints are evaluated in ascending numeric-label order; within a list, items are evaluated from index zero upward. For steps 10 through 21, predicates are evaluated in the order stated in the corresponding step.¶

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. Before parsing the bundle, require the complete received bundle to be no more than MAX_BUNDLE_BYTES. Then parse exactly one outer CBOR item and require complete input consumption, the CBAP-1 resource ceilings applicable at the outer-item boundary, and the Core Deterministic CBOR constraints that can be evaluated without applying the closed cbap1-bundle schema. At this outer-item boundary, reject every CBOR tag, including tag 18; the required tag 18 applies only to each signed COSE_Sign1 object carried inside a bundle bstr. Also reject duplicate map keys, indefinite-length items, non-shortest arguments, disallowed simple values, floats, invalid UTF-8, any declared length that cannot be consumed with checked cursor arithmetic, or any outer-boundary resource ceiling exceeded by a declared item. Re-encode that outer item under Section 4.14 and require byte-for-byte equality. Do not reject an otherwise deterministic outer item merely because its bundle version, members, or member types do not match cbap1-bundle; those checks belong to step 3.¶

3. Require the outer item to be the closed cbap1-bundle with the supported profile version, all required members, no unknown members, and the required outer member types. For bundle member 8, apply the complete CDDL grammar 8: [+ [digest, bstr]] together with digest = bstr .size 32 at this step: require a non-empty policy-set array; require each item to be exactly a two-element [digest, bstr] pair; require the digest to be a 32-byte byte string; and require the policy bytes to be a byte string. These CDDL-expressed member-8 constraints belong to this boundary and MUST NOT be re-evaluated at step 4. The MAX_POLICY_PAIRS upper bound, profile-defined ordering, uniqueness, and digest integrity are evaluated only at step 4.¶

4. Validate the already CDDL-valid policy set. Require the array to contain no more than MAX_POLICY_PAIRS pairs, require the array to be in the profile-defined order, reject duplicate policy digests, recompute SHA-256 over each policy byte string, and require equality. At this step only the MAX_POLICY_PAIRS upper bound, order, uniqueness, and internal digest integrity are evaluated. Member-8 non-empty cardinality, exact pair shape, 32-byte digest type/size, and policy-byte bstr type were already established at step 3 and MUST NOT be re-evaluated here. Referenced-policy presence is evaluated at step 13 after all five signed payloads have passed their object-validation pipelines. The upper-bound predicate remains inside B4 policy_set_invalid; it creates no semantic-field transition, so B4 remains P -- / N -- as specified in Section 6.5.¶

5. Apply the complete signed-object validation pipeline above to the CPO using its issuer-role assignment in the CBAP-1 signed-object role table, and no later signed object.¶

6. Apply the complete signed-object validation pipeline above to the Exact Forum Acceptance using its forum-role assignment in the CBAP-1 signed-object role table, and no later signed object.¶

7. Apply the complete signed-object validation pipeline above to the Authorization Artifact using its issuer-role assignment in the CBAP-1 signed-object role table, and no later signed object.¶

8. Apply the complete signed-object validation pipeline above to the Executor Verification record using its executor-role assignment in the CBAP-1 signed-object role table, and no later signed object.¶

9. Apply the complete signed-object validation pipeline above to the Execution Record using its executor-role assignment in the CBAP-1 signed-object role table.¶

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

11. Hash the complete signed Exact Forum Acceptance and require equality with the CPO acceptance reference.¶

12. Recompute action_digest from the bundle's action bytes. Then, in this order, require equality with CPO terms label 6, Authorization Artifact label 6, Executor Verification label 5, and Execution Record label 6.¶

13. Evaluate these predicates in order. Require the CPO terms to use the expected CBAP-1 ABP identifier, then the expected Authorization Trust Profile identifier. Require the CPO signer key-id to equal the CPO terms authorization-issuer key-id. Require not-before <= not-after. Require the filing-window duration to be in 1..18446744073709551615. Require conforming HTTPS URIs, first evaluating the URI-bearing cbap1-terms members in ascending numeric-label order and nested list entries in ascending index order: forum-id 7[0], submission-endpoint 7[1], Standing Policy URI 8[0], procedure URI 9[0], selection-policy URI 12[0], and each affected-party discovery-uri at 13[i][1] for increasing i; then evaluate Exact Forum Acceptance submission-receipt-profile URI 6[0] and withdrawal-policy URI 7[0], in that order. Require the CPO terms forum key-id to encode as 1 through 64 UTF-8 bytes. Let referenced_policy_digests be the set of policy digests carried at CPO terms labels 8, 9, and 12 and Exact Forum Acceptance labels 6 and 7. Require every digest in referenced_policy_digests to be present in bundle member 8. Then require bundle member 8 to contain no policy digest outside referenced_policy_digests. Do not compare the Authorization Artifact projection or any other signed-artifact digest at this step.¶

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

15. Project forum_terms exactly as Section 4.17 specifies. Require its digest in the already-validated and CPO-bound Exact Forum Acceptance to equal that projection. Require the Exact Forum Acceptance signer key-id to equal the CPO terms forum key-id exactly. Require the trust entry resolved for that signer at step 6 to carry explicit authorization for the exact CPO terms forum-id; an entry with no forum-id authorization fails this predicate.¶

16. Hash the complete signed Authorization Artifact and require equality at Executor Verification label 3 and Execution Record label 3.¶

17. Require the already-validated Executor Verification record to carry the bound authorization identifier at label 4 and CPO digest at label 6.¶

18. Hash the complete signed Executor Verification record. Require the already-validated Execution Record to carry that digest at label 4 and the bound authorization identifier at label 5.¶

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

20. Compute filing_deadline = executed-at + duration-seconds with checked unsigned arithmetic.¶

21. 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. Treat the filing window as the half-open interval [executed-at, filing_deadline). Derive filing_window_status as not_open when verification_time < executed-at, open when executed-at <= verification_time < filing_deadline, and closed when verification_time >= filing_deadline.¶

22. 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 failure at steps 1 through 21 MUST produce the corresponding first reason code at the same precedence number in Section 6.5. The verifier MUST NOT evaluate a later failure boundary for purposes of reasons before the current boundary has passed. When a boundary fails, the verifier MUST stop at the first failed predicate, MUST NOT evaluate any later predicate of that boundary or any later boundary, and MUST complete the Section 6.2 result only through the closed transition rules in Section 6.5 while preserving every field already completed by an earlier boundary.¶

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. For precedences 5 through 9, the verifier applies the complete signed-object validation pipeline in Section 6.4 in its stated order. Cross-object checks then follow precedences 10 through 21, with predicates inside each step evaluated in the order stated in Section 6.4. Evaluation stops at the first failed boundary and, within that boundary, at the first failed predicate. Later predicates of that boundary and all later boundaries are not evaluated.¶

The first-reason rule is a reproducibility rule, not permission to collapse the Section 6.2 result. On failure, the verifier applies only the structured-result transition assigned below to the first failed predicate, changes reasons from [] to the corresponding one-element array, preserves every previously completed field, and returns the result. A field without a listed transition preserves its current value. On the positive path, the listed positive completions occur at their stated boundaries. Positive completions at boundaries 5 through 9 occur only after the complete signed-object boundary passes; at boundaries 10 through 21, an earlier passed predicate may complete a field before a later predicate fails only where explicitly stated below.¶

8.1. Maturity and coverage

The implementation evidence recorded for -00 remains based on 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 external fixtures and implementation artifacts described in this section are non-normative. They do not define or override CBAP-1 requirements, and no fixture supplies authority for a rule that is absent or ambiguous in this document.¶

The cross-check re-encoded the external positive bundle fixture byte-for-byte and verified all five Ed25519 signatures. The external positive bundle fixture 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 frozen A3 source-and-artifact package underlying the reconstruction evidence was recorded at SHA-256:¶

f2b9b0745ca8b751322f416ed62e73769b2396934b8beb811d5f71b4fc88b129¶

That reconstruction passed 56 local tests. It matched the retained evaluator outcomes for the external positive bundle fixture, 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. Separately, the submitted IPv6 algorithm was independently transcribed and compared with a standard IPv6 parser over 255,022 generated candidates; no acceptance or rejection divergence was found.¶

For -01, before any source edit, the frozen A3 package was re-executed in the refresh environment and its original 56-test baseline passed 56/56. A derived refresh of the same A3 Rust lineage then implemented exact policy-set equality and the half-open filing interval [executed-at, filing_deadline). It also added regression coverage showing that otherwise-valid bundles are accepted with either equal or different object-local nonce values; no cross-object nonce comparison was added. The refresh changed three source/test files, passed 61 local tests with no compiler warnings, and cargo build --release --locked completed successfully. The unified refresh patch has SHA-256:¶

f74d4bad4db1e3ad22234d78056b6064bc7db3a20709502e61b59dae814a2a24¶

Subsequent alignment and hardening remained on the same A3 Rust lineage. The M25 public-key-decoding alignment extended the locked suite to 63/63. The P2 trust/profile-input alignment extended it to 66/66. The P6 resource-limit and URI-port hardening extended it to 73/73. Each recorded state passed its complete locked suite with zero failures; later counts supersede earlier counts as the current executable evidence snapshot but do not erase the historical intermediate states.¶

The A3 executable profile remains limited to Exact Forum Acceptance. It does not implement FAM class acceptance, valid_class, agent-contestability-notice-v1, or the FAM authorization-validity-containment semantics added during -01. The 73-test result therefore MUST NOT be read as implementation evidence for those surfaces. No signed CBAP wire format was expanded by the A3 alignment and hardening work.¶

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 -01 refresh was performed in a derived tree from the hash-verified frozen A3 input. Its review evidence records the source identities, unified patch, toolchain, test inventory, test transcripts, and release-build result. Dependency versions were selected under Cargo.lock, but required crate sources were retrieved online; offline reproduction was not established. The compiler self-report matched the historical A3 record, but historical distribution-package identity was unavailable, so build identity is not asserted.¶

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

CBAP-1 verification does not require dereferencing a signed URI. A deployment that chooses to dereference one SHOULD treat the target, every redirect, and every resolved address as untrusted network input. It SHOULD bound redirects, time, response size, and other resource use, and SHOULD reject loopback, private, link-local, metadata-service, or otherwise privileged destinations unless such access is explicitly intended and separately authorized. Signature validity and HTTPS syntax do not make a retrieval target safe.¶

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

For CBAP-1, the authenticated executed-at value is an executor-signed clock claim, not proof of external wall-clock accuracy. The ordering predicate constrains that claim relative to verified-at and the authorization interval; it does not prevent executor clock bias. A malicious or compromised executor can choose an inaccurate executed-at within the accepted signed bounds, and an earlier value can make the computed closing time earlier than a window measured from real execution.¶

A relying party that requires protection against executor-controlled clock bias SHOULD constrain clock authority and acceptable skew through the executor-role entries of its local trust set and local policy, or require independent authenticated time evidence under a profile designed for that claim. The computed CBAP-1 filing window MUST NOT be interpreted as proof that the Affected Party received a fair real-world opportunity to file.¶

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, may_bind bounds, or submission endpoint. Exact acknowledgements MUST match the forum_terms_digest. A FAM MUST bind accepted ABP and Authorization Trust Profile identifier 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. Under Notice-v1, validity requires the same locally trusted issuer-role key that authenticated the signed CPO issuer. 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. Notice-v1 MUST bind the CPO digest and MUST require its access.uri to equal the discovery_uri of an authenticated_lookup declaration authenticated in the verified CPO; the selected affected-party access profile must then validate that declaration. 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 selected profile claiming pre-execution enforcement MUST carry authenticated ordering evidence from the enforcement path. If such a profile is selected but its required authenticated ordering evidence is absent, the binding can remain cryptographically valid while pre_execution_evidence is absent; if no pre-execution evidence profile is selected, the result is instead not_claimed. Even executor_attested proves only the signed claims made under the accepted executor-role keys and their required digest bindings, not the physical order of events inside an executor. When different keys sign the linked verification and execution/refusal records, the base result does not establish that those keys belong to the same executor identity unless the selected pre-execution evidence profile defines and verifies such an authenticated relation.¶

9.14. Exact-acceptance disclosure

Exact acceptance exposes at least a stable terms digest and interaction timing to the forum before authorization. CBAP-1 fixes action_digest = SHA-256(action_bytes) and carries action_bytes by value in the complete bundle. Before those bytes are disclosed, a low-entropy action digest can permit offline dictionary guessing; a recipient of the complete CBAP-1 bundle receives the action bytes and therefore obtains no action confidentiality from the digest. Deployments using CBAP-1 SHOULD restrict access to the bundle and action bytes when confidentiality is required.¶

Deployments SHOULD prefer a class manifest when instance-specific acceptance is unnecessary and SHOULD register only a CPO or manifest digest in public transparency infrastructure. A salted or hiding commitment MAY be appropriate in another named profile that defines the salt or blinding material, exact commitment construction, disclosure or proof mechanism, and cross-artifact verification rules. A deployment MUST NOT replace CBAP-1's SHA-256(action_bytes) construction with a salted commitment and still claim CBAP-1 conformance.¶

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 required authenticated ordering evidence is not supplied or not observed, effect_ordering is not_evidenced. If ordering evidence is supplied or selected for evaluation but cannot be resolved deterministically because it is ambiguous, conflicting, unsupported, non-reducible, non-comparable, or governed by an incomplete selected profile, effect_ordering is indeterminate. Neither result becomes verified merely because 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 CBAP signed object is not itself a SCITT Signed Statement [RFC9943]. CBAP-1 requires the protected header of each signed object to contain exactly alg and kid, while a SCITT Signed Statement requires its own protected CWT Claims [RFC9597], including iss and sub; the same COSE_Sign1 therefore cannot satisfy both profiles. A composition with SCITT uses a distinct SCITT Signed Statement outside the completed CBAP object. An application profile can, for example, carry the exact completed CPO or Contestability Binding Statement bytes as the SCITT Statement payload, or define a Statement that identifies those bytes by their CBAP digest. The inner CBAP object remains byte-for-byte unchanged and is verified under this document. For a CPO, cpo_digest remains SHA-256(cpo_cose_bytes); any digest used to identify the distinct SCITT Signed Statement identifies the outer SCITT object and does not replace cpo_digest. The reference direction is from the SCITT layer to the already-completed CBAP object; the base CBAP object does not bind a later SCITT Signed Statement or receipt. 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-01, 4 September 2026, <https://datatracker.ietf.org/doc/html/draft-stone-adrp-01>.

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

[RFC8792]

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

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

[RFC9597]

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

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