]> Independent Researcher

Portugal tiago@donttrustverify.pt https://donttrustverify.pt

Security agent authorization contestability verifiable evidence Authorization artifacts can provide signed evidence of a permission under specified authorization rules. Receipts can record a signed claim or protocol event that the authorization was exercised, and outcome evidence can describe what followed. None of those artifacts necessarily tells a person or organization affected by the action where the authorization can be contested, which procedure applies, whether a filing changes execution state, or who selected the contestation forum. This document defines a transport-independent Contestability Binding for authorized agent actions. The binding commits an authorization to a versioned Contestation Parameters Object that identifies the forum, submission mechanism, Standing Policy, procedure, time bounds, declared effect policy, and selection evidence. A forum can acknowledge one exact authorization or publish a reusable acceptance manifest for closed Authorization Binding Profile and Authorization Trust Profile identifier pairs. A deterministic verifier validates the binding, separately classifies evidence claiming pre-execution verification by the executor, and reports forum-selection provenance as unilateral, multiparty, externally selected, or indeterminate. Where a filing is declared to affect execution state, the verifier also separates the issuer's declared policy, the executor's signed acceptance, the authenticated trigger, and the executor's claimed application. The mechanism makes the bound contestation parameters identifiable and verifiable, supporting discoverability while resisting post-action substitution. It does not determine standing, prove forum independence, resolve a dispute, select a remedy, establish legal enforceability, or decide whether the original authorization was legitimate.

Introduction Agent authorization can be action-bound, time-bounded, signed, logged, and receipted. That improves the answer to one question:

• Was this action authorized under the selected rules?

It does not answer a different question:

• If this authorization produces a contested consequence, before whom can the authorization or its use be challenged, under which procedure, and who chose that forum?

A URI labelled challenge_forum is not sufficient. If the authorization issuer can name, replace, or differently present the forum to each audience, the path exists syntactically while remaining captured operationally. A bound field can evidence that a contestation locator was declared in the artifact; it cannot by itself prove delivery or independence. This document therefore separates three properties:

1. Binding: the contestation parameters are cryptographically committed to the exact authorization; pre-execution presentation and ordering are reported separately.
2. Discoverability: a verifier can identify the bound forum, procedure, Standing Policy, deadlines, and submission references.
3. Selection provenance: authenticated evidence and local trust inputs support classification of the forum selection as issuer-only, multiparty, externally selected, or indeterminate.

The verifier never returns independent. Independence is a governance and trust conclusion. It returns evidence about how selection occurred.

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.

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: They are not expected to agree that the forum is fair, independent, affordable, competent, or legally authoritative. Those conclusions remain outside the protocol.

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 when, and only when, they appear in all capitals, as shown here.

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.

Adversarial survival tests for R4 and R6 R4 and R6 are deliberately tested against claims that a signature or URI cannot establish.

R4: acknowledgement is not selection or availability The following cases MUST remain distinguishable:

Case	Acknowledgement result	Selection result	Operational result
Issuer names a forum that never signed	absent	derived separately	not_checked
Forum signs for the exact authorization	valid_exact	derived separately	not_checked
Forum signs a standing manifest for a class that includes the authorization	valid_class	derived separately	not_checked
Forum signature is valid but its accepted scope does not cover the authorization	invalid_scope	derived separately	not_checked
Forum acknowledged the scope but the endpoint is unreachable	acknowledgement remains valid	derived separately	unreachable
Forum and issuer are the same controlling party	acknowledgement may be valid	normally unilateral	derived separately

A valid forum signature authenticates a signed commitment under the accepted forum key over a defined scope. It does not prove that the forum was selected independently, remains reachable, will accept a particular filer, or will decide according to the bound procedure. An acknowledgement can be either exact or class-based. A class-based acknowledgement is valid only if the verifier can deterministically establish that the authorization falls within the signed class. A free-text class description is insufficient.

R6: access must survive the effect being contested The following cases MUST NOT collapse into available:

• the CPO is retrievable only after logging into the account that the action suspended;
• a signed notice was issued but no evidence establishes that it was delivered;
• a discovery URI is public but leaks the existence or subject of a sensitive action;
• the CPO is available to the principal but not to a distinct Affected Party;
• the issuer serves audience-specific CPOs under different authorization artifacts;
• the filing window substantially expires before the first access method becomes usable;
• the affected party is not identifiable until after execution.

The protocol therefore separates notice issuance, delivery evidence, and current retrievability. Under agent-contestability-notice-v1, a valid Contestability Notice signature yields the protocol classification issued only when it verifies under the same locally trusted issuer-role key that authenticated the signed CPO issuer and all required Notice-to-CPO bindings succeed. It does not prove human issuance, receipt, comprehension, or successful access. An affected-party profile for an action that disables or controls a credential MUST provide at least one access method that does not depend solely on that credential. Otherwise the action can remove the means of contesting itself.

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.

Scope This document specifies:

• a Contestation Parameters Object (CPO);
• exact and reusable class-based forum acceptance evidence;
• an Authorization Binding Profile interface for native authorization systems;
• two ways to bind a CPO to an authorization;
• profiles for classifying pre-execution evidence without claiming physical proof;
• an optional declared effect policy, Executor Effect Acceptance Statement, authenticated filing trigger, and Effect Application Record;
• a deterministic verification algorithm;
• a structured result that keeps binding, discoverability, forum acknowledgement, operational status, selection provenance, notice evidence, retrievability, and effect evidence separate;
• security requirements for substitution, equivocation, dead endpoints, abusive deadlines, issuer-controlled forums, trigger replay, and execution races.

This document does not specify:

• a dispute-resolution protocol or case state machine;
• arbitrator discovery, evidence exchange, adjudication, appeal, award, or remedy;
• who legally has standing;
• whether a forum is impartial, competent, affordable, or legally valid;
• which effect policy a deployment ought to choose, or whether an external system is legally or operationally compelled to honor it;
• the legitimacy of the authorization, policy, issuer, or consequence.

Terminology Authorization Artifact: A signed object expressing, under an authorization system, a permission for an identified agent, workload, or delegate to perform a bounded action. Authorization Instance Identifier (authorization_id): A globally unique or collision-resistant identifier for one authorization instance. Action Digest (action_digest): A digest over the canonical action the executor will evaluate. Contestation Parameters Object (CPO): The closed, signed object defined in Section 4. Contestation Terms: The canonical, unsigned per-authorization facts inside a CPO. Role signatures refer to its digest rather than recursively signing an envelope that contains those signatures. Contestability Binding: A commitment from an Authorization Artifact to a CPO, either directly or through a companion binding statement. Forum: The service or institution designated to receive a contestation. Identification of a forum does not assert independence or legal jurisdiction. Exact Forum Acceptance Statement: A forum-signed acceptance of one closed, forum-relevant projection of the Contestation Terms. Forum Acceptance Manifest (FAM): A reusable forum-signed statement accepting contestations for authorization classes successfully verified and projected under one or more closed ABP and Authorization Trust Profile identifier pairs, subject to bound procedure, time, and continuity constraints. Authorization Binding Profile (ABP): An adapter specification referenced by a bound profile identifier that verifies one native Authorization Artifact type and deterministically projects the closed authorization tuple consumed by this document. Authorization Trust Profile: A set of trust inputs and issuer-authority rules referenced by a bound profile identifier and applied by an ABP. It answers which issuer keys are accepted; the ABP answers how the native artifact is verified and projected. A profile identifier is not necessarily a content digest unless the profile defining that identifier says so. Throughout this document, a bound profile reference identifies the exact versioned semantics to be applied. A profile identifier is not by itself a content-integrity proof or a trust authorization. If a selected profile is content-addressed, that profile MUST define the exact referenced bytes, digest algorithm, and comparison rule. If a selected profile controls trust, the verifier MUST accept that profile identifier through trusted local policy before applying its trust inputs or authority rules. Signed protocol data MAY bind or name a selected profile, but MUST NOT make an otherwise untrusted profile, trust anchor, or key trusted merely by carrying that identifier. References that already define explicit content-digest semantics retain those semantics. Effect Policy: The issuer-signed declaration in the CPO terms that selects none, hold_before_execution, or fence_after_execution and, for an active mode, binds the executor and the trigger, state-machine, idempotency, serialization, and trust profiles. Executor Trust Profile: A set of trust inputs, executor-key authority rules, rotation rules, and compromise semantics referenced by a bound profile identifier and accepted through trusted local policy to verify effect acceptance and application records. Effect Executor: The party named by an active Effect Policy that signs effect acceptance and application records and controls, or participates under a bound serialization profile in controlling, the target hold or fence transition. It can be the action executor but is not assumed to be the same party. Executor Effect Acceptance Statement: An executor-signed commitment, made over a completed authorization and CPO before execution, to process a bound active effect policy. Filing Receipt: A forum-authenticated record accepting or refusing one contestation submission. Only an accepted receipt verified under the bound trigger profile can be an effect trigger. Effect Application Record: An executor-signed claim describing how it processed one authenticated trigger under the bound effect policy. It is not proof of physical state or a remedy. Standing Policy: A versioned policy describing which roles or parties may file. This document verifies its identity and integrity, not the correctness of its determinations. Selection Authority: A party permitted by the relying party's trust profile to participate in or determine forum selection. Affected Party: A person or organization whose interests may be materially affected by an authorized action. An Affected Party need not be the principal, agent, issuer, executor, or relying party.

