INTERNET-DRAFT                                             J. Fassbender
Intended Status: Informational                              Umarise
Expires: October 5, 2026                                   April 5, 2026


        External Time Anchor Profile for SCITT Transparency Services

              draft-fassbender-scitt-time-anchor-00


Abstract

   SCITT Transparency Services record signed statements in append-only
   logs and issue receipts that include an internal timestamp derived
   from log inclusion.  This timestamp depends on the service operator's
   own clock and log infrastructure.  It cannot be independently
   verified by a party that does not trust the operator.

   This document defines an optional, additive profile that attaches an
   externally verifiable time anchor to an existing Origin Record.  The
   anchor is a standard OpenTimestamps (.ots) proof ultimately committed
   to the Bitcoin blockchain.  The resulting proof is self-contained and
   portable: it can be verified by any party holding the original file
   and the .ots proof, without contacting the Transparency Service, the
   anchoring service, or any trusted authority.

   No changes to SCITT protocols, signed statement formats, or receipt
   structures 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 October 5, 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.


1.  Introduction

   The IETF SCITT Working Group has defined architecture and building
   blocks for signed statements, receipts, and transparency services
   [SCITT-ARCH].  The working group deliberately left the underlying
   time source for Transparency Services open, relying primarily on the
   service operator's log for ordering and freshness.

   This design is appropriate for the primary SCITT use cases.  However,
   a gap exists: SCITT receipts include a timestamp that is internal to
   the Transparency Service and is not derived from an independent
   external authority.  Parties that do not trust the operator cannot
   independently verify when a statement was made.

   This document does not attempt to standardize external time sources,
   but to describe one concrete profile that can be used alongside
   existing SCITT deployments.

   This document addresses that gap by defining an External Time Anchor
   Profile.  The profile is:

   Optional.     No existing SCITT deployment is affected.

   Additive.     It supplements existing receipt structures without
                 modifying them.

   Independent.  Verification is independent of any single operator or
                 authority, based on Bitcoin consensus.

   Portable.     The proof survives discontinuation of any service,
                 including the anchoring service.

1.1.  Relationship to RFC 3161

   RFC 3161 [RFC3161] defines how a trusted Time-Stamping Authority
   (TSA) issues Time-Stamp Tokens to provide proof of existence at a
   specific time.  RFC 9921 [RFC9921] defines how such tokens can be
   embedded in COSE structures aligned with SCITT.  These are
   referenced here as prior art and for architectural context only.

   The two approaches differ in trust model.  The TSA model requires
   trusting a designated authority and depends on that authority's
   continued operation.  The profile defined here uses Bitcoin's
   proof-of-work consensus as the time bound: no authority is required
   to verify the proof, and the proof remains valid regardless of
   whether any service continues to operate.  The approaches are
   architecturally complementary.  Interoperability between this
   profile and RFC 3161 / RFC 9921 is not defined in this document.

   The semantic claim is identical in scope: the exact byte sequence
   existed no later than the moment of ledger inclusion.  The
   difference is not what is claimed, but who must be trusted to
   verify it.

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

   Origin Record:        A record in a Transparency Service attesting
                         that a specific hash was registered at a
                         specific time.

   Time Anchor:          A cryptographic proof binding a hash to a
                         Bitcoin block, providing an upper bound on the
                         time at which the hash existed.

   OTS proof:            A standard OpenTimestamps proof file (.ots) as
                         defined by the OpenTimestamps project.

   Bitcoin block         The timestamp field of a Bitcoin block header,
   timestamp:            accurate to within approximately two hours per
                         consensus rules.

   Self-contained proof: A proof verifiable without contacting any
                         online service.


------------------------------------------------------------------------


