Attestation Reconciliation Protocol

3.1. What this document builds on

The transparency model is [RFC9943]. A Reconciliation Output is a Signed Statement in that architecture's sense, the Settlement-Layer Ledger is a Transparency Service, and Appendix B states the mapping field by field. This document defines no registration API and expects [I-D.ietf-scitt-scrapi]. Receipts are [RFC9942]. Where the two disagree, [RFC9943] governs and this document is wrong.¶

The evidence-appraisal vocabulary is [RFC9334]. Appendix D states the correspondence between a Reconciliation Output and an Attestation Result, and the Reconciliation Agreement occupies the position of an Appraisal Policy. This document does not define a second appraisal model.¶

Logging and inclusion proofs are [RFC6962] and [RFC9162]. Section 5.10 uses the [RFC9162] leaf and proof structure without modification. The Merkle constructions here are that construction; the only thing this document adds is what goes into the leaf.¶

Encoding is [RFC8949] with [RFC8785] where a JSON form is required, and signatures are [RFC9052] and [RFC9053]. Section 7 adds determinism requirements over those and defines no new encoding.¶

Requester authentication over HTTP is [RFC9421], and the agentic binding of Section 6 composes with [I-D.meunier-webbotauth-httpsig-protocol] rather than defining a parallel scheme.¶

3.2. What this document does not replace

It does not replace Verifiable Credentials or Decentralized Identifiers, and it is not a credential format. A Reconciliation Output is not held by a subject, is not presented by a subject, and carries no selective-disclosure mechanism for a holder. Where a deployment needs a subject-held credential, that work exists and this document is not it.¶

It does not replace a national register's own API, signing chain or statutory access regime, and it does not ask a register to change any of them. The whole premise of Section 5.5 is that registers keep their interfaces.¶

It does not define a trust framework, an accreditation scheme or a policy language. What counts as an acceptable register, an acceptable operator or an acceptable verdict is out of scope and stays with the relying party.¶

3.3. Why it is a separate document

The problem in Section 2 is a relying party requiring a deterministic combined verdict over two or more sovereign registers that will not export their raw records, and requiring a settlement record a sovereign regulator can audit afterwards. Each ingredient of that exists. The combination does not.¶

[RFC9943] makes a statement transparent once it has been made, and is deliberately silent on how the statement was produced or whether it reconciles anything. [RFC9334] appraises evidence about one attester and does not reconcile the outputs of several independent authorities into one verdict. [RFC9162] proves an entry is in a log and says nothing about what the entry means. None of the three is deficient in this. Reconciliation across sovereign registers, under a declared agreement, with non-answers distinguished from negative answers and with a coverage denominator a relying party can check, is a layer above all of them, and adding it to any one of them would push work into that document which its own charter does not cover.¶

The alternative this document rejects, and names so that a reader can disagree with the choice rather than assume it was not made, is a profile of [RFC9943] carrying the reconciliation semantics in an unconstrained payload. That is smaller and it fails at the one property the problem requires: a payload a Transparency Service does not interpret cannot carry a verdict two independent verifiers must reach identically. Determinism has to be specified where the verdict is produced.¶

3.4. Where the design was taken from elsewhere

Several mechanisms here were established by other people, several of them in review of earlier revisions of this document, and each is named at the point of use as well as in Section 11. The Signing Input Digest construction of Section 8.11 follows from a reproduction posted to the SCITT mailing list rather than from anything original here. The sweep-every-instance method applied to that construction, and the two-axis separation of the coverage vocabulary, are likewise attributed where they are used. A specification that presents a borrowed design as its own invention is defective independently of whether the design is sound, and the naming is normative practice in this document rather than courtesy.¶

5.1. Canonical Claim Ingestion

A Canonical Claim comprises:¶

• Subject Identifier¶

• Predicate (drawn from the controlled Predicate Taxonomy)¶

• Attested Value (in the canonical type for the Predicate)¶

• Applicable-Regimes Set¶

• Evidentiary Provenance Manifest¶

• Claim Timestamp ([RFC3339] UTC)¶

• Claim Hash: the SHA-256 digest over the deterministically encoded CBOR array ["arp-claim-v1", Deployment Blinding Value, canonical serialisation], where the canonical serialisation is the [RFC8785] form of the preceding fields as Section 4 constructs it, carried as a CBOR byte string. Framing the blinding value as an array element rather than concatenating it is what stops two deployments differing on order, separator or length prefix while claiming the same construction identifier¶

The reconciliation server MUST verify, before computing the Claim Hash, that the octets it received under Section 7.2 are the canonicalisation of the claim they carry. It MUST parse them, re-serialise the parsed fields as this section constructs them, and refuse a request whose received octets differ from that re-serialisation, or whose member set is not exactly the fields enumerated above, returning the 422 of Section 7.2 with a Remediation Advisory naming the difference.¶

Section 7.2 has the requester supply the [RFC8785] serialisation as a byte string and has the server hash the octets it received, for a reason that is correct: re-serialising a natively encoded claim would let two servers receiving identical bytes compute different Claim Hashes. The consequence not drawn was that the preimage of the Settlement-Layer Ledger index is then chosen by the requester. A claim submitted in NFD and the same claim in NFC have identical canonical field values and produce two Claim Hashes, two ledger indices and two retroactive-evaluation keys, and a sweep selecting on one misses the other. The check above keeps the requester's octets as the preimage and makes them canonical, which is what the rest of this section already assumes of them. The same argument appears at Section 4 for the Authority Origin -- a value normalised on receipt is a value two parties hash differently before they compare it -- and it was applied there and not here.¶

Two claims whose canonical field values are identical MUST produce the same canonical form, and the same Claim Hash within one deployment. Across deployments the Claim Hash differs by the Deployment Blinding Value while the canonical form does not. Declared array order is significant; claims differing only in declared array order are distinct claims. The Claim Hash is the index on the Settlement-Layer Ledger and the key for retroactive re-evaluation.¶

The Evidentiary Provenance Manifest is a JSON object, and this document does not otherwise constrain its members. It MUST NOT carry a signature, a COSE_Sign1, or any other signed artefact, in any member at any depth, and a reconciliation server MUST refuse a claim whose Manifest carries one, returning the 422 of Section 7.2.¶

Where the evidentiary provenance is itself a signed artefact -- a COSE-enveloped evidence structure, or a Verified Principal Credential -- the Manifest carries the Signing Input Digest of that artefact, rendered as a lowercase hexadecimal text string, and the artefact travels outside the Canonical Claim.¶

The Manifest is a field of the Canonical Claim and therefore inside the Claim Hash preimage, so a signature within it is a signature inside a digest preimage, re-encodable in transit by a party holding no key, for the reason Section 8.11 gives. A claim carrying one indexes the Settlement-Layer Ledger under a value that moves while the claim does not, and no party outside the deployment can detect it, because the Claim Hash is blinded and cannot be recomputed outside the deployment at all.¶

This is the seventh carrier and the only one the class rule of Section 8.11 could not have reached. That rule directs a party computing a digest to substitute a Signing Input Digest for any signature made by another party, and it is inoperable here for two reasons: the preimage is [RFC8785] JSON, which has no byte-string type for the substituted value, and Section 7.2 has the server hash the requester's octets, so a server-side substitution would produce a Claim Hash over bytes the requester never signed. Where a construction cannot be repaired by the general rule, the content has to be excluded rather than the rule extended, which is what the prohibition above does. An earlier revision instead said the container form "does not alter the Claim Hash", which is true of the container and false of what the container holds.¶

5.2. Requester Identity Binding and Agent Friend-or-Foe Gate

Before the Adversarial Pre-Transmission Test, the reconciliation server MUST establish the identity of the Requesting Principal and record it in a Requester-Binding field. The Requester-Binding comprises a requester-binding class, the identifier of the accountable principal where known, and a reference to the verification method used. The class is one of:¶

• human-operator, where an authenticated human or institutional operator is the accountable principal.¶

• agent-verified, where an agent's signing key verified AND the principal it asserts was corroborated by a reconciliation under Section 6 or by a Verified Principal Credential whose status was checked.¶

• agent-key-verified, where an agent's signing key verified but the principal it asserts was not corroborated.¶

• agent-unverified, where the request was signed under a bare key that resolves to no signature-agent card, carries no Verified Principal Credential, and asserts no principal. The key gives continuity of identity between requests and nothing else, which is why it is a class and not a refusal; a request that carries no verifying signature at all is not admitted, by Section 7.4.1.¶

agent-key-verified exists because possession of a key and binding to a principal are different facts and earlier revisions recorded them as one. An agent that signs correctly under a Web Bot Auth key has demonstrated that it is the same agent as last time; it has not demonstrated that any accountable party stands behind it. Recording that state as agent-verified overclaims to every downstream reader, and recording it as agent-unverified discards a real and useful fact. A relying party that requires an attributable principal should treat agent-key-verified as it treats agent-unverified; one that requires only continuity of identity may treat it as it treats agent-verified. This document states no requirement on a relying party's own risk policy; what it requires is that the two states be recorded distinctly so that the policy can be applied. The Agent-IFF policy states which reconciliations may be decisive at each class.¶

Where the requester is an autonomous agent, the server MUST perform an Agent Friend-or-Foe (IFF) Determination. An agent is classified FRIENDLY only where at least one verifiable identity is present and cryptographically valid: a request signed under HTTP Message Signatures [RFC9421] with a key resolvable through a Web Bot Auth signature-agent card [I-D.meunier-webbotauth-registry], advertised via the Signature-Agent header [I-D.meunier-webbotauth-httpsig-protocol] and resolved through the HTTP Message Signatures directory it names [I-D.meunier-webbotauth-httpsig-directory], a genuinely verified declared bot, or a Verified Principal Credential. An agent presenting no such identity, or an identity that fails verification, MUST be classified ENEMY.¶

The Agent-IFF policy in force declares, per predicate class, whether an ENEMY requester is refused outright, permitted only for non-decisive advisory reconciliation, or permitted with the requester-binding class recorded as agent-unverified, and whether an agent whose key verified but whose principal was not corroborated -- class agent-key-verified -- may reach a decisive verdict. The server MUST NOT silently upgrade an ENEMY requester to FRIENDLY. The Requester-Binding and the Agent-IFF policy identifier are committed to the Policy-Version Hash so that the settlement record is attributable to a determined requester class.¶

5.3. Adversarial Pre-Transmission Test

Before any Per-Register Claim Projection is produced, the Adversarial Pre-Transmission Test Subsystem applies the current Pattern Library to the Canonical Claim. The Pattern Library enumerates structural evasion patterns against the projection and aggregation mechanisms of this protocol, including projection-narrowing-evasion, predicate-substitution-evasion, attested-value-bracketing-evasion, addressed-register-cherry-picking, agreement-staleness-injection, pattern-library-version-pinning, and agent-principal-spoofing (an unverifiable agent asserting a principal binding it does not hold).¶

The Subsystem emits either a Pass result or a Remediation Advisory. A Remediation Advisory comprises:¶

• a Refusal Ground, one of pattern-matched, regime-not-admitted, audience-member-not-enrolled or agent-iff-refused¶

• the identifiers of the Pattern Library patterns that matched, and the narrowing or substitution each concerns, present exactly where the Ground is pattern-matched¶

• the regime, the Audience Member Identifier or the Agent-IFF ground the other three Grounds concern respectively, present under the corresponding Ground¶

It is encoded as a CBOR array in that field order under the media type registered in Section 10, absent fields as CBOR null, and is returned to the requester as Section 7.2 provides. No projection is transmitted and no Reconciliation Output is produced. The Advisory is the only artefact a refused requester receives, so it carries the ground rather than leaving the requester to infer it.¶

Where the Ground is pattern-matched, the second field MUST be encoded as CBOR null in the Advisory returned to the requester, the array's field order being unchanged, and the matched identifiers and the narrowing or substitution each concerns MUST be retained by the server and disclosed only to a regulator under Section 5.19 and to an Audit Identity under Section 5.20.¶

A requester that can vary a claim and read back which pattern matched enumerates, one refusal at a time, the corpus Section 5.7 declines to disclose even to a register. The query budget does not bound the probe, being keyed per principal per subject, so an evader varying subjects probes without limit. An Advisory that names the pattern is a more efficient route into the Pattern Library than the Library's confidentiality is a defence of it, and the party it was handed to is the one party the Test exists to defend against.¶

The Per-Register Encryption Subsystem MUST architecturally withhold external transmission until a Pass result has been emitted or until an authorised operator has explicitly overridden the outcome. An override MUST be recorded in the Reconciliation Output as an Override Record and is thereby covered by the Sealing Signature. An override that left no artefact would be indistinguishable from a Pass to every external party, which would make the only manual bypass of the protocol's own adversarial gate invisible to the regulators that gate exists to serve.¶

An Override Record comprises:¶

• the identifiers of the Pattern Library patterns that matched¶

• the Pattern-Library Version Identifier under which they matched¶

• the Override Ground, drawn from the registry of Section 10¶

• the identifier of the authorising operator¶

• an Override Timestamp ([RFC3339] UTC)¶

• a signature by the authorising operator, a COSE_Sign1 whose payload is the CBOR array of the fields above in the order listed with the signature position encoded as CBOR null, encoded under Section 4.2.1 of [RFC8949], and carrying as its key identifier the JWK thumbprint, computed as in [RFC7638], of a key published in the reconciliation server's Operator Key Set at /.well-known/arp-operator-keys on its Authority Origin. That key set is published and validated as the sealing key set of Section 7.5.3 is, save that the Authorised-Origin Document MUST name a key identifier for the operator key set distinct from the one anchoring the sealing key set. Sealing keys and operator keys are separate sets because they are held by different parties for different purposes: a server able to sign an override with its sealing key could manufacture an operator's authorisation, and a server holding the only key that anchors its own operator key set could do the same one level up¶

The signature is by the operator and not by the server. A record the server signs attests only that the server says an operator authorised the bypass; a record the operator signs is a statement the operator made and cannot later disown, which is what a manual override of an adversarial gate has to be for the regulator reading it. The Override Ground is drawn from a registry so that grounds are enumerable and comparable across deployments rather than free text that no reviewer can aggregate.¶

The reconciliation entry that records an overridden reconciliation carries an Override Indicator, so that a regulator reading the Ledger under Section 5.19 can see that a bypass occurred without holding the Output. Having seen it, the regulator reads the Output itself under Section 5.20 or through the entitlement its statutory scope gives it, and reads the Record. An Override Record visible only to the Audience Set the operator chose to serve would be invisible to the party the mechanism exists for, which is the failure this paragraph and the Indicator together close.¶

The Record names an operator in the clear, in an artefact whose Policy-Version Hash is blinded under Section 5.16 precisely to keep principal identities out of reach. That is not a contradiction: blinding protects the Ledger, which is published, and the Reconciliation Output is confidential to its Audience Set under Section 5.15. An override is a discretionary act by a named human against a named pattern, and the parties entitled to the Output are the parties entitled to know who performed it. Nothing about the override reaches the Ledger except through the Reconciliation Hash, which is a digest.¶

5.4. Per-Register Projection Function

For each addressed register, the controlled projection function MUST inspect the Canonical Claim against the permitted-predicate set declared in the Bilateral Register Agreement. Where the Canonical Claim's Predicate is directly a member of the permitted-predicate set, the Projected Predicate equals the Canonical Claim Predicate.¶

Where it is not, the projection function resolves the Predicate through taxonomic prefix match: walking the Predicate Taxonomy upward from the Canonical Claim Predicate until reaching a Predicate that is a member of the permitted-predicate set. Where the walk reaches more than one such Predicate at the same taxonomic distance, the projection MUST fail with projection-ambiguous rather than choose between them. Where the walk reaches the taxonomy root without finding one, the projection MUST fail with projection-unsupported. The narrowing operation MUST be recorded in the Narrowed-From field of the Per-Register Claim Projection.¶

The Predicate Taxonomy over which that walk is performed is the union of the branches the Register Data-Format Profiles of Section 5.5 define, each branch's parent relation being the one its profile declares and each branch's root being the predicate that profile names as such. Taxonomic distance is defined only between predicates within one branch. A predicate belonging to no declared branch has no parent, and a walk that would leave the branch it began in MUST fail with projection-unsupported. The agent: branch of Section 6 is governed by no profile and is therefore flat: its predicates have no parent and a walk beginning at one MUST fail on the same reason.¶

There is no registry of predicates and this document does not create one. The taxonomy is a deployment artefact assembled from declared profiles, which is what makes it checkable by the register: the permitted-predicate set is item 1 of Section 5.23.1 and is therefore inside the Agreement Hash, so the second party to a projection can test the walk against terms it negotiated. Earlier revisions named the taxonomy and left the reader to infer where its edges came from.¶

A Per-Register Claim Projection comprises:¶

• Reconciliation Identifier¶

• Register Identifier¶

• Projected Predicate¶

• Subject Reference, in the form the addressed register's Bilateral Register Agreement declares¶

• Attested Value, where the Projected Predicate takes one¶

• Narrowed-From, absent where the Projected Predicate equals the Canonical Claim Predicate¶

• Bilateral-Register-Agreement Hash¶

• Policy-Version Hash¶

• Freshness Window, as declared in the Bilateral Register Agreement¶

• Reconciliation Nonce¶

• Profile Parameter Set, being the values the Bilateral Register Agreement declared under Section 5.5 that the register is to apply¶

• OPTIONAL Requester-Binding Class, present exactly where the Bilateral Register Agreement requires it under Section 8.1, disclosing the class and not the principal¶

A Per-Register Claim Projection is encoded as a CBOR array in the field order above, an absent OPTIONAL or conditionally absent field encoded as CBOR null so that position is preserved. This is the only structure a sovereign register receives, and it is enumerated here so that its contents are determinate and its digest constructions reproducible.¶

The wire binding over which it is transmitted is not specified by this document. This document specifies what the channel must achieve -- the structure it carries, the confidentiality and authenticated-additional-data properties of Section 5.7, and the Query Binding the register signs over -- and leaves the transport, the endpoint, the framing and the concrete encryption construction to be declared in each Bilateral Register Agreement.¶

That is a deliberate scoping decision and it is a real limitation, stated here rather than left to be discovered: two reconciliation servers addressing the same register do so over channels the register defined, so ARP is interoperable in its artefacts and not yet in that leg's transport. Specifying it -- an endpoint, a media type, and a COSE_Encrypt construction pinning the AEAD and the ordering of its authenticated additional data -- is the principal item of work this revision leaves for the next. The register does not receive the Canonical Claim, the Addressed-Registers Identifier Set, or any other register's projection.¶

The register echoes the Policy-Version Hash in its Partial Attestation; it does not compute it, and it is not required to be able to. The reconciliation server MUST send the same Policy-Version Hash to every addressed register in one reconciliation, and MUST verify on reception that each Partial Attestation echoes it. A mismatch MUST be treated as a refusal by that register and recorded under Section 5.11. Without this the per-register signatures over the Policy-Version Hash -- the only independent corroboration of it -- would be discarded at aggregation, and a server could address different registers under different policy versions undetectably.¶

5.5. Register Data-Format Profiles

A Bilateral Register Agreement MUST declare the data format in which the addressed register expresses the facts the permitted-predicate set ranges over. The projection function of Section 5.4 operates on predicates, not on records; a format profile is what lets an implementer determine which predicates a given register can actually answer, and what a narrowing means against that register's own structure.¶

A profile is a property of a data format, not of a register. It states, for the format it covers, how a permitted predicate is expressed and what the Predicate Taxonomy's parent relation corresponds to in that format. Parameters that vary between registers using the same format -- interest thresholds, maximum chain depths, the set of named lists and the identifiers a register uses for their states -- are not properties of the profile and MUST be declared in the Bilateral Register Agreement. A profile MUST enumerate the parameters a Bilateral Register Agreement declaring it is required to supply, and MUST state which of its predicates are threshold-sensitive per Section 4, on which the third re-typing ground of Section 5.12 turns.¶

Without that split a single registered identifier would carry facts that differ between registers, and two registers using the same format under different thresholds could not both declare it. A profile MUST NOT introduce a means of transporting register records; profiles constrain predicate expression only.¶

The vocabulary documents a profile names are informative to this document and normative to an implementation of that profile: an implementation cannot evaluate a projection expressed in a vocabulary without it. A profile MUST pin the dated version of each vocabulary it names.¶

This document defines four profiles, with the identifiers registered in Section 10:¶

• arp-profile-bods (Section 5.5.1)¶

• arp-profile-corporate-org (Section 5.5.2)¶

• arp-profile-customs-wco (Section 5.5.3)¶

• arp-profile-sanctions-consolidated (Section 5.5.4)¶

Identifiers beginning x- are reserved for bilateral use and MUST NOT be registered. A Bilateral Register Agreement MAY declare one.¶

Each of the four profiles below states the dated vocabulary it uses where it names one, the parent relation for each branch of its predicate space over which narrowing is defined, the parameters a Bilateral Register Agreement declaring it must supply, and which of its predicates are threshold-sensitive within the meaning of Section 5.12.¶

5.6. Source-Data Version Binding

Where a register's answer depends on a source data state that changes independently of the Bilateral Register Agreement and of the Policy Version -- a consolidated sanctions list being the characteristic case -- the Partial Attestation MUST carry a Source-Data Version Identifier Set: one identifier for each source consulted in evaluating the Projected Predicate. Each identifier is a two-element CBOR array of the list name as declared in the Bilateral Register Agreement, as a text string, and the state identifier the LIST PUBLISHER assigns to that state, rather than any value of the register's own devising.¶

The state identifier is itself a two-element CBOR array of a form discriminator and a value. The discriminator is the text string token where the publisher assigns a version token, and the value is that token as a text string exactly as the publisher renders it, with no normalisation, trimming or case folding. The discriminator is the text string digest where the publisher assigns none, and the value is the SHA-256 digest, as a 32-octet CBOR byte string, of the octets the publisher serves for that state, taken as served and before any decompression, transcoding or reformatting the register applies.¶

The discriminator is present because the two branches are a text string and a byte string in one position, and a reader that must infer which it holds from the CBOR major type is a reader that will be wrong the first time a publisher issues a token that happens to decode. The "as served, before decompression" rule is present because a consolidated list published as a compressed archive has at least two byte sequences with an equal claim to being the corpus, and two registers that choose differently produce two identifiers for one state, which Section 5.21 would then read as a version change that never occurred.¶

The Source-Data Version Identifier Set MUST be encoded as a CBOR array sorted in bytewise lexicographic order of the deterministic CBOR encoding of each member. Every other set this document carries into a signature is ordered, and for the reason Section 5.15.1 gives: an unordered set gives one signed artefact as many digests as it has permutations. A register consulting three lists would otherwise have six conforming encodings of one attestation, each producing a different Merkle leaf under Section 5.10 and a different Reconciliation Hash. A register-chosen opaque string would be an arbitrary-bandwidth channel from register to relying party, carried under signature into a sealed and ledgered artefact, and the rule that differing identifiers MUST NOT be read as disagreement would normalise it. The reconciliation server MUST reject an identifier that is not drawn from the publisher's own state sequence, under Section 5.11 with the reason attestation-source-version-invalid. The tuple form is what keeps identifiers issued by one register over different lists from colliding, so that a register consulting several lists can denote the state of each.¶