Contestation Parameters Object The object is first shown in JSON diagnostic form for readability. The mandatory executable profile in Section 4.14 encodes the corresponding closed data model using Core Deterministic CBOR and signs each role statement with COSE_Sign1. The JSON form is not a wire encoding and MUST NOT be hashed or signed.

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.

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.

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.

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.

Filing-window basis The filing window MUST identify the authenticated event from which its duration is calculated. Initial event classes are:

• execution_time: authenticated time in the executor's action or execution record;
• transparency_publication_time: authenticated registration time of the Contestability Notice or CPO digest under a selected transparency profile;
• authenticated_delivery_time: time in a transport-specific delivery receipt bound to the notice_digest of the complete received signed Contestability Notice under the selected Notice profile.

An issuer-signed issued_at value alone is not one of these event classes. If a selected event class can yield multiple authenticated candidate times in one verification instance, the selected filing-window profile MUST define a deterministic selection or aggregation rule that reduces those candidates to exactly one filing-clock value before the deadline is computed. The profile MAY, for example, select the earliest or latest authenticated candidate when that rule is stated explicitly. A verifier MUST NOT substitute a reduction convention that the selected profile does not state, including local arrival order or array order. If the selected event evidence is absent or invalid, if a required reduction rule is undefined, or if the authenticated evidence cannot produce exactly one filing-clock value under that rule, the verifier returns filing_window_status: indeterminate; it MUST NOT silently substitute local receipt time or another clock. A profile can define a deterministic combination or fallback among event classes, but it MUST state the precedence rule. To derive generic filing_window_status, the selected filing-window profile MUST additionally define the exact filing-clock/start representation, the interpretation of duration_seconds, deterministic checked addition or an equivalent rule for deriving the closing value, the behavior when that value is non-representable, and one deterministic comparison domain for the filing-clock/start value, verification time, and closing value. It MUST define the opening- and closing-boundary operators including equality at each boundary, and MUST partition every admitted deterministically comparable state into exactly one of not_open, open, or closed; those predicates MUST be mutually exclusive and collectively exhaustive. A verifier MUST NOT invent a local conversion, epoch mapping, rounding, clamping, wrapping, arithmetic, or boundary convention. If any required authenticated value or required profile rule is unavailable, unsupported, non-representable, incomplete, or not deterministically comparable, filing_window_status is indeterminate unless another earlier already-defined classification applies. Verification authenticates the selected clock input and computes the window under those profile rules; it does not establish that the rule gave the Affected Party a fair opportunity to act.

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

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.

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.

Contestability Notice An affected-party profile using effect_notice carries or references a signed notice with the following minimum members: 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.

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

Exact Forum Acceptance Statement Exact acceptance is represented diagnostically as: 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.

Forum Acceptance Manifest A Forum Acceptance Manifest (FAM) is a reusable, signed acceptance statement: 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.

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

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.

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 . It does not use the length-first map key ordering in Section 4.2.3 of , historically called canonical CBOR by . 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: 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 and the https URI scheme requirements in Section 4.2.2 of , 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 ;
• a bracketed host MUST contain exactly one syntactically valid 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.

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

URI	Required result	Boundary exercised
https://forum.example	accept	empty path
https://forum.example:1/	accept	minimum explicit port
https://forum.example:443/cases?open=1	accept	shortest decimal port, path and query
https://forum.example:65535/	accept	maximum explicit port
https://[2001:db8::1]/cases	accept	IPv6 address literal
https://[v1.a]/cases	accept	IPvFuture
https://forum.example/%2Fcase	accept	complete percent triplet in path
HTTPS://forum.example/	reject	scheme is not exact lowercase https
https://	reject	empty host
https://user@forum.example/	reject	user information
https://forum.example:/	reject	empty explicit port
https://forum.example:0/	reject	explicit port zero
https://forum.example:00/	reject	explicit port zero and non-shortest form
https://forum.example:0443/	reject	leading zero / non-shortest form
https://forum.example:00001/	reject	leading zeros / non-shortest form
https://forum.example:65536/	reject	port outside profile range
https://forum.example/%2/	reject	incomplete percent triplet
https://forum.example/#part	reject	fragment present
https://[:::]/	reject	invalid IPv6 address literal
https://[v1.]/	reject	invalid IPvFuture
https://[fe80::1%25eth0]/	reject	zone identifier unsupported
https://forum.example/a[b]	reject	brackets in path
https://forum.example/?a=[b]	reject	brackets in query

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

Mandatory signature envelope Every signed CBAP-1 object is an embedded-payload, tagged COSE_Sign1 object as defined by : The protected header map MUST contain exactly: Header label 1 is alg; value -19 is the fully specified Ed25519 algorithm registered by . 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 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 . CBAP-1 Ed25519 verification MUST apply Section 5.1.7 of 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 , 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 ; 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.

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

CBAP-1 digest and construction rules CBAP-1 uses these exact derivations: 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.

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:

Signed object	Required trust role
CPO	issuer-role
Exact Forum Acceptance	forum-role
Authorization Artifact	issuer-role
Executor Verification	executor-role
Execution Record	executor-role

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.

Binding to an Authorization

Direct binding An extensible Authorization Artifact carries: 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.

Companion binding statement Where the Authorization Artifact cannot be extended, the issuer signs a Contestability Binding Statement containing: 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.

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.

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

Filing triggers and effect application An accepted_filing_receipt trigger profile MUST authenticate at least the following closed projection from the forum's receipt: 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: 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.

Verification The generic verifier consumes the protocol objects, evidence, and local inputs required by the selected verification path. Its inputs are:

• the Authorization Artifact, action, CPO, and any companion binding statement;
• the Forum Acceptance Evidence referenced by the CPO when forum_acceptance.mode is exact or class_manifest; no Forum Acceptance Evidence input is required or consumed for none;
• the referenced policy and profile semantics, and any profile-defined material required to apply them, including the exact selection profile and any selected pre-execution, Notice, affected-party-access, Executor Trust, trigger, state-machine, idempotency, serialization, temporal, or freshness profile;
• trusted local policy, the local trust profile, verification time, and any profile-defined retained state required for replay, idempotency, or ordering;
• when selected by local policy, the policy-freshness profile identifier and its required evidence and, separately when selected by trusted local verifier policy, the Forum Operational Status Profile identifier and its required observation evidence; and
• the path-dependent evidence objects required by steps 8 and 16 through 22 under the selected profiles, including, when applicable, pre-execution evidence, an Executor Effect Acceptance Statement, linked execution or refusal evidence, a Contestability Notice, delivery or retrievability evidence, filing-window event evidence, a filing receipt, an Effect Application Record, and profile-required prior-application or ordering/finality evidence.

A selected profile identifier is not by itself content-integrity or trust evidence. Where a profile is content-addressed, the verifier uses only the exact bytes and digest construction defined by that profile. Values derived by verification, including authorization_digest, effect_acceptance_digest, effect_acceptance_required_until, the derived pre-execution acceptance_before_execution result, filing_receipt_digest, application_record_digest, notice_digest, trigger_time, filing-window closing time, and application_deadline, are not independent caller inputs. Given those inputs, the verifier MUST:

