David-Chadwick
commented
5 years ago @cwebber. Concerning 1, the clue is in the name: the data model is about Verifiable Credentials. So I think the purpose is clear from the title. VCs are credentials used to provide benefits and services to the subject (and in some exceptional cases, to the holder).
You don't need a passport if you dont want to travel abroad. You dont need a driving licence if you dont want to drive a car. So by their very nature, VCs are about authorisation, specifically ABAC, RBAC and IBAC in which the authorisation is split into two parts. The issuer grants the credential, and the verifier grants the access based on the credential. The subject would not bother getting the VC if they did not intend to use it for authorisation of some service or other.
Sometimes the issuer and verifier are the same entity (e.g. my supermarket loyalty card), sometimes they are different but work together cooperatively (e.g. the Visa network), sometimes they are independent. So for @cwebber to say that VCs are not addressing authorisation at all is a mis-understanding about the use and purpose of VCs. Based on this misunderstanding flow several other misunderstandings such as:
i) VCs are when "party A said something about party B". Not really, VCs are not for general identity statements such as "David says Chris has white hair". Whilst they could be used for that, they are not primarily intended for that. So please do not imply that VCs will be used for any sort of trivial identity statement, when they are intended to replace today's paper and plastic based authorisation certificates/credentials with electronic ones.
ii) "Whether we trust A, whether that means that B should be able to do things... those are things which are out of scope of VCs." Not really, there is an underlying trust model for VCs which it is critically important to understand. This states that the verifier must trust the issuer (otherwise the VC will be discarded as it is worthless).
Finally @cwebber said "they probably will to build something RBAC like, and honestly I think that's true and even fine. But we don't need to add any structure for that inside of the VC model spec". This is clearly where we have a major disagreement. The whole point in issuing a standard is to provide implementors and users with guidance and rules for how to do things in a sensible, safe and standard way so as to enable interworking. All security experts say that users should not 'roll their own security mechanisms' as they are bound to make mistakes. Even the experts make mistakes, because getting security right is very hard, but when experts work together they can minimise this. Since delegation is a fundamental component needed in many common uses of VCs, then this functionality should be in the base standard and not an extension, and we should work together to do this in the best way we know how.
cwebber
ChristopherA
agropper
burnburn
PR #198 has some bits about delegation for the sake of authorization. AFAICT there are actually two different "delegation" discussions here, and we should address them seperately:
So, as for 1, I think that VC should not be addressing authorization at all. Not everyone in the group agrees that identity-based authorization is safe, and VCs are all about identity. We should keep VCs to being a mechanism where we know that party A said something about party B. Whether we trust A, whether that means that B should be able to do things... those are things which are out of scope of VCs.
Now, I know that @David-Chadwick has pointed out that even if we don't want people to use VCs for authorization, we can't stop them from doing it and they probably will to build something RBAC like, and honestly I think that's true and even fine. But we don't need to add any structure for that inside of the VC model spec. The good news is we're using an extensible model, if you want to add an extension for specifying delegation of authorization, you can do that in a separate spec.
As for 2, I think it's important to recognize that a Holder is just... anyone holding a VC! You don't need to authorize someone to be a Holder, they become a Holder by holding onto that VC. And mathematically, there's no way to prevent someone from copying and sharing a VC with another entity. But it makes perfect sense to express intent that you would not like a VC to be copied and shared. If I have a medical condition and I share it with you, it's perfectly valid for me to say, "don't tell anyone else about this, it's for your eyes only". From a computing perspective, I can't stop you from doing so, though from a social and legal perspective, I may be able to punish you for doing so if I find out (and a well behaving receiving holder may be able to notice, "oops, I wasn't supposed to see this... I'll be nice and burn it and throw it in the trash", but there is no guarantee structurally that such a receiver will be well behaved).
I think that's what terms of service is for IMO. We can make a special property for it if we like, but I think it'll still be a special case ToS.