feat(core): add device key authorizations to mdoc signing

[Sshovon]

Allow issuers to set MSO deviceKeyInfo.keyAuthorizations via MdocSignOptions and validate that authorized namespaces and data elements exist in the issuance payload.

[changeset-bot]

🦋 Changeset detected

Latest commit: e3d9412

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 18 packages

Name	Type
@credo-ts/core	Patch
@credo-ts/action-menu	Patch
@credo-ts/anoncreds	Patch
@credo-ts/askar-to-drizzle-storage-migration	Patch
@credo-ts/askar	Patch
@credo-ts/cheqd	Patch
@credo-ts/didcomm	Patch
@credo-ts/drizzle-storage	Patch
@credo-ts/drpc	Patch
@credo-ts/hedera	Patch
@credo-ts/indy-vdr	Patch
@credo-ts/node	Patch
@credo-ts/openid4vc	Patch
@credo-ts/question-answer	Patch
@credo-ts/react-native	Patch
@credo-ts/redis-cache	Patch
@credo-ts/tenants	Patch
@credo-ts/webvh	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[TimoGlastra]

Should we incorporate this also on the holder / verifier side? If it's included i think this also influences the other roles.

[Sshovon]

Hey @TimoGlastra, need your opinion on this.

Issuer / holder / verifier behavior for deviceKeyInfo.keyAuthorizations

Per ETSI TS 119 472-2 (EAAP-ISO/IEC-mdoc-03), deviceSigned may include attributes not present in issuerSigned only when the EAA/PID Provider has explicitly authorized them.

Issuer: May optionally set deviceKeyAuthorizations at sign time; credo embeds them in the MSO and omits the field when empty. Key Authorizations may cover issuance namespaces/elements and additional device-only ones (e.g. transaction data) that are not in the issuer-signed payload. Credo does not validate that authorizations match the issuance payload.

Holder: Credo does not enforce keyAuthorizations when creating a device response; that check is left to verifiers. The standard OpenID4VP holder path (DCQL / PEX) only builds responses from disclosed issuer-signed attributes and does not yet expose deviceNameSpaces, so device-only data authorized in the MSO cannot be included via acceptOpenId4VpAuthorizationRequest

Verifier: After cryptographic verification, if the MSO contains non-empty keyAuthorizations, credo checks that both deviceSigned and disclosed issuerSigned namespaces/elements stay within that allowlist. Unauthorized presentation is rejected. If keyAuthorizations is absent or empty, no extra credo checks apply (backward compatible).

This aligns issuer-side authorization (EAAP-03) with verifier-side enforcement, while keeping the holder flexible.

[TimoGlastra]

so device-only data authorized in the MSO cannot be included via acceptOpenId4VpAuthorizationRequest

I think we can easily add this like we did for sd-jwt and transaction data, right? For mdoc we could add a custom deviceNamespaces map that you can provide in the accept call.

[TimoGlastra]

Credo does not enforce keyAuthorizations when creating a device response; that check is left to verifiers

Usually we try to enforce all checks done by a verifier also on the holder side. This ensures you don't share a presentation (containing potential PII) that won't be accepted by the verifier.

Any specific reason you would not want to enforce this check on the holder side?

[Sshovon]

Usually we try to enforce all checks done by a verifier also on the holder side. This ensures you don't share a presentation (containing potential PII) that won't be accepted by the verifier.

in that case we need to add the validation on holder side as well.

I think we can easily add this like we did for sd-jwt and transaction data, right? For mdoc we could add a custom deviceNamespaces map that you can provide in the accept call.

sure..it can be done in this way..

I'll make the requested changes,

[TimoGlastra]

We should add this to DcqlCredentialsForRequest, See the example of additionalPayload for SD-JWT VC. Would that be possible?

[Sshovon]

@TimoGlastra, sorry for the late reply. Following up on your comment to add device-only mdoc data to DcqlCredentialsForRequest, similar to additionalPayload for SD-JWT VC: I'm planning to add an optional deviceNameSpaces field on the mdoc credential entry for both DCQL and PEX, so when the holder accepts a presentation they can provide device-only attributes alongside disclosedPayload on each selected mdoc credential. The holder would typically auto-select credentials first, then set deviceNameSpaces on the relevant mdoc entries before calling accept, same workflow as manually setting additionalPayload on SD-JWT credentials. Credo would pass this through presentation creation into MdocDeviceResponse.createDeviceResponse and validate the requested namespaces and data elements against MSO keyAuthorizations on the holder side before sending, using the same allowlist logic as verifier-side enforcement. For presentations with multiple mdoc credentials, each credential query id (DCQL) or input descriptor id (PEX) would have its own entry in the credentials map with its own deviceNameSpaces, and Credo would create a separate device response per entry.

Does this match what you had in mind, or would you prefer a different shape or location for this field?

Sample code

const credentials = holder.selectCredentialsForDcqlRequest(resolved.dcql.queryResult)

await holder.acceptOpenId4VpAuthorizationRequest({
 authorizationRequestPayload: resolved.authorizationRequestPayload,
 dcql: { credentials },
 mdocDeviceNameSpaces: [{
   credentialId: 'my-mdoc-query-id',
   deviceNameSpaces: {
     'com.foobar-device': { test: 1234 },
   },
 }],
})

Also one more question should I drop PEX and only consider DCQL for this?

[rmlearney-digicatapult]

The PEX/DCQL question is a big one for the future architecture and capabilities of Credo-TS.

There's no reason the query layer needs to be bound to one specific set of capabilities in the credential layer.