]> Independent Researcher

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

Security agent authorization contestability CBAP-1 verifiable evidence Signed authorization records can show that an action was authorized under specified rules, but they do not by themselves establish a stable or verifiable path for an Affected Party to contest that action. This document defines Contestability Binding Application Profile 1 (CBAP-1), a closed application profile that binds an Authorization Artifact to signed contestation terms before execution. CBAP-1 specifies deterministic CBOR and COSE encoding, fixed artifact formats, executor-verification and execution records, by-value policy material, a half-open filing window, a closed structured result, and deterministic first-failure reason codes. CBAP-1 does not define contestation notices, active execution-state effects, network reachability checks, policy-freshness evaluation, dispute adjudication, or remedy. It reports authenticated protocol facts and signed claims without asserting forum independence, legal validity, physical execution order, or fairness.

Introduction Securing an agent authorization with signatures, receipts, validity limits, and logs can answer one question: was the action authorized under the specified rules? It does not answer a different question: where and how an Affected Party can contest the action, or which contestation parameters were bound before execution. A locator alone is insufficient. If the forum, procedure, policy references, or filing window can be substituted after authorization, two implementations can validate the same authorization while deriving different contestation paths. CBAP-1 removes that ambiguity by binding the Authorization Artifact to signed contestation parameters, Exact Forum Acceptance, executor-verification evidence, an Execution Record, and the policy material required by those objects. It defines one deterministic verification procedure and one closed structured-result contract. The profile is intentionally narrow. Successful CBAP-1 verification reports selection_provenance: unilateral, exact forum acceptance, pre_execution_evidence: executor_attested, and no active execution-state effect. It does not infer forum independence, policy fairness, legal standing, current endpoint availability, human receipt, physical execution order, or remedy.

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.

Scope This document specifies one self-contained application profile. It defines the encoding rules, payload structures, trust inputs, verification procedure, and result contract required to bind an authorization to contestation terms before execution. CBAP-1 specifies:

• Core Deterministic CBOR encoding with fixed resource ceilings for the complete bundle and its signed objects;
• tagged embedded-payload COSE_Sign1 objects using the fixed CBAP-1 Ed25519 profile;
• closed schemas for the Contestation Parameters Object, Exact Forum Acceptance Statement, Authorization Artifact, Executor Verification record, Execution Record, policy set, and bundle;
• direct binding between the Authorization Artifact and CPO, together with exact forum-terms binding;
• local trust inputs for issuer, forum, and executor roles;
• a half-open filing window [executed-at, filing_deadline);
• a deterministic 21-boundary verification procedure;
• a 17-entry structured result comprising 16 semantic fields plus reasons, with a closed CBAP-1-reachable vocabulary; and
• a closed first-failure vocabulary of 21 reason codes.

CBAP-1 does not define class-based forum acceptance, separate contestability notices, multiparty or external selection evidence, active hold or fence effects, network reachability checks, policy-freshness evaluation, or generic extension machinery. This document also does not define dispute adjudication, evidence exchange, appeals, remedies, legal standing, forum impartiality, legal enforceability, or the legitimacy of the underlying authorization or policy.

Terminology Authorization Artifact: The signed cbap1-authorization object defined by this profile. It binds the authorization identifier, issuer, validity interval, action digest, and CPO digest. Authorization Instance Identifier (authorization-id): The authorization-id CDDL member is a 16-byte identifier for one authorization instance, intended to be globally unique or collision-resistant. Action Digest (action_digest): SHA-256(action_bytes) over the exact action byte string carried by the bundle, recomputed and checked against each signed object that carries the action digest. Contestation Parameters Object (CPO): The closed signed data structure defined by the CBAP-1 CDDL in Section 5.3. Contestation Terms: The unsigned per-authorization data carried as cbap1-terms inside the CPO, including profile identifiers, authorization validity, forum and policy references, affected-party access declarations, and filing-window parameters. Contestability Binding: The cryptographic binding from the Authorization Artifact to the exact signed CPO through its digest, together with the cross-object bindings verified by Section 7. Forum: The service or institution designated to receive a contestation. Successful signature verification authenticates the forum-signed statement under the configured trust inputs; it does not establish forum independence, competence, fairness, or legal jurisdiction. Exact Forum Acceptance Statement: The forum-signed acceptance of the exact forum_terms projection bound to the CPO. Authorization Binding Profile (ABP): The rules used to verify and project the Authorization Artifact. CBAP-1 fixes one Authorization Artifact format and one ABP identifier. Authorization Trust Profile: The opaque profile identifier supplied by trusted local policy and bound in the CPO terms to identify the authorization trust semantics accepted by the verifier. Standing Policy: Versioned policy material identified by digest and URI that describes which roles or parties may file. CBAP-1 verifies its bound identity and by-value integrity but does not establish the legitimacy of the policy. 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.