The Source-Data Version Identifier Set MUST be carried in the arp-source-data-version COSE header parameter of the Partial Attestation's protected header, and is thereby covered by the Partial-Attestation signature. It MUST be carried into the Per-Register Result Set of Section 5.14 for each addressed register that supplied one, and is thereby covered by the Sealing Signature.¶

A register MUST evaluate every Projected Predicate over a given list against the state the corresponding member of its declared Source-Data Version Identifier Set denotes, and MUST use the same identifier for every Partial Attestation it issues over that list until it adopts a new state. Without this the identifier would vary per subject and become a disclosure channel.¶

Given that requirement this does not weaken minimum disclosure: a list-state identifier is a property of a published corpus rather than a register record, it discloses which published state was consulted and nothing about the subject entity, and it is identical across every Partial Attestation the register issues over that list regardless of verdict.¶

Retroactive Evaluation depends on this. On re-evaluation under an updated Pattern Library or Policy Version, an implementation MUST distinguish a material change in a historical Combined Verdict arising from the change in policy state from one arising from a change in Source-Data Version. Both MUST trigger Sovereign Re-Notification where material, and the notification MUST state which of the two occurred. Where an implementation cannot distinguish them, it MUST emit a Post-Seal Evaluation Record carrying attribution-indeterminate per Section 5.17 rather than attribute the change to policy.¶

An implementation MUST NOT infer that two Partial Attestations whose Source-Data Version Identifier Sets differ for a list they have in common disagree. They may be answers to the same predicate against different states of the same corpus. The reconciliation server MUST record this as source-version-skew, which is distinct from freshness-stale: a skewed attestation is within its freshness window and is retained and combined, whereas a stale one falls outside that window and is rejected under Section 8.6.¶

5.7. Per-Register Encryption

These are requirements on whatever bilateral channel Section 5.4 leaves each Bilateral Register Agreement to declare; they are properties the channel MUST provide and not a wire construction this document pins.¶

Each Per-Register Claim Projection MUST be encrypted under the addressed register's public key material declared in the Bilateral Register Agreement. The Reconciliation Nonce MUST be transmitted in the clear alongside the ciphertext, and the encryption operation MUST bind the Bilateral-Register-Agreement Hash and that nonce into the ciphertext as authenticated additional data, such that a register attempting to decrypt under a stale Bilateral-Register-Agreement Hash, or with a nonce other than the one the ciphertext was sealed against, fails at the authenticated-additional-data verification step. The register MUST verify that the nonce so bound equals the Reconciliation Nonce field of the decrypted projection.¶

The nonce travels in the clear because authenticated additional data is an input to the decryption operation and cannot be recovered from the plaintext that operation produces. It discloses nothing: it is a random value carrying no information about the subject or the claim.¶

These two are the only values so bound. Authenticated additional data detects a mismatch only against an expectation the receiver independently holds. A register independently holds its own agreement, and it is handed the nonce. It does not hold the Pattern-Library Version Identifier: the Pattern Library is the reconciliation server's internal adversarial-test corpus and is not published to registers, so binding it would either fail universally or be supplied alongside the ciphertext by the same party that chose it, detecting nothing.¶

A register MUST NOT issue more than one Partial Attestation for a given Reconciliation Nonce, and MUST reject a projection whose nonce it has already answered. Without this a captured ciphertext could be replayed indefinitely, each replay yielding a freshly timestamped signed attestation and defeating the freshness window of Section 8.6.¶

5.8. Partial Attestation Reception

A Partial Attestation comprises:¶

• Register Identifier¶

• Reconciliation-Verdict Field (match, no-match, partial-match, or indeterminate)¶

• OPTIONAL Divergence-Axis Field¶

• Bilateral-Register-Agreement Hash¶

• Policy-Version Hash¶

• OPTIONAL Source-Data Version Identifier Set, present where required by Section 5.6 and carried in the arp-source-data-version COSE header parameter of Section 10¶

• OPTIONAL Applied-Parameter Set, being the profile parameters the register actually applied in evaluating the Projected Predicate, present wherever the Profile Parameter Set of the Per-Register Claim Projection was non-empty¶

• Query Binding, the SHA-256 digest over the deterministically encoded CBOR array ["arp-query-binding-v1", Reconciliation Identifier, Projected Predicate, Subject Reference, Reconciliation Nonce], those four values taken from the Per-Register Claim Projection it answers. The construction is a five-element array whose first element is a fixed domain-separation string, rather than a byte concatenation, so that two implementations cannot differ on framing and the digest cannot collide with any other construction in this document. Within that array the Reconciliation Identifier is a byte string of 80 octets as Section 5.14 fixes it, the Projected Predicate is a text string, the Reconciliation Nonce is a byte string of at least 16 octets, and the Subject Reference takes the CBOR type the Subject Reference form of item 8 of Section 5.23.1 declares, which that Agreement MUST state. The register and the reconciliation server compute this digest independently and MUST obtain the same value, so an element whose type is left open is an element on which they can differ while agreeing on every negotiated term¶

• Freshness Timestamp¶

• Cryptographic Signature, a COSE_Sign1 by the register whose payload is the CBOR array of the fields above in the order listed, with an absent OPTIONAL or conditionally absent field encoded as CBOR null so that position is preserved, encoded under Section 4.2.1 of [RFC8949]. The register's signing key is published in its key set under Section 7.5.3, so that a relying party or auditor holding the attestation can resolve the key and verify the signature without the reconciliation server's assurance¶

The Query Binding is what makes an attestation an answer to a question rather than a free-standing assertion. Without it the signed payload says only that a register returned a verdict under some agreement and policy version at some time, and says nothing about what it was asked. Two consequences follow, and both are severe: an attestation harvested for one subject could be placed into the Per-Register Result Set of a reconciliation about another subject and would verify against every other check; and a register could answer the same question differently to two requesters and deny having done so, because its signature would not identify the question.¶

The arp-policy-version-hash, arp-bilateral-agreement-hash and arp-source-data-version in a Partial Attestation's protected header MUST equal the corresponding payload fields, and an implementation MUST reject an attestation where they differ: a value carried twice with no equality rule is a value an implementation may read either way. The third is included because Section 5.6 carries the Source-Data Version Identifier Set in the protected header and again into the Per-Register Result Set, which is the condition this rule exists to govern, and an earlier revision applied the rule to the first two only.¶

The reconciliation server MUST recompute the Query Binding from the projection it transmitted and MUST reject an attestation whose Query Binding does not match, under Section 5.11 with the reason attestation-binding-mismatch.¶

The Query Binding Record of Section 5.14 carries the three projection values and the register's signed attestation into the Output, so that a relying party or auditor can recompute the binding and verify the register's signature independently. A check performed only by the reconciliation server would rest on the honesty of the party the rest of this document declines to trust. The Reconciliation Nonce is unique per Per-Register Claim Projection per Section 4 and MUST NOT be reused, so that an attestation is admissible only into the reconciliation, and against the register, that elicited it.¶

The Partial Attestation payload SHALL NOT contain any register-record field, any pre-image of the register record, or any field beyond those enumerated. Restricting the Partial-Attestation payload to the enumerated fields, of which the verdict, the divergence axis, the applied parameters and the Query Binding -- a digest over the Subject Reference -- vary with the subject, is the mechanism by which ARP limits raw-record disclosure. Residual inference channels are discussed in Section 8.10.¶

5.9. Merkle Construction

Two structures in this document commit to a set of digests through a Merkle tree: the Merkle Root of Hash-Linkage Aggregation, and the Examined-Set Root of Section 5.21.1. Both use this construction, so that an inclusion proof produced by one implementation verifies under another.¶

Leaves are the digests to be committed, sorted in bytewise lexicographic order and deduplicated. Deduplication is why an Examined-Set Root commits to distinct Claim Hashes and the count beside it counts Reconciliation Outputs: two Outputs over one claim share a Claim Hash, so the leaf count and the examined count need not be equal and neither is derivable from the other. A leaf node is SHA-256(0x00 || leaf). An internal node is SHA-256(0x01 || left || right). Where a level has an odd number of nodes, the last is carried up to the next level unchanged rather than duplicated. A tree over one leaf has that leaf's leaf-node hash as its root; a tree over no leaves has thirty-two zero octets as its root.¶

For every non-empty tree this is the Merkle Tree Hash of Section 2.1.1 of [RFC9162] instantiated with SHA-256. The recursion of that section is the recursion of Section 2.1 of [RFC6962]; the two differ only in that [RFC9162] carries the hash algorithm as a log parameter where [RFC6962] fixes SHA-256, and this document fixes SHA-256. Both are named here: [RFC9162] because it is the current specification, and [RFC6962] because it is what most deployed Certificate Transparency logs implement and so is what an implementer is most likely to arrive from.¶

The odd-node rule stated above and that recursive split at the largest power of two below the leaf count are two descriptions of one tree: at every leaf count they produce the same root, and at every leaf count and index they produce the same sibling array. An implementation may compute either way and interoperate with one that computes the other. This is stated because the two rules do not look alike, so a reader who knows Certificate Transparency has no way to establish from the prose alone that they agree; and because a third convention is in common use, in which the last node at an odd level is duplicated and paired with itself. That convention produces the same root at every leaf count that is a power of two, because no level of such a tree is ever odd, and a different root at every other leaf count. A conformance vector taken at four or eight leaves will therefore not detect it, and an implementation that ports it will pass a test suite and diverge in production.¶

This document and Certificate Transparency diverge at exactly one input to the tree function, the empty tree, and the divergence is deliberate. Certificate Transparency defines the Merkle Tree Hash of the empty list as the hash of the empty string, which under SHA-256 is e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855; this document defines it as thirty-two zero octets. The Certificate Transparency value is a well formed digest that a verifier reproduces successfully and may then treat as a root that commits to something. Thirty-two zero octets is a value no commitment in this document produces, so it cannot be mistaken for one. An implementation MUST use the value defined in this section and MUST NOT substitute the Certificate Transparency empty-tree value. The requirement below, that a verifier reject any inclusion proof presented against the empty root, applies to whichever value a construction gives the empty tree, and the reason for it does not depend on which value that is.¶

Two further differences are matters of input and of encoding rather than of the tree, and each is a place an implementation ported from a Certificate Transparency log will be wrong if it is carried over unchanged. This document sorts leaves in bytewise lexicographic order and deduplicates them before the tree is built, where a Certificate Transparency log commits to entries in the order it received them; an implementation MUST apply the ordering and deduplication stated above and MUST NOT assume submission order. And this document's inclusion proof carries the leaf alongside the index, the leaf count and the sibling array, where the inclusion proof of Section 2.1.3 of [RFC9162] carries the index and the tree size but not the leaf, which its verifier is assumed already to hold. The leaf is the only field that differs, and Section 5.9.1 states what a verifier must do with it.¶

An inclusion proof is a CBOR array of the leaf, its zero-based index, the leaf count, and the array of sibling hashes from the leaf's level upward. Domain separation between leaf and internal nodes is what stops a proof of an internal node being presented as a proof of a leaf.¶

Three properties of that array are stated here because each is a place two implementations otherwise diverge while both believing they conform. The array carries one entry for each level at which the node being proved has a sibling, and no entry for a level at which it was carried up unchanged, so its length is not in general the base-two logarithm of the leaf count and a verifier MUST NOT derive the expected length that way. No direction bit is carried: at each level the verifier derives whether the sibling is the left or the right operand from the index and the leaf count, taking the floor of half the index and the ceiling of half the level width as it ascends. Halving the width by truncation instead gives the wrong width at every leaf count that is not a power of two -- five leaves give widths 5, 3, 2, 1 and not 5, 2, 1 -- which is precisely the range of leaf counts this section exists to pin down. The derivation is well defined because the shape of the tree is fixed by the leaf count alone. And the empty tree's root of thirty-two zero octets admits no inclusion proof; a verifier MUST reject any proof presented against it rather than treat a root it can reproduce as a root that commits to something.¶

5.10. Aggregation

The aggregation subsystem operates in Hash-Linkage Aggregation. Each Partial Attestation is committed to a Merkle tree as Section 5.9 defines it, under the leaf value that is its Signing Input Digest, and the resulting Merkle Root is carried in the Reconciliation Output. The leaf is the Signing Input Digest and not a digest of the attestation as received, so that the leaf a verifier computes under Section 5.9.1 does not depend on which of several byte-strings carrying one register signature it happens to hold. Its per-register inclusion proofs MAY be encoded as COSE Receipts [RFC9942], enabling any SCITT-aware verifier to check inclusion without a bespoke proof format. Each leaf commits one register's attestation individually, so an inclusion proof discloses no other register's payload.¶

5.11. Registers That Do Not Answer

A register may fail to produce a usable Partial Attestation. Every such state has a defined outcome, because dropping the register silently would produce exactly the addressed-register-cherry-picking pattern the Adversarial Pre-Transmission Test exists to detect.¶

The Per-Register Result Set MUST carry an entry for every addressed register. Where no usable attestation was received, the entry carries no Attested Verdict and carries instead, in its own field, a Non-Answer Reason drawn from:¶

• projection-ambiguous and projection-unsupported, where the projection itself failed and no projection was transmitted¶

• agreement-drift-suspended, where reconciliation against that register was suspended for Bilateral-Register-Agreement drift¶

• attestation-stale, where the Freshness Timestamp fell outside the declared window and the attestation was rejected¶

• attestation-signature-invalid, where the signature did not verify¶

• attestation-echo-mismatch, where a value the register echoed did not match the one sent, or a value carried in the protected header did not equal the corresponding payload field¶

• attestation-binding-mismatch, where the Query Binding the server recomputed did not match the one the attestation carries, which is an attestation elicited for a different question¶

• attestation-source-version-invalid, where a Source-Data Version Identifier was not drawn from the publisher's own state sequence¶

• attestation-scope-exceeded, where the register attested a Divergence Axis the registry of Section 10 records as server-recorded¶

• register-unresponsive, where no attestation was received within the window declared in the Bilateral Register Agreement¶

• register-refused, where the register declined to answer, whether under its own statutory access regime or under the Agent-IFF policy¶

• query-budget-exhausted, where the reconciliation would exceed the per-principal per-subject query budget declared under Section 8.1¶

• subject-ceiling-exhausted, where the reconciliation would exceed a per-subject ceiling declared under Section 8.1¶

• audience-constraint-exceeded, where the requested Audience Set exceeds the audience constraint that register declares under Section 5.15.1¶

• non-answer-unattested, where the register asserted a register-attested reason without a verifying Non-Answer Statement¶

Each Non-Answer Reason is either register-attested or server-observed, and the registry of Section 10 MUST record which for every registration. register-refused is register-attested. attestation-stale and the five attestation- reasons above are server-observed but arise from an attestation the server holds. The remainder are server-observed with no register artefact behind them.¶

Earlier revisions carried a single attestation-unverifiable covering all five of those conditions, and normative text in four other sections directed implementations to it for causes its own definition did not name. They are not variants of one condition and an auditor cannot be asked to treat them as one. A failed signature is a broken or impersonated register. An echo mismatch is an attestation about a different policy state. A binding mismatch is the reconciliation server presenting an attestation elicited for a different subject or predicate, which is a server-side attack and not a register fault at all. A source-version invalidity is a register attempting a covert channel. A scope excess is a register claiming competence the registry says it does not have. Recording all five as one value tells the Register Operator reading its own entry under Section 7.4.2 that something was wrong with its attestation, and does not tell it whether the fault was its own. This document made exactly this argument for non-answer-unattested two paragraphs below and did not apply it here. An implementation MUST NOT record any of the five under a value that does not name its cause.¶

Where a Non-Answer Reason is register-attested, the Per-Register Result Set entry MUST carry a Non-Answer Statement in the field Section 5.14 defines for it. The Statement is a COSE_Sign1 by that register, under the primitive its Bilateral Register Agreement declares and under a key resolvable as in Section 7.5.3, whose payload is the CBOR array¶

["arp-non-answer-v1", Reconciliation Identifier, Projected Predicate,
 Subject Reference, Reconciliation Nonce, Non-Answer Reason]

encoded under Section 4.2.1 of [RFC8949]. The Reconciliation Identifier is inside the payload for the reason the Query Binding of Section 5.8 carries it: without it a refusal elicited in one reconciliation is admissible as a refusal in another over the same subject and predicate.¶

Where a register-attested reason is recorded without a Statement, or with one that does not verify, the reason MUST be replaced by non-answer-unattested. That is a distinct reason and not any of the attestation- reasons, which denote a Partial Attestation the server holds and could not verify; collapsing the two would put the missing-refusal case back into a server-observed bucket and undo the distinction this rule exists to draw.¶

Without that rule a register-refused is an unattested assertion by the party that transmitted the projection, and a server can suppress a match by claiming the register declined. The server can still downgrade a reconciliation to indeterminate by asserting a server-observed reason -- register-unresponsive is indistinguishable from a network failure by construction, and this document does not pretend otherwise -- but it cannot dress suppression as an act of the register. Suppressing a sanctions hit is the harm this domain cares about, and the difference between "the register would not say" and "I did not ask" is the difference the record must preserve.¶

A Non-Answer Reason is not a verdict, occupies its own field of the Per-Register Result Set per Section 5.14, and MUST NOT be combined by the Verdict Arithmetic. Its effect is given in Section 5.13: a reconciliation with any non-answering register cannot reach a decisive Combined Verdict.¶

Where the reason is attestation-stale, freshness-stale MUST also be added to the Server-Recorded Divergence-Axis Set against that Register Identifier.¶

A reconciliation server MUST reject a Partial Attestation that attests a Divergence Axis the registry of Section 10 records as server-recorded, with the reason attestation-scope-exceeded. A register cannot attest a relation between itself and another register, which is what those axes are.¶

5.12. Verdict Re-Typing

A register answers the Projected Predicate it was sent, which may be a narrowing of the Canonical Claim Predicate. Where the narrowing means the register's answer does not bear on the claim as asked, the reconciliation server MUST re-type that register's Reconciliation-Verdict Field before aggregation, and MUST record the attested value, the re-typed value and the ground on which it re-typed in the Per-Register Result Set, so that an auditor can reproduce the decision without the server's assurance.¶

Re-typing is confined to these cases:¶

• Any contribution other than match, attested against a bounded-depth predicate where the Canonical Claim ranged over a transitive closure, is re-typed to indeterminate. A bounded-depth answer that is not a match is evidence about the bounded depth only, and that is as true of partial-match and indeterminate as of no-match. A match is not re-typed: an interest found at any depth establishes the existential closure predicate.¶

• A match or no-match attested over a declared fact, where the Canonical Claim ranged over a determined fact, is re-typed to partial-match under an operator that admits that value and to indeterminate under one that does not, per Section 5.13.¶

• A contribution from a register whose declared interest threshold differs from that of any other addressed register, where the Canonical Claim's predicate is threshold-sensitive, is re-typed to partial-match under an operator that admits that value and to indeterminate under one that does not. Two registers answering under different thresholds are not answering the same question, and annotating that on the Reconciliation Output while allowing a decisive Combined Verdict to be built from it would state a conclusion the inputs do not support.¶

  Threshold-sensitivity is a property of a Register Data-Format Profile, which declares which of its predicates are threshold-sensitive, and the test above names the Canonical Claim Predicate, which is not expressed in any profile. The test is therefore evaluated as follows, and is defined over a register set whose members declare different profiles. The Canonical Claim Predicate is threshold-sensitive where the Per-Register Claim Projection transmitted to ANY addressed register was a predicate that register's declared profile marks threshold-sensitive. Taking the disjunction rather than requiring agreement is deliberate: a mixed-profile register set in which one profile marks the predicate threshold-sensitive and another is silent is precisely the set in which the thresholds may differ unnoticed, and requiring every profile to mark it would disable the test in the case it exists for.¶

• A match attested against a Projected Predicate that is a proper ancestor of the Canonical Claim Predicate is re-typed to partial-match under an operator that admits that value and to indeterminate under one that does not, under the ground projection-broadened. The projection function of Section 5.4 resolves by taxonomic prefix match upward, producing the nearest permitted ancestor, so a register answering a Projected Predicate that narrowing did not reach is answering a broader question than the claim asked. A subject designated on some US sanctions list is not thereby designated on the OFAC SDN list, and a decisive match assembled from the ancestor states a conclusion the input does not support.¶

  A contribution other than match is not re-typed on this ground: a no-match over an ancestor entails no-match over every descendant of it, so the broadening is harmless in that direction and re-typing it would discard sound evidence.¶

  Earlier revisions covered the converse only. The opening sentence of this section says a register answers a Projected Predicate "which may be a narrowing of the Canonical Claim Predicate", and the projection function produces an ancestor, which is the opposite relation. The Output records the broadening in the Narrowed-From field of the Projection Record, so a relying party inspecting it could see what happened; nothing obliged it to look, and the Combined Verdict was decisive either way. Recording a divergence while permitting a decisive verdict built on it is the failure ground 3 above is written against, and it applied here and was not applied.¶

  The Divergence Axis claim-projection-narrowed-beyond-attestation-scope names this condition and is register-attestable, optional in the attestation, and connected to no normative rule anywhere in this document; it appears in its own enumeration and nowhere else. An axis a register need never emit, and which changes no verdict when emitted, is not a control. This ground is.¶

Re-typing operates on a register's contribution. It does not override the Verdict Arithmetic resolved under Section 5.13, which is applied afterwards to the re-typed set and is otherwise unaffected. An implementation MUST NOT re-type on any ground not enumerated here.¶

5.13. Verdict Arithmetic

The Verdict Arithmetic combines the Reconciliation-Verdict Fields of the Per-Register Result Set, after any re-typing under Section 5.12, into the Combined Verdict. The requester names the applicable regimes in its Canonical Claim; it does not choose the operator. The operator and every parameter it takes are resolved by the reconciliation server from the policy-epoch store of Section 5.16, keyed on the predicate and the named regimes, and are committed to the Policy-Version Hash. They are carried into the Reconciliation Output so that a relying party can reproduce the combination.¶

A requester able to choose both the operator and its threshold could choose the verdict: disjunction over five registers and threshold-count with a threshold of five differ only in which answer they return over the same contributions, and selecting between them after seeing which registers were addressed is verdict shopping that no downstream check would detect. Naming a regime is a claim about which law applies, which the requester is competent to make and accountable for; selecting an operator is a determination about how evidence combines, which the deployment's policy makes.¶

