RE: The dangers of using VCs as permission tokens

RE: Can we not have VCs remain the simple things they've been from the outset: a 'credentialSubject', i.e. set of claims about one or more subjects (where a claim can be structured as a tree of attributes), enveloped with some meta-data and proofs? ... This is effectively where I intended to take the discussion. Put another way, I'd like to see us as a community not treat the VC data model as a hammer where everything becomes a nail (including authorization systems).

A VC is, in fact, a very good hammer.

A VC  is a very good hammer in the sense VCs represent a general solution for packaging up a trustable (verifiable) collection of claims (name-value pairs) associated with a named entity (the subject identified by one of its identifiers) ...a classic object ...a named instance of a class or struct (defined by its field members, schema context, and VC type) ...a hammer for creating an infinite number of different nails for different purposes.

Hence, I see a lot of this discussion being reduced to classic/basic object-oriented design problem: For example, should VCAs (verifiable credential authorizations) always exist:
a) as their own object/class, or
b) should they/can they be packed as a subobject/child of another credential.

Additional reading: https://hyperonomy.com/2021/04/26/the-verifiable-economy-architecture-reference-model-ve-arm-fdo/
...being realized with real code: https://hyperonomy.com/2021/06/28/trusted-digital-web-8-layer-architecture-reference-model-tdw-arm/

Best regards,
Michael Herman
Far Left Self-Sovereignist

Self-Sovereign Blockchain Architect
Trusted Digital Web
Hyperonomy Digital Identity Lab
Parallelspace Corporation

[cid:image003.jpg@01D76BEB.982E59A0]



From: Kyle Den Hartog <kyle.denhartog@mattr.global>
Sent: June 28, 2021 5:23 AM
To: Joosten, H.J.M. (Rieks) <rieks.joosten@tno.nl>; Alan Karp <alanhkarp@gmail.com>; daniel.hardman@gmail.com
Cc: Kim Hamilton <kimdhamilton@gmail.com>; Manu Sporny <msporny@digitalbazaar.com>; W3C Credentials CG (Public List) <public-credentials@w3.org>
Subject: Re: The dangers of using VCs as permission tokens

> Can we not have VCs remain the simple things they've been from the outset: a 'credentialSubject', i.e. set of claims about one or more subjects (where a claim can be structured as a tree of attributes), enveloped with some meta-data and proofs?

This is effectively where I intended to take the discussion. Put another way, I'd like to see us as a community not treat the VC data model as a hammer where everything becomes a nail (including authorization systems). Rather, it's my opinion that we should keep VCs limited to what they do best. Let's keep them to claims tokens which at their technical barebones is a simple, well-designed method to binding identifiers (and by extension the subject of the identifier) to claims via digital signatures while keeping the original meaning of the claims unambiguous between the various parties in the ecosystem.

As Alan wisely pointed out, the use of the CFO is effectively creating a RBAC based system. This is because the issuers intent of the original credential was designed to be a claims token. This is why I also included the employer number - I probably should have been more explicit about that though. However, the verifier isn't treating the original credential like a claims token, instead it's bending it to be a permissions token. In effect, this bending has unintended side-effects which to mitigate (and by extension build an authorization endpoint that adheres to principle of least authority) requires the hoop jumping during the delegation. In turn, this bending by the verifier requires the holder to mash permissions with claims to make things work. These permissions are a stop gap to convert an RBAC system which isn't well designed for delegation into an ABAC system which better handles it, but also faces the tradeoff of enumerating every permission which is the downside of most ABAC systems. So now, it's not only up to the verifier to do things right, it's also up to the holder to get this right to make a safe authorization system.

