[Openid-specs-digital-credentials-protocols] A simple presentation endpoint

Fri Feb 16 13:03:15 UTC 2024

It's my understanding that all these protocols developed for exchanging
digital credentials are not OAuth flows, which is why we are talking about
them on the OIDF list instead of the OAuth list.

I'm not asserting the flow could not work with OAuth.

The existing OIDC4VP spec from OIDF has an endpoint.

It just also has a lot of other stuff.

What are the essential requirements?

What are vendor or use case specific extensions?

To keep things aligned with the familiar, let's assume were talking about
OIDC4VP, and the Wallet is at the stage where it can make the presentation.

In order to get to this point, it had to implement presentation exchange,
and other tokens formats such as "vp_token" which is not actually a VP (has
no well defined media type, assumes text encoding).

Regardless, the endpoint that accepts presentations is defined in the
OIDC4VP spec, and I could just pluck that endpoint out and use it without
the rest of the spec.

Instead of discouraging that, what if we encouraged it?

What if people could use OIDC4VP without having to use all the other
bundled designs decision, such as the VP token, and Presentation Exchange.

If such a simple exchange flow isn't possible here, that's ok too.

My use case is the OIDC4VP use case, my feedback is on its design, and in
particular it's lack of layering, and agility at layers that have poor
design.

I'm partly responsible for the poor design of PE, and it's not as bad as it
could have been, but it's not good enough commit to forever, and this is my
primary point in this thread.

The fundamental layer of presentation is: get challenged, prove possession.

All the other stuff is credential format, or query language specific...or
legacy protocol specific.

A better design would allow for agility, or upgrading at the query layer...
Not just at the credential format layer.

There are other specs that do this, but they make other design decisions
which I dislike, such as using polyfills and JavaScript to transport
credentials through post message, to enable cross origin presentation.

If you want to design a protocol with query agility, treat the query as
opaque bytes and use media types.

If you think the query language developed in the presentation exchange is
what should be standardized and baked into every wallet and RP... I guess
it's time for me to get off this list :)

Tldr, I'm here to help simplify the OIDC4VP spec or start a greenfield
exercise to make a simpler alternative here or elsewhere : )

If it's basically frozen at this point, that would be good to know.

Regards,

OS

On Fri, Feb 16, 2024, 3:03 AM Joseph Heenan via
Openid-specs-digital-credentials-protocols <
openid-specs-digital-credentials-protocols at lists.openid.net> wrote:

> Hi Orie
>
> I think I’m still struggling with the use case / protocol flow here. Am I
> correct to understand the kind of flow you’re suggesting is not an OAuth
> based flow? If so what are the usual mechanisms that link verifier & wallet
> sessions together being replaced with or why are they not applicable in
> this situation? How does the wallet know the RP wants a credential?
>
> Thanks
>
> Joseph
>
>
>
> On 16 Feb 2024, at 00:38, Orie Steele via
> Openid-specs-digital-credentials-protocols <
> openid-specs-digital-credentials-protocols at lists.openid.net> wrote:
>
> I initially said assume the endpoint is negotiated out of band.
>
> I'd assume the wallet would process the response of the post body to know
> what to do next.
>
> The response is another place where the RP might demand extra information,
> for example, providing a fresh nonce and asking for a new presentation...
> And possibly requiring a different presentation endpoint.
>
> One obvious place where the wallet might initially learn of the
> presentation endpoint, would be when it requests a nonce for a scope /
> purpose.
>
> If folks want to build negotiation into this layer, that seems fine to me.
>
> But in order to keep things simple I think it's best to focus only on the
> presentation endpoint.
>
> What http methods does it support?
>
> What content types?
>
> What query parameters?
>
> Which http headers?
>
> I'd say the simplest solution looks like this:
>
> POST https://rp.example/presentations
> --content-type application/sd-jwt / mDoc / cwt
> --accept application/json
> body (the sd-jwt / mdoc / cwt)
>
> This way it's obvious what media type the client is sending, and what
> media type the client is requesting as a response.
>
> Query parameters and headers are still available to handle state
> management and authorization.
>
> Complexity can be layered on later... For many cases, the complexity might
> be unavoidable.
>
> But for simple cases, like a wallet that only stores a single credential
> type, and a relying party that only accepts a single claim from a single
> credential type, it will be trivial to present credentials.
>
> As a concrete use case imagine relying parties that only care about over
> 18, and wallets that only store age verification credentials... Being
> forced to implement an open ended arbitrary claims query language just to
> support this is massive overkill.
>
> Having a simple way to present credentials to an RP doesn't preclude a
> complex query system, it just doesn't require it / enforce it as a barrier
> to adoption.
>
> OS
>
>
>
>
>
> On Thu, Feb 15, 2024, 6:04 PM Brian Campbell <bcampbell at pingidentity.com>
> wrote:
>
>> How does a wallet (or user of a wallet) know to send a presentation to
>> this endpoint? Or know the endpoint? What happens after, i.e., what's the
>> response have?
>>
>> On Thu, Feb 15, 2024, 3:03 PM Orie Steele via
>> Openid-specs-digital-credentials-protocols <
>> openid-specs-digital-credentials-protocols at lists.openid.net> wrote:
>>
>>>
>>> ( I signed the contributor agreement in docusign ).
>>>
>>> My ideal flow:
>>>
>>> GET relying-party.example/nonce
>>> POST relying-party.example/presentations
>>>
>>> If the RP wants to demand extra state commitments from the wallet,
>>> that's fine, but if the wallet just wants a nonce to make a presentation,
>>> the wallet should be able to just get a nonce.
>>>
>>> Once the wallet has used the nonce, the wallet wants to send the
>>> presentation to the RP.
>>>
>>> If the RP wants to demand extra state commitments from the wallet,
>>> that's fine, but if the wallet just wants to send a presentation, the
>>> wallet should be able to just send a presentation.
>>>
>>> In other words, all the parameters that are "not a nonce" and "not a
>>> presentation" are getting in the way of a simple spec.
>>>
>>> We have a proposal for a simple endpoint for getting nonces:
>>>
>>> https://datatracker.ietf.org/doc/draft-demarco-oauth-nonce-endpoint/
>>>
>>> I want a simple endpoint for sending presentations.
>>>
>>> Assume an api gateway will filter out anything it does not recognize as
>>> being encrypted to an internal verifier, or as a well formed signed
>>> presentation.
>>> Assume the nonce is negotiated out of band.
>>> Assume credential types are negotiated out of band.
>>> Assume credential claims are negotiated out of band.
>>> Assume the presentation endpoint is negotiated out of band.
>>>
>>> How does a wallet submit a presentation?
>>>
>>> Regards,
>>>
>>> OS
>>>
>>> --
>>>
>>> ORIE STEELE
>>> Chief Technology Officer
>>> www.transmute.industries
>>> <https://transmute.industries/>
>>> --
>>> 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
>>>
>>
>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>> privileged material for the sole use of the intended recipient(s). Any
>> review, use, distribution or disclosure by others is strictly prohibited.
>> If you have received this communication in error, please notify the sender
>> immediately by e-mail and delete the message and any file attachments from
>> your computer. Thank you.*
>
> --
> 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
>
>
> --
> 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/20240216/e2df51e8/attachment-0001.html>