<html xmlns="http://www.w3.org/1999/xhtml">

<head>

<title></title>

</head>

<body>

<div name="messageBodySection">

<div dir="auto">Hi Orie, <br />

<br />

thanks for joining the WG and thanks for your attempt to simplify our specs. Simplifying things is always good and appreciated.<br />

<br />

OpenID 4 VP was designed as an end 2 end interoperable protocol for presenting credentials out of a wallet used by natural persons.  That’s why it has a concrete request syntax with a concrete query language and that’s why redirects back and forth (and the security of those) between the party play an important role. It is credential format agnostic because there are many different formats implementers can use and, reality demonstrates, they do. So we cannot provide a fully interoperable solution but at least make the protocol flow interoperable and secure. <br />

<br />

We started with a simple flow, just one redirect back and forth and over time learned it is be a good idea to send the results through a backend component at the verifier for better reliability and security.<br />

<br />

I would love to get things simplified again and are eager to understand your proposal. For that I need more context about your proposal. Just an endpoint for sending the credential presentation from the wallet to the verifier is not enough to achieve interoperability between verifier and wallet. Can we agree on that? <br />

<br />

If so, may I ask you to illustrate the overall flow including what is when agreed upon oob in your proposal?<br />

<br />

best regards,<br />

Torsten. </div>

</div>

<div name="messageReplySection">Am 16. Feb. 2024, 14:03 +0100 schrieb Orie Steele via Openid-specs-digital-credentials-protocols <openid-specs-digital-credentials-protocols@lists.openid.net>:<br />

<blockquote type="cite" style="border-left-color: grey; border-left-width: thin; border-left-style: solid; margin: 5px 5px;padding-left: 10px;">

<div dir="auto">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.

<div dir="auto"><br /></div>

<div dir="auto">I'm not asserting the flow could not work with OAuth.</div>

<div dir="auto"><br /></div>

<div dir="auto">The existing OIDC4VP spec from OIDF has an endpoint.</div>

<div dir="auto"><br /></div>

<div dir="auto">It just also has a lot of other stuff.</div>

<div dir="auto"><br /></div>

<div dir="auto">What are the essential requirements?</div>

<div dir="auto"><br /></div>

<div dir="auto">What are vendor or use case specific extensions?</div>

<div dir="auto"><br /></div>

<div dir="auto">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.</div>

<div dir="auto"><br /></div>

<div dir="auto">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).</div>

<div dir="auto"><br /></div>

<div dir="auto">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.</div>

<div dir="auto"><br /></div>

<div dir="auto">Instead of discouraging that, what if we encouraged it?</div>

<div dir="auto"><br /></div>

<div dir="auto">What if people could use OIDC4VP without having to use all the other bundled designs decision, such as the VP token, and Presentation Exchange.</div>

<div dir="auto"><br /></div>

<div dir="auto">If such a simple exchange flow isn't possible here, that's ok too.</div>

<div dir="auto"><br /></div>

<div dir="auto">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.</div>

<div dir="auto"><br /></div>

<div dir="auto">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.</div>

<div dir="auto"><br /></div>

<div dir="auto">The fundamental layer of presentation is: get challenged, prove possession.</div>

<div dir="auto"><br /></div>

<div dir="auto">All the other stuff is credential format, or query language specific...or legacy protocol specific.</div>

<div dir="auto"><br /></div>

<div dir="auto">A better design would allow for agility, or upgrading at the query layer... Not just at the credential format layer.</div>

<div dir="auto"><br /></div>

<div dir="auto">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.</div>

<div dir="auto"><br /></div>

<div dir="auto">If you want to design a protocol with query agility, treat the query as opaque bytes and use media types.</div>

<div dir="auto"><br /></div>

<div dir="auto">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 :)</div>

<div dir="auto"><br /></div>

<div dir="auto">Tldr, I'm here to help simplify the OIDC4VP spec or start a greenfield exercise to make a simpler alternative here or elsewhere : )</div>

<div dir="auto"><br /></div>

<div dir="auto">If it's basically frozen at this point, that would be good to know.</div>

<div dir="auto"><br /></div>

<div dir="auto">Regards,</div>

<div dir="auto"><br /></div>

<div dir="auto">OS</div>

<div dir="auto"><br /></div>

<div dir="auto"><br /></div>

</div>

<br />

<div class="gmail_quote">

