DEOS Trust Substrate — Registries v1 Specification
Status: v1.1 — drafted 2026-05-05
Spec URI: https://projectmaya.deoscomputing.io/registry/v1
Maintainer: DEOS Computing (did:web:deos.computing)
The central registry for DEOS-specific identifiers across all published specifications. Implementations adding new values MUST register them here and follow the addition procedure in §10.
1. Action types (action.type)
Per /receipts/format/v1 §3.
| Action type | Reserved? | Required metadata keys |
Spec |
|---|---|---|---|
tool_call |
yes | tool_name, server_did |
§6.1 |
payment_intent |
yes | from, to, amount, currency |
§6.2 |
payment_settlement |
yes | intent_receipt_id, rail, external_ref |
§6.3 |
identity_claim |
yes | claim_type, evidence_hash |
§6.4 |
message_send |
yes | to, transport, content_hash |
§6.5 |
code_execution |
yes | program_did, args_hash, exit_code |
§6.6 |
policy_evaluation |
yes | policy_id, decision, reason |
§6.7 |
Vendor extensions MUST use the x- prefix:
x-vendor.namespace.thing(DNS-style; uniqueness is the vendor's responsibility)- e.g.
x-acme.kv.read,x-acme.kv.write
Verifiers SHOULD pass through unknown x- types without rejecting; v1 receivers that want to enforce types REJECT receipts with unknown action.types.
2. Caveat keys
| Key | Type | Allowed at |
|---|---|---|
with |
string OR array of strings | every attenuation |
can |
string (path with optional * / ** wildcards) |
every attenuation |
max |
integer or decimal-string | per-action-type (e.g. payment_intent.amount) |
min |
integer or decimal-string | per-action-type |
until |
integer (unix seconds) | every attenuation; AND-composes with token exp |
after |
integer (unix seconds) | every attenuation; AND-composes with token nbf |
allow |
array of strings | per-action-type-per-key |
deny |
array of strings | per-action-type-per-key |
Vendor caveat keys MUST use x- prefix.
3. Anchor schemes
Per /anchor/v1 and /anchor/bitcoin/v1.
| Service identifier | Spec | Status |
|---|---|---|
opentimestamps |
/anchor/v1 |
v1.0 |
ethereum-l1 |
/anchor/bitcoin/v1 §4 |
v1.2 |
rfc3161-tsa |
/anchor/bitcoin/v1 §4 |
v1.2 |
filecoin |
/anchor/bitcoin/v1 §4 |
v1.2 |
eigenda |
/anchor/bitcoin/v1 §4 |
v1.2 |
Vendor anchor schemes use x- prefix.
4. Signature algorithms
Per /receipts/format/v1 §2.2.
| Identifier | Algorithm | Status |
|---|---|---|
ed25519 |
Ed25519 (RFC 8032) | v1.0 |
ed25519-pq |
Hybrid Ed25519 + ML-DSA-65 | v1.2 (planned) |
For SCITT-profile receipts, identifiers come from the COSE Algorithms registry (RFC 9053). DEOS uses:
| COSE alg | Name | Status |
|---|---|---|
-8 |
EdDSA (Ed25519) | v1.1 |
-50 |
ML-DSA-65 | v1.2 (per draft-ietf-cose-dilithium) |
5. Hash functions
| Identifier | Algorithm | Used for |
|---|---|---|
| BLAKE3-256 | BLAKE3 256-bit output | DEOS-internal content addressing (receipt id, action hashes, MMR legacy log) |
| SHA-256 | NIST FIPS 180-4 | SCITT-facing (MMR for SCITT profile, OTS leaf hash, dual-hash strategy) |
The v1.1 substrate runs both; the SCITT profile (/interop/scitt/v1 §5) explains the dual-hash design.
6. Domain-separation tags
Tags prefix the canonical bytes before signing to prevent cross-protocol attacks. All tags are ASCII strings ending with :.
6.1 Prefix-freedom invariant
Domain-separation tags in v1 are concatenated to canonical bytes as bare UTF-8 strings: signing_payload = TAG || canonical(body). For this construction to be unambiguous — for two distinct (TAG, body) pairs to never produce the same signing_payload — the registered tag set MUST satisfy:
- Colon termination. Every registered tag MUST end with the byte
:(0x3A). - Prefix-freedom. No registered tag MUST be a byte-string prefix of another.
- Body-disjointness. The canonical-body bytes that follow MUST NOT begin with
:. Canonical JSON per/receipts/format/v1§4 always begins with{,[,", a digit, orn/t/f— never:— so this holds by construction for every signed body in this registry.
Together, these guarantee unique parseability of (TAG, body) from signing_payload. A verifier scans for the first : byte; the prefix up to and including it is the tag, and prefix-freedom ensures no other registered tag could have produced the same prefix. Body-disjointness ensures the verifier cannot mis-parse a : from the body as the tag terminator.
A normative CI test in the reference implementation parses this section and asserts (1) and (2) on every build. A new tag that violates either invariant fails the test.
6.2 Tag registry
| Tag | Used by | Spec |
|---|---|---|
deos-receipt-v1: |
receipt signing | /receipts/format/v1 §4.3 |
deos-mmr-leaf-v1: |
BLAKE3 MMR leaf hash | /merkle/log/v1 §3 |
deos-mmr-node-v1: |
BLAKE3 MMR internal node | /merkle/log/v1 §3 |
deos-mmr-bag-v1: |
BLAKE3 MMR peak bagging | /merkle/log/v1 §3 |
deos-mmr-root-v1: |
BLAKE3 MMR root | /merkle/log/v1 §3 |
deos-ucan-v1: |
UCAN token signing | /ucan/tokens/v1 §3 |
deos-revocation-v1: |
revocation entry signing | /revocation/v1 §3 |
deos-agent-derivation-v1: |
DID derivation entry signing | /did/deos/v1 §5 |
deos-substrate-rotation-v1: |
substrate signing-key rotation event | /key-rotation/v1 §2.2 |
deos-tombstone-v1: |
tombstone redaction signing | deployment-topology spec (operator-internal) |
deos-witness-observation-v1: |
witness observation signing | /mmr/transparency/v1 §3.1 |
deos-did-rotation-v1: |
KERI-style DID key rotation event signing | /did/deos/v1 §10.6 (v1.2) |
deos-non-membership-v1: |
revocation-log non-membership statement signing | /revocation/v1 §7 |
For SCITT-profile signing the tag is COSE_Sign1's Sig_structure first element "Signature1" (RFC 9052 §4.4); the DEOS prefix is dropped because the COSE structure provides domain separation natively.
7. CBOR labels (DEOS-private use)
Per /interop/scitt/v1 §11. All in the negative integer private-use range below -65536.
| Label | Name | Where | Spec |
|---|---|---|---|
| -65537 | deos_principal |
Statement protected header CWT_Claims | scitt-profile §2.3 |
| -65538 | deos_capability |
Statement protected header CWT_Claims | scitt-profile §2.3 |
| -65539 | deos_replay |
Statement protected header CWT_Claims | scitt-profile §2.3 |
| -65540 | deos_log_meta |
Statement protected header CWT_Claims | scitt-profile §2.3 |
| -65541 | deos_anchors |
Receipt unprotected header | scitt-profile §4.2 |
| -65542 | DEOS-MMR-SHA256 VDS identifier | Receipt protected header vds (label 395) |
scitt-profile §4.3 |
| -65543 | deos_issued_at_ns |
optional CWT_Claims for ns precision | scitt-profile §8 |
8. JSON schemas (top-level)
| Schema string | Spec |
|---|---|
deos_receipt_v1 |
/receipts/format/v1 |
deos_capability_chain_v1 |
/ucan/tokens/v1 |
deos_revocation_v1 |
/revocation/v1 |
deos_anchor_v1 |
/anchor/v1 |
deos_did_doc_v1 |
/did/deos/v1 |
deos_substrate_rotation_v1 |
/key-rotation/v1 |
deos_tombstone_v1 |
deployment-topology spec (operator-internal) |
deos_caveat_revocation_v1 |
/capability/caveats/v1 |
deos_witness_observation_v1 |
/mmr/transparency/v1 |
deos_did_event_v1 |
/did/deos/v1 §11 |
deos_federation_manifest_v1 |
/did/deos/v1 §12 |
9. Substrate revocation reasons
Per /revocation/v1 and /key-rotation/v1.
| Reason | Used in | Spec |
|---|---|---|
key_compromise |
revocation entry | /revocation/v1 |
policy_change |
revocation entry | /revocation/v1 |
expiry_early |
revocation entry | /revocation/v1 |
scheduled |
substrate rotation event | /key-rotation/v1 |
suspected_compromise |
substrate rotation event | /key-rotation/v1 |
operator_request |
substrate rotation event | /key-rotation/v1 |
gdpr_article_17 |
tombstone | deployment-topology spec (operator-internal) |
legal_compliance |
tombstone | deployment-topology spec (operator-internal) |
Vendor reasons use x- prefix.
10. Addition procedure
A new value is added to a registry by:
- Drafting a PR against this document with the new entry.
- Updating the relevant spec doc to reference the new value.
- Adding a test vector that exercises the new value.
- Review on the maintainer repo with at least one approver from the core set.
- Merging into
main.
Once merged, the value is reserved. Removal of an existing entry requires a deprecation cycle: mark deprecated for one release, then remove in the following major release.
For reserved-but-not-yet-implemented values (e.g. v1.2-planned anchor schemes), the registry entry's status reads v1.2 planned. Implementations MUST NOT emit values still in planned status.
11. References
- RFC 8126 — Guidelines for Writing IANA Considerations Sections (template for this registry)
- RFC 9052, RFC 9053 — COSE registries the DEOS profile inherits from
- RFC 8392 — CWT claim registry the DEOS profile inherits from
- Each spec listed in the tables above contributes the entries it defines
12. Maintainer
DEOS Computing — registry additions, deprecations, and conformance reports to github.com/DEOS-Computing.
License: CC BY 4.0 (text), Apache-2.0 (reference code).