Add a standard way to request additional evidence based on OpenID4VP during OpenID4CI credential issuance

[Oliver Terbu]

Currently, there is no standardized way to request credentials or other information from the user during the issuance process. How this can be achieved today is during the authorization step which the issuer orchestrates. The issuer may request additional information through OpenID4VP as part of the authorization step which requires a system browser or an internal browser for native apps. To have a native UI experience especially for native apps it would be beneficial to provide a OpenID4VP request either in the token or credential response in case additional credentials are required for issuance.

[Kristina Yasuda]

To add a little color..

so far the spec says OpenID4VP should be used if presentation of VCs is required during the Issuance process using OpenID4VCI. We have looked into this option with our engineers and it does not seem ideal from the user experience and session management perspective - openid4vp authz req will require an internal web view or the system browser opening in the wallet after receiving openid4vci authz response:

two options to improve the experience:

1. Issuer will pass openid4vp authorization request in the openid4vci authorization response asking to present a certain VC.
2. issuer publishes in the credential issuer metadata that it requires VC(s) of which type/format to be presented in order to issue certain VCs, so the wallet can send a that VC in an authorization/token request of VCI.

in either way what needs to be defined is how to include 4vp authorization request or input VCs in the VCI request/response.

‌

[Torsten Lodderstedt]

to 1: why is that better in terms of UX? How is the issuer able to complete the authorization process without the request credential?

to 2: possible, however that is a static configuration - there is no way to determine what is needed for a certain user and sub-sequently request it. Sending the credential in the token request means that the grant is split - the authz code or pre-authz code somehow authorizes (what?) and the credential complements it.

[Torsten Lodderstedt]

I think this issue needs more meat. Can you please add descriptions of use cases?

[Oliver Terbu]

As a developer, I want to integrate issuer services to retrieve VCs from that issuer that require the presentation of other credentials (e.g., W3C VCs, ISO mdocs etc.), so that I can provide a native user experience to my end users without requiring a system browser, or internal browser in my mobile app, or proprietary issuer SDK.

[Oliver Terbu]

I agree with @Torsten Lodderstedt that option 2 has the downside that a static configuration is quite limited. I was thinking whether we could use https://datatracker.ietf.org/doc/draft-ietf-oauth-step-up-authn-challenge/ in the credentials endpoint to request additional VCs but I haven’t fully thought that through. Any thoughts?

[Torsten Lodderstedt]

That is basically what the description already states, right?

Can you give a concrete example of such a flow (what credentials) and how you would envision it to work? Perhaps you could also answer my questions further up (to 1 and 2)?

[Oliver Terbu]

@Torsten Lodderstedt re 1: The UX can be improved by allowing the app developer to control UI elements.

[Oliver Terbu]

Another thought I had is that if we solve this we would also make OpenID4CI more accessible to IOT/smart device developers. What would be the strategy for IOT or smart device developers to integrate OpenID4CI into their application?

[Oliver Terbu]

@Torsten Lodderstedt regarding concrete example…

Can you give a concrete example of such a flow (what credentials) and how you would envision it to work?

After reading the section on Dynamic Credential Request again, I believe the wallet_issuer parameter might achieve already what I had in my mind but it is too complicated at the moment.

Imagine the following:

1. Wallet generates OpenID4CI authz request and includes the wallet_issuer URL in case the credential issuer has to request additional VCs to issue the credential. The wallet also includes their client_metadata credential_offer_endpoint.
2. Wallet sends the OpenID4CI authz request to the credential issuer’s authz endpoint.
3. Credential issuer verifies the OpenID4CI authz request and requires additional VCs from the user. Credential issuer fetches config from wallet_issuer and generates OpenID4VP authz request corresponding to wallet_issuer config to request additional VCs from the user. Credential issuer generates authz response which is a OpenID4VP 302 redirect (to wallet).
4. Wallet receives the 302 redirect with the OpenID4VP authz request.
5. Wallet asks the user to give consent.
6. Wallet generates the OpenID4VP response and sends the response to the redirect_uri (callback).
7. Credential issuer receives OpenId4VP response whereas redirect_uri contains some parameter (path, state) that allows the credential issuer to understand where to proceed in the OpenID4CI flow.
8. Credential issuer verifies OpenID4VP response and generates 302 with OpenID4CI Credential Offer with pre-authz code.
9. Wallet goes to OpenID4CI token endpoint with pre-authz code which results in an access_token for the credential endpoint where the wallet can get the final VC.

While the above flow can be done, it is very convoluted since it requires two 302 redirects.

By introducing a dedicated error response in the authorization error response that contains the OpenID4VP request, the process could be much simpler by removing the two 302 redirects. IMO, this would also help with interop.

I would also feel more comfortable if we could tie the initial authz request in step 1. together with the token request in step 9, e.g., through PKCE, which could be done if the OpenID4VP request would be more integrated in OpenID4CI.

‌

[Kristina Yasuda]

SIOP call: sequence diagrams would help to understand why 4vp flow during a VCI flow is a hustle.

[Mark Haine]

Migrated to GitHub

https://github.com/openid/OpenID4VCI