<div dir="ltr" class="gmail_attr">On Fri, Feb 16, 2024, 3:03 AM Joseph Heenan via Openid-specs-digital-credentials-protocols <<a href="mailto:openid-specs-digital-credentials-protocols@lists.openid.net">openid-specs-digital-credentials-protocols@lists.openid.net</a>> wrote:<br /></div>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div style="line-break:after-white-space">Hi Orie

<div><br /></div>

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

<div><br /></div>

<div>Thanks</div>

<div><br /></div>

<div>Joseph</div>

<div><br /></div>

<div><br id="m_-2702563419936603889lineBreakAtBeginningOfMessage" />

<div><br />

<blockquote type="cite">

<div>On 16 Feb 2024, at 00:38, Orie Steele via Openid-specs-digital-credentials-protocols <<a href="mailto:openid-specs-digital-credentials-protocols@lists.openid.net" target="_blank" rel="noreferrer">openid-specs-digital-credentials-protocols@lists.openid.net</a>> wrote:</div>

<br />

<div>

<div dir="auto">I initially said assume the endpoint is negotiated out of band.

<div dir="auto"><br /></div>

<div dir="auto">I'd assume the wallet would process the response of the post body to know what to do next.</div>

<div dir="auto"><br /></div>

<div dir="auto">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.</div>

<div dir="auto"><br /></div>

<div dir="auto">One obvious place where the wallet might initially learn of the presentation endpoint, would be when it requests a nonce for a scope / purpose.</div>

<div dir="auto"><br /></div>

<div dir="auto">If folks want to build negotiation into this layer, that seems fine to me.</div>

<div dir="auto"><br /></div>

<div dir="auto">But in order to keep things simple I think it's best to focus only on the presentation endpoint.</div>

<div dir="auto"><br /></div>

<div dir="auto">What http methods does it support?</div>

<div dir="auto"><br /></div>

<div dir="auto">What content types? </div>

<div dir="auto"><br /></div>

<div dir="auto">What query parameters?</div>

<div dir="auto"><br /></div>

<div dir="auto">Which http headers?</div>

<div dir="auto"><br /></div>

<div dir="auto">I'd say the simplest solution looks like this:</div>

<div dir="auto"><br /></div>

<div dir="auto">POST <a href="https://rp.example/presentations" target="_blank" rel="noreferrer">https://rp.example/presentations</a></div>

<div dir="auto">--content-type application/sd-jwt / mDoc / cwt</div>

<div dir="auto">--accept application/json </div>

<div dir="auto">body (the sd-jwt / mdoc / cwt)</div>

<div dir="auto"><br /></div>

<div dir="auto">This way it's obvious what media type the client is sending, and what media type the client is requesting as a response.</div>

<div dir="auto"><br /></div>

<div dir="auto">Query parameters and headers are still available to handle state management and authorization.</div>

<div dir="auto"><br /></div>

<div dir="auto">Complexity can be layered on later... For many cases, the complexity might be unavoidable.</div>

<div dir="auto"><br /></div>

<div dir="auto">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.</div>

<div dir="auto"><br /></div>

<div dir="auto">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.</div>

<div dir="auto"><br /></div>

<div dir="auto">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.</div>

<div dir="auto"><br /></div>

<div dir="auto">OS</div>

<div dir="auto"><br /></div>

<div dir="auto"><br /></div>

<div dir="auto"><br /></div>

<br />

<br />

<div class="gmail_quote" dir="auto">

<div dir="ltr" class="gmail_attr">On Thu, Feb 15, 2024, 6:04 PM Brian Campbell <<a href="mailto:bcampbell@pingidentity.com" target="_blank" rel="noreferrer">bcampbell@pingidentity.com</a>> wrote:<br /></div>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="auto">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? </div>

<br />

<div class="gmail_quote">

<div dir="ltr" class="gmail_attr">On Thu, Feb 15, 2024, 3:03 PM Orie Steele via Openid-specs-digital-credentials-protocols <<a href="mailto:openid-specs-digital-credentials-protocols@lists.openid.net" rel="noreferrer noreferrer" target="_blank">openid-specs-digital-credentials-protocols@lists.openid.net</a>> wrote:<br /></div>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="auto">

<div>

<div class="gmail_quote">

<div dir="ltr" class="gmail_attr"><br /></div>

<div dir="ltr">

<div>( I signed the contributor agreement in docusign ).<br />

<br /></div>

<div>My ideal flow:<br />

<br />

GET relying-party.example/nonce<br />

