dpp-crypto: DppAccessCredential has no proof member — access credentials cannot be signed

[LKSNDRTMLKV]

What

DppAccessCredential (crates/dpp-crypto/src/access/credential/types.rs) carries no proof and no jws field:

pub struct DppAccessCredential {
    pub context: Vec<String>,
    pub credential_type: Vec<String>,
    pub id: String,
    pub issuer: String,
    pub valid_from: DateTime<Utc>,
    pub valid_until: DateTime<Utc>,
    pub credential_subject: DppCredentialSubject,
    pub credential_status: Option<CredentialStatus>,
}

CredentialBuilder::build() returns one of these, unsigned. SignedCredential exists in dpp-domain::identity but wraps PassportCredential — it attests a passport, not an access role.

So there is no signed representation of an access credential anywhere in the workspace. The issuer field is a self-asserted string.

Why this is load-bearing

The verification stack around it is otherwise complete and reads as authoritative:

• verify_credential_claims — structure and validity window
• verify_credential_claims_with_trust — is this issuer trusted for this audience
• check_revocation — status-list bit
• CredentialRole::audience() — the Art. 77(2) mapping

Every one of those operates on an unauthenticated document. verify_credential_claims is honest about it ("no signature check — that is the JWS verifier's responsibility"), but the trust check in particular is misleading in effect: it asks whether issuer is trusted, and anyone can put any DID in issuer. Trust checking without signature verification is decorative.

What is needed

A decision on the signed envelope, then the type to carry it. Two shapes, both standard:

1. VC-JWT — the credential JSON is the payload of a compact JWS, and the wire format is that JWS. Nothing changes in DppAccessCredential; the envelope is external and the engine unwraps it.
2. Embedded proof — add a proof member (W3C Data Integrity), so the credential is self-contained.

(1) composes better with dpp_crypto::jws::verify_jws, which already exists and takes (jws, public_key_b64). Either way the verifier needs the issuer's public key, which means resolving the issuer did:web — dpp-resolver already does DID-document fetching for passports, so the mechanism exists but is not reachable from dpp-crypto.

Impact

Blocks the audience-access campaign at the point where a credential must actually grant something (dpp-docs/work/AUDIENCE-ACCESS-PLAN.md chunk 04). Chunks that can proceed regardless: trusted-issuer configuration and revocation wiring, both of which are policy layers that will sit on top of whatever envelope is chosen.

dpp-engine#60 implements the transport and deliberately injects a PresentedCredential rather than an Audience, precisely because the document it parses is unauthenticated.

Suggested

Do not add a proof field speculatively. Pick the envelope first — VC-JWT is the lower-friction option given verify_jws — and record it, because it is a wire-format decision that binds every future issuer.

[LKSNDRTMLKV]

Decision recorded: VC-JWT, not embedded proof.

DppAccessCredential stays exactly as it is in this repo — no proof/jws member added. The envelope is external: the credential JSON is signed as the payload of a compact JWS, reusing the verification path already in dpp-crypto (extract_kid_from_jws → issuer DID document → extract_key_by_fingerprint → verify_jws), one canonicalisation scheme (JCS) rather than two.

Chosen over embedded Data Integrity proof because:

• it composes directly with the existing dpp_crypto::jws verifier instead of adding a second signing/canonicalisation scheme to the most security-sensitive code in the workspace
• EN 18246 is unread and the ESPR Art. 11 credential implementing acts are unadopted, so only the unwrap step is likely to need revisiting later, not the credential shape itself

Implementation lives in dpp-engine #63 (feat/credential-signature-verification), which authenticates the X-DPP-Credential header this way before handing the decoded credential to this repo's verify_credential_with_revocation_and_trust. That PR is currently CI-red because it depends on Passport::disclosure_signatures (#70, not yet published) — it should go green once 0.12.0 ships and dpp-engine repins to it.

Leaving this open until #63 merges, since that's what actually makes an access credential signable end-to-end; this comment is the record the original write-up asked for.

[LKSNDRTMLKV]

Checked against the code: DppAccessCredential still has no proof member, and per the decision recorded when this was raised that is deliberate — the proof is external to the envelope (VC-JWT), so no type in this crate needs one.

So there is nothing to build here. What keeps it open is confirmation from the consumer side that the external-proof path actually works end to end; until that lands, closing this would assert something unverified.