- From: Alan Karp <alanhkarp@gmail.com>
- Date: Sun, 27 Jun 2021 21:44:05 -0700
- To: Kim Hamilton <kimdhamilton@gmail.com>
- Cc: Manu Sporny <msporny@digitalbazaar.com>, "W3C Credentials CG (Public List)" <public-credentials@w3.org>
- Message-ID: <CANpA1Z3EMWz9Fa2m-ZYPYsAYE_nViWQMgJYyWKCRYBHRnHO9xw@mail.gmail.com>
Kyle's post makes a very strong case for not using VCs as authorization tokens, but not in the way I think he intendended. Instead, it illustrates the kind of confusion that I feared was likely to occur. The examples in Kyle's post are not authorization tokens (capabilities). A capability designates a single resource and the specific permissions the token authorizes. Kyle's examples are the kind of tokens used in RBAC, where CFO is the role. As Kyle correctly points out, such a role has a lot of permissions, and submitting one of the tokens in his example authorizes the use of any of them. That's exactly the condition that leads to a confused deputy vulnerability. The examples in https://w3c-ccg.github.io/zcap-ld/ do not have this problem. -------------- Alan Karp On Sun, Jun 27, 2021 at 6:24 PM Kim Hamilton <kimdhamilton@gmail.com> wrote: > +1, Kyle’s explanations and examples are fantastic. > > Reading this next: > https://kyledenhartog.com/delegation-in-verifiable-credentials/ > > On Thu, Jun 24, 2021 at 10:15 AM Manu Sporny <msporny@digitalbazaar.com> > wrote: > >> On 6/24/21 12:35 PM, Kyle Den Hartog wrote: >> > Agreed, when it comes to the number of checks that occur it's much >> greater >> > because of the delegation. With that in mind, looking at the semantics >> only >> > of the system VCs in my opinion weren't optimally designed for >> permission >> > tokens. This difference between the two requires that an implementation >> > that wants to support both claims tokens and permissions tokens has to >> > grapple with the different mental model that arise when trying to stuff >> > these things together. This introduces additional complexity. >> Additionally >> > it leads to weird statements that are being made where it's difficult to >> > tell if the VC is behaving like a claims token or a permissions token. >> >> Yes, exactly this. Exactly what Kyle states above is the reason why it's >> so >> complicated (and thus dangerous) to use VCs as permissions tokens. >> >> This is one of the primary reasons that we separated out the Authorization >> Capabilities work from the Verifiable Credentials work. Things get really >> complicated when you start mixing authz/authn/claims/permissions into a >> Verifiable Credential. Just because you can do it doesn't mean you should. >> >> Much of the complexity that gets created in such a system that mixes all >> those >> concepts together goes away when you clearly separate claims tokens from >> permissions tokens. >> >> I suggest that folks take a look at Kyle's post to see how intractable the >> problem becomes when you don't do proper separation of concerns and >> depend on >> attributes to convey permissions: >> >> https://kyledenhartog.com/example-authz-with-VCs/ >> >> -- 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 Monday, 28 June 2021 04:45:30 UTC