CBAP-1 Profile

Mandatory encoding: CBAP-1 Core Deterministic CBOR The Contestability Binding Application Profile 1 (CBAP-1) is the mandatory-to-implement encoding and executable profile defined by 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 defines one closed end-to-end path comprising 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 are outside CBAP-1 and are unsupported by this 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 CBAP-1 is established by the authorization identifier, action digest, CPO digest, Authorization Artifact digest, Executor Verification digest, and the required signer/key relations. 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. 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 the deliberately small Authorization Artifact format admitted by this profile. The expected CBAP-1 ABP identifier is fixed by this profile as defined below; other authorization formats and ABP behaviors are outside CBAP-1. It is not proposed as a universal agent-authorization format.

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 7.2 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. CBAP-1 uses that local trust set and local policy for signed-object trust resolution and filing-clock authority.

Structured result CBAP-1 returns one closed structured result. The result has exactly sixteen semantic fields plus reasons; implementations MUST NOT add profile-defined result fields or result values to this CBAP-1 result. The closed scalar vocabulary is:

Field	CBAP-1 values
binding	valid, invalid, indeterminate
pre_execution_evidence	executor_attested, invalid, indeterminate
discoverability	complete, incomplete, indeterminate
forum_acknowledgement	valid_exact, invalid_scope, invalid, indeterminate
forum_operational_status	not_checked
selection_provenance	unilateral, indeterminate
access_binding	valid, invalid, indeterminate
notice_evidence	not_claimed, indeterminate
retrievability	not_checked
filing_window_status	not_open, open, closed, indeterminate
policy_freshness	indeterminate
declared_effect	none, indeterminate
effect_acceptance	not_required, indeterminate
effect_trigger	not_applicable, indeterminate
effect_ordering	not_applicable, indeterminate
effect_application	not_applicable, indeterminate

filing_window_status is derived by step 21 of the CBAP-1 verification procedure as not_open, open, or closed, and B21 completes the field with that derived value on its positive transition. Its indeterminate value is the initialized value preserved when verification stops before B21 completes the field. reasons has a separate closed vocabulary. It is [] on the positive path. On a negative path it contains exactly one of the twenty-one reason codes defined by the B1–B21 failure-precedence table, and that code is the first failing boundary under the specified precedence. An implementation MAY retain additional diagnostics for operators, but MUST NOT return implementation-specific strings or a second reason code in reasons. Before evaluating B1, a verifier MUST initialize the 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 CBAP-1 value. The reasons array begins empty. For binding, discoverability, and declared_effect, indeterminate means that the verifier has not established enough validated input to select another value in that field's CBAP-1 vocabulary. It MUST NOT replace an already established binding: invalid or discoverability: incomplete result. More generally, each semantic field transitions from its initial value at most once and then retains that value for the remainder of verification. The result evolves monotonically under the closed B1–B21 boundaries:

• For B1 through B4, a positive semantic-field completion occurs only where the closed transition table explicitly assigns one after the whole boundary passes. No other semantic field completes in those boundaries.
• For signed-object boundaries B5 through B9, 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 B10 through B21, a predicate that passes earlier in the current boundary may complete a semantic field before a later predicate in that boundary fails only where the closed transition table explicitly assigns that completion. There is no open-ended post-failure derivation.
• On a negative path, reasons MUST transition exactly once from [] to the one-element array containing the first failure-precedence reason code. On the positive path, reasons remains [] and transitions zero times.
• When a predicate fails, verification stops for result derivation at that predicate. Later predicates in the same boundary and all later boundaries do not derive additional result values.