Naming regimes is not thereby unconstrained. The reconciliation server MUST verify that every regime the Applicable-Regimes Set names is one the policy-epoch store admits for that predicate, and MUST refuse a claim naming a regime that is not, returning a Remediation Advisory identifying it. Without that check a requester enumerates admissible regime sets, reads out of the Outputs it receives which operator, threshold and reliance interval each resolves to, and selects the combination that returns the answer it wants -- taking the longest reliance interval with it. That is verdict shopping at one remove. There is nothing to probe for: Section 7.4.1 requires the server to publish the resolved operator, its parameters and the reliance interval per predicate and regime set, so the mapping is available without probing and the admitted-regime check is what constrains the choice.¶

Three rules apply to every operator and take precedence over the operator's own table:¶

• The Addressed-Registers Identifier Set MUST NOT be empty, and a Combined Verdict MUST NOT be computed over an empty contribution set. Every operator below is defined by a condition universally quantified over the contributions, so every one of them is vacuously satisfied where there are none: conjunction yields match, disjunction and threshold-count yield no-match, and the two rules that follow -- both of which begin "where any" -- do not fire, because there is no contribution to be indecisive. A decisive verdict from no evidence at all is the failure mode the rest of this section is built to prevent, and it is reached not by an operator behaving badly but by every guard being true of nothing. A relying party MUST reject an Output whose Addressed-Registers Identifier Set is empty, and MUST NOT treat its Combined Verdict as a verdict.¶

• Where any addressed register has no decisive contribution because it did not answer, was refused or was rejected under Section 5.11, the Combined Verdict MUST be indeterminate. An operator MUST NOT reach a decisive verdict over an incomplete register set, which would be indistinguishable from addressed-register-cherry-picking.¶

• Where any contribution is indeterminate, the Combined Verdict MUST be indeterminate wherever the operator's table would otherwise yield no-match. An indeterminate contribution is an absence of evidence and a decisive negative may not be built on one, so the rule states the substitute result rather than only a prohibition; a prohibition without a substitute would leave the verdict undefined in exactly the cases it governs.¶

Operators are drawn from the registry of Section 10. Subject to those rules, the initial four are:¶

conjunction:

match where every contribution is match. no-match where any contribution is no-match. partial-match where every contribution is match or partial-match and at least one is partial-match. indeterminate otherwise.¶

disjunction:

match where any contribution is match. no-match where every contribution is no-match. partial-match where at least one is partial-match and none is match. indeterminate otherwise.¶

threshold-count:

match where the count of match contributions meets or exceeds the threshold resolved for the named regimes. no-match where the count of match contributions cannot reach the threshold and no contribution is indeterminate. indeterminate otherwise, which includes every case in which an indeterminate contribution is present and the threshold is not met. partial-match contributions do not count toward the threshold.¶

source-class-quorum:

threshold-count evaluated per source class, over the partition and the per-class threshold resolved for the named regimes, then combined across classes by conjunction. A source class containing no addressed register contributes indeterminate and MUST NOT contribute no-match. Without that rule the class is threshold-count over nothing: the count of match contributions cannot reach a threshold of one or more, no contribution is indeterminate because there is no contribution, and the class yields a decisive negative built on an empty class -- which conjunction then propagates to the Combined Verdict. The indeterminate-substitution rule above does not reach it, because that rule governs evidence that is present and inconclusive and this is evidence that is absent. Suppressing a hit by partitioning it into a class with no members in it is a decisive negative assembled out of the partition, and the partition is resolved from the policy-epoch store rather than from the registers actually addressed.¶

Every operator admits partial-match except threshold-count and source-class-quorum, which do not. Where Section 5.12 would re-type a contribution to partial-match under an operator that does not admit it, the contribution is re-typed to indeterminate instead.¶

5.14. Reconciliation Output

A Reconciliation Output comprises:¶

• Reconciliation Event Identifier¶

• Reconciliation Identifier¶

• Claim Hash¶

• Reconciliation Timestamp¶

• Reliance Horizon of Section 5.15¶

• Audience Set of Section 5.15¶

• Combined Verdict¶

• Verdict Arithmetic as resolved under Section 5.13, together with every parameter that operator takes -- the threshold for threshold-count, and both the source-class partition and the per-class threshold for source-class-quorum¶

• Addressed-Registers Identifier Set, each member an Authority Origin, sorted in bytewise lexicographic order of its UTF-8 encoding¶

• Bilateral-Register-Agreement Hash Set, sorted in bytewise lexicographic order of the digests themselves, in the order of the Addressed-Registers Identifier Set having no meaning once a register may be absent from a set¶

• Policy-Version Hash¶

• Pattern-Library Version Identifier¶

• Requester-Binding Class¶

• Per-Register Result Set, one entry per addressed register, ordered by Register Identifier in bytewise lexicographic order of its UTF-8 encoding¶

• Aggregation-Method Descriptor, drawn from the registry of Section 10¶

• Merkle Root, constructed as in Section 5.9¶

• Server-Recorded Divergence-Axis Set, possibly empty¶

• OPTIONAL Override Record, present exactly where an Adversarial Pre-Transmission Test failure was overridden¶

• Sealing-Key Identifier¶

• Sealing Signature, a COSE_Sign1 by the reconciliation-server sealing key whose payload is the CBOR array of this Output with the Sealing Signature position alone encoded as CBOR null, so that it covers every other field including the Sealing-Key Identifier¶

The Reconciliation Event Identifier is a 16-octet value drawn from a cryptographically secure random source at the start of a reconciliation, unique to that reconciliation across the life of the deployment.¶

The Reconciliation Identifier is the Claim Hash concatenated with the Policy-Version Hash concatenated with the Reconciliation Event Identifier.¶

Earlier revisions omitted the third component, and the first two are both reproducible functions of enumerated inputs. Two reconciliations over one claim under one policy state therefore shared an identifier, and the protocol keys three mechanisms on it that each assume it names one event:¶

• A register's own read under Section 7.4.2 is keyed on the Reconciliation Identifier, and exists so that a server cannot discard a register's signed match and record register-unresponsive while the only party holding the contradicting artefact has no operation with which to produce it. Where two reconciliations shared the identifier, a server could record the register's match in the first and suppress it in the second, and serve the first to the register's audit read. The register sees its answer faithfully recorded and the suppression is invisible.¶

• The Query Binding of Section 5.8 carries the Reconciliation Identifier so that an attestation is admissible only into the reconciliation that elicited it. Every element of that preimage was identical across the two, so an attestation elicited in the first verified unchanged inside the second.¶

• The Non-Answer Statement carries it so that a refusal elicited in one reconciliation is not admissible as a refusal in another over the same subject and predicate -- which, under unchanged policy, is precisely when the identifier repeated.¶

The three protections were each written against the same assumption and the assumption was not established anywhere. A retroactive supersession under a Source-Data Version trigger leaves the policy state unchanged by definition, so the identifier repeated on the path the document itself constructs, not only on one a requester might contrive. The Event Identifier is what the three mechanisms were already relying on.¶

It is carried in the Output as its own field, so it is inside the Reconciliation Hash preimage: two reconciliations that address no register and are sealed in the same second would otherwise produce one Reconciliation Hash, which is the ledger index and the retrieval key, and no field distinguishing them.¶

The Event Identifier is not a secret and carries no requester-supplied content. It is random rather than a counter so that it discloses nothing about reconciliation volume to a register or to a relying party, and 16 octets rather than 32 because it needs only uniqueness within a deployment.¶

The Claim Hash binds the Output to the question it answers. Without it a relying party receives a Combined Verdict with nothing to attribute it to, and the Retroactive Evaluation Subsystem has no key to select on.¶

The Verdict Arithmetic and its parameters are carried because a relying party cannot otherwise reproduce the combination from the Per-Register Result Set, and because Section 5.12 turns on which values the operator admits. The Applicable-Regimes Set is a Canonical Claim field and is not itself carried in the Output, so naming the operator without its parameters would leave threshold-count and source-class-quorum irreproducible. source-class-quorum is threshold-count evaluated per class and therefore takes a threshold as well as a partition; carrying the partition alone would leave it as irreproducible as carrying neither, which an earlier revision did.¶

Each entry of the Per-Register Result Set comprises:¶

• Register Identifier¶

• Answer State, either answered or not-answered¶

• Attested Verdict, present exactly where the Answer State is answered¶

• Non-Answer Reason of Section 5.11, present exactly where the Answer State is not-answered¶

• Effective Verdict, present exactly where the Answer State is answered, being the Attested Verdict or its re-typing under Section 5.12¶

• Re-Typing Ground, drawn from the registry of Section 10, present exactly where the Attested and Effective Verdicts differ¶

• Policy-Version Hash as echoed by that register, present exactly where the Answer State is answered¶

• OPTIONAL Divergence-Axis Field, as attested by that register¶

• OPTIONAL Source-Data Version Identifier Set, as attested by that register¶

• Projection Record, comprising the Narrowed-From field of the Per-Register Claim Projection where a projection was transmitted, the Applied-Parameter Set the register reported where the Answer State is answered, and the Subject Mapping Record of Section 5.4.1; required wherever a projection was transmitted and either the projection narrowed or the Profile Parameter Set was non-empty¶

• Query Binding Record, present exactly where the Answer State is answered, comprising the Projected Predicate, the Subject Reference and the Reconciliation Nonce the server transmitted, and the register's signed Partial Attestation¶

• Non-Answer Statement, present exactly where the Answer State is not-answered and the Non-Answer Reason is register-attested under Section 5.11, comprising the Projected Predicate, the Subject Reference and the Reconciliation Nonce the server transmitted, and the register's signature over them together with the reason and the Reconciliation Identifier, as Section 5.11 constructs it. The three projection values are carried here as well as in the Query Binding Record because the two are never both present and a verifier of either needs the preimage in the artefact it holds.¶

Each member of the Server-Recorded Divergence-Axis Set is a two-element array of a Divergence Axis and the Register Identifier it concerns, the second element being CBOR null where the axis concerns the reconciliation as a whole. Members are sorted in bytewise lexicographic order of that encoding. A uniform two-element member with an explicit null, rather than a member that is sometimes a pair and sometimes a scalar, is what makes the Set's contribution to the Reconciliation Hash determinate. Of the axes recorded by the server, freshness-stale and declared-not-determined are per-register and MUST carry a Register Identifier. source-version-skew is a relation between two or more registers, and one member MUST be added for each register involved, so that the set is a determinate function of the inputs rather than a choice between them; register-threshold-divergence concerns the reconciliation and MUST NOT. agent-action-scope-divergence is likewise a relation, between two capsules rather than between two registers, and one member MUST be added for each Register Identifier whose contribution the divergence concerns, or a single member carrying null where it concerns no register's contribution; the rule is stated for all five axes and not four because the Set is inside the Reconciliation Hash preimage, so an axis whose member form is left open gives one reconciliation two ledger indices. Recording a bare axis over five addressed registers would state that something was stale without stating what, which is not reproducible.¶

The Set is a set rather than a single value: a reconciliation may be qualified on more than one axis, and an encoding admitting only one would force an implementation to choose between them silently.¶

A Reconciliation Output is encoded as a CBOR array in the field order of this section, an absent OPTIONAL or conditionally absent field encoded as CBOR null so that position is preserved and the array's length is fixed. The Per-Register Result Set is an array of arrays, each in the field order enumerated above, under the same rule. The order is normative because the Reconciliation Hash is taken over it, and because a CBOR map would be re-sorted into bytewise lexicographic key order under Section 4.2.1 of [RFC8949], which would override it.¶

The Reconciliation Hash is the SHA-256 digest over that same CBOR array with the Sealing-Key Identifier and Sealing Signature positions encoded as CBOR null. The array's length is unchanged: "excluding" means null-substitution at fixed positions and MUST NOT be implemented as truncation, because a shorter array carries a different CBOR array header and therefore a different digest, and two implementations reading "excluding" the two ways would never agree on a ledger index. It is the value recorded in the Settlement-Layer Ledger, the value a Post-Seal Evaluation Record references, and the retrieval key of Section 7.4.¶

Determinism under Section 4.2.1 of [RFC8949] fixes how a given value is encoded. It does not fix which CBOR type a field takes, nor the order of elements within a field that is a set. The Reconciliation Hash is the ledger index of Section 5.18, the retrieval key of Section 7.4, and a value Section 7.2 has the requester compute over an Output it has just been handed, so two parties compute it independently and MUST obtain the same value. The types are therefore fixed here, as Section 5.23.3 fixes them for the Agreement Hash and Section 10 fixes them for a Ledger entry.¶

The Bilateral-Register-Agreement Hash Set is deduplicated because two addressed registers may be governed by one Agreement, and an implementation that carried the digest twice and one that carried it once would compute two Policy-Version Hashes and two Reconciliation Hashes from identical inputs.¶

Every timestamp this document places inside a digest preimage or a signature payload MUST be expressed in the form YYYY-MM-DDTHH:MM:SSZ: [RFC3339] with the Z designator rather than a numeric offset, and with no fractional seconds. [RFC3339] admits several renderings of one instant, and a preimage that admits several renderings admits several digests.¶

CBOR rather than [RFC8785]: the mandatory-to-implement encoding for a Reconciliation Output is CBOR, and several of its fields are byte strings, for which JSON has no type. Digesting a JSON rendering of it would require a CBOR-to-JSON mapping this document does not define, and two implementations would produce different ledger indices. The Canonical Claim is serialised under [RFC8785] and that serialisation is carried as one element of the CBOR array the Claim Hash is taken over; the Reconciliation Output is CBOR throughout.¶

A Reconciliation Output is immutable once sealed. Conditions arising after sealing are recorded under Section 5.17 and MUST NOT be represented as fields of the Reconciliation Output.¶

5.15. Output Entitlement and Delivery

The Reconciliation Output is the confidential artefact of this protocol and the Settlement-Layer Ledger is its public one. An Output carries subject references, register-signed Partial Attestations and principal identifiers; a Ledger entry carries digests, register origins and structural metadata, and no claim, register-record or principal content. Every rule in this document about who may see what rests on that division, and they are not interchangeable. A party admitted to a Ledger read learns nothing of the subject or the answer. A party holding an Output already holds the content of one reconciliation, and admitting it to reads about that same reconciliation discloses nothing it does not have.¶

Earlier revisions had no answer to who may hold an Output. It was a bearer artefact: possession was the whole of the entitlement, it never expired, and every read predicate this document attempted was expressed in terms of a Requester-Binding that the reader could not present and the Ledger could not evaluate. This section supplies the missing term.¶

5.16. Policy-Version-Hash Sealing

The Policy-Version Hash MUST commit to:¶

1. Reconciliation rules¶

2. Threshold parameters¶

3. Pattern-Library Version Identifier¶

4. Applicable-Regimes precedence¶

5. Verdict-Arithmetic selection, together with every parameter that operator takes¶

6. The reliance interval from which the Reliance Horizon of Section 5.15.2 is computed¶

7. Agent-IFF policy identifier and the Requester-Binding¶

8. Bilateral-Register-Agreement Hashes of the addressed registers¶

The Policy-Version Hash is the SHA-256 digest over the deterministically encoded CBOR array¶

["arp-policy-version-v1", Deployment Blinding Value,
 reconciliation rules identifier, threshold parameters,
 Pattern-Library Version Identifier, applicable-regimes precedence,
 [Verdict Arithmetic, its parameters], reliance interval,
 Agent-IFF policy identifier, Requester-Binding,
 Bilateral-Register-Agreement Hash Set]

in that order, the Hash Set sorted in bytewise lexicographic order of the digests and every other composite element a CBOR array in the order this section states it. It MUST be reconstructible under audit from that array, held in the policy-epoch store. A value every addressed register echoes and every auditor recomputes cannot be left to "a canonical policy state", which earlier revisions were content with and which is not a preimage.¶

The Claim Hash and the Policy-Version Hash MUST each be computed over a preimage that includes the Deployment Blinding Value: a secret of at least 128 bits drawn once from a cryptographically secure random source, persisted in the policy-epoch store, constant for the life of the deployment, and disclosed outside the policy-epoch store only as Section 5.20 provides. Section 5.20 discharges an auditor's need as far as it can without disclosing the constant that blinds every digest in the deployment, and states what that leaves unverified.¶

It is constant rather than per-claim, and that is what makes it compatible with the rest of this document. The Claim Hash remains a deterministic function of the canonical claim fields within a deployment, so it remains usable as the Settlement-Layer Ledger index and as the retroactive-evaluation key, and the reproducibility requirement of Section 5 continues to hold: the same deployment given the same enumerated inputs produces the same digests. What changes is that the preimage is no longer guessable from outside the deployment. A per-claim random value would defeat all three properties.¶

Both digests are otherwise taken over low-entropy preimages: a subject identifier is typically a company number of ten or so digits, a predicate is drawn from a published taxonomy, and the accountable principal, agent-IFF policy identifier and verdict arithmetic are each drawn from small enumerable sets within one deployment. Both digests then appear where adversaries can reach them -- the Policy-Version Hash in the protected header of every notarised Signed Statement and in every reconciliation entry of the Ledger, the Claim Hash in the Output and in every Ledger entry of either kind. Without blinding, anyone holding either can recover by exhaustive search the subject that was investigated and the principal that commissioned the reconciliation, which is the disclosure this protocol exists to prevent. Blinding does not weaken reconstructibility under audit, since the Blinding Value is persisted with the state it blinds.¶

A register receives the same Policy-Version Hash as every other addressed register, by Section 5.4. The Blinding Value prevents two colluding registers from recovering the Addressed-Registers Identifier Set from it by search; that they can observe they were addressed together is inherent and is discussed in Section 8.10.¶

Equality is a different matter from inversion. The Requester-Binding is an element of the preimage and every other element is fixed by policy and by the addressed register set, so one requester asking repeatedly about different subjects presents every addressed register with the same Policy-Version Hash. A register cannot recover who that requester is, and can group every reconciliation that requester commissioned against it. Two registers addressed together can join their traffic on the same value, as can any reader of the notarised Signed Statements, in which the hash appears in the protected header. That is a stable requester pseudonym, disclosed to parties Section 8.1 otherwise limits to the Requester-Binding Class, and reasoning about the preimage's resistance to search says nothing about it: a correlation handle does not need to be inverted to work.¶

A deployment for which that is unacceptable MUST substitute, in the seventh element, a digest over the Requester-Binding and the Reconciliation Identifier. The Policy-Epoch Store holds both, so an auditor can still reconstruct the preimage, and the element then varies per reconciliation and carries no cross-reconciliation handle. It is stated as a deployment choice rather than a requirement because the constant form is what lets a register recognise a returning counterparty under a bilateral agreement, which some deployments need and others must not have. Discussed further in Section 8.10.¶

5.17. Post-Seal Evaluation Records

Two conditions arise after a Reconciliation Output has been sealed and therefore cannot be fields of it, and are not Divergence Axes: a Divergence Axis qualifies a verdict, and these qualify an operation performed on an Output that is already immutable.¶

• notarisation-incomplete, where notarisation under Section 7.5 neither completed nor was refused within the polling bound.¶

• attribution-indeterminate, where a Retroactive Evaluation could not determine whether a material change arose from a change in policy state or from a change in Source-Data Version.¶

Each is recorded in a Post-Seal Evaluation Record comprising:¶

• the Reconciliation Hash of the Output it concerns¶

• the Post-Seal Evaluation Qualifier, drawn from the registry of Section 10¶

• the Policy-Version Hash and Pattern-Library Version Identifier in force at the time of the evaluation, which may differ from those the Output was sealed under¶

• a Post-Seal Evaluation Timestamp, in the form of Section 5.14¶

• an Attribution Account, present exactly where the Qualifier is attribution-indeterminate: a text string stating which of the two candidate causes were examined and why neither could be excluded. A bare qualifier would be a discretionary escape signed by the party that benefits from it¶

• a Sealing-Key Identifier¶

• a signature by the reconciliation-server sealing key, a COSE_Sign1 whose payload is the CBOR array of this record with the signature position encoded as CBOR null¶

A Post-Seal Evaluation Record is encoded as a CBOR array in the field order above, an absent conditionally-absent field encoded as CBOR null so that position is preserved. The Post-Seal Evaluation Record Hash of Section 5.18 is the Signing Input Digest of that record's signature. Earlier revisions took it over the array in its entirety with the signature included, on the ground that the digest should be over the artefact as served under Section 7.4. That ground does not hold: under a signature primitive whose encoding is not byte-unique the artefact as served is not one byte-string, and a digest over it names whichever copy the reader was handed. Section 8.11 states the measurement.¶

A Post-Seal Evaluation Record MUST be retained by the reconciliation server for the period of Section 5.15.3, and a Continuation entry of type continuation-post-seal-record MUST be appended to the Settlement-Layer Ledger carrying the record's hash. The hash is not written into the entry that recorded the reconciliation: that entry is already signed and the Ledger exposes no UPDATE. An Audience Member of the Output discovers the record by reading the Continuation entries for its Reconciliation Hash under Section 7.4 and retrieves it by its hash under the same binding. The record travels as the result element of the signed read response of Section 7.4.3; the media type registered for the record labels it wherever it is carried outside that envelope, and the Post-Seal Evaluation Record Hash is taken over the record itself and not over the response that carried it. A record emitted but not appended would be undiscoverable, which would make the attribution safety valve of Section 5.6 unreachable in exactly the case it exists for.¶

A Post-Seal Evaluation Record MUST NOT alter the Reconciliation Output it references, and a relying party MUST NOT treat the existence of one as invalidating that Output. A Reconciliation Output whose notarisation is incomplete remains valid under its Sealing Signature.¶

Where a Sovereign Re-Notification is emitted under Section 5.21 for a material change, the notification MUST state whether the change arose from policy state or from Source-Data Version, and where it cannot, a Post-Seal Evaluation Record carrying attribution-indeterminate MUST be emitted and referenced by the notification.¶

5.18. Settlement-Layer Ledger

The Ledger carries two kinds of entry. A reconciliation entry records a sealed Reconciliation Output. A Continuation entry records a fact that arose after that Output was sealed and therefore could not be a field of it. Every entry carries an Entry Type drawn from the registry of Section 10, and the Entry Type determines which further fields the entry carries. An entry whose Entry Type is not reconciliation is a Continuation entry. Without a discriminator a verifier reading an entry cannot tell which field list to apply, and an entry legitimately lacking a field would be indistinguishable from one that is malformed.¶

Every entry, of either kind, comprises these fields and in this order:¶

• Entry Sequence Number, a strictly increasing integer with no gaps: the first entry of a chain is 1 and each subsequent entry is its predecessor's plus one. Contiguity is required because the consistency read of Section 7.4.2 cannot otherwise distinguish a sequence number the operator never allocated from one it is refusing to answer for, the two being the same 404 by Section 7.4.4¶

• Entry Type, from the ARP Ledger Entry Types registry of Section 10¶

• Claim Hash, the index of Section 5¶

