- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Sat, 26 Mar 2022 18:03:45 -0400
- To: public-credentials@w3.org
On 3/21/22 7:33 PM, Tobias Looker wrote: > Essentially as Nikos pointed out the primary intent of client > registration, whether it be accomplished dynamically or via other means is > for the provider to understand certain things about it, that are core from > a security and interoperability perspective. We should be careful to separate client registration for the purposes of identifying a vendor, and dynamic client registration (that allows the vendor to be, ideally, anonymous). > Suffice to say even in a model that uses CHAPI + VC API, most of the exact > same information will have to be shared in order for exchange to be > conducted securely, The details matter here, so let's look at the specifics. The objection here is to identify the wallet vendor and then base security decisions off of that information. It's a variation of a confused deputy attack. > - Redirect URIs, required so the provider knows where to send the > authorization code in response, fundamentally if you want a protocol that > involves the issuer interacting with the End-User, you will not be able to > escape the usage of redirect and therefore the necessity of this parameter > being featured somewhere in the protocol. What is the security feature being sought here, and the attack model? > - response types, what the wallet supports as a response type, required > for interoperability, there is no point the provider producing a response > the wallet is fundamentally un-able to receive, also note it is optional > in registration. You say "it is optional", but previously say "there is no point", which is a contradiction. I'm going to assume you mean "its mandatory to ensure a good UX". If so, yes, agreed some form of protocol negotiation is required at some point. In CHAPI, this can be done via the wallet manifest.json file... just like it can be done in OIDC via discover... however, I think doing both is a mistake. We should probably make this a part of the protocol, and there are already hooks in VPR to do this. My hope is that whatever we settle on works across all of the wallet protocols (the description mechanism is the same). I'm already presuming that there will be more than one wallet protocol; though, it would be a miracle if we could get down to one. > - grant types, again very much like the above but it is the client > describing which possible grants it may request, also note it is optional > in registration. This is done via VPR. We've been passing ZCAP requests for years via VPR over CHAPI. I expect we can easily do the same for other grant types. The key point here is that we move this sort of stuff into the messages in the protocol and don't have it as a one-off for OIDC/SIOP. > - application_type, client describing its nature e.g is it web or native > again important around how the provider might enforce certain policies > associated to the redirect uri used which can be critical to the security > of the flow. What is the security feature being sought here, and the attack model? > I can go on Please do, :) exhaustive list please. We need every "wallet option" written down, with an understanding of who needs it and by when, if we're going to get anywhere. > but the point is all of the information captured during registration has a > purpose in the protocol either to mitigate certain security threats OR > promote interoperability between the client and provider. Just because > CHAPI + VC API flow hasn't got to tackling this particular problem yet, > around how these two parties will communicate certain things about each > other, does not mean the end-state solution will be any different. Alright, Mr. "We've considered something you haven't"... :P CHAPI has had protocol hinting and object matching for almost a decade now (though, we've hesitated to use it to introspect deeply into a presentation request because the wallet is usually better at letting the user know the specifics of why it can't complete a VPR): https://w3c-ccg.github.io/credential-handler-api/#credentialhint-dictionary We also have stuff in VPR; we already know the verifier might want to signal which issuer's it accepts (see `trustedIssuer`): https://w3c-ccg.github.io/vp-request-spec/#query-by-example ... but it was, and probably still is a bit premature to create a long list of things we think the ecosystem is going to want. We're letting it become ecosystem driven... when we see preventable interop failures, we can implement things in the appropriate place at that point, but no sooner. We have also discussed that making the conveyance of this information protocol specific sounds like a mistake. Having OIDC do it one way and VPR do it another way and DIDCommv2 do it in yet another way sounds fairly terrible. So, I'd hope we can come together and define something that works across all protocols before giving up and hard coding feature negotiation into each protocol separately. > For example here is a concrete case with CHAPI + VC API flows today where > this issue manifests clearly, say I'm on a relying parties website that > support validating VP's signed with an ECDSA signature and only did:key as > the did method. But when the End-User clicks "login" or "authenticate with > VCs", the End-Users selects a wallet via CHAPI that only supports EdDSA and > did:ion. What is going to happen is a VP is going to be generated and sent > back to the relying party, which the relying party is going to have no > ability to rely upon due to their in-ability to resolve the did method use > OR validate the signature on the VP. Yes, that certainly is a problem! Now, let's solve that problem for as many protocols as possible instead of doing this in a piece-meal fashion! -- manu -- Manu Sporny - https://www.linkedin.com/in/manusporny/ Founder/CEO - Digital Bazaar, Inc. News: Digital Bazaar Announces New Case Studies (2021) https://www.digitalbazaar.com/
Received on Saturday, 26 March 2022 22:04:02 UTC