2.  The Gap

   SCITT receipts convey a time of log inclusion via a COSE
   countersignature.  This time is:

   1.  Set by the Transparency Service operator.

   2.  Not derived from an independent external authority.

   3.  Not verifiable by a party that does not trust the operator.

   As confirmed by the SCITT Working Group, this is a known property of
   the current architecture, and operator-independent timestamping is
   outside the current working group charter.

   The gap matters in adversarial settings -- disputes, litigation,
   audit, regulatory examination -- where the party presenting evidence
   and the party operating the Transparency Service may be the same, or
   may be in conflict.  In these settings, a receipt whose timestamp
   originates from the operator's own infrastructure is circular
   evidence.


------------------------------------------------------------------------


3.  External Time Anchor Profile

3.1.  Overview

   The External Time Anchor Profile defines how to attach an OTS proof
   to an Origin Record, as specified in [IEC].  The OTS proof commits
   the SHA-256 hash of the original artifact to a Bitcoin block via a
   Merkle tree.  Once the
   relevant Bitcoin block has sufficient confirmation depth, the proof
   can be independently verified.

   The profile does not modify any existing SCITT data structure.  It
   defines an optional proof artifact that may accompany an Origin
   Record.

3.2.  Proof Construction

   1.  Compute SHA-256(artifact) [FIPS180-4] on the client.  The
       artifact bytes do not leave the originating device.

   2.  Submit the hash to an OTS calendar server.  The calendar
       aggregates multiple hashes into a Merkle tree and commits the
       root to Bitcoin.

   3.  After Bitcoin confirmation (typically 10-20 minutes, 1-2
       blocks), retrieve the completed .ots proof file.

   4.  The .ots proof file [OTS], together with the original artifact,
       constitutes a self-contained time anchor.

3.3.  Proof Properties

   The completed proof establishes the following:

   o  The SHA-256 hash of the artifact was committed to a Merkle tree
      no later than the timestamp of the Bitcoin block in which the
      root was included.

   o  Bitcoin block timestamps are set by miners and can deviate from
      wall clock time by up to approximately two hours per Bitcoin
      consensus rules.  The proof therefore provides an upper bound,
      not a precise timestamp.

   o  The proof is verifiable by anyone holding the original artifact
      and the .ots file, using the OpenTimestamps CLI or any compliant
      verifier, without contacting the anchoring service.

   What this proof does not establish:

   Authorship.       The proof establishes that a specific hash
                     existed, not who created the artifact.

   Uniqueness.       Earlier attestations of the same hash may exist.

   Semantic meaning. The proof is context-blind.  What the hash
                     represents is defined by whoever created it.

3.4.  Verification

   Verification requires three inputs and no online dependencies:

      V(artifact, proof.ots, bitcoin_chain) -> valid | invalid

   Command-line verification:

      ots verify proof.ots -f artifact

   Or using a client-side verifier (zero network dependency on the
   anchoring service, queries Bitcoin directly via block explorers).

3.5.  Self-Contained Distribution

   The proof artifact SHOULD be distributed as a ZIP archive
   containing:

   o  certificate.json  -- origin record metadata (hash, captured_at,
                           bitcoin_block_height, origin_id)

   o  proof.ots         -- the OTS proof file

   o  VERIFY.txt        -- plain-text verification instructions

   This archive is the complete, self-contained proof.  It verifies
   without any service, account, or login.


------------------------------------------------------------------------


4.  Relationship to SCITT Architecture

   This profile operates at a layer below SCITT's transparency log.
   It can be used independently of SCITT, or in combination with it.

   When used in combination:

   o  The SCITT receipt provides the operator's log inclusion proof
      and internal timestamp.

   o  The External Time Anchor provides the operator-independent time
      bound.

   o  The two are complementary.  Neither invalidates the other.

   No changes to SCITT protocols are required.  A SCITT Transparency
   Service may optionally reference an External Time Anchor in
   statement metadata, but this is not normative.


------------------------------------------------------------------------


5.  Security Considerations

5.1.  Bitcoin Block Timestamp Accuracy

   Bitcoin block timestamps are set by miners and must satisfy the
   median time past rule.  They can deviate from UTC by up to
   approximately two hours within consensus.  The time bound
   established by this profile is therefore accurate to approximately
   two hours, not to the second.  Applications requiring higher
   temporal precision should use additional mechanisms.

