



SCITT                                                         J. Hillier
Internet-Draft                                            Certisyn, Inc.
Intended status: Standards Track                              1 May 2026
Expires: 2 November 2026


                  Attestation Reconciliation Protocol
                       draft-hillier-scitt-arp-00

Abstract

   This document specifies the Attestation Reconciliation Protocol
   (ARP), a deterministic, bilateral, zero-knowledge-capable 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, projects it through register-specific controlled
   projection functions producing the greatest-lower-bound predicate
   supported by each addressed register, transmits register-specific
   ciphertexts, receives partial attestations whose payload discloses
   only a verdict and an optional divergence axis, aggregates the
   partial attestations through either homomorphic or hash-linkage
   aggregation, and seals the resulting reconciliation output against a
   policy-version hash.  An append-only cross-jurisdictional settlement-
   layer ledger records only hashes, with no 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.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   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 2 November 2026.



Hillier                  Expires 2 November 2026                [Page 1]

Internet-Draft                     ARP                          May 2026


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.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
   3.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.1.  Canonical Claim Ingestion . . . . . . . . . . . . . . . .   6
     3.2.  Adversarial Pre-Transmission Test . . . . . . . . . . . .   7
     3.3.  Per-Register Projection Function  . . . . . . . . . . . .   7
     3.4.  Per-Register Encryption . . . . . . . . . . . . . . . . .   7
     3.5.  Partial Attestation Reception . . . . . . . . . . . . . .   8
     3.6.  Aggregation . . . . . . . . . . . . . . . . . . . . . . .   8
     3.7.  Policy-Version-Hash Sealing . . . . . . . . . . . . . . .   9
     3.8.  Settlement-Layer Ledger . . . . . . . . . . . . . . . . .   9
     3.9.  Regulator Portal  . . . . . . . . . . . . . . . . . . . .  10
     3.10. Retroactive Evaluation  . . . . . . . . . . . . . . . . .  10
     3.11. Cryptographic-Primitive-Upgrade Path  . . . . . . . . . .  10
   4.  Encoding  . . . . . . . . . . . . . . . . . . . . . . . . . .  11
     4.1.  CBOR-COSE Encoding  . . . . . . . . . . . . . . . . . . .  11
     4.2.  Verifiable Credentials Interop  . . . . . . . . . . . . .  11
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
     5.1.  Service-Operator Containment  . . . . . . . . . . . . . .  11
     5.2.  Pattern-Library Integrity . . . . . . . . . . . . . . . .  12
     5.3.  Bilateral-Register-Agreement Drift  . . . . . . . . . . .  12
     5.4.  Replay Defence  . . . . . . . . . . . . . . . . . . . . .  12
     5.5.  Post-Quantum Migration  . . . . . . . . . . . . . . . . .  12
     5.6.  Side-Channel Considerations . . . . . . . . . . . . . . .  12
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  13
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  13
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  14
   Appendix A.  Examples . . . . . . . . . . . . . . . . . . . . . .  15
     A.1.  Example: Three-register Sanctions Reconciliation  . . . .  15
     A.2.  Example: Retroactive Re-evaluation  . . . . . . . . . . .  15



Hillier                  Expires 2 November 2026                [Page 2]

Internet-Draft                     ARP                          May 2026


   Appendix B.  Composition with the SCITT Architecture  . . . . . .  16
   Appendix C.  Composition with the RATS Architecture . . . . . . .  16
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  17

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

   Existing computer-implemented approaches to such cross-sovereign
   reliance suffer from three structural and technical deficiencies that
   this protocol is specifically designed to overcome:

   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.






Hillier                  Expires 2 November 2026                [Page 3]

Internet-Draft                     ARP                          May 2026


   This document specifies ARP, a protocol that addresses all three
   deficiencies in combination, and is layered atop the SCITT
   architecture [I-D.ietf-scitt-architecture] and the RATS architecture
   [RFC9334].

