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

[Orie Steele]

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.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20240215/cc17fdf4/attachment-0001.html>