1. Parse every object under its declared closed-object rules.
2. Recompute the canonical action digest and require equality with the Authorization Artifact and CPO.
3. Verify and project the Authorization Artifact under the claimed ABP and Authorization Trust Profile, require the applied ABP identifier, the applied Authorization Trust Profile identifier, and the projected tuple to match the corresponding CPO terms, identify the authorization issuer, and derive authorization_digest from the exact complete signed Authorization Artifact under that ABP.
4. Verify the direct binding or companion binding statement.
5. Recompute the CPO digest and require equality with the bound digest.
6. Use the authorization_id from the successful ABP projection as the reference authorization identifier and the recomputed canonical action digest as the reference action digest. For each member independently, define the equality domain as every supplied object whose selected closed profile defines that member. An object whose selected closed profile does not define authorization_id is outside the authorization-identifier equality domain, and an object whose selected closed profile does not define action_digest is outside the action-digest equality domain. This is not an optional-ignore rule: omission of a member required by the selected closed profile fails that object's closed-object or schema rules. For every supplied path-dependent evidence object o, identify the exact authenticated evidence object, or use the selected profile's deterministic object-identity rule when that profile defines one, and derive one internal object-scoped equality state for that identity. If the selected closed profile defines neither equality-domain member, that state is not_applicable. Otherwise, at the earliest boundary that has accepted the closed profile/schema, resolved every trust/key/issuer authority required to make the relevant member authoritative, and successfully authenticated the object where the profile requires authentication, compare every profile-defined authorization_id and action_digest exactly once to the corresponding step-6 reference value and set that object's equality state to valid or invalid. This equality state is verifier-internal derived state, not a protocol field. For each semantic use u of o, RolePredicates(o, u) means every additional predicate required to make o valid evidence for that exact use, wherever that predicate is defined by this document or by a selected profile to which this document explicitly delegates that predicate class. A selected profile MUST NOT supply an otherwise unspecified predicate class merely because doing so would make a use executable. Before any generic semantic step consumes o, consumes any value derived from o, or derives any positive semantic classification that depends on o for use u, the verifier MUST establish all of the following: the closed profile/schema, trust/key/issuer-authority, and authentication/signature requirements applicable to o have passed (Authority(o)); the object-scoped equality state is valid or not_applicable (N7(o)); and every RolePredicates(o, u) predicate required for that exact use has passed. Authentication or predicate evaluation performed solely to establish this admissibility is not itself such semantic consumption. Successful derivation of a value from o does not by itself establish that o was admissible evidence for the use of that value. A predicate already established for the same evidence object and still applicable to a later use MAY be reused and MUST NOT be re-evaluated solely because another numbered step consumes the same object or a value derived from it. If the first semantic consumer occurs before a later numbered step that would otherwise verify the same evidence, the first consumer MUST establish this complete role admissibility before using the object or any derived value, and the later step MUST reuse every still-applicable established predicate and the already-established equality state. An invalid equality state belongs to the selected evidence object's semantic result and blocks every positive classification that depends on that object; it MUST NOT be promoted to binding except for the core Authorization Artifact, CPO, and direct or companion binding predicates already owned by steps 2 through 5 and 7. Step 6 therefore establishes the reference values, equality domains, object-identity rule, unique equality owner, and the single generic role-admissibility-before-use invariant; role-specific predicates remain defined where their semantics live and are aggregated here rather than duplicated. It MUST NOT eagerly compare an unauthenticated object's member, and no consumer step may acquire a second equality owner merely by mentioning the same evidence.
7. Verify the CPO issuer signature and require the issuer to be the authorization issuer or an authority explicitly accepted by local policy.
8. If no pre-execution evidence profile is selected, derive pre_execution_evidence: not_claimed and consume no pre-execution evidence object. Otherwise, verify the selected pre-execution evidence profile for the same CPO digest subject to the object-scoped equality precondition in step 6 and classify exactly as defined in the Pre-execution evidence profiles section: required evidence absent yields absent; supplied or applicable evidence that deterministically fails a required profile, authentication, binding, or ordering predicate yields invalid; an applicable selected profile that cannot be evaluated deterministically yields indeterminate unless invalidity has already been established; and a fully verified supported profile yields executor_attested or transparency_prior as applicable. The verifier MUST NOT treat an executor claim as physical proof of execution order. An invalid equality state for that evidence belongs to pre_execution_evidence, not binding.
9. Verify time validity and replay constraints.
10. Verify the digests of the Standing Policy, procedure, and selection policy. If the optional policy-freshness input is present, require its profile identifier to be accepted by local policy, apply that profile to the required evidence, and derive policy_freshness; if that selected profile is content-addressed, additionally verify the exact bytes and digest construction defined by that profile. If that input is absent or cannot be evaluated, return indeterminate for that field. Independently, if a Forum Operational Status Profile is selected by trusted local policy, require that exact profile identifier to be accepted by local policy and, where content-addressed, verify its exact bytes and digest construction; then apply that profile to its required operational observation evidence subject to the object-scoped equality and role-admissibility rules in step 6, require the evidence to evaluate the exact authenticated CPO forum.submission_endpoint, and derive forum_operational_status: reachable only from admissible evidence proving the profile-defined success predicate or unreachable only from admissible evidence proving the profile-defined failure predicate. If no Forum Operational Status Profile is selected, derive forum_operational_status: not_checked; if one is selected but its required evidence or semantics are absent, invalid, stale, ambiguous, unsupported, non-reducible, or otherwise not deterministically evaluable, derive forum_operational_status: indeterminate. Missing evidence alone MUST NOT yield unreachable, and this step MUST NOT perform implicit network I/O.
11. Recompute terms_digest and forum_terms_digest, then branch exhaustively on the authenticated closed forum_acceptance.mode. For none, require the exact closed { "mode": "none" } shape, require and consume no Forum Acceptance Evidence, derive no acceptance_digest or forum_acceptance_digest, and set forum_acknowledgement: absent. For exact, authenticate the Exact Forum Acceptance Statement before classifying any of its members, subject to the object-scoped equality precondition in step 6; its profile defines neither authorization_id nor action_digest, so its object-scoped equality state is not_applicable. Only after its signature and digest have successfully authenticated the received signed_at and valid_from values, require signed_at <= authorization_validity_lower_bound and valid_from <= authorization_validity_lower_bound, where authorization_validity_lower_bound is the authenticated executable lower bound produced by the successful ABP projection. A false comparison yields forum_acknowledgement: invalid_scope; if the required authenticated lower bound cannot be obtained or compared deterministically, yield forum_acknowledgement: indeterminate unless an earlier already-defined failure classification applies. For class_manifest, authenticate the FAM signature and digest subject to step 6; FAM-v1 likewise defines neither equality-domain member and therefore has object-scoped equality state not_applicable; require the authenticated type to select Section 4.11, require key_id to equal forum.verification_key_id, verify the signer under the local forum-role trust abstraction including forum-identifier authorization when defined, and require 1 <= minimum_duration_seconds <= maximum_filing_horizon_seconds. Missing, invalid, unsupported, or otherwise unevaluable evidence required by exact or class_manifest follows the existing failure semantics and MUST NOT yield absent.
12. Branch on the same three modes. For none, evaluate no forum-acceptance scope predicate and preserve forum_acknowledgement: absent. For exact, require the accepted forum_terms_digest to match. For class_manifest, require the successfully applied ABP and Authorization Trust Profile identifier pair to appear in accepted_authorization_classes; require exact CPO-to-FAM equality for forum identifier, submission endpoint, forum verification-key identifier, Standing Policy URI+digest, and procedure URI+digest; require the CPO filing basis to be permitted; require minimum_duration_seconds <= duration_seconds <= maximum_filing_horizon_seconds; and require the executable authorization-validity interval to be wholly contained in may_bind_from..may_bind_until, inclusive. The FAM submission-receipt profile and withdrawal policy remain authenticated forum parameters rather than CPO class-comparison operands. If the selected filing basis can yield multiple authenticated candidate times, the filing-window profile still MUST define the deterministic reduction required by Section 4.4.1.
13. Branch on the same three modes before verifying selection evidence. For none, recompute selection_input_none = HASH("agent-contestation-selection-no-acceptance-v1" || terms_digest) and verify every selection-evidence item against exactly that input. For exact or class_manifest, recompute the existing selection_input from terms_digest and the verified acceptance_digest and verify every item against exactly that input. In every mode use the exact selection profile identified by terms.selection_policy.digest and the local trust profile; a verifier MUST NOT substitute a different selection profile while reporting provenance for the same CPO. If that selected profile claims non-unilateral provenance, require it to declare exactly one of multiparty or external; both declared classes make the profile invalid or unsupported for provenance derivation, and neither declared class means the profile cannot establish a non-unilateral provenance result.
14. Derive selection provenance as specified in Section 6.1, accounting for role co-location under the local trust profile and evaluating only the single non-unilateral class declared by the selected profile. Evidence for the other non-unilateral class MUST NOT silently reclassify the result.
15. Parse the effect policy as a closed object, then branch exhaustively on forum_acceptance.mode before any active-effect processing. For this algorithm, the active-effect path is the effect-specific processing in steps 16, 20, 21, and 22. For none, if effect_policy.mode is not none, derive declared_effect: invalid, derive effect_acceptance: indeterminate, effect_trigger: indeterminate, effect_ordering: indeterminate, and effect_application: indeterminate, consume no active-effect evidence, and do not enter the active-effect path. Otherwise, for none, require effect_policy.mode = none and do not enter the active-effect path. For exact or class_manifest, if effect_policy.mode = none, do not enter the active-effect path; For an active mode, apply the profile-reference rule in Section 3 to every referenced profile; require the bound Executor Trust Profile identifier to be accepted by local policy; for accepted_filing_receipt, require trigger_profile.event to select that event class and require trigger_profile.uri and trigger_profile.digest to equal, component by component as one exact URI+digest pair, the submission_receipt_profile URI and digest authenticated by the forum acceptance evidence, without URI normalization, local aliasing, or identifier substitution; verify the named executor under the accepted Executor Trust Profile; require the base application_deadline.basis to be authenticated_trigger_time; and reject any base-profile grace semantics not defined by this document.
16. For any Executor Effect Acceptance Statement, first apply its selected closed statement/profile rules and require the executor and key identifiers needed to select the expected authority to match the Effect Policy; resolve and authorize the executor key under the locally accepted Executor Trust Profile; then verify the signature over the exact effect_acceptance_tbs under that resolved key. Establish or reuse the statement's object-scoped equality state under step 6 before evaluating its remaining cross-object bindings; an invalid equality state changes only effect_acceptance, not binding. Then require all remaining Authorization Artifact, CPO, effect-policy, and forum-acceptance bindings. Before deriving effect_acceptance_required_until, establish or reuse under step 6 the object-scoped equality state of every execution, filing-window, or, for fence mode, finality evidence object on which the required boundaries E, W, or F depend; this requirement also applies when the boundary is consumed only indirectly as a value derived from that evidence. If an applicable supporting object's equality state is invalid, that object MUST NOT support a positive effect_acceptance result. Derive effect_acceptance_required_until only from supporting evidence whose equality state is valid or not_applicable, using the required deterministic reduction and common comparison domain; if a supporting object or boundary was already verified or derived for an earlier consumer, reuse that established state or value rather than assigning a new equality owner. Require accepted_at <= valid_until and valid_until >= effect_acceptance_required_until; classify a false validity comparison as effect_acceptance: invalid and unavailable, non-reducible, or non-comparable required boundary evidence as effect_acceptance: indeterminate unless an earlier defined failure classification applies. Under the bound serialization profile, before deriving authenticated ordering evidence for the exact signed acceptance event and the action execution boundary, establish or reuse under step 6 every supporting evidence object's equality state and require the strict-before predicate A < E; classify authenticated evidence proving that predicate false as effect_acceptance: invalid and absent, ambiguous, unsupported, non-reducible, or non-comparable required ordering evidence as effect_acceptance: indeterminate unless an earlier defined failure classification applies. Compute effect_acceptance_digest from the complete received signed acceptance statement; and require any linked execution or refusal record to bind that exact digest. If step 8 established pre_execution_evidence: executor_attested, require the execution or refusal evidence-object identity used for this effect-acceptance linkage to be the same exact authenticated evidence-object identity accepted by that executor_attested path and require that shared object to bind both the exact verification-record digest and the exact effect_acceptance_digest. A deterministically different record identity or a deterministic missing or mismatched required linkage yields effect_acceptance: invalid; inability to establish the required shared record identity or linkage deterministically yields effect_acceptance: indeterminate unless an earlier already-defined failure classification applies. This same-record check MUST NOT compare signer kid values or infer a common executor identity. Do not infer application or physical ordering from acceptance or from accepted_at.
17. For generic Notice verification, authenticate any supplied Contestability Notice under its selected Notice profile subject to the object-scoped equality precondition in step 6. For agent-contestability-notice-v1, verify the exact Notice signature input under the same locally trusted issuer-role key that authenticated the signed CPO issuer, establish or reuse the Notice's object-scoped equality state, and require that state to be valid; an invalid state yields notice_evidence: invalid and MUST NOT change binding. Then require the remaining effect/CPO digest bindings, Contestability Notice access.mode = by_reference, and a Notice access.uri equal to the discovery_uri of at least one authenticated_lookup declaration authenticated in the verified CPO, and classify the Notice as issued, invalid, or absent. Evaluate delivery evidence separately and only when a selected transport profile defines it; before using any exact delivery-evidence object or value derived from it, establish or reuse that object's equality state under step 6. Such evidence MUST bind the same notice_digest. Later use of the same evidence object, including as filing-window event evidence, MUST reuse the established equality state and MUST NOT re-evaluate its N7 members.
18. Evaluate each declared affected-party access method under the selected profile subject to the object-scoped equality precondition in step 6. Before using any supplied access-evidence object or value derived from it to produce a positive access result, establish or reuse that object's equality state. Derive access_binding from the integrity and profile constraints of those declarations. Evaluate retrievability separately; do not infer current availability from a signed URI.
19. Verify or reuse the event evidence named by filing_window.basis subject to the object-scoped equality precondition in step 6. Before using that evidence or any value derived from it to produce a positive filing-window result, establish or reuse its object-scoped equality state; an invalid state is a failure of that filing-window evidence and MUST NOT change binding. Under the selected filing-window profile, deterministically derive or reuse the filing-clock/start value and closing value W, and apply that profile's complete arithmetic, comparison-domain, opening-boundary, closing-boundary, and state-partition rules to the supplied verification time to derive exactly one of filing_window_status: not_open, open, or closed. If the same exact evidence object was already authenticated or its equality state, filing-clock/start value, or W was established for an earlier consumer, reuse that state or derived value and MUST NOT re-evaluate its N7 members for first-reason or semantic-classification purposes. If a required authenticated clock input, deterministic reduction, arithmetic rule, representable closing value, comparison-domain rule, boundary rule, or comparable value cannot be established, return filing_window_status: indeterminate and, for exact acceptance, forum_acknowledgement: indeterminate unless an earlier already-defined failure classification applies. For exact acceptance, only after W has been derived require the already-authenticated Exact Forum Acceptance value valid_until >= W; a false comparison yields forum_acknowledgement: invalid_scope.
20. For any filing receipt, authenticate or reuse the exact receipt under the exact trigger profile and forum key subject to the object-scoped equality precondition in step 6. Establish or reuse its object-scoped equality state before evaluating the remaining Authorization Artifact digest, CPO digest, time, replay, and profile bindings. An invalid equality state is a trigger-path failure and MUST NOT change binding. Apply the selected trigger profile's complete submission_digest construction and comparison rules before using an accepted receipt as evidence of the exact filing. If the profile requires verifier recomputation and the authenticated receipt digest deterministically mismatches the digest derived from the required filing or submission material, classify effect_trigger: invalid. If a required submission_digest construction, algorithm, canonicalization, comparison rule, or required filing/submission material is unavailable, unsupported, incomplete, or not deterministically evaluable, classify effect_trigger: indeterminate unless another already-defined earlier failure classification applies. Distinguish an accepted filing from a refused or invalid submission and, for the exact complete signed receipt that establishes a valid trigger, derive filing_receipt_digest.
21. After a valid trigger, apply the base active-effect application's complete T/Delta/D/U contract from Section 4.9: require the trigger profile to derive exactly one authenticated T; apply the selected active-effect profile composition's exact seconds interpretation, checked arithmetic, conversion order, precision/rounding, overflow, and non-representable-result rules to derive D; identify or deterministically reconcile the authenticated source of exactly one application-transition value U; and place D and U into the required common totally ordered comparison domain before deriving any timing-dependent application result. If a required authenticated value, reduction, duration rule, representation rule, source-owner/reconciliation rule, conversion rule, representable deadline, or comparison rule cannot be established deterministically, return effect_application: indeterminate unless another already-defined earlier classification applies. For any Effect Application Record, first require its selected closed record-profile rules and authenticate or reuse its signature verification over the exact application_record_tbs subject to the object-scoped equality precondition in step 6. Establish or reuse the record's object-scoped equality state; an invalid state yields effect_application: invalid and MUST NOT change binding. Then complete record admissibility by requiring its effect_acceptance_digest and filing_receipt_digest to equal the digests of the exact verified complete signed acceptance and receipt, and verifying the exact policy, executor key, remaining CPO bindings, idempotency identity, and the state-machine and serialization predicates required to identify the authenticated application transition; failure of record admissibility yields effect_application: invalid. Only after record admissibility and a deterministic D/U comparison are established, apply the base no-grace rule: U > D yields effect_application: too_late regardless of the signed disposition, while U <= D is on time. Only for an admissible deterministically on-time transition evaluate the remaining closed disposition/state semantics. If they validate, map disposition: applied to effect_application: executor_claimed_applied, disposition: refused to effect_application: executor_claimed_refused, disposition: already_applied to effect_application: already_applied, and disposition: failed to effect_application: failed. An admissible deterministically on-time disposition: too_late contradicts the authenticated timing predicate and yields effect_application: invalid; if the D/U comparison is indeterminate, the verifier MUST NOT derive that contradiction merely from the signed too_late disposition. Any other deterministic mismatch in the remaining disposition/state semantics likewise yields effect_application: invalid unless another already-defined earlier classification applies. Compute application_record_digest from the complete received signed record after successful record verification.
22. For any supplied ordering or finality evidence required by the bound serialization profile, authenticate, verify, or reuse that exact evidence subject to the object-scoped equality precondition in step 6. Before using it or any value derived from it to derive a positive ordering result, establish or reuse its object-scoped equality state. If the same exact evidence object was already authenticated or its equality state was established for an earlier consumer, including step 16, reuse that state and MUST NOT re-evaluate its N7 members. Separately evaluate whether the trigger, application, execution, and finality transitions are ordered under the bound serialization profile. An invalid equality state belongs to effect_ordering and MUST NOT change binding. Do not substitute recorded_at or another signed wall-clock field for the required authenticated transition or ordering evidence.
23. Return the structured result in Section 6.2.