2.  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 permitted-predicate set, supported
      cryptographic primitives, supported aggregation capability,
      statutory-regulator-access scope, and cryptographic-primitive-
      upgrade path.  Each Bilateral Register Agreement carries an
      Agreement Hash committing to its canonicalised content.

   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 comprises
      lexicographic sorting of object keys, preservation of declared
      array order, Unicode Normalization Form C of string fields,
      canonical JSON [RFC8259] number rendering, and stripping of
      undefined values.

   Predicate Taxonomy:  A controlled hierarchical classification of
      predicates that may be the subject of reconciliation, enabling
      taxonomic prefix match in projection.

   Per-Register Claim Projection:  The narrowest structured query





Hillier                  Expires 2 November 2026                [Page 4]

Internet-Draft                     ARP                          May 2026


      sufficient to elicit the required Partial Attestation under a
      register's Bilateral Register Agreement, computed by the
      controlled projection function as the greatest-lower-bound
      predicate within the register's permitted-predicate set.

   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 only a
      Reconciliation-Verdict field and an OPTIONAL Divergence-Axis
      field; it SHALL NOT disclose any register record.

   Divergence Axis:  A controlled descriptor identifying the structural
      reason for a non-match verdict, drawn from a controlled set
      including identity-mismatch, jurisdictional-scope-mismatch,
      temporal-mismatch, ownership-threshold-mismatch, sanctions-list-
      match, register-record-absent, claim-predicate-unsupported, and
      claim-projection-narrowed-beyond-attestation-scope.

   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
      combine into the Combined Verdict, drawn from a controlled set
      including conjunction, disjunction, threshold-count, and source-
      class-quorum.

   Homomorphic Aggregation:  A cryptographic aggregation of Partial
      Attestations under a homomorphic primitive permitting verdict
      combination without decommitment of intermediate per-register
      outputs.

   Hash-Linkage Aggregation:  An aggregation of Partial Attestations in
      which the per-register attestations are canonical-hashed, ordered,
      committed to a Merkle tree, and emitted with a Merkle root and a
      per-register verdict band.

   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, and the Bilateral-
      Register- Agreement Hashes of the addressed registers.

   Settlement-Layer Ledger:  An append-only cross-jurisdictional log
      retaining only hashes of reconciliations, with no content-bearing
      fields.  Each entry comprises a sequence number, the
      reconciliation hash, the policy-version hash, the addressed-



Hillier                  Expires 2 November 2026                [Page 5]

Internet-Draft                     ARP                          May 2026


      registers identifier set, an aggregation-method descriptor, an
      optional Merkle root, a timestamp, a prior-entry hash, and a self-
      entry hash.

3.  Architecture

   ARP comprises eleven subsystems arranged as a deterministic pipeline:

   1.   Canonical Claim Ingestion

   2.   Adversarial Pre-Transmission Test

   3.   Per-Register Projection Function

   4.   Per-Register Encryption

   5.   Partial-Attestation Reception

   6.   Aggregation (Homomorphic or Hash-Linkage)

   7.   Policy-Version-Hash Sealing

   8.   Settlement-Layer Ledger Write

   9.   Regulator Portal

   10.  Retroactive Evaluation

   11.  Cryptographic-Primitive-Upgrade Path

   Given an identical Canonical Claim, 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
   bit-for-bit identical Reconciliation Outputs and Settlement-Layer
   Ledger entries.

3.1.  Canonical Claim Ingestion

   A Canonical Claim comprises:

   *  Subject Identifier

   *  Predicate (drawn from the controlled Predicate Taxonomy)

   *  Attested Value (in the canonical type for the Predicate)

   *  Applicable-Regimes Set



Hillier                  Expires 2 November 2026                [Page 6]

Internet-Draft                     ARP                          May 2026


   *  Evidentiary Provenance Manifest

   *  Claim Timestamp (RFC 3339 UTC)

   *  Claim Hash (computed over the canonical serialisation)

   Two semantically-equivalent claims MUST produce the same canonical
   form and the same Claim Hash.  The Claim Hash is the index on the
   Settlement-Layer Ledger and the key for retroactive re-evaluation.

