Credential proof format: VC-JOSE (JWT) with Ed25519, Data Integrity later

Status: accepted

ADR-0015 fixed issuer granularity, custody, and discovery (HTTPS issuer URIs with JWKS endpoints) but left the proof mechanism open. Whatever the first signed Open Badges 3.0 export uses is what external verifiers get built against, so the choice is effectively irreversible once credentials circulate.

Decision

• External JOSE proofs (VC-JWT) are the first and, for now, only proof format for OB 3.0 / CLR 2.0 / VC-DM 2.0 exports: a compact JWS over the credential, alg: EdDSA.
• Signing keys are Ed25519. One algorithm across every issuer profile; key material lives in the platform KMS per ADR-0015.
• Verification is JWKS-first, via the per-issuer JWKS endpoints ADR-0015 already mandates — JOSE is the proof family JWKS discovery natively serves.
• Embedded Data Integrity proofs (eddsa-rdfc-2022) are deferred, additive. They can be introduced later as a second proof format on newly issued credentials without re-issuing existing ones.

Considered and rejected (for v1)

• Data Integrity first. Requires RDFC-1.0 canonicalization — a significant complexity and security surface (graph canonicalization bugs are signature bypass bugs) — and fits JWKS discovery awkwardly. Its real draw (selective disclosure via BBS) is not a v1 requirement.
• Both formats from day one. Roughly doubles implementation and conformance surface before the first credential ships, for verifier reach we do not yet need.
• RSA keys. Larger keys/signatures, slower, no benefit over Ed25519 for a greenfield issuer; EdDSA is well supported across JOSE verifier stacks.

Consequences

• The KMS must support Ed25519 signing (constrains the concrete KMS choice left open by ADR-0015).
• The export assembler produces application/vc+jwt-style compact JWS artifacts; no RDF canonicalization code enters the platform in v1.
• Adding Data Integrity later is a new proof emitter plus conformance coverage, not a re-issuance event.