• Reconciliation Hash of the Reconciliation Output the entry concerns¶

• Entry Timestamp ([RFC3339] UTC), the time at which the entry was appended¶

• Prior-Entry Hash, being the Signing Input Digest of the immediately preceding entry's Entry Signature; in the first entry of a chain, which has no preceding entry, thirty-two zero octets. It is taken over that entry's signing input and not over the entry as served, so that a reader handed any byte-string carrying that entry's signature computes one value. It still commits to every field of the preceding entry, including that entry's Self-Entry Hash, and to the Sealing-Key Identifier and the algorithm identifier in the protected header, because the Sig_structure covers all of them¶

followed by the type-specific fields enumerated below, followed by:¶

• Self-Entry Hash, being the SHA-256 digest over the CBOR array of this same entry with the Self-Entry Hash and Entry Signature positions encoded as CBOR null, encoded under the Core Deterministic Encoding Requirements of Section 4.2.1 of [RFC8949], so that the array's length is the length fixed by the Entry Type and is the same array a verifier already holds. The encoding requirement is stated here and not left to be inferred from Section 7.1: without it a definite-length and an indefinite-length encoding of one entry yield two Self-Entry Hashes, and the head comparison of this section treats that as a fork, which obliges every reader of the second encoding to act under Section 5.18.1 against an operator that equivocated about nothing¶

• Entry Signature, a COSE_Sign1 by the reconciliation-server sealing key whose payload is the CBOR array of this same entry with the Entry Signature position alone encoded as CBOR null -- so it covers every other field including the Self-Entry Hash -- and whose protected header carries the Sealing-Key Identifier that resolves it¶

An entry is encoded as a CBOR array in the field order of this section, an absent field -- whether marked OPTIONAL or conditionally absent under a stated condition -- encoded as CBOR null, so that position is preserved and the array's length is fixed by the Entry Type. Absence MUST be encoded and MUST NOT be expressed by a shorter array: two encodings of one entry would otherwise yield two Self-Entry Hashes, which the head comparison of this section treats as a fork. The order is normative because the Self-Entry Hash is taken over it; an encoding as a CBOR map would be re-sorted by key under the Core Deterministic Encoding Requirements of Section 4.2.1 of [RFC8949] and would override it. A field whose value is itself a choice -- the second field of a continuation-notarisation entry -- is encoded as a two-element array of a discriminant and a value, the discriminant being the CBOR text string entry-id or refused.¶

The Self-Entry Hash is enumerated after the type-specific fields so that it covers them. Placing it before them would leave a Continuation entry's payload outside it. The Prior-Entry Hash is taken over the preceding entry's signing input rather than over that entry's Self-Entry Hash, so that the Sealing-Key Identifier and the algorithm identifier under which that entry was signed are inside the chain. Were the chain to link Self-Entry Hash to Self-Entry Hash, neither would be covered by anything, and an operator could re-sign every historical entry under a revoked or unresolvable key while every hash in the chain, and every head already published and notarised, continued to verify.¶

The signature bytes themselves are deliberately outside the chain, and this is a change from earlier revisions, which took the Prior-Entry Hash over the whole preceding entry so that Entry Signatures were inside it. That is not recoverable: Section 8.11 measures a primitive under which one signing act has many verifying encodings, so a chain keyed on those bytes breaks for a reader handed a different one. What the chain binds is the identity of the signing act rather than the bytes of one encoding of it.¶

Two things earlier revisions detected are no longer detectable and are stated here rather than left to be discovered. Stripping a historical Entry Signature while leaving its protected header and payload intact moves no Prior-Entry Hash. So does re-signing an entry under the same key and header. The Sealing-Key Identifier and the algorithm remain covered, so a re-signature under a different key or algorithm still moves the chain, which is the case the paragraph above is about; a re-signature under the same key does not.¶

An entry is signed exactly once. A second signature over the same fields is a different entry, MUST NOT be appended at the same Entry Sequence Number, and MUST NOT replace the first.¶

Under the Prior-Entry Hash of this section that rule has no verifier-side test, and saying so is better than implying one. A Signing Input Digest is a value per signing input, not per signature, so two signings of one entry share it and yield one chain and one head rather than the two divergent chains an earlier revision relied on to make the violation visible. The rule is therefore an operator obligation an Audit Identity under Section 5.20 can examine and a reader cannot, which is the price of the digest being stable under Section 8.11, and is paid deliberately: a rule that is unenforceable against an honest reader is better than a chain that breaks for one.¶

The Entry Timestamp is distinct from the Reconciliation Timestamp. A Continuation entry may be appended weeks after the reconciliation it concerns, and an entry carrying only a Reconciliation Timestamp would state that the notarisation, the post-seal evaluation or the supersession occurred at the moment of the reconciliation, which is false in every case the mechanism exists for.¶

An entry whose Entry Type is reconciliation additionally comprises:¶

• Policy-Version Hash¶

• Addressed-Registers Identifier Set, each member an Authority Origin, sorted in bytewise lexicographic order of its UTF-8 encoding¶

• Aggregation-Method Descriptor¶

• Merkle Root¶

• Requester-Binding-Class Descriptor, one of the four classes enumerated in the Requester Identity Binding and Agent Friend-or-Foe Gate section¶

• Reconciliation Timestamp, as sealed in the Reconciliation Output¶

• OPTIONAL Source-Reconciliation-Output Identifier, being the Reconciliation Hash of the Output this reconciliation supersedes, present exactly where it supersedes one¶

• Override Indicator, true exactly where the Reconciliation Output carries an Override Record under the Adversarial Pre-Transmission Test¶

An entry whose Entry Type is continuation-notarisation additionally comprises:¶

• Transparency Service Identifier, being the Authority Origin of that service¶

• exactly one of the EntryID that service returned, or the HTTP status code by which that service terminally refused registration¶

Only the status code is recorded, never a response body. A body is authored by the Transparency Service, is unbounded, and routinely echoes submitted content; writing one into an append-only log with no DELETE would put text this document does not control inside a record that forbids claim and principal content in the clear.¶

A continuation-notarisation entry MUST be appended where notarisation completes, and where the Transparency Service returns a status the implementation resolves as a terminal refusal under Section 7.5.2. Where a status cannot be so resolved -- the 404 of Section 7.5.2 carries two meanings and a service is not obliged to distinguish them -- it is not a terminal refusal, and the reconciliation is treated as one whose polling bound was exhausted. In that case no continuation-notarisation entry is appended and the outcome is recorded under Section 5.17 as notarisation-incomplete. Requiring an entry only on failure would leave the successful case -- the case the join exists for -- unrecorded.¶

Where an implementation subsequently learns the EntryID of a registration it had recorded as incomplete, it MUST append the continuation-notarisation entry then. This document defines no means by which it would learn that: [I-D.ietf-scitt-scrapi] retrieves by EntryID and the EntryID is precisely what was not received, polling is bounded, and no callback is specified. A notarisation-incomplete record will therefore usually stand permanently, and it is evidence that registration did not complete within the polling bound and not that it failed. That is open.¶

An entry whose Entry Type is continuation-post-seal-record additionally comprises:¶

• Post-Seal Evaluation Record Hash¶

An entry whose Entry Type is continuation-supersession additionally comprises:¶

• Material-Change Indicator, stating whether the Combined Verdict changed materially within the meaning of Section 5.21¶

• Superseding-Reconciliation Hash, being the Reconciliation Hash of the Reconciliation Output that supersedes the one this entry concerns, present exactly where a superseding Output was produced and absent where the supersession is the revocation of a Verified Principal Credential under Section 5.21, which supersedes an Output without producing another¶

• Superseding-Entry Sequence Number, being the Entry Sequence Number of the reconciliation entry that records the superseding Output, present under the same condition¶

No Continuation entry carries a retrieval URI. Every artefact a Continuation entry points at is retrieved under Section 7.4, by hash for a Post-Seal Evaluation Record and by Reconciliation Hash for a superseding Output, from the same authority origin that served the entry. Carrying a URI instead would oblige every reader to dereference an operator-chosen address before it could check anything -- a forced fetch, a de-blinding oracle correlating a reader's network identity with one Reconciliation Hash, and a covert channel that no constraint on the URI's content can close, since host selection and path structure carry the signal without stating anything. It would also put a non-digest field in a Ledger whose whole disclosure argument is that it holds digests.¶

A Reconciliation Output produced by Retroactive Evaluation to supersede an earlier Output MUST carry the Audience Set and the Requester-Binding Class of the Output it supersedes. Without that rule the party entitled to learn that its verdict had changed would be entitled to the entry saying so and not to the Output that says what it changed to, and the traversal would end one step short. Such an Output has no commissioning request and is not delivered under Section 5.15.3; it is retrieved.¶

Where the superseding reconciliation addresses a register whose audience constraint the inherited Audience Set exceeds -- which can happen, since the superseding reconciliation may address registers the superseded one did not -- that register is recorded audience-constraint-exceeded under Section 5.11 like any other. The Audience Set is not truncated to fit: truncating it would strand the party the supersession exists to notify, and the constraint is satisfied by not obtaining that register's answer rather than by silencing the reader.¶

A party retrieving a Post-Seal Evaluation Record MUST reconstruct the Sig_structure of that record's signature from the protected header and the payload of the retrieved COSE_Sign1, MUST verify that its Signing Input Digest equals the Post-Seal Evaluation Record Hash carried in the entry, MUST verify that signature under the Sealing-Key Identifier the record carries, and MUST discard the record where either check fails. The hash does not cover the signature bytes, so the signature check is not redundant and a record served with a substituted, absent or garbage signature satisfies the digest check alone. Without both checks the hash is decorative and an operator can serve a different record to each audience, reopening at the record the equivocation the Ledger closes at the entry.¶

A Continuation entry carries no Policy-Version Hash, no Addressed-Registers Identifier Set, no Aggregation-Method Descriptor, no Merkle Root and no Requester-Binding-Class Descriptor. Those describe the reconciliation, which the reconciliation entry already records and the Reconciliation Hash already binds; carrying them a second time would create a second place for them to disagree. A Continuation entry MUST carry the same Claim Hash and Reconciliation Hash as the reconciliation entry it continues, and the storage interface layer MUST reject a Continuation entry whose Reconciliation Hash matches no earlier reconciliation entry, returning a rejection the appending subsystem can distinguish from a transport failure. Because Entry Sequence Numbers are allocated in one sequence and secondary stores replicate rather than originate, every store holds the reconciliation entry against which the check is made.¶

Prior-Entry and Self-Entry Hashes establish that no entry has been removed from a chain; they do not establish that only one chain exists. Signing each entry makes a second chain attributable rather than merely possible.¶

A Reconciliation Output is sealed before it is notarised and so cannot itself carry the EntryID, and the Ledger exposes no UPDATE, so the join cannot be made by amending the original entry. It is made by appending. Without it a successful notarisation would be unlinkable to the reconciliation from every side, since retrieval is by EntryID and [I-D.ietf-scitt-scrapi] offers no query surface.¶

A continuation-supersession entry MUST be appended against the superseded Output on every supersession, whether or not the change is material. Where the supersession produced a superseding Output, the superseding reconciliation entry MUST also carry the Source-Reconciliation-Output Identifier naming what it replaced, and the two records are inverse pointers over one relation. Where it did not -- the revocation of a Verified Principal Credential -- there is no superseding entry and no second record, and the Continuation entry stands alone. The Material-Change Indicator distinguishes a material supersession from an immaterial one in either case. Section 5.21 imposes the further obligation of a Sovereign Re-Notification where the change is material; it does not condition the ledger record, which is written either way, since a party relying on a superseded Output needs to know it was superseded before it can be told the change was immaterial.¶

Where both records exist they are inverse pointers over one relation and neither substitutes for the other. A party holding the superseded Output cannot follow a pointer that exists only on an entry it has not been returned, and a regulator whose scope under Section 5.19 covers the superseded reconciliation is not thereby returned the superseding one, whose addressed registers and therefore whose agreements may differ. The constraint is on what a reader is returned, not on what a store holds.¶

The Ledger MUST NOT store Canonical-Claim content, register records, Partial-Attestation payloads, or any principal identifier in the clear; the requester's accountable principal is committed only through the Policy-Version Hash. The append-only constraint MUST be enforced at the storage interface layer. The Ledger interface MUST expose APPEND and READ operations only, with no UPDATE and no DELETE operation exposed or implemented. Retroactive Evaluation and the derivation-chain invariant check are subsystems of the reconciliation server and read the Ledger without scope restriction. Every read by a party outside the reconciliation server is served under Section 7.4, which states the operations, the entitlement each requires, the response form, and the error semantics. Three entitlements reach the Ledger: a regulator's, governed by Section 5.19; an Audience Member's under Section 5.15; and an Audit Identity's under Section 5.20. A Register Operator holds the narrower entitlement of the consistency check below.¶

An Audience Member is entitled to the Continuation entries carrying the Reconciliation Hash of an Output that names it, and to the reconciliation entry carrying that same Reconciliation Hash. It is entitled to no other entry. This is the predicate earlier revisions could not express. It is evaluable, because the Audience Set is a sealed field of the Output and the server retains the Output under Section 5.15.3; the Ledger is not asked to evaluate it, and could not, since it stores no principal identifier in the clear. It admits the right party, because entitlement follows the Output rather than the request, so a member the Requesting Principal named at reconciliation time is admitted and a party that merely came into possession of the artefact is not. And it survives the events that broke its predecessors: an Audience Member's verification method is required by Section 5.15.1 to be presentable after the fact, and revocation of the Requesting Principal's Verified Principal Credential does not remove the other members of the Audience Set, so the supersession entry recording that revocation has a reader.¶

Where an Output's Audience Set is reduced to members that can no longer authenticate -- a single-member Set whose sole member's credential has been revoked -- its Continuation entries are reachable only through the Regulator Portal. The reconciliation MUST still have been performed with a Requester-Binding class recorded under Section 8.4, so the condition is visible to the regulator that scope serves.¶

An Audience Member's read discloses only facts about a reconciliation whose full content it already holds: that a supersession or a post-seal evaluation exists, what it points to, and the ledger position of each. The one exception is worth naming, because it is not obvious: a Post-Seal Evaluation Record carries the Policy-Version Hash and Pattern-Library Version Identifier in force at the time of the evaluation rather than at sealing, and those are values the member did not previously hold and, being stable within a deployment, are durable correlators. That is a deliberate disclosure to a party already entitled to the reconciliation they qualify, and it is bounded by Section 5.15.1's rule that a register may cap how wide an Audience Set addressing it may be.¶

Where the Ledger is replicated per Section 5.18.1, each secondary store MUST be able to demonstrate that its chain and every other secondary store's chain share a common prefix.¶

A common-prefix demonstration between stores under one operator is that operator attesting to itself. The reconciliation server MUST therefore publish a signed Ledger Head Statement at /.well-known/arp-ledger-head on its Authority Origin. It is republished once per notarisation interval and not on every append: the resource is unauthenticated and carries a contiguous sequence number, so a continuously updated head would hand any observer the deployment's exact entry count, its write rate and the timing and size of every retroactive supersession burst -- the aggregate disclosure Section 7.4.4 rate-limits the authenticated surface to prevent. A Statement comprises:¶

• the Entry Sequence Number of the current head¶

• the Self-Entry Hash of that entry¶

• the Entry Timestamp of that entry¶

• a Statement Timestamp, being the time the Statement was produced, in the form of Section 5.14. Without it two Statements published across a quiet period differ only in their notarisation pointer and neither is dateable, so the interval a register negotiated is unverifiable from the artefact¶

• a two-element array of the Transparency Service Identifier and the EntryID of the most recent completed notarisation of a Ledger Head Statement, encoded as CBOR null until the first such notarisation completes¶

• a signature by the reconciliation-server sealing key over the foregoing, carrying the Sealing-Key Identifier that resolves it¶

A Ledger Head Statement is encoded as a COSE_Sign1 over the deterministically encoded CBOR array of the first five items above, in that order, under the media type registered in Section 10, with the fifth item encoded as CBOR null until the first notarisation completes. The server MUST notarise the Ledger Head Statement current at each interval into a SCITT Transparency Service. The interval is the shortest declared by any Bilateral Register Agreement, per the direction rule of Section 5.15.3. The Transparency Service MUST be one every Bilateral Register Agreement the deployment holds declares, and MUST NOT be operated by or under the control of the reconciliation server or any party controlling it. A notary the operator owns is the operator attesting to itself, which is the condition this mechanism exists to escape; the same requirement governs the notarisation of Evaluation Sweep Statements under Section 5.21.1. It is not registered under the binding of Section 7.5, which is scoped to sealed Reconciliation Outputs and whose protected header requires a Policy-Version Hash and a Bilateral-Register-Agreement Hash that a head statement does not have; it is registered as a Signed Statement under its own media type. Statements published between intervals are not notarised.¶

Entry Sequence Numbers are allocated in a single sequence for the logical Ledger. A secondary store under Section 5.18.1 replicates that sequence and MUST NOT allocate independently, or two conforming stores would present the same sequence number over different entries and be indistinguishable from a fork.¶

The Entry Sequence Number is what makes two heads comparable. A bare hash cannot distinguish a fork from ordinary progress: two parties who have each seen a different head learn only that the values differ, which is the expected case whenever they observed at different times. Two Head Statements bearing the same Entry Sequence Number and different Self-Entry Hashes are therefore a fork on their face, and both are signed, so both are attributable.¶

Two Head Statements bearing different sequence numbers are reconciled by the consistency read of Section 7.4.2. A party entitled to that read -- a Register Operator or a regulator -- presents the lower of the two sequence numbers and receives the Self-Entry Hash of the entry at that position in a signed response bound to the request it answers. The two views agree only where that value equals the one the lower Head Statement carried, and where they disagree the party holds two signed statements by one key that cannot both be true of one chain. That is why the response is signed and bound to its request: an unsigned answer would let an operator serve each questioner from that questioner's own branch and leave the questioner with nothing it could show a third party.¶

The rate limit of Section 7.4.4 is load-bearing on that operation and not merely hygiene. The consistency read ranges over every sequence number up to the head; swept without limit it yields the deployment's exact entry count by binary search, its write rate by polling, and the timing and size of a retroactive supersession burst by watching for a step change -- none of which any single answer discloses.¶

A party that holds two irreconcilable signed statements MUST cease to rely on any Reconciliation Output sealed by that server after the lower of the two sequence numbers, MUST report the pair to every regulator whose Bilateral Register Agreements it can identify from the Outputs it holds, and MUST NOT treat the server's subsequent statements as evidence of anything until the discrepancy is resolved. A Register Operator that holds such a pair MUST additionally refuse further Per-Register Claim Projections from that server, on which the server records agreement-drift-suspended against that register under Section 5.11 as it would for any other suspension. Detection without a required response leaves the mechanism ending in a held contradiction and no consequence.¶

Two limits remain and are stated rather than claimed away. An operator that publishes to two audiences at disjoint sequence numbers never emits a colliding pair, so detection by collision is opportunistic even though reconciliation by consistency read is not. And a party holding neither a Reconciliation Output nor a Bilateral Register Agreement has no register set against which to anchor the signing key under Section 7.5.3: it can check that a Head Statement is signed and not that the signer was entitled to publish it. Both bear on a party outside the entitled set; a Register Operator, which is the party with standing to care whether its attestations sit on one chain, has the agreement that anchors the key and the entitlement that completes the check.¶

5.19. Regulator Portal

The Regulator Portal Subsystem authenticates a sovereign regulator's jurisdictional credentials against a regulator-identity-provider trust anchor that MUST be declared in every Bilateral Register Agreement addressed by the reconciliation being read. It restricts returned fields to those within the regulator's statutory scope as declared in the statutory-regulator-access scope of those agreements. Each Bilateral Register Agreement declares, per regulator jurisdiction, a permitted-read-field set: the names of the Reconciliation Output and Ledger entry fields a regulator of that jurisdiction may be returned, and the predicates over which it may be returned them. The scope restriction is the INTERSECTION of the per-agreement permitted-read-field sets scoped to the regulator's jurisdiction, taken only over reconciliations whose Canonical Claim Predicate is in the intersection of the corresponding permitted-read-predicate sets, and further intersected with the regulator's requested field set. Fields and predicates are different domains and are intersected separately; intersecting one with the other would yield the empty set, which earlier text did. Each access MUST be recorded in an append-only audit trail. Each record MUST carry a contiguous sequence number and the digest of the preceding record, computed as Section 5.18 computes a Prior-Entry Hash, and the reconciliation server MUST publish a signed head of that trail -- its current last sequence number and digest, under its sealing key -- once per ledger-head notarisation interval, and MUST notarise that head into the Transparency Service of Section 5.18.¶

Earlier revisions called the trail subpoena-grade and specified none of that. The trail is held by the party whose reads it records, and the accountability of the Audit Identity entitlement rests on it -- an unaudited audit right is a standing unaccountable read. Without a chain and an externally anchored head, a record can be removed or rewritten by the party the trail exists to hold accountable, and it is then evidence only against a party that has not tampered with it. This document applies exactly this construction to the Settlement-Layer Ledger a few sections above and applied none of it here, which is the whole of the defect: not a technique the document lacks, a technique it did not carry to the second place that needed it.¶

The Portal is a subsystem of the reconciliation server and reads the Ledger without scope restriction. The scope governs what it RETURNS, not what it may read. Stating it the other way round would make the Portal unable to compute the authority under which it answers, since that computation requires reading the entry first.¶

Where the entry read is a Continuation entry, the Portal computes the trust anchor and the scope from the agreements addressed by the reconciliation entry carrying the same Reconciliation Hash. A Continuation entry names no registers of its own, and an intersection taken over an empty set of agreements would either deny every regulator or restrict none, which are the two failures the rest of this section exists to avoid.¶

The fields a Continuation entry carries are structural: an entry type, a sequence number, a timestamp, chain hashes, and a pointer to an artefact. None is a register record, a claim value or a verdict. A regulator in scope for a reconciliation entry is therefore in scope for every field of every Continuation entry carrying that entry's Reconciliation Hash, without any agreement having to enumerate those fields. The alternative -- intersecting a set of field names no agreement mentions -- yields the empty set, and would make a Sovereign Re-Notification arrive at a regulator that is then returned nothing when it follows the pointer. Agreements negotiated before this revision name none of these fields, and Section 5.21 forbids retroactive evaluation from requiring any agreement to be renegotiated.¶

Both intersections are load-bearing. Taking the union across agreements would let one register operator's permissive agreement widen what a regulator may read about a reconciliation that also addressed a restrictive register, inverting the data-residency property this protocol exists to preserve; and requiring the trust anchor in only one agreement would let a single register operator unilaterally introduce a regulator identity that authenticates against multi-register events. Intersecting with the requester's own requested set is not itself a restriction, since the requester chooses it.¶

5.20. Audit Path