access_binding reports only the integrity and CBAP-1 constraint status of the declared affected-party access data. It is valid only when the B21 positive completion occurs after the required prior CBAP-1 checks and the access horizon passes. It is invalid only where the closed transition table assigns that value: CPO signature failure; authenticated CPO signer key-id mismatch against the authorization-issuer key-id declared in the CPO terms; failure of an affected-party discovery-uri; or failure of the affected-party access horizon. Otherwise it retains its current value, including initialized indeterminate on paths that stop before a listed completion. access_binding does not report delivery or current retrievability. CBAP-1 performs no policy-freshness evaluation. policy_freshness therefore remains indeterminate on every CBAP-1 path. One positive-path result, for a verification_time before executed-at, is: The positive-path filing_window_status value is derived by step 21 as not_open when verification_time < executed-at, open when executed-at <= verification_time < filing_deadline, and closed when verification_time >= filing_deadline. A conforming implementation MUST NOT collapse this structured result into a boolean such as contestable: true or into an independence claim without applying an explicitly identified local policy. In particular, forum_acknowledgement: valid_exact does not establish forum reachability or independence; access_binding: valid does not establish delivery or current retrievability; and pre_execution_evidence: executor_attested does not prove physical state or remedy.

Verification

CBAP-1 verification procedure A CBAP-1 verifier performs the following closed procedure in order. Steps 1 through 21 correspond one-to-one with failure-precedence boundaries B1 through B21; step 22 returns the structured result and is not a failure boundary. Steps 1 through 9 establish the local-input, outer-item, policy-set, and signed-object boundaries in the same order as Section 7.2. Resource ceilings from Section 5.1 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 5.1 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 5.1 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 7.2.
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 5.4 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 field in the CBAP-1 structured-result contract 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 the CBAP-1 failure-precedence table. 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 CBAP-1 structured result only through the closed transition rules in that table 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 5.4, 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 7.1 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 7.1. 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 CBAP-1 structured 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 7.1. 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 clarifications for the closed failure classifications above:

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

The closed transitions above are exhaustive for CBAP-1 failure classification. In particular, policy_set_invalid does not by itself prove binding: invalid, and reachability failure is outside this closed CBAP-1 byte-verification procedure.

Implementation Status This section follows the guidance in and is intended to be removed before publication as an RFC. The implementation evidence snapshot recorded here is current through 4 September 2026. It is non-normative and does not define or override CBAP-1 requirements. The development evidence includes a Python reference implementation, an oracle-blind, context-isolated Rust reconstruction, and a JavaScript cross-check. The cross-check re-encoded the external positive bundle fixture byte-for-byte and verified all five Ed25519 signatures. That fixture has SHA-256: 8a47e89abb2c77a9de27ffb59a5bc89a7226509236e35b0f11cf6819fd1b6646 The first frozen Rust reconstruction exposed a digest-label ambiguity and remains frozen at SHA-256: 956b88d2832e4265913cb73f93e69b960ef6f1d860f8acbc5b50ea453cbab2f0 After specification repair, the frozen A3 source-and-artifact package was recorded at SHA-256: f2b9b0745ca8b751322f416ed62e73769b2396934b8beb811d5f71b4fc88b129 That reconstruction passed its 56-test baseline and matched the retained evaluator for the positive fixture, the closed failure-precedence corpus, and 28 URI cases. A later specification refresh implemented exact policy-set equality and the half-open filing interval, added nonce non-relation regression coverage, and passed 61 tests. Subsequent public-key-decoding, trust/profile-input, resource-limit, and URI-port hardening on the same Rust lineage extended the locked suite to 73/73 with zero failures. The executable evidence is limited to the exact CBAP-1 path specified by this document. It does not establish an independent human implementation, production deployment, interoperability certification, exhaustive parser safety, or a security audit. A stable public location and explicit software license for the implementation and evidence packages are to be designated as part of a verifiable release publication. Until then, this section records development evidence but does not claim public package availability. Implementation and test-package contact: Tiago Pinto tiago@donttrustverify.pt.

