Identity, trust and MLS

5. Identity, Trust, and MLS

5.1. SSP remains the identity and policy authority

MLS is not the SOVM trust model.

SSP continues to define:

• site_id;
• node root identity;
• pairing ceremony;
• human confirmation;
• vouching policy;
• node role;
• table/domain scope;
• revocation intent.

An MLS membership change MUST be authorized by SSP policy before it is merged.

5.2. Node root identity

The preferred node root remains an Ed25519 identity key whose private key is non-extractable where the platform allows secure hardware-backed signing.

The SSP site_id remains the stable node identifier.

5.3. MLS credential binding

An MLS leaf credential and signature key MUST be cryptographically bound to the corresponding SSP node identity.

OpenMLS currently supports BasicCredential, for which the identity-to-key meaning is application-defined. SOVM MUST therefore define and verify that binding rather than assuming OpenMLS provides it.

A preferred design is:

flowchart LR
  accTitle: What the SSP root identity key anchors
  accDescr: The SSP identity public key both derives the stable site identifier and signs the MLS credential binding.
  ik["SSP IK_pub"] --> site[site_id]
  ik --> binding[signs MLS credential binding]

The binding transcript SHOULD include at least:

protocol label
mesh_id
site_id
MLS credential identity
MLS signature public key
credential generation
validity information

The binding transcript is decided. It is deterministic CBOR signed with COSE_Sign1 under the SSP root identity key:

{
    binding_version,
    protocol_label = "sovm-mls-credential-binding-v1",
    mesh_id,
    site_id,
    mls_credential_identity,
    mls_signature_pubkey,
    mls_ciphersuite,
    credential_generation
}

Supersession and revocation use the monotonic credential_generation, not wall-clock validity windows, consistent with Section 9.5’s rejection of untrusted timestamps. The ciphersuite is bound to prevent cross-suite substitution. The signed binding is embedded in the BasicCredential identity field so KeyPackages are self-verifying.

Credential strategy is likewise decided: a node uses one SSP-bound credential reused across all SOVM groups. In a single-user fleet the delivery service already links node to group through routing and KeyPackage delivery, so per-group pseudonymous credentials would add binding-record and KeyPackage overhead without a corresponding privacy gain. Per-group leaf keypairs remain fresh as provided by MLS, which preserves the blast-radius property that matters. Pseudonymous per-group credentials are revisited only if multi-user meshes are introduced.

5.4. Hardware signing integration

The OpenMLS integration SHOULD implement or adapt the library signing interface such that long-lived SSP identity signatures can be produced by Secure Enclave, Android Keystore/StrongBox, TPM, or an equivalent protected keystore where available.

A software-only production fallback MUST be an explicit policy decision and MUST NOT occur silently.

5.5. Admission

A node joins cryptographic groups only after SSP admission succeeds.

Conceptually:

flowchart TD
  accTitle: Node admission sequence
  accDescr: Pairing, vouching policy and human confirmation together produce an SSP admission approval, which is what permits an MLS Add and Welcome.
  pairing[pairing / QR / SAS] --> approved[SSP admission approved]
  vouch[vouching policy] --> approved
  human[human confirmation] --> approved
  approved --> add[MLS Add / Welcome]

5.6. Removal

A node removal is:

flowchart TD
  accTitle: Node removal sequence
  accDescr: A policy decision removes the node from the trusted keyring, which drives an MLS Remove and Commit, a new MLS epoch, and finally a new application domain key generation the removed node never receives.
  decision[user / SSP policy] --> keyring[remove from trusted SSP keyring]
  keyring --> commit[MLS Remove + Commit]
  commit --> epoch[new MLS epoch]
  epoch --> kek[new application domain KEK generation]

The removed member MUST NOT receive secrets for the new epoch.

5.7. Membership authorization artifacts

Membership Commits are authorized by portable signed artifacts, not by local SSP-policy freshness.

Every Add or Remove Commit MUST reference a COSE-signed SSP authorization record produced by the node that executed the corresponding admission or removal ceremony, chained to the trusted SSP keyring, and carrying a monotonic authorization generation.

Authorization records are hash-chained: a monotonic generation alone permits two authorized nodes to independently mint conflicting next-generation records, with only the winning MLS Commit distinguishing them. Each record therefore binds its predecessor explicitly:

{
    mesh_id,
    authorization_generation,
    previous_authorization_state_hash,
    operation_id,
    operation = ADD | REMOVE,
    target_site_id,
    opaque_domain_id,
    vouch_evidence
}

The sequenced Commit still selects which record takes effect; the chain makes a losing or conflicting record independently visible and the SSP authorization history auditable on its own, rather than only through whichever MLS Commit happened to win. A node observing two records claiming the same predecessor MUST surface the conflict.

This chained-record schema is shared with sequencing receipts (Section 22.5) in the SOVM COSE profile.

Validation of a Commit is therefore self-contained: a member verifies the signature chain and generation monotonicity without requiring that its local SSP policy replica has already converged. This removes the ordering dependency in which a node that has not yet replicated a policy update would fail-closed reject a legitimate Commit and create an availability failure indistinguishable from an attack.

Local SSP policy remains authoritative for detecting and resolving conflicts after the fact; a node that later observes contradictory policy state MUST surface the conflict rather than silently reconcile it.