5.2.  Merkle Aggregation and Batching

   OTS calendars batch multiple hashes into a single Merkle tree
   before committing to Bitcoin.  The aggregation window is typically
   seconds to minutes.  The resulting proof covers all hashes in the
   batch.  This does not affect the validity of any individual proof.

5.3.  Confirmation Depth

   A proof anchored to a Bitcoin block with low confirmation depth is
   subject to chain reorganization.  For most use cases, 1-2
   confirmations (10-20 minutes) is sufficient.  Applications
   requiring high assurance SHOULD wait for 6 or more confirmations.

5.4.  OTS Calendar Availability

   The OTS calendar is required only during proof construction, not
   during verification.  If the calendar is unavailable, proof
   construction must wait.  Verification of completed proofs is
   unaffected.

5.5.  Hash Function

   This profile specifies SHA-256.  Artifact hashing is performed
   client-side.  No artifact bytes are transmitted to any service.


------------------------------------------------------------------------


6.  IANA Considerations

   This document has no IANA actions.


------------------------------------------------------------------------


7.  References

7.1.  Normative References

   [FIPS180-4]  National Institute of Standards and Technology,
                "Secure Hash Standard", FIPS PUB 180-4, August 2015.

   [IEC]        Fassbender, J., "Anchoring Specification v1.0",
                anchoring-spec.org, 2026.

   [OTS]        Todd, P., "OpenTimestamps: Scalable, Trust-Minimized,
                Distributed Timestamping with Bitcoin",
                opentimestamps.org, 2016.

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

7.2.  Informative References

   [RFC3161]    Adams, C., Cain, P., Pinkas, D., and R. Zuccherato,
                "Internet X.509 Public Key Infrastructure Time-Stamp
                Protocol (TSP)", RFC 3161, August 2001.
                Referenced for architectural context as prior art in
                operator-independent timestamping.

   [RFC9921]    Tschofenig, H., "COSE Header Parameter for Timestamp
                Tokens as Defined in RFC 3161", RFC 9921, 2024.
                Referenced for context on COSE-based timestamp
                embedding.

   [SCITT-ARCH] IETF SCITT Working Group, "An Architecture for
                Trustworthy and Transparent Digital Supply Chains",
                draft-ietf-scitt-architecture (work in progress).

   [verify-anchoring]
                Reference verifier, verify-anchoring.org, 2026.


------------------------------------------------------------------------


Appendix A.  Example Verification Output

      $ ots verify proof.ots -f artifact.jpg

      Assuming target timestamp of 1707394920
      Got 1 attestation(s) from cache
      Success! Bitcoin block 881234 attests existence as of
      2026-02-08 14:22:00 UTC


------------------------------------------------------------------------


Appendix B.  Mapping to SCITT Terminology

   +----------------------+------------------------------------------+
   | SCITT concept        | This profile                             |
   +----------------------+------------------------------------------+
   | Statement            | SHA-256 hash of artifact                 |
   | Receipt timestamp    | Internal, operator-controlled            |
   | Time anchor          | OTS proof committed to Bitcoin           |
   | Verification trust   | Bitcoin consensus (no authority needed)  |
   | Portability          | Self-contained ZIP, survives any service |
   +----------------------+------------------------------------------+


------------------------------------------------------------------------


Author's Address

   Jonna Fassbender
   Umarise
   Email: j.fassbender@umarise.com
   URI:   https://umarise.com


------------------------------------------------------------------------

   This Internet-Draft will expire on October 5, 2026.

   This document is an individual submission to the RFC Series via the
   Independent Submissions Editor (ISE) stream.  It does not represent
   IETF consensus or SCITT Working Group endorsement.  Comments welcome
   via the SCITT WG mailing list or GitHub
   (ietf-wg-scitt/draft-ietf-scitt-architecture).