An Authorization Artifact verification or projection failure, CPO issuer-signature failure, direct or companion binding failure, CPO-digest binding failure, or authorization-identifier/action-digest mismatch owned by those core authorization/CPO predicates makes binding invalid. An invalid object-scoped equality state in path-dependent evidence belongs to that evidence object's result and MUST NOT be promoted to a cryptographic binding failure. Every dependent positive classification MUST be blocked before completion rather than repaired by retroactive state rewriting. A forum-acceptance failure changes forum_acknowledgement; a selection-signature failure changes selection_provenance; a notice failure changes notice_evidence; missing filing-clock evidence changes filing_window_status; and an effect acceptance, trigger, application, or ordering failure changes only its corresponding effect result. Those failures MUST NOT be collapsed into or misreported as a cryptographic binding failure. Failure to retrieve an otherwise valid digest-bound procedure makes discoverability incomplete; it does not rewrite a valid cryptographic binding as invalid.

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.

Structured result The following JSON example uses the line-wrapping convention from . 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: 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.

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.

Evidence state	Derived result
forum_acceptance.mode = none with an active declared effect	Acceptance: indeterminate; Trigger: indeterminate; Ordering: indeterminate; Application: indeterminate.
Declared mode is none	Acceptance: not_required; Trigger: not_applicable; Ordering: not_applicable; Application: not_applicable.
Active mode, no acceptance statement	Acceptance: absent; Trigger: evaluated if supplied; Ordering: not_applicable until a valid trigger exists; Application: invalid if a record claims application; otherwise not_observed.
Valid acceptance, no filing receipt observed	Acceptance: executor_accepted; Trigger: not_observed; Ordering: not_applicable; Application: not_observed.
Valid acceptance, refused filing receipt	Acceptance: executor_accepted; Trigger: refused; Ordering: not_applicable; Application: not_observed.
Valid acceptance and trigger, no application record	Acceptance: executor_accepted; Trigger: valid; Ordering: not_evidenced unless independently established; Application: not_observed.
Admissible on-time record with disposition: applied, verified ordering	Acceptance: executor_accepted; Trigger: valid; Ordering: verified; Application: executor_claimed_applied.
Admissible on-time record with disposition: applied, required ordering evidence not supplied or not observed	Acceptance: executor_accepted; Trigger: valid; Ordering: not_evidenced; Application: executor_claimed_applied.
Admissible on-time record with disposition: applied, ordering evidence present or selected for evaluation but not deterministically resolvable	Acceptance: executor_accepted; Trigger: valid; Ordering: indeterminate; Application: executor_claimed_applied.
Admissible on-time record with disposition: refused, remaining refusal semantics valid	Acceptance: executor_accepted; Trigger: valid; Ordering: independently evaluated; Application: executor_claimed_refused.
Admissible on-time record with disposition: too_late	Acceptance: executor_accepted; Trigger: valid; Ordering: independently evaluated; Application: invalid; the signed temporal claim contradicts the authenticated on-time transition.
Admissible record with authenticated application transition after the deadline	Acceptance: preserve prior result; Trigger: valid; Ordering: independently evaluated; Application: too_late, regardless of the signed record disposition.
Inadmissible, unauthenticated, or mismatched application record	Acceptance: preserve prior result; Trigger: preserve prior result; Ordering: independently evaluated; Application: invalid.
Conflicting valid executor records with no deterministic resolution	Acceptance: preserve prior result; Trigger: preserve prior result; Ordering: indeterminate if affected; Application: indeterminate.

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.

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.

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.