Several requirements in this document are justified by what an auditor can reproduce: the re-typing decision of Section 5.12 "without the server's assurance", the Query Binding of Section 5.8, the Policy-Version Hash "under audit" of Section 5.16, and the Deployment Blinding Value of Section 5.16. No earlier revision defined that path, so every one of those justifications rested on a party the document did not admit.¶

Each Bilateral Register Agreement MUST declare at least one Audit Identity: an identifier and a key thumbprint, in the form Section 5.15.1 uses for an Audience Member. A party authenticating as an Audit Identity under Section 7.4.1 is entitled to:¶

• every operation of Section 7.4.2, unredacted, over any reconciliation addressing the register whose agreement declares that identity¶

• the Reconciliation Outputs of those reconciliations, irrespective of their Audience Sets, by GET /arp/outputs/{reconciliation-hash}¶

• for a named reconciliation, every element of the Policy-Version Hash preimage of Section 5.16 EXCEPT the Deployment Blinding Value, together with a Reconstruction Proof: a keyed digest, computed as HMAC [RFC2104] with SHA-256 under the Deployment Blinding Value over the deterministically encoded CBOR array ["arp-reconstruction-v1", P], where P is the Policy-Version Hash preimage array of Section 5.16 with its Deployment Blinding Value position encoded as CBOR null so that the array's length is preserved. It is served as the two-element array of the disclosed elements and the proof, as the result of GET /arp/outputs/{reconciliation-hash} where the requester authenticated as an Audit Identity. An auditor given the Value recomputes it; one not given the Value can only compare it against another proof the same server produced.¶

  The preimage is pinned here because it was not pinned anywhere. The sweep recorded in the Document History put every digest preimage and signature payload in this document into a CBOR array with a normative field order and null-substitution for absent fields, and enumerated the artefacts it had reached; this construction was not among them. It had no array, no domain-separation string, no field order, no rule for the excised element and no encoding requirement, and it also had no wire representation, since Section 7.4.2 defines that operation as returning the sealed Output and Section 7.4.3 defines no slot for a value served beside one¶

An Audit Identity is NOT given the Deployment Blinding Value, and is not given the preimage in full, because the preimage contains it. The Value is one deployment-wide constant and its holder can invert every Claim Hash and Policy-Version Hash on the published Ledger by the exhaustive search Section 5.16 describes, including those of reconciliations the auditor's own register had no part in; every agreement declares an Audit Identity, so disclosing the Value to one would disclose the deployment to all of them.¶

An Audit Identity that does not hold the Deployment Blinding Value compares one value the server produced against another value the server produced, under a key only the server holds, over material that neither the Sealing Signature nor any Ledger entry commits to. Equality establishes that the server was self-consistent across the two reads and establishes nothing further. It does not establish that the disclosed policy elements are the ones sealed into the Policy-Version Hash, because a server that sealed under one policy state and later disclosed a different one computes a consistent pair with no more effort than an honest one does. And it does not establish that the resulting hash is correct. Only an Audit Identity given the Value can establish either.¶

An earlier revision stated the first half as established and only the second as open, which was one step too generous: it granted the mechanism the property that a proof minted by the audited party, under the audited party's secret, over material nothing else commits to, tells a third party something about the world. A deployment that requires the stronger property MUST appoint an Audit Identity jointly with every register whose agreement it holds, and MAY disclose the Value to that joint identity alone. This document states the limit rather than resolving it, because a construction that let one register's appointee verify a deployment-wide digest without holding the deployment-wide secret is a different mechanism than the one specified here.¶

An Audit Identity is declared in an agreement rather than named by a requester, because the party being audited must not choose its auditor after the facts are known, and because the register whose records are at issue is the party with standing to insist on one. Its entitlement is scoped to reconciliations addressing that register: an auditor appointed under one agreement reads nothing about a reconciliation that agreement had no part in.¶

Every access under an Audit Identity MUST be recorded in the append-only audit trail of Section 5.19. An unaudited audit right is a standing unaccountable read of every Output a deployment holds.¶

5.21. Retroactive Evaluation

Upon publication of an updated Pattern Library, an updated Policy Version, or a new Source-Data Version for any list a register consulted under Section 5.6, the Retroactive Evaluation Subsystem MUST execute a deterministic re-application of the updated state to the retained metadata of historical Reconciliation Outputs -- the Per-Register Result Set, the resolved arithmetic and its parameters, and the Source-Data Version Identifiers, being the inputs from which a Combined Verdict is recomputed. Under a Pattern-Library or Policy-Version trigger the set to be examined is every retained Output whose Policy-Version Hash preimage, as the Policy-Epoch Store of Section 5.16 holds it, carries a value the transition changed. A Policy-Version Hash is not superseded as a value: its seventh element is that reconciliation's Requester-Binding, so it is per-reconciliation and there is no current hash against which to compare one. What a transition supersedes is a preimage element, and the store holds every preimage. Earlier revisions selected on "a superseded Policy-Version Hash", which named no determinate set and left the operator to choose which Outputs its own policy change had reached. Under a Source-Data Version trigger the policy state is unchanged and that set would be empty; the set is instead those Outputs whose Per-Register Result Set carries a Source-Data Version Identifier from the list that was republished. Under a credential-revocation trigger it is those whose Requester-Binding rested on the revoked credential. Under a register-record-correction trigger, being a statement by a Register Operator under item 32 of Section 5.23.1 that a record it attested has been corrected, the set is those Outputs carrying a Partial Attestation from that register over the corrected record.¶

The fifth trigger is new in this revision and the gap it closes is the one a subject would care about most. A source-data-version trigger reaches a corpus-level republication whose state identifier the list publisher assigns and which must be identical across every attestation over that list; it does not reach a register correcting one record about one person. So a beneficial-ownership register carrying an erroneous ownership percentage could produce a match on a sanctions-linkage predicate, correct the record the following week, and no trigger would fire, no sweep would run and no supersession would be appended. An Audience Member reading Continuations before relying past the Reliance Horizon would correctly find nothing, and the verdict built on the error would stand. Section 9.2 states that a rectified verdict is expressed by supersession rather than by deletion, and until this revision no trigger produced one. Where permissible under the applicable Bilateral Register Agreements, partial attestations MAY be re-invoked.¶

The retroactive evaluation MUST be executable without re-negotiation of any Bilateral Register Agreement. A material change in a historical Combined Verdict -- defined as any change of verdict value into, out of, or between the decisive values, the decisive values being match and no-match -- MUST trigger a Sovereign Re-Notification through the Regulator Portal, and MUST additionally be recorded as a Continuation entry of type continuation-supersession against the superseded Output, under the field rules of Section 5.18, so that a party which acted on the superseded Output can discover that it was superseded. Notifying only the regulator would leave the party that acted on a verdict the last to learn it had changed. A transition from no-match to match is material: it is the case the protocol's motivating domain cares most about, and a definition that excluded transitions within the decisive class would omit it. Revocation of a Verified Principal Credential relied upon in a historical reconciliation is itself a material change: the Retroactive Evaluation Subsystem MUST re-derive the affected Requester-Binding class and, where a decisive reconciliation was performed for what is now an unverifiable requester, emit a Sovereign Re-Notification.¶

5.22. Cryptographic-Primitive-Upgrade Path

Each Bilateral Register Agreement MUST declare a Cryptographic-Primitive-Upgrade Path comprising an ordered equivalence list for each of three primitive classes: claim-encryption, partial-attestation-signature, and sealing-signature. The equivalence list MUST include at least one post-quantum primitive for each class, drawn from a set including ML-KEM [FIPS203] for key encapsulation and ML-DSA [FIPS204] for signature operations.¶

A primitive rotation MAY be executed simultaneously across the three layers without bilateral renegotiation. The Settlement-Layer Ledger remains continuous across the rotation because Ledger entries commit to hashes of canonicalised content rather than to cryptographic identities. The Entry Signature and the Sealing-Key Identifier it carries are the exception, and a verifier MUST resolve the Sealing-Key Identifier carried by each entry rather than assume one key across the chain. An entry signed under a superseded primitive remains verifiable under the key that identifier resolves. The chain is unbroken across a rotation, but not because it is independent of the primitive: the Prior-Entry Hash of Section 5.18 is the Signing Input Digest of the preceding entry's Entry Signature, so it depends on the algorithm identifier in that signature's protected header, which the Sig_structure covers. It does not depend on the signature bytes, and that is deliberate. Earlier revisions took the Prior-Entry Hash over the whole preceding entry including its Entry Signature and argued the chain was unbroken because those bytes "are fixed at the moment the entry is appended and are never rewritten". Fixed for the operator, and not unique: Section 8.11 measures a primitive under which one signing act has many verifying encodings, so the bytes a reader is handed are not the bytes the operator appended and a chain keyed on them breaks for that reader alone. A verifier recomputing a Prior-Entry Hash across a rotation boundary takes the protected header and the payload byte strings from the preceding entry's COSE_Sign1 verbatim and constructs the Sig_structure around them. It MUST NOT re-encode the protected header: those bytes are the signer's and are what the signature covers, and a verifier that re-encoded them would compute a different digest wherever its encoding differed from the signer's, and could not encode a rotated primitive's header parameters at all without implementing that primitive. The verifier therefore parses a COSE_Sign1 but needs no knowledge of the primitive under which it was signed, and in particular need not verify it. That is more than earlier revisions asked, which was to copy the preceding entry's bytes and hash them; the additional requirement is COSE parsing, and it is the price of a digest that does not move when the signature encoding does.¶

5.23. The Bilateral Register Agreement

A register is addressable under this document only through a Bilateral Register Agreement. Nothing in this document can be executed against a register that has none: the projection has no permitted-predicate set to test against, the channel has no construction, the encryption has no key, and the Per-Register Claim Projection has no Bilateral-Register-Agreement Hash to carry. This section is where the obligations that other sections place on an Agreement are gathered, and it is the definition of the Agreement Hash.¶

5.24. Aggregate Statements

Nothing above governs what may be said about a set of Reconciliation Outputs. That is the gap through which a four-valued vocabulary becomes a percentage.¶

Section 5.13 forbids the Verdict Arithmetic from combining a Non-Answer Reason, and requires an indeterminate contribution to propagate rather than be resolved. Both hold inside one reconciliation. Neither reaches the report that says a deployment ran at ninety-one per cent. The prohibition is a rule addressed to an implementer, and the pressure to state a single figure arrives from outside engineering, after the vocabulary is public and looks like a scoring system. A rule is what an engineer follows and a structure is what a spreadsheet cannot get around, and only the second survives that pressure.¶

An Aggregate Statement is the only form in which this document permits a count, rate or proportion over more than one Reconciliation Output to be published, cited, or supplied under Section 5.19 or Section 5.20. It is a COSE_Sign1 by the reconciliation-server sealing key whose payload comprises:¶

• the Declared Population: the criterion by which an Output is in the set, and the Basis on which it is decided, being one of catalogue where the population is a list held before the period began, enumeration where it is everything in a stated Entry Sequence Number range, or declared where the operator asserts it and nothing else fixes it¶

• where the Basis is enumeration, the Entry Sequence Number range, so that the denominator is checkable against the Ledger as Section 5.21.1 checks a sweep¶

• the Denominator: the count of Outputs in the Declared Population¶

• the Verdict Vector: one count for each value of the Combined Verdict, including indeterminate, in the order Section 4 gives¶

• the Non-Answer Vector: one count for each Non-Answer Reason in the registry of Section 10 that appears in the set, each naming its reason¶

• a Statement Timestamp, a Sealing-Key Identifier and a signature¶

The Verdict Vector and the Non-Answer Vector MUST sum to the Denominator, and a reader MUST reject an Aggregate Statement in which they do not.¶

That sentence is the mechanism and everything else is scaffolding for it. A component of a sum that has to balance cannot be averaged away, folded into a neighbour, or dropped from a denominator, because each of those breaks the arithmetic in a way any reader can see without holding a single Output. There is no representation of this Statement in which indeterminate is absent and the numbers still add up. Compare the rule it replaces, which said an implementation must not combine certain values: an implementation that combined them anyway produced a document indistinguishable from one that had not.¶

A deployment MAY publish a rate derived from an Aggregate Statement, and where it does it MUST publish the Statement alongside and MUST NOT publish a derived figure alone. A rate is a projection of the vector onto one number, and this document does not forbid the projection. It requires that the thing projected from travels with it, so that a reader who wants to know what the other nine per cent were is one artefact away rather than dependent on the publisher's goodwill.¶

Why the Basis is declared and not assumed. A proportion is a claim about a denominator, and a denominator no one stated is a denominator the publisher chose after seeing the numerator. enumeration is the strong case and is checkable against the Ledger by anyone. catalogue is weaker and still falsifiable, since the list existed before the period. declared is the operator's assertion, is not falsifiable, and MUST be recorded as such rather than presented as though it were either of the others. The three-way distinction, and the requirement that a report account for every unit it did not examine rather than reconcile by arithmetic, are taken from the Coverage Attestation Profile [I-D.hillier-coverage-attestation], which specifies them in a form that is not particular to this protocol.¶

What this does not do. It does not stop a party outside the protocol computing whatever it likes from Outputs it holds. Nothing can. What it stops is that party doing so and citing this document, because a figure published without its Statement is non-conforming and a figure published with one carries its own contradiction where it has one. The distinction between a number nobody can check and a number whose components must balance is not enforcement, it is the difference between a claim that has to be believed and a claim that can be refused.¶

Acknowledged. The general problem, and the observation that a prohibition on averaging is not a mechanism, are Emek Can Doğru's, put to the SCITT mailing list on 20 August 2026.¶

7.1. CBOR-COSE Encoding

The mandatory-to-implement encoding for ARP messages on the wire is CBOR with COSE [RFC9052] [RFC9053] envelopes. COSE_Sign1 is used for both Partial Attestations and the Sealing Signature. Every COSE_Sign1 this document defines MUST carry the algorithm identifier (label 1) and the key identifier (label 4) in its protected header, and MUST NOT carry either in an unprotected header. A Signing Input Digest under Section 4 depends on the protected header and on nothing else in the envelope, so an algorithm or key identifier placed outside it is a value that digest does not bind -- and Section 5.22 relies on the algorithm identifier being bound.¶

The protected header of a Partial Attestation and of a sealed Reconciliation Output MUST additionally include the Bilateral-Register-Agreement Hash and Policy-Version Hash as COSE header parameters; the other COSE_Sign1 structures this document defines carry the headers their own sections state registered per Section 10. arp-bilateral-agreement-hash always carries an array, sorted in lexicographic byte order: a Partial Attestation's array has exactly one member, and a Sealing Signature's has one per addressed register. A single encoding for both avoids a decoder having to infer the type from context. Pending registration, implementations MAY use labels from the private-use range of the COSE Header Parameters registry; such use is not interoperable.¶

Every digest this document takes over a CBOR encoding is taken under the Core Deterministic Encoding Requirements of Section 4.2.1 of [RFC8949], and this document cites that section rather than the word canonical because the two name different things. Section 4.2.1 orders the pairs of a map in the bytewise lexicographic order of the deterministic encodings of the keys. Section 4.2.3 of the same document describes a Length-First Map Key Ordering, in which a shorter encoded key sorts ahead of a longer one and ties are broken bytewise, and that is what several widely used CBOR libraries produce under an option named canonical, the name the length-first rule carried before [RFC8949] separated the two. An implementation MUST produce the ordering of Section 4.2.1. A library option named canonical commonly produces Section 4.2.3 instead, and an implementation that relies on one without establishing which it produces has not met that requirement.¶

The two orderings agree for any map whose keys are integers or strings and share a CBOR major type, at any mix of lengths: for those types the head byte never decreases as the encoding lengthens, and where two keys share a head byte the bytewise comparison continues into the bytes that follow it, which orders them the same way. The head byte of an array, a map or a tag encodes a count rather than a length, and the agreement does not hold there; COSE admits only integer and string labels, so no map on a digest path in this document has a key of those types. Integers span two major types, so a header pairing a positive label with a negative one is outside the agreement, and that is the case the next paragraph is about. They diverge only where a map mixes major types and the key of the higher major type has the strictly shorter encoding. A negative label of -1 is the single byte 0x20; a label of 256 is 0x19 and two further bytes. Length-first puts -1 first; bytewise puts 256 first, 0x19 being below 0x20.¶

No protected header this document specifies reaches that case. The headers it defines carry the algorithm identifier, the key identifier and the parameters Section 10 registers, and a map of those sorts identically under both orderings. The requirement is stated so that it stays that way: Section 7.1 permits labels from the private-use range pending registration, private-use labels are negative, and a deployment that pairs one with a registered label of 256 or above has built the divergent case out of two permitted choices. An implementation that produced Section 4.2.3 there would encode one protected header differently from one that produced Section 4.2.1, and so compute a different Signing Input Digest over one signing act and a different Prior-Entry Hash for the entry above it. The head comparison of Section 5.18 treats that as a fork, against an operator that equivocated about nothing. The entry array of Section 5.18 is an array and not a map for the reason that section gives, which places the ordering question at the protected headers and not at the entry.¶

7.2. Reconciliation Request Binding

A reconciliation is commissioned by POST /arp/reconciliations on the reconciliation server's authority origin, with a request body carrying the Canonical Claim, the Audience Set the requester asks for, and, where the requester is an agent, its asserted principal. The body is CBOR under the media type registered in Section 10 for a reconciliation request, save for the Canonical Claim, which is carried as a CBOR byte string holding the [RFC8785] serialisation of the claim exactly as the Claim Hash is taken over it. Carrying the claim as native CBOR would need the CBOR-to-JSON mapping Section 5.14 declines to define, and two servers receiving identical bytes would compute different Claim Hashes. The request MUST be signed under the profile of Section 7.4.1, with tag set to arp-reconcile.¶

An Audience Member other than the Requesting Principal MUST have been enrolled at the reconciliation server before it may be named: an enrolment binds an accountable-principal identifier to a Verification Method Reference, is performed by the party being enrolled, and is out of scope for this document. A server MUST refuse to name an unenrolled member. Without enrolment a requester could name any identifier it liked, and the named party -- a competitor, a journalist, a foreign ministry -- would be handed a sealed, register-attested record that a named subject had been investigated under a named predicate, without its consent and without any register's. Naming is an assertion by the requester; enrolment is what makes it an assertion about a party that has agreed to receive.¶

A refusal on that ground discloses that a named identifier is not enrolled, which a requester able to repeat it turns into an enumeration of the enrolment roster. A server MUST charge such a refusal against the requester's rate limit under Section 7.4.4 and MUST record it in the access log that section requires. Section 7.4.4 refuses to distinguish absence from inentitlement on the read path, on the ground that answering differently would turn every endpoint into an existence oracle; this endpoint is outside that section, so the principle is carried here by rate and by record rather than by collapsing the two answers, because a requester naming an audience member it believes enrolled needs to be told when it is wrong. The residual is recorded in Section 9.¶

The response is one of four things, the fourth being the 401 of Section 7.4.1 where the request's own signature was not accepted. A 200 whose body is the signed read response of Section 7.4.3, whose result element is the sealed Reconciliation Output and whose As-Of pair gives the Ledger head at the moment of delivery. That is the delivery Section 5.15.3 requires, and it is what carries the Reconciliation Hash: the requester computes it over the Output it has just been handed, and the signed response fixes the head against which every later read of that Output is compared. A 422 carrying a Remediation Advisory, where the Adversarial Pre-Transmission Test did not emit a Pass and no override was authorised, or where a named regime is not one the policy-epoch store admits for the predicate, or where a named Audience Member is not enrolled. Or a 403 carrying a Remediation Advisory whose sole content is the Agent-IFF ground, where the Agent-IFF policy of the Requester Identity Binding and Agent Friend-or-Foe Gate section refuses the requester outright for the predicate class. Both refusals are signed as Section 7.4.3 requires of a 4xx, so a refused requester holds evidence of what it asked and what it was told.¶

A refusal under Section 8.1 or an audience constraint under Section 5.15.1 is not a fourth case: those refuse a register, and the reconciliation is sealed and delivered with the reason recorded against that register.¶

7.3. HTTP Message Signature Binding

Where a reconciliation is requested over HTTP by an autonomous agent, the request MUST be signed under HTTP Message Signatures [RFC9421], with the signature-agent key resolvable through a Web Bot Auth signature-agent card [I-D.meunier-webbotauth-registry], advertised via the Signature-Agent header [I-D.meunier-webbotauth-httpsig-protocol] and resolved through the HTTP Message Signatures directory it names [I-D.meunier-webbotauth-httpsig-directory]. The reconciliation server derives the Agent Friend-or-Foe Determination from verification of that signature and, where required by the Agent-IFF policy, a Verified Principal Credential carried in the request body.¶

7.4. Output and Ledger Read Binding

This section is the wire binding for every read this document requires of a party outside the reconciliation server. Earlier revisions stated what a read returns and never how one is requested, which left every discovery path ending at a value its holder could not present to anything.¶

Requests are HTTP over TLS to the reconciliation server's authority origin, the same origin whose Sealing-Key Identifier resolves under Section 7.5.3. Every hash appearing in a path segment is base64url-encoded without padding; every Authority Origin appearing in one is percent-encoded as Section 2.1 of [RFC3986] provides; and every timestamp in a path or query parameter is in the form Section 5.14 pins. The @target-uri is inside the request-binding digest of Section 7.4.3, so an encoding two implementations could choose differently would make their bindings differ over the same read. A non-Requesting Audience Member is not told that origin by this protocol; it learns it from the party that named it, and this document defines no directory by which a principal discovers the servers at which Outputs naming it may exist.¶

["arp-read-v1", request-binding, status, response-time,
 as-of-sequence-number, as-of-self-entry-hash, result]

7.5. SCITT Reference API Binding

A Reconciliation Output MAY be notarised into a SCITT Transparency Service as a transparent statement. Where it is, an implementation MUST use the binding in this section. Appendix B states the architectural relationship; this section states the wire behaviour, so that two implementations registering the same Reconciliation Output against the same Transparency Service produce interchangeable results.¶

7.6. Verifiable Credentials Interop

A Reconciliation Output MAY be additionally serialised as a JSON-LD document conforming to the W3C Verifiable Credentials Data Model [W3C-VC-DM-2.0], under the media type application/arp-reconciliation-output+json registered in Section 10 -- +json rather than +ld+json, there being no such registered structured syntax suffix -- with the Reconciliation Hash, Addressed-Registers Identifier Set, Bilateral-Register-Agreement Hash Set, Requester-Binding-Class, Policy-Version Hash, Claim Hash, Combined Verdict, Audience Set and Reliance Horizon included as credential subject fields. The COSE_Sign1 envelope is the normative form; the Verifiable Credential serialisation is an interop convenience for relying parties operating in W3C VC ecosystems.¶

