DEOS Profile of SCITT — v1 Specification

Status: v1.1 — drafted 2026-05-04 Spec URI: https://projectmaya.deoscomputing.io/interop/scitt/v1 Maintainer: DEOS Computing (did:web:deos.computing) Profile of: draft-ietf-scitt-architecture-22 Companion API: draft-ietf-scitt-scrapi-06 Receipt envelope: COSE_Sign1 (RFC 9052) Inclusion proof: draft-ietf-cose-merkle-tree-proofs-18 Wire format: CBOR Companion legacy format: JCS-JSON receipts per /receipts/format/v1, valid in parallel for one release

This document specifies the DEOS profile of SCITT: how a DEOS Trust Substrate participates as a SCITT-conformant Transparency Service (TS), how DEOS-specific concepts (UCAN-shaped capability tokens, did:deos issuers, OpenTimestamps anchors, replay-bundle pointers) ride inside the COSE_Sign1 envelope, and which subsetting and extension choices a "DEOS-profile-conformant TS" makes.

This document is normative for v1.1 SCITT-shaped receipts. The pre-existing JCS-JSON receipt format (/receipts/format/v1) remains valid in parallel for one release; v1.2 will deprecate it.

1. Goals

The profile must:

  1. Inherit, not invent. Every credibility primitive that SCITT already specifies (algorithm agility via COSE, IANA registries, RFC 3552 threat-model machinery, transparency-log gossip semantics, Verifiable Data Structures registry) is adopted directly. Where DEOS today carries a bespoke equivalent, the bespoke version is retired.
  2. Preserve all DEOS load-bearing concepts. UCAN-shaped capability chains, did:deos identity derivation, OpenTimestamps anchoring, and replay-bundle pointers all survive — they ride as profile-private CWT claims, not as new top-level fields.
  3. Round-trip cleanly with existing JCS-JSON receipts. A v1.0 JCS-JSON receipt projects to a v1.1 SCITT Transparent Statement and back, losslessly, via the deos-cose-receipt-rs adapter. Existing tooling that consumes v1.0 JSON keeps working until v1.2.
  4. Cross-verify with non-DEOS SCITT implementations. A DEOS-issued Transparent Statement MUST verify against Microsoft scitt-ccf-ledger and DataTrails clients running their public verifiers, modulo the DEOS-private claims those clients don't interpret.
  5. Be implementable from this document alone without reading any DEOS source code, by any party already familiar with SCITT.

The profile explicitly does not:

2. Statement structure

A DEOS Signed Statement is a COSE_Sign1 over a CBOR payload, built per draft-ietf-scitt-architecture-22 §6.

2.1 Protected header (REQUIRED)