Precedence	Reason code	Boundary
1	verification_time_invalid	The supplied verification time is not an unsigned integer representable in CBAP-1.
2	outer_encoding_invalid	The outer item is truncated, has trailing bytes, violates Core Deterministic CBOR, or uses a forbidden CBOR construct.
3	bundle_schema_invalid	The outer item is not the closed cbap1-bundle, has an unsupported profile version, contains a member of the wrong CDDL type, or violates member 8 CDDL non-empty cardinality, exact pair shape, 32-byte digest, or policy-byte bstr constraints.
4	policy_set_invalid	The CDDL-valid policy array exceeds MAX_POLICY_PAIRS, is unsorted, contains a duplicate policy digest, or is internally digest-inconsistent.
5	cpo_invalid	The CPO COSE envelope, payload schema including fixed CDDL constraints, object type, kid, role resolution, or signature is invalid.
6	forum_acceptance_invalid	The Exact Forum Acceptance COSE envelope, payload schema including fixed CDDL constraints, object type, kid, role resolution, or signature is invalid.
7	authorization_invalid	The Authorization Artifact COSE envelope, payload schema including fixed CDDL constraints, object type, kid, role resolution, or signature is invalid.
8	executor_verification_invalid	The executor-verification COSE envelope, payload schema including fixed CDDL constraints, object type, kid, role resolution, or signature is invalid.
9	execution_record_invalid	The execution-record COSE envelope, payload schema including fixed CDDL constraints, object type, kid, role resolution, or signature is invalid.
10	cpo_binding_mismatch	The complete signed CPO digest is not the digest bound into the Authorization Artifact.
11	acceptance_binding_mismatch	The complete signed acceptance digest is not the digest bound into the CPO.
12	action_digest_mismatch	The action bytes do not hash to the one action digest required across the four signed payloads that carry it: CPO terms label 6, Authorization Artifact label 6, Executor Verification label 5, and Execution Record label 6.
13	profile_binding_mismatch	The ABP, Authorization Trust Profile, CPO signer-to-terms issuer key-id equality, authorization-validity form, non-zero filing duration, HTTPS URI syntax for the required CPO and Exact Forum Acceptance policy-reference URIs, CPO terms forum key-id length, presence of every referenced policy digest, or absence of unreferenced policy digests does not match the supplied trust inputs and closed profile.
14	authorization_projection_mismatch	The Authorization Artifact projection does not equal the authorization identifier, issuer, or validity required by the CPO terms. The action digest is evaluated only at precedence 12 and the signed CPO digest only at precedence 10.
15	forum_terms_mismatch	The accepted forum-terms digest is not the exact projection defined in Section 4.17, the Exact Forum Acceptance signer key-id does not exactly equal the CPO terms forum key-id, or the resolved forum key is not authorized for the CPO terms forum-id.
16	authorization_digest_mismatch	The complete signed Authorization Artifact digest is not the digest bound into both executor records.
17	executor_verification_mismatch	Executor Verification label 4 does not carry the bound authorization identifier or label 6 does not carry the bound CPO digest.
18	execution_record_mismatch	Execution Record label 4 does not bind the exact signed Executor Verification record or label 5 does not carry the bound authorization identifier.
19	executor_ordering_invalid	The authenticated executor times do not satisfy not-before <= verified-at <= executed-at <= not-after.
20	filing_deadline_overflow	Adding the filing duration to executed-at exceeds the CBAP-1 unsigned-integer range.
21	filing_horizon_invalid	Exact Forum Acceptance signed-at is after not-before, valid-from is after not-before, or valid-until is before the filing deadline; CPO issued-at is after executor verified-at or expires-at is before the filing deadline; or no affected-party access declaration remains valid through the filing deadline.

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.