The Audience Set and the Reliance Horizon are not optional in this serialisation. A credential is the form of an Output most likely to reach a party outside its Audience Set, and one carrying neither the membership list against which such a party could determine that it is not entitled, nor the marker of its own staleness, would be the bearer artefact Section 5.15 exists to retire, reintroduced through the interop form.¶

7.7. Representation Invariance

Every interoperability defect this document has repaired in its digest constructions is one defect. A signature that has two byte encodings for one signing act. A CBOR item whose major type the text did not fix. A set with no ordering rule, or a CBOR map whose key order two libraries decide differently. An optional member that could be omitted or nulled. A URI that could be normalised on receipt or before sending. A Unicode string in NFC or in NFD. A binary value rendered into JSON as base64, base64url or hex. A digest taken over transmitted bytes or over a re-encoding.¶

In each case two byte strings carry the same information and a digest over them differs. The information content is invariant and the representation is not, and the digest was defined over the representation. This section states the general rule those repairs are instances of, so that the next instance is caught by the rule rather than by the next reviewer.¶

The rule. For every digest, signature payload and comparison this document defines, the value MUST depend only on the information its input carries and MUST NOT depend on any choice of representation that carries no information. A construction that fails this is not merely inconvenient: two conforming implementations given the same facts compute different values, and every mechanism built on the value inherits the divergence.¶

The obligation that makes it testable. A specification cannot discharge this by asserting it. For every digest it defines, this document names the representation class of each input: the set of byte strings that carry the same information as that input. The classes this document recognises are:¶

• Signature encoding. For ECDSA, (r, s) and (r, n - s). The class has more than two members over the wire, since a low-S rule removes one member of an unbounded set. Handled by Section 8.11.¶

• CBOR type choice. A value expressible as more than one major type: an identifier as tstr or bstr, a count as uint or text, a URI as tstr or tag 32, a timestamp as tstr or tag 0. Handled by the type tables of Section 5.23.3, Section 5.14, Section 5.8 and Section 10.¶

• Collection order. The permutations of a set, and the orderings of the pairs of a CBOR map. Handled by the bytewise sort rules stated at each set, and for a map by the requirement of Section 7.1 that Section 4.2.1 of [RFC8949] be produced and that a library option named canonical not be assumed to produce it. The map case is the one place in this class where the freedom is exercised by a library default rather than by an implementer's choice, which is why it is named there as well as here.¶

• Absence. An optional member omitted, or present and null. Handled by the null-substitution rules, which also fix array length.¶

• Text normalisation. The Unicode normalisation forms of one string. Handled by the NFC requirement of Section 5.1.¶

• Reference normalisation. The equivalent forms of one URI or origin. Handled by Section 4 for an Authority Origin and by [RFC3986] normalisation for the identifiers that carry it.¶

• Binary rendering in a text encoding. Base64, base64url with or without padding, and hexadecimal renderings of one byte string. Handled by the key-identifier rule of Section 7.5.3 and by the digest rendering of Section 5.1.¶

• Framing. A concatenation against an array, and an array against a map. Handled by the domain-separated array requirement stated at each preimage.¶

A specification that defines a new digest MUST state, for every element of its preimage, which of these classes the element belongs to and which member of the class the preimage takes. A registration under Section 10 that introduces a value carried into any digest this document defines MUST do the same, and the designated expert MUST refuse one that does not.¶

The conformance obligation. A conformance runner for any construction in this document MUST exercise the construction against the representation class of each of its inputs, and not against an enumeration of previously observed defects. The distinction is the whole of the test's value. A runner that checks a digest against the two ECDSA signature encodings it has heard of confirms what its author already knew; a runner that enumerates the class and asserts the digest is constant across it detects the member nobody had thought of. The same holds for every class above. Where a class is unbounded, the runner MUST sample it and MUST record in its run transcript that it sampled rather than enumerated, so that a reader is not told a property was established over a class when it was established over a sample of one.¶

What this does not establish. Invariance across a representation class is not correctness. A digest can be perfectly invariant and taken over the wrong elements, and this rule says nothing about that. It says only that two parties holding the same facts reach the same value, which is the precondition for every other property this document claims and is not itself any of them.¶

8.1. Service-Operator Containment

The reconciliation server operates under a service-operator entity standing in bilateral contractual relationship with each Register Operator. The service-operator entity MUST NOT be given access to any register record or any Partial-Attestation payload beyond the verdict and divergence-axis fields, and a deployment MUST enforce that by construction -- by encryption addressed to the requester or by an equivalent measure that no internal operator action can reverse -- rather than by policy. A conformance test for this requirement is whether an operator holding every credential the deployment issues can obtain a register record; if it can, the deployment does not conform.¶

Encryption addressed to the requester discharges this requirement for a register record, and for any enumerated field the reconciliation server does not read. It cannot discharge it for the Query Binding, the Freshness Timestamp, the echoed Policy-Version Hash and Bilateral-Register-Agreement Hash, the Source-Data Version Identifier Set or the Applied-Parameter Set, each of which Section 5.8, Section 5.6, Section 5.4 and Section 8.6 oblige the reconciliation server to read in the clear. For those fields the equivalent measure MUST be an execution boundary whose integrity is remotely attestable under [RFC9334] and whose plaintext state no credential the deployment issues can read, and the conformance test above extends to them: an operator holding every credential the deployment issues must be unable to obtain any of them.¶

The distinction this rests on is the one the section opens with and did not carry through. The prohibition binds the service-operator entity, a legal person, and not the reconciliation server, a process, whose reading of those six fields the sections named above require. The two named enforcement measures were therefore not alternatives of equal reach: the first is unavailable for exactly the fields where the prohibition bites, and the conformance test asked only about a register record, so the payload half of the requirement had no test at all.¶

That property is per-event and MUST NOT be read as a property of the system under repeated querying. A verdict is a function of an attested value the requester chooses, so a sequence of reconciliations varying that value recovers the underlying record field by search, and several Divergence Axis values -- ownership-threshold-mismatch, register-record-absent, temporal-mismatch -- disclose record content on their own. Each event conforms while the sequence does not.¶

A deployment MUST therefore declare in each Bilateral Register Agreement a query budget and the interval over which it is measured, and the budget MUST be measured per accountable principal per subject, not per subject alone. The subject half of that key is the Claim Hash of the Canonical Claim with its Predicate, Applicable-Regimes Set and Claim Timestamp elided, computed as Section 4 computes a Claim Hash over the remainder. The principal half is pinned in three tiers below and the subject half was pinned nowhere, which left the counter keyed on a value the requester controls: a Subject Identifier is NFC-normalised as a string and nothing more, so case, leading zeros, jurisdiction prefixes and equivalent register-specific forms each open a fresh counter. The bound on recovery-by-search this section exists to impose was evadable by respelling, and the per-subject ceiling was a shared counter whose key a party could collide with a victim's, forcing every third-party reconciliation about that victim to indeterminate. Where the budget is shared across requesters, any one requester exhausts it for all of them -- including a requester whose Requester-Binding class is agent-unverified, which is to say a party the deployment has declined to identify -- and every subsequent reconciliation about that subject is forced to indeterminate for the remainder of the interval. That is a denial of service against every other requester, granted by the countermeasure. The recovery property this budget bounds is a property of one requester's sequence, and sequences run by colluding principals are the business of the repeated-narrowing pattern below rather than of a shared counter.¶

The budget is keyed on the accountable principal identifier where the Requester-Binding carries one. Where it does not -- classes agent-unverified and agent-key-verified -- the budget MUST be keyed on the verified signing key where one exists, and otherwise on a deployment-declared fallback key such as the authenticated transport client identity. Every requester signs, by Section 7.4.1, so every requester has a key and none falls outside the budget. Admitting a requester to a shared counter is the denial of service this paragraph exists to remove.¶

A deployment MAY additionally declare a per-subject ceiling across all principals. A ceiling is a shared counter and reintroduces that denial of service by construction, so where a deployment declares one it MUST partition it: a stated proportion reserved for principals of class human-operator and agent-verified, and within that proportion a per-principal sub-budget, so that no one principal can consume the reserve. Classes carrying no corroborated principal -- agent-key-verified and agent-unverified -- are charged only against the remainder. A reserve with no per-principal partition is exhausted by a subject that incorporates enough entities to hold enough corroborated principals, which is a purchase and not a barrier. A subject able to mint identities cheaply can otherwise exhaust the ceiling on itself and force every third-party reconciliation about it to indeterminate, which is a self-service veto over the verdicts this protocol exists to produce. Exhaustion of a ceiling is recorded as subject-ceiling-exhausted rather than query-budget-exhausted, so that the two are distinguishable in the record and an auditor can see which counter refused.¶

Where a reconciliation would exceed the budget, the reconciliation server MUST NOT transmit a projection to the affected register and MUST record query-budget-exhausted as that register's Non-Answer Reason. The reconciliation proceeds and is sealed; it cannot reach a decisive Combined Verdict, by Section 5.13. It is the register that is refused, not the reconciliation: refusing the reconciliation outright would leave no Output in which to record the reason, which is the artefact the requester needs in order to know why it was refused and the regulator needs in order to see that it was.¶

The Pattern Library MUST include a repeated-narrowing pattern so that the Adversarial Pre-Transmission Test detects the sequence rather than only the event.¶

A register cannot apply its own statutory access regime to a requester it cannot see. Where a Bilateral Register Agreement requires it, the Per-Register Claim Projection MUST carry the Requester-Binding Class, which discloses the class and not the principal.¶

8.2. Budget Exhaustion as a Suppression Channel

Section 5 places a reconciliation driven to query-budget-exhausted or subject-ceiling-exhausted outside the reproducibility requirement, because the budget is accumulated state rather than an enumerated input. That carve-out is a suppression channel and is recorded here as one.¶

Any non-answering register makes a decisive Combined Verdict unreachable (Section 5.13). An operator that wishes to prevent a particular reconciliation from reaching a decisive verdict can therefore record query-budget-exhausted against one register, and an auditor replaying the enumerated inputs is required not to treat the divergence as a determinism failure. The reason is server-observed under Section 5.11, so no register signature contradicts it.¶

Two mitigations are available and neither is adopted here. Publishing the budget counter and interval boundaries beside the refusal would let an auditor distinguish exhaustion from suppression -- and would tell every requester how much third-party interest a subject has attracted, and exactly when to exhaust the counter so that no other party obtains a decisive verdict, which is a worse disclosure than the one it cures. Requiring a register-signed acknowledgement of each charge against the budget would remove the server's discretion, at the cost of a round trip to every addressed register on every refused reconciliation, including the ones the budget exists to avoid making.¶

The per-subject ceiling of Section 8.1 is the stronger of the two channels, because it is a counter several principals share: an operator need not fabricate anything, only decline to reserve enough of it. Section 8.1 requires the reserve to be partitioned per principal for that reason, and the residual is that the size of the reserve is a deployment choice this document does not bound.¶

A deployment concerned with either channel should bound it contractually: the budget, its interval and the audit right over the counter are all declared in the Bilateral Register Agreements, and an Audit Identity under Section 5.20 can be given the counter state directly. That is an out-of-band remedy and it is stated as one.¶

8.3. Pattern-Library Integrity

The Adversarial Pre-Transmission Test gates onward transmission. The Pattern Library MUST be bound to a Pattern-Library Commitment Hash. Any modification to the Pattern Library MUST produce a new Pattern-Library Version Identifier, and the Adversarial Pre-Transmission Test MUST be re-executed against the new library before the change takes effect.¶

8.4. Agent Impersonation and Friend-or-Foe Integrity

The Agent Friend-or-Foe Determination is the mechanism by which ARP resists reconciliation initiated by an agent impersonating a principal. The determination MUST default to ENEMY: absence of a verifiable identity, an expired or revoked signature-agent key, a failed HTTP Message Signature [RFC9421] verification, or a Verified Principal Credential that does not validate MUST all yield an ENEMY classification. The server MUST NOT infer friendliness from network origin, User-Agent string, or any self-asserted identifier, as these are trivially forgeable. Where an ENEMY requester is permitted for advisory reconciliation, the resulting Reconciliation Output MUST NOT carry a decisive verdict binding, and the Settlement-Layer Ledger entry MUST record the requester-binding class the gate determined -- agent-unverified where no verifiable identity was presented, or agent-key-verified where a key verified and the asserted principal was not corroborated -- so that downstream reliance is aware no accountable principal was established and can still tell the two apart.¶

8.5. Bilateral-Register-Agreement Drift

Each Bilateral Register Agreement carries an Agreement Hash. Each Partial Attestation includes a reference to the Agreement Hash under which it was issued. Agreement drift is detectable by comparison of agreement-hash references across Partial-Attestation batches. Reconciliation MUST be suspended for an addressed register whose Agreement Hash deviates from the hash committed at the start of a reconciliation event. A suspension under this section ends when the two parties have agreed a new Agreement Hash under Section 5.23.3 and the reconciliation server holds it as the hash it commits at the start of the next reconciliation event, from which event the register is addressable again. A suspension arising instead from the irreconcilable head statements of Section 5.18 ends only when the Register Operator that refused further projections states, under the read key of item 22 of Section 5.23.1, that the discrepancy is resolved. No other event ends either, and a deployment MUST NOT treat the passage of time as ending one.¶

8.6. Replay Defence

Each Partial Attestation MUST carry a Freshness Timestamp. The reconciliation server MUST verify the Freshness Timestamp against a freshness window declared in the Bilateral Register Agreement. The window is measured backward from the instant the reconciliation server received the Partial Attestation. An attestation is fresh where its Freshness Timestamp is no earlier than that instant less the declared window and no later than 60 seconds after it, and a Freshness Timestamp further in the future MUST be treated as stale. A window with no stated reference instant and no stated direction is a test two implementations apply differently to the same attestation, and the register cannot tell which one it will be held to. This document states the reference instant and direction for the witness observation window of Section 5.23.2.4 and did not state them here. Stale Partial Attestations MUST be rejected, and the rejection MUST be recorded in the Reconciliation Output under Section 5.11 with the Non-Answer Reason attestation-stale and a freshness-stale divergence axis attributed to that register. A signed agent request under [RFC9421] MUST additionally carry a nonce and created/expires parameter set that Section 7.4.1 requires, so that a captured signed request cannot be replayed to initiate a fresh reconciliation.¶

8.7. The Clocks a Response Freshness Check Is Decided Across

Section 7.4.3 bounds the response-time of a read response in both directions against the reader's receipt of it, because the two values are produced on two clocks nothing in this document synchronises. The backward bound is the declared tolerance, floored and capped in item 26 of Section 5.23.1; the forward bound is a fixed sixty seconds. A deployment applying the tolerance as a one-sided test admits a response stamped ahead of the reader's clock, and a server whose clock runs fast is then indistinguishable from one stamping ahead deliberately, which is the case the forward bound exists to separate. A deployment declaring a tolerance below the transit and clock disagreement between the two parties rejects every honest response, which is why item 26 carries a floor as well as a ceiling.¶

Section 8.6 bounds the reconciliation server against the register's clock and the created parameter of Section 7.4.1 bounds the server against the requester's. Both run toward the server; this is the return direction, and it is the one earlier revisions left unstated. All three bound a party against another party's clock over a message it has just received, all three differ in their backward bounds -- a declared window in Section 8.6, three hundred seconds in Section 7.4.1, a declared tolerance here -- and all three fix the forward bound at sixty seconds, that being the direction in which none of them has anything but the other party's word.¶

The witness observation window of Section 5.23.2.4 bounds a fourth pair of clocks, the witness's against the reconciliation server's, over an artefact published once per interval rather than over a message in flight. Its backward bound is sixty seconds and its forward bound is the greater of sixty seconds and twice the notarisation interval, so sixty seconds is the floor in both directions here too and the interval only ever widens the window.¶

8.8. Where Head-Consistency Evidence Comes From

Section 5.23.2.4 requires Head Consistency Statements from the witnesses' own origins, and requires the linkage chain between two heads from the same origins under Section 5.23.2.3. The two are one requirement about one property. A relying party that has only the first has not satisfied the second branch at all, and holds evidence under the first branch alone, which reaches exactly the head a response names and no head above it.¶

A Statement obtained from the party it is evidence about is that party's own selection, countersigned. A linkage chain obtained from that party is that party's chain, and the reason is stronger than selection: a relying party cannot recompute any value in a linkage array, because a Signing Input Digest is taken over a Sig_structure and a Self-Entry Hash over the entry array, and the array carries neither preimage. Every test the chain condition performs is therefore an equality between two values the same party supplied, which is not evidence about that party. Anchoring the ends does not repair it: the lower anchor is the response's own claim, and the upper anchor is a Self-Entry Hash, which is not a position the chain reads. Section 5.23.2.4 sets out that arithmetic in full.¶

The operational consequences follow from Section 5.23.2.4 and Section 5.23.2.3 and are gathered rather than restated here. A witness whose origin is unreachable contributes nothing. A witness whose Segment series does not reach the head its Statement covers contributes nothing to the second branch, though its Statement still serves the first, where it covers the head a response names exactly. A witness that has equivocated between two Segments contributes nothing at all. And the property the Segments deliver is append-only rather than absolute, for the reason Section 5.23.2.4 sets out: a witness records what the service served it, so the assurance is that an interval a witness has covered cannot afterwards be rewritten, and its strength in any deployment is the diversity of the Witness Set and the frequency of observation.¶

8.9. Post-Quantum Migration

The Cryptographic-Primitive-Upgrade Path is the mechanism by which ARP deployments migrate to post-quantum primitives. ML-KEM-1024 [FIPS203] is RECOMMENDED for the claim-encryption primitive class. ML-DSA-65 [FIPS204] is RECOMMENDED for the partial-attestation-signature and sealing-signature primitive classes. Implementations MUST declare their chosen post-quantum primitives in the Bilateral Register Agreement.¶

8.10. Side-Channel Considerations

The disclosure model as a whole, and the residual risks this document accepts, are set out in Section 9.¶

Per-register projection narrowing is observable to the addressed register through the Projected Predicate. Implementations MUST NOT use narrowing patterns to fingerprint individual subjects. The Predicate Taxonomy SHOULD be designed such that the set of permitted narrowings is small enough that narrowing observation does not materially weaken subject privacy.¶

8.11. Signature Malleability and Artefact Identity

A digest taken over a signed artefact as served identifies that artefact only where the signature has one valid encoding, and not every primitive this document admits has that property.¶

For ECDSA, a signature (r, s) and the signature (r, n - s), where n is the order of the curve's base point, both verify against the same key over the same message. No specification prohibits it: Section 4.1.4 of SEC1 v2.0 and Section 6.4.2 of FIPS 186-5 range-check r and s only, and Section 2.1 of [RFC9053] constrains neither. The substitution follows from the verification equation and falls outside every check any of the three imposes. No specification is violated and nothing is forged: the signing authority is identical in both encodings, and a party holding no key can produce the second from the first while it is in transit. Measured over two hundred randomly generated P-256 keys and ES256 signatures, two hundred substitutions verified and two hundred changed the enveloped bytes.¶

EdDSA is not exposed to this substitution. Section 8.4 of [RFC8032] puts the check that the decoded S is less than l inside verification, so an attacker holding an Ed25519 or Ed448 signature cannot derive a second byte-string that verifies over the same message under the same key. That is a non-malleability property and not a claim that only one byte-string can ever verify: Section 5.1.7 of [RFC8032] leaves cofactored and cofactorless verification optional, so conforming implementations can differ at the margin. A deployment that declares only EdDSA signature primitives under item 2 of Section 5.23.1 is therefore not reachable by this. Nothing in this document requires that, and a deployment declaring an ECDSA primitive is conforming, so the constructions and not the primitive choice are where this is addressed.¶

Every digest in this document that identifies or chains a signed artefact is accordingly a Signing Input Digest, or has its embedded signatures replaced by one. Those are the Prior-Entry Hash of Section 5.18, the Post-Seal Evaluation Record Hash of Section 5.17, the Merkle leaf of Section 5.10, the authority-reference digest of Appendix D in its tagged-transparency form, the Reconciliation Hash of Section 4, and -- reached through the Reconciliation Hash rather than named beside it -- the authorising operator's signature in the Override Record of Section 5.3.¶

The sixth was found after the first five had been repaired, and the way it was missed is worth stating rather than quietly corrected. The first sweep looked for digests taken over signed artefacts, found the Reconciliation Hash embedded a register signature, and repaired that. The Override Record is a signature made by a third party -- the authorising operator, deliberately not the server, under Section 5.3 -- travelling to the server over a channel the server does not control, and sitting in a field the Reconciliation Hash preimage carries. It failed no test that was applied to it; no test was applied to it.¶

An implementation MUST therefore apply the rule of Section 4 over the class rather than over the list above: in any preimage this document defines, every signature made by a party other than the party computing the digest is replaced by its Signing Input Digest. A specification that enumerates the carriers is correct until someone adds a field, and correctness that expires on the next revision is not the property this section exists to establish. The Sig_structure excludes the signature by construction, which is why this is total where a low-S canonicalisation rule is partial -- low-S removes one encoding from a set with more than one member, while the signing input has one value for one signing act however many encodings of the signature exist.¶

The Reconciliation Hash is the one worth naming separately, because excluding the Sealing Signature is what an earlier revision did and it is not sufficient. A Reconciliation Output embeds a register signature in each Query Binding Record and in each Non-Answer Statement of Section 5.14, so its preimage carried a signature after the sealing one was excluded. The Reconciliation Hash is a field of every Settlement-Layer Ledger entry, and therefore inside the Entry Signature payload and inside the Prior-Entry Hash, so leaving it exposed would have reintroduced at one remove exactly what fixing the Prior-Entry Hash removed. The Self-Entry Hash of Section 5.18 nulls the signature position and was already outside it.¶

The consequence of getting this wrong is not a forgery and is easy to misdiagnose as one. A reader served a substituted entry computes a Prior-Entry Hash that does not match the following entry's, and concludes the chain is broken when the operator equivocated about nothing. Under Section 5.9.1 a substituted Partial Attestation makes a verifier refuse a valid inclusion proof for the same reason. Both are failures of verification rather than of authenticity, and a deployment that reports them as detected tampering will be reporting something that did not happen.¶

8.12. Artefact Identity Across a Change of Signature Algorithm

Section 8.11 establishes that a digest over a signed artefact as served identifies that artefact only where the signature has one valid encoding, and it names EdDSA as the primitive not reachable by the substitution. That exemption is real, and it is temporary. A deployment planning a migration to post-quantum signatures should know which of those two facts it is relying on.¶

The substitution asks what a party holding no key can do to an artefact in transit. A registration protocol has to answer a narrower question first, and one that does not involve an adversary at all: how many valid enveloped byte-strings exist over one signing input when the same signer signs the same input more than once. Measured over two hundred ordinary signing operations per primitive, one key and one signing input each, with every reported value recovered by decoding the served envelope rather than reusing the locals that were signed:¶

Three consequences follow, and the third is not addressed by any document this one is aware of.¶

