- From: Adrian Gropper <agropper@healthurl.com>
- Date: Sat, 12 Jun 2021 11:44:29 -0400
- To: Manu Sporny <msporny@digitalbazaar.com>
- Cc: W3C Credentials Community Group <public-credentials@w3.org>
- Message-ID: <CANYRo8g-3poOBePVez=RNZBuW=Nu49nNsh+MwtJMR+bA1EiXzQ@mail.gmail.com>
Brian's initiative and Manu's analysis suggests that we could benefit from separating internal vs. external endpoints. Internal endpoints, for example, are unlikely targets for DoS attacks and benefit from delegation only to the extent it promotes a Zero Trust Architecture. - Adrian On Sat, Jun 12, 2021 at 11:23 AM Adrian Gropper <agropper@healthurl.com> wrote: > Manu, > > I also appreciate the clarity of this thread. > > Can we try not to respond to a privacy argument (delegation) with a > business argument (speed) because it just emboldens critics. > > As Justin phrased it in another thread, making delegation a SHOULD, would > satisfy the privacy concern. > > Adrian > > On Sat, Jun 12, 2021 at 10:15 AM Manu Sporny <msporny@digitalbazaar.com> > wrote: > >> 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 15:45:16 UTC