Presentation during Issuance

[danielfett]

There is currently no sufficient guidance provided for doing a presentation of a credential during the issuance of another credential. In particular, there are specific advantages using the OAuth for First-Party Applications draft for this.

Here's our proposal from the German EUDI wallet project: https://gitlab.opencode.de/bmi/eudi-wallet/eidas-2.0-architekturkonzept/-/blob/main/architecture-proposal/flows/Presentation-During-Issuance.md?ref_type=heads

I discussed with Torsten that VCI would probable be the right place to add this guidance.

[TimoGlastra]

+1 from me

I was just thinking last week that it would be great if this got standardized in OID4VCI. We have implemented this in our wallet, and the flow was very reasonable to support, and provides great UX improvements.

Especially the fallback to PAR in the authorization challenge endpoint as defined in Firth Party Applications draft, means you can always use the authorization challenge endpoint if the authorization server supports it. If no presentation during issuance is required, the authorization challenge endpoint can just return the PAR response as if you'd done the PAR request directly.

There's now also an IETF draft: https://datatracker.ietf.org/doc/draft-ietf-oauth-first-party-apps/

[Sakurann]

+1. there seems to be multiple implementers working on/interested in this in the EU and ISO communities

[paulbastian]

I support this as well. The question to me is how much to rely on the OAuth for first party applications draft or whether to define something separate.

[jogu]

Discussed on today's WG call:

• Restrict scope to presentation (using OpenID4VP) during issuance
• Have extension points so presenting ID cards etc can be defined elsewhere
• We need to think more about how this applies to DC API issuance/presentation
• This situations are mostly not going to be first party so probably we shouldn't reference the first party apps drafts (and it's not ready yet and it could be confusing for developers when they're implementing non-first party cases) so perhaps define something directly in VP

Lee suggested an alternative where a VP request is bundled into the DC API issuance call. Torsten said this has less flexibility than the above proposal based on first party apps draft, and we have implementation experience on first party apps approach (at least in non-DC API model). Plus we need a solution that works for wallet initiated issuance too.

[jogu]

Discussion on 1st May WG call:

Proposal above doesn't work if the credential is being issued into a different wallet than holds the credential to be presented. But solving for just single wallet case is still worthwhile so we should solve just that case for now.

Nice to have for 1.0 but shipping the spec without it is okay, it gives a nicer user experience but doesn't prevent any use cases, and wallets/issuers would likely need to implement a fallback to a redirect flow anyway. Payment LSPs are keen to have it.

Agreed on call to follow model in https://datatracker.ietf.org/doc/draft-ietf-oauth-first-party-apps/ but not reference that spec.

[Sakurann]

WG discussion

• this solves a real problem: want to do it in 1.0, not 1.1
  • there is quite some implementation experience (in cases without DC API)
• requirements:
  • define this for vanilla openid4vp during VCI. has to work also with DC API but might be able to put only limited guidance around DC API for now
• define behavior/error when wallet does not have a credential that the issuer is requesting during issuance; but might be able to define this later