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

Tue Oct 17 16:39:12 UTC 2023

> 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.
>

There’s no way to indicate it’s part 1 of N, or there will be subsequent
submissions. Without that indication the verifier has every reason to
dismiss the submission as invalid.

This is being somewhat defined in PR 52:
> https://github.com/openid/OpenID4VP/pull/52
>

Yes, this defines the negotiation step with wallets, but seems we need to
add in the “suggest N requests from M devices/identifiers” piece.

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.
>

Agree!

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?
>

It may be sufficient, but it places a higher burden on the wallet to
discover the scheme used by the issuer. I am also thinking of cases where
the issuer’s identifier is not present in the request at all, but instead
it points to an identifier for a Trust List/Registry which contains many
issuers. It may be more helpful to provide additional contextual
information to a wallet so they can more seamlessly get the necessary
credentials. Something we can talk about in v3.

Gabe

On Oct 16, 2023 at 2:58:41 PM, Kristina Yasuda <
Kristina.Yasuda at microsoft.com> wrote:

> 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> 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
>
> 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/20231017/3a875c34/attachment.html>