[has-PR] Do not limit Dynamic Credential Requests to OpenID4VP

[Thomas Bellebaum]

From the current spec:

The Issuer MUST utilize [@OpenID4VP] to dynamically request additional Credential Presentations

From RFC 2119 (Defining “MUST”):

Imperatives of the type defined in this memo must be used with care

and sparingly. In particular, they MUST only be used where it is

actually required for interoperation or to limit behavior which has

potential for causing harm (e.g., limiting retransmisssions) For

example, they must not be used to try to impose a particular method

on implementors where the method is not required for

interoperability.

It is unclear to me why exactly any presentations must be exchanged using OpenID4VP, and why other protocols may not be used. The only interaction with OpenID4VCI are the wallet_issuer and user_hint request parameters, which exist exclusively to support OpenID4VP. As long as other protocols for presentation exchanges can be employed, this should be possible.

As a potential use-case: Assume I have several wallets on my phone, into one of which I would like to import my university diploma. To retrieve it however, I need to present my state id card, which uses its own wallet (for whatever reasons) and does not even use OpenID4VP, but its own custom protocol.

[Kristina Yasuda]

what would be the options for “other protocols“? do you mean proprietary protocols?

using OpenID4VP to do presentation of a VP during presentation/issuance does not work for our implementation because we use webview and redirecting the user to other wallets from there is not a good user experience.

So I agree limiting a mechanism only to OpenID4VP is very limiting, but from interoperability perspective, I am also hesitant to say implementations are free to do anything they want to present VPs during issuance/presentation. If not OpenID4VP, we should define an additional mechanism within OpenID4VP.

[Michael Jones]

I believe that Thomas is technically right that the “MUST” is overreaching. Specs can only define behaviors for conforming implementations. There’s nothing useful to say in the spec about implementations that do things outside what’s specified.

I’d suggest changing “The Issuer MUST utilize“ to “The Issuer uses” or “The Issuer can use”.

[Kristina Yasuda]

PR #291

[Kristina Yasuda]

PR merged