Constants, COSE profile and extension policy

1. Protocol version

Field	Value
ssp_version (message envelopes)	1

Signed records do not carry ssp_version; they are versioned by their protected content type, which the signature covers.

2. The SSP/1 COSE profile

SSP/1 uses COSE ([RFC 9052], [RFC 9053]) for every durable signed structure, under a profile deliberately narrower than COSE allows. It is the same shape as the SOVM COSE profile the object plane mandates, restated here so SSP/1 remains implementable standalone.

Rule	Value
Message types	COSE_Sign1 only
Algorithm	EdDSA (Ed25519) only
Payload encoding	Deterministic CBOR ([RFC 8949] section 4.2.1)
kid	The signer’s 16-byte site_id, in the protected bucket
external_aad	The verifier’s own 16-byte mesh_id, on every record — mesh binding without transmission
Unprotected bucket	MUST be empty
Unknown critical headers	Fail closed
Unknown content type	Fail closed
Algorithm agility	None — a second suite is added only for a concrete interoperability need

SSP/1 defines no encryption algorithm because it seals nothing: confidentiality is the transport binding’s responsibility.

This is one family profile, not two. SOP/1’s instantiation adds a single encryption suite (A256GCM COSE_Encrypt0) for its wrapped-key records, and binds richer per-record context in external_aad — storage identity, domain and key generation — where SSP/1 records need only the mesh. The principle is shared: external_aad carries what the verifier must supply rather than trust, so a record replayed outside its context fails signature verification rather than a policy check. The family registry indexes every content type and label across both layers and states the shared conventions once.

3. Registered content types

Durable records are distinguished by protected content type. One content type, one payload schema, one purpose.

Content type	Record	Defined in
sovm/ssp-event-v1	Change event	data model
sovm/ssp-vouch-v1	Vouch certificate	identity
sovm/ssp-role-v1	Role assignment (chained)	scope
sovm/ssp-binding-v1	Transport binding	transport

Admission and removal authorization records use the chained-record schema shared with the object plane; where SOP/1 is deployed its definition (SOP/1 section 5.7) applies unchanged.

4. Raw domain-separation labels

The dividing principle: durable records use COSE content types; transient in-ceremony transcript signatures use raw labels. A transcript signature never outlives its ceremony and is never stored or forwarded, so wrapping it in a COSE envelope would add structure with nothing to protect.

Label	Used in
sovm-mesh-id-v1	mesh_id derivation
sovm-mesh-pair-v1	Pairing transcript

HKDF info strings, scoped by their input key rather than globally:

info	Used in
pair-session	Pairing session key
pair-sas	SAS derivation

5. Enumerations

Space	Values	Reserved
operation	upsert, delete	purge
Pairing method	qr, sas, vouch	—
Policy layer	system, role, user	—
Policy effect	allow, deny	—
Transport mode	batch, realtime	—

There are no encoding, hash or signature tag enumerations: those axes are versioned by content type, and the hash convention is fixed – BLAKE3 over exact signed bytes, the family’s single hash namespace.

6. Extension policy

A new record or a changed payload schema ships as a new content type version (sovm/ssp-event-v2). Because the content type is a protected header, a receiver that does not know it fails closed on the signature path, never by guessing.

Adding a member to a message envelope requires a new ssp_version. There is no ignore-unknown-members rule.

Adding a value to an enumeration requires a new revision of this document. A receiver encountering an unknown value MUST fail closed for that item.

New raw labels MUST be registered here before use. An unregistered label is a latent cross-protocol signature-confusion risk that no automated check can find, since nothing knows to look for it.

Changing any value in this registry is a wire change. It is never a revision of an existing version.

7. Conformance

An implementation claiming SSP/1 conformance MUST:

1. implement every fail-closed behaviour in the inventory;
2. implement the COSE profile above with no extensions;
3. document its floor partition;
4. document its implementation-chosen limits;
5. document its key custody posture per platform;
6. state which transport binding it uses and what that binding provides;
7. state which limitations it has closed locally, if any, and how.

There is no conformance corpus yet. See limitations.