Last verified: 28 September 2026
Verifiable Credentials Trust Disclosure
The substrate's external VC issuer trust anchor model — how we admit, verify, and revoke external credential authorities.
External trust anchor model
Substrate verifiable credential verification operates in two modes. Internal federation VCs (where iss = urn:sovern:org:<id>) are verified against the federation_keys table — this path is unchanged from Stage 13.1. External VC issuers (regulators, notary CAs, compliance authorities) must be admitted via a substrate-operator-attested 2-of-2 ceremony before any credential they sign can be verified. There is no open-internet JWKS fetching at v1.
Admission is stored in vc_issuer_keys (V017, §ZD-β Phase β-5). The table follows Rule 14 environment fanout — each org × environment pair independently controls which external issuers it trusts.
Locked substrate-shape decisions
Coordinator-ratified at §ZD-β Phase β-5 (2026-05-27). All 7 decisions are BLOCKING-from-day-one; changes require a §ZD amendment.
Decision 1 — Closed admission ceremony only
The substrate verifies VCs ONLY from `iss` values that map to either `federation_keys` (internal, urn:sovern:org: prefix) or `vc_issuer_keys` (admitted external). Any other `iss` → rejected as `unadmitted_issuer`. No open-internet JWKS fetching.
Decision 2 — Per-environment admission (Rule 14 fanout)
`vc_issuer_keys` carries `org_id` + `environment_id` with Rule 14 fanout: enforce_environment_id_matches_org() trigger, restrictive RLS policy, FK to environments(id). Each org × environment pair maintains its own closed set of admitted external issuers.
Decision 3 — Ed25519 / EdDSA / JWK only at v1
Single cryptographic primitive at v1. Admitted external issuer keys must be OKP/Ed25519 JWK. RSA and ECDSA admission are deferred to <horizon:vc-issuer-keys-rsa-ecdsa-admission>.
Decision 4 — Manual 2-of-2 substrate-operator-attested revocation
Revocation requires a 2-of-2 co-sign by distinct substrate-operators (requester ≠ cosigner, DB CHECK-enforced per C-EE-PRE-7). CRL/OCSP automatic revocation fetching is deferred to <horizon:vc-issuer-keys-crl-ocsp>.
Decision 5 — Optional valid_until
Each admitted key row carries an optional `valid_until` timestamp. NULL means no expiration. The verifier rejects credentials when the admitted key's `valid_until < now()` (returns `issuer_expired`) or `status = 'revoked'` (returns `unadmitted_issuer`).
Decision 6 — Audit events with long retention
Two audit event types are registered: `identity.vc_issuer_key.admitted` and `identity.vc_issuer_key.revoked`. Both carry `retentionClass: 'long'` (7 years) — trust anchor admission/revocation decisions are governance-significant records per §ZA-iii G5.
Decision 7 — URI-prefix disambiguation in verifier
The verifier branches on `iss` prefix: `urn:sovern:org:` → existing `federation_keys` lookup path (unchanged). Any other `iss` value → new `vc_issuer_keys` lookup path. Both paths share EdDSA + JWK + JWS-compact wire format. The external-issuer path is ADDITIVE and OPTIONAL — callers must explicitly pass `tenantContext` to VerifyOptions.
Currently admitted external issuers
No external issuers have been admitted yet on this environment. The vc_issuer_keys table is empty pre-launch — substrate ships clean from day one per Rule 16. Admitted issuers will appear here once the substrate-operator admission ceremony is executed for this environment.
Admission ceremony: 2-of-2 co-sign by distinct substrate-operator principals via vcIssuerKeysService.admitIssuerKey(). Revocation ceremony mirrors the same 2-of-2 shape via vcIssuerKeysService.revokeIssuerKey().
Deferred horizons
The following capabilities are explicitly NOT in scope at v1. They are tracked as substrate horizons and require a §ZD amendment to land.
<horizon:vc-issuer-keys-rsa-ecdsa-admission>
RSA and ECDSA public key admission. At v1, only Ed25519 / EdDSA / OKP JWK keys are admitted (locked decision 3). RSA/ECDSA extends the vc_issuer_keys.algorithm / key_type / curve CHECK constraints and the verifier's key-loading logic.
<horizon:vc-issuer-keys-crl-ocsp>
CRL and OCSP automatic revocation checking. At v1, revocation is manual 2-of-2 substrate-operator ceremony (locked decision 4). Automatic revocation status fetching from issuer-published CRL endpoints or OCSP responders is deferred.