Label Name Value
1 alg -8 (EdDSA, RFC 9053 §2.2). v1.1 issuers MUST sign with Ed25519. v2 issuers MAY use -50 (ML-DSA-65) per draft-ietf-cose-dilithium-11 once registered.
3 content type application/deos-receipt-v1+cose (text-form per RFC 9052 §3.1)
4 kid UTF-8 bytes of the issuer key id (DID URL with fragment, e.g. did:deos:user-maya#sig-1). Mutually exclusive with the x5* family below in v1.1; v1.2 may add x5chain for cross-substrate interop (CC-12h).
15 CWT_Claims CBOR map; see §2.3.

Profile-private headers MUST use the negative integer range -65537..-65540 (private use per RFC 9052 §1.4) and MUST NOT collide with future IANA-registered labels.

2.2 Unprotected header

Empty in v1.1. SCITT places the inclusion proof in the Receipt's unprotected header, not the Statement's.

2.3 CWT_Claims map (REQUIRED, label 15)

Mirrors draft-ietf-scitt-architecture-22 §6.11.

CWT label Name Source Notes
1 iss DEOS receipt issuer DID URI, e.g. did:deos:substrate-alpha-1
2 sub DEOS receipt subject Agent DID, e.g. did:deos:agent-maya-2026
6 iat DEOS receipt issued_at (ns → s) Unix seconds; v1 receipts use ns, divide by 10^9 with rounding rules in §3.2
-65537 deos_principal DEOS receipt principal DID; the entity ultimately accountable. Not a SCITT-native concept.
-65538 deos_capability DEOS receipt capability CBOR map: {id, chain, scope}. UCAN-shaped chain is opaque to non-DEOS verifiers; DEOS Registration Policy validates it before admission.
-65539 deos_replay DEOS receipt replay CBOR map: {deterministic, bundle_uri?, bundle_hash?}. Producer-managed in v1.1 per RFV1.1-7 resolution.
-65540 deos_log_meta DEOS receipt log CBOR map: {tree_id, leaf_index, root?}. The substrate's MMR log identity; redundant with the SCITT Receipt's VDS metadata but preserved for v1.0 round-trip.

2.4 Payload (REQUIRED)

A CBOR map representing the action being attested:

deos-action = {
  "type"          : tstr,                 ; per /receipts/format/v1 §6
  "code_hash"     : bstr .size 32,        ; BLAKE3-256
  "inputs_hash"   : bstr .size 32,
  "outputs_hash"  : bstr .size 32,
  "metadata"      : { tstr => any },      ; action-type-specific
}

The DEOS-canonical concept "action" is the SCITT "Statement payload" — it is what the issuer is asserting happened. Hashes are CBOR byte strings (32 raw bytes each), not hex strings, to avoid double-encoding overhead. The legacy v1.0 lowercase-hex strings convert via deos-cose-receipt-rs::project_to_v1_json().

3. Signing

3.1 Sig_structure (RFC 9052 §4.4)

Sig_structure = [
  context: "Signature1",
  body_protected: bstr,        ; encoded protected header
  external_aad: bstr (empty),
  payload: bstr,               ; encoded action map
]

The context is "Signature1" per RFC 9052; the DEOS-specific domain-separation tag "deos-receipt-v1:" is dropped in the SCITT profile. SCITT's COSE structure is itself the domain separator.

3.2 iat derivation from issued_at

DEOS v1.0 receipts carry issued_at in unix nanoseconds. CWT iat is unix seconds. The conversion is:

iat = floor(issued_at_ns / 1_000_000_000)

The full nanosecond precision is preserved separately in the projection back to JCS-JSON, but for SCITT-conformant verifiers, iat is seconds. The profile does not introduce a CWT nbf claim; UCAN tokens carry their own nbf/exp.

4. The Receipt (SCITT)

A SCITT Receipt is a separate COSE_Sign1 emitted by the Transparency Service after registration, per draft-ietf-cose-merkle-tree-proofs-18 §5.2.1.

4.1 Protected header (REQUIRED)

Label Name Value
1 alg -8 (EdDSA); the substrate's signing key, distinct from the issuer's
4 kid substrate DID URL with fragment, e.g. did:deos:substrate-alpha-1#sig-1
395 vds Verifiable Data Structure identifier; see §4.3

4.2 Unprotected header (REQUIRED)

Label Name Value
396 vdp Verifiable Data Proof; for DEOS this is an inclusion proof against the substrate's MMR. Encoded per §4.4.
-65541 deos_anchors CBOR array of OpenTimestamps anchor records, one per OTS calendar configured. Profile-private; non-DEOS verifiers ignore.

4.3 VDS identifier

In v1.1, DEOS substrates use a profile-private VDS identifier -65542 denoting "DEOS-MMR-SHA256". This is documented here pending standardization.

The standardization path (CC-12f) is to revive draft-bryce-cose-merkle-mountain-range-proofs (currently expired individual draft, May 2025) and co-author the registration with Robin Bryce at DataTrails so that v1.2 can use a real IANA-assigned MMR VDS identifier.

Substrates MUST NOT use 1 (RFC9162_SHA256) unless they actually maintain an RFC 9162 binary tree; the DEOS log is post-order MMR and disagreements on the underlying structure produce silent verification failures.

4.4 Inclusion-proof encoding (vdp)

The DEOS post-order MMR inclusion proof maps to the cose-merkle-tree-proofs §5.2.1 inclusion-proof shape as:

deos-inclusion-proof = {
  -1: uint,                    ; leaf-index (0-based)
  -2: uint,                    ; leaf-count
  -3: [* bstr],                ; siblings (hash path to peak)
  -4: [* bstr],                ; bag_peaks_left
  -5: [* bstr],                ; bag_peaks_right
}

The four arrays match the structure documented in /merkle/log/v1. All hashes are 32 raw bytes (SHA-256 of the leaf sub-tree, see §5.1).

4.5 Payload

The Receipt's payload is the SHA-256 hash of the registered Statement's encoded COSE_Sign1 bytes. This is consistent with cose-merkle-tree-proofs §3.2.

5. Dual-hash strategy

DEOS v1.0 uses BLAKE3-256 as its hash function throughout. SCITT/COSE Receipts mandate SHA-256 (no algorithm-agile hash field exists in cose-merkle-tree-proofs as of -18). The profile adopts a dual-hash scheme so we don't lose BLAKE3's content-addressing properties:

5.1 SCITT-facing hash: SHA-256

5.2 DEOS-internal hash: BLAKE3-256

5.3 Standardization path

CC-12g requests a BLAKE3-in-COSE registration with the COSE WG. Once a BLAKE3-256 algorithm is registered and a matching VDS hash-agility extension lands, v1.2 substrates MAY swap the SCITT-facing hash to BLAKE3 and drop the dual computation. Until then, the cost is one extra SHA-256 per leaf — negligible.

6. Transparency Service (DEOS substrate as TS)

A DEOS substrate is a SCRAPI-conformant Transparency Service per draft-ietf-scitt-scrapi-06.

6.1 SCRAPI endpoints (REQUIRED)

Method Path Purpose
GET /.well-known/scitt-keys TS verifying-key set as a COSE Key Set (RFC 9052 §7). Body is application/cose-key-set+cbor.
GET /.well-known/scitt-keys/{kid} Single TS verifying key.
POST /entries Register a Signed Statement. Body: application/cose. Returns 201 (sync) or 303 → /entries/{operation_id} (async).
GET /entries/{operation_id} Poll asynchronous registration.
GET /entries/{entry_id} Retrieve a persisted Receipt. Body: application/cose.

6.2 Legacy v1 endpoints (PRESERVED)

The pre-SCITT endpoints in /attestation/api/v1 (/attestation/v1/*) remain available in parallel for one release. They emit JCS-JSON receipts. Internally, the substrate runs the same MMR; the two endpoint families are two views over the same log.

6.3 Registration Policy

draft-ietf-scitt-architecture-22 §5.1.1.1 requires a Transparency Service to authenticate Signed Statements via a documented Registration Policy. The DEOS profile defines:

  1. Issuer authentication. The kid in the Statement's protected header MUST resolve to a public key via:
    • The DEOS DID resolver (did:deos chain), if it returns a key for the kid; OR
    • The hybrid resolver's web fallback (did:web), if configured; OR
    • The substrate's pre-registered allow-list of issuer DIDs (production deployments).
  2. Signature verification. COSE_Sign1 over Sig_structure MUST verify with the resolved public key under alg.
  3. Capability-chain admission (DEOS-specific). The deos_capability.chain (CWT label -65538) MUST be a non-empty UCAN-v1.0-shaped chain that:
    • Has chain[0].iss == deos_principal and chain[last].aud == sub.
    • Validates per /ucan/tokens/v1 §4 (per-token signatures, continuity, time bounds, attenuation narrowing, caveat satisfaction against the action payload).
    • Has no token in the substrate's revocation log at-or-before iat.
  4. Tree id check. The deos_log_meta.tree_id (CWT label -65540) MUST equal the substrate's configured tree id, per /receipts/format/v1 §2.1.
  5. Capability id check. The deos_capability.id MUST equal BLAKE3-256(canonicalize(deos_capability.chain[0])) per /receipts/format/v1 §5.4.

A DEOS substrate that fails any of (1)–(5) MUST reject the registration with HTTP 400 and a SCITT-conformant cwt_claims error (per SCRAPI §3.2 error format). Non-DEOS SCITT TSs that lack the UCAN/DID layer SHOULD register the Statement on signature/issuer trust alone (rules 1 + 2); the DEOS-specific rules (3–5) are profile-private admission control.

7. Transparent Statement

Per architecture §7, a Transparent Statement is the original Signed Statement with the Receipt embedded in its unprotected header under label 394 (receipt). DEOS profile binding:

deos-transparent-statement = COSE_Sign1 {
  protected   : <as §2.1>,
  unprotected : { 394 : COSE_Sign1 (the Receipt, §4) },
  payload     : <as §2.4>,
  signature   : bstr,
}

This is the artifact a DEOS verifier hands to a third party. It contains everything needed for offline verification: issuer signature, substrate signature, inclusion proof, OTS anchors. The full UCAN chain rides inside deos_capability for DEOS-aware verifiers; non-DEOS verifiers see only the SCITT-conformant outer shell and verify what they can.

8. JSON projection (legacy interop)

The deos-cose-receipt-rs::project_to_v1_json() function losslessly converts a Transparent Statement to a JCS-JSON v1.0 receipt. The mapping is field-by-field per §2.3 plus the inverse of §3.2 (multiplying iat back to nanoseconds requires either fetching the original issued_at_ns from a profile-private extension or accepting one-second precision loss for receipts that don't preserve ns).

To round-trip ns precision losslessly, v1.1 issuers SHOULD include a profile-private claim -65543 = deos_issued_at_ns carrying the full nanosecond value as a CBOR uint. v1.0 → v1.1 conversions populate this; v1.1 → v1.0 conversions read it.

9. Conformance

A "DEOS profile of SCITT" implementation MUST:

  1. Conform to draft-ietf-scitt-architecture-22 §6 (Statement structure) for issuer-side code.
  2. Conform to draft-ietf-scitt-scrapi-06 §2 (the SCRAPI endpoints listed in §6.1) for substrate-side code.
  3. Conform to draft-ietf-cose-merkle-tree-proofs-18 §5.2 (Receipt structure) for both sides.
  4. Implement the dual-hash scheme of §5.
  5. Implement the Registration Policy of §6.3 in the substrate.
  6. Round-trip cleanly to and from JCS-JSON v1.0 receipts via §8.
  7. Verify against the conformance test-vector suite (CC-6) which covers: Statement build/sign/verify, Receipt issuance, full Transparent Statement verification, JSON projection round-trip, mis-canonicalization rejection, mis-issuance rejection, capability-chain rejection, tree-id mismatch rejection, capability-id mismatch rejection.

A DEOS substrate is not required to also implement the SCITT CCF profile (draft-ietf-scitt-receipts-ccf-profile) and SHOULD NOT do so until the IPR situation around patent 18/260763 is resolved (CC-12i).

10. Security considerations

This section satisfies the RFC 3552 requirement and supplements draft-ietf-scitt-architecture-22 §10.

10.1 Threat model summary (STRIDE)

Inherited verbatim from architecture §10–§12, plus the following DEOS-specific deltas.

10.2 DEOS-specific threats

10.3 Algorithm agility

alg is a COSE-registered identifier; v1.1 issuers use -8 (EdDSA). Migration to ML-DSA-65 is a one-field change at the issuer (alg = -50) with no protocol or wire-format break. The dual-hash scheme of §5 isolates BLAKE3 (DEOS-internal) from the SCITT-facing SHA-256 so that future hash agility (BLAKE3-in-COSE registration, CC-12g) likewise lands as a single VDS-identifier swap, not a wire-format break.

10.4 Privacy considerations

11. IANA considerations

This profile uses CBOR labels in the private use range (negative integers below -65536) for DEOS-specific extensions. The labels chosen are:

Label Name Where
-65537 deos_principal Statement protected header CWT_Claims
-65538 deos_capability Statement protected header CWT_Claims
-65539 deos_replay Statement protected header CWT_Claims
-65540 deos_log_meta Statement protected header CWT_Claims
-65541 deos_anchors Receipt unprotected header
-65542 DEOS-MMR-SHA256 VDS vds (label 395) value, until standardized via CC-12f
-65543 deos_issued_at_ns optional profile-private claim for ns precision

Should any of these be standardized in the future, this profile will rev to use the IANA-assigned labels and treat the private-use values as deprecated aliases for one release.

12. References

Normative

Informative

13. Open questions for v1.2

These do not block v1.1 ship.