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): \n \n \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., . [OTS] Project, O., "OpenTimestamps: A Timestamping Proof Standard", n.d., . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, . [RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162, December 2021, . 18.2. Informative References [BITCOIN] Nakamoto, S., "Bitcoin: A Peer-to-Peer Electronic Cash System", 2008, . 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., . [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, . [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, . [VC-DM] Consortium, W. W. W., "Verifiable Credentials Data Model v2.0", 2025, . 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]