CBAP-1 structured-result transitions The following transition rules are closed. P identifies positive completion when the boundary passes. N identifies the transition caused by the first failed predicate. -- means no semantic-field transition.

• B1 verification_time_invalid: P --; N --.
• B2 outer_encoding_invalid: P --; N --.
• B3 bundle_schema_invalid: P notice_evidence = not_claimed; N --. This is the profile-determined completion for a valid closed cbap1-bundle, which carries no notice member.
• B4 policy_set_invalid: P --; N --.
• B5 cpo_invalid: P declared_effect = none, effect_acceptance = not_required, effect_trigger = not_applicable, effect_ordering = not_applicable, and effect_application = not_applicable. For N, signed-object predicates 1 through 7 have no semantic-field transition; signature failure sets binding = invalid and access_binding = invalid.
• B6 forum_acceptance_invalid: P --; any first failed signed-object predicate sets forum_acknowledgement = invalid.
• B7 authorization_invalid: P --; any first failed signed-object predicate sets binding = invalid.
• B8 executor_verification_invalid: P --; any first failed signed-object predicate sets pre_execution_evidence = invalid.
• B9 execution_record_invalid: P --; any first failed signed-object predicate sets pre_execution_evidence = invalid.
• B10 cpo_binding_mismatch: P --; N sets binding = invalid.
• B11 acceptance_binding_mismatch: P --; N sets forum_acknowledgement = invalid.
• B12 action_digest_mismatch: P --. A mismatch at CPO terms label 6 or Authorization Artifact label 6 sets binding = invalid. A mismatch at Executor Verification label 5 or Execution Record label 6 sets pre_execution_evidence = invalid.
• B13 profile_binding_mismatch: P discoverability = complete. Expected-ABP or expected-Authorization-Trust-Profile mismatch has no semantic-field transition. CPO signer key-id mismatch against the terms authorization-issuer key-id sets binding = invalid and access_binding = invalid. Failure of not-before <= not-after, filing duration, any HTTPS URI other than an affected-party discovery-uri, or forum key-id length has no semantic-field transition. Failure of an affected-party discovery-uri sets access_binding = invalid. A missing referenced policy digest sets discoverability = incomplete. An unreferenced policy digest sets discoverability = complete.
• B14 authorization_projection_mismatch: P selection_provenance = unilateral, binding = valid; N sets binding = invalid.
• B15 forum_terms_mismatch: P --. Accepted-digest mismatch sets forum_acknowledgement = invalid_scope. Acceptance-signer key-id mismatch or resolved-signer authorization failure sets forum_acknowledgement = invalid.
• B16 authorization_digest_mismatch: P --; N sets pre_execution_evidence = invalid.
• B17 executor_verification_mismatch: P --; failure of either label 4 authorization-identifier binding or label 6 CPO-digest binding sets pre_execution_evidence = invalid.
• B18 execution_record_mismatch: P --; failure of either label 4 exact Executor Verification binding or label 5 authorization-identifier binding sets pre_execution_evidence = invalid.
• B19 executor_ordering_invalid: P pre_execution_evidence = executor_attested; N sets pre_execution_evidence = invalid.
• B20 filing_deadline_overflow: P --; N --.
• B21 filing_horizon_invalid: P forum_acknowledgement = valid_exact, access_binding = valid, and filing_window_status derived as specified in Section 6.4. Failure of Exact Forum Acceptance signed-at, valid-from, or valid-until sets forum_acknowledgement = invalid_scope. Failure of CPO issued-at or expires-at has no semantic-field transition. Failure of the affected-party access horizon sets access_binding = invalid.

forum_operational_status remains not_checked, retrievability remains not_checked, and policy_freshness remains indeterminate on every CBAP-1 path. The following list is the complete set of CBAP-1 field-ownership exceptions to the generic failure classifications in Section 6:

• B5 signed-object predicates 1 through 7 do not transition binding; only CPO signature failure does.
• B12 Executor Verification and Execution Record action-digest failures transition pre_execution_evidence, not binding.
• B13 expected-ABP and expected-Authorization-Trust-Profile mismatches leave binding unchanged.
• B16 transitions pre_execution_evidence, not binding.
• B17 and B18 identifier or digest mismatches transition pre_execution_evidence, not binding.

Outside those listed exceptions, the generic failure classification applies as instantiated by the closed transitions above. In particular, policy_set_invalid does not by itself prove binding: invalid, and reachability failure is outside this closed CBAP-1 byte-verification procedure.

Lifecycle The common pre-execution sequence is: forum manifest or exact acceptance; Contestation Terms; selection signatures; signed CPO; signed authorization binding; executor verification; and, for an active effect, an Executor Effect Acceptance Statement. Execution, refusal, hold, fence, and application records are mode-specific and do not occur in this common prefix. The remaining order depends on the effect mode:

Mode	Required protocol order
none	execution or refusal record binding the executor-verification evidence; notice, delivery, or publication; optional filing
hold_before_execution	accepted filing receipt; verified trigger ordering before the execution boundary; Effect Application Record binding the exact effect-acceptance and filing-receipt digests; executor hold or refusal record binding that application record and any verification/acceptance linkage required by the selected record profile
fence_after_execution	execution record binding the executor-verification and effect-acceptance linkage; notice, delivery, or publication; accepted filing receipt; verified trigger ordering before finality; Effect Application Record binding the exact effect-acceptance and filing-receipt digests

When an active row is evaluated together with pre_execution_evidence: executor_attested, the execution or refusal record serving that row's action boundary (including the hold/refusal record selected for that boundary in hold_before_execution) is the same exact authenticated evidence-object identity accepted by the executor_attested path and binds both the exact verification-record digest and the exact effect_acceptance_digest. This same-record rule concerns record identity, not signer identity. An external dispute procedure, if any, is outside this document and may continue after any of those rows. This document ends after authenticating the filing-trigger and the executor's claimed state transition. It neither defines adjudication nor converts a hold or fence into a remedy. Changing the forum, procedure, Standing Policy, filing window, or effect policy requires a new CPO and a new authorization binding. An active effect additionally requires a new Executor Effect Acceptance Statement. A deployment replacing a CPO after execution SHOULD NOT narrow an already-open filing window instantiated by the prior binding unless the previously bound procedure authorized that transition. The base protocol and CBAP-1 do not carry authenticated predecessor linkage or prior-binding evidence, so a verifier cannot evaluate that continuity property. A profile that claims verifier-enforced non-narrowing MUST define authenticated predecessor/successor linkage, the predecessor evidence supplied to the verifier, the exact window-comparison predicate and boundary operators, the procedure-authorized exception rule, and the failure classification for missing, invalid, ambiguous, or conflicting predecessor evidence.