As Daniel points out this all happens because, "The complexity of VCs as a delegation mechanism is not an inherent characteristic of VCs, but rather a characteristic of the wrong VC schemas." It's worth pointing out though that the issuer's intention never was to build a VC schema for an authorization system though. Their only intent was to make claims about the subject (via the identifier to digitally bind it). So, yes it is "wrong" in the since that it's not well designed for an authorization system, but it's not "wrong" for what it was originally intended. And this goes to the heart of what I'd like us to acknowledge as a community. VCs are great, but they're not the end all be all solution to every problem. Sure, in a well-defined closed model ecosystems where all parties are getting together to design it, they can be used to build good authorization systems where an ABAC authorization is being well designed with attenuated delegation. More than likely that's not what's happening though. The more common case is likely going to end up on the route I described where the issuer is making claims, the verifier wants to use them in an authorization endpoint and the holder ends up as a translator between them both. Likely for both the reasons Alan and Daniel pointed out - or a multitude of other second and third order effects which aren't predicted by the issuer (or even that I can guess at this stage).

So what do I think we as a community should do about it? Put simply, exactly what you're proposing Rieks. I'd like to see us keep the mental model of VCs simple and well defined to their purpose and instead look to other technologies for permissions tokens. I'd personally propose ZCAP-LDs (as I've done already), because it seems simple and straight forward to build permission tokens with. However, maybe it's not. Maybe there's other simpler ways to achieve the intended goal at hand, in which case I'm open to them as well. Maybe it's just me, but I'd much rather take my time and have a good tool belt worth of tools to build decentralized identity ecosystems with then to go around with a hammer and treat everything like a nail. As a developer, that's what I want so that's what I'm aiming for when I'm contributing to standards.

-Kyle
________________________________
From: Joosten, H.J.M. (Rieks) <rieks.joosten@tno.nl<mailto:rieks.joosten@tno.nl>>
Sent: Monday, June 28, 2021 10:02 PM
To: Alan Karp <alanhkarp@gmail.com<mailto:alanhkarp@gmail.com>>; daniel.hardman@gmail.com<mailto:daniel.hardman@gmail.com> <daniel.hardman@gmail.com<mailto:daniel.hardman@gmail.com>>
Cc: Kim Hamilton <kimdhamilton@gmail.com<mailto:kimdhamilton@gmail.com>>; Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>>; W3C Credentials CG (Public List) <public-credentials@w3.org<mailto:public-credentials@w3.org>>
Subject: Re: The dangers of using VCs as permission tokens


I'm not sure if I've got the gist of this discussion, so correct me if I'm wrong, but it seems to me that VCs are becoming increasingly difficult whereas ease of use (of VCs) is key to adoption. Can we not have VCs remain the simple things they've been from the outset: a 'credentialSubject', i.e. set of claims about one or more subjects (where a claim can be structured as a tree of attributes), enveloped with some meta-data and proofs?



Would it make sense to specify schemes for claims in the credentialSubject field, for specific purposes, e.g. to discuss their merits disjunct from the VCs themselves (but rather as possible payloads)? Would it be beneficial to setup a repo for such schemes where they can be defined and discussed?



Rieks



________________________________

From: Daniel Hardman <daniel.hardman@gmail.com<mailto:daniel.hardman@gmail.com>>
Sent: Monday, June 28, 2021 9:57:19 AM
To: Alan Karp
Cc: Kim Hamilton; Manu Sporny; W3C Credentials CG (Public List)
Subject: Re: The dangers of using VCs as permission tokens



The use case that Kyle describes around delegation seems reasonable -- but I don't agree with the article's suggestion about how this would/could be modeled with VCs. The complexity of VCs as a delegation mechanism is not an inherent characteristic of VCs, but rather a characteristic of the wrong VC schemas. In other words, Kyle's critique might be better summarized as, "If you attempt to adapt complex VCs that weren't built for delegation to a simple delegation problem, you get a lot of baggage that makes it easy to make mistakes." Cue Alan's comment about confusion...

My conclusion would be: "Don't use complex VC schemas to delegate along the lines of the model Kyle warned against."

We had a deep discussion about whether or not to use VCs as OCAPs, facilitated by the chairs of the CCG. I suggest that if we want to explore this topic further, we allocate proper time and focus to it again, rather than touching on it in smaller, less contextualized increments.



--Daniel



This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.