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

[Tom Jones]

I take that to mean that OIDF wants to OWN THE ENDPOINT?

Be the change you want to see in the world ..tom


On Fri, Feb 16, 2024 at 9:11 AM Kristina Yasuda via
Openid-specs-digital-credentials-protocols <
openid-specs-digital-credentials-protocols at lists.openid.net> wrote:

> And I don’t think it makes sense for the same endpoint to be part of two
> different flows.
>
>
>
> *From:* Orie Steele <orie at transmute.industries>
> *Sent:* Friday, February 16, 2024 9:07 AM
> *To:* Kristina Yasuda <Kristina.Yasuda at microsoft.com>
> *Cc:* Digital Credentials Protocols List <
> openid-specs-digital-credentials-protocols at lists.openid.net>; Torsten
> Lodderstedt <torsten at lodderstedt.net>
> *Subject:* Re: [Openid-specs-digital-credentials-protocols] A simple
> presentation endpoint
>
>
>
> 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.
>
> 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.
>
> OS
>
>
>
> On Fri, Feb 16, 2024 at 10:58 AM Kristina Yasuda <
> Kristina.Yasuda at microsoft.com> wrote:
>
> Hi Orie,
>
>
>
> I think the presentation model you are asking for is a different one that
> OpenID4VP.
>
>
>
> From what you described, sounds like you are envisioning the following:
>
>    - The verifier advertises what credential it needs for what service
>    - The wallet looks up that advertised information and sends a
>    credential to fulfill that requirement to get a service from the Verifier
>
>
>
> while OpenID4VP operates as following:
>
>    - The verifier sends a request to the wallet telling what credential
>    the verifier needs for what
>    - The wallet fulfills that request
>
>
>
> So the main difference is how to communicate the information about “what
> credential verifier needs for what service”.
>
>
>
> The closest to that idea I have seen is in the dataspaces specs.
>
>
> https://docs.internationaldataspaces.org/ids-knowledgebase/v/idsa-rulebook/idsa-rulebook/3_functional_requirements
>
> https://github.com/eclipse-tractusx/identity-trust
>
>
>
> Cheers,
>
> Kristina
>
>
>
> *From:* Openid-specs-digital-credentials-protocols <
> openid-specs-digital-credentials-protocols-bounces at lists.openid.net> *On
> Behalf Of *Orie Steele via Openid-specs-digital-credentials-protocols
> *Sent:* Friday, February 16, 2024 7:10 AM
> *To:* Torsten Lodderstedt <torsten at lodderstedt.net>
> *Cc:* Orie Steele <orie at transmute.industries>;
> openid-specs-digital-credentials-protocols at lists.openid.net
> *Subject:* Re: [Openid-specs-digital-credentials-protocols] A simple
> presentation endpoint
>
>
>
> Hey,
>
>
>
> Inline, and apologies this is long... coffee kicked in towards the very
> end.
>
>
>
> On Fri, Feb 16, 2024 at 7:46 AM <torsten at lodderstedt.net> wrote:
>
> Hi Orie,
>
> thanks for joining the WG and thanks for your attempt to simplify our
> specs. Simplifying things is always good and appreciated.
>
> 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.
>
> 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.
>
> 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?
>
>
>
> The problem is the word interoperability.
>
> A wallet and a verifier have interoperability, if they support the same
> standardS, and they can communicate using them.
>
> 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.
>
> 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.
>
> 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":
>
> Clients MUST set the content type of the post body to one of the following
> values:
>
> - application/sd-jwt
> - application/cwt
> - application/cose
>
> Clients MUST POST to the "presentation endpoint" that was negotiated out
> of band.
>
> Servers MUST respond with the following status messages and JSON response
> bodies:
>
> HTTP 200 { next_nonce: ..., ... extensions go here ... }
> HTTP 4XX { error: "Invalid DPoP key binding / Invalid credential key
> binding",  ... extensions go here ... }
>
> In some other spec, for now I will call in "Wallet Query Appraisal Spec",
>
> A wallet receives a nonce, presentation endpoint, and query, and RP
> identity information.
>
> The wallet reviews these details and presents consent UI to the user based
> on its local state.
>
> The wallet crafts the presentation, and then the "Presentation Endpoint
> Spec", picks up the ball.
>
> In some other spec, for now I will call it "RP Presentation Query Spec",
>
> 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.
>
> 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...
>
> In the simple case, all 3 specs are just OIDC4VP divided into separate
> documents
>
> - "RP Presentation Query Spec"
> - "Wallet Query Appraisal Spec"
> - "Presentation Endpoint Spec"
>
>
> If so, may I ask you to illustrate the overall flow including what is when
> agreed upon oob in your proposal?
>
>
> I'll make up an example:
>
> I'm in physical proximity to a device in the middle of a desert, holding a
> mobile phone.
> The device is beaconing over bluetooth and as I approach it, I scan a QR
> Code.
>
> -- End of RP Presentation Query Spec --
>
> It turns out I have installed trust roots for the device per RFC6024.
> The beacon was requesting permission to dispense water for anyone with
> digital drivers license using a SQL Query.
> My wallet understands the SQL Query and authenticates it and a nonce, and
> an endpoint.
> 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.
> I tap yes, or shake my phone furiously, which is interpreted as yes.
>
> -- End Wallet Query Appraisal Spec --
>
> My wallet applies the query, selects the credential, consumes the nonce,
> applies a signature from my HSM locked private key (Presentation Ready).
> 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.
> My wallet initiates an http POST request carrying my presentation to a tor
> hidden service over a satellite connection.
> A few minutes later, my wallet starts playing Africa by TOTO.
>
> -- End Presentation Endpoint Spec ---
>
> 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.
>
> Are there any parts of OIDC4VP that can be used here without using all of
> OIDC4VP?
>
> Perhaps wallets that don't understand RP Queries can ignore them.
> Wallets that can't authenticate RPs, don't present consent UI.
> RPs that don't understand presentations reject them.
>
> 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`.
>
> What if query, nonce, RP identity information, and presentation endpoint
> negotiation where out of scope?
>
> Would it still be possible to write a useful proposed standard that JUST
> covered delivery of credentials to an endpoint?
> ... even if it was useless without key discovery and nonce and query
> language negotiation?
>
> 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.
>
> I'm looking for a layering approach that makes this possible for OIDC4VP
> without pulling in all the current requirements that OIDC4VP mandates.
>
> I want smaller reusable building blocks.
>
>
> best regards,
> Torsten.
>
> Am 16. Feb. 2024, 14:03 +0100 schrieb Orie Steele via
> Openid-specs-digital-credentials-protocols <
> openid-specs-digital-credentials-protocols at lists.openid.net>:
>
> 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
>
> --
> 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
>
>
>
>
> --
>
>
>
>
> *ORIE STEELE *Chief Technology Officer
> www.transmute.industries
>
> <https://transmute.industries/>
>
>
>
>
> --
>
>
>
>
> *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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20240216/51c3e33d/attachment-0001.html>