Open OIDF-automation opened 1 year ago
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:
in either way what needs to be defined is how to include 4vp authorization request or input VCs in the VCI request/response.
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.
I think this issue needs more meat. Can you please add descriptions of use cases?
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.
I agree with @{557058:cf344cf5-3085-4fd6-abb3-eaa88b0f0ab9} 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?
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)?
@{557058:cf344cf5-3085-4fd6-abb3-eaa88b0f0ab9} re 1: The UX can be improved by allowing the app developer to control UI elements.
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?
@{557058:cf344cf5-3085-4fd6-abb3-eaa88b0f0ab9} 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:
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
. 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).redirect_uri
(callback). redirect_uri
contains some parameter (path, state) that allows the credential issuer to understand where to proceed in the OpenID4CI flow.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.
SIOP call: sequence diagrams would help to understand why 4vp flow during a VCI flow is a hustle.
this has been brought up multiple times in my conversations with the implementers. there are some use-cases for presentation during issuance where desired behavior is
One proposed solution has been 1. being send as a POST to the issuer's endpoint instead of a redirect. there is a related draft https://datatracker.ietf.org/doc/html/draft-parecki-oauth-first-party-apps-01 in the oauth wg that defines a behavior very similar to the one desired here. (cc @aaronpk)
Another option is:
presentation_required
error and a presentation request (this is the same pattern as requiring a DID-based proof today with invalid_proof
error)No redirection is needed with this approach and it technically could support multiple rounds of requests depending on what is submitted (for more complex flows).
The discussion about this requirement appears to be proceeding on https://github.com/openid/OpenID4VCI/issues/360 I hence suggest we close this issue and continue in #360. If anyone objects please say otherwise we'll close in a week or two.
@dlongley I think using first party apps draft as discussed here is very close to what you are proposing. one difference is probably that 3. will be another authorization challenge endpoint request resulting in 200 and authorization code.
also, I am ok closing this issue - let's continue in #360 or an issue in first party apps GH.
@dlongley chairs can't find a contribution agreement for you or digital bazaar for DCP WG. Could you please sign one, or we cannot incorporate your comments.
@dlongley chairs can't find a contribution agreement for you or digital bazaar for DCP WG. Could you please sign one, or we cannot incorporate your comments.
Done. Please incorporate our comments.
Imported from AB/Connect bitbucket: https://bitbucket.org/openid/connect/issues/1783
Original Reporter: @awoie
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.