[oidc4vci] Proposal: Move custom presentation exchange logic to a different spec

[Jeremie Miller]

In the current draft, before issuance if there are required presentations they are performed during and as part of the authorization flow. This is challenging, for example the discussion in #1443, and requires additional complexity around managing sessions with multiple possible presentations before or during authorization as well as deep integration with the authorization endpoint to support this complexity.

I believe this should be handled in its own specification as it deals entirely with presentation exchange and not issuance. The credential issuance specification should cleanly and clearly document how to have a credential issued within an OpenID Connect context.

Deployments may have more complex use-cases where credential presentation is required before issuance and they are perfectly valid, but I believe the specifications for those flows should be either part of the OIDC4VP or a separate draft as they relate entirely to the complexity of presentation exchange and are not documenting the act of issuance.

[Kristina Yasuda]

An option to present presentations in the request to the Issuance API (ie after authorization) has been discussed, and then we kept a design to present presentations during/as part of the authorization flow to enable identification/authentication of the user based on those presentations.

That was to explain the current logic, and having said that, I understand complexity around managing sessions when OIDC4VP flow is nested within OIDC4VCI flow.

After the client has an access token, it can then optionally interact with a presentation service to satisfy any additional requirements.

In the presentation request, the Issuer would act as an RP requesting VPs from the client-wallet (can beSIOP) Could you please elaborate how is access token from the Issuer would be used?

[Tom Jones]

I never understood the idea of PE inside of OIDC from the beginning. This should be called a Turduckin protocol with oidc4vp wrapping odic4vp wrapping didcom wrapping pe wrapping vc. If the wallet has to enable didcom anyway, what’s the point of all this?

[Jeremie Miller]

and then we kept a design to present presentations during/as part of the authorization flow to enable identification/authentication of the user based on those presentations.

Why is that in scope for a Credential Issuance draft? That use-case is completely independent and purely an application of Verifiable Presentations as a form of identification or recovery prior to an authorization flow.

In the presentation request, the Issuer would act as an RP requesting VPs from the client-wallet (can beSIOP)

I’m uncomfortable burdening such VP requirement complexity in a VCI spec which only needs to define how to use OIDC for issuance. Presentations should be an independent spec that can be used as needed by an implementor in conjunction with issuance.

Could you please elaborate how is access token from the Issuer would be used?

If the issuer is performing a presentation request in response to an issuance request (or any other request), when such an exchange happens after authorization the issuer has the ability to address and secure the presentation exchange since the holder will have a client_id and requests from the holder will be authorized through an access_token.

[Kristina Yasuda]

using VPs as authentication/identification required certain additions to the request that needed to be standardized. maybe it should have been a separate spec, but we added in the issuance draft because this application of the VPs would not have been possible.

presentation is an independent spec, issuance draft would just has a note that OIDC4VP flow can be nested inside OIDC4VCI flow whether during authorization or issuance requests - as we decide.

Which part of the “presentation request in response to an issuance request“ does the holder authorize through an access_token if it is the issuer who sends a presentation request? I am sorry I am definitely missing something.

[Jeremie Miller]

we added in the issuance draft because this application of the VPs would not have been possible.

I believe VPs as part of the auth process is a valid use case on its own and having nothing to do with issuance. It does not require or depend on issuance, and may independently be combined with issuance but also may only be used for authorization.

issuance draft would just has a note that OIDC4VP flow can be nested inside OIDC4VCI flow whether during authorization or issuance requests - as we decide.

If VP for authorization is documented elsewhere then it would be a simple note. I believe documenting it with normative language is much more complex than being just a note, and it deserves its own well-defined place fully decoupled from issuance.

[Kristina Yasuda]

2022-Mar-14 Connect call, agreed that PR #134 addresses this issue

[Kristina Yasuda]

Resolved by merging PR #134 and PR #138