RFC-0006: Identity Model

Status: Last Call · Date: 2026-07-17 · Editors: Untilum project — hello@untilum.com

Part of the TSP RFC series; see the series index for the Last Call window and how to comment. The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY in this document are to be interpreted as described in BCP 14 [RFC 2119] [RFC 8174] when, and only when, they appear in all capitals.

Abstract

This document defines the optional creator-identity layer of the Untilum Protocol. A creator signature answers “who sealed this?” and is never a factor in decryption. It specifies the canonically signed message and its domain separation, the exclusion of mutable zones from the signature, the signing-provider contract, and the algorithm registry (Ed25519 specified and implemented; WebAuthn planned), together with what identity deliberately does not cover.

1. Principle

Identity answers “who sealed this?” — and nothing else. It is optional and orthogonal to opening: a creator signature is never a factor in decryption (G3 has exactly two factors, and identity is not one of them), and an unsigned capsule is a fully valid capsule. Identity exists for verifiers and counterparties, not for the lock.

2. The signed message

A creator signature covers the canonical form of the capsule’s immutable fields:

message = UTF8("untilum-v2-creator-sig")
        || SHA-256(canonicalJson(pick(capsule, signedFields)))

(Normative definition: tsp-v1.md §10.1.2.)

Three load-bearing choices:

• Canonical JSON (sorted keys, no insignificant whitespace, integers only) — a signature over a raw serialization would break on any re-serialization; canonicalization makes the signature a property of the document, not of one byte stream.
• Domain separation — the fixed prefix ensures a capsule signature cannot be replayed as any other statement signed by the same key, and vice versa.
• Mutable-zone exclusion — signedFields MUST include the immutable core (v, kind, alg, salt, payload, unlock), SHOULD include metaEnc when present, and MUST NOT include creator (circular), storage, or proofs (appendable by design, RFC-0004 §R3). A signature that covered the storage list would freeze it, defeating lifetime replication.

3. Provider contract

type          — algorithm family
publicKey()   — public key, embeddable in the capsule
sign(message) — signature; the private key never leaves the provider

The private key MUST NOT be exported, logged, serialized into any document, or observable by other layers. Verification MUST be pure — no network, no secrets — and MUST distinguish “no identity claimed” from “identity claimed and invalid” (RFC-0007’s skipped-vs-fail rule).

4. Algorithm registry

type	Status	Notes
ed25519	Specified, implemented	Raw keypair (audited @noble/curves); works everywhere — CLI, backend, mobile — with no platform binding
webauthn	Planned	FIDO2 assertion with challenge = capsuleHash; hardware-backed, phishing-resistant, keys never leave the authenticator. Requires its own RFC before validators accept it

Unknown identity types follow the fail-closed rule: a verifier that cannot check a claim reports it unverifiable — it does not pass it.

5. Out of scope

Binding a key to a person (DNS, DID, PGP web-of-trust, attestation certificates) layers above the protocol. TSP proves this key signed this capsule; who holds the key is someone else’s protocol. Key rotation is likewise out of scope by design — a capsule is signed once, at sealing, and the signature is a historical fact, not a live credential.

6. Security Considerations

A creator signature is attribution evidence, never an access factor — implementations MUST NOT let identity strengthen or replace either opening factor (G3). Signing reveals authorship: the protocol offers no anonymity (RFC-0001 §3), and applications SHOULD say so where a signature is optional. Domain separation (§2) is what prevents a capsule signature from being replayed as any other statement by the same key; the mutable-zone exclusion is what keeps lifetime storage replication from invalidating signatures. The private-key handling rules in §3 are absolute: a provider that logs, serializes, or exports the key does not conform.

7. References

7.1. Normative

• [RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.
• [RFC8174] Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, May 2017.
• [TSP-V1] “Untilum Protocol (TSP) — Version 1”, ../spec/tsp-v1.md — §10.1.2 normative signed-message definition.

7.2. Informative

• RFC-0007 Verification Model — this series.
• [RFC8032] Josefsson, S., Liusvaara, I., “Edwards-Curve Digital Signature Algorithm (EdDSA)”, RFC 8032, January 2017.
• W3C, “Web Authentication: An API for accessing Public Key Credentials” (WebAuthn): https://www.w3.org/TR/webauthn-2/

Editors’ Addresses

Untilum project — Editors of the TSP RFC series Email: hello@untilum.com · Issues: https://github.com/untilum/protocol/issues

Revision History

Date	Status	Change
2026-07-07	Draft	Initial version.
2026-07-17	Last Call	Publication pass: BCP 14 boilerplate, Abstract, Security Considerations, References, Revision History added; no normative changes. Entered Last Call per RFC-0008 §4.