]> OpenAIIS

Germany contact@openaiis.org https://openaiis.org

OpenAIIS Artificial Intelligence agentic AI autonomous AI agents AI safety decentralized trust governance signed claims transparency Bitcoin independent verification 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.

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

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

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.

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.

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.

Universal Signed Claim

Record Envelope The core profile identifier is openaiis-universal-registry-v1. A signed record is a canonical JSON object containing exactly the following fields:

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

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.

Canonical Encoding A canonical record is serialized as JSON 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.

Cryptographic Signature The universal signed-record profile uses Ed25519 , with the following exact signing domain: 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: signature MUST be the padded, canonical Base64 encoding 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.

Content Commitments For original content bytes B, the ordinary profile uses: For canonical typed-payload bytes 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: Its content commitment is: 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.

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.

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 schema	Declared payload fields or format
artifact_registration	schema:artifact-registration-v1	profile, media_type, visibility
invention_claim	schema:invention-claim-v1	profile, invention_kind, disclosure
research_work	schema:research-work-v1	profile, research_kind, visibility
software_release	schema:company-release-v1	Release authorization and evidence fields
ai_generated_code	schema:ai-generated-code-v1	profile, tool_id, model_claim, review_status
media_work	schema:media-work-v1	profile, media_type, rights_claim
identity_attestation	schema:identity-attestation-v1	profile, holder_id, evidence_sha256
artifact_attestation	schema:artifact-attestation-v1	profile, holder_id, evidence_sha256
identity_consent	schema:identity-consent-v1	profile, intent_sha256
authority_statement	schema:authority-statement-v1	Embedded independently signed authority statement
evidence_attestation	schema:company-evidence-v1	profile, release_id, code_sha256, evidence_sha256, not_before, not_after
issuer_revocation	schema:attestation-lifecycle-v1	target_ref, reason
subject_withdrawal	schema:attestation-lifecycle-v1	target_ref
dispute_raised	schema:attestation-lifecycle-v1	target_ref, dispute_id, reason
dispute_settled	schema:attestation-lifecycle-v1	target_ref, dispute_id, dispute_ref, resolution
artifact_transfer_offer	schema:attestation-lifecycle-v1	target_ref, from_holder, to_holder, predecessor_ref, nonce
artifact_transfer_accept	schema:attestation-lifecycle-v1	target_ref, from_holder, to_holder, offer_ref

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.

Registry Admission and Authenticated History

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: 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 . The operator MUST preserve sufficient durable state to continue the obligation across crashes, outages, and restarts.

Domain-Separated Merkle Leaves The log kind for universal registered claims is registry_record. For a record at zero-based index i, compute: 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 with these OpenAIIS leaf inputs. The root is a commitment to both exact record content and registry order.

Inclusion Receipt The profile openaiis-universal-inclusion-v1 contains the following exact keys:

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

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.

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 ]]> The displayed \n is an ASCII LF byte, not the literal two-character sequence. The note follows the signed checkpoint structure described by : 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: 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 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.

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.

Bitcoin Anchoring and Confirmation

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: An OpenTimestamps commitment 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.

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.

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.

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

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.

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: = 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

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.

Portable Proof and Independent Verification

Universal Proof Bundle The exact bundle schema is openaiis-universal-bitcoin-bundle-v1. A canonical JSON bundle contains exactly the following keys:

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

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.

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

Governed Authority, Consent, and Responsibility

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.

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

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.

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.

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.

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

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 .

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
GET	/v1/claims/{digest}/receipt	Covering checkpoint and inclusion receipt
GET	/v1/claims/{digest}/anchor	Claim-specific Bitcoin 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/checkpoints/{size}/anchor	OTS and Bitcoin evidence for checkpoint
GET	/v1/proofs/consistency?old=N&new=N	History consistency proof
POST	/v1/verify/record	Canonical signature validation
POST	/v1/verify/typed	Typed payload and schema validation
POST	/v1/verify/inclusion	Signed receipt validation

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

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 , SCITT transparency models , C2PA assertions and verifiable credentials 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.

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:

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

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.

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.

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.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. This document describes version 2.0 of the Certificate Transparency (CT) protocol for publicly logging the existence of Transport Layer Security (TLS) server certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. This document obsoletes RFC 6962. It also specifies a new TLS extension that is used to send various CT log artifacts. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. n.d. n.d. Informative References CBOR Object Signing and Encryption (COSE) Receipts prove properties of a Verifiable Data Structure (VDS) to a verifier. VDSs and associated Proof Types enable security properties, such as minimal disclosure, transparency, and non-equivocation. Transparency helps maintain trust over time and has been applied to certificates, end-to-end encrypted messaging systems, and supply chain security. This specification enables concise transparency-oriented systems by building on Concise Binary Object Representation (CBOR) and COSE. The extensibility of the approach is demonstrated by providing CBOR encodings for Merkle inclusion and consistency proofs. Traceability in supply chains is a growing security concern. While Verifiable Data Structures (VDSs) have addressed specific issues, such as equivocation over digital certificates, they lack a universal architecture for all supply chains. This document defines such an architecture for single-issuer signed statement transparency. It ensures extensibility and interoperability between different transparency services as well as compliance with various auditing procedures and regulatory requirements. n.d.

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. The canonical preimage procedure in yields: 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.

Protocol Identifiers

Object	Exact identifier
Universal signed record	openaiis-universal-registry-v1
Signed-record domain	OPENAIIS/UNIVERSAL-REGISTRATION/v1\0
Inclusion receipt	openaiis-universal-inclusion-v1
Registry entry profile	openaiis-anchor-log-v1
Registry leaf domain	OPENAIIS-ANCHOR-LEAF-v1\0
Registry log kind	registry_record
Core 17-type catalogue	openaiis-universal-type-lock-v1
Extension catalogue	openaiis-universal-type-extensions-v2
Identity-consent domain	OPENAIIS/IDENTITY-CONSENT/v1\0
Private artifact profile	openaiis-artifact_registration-private-v1
Private-content domain	OPENAIIS/PRIVATE-ARTIFACT-COMMITMENT/v1\0
Lifecycle index	openaiis-lifecycle-index-v1
Lifecycle proof	openaiis-lifecycle-index-proof-v1
Portable Bitcoin bundle	openaiis-universal-bitcoin-bundle-v1

Acknowledgments The author acknowledges the foundational open work on Bitcoin , append-only Merkle transparency , signed checkpoints , and portable timestamp commitments . The broader interoperability landscape includes transparent signed supply-chain statements and cryptographically verifiable receipts .