3.2.  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 known nation-
   state evasion patterns including projection-narrowing-evasion,
   predicate-substitution- evasion, attested-value-bracketing-evasion,
   addressed-register-cherry-picking, agreement-staleness-injection, and
   pattern-library-version-pinning.

   The Subsystem emits either a Pass result or a Remediation Advisory.
   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.

3.3.  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.  The narrowing operation
   MUST be recorded in the Narrowed-From field of the Per-Register Claim
   Projection.

3.4.  Per-Register Encryption

   Each Per-Register Claim Projection MUST be encrypted under the
   addressed register's public-key material declared in the Bilateral
   Register Agreement.  The encryption operation MUST bind the
   Bilateral-Register-Agreement Hash and the Pattern-Library Version
   Identifier into the ciphertext as authenticated additional data, such
   that a register attempting to decrypt under a stale Bilateral-



Hillier                  Expires 2 November 2026                [Page 7]

Internet-Draft                     ARP                          May 2026


   Register-Agreement Hash or Pattern-Library Version Identifier fails
   at the authenticated-additional-data verification step.

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

   *  Cryptographic Signature over the canonical payload of the
      foregoing

   *  Freshness Timestamp

   The Partial Attestation payload SHALL NOT contain any register-record
   field, any pre-image of the register record, or any field beyond
   those enumerated.  The architectural absence of register-record
   content is the specific technical mechanism by which ARP avoids raw-
   record disclosure.

3.6.  Aggregation

   Where every addressed register declares Homomorphic capability, the
   aggregation subsystem operates in Homomorphic Aggregation Mode.  Per-
   register encrypted verdict contributions are aggregated through a
   homomorphic operator sequenced according to the Verdict Arithmetic
   declared in the Applicable-Regimes Set. Intermediate values remain
   cryptographically committed.

   Where any addressed register does not declare Homomorphic capability,
   the aggregation subsystem MUST operate in Hash-Linkage Aggregation
   Mode.  Each Partial Attestation is canonical-hashed, ordered by
   sorted-leaf construction, committed to a Merkle tree, and emitted
   with a Merkle root and a per-register verdict band signed by the
   reconciliation-server sealing key.  The per-register verdict band
   MUST commit each register's verdict individually without disclosure
   of any other register's payload.





Hillier                  Expires 2 November 2026                [Page 8]

Internet-Draft                     ARP                          May 2026


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

   6.  Bilateral-Register-Agreement Hashes of the addressed registers

   The Policy-Version Hash MUST be reconstructible under audit from a
   canonical policy state persisted in a policy-epoch store.

3.8.  Settlement-Layer Ledger

   Each Settlement-Layer Ledger entry comprises only:

   *  Entry Sequence Number (monotonically increasing)

   *  Reconciliation Hash

   *  Policy-Version Hash

   *  Addressed-Registers Identifier Set (sorted in canonical
      lexicographic order)

   *  Aggregation-Method Descriptor

   *  OPTIONAL Merkle Root

   *  Reconciliation Timestamp

   *  Prior-Entry Hash

   *  Self-Entry Hash

   The Ledger MUST NOT store Canonical-Claim content, register records,
   or Partial-Attestation payloads.  The append-only constraint MUST be
   enforced at the storage interface layer; the Ledger interface MUST
   expose only an APPEND operation, with no UPDATE or DELETE operation
   exposed or implemented.




Hillier                  Expires 2 November 2026                [Page 9]

Internet-Draft                     ARP                          May 2026


   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 Self-Entry Hash of the immediately preceding entry --
   MUST be preserved across all secondary stores.

