Attestation Reconciliation Protocol
draft-hillier-scitt-arp-06
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Joel Hillier | ||
| Last updated | 2026-10-23 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-hillier-scitt-arp-06
Network Working Group J. D. Hillier
Internet-Draft Certisyn, Inc.
Intended status: Standards Track 23 October 2026
Expires: 26 April 2027
Attestation Reconciliation Protocol
draft-hillier-scitt-arp-06
Abstract
This document specifies the Attestation Reconciliation Protocol
(ARP), a deterministic, bilateral, minimum-disclosure mechanism for
reconciling verification claims against a plurality of sovereign
authoritative registers without raw register records leaving their
data-residency jurisdiction. ARP extends the SCITT (Supply Chain
Integrity, Transparency, and Trust) architecture to cross-sovereign
claim reconciliation. A reconciliation server canonicalises a
structured claim, binds the identity of the requesting principal --
including, where the requester is an autonomous agent, a friend-or-
foe determination of that agent's verifiable principal binding --
projects the claim through register-specific controlled projection
functions producing the nearest permitted ancestor predicate
supported by each addressed register, transmits register-specific
ciphertexts, receives partial attestations whose payload discloses,
of the subject, only a verdict, an optional divergence axis, the
applied profile parameters and a query binding digest, aggregates
those attestations under a verdict arithmetic the deployment's policy
resolves, committing each register's contribution to a Merkle tree,
and seals the resulting reconciliation output against a policy-
version hash. An append-only cross-jurisdictional settlement-layer
ledger records digests and structural metadata, with no claim,
register-record or principal content. The protocol supports
retroactive re-evaluation of historical reconciliations under updated
pattern libraries or policy versions without bilateral renegotiation,
and a cryptographic-primitive-upgrade path including post-quantum
primitives. This revision adds a normative binding to the SCITT
Reference APIs, register data-format profiles for beneficial-
ownership, corporate-registry, customs and consolidated-sanctions
formats, and a source-data version binding that makes a change in a
historical verdict attributable to a change in policy or to a change
in the underlying published corpus.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Hillier Expires 26 April 2027 [Page 1]
Internet-Draft ARP October 2026
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 26 April 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Note to the RFC Editor . . . . . . . . . . . . . . . . . . . 5
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Relationship to Other Work . . . . . . . . . . . . . . . . . 8
3.1. What this document builds on . . . . . . . . . . . . . . 8
3.2. What this document does not replace . . . . . . . . . . . 9
3.3. Why it is a separate document . . . . . . . . . . . . . . 9
3.4. Where the design was taken from elsewhere . . . . . . . . 10
4. Conventions and Definitions . . . . . . . . . . . . . . . . . 10
5. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1. Canonical Claim Ingestion . . . . . . . . . . . . . . . . 20
5.2. Requester Identity Binding and Agent Friend-or-Foe
Gate . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.3. Adversarial Pre-Transmission Test . . . . . . . . . . . . 24
5.4. Per-Register Projection Function . . . . . . . . . . . . 27
5.4.1. Subject Mapping Record . . . . . . . . . . . . . . . 29
5.5. Register Data-Format Profiles . . . . . . . . . . . . . . 30
5.5.1. Beneficial ownership: BODS . . . . . . . . . . . . . 31
5.5.2. Corporate registries: vCard and the Organization
Ontology . . . . . . . . . . . . . . . . . . . . . . 33
Hillier Expires 26 April 2027 [Page 2]
Internet-Draft ARP October 2026
5.5.3. Customs and transport: UN/CEFACT and the WCO Data
Model . . . . . . . . . . . . . . . . . . . . . . . . 34
5.5.4. Sanctions: consolidated list formats . . . . . . . . 34
5.6. Source-Data Version Binding . . . . . . . . . . . . . . . 35
5.7. Per-Register Encryption . . . . . . . . . . . . . . . . . 37
5.8. Partial Attestation Reception . . . . . . . . . . . . . . 38
5.9. Merkle Construction . . . . . . . . . . . . . . . . . . . 40
5.9.1. Leaf binding . . . . . . . . . . . . . . . . . . . . 42
5.9.2. Verification outcomes . . . . . . . . . . . . . . . . 43
5.10. Aggregation . . . . . . . . . . . . . . . . . . . . . . . 44
5.11. Registers That Do Not Answer . . . . . . . . . . . . . . 44
5.12. Verdict Re-Typing . . . . . . . . . . . . . . . . . . . . 47
5.13. Verdict Arithmetic . . . . . . . . . . . . . . . . . . . 49
5.14. Reconciliation Output . . . . . . . . . . . . . . . . . . 51
5.15. Output Entitlement and Delivery . . . . . . . . . . . . . 59
5.15.1. Audience . . . . . . . . . . . . . . . . . . . . . . 59
5.15.2. Reliance Horizon . . . . . . . . . . . . . . . . . . 61
5.15.3. Delivery . . . . . . . . . . . . . . . . . . . . . . 62
5.16. Policy-Version-Hash Sealing . . . . . . . . . . . . . . . 63
5.17. Post-Seal Evaluation Records . . . . . . . . . . . . . . 65
5.18. Settlement-Layer Ledger . . . . . . . . . . . . . . . . . 67
5.18.1. Replication . . . . . . . . . . . . . . . . . . . . 77
5.19. Regulator Portal . . . . . . . . . . . . . . . . . . . . 78
5.19.1. Sovereign Re-Notification . . . . . . . . . . . . . 79
5.20. Audit Path . . . . . . . . . . . . . . . . . . . . . . . 80
5.21. Retroactive Evaluation . . . . . . . . . . . . . . . . . 82
5.21.1. Evaluation Sweep Statements . . . . . . . . . . . . 84
5.21.2. Revocation and the reliance window . . . . . . . . . 89
5.21.3. Coverage Probes . . . . . . . . . . . . . . . . . . 89
5.22. Cryptographic-Primitive-Upgrade Path . . . . . . . . . . 91
5.23. The Bilateral Register Agreement . . . . . . . . . . . . 92
5.23.1. Declared items . . . . . . . . . . . . . . . . . . . 92
5.23.2. Witness Set and Witness Quorum . . . . . . . . . . . 96
5.23.2.1. Witness Entries . . . . . . . . . . . . . . . . 96
5.23.2.2. Head Consistency Statements . . . . . . . . . . 97
5.23.2.3. Witness Linkage Segments . . . . . . . . . . . . 98
5.23.2.4. The quorum rule . . . . . . . . . . . . . . . . 101
5.23.2.5. Discovery . . . . . . . . . . . . . . . . . . . 106
5.23.2.6. Where the quorum is zero . . . . . . . . . . . . 107
5.23.3. The Agreement Hash . . . . . . . . . . . . . . . . . 107
5.23.4. What a Bilateral Register Agreement does not
establish . . . . . . . . . . . . . . . . . . . . . . 110
5.24. Aggregate Statements . . . . . . . . . . . . . . . . . . 110
6. Agentic Principal Reconciliation . . . . . . . . . . . . . . 112
7. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 113
7.1. CBOR-COSE Encoding . . . . . . . . . . . . . . . . . . . 113
7.2. Reconciliation Request Binding . . . . . . . . . . . . . 115
7.3. HTTP Message Signature Binding . . . . . . . . . . . . . 116
Hillier Expires 26 April 2027 [Page 3]
Internet-Draft ARP October 2026
7.4. Output and Ledger Read Binding . . . . . . . . . . . . . 117
7.4.1. Request signing profile . . . . . . . . . . . . . . . 117
7.4.2. Read operations . . . . . . . . . . . . . . . . . . . 120
7.4.3. Responses . . . . . . . . . . . . . . . . . . . . . . 123
7.4.4. Error semantics . . . . . . . . . . . . . . . . . . . 126
7.5. SCITT Reference API Binding . . . . . . . . . . . . . . . 129
7.5.1. Registration . . . . . . . . . . . . . . . . . . . . 129
7.5.2. Asynchronous registration . . . . . . . . . . . . . . 131
7.5.3. Sealing-key discovery . . . . . . . . . . . . . . . . 132
7.5.4. Receipt validation . . . . . . . . . . . . . . . . . 134
7.5.5. Policy-version determination . . . . . . . . . . . . 135
7.6. Verifiable Credentials Interop . . . . . . . . . . . . . 135
7.6.1. Credential Form . . . . . . . . . . . . . . . . . . . 135
7.6.2. Securing . . . . . . . . . . . . . . . . . . . . . . 138
7.6.3. Verification . . . . . . . . . . . . . . . . . . . . 139
7.6.4. JOSE Securing Forms . . . . . . . . . . . . . . . . . 140
7.6.5. Conformance Class . . . . . . . . . . . . . . . . . . 142
7.7. Representation Invariance . . . . . . . . . . . . . . . . 142
8. Security Considerations . . . . . . . . . . . . . . . . . . . 144
8.1. Service-Operator Containment . . . . . . . . . . . . . . 145
8.2. Budget Exhaustion as a Suppression Channel . . . . . . . 147
8.3. Pattern-Library Integrity . . . . . . . . . . . . . . . . 148
8.4. Agent Impersonation and Friend-or-Foe Integrity . . . . . 148
8.5. Bilateral-Register-Agreement Drift . . . . . . . . . . . 149
8.6. Replay Defence . . . . . . . . . . . . . . . . . . . . . 149
8.7. The Clocks a Response Freshness Check Is Decided
Across . . . . . . . . . . . . . . . . . . . . . . . . . 150
8.8. Where Head-Consistency Evidence Comes From . . . . . . . 150
8.9. Post-Quantum Migration . . . . . . . . . . . . . . . . . 151
8.10. Side-Channel Considerations . . . . . . . . . . . . . . . 151
8.11. Signature Malleability and Artefact Identity . . . . . . 152
8.12. Artefact Identity Across a Change of Signature
Algorithm . . . . . . . . . . . . . . . . . . . . . . . 154
8.13. Declared Trade-offs . . . . . . . . . . . . . . . . . . . 156
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 159
9.1. Against the threat model of RFC 6973 . . . . . . . . . . 161
9.2. Erasure and rectification against an append-only
record . . . . . . . . . . . . . . . . . . . . . . . . . 162
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 163
10.1. Well-Known URIs . . . . . . . . . . . . . . . . . . . . 167
10.2. Media types . . . . . . . . . . . . . . . . . . . . . . 169
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 170
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 172
12.1. Normative References . . . . . . . . . . . . . . . . . . 172
12.2. Informative References . . . . . . . . . . . . . . . . . 175
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 177
A.1. Example: Three-register Sanctions Reconciliation . . . . 178
A.2. Example: Retroactive Re-evaluation . . . . . . . . . . . 180
Hillier Expires 26 April 2027 [Page 4]
Internet-Draft ARP October 2026
A.3. Example: Agentic Principal Reconciliation . . . . . . . . 182
A.4. Example: Divergent Agent-Action Reconciliation . . . . . 182
A.5. Example: Verifiable Credentials Form of an Output . . . . 183
Appendix B. Composition with the SCITT Architecture . . . . . . 185
Appendix C. Composition with the RATS Architecture . . . . . . . 185
Appendix D. Composition with Agent-Action Accountability
Capsules . . . . . . . . . . . . . . . . . . . . . . . . 186
D.1. The digest constructions are distinct . . . . . . . . . . 188
D.1.1. What a content digest does and does not establish . . 190
Appendix E. Document History . . . . . . . . . . . . . . . . . . 192
E.1. Since draft-hillier-scitt-arp-05 . . . . . . . . . . . . 192
E.1.1. Mechanical . . . . . . . . . . . . . . . . . . . . . 192
E.2. Since draft-hillier-scitt-arp-04 . . . . . . . . . . . . 192
E.2.1. The Verifiable Credentials form is a complete
profile . . . . . . . . . . . . . . . . . . . . . . . 192
E.2.2. Four securing forms for one credential . . . . . . . 193
E.2.3. Sealing-key discovery is exercised end to end . . . . 193
E.3. Since draft-hillier-scitt-arp-03 . . . . . . . . . . . . 193
E.3.1. The chain a head-consistency check is decided over . 193
E.3.2. One deterministic encoding, named by section . . . . 195
E.3.3. A floor on the response freshness tolerance . . . . . 196
E.3.4. Certificate Transparency, and the leaf a proof
carries . . . . . . . . . . . . . . . . . . . . . . . 196
E.3.5. Every digest that identifies a signed artefact . . . 198
E.3.6. The Bilateral Register Agreement . . . . . . . . . . 200
E.3.7. The witness quorum . . . . . . . . . . . . . . . . . 200
E.3.8. The head-linkage projection . . . . . . . . . . . . . 202
E.3.9. Six adversarial passes, and what they found . . . . . 203
E.3.10. Five mechanisms taken from outside this field . . . . 206
E.3.11. The two clocks a response freshness check is decided
across . . . . . . . . . . . . . . . . . . . . . . . 208
E.3.12. Mechanical . . . . . . . . . . . . . . . . . . . . . 208
E.4. Since draft-hillier-scitt-arp-02 . . . . . . . . . . . . 209
E.4.1. Five things the protocol assumed and never stated . . 213
E.4.2. Ways the protocol could be gamed, closed . . . . . . 216
E.5. Since draft-hillier-scitt-arp-01 . . . . . . . . . . . . 218
E.6. Since draft-hillier-scitt-arp-00 . . . . . . . . . . . . 222
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 223
1. Note to the RFC Editor
RFC EDITOR: please remove this section before publication.
This document is Standards Track and makes six normative references
to Informational documents: RFC 2104, RFC 6234, RFC 6839, RFC 8785,
RFC 9053 and RFC 9334. Each is a downref under [RFC8067]. RFC 6839,
RFC 9053 and RFC 9334 are already recorded in the downref registry,
so no Last Call action is required for them. RFC 2104 and RFC 6234
Hillier Expires 26 April 2027 [Page 5]
Internet-Draft ARP October 2026
are cited for HMAC and for SHA-256, which every digest this document
defines depends on and which earlier revisions used throughout with
no normative reference at all; RFC EDITOR, please confirm their
current downref-registry status, since it may have changed since this
revision was written. RFC 8785 is not registered, and it is the one
that needs the announcement below. That reference is deliberately
normative: ARP's Canonical Claim is a digest over an RFC 8785
serialisation preceded by Unicode Normalization Form C, and the
subject digest of Appendix D is a digest over an unmodified RFC 8785
serialisation. Neither can be computed without RFC 8785, and an
implementation that substituted any other canonicalisation would
compute a different value for the same claim. The reference is
therefore load-bearing for interoperability and cannot be demoted to
informative. This is called out here so that the downref can be
noted in the IETF Last Call announcement, which Section 2 of
[RFC8067] strongly recommends without requiring.
This document also makes a normative reference to
[I-D.ietf-scitt-scrapi], which at the time of writing has completed
IETF process and is in the RFC Editor queue with no RFC number yet
assigned. Section 7.5 imposes requirements expressed in terms of
that document's endpoints, status codes and media types, and an
implementation cannot satisfy them without it, so the reference
cannot be informative. RFC EDITOR: this document should not be
published before that draft, and the reference should be updated to
the resulting RFC number.
2. Introduction
Sovereign authoritative registers record facts that are treated as
conclusive within their jurisdiction. Examples include beneficial-
ownership registers (such as the United States FinCEN Beneficial
Ownership Secure System, the United Kingdom People with Significant
Control register, and the European Union beneficial-ownership
registers under the Anti-Money-Laundering Directives), corporate
registries, consolidated sanctions lists, export-control registers,
foreign-ownership-and-control-or-influence registers, maritime vessel
registrations, flag-state registers, aviation registrations, land-
title registries, customs declarations, and multilateral biometric
registers.
Institutional decision-makers -- including export-control compliance
officers, anti-money-laundering review functions, foreign-investment
screening review functions, sanctions-screening operators,
multilateral aid distribution authorities, and platform-owned
verification infrastructure -- routinely require reliance on facts
recorded across two or more sovereign registers simultaneously.
Hillier Expires 26 April 2027 [Page 6]
Internet-Draft ARP October 2026
Cross-sovereign reliance today faces four structural problems, which
this protocol is designed to address in combination:
1. *Raw-record disclosure.* Existing approaches require the raw
register record either to leave its data-residency jurisdiction
or to be re-disclosed in plaintext to a relying party in another
jurisdiction. Sovereign registers under data-protection regimes
are jurisdictionally constrained against such re-disclosure.
2. *Non-reconcilable register outputs.* Each sovereign register
exposes a different schema, a different signing chain, a
different verdict semantic, and a different statutory access
regime. A relying party that requires a deterministic combined
verdict over n sovereign registers therefore faces n parallel
verification problems.
3. *Non-auditable settlement.* Cross-sovereign reliance, where it
occurs at all, occurs without a settlement-layer audit trail
consumable by sovereign regulators.
4. *Unverifiable requester identity in an agentic setting.* Cross-
sovereign reliance is increasingly initiated not by an
authenticated human operator but by an autonomous software agent
acting on behalf of a principal. Where the agent's binding to a
real, authenticated principal cannot be verified, the
reconciliation is performed for an unknown or impersonated party,
and the settlement record attributes reliance to no accountable
principal. An agent whose principal binding cannot be verified
is treated as hostile (zero-trust); the normative rules are in
Section 4 and Section 8.4.
This document specifies ARP, a protocol that addresses all four
deficiencies in combination, and is layered atop the SCITT
architecture [RFC9943] and the RATS architecture [RFC9334].
The fourth deficiency is not hypothetical. Where an autonomous agent
can act, its containment assumptions may not hold at run time, and a
binding between an agent's claimed authority and its actual conduct
that is established only after the fact is not a control. The
binding must be checkable at the moment of action.
Hillier Expires 26 April 2027 [Page 7]
Internet-Draft ARP October 2026
ARP is designed for that moment. Forensic reconstruction establishes
what an agent did after a consequence has occurred; ARP reconciles an
agent's claimed authority and principal binding against authoritative
registers while the action can still be refused. A reconciliation
that yields a non-decisive or divergent verdict is a control input
available before the action commits, not an audit finding available
after. This document treats real-time reconciliation of claimed-
versus-actual conduct as a first-class property of accountable
autonomous action.
3. Relationship to Other Work
This protocol is assembled from existing work wherever existing work
reaches, and this section states what it takes, what it does not
replace, and why it exists as a separate document rather than as an
extension to one of them. A reader who concludes after this section
that an existing mechanism already covers the problem has the
information needed to say so, which is the purpose of putting it
before the specification rather than after it.
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 [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.ietf-webbotauth-httpsig-protocol] rather than defining a
parallel scheme.
Hillier Expires 26 April 2027 [Page 8]
Internet-Draft ARP October 2026
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.
Hillier Expires 26 April 2027 [Page 9]
Internet-Draft ARP October 2026
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.
4. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
The following terms are defined for use throughout this document:
Sovereign Register: An authoritative data store maintained by or on
behalf of a sovereign and treated as conclusive within that
sovereign's jurisdiction for the predicates the register is
empowered to record.
Register Operator: The entity that operates the Sovereign Register
and is contractually empowered to bind the register's
attestations.
Bilateral Register Agreement: A negotiated contractual instrument
between the operator of the reconciliation server and a Register
Operator, declaring the terms under which a register is
addressable under this document. Section 5.23 enumerates the
items an Agreement MUST declare, in the order that fixes them, and
defines the Agreement Hash each Agreement carries.
Witness Set: The set of observers, declared in a Bilateral Register
Agreement under Section 5.23.2.1, whose Head Consistency
Statements under Section 5.23.2.2 and Witness Linkage Segments
under Section 5.23.2.3 constitute head-consistency evidence
independent of the responding service.
Witness Linkage Segment: A signed record, published by a witness at
Hillier Expires 26 April 2027 [Page 10]
Internet-Draft ARP October 2026
its own origin under Section 5.23.2.3, of the linkage arrays it
observed over a contiguous interval of Entry Sequence Numbers.
Consecutive Segments from one witness cover a Ledger from that
witness's Attestation Floor upward, and are what a relying party
assembles a chain between two heads from where Section 5.23.2.4
obliges it to hold one.
Witness Quorum: The number of Witness Entries, as Section 5.23.2.1
defines them, with pairwise distinct Operating-Party Identifiers
whose head-consistency evidence a relying party must hold before
the evidence condition of Section 7.4.3 is satisfied. Declared
under Section 5.23.2 and evaluated under Section 5.23.2.4, which
states what that evidence is in each of its two branches.
Policy-Epoch Store: The persisted, versioned record of a
deployment's verification-policy state, from which the Policy-
Version Hash of Section 5.16 is reconstructible and from which the
reconciliation server resolves, per predicate and named regime
set, the Verdict Arithmetic and its parameters and the reliance
interval. It holds the Deployment Blinding Value and the
Requester-Binding of each reconciliation. It is internal to the
reconciliation server; this document constrains what it must be
able to answer and not how it is built.
Requesting Principal: The accountable party on whose behalf a
reconciliation is performed. A Requesting Principal is either an
authenticated human or institutional operator, or an autonomous
agent carrying a Verified Principal Credential that binds it to
such an operator.
Requesting Agent: An autonomous software agent that initiates a
reconciliation. A Requesting Agent is FRIENDLY when it carries a
verifiable identity -- a request signed under HTTP Message
Signatures [RFC9421] per Web Bot Auth
[I-D.ietf-webbotauth-httpsig-protocol], a genuinely verified
declared bot, or a Verified Principal Credential -- and ENEMY when
its principal binding is absent or unverifiable. Anything
unverifiable is treated as ENEMY.
Verified Principal Credential: A cryptographic credential asserting
that a named, authenticated principal stands behind a request,
verifiable without contacting the credential issuer in the
reconciliation hot path. A Verified Principal Credential MAY be
carried in any COSE-enveloped structure binding the claim, its
evidentiary provenance, and the principal's credential, or in any
equivalent verifiable-credential form [W3C-VC-DM-2.0].
Agent Friend-or-Foe (IFF) Determination: The deterministic
Hillier Expires 26 April 2027 [Page 11]
Internet-Draft ARP October 2026
classification of a Requesting Agent as FRIENDLY or ENEMY,
computed from the presence and cryptographic validity of a
verifiable agent identity and, where required by policy, a
Verified Principal Credential. The determination is recorded in
the Requester-Binding field and committed to the Policy-Version
Hash.
Canonical Claim: A deterministic structured representation of a
verification claim, comprising at least a subject identifier, a
predicate, an attested value, an applicable-regimes set, and an
evidentiary provenance manifest. Canonicalisation is performed in
the following order, which is normative because the operations do
not commute:
1. Unicode Normalization Form C [UAX15] is applied to every
string value and to every object member name.
2. Object member names are sorted by UTF-16 code unit, as
specified in Section 3.2.3 of [RFC8785].
3. Declared array order is preserved.
4. Numbers are rendered as specified in Section 3.2.2.3 of
[RFC8785].
5. A member whose value is absent is omitted, rather than
serialised with a null placeholder.
Steps 1 and 2 are order-dependent and observably so: for an object
carrying the member names "A" followed by COMBINING RING ABOVE
(U+0041 U+030A) and "B", normalising before sorting and sorting
before normalising yield different serialisations and therefore
different Claim Hashes. This specification requires normalisation
first.
The member-sort code unit is normative. An implementation that
sorts by Unicode code point rather than by UTF-16 code unit
produces a different Claim Hash for any object carrying a member
name outside the Basic Multilingual Plane. The two orderings are
not interchangeable, and this specification pins the UTF-16
reading, which is the one Section 3.2.3 of [RFC8785] specifies.
This construction is NOT the construction defined in Appendix D
for subject_digest. The two MUST NOT be substituted for one
another; see Appendix D.1.
Predicate Taxonomy: A controlled hierarchical classification of
Hillier Expires 26 April 2027 [Page 12]
Internet-Draft ARP October 2026
predicates that may be the subject of reconciliation, enabling
taxonomic prefix match in projection. The taxonomy includes an
agent: branch whose predicates reconcile the verifiability of an
agent's binding to a principal (for example agent:principal-
binding-verifiable and agent:credential-attested).
Per-Register Claim Projection: The narrowest structured query
sufficient to elicit the required Partial Attestation under a
register's Bilateral Register Agreement, computed by the
controlled projection function as the nearest ancestor of the
Canonical Claim Predicate that is a member of the register's
permitted-predicate set. Where the taxonomy admits more than one
such ancestor, the projection MUST fail rather than choose.
Partial Attestation: A cryptographically signed output produced by a
Sovereign Register in response to a Per-Register Claim Projection.
The Partial Attestation payload SHALL disclose, of the subject,
only a Reconciliation-Verdict field, an OPTIONAL Divergence-Axis
field, the applied parameters of Section 5.5 and the Query
Binding, which is a digest; it SHALL NOT disclose any register
record. Fields denoting state rather than the subject -- the
Freshness Timestamp, and the Source-Data Version Identifier of
Section 5.6 -- are enumerated in Section 5.8.
Applicable-Regimes Set: The set of regulatory regimes a Canonical
Claim names as applicable. It is a claim field chosen by the
requester and states which law the requester asserts governs the
question. It does not carry the Verdict Arithmetic, its
parameters or the reliance interval; those 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. A requester names the regime; the
deployment's policy determines how evidence under it combines and
how long a verdict may be relied upon.
Combined Verdict: The single verdict value produced by aggregating
the Reconciliation-Verdict fields of the Per-Register Result Set
of Section 5.14 under the Verdict Arithmetic resolved under
Section 5.13. Its values are match, no-match, partial-match and
indeterminate. The decisive values are match and no-match.
Reconciliation Hash: The SHA-256 digest of [RFC6234] over the
deterministically encoded CBOR serialisation of a Reconciliation
Output excluding its Sealing Signature and Sealing-Key Identifier,
as specified in Section 5.14, and with every signature made by a
party other than the sealing reconciliation server replaced by the
Signing Input Digest of that signature. Those are the register
signature carried in each Query Binding Record, the register
Hillier Expires 26 April 2027 [Page 13]
Internet-Draft ARP October 2026
signature carried in each Non-Answer Statement, and the
authorising operator's signature carried in the Override Record of
Section 5.3. Excluding the Sealing Signature is not sufficient on
its own: a Reconciliation Output embeds signatures made by parties
other than the server, and a digest over those names whichever
encoding the reader was handed, for the reason Section 8.11 gives.
The rule is stated over the class -- every signature not made by
the sealing server -- and not over an enumeration, because an
enumeration is complete only until a field is added, and the
Override Record is the field that showed this.
Authority Origin: The serialisation of an origin as Section 6.2 of
[RFC6454] defines it: the scheme, the U+003A COLON and two U+002F
SOLIDUS characters, the host, and, where the port differs from the
default for the scheme, a U+003A COLON and the port in decimal
with no leading zeros. The scheme and the host are lowercased.
There is no trailing solidus, no path, no query and no fragment,
and no userinfo component: https://register-a.example and
https://register-a.example:8443 are Authority Origins and
https://register-a.example/, https://Register-A.example,
https://register-a.example:443 and register-a.example are not. An
implementation MUST reject a value in any of those other forms
rather than normalise it, because a value that is normalised on
receipt is a value two parties can hash differently before they
compare it.
This document uses Authority Origins as bytewise sort keys inside
signed sets, as path segments, and as equality targets against the
origin component of a Sealing-Key Identifier. Each of those three
uses breaks on a different divergence: a sort key reorders, a path
segment resolves elsewhere, and an equality test refuses a key
that was in fact authorised. Fixing the form once, here, is what
makes those three uses one term.
Signing Input Digest: The SHA-256 digest over the deterministically
encoded CBOR Sig_structure of a COSE_Sign1, as Section 4.4 of
[RFC9052] constructs it: the array of the context string
"Signature1", the protected header, the external additional
authenticated data, and the payload. It is a digest of what the
signer signed and not of the envelope carrying it, so it does not
depend on the signature bytes and does depend on the protected
header, which in this document carries the key identifier and the
algorithm identifier under Section 7.1. This document supplies no
external additional authenticated data: the third element is the
zero-length byte string in every Sig_structure it defines, and an
implementation MUST NOT supply another value, because a Signing
Input Digest a third party cannot reproduce is not an identifier.
The protected header is taken as the byte string transmitted and
Hillier Expires 26 April 2027 [Page 14]
Internet-Draft ARP October 2026
MUST NOT be re-encoded; those bytes are the signer's and are what
the signature covers. Every digest in this document that
identifies or chains a signed artefact is a Signing Input Digest,
for the reason Section 8.11 gives.
Divergence Axis: A controlled descriptor identifying a structural
qualification on a verdict. Most identify the reason for a non-
match; those recorded by the reconciliation server may qualify a
verdict of any value. The controlled set is the registry of
Section 10, which at the time of writing comprises identity-
mismatch, jurisdictional-scope-mismatch, temporal-mismatch,
ownership-threshold-mismatch, sanctions-list-match, register-
record-absent, claim-predicate-unsupported, claim-projection-
narrowed-beyond-attestation-scope, agent-principal-unverifiable,
agent-credential-absent, agent-impersonation-suspected, agent-
action-scope-divergence (the authorised scope attested for an
agent action and the actual conduct attested for it do not
reconcile), source-version-skew, register-threshold-divergence
(two registers answered the same predicate under different
declared interest thresholds, per Section 5.5.1), declared-not-
determined (the register could answer only over a declared fact
where the claim ranged over a determined one, per Section 5.5.3),
and freshness-stale. Divergence Axes recorded by the
reconciliation server rather than by a register, which the
registry marks as such and which initially are freshness-stale,
source-version-skew, register-threshold-divergence, declared-not-
determined and agent-action-scope-divergence, are carried in the
Reconciliation Output, not in the register's signed Partial-
Attestation payload.
Source-Data Version Identifier: An identifier denoting the state of
a published corpus, external to both the Bilateral Register
Agreement and the Policy Version, against which a register
evaluated a Projected Predicate. A consolidated sanctions list is
the characteristic case. Its purpose is attribution: without it,
a change in a historical Combined Verdict cannot be attributed to
a change in policy state rather than to a change in the underlying
corpus. Requirements are in Section 5.6.
Post-Seal Evaluation Qualifier: A controlled descriptor identifying
a condition arising after a Reconciliation Output has been sealed,
carried in a Post-Seal Evaluation Record per Section 5.17 rather
than in the Output. The values are those of the registry in
Section 10, at the time of writing notarisation-incomplete and
attribution-indeterminate. A Post-Seal Evaluation Qualifier is
not a Divergence Axis: a Divergence Axis qualifies a verdict, and
a Post-Seal Evaluation Qualifier qualifies an operation on an
Output whose verdict is already fixed.
Hillier Expires 26 April 2027 [Page 15]
Internet-Draft ARP October 2026
Threshold-Sensitive Predicate: A Predicate whose truth depends on an
interest threshold, so that two registers evaluating it under
different declared thresholds are not answering the same question.
A profile registered under Section 5.5 MUST state which of its
predicates are threshold-sensitive.
Source Class: A partition of the Addressed-Registers Identifier Set
resolved for the named regimes under Section 5.13, over which
source-class-quorum is evaluated.
Sovereign Re-Notification: A signed notification emitted through the
Regulator Portal to each regulator whose statutory scope covers a
reconciliation whose historical Combined Verdict has materially
changed. The supersession that occasions it is separately
recorded as a continuation-supersession entry on the Settlement-
Layer Ledger under Section 5.18, so that a relying party that
acted on the superseded Output can discover the change.
Reconciliation Nonce: A value of at least 128 bits drawn from a
cryptographically secure random source, unique to one Per-Register
Claim Projection and therefore to one register within one
reconciliation. It is never reused. Two registers addressed in
the same reconciliation receive different nonces, so their Query
Bindings differ even where the Projected Predicate and Subject
Reference are identical, and an attestation elicited from one
register cannot be presented as an answer from another.
Source-Version Skew: The condition, recorded as source-version-skew,
in which two Partial Attestations answer the same Projected
Predicate against different states of the same published corpus.
Both are within their freshness windows; the skew is in the
corpus, not in the attestations. It is not a disagreement, and an
implementation MUST NOT treat it as one.
Attribution Indeterminate: The Post-Seal Evaluation Qualifier,
recorded as attribution-indeterminate, in which a Retroactive
Evaluation cannot determine whether a material change in a
historical Combined Verdict arose from a change in policy state or
from a change in Source-Data Version. It is a statement about the
evaluation, not about any register's answer.
Reconciliation Output: A data structure aggregating Partial
Attestations from a single reconciliation event, sealed against a
Policy-Version Hash.
Verdict Arithmetic: The operator governing how per-register verdicts
Hillier Expires 26 April 2027 [Page 16]
Internet-Draft ARP October 2026
combine into the Combined Verdict, specified in Section 5.13. The
controlled set comprises conjunction, disjunction, threshold-count
and source-class-quorum.
Hash-Linkage Aggregation: An aggregation of Partial Attestations in
which the per-register attestations are reduced to their Signing
Input Digests, ordered, committed to a Merkle tree, and emitted
with a Merkle root and a per-register verdict band. The Merkle
commitment and its inclusion proofs MAY be encoded as COSE
Receipts [RFC9942].
Policy-Version Hash: A cryptographic commitment to the canonical
verification-policy state in force at the moment of
reconciliation, including reconciliation rules, threshold
parameters, pattern-library version, applicable-regimes
precedence, verdict-arithmetic selection with every parameter it
takes, the reliance interval, the Agent-IFF policy in force, the
Requester-Binding, and the Bilateral-Register-Agreement Hashes of
the addressed registers.
Settlement-Layer Ledger: An append-only cross-jurisdictional log
retaining hashes of reconciliations and no Canonical-Claim,
register-record or principal content. It carries entries of two
kinds, discriminated by an entry type: a reconciliation entry,
which records a sealed Reconciliation Output, and a Continuation
entry, which records a notarisation outcome, a Post-Seal
Evaluation Record or a supersession arising after that Output was
sealed. Every entry carries a sequence number, the entry type,
the claim hash, the reconciliation hash, an entry timestamp, a
prior-entry hash, a self-entry hash and an entry signature; the
fields each kind carries in addition are enumerated in
Section 5.18. A Continuation entry may also carry a transparency-
service identifier, an entry identifier, an HTTP status code, a
post-seal evaluation record hash, a material-change indicator, a
superseding reconciliation hash and a superseding entry sequence
number. Not every field is a digest -- the sequence numbers, the
timestamps, the entry type, the descriptors and the indicators are
not -- but no field carries Canonical-Claim, register-record or
principal content, and no field is a retrieval address.
Audience Set: The set of Audience Members of a Reconciliation
Output, sealed with it under Section 5.15. Each Audience Member
is an accountable-principal identifier together with a
verification method that can be presented after the
reconciliation. The Requesting Principal is a member wherever it
can be identified. Entitlement to read about a reconciliation
follows membership, not possession of the artefact.
Hillier Expires 26 April 2027 [Page 17]
Internet-Draft ARP October 2026
Reliance Horizon: The time after which an Audience Member MUST NOT
treat a Combined Verdict as current without reading the
Continuation entries for its Reconciliation Hash. It is the
Reconciliation Timestamp advanced by the reliance interval that
deployment policy declares for the predicate and the named
regimes, resolved as Section 5.13 resolves the Verdict Arithmetic.
It bounds reliance and does not affect the validity of the Sealing
Signature.
Ledger Head Statement: A signed statement of the current head of the
Settlement-Layer Ledger, published at a well-known URI and
notarised at a declared interval, comprising the head's Entry
Sequence Number, its Self-Entry Hash, its Entry Timestamp, the
time the Statement was produced, and a pointer to the most recent
completed head notarisation. Defined in Section 5.18.
Evaluation Sweep Statement: A signed record that a retroactive
evaluation was performed, comprising the trigger, the policy state
applied, the ledger head at the start and end of the sweep, the
counts examined and materially changed, a Merkle root over the
Claim Hashes examined, a timestamp, a pointer to the notarisation
of the previous Statement. Defined in Section 5.21.1. Its
purpose is to make an evaluation that never ran a signed omission
rather than a silence.
Non-Answer Statement: A statement signed by a register recording
that it declined to answer, over the Reconciliation Identifier,
the Projected Predicate, the Subject Reference, the Reconciliation
Nonce and the reason. Required wherever a Non-Answer Reason is
register-attested, per Section 5.11.
5. Architecture
ARP comprises seventeen subsystems arranged as a deterministic
pipeline:
1. Canonical Claim Ingestion
2. Requester Identity Binding and Agent Friend-or-Foe Gate
3. Adversarial Pre-Transmission Test
4. Per-Register Projection Function, under the profile of
Section 5.5 declared in the Bilateral Register Agreement
5. Per-Register Encryption
Hillier Expires 26 April 2027 [Page 18]
Internet-Draft ARP October 2026
6. Partial-Attestation Reception, including Source-Data Version
Binding
7. Non-Answer Resolution
8. Verdict Re-Typing
9. Aggregation under the Verdict Arithmetic, per Section 5.10
10. Policy-Version-Hash Sealing
11. Settlement-Layer Ledger Write
12. Notarisation under Section 7.5, where performed
13. Regulator Portal
14. Retroactive Evaluation
15. Output Delivery under Section 5.15.3
16. Post-Seal Evaluation Recording
17. Cryptographic-Primitive-Upgrade Path
Given an identical Canonical Claim, an identical Requester-Binding,
an identical Audience Set, an identical Addressed-Registers
Identifier Set, identical Bilateral-Register-Agreement Hashes for the
addressed registers, an identical Pattern-Library Version Identifier,
and an identical Policy-Version Identifier, the system MUST produce
Reconciliation Outputs identical in every field save those enumerated
below as outside this requirement, and identical Claim Hash and
Policy-Version Hash values in the corresponding Settlement-Layer
Ledger entries.
The Reconciliation Hash is deliberately not among those values. It
is a content commitment over one sealed Output, taken over a preimage
that includes that Output's Reconciliation Timestamp, and it is not
reproducible across runs; the Reconciliation Identifier of
Section 5.14 is the reproducible index, and it is the Claim Hash and
Policy-Version Hash that make it so. Requiring an identical
Reconciliation Hash would require an identical timestamp, which no
implementation can deliver.
The per-event fields of a Ledger entry -- Entry Sequence Number,
Entry Timestamp, Prior-Entry Hash, Self-Entry Hash and Entry
Signature -- are position-dependent by construction and are outside
this requirement; the Entry Signature is further outside it because a
Hillier Expires 26 April 2027 [Page 19]
Internet-Draft ARP October 2026
signature scheme is not required to be deterministic. Within the
Reconciliation Output itself the Reconciliation Timestamp, the
Reliance Horizon computed from it, the Sealing Signature and any
Override Record are outside it: the first is per-event, the second
need not be deterministic, and an Override Record records an
operator's discretionary act rather than a function of the enumerated
inputs. The register-produced signatures the Output carries -- the
Partial Attestation inside each Query Binding Record, and each Non-
Answer Statement -- are outside it on the same ground as the Sealing
Signature: they are signatures, and a signature scheme need not be
deterministic. So is the Sealing-Key Identifier, which is rotation
state and not an enumerated input. So are the Reconciliation Event
Identifier, the Reconciliation Identifier that carries it, and every
Reconciliation Nonce carried in a Query Binding Record or a Non-
Answer Statement, together with the register signatures taken over
them: each is drawn fresh per reconciliation and is uniqueness state
rather than an enumerated input. Two reconciliations agreeing on
every enumerated input MUST differ in all three, and an
implementation MUST NOT read that difference as a determinism
failure. Stating it matters because the requirement above is
expressed as identity in every field save those carved out here, so a
field that is necessarily fresh and not carved out makes the
requirement unsatisfiable by any implementation. So are attestation-
stale and register-unresponsive, and the Divergence-Axis and verdict
consequences that follow from either: both are functions of wall-
clock timing and network conditions rather than of the enumerated
inputs, which is the same ground on which the Freshness Timestamps
themselves are outside it. A reconciliation driven to a query-
budget-exhausted or subject-ceiling-exhausted Non-Answer Reason under
Section 5.11 is also outside it, because the budget is accumulated
state and not an enumerated input. The residual risk that carve-out
creates, and why this document does not close it, is set out in
Section 8.2. The Freshness Timestamps of the constituent Partial
Attestations, and any Source-Data Version Identifiers they carry per
Section 5.6, are likewise outside it: both denote state external to
the enumerated inputs. Two reconciliations agreeing on every
enumerated input but differing in Source-Data Version are not
required to agree field for field, and an implementation MUST NOT
treat such a difference as a determinism failure.
5.1. Canonical Claim Ingestion
A Canonical Claim comprises:
* Subject Identifier
* Predicate (drawn from the controlled Predicate Taxonomy)
Hillier Expires 26 April 2027 [Page 20]
Internet-Draft ARP October 2026
* 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.
Hillier Expires 26 April 2027 [Page 21]
Internet-Draft ARP October 2026
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.
Hillier Expires 26 April 2027 [Page 22]
Internet-Draft ARP October 2026
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
Hillier Expires 26 April 2027 [Page 23]
Internet-Draft ARP October 2026
via the Signature-Agent header
[I-D.ietf-webbotauth-httpsig-protocol], which also defines the key
directory it names, 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
Hillier Expires 26 April 2027 [Page 24]
Internet-Draft ARP October 2026
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
Hillier Expires 26 April 2027 [Page 25]
Internet-Draft ARP October 2026
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.
Hillier Expires 26 April 2027 [Page 26]
Internet-Draft ARP October 2026
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
Hillier Expires 26 April 2027 [Page 27]
Internet-Draft ARP October 2026
* 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.
Hillier Expires 26 April 2027 [Page 28]
Internet-Draft ARP October 2026
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.4.1. Subject Mapping Record
The projection function transforms the Canonical Claim's Subject
Identifier into a Subject Reference in the form the addressed
register's Bilateral Register Agreement declares. Until this
revision nothing recorded that transformation, nothing constrained
it, and no party outside the reconciliation server could check it.
That is the gravest thing a reader can fail to notice about an
Output. Every signature in a Reconciliation Output can verify, every
Query Binding can recompute, the Merkle Root can be correct, the
ledger entry can chain and the notarised Signed Statement can pass
every check in Section 7.5.1, while every addressed register answered
honestly and completely *about a different person*. The registers
answer about the Subject Reference they were sent. The Output is
read as an answer about the Subject Identifier in the claim. Nothing
joined the two, and a substitution at that step is invisible to the
requester, to an Audience Member, to a regulator reading the portal,
to an Audit Identity, and to the registers themselves, none of which
is shown the Canonical Claim.
Hillier Expires 26 April 2027 [Page 29]
Internet-Draft ARP October 2026
Each Per-Register Result Set entry for which a projection was
transmitted MUST therefore carry a *Subject Mapping Record*: the two-
element CBOR array of the Subject Reference transmitted to that
register, and the *Subject Mapping Descriptor* -- a text string,
drawn from the registry of Section 10, naming the transformation
applied. The initial registrations are identity, where the Subject
Reference is the Subject Identifier unchanged; profile-declared,
where the transformation is the one the register's declared Data-
Format Profile specifies for the Subject Identifier's form; and
agreement-declared, where the Bilateral Register Agreement declares
the transformation as one of its terms. A registration MUST specify
a transformation that is a function of the Subject Identifier and of
declared terms alone, so that a party holding the Canonical Claim and
the applicable Agreement can recompute the Subject Reference and
compare it. The designated expert MUST refuse a registration whose
transformation takes any input the server chooses at reconciliation
time, since such a descriptor would name the discretion rather than
remove it.
A verifier holding the Canonical Claim MUST recompute the Subject
Reference under the named descriptor and MUST reject the Output where
the recomputed value differs from the one carried. A verifier not
holding the Canonical Claim cannot perform that check, and this
document does not claim otherwise: what the record gives that party
is an attributable statement, signed and sealed and ledgered, of
which subject each register was actually asked about. The
substitution remains possible and stops being deniable, which is the
same trade Section 5.11 makes for a suppressed register answer.
This does not close the case where the Subject Identifier in the
claim was already the wrong person. Nothing in a reconciliation
protocol can, and Appendix D.1.1 states the boundary.
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
Hillier Expires 26 April 2027 [Page 30]
Internet-Draft ARP October 2026
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.5.1. Beneficial ownership: BODS
For registers expressing beneficial ownership as [BODS] records, the
permitted-predicate set is expressed over relationship records --
termed ownership-or-control statements before BODS 0.4 -- reachable
from a declared subject entity. This profile is written against BODS
0.4.
Hillier Expires 26 April 2027 [Page 31]
Internet-Draft ARP October 2026
Taxonomic narrowing corresponds to reducing the depth of the
ownership chain a predicate ranges over. A relying party's question
is characteristically about ultimate beneficial ownership -- the
transitive closure -- while a register may be able to answer only a
bounded-depth predicate over direct or once-removed interests. The
parent of a predicate at depth n is the corresponding predicate at
depth n-1. The direct-interest predicate is the root of this
profile's branch of the Predicate Taxonomy, and the walk of
Section 5.4 fails as projection-unsupported on reaching it, as it
does at the taxonomy root.
A Bilateral Register Agreement declaring arp-profile-bods MUST supply
the maximum chain depth over which the register's permitted
predicates are evaluated. Where the Canonical Claim ranges over the
transitive closure and the register's declared maximum depth is
finite, the projection is a narrowing and MUST be recorded in
Narrowed-From. An implementation MUST NOT treat a bounded-depth no-
match as a transitive-closure no-match. The rule is stated in
Section 5.12 and applies to that register's contribution, not to the
Combined Verdict: a no-match returned at bounded depth against a
closure claim is re-typed to indeterminate before aggregation, and
the Verdict Arithmetic then proceeds unchanged. A match found at any
depth does establish the existential closure predicate and is not re-
typed.
The depth at which the register answered is reported in the Applied-
Parameter Set of its Partial Attestation and MUST be carried into the
Projection Record of Section 5.14. A register MAY answer at a
shallower depth than the declared maximum; the declared maximum is
therefore not a substitute for the applied value, and re-typing under
Section 5.12 turns on the applied value.
Interest thresholds -- the percentage at which an interest becomes
reportable -- vary by jurisdiction and are properties of the
register, not of the claim or of the format. A Bilateral Register
Agreement declaring arp-profile-bods MUST supply the threshold its
permitted predicates assume. Two registers answering the same
predicate under different thresholds are not answering the same
question. The reconciliation server MUST add register-threshold-
divergence to the Server-Recorded Divergence-Axis Set wherever the
Reconciliation Output combines registers whose declared thresholds
differ, irrespective of the verdicts they returned.
In this profile the ownership and control predicates are threshold-
sensitive; the identity and existence predicates are not.
Hillier Expires 26 April 2027 [Page 32]
Internet-Draft ARP October 2026
5.5.2. Corporate registries: vCard and the Organization Ontology
A profile in this class MUST declare [W3C-ORG] for any branch of its
predicate space over which taxonomic narrowing is defined. [RFC6350]
expresses organisational hierarchy only within one organisation's own
ORG structured value and defines no property relating one
organisation to another, so a vCard-only profile has no term capable
of satisfying the parent-relation requirement of Section 5.5 and MUST
NOT declare a narrowing branch. vCard remains available for the
identifying and contact predicates, over which no narrowing is
defined.
For registers expressing legal-entity and organisational structure, a
profile MAY declare [RFC6350] vCard properties or [W3C-ORG] classes
and properties as the vocabulary in which permitted predicates are
expressed.
A profile MUST declare exactly one parent relation for each branch of
its predicate space, and MUST partition that space so the branches do
not overlap. Declaring two relations applicable to one predicate
would make the taxonomic walk of Section 5.4 reach two predicates at
equal distance, which that section requires to fail as projection-
ambiguous.
Where [W3C-ORG] is used, org:subOrganizationOf is the parent relation
for the organisational-structure branch, and org:hasSite for the
branch of predicates ranging over establishment or place of business.
Neither vocabulary asserts the legal effect of a recorded fact.
[W3C-ORG] does carry a notion of legal recognition --
org:FormalOrganization denotes an organisation recognised in legal
jurisdictions, and org:identifier a company registration number --
but recognition is not determination. A predicate expressed in these
terms is a predicate about a register's recorded representation of an
entity, not about the entity's status in law, and a profile MUST NOT
be read as asserting the latter.
The vocabulary is pinned to [W3C-ORG] as at its 2014 Recommendation
and to [RFC6350]. A Bilateral Register Agreement declaring this
profile supplies the register's jurisdiction identifier and the
identifier scheme of its org:identifier values. No predicate in this
profile is threshold-sensitive: corporate registries record
recognition rather than a quantified interest.
Hillier Expires 26 April 2027 [Page 33]
Internet-Draft ARP October 2026
5.5.3. Customs and transport: UN/CEFACT and the WCO Data Model
For customs declarations and transport registers, a profile MAY
declare [UNCEFACT] core components or [WCO-DM] classes as the
vocabulary for permitted predicates.
Both express declaration-side and authority-side facts, and telling
them apart is the purpose of this profile rather than a property of
the vocabularies. The WCO Data Model's Declaration Response and its
Licence, Permit, Certificate and Other packages record authority
determinations, as does UN/CEFACT's eCERT for sanitary and
phytosanitary certification; the goods and cargo declaration classes
in both record what was declared to an authority.
A Bilateral Register Agreement declaring arp-profile-customs-wco MUST
supply, for each permitted predicate, whether it ranges over a
declared fact or over a determined one. Where a relying party's
Canonical Claim ranges over a determined fact and the register can
answer only over a declared one, that is a narrowing and MUST be
recorded in Narrowed-From. The reconciliation server MUST derive the
Divergence Axis declared-not-determined from the Narrowed-From field
and add it to the Server-Recorded Divergence-Axis Set of Section 5.14
whenever the narrowing occurred, whether or not it changed the
Combined Verdict; the corresponding contribution is re-typed under
Section 5.12. The register cannot record it: the register never sees
the Canonical Claim, and the Combined Verdict does not exist until
every Partial Attestation has been received.
The vocabulary is pinned to Version 4 of the [WCO-DM] and to the UN/
CEFACT Core Component Library release the Bilateral Register
Agreement names, which it MUST name. The Agreement also supplies the
declaration types the register answers over. No predicate in this
profile is threshold-sensitive.
5.5.4. Sanctions: consolidated list formats
For registers expressing designation status by reference to a
consolidated list -- [OFAC-SDN], [EU-CFSP] or equivalent -- the
permitted-predicate set is expressed over designation of a subject
entity on a named list.
Consolidated lists are republished on no fixed schedule -- OFAC
states there is no predetermined timetable, and the EU list is
updated as amending regulations are adopted -- and are distributed
either as full republications or as delta updates against a prior
state. That the cadence is event-driven strengthens the requirement
below rather than weakening it: a relying party cannot infer list
state from the clock. A designation verdict is meaningful only
Hillier Expires 26 April 2027 [Page 34]
Internet-Draft ARP October 2026
relative to the list state that produced it, and this has a
consequence the rest of this document depends on: without it, a
change in a historical Combined Verdict cannot be attributed to a
policy change rather than to a list change. Accordingly the
requirements of Section 5.6 apply.
A Bilateral Register Agreement declaring arp-profile-sanctions-
consolidated MUST supply the set of lists the register consults and,
for each, the identifier by which the register expresses that list's
state. Where the register publishes both a full list and deltas, the
identifier MUST denote the resulting state and not the delta applied
to reach it.
A profile in this class names no single vocabulary, consolidated
sanctions lists having no common schema. It instead pins, per
register, the list identifier and the publisher's state-identifier
form that Section 5.6 requires, both supplied by the Bilateral
Register Agreement, together with the matching predicate set the
register answers over. No predicate in this profile is threshold-
sensitive: a designation is a listed-or-not fact.
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
Hillier Expires 26 April 2027 [Page 35]
Internet-Draft ARP October 2026
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.
Hillier Expires 26 April 2027 [Page 36]
Internet-Draft ARP October 2026
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-
Hillier Expires 26 April 2027 [Page 37]
Internet-Draft ARP October 2026
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,
Hillier Expires 26 April 2027 [Page 38]
Internet-Draft ARP October 2026
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.
Hillier Expires 26 April 2027 [Page 39]
Internet-Draft ARP October 2026
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. [RFC9162]
carries the hash algorithm as a log parameter and this document fixes
SHA-256, which is the hash that Certificate Transparency logs built
on the earlier specification also use, so an implementer arriving
from either computes the same tree.
Hillier Expires 26 April 2027 [Page 40]
Internet-Draft ARP October 2026
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.
Hillier Expires 26 April 2027 [Page 41]
Internet-Draft ARP October 2026
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.9.1. Leaf binding
The leaf a proof carries is a convenience and is not evidence. A
verifier MUST compute the leaf from the object whose inclusion is
being proved -- the Signing Input Digest of the Partial Attestation
for a Merkle Root under Section 5.10, the Claim Hash for an Examined-
Set Root under Section 5.21.1 -- and MUST use that computed value,
and no value taken from the proof, as the input to the sibling walk.
Where the proof carries a leaf, the verifier MUST refuse the proof if
the computed value does not equal it, and MUST perform that
comparison before the sibling array is walked.
The requirement is stated over the object rather than over the
carried field because the field is not always present. Section 5.10
permits per-register inclusion proofs to be encoded as COSE Receipts
[RFC9942], whose inclusion proof carries no leaf; a requirement
written only as a comparison against a carried leaf would be vacuous
under that encoding, which is the encoding a SCITT-aware verifier is
most likely to use.
Hillier Expires 26 April 2027 [Page 42]
Internet-Draft ARP October 2026
The ordering is the whole of the requirement. A proof whose leaf is
lifted unchanged from another object's valid proof folds to the
correct root under a sibling array that verifies, because it is a
correct proof -- of the other object. A verifier that walks the path
first and takes the carried leaf on trust accepts it, and concludes
that the object it holds was committed when what was committed was
something else. Nothing in the walk depends on the object, so the
walk cannot detect this; only the recomputation can. It is the more
dangerous half of its pair: a malformed proof fails loudly on every
path a verifier tries, while a valid proof bound to the wrong leaf
passes every check except this one.
5.9.2. Verification outcomes
The preceding rules tell a verifier to refuse. They do not give it
any way to record which refusal it made, and four conditions that
arrive at "refuse" through this section are evidence about four
different things. A deployment that reports them alike reports
something that did not happen, and the report will be believed,
because the check that produced it worked exactly as specified.
A verifier that refuses a proof or an artefact under this document
MUST record a Verification Outcome, drawn from the registry of
Section 10, and MUST NOT report one as another. The initial values
are:
proof-against-empty-root: A proof was presented against the empty-
tree root of Section 5.9. Evidence of neither equivocation nor
re-encoding: the empty root commits to nothing and no proof
against it can be valid.
leaf-object-mismatch: The leaf recomputed from the object differs
from the leaf the proof carries. Evidence of equivocation by the
serving party, and the case this section exists to catch.
root-mismatch: The sibling walk completed and produced a root other
than the one named. Evidence of equivocation by the serving
party.
same-act-distinct-encodings: The artefact the verifier holds and the
artefact the proof or digest commits to have equal Signing Input
Digests and unequal enveloped bytes. *Evidence of a re-encoding
and not of equivocation.* A verifier MUST test for this condition
before reporting leaf-object-mismatch or root-mismatch, and where
it holds, MUST report this outcome instead.
Hillier Expires 26 April 2027 [Page 43]
Internet-Draft ARP October 2026
The last is the one that changes what a reader concludes. Two
artefacts with one Signing Input Digest are one signing act under two
encodings, which Section 8.11 shows a third party holding no key can
produce from the honest signer's own bytes -- and which, for ECDSA,
is produced by any implementation that normalises s on ingest while
believing it is hardening. Reporting that as detected tampering
accuses a party of equivocating on the strength of an operation an
intermediary performed correctly. The constructions of Section 8.11
make the digests stable; this makes the report that survives them
accurate.
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
Hillier Expires 26 April 2027 [Page 44]
Internet-Draft ARP October 2026
* 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
Hillier Expires 26 April 2027 [Page 45]
Internet-Draft ARP October 2026
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.
Hillier Expires 26 April 2027 [Page 46]
Internet-Draft ARP October 2026
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,
Hillier Expires 26 April 2027 [Page 47]
Internet-Draft ARP October 2026
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.
Hillier Expires 26 April 2027 [Page 48]
Internet-Draft ARP October 2026
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.
Hillier Expires 26 April 2027 [Page 49]
Internet-Draft ARP October 2026
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.
Hillier Expires 26 April 2027 [Page 50]
Internet-Draft ARP October 2026
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
Hillier Expires 26 April 2027 [Page 51]
Internet-Draft ARP October 2026
* 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
Hillier Expires 26 April 2027 [Page 52]
Internet-Draft ARP October 2026
* 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.
Hillier Expires 26 April 2027 [Page 53]
Internet-Draft ARP October 2026
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
Hillier Expires 26 April 2027 [Page 54]
Internet-Draft ARP October 2026
* 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
Hillier Expires 26 April 2027 [Page 55]
Internet-Draft ARP October 2026
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.
+==============================+===================================+
| Field | CBOR encoding |
+==============================+===================================+
| Reconciliation Event | byte string of 16 octets |
| Identifier | |
+------------------------------+-----------------------------------+
| Reconciliation Identifier | byte string of 80 octets, the |
Hillier Expires 26 April 2027 [Page 56]
Internet-Draft ARP October 2026
| | Claim Hash followed by the |
| | Policy-Version Hash followed by |
| | the Reconciliation Event |
| | Identifier |
+------------------------------+-----------------------------------+
| Claim Hash, Policy-Version | byte string of 32 octets |
| Hash, Merkle Root | |
+------------------------------+-----------------------------------+
| Reconciliation Timestamp, | text string, in the form fixed |
| Reliance Horizon | below |
+------------------------------+-----------------------------------+
| Combined Verdict | text string, one of the four |
| | values of Section 4 |
+------------------------------+-----------------------------------+
| Verdict Arithmetic and its | two-element array: the operator |
| parameters | identifier as a text string, and |
| | its parameters as an array, empty |
| | for conjunction and disjunction, |
| | a one-element array of the |
| | threshold as an unsigned integer |
| | for threshold-count, and a two- |
| | element array of the source-class |
| | partition and the per-class |
| | threshold for source-class-quorum |
+------------------------------+-----------------------------------+
| source-class partition | array of two-element arrays of |
| | the class identifier as a text |
| | string and the sorted array of |
| | Register Identifiers in that |
| | class, the outer array sorted by |
| | class identifier |
+------------------------------+-----------------------------------+
| Addressed-Registers | array of Authority Origins as |
| Identifier Set | text strings, sorted as |
| | Section 5.14 states |
+------------------------------+-----------------------------------+
| Bilateral-Register-Agreement | array of 32-octet byte strings, |
| Hash Set | deduplicated, sorted |
+------------------------------+-----------------------------------+
| Pattern-Library Version | text string |
| Identifier | |
+------------------------------+-----------------------------------+
| Requester-Binding Class | text string |
+------------------------------+-----------------------------------+
| Aggregation-Method | text string |
| Descriptor | |
+------------------------------+-----------------------------------+
| Audience Set, Per-Register | array of arrays, each member in |
Hillier Expires 26 April 2027 [Page 57]
Internet-Draft ARP October 2026
| Result Set, Server-Recorded | the field order its own section |
| Divergence-Axis Set | enumerates |
+------------------------------+-----------------------------------+
| Override Record | array in the field order of |
| | Section 5.3, or null |
+------------------------------+-----------------------------------+
| Sealing-Key Identifier | two-element array of the |
| | Authority Origin as a text string |
| | and the JWK thumbprint as a text |
| | string |
+------------------------------+-----------------------------------+
| Sealing Signature | byte string, the serialised |
| | COSE_Sign1, or null in a preimage |
+------------------------------+-----------------------------------+
| Register Identifier | text string |
+------------------------------+-----------------------------------+
| Answer State, Attested | text string |
| Verdict, Effective Verdict, | |
| Non-Answer Reason, Re-Typing | |
| Ground, Subject Mapping | |
| Descriptor | |
+------------------------------+-----------------------------------+
| Divergence-Axis Field | array of two-element arrays of |
| | the axis identifier as a text |
| | string and its Register |
| | Identifier or null, sorted by the |
| | deterministic encoding of the |
| | member |
+------------------------------+-----------------------------------+
| Query Binding Record, Non- | array in the field order its own |
| Answer Statement, Projection | section enumerates, or null |
| Record | |
+------------------------------+-----------------------------------+
Table 1
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.
Hillier Expires 26 April 2027 [Page 58]
Internet-Draft ARP October 2026
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.15.1. Audience
A Reconciliation Output carries an Audience Set of zero or more
Audience Members, encoded as a CBOR array which is empty only in the
case described below. Each Audience Member comprises:
* an Audience Member Identifier: a URI, in the same identifier space
a Requester-Binding uses for an accountable principal, encoded as
a CBOR text string. Two Audience Member Identifiers are equal
where they do not differ after normalisation under Sections 6.2.2
and 6.2.3 of [RFC3986]; comparison is over the normalised form and
is otherwise bytewise, and an implementation MUST encode the
normalised form rather than normalise on receipt, for the reason
Section 4 gives for an Authority Origin. It is a sort key inside
Hillier Expires 26 April 2027 [Page 59]
Internet-Draft ARP October 2026
the Audience Set and so inside the Reconciliation Hash preimage,
the first element of every Witness Entry and so inside the
Agreement Hash, and the equality target of the quorum rule of
Section 5.23.2.4; the same treatment is given to an Operating-
Party Identifier and was not given here
* a Verification Method Reference: the JWK thumbprint, computed as
in [RFC7638], of the public key under which that member signs a
read request under Section 7.4. It MUST be a durable key and MUST
NOT be a session credential or a one-time request signature,
because the member has to present it long after the reconciliation
is over
Audience Members are sorted in bytewise lexicographic order of the
deterministic CBOR encoding of the Audience Member Identifier, and
each member is encoded as a two-element array in the field order
above. Ordering is stated because the Audience Set is inside the
Reconciliation Hash preimage, and an unordered set would give one
Output as many hashes as it has permutations.
The server MUST NOT require proof of possession from a named member
at reconciliation time -- the member is typically not present -- and
naming one is therefore an assertion by the Requesting Principal, not
a fact about the member. Two consequences follow and are stated so
that neither surprises. Naming a party places a row in that party's
GET /arp/outputs enumeration and in the server's access log that the
party did not ask for, so a deployment SHOULD constrain who may be
named through the audience constraint below and through the enrolment
requirement of Section 7.2. And a member that loses or rotates the
key its thumbprint names loses entitlement to every Output that names
it, permanently, because the Audience Set cannot be amended after
sealing; a member that expects to rely on Outputs over time SHOULD be
named by a thumbprint of a key held for that purpose.
The Requesting Principal is an Audience Member of every Output
performed on its behalf where it can be identified: by its
accountable-principal identifier where the Requester-Binding carries
one, and otherwise as below. Where it does not -- classes agent-
unverified and agent-key-verified -- the Set carries a member whose
Identifier is the URI form of the verified signing key's thumbprint.
Every requester signs, by Section 7.4.1, so there is always a key to
name and an Audience Set is never empty.
Further members are named in the reconciliation request, are
enumerated inputs for the purposes of Section 5, and are sealed with
the rest of the Output. The Audience Set MUST NOT be enlarged after
sealing; naming a further member requires a new reconciliation, which
is a new question and gets a new answer.
Hillier Expires 26 April 2027 [Page 60]
Internet-Draft ARP October 2026
A Bilateral Register Agreement MAY declare an audience constraint: a
maximum cardinality, a permitted class of member, or both. Where the
Audience Set exceeds the constraint an addressed register declares,
the reconciliation server MUST NOT transmit a projection to that
register and MUST record audience-constraint-exceeded as its Non-
Answer Reason. It MUST NOT refuse the reconciliation, and MUST NOT
quietly drop the register: the first leaves no artefact stating why,
and the second is the addressed-register-cherry-picking Section 5.11
exists to prevent. The reconciliation is sealed and, by
Section 5.13, cannot reach a decisive Combined Verdict.
The requester is not a party to any Bilateral Register Agreement and
cannot read the constraint, so it learns the cap from the reason
recorded against that register rather than by inspection. A register
that attests about a subject is entitled to bound how widely that
attestation travels, and a constraint enforced after transmission
would be enforced too late. The constraint is enforced by the
reconciliation server on the register's behalf and the register
cannot verify that enforcement from any artefact this document
defines; a register that requires assurance of it should negotiate an
audit right in its agreement.
A party MUST NOT be treated as entitled to a Reconciliation Output by
possession alone. A relying party that has been handed an Output and
is not an Audience Member of it MAY verify its Sealing Signature and
read its Combined Verdict -- nothing prevents this, and the signature
is what makes the Output worth handing on -- but it obtains no read
under Section 7.4, learns nothing of supersession or post-seal
evaluation, and MUST NOT treat the verdict as current. Reliance
without entitlement is reliance on a snapshot of unknown age.
5.15.2. Reliance Horizon
A Reconciliation Output carries a Reliance Horizon: a time in the
form of Section 5.14, being the Reconciliation Timestamp advanced by
the reliance interval the reconciliation server resolves from the
policy-epoch store of Section 5.16, keyed on the predicate and the
regimes the claim names, exactly as it resolves the Verdict
Arithmetic under Section 5.13. A requester able to set its own
reliance interval could set its own staleness window, which is the
same defect as choosing its own Verdict Arithmetic. After that time
an Audience Member MUST NOT treat the Combined Verdict as current
without having read the Continuation entries for its Reconciliation
Hash under Section 7.4 and found no supersession.
The Horizon does not invalidate the Output and does not weaken the
Sealing Signature: what was sealed remains true of the moment it was
sealed. It bounds reliance, not validity. A sanctions no-match is a
Hillier Expires 26 April 2027 [Page 61]
Internet-Draft ARP October 2026
statement about consolidated lists as they stood, and those lists
change on a daily cadence (Section 5.5.4); an artefact that asserted
such a verdict indefinitely and carried no marker of its own
staleness would be relied upon indefinitely, which is the failure
Section 5.21 exists to prevent and could not, having no way to reach
the party that had relied.
The Reliance Horizon is derived from the Reconciliation Timestamp and
is therefore outside the reproducibility requirement of Section 5 on
the same ground.
5.15.3. Delivery
The reconciliation server MUST return the sealed Reconciliation
Output to the Requesting Principal in the response to the request
that commissioned it, in the form Section 7.2 states. Where the
Adversarial Pre-Transmission Test emitted a Remediation Advisory, the
server returns that Advisory and no Output. Section 7.2 enumerates
the responses to a commissioning request. A refusal under
Section 8.1 or an audience constraint under Section 5.15.1 is not
among them: those refuse a register and not the reconciliation, so an
Output is produced and delivered, carrying the reason against the
register it concerns.
That the server returns the Output is stated because nothing in
earlier revisions did. The document specified in detail what an
Output contains, how it is sealed, digested, ledgered and notarised,
and never that any party receives one. Every discovery path in this
document begins with a party holding a Reconciliation Hash, and it
holds one because of this paragraph.
An Audience Member other than the Requesting Principal is not
delivered to. It retrieves under Section 7.4: the server has no
channel to a party it has never spoken to, and pushing a confidential
artefact to an address named by somebody else is not a mechanism this
protocol should define.
The Reconciliation Hash is the retrieval key and is not reproducible
across runs (Section 5), so a party that has discarded it cannot
recompute it, and the Reconciliation Identifier is no help because
the Claim Hash within it is blinded under Section 5.16 and cannot be
computed outside the deployment. The server MUST therefore also
answer the enumeration of Section 7.4, returning to an authenticated
principal the Reconciliation Hashes of the Outputs whose Audience Set
names it. Without it, an Audience Member that has lost a 32-byte
value has lost every entitlement this section grants it, permanently
and silently.
Hillier Expires 26 April 2027 [Page 62]
Internet-Draft ARP October 2026
The server MUST retain each sealed Output, and MUST answer reads of
it and of its Continuation entries, for the retention period, which
is the LONGEST period any Bilateral Register Agreement addressed by
that reconciliation declares, and in no case ending before the
Reliance Horizon advanced by one further reliance interval. Where
two agreements declare different periods the longest governs. That
direction is specific to a retention period, which is a floor: the
shortest declaration would let one register's agreement extinguish
another's.
Wherever else this document takes a value from a plural set of
agreements, the direction is the one that makes the obligation
stricter, and it is stated at each site. For every interval that
bounds a deadline -- the ledger-head notarisation interval of
Section 5.18, and the Evaluation Sweep and supersession deadlines
measured against it -- the SHORTEST declaration governs. Taking the
longest there would let one permissive agreement postpone every
deadline for every other register, which inverts the obligation
instead of strengthening it. For the read rate limit of
Section 7.4.4, the most permissive declaration governs, a rate limit
being a ceiling on the server's refusals rather than on its duties.
The extra interval matters. Section 5.15.2 requires an Audience
Member to read before relying past the Horizon, and entitlement is
evaluated against the Audience Set of the retained Output; a
retention floor that ended exactly at the Horizon would permit the
server to discard the basis of that evaluation at the moment the
obligation begins, and the member would receive the 404 of
Section 7.4.4 -- indistinguishable, by design, from never having been
entitled.
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
Hillier Expires 26 April 2027 [Page 63]
Internet-Draft ARP October 2026
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-
Hillier Expires 26 April 2027 [Page 64]
Internet-Draft ARP October 2026
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.
Hillier Expires 26 April 2027 [Page 65]
Internet-Draft ARP October 2026
* 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
Hillier Expires 26 April 2027 [Page 66]
Internet-Draft ARP October 2026
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
Hillier Expires 26 April 2027 [Page 67]
Internet-Draft ARP October 2026
* 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
Hillier Expires 26 April 2027 [Page 68]
Internet-Draft ARP October 2026
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
Hillier Expires 26 April 2027 [Page 69]
Internet-Draft ARP October 2026
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
Hillier Expires 26 April 2027 [Page 70]
Internet-Draft ARP October 2026
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
Hillier Expires 26 April 2027 [Page 71]
Internet-Draft ARP October 2026
* 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.
Hillier Expires 26 April 2027 [Page 72]
Internet-Draft ARP October 2026
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
Hillier Expires 26 April 2027 [Page 73]
Internet-Draft ARP October 2026
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.
Hillier Expires 26 April 2027 [Page 74]
Internet-Draft ARP October 2026
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
Hillier Expires 26 April 2027 [Page 75]
Internet-Draft ARP October 2026
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 submit the Ledger Head Statement current
at each interval for notarisation by 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.
Hillier Expires 26 April 2027 [Page 76]
Internet-Draft ARP October 2026
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.18.1. Replication
The Ledger MAY be distributed across a plurality of per-jurisdiction
secondary stores under synchronous replication, each operated under
the data-residency constraints of its host jurisdiction. The append-
only derivation-chain invariant -- that every entry's Prior-Entry
Hash equals the Signing Input Digest, as Section 5.18 defines it, of
the immediately preceding entry's Entry Signature -- MUST be
preserved across all secondary stores. A secondary store replicates
the single sequence of Section 5.18 and originates no entry of its
own.
Hillier Expires 26 April 2027 [Page 77]
Internet-Draft ARP October 2026
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 submit that head
for notarisation by 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.
Hillier Expires 26 April 2027 [Page 78]
Internet-Draft ARP October 2026
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.19.1. Sovereign Re-Notification
A Sovereign Re-Notification is a COSE_Sign1 by the reconciliation-
server sealing key, under the media type registered in Section 10,
whose payload is the CBOR array of:
* the Claim Hash and the Reconciliation Hash of the superseded
Output
* the Entry Sequence Number of the continuation-supersession entry
recording the supersession
* the Material-Change Indicator
* the verdict values before and after
Hillier Expires 26 April 2027 [Page 79]
Internet-Draft ARP October 2026
* the Attribution, one of policy-state, source-data-version or
attribution-indeterminate, and where it is the last, the Post-Seal
Evaluation Record Hash of the record Section 5.17 requires
* a Notification Timestamp, in the form of Section 5.14
encoded as a CBOR array in that order, an absent conditionally-absent
element as CBOR null so that the array's length is fixed, the first
element a two-element array of the two hashes and the fourth a two-
element array of the verdict before and after; and signed under the
Sealing-Key Identifier its protected header carries. The signature
is not a payload element.
The server MUST deliver it to the notification endpoint each affected
regulator's Bilateral Register Agreements declare, MUST retry until
acknowledged or until the retention period of Section 5.15.3 elapses,
and MUST make every Re-Notification retrievable by a regulator under
Section 7.4.2. A regulator that is unreachable when a verdict
changes is exactly the case the mechanism exists for, so delivery
cannot be a single attempt, and an obligation with no artefact and no
endpoint -- which is what earlier revisions specified -- is an
obligation no party can discharge or audit.
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,
Hillier Expires 26 April 2027 [Page 80]
Internet-Draft ARP October 2026
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.
Hillier Expires 26 April 2027 [Page 81]
Internet-Draft ARP October 2026
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
Hillier Expires 26 April 2027 [Page 82]
Internet-Draft ARP October 2026
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.
Hillier Expires 26 April 2027 [Page 83]
Internet-Draft ARP October 2026
5.21.1. Evaluation Sweep Statements
Every trigger of retroactive evaluation is observed by the
reconciliation server, every decision to run is taken by it, and
until this revision nothing recorded that a sweep had run. "We
evaluated and found no change" and "we never evaluated" were the same
observation from every position outside the server, which made the
central obligation of this section unfalsifiable.
The Retroactive Evaluation Subsystem MUST emit exactly one Evaluation
Sweep Statement for each trigger, within the ledger-head notarisation
interval of Section 5.18 measured from the trigger event. One
Statement per trigger, on a deadline tied to an event outside the
server, is what makes a missing Statement provable; "one per sweep"
would let an operator batch a quarter's triggers into a single
Statement and remain conformant while evaluating nothing in time. A
Statement comprises:
* the trigger, drawn from the registry of Section 10 and initially
one of pattern-library, policy-version, source-data-version,
credential-revocation or register-record-correction, and the
identifier of the artefact that triggered it
* the Policy-Version Hash and Pattern-Library Version Identifier
applied
* the Entry Sequence Number of the Ledger head when the sweep began
and when it completed
* the Excluded-Range Set: the set of Entry Sequence Number ranges
inside the bracket that the sweep deliberately did not examine,
each a two-element array of a range and a reason drawn from the
registry of Section 10, empty where the sweep examined its whole
bracket
* the Examined-Range Set: the set of Entry Sequence Number ranges
the sweep covered, each a two-element array of a first and a last
Entry Sequence Number inclusive, the ranges pairwise disjoint and
in ascending order, and together covering every entry between the
two head sequence numbers above whose Entry Type is reconciliation
* the count of Reconciliation Outputs examined, and the count found
materially changed
* the Examined-Set Root: the root of a Merkle tree, constructed as
Section 5.9 defines it, over the Claim Hashes of the
Reconciliation Outputs examined, sorted in bytewise lexicographic
order, so that a party entitled to one of those reconciliations
Hillier Expires 26 April 2027 [Page 84]
Internet-Draft ARP October 2026
can be shown an inclusion proof that its own reconciliation was in
the set. The Root commits to the distinct Claim Hashes examined
and to nothing else. By Section 5.9 the leaf count and the
examined count are not derivable from one another, because two
Outputs over one claim share a Claim Hash and the leaves are
deduplicated; and no construction in this document commits the
count found materially changed to anything beyond this Statement's
own signature. Both counts are therefore assertions of the
signing server, which the signature, the Timestamp and the
notarisation make attributable and dated, and do not make
verifiable. An earlier revision said the counts "are not bare
assertions", which the deduplication rule two sections above
already contradicted. The Examined-Range Set and the identity
below are what make them checkable, by measuring them against the
Ledger rather than against the Root
* an Evaluation Sweep Timestamp, in the form of Section 5.14
* the Transparency Service Identifier and EntryID of the
notarisation of the previous Evaluation Sweep Statement, encoded
as CBOR null in the first Statement of a series
* a Sealing-Key Identifier
* a signature by the reconciliation-server sealing key, 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, an
absent field likewise, encoded under Section 4.2.1 of [RFC8949].
The first, second, third, fourth and seventh items are each a two-
element array, so that a field carrying two values occupies one
position
Statements are retrievable under Section 7.4.2 and MUST each be
notarised into the Transparency Service of Section 5.18 under their
own media type, within the same interval that bounds their emission.
The previous- notarisation pointer above makes the published series a
chain, so that a withdrawn Statement is detectable rather than merely
absent; [I-D.ietf-scitt-scrapi] retrieves by EntryID and offers no
query surface, so a party not told an EntryID could not find that
notarisation by search. A Statement is retained for the retention
period of Section 5.15.3.
On request under Section 7.4.2, a server MUST return an inclusion
proof of a given Claim Hash in the Examined-Set Root of a given
Statement, to a party entitled to a reconciliation carrying that
Claim Hash.
Hillier Expires 26 April 2027 [Page 85]
Internet-Draft ARP October 2026
*The sweep identity.* For every Evaluation Sweep Statement, a party
able to read the Ledger over the Statement's Examined-Range Set MUST
be able to verify all three of the following, and a Statement failing
any of them is non-conforming:
1. *The bracket abuts the previous one.* The beginning head sequence
number equals the completing head sequence number of the
Statement this one names as its predecessor, or the Statement is
the first of its series. Without this the identity below is an
accounting over an interval the operator chose after seeing what
was in it, and a sweep can be complete over a bracket that begins
after the entries it would rather not have examined. The
Examined-Range Set answers _was anything skipped inside the
bracket_; this answers _was the bracket cut_, and the second
question is the one an operator with something to hide would
prefer nobody asked.
2. The Examined-Range Set and the Excluded-Range Set together are
contiguous over the interval claimed: the ranges are pairwise
disjoint, ascending, and their union contains every Entry
Sequence Number between the two head sequence numbers whose entry
is of Entry Type reconciliation. A range the sweep chose not to
examine is therefore individually disposed, with a reason, rather
than absent -- a remainder that reconciles only by arithmetic
being exactly what [I-D.hillier-coverage-attestation] declines to
accept, one level down. A gap is a claim to have examined an
interval with a hole in it, and it is visible because the Ledger
is contiguous by construction.
3. The count of Reconciliation Outputs examined equals the number of
reconciliation entries in the Examined-Range Set alone.
4. The count found materially changed equals the number of
continuation-supersession entries appended in the interval
between the two head sequence numbers whose superseded
Reconciliation Hash is one of a reconciliation entry in that
union.
Hillier Expires 26 April 2027 [Page 86]
Internet-Draft ARP October 2026
The four together are an accounting identity rather than a signature,
and that is the point of them. A signature makes an assertion
attributable; an identity makes it checkable against something the
asserting party does not solely control. The Ledger is append-only,
contiguous, head-notarised into a Transparency Service outside the
operator's control, and read under Section 7.4.2 by regulators,
Audience Members, Register Operators and Audit Identities. Requiring
the counts to balance against it converts two numbers the operator
could previously choose into two numbers the operator must now make
true, and a sweep that examined less than it claims fails the
identity at whichever of the three it falsified.
The first of the four was added after Walter Hawkins showed, on the
SCITT mailing list on 20 August 2026, that an equivalent rule one
level down constrains the remainder inside a declared population and
says nothing about where the population's edge falls. His sentence
for it is the one worth keeping: the information did not survive
being moved from the remainder to the denominator, it just moved. An
operator that may choose the bracket has the same freedom as one that
may choose the denominator, and every rule below the first was
satisfiable over a bracket selected after the fact.
The Examined-Set Root and the Examined-Range Set answer different
questions and both are needed. The Root proves *membership*: an
Audience Member can be shown that its own reconciliation was in the
examined set. The Range Set proves *coverage*: any Ledger reader can
see that no interval was skipped. A Merkle root over a set of Claim
Hashes cannot prove coverage, because Claim Hashes are sparse in the
digest space and a set commitment has no notion of the elements that
are missing. Entry Sequence Numbers are dense and contiguous, so
absence in that space is visible in a way absence in the digest space
is not. Committing to the same sweep in both spaces is what lets one
artefact answer both questions.
A Statement does not prove a sweep was performed honestly, and this
document does not claim it does. What it changes is that a sweep not
performed is now a statement the operator has to make, sign and date,
rather than a silence. A Source-Data Version publication is a public
event with a public timestamp; an operator with no Statement within
the deadline has not evaluated in time, which is checkable. The
other three triggers are not public events, so the Policy Parameters
Document of Section 7.4.1 carries the identifier and effective time
of every Pattern-Library and Policy-Version transition the server
applies, which makes those two triggers observable. A credential-
revocation trigger is observable to the credential's issuer and to
the affected principal and to nobody else, and this document does not
make it more so.
Hillier Expires 26 April 2027 [Page 87]
Internet-Draft ARP October 2026
The fifth trigger, register-record-correction, is a statement by a
Register Operator under item 32 of Section 5.23.1, so the event that
starts its clock is outside the reconciliation server in the same way
a list publication is, and the argument reaches it.
The falsifiability argument therefore holds for four triggers in
five, and it holds for the second and third of them *only through the
anchoring Section 7.4.1 places on the Policy Parameters Document
itself*, which is stated here because an earlier revision of this
section claimed three in four while the Document carrying two of them
was published by the reconciliation server, under its own key, with
no publication time and no notarisation. On that footing the count
was one in four and the sentence claiming otherwise was the one place
this document rounded up. A transition simply omitted from the array
started no clock, and no party could date the Document well enough to
show that it had been. The Publication Timestamp, the notarisation,
and the obligation to republish on the interval whether or not
anything changed are what make the second and third arguments true,
and a deployment whose Policy Parameters Document is not anchored as
Section 7.4.1 requires has two falsifiable triggers and not four.
Both counts in this paragraph were stale within two hours of the
fifth trigger being added, in opposite directions: the enumeration
above still named four triggers while the registry of Section 10
named five, and this sentence still said three in four. Neither
needed a reader to catch. A count in a specification is an assertion
about the specification, and the conformance class of Section 5.21.3
now carries a runner that checks every such count against the text
that makes it. An operator that signs a Statement it did not earn is
making a false attributable claim, which is a different thing from an
invisible omission, and the Examined-Set Root means an Audience
Member can require it to prove that its own reconciliation was in the
set it claims to have examined.
Where a Sovereign Re-Notification cannot state whether a material
change arose from policy state or from Source-Data Version, the
attribution-indeterminate Post-Seal Evaluation Record it references
MUST state which of the two candidate causes were examined and why
neither could be excluded. A bare qualifier is a discretionary
escape signed by the party that benefits from it.
Hillier Expires 26 April 2027 [Page 88]
Internet-Draft ARP October 2026
5.21.2. Revocation and the reliance window
Revocation of a Verified Principal Credential cannot be detected at
the moment of reliance by a party that is not checking, and this
protocol does not put a revocation check in the hot path of every
relying party. What it does instead is bound the window. An
Audience Member MUST read the Continuation entries for a
Reconciliation Hash under Section 7.4 before relying on that Output
past its Reliance Horizon (Section 5.15.2), and the supersession that
records a revocation is among the entries that read returns.
Reliance inside the horizon on a credential revoked during it is
possible and is not prevented; reliance years later on an Output
whose principal was disowned the following week is prevented, which
is the case that matters and the case earlier revisions left open.
The horizon is declared per predicate, so a deployment needing a
shorter window for a sanctions predicate than for a corporate-
registry one sets one.
5.21.3. Coverage Probes
Every mechanism in this section makes a sweep that was not performed
into a statement an operator has to sign and date. None of them
establishes how much of what should have been examined actually was.
The sweep identity of Section 5.21.1 closes the gap between the
counts and the Ledger; it does not close the gap between the Ledger
and the world, because an operator that never wrote an entry has
nothing to be caught balancing.
That is the omission problem, and it does not have a proof. It has
an estimator.
*The construction.* A *Coverage Probe* is an ordinary reconciliation,
commissioned by an Audit Identity under Section 5.20, that is
indistinguishable at the reconciliation server from any other
reconciliation over the same predicate and register set. Before
commissioning a set of probes, the Audit Identity publishes a *Probe
Commitment*: a COSE_Sign1 under its own key whose payload is the
Merkle Root, constructed as Section 5.9 defines it, over the Claim
Hashes of the probes it intends to commission, together with their
count and a Commitment Timestamp. The commitment is published before
the first probe is commissioned and MUST be notarised into the
Transparency Service of Section 5.18.
Hillier Expires 26 April 2027 [Page 89]
Internet-Draft ARP October 2026
After a sweep that should have covered them, the Audit Identity
requests an inclusion proof for each probe's Claim Hash under the
Examined-Set Root of the Statement covering the interval its probe
fell in, which Section 5.21.1 already obliges the server to return.
The *recovery fraction* is the number of probes for which a valid
inclusion proof was returned, over the number committed.
*What it estimates.* The recovery fraction is an unbiased estimator
of the proportion of eligible Outputs the sweep actually examined,
provided the server cannot distinguish a probe from an ordinary
reconciliation. Applied to the examined count the Statement asserts,
it yields an estimate of the population that should have been
examined and was not: where a sweep asserts E examined and recovers m
of k probes, the eligible population is estimated at E * k / m, and
the shortfall at E * (k - m) / m.
This is not a proof about any individual Output and this document
does not claim it is. It is a bound on an aggregate, with a
confidence interval that narrows as k grows, and it is the only thing
in this document that speaks to the size of what was never written
down. An operator suppressing a class of reconciliations suppresses
probes at the same rate, because it cannot tell them apart, and the
suppression appears in the recovery fraction rather than in any
artefact the operator controls.
*Indistinguishability is the whole of the mechanism, and it is what
makes it expensive.* A probe MUST address real registers over a real
predicate and MUST be charged against a real query budget, and its
subject MUST be drawn from the same distribution as ordinary subjects
for that predicate. A server that can identify probes by their
subject, their register set, their timing, their requester or their
budget treatment can examine those and suppress the rest, and the
estimator then reports the operator's discrimination rather than its
coverage. A deployment MUST NOT exempt a probe from any charge,
limit or path that applies to an ordinary reconciliation, and MUST
NOT mark one as a probe in any artefact before the sweep it tests has
been notarised.
*Why the commitment precedes the probes.* Without it, an auditor
could commission many probes, observe which were examined, and
publish only those it liked, in either direction: an auditor hostile
to an operator publishes only the misses, and an auditor captured by
one publishes only the hits. The commitment fixes the denominator
before the numerator is knowable to anybody, which is what makes the
fraction evidence rather than a selection.
Hillier Expires 26 April 2027 [Page 90]
Internet-Draft ARP October 2026
*What it costs and what it cannot do.* Probes consume register
capacity, and a register bears that cost without receiving the
benefit, so the number of probes is a term for a Bilateral Register
Agreement rather than a constant this document sets; item 33 of
Section 5.23.1 carries it. The technique establishes nothing about a
deployment whose registers are themselves suppressing, since a
probe's answer is only as good as the register's. And it cannot
reach a reconciliation that was never commissioned by anyone, which
is the requester's vantage and not the auditor's.
The estimator is standard practice in fields that must characterise a
survey they cannot repeat: sources of known brightness are injected
into an astronomical image and the fraction recovered gives the
survey's completeness function; marked individuals are released into
a population and the fraction recaptured bounds the population that
was never seen. In both cases the quantity of interest is what the
instrument missed, which cannot be observed directly and can be
estimated from a known signal passed through the same instrument. A
retroactive evaluation sweep is an instrument of that kind.
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".
Hillier Expires 26 April 2027 [Page 91]
Internet-Draft ARP October 2026
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.23.1. Declared items
Each Bilateral Register Agreement MUST declare each of the following,
save where an item is marked OPTIONAL or the text of the item admits
its absence; Section 5.23.3 lists which those are. The numbering is
normative: it is the order in which the Agreement Hash of
Section 5.23.3 is computed, and it is the only order this document
specifies.
1. The permitted-predicate set of Section 5.4.
2. The supported cryptographic primitives, including any post-
quantum primitives selected under Section 8.9. Every primitive
appearing in an equivalence list of item 3 MUST appear here.
3. The Cryptographic-Primitive-Upgrade Path of Section 5.22.
Hillier Expires 26 April 2027 [Page 92]
Internet-Draft ARP October 2026
4. The transport, endpoint, framing and encryption construction of
the bilateral channel of Section 5.4.
5. The regulator-identity-provider trust anchor of Section 5.19.
6. The notification endpoint of Section 5.19.1.
7. The statutory-regulator-access scope of Section 5.19, together
with the per-jurisdiction permitted-read-field and permitted-
read-predicate sets it is computed from.
8. The Subject Reference form of Section 5.4.
9. The Freshness Window of Section 5.4.
10. The register's data-format profile under Section 5.5, together
with every value that profile obliges a declaring Agreement to
supply or to name, in the order the profile enumerates them. A
vocabulary release a profile requires the Agreement to name is
such a value and is not a parameter in the sense of Section 5.5,
so naming only the parameters would leave it outside the
Agreement Hash.
11. The register's public key material, as a COSE Key Set carrying
at least one claim-encryption key and at least one partial-
attestation-signature key, each with its arp-key-status and arp-
key-validity.
12. The response window after which a register is recorded
unresponsive.
13. The per-principal per-subject query budget of Section 8.1 and
the interval over which it is measured.
14. Any per-subject ceiling under Section 8.1.
15. The ledger-head notarisation interval of Section 5.18.
16. The Transparency Service of Section 5.18.
17. The artefact retention period of Section 5.15.3.
18. The read rate limit of Section 7.4.4.
19. The notarisation polling bound of Section 7.5.2.
20. The authority origin of the reconciliation server the Agreement
authorises.
Hillier Expires 26 April 2027 [Page 93]
Internet-Draft ARP October 2026
21. At least one Audit Identity under Section 5.20.
22. The Register Operator's own read key.
23. Whether the Per-Register Claim Projection must carry the
Requester-Binding Class.
24. The audit right over the query-budget counter of Section 8.2.
25. The reserved proportion of any per-subject ceiling and its per-
principal sub-budget.
26. The response freshness tolerance of Section 7.4.3, which is the
backward bound only. It MUST be at least sixty seconds, and
MUST NOT exceed the effective ledger-head notarisation interval
of Section 5.18 or sixty seconds, whichever is longer, that
interval being the shortest item 15 any Bilateral Register
Agreement the deployment holds declares. The floor is stated
because the bound runs backward from the reader's receipt of the
response and the response was produced before that instant: a
tolerance below the transit and clock disagreement between the
two parties rejects every honest response, and a tolerance of
zero rejects all of them, which is a denial of service a
deployment can declare itself into without any party
misbehaving. Sixty seconds is the figure this document fixes
for the forward bound of this test and of the two others that
bound a party against another's clock over a message it has just
received, so using it as the floor makes the narrowest
admissible interval symmetric. A fourth test, the witness
observation window of Section 5.23.2.4, bounds a pair of clocks
over an artefact published on an interval rather than over a
message in flight; its forward bound is the greater of sixty
seconds and twice that interval, and sixty seconds is its floor
in both directions for the reason it is the floor here. The
forward bound is that fixed sixty seconds and is not negotiable
per Agreement: a forward bound each deployment set for itself
would restore the untestable case the fixed one exists to close.
Bounding the ceiling against this Agreement's own item 15 would
admit a tolerance longer than the interval the deployment
notarises at, and so a response naming a head the reader could
already know to be superseded. Where that interval is itself
shorter than sixty seconds the floor governs, a ceiling below a
floor being a term no deployment can declare, and such a
deployment trades the supersession property for liveness
knowingly: it notarises more often than the window in which a
reader will accept a response, so a response naming a superseded
head is admissible by exactly the difference. A deployment that
wants both notarises no more often than sixty seconds.
Hillier Expires 26 April 2027 [Page 94]
Internet-Draft ARP October 2026
27. The Witness Set of Section 5.23.2, which MAY be empty.
28. The Witness Quorum of Section 5.23.2.
29. OPTIONALLY, an audience constraint under Section 5.15.1.
30. The regulator read keys of Section 7.4.1, or the means by which
they are resolved from the trust anchor of item 5, together with
the means by which key material for items 21, 22, 27 and 30 is
retrieved. A Witness Entry carries a key thumbprint, and a
thumbprint is not key material, so without this a relying party
holding a Head Consistency Statement has no defined way to
obtain the key that verifies it.
31. Whether partial attestations may be re-invoked under
Section 5.21.
32. Whether the Register Operator notifies corrections to records it
has attested, and the endpoint at which it does so, which is
what makes the register-record-correction trigger of
Section 5.21 reachable.
33. The Coverage Probe allowance of Section 5.21.3: the number of
probes an Audit Identity may commission against that register
per interval, and the interval, as a two-element array of
unsigned integers.
Items 26, 27, 28, 30, 31, 32 and 33 are new in this revision; item 29
is carried from -03 in a new position. Three of the seven, items 26,
30 and 31, were already relied on elsewhere in this document while
sitting outside the Agreement Hash. Section 7.4.3 obliges a
deployment to declare a response freshness tolerance in its Bilateral
Register Agreements; that is item 26. Section 7.4.1 obliges an
Agreement to declare the keys under which a regulator reads, and item
5's regulator-identity-provider trust anchor is not a key; that is
item 30. In both cases two deployments could agree on every item the
Agreement Hash committed to, differ on the term, and compute the same
Agreement Hash -- an Agreement Hash that does not cover a term the
Agreement is required to carry. Section 5.21 makes re-invocation of
partial attestations conditional on what the applicable Agreements
permit without making that permission a declared item; that is item
31. Items 27 and 28 specify the witness quorum Section 7.4.3 names
and earlier revisions declined to fix. Items 32 and 33 are terms
this revision creates rather than terms it moves inside the Agreement
Hash: item 32 is what makes the register-record-correction trigger of
Section 5.21 reachable, and item 33 is the probe allowance
Section 5.21.3 meters against.
Hillier Expires 26 April 2027 [Page 95]
Internet-Draft ARP October 2026
*An Agreement computed under an earlier revision does not compute the
same Agreement Hash under this one.* The Agreement Hash covers seven
items it did not cover before -- 26, 27, 28, 30, 31, 32 and 33 -- and
Section 5.23.3 now fixes the CBOR type of every item and the ordering
within every set-valued one, so the value changes for every Agreement
even where no negotiated term has changed. Agreements MUST be
recomputed, and a deployment holding a Bilateral-Register-Agreement
Hash recorded before this revision MUST treat it as naming an
Agreement under the earlier item list rather than as a value
comparable with one computed under this section. Comparing the two
is the Bilateral-Register-Agreement drift of Section 8.5, and a
deployment that does not recompute will observe drift where none
exists.
5.23.2. Witness Set and Witness Quorum
Section 7.4.3 establishes that an empty result is falsifiable to the
extent that its reader holds head-consistency evidence for the served
chain from an observer independent of the responding service, and
that head evidence obtained only from that service bounds nothing.
It states the preference -- a witness countersignature over the head,
or, failing that, an independently anchored head digest -- without
saying how many countersignatures, from whom, or what makes two of
them two rather than one. This section says.
5.23.2.1. Witness Entries
A *Witness Set* is a set of zero or more Witness Entries. Each
Witness Entry is a CBOR array of exactly three elements, in this
order and not nested:
1. the Audience Member Identifier, as Section 5.15.1 defines it;
2. the Verification Method Reference, as Section 5.15.1 defines it;
and
3. an *Operating-Party Identifier*: an Authority Origin naming the
party that controls the witness.
Section 5.15.1 encodes those first two as a two-element array. Here
they are the first and second elements of a three-element array and
are not wrapped in one, because a Witness Entry is carried both in
the Agreement Hash of Section 5.23.3 and in the Policy Parameters
Document of Section 7.4.1, and two readings of one shape would let
those two artefacts disagree about a set they are both supposed to
describe.
Hillier Expires 26 April 2027 [Page 96]
Internet-Draft ARP October 2026
Two Operating-Party Identifiers are *distinct* where they differ
after normalisation under Sections 6.2.2 and 6.2.3 of [RFC3986].
Comparison is over the normalised form and is otherwise bytewise.
Without a stated normalisation https://acme.example and
https://ACME.example/ are distinct to one implementation and
identical to another, and whether a quorum is met turns on which.
A Witness Entry's Operating-Party Identifier MUST NOT be that of the
reconciliation server, of the Transparency Service of Section 5.18,
of any party controlling either, of any party controlled by either,
or of any party under common control with either, and no two Witness
Entries counted toward one quorum may be under common control with
each other. The first exclusion runs in every direction because
running it upward alone excludes nothing that matters: a
reconciliation server that incorporates three subsidiaries, declares
three distinct Operating-Party Identifiers and satisfies a quorum of
three controls every observation the quorum is composed of, and the
fork Section 7.4.3 is concerned with stays invisible while the quorum
reports it as checked. The second exclusion is there because the
rationale of this section is observer diversity and not identifier
diversity: three witnesses that are three subsidiaries of one
unrelated parent declare three distinct Operating-Party Identifiers,
pass the distinctness test as a verifier computes it, and are one
observation reported three times. The Register Operator of the
addressed register, and any operator of a secondary store under
Section 5.18.1, are excluded on the same ground.
5.23.2.2. Head Consistency Statements
A *Head Consistency Statement* is a COSE_Sign1 by a witness, under
the media type registered in Section 10.2, carrying the arp-witness-
identifier header parameter registered in Section 10 in its protected
header, whose payload is the deterministically encoded CBOR array,
under Section 7.1, of:
1. the text string arp-head-consistency-v1;
2. the Entry Sequence Number of the head covered;
3. the Self-Entry Hash of that entry;
4. the Statement Timestamp of the Ledger Head Statement the witness
observed, in the form of Section 5.14; and
5. the *Witness Observation Time*, being the time the witness
produced this Statement, in the same form.
Hillier Expires 26 April 2027 [Page 97]
Internet-Draft ARP October 2026
Item 5 exists because a COSE_Sign1 is not dateable from its own
bytes, so a freshness rule over a Statement carrying no time is a
rule no verifier can apply. Section 5.18 adds a Statement Timestamp
to the Ledger Head Statement for the same reason.
5.23.2.3. Witness Linkage Segments
A *Witness Linkage Segment* is a COSE_Sign1 by a witness, under the
media type registered in Section 10.2, carrying the arp-witness-
identifier header parameter registered in Section 10 in its protected
header, whose payload is the deterministically encoded CBOR array,
under Section 7.1, of:
1. the text string arp-witness-linkage-v1;
2. the Authority Origin of the reconciliation server whose
Settlement-Layer Ledger the Segment covers, as a text string,
normalised as Section 5.23.2.1 normalises an Operating-Party
Identifier, so that equality is a test a verifier computes rather
than one it decides and a Segment cannot be presented as evidence
about a Ledger it was not taken over;
3. the Entry Sequence Number of the lowest entry the Segment covers,
as an unsigned integer;
4. the Entry Sequence Number of the highest entry it covers, as an
unsigned integer;
5. the ordered array, lowest Entry Sequence Number first, of the
linkage array of Section 7.4.2 for each entry in that inclusive
interval, each a four-element array of the Entry Sequence Number
as an unsigned integer and the Prior-Entry Hash, the Self-Entry
Hash and the Signing Input Digest of that entry's Entry
Signature, each as a byte string; and
6. the time the witness produced this Segment, in the form of
Section 5.14. It is present for the reason item 5 of
Section 5.23.2.2 is present: a COSE_Sign1 is not dateable from
its own bytes.
A Segment MUST cover at least one and at most *one thousand* entries.
The cap is what makes the artefact bounded independently of how often
a witness observes or how fast a Ledger is appended to, both of which
this document leaves to a deployment; a witness with more entries to
cover publishes consecutive Segments rather than one larger one.
Hillier Expires 26 April 2027 [Page 98]
Internet-Draft ARP October 2026
A Witness Entry names one Ledger. A party observing more than one
MUST appear as one Witness Entry per Ledger, under a distinct
Operating-Party Identifier and so a distinct Authority Origin,
because the addressing below is by Entry Sequence Number alone and
two series on one origin would give one sequence number two Segments
and no conforming answer.
Item 3 of a Segment MUST be one greater than item 4 of the Segment
the witness published before it, or, in the first Segment it
publishes for a Ledger, the Entry Sequence Number the witness elects
to attest from. The lowest entry a witness's first Segment for a
Ledger covers is that witness's *Attestation Floor* for it, and a
witness chooses that value when it begins publishing: one that begins
observing a Ledger at entry n attests from n and makes no claim below
it, which is what lets a witness join a Ledger of any length without
signing its history.
*A witness MUST publish Segments that together cover every Entry
Sequence Number from its Attestation Floor to the head named by the
most recent Head Consistency Statement it has published for that
Ledger.* The obligation is stated as coverage rather than per
observation so that an interval in which nothing was appended obliges
nothing: Section 5.18 republishes the Ledger Head Statement once per
notarisation interval and not on every append, and a Statement
covering a head already covered needs no further Segment. A
Statement whose head the witness's Segments do not reach is a
Statement no relying party can use for the second branch of
Section 5.23.2.4; the first branch needs no Segment.
A witness MUST serve, at /.well-known/arp-witness-linkage/{n} on the
Authority Origin of its Operating-Party Identifier, where {n} is an
Entry Sequence Number, the single Segment whose interval contains n,
and MUST answer 404 where it has published none covering n, which is
the answer for every n below its Attestation Floor. It MUST serve
its most recently published Segment at /.well-known/arp-witness-
linkage. Each response carries exactly one Segment under the media
type registered in Section 10.2. A witness MUST serve the same
Segment for a given Entry Sequence Number on every request, and MUST
serve Segments to any party without authentication, for the reason
Section 5.23.2.4 gives for serving Head Consistency Statements that
way: an artefact obtainable only through the party it is evidence
about is that party's selection.
A relying party assembles an interval by requesting the Segment
containing the head a response names and then the Segment containing
one above each Segment's item 4, until one covers the head a Head
Consistency Statement names. It MUST stop and treat the interval as
uncovered on a 404, on a Segment whose item 3 is not one greater than
Hillier Expires 26 April 2027 [Page 99]
Internet-Draft ARP October 2026
the item 4 of the Segment below it, or on a Segment carrying a
signature that does not verify. The first Segment it fetches has no
Segment below it and is subject only to the last of those.
Addressing per entry rather than per collection is what makes the
cost of assembling an interval proportional to the interval rather
than to the witness's publication history; the interval itself is
unbounded, so a relying party MAY decline to assemble one longer than
it is prepared to fetch and holds no evidence from that witness where
it does.
A witness MUST retain and serve every Segment it has published for a
Ledger for as long as it publishes Segments for that Ledger, and for
at least one year after its last publication for it. The period is
stated against the witness's own publication history because a
witness is party to no Bilateral Register Agreement and cannot
compute the retention period of Section 5.15.3. A relying party that
cannot obtain the Segments covering an interval holds no evidence for
that interval from that witness, which is the same outcome as an
unreachable origin.
Two Segments by one witness for one Ledger whose intervals intersect,
and whose linkage arrays differ at any entry in the intersection, are
a *witness equivocation*. A relying party holding both MUST NOT count
that witness toward a quorum under Section 5.23.2.4. Detection is
opportunistic in the way Section 5.18 says detection of two entries
at one Entry Sequence Number is opportunistic: the addressing above
returns one Segment per entry, so a party sees a pair only where it
retained an earlier Segment, or compared with another party, and no
single request reveals one. What the rules above establish is not
that equivocation is caught but that it is the *only* way a witness
can present two chains over one interval, since a conforming witness
publishes each interval once and serves one Segment for each entry.
That is the property the append-only claim of Section 5.23.2.4 rests
on, and its enforcement is an audit obligation rather than a
verifier-side test.
A Segment carries no Reconciliation Hash, no Claim Hash and no
structural metadata, because a linkage array carries none. What its
unauthenticated publication adds over the entitled read of
Section 7.4.2 is set out in Section 9.
Hillier Expires 26 April 2027 [Page 100]
Internet-Draft ARP October 2026
5.23.2.4. The quorum rule
The *Witness Quorum* is an integer t with 0 <= t <= n, where n is the
cardinality of the Witness Set. A Witness Set MUST contain at least t
entries with pairwise distinct Operating-Party Identifiers; an
Agreement whose Witness Set does not is non-conforming, and a
deployment MUST NOT address a register under it. Without that
constraint an Agreement declaring three entries under one operating
party and t of three is well formed, satisfiable by nobody, and every
empty result served under it is permanently unfalsifiable with no
conformance test firing.
A relying party holds sufficient head-consistency evidence for an
empty result under Section 7.4.3 when it holds Head Consistency
Statements from at least t Witness Entries where:
* each verifies under the key material declared for that entry;
* the t entries have *pairwise distinct Operating-Party
Identifiers*;
* the t entries have *pairwise distinct Verification Method
References*, and a relying party MUST reject a set in which two
entries resolve to the same key. Distinctness of the Operating-
Party Identifier alone does not establish that two entries are two
observations: two entries declaring one key under two Operating-
Party Identifiers are satisfied by a single COSE_Sign1, and a
relying party applying only the previous condition counts one
signature twice and reports a quorum of two met by one signer.
That failure is mechanical and locally checkable, which
distinguishes it from the declared-independence limit
Section 5.23.4 concedes and cannot close: a verifier cannot test
whether two named parties are truly independent, and it can always
test whether two entries name one key;
* each covers the head the response names, that is, item 2 of the
Statement equals the response's as-of-sequence-number and item 3
equals the Self-Entry Hash that response names; or covers a head
at a higher Entry Sequence Number *and* the relying party
additionally holds the Witness Linkage Segments of
Section 5.23.2.3 covering the two, *obtained from that witness's
own origin and not from the responding service*, and has verified
all six of:
Hillier Expires 26 April 2027 [Page 101]
Internet-Draft ARP October 2026
1. that each Segment verifies under the same key material as the
Statement, carries the same arp-witness-identifier, and
carries as its item 6 a time no later than the Witness
Observation Time of that Statement, so that the chain and the
head are one witness's observation, not two parties', and not
one witness's later account of an earlier interval;
2. that item 2 of each names the Authority Origin of the
responding reconciliation server;
3. that item 3 of each Segment above the lowest it holds is one
greater than item 4 of the Segment below it, and that between
them they cover every Entry Sequence Number from the named
head to the head the Statement covers, inclusive. A span
covered by one Segment satisfies this on its second clause
alone;
4. that the Self-Entry Hash of the linkage array at the
Statement's Entry Sequence Number equals item 3 of that
Statement;
5. that the Self-Entry Hash of the linkage array at the named
head equals the one the response names; and
6. that the linkage array at each sequence number in that
interval above the named head carries, as its Prior-Entry
Hash, the Signing Input Digest that the linkage array of the
entry below it reports. The named head is the bottom of the
interval, the entry below it is outside the Statement's
coverage, and check 5 is what pins that end.
A relying party holding two Segments from one witness that
equivocate under Section 5.23.2.3 MUST NOT count that witness
toward the quorum, whichever branch it would otherwise satisfy.
The linkage array carries that digest as its fourth element
precisely so this condition is computable by the party required to
compute it: a Signing Input Digest is taken over the
Sig_structure, so neither the protected header nor the payload of
the entry below is recoverable from a sequence number and three
hashes, and the substitution a reader might reach for instead is
the one the next sentence forbids. Those last two values are
digests over different preimages -- Section 5.18 takes a Self-
Entry Hash over the entry array with two positions nulled and a
Prior-Entry Hash over a Sig_structure -- so a verifier MUST NOT
test them for equality against each other; and
Hillier Expires 26 April 2027 [Page 102]
Internet-Draft ARP October 2026
* each carries a Witness Observation Time no earlier than sixty
seconds before the Statement Timestamp of item 4 and no later than
the greater of sixty seconds and twice the effective ledger-head
notarisation interval after it, that interval being the shortest
any Bilateral Register Agreement the deployment holds declares,
per the direction rule of Section 5.15.3. The sixty seconds is
the allowance this document makes wherever one party's clock is
tested against another's, here the witness's against the
reconciliation server's: with no allowance a witness whose clock
is a second slow fails this condition on every Statement it
publishes, permanently and with no party misbehaving, which is the
case item 26 of Section 5.23.1 floors the response freshness
tolerance to avoid. The forward bound is floored for the same
reason: a deployment notarising every few seconds would otherwise
admit a window of a few seconds against a clock this document does
not synchronise, and a witness running slightly fast would fail on
every Statement it published. Section 8.7 gathers the clock
bounds this document sets. A witness whose Statements fall
outside this window satisfies no condition of this rule and so
counts toward no quorum, which is the outcome Section 8.8 gathers
for every other way a witness can fail to contribute.
A witness MUST publish its Head Consistency Statements at /.well-
known/arp-head-consistency on the Authority Origin of its Operating-
Party Identifier, most recent first, under the media type registered
in Section 10, and MUST serve them to any party without
authentication. The Operating-Party Identifier is for this reason an
Authority Origin and not a bare name: an identifier that names a
party without locating it cannot be the route by which the artefact
is obtained.
*A relying party MUST obtain Head Consistency Statements from the
witnesses' own origins, and MUST NOT accept for quorum purposes a
Statement obtained from the responding service.* Until this revision
the document specified the artefact, the quorum arithmetic and the
freshness window, and specified no channel at all, which left the
obvious implementation: the responding service hands over the witness
statements alongside its response. That implementation satisfies
every condition above. The witness signature stops the service
forging a Statement and does nothing to stop it choosing which ones
to pass on, and under exactly the fork this mechanism exists to
detect, an operator serving two branches hands each reader the
statements of the witnesses it fed that branch. Every check passes
on both branches and the quorum is met on both.
This is the whole of the artefact's value and it was the one thing
not stated. A Head Consistency Statement obtained from the party it
is evidence about is not independent evidence; it is the responding
Hillier Expires 26 April 2027 [Page 103]
Internet-Draft ARP October 2026
service's own selection, countersigned. Where a witness origin is
unreachable, the relying party holds fewer than t Statements and MUST
act under Section 7.4.3 accordingly, rather than accepting a
substitute from the service.
*The chain requirement is what makes the artefact worth its name, and
the requirement that the Segments come from the witness is what makes
the chain evidence.* A witness signature over a head at a higher
sequence number is, on its own, evidence about whatever branch that
witness was served, which may not be the reader's: a fork at disjoint
sequence numbers is precisely a pair of heads neither of which
contradicts the other. So the two observations have to be put on one
chain, and the chain has to be one the responding service did not
write.
Anchoring the ends of a service-supplied chain does not do it, and
the arithmetic is worth stating because it is not obvious. The
condition anchors two Self-Entry Hashes, one signed by the witness at
the top of the span and one named by the response at the bottom, and
then walks a chain over two other positions, the Prior-Entry Hash and
the Signing Input Digest. No anchored value sits in a position the
chain reads. The reader cannot recompute any value it does read, for
the reason the previous paragraph gives. And the lower anchor is the
response's own claim, so it constrains the service against itself and
nothing else. A service supplying the arrays therefore supplies
every value the chain is made of, and an equality between two values
one party supplies is not evidence about that party: it can serve the
Self-Entry Hash the witness published at the top, its own values in
every other position, and satisfy each part of the condition.
Extending the span makes that easier rather than harder, since every
interior array is two further values the condition constrains only
against their neighbours.
Anchoring both ends does better and does not reach. Where the lower
anchor is a value in a position the chain reads and comes from
somewhere other than the responding service, the chain values of a
three-array span are determined, and only those: the interior Self-
Entry Hash is constrained by neither anchor nor chain even there. A
span of four is not: the two arrays between the ends are constrained
only against each other, and every further entry adds another such
pair. The condition places no bound on the span, and the span is the
distance between a head a witness happened to observe and a head a
response happens to name, so it is not a quantity the relying party
controls.
Segments served by the witness bound the freedom by a different
route: every value the chain is made of was observed and signed by a
party that is not the one being checked, the covering requirement of
Hillier Expires 26 April 2027 [Page 104]
Internet-Draft ARP October 2026
Section 5.23.2.3 leaves no Entry Sequence Number in the interval that
a service supplies, and the two anchors become checks that the
witness's chain is the one the Statement and the response are about.
*What that buys and where the residue is.* A witness reads the Ledger
from the reconciliation server, so a witness is not an independent
observer of the entries; it is an independent _recorder_ of what it
was served, at a time it stamps and under a signature it cannot
revise. The property the Segments deliver is therefore append-only
rather than absolute: a conforming witness publishes each interval
once and serves one Segment per entry, so an operator rewriting an
interval that witness has covered can only do so with a witness that
equivocates, and Section 5.23.2.3 states both what that costs the
witness and why detecting it is opportunistic rather than a verifier-
side test. An operator that rewrites an interval before any witness
has covered it, or that serves a rewritten chain to a witness setting
its Attestation Floor above the rewrite, obtains a witness-signed
chain over the rewrite. What bounds that is witness diversity and
observation frequency, both of which the Witness Set and the
notarisation interval already govern, and it is the same residue
Section 5.23.4 concedes for declared independence rather than a new
one. A Statement covering the named head exactly needs no Segment,
because there is nothing to link.
The window in the fifth condition is measured from the Statement
Timestamp of the Ledger Head Statement and not from the Entry
Timestamp of the head, and it is two intervals and not one, because
Section 5.18 republishes the Ledger Head Statement once per
notarisation interval and not on every append. An entry appended
just after a publication is not published until one interval later; a
window of one interval measured from that entry's own timestamp is
already closed when the witness first sees the head, and no
conforming Statement could exist for it.
The distinctness requirement is the substance of the rule.
Countersignatures from witnesses under one operating party are one
observation reported t times, and a quorum satisfied by them is a
quorum in arithmetic only: the equivocation Section 7.4.3 is
concerned with becomes observable when two independent observers
compare heads, and two instances of one observer are not two
observers.
Hillier Expires 26 April 2027 [Page 105]
Internet-Draft ARP October 2026
5.23.2.5. Discovery
A relying party is not a party to any Bilateral Register Agreement
and holds only the hashes of those Agreements, so a quorum declared
only inside an Agreement is a test the party required to run it
cannot read. The Policy Parameters Document of Section 7.4.1
therefore carries the effective Witness Set and the effective Witness
Quorum, and a relying party evaluates the quorum against that
document.
Where a deployment holds more than one Bilateral Register Agreement,
the effective Witness Set is the intersection of the Witness Sets
every such Agreement declares and the effective Witness Quorum is the
largest any of them declares, per the direction rule of
Section 5.15.3. Two Witness Entries are *equal for the purpose of
that intersection when their Operating-Party Identifiers are equal
and their Verification Method References are equal*, and the
intersection carries, for each such pair, the entry as the Agreement
with the lexicographically least Agreement Hash declares it.
Stating the relation is not pedantry. Taken over whole entries, the
intersection empties on any difference in the first element -- an
Audience Member Identifier written two ways for one witness -- and
this section then obliges a conforming deployment to stop serving
reads entirely. Taken over the Operating-Party Identifier alone, two
entries declaring different keys for one party merge, and a relying
party accepts a Head Consistency Statement under key material only
one of the two Agreements declared. Both readings are available from
the bare word "intersection", one produces an outage and the other
produces an unauthorised key, and a deployment cannot be conforming
under both.
The effective Witness Set MUST contain at least the effective Witness
Quorum entries with pairwise distinct Operating-Party Identifiers.
Where it does not, the deployment is non-conforming and MUST NOT
serve reads under Section 7.4.3. The per-Agreement constraint of
Section 5.23.2.4 does not reach this: two Agreements each declaring
two entries and a quorum of two, with no entry in common, are each
conforming and together produce an empty effective set under a quorum
of two, which is the unsatisfiable quorum that constraint exists to
forbid.
Hillier Expires 26 April 2027 [Page 106]
Internet-Draft ARP October 2026
5.23.2.6. Where the quorum is zero
A Witness Quorum of 0, which a Witness Set of zero entries requires,
declares that no witness evidence is available. A relying party
acting on an empty result served under an effective quorum of 0
SHOULD instead hold an independently anchored head digest as
Section 7.4.3 provides, and MUST NOT treat the absence of a witness
requirement as evidence that the head is uncontradicted. A
deployment declaring 0 is making a statement about what its empty
results can be checked against, in a term a relying party can read,
rather than leaving a reader to infer it.
5.23.3. The Agreement Hash
Each Bilateral Register Agreement carries an Agreement Hash: the
SHA-256 digest over the deterministically encoded CBOR array, under
Section 7.1, of the items of Section 5.23.1 in the order given there.
The array has *exactly thirty-three elements*. The reconciliation
server and the Register Operator compute it independently and MUST
obtain the same value.
Determinism under Section 4.2.1 of [RFC8949] fixes how a given value
is encoded. It does not fix which CBOR type an item takes, nor the
order of elements within an item that is a set, and two parties that
differ on either compute different digests from identical negotiated
terms. Since Section 8.5 suspends reconciliation on a deviation,
that is an outage and not a warning. The types are therefore fixed
here.
+========+=======================================================+
| Item | CBOR encoding |
+========+=======================================================+
| 1, 2, | array, sorted in bytewise lexicographic order of the |
| 21, | deterministic CBOR encoding of each element |
| 27, 30 | |
+--------+-------------------------------------------------------+
| 3 | three-element array, in the class order of |
| | Section 5.22, each element that class's equivalence |
| | list *in the declared preference order and not |
| | sorted* |
+--------+-------------------------------------------------------+
| 4 | four-element array: transport identifier, endpoint |
| | URI and framing identifier, each a text string, and |
| | the sorted array of COSE algorithm identifiers of the |
| | encryption construction |
+--------+-------------------------------------------------------+
| 5, 8, | text string |
| 16, 20 | |
Hillier Expires 26 April 2027 [Page 107]
Internet-Draft ARP October 2026
+--------+-------------------------------------------------------+
| 6 | URI, as a text string |
+--------+-------------------------------------------------------+
| 7 | three-element array: the statutory-regulator-access |
| | scope as a text string, and the per-jurisdiction |
| | permitted-read-field and permitted-read-predicate |
| | sets, each a sorted array of two-element arrays of |
| | the jurisdiction identifier and the sorted set for it |
+--------+-------------------------------------------------------+
| 9, 12, | unsigned integer, seconds |
| 15, | |
| 17, | |
| 19, 26 | |
+--------+-------------------------------------------------------+
| 10 | two-element array: the profile identifier as a text |
| | string, and the array of profile-obliged values *in |
| | the order that profile enumerates them* |
+--------+-------------------------------------------------------+
| 11, 22 | COSE Key Set, its keys sorted in bytewise |
| | lexicographic order of the deterministic CBOR |
| | encoding of each key |
+--------+-------------------------------------------------------+
| 13 | two-element array: the budget as an unsigned integer |
| | count, and the interval in seconds as an unsigned |
| | integer |
+--------+-------------------------------------------------------+
| 14, 28 | unsigned integer |
+--------+-------------------------------------------------------+
| 18 | two-element array: the permitted request count as an |
| | unsigned integer, and the interval in seconds as an |
| | unsigned integer |
+--------+-------------------------------------------------------+
| 23, | boolean |
| 24, 31 | |
+--------+-------------------------------------------------------+
| 32 | two-element array: a boolean, and the endpoint URI as |
| | a text string or null |
+--------+-------------------------------------------------------+
| 33 | two-element array of unsigned integers: the probe |
| | allowance and the interval in seconds |
+--------+-------------------------------------------------------+
| 25 | two-element array: the reserved proportion as a CBOR |
| | decimal fraction, and the per-principal sub-budget as |
| | an unsigned integer |
+--------+-------------------------------------------------------+
| 29 | two-element array: the maximum cardinality as an |
| | unsigned integer or null, and the permitted member |
| | class as a text string or null |
Hillier Expires 26 April 2027 [Page 108]
Internet-Draft ARP October 2026
+--------+-------------------------------------------------------+
Table 2
Every item that is a set is encoded as a CBOR array sorted in
bytewise lexicographic order of the deterministic CBOR encoding of
each element. This document already requires that ordering of the
Audience Set, of the algorithm array of Section 7.4.1 and of the
origin array of Section 7.5.3, and for the same reason: an unordered
set gives one Agreement as many hashes as it has permutations. Items
3 and 10 are the exceptions and are called out in the table as such,
because each is a *sequence* rather than a set: Section 5.22 declares
an ordered equivalence list whose order is the preference, and item
10 takes its order from the profile that enumerates the values.
Sorting either would discard the meaning it carries, and a change of
order in either would then leave the Agreement Hash unmoved.
An item that is absent, inapplicable or empty is encoded as CBOR
null, and the element is present in the array regardless. *Items 14,
25, 27 and 29 are the only items that may be absent*: 14 and 25 where
the Agreement sets no per-subject ceiling, 27 where the Witness Set
is empty, and 29 because it is OPTIONAL. Item 25 is null whenever
item 14 is. An empty Witness Set is encoded as CBOR null and not as
an empty array. Every other item MUST be present and MUST NOT be
null. Encoding an absent per-subject ceiling as null, as zero, or by
omitting the element are three readings of one sentence, and all
three produce different Agreement Hashes.
The order is fixed by the numbering of Section 5.23.1 and by nothing
else. An implementation MUST NOT derive it from the order in which
terms appear in the negotiated instrument, from any serialisation the
parties exchange, or from an alphabetisation of the item names.
Earlier revisions of this document specified the digest over "its
canonicalised content", which named no order and so did not make
independent computation of one value possible.
A change to any item changes the Agreement Hash, and Section 8.5
suspends reconciliation against a register whose Agreement Hash
deviates from the one committed at the start of a reconciliation
event. Items 11, 22, 27 and 30 carry key material and witness
membership, which change under ordinary operation -- a rotation under
the upgrade path of item 3, the addition of a witness -- so an
Agreement Hash change is a renegotiation event and the parties MUST
agree the new Agreement Hash before the operation that causes it. A
deployment that rotates first and renegotiates afterwards has
suspended its own reconciliation, by its own drift rule, at the
moment its upgrade path was exercised.
Hillier Expires 26 April 2027 [Page 109]
Internet-Draft ARP October 2026
5.23.4. What a Bilateral Register Agreement does not establish
An Agreement is a declaration by two parties. It is not evidence
that what it declares is true.
The Operating-Party Identifiers of Section 5.23.2.1 are declared, not
proven. Section 5.23.2.1 excludes a witness under the control of the
responding service, under common control with it, or controlling it,
and that exclusion is normative; what this document supplies no
mechanism for is *detecting a false declaration*. Two witnesses under
common control that each declare a distinct Operating-Party
Identifier satisfy the distinctness test as a verifier can compute
it, and a relying party comparing the two identifiers sees two
parties. The requirement is worth stating regardless, because a
party that declares an independence it does not have has made a false
attributable claim rather than benefited from an unexamined silence,
and because an Audit Identity under Section 5.20 can be given the
Witness Set to examine. But a relying party MUST NOT treat a met
quorum as proof of observer diversity. It is proof that observer
diversity was declared, by a named party, in a term that party can be
held to.
The same holds of item 20, the Authority Origin, which Section 8.1
already requires a register operator to corroborate by publishing an
Authorised-Origin Document, and which is the one declared item this
document does provide a mechanism to check.
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.
Hillier Expires 26 April 2027 [Page 110]
Internet-Draft ARP October 2026
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.
Hillier Expires 26 April 2027 [Page 111]
Internet-Draft ARP October 2026
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 Dogru's,
put to the SCITT mailing list on 20 August 2026.
6. Agentic Principal Reconciliation
The Agent Friend-or-Foe Determination described in the Requester
Identity Binding and Agent Friend-or-Foe Gate above establishes
whether the requester of a reconciliation is friendly. ARP
additionally supports reconciling an agent's principal binding as the
subject of a reconciliation in its own right, so that the question
"does a real, authenticated principal stand behind this agent?" can
itself be answered against authoritative identity registers rather
than asserted.
Hillier Expires 26 April 2027 [Page 112]
Internet-Draft ARP October 2026
A reconciliation over the agent: predicate branch takes as its
Subject Identifier the agent's declared identity (for example its
signature-agent-card key thumbprint or a directory identifier) and as
its Attested Value the principal binding the agent asserts.
Addressed registers for this predicate class are identity and
credential registers -- for example an organisational directory, a
credential-issuer status list, or a national identity register --
each under its own Bilateral Register Agreement. The Combined
Verdict answers whether the asserted principal binding is
corroborated:
* match: the agent's asserted principal binding is corroborated by
the addressed registers; the agent is FRIENDLY with an
attributable principal.
* no-match with divergence axis agent-impersonation-suspected: the
asserted binding is contradicted; the agent is asserting a
principal it is not bound to.
* no-match with divergence axis agent-credential-absent or agent-
principal-unverifiable: no corroborating record exists; the
binding cannot be established and the agent MUST be treated as
ENEMY.
This composition allows a relying party to gate an action not merely
on the presence of an agent signature but on register-corroborated
proof that an accountable principal stands behind it, narrowing the
impersonation surface at the reconciliation layer. The result is a
Reconciliation Output like any other: sealed against a Policy-Version
Hash, written to the Settlement-Layer Ledger without claim or
register content, and re-evaluable if the underlying credential is
later revoked.
7. Encoding
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.
Hillier Expires 26 April 2027 [Page 113]
Internet-Draft ARP October 2026
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.
Hillier Expires 26 April 2027 [Page 114]
Internet-Draft ARP October 2026
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.
Hillier Expires 26 April 2027 [Page 115]
Internet-Draft ARP October 2026
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.ietf-webbotauth-httpsig-protocol], which also defines the key
directory it names. The reconciliation server derives the Agent
Friend-or-Foe Determination from verification of that signature and,
Hillier Expires 26 April 2027 [Page 116]
Internet-Draft ARP October 2026
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.
7.4.1. Request signing profile
[RFC9421] requires an application that uses it to state a profile.
This is that profile. It governs every request to an operation of
Section 7.4.2 and the commissioning request of Section 7.2.
* Every request MUST carry exactly one signature, labelled arp.
* The covered components MUST be @method, @target-uri, and, where
the request carries a body, content-digest as [RFC9530] defines
it, together with the signature parameters created, expires,
nonce, keyid, alg and tag. A request covering fewer MUST be
refused. tag is arp-read for an operation of Section 7.4.2 and
arp-reconcile for the commissioning request of Section 7.2; those
are the only two values, and a server MUST reject a request whose
tag does not match the endpoint it was sent to.
* Covering content-digest is what binds the body. The commissioning
request carries the Canonical Claim, the requested Audience Set
and any asserted principal in its body; a signature that covered
only the target would leave an intermediary free to substitute the
subject or add Audience Members and have the result sealed,
ledgered and notarised as the signed requester's.
Hillier Expires 26 April 2027 [Page 117]
Internet-Draft ARP October 2026
* The nonce MUST be at least 128 bits drawn from a cryptographically
secure random source, base64url-encoded.
* expires MUST be no more than 300 seconds after created. A server
MUST reject a request whose created is more than 300 seconds in
the past or more than 60 seconds in the future, and MUST reject a
repeated nonce from the same keyid within that window. Without
this a captured read request replays indefinitely, which
Section 8.6 closes only for requests that initiate a
reconciliation.
* The permitted signature algorithms are those the deployment
declares for the partial-attestation-signature class in its
Cryptographic-Primitive-Upgrade Path, so that read authentication
rotates with everything else.
* keyid MUST be the JWK thumbprint of the requester's public key,
computed as in [RFC7638]. For an Audience Member it MUST equal
the Verification Method Reference the Output names. For a
regulator, a Register Operator or an Audit Identity it MUST be a
key the corresponding Bilateral Register Agreement declares. For
a witness reading under Section 5.23.2.3 it MUST be the thumbprint
a Witness Entry of Section 5.23.2.1 carries, in a Bilateral
Register Agreement the deployment holds. For a requester
commissioning a reconciliation it is the key that becomes that
requester's Verification Method Reference in the resulting
Audience Set. Key material is retrieved as that agreement
provides, or, for an agent, through the Web Bot Auth directory of
Section 7.3.
* The reconciliation server MUST publish a Policy Parameters
Document at /.well-known/arp-policy-parameters on its Authority
Origin: a COSE_Sign1 by its sealing key, under the media type
registered in Section 10, whose payload is the six-element CBOR
array of: a Publication Timestamp, in the form Section 5.14 fixes;
the array of permitted signature algorithm identifiers, sorted in
bytewise lexicographic order of the deterministic CBOR encoding of
each element; the array of per-predicate entries, each a four-
element array of the predicate, the admitted regime set sorted in
bytewise lexicographic order, the two-element array of the
resolved Verdict Arithmetic and its parameters, and the reliance
interval, the entries themselves sorted by predicate; and the
array of two-element arrays of the identifier and effective time
of every Pattern-Library and Policy-Version transition the server
has applied, sorted by effective time, which Section 5.21.1 relies
on; and the two-element array of the effective Witness Set and the
effective Witness Quorum of Section 5.23.2.5, the Witness Set
sorted in bytewise lexicographic order of the deterministic CBOR
Hillier Expires 26 April 2027 [Page 118]
Internet-Draft ARP October 2026
encoding of each entry; and the two-element array of the response
freshness tolerance of Section 7.4.3 in seconds and the effective
ledger-head notarisation interval that bounds it, each an unsigned
integer.
The sixth element is present for the same reason as the fifth.
Section 7.4.3 obliges *every* reader of a read response to check
that the response time falls within an interval whose backward
bound is a declared tolerance, and declares that tolerance in the
Bilateral Register Agreements. The forward bound of that interval
is the fixed sixty seconds of Section 7.4.3, which every reader
already holds because this document states it, so it is the
backward bound alone that has to be published here. A relying
party is party to no Agreement and holds only their hashes, so the
tolerance every reader must apply was readable only by the parties
who did not have to apply it themselves, which is precisely the
defect the Witness Set element was added to fix.
Without that fifth element a relying party, which holds only
Agreement Hashes, could not evaluate the quorum the same section
obliges it to evaluate.
The Publication Timestamp is first because the rest of the array
is evidence about the reconciliation server, published by the
reconciliation server, under its own key, and a COSE_Sign1 is not
dateable from its own bytes. Two Documents published a year
apart, one of which has had a transition or a Witness Entry
quietly dropped from it, are otherwise indistinguishable to every
party the Document exists to inform. This document already
reached that conclusion twice, for the Ledger Head Statement of
Section 5.18 and for the Head Consistency Statement of
Section 5.23.2.2, and the same reasoning was not carried here.
The reconciliation server MUST submit each published Policy
Parameters Document for notarisation by the Transparency Service
of Section 5.18, under its own media type, within the ledger-head
notarisation interval of that section measured from its
Publication Timestamp, and MUST republish it on that interval
whether or not its contents changed. A Document that changed
without a new Publication Timestamp, or a published Document with
no notarisation inside the interval, is non-conforming.
The obligation to republish unchanged is what makes silence
readable: without it, an operator that has removed a Witness Entry
and an operator that has changed nothing publish the same thing,
and the notarised series has no entry to be missing. A relying
party MUST NOT treat a Policy Parameters Document as current where
its Publication Timestamp is older than twice that interval, and
Hillier Expires 26 April 2027 [Page 119]
Internet-Draft ARP October 2026
MUST refuse to evaluate a quorum against one it cannot date. A
requester is party to no Bilateral Register Agreement and could
not otherwise determine how to sign, and publishing the resolved
parameters removes the regime-shopping probe of Section 5.13 by
making its result available without probing.
* A request that is unsigned, that fails signature verification,
that is outside the freshness window, or that replays a nonce MUST
be refused with 401. A 401 is the one response of this section
that is not signed under Section 7.4.3: its payload would have to
bind a request carrying no nonce and no key identifier, and there
is no requester key to bind it to. A 401 therefore carries no
body, and a requester receiving one has learned only that its own
signature was not accepted.
7.4.2. Read operations
Nine operations are defined, and no read of an Output or of the
Settlement-Layer Ledger by a party outside the reconciliation server
is defined anywhere else in this document. An Audit Identity under
Section 5.20 is entitled to every one of them, unredacted, over
reconciliations addressing the register whose agreement declares it;
the Entitlement clauses below state the other parties and do not
repeat that. The Ledger Head Statement of Section 5.18 is not a read
of the Ledger: it is a published statement about the Ledger, served
without authentication at a well-known URI, and is deliberately
outside this section so that a party holding no entitlement at all
can still observe a head.
* GET /arp/outputs/{reconciliation-hash} returns the sealed
Reconciliation Output. Entitlement: an Audience Member of that
Output; an Audit Identity under Section 5.20 for a reconciliation
addressing its register; and a regulator in scope for that
reconciliation under Section 5.19, whose response is field-
restricted by that section.
* GET /arp/reconciliations/{reconciliation-
identifier}/registers/{register-identifier} returns the Per-
Register Result Set entry concerning that register alone, keyed on
the Reconciliation Identifier the register received in its Per-
Register Claim Projection, since a register never holds a
Reconciliation Hash. Entitlement: the Register Operator of that
register. It is what lets a register see what was recorded of its
own answer. Without it a server could discard a register's signed
match and record register-unresponsive, and the only party holding
the contradicting artefact would have no operation with which to
produce it.
Hillier Expires 26 April 2027 [Page 120]
Internet-Draft ARP October 2026
* GET /arp/outputs returns, for the Outputs whose Audience Set names
the authenticated principal, the Reconciliation Hash, the Reliance
Horizon and the Entry Sequence Number of the reconciliation entry
that records each. It is ordered by that Entry Sequence Number
descending, which is a total order and needs no tie-break. A
since parameter carrying an [RFC3339] UTC time is REQUIRED; a
server MUST return at most 100 entries and MUST carry a next
parameter value in the response where more exist, which the
requester supplies on the following request. Entitlement: any
authenticated principal, as to its own membership only; and an
Audit Identity, as to the Outputs of reconciliations addressing
the register whose agreement declares it, without which an auditor
entitled to Outputs by hash would hold no operation that yields
the hashes.
* GET /arp/continuations/{reconciliation-hash} returns the
Continuation entries of Section 5.18 carrying that Reconciliation
Hash, in Entry Sequence Number order, and no reconciliation entry.
Entitlement: an Audience Member of the Output that Reconciliation
Hash identifies, or a regulator in scope for that reconciliation
under Section 5.19.
* GET /arp/entries/{entry-sequence-number} returns one Ledger entry.
Entitlement: a regulator, subject to Section 5.19; an Audience
Member, for an entry carrying a Reconciliation Hash it is entitled
to; and a Register Operator or regulator requesting the Self-Entry
Hash alone, for the consistency check of Section 5.18, by the
fields=self-entry-hash query parameter. Any requester whose
signature verifies under Section 7.4.1 is additionally entitled to
the four-element array of the Entry Sequence Number, the Prior-
Entry Hash, the Self-Entry Hash and the Signing Input Digest of
that entry's Entry Signature, by the fields=linkage query
parameter, which is what a witness reads to produce the Segments
of Section 5.23.2.3. The projection is additionally available for
a contiguous range, by the OPTIONAL through parameter naming an
Entry Sequence Number at or above the one in the path, the
response carrying the linkage array of every entry from the one in
the path up to and including the lowest of the value in through,
the head bound below, and the highest the server elects to serve.
A server MUST serve at least one thousand entries in one such
response where that many lie in range, which is the Segment cap of
Section 5.23.2.3, so that a witness can produce one Segment from
one read. A response that stops short carries the entries it
served and the requester continues from the next Entry Sequence
Number, so a range longer than a server elects to serve draws no
refusal and no status a shorter one would not have drawn. A
ranged read counts as one request against the limit of
Section 7.4.4, save for the fixed allowance that section makes
Hillier Expires 26 April 2027 [Page 121]
Internet-Draft ARP October 2026
each interval for a witness principal so that a rate limit cannot
void the publication obligation of Section 5.23.2.3. That
allowance does distinguish a witness from another principal, by
the number of reads admitted rather than by the answer to any one
of them, and what it discloses is that the reading key is in a
Witness Set some Agreement the deployment holds declares. That is
a wider set than the effective Witness Set Section 7.4.1
publishes, so the allowance is a disclosure and is recorded as one
in Section 9. Every linkage read is *only for an Entry Sequence
Number at or below the head of the most recently published Ledger
Head Statement*, and a ranged read is bounded at that head in the
same way. A linkage read naming a higher sequence number MUST be
refused with 404 whether or not the entry exists. Without that
bound the projection is a live head oracle: the Ledger is
contiguous, so a requester could binary-search the current head
between publications and poll it for the write rate, which is the
disclosure Section 5.18 publishes the head once per notarisation
interval to prevent. Bounded, the projection carries no
Reconciliation Hash and no structural metadata and discloses
nothing beyond the chain shape below a head that is already
published unauthenticated. It is rate-limited as Section 7.4.4
provides.
* GET /arp/post-seal-records/{post-seal-evaluation-record-hash}
returns the Post-Seal Evaluation Record of Section 5.17.
Entitlement: as for the Continuation entry that carries the hash.
* GET /arp/sweeps/{examined-set-root}/inclusion/{claim-hash} returns
an inclusion proof of that Claim Hash under that Examined-Set
Root. Entitlement: a party entitled to a reconciliation carrying
that Claim Hash. The Statement is keyed on its Examined-Set Root
rather than on its timestamp, which is pinned to whole seconds and
would collide where two triggers fall in one second.
* GET /arp/re-notifications returns the Sovereign Re-Notifications
of Section 5.19.1 whose Notification Timestamp falls in the
interval named by REQUIRED since and until parameters, at most 100
per response under the same next rule. Entitlement: a regulator,
as to notifications addressed to it.
Hillier Expires 26 April 2027 [Page 122]
Internet-Draft ARP October 2026
* GET /arp/sweeps returns the Evaluation Sweep Statements of
Section 5.21.1 whose Evaluation Sweep Timestamp falls in the
interval named by REQUIRED since and until parameters, at most 100
per response under the same next rule. Entitlement: a Register
Operator, a regulator or an Audience Member. Its counts are
deployment-wide aggregates and disclosing them to a party named in
one Audience Set is a real cost, recorded in Section 9; the
Statement is a signature over a fixed array and cannot be served
with fields removed without destroying the signature that makes it
worth serving.
The enumeration is what makes the Entry Sequence Number of a party's
own reconciliation entry reachable. Without it an Audience Member
entitled to that entry under Section 5.18 would have no operation
that maps its Reconciliation Hash to a sequence number, and its only
route to an entitlement this document grants would be the sweep of
GET /arp/entries/{n} that the rate limit below exists to prevent.
7.4.3. Responses
Every response to an operation of Section 7.4.2 or to the
commissioning request of Section 7.2, including every 4xx other than
the 401 of Section 7.4.1, MUST be a COSE_Sign1 by the reconciliation-
server sealing key, under the media type registered in Section 10,
whose payload is the CBOR array
["arp-read-v1", request-binding, status, response-time,
as-of-sequence-number, as-of-self-entry-hash, result]
where:
* request-binding is the SHA-256 digest over the CBOR array of the
request's @method, its @target-uri normalised as in Section 6.2.2
and 6.2.3 of [RFC3986], the request's nonce, and its keyid.
Digesting a normalised binding rather than echoing the target as
sent leaves nothing to disagree about and binds the response to
one requester and one request.
* status is the HTTP status code.
* response-time is the time the response was produced, in the
timestamp form of Section 5.14.
* as-of-sequence-number and as-of-self-entry-hash MUST be those of
the Ledger head at the moment the read was served, and MUST NOT be
those of any earlier entry. A response naming a head lower than
the most recently published Ledger Head Statement is non-
conforming, and a reader MUST reject one: a server free to answer
Hillier Expires 26 April 2027 [Page 123]
Internet-Draft ARP October 2026
against a head it chooses could suppress a supersession
indefinitely by answering truthfully about a stale head, and its
answer would never contradict anything.
* result is the operation's result, an empty array where the
operation is set-valued and nothing matched. On a 404 it is an
empty array. On the 422 or 403 of Section 7.2 it is the
Remediation Advisory, which is the artefact a refused requester
needs; on a 429 it is an empty array.
* For a response to the commissioning request, as-of-sequence-number
and as-of-self-entry-hash are those of the Ledger head at the
moment the response was produced, and the request-binding digest
is taken over a five-element array, the request's content-digest
appended after its keyid.
Signing errors as well as successes is the load-bearing part. A
server that signed only its successes could suppress any continuation
channel by answering 404 or 429 forever, and the party it was
suppressing would hold an unsigned status line: no proof that it
asked, no proof of what it was told, and no way to distinguish
suppression from a hash that names nothing. Binding the response to
the requester's nonce and key, and stamping it with a time, is what
stops a server serving one party's response to another or replaying a
year-old empty result; without those the same bytes verify forever
and against everybody.
A reader MUST check that the request-binding matches the request it
sent, that the as-of-sequence-number is at least that of the most
recent Ledger Head Statement it has seen, and that the response-time
is fresh. The response-time is fresh where it is no earlier than the
instant the reader received the response less the declared tolerance,
and no later than 60 seconds after that instant. A reader MUST
reject a response whose response-time falls outside that interval in
either direction.
The reference instant is the reader's receipt of the response and the
direction is backward, stated here for the reason Section 8.6 gives
for stating them there: a tolerance with no reference instant and no
direction is a test two implementations apply differently to the same
response. The forward bound is stated because response-time is
produced on the responding service's clock and tested against the
reader's, and nothing in this document synchronises the two. Without
it, a response stamped ahead of the reader's clock and a response
produced at the instant it claims are one value to the check, and a
server whose clock runs fast is indistinguishable from one stamping
ahead deliberately. The sixty seconds is the figure this document
already uses wherever one party is bounded against another's clock:
Hillier Expires 26 April 2027 [Page 124]
Internet-Draft ARP October 2026
the reconciliation server against the register's, in the Freshness
Timestamp of Section 8.6, and the server against the requester's, in
the created parameter of Section 7.4.1. Both of those run toward the
server. This is the return direction, and it is the one the document
had not stated. Neither party is required to hold a reference clock:
the rule bounds the disagreement rather than removing it, which is
what a two-clock test can do. A deployment MUST declare that
tolerance in its Bilateral Register Agreements, it MUST be at least
sixty seconds, and it MUST NOT exceed the effective ledger-head
notarisation interval of Section 5.18 or sixty seconds, whichever is
longer, that interval being the shortest any Bilateral Register
Agreement the deployment holds declares, per the direction rule of
Section 5.15.3: a tolerance left to each reader is not a property two
implementations can be tested against; one shorter than the transit
and clock disagreement between the two parties rejects every honest
response, the backward bound running from the reader's receipt and
the response having been produced before it; and one longer than the
notarisation interval would admit a response naming a head the reader
could already know to be superseded. Without those checks a server
may serve a cached response for a repeated request tuple
indefinitely, and the properties below do not hold.
An empty result is therefore an assertion and not an absence: a
signed statement that as of a named head, at a named time, in answer
to this requester's request, there was nothing. A continuation-
supersession entry later found at or below that head contradicts it,
in one operator's own signature.
That contradiction is conditional on the reader and the later
observer having been served one chain, and the condition is load-
bearing. Section 5.18 states that detection of a fork is
opportunistic: an operator publishing to two audiences at disjoint
sequence numbers never emits a colliding pair. Under such a fork the
superseding entry lands on a branch the holder of the empty result
never reads, the at-or-below test never fires, and the assertion
stands uncontradicted for as long as the branches are kept apart. An
empty result is therefore an assertion about a named head on the
chain its reader was served, and it is falsifiable to the extent that
the reader holds head-consistency evidence for that chain from an
observer independent of the responding service.
Head evidence obtained only from that service does not bound this. A
fork at disjoint sequence numbers is invisible from a single vantage
by construction, and the vantage is what is in question: equivocation
is precisely the condition that no single consistent chain explains
two observations, so it becomes observable when two independent
observers compare heads and not before. A relying party acting on an
empty result SHOULD hold head-consistency evidence for the served
Hillier Expires 26 April 2027 [Page 125]
Internet-Draft ARP October 2026
chain from at least one observer independent of the responding
service -- a witness countersignature over the head, or, where no
Witness Set is available, an independently anchored head digest, in
decreasing order of strength. Section 5.23.2 specifies the Witness
Set and the Witness Quorum, so that "at least one observer
independent of the responding service" is a condition a deployment
declares a value for and an implementation can be tested against,
rather than a property each reader decides for itself. What that
quorum does and does not establish is stated in Section 5.23.4: it is
independence declared, not independence proven, and this document
still does not claim to close the gap.
The contradiction is only as tight as the operator's freedom to
defer. A continuation-supersession entry MUST be appended within the
ledger-head notarisation interval of Section 5.18, measured from the
completion of the Evaluation Sweep that produced the superseding
Output -- an event the Evaluation Sweep Statement of Section 5.21.1
dates and signs, and which therefore exists for an immaterial
supersession as much as for a material one. Where the supersession
is the revocation of a Verified Principal Credential and no
superseding Output is produced, the deadline runs from the completion
of the sweep the revocation triggered, which Section 5.21.1 likewise
dates and signs. Measuring from "the material change" would leave
both that case and an immaterial supersession with no start point and
so no deadline. Without a deadline an operator defers every
supersession above the highest head it has ever named and no
contradiction ever arises.
7.4.4. Error semantics
A request that is well-formed and signed but that names a resource
the requester is not entitled to, and a request naming a resource
that does not exist, MUST both be refused with 404. Only an entitled
requester receives 200. Answering 403 for the first and 404 for the
second would turn every endpoint into an existence oracle: a party
could sweep Reconciliation Hashes, or sequence numbers, and learn
what a deployment had done without being entitled to any of it.
The two cases MUST be equivalent under the normalised observation
this section defines, rather than byte-identical, which a conforming
server cannot make them: Section 7.4.3 requires every response to
bind the request and the serving instant, so the request-binding, the
response-time, the As-Of pair and the resulting signature differ
between any two requests whether or not the resource exists. A
requirement of byte equality would be unsatisfiable, and a test
written against it would fail every conforming implementation.
Hillier Expires 26 April 2027 [Page 126]
Internet-Draft ARP October 2026
The normalised observation of a response is that response with
exactly those four values removed. Two responses are equivalent when
their normalised observations are equal. Across the two cases a
server MUST therefore produce the same status, the same media type,
the same set of HTTP header field names, the same set of protected
COSE header parameters, the same empty-result representation, the
same cache directives and the same rate-limit effects, and the signed
payload MUST NOT carry any error discriminator whose value depends on
whether the resource exists. Every value removed by normalisation
MUST still be valid for its own request: normalisation is how two
responses are compared, not a licence to omit a required field or to
carry an existence-dependent discriminator inside one.
A response to either case MUST carry Cache-Control: no-store. A
response bound to a nonce and a serving instant is not reusable by
another requester, and a cache that retained one case and not the
other would reintroduce through intermediaries the distinction the
rest of this section removes.
Two channels survive that rule and MUST be closed with it. A server
MUST charge the rate-limit counter before evaluating entitlement, so
that an unentitled request and a nonexistent one consume the same
budget and a burst of each yields the same sequence of statuses. And
entitlement evaluation MUST NOT be short-circuited: a server MUST
perform the same work for a Reconciliation Hash it does not hold as
for one whose Audience Set does not name the requester, so that the
two do not differ in response time.
Response timing is a separate claim from the requirements above and
MUST be stated separately. Serving both cases from one processing
path is evidence about the design and is not evidence that the two
latency distributions are indistinguishable to an observer. An
implementation that claims resistance to timing-based existence
inference MUST publish the measurement population, the sample count,
the network placement of the measurement, the decision rule and the
acceptance threshold under which the two response classes were
compared. An implementation that makes no such claim is not for that
reason non-conforming: the requirements above are met or not met
independently of it, and conflating the two would let a deterministic
conformance failure be excused as a measurement artefact, or a
measurement result be read as protocol conformance.
The fields=linkage projection of Section 7.4.2 answers 200 for an
entry whose full read the same requester would be refused, and is not
an existence oracle for two reasons that both have to hold. The
Ledger carries a contiguous Entry Sequence Number and Section 5.18
publishes the head unauthenticated, so existence at or below that
head is already public and the projection discloses no fact about
Hillier Expires 26 April 2027 [Page 127]
Internet-Draft ARP October 2026
which entries exist. And the projection is bounded at that published
head, so it cannot answer the one existence question that is not
already public, which is where the head is now. A projection that
widened either -- serving a non-contiguous ledger, or serving above
the published head -- would be an oracle, and neither is permitted.
A server MUST rate-limit these operations, per authenticated
principal, at the most permissive rate any of its Bilateral Register
Agreements declares, and MUST answer 429 when the limit is reached.
The declared rate MUST admit at least one read of each operation per
Reconciliation Hash per reliance interval, so that a limit cannot
silently void the obligation of Section 5.15.2. A server MUST NOT
count against that limit the first sixty ranged linkage reads made in
each effective ledger-head notarisation interval, being the shortest
item 15 any Bilateral Register Agreement the deployment holds
declares, by a principal whose keyid resolves to the key of a Witness
Entry any Bilateral Register Agreement the deployment holds declares,
so that a limit cannot silently void the publication obligation
Section 5.23.2.3 places on a witness. The allowance is a fixed count
outside the declared rate rather than a second rate inside it: item
18 of Section 5.23.1 carries one request count and one interval, and
a per-class rate would be a negotiated term sitting outside the
Agreement Hash. Sixty reads of the thousand entries Section 7.4.2
obliges a server to serve in one of them cover sixty thousand appends
in an interval; a deployment appending faster declares a shorter
interval or a higher rate, which are its own terms and not a third
party's cadence. GET /arp/entries/{n} in particular ranges over the
whole Ledger; unlimited, a party entitled to one consistency check
could sweep for the deployment's entry count, write rate, and the
timing of retroactive bursts, which is disclosure by aggregation of a
surface every individual answer to which is innocuous.
A read served under Section 5.19 with any field redacted MUST NOT
return the Prior-Entry Hash or the Self-Entry Hash of that entry, and
MUST NOT return the Prior-Entry Hash of the entry that follows it,
which is the Signing Input Digest of the redacted entry's Entry
Signature and so covers every field of that entry including the
fields being withheld. The Self-Entry Hash is a digest over the
entry's own fields and carries no blinding value; a reader holding
the leading fields and denied the type-specific block could otherwise
recover the block by search over register subsets, a small
aggregation descriptor set, four binding classes and a bounded
timestamp, and would do so off the audit trail that section imposes.
A redacted field is returned as CBOR null in its position, so that
the array's length is still the length fixed by the Entry Type; a
regulator receiving a redacted entry therefore cannot verify its
chain hashes, which is the price of redaction and is why an
unredacted read is the ordinary case.
Hillier Expires 26 April 2027 [Page 128]
Internet-Draft ARP October 2026
Each read served under this section MUST be recorded in an append-
only access log, retained for the period of Section 5.15.3,
sequenced, chained, headed and notarised as the audit trail of
Section 5.19 is and for the same reason. The log is not the
Settlement-Layer Ledger and MUST NOT be written to it: who asked a
question is not a fact about the reconciliation, and a Ledger that
recorded reads would disclose the pattern of interest in a subject to
every party entitled to read it. The log is readable only by a
regulator under Section 5.19 and by an Audit Identity under
Section 5.20, to which it is disclosed out of band as the policy-
epoch material is; the reasoning that keeps it off the Ledger applies
equally to the log itself.
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.5.1. Registration
The Reconciliation Output MUST be registered as a Signed Statement by
POST /entries as defined in [I-D.ietf-scitt-scrapi], with the HTTP
Content-Type that document requires on that request. A Transparency
Service returns a Location header on both 201 Created and 202
Accepted; an implementation MUST use it in both cases rather than
constructing a polling URL of its own.
Notarising an Output does not enlarge its Audience Set. Registration
places the sealed Output in a log whose retrieval is by EntryID, and
a party that obtains it that way holds it on the terms of
Section 5.15: it may verify the Sealing Signature and read the
Combined Verdict, and it obtains no read under Section 7.4 and no
notice of supersession. A deployment for which that is the wrong
disclosure should not notarise; Section 7.5 is composed permissively
for that reason.
The payload of the Signed Statement MUST be the sealed COSE_Sign1 --
the Reconciliation Output under its Sealing Signature, as produced by
Section 5.16 -- and MUST NOT be the bare Reconciliation Output.
Nesting is what makes the requirements below checkable: a relying
party holding only the bare Output has neither the sealing key
identity nor the Policy-Version Hash the seal committed to, and could
not verify either.
Hillier Expires 26 April 2027 [Page 129]
Internet-Draft ARP October 2026
The Signed Statement is therefore a COSE_Sign1 whose payload is
itself a COSE_Sign1. Its protected header MUST carry:
* the content type application/arp-sealed-reconciliation-
output+cose, registered per Section 10. The outer payload is a
COSE_Sign1 wrapping a Reconciliation Output, not a Reconciliation
Output, and labelling it with the latter's media type would have a
conforming decoder parse a signature envelope as an Output;
* arp-policy-version-hash;
* arp-bilateral-agreement-hash, carrying the array of the Bilateral-
Register-Agreement Hashes of the addressed registers, sorted in
lexicographic byte order as required by Section 7. A
Reconciliation Output aggregates registers under more than one
agreement, and an unordered encoding would make two conforming
implementations produce non-interchangeable Signed Statements.
The outer COSE_Sign1 MUST carry a kid in its protected header, MUST
be signed under a key resolvable through Section 7.5.3, and that
key's Sealing-Key Identifier MUST equal the Sealing-Key Identifier of
the nested Output in both components. A relying party MUST verify
the outer signature and that equality. "Signed by the server that
sealed it" is otherwise not a predicate a relying party can evaluate:
any operator of a conforming server could wrap another server's
sealed Output, sign it under its own resolvable key, and every other
check here would pass, and the Receipt would attribute the statement
to the Transparency Service and to nobody else. Fixing the nested
payload closes a false-policy-version attack; fixing the outer signer
closes a wrong-registrant one.
The arp-bilateral-agreement-hash in the outer protected header MUST
equal the value carried in the nested sealed COSE_Sign1, and the arp-
policy-version-hash in the outer protected header MUST equal the
Policy-Version Hash carried in the nested sealed COSE_Sign1. A
relying party MUST verify the Sealing Signature over the nested
payload, MUST verify that equality, and MUST reject the Signed
Statement where either fails.
The verification key for the Sealing Signature is identified by the
Sealing-Key Identifier of Section 5.14, whose kid component MUST
equal the kid in the protected header of the nested COSE_Sign1, and
is resolved through Section 7.5.3. A relying party that cannot
resolve the Sealing-Key Identifier MUST NOT rely on the notarised
statement.
Hillier Expires 26 April 2027 [Page 130]
Internet-Draft ARP October 2026
Without nesting and this equality the Signed Statement would be a
second and independent envelope: any party holding a valid
Reconciliation Output could register it under a protected header
asserting a policy version it was not sealed under, and a relying
party following Section 7.5.5 would believe that assertion. A
protected header cannot be altered after signing, but it can be false
when signed, and integrity is not correctness.
The payload MUST NOT be the Verifiable Credentials serialisation of
Section 7.6. That form is an interop convenience for relying parties
and is not the notarised object; registering it instead would
notarise a representation whose canonical form is unspecified.
7.5.2. Asynchronous registration
A Transparency Service may register synchronously or asynchronously,
and an implementation MUST support both. This is the most likely
source of divergence between two otherwise conforming
implementations, and is therefore stated as a requirement rather than
left to the referenced document.
On 201 Created the Receipt is available immediately. On 202 Accepted
the response carries a Location header, and the implementation MUST
poll that URL verbatim rather than constructing a path of its own. A
204 No Content means registration is still in progress and MUST NOT
be treated as failure or as a negative result.
A 4xx other than 404 returned synchronously by POST /entries is a
terminal refusal and MUST NOT be retried under the same Signed
Statement; it is the ordinary refusal case and is recorded as such
under Section 5.18.
A 404 Not Found ends polling and MUST NOT be polled further. It
carries two meanings in [I-D.ietf-scitt-scrapi] -- that no Receipt
was found for the specified EntryID, and that an asynchronous
registration has failed and no Receipt will be produced -- and an
implementation MUST distinguish them from the response body where the
service supplies one, because the second is a registration failure
and the first may follow from having polled a URL the Transparency
Service did not issue. Ending polling is not the same as resolving
the outcome: only the second meaning is a terminal refusal for the
purposes of Section 5.18, and a 404 the implementation cannot resolve
to one meaning or the other is recorded as an incomplete
notarisation, not as a refusal.
An implementation MUST honour a Retry-After header where one is
present, MUST NOT poll more frequently than once per second in its
absence, and MUST bound total polling, to the shortest bound any
Hillier Expires 26 April 2027 [Page 131]
Internet-Draft ARP October 2026
Bilateral Register Agreement addressed by the reconciliation
declares; a bound of 300 seconds is RECOMMENDED where the Bilateral
Register Agreement declares none. Exhaustion of the bound MUST be
recorded in a Post-Seal Evaluation Record carrying notarisation-
incomplete per Section 5.17, rather than as either success or
refusal. A Reconciliation Output whose notarisation is incomplete
remains valid under its Sealing Signature; notarisation is an
additional property, not a precondition of validity.
7.5.3. Sealing-key discovery
A signed key set, wherever this document requires one, is a
COSE_Sign1 whose payload is the deterministically encoded CBOR
serialisation of the COSE_KeySet, under the media type registered in
Section 10. Each key in the set carries the arp-key-status and arp-
key-validity COSE Key common parameters registered in Section 10. An
Authorised-Origin Document is a COSE_Sign1 whose payload is a CBOR
array of three-element arrays -- the server's authority origin, the
identifier of the key signing its sealing key set, and the identifier
of the key signing its operator key set -- sorted in bytewise
lexicographic order of the origin.
A relying party is not a party to any Bilateral Register Agreement
and holds only the hashes of those agreements. It therefore cannot
resolve the sealing key from them, and a binding that assumed
otherwise would oblige every conforming relying party to refuse every
Reconciliation Output.
A reconciliation server MUST publish its sealing keys as a COSE Key
Set at /.well-known/arp-sealing-keys on the reconciliation server's
authority origin, and a single key by identifier at /.well-known/arp-
sealing-keys/{kid_value}. The Sealing-Key Identifier is the pair of
that origin and the kid. A key identifier in this document is in
every case the JWK thumbprint of [RFC7638], base64url-encoded without
padding. It is carried as a CBOR text string in every payload field
and in every keyid signature parameter, as the UTF-8 encoding of that
same text string in a COSE kid (label 4), which [RFC9052] makes a
byte string, and as that text string unaltered in a {kid_value} path
segment. Every equality test this document requires between a kid
and a Sealing-Key Identifier component is over the base64url text.
Without one pinned form the same key has three spellings and those
equality tests compare values of different CBOR types. With that
fixed, it is the kid component that is compared.
Resolving a key is not sufficient. Web PKI establishes that an
origin is the origin it claims to be; it does not establish that the
origin is entitled to seal Reconciliation Outputs naming a given
register set. A relying party that accepted any well-formed key set
Hillier Expires 26 April 2027 [Page 132]
Internet-Draft ARP October 2026
would accept an Output minted by any party able to stand up a host,
since the Bilateral-Register-Agreement Hashes can be copied from a
genuine Output and are one-way.
Each Bilateral Register Agreement MUST therefore declare the
Authority Origin of the reconciliation server it authorises, and each
register operator MUST publish an Authorised-Origin Document at
/.well-known/arp-authorised-origins on its own register origin. A
Register Identifier is an origin, so the register origin is a member
of the Addressed-Registers Identifier Set and is known to the relying
party from the Output.
An Authorised-Origin Document is a COSE_Sign1 whose payload
comprises, for each reconciliation server the register operator has
authorised, that server's three-element array of Section 7.5.3: its
authority origin, the identifier of the key signing its sealing key
set, and the identifier of the key signing its operator key set. It
MUST be signed under a key served in a COSE Key Set at /.well-known/
arp-register-keys on the same register origin -- a key set carrying
the same arp-key-status and arp-key-validity parameters as a sealing
key set, so that a compromised register key has an in-band revocation
path, and the same key set that resolves a register's signatures on
Partial Attestations and Non-Answer Statements -- which the relying
party fetches over its ordinary web PKI. Signing it matters for the
same reason signing the sealing key set matters: an unsigned document
fetched over TLS can be varied per audience, and this one is the root
of the chain.
A relying party MUST verify that the origin component of the Sealing-
Key Identifier appears in the Authorised-Origin Document published by
every register in the Addressed-Registers Identifier Set, and MUST
reject the Output where it does not or where any such document cannot
be verified.
The chain is then: register origins from the Output; each register's
own key from its register origin; the Authorised-Origin Document
verified under that key; the authorised server origin and its key-set
signing key identifier from that document; and the sealing key from
the server's key set, verified under that identifier. Every step is
fetchable by a party holding only the Output.
A key entry MUST carry the arp-key-validity and arp-key-status
parameters of active, retired or revoked, and an entry whose status
is revoked MUST carry a revocation time as the third element of arp-
key-validity. A relying party MUST reject a Sealing Signature made
under a revoked key whose Reconciliation Timestamp falls at or after
the revocation time that key entry carries, MUST reject a Sealing
Signature made under a revoked key carrying no revocation time
Hillier Expires 26 April 2027 [Page 133]
Internet-Draft ARP October 2026
irrespective of when the Output claims to have been sealed, MUST
accept one made under a retired key only where the Reconciliation
Timestamp falls within that key's validity interval, and MUST reject
one whose Reconciliation Timestamp falls outside the interval of the
key it resolves to. A key MUST NOT be removed from the set while any
Reconciliation Output it sealed may still be relied upon: retirement
is by status, not by deletion, so that a historical Output remains
verifiable while a compromised key can still be refused.
Revocation without a time is repudiation of an epoch. Earlier
revisions scoped retired by validity interval and left revoked
unscoped, so one status change in a document the reconciliation
server publishes, on its own origin, under its own key, invalidated
every Reconciliation Output, Evaluation Sweep Statement, signed read
response and Entry Signature that key had ever made. The rule
closing removal -- a key MUST NOT be deleted while an Output it
sealed may be relied upon -- was defeated by status, which is the
same act with a different verb.
The reconciliation server MUST therefore publish and notarise its
sealing key set as Section 7.4.1 requires of the Policy Parameters
Document: with a Publication Timestamp, notarised into the
Transparency Service of Section 5.18 on the ledger-head notarisation
interval, and republished on that interval whether or not its
contents changed. A relying party MUST NOT act on a status
transition it cannot date. A COSE_Sign1 is not dateable from its own
bytes, and a status flip that no party can place in time disarms
every party it disarms without any of them being able to say when, or
to show that it happened after the Output they hold.
The key set MUST itself be signed under the key whose identifier the
Authorised-Origin Document gives for that server, and a relying party
MUST verify that signature. The identifier comes from a document the
relying party can fetch, not from an agreement it does not hold. A
key set fetched over TLS alone can be varied per audience, which
would let a server present one key to one relying party and another
to a second and seal two contradictory Outputs for the same
reconciliation, each verifiable only by its intended audience --
reopening at the origin the equivocation that Section 7.5.5 closes at
the Transparency Service.
7.5.4. Receipt validation
A relying party MUST validate the Receipt against Transparency
Service keys obtained from GET /.well-known/scitt-keys, or from GET
/.well-known/scitt-keys/{kid_value} for a single key identified in
the Receipt.
Hillier Expires 26 April 2027 [Page 134]
Internet-Draft ARP October 2026
7.5.5. Policy-version determination
A relying party MUST determine the Policy Version of a notarised
Reconciliation Output from the arp-policy-version-hash parameter in
the verified protected header of the Signed Statement, and MUST NOT
determine it from any retrieval path, query parameter or Transparency
Service index entry.
Because the parameter is in the protected header, it is covered by
the Receipt; and because Section 7.5.1 requires the sealed COSE_Sign1
to be the nested payload and the outer parameter to equal the Policy-
Version Hash it carries, what the header asserts is verifiably what
the seal committed to. The policy version is therefore established
by verification rather than by lookup, and a Transparency Service
that indexed an entry incorrectly, or presented different index
results to different relying parties, cannot cause a relying party to
attribute a Reconciliation Output to a policy version it was not
sealed under.
This holds only because of the nesting and equality requirements in
Section 7.5.1, both of which the relying party checks. A protected
header alone establishes that a value was not altered after signing,
not that it was true when signed.
[I-D.ietf-scitt-scrapi] defines retrieval by EntryID and defines no
query surface. Correlating entries by policy version is consequently
outside the scope of this binding and is a property of the
deployment, not of the protocol. An implementation MUST NOT assume a
standard retrieval path keyed on the Policy-Version Hash exists.
7.6. Verifiable Credentials Interop
A Reconciliation Output MAY be additionally serialised as a
Verifiable Credential conforming to [W3C-VC-DM-2.0] and secured as
application/vc+cose under [W3C-VC-JOSE-COSE]. The COSE_Sign1 of
Section 5.14 is the normative form. The credential is a projection
of it for relying parties that operate in W3C VC ecosystems, and it
states what the Output establishes about a claim in the vocabulary
those ecosystems evaluate. This section is the complete profile; a
conforming credential satisfies every requirement below, and a
verifier applies every verification step below.
7.6.1. Credential Form
The credential is a JSON object with these members.
Hillier Expires 26 April 2027 [Page 135]
Internet-Draft ARP October 2026
+===================+============================================+
| Member | Value |
+===================+============================================+
| @context | the array of exactly two elements: |
| | https://www.w3.org/ns/credentials/v2, then |
| | an object whose only member is @vocab, set |
| | to https://datatracker.ietf.org/doc/draft- |
| | hillier-scitt-arp/vocab# |
+-------------------+--------------------------------------------+
| type | the array VerifiableCredential, |
| | ArpReconciliationOutput and no other |
| | element |
+-------------------+--------------------------------------------+
| id | urn:arp:reconciliation: followed by the |
| | Reconciliation Hash |
+-------------------+--------------------------------------------+
| issuer | the Authority Origin of the Sealing-Key |
| | Identifier, as a text string |
+-------------------+--------------------------------------------+
| validFrom | the Reconciliation Timestamp |
+-------------------+--------------------------------------------+
| validUntil | the Reliance Horizon |
+-------------------+--------------------------------------------+
| credentialSubject | an object with the members below |
+-------------------+--------------------------------------------+
Table 3
Every byte string rendered into the credential is rendered as
base64url without padding (Section 5 of [RFC4648]), the single
rendering Section 7.7 requires. Every timestamp is in the form YYYY-
MM-DDTHH:MM:SSZ fixed by Section 5.14.
Hillier Expires 26 April 2027 [Page 136]
Internet-Draft ARP October 2026
+==================================+================================+
| Subject member | Value |
+==================================+================================+
| reconciliationHash, claimHash, | the 32-octet values of the |
| policyVersionHash | same names |
+----------------------------------+--------------------------------+
| combinedVerdict | the Combined Verdict, one of |
| | match, no-match, partial- |
| | match, indeterminate |
+----------------------------------+--------------------------------+
| requesterBindingClass | the Requester-Binding Class |
+----------------------------------+--------------------------------+
| addressedRegisters | the Addressed-Registers |
| | Identifier Set, in the order |
| | of Section 5.14 |
+----------------------------------+--------------------------------+
| bilateralRegisterAgreementHashes | the Bilateral-Register- |
| | Agreement Hash Set, in the |
| | order of Section 5.14 |
+----------------------------------+--------------------------------+
| reconciliationTimestamp, | the Reconciliation Timestamp |
| relianceHorizon | and the Reliance Horizon |
+----------------------------------+--------------------------------+
| audienceSet | an array with one object per |
| | Audience Member, in the |
| | order of Section 5.15.1, |
| | carrying id (the Audience |
| | Member Identifier) and |
| | verificationMethod (the |
| | Verification Method |
| | Reference) |
+----------------------------------+--------------------------------+
| sealedOutput | an object carrying |
| | digestAlgorithm (sha-256), |
| | digest (the SHA-256 digest |
| | of the serialised COSE_Sign1 |
| | of the sealed Reconciliation |
| | Output) and mediaType |
| | (application/arp-sealed- |
| | reconciliation-output+cose) |
+----------------------------------+--------------------------------+
Table 4
The credential carries no Subject Identifier, no Attested Value, no
Per-Register Result Set and no register record. The members above
are the whole of it. A credential with a member outside them, at the
top level or in credentialSubject, is refused: an added member is the
Hillier Expires 26 April 2027 [Page 137]
Internet-Draft ARP October 2026
route by which register content or a redefined term enters a signed
document, and the second element of @context is fixed for the same
reason, because a context that redefines combinedVerdict changes what
a JSON-LD processor reads under a valid signature.
validUntil is the Reliance Horizon and validFrom is the
Reconciliation Timestamp. A W3C verifier that treats validUntil as
expiry therefore stops treating the Combined Verdict as current at
the instant Section 5.15.2 requires, with no ARP-specific code. The
Horizon bounds reliance and does not invalidate the Output, and the
credential carries the same meaning: after validUntil the Sealing
Signature still verifies and the verdict remains true of the moment
it was sealed.
7.6.2. Securing
The credential is secured as a COSE_Sign1 under Section 3.3.1 of
[W3C-VC-JOSE-COSE].
* The payload is the credential serialised under [RFC8785] and
encoded as UTF-8. A verifier compares the payload to the
[RFC8785] serialisation of its own parse of it, because a
signature over a second serialisation of one credential is a
second signing act over one statement.
* The protected header carries alg (1, the value -8, EdDSA), kid
(4), typ (16) and the content type (3). A verifier reads all four
from the protected header only; a value in the unprotected header
is not evidence of anything. typ is application/vc+cose. The
content type is application/arp-reconciliation-output+json, the
more specific type that Section 3.3.1 of [W3C-VC-JOSE-COSE]
permits in place of application/vc. The kid is the UTF-8 encoding
of the JWK thumbprint of the Sealing key, as Section 7.5.3 states
for every kid in this document.
* The signing key is the Sealing key. The pair of issuer and kid is
the Sealing-Key Identifier of the Output the credential projects,
and it resolves through Section 7.5.3.
* The iat and exp CWT claims, where present in a COSE header,
describe the signature. A verifier MUST NOT read either as the
Reconciliation Timestamp or the Reliance Horizon. In the SD-JWT
VC form exp is a payload claim and carries validUntil.
Hillier Expires 26 April 2027 [Page 138]
Internet-Draft ARP October 2026
7.6.3. Verification
A relying party that receives the credential MUST perform every step.
A failure at any step is a refusal to rely, and the step that failed
is the reason recorded.
1. Resolve the key for the Sealing-Key Identifier formed from issuer
and kid through Section 7.5.3 and verify the COSE_Sign1 under it.
2. Check typ, the content type and alg against Section 7.6.2.
3. Check that the payload is the [RFC8785] serialisation of its own
parse. A payload with a duplicated member name, a string spelled
with an escape that [RFC8785] does not produce, or members in any
other order fails here.
4. Check that @context and type are exactly the values of
Section 7.6.1, that issuer equals the Authority Origin of the key
resolved in step 1, that every member of Section 7.6.1 is
present, that no other member is, and that id is
urn:arp:reconciliation: followed by reconciliationHash.
5. Check that validFrom equals reconciliationTimestamp, that
validUntil equals relianceHorizon, that validFrom is earlier than
validUntil, and that every timestamp has the required form.
6. Check that audienceSet is present and non-empty, and that its
members are distinct and in the order of Section 5.15.1. An
Audience Set is never empty (Section 5.15.1), and a credential
without one is the bearer artefact Section 5.15 exists to retire.
7. Check that combinedVerdict is one of the four defined values, and
that every byte string is rendered in the single form of
Section 7.6.1: unpadded base64url that decodes to the length the
field has and re-encodes to the same text. The Bilateral-
Register-Agreement Hash Set is sorted and deduplicated.
8. Where the sealed Reconciliation Output is held, check that
sealedOutput.digest equals its SHA-256 digest and that
reconciliationHash equals the Reconciliation Hash recomputed from
it. Where it is not held, the verdict is a snapshot of unknown
provenance until the Ledger entry for reconciliationHash has been
read under Section 7.4.
9. Compare the evaluation time to validUntil. After it, the
Combined Verdict MUST NOT be treated as current under
Section 5.15.2.
Hillier Expires 26 April 2027 [Page 139]
Internet-Draft ARP October 2026
Steps 1 to 8 determine whether the credential is genuine. Step 9
determines whether it is current. A genuine credential evaluated
after its Horizon yields a stale outcome, which differs from a
refusal: the verdict is authentic and its reliance window has closed.
A relying party that is not an Audience Member holds a credential
that carries the Audience Set it is not on. Section 5.15 applies to
it exactly as it applies to the COSE_Sign1 form.
7.6.4. JOSE Securing Forms
The credential of Section 7.6.1 has three further securing forms.
All four carry the same credential, verify under the same Sealing
key, and resolve that key through Section 7.5.3. A relying party
applies the verification steps of Section 7.6.3 to the credential it
recovers from any form.
*vc+jwt.* The credential is secured as a compact JWS under
Section 3.1.1 of [W3C-VC-JOSE-COSE]. The payload is the [RFC8785]
serialisation of the credential. The protected header carries alg
EdDSA, kid (the JWK thumbprint of the Sealing key, [RFC7638]), typ
vc+jwt and cty vc, and no other member. The media type is
application/vc+jwt.
*SD-JWT VC.* The credential is secured as an SD-JWT VC under
[SD-JWT-VC] and [SD-JWT]. The protected header carries alg EdDSA,
kid and typ dc+sd-jwt. The payload carries iss (the credential's
issuer), jti (its id), iat and nbf (validFrom), exp (validUntil), vct
(https://datatracker.ietf.org/doc/draft-hillier-scitt-arp/
vct#reconciliation-output), _sd_alg sha-256 and _sd, a sorted array
of digests. Four credential subject members are always in the clear:
reconciliationHash, combinedVerdict, reconciliationTimestamp and
relianceHorizon. Seven are selectively disclosable, each with its
own Disclosure: claimHash, policyVersionHash, requesterBindingClass,
addressedRegisters, bilateralRegisterAgreementHashes, audienceSet and
sealedOutput. The issuer serialisation carries every Disclosure and
no key-binding JWT. A holder presents a subset of the Disclosures.
The media type is application/dc+sd-jwt.
A verifier of the SD-JWT VC form MUST refuse a Disclosure whose
digest is not in _sd, a Disclosure presented twice, a Disclosure that
names a member that is in the clear or is not one of the seven, and
an _sd that is not sorted. The members recovered from the
Disclosures and the clear members together are the credential subject
of Section 7.6.1, and steps 4 to 7 of Section 7.6.3 apply to the
credential as the issuer serialised it, with every Disclosure
present. The clear members map to that credential as iss to issuer,
jti to id, nbf to validFrom, exp to validUntil and vct to the
Hillier Expires 26 April 2027 [Page 140]
Internet-Draft ARP October 2026
credential type, the subject members are top-level claims, and the
credential's @context is the constant Section 7.6.1 fixes. A
presentation that omits a Disclosure states less than the credential
does and states nothing different: a verifier applies the Disclosure
rules above, the clear members and the key binding to what it
received, and treats each member it did not receive as not stated.
Where the issuer binds the credential to a wallet key, cnf carries
that key as a jwk, and a presentation of that credential carries a
key-binding JWT after the final tilde, per [SD-JWT]. The key-binding
JWT has alg EdDSA and typ kb+jwt; its payload carries iat, aud, nonce
and sd_hash, the base64url SHA-256 of the presentation up to and
including its final tilde. A verifier MUST refuse a presentation of
a bound credential that carries no key-binding JWT, one whose
signature does not verify under cnf.jwk, and one whose aud, nonce,
freshness or sd_hash does not match what the verifier issued and
received. The Audience Set of Section 5.15.1 is carried in every
form and is not made optional by selective disclosure: a holder that
withholds the audienceSet Disclosure presents a credential the
relying party cannot place itself on, and Section 5.15 applies to
that presentation.
*mdoc.* The credential is secured as an IssuerSigned structure of
[ISO18013-5], profiled so that the issuer key resolves by thumbprint
through Section 7.5.3 where [ISO18013-5] carries an X.509 chain.
Each credential subject member is one data element in the namespace
and docType com.certisyn.arp.reconciliation.1, carried as an
IssuerSignedItemBytes (tag 24) of digestID, random, elementIdentifier
and elementValue. The issuerAuth is a COSE_Sign1 ([RFC9052]) whose
protected header carries alg -8 and kid (the thumbprint of the
Sealing key) and whose payload is a Mobile Security Object (tag 24)
holding version 1.0, digestAlgorithm SHA-256, the SHA-256 digest of
every IssuerSignedItemBytes under valueDigests, the holder's
deviceKey as a COSE_Key under deviceKeyInfo, the docType, and
validityInfo (signed, validFrom, validUntil) equal to the
credential's window. Encoding is the core deterministic encoding of
[RFC8949]. A verifier MUST refuse an issuerAuth that does not verify
under the Sealing key, an item whose digest is not in valueDigests, a
digest with no item, a repeated digestID, a docType other than the
one it requested, a validity window that excludes the evaluation
time, and a deviceKey other than the holder key the relying party
expects. The elements recovered from the items are the credential
subject of Section 7.6.1.
Hillier Expires 26 April 2027 [Page 141]
Internet-Draft ARP October 2026
*Issuer metadata.* The issuer publishes the metadata document of
[SD-JWT-VC]: issuer (the credential's issuer) and jwks, a JWK Set
that holds the Sealing key with kid equal to its thumbprint. A
relying party resolves the Sealing key from this document or through
Section 7.5.3 and pins it before it accepts a credential in any form.
7.6.5. Conformance Class
A conformance class for this profile is published with the draft's
conformance material: 30 vectors, each declaring the outcome it must
produce and the one check designed to produce it, decided by two
independent COSE_Sign1 and [RFC8785] implementations that must agree
on every row. Thirteen of the vectors are signed by the genuine
Sealing key and fail only on profile content: a redefined context
term, an added subject or top-level member, an id naming another
reconciliation, a validFrom after validUntil, a padded or standard-
alphabet byte string, unsorted agreement hashes, a duplicated
Audience Member, a duplicated JSON member name, an escape-spelled
string, header parameters carried unprotected, and an additional
credential type. One vector is a genuine credential evaluated after
its Horizon, whose outcome is stale. For each check a mutant
verifier with that check removed must admit at least one vector the
full verifier refuses.
The JOSE securing forms are checked against the platform's own
emission by a third implementation, hand-written over [RFC8785],
[RFC8949] and Ed25519, that applies 30 rows: the four forms must
state one credential and one holder key, a holder presentation with
its key-binding JWT must verify, and mutants of each form that the
genuine Sealing key signed, or that a holder or intermediary altered,
must be refused at their designed check.
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.
Hillier Expires 26 April 2027 [Page 142]
Internet-Draft ARP October 2026
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.
Hillier Expires 26 April 2027 [Page 143]
Internet-Draft ARP October 2026
* *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. Security Considerations
Hillier Expires 26 April 2027 [Page 144]
Internet-Draft ARP October 2026
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.
Hillier Expires 26 April 2027 [Page 145]
Internet-Draft ARP October 2026
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
Hillier Expires 26 April 2027 [Page 146]
Internet-Draft ARP October 2026
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
Hillier Expires 26 April 2027 [Page 147]
Internet-Draft ARP October 2026
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
Hillier Expires 26 April 2027 [Page 148]
Internet-Draft ARP October 2026
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.
Hillier Expires 26 April 2027 [Page 149]
Internet-Draft ARP October 2026
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
Hillier Expires 26 April 2027 [Page 150]
Internet-Draft ARP October 2026
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.
Hillier Expires 26 April 2027 [Page 151]
Internet-Draft ARP October 2026
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 --
Hillier Expires 26 April 2027 [Page 152]
Internet-Draft ARP October 2026
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.
Hillier Expires 26 April 2027 [Page 153]
Internet-Draft ARP October 2026
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:
+========================+================+====================+
| Signature primitive | Distinct | Distinct enveloped |
| | signing inputs | byte-strings |
+========================+================+====================+
| Ed25519 | 1 of 200 | 1 of 200 |
+------------------------+----------------+--------------------+
| ECDSA P-256 | 1 of 200 | 200 of 200 |
+------------------------+----------------+--------------------+
| ML-DSA-65, hedged | 1 of 200 | 200 of 200 |
+------------------------+----------------+--------------------+
| ML-DSA-65, | 1 of 200 | 1 of 200 |
| deterministic | | |
+------------------------+----------------+--------------------+
| Ed25519 with a | 1 of 200 | 200 of 200 |
| parallel ML-DSA-65 leg | | |
+------------------------+----------------+--------------------+
Table 5
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.
Hillier Expires 26 April 2027 [Page 154]
Internet-Draft ARP October 2026
*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
Hillier Expires 26 April 2027 [Page 155]
Internet-Draft ARP October 2026
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.
+=============+==============+==============+========+==============+
|Wanted |Also wanted |Given up |Stated |What a reader |
| | | |in |can check |
| | | | |instead |
+=============+==============+==============+========+==============+
|A chain |A chain the |Absolute |Section |How many |
|between two |responding |rewrite |5.23.2.3|independent |
|heads a |service did |detection; | |witnesses |
|relying party|not write |what holds is | |cover the |
|can check | |append-only | |interval, and |
| | |over intervals| |how often |
| | |a witness has | |each observes |
| | |covered | | |
+-------------+--------------+--------------+--------+--------------+
|Reproducible |Uniqueness per|Exact |Section |Every other |
|output from |reconciliation|identity, for |5 |field is |
|enumerated | |three fields | |identical; |
|inputs | | | |the three are |
| | | | |carved out by |
| | | | |name |
+-------------+--------------+--------------+--------+--------------+
|Erasure of a |An append-only|Permanence of |Section |No chain |
|subject's |record |Output content|9.2 |depends on |
|data | | | |content; a |
Hillier Expires 26 April 2027 [Page 156]
Internet-Draft ARP October 2026
| | | | |digest whose |
| | | | |preimage is |
| | | | |gone is still |
| | | | |a valid chain |
| | | | |element |
+-------------+--------------+--------------+--------+--------------+
|A schema |Telling |The upgrade; |Section |Array length |
|upgrade with |withheld from |absence is |5.18 |is fixed by |
|no flag day |never-defined |encoded, not | |Entry Type, |
| | |omitted | |so a short |
| | | | |array is a |
| | | | |defect and |
| | | | |not a version |
+-------------+--------------+--------------+--------+--------------+
|A chain |A verifier- |The test |Section |The |
|stable under |side test that| |8.11 |obligation |
|re-encoding |an entry was | | |remains and |
| |signed once | | |is examinable |
| | | | |by an |
| | | | |auditor; a |
| | | | |re-signature |
| | | | |under a |
| | | | |different key |
| | | | |still moves |
| | | | |the chain |
+-------------+--------------+--------------+--------+--------------+
|Digests |An auditor who|Recomputation |Section |Consistency |
|unguessable |can recompute |without the |5.20 |across two |
|from outside |them |blinding value| |reads, and |
| | | | |nothing more, |
| | | | |which that |
| | | | |section now |
| | | | |says |
+-------------+--------------+--------------+--------+--------------+
|A register |A requester |Unlinkability,|Section |The |
|recognising a|unlinkable |by default |5.16 |deployment |
|returning |from one | | |may |
|counterparty |reconciliation| | |substitute a |
| |to the next | | |fresh element |
| | | | |each time; |
| | | | |the choice is |
| | | | |declared |
+-------------+--------------+--------------+--------+--------------+
|One |Sovereign |The common leg|Section |Every leg is |
|interoperable|registers | |5.5 |declared in |
|register leg |keeping their | | |an Agreement |
| |own interfaces| | |whose hash is |
| | | | |committed to |
Hillier Expires 26 April 2027 [Page 157]
Internet-Draft ARP October 2026
+-------------+--------------+--------------+--------+--------------+
|A regulator |That regulator|Chain |Section |Redacted |
|reading a |verifying the |verification |7.4.2 |fields are |
|redacted |entry's chain |under | |null in |
|entry | |redaction | |place, so the |
| | | | |length is |
| | | | |intact and an |
| | | | |unredacted |
| | | | |read is |
| | | | |available |
+-------------+--------------+--------------+--------+--------------+
|Errors that |Endpoints that|Distinguishing|Section |The |
|tell a |are not |errors, on the|7.4.4 |commissioning |
|requester |existence |read path | |path |
|what went |oracles | | |distinguishes |
|wrong | | | |them and pays |
| | | | |for it in |
| | | | |rate limit |
| | | | |and access |
| | | | |log |
+-------------+--------------+--------------+--------+--------------+
|Coverage |Probes a |Free |Section |A probe |
|measured |register |measurement |5.21.3 |consumes a |
|without cost |cannot tell | | |real budget |
| |from real work| | |against a |
| | | | |real |
| | | | |register, |
| | | | |which is what |
| | | | |makes it |
| | | | |uncountable |
| | | | |by the |
| | | | |operator |
+-------------+--------------+--------------+--------+--------------+
|A quorum |A test a |Proof of |Section |Distinct |
|proving |verifier can |independence |5.23.4 |declared |
|observer |actually run | | |parties and |
|independence | | | |distinct |
| | | | |keys, both |
| | | | |mechanically |
| | | | |checkable |
+-------------+--------------+--------------+--------+--------------+
Table 6
Two things follow from having written this table that were not
obvious before writing it.
Hillier Expires 26 April 2027 [Page 158]
Internet-Draft ARP October 2026
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. Privacy Considerations
This protocol operates over beneficial-ownership registers, corporate
registries, consolidated sanctions lists and customs records. Its
subject is almost always a party that is neither the requester nor a
recipient, and that is not told a reconciliation about it occurred.
The disclosure model has two artefacts and one division. A
Reconciliation Output is confidential to its Audience Set and carries
subject references, register-signed attestations and principal
identifiers; the Settlement-Layer Ledger is broadly readable and
carries digests, register origins and structural metadata.
Section 5.15 states the division and the rules that rest on it.
What the witness artefacts disclose. Section 5.23.2.3 obliges a
witness to serve Segments to any party without authentication, where
the same linkage arrays are readable from the reconciliation server
only by an entitled requester under a rate limit. That is an
entitlement change and it is made deliberately: an artefact
obtainable only from the party it is evidence about is that party's
selection, so head-consistency evidence has to be world-readable to
be evidence at all, which is the choice Section 5.23.2.2 already made
for Head Consistency Statements. What it adds is the Prior-Entry
Hash and the Signing Input Digest of each entry alongside the Self-
Entry Hash. All three are digests over signed artefacts rather than
over subject data, none is a low-entropy preimage of the kind the
Deployment Blinding Value of Section 5.16 exists to protect, and the
interval a Segment covers is bounded above by a head Section 5.18
already publishes unauthenticated, so the live head oracle
Section 7.4.2 guards against is not reintroduced.
Hillier Expires 26 April 2027 [Page 159]
Internet-Draft ARP October 2026
Two residues follow and are recorded here rather than left to be
inferred. The first is that the linkage values of every covered
entry become readable without entitlement, where Section 7.4.4 rate
limits the equivalent read at the reconciliation server and a witness
serving Segments is not rate limited by this document. The entry
count and the write rate over time are not part of that residue:
Section 5.18 publishes a contiguous head unauthenticated once per
interval, so both follow from differencing two published heads and
were public already. What is new is the per-entry chain shape below
a published head.
The second is the allowance Section 7.4.4 makes for a witness
principal. The holder of a key can learn, from the number of ranged
linkage reads admitted to it, that the key sits in a Witness Set some
Bilateral Register Agreement the deployment holds declares, which is
a wider set than the effective Witness Set the Policy Parameters
Document of Section 7.4.1 already publishes. The disclosure is
membership of a union rather than of an intersection, it is available
only to the holder of the key in question, and it is the price of a
publication obligation a rate limit would otherwise void.
What is protected. The Deployment Blinding Value of Section 5.16
keeps the Claim Hash and the Policy-Version Hash from being inverted
by exhaustive search over their low-entropy preimages, which is what
stops a Ledger reader recovering the subject and the commissioning
principal. Entitlement follows the Audience Set, so possession of an
Output is not authorisation to learn what happened to it afterwards.
Enrolment under Section 7.2 means a requester cannot direct an Output
at a party that has not agreed to receive one. The per-principal
query budget of Section 8.1 bounds recovery of a register record by
repeated querying. Read responses are rate-limited and logged, and
the log is not on the Ledger, because a Ledger that recorded reads
would disclose the pattern of interest in a subject to everyone
entitled to read it.
What is not. A subject has no standing in this protocol: it is not
notified, it cannot object, and it cannot learn that it was
reconciled. That is a deliberate property of a sanctions-screening
protocol and a real cost, and a deployment operating where subject
rights attach should provide for them outside this document. An
Audience Member learns the subject, the predicate and every
register's answer; the audience constraint of Section 5.15.1 lets a
register cap how many such parties there may be, and the register
cannot verify that the cap was enforced. Notarising an Output under
Section 7.5 places it in a log whose retrieval is by EntryID, and a
deployment for which that is the wrong disclosure should not
notarise. The Ledger Head Statement is unauthenticated and carries a
contiguous sequence number, so it discloses the deployment's size and
Hillier Expires 26 April 2027 [Page 160]
Internet-Draft ARP October 2026
approximate rate at the notarisation interval. An Audit Identity
under Section 5.20 reads every Output of every reconciliation
addressing its register irrespective of Audience Set, and each
register declares one, so a deployment's disclosure surface grows
with the number of registers it addresses. An Override Record names
an authorising operator in the clear inside the Output. Section 8.2
records a further residual risk, and Section 8.10 the projection-
narrowing channel.
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.
Hillier Expires 26 April 2027 [Page 161]
Internet-Draft ARP October 2026
*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
Hillier Expires 26 April 2027 [Page 162]
Internet-Draft ARP October 2026
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. IANA Considerations
This document requests IANA to register the following:
* Four COSE header parameters in the COSE Header Parameters
registry, values to be assigned by IANA:
- arp-bilateral-agreement-hash (value TBD)
- arp-policy-version-hash (value TBD)
- arp-source-data-version (value TBD)
- arp-witness-identifier (value TBD)
arp-witness-identifier is a CBOR text string carrying the
identifier of the Witness Entry whose key signed the artefact, and
is used by Section 5.23.2.2 and Section 5.23.2.3; arp-policy-
version-hash is a CBOR byte string; arp-bilateral-agreement-hash
is a CBOR array of byte strings; arp-source-data-version is a CBOR
array of two-element arrays, each of a list name and that
publisher's state identifier, as Section 5.6 constructs it. Each
MUST appear in a protected header and MUST NOT appear in an
unprotected one: every one of them is a commitment a verifier
relies on, and a commitment a signature does not cover is not a
commitment. arp-policy-version-hash and arp-bilateral-agreement-
hash are used by Section 7.5.1; arp-source-data-version is used by
Section 5.6.
* Two COSE Key common parameters in the COSE Key Common Parameters
registry, values to be assigned by IANA: arp-key-status (value
TBD), a CBOR text string of active, retired or revoked; and arp-
key-validity (value TBD), a two-element CBOR array of the not-
before and not-after times, or a three-element array whose third
element is a revocation time where the entry's arp-key-status is
revoked, each in the form of Section 5.14. Section 7.5.3 requires
both on every key it publishes, and a key parameter used
normatively and never registered is a parameter no other
implementation can read.
* A registry of ARP Divergence-Axis values, registration policy
Specification Required, initially containing the descriptors
enumerated in the Divergence Axis definition of Section 4. Each
entry MUST record whether the axis is register-attestable or
Hillier Expires 26 April 2027 [Page 163]
Internet-Draft ARP October 2026
server-recorded, a distinction eight normative sections depend on
and which is otherwise carried only in prose. The designated
expert MUST refuse a registration that does not state it.
* A registry of ARP Non-Answer Reasons, registration policy
Specification Required, initially containing the values enumerated
in Section 5.11. Each entry MUST record whether the reason is
register-attested or server-observed, which determines whether a
Non-Answer Statement signed by the register is required; the
initial entries are recorded as Section 5.11 states. A Non-Answer
Reason is not a verdict; the designated expert MUST refuse a
registration that could be combined by the Verdict Arithmetic, and
MUST refuse a register-attested registration that does not state
what the register signs over.
* A registry of ARP Excluded-Range Reasons, registration policy
Specification Required, initially containing outside-retention,
where the range predates the retention period of Section 5.15.3;
not-in-scope-of-trigger, where no entry in the range carries a
value the trigger reached; and superseded-in-range, where every
entry in the range was already superseded by an earlier sweep
whose Statement is named. A registration MUST name a condition a
reader holding the Ledger can check for itself, and the designated
expert MUST refuse one that can only be confirmed by the operator
asserting it, since a disposition a reader cannot test returns the
range to the state that having a disposition was meant to leave
behind.
* A registry of ARP Subject Mapping Descriptors, registration policy
Specification Required, initially containing identity, profile-
declared and agreement-declared, defined in Section 5.4.1. A
registration MUST specify a transformation that is a function of
the Subject Identifier and of declared terms alone. The
designated expert MUST refuse a registration whose transformation
takes any input the reconciliation server chooses at
reconciliation time, since a descriptor naming server discretion
records that the discretion was exercised and not what it did.
* A registry of ARP Verification Outcomes, registration policy
Specification Required, initially containing the values enumerated
in Section 5.9.2. A registration MUST name a condition a verifier
can reach mechanically, and MUST state whether reaching it is
evidence of equivocation by the serving party, evidence of a
transport or encoding difference, or neither. The designated
expert MUST refuse a registration that does not state which,
because the distinction between an operator that equivocated and
an artefact that was re-encoded in transit is the one this
registry exists to carry.
Hillier Expires 26 April 2027 [Page 164]
Internet-Draft ARP October 2026
* A registry of ARP Post-Seal Evaluation Qualifiers, registration
policy Specification Required, initially containing notarisation-
incomplete and attribution-indeterminate, defined in Section 5.17.
A registration MUST identify a condition arising after a
Reconciliation Output is sealed; the designated expert refuses a
registration that qualifies a verdict, which belongs in the
Divergence-Axis registry.
* A registry of ARP Register Data-Format Profile identifiers,
registration policy Specification Required, initially containing
arp-profile-bods, arp-profile-corporate-org, arp-profile-customs-
wco and arp-profile-sanctions-consolidated, defined in
Section 5.5. Identifiers beginning x- are reserved for bilateral
use and are not registered. A registration MUST state the dated
vocabulary in which permitted predicates are expressed where it
names one and state that it names none otherwise, the relation
corresponding to taxonomic narrowing for each branch of its
predicate space, and the parameters a Bilateral Register Agreement
declaring it must supply. The designated expert refuses a
registration that defines any means of transporting register
records, that declares more than one parent relation applicable to
a single predicate, that names a vocabulary without pinning its
version, or that fixes in the profile a parameter varying between
registers using the same format.
* A registry of ARP Aggregation-Method Descriptors, registration
policy Specification Required, initially containing hash-linkage-
conjunction, hash-linkage-disjunction, hash-linkage-threshold-
count and hash-linkage-source-class-quorum: the aggregation mode
of Section 5.10 joined to the Verdict-Arithmetic operator it
sequenced. A registration naming a new aggregation mode MUST
specify that mode's construction; the descriptor is a signed
Ledger field and a mode with no construction gives it no meaning.
* A registry of ARP Retroactive Evaluation Triggers, registration
policy Specification Required, initially containing pattern-
library, policy-version, source-data-version, credential-
revocation and register-record-correction, defined in
Section 5.21.1. A registration MUST name an event whose
occurrence and time a party outside the reconciliation server can
establish, or state plainly that it cannot, since the
falsifiability of Section 5.21.1 turns on it.
* A registry of ARP Override Grounds, registration policy
Specification Required, initially containing operational-
continuity, pattern-false-positive and statutory-obligation,
defined for use in the Override Record of the Adversarial Pre-
Transmission Test. A registration MUST state the circumstances in
Hillier Expires 26 April 2027 [Page 165]
Internet-Draft ARP October 2026
which the ground is available and MUST NOT admit a ground that
could be asserted of every override, which would return the field
to free text.
* A registry of ARP Re-Typing Grounds, registration policy
Specification Required, initially containing bounded-depth-not-
closure, declared-not-determined, threshold-divergence and
projection-broadened, corresponding to the four grounds of
Section 5.12.
* A registry of ARP Verdict-Arithmetic operators, registration
policy Specification Required, initially containing conjunction,
disjunction, threshold-count and source-class-quorum, defined in
Section 5.13. A registration MUST state the operator's result as
a total function of the multiset of contribution values and the
operator's declared parameters, and MUST state whether it admits
partial-match, on which Section 5.12 turns.
* A registry of ARP Ledger Entry Types, registration policy
Specification Required, initially containing reconciliation,
continuation-notarisation, continuation-post-seal-record and
continuation-supersession, defined in Section 5.18. Entry Type
values are CBOR text strings. A registration MUST enumerate the
fields an entry of that type carries in addition to the fields
every entry carries, MUST state their order, since the Self-Entry
Hash is taken over that order, and MUST state each field's value
type and whether it is conditionally absent and on what condition.
The designated expert MUST refuse a registration whose type
restates a field already carried by the reconciliation entry it
continues, and MUST refuse any type other than reconciliation that
records a reconciliation rather than a fact arising after one was
sealed.
Hillier Expires 26 April 2027 [Page 166]
Internet-Draft ARP October 2026
The initial registrations are those of Section 5.18, with these
value types. Every hash is a 32-octet CBOR byte string; every
sequence number is a CBOR unsigned integer; every timestamp is a
CBOR text string in the form of Section 5.14; every Entry Type is
a CBOR text string; the Addressed-Registers Identifier Set is a
CBOR array of text strings, each an authority origin, sorted in
bytewise lexicographic order of its UTF-8 encoding; the
Aggregation-Method Descriptor and the Requester-Binding-Class
Descriptor are CBOR text strings, the first drawn from the ARP
Aggregation-Method Descriptors registry and the second from the
four classes of the Requester Identity Binding and Agent Friend-
or-Foe Gate section; the Override Indicator and the Material-
Change Indicator are CBOR booleans; the Transparency Service
Identifier is a CBOR text string carrying an authority origin; the
EntryID is a CBOR text string as [I-D.ietf-scitt-scrapi] returns
it; an HTTP status code is a CBOR unsigned integer; and every
Entry Signature is a COSE_Sign1.
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.
Hillier Expires 26 April 2027 [Page 167]
Internet-Draft ARP October 2026
+========================+==================+=======================+
| URI suffix | Defined in | Path syntax below |
| | | the suffix |
+========================+==================+=======================+
| arp-sealing-keys | Section 7.5.3 | /{kid}, where {kid} |
| | | is a JWK thumbprint, |
| | | returns that single |
| | | key |
+------------------------+------------------+-----------------------+
| arp-register-keys | Section 7.5.3 | /{kid} as above |
+------------------------+------------------+-----------------------+
| arp-operator-keys | the Adversarial | /{kid} as above |
| | Pre-Transmission | |
| | Test | |
+------------------------+------------------+-----------------------+
| arp-authorised-origins | Section 7.5.3 | none |
+------------------------+------------------+-----------------------+
| arp-ledger-head | Section 5.18 | none |
+------------------------+------------------+-----------------------+
| arp-policy-parameters | Section 7.4.1 | none |
+------------------------+------------------+-----------------------+
| arp-head-consistency | Section 5.23.2.2 | none; served by a |
| | | witness on the |
| | | Authority Origin of |
| | | its Operating-Party |
| | | Identifier |
+------------------------+------------------+-----------------------+
| arp-witness-linkage | Section 5.23.2.3 | /{n}, where {n} is |
| | | an Entry Sequence |
| | | Number, returns the |
| | | single Segment |
| | | covering it; the |
| | | bare suffix returns |
| | | the most recent; |
| | | served by a witness |
| | | on the same origin |
| | | as arp-head- |
| | | consistency |
+------------------------+------------------+-----------------------+
Table 7
Hillier Expires 26 April 2027 [Page 168]
Internet-Draft ARP October 2026
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.
+===================+==============================+==============+
| Subtype | Carries | Defined in |
+===================+==============================+==============+
| arp- | a request commissioning a | Section 7.2 |
| reconciliation- | reconciliation | |
| request+cbor | | |
+-------------------+------------------------------+--------------+
| arp-remediation- | a Remediation Advisory | the |
| advisory+cbor | | Adversarial |
| | | Pre- |
| | | Transmission |
| | | Test |
+-------------------+------------------------------+--------------+
| arp-sovereign-re- | a Sovereign Re-Notification | Section |
| notification+cose | | 5.19.1 |
+-------------------+------------------------------+--------------+
| arp-sealed- | a Reconciliation Output | Section 5.14 |
| reconciliation- | under its Sealing Signature, | |
| output+cose | whether delivered directly | |
| | or nested in a SCITT Signed | |
| | Statement | |
+-------------------+------------------------------+--------------+
| arp-policy- | a Policy Parameters Document | Section |
| parameters+cose | | 7.4.1 |
+-------------------+------------------------------+--------------+
| arp-post-seal- | a Post-Seal Evaluation | Section 5.17 |
| evaluation- | Record | |
| record+cbor | | |
+-------------------+------------------------------+--------------+
Hillier Expires 26 April 2027 [Page 169]
Internet-Draft ARP October 2026
| arp- | the RFC 8785 payload of the | Section 7.6 |
| reconciliation- | Verifiable Credentials form | |
| output+json | | |
+-------------------+------------------------------+--------------+
| arp-ledger- | a Ledger Head Statement | Section 5.18 |
| head+cose | | |
+-------------------+------------------------------+--------------+
| arp-read- | a signed read response | Section |
| response+cose | | 7.4.3 |
+-------------------+------------------------------+--------------+
| arp-evaluation- | an Evaluation Sweep | Section |
| sweep+cose | Statement | 5.21.1 |
+-------------------+------------------------------+--------------+
| arp-key-set+cose | a signed COSE Key Set or an | Section |
| | Authorised-Origin Document | 7.5.3 |
+-------------------+------------------------------+--------------+
| arp-head- | a Head Consistency Statement | Section |
| consistency+cose | | 5.23.2.2 |
+-------------------+------------------------------+--------------+
| arp-witness- | a Witness Linkage Segment | Section |
| linkage+cose | | 5.23.2.3 |
+-------------------+------------------------------+--------------+
| arp-probe- | a Probe Commitment | Section |
| commitment+cose | | 5.21.3 |
+-------------------+------------------------------+--------------+
Table 8
11. Acknowledgments
This document benefits from the SCITT Architecture [RFC9943], the
SCITT Reference APIs [I-D.ietf-scitt-scrapi], COSE Receipts
[RFC9942], the RATS Architecture [RFC9334], HTTP Message Signatures
[RFC9421], and the Web Bot Auth HTTP message signature protocol
[I-D.ietf-webbotauth-httpsig-protocol].
Named findings, because a specification improved by review should say
by whom.
Songbo Bu established that the indistinguishability requirement of
Section 7.4.4 could not be satisfied as -02 stated it: the response
profile of Section 7.4.3 binds each response to its request and its
serving instant, so two responses cannot be byte-equal, and a
conformance rule demanding that they be would fail every conforming
implementation. The normalised observation in Section 7.4.4, its
enumeration of HTTP metadata and cache behaviour, and the separation
of the deterministic requirements from any statistical timing claim
are his design, contributed as an executable vector class.
Hillier Expires 26 April 2027 [Page 170]
Internet-Draft ARP October 2026
Steven Mih established that the empty-result contradiction of
Section 7.4.3 is conditional on the reader and any later observer
having been served one chain, and that under the fork Section 5.18
admits it may be opportunistic to detect, an absence assertion can
stand uncontradicted indefinitely. The boundary now stated in
Section 7.4.3 is his finding. He also confirmed, against three
independent drafts, that the deterministic encoding requirements
relied on here are those of Section 4.2.1 of [RFC8949] and not those
of Section 9 of [RFC9052].
Iman Schrock established, with Anton Sokolov, that a content digest
cannot serve as a correlation key across independently produced
descriptions of one act. He then established that the earlier repair
was itself imprecise: [I-D.schrock-canonical-action-identifier]
declares required and optional fields per action type and marks no
field as a correlation key, so the selection belongs to the profile.
The requirements in Appendix D.1 to pin the action type and version,
the selected field and its normalisation and comparison rules, and to
require that the selected field be present in the Canonical Claim so
that the Claim Hash commits to it, are his, substantially as he
drafted them.
Walter Hawkins established that the falsifiability condition of
Section 7.4.3 is bounded by observer diversity rather than by any
stronger single-log property: head evidence obtained from the
responding service cannot bound a fork, because a fork at disjoint
sequence numbers is invisible from a single vantage by construction
and the vantage is what is in question. Naming the independent
observer, and the ordering of witness countersignature over
independently anchored head digest, is his.
Tiago Pinto established that the obligation to answer with a signed
response carrying a log position belongs on the party making the
claim rather than on the party relying on it, and that an unsigned or
position-less answer is to be treated as the log not having answered.
Section 7.4.3 takes that shape at his argument.
Tom Sato's leaf-construction work on Certificate Transparency logs
informed the inclusion-proof requirements of Section 5.9, and
established that a document defining a Merkle construction without
stating its relationship to Certificate Transparency leaves an
implementer arriving from RFC 6962 unable to tell whether the two
agree.
Anton Sokolov established that a digest taken over a signed artefact
as served does not identify that artefact under a signature primitive
whose encoding is not byte-unique, and that ECDSA is such a primitive
without violating SEC1, FIPS 186-5 or [RFC9053]. Section 8.11, and
Hillier Expires 26 April 2027 [Page 171]
Internet-Draft ARP October 2026
the reconstruction of the Prior-Entry Hash of Section 5.18, the Post-
Seal Evaluation Record Hash of Section 5.17 and the Merkle leaf of
Section 5.10 as Signing Input Digests, follow from his measurement.
Iman Schrock separately established that the digest of a COSE_Sign1
envelope, the digest of its Sig_structure and the digest of the
authorization payload inside it are three references a relying party
has to be able to hold apart, and that a protocol identifying a
registration entry by the first of them forces applications to treat
it as the identity of the third. He further established the scope of
a low-S canonicalisation rule against that question: low-S
enforcement can reject the high-S encoding at a verifier and does not
by itself resolve the identity question, particularly where
normalisation occurs after an envelope has already been registered.
The separation stated in Section 8.12, and its limitation of low-S,
are his; what this document adds is the measurement across signature
primitives and the observation that the exemption Section 8.11 grants
to EdDSA does not survive composition with a post-quantum leg.
Henri Sirkkavaara established that a document may carry both the
sound and the unsound rule at once, each defensible on its own
reading, and that the check is therefore to sweep every identity rule
in a tree rather than to correct the one that was reported. Applied
to this document it found that the Self-Entry Hash of Section 5.18
already excluded the signature while the Prior-Entry Hash two
paragraphs below it did not.
Nenad Vasic established that an inclusion proof whose carried leaf is
lifted unchanged from another object's valid proof folds to the
correct root under a sibling array that verifies, so that a verifier
walking the path before recomputing the leaf accepts a proof bound to
bytes it does not hold. The requirement in Section 5.9.1 that a
verifier compute the leaf from the object whose inclusion is being
proved and use that value as the input to the sibling walk is his,
contributed as an executable vector against a third-party corpus.
12. References
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>.
Hillier Expires 26 April 2027 [Page 172]
Internet-Draft ARP October 2026
[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", 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>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/rfc/rfc4648>.
[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", RFC 8174, DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/rfc/rfc8174>.
Hillier Expires 26 April 2027 [Page 173]
Internet-Draft ARP October 2026
[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", 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., Richer, J., 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>.
Hillier Expires 26 April 2027 [Page 174]
Internet-Draft ARP October 2026
[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.ietf-webbotauth-httpsig-protocol]
Meunier, T. and S. Major, "HTTP Message Signatures for
automated traffic", Work in Progress, Internet-Draft,
draft-ietf-webbotauth-httpsig-protocol-00, 1 September
2026, <https://datatracker.ietf.org/doc/html/draft-ietf-
webbotauth-httpsig-protocol-00>.
[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>.
Hillier Expires 26 April 2027 [Page 175]
Internet-Draft ARP October 2026
[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, "Canonicalization Declaration for
SCITT Signed Statements", Work in Progress, Internet-
Draft, draft-mih-sokolov-scitt-payload-binding-05, 12
September 2026, <https://datatracker.ietf.org/doc/html/
draft-mih-sokolov-scitt-payload-binding-05>.
[I-D.schrock-canonical-action-identifier]
Schrock, I., "The Canonical Action Identifier (CAID)",
Work in Progress, Internet-Draft, draft-schrock-canonical-
action-identifier-05, 2 October 2026,
<https://datatracker.ietf.org/doc/html/draft-schrock-
canonical-action-identifier-05>.
[ISO18013-5]
"ISO/IEC 18013-5:2021 Personal identification - ISO-
compliant driving licence - Part 5: Mobile driving licence
(mDL) application", 2021,
<https://www.iso.org/standard/69084.html>.
[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>.
[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>.
Hillier Expires 26 April 2027 [Page 176]
Internet-Draft ARP October 2026
[RFC8067] Leiba, B., "Updating When Standards Track Documents May
Refer Normatively to Documents at a Lower Level",
RFC 8067, DOI 10.17487/RFC8067, January 2017,
<https://www.rfc-editor.org/rfc/rfc8067>.
[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
"Handling Long Lines in Content of Internet-Drafts and
RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
<https://www.rfc-editor.org/rfc/rfc8792>.
[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>.
[SD-JWT] "Selective Disclosure for JWTs (SD-JWT)", 2025,
<https://datatracker.ietf.org/doc/draft-ietf-oauth-
selective-disclosure-jwt/>.
[SD-JWT-VC]
"SD-JWT-based Verifiable Credentials (SD-JWT VC)", 2025,
<https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-
vc/>.
[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/>.
[W3C-VC-JOSE-COSE]
"Securing Verifiable Credentials using JOSE and COSE",
2026, <https://www.w3.org/TR/vc-jose-cose/>.
[WCO-DM] World Customs Organization, "WCO Data Model", 2024,
<https://www.wcoomd.org/en/topics/facilitation/instrument-
and-tools/tools/data-model.aspx>.
Appendix A. Examples
Hillier Expires 26 April 2027 [Page 177]
Internet-Draft ARP October 2026
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
Hillier Expires 26 April 2027 [Page 178]
Internet-Draft ARP October 2026
* 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
Hillier Expires 26 April 2027 [Page 179]
Internet-Draft ARP October 2026
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.
Hillier Expires 26 April 2027 [Page 180]
Internet-Draft ARP October 2026
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.
Hillier Expires 26 April 2027 [Page 181]
Internet-Draft ARP October 2026
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.
Hillier Expires 26 April 2027 [Page 182]
Internet-Draft ARP October 2026
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.
A.5. Example: Verifiable Credentials Form of an Output
This example is the first vector of the conformance class of
Section 7.6.5. The payload below is shown with indentation for
reading and folded under [RFC8792]. The signed payload is its
[RFC8785] serialisation, 1,247 octets with no whitespace and members
in code-unit order. The hash and key values are those of the
published test seed.
The COSE_Sign1 protected header, in extended diagnostic notation:
{
1: -8,
4: 'VDux_CmeAgi2AvrAFW0bInmtCjMDD9kHOfzia5l81w0',
16: "application/vc+cose",
3: "application/arp-reconciliation-output+json"
}
The payload:
========== NOTE: '\' line wrapping per RFC 8792 ==========
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
{
Hillier Expires 26 April 2027 [Page 183]
Internet-Draft ARP October 2026
"@vocab": "https://datatracker.ietf.org/doc/draft-hillier-\
\scitt-arp/vocab#"
}
],
"credentialSubject": {
"addressedRegisters": [
"https://ofac.example.gov",
"https://sanctions.example.eu"
],
"audienceSet": [
{
"id": "https://acme.example.com/operators/jdoe",
"verificationMethod": "ui8q-Oh_44_8fBC8GAy1L9256mAf5rFhk\
\au8_M3YL7k"
}
],
"bilateralRegisterAgreementHashes": [
"bGZZqJQYgwPMmKK8JhsCgjO_qLBBDx2vJWVHo_rY03k",
"f9SeSX9aYohdR8ZQESBPAKLgx0DiRCGI9RKhdL6h4m4"
],
"claimHash": "DXnYYMYKBOTXl8wyyilXrljSu_xfAHgO8uGsTuLKu_s",
"combinedVerdict": "no-match",
"policyVersionHash": "AFF2RolekqOQRbkVNzh5WM493yXRFD4PtgFtFA\
\7FcIo",
"reconciliationHash": "LLJqwmuxKzSvgqXO2zWYJyB4tEY6tt6NIojRV\
\jPDyfM",
"reconciliationTimestamp": "2026-10-14T18:00:00Z",
"relianceHorizon": "2026-10-15T18:00:00Z",
"requesterBindingClass": "agent-verified",
"sealedOutput": {
"digest": "wV7R-2vxEC9c7XAWIaMKYht97UvgOjF7vQhXmw9kJTo",
"digestAlgorithm": "sha-256",
"mediaType": "application/arp-sealed-reconciliation-output\
\+cose"
}
},
"id": "urn:arp:reconciliation:LLJqwmuxKzSvgqXO2zWYJyB4tEY6tt6N\
\IojRVjPDyfM",
"issuer": "https://arp.example.org",
"type": [
"VerifiableCredential",
"ArpReconciliationOutput"
],
"validFrom": "2026-10-14T18:00:00Z",
"validUntil": "2026-10-15T18:00:00Z"
}
Hillier Expires 26 April 2027 [Page 184]
Internet-Draft ARP October 2026
A verifier holding the sealed Output computes the SHA-256 digest of
its COSE_Sign1 and compares it to sealedOutput.digest. A verifier
that holds only this credential reads the Ledger entry for
reconciliationHash before treating the verdict as more than a
snapshot, and stops treating it as current at validUntil.
Appendix B. Composition with the SCITT Architecture
The SCITT Architecture [RFC9943] provides notarisation of supply-
chain artefacts through a Transparency Service, which registers
Signed Statements and returns Receipts, yielding Transparent
Statements. ARP composes with SCITT in four ways:
1. SCITT receipts MAY be the input claim to ARP. A claim
referencing a SCITT-anchored artefact (its hash and its
registration receipt) is reconciled across registers without
disclosing the underlying artefact.
2. ARP Reconciliation Outputs MAY be notarised into a SCITT
Transparency Service as Transparent Statements, enabling SCITT-
aware relying parties to verify the cross-sovereign
reconciliation event in the same way they verify any other
supply-chain claim. Registration and retrieval MAY use the SCITT
Reference APIs [I-D.ietf-scitt-scrapi]. Notarisation does not
enlarge the Audience Set of Section 5.15: what is registered is
the sealed Output, and a party that retrieves it by EntryID holds
it on the same terms as a party handed it directly.
3. The SCITT Architecture's Issuer role maps to the Bilateral
Register Agreement structure: each Sovereign Register acts as a
SCITT Issuer for a constrained predicate set. RFC 9943 defines
no role for a party that combines statements from several
Issuers, and this document does not claim one: the reconciliation
server is an ARP role that acts as a SCITT Client toward the
Transparency Service, registering its own Signed Statements.
4. ARP Hash-Linkage Aggregation MAY emit its Merkle commitment as
COSE Receipts [RFC9942], a compatible inclusion-proof encoding
SCITT uses for transparency receipts, so a single verifier
library checks both.
Appendix C. Composition with the RATS Architecture
The RATS Architecture [RFC9334] provides remote-attestation
procedures for compute-substrate trust. ARP composes with RATS in
two ways:
Hillier Expires 26 April 2027 [Page 185]
Internet-Draft ARP October 2026
1. The Adversarial Pre-Transmission Test runs inside a confidential
computing boundary attested under RATS. The reconciliation
server's integrity MAY be verified by relying parties through
standard RATS verification flows.
2. Compute-attestation reconciliation across heterogeneous TEE / CC
providers is the natural specialisation of ARP to the RATS
evidence class. That specialisation is outside the scope of this
document.
Appendix D. Composition with Agent-Action Accountability Capsules
[I-D.mih-sato-agent-accountability-composition] models accountable
autonomous action as four independently verifiable slots -- CAN, what
the agent was permitted to do; WHO, which human authorised it; WHAT
the agent did; and AUDIT, the runtime enforcement record -- each
filled by a separately signed profile. This document does not
restate that model; the slot definitions, their semantics and their
composition rules are those of
[I-D.mih-sato-agent-accountability-composition], and this appendix
uses them as defined there.
This appendix calls a filled slot a capsule. That is this document's
term and not that draft's, which speaks of slots and profiles; it is
used here because ARP admits each filled slot as a Partial-
Attestation source and the word names the signed unit rather than the
position it occupies.
What this appendix adds is reconciliation across those capsules.
Each capsule may be signed by a different party, under a different
signing chain, with a different payload schema -- the same non-
reconcilable-outputs problem this document addresses for sovereign
registers, arising in the agent-action domain. What the capsules
share is the action serialisation over which the subject digest is
computed.
ARP composes such capsules without requiring them to share a
producer, a schema, or a signing chain. The capsules are bound to a
common action through a shared subject digest, computed as the
SHA-256 of the JSON Canonicalization Scheme serialisation of the
action being attested:
subject_digest = SHA-256(JCS(action))
where JCS is the JSON Canonicalization Scheme specified in [RFC8785],
and action is one action object serialised once. All capsules
composed under this appendix MUST be computed over that same
serialised action object. subject_digest is a join key across
Hillier Expires 26 April 2027 [Page 186]
Internet-Draft ARP October 2026
capsules over a shared serialisation; it is NOT a correlation key
across independently produced descriptions of an act, and MUST NOT be
used as one. See Appendix D.1.1.
The shared serialisation is established once, by the party that
authorises the action, and is echoed verbatim by every later
attester. An attester that re-serialises its own account of the
action MUST NOT compute subject_digest over that account; it MUST
carry the serialisation it received. This is what makes the digest a
join key here rather than a correlation across independent
descriptions, and a profile that cannot guarantee it is in the second
case of Appendix D.1.1 rather than the first. Implementations MUST
use [RFC8785] and MUST NOT substitute another canonicalisation. In
particular, [RFC8785] does not apply Unicode normalisation. An
implementation that normalises before serialising therefore computes
a different subject digest from a conforming implementation for any
input carrying a member name or string value that is not already in
the normalisation form it applies -- silently, since both parties
obtain a well-formed digest.
The agreement of this construction with a deployed [RFC8785] profile
depends on both parties having selected [RFC8785], which the
normative reference above makes an obligation.
[I-D.mih-sato-agent-accountability-composition] freezes a conformance
vector only once two independent implementations have recomputed it
and specifies no implementation, so no pinned corpus is cited here.
The capsules may disagree about the action -- that disagreement is
the finding ARP exists to surface -- but they do not disagree about
which action is under attestation, because they carry the same action
serialisation. Each capsule's own account travels in its payload,
committed by its receipt-payload digest below, not in subject_digest.
Two further profile-tagged digests, defined by this document rather
than by [I-D.mih-sato-agent-accountability-composition], position
each capsule for reconciliation: an authority-reference digest
committing to the authorising instrument (tagged transparency where
it is the Signing Input Digest of the COSE_Sign1 transparency
receipt, an RFC 9942 receipt being signed by the Transparency Service
and so within Section 8.11; or offline where it is the SHA-256 of the
[RFC8785] serialisation of an offline receipt payload, which carries
no signature), and a receipt-payload digest committing to the
capsule's own payload.
Each capsule is admitted to ARP as a Partial-Attestation source keyed
on the shared subject digest, in the slot
[I-D.mih-sato-agent-accountability-composition] assigns it. The
reconciliation server verifies each capsule's signature under its own
Hillier Expires 26 April 2027 [Page 187]
Internet-Draft ARP October 2026
trust anchor, projects each into the agent: predicate branch, and
aggregates the per-capsule verdicts under the Verdict Arithmetic
declared for the action class -- yielding a single, producer-agnostic
Combined Verdict over an action whose constituent attestations were
never designed to interoperate.
Where the authorised-scope capsule and the actual-conduct capsule
reconcile to divergent scopes, the Combined Verdict is no-match with
divergence axis agent-action-scope-divergence; the divergence is a
refusable control input, produced at decision time and sealed to the
Settlement-Layer Ledger without claim or capsule content.
This composition is the agent-action specialisation of the mechanism
ARP applies to sovereign registers: reconcile heterogeneous
authoritative outputs over a shared subject into one deterministic
verdict, disclose only verdict and divergence, and seal against a
Policy-Version Hash. It allows a relying party to reconcile what an
agent was permitted to do against what it did, at the moment of
action, across attestations no single party produced.
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.
Hillier Expires 26 April 2027 [Page 188]
Internet-Draft ARP October 2026
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.
Hillier Expires 26 April 2027 [Page 189]
Internet-Draft ARP October 2026
D.1.1. What a content digest does and does not establish
subject_digest is collision-resistant over content: two actions whose
serialisations differ in any byte produce different digests except
with negligible probability, so a receipt bound to one action does
not bind another. That property is what makes it usable as a join
key between capsules computed over the SAME serialised action.
It does not, and cannot, establish that two INDEPENDENTLY DESCRIBED
accounts of one act correlate. The action types, their required and
optional members and the reference issuer that minted the instances
measured below are those of
[I-D.schrock-canonical-action-identifier]; the measurement is not
reproducible without it. Where an action type declares optional
members, two conforming producers describing the same act may
legitimately differ on whether an optional member is present, and
their subject digests then differ. Stability under permitted
variation and collision resistance over content are contradictory
requirements, and no single digest satisfies both.
This is measured, not assumed. Five action objects, each a
conforming instance of one registered action type and each accepted
by that type's reference issuer, differing only in content the type
declares OPTIONAL, produced five distinct subject digests. The
divergence appeared at the first optional member and did not require
any nested reference or unusual value.
Accordingly:
* A profile MAY key capsules on subject_digest where those capsules
are computed over the same serialised action object. Appendix D
is such a profile: the capsules it composes share one action
serialisation.
* A profile that requires correlation across independently produced
descriptions of one act MUST NOT rely on subject_digest alone. It
MUST either pin the exact member set over which the digest is
computed, so that permitted variation cannot enter it, or
designate a typed field that the action type itself requires, and
correlate on that. The second is the more robust of the two,
because it does not require every producer to agree on a
serialisation before they can agree that they are describing the
same act. The selection is the profile's and not the registry's.
[I-D.schrock-canonical-action-identifier] declares required and
optional fields per action type; it does not mark any field as a
correlation key, and a specification that says an action type
"declares a material identifier" attributes to that registry a
semantic it does not carry. A profile therefore MUST pin the
Hillier Expires 26 April 2027 [Page 190]
Internet-Draft ARP October 2026
action type and its version, the field it has selected for
correlation, and that field's normalisation and comparison rules.
The selected field MUST be present in the Canonical Claim, so that
the Claim Hash commits to it and the join cannot be made on a
value the reconciliation does not cover.
Equality of the selected value identifies candidate descriptions
only. It MUST NOT establish action equivalence, authorisation or
execution. Exact-action agreement remains a separate comparison,
under the subject-digest construction of Appendix D or under the
profile of [I-D.schrock-canonical-action-identifier]. Where the
selected values match and the exact-action digests differ, that is
a conflict to surface and not a failed join, and surfacing it is
what reconciliation is for.
Three substitutions are forbidden, because each is available to an
implementer who has read only part of the foregoing and each fails
silently.
* The designated join key MUST NOT be treated as the action's
identity. The identity of an exact action is its content
commitment; the join key is stable across the variation that
commitment is required to detect, which is what makes it usable
for correlation and useless for authorisation.
* A Claim Hash MUST NOT be treated as a cross-deployment identifier.
It is a digest over a canonical serialisation preceded by the
Deployment Blinding Value of Section 5.16, so two deployments
reconciling the same claim compute different Claim Hashes by
construction, and equality of Claim Hashes across deployments is
not a comparison that can be made at all.
* Equal join keys MUST NOT be taken to mean equal claims. Two
reports sharing a designated join key have been asserted to
describe one act; whether they agree about it is the question
reconciliation exists to answer. Where their Claim Hashes differ,
the difference is the finding, and a profile that collapsed them
on the strength of the join key would report agreement it never
established.
Stated positively, each object has one job: the designated field
joins candidate reports across permitted variation, the Claim Hash
commits to the exact claim under the deployment's blinding value, and
the action type's own content commitment remains what authorisation
and execution bind to.
Hillier Expires 26 April 2027 [Page 191]
Internet-Draft ARP October 2026
A specification that describes a content digest as a correlation key
without stating which of the two preceding cases it relies on invites
an implementer to assume a stability property the construction does
not have. The resulting failure is a correlation that silently does
not occur.
Appendix E. Document History
RFC Editor: please remove this section before publication.
E.1. Since draft-hillier-scitt-arp-05
E.1.1. Mechanical
* The document is validated by both idnits and idnits3 with no error
or warning other than those that follow from the Standards Track
status itself: the downward references enumerated in the Note to
the RFC Editor, and the normative reference to
[I-D.ietf-scitt-scrapi].
* Requirement-level keywords are marked with the bcp14 element, and
the three sentences in which the verb "notarise" followed a
keyword are reworded so that the keyword and the verb are not read
as a single negated keyword.
* The obsolete Certificate Transparency reference RFC 6962 is no
longer cited. [RFC9162] is the reference, and Section 5.9 states
that the tree it defines is the tree earlier logs compute.
* The Web Bot Auth references are updated to
[I-D.ietf-webbotauth-httpsig-protocol], which defines the
Signature-Agent header and the key directory it names. The
separate directory reference is removed.
E.2. Since draft-hillier-scitt-arp-04
E.2.1. The Verifiable Credentials form is a complete profile
Section 7.6 specifies the credential form of a Reconciliation Output
in full: its members, its securing as application/vc+cose under
[W3C-VC-JOSE-COSE], the verification steps, and the mapping of the
Reliance Horizon onto validUntil. A worked example and a 30-vector
conformance class accompany it.
Hillier Expires 26 April 2027 [Page 192]
Internet-Draft ARP October 2026
E.2.2. Four securing forms for one credential
The credential is also specified in application/vc+jwt, in SD-JWT VC
(application/dc+sd-jwt) with selective disclosure of the subject
members and an optional key-binding JWT, and as an ISO/IEC 18013-5
mdoc IssuerSigned structure. The issuer's JWK Set resolves the
Sealing key for every form. All four carry the same RFC 8785 payload
under the same Sealing key, and a 30-row conformance class checks
them independently.
E.2.3. Sealing-key discovery is exercised end to end
A reconciliation server publishes its signed COSE Key Set, a single
key by identifier, and a distinct operator key set. Each entry
carries arp-key-status and arp-key-validity, retirement is by status,
and the issuer JWKS names the same key under the same thumbprint kid.
A 23-row conformance class decides resolution, status and validity,
and the refusal of each malformed set.
E.3. Since draft-hillier-scitt-arp-03
E.3.1. The chain a head-consistency check is decided over
The second branch of Section 5.23.2.4, where a witness Statement
covers a head above the one a response names, now requires the chain
between the two heads to be obtained from that witness's own origin,
as the Witness Linkage Segments of Section 5.23.2.3, and forbids
taking it from the responding service. -03 had the relying party read
that chain from the service and anchor its two ends: the top to the
Self-Entry Hash the witness signed, the bottom to the Self-Entry Hash
the response named.
Anchoring the ends of a service-supplied chain is not sufficient, and
the reason is arithmetic rather than cryptographic. The condition
anchors two Self-Entry Hashes and then walks a chain over two other
positions, the Prior-Entry Hash and the Signing Input Digest.
Neither anchored value sits in a position the chain reads. No value
the chain does read can be recomputed by a party holding linkage
arrays, a Signing Input Digest being taken over a Sig_structure and
the array carrying no preimage. And the lower anchor is the
response's own claim, so it constrains the responding service against
itself. Every value the chain is made of is supplied by the party
the chain exists to check, and an equality between two values one
party supplies is not evidence about that party.
This was established by executing the condition rather than by
reading it. An independent construction of the Ledger chain and of
the readers this document defines, written from the section text with
Hillier Expires 26 April 2027 [Page 193]
Internet-Draft ARP October 2026
nothing imported from any implementation, was run over a four-entry
Ledger under six cases: served honestly; the digest moved whole; the
digest moved with the witness observing before the move; one
Reconciliation Hash changed at entry 2 with the chain re-linked and
re-sealed and served plainly; the same rewrite with the witness-
signed Self-Entry Hash served at the top of the span and the
service's own values in every other position; and a response naming a
head its own arrays do not carry. The condition as -03 stated it
accepts the fifth. Replacing each of the nine hash positions of a
three-array span in turn identifies three the condition never
constrains, one of them an interior Self-Entry Hash, which is a value
a relying party checking a receipt against a particular entry would
otherwise take as attested.
Two narrower repairs were constructed and neither reaches. Adding
the Signing Input Digest of the covered entry to the Head Consistency
Statement and checking the top array against it is defeated by
copying one further value the witness already published, that
position being one the chain does not read. Anchoring both ends in
positions the chain does read pins the chain values of a three-array
span, and only those: the interior Self-Entry Hash is constrained by
neither anchor nor chain even there. From four arrays up the chain
values between the ends are unconstrained as well. The span is the
distance between a head a witness happened to observe and a head a
response happens to name, which the relying party does not control,
so a repair that holds only at three arrays holds only by accident.
Section 5.23.2.3 defines the artefact, its covering requirement, its
Attestation Floor, its addressing and its equivocation rule;
Section 8.8 gathers the operational consequences; Section 10.2 and
Section 10.1 register the media type and the well-known URI;
Section 9 records what unauthenticated publication of the arrays
discloses. Section 7.4.2 gains the entitlement and the ranged read a
witness needs to produce a Segment at all, a Witness Entry key not
being reached by the roles the other reads name. Section 4 gains the
artefact and restates the Witness Set and Witness Quorum entries,
which described Statements alone as the evidence.
The property is stated as what it is. A witness reads the Ledger
from the reconciliation server, so what a Segment records is what
that witness was served, under a signature it cannot revise and at a
time it stamps. The assurance is therefore append-only: a conforming
witness publishes each interval once and serves one Segment per
entry, so an operator rewriting an interval a witness has covered can
only do so with a witness that equivocates. Detection of that
equivocation is opportunistic in the way Section 5.18 already says
detection of two entries at one Entry Sequence Number is, and
Section 5.23.2.3 says so rather than leaving the impression that a
Hillier Expires 26 April 2027 [Page 194]
Internet-Draft ARP October 2026
single verifier-side test catches it. An operator rewriting an
interval no witness has yet covered is bounded by witness diversity
and observation frequency and not by this mechanism, which is the
residue Section 5.23.4 already concedes for declared independence
rather than a new one.
The first branch of Section 5.23.2.4 is unchanged: a Statement
covering the named head exactly carries no span and needs no Segment.
E.3.2. One deterministic encoding, named by section
Section 7.1 now states that Section 4.2.1 of [RFC8949] orders the
pairs of a map in the bytewise lexicographic order of the
deterministic encodings of the keys, that the Length-First Map Key
Ordering of Section 4.2.3 is a different ordering which widely used
libraries produce under an option named canonical, and that an
implementation MUST produce the former, a library option named
canonical not being evidence that it does. The two 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 runs on into the bytes after it and orders them
the same way. Those are the keys COSE admits. That is why the
difference travels, and why a protected header carrying COSE labels 1
and 4 is unaffected. They diverge only where a map mixes major types
and the key of the higher major type has the strictly shorter
encoding: a label of -1 is the single byte 0x20 and a label of 256 is
0x19 and two further bytes. No protected header this document
specifies reaches that case, and the requirement is stated so that
none added later does, since Section 7.1 permits private-use labels
pending registration and private-use labels are negative. Where the
case is reached, one protected header has two encodings, one signing
act has two Signing Input Digests, the entry above has two Prior-
Entry Hashes, and Section 5.18 treats that as a fork.
This is the Collection order class of Section 7.7 reaching a place
that section did not name. Its bullet covered the permutations of a
set and is extended here to the orderings of the pairs of a map,
which is the one member of the class where the freedom is exercised
by a library default rather than by an implementer's choice: an
implementation that reads the requirement correctly and reaches for
the obvious option still departs from it. The eight classes are
unchanged in number.
Hillier Expires 26 April 2027 [Page 195]
Internet-Draft ARP October 2026
E.3.3. A floor on the response freshness tolerance
Item 26 of Section 5.23.1 and Section 7.4.3 now floor the declared
tolerance at sixty seconds as well as capping it. The bound runs
backward from the reader's receipt of the response and the response
was produced before that instant, so a tolerance below the transit
and clock disagreement between the two parties rejects every honest
response, and a tolerance of zero rejects all of them. That is an
outage a deployment could declare itself into with no party
misbehaving and no conformance test firing, which places it with the
Witness Set constraint of Section 5.23.2 rather than with the
parameters a deployment tunes. Sixty seconds is the figure already
fixed for the forward bound of this test and of the two others that
bound a party against another's clock over a message it has just
received, so the narrowest admissible interval is symmetric. Those
three differ in their backward bounds and agree in their forward
ones. A fourth, the witness observation window of Section 5.23.2.4,
runs over an artefact published on an interval rather than over a
message, and this revision floors it at sixty seconds in both
directions while leaving the interval free to widen the forward
bound: unfloored, a deployment notarising every few seconds admitted
a window of a few seconds against an unsynchronised clock.
Section 8.7 states all four rather than leaving them to be collected.
Where a deployment's effective notarisation interval is shorter than
sixty seconds the floor governs, a ceiling below a floor being a term
no deployment can declare, and that deployment trades the
supersession property for liveness by exactly the difference between
the two figures. The trade is stated rather than left in the
arithmetic, and a deployment wanting both notarises no more often
than sixty seconds.
E.3.4. Certificate Transparency, and the leaf a proof carries
Section 5.9 now states its relationship to Certificate Transparency,
which -03 named only in its Acknowledgments while defining a Merkle
construction in its body. An implementer arriving from Certificate
Transparency had no way to tell from the text whether the two
constructions agree. The finding is Tom Sato's.
The relationship was established by executing both constructions
rather than by comparing their prose. The odd-node rule of
Section 5.9 and the recursive split at the largest power of two below
the leaf count of [RFC9162] Section 2.1.1 produce identical roots for
every leaf count from 1 to 4200, and identical sibling arrays for all
131,328 leaf-count-and-index pairs up to 512 leaves. They diverge at
one input in that whole range: the empty tree, where this document
gives thirty-two zero octets and Certificate Transparency gives the
hash of the empty string. That divergence is kept, and the section
Hillier Expires 26 April 2027 [Page 196]
Internet-Draft ARP October 2026
now says why -- the Certificate Transparency value is a digest a
verifier reproduces successfully and may then treat as a root that
commits to something, and thirty-two zero octets is a value no
commitment in this document produces.
The section also states what an implementation ported from a
Certificate Transparency log gets wrong if it is carried over
unchanged: this document sorts and deduplicates leaves where a log
commits to submission order, and this document's inclusion proof
carries the leaf where the inclusion proof of [RFC9162] Section 2.1.3
does not, carrying the index and the tree size as this document does
but assuming the verifier already holds the leaf. And it records
that the third convention in common use -- duplicating the last node
at an odd level -- agrees with this construction at *every leaf count
that is a power of two* and disagrees at every other, so a
conformance vector taken at four or eight leaves will not detect an
implementation that ported it.
Section 5.9.1 is new and is the security-relevant part. -03 defined
the inclusion proof as carrying the leaf and said nothing about where
a verifier should get the leaf it checks against. A proof whose
carried leaf is lifted unchanged from another object's valid proof
folds to the correct root under a sibling array that verifies,
because it is a correct proof of the other object; a verifier that
walks the path first and trusts the carried leaf accepts it and
concludes that the object it holds was committed. Nothing in the
walk depends on the object, so no amount of path checking detects it.
A verifier MUST now compute the leaf from the object whose inclusion
is being proved and use that value, and no value taken from the
proof, as the input to the walk. The requirement is stated over the
object rather than over the carried field because Section 5.10
permits COSE Receipts [RFC9942], whose inclusion proof carries no
leaf, and a rule written only as a comparison against a carried leaf
would be vacuous under exactly the encoding a SCITT-aware verifier is
most likely to use. The finding is Nenad Vasic's, contributed as an
executable vector against a third-party corpus.
Two errors in the -03 text of Section 5.9 are corrected. The
sibling-derivation rule said the verifier halves "the index and the
level width" as it ascends; the level width halves by *ceiling*, not
by truncation, and an implementation following the sentence literally
computes the wrong width at every leaf count that is not a power of
two -- which is the entire range the paragraph exists to pin down.
And Appendix B described COSE Receipts as "the same inclusion-proof
format", which they are not: an RFC 9942 inclusion proof carries no
leaf and is defined over the RFC 9162 tree whose empty root this
document rejects. Section 5.10 also loses a stray duplicated clause.
Hillier Expires 26 April 2027 [Page 197]
Internet-Draft ARP October 2026
E.3.5. Every digest that identifies a signed artefact
Section 8.11 is new, and five constructions changed with it. -03 took
the Prior-Entry Hash of Section 5.18 over the whole preceding entry
including its Entry Signature, the Post-Seal Evaluation Record Hash
of Section 5.17 over its record "in its entirety, signature
included", the Merkle leaf of Section 5.10 over a canonical hash of a
register-signed Partial Attestation, and the tagged-transparency
authority-reference digest of Appendix D over a COSE_Sign1 receipt.
Those four are now Signing Input Digests. The Reconciliation Hash of
Section 4 is the fifth and took a different repair, below.
The reason is a measurement. For ECDSA, (r, s) and (r, n - s) both
verify against the same key over the same message, and 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. Nothing is forged and no authority
is bypassed -- a party holding no key produces the second encoding
from the first, in transit. Over two hundred random P-256 keys, two
hundred substitutions verified and two hundred changed the entry
bytes. The finding is Anton Sokolov's.
*The Reconciliation Hash is where the repair nearly failed.* -03
defined it as excluding the Sealing Signature, and an earlier draft
of this section asserted on that basis that it was already outside
the signature and unchanged. It was not. Section 5.14 embeds a
register signature in each Query Binding Record and in each Non-
Answer Statement, so the preimage still carried a signature after the
sealing one was removed -- measured, stable in none of two hundred
trials. The Reconciliation Hash is a field of every Settlement-Layer
Ledger entry, hence inside the Entry Signature payload, hence inside
the Prior-Entry Hash: leaving it would have reintroduced at one
remove exactly what fixing the Prior-Entry Hash removed. It now
replaces each embedded register signature with that signature's
Signing Input Digest.
That is the second instance in two days of this document carrying the
sound rule and the unsound one at once. The first was in a single
bulleted list, where the Self-Entry Hash nulled the signature
position and the Prior-Entry Hash two paragraphs below it did not.
The instruction to sweep every identity rule in a document rather
than correct the one that was reported is Henri Sirkkavaara's, from
finding the same split in his own implementation on the same day, and
the Reconciliation Hash is what the second sweep found.
*Two things earlier revisions detected are no longer detectable*, and
Section 5.18 now says so rather than leaving it to be discovered.
Stripping a historical Entry Signature while leaving its protected
Hillier Expires 26 April 2027 [Page 198]
Internet-Draft ARP October 2026
header and payload intact moves no Prior-Entry Hash, and neither does
re-signing an entry under the same key and header. A re-signature
under a _different_ key or algorithm still moves the chain, because
the Sig_structure covers the protected header. The "signed exactly
once" rule consequently has no verifier-side test and is stated as an
operator obligation an Audit Identity can examine.
Section 7.1 now requires every COSE_Sign1 this document defines to
carry the algorithm and key identifiers in its protected header and
not in an unprotected one. Nothing previously required it, while
both Section 4's definition and Section 5.22's rotation argument
assumed it -- and RFC 9052 permits alg in the unprotected bucket,
which a Sig_structure does not cover. Section 4 also fixes the
external additional authenticated data at the zero-length byte
string, because a Signing Input Digest a third party cannot reproduce
is not an identifier.
Section 5.22 is rewritten where it rested on this. Its conclusion
survives and both its reason and its stated cost change. The chain
holds because the Prior-Entry Hash is over the signing input; and a
verifier recomputing one takes the protected header and payload byte
strings verbatim and MUST NOT re-encode them, which is _more_ than
-03 asked rather than less. -03 required copying bytes and hashing
them; -04 requires parsing a COSE_Sign1. That is the price of a
digest that does not move when the signature encoding does, and an
earlier draft of this section had the comparison backwards.
The consequence of the old constructions was a failure of
verification rather than of authenticity, which is the harder kind to
diagnose. A reader served a substituted entry concludes the chain is
broken when the operator equivocated about nothing; under
Section 5.9.1 it refuses a valid inclusion proof. A deployment
reporting either as detected tampering reports something that did not
happen.
[RFC8032] is added as an informative reference for Section 8.4 alone:
EdDSA puts the low-S check inside verification, so an attacker cannot
derive a second verifying byte-string, and a deployment declaring
only EdDSA primitives under item 2 of Section 5.23.1 is not reachable
by this. That is non-malleability and not a claim that one byte-
string alone can ever verify, since Section 5.1.7 of [RFC8032] leaves
cofactored verification optional. Nothing in this document requires
EdDSA, which is why the constructions and not the primitive choice
are where this is addressed.
Hillier Expires 26 April 2027 [Page 199]
Internet-Draft ARP October 2026
E.3.6. The Bilateral Register Agreement
Section 5.23 is new. The Bilateral Register Agreement is what makes
a register addressable, and -03 defined it in a definition-list entry
in Section 4: one paragraph enumerating twenty-six declared items and
the Agreement Hash construction over them. That is normative content
with MUST-level force, sited where a reader looks for a definition
and not for a requirement, and unreadable at the length it had
reached. It is now a section, the enumeration is numbered, and the
numbering is what fixes the Agreement Hash order.
Gathering it surfaced two obligations this document places on an
Agreement elsewhere and never enumerated here, so that neither was
covered by the Agreement Hash. Section 7.4.3 obliges a deployment to
declare a response freshness tolerance; that is now item 26.
Section 7.4.1 obliges an Agreement to declare the keys under which a
regulator reads, and the regulator-identity-provider trust anchor of
item 5 is not a key; that is now item 30. In both cases two
deployments could agree on every item the Agreement Hash committed
to, differ on the term, and compute the same Agreement Hash -- an
Agreement Hash that does not cover a term the Agreement is required
to carry, which is the class of defect this document exists to
prevent. Item 31 makes the re-invocation permission Section 5.21
already conditions on a declared term for the same reason.
Section 5.23.3 now fixes the CBOR type of every item and requires
every set-valued item to be sorted in bytewise lexicographic order of
the deterministic CBOR encoding of each element. Determinism under
Section 4.2.1 of [RFC8949] fixes how a given value is encoded and
does not fix which type an item takes or how a set is ordered, so
-03's construction was not one two parties could independently
compute even with the item order settled. It also states that the
array has exactly thirty-three elements and that an absent,
inapplicable or empty item is encoded as CBOR null with the element
still present, naming the four items that may be absent -- -03 said
only that an absent _optional_ item was null, while more than the one
OPTIONAL item admits absence. Since Section 8.5 suspends
reconciliation on a deviating Agreement Hash, each of these was an
outage rather than a warning.
E.3.7. The witness quorum
Section 5.23.2 specifies the witness quorum. -03 stated, in
Section 7.4.3, that a relying party acting on an empty result SHOULD
hold head-consistency evidence from at least one observer independent
of the responding service, and said in terms that it specified no
quorum. The condition was therefore normative while the thing that
satisfies it was not. The finding that this is bounded by observer
Hillier Expires 26 April 2027 [Page 200]
Internet-Draft ARP October 2026
diversity rather than by any stronger single-log property is Walter
Hawkins's, carried from -03.
What satisfies the condition in its multi-entry form is stated in the
entry above rather than here: this entry records the quorum, and the
chain a quorum is evaluated over comes from the witness under
Section 5.23.2.3.
An Agreement now declares a Witness Set and a Witness Quorum, both of
which enter the Agreement Hash. Section 5.23.2.1 gives a Witness
Entry a form and an Operating-Party Identifier with a stated
normalisation, so that "distinct" is a test a verifier computes
rather than one it decides. The exclusion runs in every direction --
a witness may not be operated by the responding service, by a party
controlling it, by a party it controls, or by a party under common
control -- because an exclusion running upward alone excludes nothing
that matters: a server that incorporates three subsidiaries satisfies
a quorum of three while controlling every observation in it.
Section 5.23.2.2 gives the Statement a payload, a media type and a
registered protected-header parameter, and carries a Witness
Observation Time, because a COSE_Sign1 is not dateable from its own
bytes and a freshness rule over an undateable artefact is a rule no
verifier can apply.
Section 5.23.2.4 requires that a Statement covering a *higher* head
be accompanied by the chain linking that head back to the one the
response names, verified by Prior-Entry Hash. A witness signature
over a higher head is otherwise evidence about whichever branch that
witness was served, and a fork at disjoint sequence numbers is
precisely a pair of heads neither of which contradicts the other;
only the linkage puts the two observations on one chain. Where that
chain is obtained is settled by the entry above, which replaced a
chain read from the responding service with the Witness Linkage
Segments of Section 5.23.2.3: the requirement to link stands, the
source of the links does not.
It also measures the freshness window from the Statement Timestamp of
the Ledger Head Statement rather than from the head's own Entry
Timestamp, and sets it at two notarisation intervals, because
Section 5.18 republishes once per interval and a one-interval window
measured from an entry's own timestamp closes before any witness can
see that entry. That window is floored at sixty seconds in both
directions, for the reason the entry on the response freshness
tolerance gives: a window narrower than the disagreement between two
unsynchronised clocks fails an honest party permanently.
Hillier Expires 26 April 2027 [Page 201]
Internet-Draft ARP October 2026
Section 5.23.2.5 puts the effective Witness Set and Quorum in the
Policy Parameters Document of Section 7.4.1. A relying party is
party to no Agreement and holds only Agreement Hashes, so a quorum
declared solely inside an Agreement is a test the party obliged to
run it cannot read.
Section 5.23.4 states what none of this establishes. Operating-Party
Identifiers are declared and not proven; the exclusion is normative
and the detection of a false declaration is not provided for. A met
quorum is proof that observer diversity was declared, by a named
party, in a term that party can be held to.
E.3.8. The head-linkage projection
Section 7.4.2 gains a fields=linkage projection returning the Entry
Sequence Number, Prior-Entry Hash, Self-Entry Hash and the Signing
Input Digest of the Entry Signature of one entry, entitled to any
requester whose signature verifies. The projection was specified so
that a relying party could link two heads itself; the entry above
supersedes that use, and the projection's reader is now the witness,
which needs the same four values to publish the Segments of
Section 5.23.2.3 and reads them for a range. The fourth element was
added after the projection was specified with three: the chain
condition of Section 5.23.2.4 compares a Prior-Entry Hash against the
Signing Input Digest of the entry below, that digest is taken over a
Sig_structure, and neither the protected header nor the payload of
the entry below is recoverable from a triple of one sequence number
and two hashes. The condition was uncomputable by the party then
required to compute it, and the substitution a reader might have
reached for instead is the one the same section forbids. The fourth
element is what a witness now commits to, so the repair holds under
the entry above rather than being superseded by it. The projection
is bounded at the head of the most recently published Ledger Head
Statement. Unbounded it would be a live head oracle -- the Ledger is
contiguous, so a requester could binary-search the current head
between publications and poll it for the write rate, which is the
disclosure Section 5.18 publishes the head only once per notarisation
interval to prevent. Section 7.4.4 states why a projection answering
200 where the full read answers 404 is not an existence oracle, and
what would make it one.
No timing claim is added by this revision and none is tested.
Section 7.4.4 continues to state that response timing is a separate
claim which an implementation must either make with its measurement
conditions published or not make at all, and that making none is not
non-conformance.
Hillier Expires 26 April 2027 [Page 202]
Internet-Draft ARP October 2026
E.3.9. Six adversarial passes, and what they found
The changes above were made in response to review. The changes below
were made in response to a sweep run against this document with the
specific intent of breaking it, from six directions at once, before
anyone else did. They are grouped by what they say about the
document rather than by section, because the grouping is the finding.
*Three sentences claiming rigour were the least rigorous sentences in
the document.*
Section 5.21.1 said the falsifiability argument holds for three
triggers in four, "stated rather than rounded up". It held for one.
Two of the three rested on a transition array published by the
reconciliation server, under its own key, in a Policy Parameters
Document with no publication time, no notarisation and no chain, so a
transition omitted from the array started no clock and no party could
date the Document well enough to show that it had been.
Section 7.4.1 now gives that Document a Publication Timestamp,
requires it to be notarised on the ledger-head interval, and requires
republication on that interval whether or not its contents changed.
The claim is now three in four and is stated as conditional on that
anchoring.
Section 8.11 said "every digest in this document that identifies or
chains a signed artefact" and enumerated five. There were seven.
The Override Record of Section 5.3 carries a COSE_Sign1 by the
authorising operator inside the Reconciliation Hash preimage, and the
Evidentiary Provenance Manifest of Section 5.1 could carry one inside
the Claim Hash preimage. The rule is now stated over the class -- in
any preimage this document defines, every signature made by a party
other than the one computing the digest is replaced by its Signing
Input Digest -- because an enumeration of carriers is correct only
until someone adds a field. The Manifest could not be repaired that
way, its preimage being [RFC8785] JSON with no byte-string type and
its octets being the requester's, so signed artefacts are now
prohibited inside it and carried beside it by digest.
Section 5.23.2 said two instances of one observer are not two
observers and tested distinctness on the Operating-Party Identifier
alone. Two entries declaring one key under two identifiers satisfied
a quorum of two with a single signature. Section 5.23.2.4 now
requires pairwise distinct Verification Method References, which is a
mechanical test, and states why that is different from the declared-
independence limit Section 5.23.4 concedes and cannot close.
Hillier Expires 26 April 2027 [Page 203]
Internet-Draft ARP October 2026
*Two paths reached a decisive verdict out of nothing.* An empty
Addressed-Registers Identifier Set yielded match under conjunction:
every operator in Section 5.13 is a condition universally quantified
over the contributions, and both precedence rules began "where any",
so at zero contributions every guard was vacuously satisfied. A
source class containing no addressed register yielded a decisive no-
match, which conjunction propagated. Neither required an operator to
misbehave. Both are now closed by explicit rules.
*Nothing bound the subject.* The transformation from the Canonical
Claim's Subject Identifier to the Subject Reference each register was
asked about was unrecorded, unconstrained and invisible to every
party outside the reconciliation server. Every signature could
verify, every binding recompute, the chain hold and the notarisation
pass, while every register answered honestly about a different
person. Section 5.4.1 adds a Subject Mapping Record carrying the
Subject Reference and a registered descriptor naming a transformation
that must be a function of the Subject Identifier and declared terms
alone.
*Evidence about a party was obtainable only from that party.* Head
Consistency Statements had an artefact, a quorum rule, a linkage
chain and a freshness window, and no channel. The obvious
implementation has the responding service supply them, which
satisfies every stated condition and defeats the mechanism entirely
under exactly the fork it exists to detect. Witnesses now publish on
their own origins and a relying party MUST NOT accept one from the
responding service.
*Vocabulary that did not reach the output.* A verifier told to refuse
a proof had no way to record which of four refusals it made;
Section 5.9.2 adds them, and requires same-act-distinct-encodings to
be tested before any outcome that accuses a party of equivocation.
One Non-Answer Reason carried five distinct causes because four other
sections directed implementations to it for conditions its own
definition never named; it is now five reasons.
Hillier Expires 26 April 2027 [Page 204]
Internet-Draft ARP October 2026
*Claims a mechanism could not support.* The Reconstruction Proof of
Section 5.20 had no pinned preimage, no wire representation, and
compares one value the audited server produced against another value
the same server produced under a key only it holds. The preimage and
the wire form are now fixed, and the stated limit is corrected:
equality establishes self-consistency across two reads and nothing
else. The Examined-Set Root's counts were said not to be bare
assertions, which Section 5.9 already contradicted; they are
assertions, made attributable and dated by the signature and the
notarisation and not made verifiable. The Regulator Portal audit
trail was called subpoena-grade with no sequence, chain, head or
notarisation behind it, and is now given all four.
*Things two implementers would encode differently.* A CBOR type table
for the Reconciliation Output; deterministic encoding stated for the
Self-Entry Hash preimage; authority origin defined as an Authority
Origin against [RFC6454]; element types for the Query Binding
preimage; a form for the Audience Member Identifier; one canonical
form for a key identifier and its two conversions; an ordering rule,
a form discriminator and an equality rule for the Source-Data Version
Identifier Set; an equality relation for the Witness Set
intersection; a member form for the fifth Divergence Axis; a subject
key for the query budget; a reference instant and direction for the
freshness window; and the edges of the Predicate Taxonomy the
projection function walks.
*Things no implementer could satisfy.* The reproducibility
requirement of Section 5 was stated as identity in every field save
an enumerated carve-out, and three fields that are necessarily fresh
were not in it. The fields=linkage projection returned three values
where the chain condition it exists to serve needs four. The
response freshness tolerance every reader must apply was readable
only by the parties who do not have to apply it. Suspension under
Section 8.5 had no defined exit.
*Privacy.* Section 9.1 takes the threats of [RFC6973] in turn and
states the residual rather than the mitigation where there is one,
including exclusion, which this protocol does not mitigate.
Section 9.2 states the one property that makes erasure implementable
against an append-only record -- no personal data enters the Ledger,
and no chain depends on the continued existence of content that could
be erased -- and prohibits notarising an Output where that disclosure
has not been accounted for.
*What was looked for and not found.* Several candidates did not
survive verification and no change was made for them: the Claim
Hash's unverifiability outside the deployment is already stated in
two places; notarisation-incomplete already distinguishes pending,
Hillier Expires 26 April 2027 [Page 205]
Internet-Draft ARP October 2026
refused and never-attempted; the register key discovery root already
has an encoding, a media type and a trust anchor; and the containment
requirement of Section 8.1 is satisfiable, though its named
enforcement measure could not reach six fields the reconciliation
server is obliged to read, which is now stated.
E.3.10. Five mechanisms taken from outside this field
The repairs above answer review. These five answer questions the
document could not previously answer at all, and each is a technique
this field has not used and another has.
*Section 7.7 -- every encoding defect is one defect.* A signature
with two byte forms, a CBOR item whose type is unfixed, a set with no
order, an optional member omitted or nulled, a URI normalised or not,
NFC or NFD, base64 or hex, transmitted bytes or a re-encoding. In
each the information is the same and the representation differs, and
the digest was defined over the representation. Physics has a name
for a quantity that must not depend on a choice carrying no
information, and the discipline that goes with it is to identify the
freedom and quotient it out rather than to patch each place it shows.
The section names the eight representation classes this document
recognises, requires every new digest to state which class each
preimage element belongs to, and requires a conformance runner to
exercise the *class* rather than an enumeration of previously
observed defects. A runner testing the two ECDSA encodings it has
heard of confirms what its author knew; a runner enumerating the
class finds the member nobody thought of.
Hillier Expires 26 April 2027 [Page 206]
Internet-Draft ARP October 2026
*Section 5.21.3 -- an estimator where there is no proof.* The sweep
identity below closes the gap between the counts and the Ledger.
Nothing closes the gap between the Ledger and the world, because an
operator that never wrote an entry has nothing to be caught
balancing, and that is the omission problem in its general form. It
has no proof and it has an estimator. An Audit Identity publishes a
commitment to a set of Claim Hashes it intends to commission, then
commissions them as ordinary reconciliations the server cannot
distinguish, then requests the inclusion proofs Section 5.21.1
already obliges the server to return. The recovery fraction
estimates the proportion of eligible Outputs the sweep actually
examined, and the shortfall estimates the population that was never
written down. Astronomy injects sources of known brightness into an
image to measure what its pipeline missed; ecology releases marked
individuals to bound a population it cannot count. Both are
estimating the same thing: what an instrument failed to record, from
a known signal passed through the same instrument. A retroactive
sweep is an instrument of that kind. The commitment precedes the
probes so that the denominator is fixed before the numerator is
knowable, which is what makes the fraction evidence rather than a
selection.
*The sweep identity in Section 5.21.1 -- accounting rather than
signature.* The examined count and the materially-changed count were
assertions of the signing server. They are now required to balance
against the Ledger: the Examined-Range Set must be contiguous over
the interval it claims, the examined count must equal the number of
reconciliation entries in it, and the materially-changed count must
equal the number of continuation-supersession entries appended over
the same interval. A signature makes an assertion attributable; an
identity makes it checkable against something the asserting party
does not solely control, which is what double-entry bookkeeping has
done for six centuries and what a conservation law does in physics.
*The Examined-Range Set -- coverage needs a dense space.* A Merkle
root over Claim Hashes proves membership and cannot prove coverage,
because Claim Hashes are sparse in the digest space and a set
commitment has no notion of what is missing from it. Entry Sequence
Numbers are dense and contiguous, so a gap in them is visible.
Committing to the same sweep in both spaces lets one artefact answer
both questions, and the choice of space is the whole of the trick.
*Section 8.13 -- locating the loss.* Several properties this document
wants cannot hold together, and a specification facing that can claim
both and be wrong somewhere a reader must find, weaken both and
deliver neither, or choose and say where the loss went. The section
is the third, in one table. What makes it useful is that the loss is
located rather than distributed: a reader who knows which property
Hillier Expires 26 April 2027 [Page 207]
Internet-Draft ARP October 2026
was surrendered and where can compensate, and a reader told that
everything holds cannot. Two rows that stood in earlier revisions
have already been retired by the mechanisms above, which is the other
thing the table turns out to be -- a list of what to attack next.
E.3.11. The two clocks a response freshness check is decided across
Section 7.4.3 now bounds the two clocks a response freshness check is
decided across. -03 required only that response-time fall within a
declared tolerance, naming no reference instant, no direction and no
forward bound, so a response-time stamped ahead of the reader's clock
was inside the tolerance on one reading and outside it on another,
and a server whose clock ran fast was indistinguishable from one
stamping ahead deliberately. The reference instant is now the
reader's receipt of the response, the direction is backward, and the
forward bound is sixty seconds. That figure is not new to this
document: it is what Section 8.6 already allowed on the Freshness
Timestamp and what Section 7.4.1 already allowed on created, both of
which protect the server against the reader's clock. The reader was
the one party to the exchange the same bound had not been applied to.
Item 26 of Section 5.23.1 now states that the declared tolerance is
the backward bound only and that the forward bound is not negotiable
per Agreement. The question is Emek Can Dogru's.
The repair invents no mechanism. It applies, in the return
direction, a bound this document had already chosen twice in the
other one.
E.3.12. Mechanical
Anchors were added to sections that had none -- Section 5.22,
Section 7.1, Section 8.5 and Section 8.9 -- so that Section 5.23 can
cite them. No heading text changed. Item 2 of Section 5.23.1 cites
Section 8.9 for the post-quantum primitives a deployment has
selected. [RFC9162] is added as an informative reference: it is the
current Certificate Transparency specification. It is not normative,
because the construction is fully specified here, so no downref is
introduced.
Hillier Expires 26 April 2027 [Page 208]
Internet-Draft ARP October 2026
Four counts are corrected. Section 5.23.1 described two of five
items as already relied on elsewhere in this document where three of
seven are, and said the Agreement Hash covers five items it did not
cover before where it covers seven, items 32 and 33 having been added
after that sentence was written. The mechanisms taken from outside
this field are five, under a heading that says so and an opening
sentence that said four. Section 10.2 requested twelve media types
while listing thirteen, and now requests fourteen. Separately and
not as a correction, Section 10.1 requests eight well-known URIs
where it requested seven, the eighth being the one a Witness Linkage
Segment is served at.
E.4. 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.
Hillier Expires 26 April 2027 [Page 209]
Internet-Draft ARP October 2026
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.
Hillier Expires 26 April 2027 [Page 210]
Internet-Draft ARP October 2026
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.
Hillier Expires 26 April 2027 [Page 211]
Internet-Draft ARP October 2026
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
Hillier Expires 26 April 2027 [Page 212]
Internet-Draft ARP October 2026
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.4.1. Five things the protocol assumed and never stated
Working through the Ledger changes made it clear that a class of gap
ran under all of them. Every discovery path in -02 ended at a value
its holder could not present to anything, and each attempt to fix one
by adding a pointer moved the dead end without removing it. Five
substrate layers were missing. They are now written, and adding them
closed more open items than any mechanism in this revision.
*Section 5.15.3 states what the pipeline returns.* No earlier
revision said that a Reconciliation Output is delivered to anybody.
The document specified in detail how an Output is composed, sealed,
digested, ledgered and notarised, and never that any party receives
one. Every discovery path begins with a party holding a
Reconciliation Hash; until now nothing said how it came to hold one.
Hillier Expires 26 April 2027 [Page 213]
Internet-Draft ARP October 2026
*Section 5.15 states who may hold an Output.* -02 made it a bearer
artefact: possession was the whole of the entitlement, it never
expired, and every read predicate the document attempted was
expressed in terms of a Requester-Binding the reader could not
present and the Ledger could not evaluate. An Output now carries a
sealed Audience Set and a Reliance Horizon. Entitlement follows the
Audience Set rather than possession, which admits the party the
Requesting Principal named and excludes the party that merely came
into possession; a register may cap how wide an Audience Set
addressing it may be, because a register that attests about a subject
is entitled to bound how far that attestation travels. The Horizon
bounds reliance without touching validity: a sanctions no-match is a
statement about lists that change daily, and an artefact asserting
one indefinitely was relied upon indefinitely.
*Section 7.4 states how a read is requested.* -02 and every draft of
this revision before it stated what a read returns and never the
endpoint, the request form, the response form, the media type, or the
error semantics -- and the two errors that matter most, "nothing
exists" and "you may not ask", are the two a reader most needs
distinguished, because a server suppressing a supersession returns
what a server with nothing to report returns. There are nine
operations. Every response, success or error, is signed and carries
the ledger head it was served against, so an empty result is an
assertion rather than an absence, and a supersession later found at
an earlier sequence number is evidence against the operator who
signed the denial. Not-entitled and not-found are both 404 with no
distinguishing body, so no endpoint is an existence oracle. Reads
are rate-limited, because a surface whose every individual answer is
innocuous discloses entry count, write rate and retroactive-burst
timing when swept.
With those in place, the Continuation entries of this revision are
reachable by the parties they were written for, a superseded Output's
replacement is retrievable because a superseding Output inherits the
Audience Set of what it supersedes, and the fork check reconciles two
heads at different sequence numbers through a signed consistency read
rather than through an unsigned answer from the party under
suspicion. Retrieval URIs, which an earlier draft of this revision
put in Continuation entries, are gone: every artefact is now fetched
by hash from the origin that served the entry, so the Ledger holds no
retrieval address, no reader is obliged to dereference an operator-
chosen URL before it can check anything, and the covert channel that
host selection and path structure carried is closed.
The published ledger head is a signed statement carrying a sequence
number, and Entry Sequence Numbers are allocated in one sequence so
that two conforming stores cannot present the same number over
Hillier Expires 26 April 2027 [Page 214]
Internet-Draft ARP October 2026
different entries. Two limits are stated rather than claimed away:
an operator publishing to two audiences at disjoint sequence numbers
never emits a colliding pair, and a party holding neither an Output
nor an agreement cannot anchor the signing key.
The Reconciliation Hash is no longer among the values required to be
reproducible across runs. Its preimage includes the Reconciliation
Timestamp, so the requirement was unsatisfiable; the Reconciliation
Identifier is the reproducible index and always was.
*Section 7.2 states how a reconciliation is commissioned.* The
document imposed obligations on "the response to the request that
commissioned it" without defining that request anywhere.
*Section 5.20 states who an auditor is.* Four requirements were
justified by what an auditor could reproduce, and the auditor was not
a party this document admitted; an Audit Identity is now declared in
a Bilateral Register Agreement, so that the audited party cannot
choose its auditor after the facts are known.
Several corrections follow from checking this document's claims about
other specifications against those specifications. The deterministic
CBOR encoding every digest here depends on is that of Section 4.2.1
of [RFC8949], which is now a normative reference; RFC 9052 narrows
those requirements to COSE's own signing structures and states no
map-key ordering rule, so the previous citation did not support what
was built on it. [RFC3339], [RFC7638], [RFC3986] and [RFC6838] are
referenced rather than named in prose. Appendix B no longer
attributes an Identity Manager or an Aggregator role to [RFC9943],
which defines neither. Appendix D no longer presents "capsule" as
that draft's term. An unsourced claim about agreement on twenty-two
pinned conformance vectors is removed, that draft having frozen none.
The EU consolidated financial sanctions list and the OFAC SDN list
are retargeted at the resources that actually publish them.
Three further sections follow from those. Section 5.9 pins the tree
both Merkle roots in this document use, with domain separation and an
inclusion- proof encoding, so that a proof produced by one
implementation verifies under another. Section 5.19.1 gives the
Sovereign Re-Notification an artefact, a payload, a media type, a
delivery endpoint and a retry obligation; it was a MUST with none of
those in -02. Section 9 states the disclosure model and the residual
risks this revision accepts rather than leaving them to be inferred
-- the subject has no standing in this protocol, an Audit Identity
reads broadly, and the published ledger head discloses a deployment's
size at the notarisation interval.
Hillier Expires 26 April 2027 [Page 215]
Internet-Draft ARP October 2026
Every digest preimage and signature payload in the document is now
pinned to a CBOR array with a normative field order and null-
substitution for absent fields: the Reconciliation Output and its
Sealing Signature, the Partial Attestation, the Per-Register Claim
Projection, the ledger entry, the Post-Seal Evaluation Record, the
Non-Answer Statement, the Ledger Head Statement, the Evaluation Sweep
Statement and the read response. -02 left several of them as "the
canonical serialisation of the foregoing", which is not a preimage
two implementations can agree on.
Homomorphic Aggregation Mode is removed and Hash-Linkage is the only
mode. The mode named no primitive, had no class in the
Cryptographic-Primitive-Upgrade Path for one to be declared in, and
defined no encrypted-contribution structure; and the reconciliation
server must read every per-register verdict in the clear in any case,
to verify the register's signature, recompute the Query Binding,
check the echoed Policy-Version Hash and apply re-typing. The
privacy property the mode advertised was therefore not available
under it, and ARP's actual minimum-disclosure property -- controlled
projection, and a Partial Attestation payload that discloses of the
subject only a verdict, a divergence axis, the applied parameters and
a digest -- is unaffected by its removal. Four homomorphic-*
Aggregation-Method Descriptors go with it.
The interface between the reconciliation server and a sovereign
register is now stated to be out of scope, and the claim that
enumerating the Per-Register Claim Projection lets two register
operators build interoperable endpoints is withdrawn. Enumerating a
structure is not specifying a binding. That leg -- an endpoint, a
media type, and a COSE_Encrypt construction pinning the AEAD and its
authenticated additional data -- is the principal item this revision
leaves for the next.
E.4.2. Ways the protocol could be gamed, closed
Section 8.1's query budget is now measured per accountable principal
per subject. A budget shared across requesters is exhausted for
everyone by any one of them -- including an unidentified agent --
which forced every reconciliation about that subject to indeterminate
for the interval. The countermeasure was a denial of service.
Exhaustion now refuses the register and not the reconciliation, which
resolves a contradiction in -02: the old text refused the
reconciliation and then recorded a Non-Answer Reason in an Output
that consequently did not exist.
A register-attested Non-Answer Reason now requires a Non-Answer
Statement signed by that register over the projection values and the
reason, and Section 5.11 records which reasons are register-attested
Hillier Expires 26 April 2027 [Page 216]
Internet-Draft ARP October 2026
and which are server-observed. Without it a register-refused was an
unattested assertion by the party that transmitted the projection,
and a server could suppress a match by claiming the register had
declined. A server can still downgrade a reconciliation by asserting
a server-observed reason and the document says so; what it can no
longer do is dress suppression as an act of the register.
Section 5.21.1 is new. Every trigger of retroactive evaluation was
server-observed, every decision to run was the server's, and nothing
recorded that a sweep had happened -- so "we evaluated and found no
change" and "we never evaluated" were the same observation from
outside. A signed Evaluation Sweep Statement per sweep, notarised on
the head interval, makes the absence of one an assertion the operator
has to make. A Source-Data Version publication is a public event
with a public timestamp; an operator with no Statement covering one
has not evaluated, which is now checkable.
The Verdict Arithmetic is resolved by the reconciliation server from
policy, keyed on the predicate and the regimes the requester names.
-02 read as though the requester declared the operator and its
threshold in its own claim, which would let it 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. Naming a regime is a claim about which law applies
and the requester is accountable for it; selecting an operator is a
determination about how evidence combines, and the deployment makes
it. source-class-quorum now carries its per-class threshold into the
Output as well as its partition, without which it was as
irreproducible as carrying neither.
The Requester-Binding gains a fourth class, agent-key-verified, for
an agent whose signing key verified but whose asserted principal was
not corroborated. -02 recorded key possession and principal binding
as one fact. An agent that signs correctly has shown it is the same
agent as last time and not that any accountable party stands behind
it; recording that as agent-verified overclaimed to every downstream
reader and recording it as agent-unverified discarded something real.
Section 5.21.2 states what revocation of a Verified Principal
Credential does and does not reach. It is not detected in the hot
path and this document does not pretend to put it there; what it does
is bound the window, by requiring an Audience Member to read
continuations before relying past the Reliance Horizon. Reliance
years later on an Output whose principal was disowned the following
week is the case that matters, and -02 left it open.
Hillier Expires 26 April 2027 [Page 217]
Internet-Draft ARP October 2026
The Override Record is enumerated, carries an Override Ground from a
new registry, and is signed by the authorising operator rather than
by the server. A record the server signs attests only that the
server says an operator authorised a bypass. It names that operator
in the clear, which is consistent with Section 5.15: blinding
protects the published Ledger, and the Output is confidential to its
Audience Set.
Retroactive Evaluation now triggers on a new Source-Data Version. It
previously triggered only on a Pattern Library or Policy Version
change, so a sanctions list republication -- the case Section 5.6 was
written for -- fired nothing. A material change now includes a
transition between decisive values: a no-match becoming a match is
the case the motivating domain cares most about, and the earlier
definition omitted it.
Homomorphic Aggregation Mode was restricted in -02 and is removed in
-03; see the -03 entry above. The Pattern-Library Version Identifier
is no longer bound as authenticated additional data: registers are
never told the pattern-library version, so binding it either failed
universally or was supplied by the party that chose it. The
Reconciliation Hash is taken over deterministic CBOR rather than
[RFC8785], because the Output is CBOR and several fields are byte
strings for which JSON has no type. Regulator Portal scope is the
intersection across agreements rather than the union, which had let
one permissive agreement widen access to a stricter register's
reconciliations.
The Freshness Timestamp is now enumerated before the signature line
in Section 5.8 and is therefore covered by it. It was listed after
the signature in earlier revisions, and both replay defence and the
new freshness-versus-skew distinction depend on it being signed.
Not adopted: a statement that a reference implementation is
forthcoming. It does not exist yet, and a draft should not carry a
claim about an artefact a reader cannot check. When it is published
it will be cited by repository and commit alongside the conformance
vectors it is checked against.
E.5. 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
Hillier Expires 26 April 2027 [Page 218]
Internet-Draft ARP October 2026
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.
Hillier Expires 26 April 2027 [Page 219]
Internet-Draft ARP October 2026
* [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.ietf-webbotauth-httpsig-protocol].
[I-D.meunier-webbotauth-registry], which defines the signature-
agent card, is retained. The directory the Signature-Agent header
names is defined in [I-D.ietf-webbotauth-httpsig-protocol], so no
separate directory reference is carried.
* 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.
Hillier Expires 26 April 2027 [Page 220]
Internet-Draft ARP October 2026
* 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
Hillier Expires 26 April 2027 [Page 221]
Internet-Draft ARP October 2026
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.6. 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.
Hillier Expires 26 April 2027 [Page 222]
Internet-Draft ARP October 2026
* 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).
Author's Address
Joel David Hillier
Certisyn, Inc.
United States of America
Email: jhillier@certisyn.com
Hillier Expires 26 April 2027 [Page 223]