Delegated authorization & VC distribution

[cwebber]

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:

1. Delegation in terms of authorization, where a VC is being used for an authorization mechanism, and party A wants to allow party B to act on their behalf.
2. "Delegation" in terms of Holder A wants to share a VC with Holder B, but the issuer maybe did or didn't want them to do that. I suggest we call this "distribution" instead of "delegation".

---

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.

[David-Chadwick]

@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.

[David-Chadwick]

@cwebber Concerning 2, "You don't need to authorize someone to be a Holder, they become a Holder by holding onto that VC" This is another fundamental mistake that you are making, based I am guessing, on your first mistake of thinking that VCs are just for holding any old identity statement that anyone can make and hold, rather than their primary purpose (if you read the use cases), which is to replace today's physical credentials and certificates.

So whilst it is true that I could pick up any credit card that I find on the street, or I could pickpocket someone and steal their passport, I am not authorised to hold either of these and indeed I should not hold either of them or pass them off to a verifier. And it is the same for the majority of VCs.

Consequently the verifier needs to be assured that the holder is properly authorised to hold the VC and present it to the verifier.

Now whilst we could say in the standard, that it is out of the scope of the standard how the verifier determines that the holder has the right to hold and present the subject's VC (when the holder is not the subject), this is hardly very helpful to the verifier, and it makes the standard far less useful. Thus it is a fundamental requirement of the standard to help and guide the verifier in determining if the holder, who is not the subject, is the rightful holder. This is the purpose of the various properties given in the Subject NE Holder section.

Likewise we should have properties in the data model that tell the verifier what they are expected to do with the VC that they recieve, and properties in the data model to indicate to a subsequent verifier if the first verifier has broken the trust rules and passed on the VC when not requested to by either the issuer or the holder.

Of course, any issuer or subject that does not care who holds or sees or presents a particular VC to any verifier, can ignore all the properties that the data model provides, and can revert to your model in which anyone can hold any VC and present it to any verifier. So we are not ruling this out, but rather acknowledging that this is a less useful use of VCs.

[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).

VCs are a mechanism for assuring that party A said B about C. We aren't using "verifiable claims" because it's confusing people, but IMO the biggest confusion is the combination of those two words together as meaning "verifying that a claim is true" rather than "verifying that a claim was made by this party", which IIUC is the main reason for the rename back to credentials. I'd assert that VCs allow you to make all sorts of claims, some of which might not be credentials, but we've been stuck repainting that bikeshed so many times that this is the term we ended up with.

Everyone in the group agrees that we should be able to assert that a person has eyes with the color blue on their drivers license. Is this itself a path to authority? Hopefully not, but it's useful to be able to verify that the DMV made this assertion in many situations.

Having a credential is not immediately power itself, but it may be a path to power. As many young graduates know, getting a college degree does not immediately give you a job. But it may be a path towards receiving a job, and thus being able to take actions on part of your employer.

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.

I agree, this is the major source of disagreement. Currently all VCs are modeled to do is to provide a way to verify that party A claimed B about C. That's a very useful thing to do.

The question is whether or not we should add an authority structure beyond that. The way VCs are built, it is absolutely possible to layer another structure to build RBAC / ACL style systems on top of VCs. You want to do this, and I support that you should be able to do it, even though I think ocaps are a better and safer way to handle authority. But I don't think we should add an RBAC / ACL style authority system to this spec. I think a new spec should be defined that makes that decision built on top of VCs (after all, VCs are useful in their present form, but you are right in that people will inevitably build an RBAC / ACL style system on top of them).

If you want to build such an RBAC / ACL style extension, I will even be happy to review and help you make be the best RBAC / ACL system it can be. Then we can take the decision as to whether the ACL model or ocap model is the best authority model into the real world, and see what works best. But let's not add that authority section to this spec.

[ChristopherA]

I will not be able to attend meeting tomorrow on topic of delegation (as we've had to cancel CCG call due to travel).

However, I'm definitely against having authorization be in scope for this version of our spec. I do believe that credentials will be key part of any authorization scheme (aka "A said B about C") but I do not believe that credentials should be conflated with authorization. This is one of the biggest challenges of legacy identity architectures and we should not repeat it.

[agropper]

+1 to Christofer Allen In HIE of One, for example, the authorization standard is UMA2 and the identity standards are either DID or OpenID Connect. Or, to put it another way, I see no alternative standard to UMA/OAuth when it comes to authorization but on the identity side there should be compatibility between federated and self-sovereign so that the subject can whitelist whatever style of trust. Adrian

…

On Mon, Jul 30, 2018 at 8:17 PM, Christopher Allen ***@***.*** > wrote: I will not be able to attend meeting tomorrow on topic of delegation (as we've had to cancel CCG call due to travel). However, I'm definitely against having authorization be in scope for this version of our spec. I do believe that credentials will be key part of any authorization scheme (aka "A said B about C") but I do not believe that credentials should be conflated with authorization. This is one of the biggest challenges of legacy identity architectures and we should not repeat it. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#204 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAIeYRBIZfvgrd_kPrF2IL2nmOSiJ-zeks5uL6IIgaJpZM4VW7kC> .

-- Adrian Gropper MD PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: https://patientprivacyrights.org/donate-3/

[burnburn]

This needs TPAC time. Chairs will schedule.

[burnburn]

From TPAC:

• Text needs to be added to assert that the VC data model is not by itself an authorization framework
• Discuss and decide whether or not ToU is removed

Note related to issues #224, #234, #251, and #252.