3.9.  Regulator Portal

   The Regulator Portal Subsystem authenticates a sovereign regulator's
   jurisdictional credentials against a regulator-identity-provider
   trust anchor declared in at least one Bilateral Register Agreement.
   It restricts returned fields to those within the regulator's
   statutory scope as declared in the statutory-regulator-access scope
   of the Bilateral Register Agreements of the addressed registers.  The
   scope restriction is computed as the union of per-agreement
   permitted-read-predicates entries scoped to the regulator's
   jurisdiction, intersected with the regulator's requested field set.
   Each access MUST be recorded in an append-only subpoena-grade audit
   trail.

3.10.  Retroactive Evaluation

   Upon publication of an updated Pattern Library or an updated Policy
   Version, the Retroactive Evaluation Subsystem MUST execute a
   deterministic re-application of the updated policy state to retained
   reconciliation metadata of historical Reconciliation Outputs sealed
   against a superseded Policy-Version Hash.  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 transition into or out
   of a decisive verdict value (the decisive values being match and no-
   match) -- MUST trigger a Sovereign Re-Notification through the
   Regulator Portal.

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




Hillier                  Expires 2 November 2026               [Page 10]

Internet-Draft                     ARP                          May 2026


   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.

4.  Encoding

4.1.  CBOR-COSE Encoding

   The recommended 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.  The protected header
   MUST include the Bilateral-Register-Agreement Hash and Policy-Version
   Hash as unregistered labels in the range 0x800 .. 0x8FF (Certisyn
   private use).

4.2.  Verifiable Credentials Interop

   A Reconciliation Output MAY be additionally serialised as a JSON-LD
   document conforming to the W3C Verifiable Credentials Data Model
   [W3C-VC-DM-2.0], with the Reconciliation Hash, Addressed-Registers
   Identifier Set, Bilateral-Register-Agreement Hash Set, and Policy-
   Version Hash included as credential subject fields.  The COSE_Sign1
   envelope is the normative form; the Verifiable Credential
   serialisation is an interop convenience for relying parties operating
   in W3C VC ecosystems.

5.  Security Considerations

5.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 be architecturally
   prohibited from observing any register record or any Partial-
   Attestation payload beyond the verdict and divergence-axis fields.
   The service-operator entity MUST be structurally incapable of
   disclosing any register record irrespective of internal operator
   action.











Hillier                  Expires 2 November 2026               [Page 11]

Internet-Draft                     ARP                          May 2026


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

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

5.4.  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.  Stale
   Partial Attestations MUST be rejected with a freshness-stale
   divergence axis.

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

5.6.  Side-Channel Considerations

   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 2 November 2026               [Page 12]

Internet-Draft                     ARP                          May 2026


6.  IANA Considerations

   This document requests IANA to register the following:

   *  A namespace for ARP-specific COSE protected-header labels in the
      range 0x800 .. 0x8FF, containing at least:

      -  arp-bilateral-agreement-hash (label 0x801)

      -  arp-policy-version-hash (label 0x802)

      -  arp-pattern-library-hash (label 0x803)

      -  arp-divergence-axis (label 0x804)

   *  A media type application/arp-reconciliation-output+cbor for the
      CBOR-encoded Reconciliation Output.

   *  A media type application/arp-reconciliation-output+json for the
      Verifiable Credentials JSON-LD form.

7.  Acknowledgments

   This document benefits from the SCITT Architecture
   [I-D.ietf-scitt-architecture], the SCITT Receipts specification
   [I-D.ietf-scitt-receipts], and the RATS Architecture [RFC9334].

8.  References

8.1.  Normative References

   [I-D.ietf-scitt-architecture]
              Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande,
              Y., and S. Lasker, "An Architecture for Trustworthy and
              Transparent Digital Supply Chains", Work in Progress,
              Internet-Draft, draft-ietf-scitt-architecture-22, 10
              October 2025, <https://datatracker.ietf.org/doc/html/
              draft-ietf-scitt-architecture-22>.

   [I-D.ietf-scitt-receipts]
              "*** BROKEN REFERENCE ***".

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





Hillier                  Expires 2 November 2026               [Page 13]

