Signed claims
The basic unit is a signed, typed claim: a statement about an exact digital subject, made by an identified issuer, with references to the authority, evidence and consent behind it.
The issuer signs canonical JSON (sorted keys, no extra fields, at most 65,536 bytes) prefixed with a fixed signing domain, using Ed25519. Content is committed by SHA-256, so the original file can stay private: anyone who later receives the bytes can recompute the digest and compare.
M = OPENAIIS/UNIVERSAL-REGISTRATION/v1\0 || CanonicalJSON(claim body)
signature = Ed25519.Sign(issuer_private_key, M)
content_sha256 = "sha256:" || HEX(SHA256(original bytes))A verifier checks the signature against an issuer key it has pinned independently. A key that arrives inside the claim proves nothing about who the issuer is. For confidential work, a private profile uses a salted, domain-separated digest so that predictable content cannot be guessed from its hash.
Protocol V5.0 §3; Whitepaper V4.0 §3
Typed claims
Every claim has a declared type and payload schema. The type decides what the claim can mean: a claim that a document existed is different from an identity attestation, which is different again from permission to run software. The core vocabulary has 17 types.
| Area | Core claim types |
|---|---|
| Creative, scientific and technical work | artifact_registration, invention_claim, research_work, software_release, ai_generated_code, media_work |
| Identity, attestations and consent | identity_attestation, artifact_attestation, identity_consent |
| Delegation and supporting evidence | authority_statement, evidence_attestation |
| Lifecycle, dispute and transfer | issuer_revocation, subject_withdrawal, dispute_raised, dispute_settled, artifact_transfer_offer, artifact_transfer_accept |
An extension catalogue adds artifact_transfer_cancel and
company_release_authorization. New meanings need an explicitly versioned type
definition: an unknown signed JSON object never gains governance or safety authority on its own.
Protocol V5.0 §4
Authority, consent and responsibility
Trust is specific to an actor, a key, a scope and an operation. An issuer trusted for research credentials has no authority over software publication. An agent allowed to publish software cannot change its own delegation. For a delegated operation, the verifier must establish:
Authorized(A) = TrustedPrincipal AND ValidDelegation AND ScopeMatch
AND CurrentAuthority AND AuthenticatedRequestNone of these can be inferred from holding an agent's signing key. Where responsibility is required, a principal must have signed an explicit acceptance of it.
Identity attestations need the subject's consent. The subject signs the exact intended attestation under a separate signing domain, and the attestation must reference that consent record. Naming a person, or pointing at an unsigned statement, is not consent.
Protocol V5.0 §5 and §6; Whitepaper V4.0 §4
Revocation, withdrawal, disputes and transfer
Authority changes after records are published, so those changes are new signed records rather than edits. Each has its own actor and meaning:
- An issuer revokes its own attestation.
- A subject withdraws consent, which is not the same as the issuer revoking.
- An authorized party raises a dispute, and an independent arbiter can settle it. A dispute does not erase the record it targets.
- An artifact attestation moves to a new holder only when the current holder signs an offer and the recipient signs acceptance of that exact offer. Identity attestations can never be transferred.
These states stay distinct. The protocol forbids collapsing them into a single "verified" flag. A signed lifecycle index lets a verifier check the governance state of one record at a given checkpoint without reading the whole history.
Protocol V5.0 §6 to §8 and §11.4
Accountable software and agent actions
An accountable software release is checked as a chain of separately signed records:
Organization -> Operator -> Responsible Principal -> Agent -> Signed Release -> Signed EvidenceThe verifier confirms the release bytes match their digest, the expected agent key signed it, the operator binding, responsibility acceptance and delegation are authentic and still valid, the delegation covers this project and action, and the evidence meets the policy. A valid agent signature cannot stand in for any missing link.
When the evidence is used to authorize a real-world effect, the decision and the execution are kept apart. The enforcement point can issue a single-use grant scoped to the exact operation; replays, changed effects, other tenants and reused grants are rejected, and spending limits are checked atomically. The executor's signed outcome keeps "completed", "failed" and "uncertain" distinct.
If a key is compromised, the organization can publish an authenticated revocation, and a security issuer can link evidence about affected releases. Each relying system decides what to do using its own trust roots. A report from an unknown signer cannot override trusted authorization records, and conflicting evidence stays visible.
Protocol V5.0 §9 and §10; Whitepaper V4.0 §5 and §6
Verifiable registry history
Registered claims are appended to an ordered Merkle log. Each registration gets a receipt with its position, the tree size, the root and the inclusion path. A checkpoint signer, separate from every claim issuer, signs the tree size and root in the C2SP signed-note format.
A receipt proves inclusion relative to one exact checkpoint. Successive checkpoints are linked by RFC 9162 consistency proofs, and independent witnesses can compare them to detect an operator showing different histories to different people. Submitting the same record twice returns the same entry.
Protocol V5.0 §11; Whitepaper V4.0 §7
Verifying and deciding
A full evaluation runs in this order, and the result says which properties were actually checked:
- Canonical encoding, issuer identity and signature
- Typed payload and schema, and the content commitment when the bytes are available
- Checkpoint signer and origin, then Merkle inclusion
- Referenced records: consent, authority and responsibility
- Lifecycle history, required evidence and evaluation windows
- The relying party's policy, returning a decision with reasons and evidence references
Every applicable authenticated requirement is satisfied.
A recognized rule fails or an authenticated prohibition applies.
Missing or conflicting information prevents an automated yes.
A valid Merkle receipt alone can never become ALLOW. A decision that depends on nothing having been revoked needs a sufficiently complete and current history, not just an old receipt. Given the same evidence, trust roots and policy, independent verifiers must reach the same result.
Protocol V5.0 §12 and §17; Appendix B lists 23 verifier invariants
Bitcoin anchoring
A signed checkpoint can be timestamped through OpenTimestamps into Bitcoin. One commitment then covers every record proven beneath that checkpoint, with no Bitcoin transaction per claim.
Issuer-signed claim
-> RFC 9162 inclusion receipt
-> operator-signed checkpoint note
-> detached OpenTimestamps proof of that exact note
-> Bitcoin transaction commitment
-> mainnet block-header and confirmation evidenceThe verifier checks the registry evidence first, then the Bitcoin evidence: proof of work, linked confirming headers (six by default) and difficulty. Results name the assurance class applied, from public-source header verification up to an independently pinned confirming chain, and one class is never reported as another.
Bitcoin gives a historical bound: the checkpoint existed no later than the block. It does not prove authorship, legal priority, authority, consent or that a claim is true.
Protocol V5.0 §13; Whitepaper V4.0 §9. See the Bitcoin proof.
The decentralized network
The intended architecture is a network of independently operated nodes that validate records, keep a common history and expose portable proofs, so no single organization controls registration or verification. Proof of work is the candidate basis for ordering, and the network is designed without a native token: fees for services or capacity can be paid in existing assets.
Node acceptance fixes a record's place in history, not the truth of its contents. Fork choice, difficulty, admission and abuse prevention must be fully specified before the network runs. This network is not deployed today; see Status.
Protocol V5.0 §14; Whitepaper V4.0 §8
Existing standards and privacy
OpenAIIS builds on Certificate Transparency (RFC 9162), C2SP checkpoints, SCITT (RFC 9943) and COSE receipts (RFC 9942), Sigstore and Rekor, C2PA, W3C Verifiable Credentials and OpenTimestamps. These can supply evidence or receipts under explicitly identified profiles; converting a format never manufactures authority, consent or historical time.
The registry stores commitments and signed statements, not original content. A public hash of predictable content can still reveal it, so private profiles and controlled disclosure exist for sensitive material.
Protocol V5.0 §15 and §16; Whitepaper V4.0 §10.2 and §12