I was re-reading the Digital Credentials API's design, privacy, and security considerations, and noticed what looks like a possible mismatch with openid4vp-v1-unsigned.

The spec says, in §11.1:

The Digital Credentials API offers the user agent the ability to intermediate on behalf of the user ... It also enforces certain minimum requirements on supported protocols, such as response encryption.

And in §11.3.1.7:

To prevent exposure of user information to other parties in "transit", for example browser extensions loaded on verifier pages, and to encourage secure storage of user credentials by the verifier, protocols are required to support and mandate encrypted responses in a credential exchange.

However, OpenID4VP over the Digital Credentials API appears to allow openid4vp-v1-unsigned requests to use an unencrypted response.

In particular, OpenID4VP says:

The value of the response_mode parameter MUST be dc_api when the response is not encrypted and dc_api.jwt when the response is encrypted as defined in Section 8.3.

It also gives a non-normative example of an unsigned OpenID4VP request using:

{
  response_type: "vp_token",
  response_mode: "dc_api",
  nonce: "n-0S6_WzA2Mj",
  client_metadata: {...},
  dcql_query: {...}
}

My reading is that unsigned only describes the request, not the response. So openid4vp-v1-unsigned is not inherently a problem.

The problem is that openid4vp-v1-unsigned appears to be usable with response_mode: "dc_api", and OpenID4VP defines that as the unencrypted response mode.

If that reading is correct, then openid4vp-v1-unsigned as currently referenced by the Digital Credentials API seems incompatible with the Digital Credentials API's stated requirement that supported protocols mandate encrypted responses.

Questions:

1. Is it correct that openid4vp-v1-unsigned can be used with response_mode: "dc_api" and therefore produce an unencrypted response?
2. If so, should the Digital Credentials API require OpenID4VP requests to use response_mode: "dc_api.jwt"?
3. Should the Digital Credentials API reject openid4vp-v1-unsigned requests that specify response_mode: "dc_api"?
4. Should the Digital Credentials API define protocol-specific request validation hooks so that a user agent can reject requests that do not meet the API's baseline privacy/security requirements?
5. Should the OpenID4VP DC API profile also make this requirement explicit, perhaps by saying that when OpenID4VP is used through the W3C Digital Credentials API, response_mode MUST be dc_api.jwt?

This may not require dropping openid4vp-v1-unsigned. An unsigned request with an encrypted response may still be acceptable. The concern is specifically allowing response_mode: "dc_api" through the Digital Credentials API.