[Openid-specs-digital-credentials-protocols] What does Presentation Exchange do and what parts of it do we actually need? (redux)

[Kristina Yasuda]

What prevents a wallet from specifying in the `presentation_submission` that it is returning only x out of N requested credentials (x <= N)? I thought nothing in the PE mandates this behavior.

And IMO this is somewhat orthogonal from in how many wallets credentials are being stored – as of today, no single protocol allows to return credentials from multiple wallets in one response, so it would be silly for the verifier to expect response to include credentials from multiple wallets. Hence the question becomes whether the wallet receiving the request can fulfill it entirely or not.

Regarding the requests you make for OID4VP..
> The ability to support multi-step presentations including a negotiation step with wallets.
This is being somewhat defined in PR 52: https://github.com/openid/OpenID4VP/pull/52

> (Possibly) A well known endpoint for a verifier to advertise the credentials they trust, for which purpose, from different issuers, and where to get them (perhaps similar to the work we started on DIF Trust Establishment<https://identity.foundation/trust-establishment/>)
I think how this is done might depend on the `client_id_scheme`. If a verifier is identified by an https url, as you say, a new .well-known endpoint is most natural. If a verifier is identified using a DID or an x.509 name, that would possibly lead to alternative mechanisms.

Regarding issuance during presentation that you mention (I personally think making this seamless could help us expand the ecosystem), why passing issuer’s identifier (whether https url or a DID or x.509 name) in the presentation_definition using already defined mechanisms not sufficient? Wallet will obtain issuer’s information by either appending a .well-known/openid-credential-issuer or going to a service endpoint from a DID or looking up an x.509 name in a trusted list of issuer it has and formulate an issuance request to that issuer.

+1 to working on PE in DCP WG.

Best,
Kristina

From: Openid-specs-digital-credentials-protocols <openid-specs-digital-credentials-protocols-bounces at lists.openid.net> On Behalf Of Gabe Cohen via Openid-specs-digital-credentials-protocols
Sent: Monday, October 16, 2023 9:49 AM
To: Digital Credentials Protocols List <openid-specs-digital-credentials-protocols at lists.openid.net>
Cc: Gabe Cohen <gabe at tbd.email>
Subject: Re: [Openid-specs-digital-credentials-protocols] What does Presentation Exchange do and what parts of it do we actually need? (redux)

Mike,

Thanks for writing down your thoughts, very helpful! I’ve spent time thinking about, and have had discussions about your post script:

When a verifier needs multiple credentials, they may be in different wallets. If the verifier tries to make a PE request for multiple credentials that are spread between wallets, will it always fail because no single wallet can satisfy it?


My answer to our team internally has been “yes it will fail.” PE was designed in a weird spot between a data model and a protocol, maybe more accurately described as a data model for a protocol, but it has left out a few pieces of the data model that would make it even more useful for a robust protocol.

To mitigate in the short term, we are going with multiple finer-grained PE requests; however, there’s still the question of how a wallet can communicate with a verifier that they need a single request broken up into N pieces—that’s part 1 of what’s missing in the data model.

There’s another problem, too—what happens if a wallet does not have the credential(s) they need, where do they go and get them? In the OID4VC world we could leverage an issuer’s well known endpoints to discover the credential’s they offer, but it may be more useful to encode this information directly in PE as a part of a “discovery” request. Especially useful in cases where the verifier is not the issuer of the credentials being requested.

I’d like to see two additions to PE:


  *   A new data object that enables a wallet to communicate how many submission’s they’ll make against a single presentation request (multi-part) OR a way for a wallet to specify they need N presentation requests (while also specifying which input descriptors/submission requirements they’ll fulfill for each).
  *   A new data object for a verifier to advertise where a wallet can obtain the credentials they’re requesting

And in a protocol (OID4VP):

  *   The ability to support multi-step presentations including a negotiation step with wallets
  *   (Possibly) A well known endpoint for a verifier to advertise the credentials they trust, for which purpose, from different issuers, and where to get them (perhaps similar to the work we started on DIF Trust Establishment<https://identity.foundation/trust-establishment/>)

PE needs other changes too, as you called out. I had a few conversations at IIW which made me think PEv3 may be need to be started sooner, rather than later, and this group may be the right place to do it.

Gabe

On Oct 14, 2023 at 6:11:18 PM, Michael Jones via Openid-specs-digital-credentials-protocols <openid-specs-digital-credentials-protocols at lists.openid.net<mailto:openid-specs-digital-credentials-protocols at lists.openid.net>> wrote:
I thought I’d share my write-up of the Presentation Exchange session at IIW for those of you who couldn’t be there.

See https://self-issued.info/?p=2427.

                                                       -- Mike

--
Openid-specs-digital-credentials-protocols mailing list
Openid-specs-digital-credentials-protocols at lists.openid.net<mailto:Openid-specs-digital-credentials-protocols at lists.openid.net>
https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20231016/3eb3326d/attachment-0001.html>