Implementation Status This section follows the guidance in and is intended to be removed before publication as an RFC. The implementation evidence snapshot described below is current through 4 September 2026.

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.

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.

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.

Security Considerations

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

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Relationship to Existing Work

EMILIA Protocol artifacts 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.

Agentic Dispute Protocol and ADRP The Agentic Dispute Protocol defines filing, evidence, adjudication, awards, and arbitrator discovery. 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.

OAuth and agent authorization frameworks OAuth Rich Authorization Requests , WIMSE-based guidance, and agent authorization frameworks such as 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.

SCITT A CBAP signed object is not itself a SCITT Signed Statement . 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 , 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.

RATS and COSE The reusable FAM has a role analogous to an endorsement in the RATS architecture : 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.

IANA Considerations The initial individual draft requests no IANA action. A later protocol revision may request media types, a well-known URI, or a registry of structured reason codes after the encoding and deployment model stabilize.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] Federal Information Processing Standard, FIPS This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052). This document, along with RFC 9052, obsoletes RFC 8152. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. This specification refers to cryptographic algorithm identifiers that fully specify the cryptographic operations to be performed, including any curve, key derivation function (KDF), and hash functions, as being "fully specified". It refers to cryptographic algorithm identifiers that require additional information beyond the algorithm identifier to determine the cryptographic operations to be performed as being "polymorphic". This specification creates fully-specified algorithm identifiers for registered JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) polymorphic algorithm identifiers, enabling applications to use only fully-specified algorithm identifiers. It deprecates those polymorphic algorithm identifiers. This specification updates RFCs 7518, 8037, and 9053. It deprecates polymorphic algorithms defined by RFCs 8037 and 9053 and provides fully-specified replacements for them. It adds to the instructions to designated experts in RFCs 7518 and 9053. Informative References This document describes how the zone identifier of an IPv6 scoped address, defined as in the IPv6 Scoped Address Architecture (RFC 4007), can be represented in a literal IPv6 address and in a Uniform Resource Identifier that includes such a literal address. It updates the URI Generic Syntax specification (RFC 3986) accordingly. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. This document defines two strategies for handling long lines in width-bounded text content. One strategy, called the "single backslash" strategy, is based on the historical use of a single backslash ('\') character to indicate where line-folding has occurred, with the continuation occurring with the first character that is not a space character (' ') on the next line. The second strategy, called the "double backslash" strategy, extends the first strategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy. Both strategies use a self-describing header enabling automated reconstitution of the original content. In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. This document specifies a new parameter authorization_details that is used to carry fine-grained authorization data in OAuth messages. This document describes how to include CBOR Web Token (CWT) claims in the header parameters of any CBOR Object Signing and Encryption (COSE) structure. This functionality helps to facilitate applications that wish to make use of CWT claims in encrypted COSE structures and/or COSE structures featuring detached signatures, while having some of those claims be available before decryption and/or without inspecting the detached payload. Another use case is using CWT claims with payloads that are not CWT Claims Sets, including payloads that are not CBOR at all. This document describes how the zone identifier of an IPv6 scoped address, defined in the IPv6 Scoped Address Architecture specification (RFC 4007), should be entered into a user interface. This document obsoletes RFC 6874 and updates RFCs 4007, 7622, and 8089. Traceability in supply chains is a growing security concern. While Verifiable Data Structures (VDSs) have addressed specific issues, such as equivocation over digital certificates, they lack a universal architecture for all supply chains. This document defines such an architecture for single-issuer signed statement transparency. It ensures extensibility and interoperability between different transparency services as well as compliance with various auditing procedures and regulatory requirements. Consulate, Inc. This document specifies the Agentic Dispute Protocol (ADP), a standardized framework for autonomous agents and AI systems to file, process, and resolve disputes through structured, automated processes. The protocol defines message formats, transport mechanisms, evidence submission standards, and cryptographic proof requirements for internet-native dispute resolution. ADP is designed to handle disputes arising from AI agent interactions, service level agreement breaches, and automated contract enforcement, providing deterministic, auditable, and legally enforceable outcomes. ADP includes chain of custody tracking, dual-format award specifications (JSON and PDF), arbitrator discovery mechanisms, and support for multiple resolution frameworks including expert determination, binding arbitration, mediation, and hybrid approaches. Alibaba Group Alibaba Group Cisco Okta Alibaba Group This document describes how to integrate multiple OAuth 2.0 extensions to enable secure authorization for AI agents acting on behalf of users. It combines cross-domain identity, policy-based authorization, user consent evidence, and multi-hop delegation into a cohesive framework for autonomous agent authorization. EMILIA Protocol, Inc. This document defines the EMILIA Protocol (EP) authorization receipt, an evidence artifact binding an enrolled approver key to one canonical action before execution. An approver-held key signs an Authorization Context containing the action hash, policy reference, shared authorization instance, per-signoff nonce, audience, and validity window. A Trust Receipt carries the signed contexts, terminal consumption record, and Merkle inclusion material so a relying party can verify the recorded event offline under independently selected log, directory, policy, and approver trust inputs. The receipt establishes only the guarantees of the selected verification profile. The mapping from an enrolled approver identifier to a natural person is asserted by the directory authority. Offline verification does not establish current revocation status, global non-replay, comprehension, legality, safety, or execution. Replay prevention requires an online atomic consumption store at the executor. The state-machine invariants are machine-checked under the assumptions stated in this document. This revision defines the closed EP-AUTHORIZATION-BUNDLE-v1 pre- execution profile and its verification algorithm. The bundle carries the Action Object, signed Authorization Contexts, signoffs, key proofs, and presentation evidence; it deliberately carries no terminal consumption or execution claim. An optional, profile- identified authorization binding can commit the human evidence to an independently verified native authorization artifact without replacing that artifact or making this receipt format depend on its transport or trust model. A receipt is evidence, not authorization. This document does not treat a local user interaction as an authorization decision. It defines one evidence artifact that an authorization architecture can use in a human-confirmation flow: the signed Authorization Context is action-bound confirmation evidence an authorization server MAY validate and bind to the grant it issues. The resulting Trust Receipt records terminal consumption and remains evidence; neither object makes the authorization decision. That decision remains with the authorization server. SwarmSync.AI This document defines the Agent Dispute Resolution Protocol (ADRP), a wire protocol and state machine for resolving disputes that arise from cryptographically-attested agent-to-agent (A2A) transactions. ADRP is the companion specification to ATXN (draft-stone-atxn-01), which defines what an A2A transaction is. ADRP defines what happens when a party contests one. ADRP severs an equivalence that every prior agentic commerce design has implicitly assumed: that a valid cryptographic proof bundle equals contractual satisfaction. It does not. Conduit-style cryptographic verifiers prove that an agent took specified actions; they do not prove that those actions satisfied the principal's Intent Mandate. ADRP bifurcates disputes into a *cryptographic class* (resolvable by code from the proof bundle and mandate chain) and a *semantic class* (resolvable only against pre-committed machine- readable acceptance criteria, with arbitration escalation when those criteria are absent or under-specified). ADRP introduces the *Arbitration Mandate* as an ADRP extension that can be cryptographically linked to AP2 Intent/Cart/Payment Mandates or to an ATXN Standing Token. It is not an AP2 core mandate. The Arbitration Mandate records the principal's pre-committed dispute policy and is designed to support a written arbitration agreement where applicable; enforceability remains jurisdiction- and fact- specific. ADRP defines a *counter-attestation override pattern* in which a signed RulingBundle supersedes a Conduit ProofBundle by a signing- time precedence rule rather than by mutation. Both the original attestation and the override are preserved forever in the hash chain; "override" is a verification-time computation, not a write. Companion specifications: * *ATXN* (draft-stone-atxn-01): defines the A2A transaction primitive that ADRP resolves disputes over * *AIVS* (draft-stone-aivs-01): cryptographic audit-trail substrate for proof bundles * *VCAP* (draft-stone-vcap-01): verified-commerce escrow rails consumed by ADRP EscrowDirectives * *ATEP* (draft-stone-atep-01): trust passports referenced by Standing Tokens in ADRP

Changes from -00 No signed CBAP-1 wire-object shape, numeric member label, CDDL grammar production, or CBAP-1 COSE signature-input construction changed between -00 and -01. The Exact Forum Acceptance label 6 semantic registry name was corrected from submission-receipt-policy to submission-receipt-profile to match the CDDL, and two CDDL productions were re-wrapped without semantic change. This revision:

• makes the verification algorithm and first-failure contract deterministic: signed-object validation has one normative pipeline, fixed CDDL constraints are owned by the corresponding signed-object boundaries, cross-object predicates have one closed precedence order, and the outer-CBOR versus bundle-schema split is explicit;
• defines the complete negative-path structured-result state machine. All 17 result entries have defined initial values, fields that can be unevaluated admit the required indeterminate/not-checked states, processing stops at the first failed boundary and predicate, and later semantic fields cannot overwrite earlier resolved states;
• makes deterministic encoding and signature verification boundaries explicit at all encoded levels, selects the uncofactored Ed25519 verification equation, and aligns external Ed25519 trust-key decoding with RFC 8032 without adding a separate weak-key or verify_strict policy;
• reconciles digest semantics around exact signed artifacts. Signed-artifact digests are over the complete received signed representation, the CPO and contestability digest terminology is made consistent, reconstructed bytes matter only when they differ from the received artifact, the Effect Application Record has a defined signed-artifact digest used by prior_application_digest, and a selected trigger profile that consumes submission_digest MUST define its exact authenticated construction rather than relying on an undefined generic filing byte string;
• defines ABP and Authorization Trust Profile values as bound profile identifiers, fixes CBAP-1 trust-input cardinality, assigns each signed-object boundary through a closed issuer/forum/executor trust-role table while preserving separate fail-closed forum-id authorization, and makes generic object admissibility depend on authenticated authority, closed-schema, and role predicates before path-dependent members can be consumed. Signature length and trust-key algorithm checks remain owned by those signed-object boundaries; unused controlling-trust-domain input is removed from mandatory CBAP-1 verification; selection evidence MUST use the exact bound selection profile; and profile-identifier bindings are compared as exact URI-and-digest pairs rather than by an implicit identifier relation;
• makes forum and authorization binding predicates exact, including issuer-key identity, forum signer/key and forum-id authorization, Exact Forum Acceptance trust ownership, and explicit object-local nonce semantics with no implied cross-object equality, freshness, uniqueness, replay, or ordering rule. Dependent classification cannot consume CPO, acceptance, profile, or path-dependent object members before the owning authentication, digest binding, and admissibility predicates have succeeded;
• completes FAM class semantics: class type/profile identity, signer/key relation, accepted ABP/Authorization Trust Profile identifier pairs, authorization-validity containment within may_bind_from / may_bind_until, filing-horizon and issued_at semantics, and deterministic failure ownership. The may_bind fields no longer imply binding-time measurement;
• completes filing-time semantics by fixing the relevant timestamp model, deterministic reduction when a filing profile can yield multiple authenticated candidate clocks, and the half-open CBAP-1 execution-time filing interval. Generic filing-window profiles additionally define the exact duration_seconds arithmetic, non-representable behavior, one common comparison domain for start/verification/closing values, and mutually exclusive and exhaustive not_open / open / closed boundary semantics, with indeterminate rather than implementation-local conversion or boundary conventions when the comparison cannot be completed deterministically;
• makes previously exposed generic result states constructible without changing the closed structured-result vocabulary. An optional Forum Operational Status Profile selected by trusted local verifier policy defines evidence and predicates for reachable / unreachable; with no operational-status profile selected, the result remains not_checked. A CPO can use forum_acceptance.mode = none to produce forum_acknowledgement: absent, with that disclosure-only mode coupled to effect_policy.mode = none. With no pre-execution evidence profile selected, the result is pre_execution_evidence: not_claimed, while a selected claim whose required evidence is missing produces absent;
• defines Notice and affected-party access semantics, including Notice signer authority, signed-Notice digest construction, binding of by-reference Notice access to an authenticated CPO discovery declaration, separation of access integrity from retrievability, and the fact that public_transparency is not itself a CBAP-1 network retrieval protocol;
• separates effect acceptance from effect application and closes active-effect digest, signature-input, validity-horizon, and application-time boundaries: Authorization Artifact, forum acceptance, and filing-receipt digests have exact signed-artifact constructions; acceptance and application-record signature inputs exclude only the signature being computed; Executor Effect Acceptance has authenticated mode-specific validity horizons, deterministic temporal reduction and cross-profile comparison rules, explicit operators, and invalid/indeterminate classification; the generic verifier compares authorization identifiers and action digests only across objects whose selected closed profiles define those members; executor acceptance requires authenticated strict-before ordering of the exact acceptance event against execution under the bound serialization profile, without treating accepted_at as ordering evidence; application records bind the exact acceptance and receipt digests; ordering-evidence absence is distinguished deterministically from unevaluable evidence; and idempotent prior application is referenced deterministically. For application timing, the selected active-effect profile composition now owns exactly one authenticated trigger value, seconds-capable deadline construction, exactly one authenticated application-transition value, and a deterministic common comparison domain; an unevaluable comparison yields indeterminate. Late transitions derive too_late before signed disposition semantics, while deterministically on-time applied / refused dispositions map to executor_claimed_applied / executor_claimed_refused, and an on-time signed too_late claim is invalid;
• removes verifier requirements that cannot be evaluated from mandatory inputs. Supersession continuity becomes deployment guidance unless a future profile supplies authenticated predecessor evidence; replacement-forum continuity likewise remains an operational objective rather than an unevaluable exception to Exact Forum Acceptance validity; generic exact- acceptance temporal predicates execute only after the compared acceptance members are authenticated and, for valid_until, after the filing-window closing time is deterministically derived; authenticated filing transport is explicitly owned by the deployment rather than by the CBAP-1 verifier; and a later withdrawal cannot erase a historically valid forum acknowledgement. Verifier-evaluated withdrawal or continuity requires the exact bound policy and a profile that completely defines authenticated event, authority, binding, ordering, linkage, and failure semantics rather than an unbound local convention;
• narrows executor_attested to the signer continuity that the evidence actually proves. The verification and execution/refusal records form a digest-linked signed sequence whose signer keys are independently authorized for the required executor role; CBAP-1 does not require those kid values to be equal and the base result does not establish a common executor identity when they differ. A stronger same-executor claim requires a selected pre-execution evidence profile to define and authenticate the key-rotation, delegation, exact-key, or common-identity relation it relies on;
• aligns structured-result prose with the closed CBAP-1 transition model: out-of-vocabulary fixed integers fail the containing closed schema rather than producing a post-schema unsupported field result, and pre- authentication CPO schema failure does not by itself prove access_binding: invalid;
• makes non-unilateral selection provenance deterministic by requiring the selected selection profile to declare exactly one of multiparty or external, with no verifier-side precedence or fall-through between them;
• hardens security and resource handling without changing the reason-code vocabulary: CBAP-1 has explicit resource ceilings, a normative MAX_NESTING_DEPTH convention with the top-level decoded item at depth zero, opaque byte strings and a reset for separately decoded CBOR, explicit-port lexical rules, clearer unsalted action-digest semantics, and deployment guidance for safe dereferencing of signed URIs;
• rebuilds the generic verification-input description from the complete verification procedure so that protocol/profile inputs, local trust/policy inputs, retained replay/idempotency/ordering state, and path-dependent evidence are distinguished from derived values; and
• refreshes the implementation evidence from the original 56-test A3 corpus through the -01 61-, 63-, 66-, and 73-test states while preserving the implementation boundary: the current A3 lineage remains an Exact Forum Acceptance implementation and does not implement FAM class acceptance, valid_class, or agent-contestability-notice-v1.

These changes incorporate the review and implementation findings recorded during preparation of -01.

Acknowledgements AI-based tools were used during the development and evaluation of this work. The author made the design decisions, reviewed and approved the submitted text, and remains solely responsible for its content and technical claims. The author thanks Emek Can Doğru and Iman Schrock for detailed review of the -00 revision and for identifying issues addressed in this revision.