<div dir="ltr">That's how the token endpoint works? <br><br><a href="https://datatracker.ietf.org/doc/html/rfc6749#section-3.2">https://datatracker.ietf.org/doc/html/rfc6749#section-3.2</a><br><br>That's also how open id configuration works:<br><br><a href="https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig">https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig</a><br><br>AFAIK, these endpoints are not restricted to "only 1 flow".<br><br>Even if you feel the endpoint should only be used for 1 flow, the current spec says it supports multiple flows, and it defines a parameter for distinguishing them:<br><br><a href="https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#name-response-mode-direct_postjw">https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#name-response-mode-direct_postjw</a><br><br>The endpoint works for both signed and encrypted responses:<br><br><a href="https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#section-6.3">https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#section-6.3</a><br><br>And the response type is specifically parameterized to support different response types:<br><br><a href="https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#response_mode_post">https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#response_mode_post</a><br><br>OS<br><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 16, 2024 at 11:10 AM Kristina Yasuda <<a href="mailto:Kristina.Yasuda@microsoft.com">Kristina.Yasuda@microsoft.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg-7393211826432061527">
<div lang="EN-US" style="overflow-wrap: break-word;">
<div class="m_-7393211826432061527WordSection1">
<p class="MsoNormal">And I don’t think it makes sense for the same endpoint to be part of two different flows.
<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11pt;font-family:Calibri,sans-serif">From:</span></b><span style="font-size:11pt;font-family:Calibri,sans-serif"> Orie Steele <orie@transmute.industries>
<br>
<b>Sent:</b> Friday, February 16, 2024 9:07 AM<br>
<b>To:</b> Kristina Yasuda <<a href="mailto:Kristina.Yasuda@microsoft.com" target="_blank">Kristina.Yasuda@microsoft.com</a>><br>
<b>Cc:</b> Digital Credentials Protocols List <<a href="mailto:openid-specs-digital-credentials-protocols@lists.openid.net" target="_blank">openid-specs-digital-credentials-protocols@lists.openid.net</a>>; Torsten Lodderstedt <<a href="mailto:torsten@lodderstedt.net" target="_blank">torsten@lodderstedt.net</a>><br>
<b>Subject:</b> Re: [Openid-specs-digital-credentials-protocols] A simple presentation endpoint<u></u><u></u></span></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal" style="margin-bottom:12pt">As I said in my initial post, I am looking for an endpoint to submit presentations to... not a protocol that defines an endpoint that only works with that protocol.<br>
<br>
If we skip to the part where "the wallet has a presentation and knows where to send it"... we don't need to discuss who initiated the flow, the wallet or the verifier... a proposed standard for such an endpoint could be used for both flows, or more than one
protocol.<br>
<br>
OS<br>
<br>
<u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Fri, Feb 16, 2024 at 10:58<span style="font-family:Arial,sans-serif"> </span>AM Kristina Yasuda <<a href="mailto:Kristina.Yasuda@microsoft.com" target="_blank">Kristina.Yasuda@microsoft.com</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<p class="MsoNormal">Hi Orie,<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">I think the presentation model you are asking for is a different one that OpenID4VP.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">From what you described, sounds like you are envisioning the following:<u></u><u></u></p>
<ul type="disc">
<li class="m_-7393211826432061527m-5936930325554570752msolistparagraph">
The verifier advertises what credential it needs for what service<u></u><u></u></li><li class="m_-7393211826432061527m-5936930325554570752msolistparagraph">
The wallet looks up that advertised information and sends a credential to fulfill that requirement to get a service from the Verifier<u></u><u></u></li></ul>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">while OpenID4VP operates as following:<u></u><u></u></p>
<ul type="disc">
<li class="m_-7393211826432061527m-5936930325554570752msolistparagraph">
The verifier sends a request to the wallet telling what credential the verifier needs for what<u></u><u></u></li><li class="m_-7393211826432061527m-5936930325554570752msolistparagraph">
The wallet fulfills that request<u></u><u></u></li></ul>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">So the main difference is how to communicate the information about “what credential verifier needs for what service”.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">The closest to that idea I have seen is in the dataspaces specs.<u></u><u></u></p>
<p class="MsoNormal"><a href="https://docs.internationaldataspaces.org/ids-knowledgebase/v/idsa-rulebook/idsa-rulebook/3_functional_requirements" target="_blank">https://docs.internationaldataspaces.org/ids-knowledgebase/v/idsa-rulebook/idsa-rulebook/3_functional_requirements</a><u></u><u></u></p>
<p class="MsoNormal"><a href="https://github.com/eclipse-tractusx/identity-trust" target="_blank">https://github.com/eclipse-tractusx/identity-trust</a><u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">Cheers,<u></u><u></u></p>
<p class="MsoNormal">Kristina<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11pt;font-family:Calibri,sans-serif">From:</span></b><span style="font-size:11pt;font-family:Calibri,sans-serif"> Openid-specs-digital-credentials-protocols
<<a href="mailto:openid-specs-digital-credentials-protocols-bounces@lists.openid.net" target="_blank">openid-specs-digital-credentials-protocols-bounces@lists.openid.net</a>>
<b>On Behalf Of </b>Orie Steele via Openid-specs-digital-credentials-protocols<br>
<b>Sent:</b> Friday, February 16, 2024 7:10 AM<br>
<b>To:</b> Torsten Lodderstedt <<a href="mailto:torsten@lodderstedt.net" target="_blank">torsten@lodderstedt.net</a>><br>
<b>Cc:</b> Orie Steele <<a href="mailto:orie@transmute.industries" target="_blank">orie@transmute.industries</a>>;
<a href="mailto:openid-specs-digital-credentials-protocols@lists.openid.net" target="_blank">
openid-specs-digital-credentials-protocols@lists.openid.net</a><br>
<b>Subject:</b> Re: [Openid-specs-digital-credentials-protocols] A simple presentation endpoint</span><u></u><u></u></p>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<div>
<p class="MsoNormal">Hey, <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Inline, and apologies this is long... coffee kicked in towards the very end.<u></u><u></u></p>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<div>
<p class="MsoNormal">On Fri, Feb 16, 2024 at 7:46<span style="font-family:Arial,sans-serif"> </span>AM <<a href="mailto:torsten@lodderstedt.net" target="_blank">torsten@lodderstedt.net</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin:5pt 0in 5pt 4.8pt">
<div>
<div name="messageBodySection">
<div>
<p class="MsoNormal">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? <u></u><u></u></p>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12pt">The problem is the word interoperability.<br>
<br>
A wallet and a verifier have interoperability, if they support the same standardS, and they can communicate using them.<br>
<br>
Consider a possible "presentation exchange standard", that used an encrypted out of band channel to negotiate the nonce, credential formats and credential disclosures, and then delivered them in an encrypted message to a standard endpoint.<br>
<br>
By definition, putting the negotiation for nonce, credential format and disclosed claims, and endpoint into the out of band channel, removes them from the definition of successful interoperability for the standard presentation delivery spec.<br>
<br>
Interoperability wrt the "presentation endpoint standard" then defines the "not out of band portions", and is then limited to the following, I'll call this "Presentation Endpoint Spec":<br>
<br>
Clients MUST set the content type of the post body to one of the following values:<br>
<br>
- application/sd-jwt<br>
- application/cwt<br>
- application/cose<br>
<br>
Clients MUST POST to the "presentation endpoint" that was negotiated out of band.<br>
<br>
Servers MUST respond with the following status messages and JSON response bodies:<br>
<br>
HTTP 200 { next_nonce: ..., ... extensions go here ... }<br>
HTTP 4XX { error: "Invalid DPoP key binding / Invalid credential key binding", ... extensions go here ... }<br>
<br>
In some other spec, for now I will call in "Wallet Query Appraisal Spec",<br>
<br>
A wallet receives a nonce, presentation endpoint, and query, and RP identity information.<br>
<br>
The wallet reviews these details and presents consent UI to the user based on its local state.<br>
<br>
The wallet crafts the presentation, and then the "Presentation Endpoint Spec", picks up the ball.<br>
<br>
In some other spec, for now I will call it "RP Presentation Query Spec",<br>
<br>
An RP advertises queries that wallets can request and how for the wallet to request them, if a wallet likes a query (and an RP), it asks for the query to be delivered from the RP and the "Wallet RP Appraisal Spec" takes over.<br>
<br>
Wallet and Verifier (RP) Interoperability is still achievable, instead of reading 1 spec and advertising support for 1 spec, they must read 3, and advertise support for 3...
<br>
<br>
In the simple case, all 3 specs are just OIDC4VP divided into separate documents<br>
<br>
- "RP Presentation Query Spec"<br>
- "Wallet Query Appraisal Spec"<br>
- "Presentation Endpoint Spec"<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin:5pt 0in 5pt 4.8pt">
<div>
<div name="messageBodySection">
<div>
<p class="MsoNormal"><br>
If so, may I ask you to illustrate the overall flow including what is when agreed upon oob in your proposal?<u></u><u></u></p>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal" style="margin-bottom:12pt"><br>
I'll make up an example:<br>
<br>
I'm in physical proximity to a device in the middle of a desert, holding a mobile phone.<br>
The device is beaconing over bluetooth and as I approach it, I scan a QR Code.<br>
<br>
-- End of RP Presentation Query Spec --<br>
<br>
It turns out I have installed trust roots for the device per RFC6024.<br>
The beacon was requesting permission to dispense water for anyone with digital drivers license using a SQL Query.<br>
My wallet understands the SQL Query and authenticates it and a nonce, and an endpoint.<br>
My wallet displays a prompt asking me to confirm I want to present my drivers license to the device, so it can give me water.<br>
I tap yes, or shake my phone furiously, which is interpreted as yes.<br>
<br>
-- End Wallet Query Appraisal Spec --<br>
<br>
My wallet applies the query, selects the credential, consumes the nonce, applies a signature from my HSM locked private key (Presentation Ready).<br>
My wallet looks at the presentation endpoint, at this point we know the endpoint is acceptable, because it would have been rejected in the previous spec otherwise.<br>
My wallet initiates an http POST request carrying my presentation to a tor hidden service over a satellite connection.<br>
A few minutes later, my wallet starts playing Africa by TOTO.<br>
<br>
-- End Presentation Endpoint Spec --- <br>
<br>
While I listen to TOTO, I realize a button light on the device has turned green, I press it, and it dispenses a delicious glass of cold water.<br>
<br>
Are there any parts of OIDC4VP that can be used here without using all of OIDC4VP?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12pt">Perhaps wallets that don't understand RP Queries can ignore them.<br>
Wallets that can't authenticate RPs, don't present consent UI.<br>
RPs that don't understand presentations reject them.<br>
<br>
Its pretty common for proposed standards to say things like "key discovery is out of scope", and yet still require some form of key discovery to exist... possibly even while giving hints that might be helpful to key discovery, such as `iss`, `kid` or `x5t`.<br>
<br>
What if query, nonce, RP identity information, and presentation endpoint negotiation where out of scope?<br>
<br>
Would it still be possible to write a useful proposed standard that JUST covered delivery of credentials to an endpoint?<br>
... even if it was useless without key discovery and nonce and query language negotiation?<br>
<br>
Hopefully this long email makes it clear what I am looking for... I want an endpoint that can be used with OIDC4VP, but that can also be used assuming the critical parts of OIDC4VP are somehow negotiated over a different set of protocols, possibly ones with
superior privacy properties, or better operation in network denied environments.<br>
<br>
I'm looking for a layering approach that makes this possible for OIDC4VP without pulling in all the current requirements that OIDC4VP mandates.<br>
<br>
I want smaller reusable building blocks.<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin:5pt 0in 5pt 4.8pt">
<div>
<div name="messageBodySection">
<div>
<p class="MsoNormal"><br>
best regards,<br>
Torsten. <u></u><u></u></p>
</div>
</div>
<div name="messageReplySection">
<p class="MsoNormal" style="margin-bottom:12pt">Am 16. Feb. 2024, 14:03 +0100 schrieb Orie Steele via Openid-specs-digital-credentials-protocols <<a href="mailto:openid-specs-digital-credentials-protocols@lists.openid.net" target="_blank">openid-specs-digital-credentials-protocols@lists.openid.net</a>>:<u></u><u></u></p>
<blockquote style="margin:3.75pt">
<div>
<p class="MsoNormal">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. <u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">I'm not asserting the flow could not work with OAuth.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">The existing OIDC4VP spec from OIDF has an endpoint.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">It just also has a lot of other stuff.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">What are the essential requirements?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">What are vendor or use case specific extensions?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">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).<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Instead of discouraging that, what if we encouraged it?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">What if people could use OIDC4VP without having to use all the other bundled designs decision, such as the VP token, and Presentation Exchange.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">If such a simple exchange flow isn't possible here, that's ok too.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">The fundamental layer of presentation is: get challenged, prove possession.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">All the other stuff is credential format, or query language specific...or legacy protocol specific.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">A better design would allow for agility, or upgrading at the query layer... Not just at the credential format layer.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">If you want to design a protocol with query agility, treat the query as opaque bytes and use media types.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">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 :)<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Tldr, I'm here to help simplify the OIDC4VP spec or start a greenfield exercise to make a simpler alternative here or elsewhere : )<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">If it's basically frozen at this point, that would be good to know.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Regards,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">OS<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<div>
<p class="MsoNormal">On Fri, Feb 16, 2024, 3:03<span style="font-family:Arial,sans-serif"> </span>AM Joseph Heenan via Openid-specs-digital-credentials-protocols <<a href="mailto:openid-specs-digital-credentials-protocols@lists.openid.net" target="_blank">openid-specs-digital-credentials-protocols@lists.openid.net</a>>
wrote:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin:5pt 0in 5pt 4.8pt">
<div>
<p class="MsoNormal">Hi Orie
<u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">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?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Thanks<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Joseph<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<p class="MsoNormal" style="margin-bottom:12pt"><u></u> <u></u></p>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div>
<p class="MsoNormal">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">openid-specs-digital-credentials-protocols@lists.openid.net</a>>
wrote:<u></u><u></u></p>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<div>
<p class="MsoNormal">I initially said assume the endpoint is negotiated out of band.
<u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">I'd assume the wallet would process the response of the post body to know what to do next.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">One obvious place where the wallet might initially learn of the presentation endpoint, would be when it requests a nonce for a scope / purpose.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">If folks want to build negotiation into this layer, that seems fine to me.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">But in order to keep things simple I think it's best to focus only on the presentation endpoint.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">What http methods does it support?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">What content types? <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">What query parameters?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Which http headers?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">I'd say the simplest solution looks like this:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">POST
<a href="https://rp.example/presentations" target="_blank">https://rp.example/presentations</a><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">--content-type application/sd-jwt / mDoc / cwt<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">--accept application/json <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">body (the sd-jwt / mdoc / cwt)<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">This way it's obvious what media type the client is sending, and what media type the client is requesting as a response.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Query parameters and headers are still available to handle state management and authorization.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Complexity can be layered on later... For many cases, the complexity might be unavoidable.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">OS<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<p class="MsoNormal" style="margin-bottom:12pt"> <u></u><u></u></p>
<div>
<div>
<p class="MsoNormal">On Thu, Feb 15, 2024, 6:04<span style="font-family:Arial,sans-serif"> </span>PM Brian Campbell <<a href="mailto:bcampbell@pingidentity.com" target="_blank">bcampbell@pingidentity.com</a>>
wrote:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin:5pt 0in 5pt 4.8pt">
<div>
<p class="MsoNormal">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? <u></u><u></u></p>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<div>
<p class="MsoNormal">On Thu, Feb 15, 2024, 3:03<span style="font-family:Arial,sans-serif"> </span>PM Orie Steele via Openid-specs-digital-credentials-protocols <<a href="mailto:openid-specs-digital-credentials-protocols@lists.openid.net" target="_blank">openid-specs-digital-credentials-protocols@lists.openid.net</a>>
wrote:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin:5pt 0in 5pt 4.8pt">
<div>
<div>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12pt">( I signed the contributor agreement in docusign ).<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12pt">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/" 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<u></u><u></u></p>
</div>
<p class="MsoNormal"><span class="m_-7393211826432061527m-5936930325554570752gmailsignatureprefix">--</span><u></u><u></u></p>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><b><span style="font-size:10pt;font-family:Arial,sans-serif;color:rgb(32,18,77)">ORIE STEELE<br>
</span></b><span style="font-size:10pt;font-family:Arial,sans-serif;color:rgb(32,18,77)">Chief Technology Officer<br>
</span><span style="font-size:8pt;font-family:Arial,sans-serif;color:rgb(32,18,77)"><a href="http://www.transmute.industries/" target="_blank">www.transmute.industries</a></span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><a href="https://transmute.industries/" target="_blank"><span style="text-decoration:none"><img border="0" width="96" height="22" style="width: 1in; height: 0.2291in;" id="m_-7393211826432061527_x0000_i1027" src="https://ci3.googleusercontent.com/mail-sig/AIorK4xqtkj5psM1dDeDes_mjSsF3ylbEa5EMEQmnz3602cucAIhjLaHod-eVJq0E28BwrivrNSBMBc"></span></a><u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal">--<br>
Openid-specs-digital-credentials-protocols mailing list<br>
<a href="mailto:Openid-specs-digital-credentials-protocols@lists.openid.net" 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" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols</a><u></u><u></u></p>
</blockquote>
</div>
<p class="MsoNormal"><br>
<b><i><span style="font-size:10pt;font-family:"Segoe UI",sans-serif;color:rgb(85,85,85);border:1pt none windowtext;padding:0in">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.</span></i></b><u></u><u></u></p>
</blockquote>
</div>
</div>
<p class="MsoNormal">--<br>
Openid-specs-digital-credentials-protocols mailing list<br>
<a href="mailto:Openid-specs-digital-credentials-protocols@lists.openid.net" 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" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols</a><u></u><u></u></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
<p class="MsoNormal">--<br>
Openid-specs-digital-credentials-protocols mailing list<br>
<a href="mailto:Openid-specs-digital-credentials-protocols@lists.openid.net" 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" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols</a><u></u><u></u></p>
</blockquote>
</div>
<p class="MsoNormal">--<br>
Openid-specs-digital-credentials-protocols mailing list<br>
<a href="mailto:Openid-specs-digital-credentials-protocols@lists.openid.net" 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" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols</a><u></u><u></u></p>
</blockquote>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><br clear="all">
<u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<p class="MsoNormal"><span class="m_-7393211826432061527m-5936930325554570752gmailsignatureprefix">--
</span><u></u><u></u></p>
<div>
<div>
<div>
<div>
<div>
<div>
<p style="margin:0in"> <u></u><u></u></p>
<p style="margin:0in"><b><span style="font-size:10pt;font-family:Arial,sans-serif;color:rgb(32,18,77)">ORIE STEELE<br>
</span></b><span style="font-size:10pt;font-family:Arial,sans-serif;color:rgb(32,18,77)">Chief Technology Officer<br>
</span><span style="font-size:8pt;font-family:Arial,sans-serif;color:rgb(32,18,77)"><a href="http://www.transmute.industries/" target="_blank">www.transmute.industries</a></span><u></u><u></u></p>
<p style="margin:0in"><a href="https://transmute.industries/" target="_blank"><span style="text-decoration:none"><img border="0" width="96" height="22" style="width: 1in; height: 0.2291in;" id="m_-7393211826432061527_x0000_i1026" src="https://ci3.googleusercontent.com/mail-sig/AIorK4xqtkj5psM1dDeDes_mjSsF3ylbEa5EMEQmnz3602cucAIhjLaHod-eVJq0E28BwrivrNSBMBc"></span></a><u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><br clear="all">
<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal"><span class="m_-7393211826432061527gmailsignatureprefix">-- </span><u></u><u></u></p>
<div>
<div>
<div>
<div>
<div>
<div>
<p style="margin:0in"><u></u> <u></u></p>
<p style="margin:0in"><b><span style="font-size:10pt;font-family:Arial,sans-serif;color:rgb(32,18,77)">ORIE STEELE<br>
</span></b><span style="font-size:10pt;font-family:Arial,sans-serif;color:rgb(32,18,77)">Chief Technology Officer<br>
</span><span style="font-size:8pt;font-family:Arial,sans-serif;color:rgb(32,18,77)"><a href="http://www.transmute.industries/" target="_blank">www.transmute.industries</a></span><u></u><u></u></p>
<p style="margin:0in"><a href="https://transmute.industries/" target="_blank"><span style="text-decoration:none"><img border="0" width="96" height="22" style="width: 1in; height: 0.2291in;" id="m_-7393211826432061527_x0000_i1025" src="https://ci3.googleusercontent.com/mail-sig/AIorK4xqtkj5psM1dDeDes_mjSsF3ylbEa5EMEQmnz3602cucAIhjLaHod-eVJq0E28BwrivrNSBMBc"></span></a><u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div></blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><span><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><br></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;padding:10pt 0pt"><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></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;padding:0pt 0pt 10pt"><a href="https://transmute.industries" target="_blank"><img width="96" height="22" src="https://ci3.googleusercontent.com/mail-sig/AIorK4xqtkj5psM1dDeDes_mjSsF3ylbEa5EMEQmnz3602cucAIhjLaHod-eVJq0E28BwrivrNSBMBc"></a><br></p></span></div></div></div></div></div></div>