The Signing Input Digest is stable on every primitive measured, including those whose envelopes are all distinct. This is the property Section 4 already relies on, and the table establishes that it does not depend on the primitive. A construction bound to the signing input survives a change of algorithm; a construction bound to the enveloped bytes does not.¶

The enveloped byte-string is a stable identifier on Ed25519 because of [RFC8032], not because of anything in COSE or in this document. Section 5.1.6 of [RFC8032] derives the per-signature nonce from a hash of the private key prefix and the message, so one key over one message yields exactly one signature. That is a property of one primitive. A deployment that declared only EdDSA under item 2 of Section 5.23.1 and inferred from Section 8.11 that its enveloped digests are stable has inferred correctly, and the inference expires the moment a second signature leg is added. A parallel composition of Ed25519 with ML-DSA-65 over one signing input produced two hundred distinct byte-strings from two hundred signing operations, while the Ed25519 leg alone produced one. Composition does not preserve the determinism of its most deterministic member. It cannot: the composed artefact is unique whenever any member is.¶

Two conforming ML-DSA-65 signers disagree about whether the enveloped byte-string is stable, and the artefact does not record which one produced it. [FIPS204] specifies both hedged and deterministic signing. Both produce signatures that verify against the same public key, and [I-D.connolly-cfrg-ml-dsa-security-considerations] recommends hedged signing as the safer default in all environments, on fault-injection grounds that this document does not dispute and does not attempt to weigh against anything here. The consequence for artefact identity is unremarked rather than contested: the recommended mode is the mode under which one signing input has an unbounded family of valid envelopes, the selection between the two modes appears nowhere in the protected header or anywhere else in the signed object, and a relying party holding one envelope therefore cannot determine whether a second envelope over the same input would be the same bytes. A registration protocol that identifies an entry by its enveloped digest is, under ML-DSA, identifying something whose stability is decided by a signer-side flag it cannot observe.¶

A low-S canonicalisation rule does not reach any of this, and its reach shrinks rather than holds. Section 8.11 states why it is partial for ECDSA: it removes one encoding from a set with more than one member. Past the classical boundary it is not partial but inapplicable, because ML-DSA signatures carry no s value to canonicalise. A deployment defending enveloped-digest identity by mandating low-S is defended for exactly as long as it signs with ECDSA.¶

An implementation MUST NOT treat the digest of an enveloped signed artefact as an identifier for the claim the artefact carries, and MUST use the Signing Input Digest of Section 4 for that purpose, in any construction this document defines. Where a Reconciliation Agreement declares a signature primitive under item 2 of Section 5.23.1, it MUST additionally declare, for any primitive admitting more than one signing mode, which mode the signer operates. That declaration is a statement about a signer and not about an artefact, and a relying party that requires the distinction has no other place to obtain it.¶

8.13. Declared Trade-offs

Several properties this document would like to hold cannot hold together. Where that is so, the document chooses, and this section is the list of the choices in one place, so that a reader can find what was given up without reading for it.¶

The discipline is worth stating on its own. A specification that wants two incompatible properties has three options: claim both and be wrong somewhere a reader has to find; weaken both until the conflict disappears and deliver neither; or take the conflict as irreducible, choose, and say where the loss went. The third is the only one that leaves a reader able to reason about a deployment. What makes it work is that the loss is located rather than distributed: a reader who knows exactly which property was surrendered, and where, can compensate for it, and a reader told that everything holds cannot.¶

Two things follow from having written this table that were not obvious before writing it.¶

The first is that most of the losses are stated limits rather than open defects, and the difference is whether a reader can compensate. A limit a reader knows about is an input to that reader's decision; a limit it does not know about is a false belief. This document has repeatedly found that its own worst errors were sentences claiming a property it did not have, rather than missing properties honestly described, and the table is the form that makes the distinction hard to lose.¶

The second is that a row can be retired by invention. Two rows that stood in earlier revisions no longer do: the falsifiability of a sweep against its operator, which was traded away and has been bought back by anchoring the Policy Parameters Document; and the verifiability of the sweep counts, which was conceded as an assertion and is now an accounting identity against the Ledger. A trade-off is a statement about the mechanisms available at the time it was made, not a law, and a list of them is also a list of what to attack next.¶

9.1. Against the threat model of RFC 6973

Taking the threats of Section 5 of [RFC6973] in turn, and stating the residual rather than the mitigation where there is one.¶

Surveillance and correlation. Every digest that could otherwise correlate a subject across deployments is blinded: a Claim Hash cannot be recomputed outside the deployment that produced it and equality of Claim Hashes across deployments is not a comparison that can be made at all. Within a deployment, correlation is by design -- the Ledger index is a stable function of the claim, which is what makes retroactive re-evaluation possible -- so a Ledger reader entitled to nothing else still learns that some subject was reconciled repeatedly, and how often. That residual is inherent in an append-only index and is not closed here.¶

Identification. The Ledger carries no Subject Identifier and no Subject Reference. Those travel to the addressed registers, which is unavoidable in a protocol that asks a register about a subject, and into the Reconciliation Output, which is confidential to its Audience Set.¶

Secondary use and disclosure. A reconciliation server MUST NOT write a Subject Identifier, a Subject Reference, an Applied-Parameter Set or any register-record field to the Settlement-Layer Ledger, and MUST NOT include one in any artefact it notarises into a Transparency Service. Notarisation under Section 7.5 places the sealed Output into an append-only log operated by a third party, and a sealed Output carries Subject References inside its Query Binding Records. Notarisation of an Output is a MAY and MUST NOT be performed where the deployment's subjects have not been accounted for in that disclosure. The Ledger Head Statement, the Evaluation Sweep Statements and the Policy Parameters Document carry no subject data and are the artefacts this document requires to be notarised.¶

Exclusion. The subject is not told, cannot object and cannot learn that it was reconciled. This is stated above as a deliberate property and it is the sharpest privacy cost the protocol imposes. It is restated here because [RFC6973] names exclusion as a threat in its own right and a document that lists its mitigations and passes over the one threat it does not mitigate is reporting selectively.¶

9.2. Erasure and rectification against an append-only record

A jurisdiction in which a subject may require erasure or rectification of personal data is in direct tension with a Ledger this document requires to be append-only and with a Transparency Service it requires to be outside the operator's control. That tension cannot be resolved by a protocol mechanism, and this document does not claim to resolve it. What it can do is bound what has to be erased, and that is a design obligation rather than a remark:¶

• No personal data is written to the Ledger, per the rule above. What the Ledger carries about a reconciliation is digests, register Authority Origins, verdict values and structural metadata. An erasure obligation over the subject's data therefore falls on the Reconciliation Output and the register correspondence, both of which are held by the deployment and both of which have a retention period.¶

• A retracted or rectified verdict is expressed by supersession and not by deletion. Section 5.21 appends a continuation-supersession entry and Section 5.19.1 notifies the affected regulators. The superseded Output remains identified by its Reconciliation Hash and its content may be destroyed at the end of its retention period without breaking any chain, because no chain hashes the Output's content: the Ledger commits to the Reconciliation Hash, and a digest whose preimage no longer exists is still a valid chain element. This is the property that makes erasure implementable at all, and an implementation MUST NOT introduce any construction that hashes Output content into the chain.¶

• A deployment that has notarised an Output cannot erase it, because the Transparency Service is required not to be under the operator's control. That is the reason notarisation of an Output is optional and is now prohibited where the disclosure has not been accounted for.¶

A deployment operating under an erasure regime should treat the retention period of Section 5.15.3 as the erasure horizon for Output content, and should not notarise Outputs. This document states that as guidance and not as a requirement, because the obligation arises outside it and its shape differs by jurisdiction. What is normative is the constraint that makes any of it possible: personal data does not enter the append-only record, and nothing in the chain depends on the continued existence of the content that could be erased.¶

10.1. Well-Known URIs

Eight entries are requested in the Well-Known URIs registry of [RFC8615]. For each, the change controller is the IETF, the status is permanent, and the specification document is this document.¶

10.2. Media types

Fourteen media types are requested, registered under the template of [RFC6838]. For each: the type name is application; there are no required and no optional parameters; the encoding considerations are binary, save for the +json type, which is 8-bit UTF-8 text; the security and interoperability considerations are those of this document; the published specification is this document; the intended usage is COMMON; the change controller is the IETF; the applications that use the type are ARP reconciliation servers, registers, regulators and relying parties; there are no restrictions on usage; the author is the author of this document and the contact address is the one on its front page; there are no deprecated alias names, no magic numbers and no customary file extensions; and fragment identifier considerations are those of the structured syntax suffix where one applies -- Section 3.1 of [RFC6839] for +json -- and are otherwise none, no fragment identifier syntax being defined for the +cbor and +cose forms.¶

12.1. Normative References

[I-D.ietf-scitt-scrapi]

Birkholz, H., Geater, J., and A. Delignat-Lavaud, "Supply Chain Integrity, Transparency, and Trust (SCITT) Reference APIs", Work in Progress, Internet-Draft, draft-ietf-scitt-scrapi-11, 26 June 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-scitt-scrapi-11>.

[RFC2104]

Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, <https://www.rfc-editor.org/rfc/rfc2104>.

[RFC2119]

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

[RFC3339]

Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/rfc/rfc3339>.

[RFC3986]

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

[RFC6234]

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

[RFC6454]

Barth, A., "The Web Origin Concept", RFC 6454, DOI 10.17487/RFC6454, December 2011, <https://www.rfc-editor.org/rfc/rfc6454>.

[RFC6838]

Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <https://www.rfc-editor.org/rfc/rfc6838>.

[RFC6839]

Hansen, T. and A. Melnikov, "Additional Media Type Structured Syntax Suffixes", RFC 6839, DOI 10.17487/RFC6839, January 2013, <https://www.rfc-editor.org/rfc/rfc6839>.

[RFC7638]

Jones, M. and N. Sakimura, "JSON Web Key (JWK) Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 2015, <https://www.rfc-editor.org/rfc/rfc7638>.

[RFC8174]

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

[RFC8615]

Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, <https://www.rfc-editor.org/rfc/rfc8615>.

[RFC8785]

Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, <https://www.rfc-editor.org/rfc/rfc8785>.

[RFC8949]

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

[RFC9052]

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

[RFC9053]

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

[RFC9334]

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

[RFC9421]

Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP Message Signatures", RFC 9421, DOI 10.17487/RFC9421, February 2024, <https://www.rfc-editor.org/rfc/rfc9421>.

[RFC9530]

Polli, R. and L. Pardue, "Digest Fields", RFC 9530, DOI 10.17487/RFC9530, February 2024, <https://www.rfc-editor.org/rfc/rfc9530>.

[RFC9942]

Steele, O., Birkholz, H., Delignat-Lavaud, A., and C. Fournet, "CBOR Object Signing and Encryption (COSE) Receipts", RFC 9942, DOI 10.17487/RFC9942, June 2026, <https://www.rfc-editor.org/rfc/rfc9942>.

[RFC9943]

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

[UAX15]

The Unicode Consortium, "Unicode Standard Annex #15: Unicode Normalization Forms", 2025, <https://www.unicode.org/reports/tr15/>.

12.2. Informative References

[BODS]

Open Ownership, "Beneficial Ownership Data Standard", 2024, <https://standard.openownership.org/>.

[EU-CFSP]

European Union, "EU Consolidated Financial Sanctions List", 2026, <https://webgate.ec.europa.eu/fsd/fsf>.

[FIPS203]

"Module-Lattice-Based Key-Encapsulation Mechanism Standard", NIST FIPS 203, 2024, <https://csrc.nist.gov/pubs/fips/203/final>.

[FIPS204]

"Module-Lattice-Based Digital Signature Standard", NIST FIPS 204, 2024, <https://csrc.nist.gov/pubs/fips/204/final>.

[I-D.connolly-cfrg-ml-dsa-security-considerations]

Connolly, D., "Security Considerations for ML-DSA", Work in Progress, Internet-Draft, draft-connolly-cfrg-ml-dsa-security-considerations-02, 19 March 2026, <https://datatracker.ietf.org/doc/html/draft-connolly-cfrg-ml-dsa-security-considerations-02>.

[I-D.hillier-coverage-attestation]

Hillier, J., "The Coverage Attestation Profile (CAP-1)", Work in Progress, Internet-Draft, draft-hillier-coverage-attestation-00, 20 August 2026, <https://datatracker.ietf.org/doc/html/draft-hillier-coverage-attestation-00>.

[I-D.meunier-webbotauth-httpsig-directory]

Meunier, T. and S. Major, "HTTP Message Signatures Directory", Work in Progress, Internet-Draft, draft-meunier-webbotauth-httpsig-directory-00, 26 June 2026, <https://datatracker.ietf.org/doc/html/draft-meunier-webbotauth-httpsig-directory-00>.

[I-D.meunier-webbotauth-httpsig-protocol]

Meunier, T. and S. Major, "HTTP Message Signatures for automated traffic", Work in Progress, Internet-Draft, draft-meunier-webbotauth-httpsig-protocol-02, 18 August 2026, <https://datatracker.ietf.org/doc/html/draft-meunier-webbotauth-httpsig-protocol-02>.

[I-D.meunier-webbotauth-registry]

Guerreiro, M., Kirazci, U., and T. Meunier, "Registry and Signature Agent card for Web bot auth", Work in Progress, Internet-Draft, draft-meunier-webbotauth-registry-03, 26 June 2026, <https://datatracker.ietf.org/doc/html/draft-meunier-webbotauth-registry-03>.

[I-D.mih-sato-agent-accountability-composition]

Mih, S., Sato, Schrock, I., Bu, S., and A. Sokolov, "Agent Accountability: Composition and Conformance", Work in Progress, Internet-Draft, draft-mih-sato-agent-accountability-composition-01, 16 August 2026, <https://datatracker.ietf.org/doc/html/draft-mih-sato-agent-accountability-composition-01>.

[I-D.mih-sokolov-scitt-payload-binding]

Mih, S. and A. Sokolov, "Canonical Payload Binding: A Signed Statement Construction Profile", Work in Progress, Internet-Draft, draft-mih-sokolov-scitt-payload-binding-03, 5 September 2026, <https://datatracker.ietf.org/doc/html/draft-mih-sokolov-scitt-payload-binding-03>.

[I-D.schrock-canonical-action-identifier]

Schrock, I., "The Canonical Action Identifier (CAID)", Work in Progress, Internet-Draft, draft-schrock-canonical-action-identifier-02, 6 August 2026, <https://datatracker.ietf.org/doc/html/draft-schrock-canonical-action-identifier-02>.

[OFAC-SDN]

United States Department of the Treasury, Office of Foreign Assets Control, "Specially Designated Nationals and Blocked Persons List", 2026, <https://sanctionslist.ofac.treas.gov/Home/SdnList>.

[RFC6350]

Perreault, S., "vCard Format Specification", RFC 6350, DOI 10.17487/RFC6350, August 2011, <https://www.rfc-editor.org/rfc/rfc6350>.

[RFC6962]

Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, <https://www.rfc-editor.org/rfc/rfc6962>.

[RFC6973]

Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/rfc/rfc6973>.

[RFC8032]

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

[RFC8067]

Leiba, B., "Updating When Standards Track Documents May Refer Normatively to Documents at a Lower Level", BCP 97, RFC 8067, DOI 10.17487/RFC8067, January 2017, <https://www.rfc-editor.org/rfc/rfc8067>.

[RFC9162]

Laurie, B., Messeri, E., and R. Stradling, "Certificate Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162, December 2021, <https://www.rfc-editor.org/rfc/rfc9162>.

[UNCEFACT]

United Nations Economic Commission for Europe, "UN/CEFACT Core Component Library and XML Schemas", 2024, <https://unece.org/trade/uncefact>.

[W3C-ORG]

World Wide Web Consortium, "The Organization Ontology", 2014, <https://www.w3.org/TR/vocab-org/>.

[W3C-VC-DM-2.0]

"Verifiable Credentials Data Model 2.0", 2025, <https://www.w3.org/TR/vc-data-model-2.0/>.

[WCO-DM]

World Customs Organization, "WCO Data Model", 2024, <https://www.wcoomd.org/en/topics/facilitation/instrument-and-tools/tools/data-model.aspx>.

A.1. Example: Three-register Sanctions Reconciliation

This example is illustrative and non-normative; register identifiers, values and parties are fictitious, and no bilateral agreement with any named authority is asserted or implied. Suppose a relying party requests reconciliation of the predicate sanctions:any-list-match for subject identifier corp:EXAMPLE:0123456789 against three consolidated sanctions registers.¶

Each Bilateral Register Agreement permits the predicate. The projection function emits identical Per-Register Claim Projections to all three registers. All three return Partial Attestations with verdict no-match.¶

The Aggregation Subsystem operates in Hash-Linkage Aggregation. The Verdict Arithmetic, resolved from policy for the regimes the claim names, is disjunction. The Combined Verdict is no-match.¶

The requester named itself and its compliance department's shared identity in the Audience Set; no addressed register declared an audience constraint, so both are admitted. The reliance interval that policy declares for sanctions: predicates is seven days, so the Reliance Horizon is 2026-05-04T19:47:14Z. The Output is sealed against the current Policy-Version Hash and returned to the requester in the signed read response to the request that commissioned it, over which the requester computes its Reconciliation Hash.¶

The Settlement-Layer Ledger entry comprises:¶

• Entry Sequence Number: 42¶

• Entry Type: reconciliation¶

• Claim Hash: <32 bytes>¶

• Reconciliation Hash: <32 bytes>¶

• Entry Timestamp: 2026-04-27T19:47:15Z¶

• Prior-Entry Hash: <32 bytes>¶

• Policy-Version Hash: <32 bytes>¶

• Addressed-Registers Identifier Set: ["https://register-a.example", "https://register-b.example", "https://register-c.example"]¶

• Aggregation-Method Descriptor: hash-linkage-disjunction¶

• Merkle Root: <32 bytes>¶

• Requester-Binding-Class Descriptor: "human-operator"¶

• Reconciliation Timestamp: 2026-04-27T19:47:14Z¶

• Source-Reconciliation-Output Identifier: CBOR null -- this reconciliation supersedes none¶

• Override Indicator: false¶

• Self-Entry Hash: <32 bytes>¶