Internet-Draft                     ARP                          May 2026


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

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

8.2.  Informative References

   [FIPS203]  "Module-Lattice-Based Key-Encapsulation Mechanism Standard
              (ML-KEM)", NIST FIPS 203, 2024,
              <https://csrc.nist.gov/publications/detail/fips/203/
              final>.

   [FIPS204]  "Module-Lattice-Based Digital Signature Standard (ML-
              DSA)", NIST FIPS 204, 2024,
              <https://csrc.nist.gov/publications/detail/fips/204/
              final>.

   [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
              Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
              2015, <https://www.rfc-editor.org/rfc/rfc7515>.

   [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
              (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
              <https://www.rfc-editor.org/rfc/rfc7519>.

   [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", STD 90, RFC 8259,
              DOI 10.17487/RFC8259, December 2017,
              <https://www.rfc-editor.org/rfc/rfc8259>.

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

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

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





Hillier                  Expires 2 November 2026               [Page 14]

Internet-Draft                     ARP                          May 2026


Appendix A.  Examples

A.1.  Example: Three-register Sanctions Reconciliation

   A relying party requests reconciliation of the predicate
   sanctions:any-list-match for subject identifier corp:DUNS:0123456789
   against the OFAC SDN list, the EU consolidated list, and the UK OFSI
   list.

   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 Homomorphic Aggregation Mode
   (all three registers declare homomorphic capability).  The Verdict
   Arithmetic is disjunction.  The Combined Verdict is no-match.

   The Reconciliation Output is sealed against the current Policy-
   Version Hash.  The Settlement-Layer Ledger entry comprises:

   *  Entry Sequence Number: 4,217,981

   *  Reconciliation Hash: <32 bytes>

   *  Policy-Version Hash: <32 bytes>

   *  Addressed-Registers Identifier Set: ["EU-CONSOLIDATED-2026-Q2",
      "UK-OFSI-2026-Q2", "US-OFAC-SDN-2026-Q2"]

   *  Aggregation-Method Descriptor: "homomorphic-disjunction"

   *  Reconciliation Timestamp: 2026-04-27T19:47:14Z

   *  Prior-Entry Hash: <32 bytes>

   *  Self-Entry Hash: <32 bytes>

   No register record content is stored on the Ledger.

A.2.  Example: Retroactive Re-evaluation

   Six weeks after the above reconciliation, OFAC adds the subject to
   the SDN list as part of a new tranche.  The OFAC register's Partial-
   Attestation endpoint, on next invocation, would return verdict match
   with divergence-axis sanctions-list-match.





Hillier                  Expires 2 November 2026               [Page 15]

Internet-Draft                     ARP                          May 2026


   The Retroactive Evaluation Subsystem detects the new Pattern-Library
   and Policy-Version transition, re-invokes Partial Attestations on all
   historical reconciliations addressing OFAC under the superseded
   Policy-Version Hash, 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.  A new Reconciliation Output is appended to
   the Ledger referencing the superseded one in its Source-
   Reconciliation-Output Identifier field.

Appendix B.  Composition with the SCITT Architecture

   The SCITT Architecture [I-D.ietf-scitt-architecture] provides
   notarisation of supply-chain artefacts, including transparency
   receipts, transparent statements, and registries.  ARP composes with
   SCITT in three 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 SCITT registries
       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.

   3.  The SCITT Architecture's Identity Manager and Issuer roles map
       cleanly to the Bilateral Register Agreement structure: each
       Sovereign Register acts as a SCITT Issuer for a constrained
       predicate set, and the reconciliation server acts as a SCITT
       Aggregator across multiple Issuers.

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:

   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.  A separate document specifies that
       specialisation.



Hillier                  Expires 2 November 2026               [Page 16]

Internet-Draft                     ARP                          May 2026


Author's Address

   Joel David Hillier
   Certisyn, Inc.
   Email: jhillier@certisyn.com














































Hillier                  Expires 2 November 2026               [Page 17]
