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.