POST relying-party.example/presentations<br />

<br />

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

<br />

Once the wallet has used the nonce, the wallet wants to send the presentation to the RP.<br />

<br />

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

<br />

In other words, all the parameters that are "not a nonce" and "not a presentation" are getting in the way of a simple spec.<br />

<br />

We have a proposal for a simple endpoint for getting nonces:<br />

<br />

<a href="https://datatracker.ietf.org/doc/draft-demarco-oauth-nonce-endpoint/" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">https://datatracker.ietf.org/doc/draft-demarco-oauth-nonce-endpoint/</a><br />

<br />

I want a simple endpoint for sending presentations.<br />

<br />

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

Assume the nonce is negotiated out of band.<br />

Assume credential types are negotiated out of band.<br />

Assume credential claims are negotiated out of band.<br />

Assume the presentation endpoint is negotiated out of band.<br />

<br />

How does a wallet submit a presentation?<br />

<br />

Regards,<br />

<br />

OS<br />

<br /></div>

<span class="gmail_signature_prefix">--</span><br />

<div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">

<div dir="ltr">

<div dir="ltr">

<div dir="ltr">

<div dir="ltr">

<div dir="ltr"><span></span>

<div style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span><br /></span></div>

<div style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;padding:10pt 0pt"><span><span style="font-size:10pt;font-family:Arial;color:rgb(32,18,77);background-color:transparent;font-weight:700;vertical-align:baseline;white-space:pre-wrap">ORIE STEELE</span><span style="font-size:10pt;font-family:Arial;color:rgb(32,18,77);background-color:transparent;font-weight:700;vertical-align:baseline;white-space:pre-wrap"><br /></span><span style="font-size:10pt;font-family:Arial;color:rgb(32,18,77);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">Chief Technology Officer</span><span style="font-size:10pt;font-family:Arial;color:rgb(32,18,77);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"><br /></span><span style="font-size:8pt;font-family:Arial;color:rgb(32,18,77);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">www.transmute.industries</span></span></div>

<div style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;padding:0pt 0pt 10pt"><a href="https://transmute.industries/" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank"><img width="96" height="22" src="https://ci3.googleusercontent.com/mail-sig/AIorK4xqtkj5psM1dDeDes_mjSsF3ylbEa5EMEQmnz3602cucAIhjLaHod-eVJq0E28BwrivrNSBMBc" /></a><br /></div>

</div>

</div>

</div>

</div>

</div>

</div>

</div>

</div>

</div>

</div>

--<br />

Openid-specs-digital-credentials-protocols mailing list<br />

<a href="mailto:Openid-specs-digital-credentials-protocols@lists.openid.net" rel="noreferrer noreferrer noreferrer" target="_blank">Openid-specs-digital-credentials-protocols@lists.openid.net</a><br />

<a href="https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols</a><br /></blockquote>

</div>

<br />

<i style="margin:0px;padding:0px;border:0px;outline:0px;vertical-align:baseline;background:rgb(255,255,255);font-family:proxima-nova-zendesk,system-ui,-apple-system,system-ui,"Segoe UI",Roboto,Oxygen-Sans,Ubuntu,Cantarell,"Helvetica Neue",Arial,sans-serif;color:rgb(85,85,85)"><span style="margin:0px;padding:0px;border:0px;outline:0px;vertical-align:baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ubuntu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"><font size="2">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.</font></span></i></blockquote>

</div>

</div>

--<br />

Openid-specs-digital-credentials-protocols mailing list<br />

<a href="mailto:Openid-specs-digital-credentials-protocols@lists.openid.net" target="_blank" rel="noreferrer">Openid-specs-digital-credentials-protocols@lists.openid.net</a><br />

<a href="https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols" target="_blank" rel="noreferrer">https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols</a><br /></div>

</blockquote>

</div>

<br /></div>

</div>

--<br />

Openid-specs-digital-credentials-protocols mailing list<br />

<a href="mailto:Openid-specs-digital-credentials-protocols@lists.openid.net" target="_blank" rel="noreferrer">Openid-specs-digital-credentials-protocols@lists.openid.net</a><br />

<a href="https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols" rel="noreferrer noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols</a><br /></blockquote>

</div>

--<br />

Openid-specs-digital-credentials-protocols mailing list<br />

Openid-specs-digital-credentials-protocols@lists.openid.net<br />

https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols<br /></blockquote>

</div>

</body>

</html>