Upload 2 files

draft-fassbender-scitt-time-anchor-01.txt

@@ -0,0 +1,1960 @@
+
+
+
+
+Network Working Group                                      J. Fassbender
+Internet-Draft                                                   Umarise
+Intended status: Informational                             27 April 2026
+Expires: 29 October 2026
+
+
+         External Temporal Anchoring for Transparency Services
+                 draft-fassbender-scitt-time-anchor-01
+
+Abstract
+
+   This document defines a mechanism for external temporal anchoring of
+   digital artifacts by committing cryptographic hashes to an
+   independent, publicly verifiable ledger -- specifically, the Bitcoin
+   blockchain via the OpenTimestamps protocol.  The resulting proof is
+   independently verifiable by any party with access to ledger state,
+   without reliance on a trusted third party.  The SCITT Architecture
+   [RFC9943] is used as the primary integration example, but the
+   anchoring primitive is applicable to any system requiring externally
+   verifiable temporal proof.  No changes to the SCITT architecture are
+   required.
+
+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 29 October 2026.
+
+Copyright Notice
+
+   Copyright (c) 2026 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+
+
+
+
+
+
+
+Fassbender               Expires 29 October 2026                [Page 1]
+
+Internet-Draft         External Temporal Anchoring            April 2026
+
+
+   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.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
+     1.1.  Motivating Example  . . . . . . . . . . . . . . . . . . .   5
+     1.2.  Requirements Language . . . . . . . . . . . . . . . . . .   5
+     1.3.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   5
+   2.  Anchoring Model . . . . . . . . . . . . . . . . . . . . . . .   5
+     2.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   6
+     2.2.  Statement Anchoring . . . . . . . . . . . . . . . . . . .   7
+     2.3.  Log Root Anchoring  . . . . . . . . . . . . . . . . . . .   7
+     2.4.  Anchor Proof Format . . . . . . . . . . . . . . . . . . .   7
+       2.4.1.  Abstract Field Requirements . . . . . . . . . . . . .   8
+       2.4.2.  OpenTimestamps Wire Format Mapping  . . . . . . . . .   9
+     2.5.  Anchor Ledger Requirements  . . . . . . . . . . . . . . .  10
+     2.6.  Temporal Precision  . . . . . . . . . . . . . . . . . . .  10
+       2.6.1.  Temporal Claim  . . . . . . . . . . . . . . . . . . .  10
+       2.6.2.  Assumptions . . . . . . . . . . . . . . . . . . . . .  11
+       2.6.3.  Temporal Bound  . . . . . . . . . . . . . . . . . . .  11
+       2.6.4.  Non-Claims  . . . . . . . . . . . . . . . . . . . . .  11
+     2.7.  Architectural Overview  . . . . . . . . . . . . . . . . .  12
+       2.7.1.  Anchoring Flow  . . . . . . . . . . . . . . . . . . .  12
+       2.7.2.  Verification Flow . . . . . . . . . . . . . . . . . .  12
+   3.  Verification Procedure  . . . . . . . . . . . . . . . . . . .  13
+     3.1.  Verification Algorithm (VERIFY-ANCHOR)  . . . . . . . . .  13
+     3.2.  Verification Independence . . . . . . . . . . . . . . . .  15
+     3.3.  Error Conditions  . . . . . . . . . . . . . . . . . . . .  16
+   4.  Integration with SCITT Architecture . . . . . . . . . . . . .  16
+     4.1.  No Protocol Changes Required  . . . . . . . . . . . . . .  16
+     4.2.  Metadata Extension  . . . . . . . . . . . . . . . . . . .  17
+     4.3.  Receipt Association . . . . . . . . . . . . . . . . . . .  17
+     4.4.  Relationship to RFC 9921 (COSE Timestamp Headers) . . . .  17
+   5.  Formal Security Argument  . . . . . . . . . . . . . . . . . .  18
+     5.1.  Claim . . . . . . . . . . . . . . . . . . . . . . . . . .  18
+     5.2.  Assumptions . . . . . . . . . . . . . . . . . . . . . . .  18
+     5.3.  Note on Assumption A4 . . . . . . . . . . . . . . . . . .  19
+     5.4.  Proof . . . . . . . . . . . . . . . . . . . . . . . . . .  20
+     5.5.  Strength and Limitations  . . . . . . . . . . . . . . . .  20
+     5.6.  Anchor Proof Integrity  . . . . . . . . . . . . . . . . .  21
+     5.7.  Hash Algorithm Agility  . . . . . . . . . . . . . . . . .  21
+     5.8.  Ledger Availability . . . . . . . . . . . . . . . . . . .  21
+     5.9.  Equivocation Detection  . . . . . . . . . . . . . . . . .  21
+   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  22
+
+
+
+Fassbender               Expires 29 October 2026                [Page 2]
+
+Internet-Draft         External Temporal Anchoring            April 2026
+
+
+     6.1.  Threat: Hash Collision (Forged Commitment)  . . . . . . .  22
+     6.2.  Threat: Anchor Ledger Rewrite (51% Attack)  . . . . . . .  22
+     6.3.  Threat: Calendar Server Equivocation  . . . . . . . . . .  23
+     6.4.  Threat: Transparency Service Equivocation . . . . . . . .  23
+     6.5.  Threat: Temporal Claim Inflation  . . . . . . . . . . . .  23
+     6.6.  Threat: Anchor Proof Tampering  . . . . . . . . . . . . .  23
+     6.7.  Threat: Denial of Anchoring Service . . . . . . . . . . .  24
+     6.8.  Threat: Long-Term Hash Algorithm Compromise . . . . . . .  24
+     6.9.  Trust Boundary: Hash Intake . . . . . . . . . . . . . . .  24
+     6.10. Positive Property: No Long-Term Key Dependency  . . . . .  25
+     6.11. Threat: Premature Anchored State (False Finality) . . . .  25
+     6.12. Threat: Batch Integrity Compromise (Merkle Mixing)  . . .  26
+   7.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  26
+   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  27
+   9.  Normative References  . . . . . . . . . . . . . . . . . . . .  27
+   10. Informative References  . . . . . . . . . . . . . . . . . . .  28
+   Appendix A.  Relationship to Four-Layer Evidence Stack  . . . . .  29
+   Appendix B.  Example: Anchored SCITT Flow . . . . . . . . . . . .  30
+   Appendix C.  Implementation Status  . . . . . . . . . . . . . . .  30
+   Appendix D.  Acknowledgements . . . . . . . . . . . . . . . . . .  30
+   Appendix E.  OTS Anchoring Protocol -- Construction and
+           Verification  . . . . . . . . . . . . . . . . . . . . . .  31
+     E.1.  D.1.  Construction Algorithm (Anchor) . . . . . . . . . .  31
+     E.2.  D.2.  Upgrade Algorithm (Bitcoin Confirmation)  . . . . .  32
+     E.3.  D.3.  Batch Anchoring with Merkle Trees . . . . . . . . .  34
+     E.4.  D.4.  Verification Algorithm  . . . . . . . . . . . . . .  35
+     E.5.  D.5.  Verification Independence . . . . . . . . . . . . .  35
+   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  35
+
+1.  Introduction
+
+   Cryptographic time-stamping -- proving that a datum existed at or
+   before a given point in time -- is a foundational primitive for
+   audit, compliance, and non-repudiation on the Internet.
+
+   RFC 3161 [RFC3161] defines a widely deployed protocol in which a
+   trusted Time Stamping Authority (TSA) signs a timestamp token binding
+   a hash to a point in time.  The security of an RFC 3161 timestamp
+   depends on the TSA's private key, its operational continuity, and the
+   validity of its certificate chain.  If the TSA ceases operations, its
+   certificate expires without renewal, or its key is compromised,
+   previously issued timestamps may become unverifiable or disputed.
+
+
+
+
+
+
+
+
+
+Fassbender               Expires 29 October 2026                [Page 3]
+
+Internet-Draft         External Temporal Anchoring            April 2026
+
+
+   This document defines a complementary mechanism in which temporal
+   proof derives from inclusion in a public, append-only ledger
+   maintained by computational consensus -- specifically, the Bitcoin
+   blockchain.  The resulting proof is independently verifiable by any
+   party with access to ledger state, without reliance on any single
+   authority or certificate chain.
+
+   The distinction is structural:
+
+   *  RFC 3161: a trusted authority attests to the time of a hash
+      commitment.  Verification requires trust in that authority.
+   *  This document: temporal proof is a consequence of ledger
+      inclusion.  Verification requires only access to public ledger
+      state.
+
+   These approaches are not mutually exclusive.  A system MAY use both
+   RFC 3161 timestamps and ledger-based anchoring to provide
+   complementary assurance under different trust assumptions.
+
+   The SCITT Architecture [RFC9943] is used as the primary integration
+   example throughout this document.  SCITT defines a framework for
+   Transparency Services that record signed claims about digital
+   artifacts.  A Transparency Service receives Signed Statements,
+   appends them to a verifiable log, and returns cryptographic Receipts
+   proving inclusion.
+
+   SCITT is deliberately ledger-agnostic and does not mandate a specific
+   time source.  Time is derived from log position -- an internal clock
+   controlled by the Transparency Service operator.  This creates an
+   architectural gap: the system that manages the evidence also manages
+   the timeline.  The operator can:
+
+   *  Delay recording without detection
+   *  Backdate entries (within operational constraints)
+   *  Present different log views to different auditors (equivocation)
+
+   Furthermore, the Verifier does not need to trust any Calendar Server
+   or anchoring intermediary -- the trust root is Bitcoin consensus
+   itself.  This property, termed "verification independence" in this
+   document (Section 3.2), is the primary architectural distinction from
+   existing time-stamping mechanisms.  SCITT mitigates equivocation
+   through consistency proofs, but these proofs are relative to the log
+   itself.  There is no external reference point.
+
+   This document defines an OPTIONAL profile that closes this gap by
+   anchoring operations to an external, publicly verifiable ledger.  The
+   anchoring mechanism is generic and applicable beyond SCITT to any
+   system requiring externally verifiable temporal proof.
+
+
+
+Fassbender               Expires 29 October 2026                [Page 4]
+
+Internet-Draft         External Temporal Anchoring            April 2026
+
+
+1.1.  Motivating Example
+
+   An AI research laboratory produces model weights and safety
+   evaluations that must be auditable by regulators and the public.  The
+   lab registers each artifact with a SCITT Transparency Service and
+   receives a Receipt.  However, regulators ask: "How do we know the lab
+   did not register these weights after the safety evaluation was
+   already public -- backdating the claim?"
+
+   With External Temporal Anchoring, the Transparency Service submits
+   the SHA-256 hash of the Signed Statement to an anchoring service.
+   The anchoring service returns an Anchor Proof -- a portable, self-
+   contained cryptographic proof that the hash was committed to the
+   Bitcoin blockchain.  The proof is independently verifiable by any
+   party with access to Bitcoin block headers, without contacting the
+   anchoring service or the Transparency Service.
+
+   Within the next Bitcoin confirmation -- typically 10 to 60 minutes --
+   the regulator obtains a temporal guarantee: these model weights
+   existed no later than block height H.  The anchoring service provides
+   proof of existence and time, not claims about authorship, quality, or
+   regulatory compliance.
+
+1.2.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in BCP
+   14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+1.3.  Terminology
+
+   *  *Temporal Anchor*: A cryptographic commitment of a hash value to a
+      public, append-only ledger, proving that the hashed content
+      existed at or before the ledger's recorded time.
+
+   *  *Anchor Proof*: A portable, self-contained proof object (e.g., an
+      OpenTimestamps .ots file) that is independently verifiable without
+      contacting the anchoring service.
+
+   *  *Anchor Ledger*: A public, append-only data structure where no
+      single controlling authority -- including the proof issuer -- can
+      rewrite historical state or timestamps.  Bitcoin is the reference
+      Anchor Ledger in this document.
+
+2.  Anchoring Model
+
+
+
+
+Fassbender               Expires 29 October 2026                [Page 5]
+
+Internet-Draft         External Temporal Anchoring            April 2026
+
+
+2.1.  Overview
+
+   External temporal anchoring adds an independent time reference to
+   SCITT operations without modifying the SCITT architecture.  A
+   Transparency Service that implements this profile MUST anchor
+   operations to an Anchor Ledger at one or both of the following
+   levels:
+
+   1.  *Statement Anchoring* (per-statement)
+   2.  *Log Root Anchoring* (periodic)
+
+   The following diagram illustrates the actors and message flow in a
+   federated anchoring deployment:
+
+  Submitter          Calendar Servers         Bitcoin Miners    Verifier
+     |                (Alice, Bob, Finney)          |              |
+     |                                              |              |
+  1. |--SHA-256(A)-->|                              |              |
+     |               |                              |              |
+  2. |               |--aggregate--> Merkle root    |              |
+     |               |                              |              |
+  3. |               |--OP_RETURN(root)------------>|              |
+     |               |                              |              |
+  4. |               |              <--block H------|              |
+     |               |                (BIP113 MTP)  |              |
+  5. |<--.ots proof--|                              |              |
+     |  (pending->anchored)                          |              |
+     |                                              |              |
+  6. |                                              |  <--artifact+.ots
+     |                                              |              |
+  7. |                                        +-----+              |
+     |                                        |  Fetch block      |
+     |                                        |  headers directly |
+     |                                        |  (any full node)  |
+     |                                        +-----+              |
+  8. |                                              |--valid/invalid
+     |                                              |              |
+
+             Figure 1: Federated Anchoring Message Flow
+
+   Key trust property: the Verifier (step 7) retrieves block headers
+   directly from the Bitcoin network.  The Verifier does NOT need to
+   trust any Calendar Server -- if a Calendar Server equivocated, the
+   .ots proof simply fails verification against the blockchain.  The
+   trust root is Bitcoin's Proof-of-Work consensus, not any
+   intermediary.
+
+
+
+
+
+Fassbender               Expires 29 October 2026                [Page 6]
+
+Internet-Draft         External Temporal Anchoring            April 2026
+
+
+2.2.  Statement Anchoring
+
+   When a Transparency Service receives a Signed Statement, it MAY
+   compute a Temporal Anchor for that statement:
+
+   anchor_input = SHA-256(SignedStatement)
+   anchor_proof = Anchor(anchor_input, AnchorLedger)
+
+   The resulting Anchor Proof is stored alongside the SCITT Receipt.
+   Together, they provide:
+
+   *  *Receipt*: proof of inclusion in the Transparency Service log
+   *  *Anchor Proof*: proof of existence at or before time T on the
+      Anchor Ledger
+
+2.3.  Log Root Anchoring
+
+   A Transparency Service SHOULD periodically anchor the root of its
+   verifiable data structure:
+
+   log_root = MerkleRoot(TransparencyLog)
+   anchor_proof = Anchor(log_root, AnchorLedger)
+
+   This creates an external checkpoint.  If the operator later presents
+   a different log state, the anchored root provides a publicly
+   verifiable commitment against which inconsistencies can be detected.
+
+2.4.  Anchor Proof Format
+
+   An Anchor Proof MUST be:
+
+   1.  *Self-contained*: Verifiable without contacting the anchoring
+       service or the Transparency Service
+   2.  *Portable*: A standalone file that travels with the Receipt
+   3.  *Deterministic*: Given the same input bytes and ledger state,
+       verification MUST produce the same result
+
+   The verification function is:
+
+   V(B, P, L) -> { valid | invalid | unverifiable }
+
+   Where: - *B* = the bytes being verified - *P* = the Anchor Proof -
+   *L* = the Anchor Ledger
+
+   This function is defined in Section 4 of the Anchoring Specification
+   [ANCHORING].
+
+
+
+
+
+Fassbender               Expires 29 October 2026                [Page 7]
+
+Internet-Draft         External Temporal Anchoring            April 2026
+
+
+2.4.1.  Abstract Field Requirements
+
+   A conformant Anchor Proof MUST encode the following abstract fields,
+   regardless of serialization format:
+
+   +-----+---------------------+----------+---------------------------+
+   | #   | Field               | Required | Description               |
+   +-----+---------------------+----------+---------------------------+
+   | F1  | artifact_hash       | MUST     | SHA-256 digest of the     |
+   |     |                     |          | anchored byte sequence    |
+   +-----+---------------------+----------+---------------------------+
+   | F2  | hash_algorithm      | MUST     | Algorithm identifier      |
+   |     |                     |          | (MUST be "sha-256")       |
+   +-----+---------------------+----------+---------------------------+
+   | F3  | merkle_path         | MUST     | Ordered sequence of       |
+   |     |                     |          | operations linking F1 to  |
+   |     |                     |          | the ledger commitment     |
+   +-----+---------------------+----------+---------------------------+
+   | F4  | ledger_id           | MUST     | Identifier of the Anchor  |
+   |     |                     |          | Ledger (e.g., "bitcoin-   |
+   |     |                     |          | mainnet")                 |
+   +-----+---------------------+----------+---------------------------+
+   | F5  | block_height        | MUST     | Block number in which the |
+   |     |                     |          | anchor commitment appears |
+   +-----+---------------------+----------+---------------------------+
+   | F6  | block_hash          | SHOULD   | Hash of the block header  |
+   |     |                     |          | for cross-verification    |
+   +-----+---------------------+----------+---------------------------+
+   | F7  | tx_id               | SHOULD   | Transaction identifier    |
+   |     |                     |          | containing the commitment |
+   +-----+---------------------+----------+---------------------------+
+   | F8  | block_time          | MUST     | Timestamp from the block  |
+   |     |                     |          | header (see Section 2.6)  |
+   +-----+---------------------+----------+---------------------------+
+   | F9  | anchor_status       | MUST     | One of: "submitted",      |
+   |     |                     |          | "pending", "anchored",    |
+   |     |                     |          | "failed"                  |
+   +-----+---------------------+----------+---------------------------+
+   | F10 | calendar_url        | MAY      | URL of the calendar       |
+   |     |                     |          | server used for           |
+   |     |                     |          | submission                |
+   +-----+---------------------+----------+---------------------------+
+
+                 Table 1: Anchor Proof Abstract Fields
+
+   Fields F1-F5, F8, and F9 are REQUIRED for a proof with anchor_status
+   "anchored".  Fields F6-F7 are RECOMMENDED.  Field F10 is
+   informational.
+
+
+
+Fassbender               Expires 29 October 2026                [Page 8]
+
+Internet-Draft         External Temporal Anchoring            April 2026
+
+
+   A proof with anchor_status "pending" MUST contain at minimum F1, F2,
+   F9, and a partial merkle_path (F3) sufficient for later upgrade.
+
+2.4.2.  OpenTimestamps Wire Format Mapping
+
+   This profile uses the OpenTimestamps binary format as the reference
+   serialization.  The mapping from abstract fields to OTS encoding is
+   as follows:
+
+   +-----+---------------------+-------------------------------------+
+   | #   | Abstract Field      | OTS Encoding                        |
+   +-----+---------------------+-------------------------------------+
+   | F1  | artifact_hash       | Initial hash input to the proof     |
+   |     |                     | chain                               |
+   +-----+---------------------+-------------------------------------+
+   | F2  | hash_algorithm      | Implicit: SHA-256 (OTS magic byte   |
+   |     |                     | 0x08)                               |
+   +-----+---------------------+-------------------------------------+
+   | F3  | merkle_path         | Sequence of append (0xf0), prepend  |
+   |     |                     | (0xf1), and hash (0x08)             |
+   |     |                     | operations                          |
+   +-----+---------------------+-------------------------------------+
+   | F4  | ledger_id           | Attestation tag: Bitcoin (0x0588960d|
+   |     |                     | 73d71901)                           |
+   +-----+---------------------+-------------------------------------+
+   | F5  | block_height        | Derived: verifier resolves from     |
+   |     |                     | Bitcoin block headers               |
+   +-----+---------------------+-------------------------------------+
+   | F6  | block_hash          | Derived: verifier resolves from     |
+   |     |                     | Bitcoin block headers               |
+   +-----+---------------------+-------------------------------------+
+   | F7  | tx_id               | Derived: verifier resolves from     |
+   |     |                     | Bitcoin block data                  |
+   +-----+---------------------+-------------------------------------+
+   | F8  | block_time          | Derived: from block header          |
+   |     |                     | timestamp field                     |
+   +-----+---------------------+-------------------------------------+
+   | F9  | anchor_status       | Implicit: presence of attestation   |
+   |     |                     | tag = "anchored"; absence =         |
+   |     |                     | "pending"                           |
+   +-----+---------------------+-------------------------------------+
+   | F10 | calendar_url        | Encoded as pending attestation URL  |
+   |     |                     | in incomplete proofs                |
+   +-----+---------------------+-------------------------------------+
+
+            Table 2: OTS Wire Format Mapping
+
+
+
+
+
+Fassbender               Expires 29 October 2026                [Page 9]
+
+Internet-Draft         External Temporal Anchoring            April 2026
+
+
+   Note: Fields F5-F8 are "derived" in OTS because the binary proof
+   encodes the Merkle path to the Bitcoin transaction, not the block
+   metadata directly.  The verifier extracts these values by replaying
+   the proof operations against the Bitcoin blockchain.  This is a
+   design strength: the proof is compact and self-contained, while the
+   ledger provides the authoritative metadata.
+
+   An implementation MAY use an alternative serialization format
+   provided it encodes all REQUIRED abstract fields from Table 1.  A
+   future specification MAY define a CBOR-based encoding (see
+   Section 4.4).
+
+2.5.  Anchor Ledger Requirements
+
+   An Anchor Ledger used with this profile MUST satisfy the properties
+   defined in [ANCHORING] Section 7 (Ledger Qualification):
+
+   1.  *Append-only*: Historical entries cannot be modified or deleted
+   2.  *Public*: Any party can read and verify entries without
+       permission
+   3.  *No single controlling authority*: No single entity -- including
+       the proof issuer -- can rewrite historical state or timestamps
+   4.  *Independently verifiable*: Verification does not require trust
+       in any specific service or operator
+
+   Bitcoin satisfies all four requirements and is the reference Anchor
+   Ledger for this profile.
+
+2.6.  Temporal Precision
+
+   This section formally defines the temporal claim established by a
+   verified Anchor Proof, the assumptions under which the claim holds,
+   and the bounds on temporal uncertainty.
+
+2.6.1.  Temporal Claim
+
+   Given artifact A and Anchor Proof P verified against Bitcoin block B
+   at height H:
+
+   A existed at or before T_B
+
+   where T_B is the Median Time Past (MTP) of block B as defined in
+   [BIP113].  T_B is a ledger-derived temporal reference; it is not a
+   wall-clock creation time and MUST NOT be interpreted as such.
+
+
+
+
+
+
+
+Fassbender               Expires 29 October 2026               [Page 10]
+
+Internet-Draft         External Temporal Anchoring            April 2026
+
+
+   The claim is exact with respect to T_B: the uncertainty is in T_B
+   itself relative to wall-clock time, not in the claim relative to T_B.
+   The phrase "at or before" is definitive -- no tighter bound is
+   claimed or implied.
+
+2.6.2.  Assumptions
+
+   The temporal claim holds under the following assumptions:
+
+   ASSUMPTION 1 (Hash Collision Resistance): No second-preimage or
+   collision has been found for the hash algorithm identified in P.  For
+   SHA-256 [RFC6234], this assumption is supported by the current state
+   of cryptanalytic research.
+
+   ASSUMPTION 2 (Ledger Immutability): Block B at height H has not been
+   replaced by a competing chain.  This assumption strengthens with each
+   subsequent confirmation.  After six confirmations (~60 minutes),
+   reorganization is considered computationally infeasible under current
+   network conditions.
+
+   ASSUMPTION 3 (Timestamp Validity): Bitcoin miners comply with the
+   consensus rule that a block's timestamp MUST be strictly greater than
+   the MTP of the previous 11 blocks and MUST be less than the network-
+   adjusted time plus two hours [BIP113].
+
+2.6.3.  Temporal Bound
+
+   The temporal resolution of the claim is bounded by:
+
+   *  Bitcoin's block interval (~10 minutes average)
+   *  MTP consensus rules (up to 2 hours of variance from wall-clock
+      time)
+
+   These bounds are inherent to the Anchor Ledger and cannot be reduced
+   by the anchoring service or the verifier.  For use cases requiring
+   sub-minute precision, an additional time source (e.g., RFC 3161) MAY
+   be combined with anchoring to provide a complementary, finer-grained
+   timestamp.
+
+2.6.4.  Non-Claims
+
+   An Anchor Proof explicitly does NOT establish:
+
+   *  That A was created at T_B (only: existed at or before T_B)
+   *  That A was created by any specific party
+   *  That A did not exist before T_B
+   *  That T_B corresponds to wall-clock time (T_B is consensus-
+      accurate, not wall-clock-accurate)
+
+
+
+Fassbender               Expires 29 October 2026               [Page 11]
+
+Internet-Draft         External Temporal Anchoring            April 2026
+
+
+   These exclusions are consistent with [ANCHORING] Section 8 (Semantic
+   Exclusions) and Section 15 (Non-Retroactivity).
+
+2.7.  Architectural Overview
+
+   This section provides a complete actor-level view of the anchoring
+   and verification flows.  The role of Bitcoin miners is shown
+   explicitly, since miners -- not any intermediary -- are the trust
+   anchor that makes the temporal claim binding.
+
+2.7.1.  Anchoring Flow
+
+                    ANCHORING FLOW
+
+  Producer          Transparency     OTS              Bitcoin          Bitcoin
+  (Artifact)        Service          Calendar         Miners           Network
+      |                  |               |                |                |
+      |-- SHA-256(A) --->|               |                |                |
+      |                  |-- hash ------>|                |                |
+      |                  |              |-- Merkle root ->|                |
+      |                  |              |                 |-- PoW -------->|
+      |                  |              |                 |   consensus    |
+      |                  |              |                 |                |
+      |                  |<-- Receipt --|                 |<-- Block N ----|
+      |<-- Receipt + --  |              |<-- .ots proof --|                |
+      |    Anchor Proof  |              |                 |                |
+
+   Note: Miners include the Merkle root in a block.  The block is
+   accepted by the network via proof-of-work consensus.  This is the
+   moment the temporal anchor becomes binding and independently
+   verifiable.  Until inclusion in a confirmed block, the Anchor Proof
+   carries status "pending" (see F9 in Section 2.4.1) and MUST NOT be
+   relied upon as a temporal claim.
+
+2.7.2.  Verification Flow
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fassbender               Expires 29 October 2026               [Page 12]
+
+Internet-Draft         External Temporal Anchoring            April 2026
+
+
+                    VERIFICATION FLOW
+
+  Auditor           Bitcoin          Bitcoin          Transparency
+  (Verifier)        Network          Block N          Service
+      |                  |               |                |
+      |-- fetch TX ----->|               |                |
+      |<-- transaction --|               |                |
+      |                  |               |                |
+      |-- fetch header ->|               |                |
+      |<-- block header -|               |                |
+      |                  |               |                |
+      |-- walk Merkle path (from .ots proof) ------------>|
+      |<-- verify: hash matches OP_RETURN in block N -----|
+      |                  |               |                |
+      |  [optional] verify Receipt against Transparency Service
+      |---------------------------------------------------------------->|
+      |<----------------------------------------------------------------|
+      |                  |               |                |
+      |  RESULT: artifact existed at or before T_block
+      |  No contact with Umarise required.
+      |  No contact with OTS Calendar required.
+      |  Only Bitcoin block headers needed.
+
+   The Verifier's only required trust dependency is the Bitcoin block
+   header chain, which can be obtained from any full node or independent
+   block explorer.  Contact with the Transparency Service is OPTIONAL
+   and only relevant if the Verifier wishes to additionally confirm
+   SCITT log inclusion.  This separation is what allows the Anchor Proof
+   to satisfy the self-containment requirement defined in Section 2.4.
+
+3.  Verification Procedure
+
+   This section defines the normative verification algorithm for Anchor
+   Proofs produced under this profile.  An implementation that claims
+   conformance to this profile MUST implement the procedure specified in
+   Section 3.1.
+
+3.1.  Verification Algorithm (VERIFY-ANCHOR)
+
+   The verification function V(B, P, L) defined in Section 2.4 is
+   instantiated as follows:
+
+   Algorithm: VERIFY-ANCHOR(artifact_bytes, proof_bundle)
+
+   Input:
+     artifact_bytes    -- the original artifact byte sequence
+     proof_bundle      -- contains: ots_proof (.ots file),
+                          claimed_hash, origin_id,
+
+
+
+Fassbender               Expires 29 October 2026               [Page 13]
+
+Internet-Draft         External Temporal Anchoring            April 2026
+
+
+                          bitcoin_block_height (optional)
+
+   Output:
+     { valid, invalid, unverifiable }
+
+   Steps:
+
+   1.  RECOMPUTE HASH
+       computed_hash <- SHA-256(artifact_bytes)
+       The verifier MUST recompute the hash from the original
+       bytes. The verifier MUST NOT rely on any claimed hash
+       value without independent computation.
+
+   2.  COMPARE HASH
+       IF HEX(computed_hash) != STRIP-PREFIX(
+           proof_bundle.claimed_hash):
+         RETURN invalid
+         // The artifact does not match the anchored hash.
+
+   3.  PARSE OTS PROOF
+       parsed <- OTS-DESERIALIZE(proof_bundle.ots_proof)
+       The verifier MUST parse the binary .ots proof according
+       to the OpenTimestamps wire format (Section 2.4.2).
+       IF parsed IS NULL OR parsed.hash != computed_hash:
+         RETURN invalid
+
+   4.  CHECK PROOF STATUS
+       IF parsed contains only a calendar commitment (no
+       Bitcoin attestation tag 0x0588960d73d71901):
+         RETURN unverifiable
+         // The proof has not been upgraded to a Bitcoin
+         // anchor. It depends on the Calendar Server.
+
+   5.  VERIFY BITCOIN MERKLE PATH
+       The verifier MUST replay the sequence of append (0xf0),
+       prepend (0xf1), and hash (0x08) operations encoded in
+       the proof to derive the expected OP_RETURN value.
+       tx_id <- OTS-EXTRACT-TX(parsed)
+       expected_op_return <- OTS-WALK-MERKLE-PATH(
+           parsed, computed_hash)
+
+   6.  VERIFY AGAINST BITCOIN
+       The verifier MUST retrieve the Bitcoin transaction from
+       any full node, block explorer, or local block header
+       cache. The verifier MUST NOT depend on any single
+       service for this lookup.
+       bitcoin_tx <- FETCH-TX(tx_id)              [NAKAMOTO]
+       IF bitcoin_tx IS NULL:
+
+
+
+Fassbender               Expires 29 October 2026               [Page 14]
+
+Internet-Draft         External Temporal Anchoring            April 2026
+
+
+         RETURN unverifiable              // ledger unavailable
+
+       IF bitcoin_tx.OP_RETURN != expected_op_return:
+         RETURN invalid
+
+   7.  EXTRACT TEMPORAL BOUND
+       block_header  <- FETCH-BLOCK-HEADER(
+           bitcoin_tx.block_hash)
+       prev_headers  <- FETCH-PREV-HEADERS(block_header, 11)
+       timestamp_T_B <- MEDIAN(prev_headers.timestamp)  [BIP113]
+       // T_B is the Median Time Past (MTP) of block B.
+       // MTP is always strictly less than the actual
+       // inclusion time, so "existed at or before T_B"
+       // is a conservative, forward-drift-free claim.
+       // See Section 2.6.1.
+
+   8.  RETURN valid
+       // The proof demonstrates: these exact bytes existed
+       // at or before T_B (the MTP of block B). No
+       // authorship, ownership, or identity claim is made.
+       // See Section 2.6 (Temporal Precision) for the
+       // semantics of T_B.
+
+               Figure 2: VERIFY-ANCHOR Algorithm
+
+3.2.  Verification Independence
+
+   A conformant verifier MUST be able to complete the VERIFY-ANCHOR
+   procedure using ONLY:
+
+   1.  The artifact bytes (possessed by the verifier)
+   2.  The .ots proof file (portable, self-contained)
+   3.  Access to Bitcoin block headers (any full node, any block
+       explorer, or a local header cache)
+
+   A conformant verifier MUST NOT require:
+
+   *  Contact with any anchoring service or Transparency Service
+   *  An API key, account, or authentication credential
+   *  Trust in any certificate authority
+   *  The Calendar Server that issued the pending commitment
+
+   This satisfies the Independence Requirement defined in [ANCHORING]
+   Section 9: verification is possible even if the anchoring service
+   ceases to exist.
+
+
+
+
+
+
+Fassbender               Expires 29 October 2026               [Page 15]
+
+Internet-Draft         External Temporal Anchoring            April 2026
+
+
+3.3.  Error Conditions
+
+   The VERIFY-ANCHOR algorithm produces three possible outputs.
+   Implementations MUST handle each as follows:
+
+   +----------------+------------------------------------------+
+   | Output         | Meaning                                  |
+   +----------------+------------------------------------------+
+   | valid          | The artifact bytes match the anchored     |
+   |                | hash, the Merkle path is correct, and    |
+   |                | the Bitcoin transaction confirms the      |
+   |                | commitment. The artifact existed at or    |
+   |                | before T_B (the MTP of the containing    |
+   |                | block), as defined in Section 2.6.1.     |
+   +----------------+------------------------------------------+
+   | invalid        | The artifact does not match the anchored  |
+   |                | hash (step 2), the proof fails to parse   |
+   |                | (step 3), or the Merkle path does not     |
+   |                | match the Bitcoin OP_RETURN (step 6).     |
+   |                | The verifier SHOULD treat this as a       |
+   |                | verification failure.                     |
+   +----------------+------------------------------------------+
+   | unverifiable   | The proof is pending (step 4) or the      |
+   |                | Bitcoin ledger is unavailable (step 6).   |
+   |                | The verifier SHOULD retry after a delay.  |
+   |                | A pending proof MAY become verifiable     |
+   |                | after Bitcoin confirmation (~2-4 hours).  |
+   +----------------+------------------------------------------+
+
+             Table 3: VERIFY-ANCHOR Output Semantics
+
+4.  Integration with SCITT Architecture
+
+4.1.  No Protocol Changes Required
+
+   This profile is additive.  It does not modify:
+
+   *  The Signed Statement format
+   *  The Receipt format
+   *  The Transparency Service API
+   *  The consistency or inclusion proof mechanisms
+
+   A Transparency Service operator MAY adopt this profile unilaterally.
+   Auditors MAY verify Anchor Proofs independently of the SCITT
+   verification flow.
+
+
+
+
+
+
+Fassbender               Expires 29 October 2026               [Page 16]
+
+Internet-Draft         External Temporal Anchoring            April 2026
+
+
+4.2.  Metadata Extension
+
+   A Transparency Service that implements this profile SHOULD include
+   anchor metadata in its service parameters:
+
+   {
+     "anchor_ledger": "bitcoin",
+     "anchor_method": "opentimestamps",
+     "anchor_level": "log_root",
+     "anchor_interval": "batch",
+     "anchor_spec": "https://anchoring-spec.org/v1.0/"
+   }
+
+4.3.  Receipt Association
+
+   An Anchor Proof MAY be associated with a Receipt by including the
+   Anchor Proof hash in the Receipt's metadata, or by co-locating the
+   .ots file with the Receipt in a proof bundle.
+
+4.4.  Relationship to RFC 9921 (COSE Timestamp Headers)
+
+   RFC 9921 defines two COSE header parameters -- 3161-ctt and 3161-ttc
+   -- for embedding RFC 3161 Time-Stamp Tokens directly inside
+   COSE_Sign1 structures [RFC9052].  This establishes a precedent: COSE
+   already supports binding external temporal proofs to signed objects
+   without modifying the object's payload.
+
+   This profile extends the same principle to a different trust model:
+
+   +------------------------------------------------------+
+   |  RFC 9921          |  This Profile                   |
+   +------------------------------------------------------+
+   |  Trust root: CA    |  Trust root: Consensus (PoW)    |
+   |  Proof: TST token  |  Proof: .ots file               |
+   |  Precision: ms     |  Precision: block (~10 min)     |
+   |  Binding: COSE hdr |  Binding: Anchor Proof or hdr   |
+   |  Verifier trusts:  |  Verifier trusts:               |
+   |    TSA + CA chain  |    Bitcoin blockchain            |
+   |  Offline verify:   |  Offline verify:                |
+   |    With CA certs   |    With block headers            |
+   +------------------------------------------------------+
+
+   The two mechanisms are complementary.  A Transparency Service MAY
+   implement both -- producing a dual-anchored Anchor Proof that
+   combines CA-rooted precision (RFC 3161 via RFC 9921) with consensus-
+   rooted independence (OpenTimestamps via this profile).
+
+
+
+
+
+Fassbender               Expires 29 October 2026               [Page 17]
+
+Internet-Draft         External Temporal Anchoring            April 2026
+
+
+   A COSE header parameter for OpenTimestamps proofs is out of scope for
+   this document but could be defined in a future specification,
+   following the pattern established by RFC 9921.  Such a specification
+   could define a CBOR-based serialization of the abstract fields in
+   Section 2.4.1 (Table 1), using COSE_Sign1 as the envelope, analogous
+   to how RFC 9921 embeds RFC 3161 TST tokens.  The abstract field table
+   in this document is designed to facilitate such mapping without
+   requiring changes to the anchoring model itself.
+
+5.  Formal Security Argument
+
+   This section provides a formal argument supporting the central claim
+   of the External Temporal Anchoring mechanism.
+
+5.1.  Claim
+
+   *Theorem (Existence-at-or-before-T)*: If VERIFY-ANCHOR(A, P) = valid
+   (Section 3.1), then the byte sequence A existed at or before time T,
+   where T is the timestamp of the Bitcoin block containing the anchor
+   commitment.
+
+5.2.  Assumptions
+
+   The proof relies on the following assumptions, each of which is a
+   well-established property of the underlying primitives:
+
+   *  *A1 (Collision Resistance)*: SHA-256 is collision-resistant.  That
+      is, no computationally bounded adversary can find distinct inputs
+      x != y such that SHA-256(x) = SHA-256(y) [FIPS180-4].
+
+   *  *A2 (Ledger Immutability)*: The Bitcoin blockchain is append-only
+      and infeasible to rewrite for any confirmed block.  Specifically,
+      a transaction included in block B with k >= 6 confirmations cannot
+      be removed or altered without controlling a majority of the
+      network's hash power [NAKAMOTO].
+
+   *  *A3 (Temporal Ordering)*: Bitcoin block timestamps are constrained
+      by consensus rules.  A block's timestamp must be greater than the
+      median of the previous 11 blocks [BIP113].  The maximum forward
+      drift permitted by nodes is 2 hours.  Therefore, for a block with
+      timestamp T_b, the block was accepted by the network within the
+      interval [T_b - tolerance, T_b + 2h], and any transaction in that
+      block was submitted before the block was mined.
+
+
+
+
+
+
+
+
+Fassbender               Expires 29 October 2026               [Page 18]
+
+Internet-Draft         External Temporal Anchoring            April 2026
+
+
+   *  *A4 (OTS Correctness)*: The OpenTimestamps proof format provides a
+      deterministic chain of hash operations from an input hash H to a
+      value embedded in a Bitcoin transaction's OP_RETURN output [OTS].
+      This chain is publicly verifiable.  The normative algorithms for
+      construction and verification are specified in Appendix D of this
+      document; see Section 5.2.1.
+
+   *  *A5 (Operator Independence)*: The anchoring service and any
+      intermediary may fail, be compromised, or cease operations without
+      affecting the validity of previously issued proofs.  The temporal
+      claim is grounded in Bitcoin consensus, not in the continued
+      operation or trustworthiness of the anchoring service operator.
+      This assumption is supported by the verification independence
+      requirement in Section 3.2: a conformant verifier requires only
+      the artifact bytes, the .ots proof, and access to Bitcoin block
+      headers.
+
+5.3.  Note on Assumption A4
+
+   OpenTimestamps [OTS] is a deployed open-source protocol with multiple
+   independent implementations and a public project site [OTS-SITE].  It
+   does not, however, have a formal IETF or ISO specification.  This
+   profile therefore treats OpenTimestamps as a *reference
+   implementation*, not as a normative dependency.
+
+   The security argument of Section 5.3 does not rely on the correctness
+   of any particular OTS software library.  Assumption A4 reduces to the
+   correctness of two well-understood primitives that are fully
+   specified in Appendix D:
+
+   1.  *SHA-256 Merkle tree construction* (Appendix D.1, D.2): Binary
+       hash trees as described in [RFC6962], Section 2.1.
+
+   2.  *Bitcoin transaction parsing and block header verification*
+       (Section 3.1, steps 5-7): OP_RETURN output identification and
+       block confirmation depth checking per [BIP141].
+
+   Both primitives are independently verifiable against the Bitcoin
+   blockchain without reference to any OTS software.  Appendix D
+   provides self-contained pseudocode sufficient to implement
+   verification from first principles.  If the OTS reference
+   implementation were to become unavailable, the algorithms in
+   Appendix D remain sufficient to verify any proof produced under this
+   profile.
+
+
+
+
+
+
+
+Fassbender               Expires 29 October 2026               [Page 19]
+
+Internet-Draft         External Temporal Anchoring            April 2026
+
+
+5.4.  Proof
+
+   Let A be an artifact (byte sequence), and let P be a proof Anchor
+   Proof for which VERIFY-ANCHOR(A, P) returns valid.
+
+   *Step 1*: By steps 1-2 of the verification algorithm (Section 3.1),
+   SHA-256(A) = H, where H is the hash committed in the Anchor Proof.
+   By assumption A1, A is the unique preimage of H with overwhelming
+   probability (2^-128 security level for second preimage).
+
+   *Step 2*: By steps 3 and 5, the .ots proof contains a deterministic
+   sequence of hash operations linking H to a value V embedded in a
+   Bitcoin transaction TX.  By assumption A4, this chain is correct and
+   verifiable: V = f(H) where f is the composition of the Merkle path
+   operations.
+
+   *Step 3*: By step 6, the Bitcoin transaction TX exists in block B and
+   TX.OP_RETURN = V.  By assumption A2, TX was included in B at the time
+   B was mined, and this inclusion cannot be retroactively altered.
+
+   *Step 4*: By step 7, block B has Median Time Past T_B, computed per
+   [BIP113] as the median of the timestamps of the 11 blocks preceding
+   B.  By assumption A3, Bitcoin consensus requires that the actual time
+   at which B was accepted by the network is strictly greater than T_B
+   (since T_B is the median of prior blocks, it is always behind actual
+   inclusion time).  Therefore, transaction TX -- which commits to V,
+   which commits to H, which commits to A -- existed before block B was
+   mined.
+
+   *Step 5*: The hash commitment is causal: to produce H, the artifact A
+   must have existed before H was computed.  To include H in the OTS
+   Merkle tree that produces V, H must have existed before TX was
+   broadcast.  To include TX in block B, TX must have existed before B
+   was mined.
+
+   *Therefore*: A existed -> H was computed -> TX was broadcast -> B was
+   mined at an actual time strictly greater than T_B.  The artifact A
+   existed at or before T_B (the Median Time Past of block B at height
+   H), as defined in Section 2.6.1.  No 2-hour tolerance caveat applies:
+   T_B is a conservative lower bound on the actual inclusion time by
+   construction. [end]
+
+5.5.  Strength and Limitations
+
+   The above argument is a *computational security* argument, not an
+   information-theoretic proof.  Its strength is bounded by:
+
+
+
+
+
+Fassbender               Expires 29 October 2026               [Page 20]
+
+Internet-Draft         External Temporal Anchoring            April 2026
+
+
+   1.  The collision resistance of SHA-256 (currently 128-bit security
+       level)
+   2.  The cost of a sustained 51% attack on Bitcoin, which depends on
+       then-current network conditions and is external to this
+       specification
+   3.  The 2-hour temporal tolerance inherent to Bitcoin block
+       timestamps
+
+   The argument does NOT prove: - When exactly A was created (only an
+   upper bound on existence) - Who created A (no identity binding) -
+   That A has not been modified since anchoring (only that these
+   specific bytes existed)
+
+   These limitations are inherent to the mechanism and are documented in
+   [ANCHORING] Section 8 (Semantic Exclusions).
+
+5.6.  Anchor Proof Integrity
+
+   The Anchor Proof does not replace the SCITT Receipt.  It provides an
+   independent temporal claim.  If the Anchor Proof is lost or
+   corrupted, the Receipt remains valid within the SCITT framework.  The
+   temporal independence guarantee is degraded but the claim integrity
+   is unaffected.
+
+5.7.  Hash Algorithm Agility
+
+   This profile specifies SHA-256 as the hash function for anchor
+   inputs.  If SHA-256 is deprecated, the Anchor Ledger requirement
+   (Section 2.5) remains valid with a successor hash function.  The
+   anchoring mechanism is hash-agile by design.
+
+5.8.  Ledger Availability
+
+   Bitcoin's availability characteristics exceed those of any single-
+   operator Transparency Service.  However, Anchor Proof verification
+   requires access to the Bitcoin blockchain (or a trusted copy).
+   Offline verification is possible with a local blockchain copy or
+   cached block headers.
+
+5.9.  Equivocation Detection
+
+   Log Root Anchoring (Section 2.3) enables equivocation detection: if a
+   Transparency Service presents different log states to different
+   parties, the anchored root provides a public commitment that can be
+   compared.  This is a strictly stronger guarantee than SCITT provides
+   without external anchoring.
+
+
+
+
+
+Fassbender               Expires 29 October 2026               [Page 21]
+
+Internet-Draft         External Temporal Anchoring            April 2026
+
+
+6.  Security Considerations
+
+   This section follows the guidelines in [RFC3552] for describing
+   threats and mitigations relevant to the External Temporal Anchoring
+   mechanism defined in this document.
+
+   The attacker model assumes the following capabilities:
+
+   *  The attacker can observe all network traffic between the
+      submitter, the anchoring service, Calendar Servers, and the Anchor
+      Ledger.
+   *  The attacker can operate one or more Calendar Servers.
+   *  The attacker can submit arbitrary hashes to the anchoring service.
+   *  The attacker cannot find collisions or second pre-images for
+      SHA-256 (Assumption A1, Section 5.2).
+   *  The attacker cannot rewrite confirmed Bitcoin blocks with k >= 6
+      confirmations (Assumption A2, Section 5.2).
+   *  The attacker cannot control a majority of Bitcoin's network hash
+      power.
+
+   The following subsections enumerate specific threats under this
+   model.
+
+6.1.  Threat: Hash Collision (Forged Commitment)
+
+   An attacker could construct a second artifact B such that SHA-256(B)
+   = SHA-256(A), thereby claiming that the anchor for artifact A also
+   proves the existence of artifact B.
+
+   This is remediated by the collision resistance of SHA-256
+   [FIPS180-4].  No known practical collision attack exists against
+   SHA-256 as of the date of this document.  The Construction Algorithm
+   (Appendix D.1) is hash-algorithm- agile: if SHA-256 is weakened, the
+   hash_algo field permits migration to a successor algorithm without
+   protocol changes.
+
+6.2.  Threat: Anchor Ledger Rewrite (51% Attack)
+
+   An attacker with majority hash power on the Anchor Ledger could
+   rewrite the block containing the commitment, thereby invalidating or
+   altering the temporal proof.
+
+   This is remediated by the economic cost of sustaining a majority
+   attack on Bitcoin, which is the only Anchor Ledger currently
+   qualified under the Anchoring Specification [ANCHORING] Section 7
+   (Ledger Qualification).  The economic and operational cost of
+   producing a competing chain with greater accumulated proof-of-work
+   depends on then-current Bitcoin network conditions and is external to
+
+
+
+Fassbender               Expires 29 October 2026               [Page 22]
+
+Internet-Draft         External Temporal Anchoring            April 2026
+
+
+   this specification.  The Verification Algorithm (Section 3.1)
+   requires a minimum confirmation depth before accepting an anchor as
+   valid.
+
+6.3.  Threat: Calendar Server Equivocation
+
+   An attacker operating a compromised OpenTimestamps calendar server
+   could return divergent intermediate commitments to different clients,
+   or withhold a valid commitment entirely.
+
+   This is remediated by the OTS protocol design: multiple independent
+   Calendar Servers provide redundant commitment paths.  The final
+   anchor is a Bitcoin transaction, not a calendar assertion.  A
+   verifier does not need to trust any Calendar Server -- verification
+   uses only the Bitcoin blockchain (Section 2.1, step 7).  A Calendar
+   Server that equivocates produces proofs that fail verification.
+
+6.4.  Threat: Transparency Service Equivocation
+
+   A malicious Transparency Service operator could present different log
+   states to different relying parties while anchoring only one version.
+
+   This is remediated by Log Root Anchoring (Section 2.3).  Because the
+   anchored Merkle root is committed to the public ledger, any party
+   holding a Receipt can independently compute the expected root and
+   compare it against the anchored value.  Divergent log states are
+   detectable by any two parties that compare their anchored roots.
+
+6.5.  Threat: Temporal Claim Inflation
+
+   An attacker could claim that the anchor proves existence at a time
+   earlier than the actual anchoring.  For example, asserting that T
+   equals the block timestamp minus an arbitrary margin.
+
+   This is remediated by the formal time semantics defined in
+   Section 5.1.  The anchor provides an existence-at-or-before-T
+   guarantee where T is the consensus-confirmed block inclusion time.
+   The protocol does not claim to prove existence at the exact moment of
+   hash creation -- only that the hash existed no later than T.
+   Verifiers MUST NOT interpret T as the creation time of the artifact.
+
+6.6.  Threat: Anchor Proof Tampering
+
+   An attacker could modify the certificate.json or .ots proof file
+   within an Anchor Proof after generation, for example by altering the
+   captured_at timestamp or substituting a different hash value.
+
+
+
+
+
+Fassbender               Expires 29 October 2026               [Page 23]
+
+Internet-Draft         External Temporal Anchoring            April 2026
+
+
+   This is remediated by the cryptographic binding between the
+   components.  The .ots proof commits to a specific hash value; any
+   modification to certificate.json that changes the hash breaks the OTS
+   verification chain.  The Verification Algorithm (Section 3.1) re-
+   derives the hash from the original artifact bytes and verifies it
+   against the .ots proof independently -- it does not trust the
+   metadata in certificate.json.
+
+6.7.  Threat: Denial of Anchoring Service
+
+   An attacker could prevent the Transparency Service from submitting
+   commitments to the Anchor Ledger, for example via a denial-of-service
+   attack on the Calendar Servers or the Transparency Service's network
+   connectivity.
+
+   This is remediated by the asynchronous design of the protocol
+   (Section 2.1).  Commitments can be retried.  The Transparency Service
+   retains the pending .ots proof and resubmits when connectivity is
+   restored.  During the outage, existing anchored proofs remain
+   independently verifiable.  New Signed Statements are still recorded
+   by the Transparency Service; only their external temporal anchoring
+   is delayed.
+
+6.8.  Threat: Long-Term Hash Algorithm Compromise
+
+   Over decades, SHA-256 may become vulnerable to collision or pre-image
+   attacks due to advances in computing (including quantum computing).
+
+   This is remediated by the algorithm-agility provision in the
+   protocol.  The hash_algo field in the anchor record (Section 2.4.1,
+   field F2) permits migration to a successor hash algorithm.  Existing
+   proofs anchored with SHA-256 retain their validity for the period
+   during which SHA-256 was considered secure.  The Anchoring
+   Specification [ANCHORING] Section 15 defines the temporal semantics
+   that bound this validity window.
+
+6.9.  Trust Boundary: Hash Intake
+
+   The anchoring service proves that a given hash existed at or before a
+   certain time.  It does not, and cannot, prove the truth, accuracy, or
+   origin of the data that produced that hash.
+
+   An attacker could submit the hash of a fabricated or falsified
+   artifact before anchoring.  The resulting proof would be
+   cryptographically valid and temporally bound, yet the underlying data
+   would be false.
+
+
+
+
+
+Fassbender               Expires 29 October 2026               [Page 24]
+
+Internet-Draft         External Temporal Anchoring            April 2026
+
+
+   This is not remediated by the protocol.  It is an explicit trust
+   boundary: the anchoring service guarantees temporal existence of a
+   hash commitment, not the integrity or authenticity of the pre-image
+   data.  Consumers of anchor proofs MUST apply independent verification
+   of the artifact content, authorship, and provenance outside the scope
+   of this specification.
+
+6.10.  Positive Property: No Long-Term Key Dependency
+
+   Unlike certificate-based timestamping mechanisms (e.g., RFC 3161),
+   Anchor Proofs do not depend on any signing key, certificate chain, or
+   key management infrastructure.  The proof's validity derives from the
+   mathematical properties of hash functions and the computational
+   consensus of the Anchor Ledger.
+
+   This eliminates three threat categories that apply to key-based
+   timestamping:
+
+   *  *Key compromise*: There is no private key that, if exposed, would
+      allow an attacker to forge timestamps.
+   *  *Certificate expiration*: There is no certificate whose expiry
+      would invalidate existing proofs.
+   *  *Authority revocation*: There is no trusted authority whose
+      revocation would render proofs unverifiable.
+
+   An Anchor Proof verified today remains verifiable indefinitely,
+   provided SHA-256 retains its collision resistance (Section 6.8) and
+   the Anchor Ledger remains accessible (Section 6.7).
+
+6.11.  Threat: Premature Anchored State (False Finality)
+
+   An attacker -- or a faulty implementation -- could mark a proof as
+   "anchored" before the Bitcoin transaction has reached a durable
+   confirmation depth.  A relying party that accepts an "anchored"
+   status asserted by the anchoring service could be misled into relying
+   on a temporal proof that is subsequently invalidated by a chain
+   reorganization.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fassbender               Expires 29 October 2026               [Page 25]
+
+Internet-Draft         External Temporal Anchoring            April 2026
+
+
+   This is remediated by two independent controls.  First, the
+   Verification Algorithm (Section 3.1) requires the verifier to
+   independently retrieve the Bitcoin transaction and confirm block
+   inclusion -- the verifier does not rely on any status field asserted
+   by the anchoring service.  Second, Assumption A2 (Section 5.2)
+   specifies that a minimum of six confirmations (~60 minutes) must be
+   reached before the immutability assumption is considered
+   computationally sound.  Implementations MUST NOT promote a proof from
+   "pending" to "anchored" (field F9, Section 2.4.1) until the
+   transaction has reached the minimum confirmation depth required by
+   their deployment policy.
+
+6.12.  Threat: Batch Integrity Compromise (Merkle Mixing)
+
+   In the batch anchoring mode (Appendix D.3), an implementation error
+   in the Merkle tree construction could incorrectly associate hashes
+   from different submitters within the same batch.  A defective batch
+   could produce a valid-appearing Anchor Proof that binds a hash to an
+   incorrect Merkle position, undermining the evidence integrity of all
+   origins in the batch.
+
+   This is remediated by the Batch Anchoring algorithm (Appendix D.3),
+   which specifies deterministic leaf ordering (lexicographic sort
+   before concatenation) and requires individual origin records per hash
+   in addition to the shared Merkle root anchor.  A verifier can
+   independently recompute the Merkle path from a leaf hash to the root
+   and confirm correct positioning.  Post-batch verification sampling
+   SHOULD be performed by implementations to detect systematic
+   construction errors before they are exposed to relying parties.
+
+7.  Privacy Considerations
+
+   The External Temporal Anchoring mechanism operates on cryptographic
+   hashes only.  No artifact content, personal data, or identity
+   information is transmitted to or stored on the Anchor Ledger.
+
+   However, the following privacy-relevant properties apply:
+
+   *  The hash of an artifact is a unique identifier.  An observer who
+      independently possesses the artifact can confirm whether it was
+      anchored by computing the hash and searching for a matching
+      commitment.
+
+   *  Bitcoin transactions are publicly visible and permanent.  An
+      anchored hash cannot be removed from the ledger.
+
+   *  The temporal ordering of anchored hashes is public.  An observer
+      can determine that hash A was anchored before hash B.
+
+
+
+Fassbender               Expires 29 October 2026               [Page 26]
+
+Internet-Draft         External Temporal Anchoring            April 2026
+
+
+   Implementations that anchor hashes of privacy-sensitive artifacts
+   SHOULD inform users that the hash becomes a permanent, publicly
+   queryable identifier on the anchor ledger.
+
+   In multi-tenant deployments, anchored hashes from different tenants
+   appear on the same public ledger within the same Bitcoin blocks.  An
+   observer with access to hashes from multiple tenants can determine
+   temporal ordering relationships across tenants -- including whether
+   two artifacts were anchored in the same batch -- even when no
+   artifact content is disclosed.  Implementations that anchor on behalf
+   of multiple tenants SHOULD be aware that the public ledger creates a
+   permanent, cross-tenant ordering record.  The 2-hour maximum forward
+   drift in Bitcoin block timestamps (Section 2.6.3, Assumption A3)
+   defines the worst-case window within which ordering observations are
+   unreliable; within a single confirmed block (~10 minutes), ordering
+   between co-batched hashes is not preserved by the protocol.
+
+8.  IANA Considerations
+
+   This document has no IANA actions.
+
+9.  Normative References
+
+   [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/info/rfc2119>.
+
+   [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/info/rfc8174>.
+
+   [FIPS180-4]
+              National Institute of Standards and Technology, "Secure
+              Hash Standard (SHS)", FIPS PUB 180-4,
+              DOI 10.6028/NIST.FIPS.180-4, August 2015,
+              <https://doi.org/10.6028/NIST.FIPS.180-4>.
+
+   [ANCHORING]
+              Fassbender, J., "Anchoring Specification (IEC), Version
+              1.0", DOI 10.5281/zenodo.19537321, February 2026,
+              <https://doi.org/10.5281/zenodo.19537321>.
+
+   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
+              Text on Security Considerations", BCP 72, RFC 3552,
+              DOI 10.17487/RFC3552, July 2003,
+              <https://www.rfc-editor.org/info/rfc3552>.
+
+
+
+
+Fassbender               Expires 29 October 2026               [Page 27]
+
+Internet-Draft         External Temporal Anchoring            April 2026
+
+
+10.  Informative References
+
+   [RFC3161]  Adams, C., Cain, P., Pinkas, D., and R. Zuccherato,
+              "Internet X.509 Public Key Infrastructure Time-Stamp
+              Protocol (TSP)", RFC 3161, DOI 10.17487/RFC3161, August
+              2001, <https://www.rfc-editor.org/info/rfc3161>.
+
+   [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/info/rfc9052>.
+
+   [RFC9921]  Pinkas, D., Jones, M., and K. Yasuda, "CBOR Object Signing
+              and Encryption (COSE) Header Parameter for Carrying and
+              Conveying a Timestamp Token", RFC 9921,
+              DOI 10.17487/RFC9921, February 2025,
+              <https://www.rfc-editor.org/info/rfc9921>.
+
+   [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/info/rfc9162>.
+
+   [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, March 2026,
+              <https://www.rfc-editor.org/info/rfc9943>.
+
+   [OTS]      Todd, P., "OpenTimestamps: Scalable, Trust-Minimized,
+              Distributed Timestamping with Bitcoin (Reference
+              Implementation, Release v0.4.3)", November 2022,
+              <https://github.com/opentimestamps/python-
+              opentimestamps/tree/python-opentimestamps-v0.4.3>.
+
+   [OTS-SITE] Todd, P., "OpenTimestamps (Project Site)", 2016,
+              <https://opentimestamps.org>.
+
+   [OTS-DESIGN]
+              Todd, P., "OpenTimestamps Announcement", September 2016,
+              <https://petertodd.org/2016/opentimestamps-announcement>.
+
+   [NAKAMOTO] Nakamoto, S., "Bitcoin: A Peer-to-Peer Electronic Cash
+              System", DOI 10.2139/ssrn.3440802, October 2008,
+              <https://doi.org/10.2139/ssrn.3440802>.
+
+
+
+
+
+
+
+
+Fassbender               Expires 29 October 2026               [Page 28]
+
+Internet-Draft         External Temporal Anchoring            April 2026
+
+
+   [BIP113]   Kerin, T. and M. Friedenbach, "Median time-past as
+              endpoint for lock-time calculations (BIP 113, Status:
+              Deployed)", August 2015, <https://github.com/bitcoin/bips/
+              blob/24e96e870fffaa257b465ce1f0370c14aac588e8/bip-
+              0113.mediawiki>.
+
+   [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/info/rfc6234>.
+
+   [RFC6962]  Laurie, B., Langley, A., and E. Kasper, "Certificate
+              Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
+              <https://www.rfc-editor.org/info/rfc6962>.
+
+   [BIP141]   Lombrozo, E., Lau, J., and P. Wuille, "Segregated Witness
+              (Consensus layer) (BIP 141, Status: Deployed)", December
+              2015, <https://github.com/bitcoin/bips/
+              blob/1f0b563738199ca60d32b4ba779797fc97d040fe/bip-
+              0141.mediawiki>.
+
+   [MERKLE]   Merkle, R., "A Digital Signature Based on a Conventional
+              Encryption Function", Advances in Cryptology - CRYPTO '87,
+              Lecture Notes in Computer Science, vol 293, Springer,
+              DOI 10.1007/3-540-48184-2_32, 1988,
+              <https://doi.org/10.1007/3-540-48184-2_32>.
+
+Appendix A.  Relationship to Four-Layer Evidence Stack
+
+   +---------------------------------------------+
+   |  L4  Evidence Format        (Partner/SCITT) |
+   |       Signed Statements, manifests, SBOMs   |
+   +---------------------------------------------+
+   |  L3  Signing & Identity     (Partner/TSA)   |
+   |       SCITT Receipts, X.509, passkeys       |
+   +---------------------------------------------+
+   |  L2  Anchor Primitive       (This Profile)  |
+   |       SHA-256 -> .ots -> Bitcoin              |
+   +---------------------------------------------+
+   |  L1  Consensus Layer        (Bitcoin)       |
+   |       Proof-of-work, append-only            |
+   +---------------------------------------------+
+
+   SCITT operates at L3-L4.  This profile defines the L2 integration.
+   L1 is the Bitcoin consensus layer.  The layers are independent: each
+   can be verified without the others.
+
+
+
+
+
+Fassbender               Expires 29 October 2026               [Page 29]
+
+Internet-Draft         External Temporal Anchoring            April 2026
+
+
+Appendix B.  Example: Anchored SCITT Flow
+
+   1. Producer creates artifact A
+   2. Producer signs Signed Statement S about A
+   3. Transparency Service receives S
+   4. Transparency Service appends S to log -> Receipt R
+   5. Transparency Service computes SHA-256(S) -> H
+   6. Transparency Service submits H to anchoring service
+   7. Anchoring service returns Anchor Proof P (.ots)
+   8. Transparency Service stores (R, P) together
+
+   Verification (by any auditor):
+     a. Verify R against Transparency Service log  -> SCITT valid
+     b. Verify P against Bitcoin                   -> Temporal valid
+     c. Compare: H in P == SHA-256(S)              -> Binding valid
+
+   Note: If the Transparency Service is no longer available, step (a)
+   cannot be performed -- steps (b) and (c) remain independently valid.
+   The temporal and binding proofs do not depend on the continued
+   operation of the log.
+
+Appendix C.  Implementation Status
+
+   As of March 2026, the following implementations exist:
+
+   *  *Umarise Core API*: Production anchoring service implementing the
+      Anchoring Specification, with Merkle-tree batching and
+      OpenTimestamps anchoring.  RFC 3161 TSA integration is planned.
+      253,000+ attestations anchored.
+
+   *  *verify-anchoring.org*: 100% client-side verification tool.  Zero
+      API contact, zero tracking.  Public domain.
+
+   *  *@umarise/cli*: Node.js CLI for automated anchoring.  Published on
+      npm.
+
+   *  *anchor-action*: GitHub Actions integration for CI/CD pipeline
+      anchoring.  Published on GitHub Marketplace.
+
+Appendix D.  Acknowledgements
+
+   The authors thank Eliot Lear (Independent Submissions Editor) for his
+   detailed review of the initial submission and his concrete guidance
+   on strengthening the formal security argument, algorithmic
+   specification, and Security Considerations structure.
+
+
+
+
+
+
+Fassbender               Expires 29 October 2026               [Page 30]
+
+Internet-Draft         External Temporal Anchoring            April 2026
+
+
+   The authors thank Nicole Bates (Microsoft, SCITT Working Group Chair)
+   for her review of the SCITT integration approach and her assessment
+   that the mechanism requires no changes to existing SCITT protocols.
+
+   The OpenTimestamps protocol was designed by Peter Todd, whose
+   reference implementation [OTS] underpins the anchoring mechanism
+   described in this document.
+
+   The Merkle tree construction in Appendix D.3 follows the conventions
+   established in RFC 6962 (Certificate Transparency).
+
+   _Author's Address:_
+
+   Jonna Fassbender
+   Umarise
+   The Netherlands
+
+   Email: j.fassbender@umarise.com
+   URI: https://umarise.com
+
+Appendix E.  OTS Anchoring Protocol -- Construction and Verification
+
+   Sections D.1 through D.3 are informative examples of a compliant
+   construction.  Sections D.4 and D.5 have been promoted to the
+   normative main body (Section 3) and are retained here as cross-
+   references only.  This appendix supports Assumption A4 (Section 5.2).
+   It defines the construction algorithms for OpenTimestamps-based
+   anchoring as used in this document.  The algorithms are presented in
+   pseudocode and are self-contained: they can be implemented
+   independently of any OpenTimestamps software library.  They
+   correspond to the reference implementation described in Appendix C,
+   but do not depend on it.
+
+   For background on the OpenTimestamps protocol design, see [OTS-SITE]
+   and [OTS-DESIGN].
+
+E.1.  D.1.  Construction Algorithm (Anchor)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fassbender               Expires 29 October 2026               [Page 31]
+
+Internet-Draft         External Temporal Anchoring            April 2026
+
+
+Algorithm: CONSTRUCT-ANCHOR(artifact_bytes)
+
+Input:
+  artifact_bytes    -- arbitrary byte sequence (the artifact)
+
+Output:
+  origin_record     -- {origin_id, hash, captured_at, proof_status}
+  pending_proof     -- serialised OTS pending proof (.ots file)
+
+Steps:
+
+1.  HASH COMPUTATION
+    hash_value  <- SHA-256(artifact_bytes)              // [FIPS180-4]
+    hash_string <- "sha256:" || HEX(hash_value)        // canonical form
+
+2.  TIMESTAMP CAPTURE
+    captured_at <- NOW()                                // UTC ISO 8601
+
+3.  ORIGIN REGISTRATION
+    origin_id   <- UUID-v4()                            // unique identifier
+    short_token <- RANDOM-ALPHANUMERIC(8)               // human-readable ref
+    INSERT origin_attestations {
+      origin_id, hash: hash_string, hash_algo: "sha256",
+      captured_at, short_token
+    }
+
+4.  OTS CALENDAR SUBMISSION
+    // Submit hash to >=1 OpenTimestamps Calendar Server(s) [OTS]
+    FOR EACH calendar IN configured_calendars:
+      pending_commitment <- HTTP-POST(calendar.url, hash_value)
+      STORE pending_commitment
+
+5.  PENDING PROOF ASSEMBLY
+    // The .ots file at this stage contains calendar commitment(s)
+    // but NOT a Bitcoin anchor. It is NOT independently verifiable.
+    pending_proof <- OTS-SERIALIZE(hash_value, pending_commitments)
+    INSERT core_ots_proofs {
+      origin_id, ots_proof: pending_proof, status: "pending"
+    }
+
+6.  RETURN {origin_id, hash_string, captured_at, proof_status: "pending"}
+
+E.2.  D.2.  Upgrade Algorithm (Bitcoin Confirmation)
+
+
+
+
+
+
+
+
+Fassbender               Expires 29 October 2026               [Page 32]
+
+Internet-Draft         External Temporal Anchoring            April 2026
+
+
+   Algorithm: UPGRADE-PENDING-PROOFS()
+
+   // Runs periodically (e.g. every 15 minutes) as a background worker.
+   // Converts calendar-level commitments to Bitcoin-level proofs.
+
+   Input:
+     none (reads from core_ots_proofs WHERE status = "pending")
+
+   Steps:
+
+   1.  pending_proofs <- SELECT * FROM core_ots_proofs
+                         WHERE status = "pending"
+                         AND created_at < NOW() - INTERVAL '2 hours'
+
+   2.  FOR EACH proof IN pending_proofs:
+
+       2a. CONTACT CALENDAR
+           upgraded_proof <- OTS-UPGRADE(proof.ots_proof)
+           // OTS-UPGRADE contacts the Calendar Server that issued
+           // the pending commitment and requests the Bitcoin
+           // Merkle path if available.
+
+       2b. IF upgraded_proof IS NULL:
+           // Bitcoin transaction not yet confirmed, or calendar
+           // not yet merged into a block. Retry next cycle.
+           CONTINUE
+
+       2c. EXTRACT BITCOIN BINDING
+           block_height <- OTS-EXTRACT-BLOCK-HEIGHT(upgraded_proof)
+           block_time   <- OTS-EXTRACT-BLOCK-TIME(upgraded_proof)
+
+       2d. VERIFY LOCALLY
+           // Verify the Merkle path from hash -> Bitcoin OP_RETURN
+           valid <- OTS-VERIFY(upgraded_proof, proof.origin_hash)
+           IF NOT valid:
+             LOG-ERROR("Upgrade verification failed", proof.origin_id)
+             CONTINUE
+
+       2e. PERSIST UPGRADED PROOF
+           UPDATE core_ots_proofs SET
+             ots_proof           = upgraded_proof,
+             status              = "anchored",
+             bitcoin_block_height = block_height,
+             anchored_at          = block_time,
+             upgraded_at          = NOW()
+           WHERE origin_id = proof.origin_id
+
+
+
+
+
+Fassbender               Expires 29 October 2026               [Page 33]
+
+Internet-Draft         External Temporal Anchoring            April 2026
+
+
+E.3.  D.3.  Batch Anchoring with Merkle Trees
+
+Algorithm: BATCH-ANCHOR(hash_list)
+
+// For high-volume partners (>1,000 hashes per request).
+// Anchors a single Merkle root instead of N individual hashes.
+
+Input:
+  hash_list       -- ordered list of SHA-256 hashes [h_0 ... h_{n-1}]
+
+Output:
+  batch_record    -- {batch_id, merkle_root, merkle_origin_id, origins[]}
+
+Steps:
+
+1.  VALIDATE
+    ASSERT 1 <= |hash_list| <= 1000
+    FOR EACH h IN hash_list:
+      ASSERT h matches /^(sha256:)?[0-9a-f]{64}$/
+
+2.  COMPUTE MERKLE ROOT                               // [RFC9162] Section 2.1
+    // Canonical leaf ordering: strip "sha256:" prefix, sort pairs
+    // lexicographically before concatenation.
+    level <- [STRIP-PREFIX(h) FOR h IN hash_list]
+    WHILE |level| > 1:
+      next_level <- []
+      FOR i <- 0 TO |level|-1 STEP 2:
+        IF i+1 < |level|:
+          pair <- SORT([level[i], level[i+1]])
+          next_level.APPEND(SHA-256(pair[0] || pair[1]))
+        ELSE:
+          next_level.APPEND(level[i])           // odd element: promote
+      level <- next_level
+    merkle_root <- "sha256:" || level[0]
+
+3.  CREATE INDIVIDUAL ORIGINS
+    FOR EACH h IN hash_list:
+      CALL CONSTRUCT-ANCHOR-RECORD(h)           // DB insert only, no OTS
+
+4.  ANCHOR MERKLE ROOT
+    // Only the root is submitted to OTS calendar(s).
+    // This reduces N OTS operations to 1.
+    CALL CONSTRUCT-ANCHOR(merkle_root)
+
+5.  LINK BATCH
+    INSERT batch_submissions {
+      batch_id, merkle_root, merkle_origin_id,
+      hashes: hash_list, origin_ids: [per-hash origin_ids]
+
+
+
+Fassbender               Expires 29 October 2026               [Page 34]
+
+Internet-Draft         External Temporal Anchoring            April 2026
+
+
+    }
+
+6.  RETURN batch_record
+
+E.4.  D.4.  Verification Algorithm
+
+   The normative verification algorithm has been promoted to Section 3.1
+   of this document.  This appendix section is retained as a cross-
+   reference for continuity.
+
+   See Section 3.1 (VERIFY-ANCHOR) for the full eight-step verification
+   procedure with MUST/SHOULD requirements.
+
+E.5.  D.5.  Verification Independence
+
+   The normative verification independence requirements have been
+   promoted to Section 3.2 of this document.
+
+   See Section 3.2 for the definitive statement of what a conformant
+   verifier requires and what it MUST NOT depend on.
+
+Author's Address
+
+   Jonna Fassbender
+   Umarise
+   Email: j.fassbender@umarise.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fassbender               Expires 29 October 2026               [Page 35]

model.txt

@@ -0,0 +1,15 @@
+Umarise Smoke Test Model
+========================
+
+This is a placeholder artefact used to demonstrate verifiable provenance
+for ML model files via cryptographic anchoring.
+
+The file you are reading now will be hashed (SHA-256) and that hash
+will be anchored into the Bitcoin blockchain via OpenTimestamps.
+
+After anchoring, anyone can independently prove that this exact byte
+sequence existed at or before the timestamp recorded in the .ots proof,
+without needing to trust Umarise or Hugging Face.
+
+Replace this file with your actual model artefact (weights, config,
+tokenizer) when running the POC against a real model.