Security Considerations

Issuer-Controlled Forum A discoverable forum can still be biased or controlled by the issuer. On the successful path, CBAP-1 reports selection_provenance: unilateral. A valid forum signature therefore does not establish institutional independence.

Forum Substitution The forum identifier, submission endpoint, key identifier, procedure, and bound policy references are protected by the CBAP-1 digest and signature bindings. A verifier MUST reject substitution after authorization.

Policy Equivocation Serving different CPOs or policy documents to different audiences can move equivocation into the contestation layer. Deployments claiming a consistent view SHOULD register CPOs or their digests in a transparency service and MUST define how readers detect split views.

Endpoint Availability and Network Access Cryptographic binding and Exact Forum Acceptance do not prove current endpoint availability. CBAP-1 performs no forum-operational-status or retrievability check; forum_operational_status and retrievability remain not_checked. CBAP-1 verification does not require dereferencing a signed URI. A deployment that chooses to dereference one SHOULD treat the target, each redirect, and each 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.

Deadline Control and Clock Bias An issuer can declare a filing window that is too short to be useful. Verification authenticates the filing-window inputs and checks the required arithmetic; it does not establish fairness. Relying parties SHOULD apply an appropriate minimum-window policy and MUST NOT infer legitimacy from syntactic validity. 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, but it does not prevent executor-controlled clock bias. A deployment that requires protection against such bias SHOULD constrain clock authority and acceptable skew through its local trust inputs and policy.

Standing and Privacy A Standing Policy can exclude a person materially affected by an action. CBAP-1 makes the policy identity and supplied bytes verifiable; it does not establish legal standing or policy legitimacy. Standing SHOULD be expressed by role or policy where possible. Personally identifying evidence SHOULD be disclosed only under an appropriate confidentiality mechanism.

Abuse Controls and Credential Survivability Anti-replay, rate limiting, authentication, and other abuse controls MUST NOT silently alter the bound Standing Policy or filing window. An action can disable the only credential or lookup path available to an Affected Party after execution. CBAP-1 binds the declared access information but does not prove that a real-world retrieval method survives the action. Deployments requiring survivable access need an operational method that remains usable independently of the contested action.

Replay and Exact-Acceptance Scope Exact Forum Acceptance is bound to the exact forum_terms_digest, forum signer, forum identifier authorization, and the other CBAP-1 cross-object digests. Evidence from different terms, keys, profile identifiers, policy references, or authorization bytes does not become valid because labels or URIs appear similar. CBAP-1 nonce members are object-local opaque values. Their presence or value does not establish freshness, uniqueness, single use, replay resistance, or protocol ordering.

Executor Claims and Confidentiality Signatures establish integrity and signer attribution, not physical execution order or organizational identity across different keys. pre_execution_evidence: executor_attested therefore establishes only the signed claims accepted under the configured executor-role trust inputs and the required digest and time bindings. CBAP-1 fixes action_digest = SHA-256(action_bytes) and carries action_bytes by value in the complete bundle. Before disclosure, a low-entropy action digest can permit offline guessing. Deployments SHOULD restrict access to the bundle and action bytes when confidentiality is required. A deployment MUST NOT replace CBAP-1's SHA-256(action_bytes) construction with a salted commitment and still claim CBAP-1 conformance.

Historical Verification and Common Control Historical verification depends on the signed bytes and the trust inputs accepted by the verifier for the relevant role. CBAP-1 does not define a separate key-rotation or continuity protocol. Distinct issuer, forum, and executor keys establish cryptographic separation, not organizational, legal, physical, or logical independence. Implementations MUST NOT infer institutional independence merely from the number of valid signatures or distinct key identifiers.

IANA Considerations This document requests no IANA action.

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

Acknowledgements The author thanks Emek Can Doğru and Iman Schrock for their review of the architectural predecessor to this document.