- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Sat, 12 Jun 2021 10:10:43 -0400
- To: public-credentials@w3.org
On 6/12/21 6:03 AM, Brian Richter wrote: > I know but there are implementations out in the real world so I am asking > those implementers directly. YES! These are exactly the right set of questions to be asking, Brian. Thank you! For those that don't know where Brian got the endpoints from, they came from these documents: https://w3c-ccg.github.io/vc-http-api/issuer.html https://w3c-ccg.github.io/vc-http-api/verifier.html https://w3c-ccg.github.io/vc-http-api/holder.html Asking and answering these *focused* questions will help us understand the use cases for each endpoint in far more detail than having a meta-conversation about authz, GNAP, and UMA. > To address David's questions about the endpoints. *Issuer* > > * It appears you are going for a short lived credential and the API is > currently setup for long lived credentials (I forgot to mention the update > endpoint only updates status) This is not a correct assumption. The endpoints are set up for both short lived and long lived credentials and presentations. > *Holder* > > * Yes*/presentations/prove *takes in a presentation and this prove a > presentation returns the presentation along with a proof Yes, although we haven't gotten to the point where at least one organization is going to object to the current construction of almost every Holder API endpoint. :) To be clear, the Holder endpoints are in there as a proposal; people need them, but they are not in their final form and everyone should expect these endpoints to churn once we get around to discussing them. > * /credentials/issue o I am an endpoint internal to my organization so the > authz shouldn't matter to you There are internal and external use cases for this: * internal (behind a corporate firewall) * external (exposed as a SaaS endpoint) In both cases, one could say that the authorization happens within the same trust boundary, and that's probably the determining factor here. Every use case we have right now for that endpoint has the client in the same trust boundary as the server. That endpoint is YOUR endpoint in all use cases because it is using YOUR keys to sign the VC. It is true that in the future we might allow you to delegate access to that endpoint, and it is true that Digital Bazaar uses ZCAPs to do this with our issuer software today... but we absolutely do not want to expose the group to that at present because... we don't want to hold up the work to do the simplest thing first, which is OAuth2 and simple bearer tokens and scopes. Doing that in no way blocks ZCAPs or GNAP from working in the future. > * /credentials/update o I use the internal org authz as well Same things above apply here as well. Authorization is same trust boundary. If we need to delegate, we can do that in the future. > Veronica > > * To be honest.. I verify anything you throw at me. I get upset when I > can't verify something. Do I really need to authz? Yes, authz is needed here. If you don't have authz, you have a denial of service attack vector. Yes, you will try to verify anything that is thrown at you, but you need to establish if the caller is in your trust boundary, and to do that OAuth2 suffices for now... and in the future, if we want delegation, we can add support for delegation-aware authorization protocols. The switch is as simple as this: OAuth2 HTTP Header example: Authorization: Bearer mF_9.B5f-4.1JqM ZCAP HTTP Header example: Authorization: zcap capability=u3jf8Kf....pKq ^^ That seems to be what all of the fuss is about, and it seems to be a tempest in a tea pot. > Holder > > * /credentials/derive o All I do is remove information. Do I need authz? Yes, you need authz to provide denial of service attack prevention. The server also needs authz to determine which cryptographic keys to use when performing a derivation. > * /presentations/prove o I'm pretty proud of my credentials, I will prove > anything you want me to. Do I need authz? Same answer as above. > * /presentations/available o I don't need authz since I'm just a notify me > button to poke. This endpoint might be misguided and needs to be debated. If it stays, it doesn't need authz for the reason mentioned above. > * /presentation/submissions o I only take in credentials from you. I can > find other ways to throw away garbage. Do I need authz? Exactly -- this endpoint doesn't need authz to call it because you want just about anyone to be able to call it. Any endpoint that doesn't have authz will need to be protected using industry standard mechanisms (rate limiting by IP, DDoS detection and prevention, etc.) The server is almost certainly going to provide other mechanisms to throw away garbage/attacks that are layered on top of an effectively open endpoint. ------------ The fundamental take away here is: OAuth2 bearer tokens are just fine for now, and it's easy to see how delegation works for ZCAPs (or any other delegation mechanism that can be triggered through the 'Authorization' header in the future). Hope this helps... and I hope folks in the community, Adrian included, start focusing on the endpoints themselves and the *focused* ramifications of authz on each endpoint. -- 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, 12 June 2021 14:11:15 UTC