- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Thu, 24 Jun 2021 13:10:38 -0400
- To: public-credentials@w3.org
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 Thursday, 24 June 2021 17:11:17 UTC