• Entry Signature: COSE_Sign1, Sealing-Key Identifier (https://arp.example, example-sealing-2026-01)¶

The one absent field occupies its position as CBOR null, so that the array's length is fixed by the Entry Type and the Self-Entry Hash is taken over a determinate encoding. When the sealed Output is registered with a Transparency Service, the EntryID it returns is not written into entry 42, which is already signed; it is appended as a later entry:¶

• Entry Sequence Number: 57¶

• Entry Type: continuation-notarisation¶

• Claim Hash: <the same 32 bytes as entry 42>¶

• Reconciliation Hash: <the same 32 bytes as entry 42>¶

• Entry Timestamp: 2026-04-27T19:52:03Z¶

• Prior-Entry Hash: <32 bytes>¶

• Transparency Service Identifier: https://ts.example/¶

• the notarisation outcome: ["entry-id", <the identifier that service returned>]¶

• Self-Entry Hash: <32 bytes>¶

• Entry Signature: COSE_Sign1, Sealing-Key Identifier (https://arp.example, example-sealing-2026-01)¶

Entry 57 carries no Policy-Version Hash and no Addressed-Registers Identifier Set; entry 42 records those and the shared Reconciliation Hash binds them. No register record content is stored on the Ledger in either entry. Had the registration neither completed nor been refused within the polling bound, entry 57 would not exist: the outcome would be a Post-Seal Evaluation Record qualified notarisation-incomplete, pointed to by a continuation-post-seal-record entry, and a later completion -- were the server able to learn of one, which Section 5.18 records as an open question -- would be appended as a continuation-notarisation entry later in the sequence. Had the service instead refused registration terminally, the second field would read ["refused", 400].¶

On 2026-05-06, two days past the Reliance Horizon, the compliance department wishes to rely on the verdict again. Being an Audience Member it presents a signed GET /arp/continuations/{reconciliation-hash}. The server answers 200 with a signed response carrying the ledger head it was served against and, as its result, entry 57 alone. That the result contains no continuation-supersession entry is a signed statement by the server that as of that head there was none -- not merely the absence of one -- and the department retains it. Had it not been an Audience Member the same request would have returned 404, which is also what it would have received had the Reconciliation Hash named nothing at all.¶

A.2. Example: Retroactive Re-evaluation

Continuing the illustrative example above: six weeks after that reconciliation, the list register-a.example consults adds the subject as part of a new tranche. That register, on next invocation over the bilateral channel its agreement declares, returns verdict match.¶

The Retroactive Evaluation Subsystem detects the new Source-Data Version the list publisher issued, re-invokes Partial Attestations on the historical reconciliations whose Per-Register Result Set carries a Source-Data Version Identifier from the republished list, identifies the material verdict change, and emits a Sovereign Re-Notification through the Regulator Portal to the regulators whose statutory-regulator-access scope intersects the changed reconciliation.¶

It also emits an Evaluation Sweep Statement recording the trigger source-data-version, the identifier of the list version that triggered it, the policy state applied, the ledger head at the start and end of the sweep, the Examined-Set Root over the Claim Hashes it examined, and the counts examined and materially changed. The compliance department later presents that root and its own Claim Hash to GET /arp/sweeps/{examined-set-root}/inclusion/{claim-hash} and is shown that its reconciliation was in the set the server claims to have examined. Had the server not run the sweep, there would be no Statement covering a list republication whose date is public, and its absence would itself be the finding.¶

The supersession is recorded from both ends. A new Reconciliation Output is sealed against the current Policy-Version Hash and appended as a reconciliation entry whose Source-Reconciliation-Output Identifier is the Reconciliation Hash of the superseded Output. A continuation-supersession entry is then appended against the superseded Output, carrying that Output's Claim Hash and Reconciliation Hash, a Material-Change Indicator of true -- the verdict moved from no-match to match, which is decisive-to-decisive and therefore material -- the Superseding-Reconciliation Hash of the new Output, and the Entry Sequence Number of the entry that records it.¶

The compliance department, an Audience Member of the original Output, presents GET /arp/continuations/{reconciliation-hash} again. This time the signed response carries the continuation-supersession entry. It reads the Superseding-Reconciliation Hash, presents GET /arp/outputs/{superseding-reconciliation-hash}, and is served the new Output -- because a superseding Output inherits the Audience Set of the Output it supersedes, so the party entitled to learn that its verdict changed is entitled to see what it changed to. It verifies the new Sealing Signature, reads the match, and acts.¶

Had the department retained the earlier signed empty response and the server now denied that any supersession existed, the two signed statements by one key would be irreconcilable, which is the point of signing them.¶

A party that is not an Audience Member -- one that was handed the Output by someone who was -- reaches none of this. It may verify the Sealing Signature and read the no-match, which is what makes an Output worth handing on, and it obtains no read, learns of no supersession, and must not treat the verdict as current. Entitlement follows the Audience Set, not the artefact.¶

A.3. Example: Agentic Principal Reconciliation

An autonomous agent requests reconciliation of sanctions:any-list-match over HTTP, signing the request under HTTP Message Signatures [RFC9421] with a key published in a Web Bot Auth signature-agent card. The reconciliation server verifies the signature (Agent Friend-or-Foe Determination: the agent carries a verifiable identity). That establishes the class agent-key-verified -- the key verified and the asserted principal is so far uncorroborated -- and the Agent-IFF policy for the sanctions: class does not admit a decisive verdict at that class.¶

The server therefore first performs an agent:principal-binding-verifiable reconciliation with Subject Identifier set to the agent's key thumbprint and Attested Value set to the asserted principal org:ACME:operator:jdoe, addressing the ACME organisational directory register and the credential-issuer status-list register. Both return match. The Requester-Binding class is raised to agent-verified with accountable principal org:ACME:operator:jdoe, committed to the Policy-Version Hash, and only then is the sanctions reconciliation performed with a decisive verdict binding. Had either identity register returned no-match with an attested Divergence-Axis Field of agent-impersonation-suspected, the agent would have been classified ENEMY -- a contradicted binding is a stronger signal than an absent one -- and the sanctions reconciliation refused or downgraded to advisory per policy.¶

The distinction is not bookkeeping. Under -02 both states were recorded as agent-verified, so a relying party reading the Ledger entry for the first reconciliation could not tell an agent whose principal had been corroborated against two registers from one that had merely signed correctly.¶

A.4. Example: Divergent Agent-Action Reconciliation

This example is illustrative and non-normative. Capsule slots are those of [I-D.mih-sato-agent-accountability-composition]; see Appendix D.¶

An autonomous agent is authorised, by a signed CAN capsule, to read from a named evaluation dataset and to write only to a sandboxed result store. During execution the agent's actual conduct, attested by a WHAT capsule produced by the execution environment, includes an outbound network connection to an external host and a write outside the sandboxed store.¶

A relying party submits both capsules to ARP over the agent: predicate branch with a shared subject digest computed over the action. ARP verifies each capsule's signature, projects the authorised scope from the CAN capsule and the actual scope from the WHAT capsule, and reconciles them. The scopes diverge: the actual conduct exceeds the authorised scope. The Combined Verdict is no-match, and agent-action-scope-divergence is recorded in the Server-Recorded Divergence-Axis Set: it is a relation between two capsules and no single capsule producer can attest it, on the same reasoning that makes source-version-skew server-recorded.¶

Because the Agent-IFF policy for this action class requires a decisive match before the action is treated as authorised, the divergent verdict is available as a refusal at decision time -- the reconciliation surfaces the excess while the action can still be refused, rather than after the consequence. The Reconciliation Output is sealed against the Policy-Version Hash and written to the Settlement-Layer Ledger without claim or register content, with requester-binding class agent-verified -- the agent's asserted principal having been corroborated as in the preceding example -- and no register or capsule content disclosed.¶

D.1. The digest constructions are distinct

A third construction, the Signing Input Digest of Section 4, identifies a signed artefact by what was signed rather than by the envelope carrying it, and is over deterministic CBOR rather than over a JSON serialisation. It is distinct from both of the constructions below and from the Reconciliation Hash, which is over a Reconciliation Output with each embedded register signature replaced by its Signing Input Digest. Substituting any of these four for another produces a value that verifies against nothing.¶

This document defines two digest constructions over a JSON serialisation, for two different purposes, and they are NOT interchangeable:¶

Claim Hash:

SHA-256 over the Canonical Claim serialisation of Section 4 together with the Deployment Blinding Value of Section 5.16. Its purpose is to index a claim in the Settlement-Layer Ledger. It applies Unicode Normalization Form C.¶

subject_digest:

SHA-256 over the [RFC8785] serialisation of an action, per Appendix D. It is a CONTENT digest: it commits to the action object as serialised, and any difference in the serialised bytes yields a different digest except with negligible probability. [RFC8785] does not normalise.¶

An implementation that substitutes one for the other MUST be assumed to produce incorrect correlations. The failure is silent: both constructions return a well-formed 32-octet digest for any input, so a substitution surfaces as a correlation that does not occur, or as two distinct actions correlating to one subject, rather than as an error.¶

Two cases are worse than a mere difference of bytes, because the substitution produces a COLLISION rather than a mismatch. Under the Claim Hash construction, which normalises, an input in Normalization Form D and the same input in Normalization Form C yield the SAME digest; so do U+212B ANGSTROM SIGN and U+00C5 LATIN CAPITAL LETTER A WITH RING ABOVE. Under the subject_digest construction, which does not normalise, all four are distinct. An implementer who reuses the Claim Hash where a subject digest is required will therefore correlate two actions that a conforming implementation keeps apart. Neither case needs measuring: both follow from the two constructions as this document defines them, and either can be checked by computing the two digests over the four inputs named above.¶

Accordingly:¶

• An implementation MUST NOT use the Claim Hash construction where subject_digest is specified, or the reverse.¶

• Where a digest is carried on the wire for correlation, the producer MUST identify the construction used, by an identifier that commits to the declared canonicalisation parameters -- member-sort code unit, normalisation, number rendering, absent-member handling and hash algorithm -- so that a consumer can determine compatibility rather than assume it. Such an identifier MUST NOT commit to facts about a specification that do not affect the serialised bytes, so that two implementations producing identical bytes share an identifier. [I-D.mih-sokolov-scitt-payload-binding] expresses a compatible rule statement-side.¶

• Where the correlation digest is computed over a TYPED action object whose type declares required material fields, the producer MUST validate the object against a pinned definition of that type before emitting a correlation identifier for it, and MUST NOT emit one where validation fails. A digest is well-formed over any object, including one that omits fields the type requires; emitting an identifier in that case mints a join key for an action the identifier does not fully describe, which is the condition a relying party has no way to detect downstream. Validation against a pinned type definition is therefore required before emission.¶

E.1. Since draft-hillier-scitt-arp-03

E.2. Since draft-hillier-scitt-arp-02

This revision answers a review of -02 on the SCITT list. Of its five asks, three are adopted as put, one is adopted in its goal and not in its mechanism, and one is declined for now with a reason.¶

Section 7.4.3 now names the evidence that bounds the empty-result falsifiability condition. -02, and this revision as circulated for comment, said that an empty result is falsifiable to the extent that the reader "independently holds head-consistency evidence" for the served chain, without saying independent of whom. Head evidence obtained from the responding service bounds nothing, because a fork at disjoint sequence numbers is invisible from a single vantage by construction and the vantage is what is in question. The condition now names an observer independent of the responding service and carries a SHOULD on the relying party, with witness countersignature over the head preferred to an independently anchored head digest. The gap is not closed and is not claimed to be; it is bounded by evidence an implementation can be said to hold or not hold. The finding is Walter Hawkins's.¶

Section 7.5 is new and normative. -02 composed with the SCITT Reference APIs permissively -- Reconciliation Outputs MAY be notarised, registration MAY use the APIs -- which is a permission and not a binding: two implementations could both conform to -02 and fail to interoperate against the same Transparency Service. The section now fixes the registration endpoint, the COSE_Sign1 framing and content type, receipt validation, and the asynchronous registration path. The asynchronous case is stated as a requirement because it is the most likely divergence between conforming implementations: a 202 Accepted with polling against 204 No Content is not the same code path as a 201 Created, and an implementer who codes only the latter interoperates with some Transparency Services and not others.¶

The review also asked for a standard retrieval path keyed on the Policy-Version Hash. That is not specified here, because [I-D.ietf-scitt-scrapi] defines retrieval by EntryID and defines no query surface at all; a binding that specified one would specify an endpoint that does not exist. The goal -- preventing policy equivocation over time -- is met instead by requiring the Policy-Version Hash in the protected header of the Signed Statement, so that it is covered by the Receipt. A relying party therefore establishes the policy version by verification rather than by lookup, which is the stronger property: an index can be wrong, or can present different results to different relying parties, and a signed protected header cannot.¶

Section 5.5 is new. -02 specified the controlled projection function over an abstract Predicate Taxonomy without saying how an implementer determines what a given register can answer. Four profiles are defined -- [BODS], [RFC6350] with [W3C-ORG], [UNCEFACT] with [WCO-DM], and consolidated sanctions list formats. Profiles constrain predicate expression only and are prohibited from introducing any means of transporting register records, which would defeat the property the protocol exists to provide.¶

Section 5.6 is new, and is the substantive addition rather than the largest one. A designation verdict against a consolidated sanctions list is meaningful only relative to the state of that list, and consolidated lists are republished on a cadence and distributed as deltas. -02 could therefore record that a historical Combined Verdict had changed but could not attribute the change: a verdict that flipped because the policy changed and one that flipped because the list changed were indistinguishable, and Sovereign Re-Notification reported both as policy changes. Partial Attestations now carry a Source-Data Version Identifier under signature, Retroactive Evaluation must distinguish the two causes, and where it cannot it must report attribution-indeterminate rather than attribute the change to policy. A list-state identifier is a property of a published corpus and not a register record, so this does not weaken minimum disclosure.¶

Three structural gaps predating this revision are closed, because the new material could not be made testable without them. Section 5.14 enumerates the Reconciliation Output, which no earlier revision did although both the Partial Attestation and the Ledger entry were enumerated; Reconciliation Hash and Combined Verdict are now defined in Section 4, the former having been used inside the bit-for-bit determinism requirement while undefined; and the Server-Recorded Divergence-Axis Set is a set, since a reconciliation may be qualified on more than one axis and a single-valued encoding would force a silent choice.¶

Section 5.12 is new. Where a narrowing means a register's answer does not bear on the claim as asked, that register's contribution is re-typed before aggregation rather than the Combined Verdict being overridden after it, so the Verdict Arithmetic resolved under Section 5.13 is never displaced. A match found at any depth still establishes an existential closure predicate and is not re-typed.¶

Section 5.17 is new. Notarisation outcomes and retroactive attribution failures arise after a Reconciliation Output is sealed and so can be carried neither in a Partial Attestation nor in the Output; they are Post-Seal Evaluation Qualifiers recorded in a separate signed record referencing the Reconciliation Hash, and are expressly not Divergence Axes.¶

New Divergence Axis values: register-threshold-divergence, declared-not-determined and source-version-skew. New COSE header parameter arp-source-data-version, carrying a set so that a register consulting several lists can denote the state of each. arp-bilateral-agreement-hash now always carries a sorted array, of one member on a Partial Attestation and one per addressed register on a Sealing Signature, so that a decoder never has to infer the type from context. New IANA registries for Register Data-Format Profile identifiers and for Post-Seal Evaluation Qualifiers. -03 adds registries for Ledger Entry Types, Override Grounds, Retroactive Evaluation Triggers and Aggregation-Method Descriptors. [I-D.ietf-scitt-scrapi] moves from informative to normative, because Section 7.5 imposes requirements that cannot be met without it.¶

A role-by-role walkthrough of the whole pipeline -- requester, agent, reconciliation server, register operator, relying party, Transparency Service, regulator, retroactive subsystem and IANA expert -- was run against this revision and found a further class of defect that no earlier review had reached: requirements addressed to an actor that does not hold the inputs they name. Those are closed here, and most of them predate -02.¶

Section 5.4 now enumerates the Per-Register Claim Projection. It is the only structure a sovereign register receives and it was the sole major structure in the protocol without a field list, which made the register role unimplementable. The register echoes the Policy-Version Hash rather than computing it, and the server MUST now send one Policy-Version Hash to every addressed register and verify each echo -- without which the per-register signatures over it, the only independent corroboration the protocol has, were discarded at aggregation.¶

Section 7.5.3 is new. -02 and the earlier -03 text told a relying party to verify a Sealing Signature whose key it had no way to obtain: it holds hashes of bilateral agreements it is not party to. Sealing keys are now published at a well-known location on a declared authority origin, mirroring how [I-D.ietf-scitt-scrapi] treats Transparency Service keys.¶

Section 5.13 is new. Every operator is now given its result for every combination of contribution values, and whether it admits partial-match, on which Section 5.12 turns. -02 delegated combination to an operator it named but never defined, so two conforming implementations could produce different Combined Verdicts from identical inputs while the determinism requirement demanded they not.¶

Section 5.11 is new. A register may fail to answer in eleven distinct ways and no earlier revision defined an outcome for any of them; dropping the register silently produces exactly the addressed-register-cherry-picking the adversarial test exists to detect. A reconciliation with any non-answering register can no longer reach a decisive Combined Verdict.¶

The Reconciliation Output gains the Claim Hash, a timestamp, the Verdict Arithmetic, the Sealing-Key Identifier, per-register attested and effective verdicts with the re-typing ground, per-register echoed Policy-Version Hashes, and register attribution on the server-recorded divergence axes. Without the Claim Hash a relying party received a verdict with nothing to attribute it to, and the retroactive subsystem had no key to select on although the Claim Hash was already declared its key. The Settlement-Layer Ledger gains the Claim Hash and now exposes READ as well as APPEND -- the Regulator Portal, retroactive evaluation and the chain-invariant check all require reads that "only APPEND" forbade. Ledger entries are now signed, because prior-entry hashes prove that nothing was removed from a chain and not that only one chain exists.¶

The Ledger now carries two kinds of entry under an Entry Type discriminator, and each type's fields are enumerated. Facts arising after an Output is sealed -- the outcome of notarisation, a Post-Seal Evaluation Record, a supersession -- are recorded as Continuation entries appended against the Reconciliation Hash they concern. An earlier revision of this text described Continuation entries without giving them a form: they carried fields the entry list did not admit, supplied none of the fields it made mandatory, and nothing distinguished one kind from another. Section 5.17 correspondingly no longer requires a Post-Seal Evaluation Record Hash to be appended to an already-signed entry, which the Ledger's absent UPDATE made impossible. Supersession is now recorded from both ends, the superseding entry naming what it replaced and a Continuation entry naming what replaced it, because neither pointer is reachable from the other's starting point. A retriever of a Post-Seal Evaluation Record must now check the retrieved bytes against the hash carried beside them, and that hash's construction is defined. A supersession entry carries the superseding entry's sequence number rather than a retrieval URI: obliging every reader to dereference an operator-chosen URI before it could check anything would have been a forced fetch, a de-blinding oracle and a covert channel no constraint on the URI's content could close.¶

The Self-Entry Hash is defined, and is taken after the type-specific fields so that it covers them. The Prior-Entry Hash is now taken over the whole preceding entry including its Entry Signature. Chaining Self-Entry Hash to Self-Entry Hash would have left every signature outside the structure that detects tampering, which is a poor place for the field this document relies on to make a second chain attributable. Entry encoding and field order are stated, because the Self-Entry Hash is taken over them and a CBOR map would have been re-sorted by key.¶

E.3. Since draft-hillier-scitt-arp-01

This revision closes canonicalisation ambiguities identified by running an implementation of -01 against two published conformance corpora -- the EMILIA clean-room frozen-v1 agent-action corpus and the Noa AI-agent-receipt corpus -- states the role of the Appendix D subject digest explicitly, and corrects a number of requirements that were unsatisfiable, untestable or out of scope as written in -01. The harness and its machine-readable results were posted to the SCITT mailing list.¶

• [RFC8785] is now a NORMATIVE reference. -01 named JCS in Appendix D without identifying which JCS; the string "8785" did not occur in -01 at all. Agreement with a deployed profile depended on both parties having independently selected [RFC8785]. It is now an obligation rather than a coincidence.¶

• The Canonical Claim in Section 4 now pins its member-sort code unit to UTF-16, per Section 3.2.3 of [RFC8785]. -01 said "lexicographic sorting of object keys", which does not determine the ordering of member names outside the Basic Multilingual Plane.¶

• Number rendering now cites Section 3.2.2.3 of [RFC8785]. -01 cited "canonical JSON RFC 8259 number rendering"; RFC 8259 defines no canonical number rendering, and was an informative reference in -01.¶

• "Stripping of undefined values" is replaced by a statement about absent members, JSON having no undefined value to strip.¶

• New Appendix D.1 states that the Claim Hash and subject_digest are distinct constructions that MUST NOT be substituted for one another, and records the two observed COLLISION cases (Normalization Form D against Form C, and U+212B against U+00C5) in which a substitution fails silently rather than visibly.¶

• New Appendix D.1.1 states what subject_digest is and what it is not, which -01 left to be inferred. subject_digest is a content digest: collision-resistant over content, and therefore NOT stable under the variation an action type permits. Measured: five conforming instances of one registered action type, each accepted by that type's reference issuer and differing only in content the type declares OPTIONAL, produced five distinct subject digests. The section now separates the case the construction supports -- capsules over one shared serialisation, which is what Appendix D composes -- from the case it does not, and requires a profile needing the latter to pin its member set or to join on a material identifier the action type declares. It also forbids describing a content digest as a correlation key without saying which case is relied on.¶

• The order of canonicalisation operations in Section 4 is now normative. Normalization Form C is applied BEFORE the member sort. The two do not commute: for an object whose member names are U+0041 U+030A and "B", normalising first and sorting first produce different Claim Hashes. -01 gave the operations as an unordered list.¶

• [I-D.mih-sato-agent-accountability-composition] remains an informative reference. Appendix D composes over the capsule slots it defines and would cite it normatively, but it is an individual draft; making it normative now would create a publication dependency. The same applies to [I-D.mih-sokolov-scitt-payload-binding]. The status of both references will be revisited as those documents progress.¶

• Appendix D.1 requires that a correlation digest carried on the wire identify its construction, and requires that such an identifier not commit to facts which do not affect the serialised bytes, so that two implementations producing identical bytes share an identifier.¶

• Appendix D.1 additionally requires that a correlation identifier over a typed action object be emitted only after the object validates against a pinned definition of its type.¶

Reference and source corrections in this revision:¶

• The SCITT Architecture reference is now [RFC9943] and the COSE Merkle tree proofs reference is now [RFC9942]. -01 cited both as Internet-Drafts; both have since been published as RFCs.¶

• The Web Bot Auth architecture reference is replaced. -01 cited draft-meunier-web-bot-auth-architecture, which has been replaced by [I-D.meunier-webbotauth-httpsig-protocol]. [I-D.meunier-webbotauth-registry], which defines the signature-agent card, is retained. [I-D.meunier-webbotauth-httpsig-directory] is added, because the card is resolved through the directory the Signature-Agent header names and -01 cited no document for that step.¶

• The document date, RFCXML version and submission type are declared in the source, and keyword is a single YAML sequence.¶

• A note to the RFC Editor records the [RFC8785] downref explicitly, so that it can be called out at IETF Last Call per [RFC8067] rather than found there.¶

• Appendix D now REQUIRES that all composed capsules carry one shared action serialisation, established by the authorising party and echoed verbatim by later attesters, and states that a capsule's own account of the action travels in its payload rather than in subject_digest. -01 left the shared-serialisation condition implicit, which is the condition the digest depends on.¶

• The determinism requirement is scoped to the Reconciliation Output and to the Claim Hash, Reconciliation Hash and Policy-Version Hash; -03 removes the Reconciliation Hash from that set, as the -03 entry above records. -01 required bit-for-bit identical Settlement-Layer Ledger entries, which the entry's own sequence number, timestamp and prior-entry hash make unsatisfiable.¶

• The Claim Hash is pinned to SHA-256 in Canonical Claim Ingestion. -01 named the algorithm only in an appendix, leaving a parameter the construction identifier is required to commit to unstated in the normative body.¶

• Claim equality is stated over canonical field values, and declared array order is significant. -01 required semantically-equivalent claims to hash alike without defining semantic equivalence, which no implementer could test.¶

• The Per-Register Claim Projection is defined as the nearest permitted ancestor predicate rather than a greatest lower bound, which the Predicate Taxonomy -- a tree -- does not have, and the projection function now fails explicitly on an ambiguous or unreachable walk rather than choosing.¶

• The Settlement-Layer Ledger entry carries an OPTIONAL Source-Reconciliation-Output Identifier, which the retroactive re-evaluation example already relied on and the entry's closed field list did not admit.¶

• freshness-stale is added to the Divergence-Axis controlled set, and server-recorded axes are stated to travel in the Reconciliation Output rather than in a register's signed payload, which the reconciliation server cannot modify.¶

• COSE header labels are requested from IANA rather than asserted as a vendor-private range, and an IANA registry is requested for Divergence-Axis values.¶

• The examples are de-identified. Register identifiers are illustrative and no bilateral agreement with any named authority is asserted.¶

• Two independent implementations of an [RFC8785]-based digest construction, one in Go and one in Python and sharing no source, were measured as agreeing byte-for-byte on 24 generated inputs selected to exercise absent-field normalisation, arrays, string escaping, UTF-16 member sorting and both integer bounds. Two implementations derived from one source would have demonstrated code identity rather than agreement, which is why the pair is named. That is the outcome Appendix D.1 argues for: one identified construction per digest role, committing to the parameters that affect the serialised bytes and to nothing else.¶

E.4. Since draft-hillier-scitt-arp-00

• Added a fourth motivating deficiency (unverifiable requester identity in an agentic setting) to the Introduction.¶

• Added a new pipeline subsystem, Requester Identity Binding and Agent Friend-or-Foe (IFF) Gate, and renumbered the pipeline to twelve subsystems.¶

• Added the agent: predicate branch, a new Agentic Principal Reconciliation section, and the divergence axes agent-principal-unverifiable, agent-credential-absent, and agent-impersonation-suspected.¶

• Added Requester-Binding to the Policy-Version Hash commitment and a requester-binding-class descriptor to the Settlement-Layer Ledger entry.¶

• Bound ARP to HTTP Message Signatures [RFC9421] and Web Bot Auth for signed agent requests, and added an Agent Impersonation security consideration.¶

• Replaced the stale scitt-receipts reference with COSE Receipts [RFC9942] and added the SCITT Reference APIs [I-D.ietf-scitt-scrapi]; Hash-Linkage Aggregation now emits COSE Receipts.¶

• Described the Evidentiary Provenance Manifest's optional carriage as a COSE-enveloped Verified-Principal-Credential evidence container.¶

• Extended Retroactive Evaluation to treat credential revocation as a material change, and added a new IANA header label and worked agentic example.¶

• Added the motivating agentic-containment failure class to the Introduction and framed real-time reconciliation of claimed-versus-actual conduct as a first-class property, distinct from after-the-fact forensic reconstruction.¶

• Added a Composition with Agent-Action Accountability Capsules section reconciling heterogeneous CAN/WHO/WHAT/AUDIT capsules [I-D.mih-sato-agent-accountability-composition] over a shared subject digest into a producer-agnostic verdict, with a worked divergent agent-action example.¶

• Added the agent-action-scope-divergence divergence axis.¶

• Removed two unused informative references (JWS, JWT).¶