OpenAIIS -- A Decentralized Trust, Governance and Safety Protocol for the Digital World
draft-sethi-openaiis-protocol-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Tarun Sethi | ||
| Last updated | 2026-10-30 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-sethi-openaiis-protocol-00
Network Working Group Sethi
Internet-Draft OpenAIIS
Intended status: Standards Track 30 October 2026
Expires: 3 May 2027
OpenAIIS — A Decentralized Trust, Governance and Safety Protocol for the
Digital World
draft-sethi-openaiis-protocol-00
Abstract
Open Artificial Intelligence Integrity Sentinel (OpenAIIS) specifies
a decentralized trust, governance, and safety protocol for digital
activity performed by people, organizations, and autonomous AI
agents. It binds digital assertions and consequential actions to
authenticated issuers, scoped authority, accepted responsibility,
supporting evidence, and a verifiable history. A canonical, domain-
separated signature authenticates each typed claim; ordered Merkle
records and signed checkpoints establish its historical registry
context.
Every accepted registry record enters an automatic, durable process
that commits covering checkpoints to Bitcoin mainnet. The resulting
portable proof binds the exact signed claim and its authenticated
history to Bitcoin's proof-of-work chain, protecting historical
evidence against retroactive substitution or rewriting without the
work required to establish an accepted competing Bitcoin history.
Governance and safety records express consent, delegation,
authorization, revocation, withdrawal, disputes, and security
incidents. Independent implementations can verify both historical
commitments and the evidence governing present action without relying
exclusively on the system that issued or executed a claim. OpenAIIS
supports versioned decentralized consensus profiles without a
protocol-native currency.
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/.
Sethi Expires 3 May 2027 [Page 1]
Internet-Draft OpenAIIS Protocol October 2026
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 3 May 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
3. Core Protocol Model . . . . . . . . . . . . . . . . . . . . . 6
4. Autonomous Agents and Accountable Actions . . . . . . . . . . 7
5. Universal Signed Claim . . . . . . . . . . . . . . . . . . . 7
5.1. Record Envelope . . . . . . . . . . . . . . . . . . . . . 7
5.2. Canonical Encoding . . . . . . . . . . . . . . . . . . . 9
5.3. Cryptographic Signature . . . . . . . . . . . . . . . . . 9
5.4. Content Commitments . . . . . . . . . . . . . . . . . . . 10
5.5. Historical Signature Profiles . . . . . . . . . . . . . . 11
6. Typed Claim Semantics . . . . . . . . . . . . . . . . . . . . 11
7. Registry Admission and Authenticated History . . . . . . . . 13
7.1. Admission . . . . . . . . . . . . . . . . . . . . . . . . 13
7.2. Domain-Separated Merkle Leaves . . . . . . . . . . . . . 14
7.3. Inclusion Receipt . . . . . . . . . . . . . . . . . . . . 14
7.4. Signed Checkpoints . . . . . . . . . . . . . . . . . . . 15
7.5. Authenticated Lifecycle Index . . . . . . . . . . . . . . 16
8. Bitcoin Anchoring and Confirmation . . . . . . . . . . . . . 17
8.1. Exact Checkpoint Commitment . . . . . . . . . . . . . . . 17
8.2. Automatic and Durable Processing . . . . . . . . . . . . 17
8.3. State Separation . . . . . . . . . . . . . . . . . . . . 18
8.4. Mainnet Confirmation and Assurance . . . . . . . . . . . 19
9. Portable Proof and Independent Verification . . . . . . . . . 20
9.1. Universal Proof Bundle . . . . . . . . . . . . . . . . . 20
9.2. Verification Algorithm . . . . . . . . . . . . . . . . . 21
Sethi Expires 3 May 2027 [Page 2]
Internet-Draft OpenAIIS Protocol October 2026
10. Governed Authority, Consent, and Responsibility . . . . . . . 22
10.1. Scoped Delegation and Accountable Operations . . . . . . 22
10.2. Consent-Governed Identity Attestations . . . . . . . . . 23
10.3. Artifact Holders and Transfers . . . . . . . . . . . . . 23
10.4. Disputes, Withdrawal, and Lifecycle Resolution . . . . . 24
11. Verifiable Safety Evidence . . . . . . . . . . . . . . . . . 24
12. Decentralized Network Profiles . . . . . . . . . . . . . . . 24
13. HTTP Interoperability Profile . . . . . . . . . . . . . . . . 25
14. Privacy and Interoperability . . . . . . . . . . . . . . . . 27
15. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 27
16. Security Considerations . . . . . . . . . . . . . . . . . . . 29
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
18.1. Normative References . . . . . . . . . . . . . . . . . . 30
18.2. Informative References . . . . . . . . . . . . . . . . . 30
Appendix A. Reproducible Merkle-Leaf Test Vector . . . . . . . . 31
Appendix B. Protocol Identifiers . . . . . . . . . . . . . . . . 32
Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 33
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction
Autonomous software can now create artifacts, publish code, invoke
services, and initiate actions across organizational boundaries.
After an action, a signature may identify the software key that
produced it without identifying the organization that authorized it,
the human or institution that accepted responsibility, the evidence
supporting its execution, or the conditions under which its authority
was withdrawn. Each organization can maintain internal logs, but
those logs may be unavailable, rewritten, or impossible for another
organization to verify independently.
OpenAIIS addresses the linked problems of provenance, authority,
responsibility, historical integrity, and safety through a shared
protocol. Actors issue typed signed claims about exact subjects,
content commitments, delegations, consent, evidence, and lifecycle
events. The records enter an authenticated ordered history. The
registry checkpoints of that history are committed to Bitcoin's
proof-of-work blockchain, making its previously recorded state
independently testable even if the originating organization, registry
service, or autonomous agent later becomes unavailable or is
compromised.
The protocol applies equally to human and institutional activity:
research, inventions, media, identity, software, and supporting
evidence use the same historical foundation, with type-specific
governance rules. New authenticated events update current trust
state without erasing the earlier evidence.
Sethi Expires 3 May 2027 [Page 3]
Internet-Draft OpenAIIS Protocol October 2026
OpenAIIS combines five protocol properties:
* *Provenance:* an issuer signs a canonical statement about an exact
subject and cryptographic content commitment.
* *Authenticated history:* an ordered Merkle log binds admitted
records to signed checkpoints whose bytes are committed to Bitcoin
mainnet.
* *Governance:* explicit signed relationships establish consent,
scoped delegation, responsibility, and controlled lifecycle
changes.
* *Safety:* authenticated compromise, revocation, dispute, and
related evidence can affect subsequent trust decisions.
* *Independent verification:* portable cryptographic proofs and
declared trust inputs permit distinct implementations to reproduce
supported evidence and policy outcomes.
This document defines the core signed-record and historical-
verification format, its Bitcoin commitment requirements, the
associated trust-state operations, and an HTTP interoperability
interface. OpenAIIS is not limited to AI-generated artifacts: its
claim model also covers human and institutional works, research,
inventions, media, software, evidence, and digital identity.
The architecture admits independent OpenAIIS consensus profiles for
replicated and proof-of-work-ordered network history. Bitcoin
anchoring and OpenAIIS network consensus serve different purposes:
Bitcoin supplies an external, widely verifiable proof-of-work
historical commitment; OpenAIIS orders and evaluates its own signed
claims and governance records. Neither layer by itself determines
the truth of a claim or the authority of its signer.
2. Conventions and Terminology
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.
Throughout this document, || denotes byte concatenation; SHA256(B)
denotes the 32-byte SHA-256 digest of byte string B; HEX(B) denotes
lowercase hexadecimal encoding of B; and CanonicalJSON denotes the
canonical ASCII JSON encoding specified in Section 5.2.
Sethi Expires 3 May 2027 [Page 4]
Internet-Draft OpenAIIS Protocol October 2026
*Issuer:* The party whose signing key authenticates an assertion.
*Subject:* The person, artifact, system, agent, or other entity about
which an assertion is made.
*Principal:* An actor that accepts responsibility or delegates scoped
authority.
*Operator:* An actor controlling a system, agent, or delegated
operation.
*Agent:* Software or another autonomous actor that operates under an
authenticated delegation.
*Registry operator:* An operator that validates and appends claims
and signs registry checkpoints.
*Node:* An independently operated validator of replicated registry
history under a declared consensus profile.
*Verifier:* Software or an actor that independently evaluates claim
signatures, registry inclusion, signed checkpoints, Bitcoin
commitments, and, when applicable, governance evidence.
*Optional checkpoint monitor (witness):* An independent participant
that retains and compares authenticated registry checkpoints and
consistency proofs. Such monitoring may expose inconsistent
histories; it is not a prerequisite for registration, Bitcoin
anchoring, or Bitcoin confirmation.
*Relying party:* An actor or system that selects its trust roots,
evidence requirements, and decision policy, possibly using a
verifier.
*Registration:* Durable admission of an authenticated claim to a
registry history, with a durable obligation for Bitcoin anchoring.
Registration success is not a Bitcoin-confirmation verdict.
*Confirmed historical evidence:* A signed checkpoint and
corresponding Bitcoin proof that satisfy the selected mainnet
assurance policy.
A single entity may occupy multiple roles, but a signature or valid
proof in one role MUST NOT grant another role's authority by
implication.
Sethi Expires 3 May 2027 [Page 5]
Internet-Draft OpenAIIS Protocol October 2026
3. Core Protocol Model
OpenAIIS has one authenticated record history with two complementary
verification responsibilities. Historical verification establishes
the unaltered registry evidence committed beneath a Bitcoin
checkpoint; governance verification evaluates authorization, consent,
responsibility, and subsequent safety-related changes from the
applicable authenticated records. One result does not substitute for
the other.
Human / organization / AI agent
|
+-- signed identity, delegation, consent
+-- responsibility, evidence
|
+-- signed artifact, release, action, or lifecycle claim
|
Registry admission
|
Ordered, authenticated Merkle history
|
Operator-signed checkpoint
|
OpenTimestamps commitment
|
Bitcoin mainnet
|
Confirmed historical checkpoint proof
|
Independent proof verification
|
Authenticated authority + current lifecycle
|
Policy-specific trust decision
Figure 1: OpenAIIS signed-claim and Bitcoin-backed verification path
The path is automatic from successful registry admission through the
Bitcoin-anchoring obligation. A confirmed Bitcoin checkpoint
protects the historical commitment to the claim and related
governance records. A later revocation, security incident, or
dispute adds new evidence and can change current authorization
without modifying that Bitcoin-anchored past.
Sethi Expires 3 May 2027 [Page 6]
Internet-Draft OpenAIIS Protocol October 2026
4. Autonomous Agents and Accountable Actions
An autonomous agent's valid signature authenticates the agent's
statement, not the authority under which the agent acted. OpenAIIS
establishes the relation between that statement and independently
verifiable records of organizational control, accepted
responsibility, delegated scope, and supporting evidence.
Consider an organization authorizing an AI agent to publish a
software release. Its operator and responsible principal are bound
through signed governance records; the principal grants a delegation
for a specified release action, resource, and environment. The agent
signs a claim committing to the exact release bytes, while a
recognized evidence issuer signs any required testing or security
evidence. The release claim references the applicable authority and
evidence records. These claims are admitted to authenticated
registry history and covered by a Bitcoin-anchored checkpoint.
Another organization can later verify the agent's signing key, the
signed release and code digest, the authorized principal and
delegation, the supporting evidence, the claim's registry inclusion,
and the Bitcoin commitment to that historical state. It can
additionally inspect current revocation or security evidence before
permitting a new action. Neither the agent nor its original operator
can retrospectively replace that Bitcoin-anchored evidence merely by
rewriting a local database.
This procedure extends to automated infrastructure, AI-generated
research, media, software supply chains, and other consequential
digital acts. The following sections specify the common record and
proof structures, then the governance rules by which such actions are
evaluated.
5. Universal Signed Claim
5.1. Record Envelope
The core profile identifier is openaiis-universal-registry-v1. A
signed record is a canonical JSON object containing exactly the
following fields:
Sethi Expires 3 May 2027 [Page 7]
Internet-Draft OpenAIIS Protocol October 2026
+=====================+=========+=========================+
| Field | Type | Description |
+=====================+=========+=========================+
| profile | string | Exact signed-record |
| | | profile identifier |
+---------------------+---------+-------------------------+
| record_type | string | Versioned typed |
| | | assertion category |
+---------------------+---------+-------------------------+
| subject_id | string | Declared subject |
| | | identifier |
+---------------------+---------+-------------------------+
| issuer_id | string | Declared issuer |
| | | identifier |
+---------------------+---------+-------------------------+
| issuer_key_id | string | SHA-256 identifier of |
| | | raw issuer public key |
+---------------------+---------+-------------------------+
| content_sha256 | string | Content commitment |
+---------------------+---------+-------------------------+
| payload_schema | string | Exact typed payload |
| | | schema |
+---------------------+---------+-------------------------+
| payload_sha256 | string | Commitment to canonical |
| | | typed payload |
+---------------------+---------+-------------------------+
| authority_refs | array | Referenced authority |
| | | claims |
+---------------------+---------+-------------------------+
| evidence_refs | array | Referenced evidence |
| | | claims |
+---------------------+---------+-------------------------+
| consent_refs | array | Referenced consent |
| | | claims |
+---------------------+---------+-------------------------+
| related_record_refs | array | Referenced lifecycle |
| | | and other claims |
+---------------------+---------+-------------------------+
| claimed_at | integer | Issuer-declared time |
+---------------------+---------+-------------------------+
| signature | string | Canonical Base64 |
| | | Ed25519 signature |
+---------------------+---------+-------------------------+
Table 1
Sethi Expires 3 May 2027 [Page 8]
Internet-Draft OpenAIIS Protocol October 2026
The record body is the same object without signature. Its field
names MUST NOT be extended or omitted under this profile. The four
reference arrays each contain zero to 64 sorted, unique values of the
form sha256: followed by exactly 64 lowercase hexadecimal digits.
The same digest syntax applies to issuer_key_id, content_sha256, and
payload_sha256.
record_type matches [a-z][a-z0-9_]{2,63}. issuer_id, subject_id, and
payload_schema match [a-z][a-z0-9_-]{1,31}:[a-zA-Z0-9._:/-]{1,160}.
claimed_at is an integer from zero inclusive to 2^63 exclusive; JSON
booleans are not integers for this purpose. Complete signed-record
length MUST be between 1 and 65,536 bytes inclusive.
A record's asserted issuer name is not itself proof of a legal or
institutional identity. Relying parties MUST independently select
the expected issuer-key binding before accepting issuer authority.
5.2. Canonical Encoding
A canonical record is serialized as JSON [RFC8259] with:
* object keys sorted lexicographically;
* no nonessential whitespace;
* comma and colon as separators;
* ASCII escaping of non-ASCII characters;
* no NaN, infinity, or non-JSON numeric values;
* exact key sets and field types for the selected schema; and
* no duplicate object member names.
The signed bytes MUST equal the byte-for-byte canonical re-
serialization of the parsed object. Implementations MUST reject
malformed encodings, duplicate keys, unknown fields, unsupported
profile values, incorrect array ordering, and alternate noncanonical
representations. The complete canonical serialization is encoded as
ASCII bytes.
5.3. Cryptographic Signature
The universal signed-record profile uses Ed25519 [RFC8032], with the
following exact signing domain:
OPENAIIS/UNIVERSAL-REGISTRATION/v1\0
Sethi Expires 3 May 2027 [Page 9]
Internet-Draft OpenAIIS Protocol October 2026
The displayed \0 denotes a single NUL byte (0x00), not two printable
characters. Let C be the canonical body without signature, and let D
be the ASCII bytes of the signing domain including the NUL byte. The
signing message and signature are:
m = D || CanonicalJSON(C)
sigma = Ed25519.Sign(issuer_private_key, m)
key_id = "sha256:" || HEX(SHA256(raw_32_byte_public_key))
signature MUST be the padded, canonical Base64 encoding [RFC4648] of
the 64-byte Ed25519 signature. The signer serializes the completed
object using the same canonical JSON rules.
A verifier MUST reconstruct m from the exact version-specific body,
verify sigma with the independently established issuer public key,
and compare issuer_key_id with key_id. Where issuer identity is a
trust condition, the verifier MUST compare issuer_id to an
independently established expected identifier. Signature validity
alone does not imply permission to issue the signed type of claim.
5.4. Content Commitments
For original content bytes B, the ordinary profile uses:
content_sha256 = "sha256:" || HEX(SHA256(B))
For canonical typed-payload bytes P:
payload_sha256 = "sha256:" || HEX(SHA256(P))
The validator MUST bind record_type, payload_schema, the embedded
payload profile, and the actual canonical payload bytes. It MUST
check all required and forbidden references and typed validation
constraints. When the original content is unavailable, content-byte
verification is unevaluated, not successful by assertion.
The private artifact profile openaiis-artifact_registration-
private-v1 uses a separately generated 32-byte salt and the domain:
OPENAIIS/PRIVATE-ARTIFACT-COMMITMENT/v1\0
Its content commitment is:
"sha256:" || HEX(SHA256(domain || salt || B))
Sethi Expires 3 May 2027 [Page 10]
Internet-Draft OpenAIIS Protocol October 2026
The typed payload identifies visibility as blinded_digest. A
verifier claiming private-content integrity MUST obtain both salt and
B and recompute this exact commitment. Neither B nor salt is
required in registry history or a Bitcoin transaction.
5.5. Historical Signature Profiles
A signed record retains the signature domain and payload-schema rules
selected by its authenticated profile identifier. Historic
candidate-v1 encodings cannot be renamed or silently reinterpreted as
a new profile. An existing Bitcoin proof MUST NOT be attached to re-
signed or re-serialized bytes with a different identity.
6. Typed Claim Semantics
The core type catalogue identifier is openaiis-universal-type-lock-
v1. The catalogue contains exactly 17 record types sharing the
universal signed envelope and historical verification chain.
+==========================+=====================+================+
| Record type | Typed payload |Declared payload|
| | schema |fields or format|
+==========================+=====================+================+
| artifact_registration | schema:artifact- |profile, |
| | registration-v1 |media_type, |
| | |visibility |
+--------------------------+---------------------+----------------+
| invention_claim | schema:invention- |profile, |
| | claim-v1 |invention_kind, |
| | |disclosure |
+--------------------------+---------------------+----------------+
| research_work | schema:research- |profile, |
| | work-v1 |research_kind, |
| | |visibility |
+--------------------------+---------------------+----------------+
| software_release | schema:company- |Release |
| | release-v1 |authorization |
| | |and evidence |
| | |fields |
+--------------------------+---------------------+----------------+
| ai_generated_code | schema:ai- |profile, |
| | generated-code-v1 |tool_id, |
| | |model_claim, |
| | |review_status |
+--------------------------+---------------------+----------------+
| media_work | schema:media- |profile, |
| | work-v1 |media_type, |
| | |rights_claim |
Sethi Expires 3 May 2027 [Page 11]
Internet-Draft OpenAIIS Protocol October 2026
+--------------------------+---------------------+----------------+
| identity_attestation | schema:identity- |profile, |
| | attestation-v1 |holder_id, |
| | |evidence_sha256 |
+--------------------------+---------------------+----------------+
| artifact_attestation | schema:artifact- |profile, |
| | attestation-v1 |holder_id, |
| | |evidence_sha256 |
+--------------------------+---------------------+----------------+
| identity_consent | schema:identity- |profile, |
| | consent-v1 |intent_sha256 |
+--------------------------+---------------------+----------------+
| authority_statement | schema:authority- |Embedded |
| | statement-v1 |independently |
| | |signed authority|
| | |statement |
+--------------------------+---------------------+----------------+
| evidence_attestation | schema:company- |profile, |
| | evidence-v1 |release_id, |
| | |code_sha256, |
| | |evidence_sha256,|
| | |not_before, |
| | |not_after |
+--------------------------+---------------------+----------------+
| issuer_revocation | schema:attestation- |target_ref, |
| | lifecycle-v1 |reason |
+--------------------------+---------------------+----------------+
| subject_withdrawal | schema:attestation- |target_ref |
| | lifecycle-v1 | |
+--------------------------+---------------------+----------------+
| dispute_raised | schema:attestation- |target_ref, |
| | lifecycle-v1 |dispute_id, |
| | |reason |
+--------------------------+---------------------+----------------+
| dispute_settled | schema:attestation- |target_ref, |
| | lifecycle-v1 |dispute_id, |
| | |dispute_ref, |
| | |resolution |
+--------------------------+---------------------+----------------+
| artifact_transfer_offer | schema:attestation- |target_ref, |
| | lifecycle-v1 |from_holder, |
| | |to_holder, |
| | |predecessor_ref,|
| | |nonce |
+--------------------------+---------------------+----------------+
| artifact_transfer_accept | schema:attestation- |target_ref, |
| | lifecycle-v1 |from_holder, |
| | |to_holder, |
Sethi Expires 3 May 2027 [Page 12]
Internet-Draft OpenAIIS Protocol October 2026
| | |offer_ref |
+--------------------------+---------------------+----------------+
Table 2
A type definition determines the permitted issuer and subject roles,
exact allowed payload members and values, required and forbidden
references, content commitment profile, verification rules, and
lifecycle transitions. Merely matching the declared keys or a
payload digest does not validate its semantic authority.
Unrecognized types MUST NOT obtain recognized governance meaning
under an existing type's identifier.
The extension catalogue openaiis-universal-type-extensions-v2 adds:
* artifact_transfer_cancel under schema:attestation-lifecycle-v1,
binding a target attestation to a specified transfer offer; and
* company_release_authorization under schema:company-signed-release-
approval-v1, binding a principal's signed approval to an exact
software-release commitment.
A separately identified transfer-offer extension supports the
expires_at_tree_size constraint. Extensions MUST select their exact
versioned profile. An extension MUST NOT silently broaden the
meaning of an earlier signed record or grant privileges to an
otherwise unrecognized issuer.
7. Registry Admission and Authenticated History
7.1. Admission
The registrant signs locally, then submits the exact signed record
and required typed payload. The registry MUST validate canonical
encoding, issuer signature, configured issuer admission rules, record
type, payload hash, and profile-specific constraints before accepting
it.
An accepted record MUST be durably stored as its original signed
bytes and assigned a stable, zero-based log position. Its public
record digest is:
record_sha256 = HEX(SHA256(exact_signed_record_bytes))
Sethi Expires 3 May 2027 [Page 13]
Internet-Draft OpenAIIS Protocol October 2026
The same signed record submitted again to the same registry MUST be
idempotent and MUST NOT create a second history entry. A successful
registration response commits the registry to the automatic Bitcoin
anchoring obligation described in Section 8. The operator MUST
preserve sufficient durable state to continue the obligation across
crashes, outages, and restarts.
7.2. Domain-Separated Merkle Leaves
The log kind for universal registered claims is registry_record. For
a record at zero-based index i, compute:
r_i = HEX(SHA256(exact_signed_record_bytes_i))
p_i = "0000...0000" (64 zero hexadecimal characters), if i = 0
p_i = entry_digest_(i-1), otherwise
J_i = CanonicalJSON({
"profile": "openaiis-anchor-log-v1",
"kind": "registry_record",
"index": i,
"record_sha256": r_i,
"prev_entry_digest": p_i
})
E_i = ASCII("OPENAIIS-ANCHOR-LEAF-v1") || 0x00 || J_i
entry_digest_i = HEX(SHA256(E_i))
leaf_i = SHA256(0x00 || E_i)
node(L,R) = SHA256(0x01 || L || R)
The entry_digest and the Merkle leaf hash are distinct byte
commitments. The receipt's prev_entry_digest binds each entry to the
previous accepted entry commitment. A verifier MUST NOT hash the raw
record bytes directly as its Merkle leaf.
For a tree of size one, the root is leaf_0. For larger trees, split
the ordered leaf sequence at the largest power of two strictly less
than the number of leaves and hash the left and right subtree roots
using node(L,R). Inclusion and append-only consistency proofs use
the left-balanced Merkle algorithms of [RFC9162] with these OpenAIIS
leaf inputs. The root is a commitment to both exact record content
and registry order.
7.3. Inclusion Receipt
The profile openaiis-universal-inclusion-v1 contains the following
exact keys:
Sethi Expires 3 May 2027 [Page 14]
Internet-Draft OpenAIIS Protocol October 2026
+===================+============================+
| Key | Representation |
+===================+============================+
| profile | The exact inclusion- |
| | receipt profile identifier |
+-------------------+----------------------------+
| kind | registry_record |
+-------------------+----------------------------+
| record_sha256 | Lowercase 64-character hex |
| | digest |
+-------------------+----------------------------+
| index | Zero-based nonnegative |
| | integer |
+-------------------+----------------------------+
| tree_size | Authenticated positive |
| | integer |
+-------------------+----------------------------+
| root | Lowercase 64-character hex |
| | root |
+-------------------+----------------------------+
| prev_entry_digest | Lowercase 64-character hex |
| | predecessor digest |
+-------------------+----------------------------+
| inclusion_path | Ordered array of lowercase |
| | hex sibling hashes |
+-------------------+----------------------------+
Table 3
A verifier reconstructs the leaf input, checks index < tree_size,
reproduces the inclusion path, and compares the resulting root with
the same signed checkpoint's root. An inclusion proof under one root
MUST NOT be transferred to a different checkpoint without proving
inclusion under that target tree state.
7.4. Signed Checkpoints
A checkpoint authenticates the registry origin, tree_size, and
32-byte Merkle root using a key distinct from the claim issuer's
signing key. Its core note body consists of exactly three ASCII
lines, each terminated by LF (0x0A):
<registry_origin>\n
<decimal_tree_size>\n
<canonical_base64_of_32_byte_merkle_root>\n
Sethi Expires 3 May 2027 [Page 15]
Internet-Draft OpenAIIS Protocol October 2026
The displayed \n is an ASCII LF byte, not the literal two-character
sequence. The note follows the signed checkpoint structure described
by [C2SP-CHECKPOINT]: one empty line separates the body from the
signature line or lines.
The registry signs the exact three-line body with Ed25519. The
operator signature line contains its origin and the canonical Base64
of:
key_id || Ed25519_signature
key_id = first_4_bytes(SHA256(
ASCII(origin) || 0x0A || 0x01 || raw_public_key))
The complete signed note, including its body, separator, and
signature line or lines, is the object committed through Bitcoin. A
verifier MUST obtain the expected checkpoint origin and public key
independently of an untrusted receipt or bundle and MUST validate the
operator signature.
Two accepted signed checkpoints for the same origin MUST describe a
consistent append-only history. An operator MUST produce the
applicable [RFC9162] consistency proof between distinct authenticated
tree sizes. A checkpoint monitor, when deployed, MUST reject an
inconsistent later checkpoint under the same origin and signing
identity relative to the checkpoints it has retained. The registry's
signature and Bitcoin commitment do not depend on a monitor
cosignature or a separately operated witness quorum.
7.5. Authenticated Lifecycle Index
The index identifiers are openaiis-lifecycle-index-v1 and openaiis-
lifecycle-index-proof-v1. The signed index note binds its index root
to the registry origin, tree size, and log root. Index keys are
derived from record and subject scope and issuer-key identity using
versioned domain-separated commitments.
A verifier evaluating current governance state MUST establish an
adequately current authenticated registry checkpoint, the bound index
note, necessary membership and non-membership proofs, and the
relevant signed lifecycle records. Index evidence MUST be
reconstructible from the authenticated log history. A missing index
proof MUST NOT be taken as proof that no revocation, withdrawal,
transfer, or dispute exists.
Sethi Expires 3 May 2027 [Page 16]
Internet-Draft OpenAIIS Protocol October 2026
8. Bitcoin Anchoring and Confirmation
8.1. Exact Checkpoint Commitment
Let N be the exact UTF-8 bytes of the complete signed checkpoint
note. The detached timestamp has file-hash type SHA-256 and digest:
d = SHA256(N)
An OpenTimestamps commitment [OTS] preserves the cryptographic path
from this digest through its permitted operations to a Bitcoin block
attestation. Aggregation can bind multiple checkpoints to one
Bitcoin transaction, avoiding the need to place each individual claim
or original artifact on Bitcoin. The original documents,
confidential evidence, and typed payload bodies do not need to be
revealed on-chain.
The Bitcoin attestation is valid for the _exact signed checkpoint
bytes_. A claimed block height, pending calendar receipt, or proof
for a different checkpoint does not establish this checkpoint's
Bitcoin confirmation.
8.2. Automatic and Durable Processing
Every successfully registered claim at index i MUST be covered by a
signed checkpoint of size n where i < n. The registry MUST initiate
and persist a Bitcoin-commitment obligation automatically. A
registry MAY aggregate multiple consecutive accepted records in a
single checkpoint, provided every accepted record remains covered.
The anchoring workflow MUST perform, without further manual action by
the registrant:
1. Generation and durable retention of a signed covering checkpoint.
2. Submission of a commitment to the approved OpenTimestamps
calendar path or paths and retention of returned detached proof
material.
3. Subsequent retrieval and merging of authentic timestamp upgrades.
4. Verification of Bitcoin mainnet inclusion and required
confirmations.
5. Publication or retrievable export of the corresponding portable
proof and a verifiable status.
Sethi Expires 3 May 2027 [Page 17]
Internet-Draft OpenAIIS Protocol October 2026
A registry MUST preserve unfinished obligations and retry them with
bounded work after transient network, calendar, or verification-
source failures. Repeated attempts MUST be idempotent for the exact
checkpoint or produce a _different, separately signed_ checkpoint
consistent with accepted history. It MUST NOT silently abandon an
accepted record, substitute an unrelated historical Bitcoin proof, or
present a calendar's pending response as confirmed Bitcoin inclusion.
Network availability cannot force a particular time to Bitcoin
confirmation. Successful registry admission is therefore durable and
retrievable while the externally anchored evidence is still pending.
The mandatory anchoring obligation persists throughout that interval.
8.3. State Separation
Registration state is distinct from Bitcoin historical evidence
state. REGISTERED establishes successful durable admission, not
Bitcoin confirmation. The checkpoint evidence state has these
meanings:
+=========================+========================================+
| Evidence state | Established condition |
+=========================+========================================+
| CHECKPOINT_SIGNED | Exact checkpoint and its authenticated |
| | registry prefix are signed and durable |
+-------------------------+----------------------------------------+
| STAMPED_PENDING_BITCOIN | Detached timestamp carries a valid |
| | pending calendar attestation |
+-------------------------+----------------------------------------+
| BITCOIN_ATTESTED | Proof identifies a Bitcoin block |
| | commitment, but required confirmation |
| | evidence is incomplete |
+-------------------------+----------------------------------------+
| BITCOIN_CONFIRMED | Exact checkpoint proof and Bitcoin |
| | evidence satisfy the selected |
| | confirmation policy |
+-------------------------+----------------------------------------+
Table 4
ANCHOR_RETRY_PENDING, ANCHOR_UNVERIFIABLE, and ANCHOR_INVALID
describe processing or verification conditions, not successful
finality. The registry and verifier MUST distinguish unavailability
from an invalid cryptographic proof and preserve previously
authenticated evidence. A record MAY obtain historical confirmation
from any later _covering_ checkpoint when its membership in that
later checkpoint is independently demonstrated.
Sethi Expires 3 May 2027 [Page 18]
Internet-Draft OpenAIIS Protocol October 2026
8.4. Mainnet Confirmation and Assurance
The core Bitcoin confirmation policy requires a minimum of *six
Bitcoin mainnet confirmations*. For an attested block at height h and
accepted active-chain tip at height H:
confirmations = H - h + 1
BITCOIN_CONFIRMED only if confirmations >= 6
The verifier MUST validate the detached timestamp's exact-note
digest, permitted operations, Bitcoin block Merkle commitment, block-
header hash and proof of work, linked confirming headers, applicable
mainnet work constraints, and accepted active-chain evidence under
the declared verification assurance class. Verification of six block
confirmations does not require contact with six independent node
operators.
The assurance classes are:
+=========================+======================================+
| Class | Additional evidence |
+=========================+======================================+
| PUBLIC_SOURCE | Local OTS and header checks with |
| | provider-reported active-chain |
| | selection and bounded work reference |
+-------------------------+--------------------------------------+
| PINNED_ANCHOR | Public-source checks with |
| | independently established attested |
| | block identity |
+-------------------------+--------------------------------------+
| PINNED_CONFIRMING_CHAIN | Independently established anchor and |
| | confirming-tip identities and |
| | verified linkage |
+-------------------------+--------------------------------------+
| VALIDATING_NODE | A trusted fully validating mainnet |
| | node supplies active-chain and |
| | consensus validation; OpenAIIS |
| | commitments are checked locally |
+-------------------------+--------------------------------------+
Table 5
Sethi Expires 3 May 2027 [Page 19]
Internet-Draft OpenAIIS Protocol October 2026
A result MUST report its actual class and MUST NOT represent
provider-reported chain selection as independently executed full-node
consensus validation. Bitcoin reorganization can alter current
confirmation depth or accepted-chain membership; a verifier rechecks
current-chain status when its policy requires current confirmation.
A provider outage yields UNVERIFIABLE, rather than INVALID, unless
cryptographic inconsistency is actually established.
A checkpoint confirmed in Bitcoin inherits the historical resistance
to modification of Bitcoin's cumulative proof-of-work chain. To
replace the committed checkpoint history while presenting a valid
accepted Bitcoin chain, an adversary would need to establish a
competing chain with the necessary proof of work. Altering an
OpenAIIS database, compromising an AI agent, or replacing a registry
operator cannot by itself produce an alternative valid proof for the
original Bitcoin-anchored history. The exact signed checkpoint binds
the authenticated registry state, including claims of authorization,
responsibility, release and security evidence, to an independently
verifiable historical commitment.
This is computational and consensus-based protection rather than an
unconditional guarantee against every chain reorganization. Six
confirmations express the core policy for accepting that protection;
relying parties can require stronger assurance using the same Bitcoin
commitment. The proof establishes that the committed checkpoint data
existed by the attesting block's historical bound. Whether a
person's identity, an AI agent's delegation, or a real-world
assertion is accepted follows from the separately authenticated
governance and evidence rules.
9. Portable Proof and Independent Verification
9.1. Universal Proof Bundle
The exact bundle schema is openaiis-universal-bitcoin-bundle-v1. A
canonical JSON bundle contains exactly the following keys:
Sethi Expires 3 May 2027 [Page 20]
Internet-Draft OpenAIIS Protocol October 2026
+============+=============================================+
| Key | Meaning |
+============+=============================================+
| schema | Exact bundle schema |
+------------+---------------------------------------------+
| kind | registry_record |
+------------+---------------------------------------------+
| record_b64 | Canonical Base64 of the exact signed record |
+------------+---------------------------------------------+
| receipt | Exact inclusion receipt |
+------------+---------------------------------------------+
| note | Complete exact signed checkpoint note |
+------------+---------------------------------------------+
| ots_b64 | Canonical Base64 of the detached timestamp |
+------------+---------------------------------------------+
Table 6
The complete bundle MUST NOT exceed 2 MiB. The verifier MUST reject
unknown or duplicate top-level keys, malformed Base64, incompatible
record/receipt/bundle profiles, an altered signed note, a mismatched
timestamp digest, and a false inclusion path. The bundle does not
implicitly confer trust on the issuer, record content, or current
lifecycle state.
9.2. Verification Algorithm
An independent verifier processing a universal Bitcoin bundle MUST:
1. Obtain an expected registry origin, checkpoint signing key,
issuer identity/key binding, accepted type profile, and Bitcoin
assurance policy independently of the untrusted bundle.
2. Parse and verify the exact canonical record, profile-specific
signing domain, Ed25519 signature, and expected issuer key
identifier.
3. Reconstruct the domain-separated Merkle leaf and verify the
receipt's index, size, and inclusion path under the exact signed
checkpoint.
4. Verify the checkpoint origin/key, signature and root; check
relevant historical consistency against independently retained
checkpoints.
5. Require that the detached proof's SHA-256 digest is exactly
SHA256(UTF8(complete_signed_checkpoint_note)) and independently
evaluate its permitted commitment operations.
Sethi Expires 3 May 2027 [Page 21]
Internet-Draft OpenAIIS Protocol October 2026
6. Verify the claimed Bitcoin block and the six-confirmation minimum
under the selected assurance method, reporting that method and
current-chain evidence.
7. If a governance decision is requested, obtain and verify the
typed payload, supporting authority, consent, evidence,
responsibility and lifecycle records under a sufficiently current
authenticated head.
8. Return distinct integrity, inclusion, historical confirmation,
governance and policy results with reproducible evidence
references.
Checks 1 through 6 establish historical Bitcoin confirmation when all
of their conditions hold. Operational authorization additionally
requires the applicable governance checks. A relying party MUST NOT
infer the absence of later revocation from an older, even Bitcoin-
confirmed, registry checkpoint.
10. Governed Authority, Consent, and Responsibility
10.1. Scoped Delegation and Accountable Operations
Authority is expressed as an authenticated, typed relation between a
principal, a grantee, a scope and the action that scope permits. To
authorize a consequential action, a verifier MUST establish all
required links among trusted principal, authenticated delegation,
operation scope, applicable current lifecycle, request
authentication, and any required responsibility acceptance.
For accountable software publication, the relationship includes an
organization, operator, responsible principal, agent, exact signed
release and signed supporting evidence. A principal approval MUST
bind the intended action, release identity, code commitment, and
relevant delegation. Where an approval-before-release policy
applies, its _authenticated log position_ MUST precede that of the
release; claimed_at is an issuer assertion and cannot replace
authenticated ordering.
A private key's possession is not self-authorization. Key
replacement, revocation and recovery require a separately trusted and
applicable signed authority; a replacement key named in an untrusted
claim cannot inherit a revoked principal's rights.
Sethi Expires 3 May 2027 [Page 22]
Internet-Draft OpenAIIS Protocol October 2026
10.2. Consent-Governed Identity Attestations
An identity attestation subject to consent MUST reference separately
signed identity_consent from the independently recognized controller
of that identity. The consent intent commits to the precise intended
attestation with consent_refs excluded to avoid circular reference,
under the domain:
OPENAIIS/IDENTITY-CONSENT/v1\0
The verifier MUST confirm the subject-control key, exact consent
intent, attestation issuer and subject, content and typed
commitments, references and authenticated record order. An issuer's
attestation and the subject's consent are separate signatures with
separate functions.
Identity attestations are non-transferable. Subject withdrawal and
issuer revocation are separate events governed by their authorized
roles. Where a declared identity assurance profile requires k-of-n
independent issuers, the verifier MUST authenticate the selected
issuer set, applicable independence requirements, threshold and
required consent. Unknown or self-declared keys do not satisfy
issuer independence. No automatic expiry applies unless the selected
profile defines one.
10.3. Artifact Holders and Transfers
A transferable artifact attestation has a holder state derived from
its authenticated history. Transfer requires a valid signed offer by
the current holder and a distinct signed acceptance by the intended
recipient, referencing the same exact offer and predecessor state. A
verifier MUST reject a cancelled, mismatched, replayed, conflicting
or out-of-order offer, as well as an offer signed by an actor other
than the current recognized holder.
artifact_transfer_cancel cancels the referenced offer according to
the extension profile. The transfer-offer extension's
expires_at_tree_size, where selected, is evaluated against the
associated authenticated tree position. An attestation holder's
change does not in itself establish legal transfer of underlying
property.
Sethi Expires 3 May 2027 [Page 23]
Internet-Draft OpenAIIS Protocol October 2026
10.4. Disputes, Withdrawal, and Lifecycle Resolution
An issuer revocation, subject withdrawal, dispute, dispute
settlement, transfer offer, transfer acceptance and offer
cancellation remain distinct signed lifecycle events. An authorized
settlement references the particular unresolved dispute and its
qualified arbiter; merely signing a settlement does not confer
arbitration authority.
Current-state verification MUST account for relevant events in the
accepted authenticated order and apply the declared actor, scope and
policy rules. An open dispute can produce a REVIEW decision without
erasing the earlier signed assertion. A missing or stale current-
state proof MUST NOT silently become a positive authorization.
11. Verifiable Safety Evidence
Security-relevant claims identify the affected actor or artifact,
authenticated issuer, scope, committed evidence and relevant
lifecycle relationships. A signed incident or compromise assertion
is attributable but does not automatically override another entity's
authorized state. The verifier evaluates the incident issuer, role,
evidence, freshness and conflict or recovery events under the
applicable policy.
A policy-enforcement point for consequential effects MUST
authenticate the exact request intent, agent, principal, tenant,
action, resource and target. It MUST prevent changed-effect
substitution, unauthorized cross-tenant reuse and replay. Where the
selected action profile uses one-time grants, issuance and any
associated resource reservation MUST be atomic. An uncertain
execution outcome does not authorize repeating an irreversible
effect. An executor's signed outcome is evidence of its assertion,
not independent proof of external settlement.
When a signing key is compromised, authenticated revocation and
incident evidence can alter authorization of later activity while
retaining the original record's historical signature and Bitcoin-
backed provenance.
12. Decentralized Network Profiles
OpenAIIS nodes independently validate the same signed claims and
authenticated checkpoint history under versioned consensus profiles.
The network model supports proof-of-work ordering and admission
without a protocol-native currency. Unverified claims may be
registered under the declared anti-abuse work rules without a
recognized identity issuer; verified attestations additionally
Sethi Expires 3 May 2027 [Page 24]
Internet-Draft OpenAIIS Protocol October 2026
require the appropriate independently trusted authorities and
consent.
A versioned consensus profile MUST deterministically specify block
serialization, parent commitments, exact work inputs and targets,
difficulty transitions, record ordering, fork-choice and chainwork
comparison, reorganization handling, timestamp validity, admission
work, resource bounds, replay protection and synchronization
behavior. Nodes MUST enforce the exact declared profile and reject
invalid transitions. A validator MUST NOT claim cross-node consensus
interoperability without those common deterministic rules.
Independent nodes SHOULD make signed checkpoints, append-only
consistency proofs, and observed conflict evidence available for
independent verification. Optional checkpoint monitors MAY retain
and compare these records. No external monitor or witness
cosignature is required as an additional Bitcoin-anchoring or
confirmation gate. Bitcoin's proof-of-work history protects the
committed checkpoint; the OpenAIIS consensus profile specifies its
own record ordering, admission, and governance rules.
13. HTTP Interoperability Profile
The HTTP interface carries pre-signed claims and authenticated
evidence, not registry-generated signatures for claim issuers. For
an HTTP profile using the routes below, the method and path determine
the operation [RFC9110].
+========+===========================+===========================+
| Method | Path | Operation |
+========+===========================+===========================+
| GET | /health | Service liveness |
+--------+---------------------------+---------------------------+
| GET | /v1/capabilities | Supported formats, |
| | | origin, assurance methods |
+--------+---------------------------+---------------------------+
| GET | /v1/claim-types | Recognized typed profile |
| | | catalogue |
+--------+---------------------------+---------------------------+
| GET | /v1/registry/status | Authenticated registry |
| | | head and checkpoint |
+--------+---------------------------+---------------------------+
| POST | /v1/claims | Signed-claim registration |
| | | and durable Bitcoin |
| | | obligation |
+--------+---------------------------+---------------------------+
| GET | /v1/claims/{digest} | Exact signed record |
+--------+---------------------------+---------------------------+
Sethi Expires 3 May 2027 [Page 25]
Internet-Draft OpenAIIS Protocol October 2026
| GET | /v1/ | Covering checkpoint and |
| | claims/{digest}/receipt | inclusion receipt |
+--------+---------------------------+---------------------------+
| GET | /v1/ | Claim-specific Bitcoin |
| | claims/{digest}/anchor | status and proof identity |
+--------+---------------------------+---------------------------+
| POST | /v1/checkpoints | Authenticated operator |
| | | checkpoint operation |
+--------+---------------------------+---------------------------+
| GET | /v1/checkpoints/latest | Latest signed checkpoint |
+--------+---------------------------+---------------------------+
| GET | /v1/checkpoints/{size} | Checkpoint of specified |
| | | tree size |
+--------+---------------------------+---------------------------+
| GET | /v1/ | OTS and Bitcoin evidence |
| | checkpoints/{size}/anchor | for checkpoint |
+--------+---------------------------+---------------------------+
| GET | /v1/proofs/ | History consistency proof |
| | consistency?old=N&new=N | |
+--------+---------------------------+---------------------------+
| POST | /v1/verify/record | Canonical signature |
| | | validation |
+--------+---------------------------+---------------------------+
| POST | /v1/verify/typed | Typed payload and schema |
| | | validation |
+--------+---------------------------+---------------------------+
| POST | /v1/verify/inclusion | Signed receipt validation |
+--------+---------------------------+---------------------------+
Table 7
POST /v1/claims accepts a JSON object containing exactly
record_base64, payload_base64 and issuer_id. The first two are
canonical Base64 of the exact previously signed record and typed
payload; issuer_id matches the independently recognized issuer
admission policy. A successful new registration returns HTTP status
201 with its record digest, stable log position and retrievable
inclusion and Bitcoin-processing references. It MUST distinguish
registry admission from Bitcoin confirmation. Repeating an identical
signed record MUST NOT append another entry.
A syntactically malformed request produces HTTP 400, an unauthorized
issuer produces 403, a missing resource produces 404, an as-yet
unavailable covering-checkpoint receipt produces 409, and a
syntactically valid but invalid signature or typed claim produces
422. An operator MUST NOT return 201 unless both the accepted record
and the Bitcoin commitment obligation are durably recoverable.
Sethi Expires 3 May 2027 [Page 26]
Internet-Draft OpenAIIS Protocol October 2026
Anchor-status responses MUST bind their conclusions to registry
origin, checkpoint tree size, the SHA-256 of the exact note, and,
where relevant, record digest and proof digest. BITCOIN_CONFIRMED
additionally requires block height, hash, observed confirmation depth
and assurance class. The interface MUST preserve distinctions among
pending processing, provider unavailability, invalid evidence and
confirmed historical proof. Read-only proof retrieval does not
require access to private issuer or checkpoint signing keys.
Publicly exposed transports MUST use appropriate connection security,
resource limits and authorization on privileged mutations. Other
transports MAY carry the same authenticated objects if their framing
does not reinterpret signed bytes or proof identities.
14. Privacy and Interoperability
The registry records signed claims and commitments; original
confidential artifacts, evidence and identity documentation may
remain with their holders or approved custodians. No original
artifact data is required in a Bitcoin transaction. Public subject
identifiers and unsalted commitments may nevertheless disclose
sensitive relationships or make predictable information identifiable.
Privacy-sensitive profiles SHOULD use blinded commitments and
controlled disclosure where appropriate.
External COSE receipts [RFC9942], SCITT transparency models
[RFC9943], C2PA assertions [C2PA] and verifiable credentials [VC-DM]
MAY be referenced as typed evidence. Any adapter MUST enforce the
external format's original signature, issuer, proof and key rules.
No conversion or cross-registration can manufacture authority,
consent, Bitcoin inclusion or historical time that was not
established in the source evidence. OpenAIIS's canonical JSON record
and checkpoint profiles remain distinguishable from external COSE or
SCITT encodings.
15. Conformance
A conforming component identifies its actual role (issuer, registry,
node, verifier, relying party, or optional checkpoint monitor) and
exact protocol profile. A conforming OpenAIIS registry MUST satisfy
the universal record, Merkle, checkpoint, and mandatory automatic
Bitcoin-anchoring requirements. A conforming Bitcoin historical
verifier MUST satisfy the exact-note proof checks and selected
confirmation assurance class. A component claiming governance
verification MUST additionally enforce applicable typed authority,
consent, lifecycle and policy rules.
The following requirements form a compact conformance matrix:
Sethi Expires 3 May 2027 [Page 27]
Internet-Draft OpenAIIS Protocol October 2026
+======+=============================================+
| ID | Requirement |
+======+=============================================+
| C-01 | Exact canonical record and domain-separated |
| | signature verification |
+------+---------------------------------------------+
| C-02 | Versioned typed-payload, role, reference |
| | and consent constraints |
+------+---------------------------------------------+
| C-03 | Durable, stable, idempotent registry |
| | admission |
+------+---------------------------------------------+
| C-04 | Exact domain-separated Merkle leaves, roots |
| | and receipts |
+------+---------------------------------------------+
| C-05 | Signed checkpoint origin/key identity and |
| | append-only consistency |
+------+---------------------------------------------+
| C-06 | Automatic durable Bitcoin obligation for |
| | every accepted claim |
+------+---------------------------------------------+
| C-07 | Retention, bounded retry and recovery for |
| | unfinished anchoring |
+------+---------------------------------------------+
| C-08 | SHA-256 of exact signed note, detached OTS |
| | path and six-confirmation minimum |
+------+---------------------------------------------+
| C-09 | Separate pending, invalid, unverifiable and |
| | confirmed statuses with assurance basis |
+------+---------------------------------------------+
| C-10 | Governed consent, identity, authority, |
| | responsibility and lifecycle resolution |
+------+---------------------------------------------+
| C-11 | Reproducible decisions for identical |
| | authenticated inputs and policy |
+------+---------------------------------------------+
| C-12 | Exact enforcement of a separately declared |
| | network consensus profile |
+------+---------------------------------------------+
Table 8
Historic record authenticity and current authorization are different
claims. A verifier MUST NOT treat a Bitcoin-confirmed signature, an
unauthenticated incident assertion or an old receipt as sufficient
permission for an unrelated consequential operation.
Sethi Expires 3 May 2027 [Page 28]
Internet-Draft OpenAIIS Protocol October 2026
16. Security Considerations
*Trust-root substitution:* A malicious proof may embed its own issuer
or checkpoint public keys. Verifiers MUST acquire expected issuer,
origin, role and checkpoint-key trust independently. Valid
signatures from attacker-selected keys are not recognized authority.
*Log equivocation and stale-state omission:* An inclusion proof under
one signed checkpoint demonstrates membership in that state. Bitcoin
anchoring protects that committed historical state against
retroactive replacement under the accepted chain's proof-of-work
assumptions; it does not prove that an operator published every
relevant claim or that an old checkpoint is the latest. Decisions
requiring current authority MUST establish an adequately current
authenticated registry head and validate the relevant consistency and
lifecycle-index evidence. Independent checkpoint monitoring MAY help
expose equivocation; it is not a required external witness service.
*Bitcoin proof substitution and chain selection:* The detached proof
MUST bind the exact signed note and Bitcoin Merkle commitment.
Pending calendar receipts MUST NOT be promoted to Bitcoin
confirmation. Verifiers MUST disclose their chain-selection
assurance class and reassess current confirmation status when network
reorganization affects it. A compromised public source can misreport
its own selected chain; local proof-of-work/header checks alone do
not grant full-node consensus assurance.
*Authorization and replay:* Consent, delegation, approvals, transfer
state, disputes, one-time effect grants and key recovery require
exact scopes and independently authenticated actors. Client-supplied
parameters or timestamps cannot confer authority to execute an
action.
*Resource exhaustion and disclosure:* Parsers, inclusion paths,
timestamp operations and external responses MUST be bounded. A
verifier MUST NOT fetch untrusted arbitrary calendar URLs without an
explicit, constrained policy. Operators SHOULD minimize public
identifiers, avoid publishing confidential original evidence, and use
privacy-preserving commitment profiles for predictable sensitive
data.
17. IANA Considerations
This document requests no IANA actions. OpenAIIS's versioned record,
type, receipt and proof identifiers are protocol-defined values
rather than assignments from an existing IANA registry. Any
subsequent request for an IANA-maintained namespace will be specified
separately with its allocation and change-control policy.
Sethi Expires 3 May 2027 [Page 29]
Internet-Draft OpenAIIS Protocol October 2026
18. References
18.1. Normative References
[C2SP-CHECKPOINT]
Project, C. C. S., "Transparency Log Checkpoints", n.d.,
<https://c2sp.org/tlog-checkpoint>.
[OTS] Project, O., "OpenTimestamps: A Timestamping Proof
Standard", n.d., <https://opentimestamps.org/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/rfc/rfc4648>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/rfc/rfc8032>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/rfc/rfc8259>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/rfc/rfc9110>.
[RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate
Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162,
December 2021, <https://www.rfc-editor.org/rfc/rfc9162>.
18.2. Informative References
[BITCOIN] Nakamoto, S., "Bitcoin: A Peer-to-Peer Electronic Cash
System", 2008, <https://bitcoin.org/bitcoin.pdf>.
Sethi Expires 3 May 2027 [Page 30]
Internet-Draft OpenAIIS Protocol October 2026
[C2PA] Authenticity, C. for C. P. and., "C2PA Technical
Specifications", n.d.,
<https://spec.c2pa.org/specifications/>.
[RFC9942] Steele, O., Birkholz, H., Delignat-Lavaud, A., and C.
Fournet, "CBOR Object Signing and Encryption (COSE)
Receipts", RFC 9942, DOI 10.17487/RFC9942, June 2026,
<https://www.rfc-editor.org/rfc/rfc9942>.
[RFC9943] Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande,
Y., and S. Lasker, "An Architecture for Trustworthy and
Transparent Digital Supply Chains", RFC 9943,
DOI 10.17487/RFC9943, June 2026,
<https://www.rfc-editor.org/rfc/rfc9943>.
[VC-DM] Consortium, W. W. W., "Verifiable Credentials Data Model
v2.0", 2025, <https://www.w3.org/TR/vc-data-model-2.0/>.
Appendix A. Reproducible Merkle-Leaf Test Vector
This vector exercises the exact registry leaf algorithm,
independently of any assertion that the illustrative ASCII input is a
valid signed universal claim. Let the input record bytes be ASCII
example, with:
In the following vector, each 64-character hexadecimal digest appears
on the line immediately following its field name.
record_sha256 =
50d858e0985ecc7f60418aaf0cc5ab587f42c2570a884095a9e8ccacd0f6545c
index = 0
kind = registry_record
prev_entry_digest =
0000000000000000000000000000000000000000000000000000000000000000
The canonical preimage procedure in Section 7.2 yields:
entry_digest =
6c950db18d058aa5a9d28d64ebca5cf18f61b192bb60437a4e93d2ba7388c86d
leaf_hash =
672cde8b236cf3d48ce2d2c52a5b16f911db55ccb6a49916b026bf312659a9b2
one_leaf_root =
672cde8b236cf3d48ce2d2c52a5b16f911db55ccb6a49916b026bf312659a9b2
Sethi Expires 3 May 2027 [Page 31]
Internet-Draft OpenAIIS Protocol October 2026
Implementations of this exact leaf profile MUST reproduce these
digests. The complete conformance suite additionally includes
records, signatures, typed validation, checkpoint notes, timestamp
operations, Bitcoin confirmation, lifecycle resolutions and network-
profile vectors appropriate to each claimed conformance role.
Appendix B. Protocol Identifiers
+==================+===========================================+
| Object | Exact identifier |
+==================+===========================================+
| Universal signed | openaiis-universal-registry-v1 |
| record | |
+------------------+-------------------------------------------+
| Signed-record | OPENAIIS/UNIVERSAL-REGISTRATION/v1\0 |
| domain | |
+------------------+-------------------------------------------+
| Inclusion | openaiis-universal-inclusion-v1 |
| receipt | |
+------------------+-------------------------------------------+
| Registry entry | openaiis-anchor-log-v1 |
| profile | |
+------------------+-------------------------------------------+
| Registry leaf | OPENAIIS-ANCHOR-LEAF-v1\0 |
| domain | |
+------------------+-------------------------------------------+
| Registry log | registry_record |
| kind | |
+------------------+-------------------------------------------+
| Core 17-type | openaiis-universal-type-lock-v1 |
| catalogue | |
+------------------+-------------------------------------------+
| Extension | openaiis-universal-type-extensions-v2 |
| catalogue | |
+------------------+-------------------------------------------+
| Identity-consent | OPENAIIS/IDENTITY-CONSENT/v1\0 |
| domain | |
+------------------+-------------------------------------------+
| Private artifact | openaiis-artifact_registration-private-v1 |
| profile | |
+------------------+-------------------------------------------+
| Private-content | OPENAIIS/PRIVATE-ARTIFACT-COMMITMENT/v1\0 |
| domain | |
+------------------+-------------------------------------------+
| Lifecycle index | openaiis-lifecycle-index-v1 |
+------------------+-------------------------------------------+
| Lifecycle proof | openaiis-lifecycle-index-proof-v1 |
+------------------+-------------------------------------------+
Sethi Expires 3 May 2027 [Page 32]
Internet-Draft OpenAIIS Protocol October 2026
| Portable Bitcoin | openaiis-universal-bitcoin-bundle-v1 |
| bundle | |
+------------------+-------------------------------------------+
Table 9
Appendix C. Acknowledgments
The author acknowledges the foundational open work on Bitcoin
[BITCOIN], append-only Merkle transparency [RFC9162], signed
checkpoints [C2SP-CHECKPOINT], and portable timestamp commitments
[OTS]. The broader interoperability landscape includes transparent
signed supply-chain statements [RFC9943] and cryptographically
verifiable receipts [RFC9942].
Author's Address
Tarun Sethi
OpenAIIS
Germany
Email: contact@openaiis.org
URI: https://openaiis.org
Sethi Expires 3 May 2027 [Page 33]