Delegated Credentials = Guardians, Controllers, and Delegates with Any W3C Credential Type

Delegatable Credentials: Guardians, Controllers, and Delegates with Any W3C Credential Type

Wednesday 7B

Convener(s): Daniel Hardman

Notes-taker(s): Daniel Hardman & Gregory Rocco

Tags for the session - technology discussed/ideas considered:

W3C, DIDs, Verifiable Credentials, Delegation

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

#Notes from Daniel Hardman:

Summary: we can implement delegatable credentials on top of any W3C-compatible credential mechanism. We just need to implement some lightweight conventions.

We reviewed this slide deck: 

https://docs.google.com/presentation/d/1NzWB4gyaj43TEYUsTNL4O4-t35x-DP_ubS0YqunN5Rg/edit

*************** *********** ****************** ***********************

Notes from Gregory Rocco:

Notes [bolded includes individuals other than the convener]:

·       j.mp/2pnXqKx

·       Ordinary credentials aren’t easily delegatable

·       Physical credentials (like a driver’s license) – my kids will try to borrow particular credentials like a credit card. They can use my credential but if they get challenged, they can’t assert their position.

·       Verifiable Credentials – it’s not impossible to delegate but there’s no standard yet

o   Can we come up with a standard way to behave with VCs so delegation works right

o   This isn’t ZKP specific

·       One of the things to think about: in an organization (company that needs to give signing authority to three managing directors for example) – you might need delegation. If you think about it as one holistic wallet, you may arrive at an example that might work, but won’t be ideal.

o   Another example isa science organization that wants to delegate pilot and maintenance privileges to other staff members

o   Parents want to delegate medical care decisions to a babysitter for a few hours

·       Isn’t delegation a subset of authorization?             

o   Yes – it’s the process of giving part of your authorization, and part of your responsibility

·       How do you handle consent?

o   Definitely need to think about this in a form of delegation model

·       One thing I want to bring to the table: are we doing this right

·       [Confused Deputy Analogy https://en.wikipedia.org/wiki/Confused_deputy_problem]

o   Fooling someone to give you more authority than you should have

·       Acid Test:

o   There’s a national car rental company which has an office in Houston Texas (subsidiary), and the company buys the cars in the fleet and own them. They have a traditional credential that is a title to a car (they can prove title ownership). They want to give to the Houston office the privilege of operating that car – the privilege consists of (rental, maintenance, selling it, driving it, or delegating further).

§  If you give me a permission with a do-not-delegate, I’m going to just have to share my credentials. Delegate is not a good permission – it’s a “please don’t delegate”

§  There’s an assumption with VCs where you should not be transferring them. I’m assuming that you can prevent transference of credentials.

o   Now, the credential chain delegation starts – then Alice walks into the office and wants to rent the car. Alice receives the drive and delegate credentials (less privileges) with constraints like 7-days and only in Texas. Then Alice goes to a restaurant and gets valet parking where she delegates with “drive” and more constraints.

o   Let’s say the FBI calls up the Houston office and says they believe the person that drove the car last week committed a crime (nobody can drive or touch it). Houston revokes their credentials to Alice, now when the valet comes out, the car doesn’t open the door because the valet doesn’t have authorization

o   If we can solve that use-case, then we’ve solved the delegatable credential problem.

o   What is the use case? Can we lock Alice out?

o   This is generally about any use-case (example: generation of new credentials, or demonstration of existing permissions)

o   You can have delegatable credentials and revocable delegatable credentials

o   If you want to talk about delegatable credentials that don’t support revocation, don’t have the chat here.

o   If the valet puts a scratch on the car, there’s a chain of responsibility

o   Houston office is going to blame Alice.

·       Standard W3C VC with special sauce

o   Field name: `schema` (self-contained)

§  Could be a well-known schema, but you have to have the credential say this is the schema of what you’re about to see so we can be creative about delegation.

o   Field name `delegationProof`

o   Satisfies “proxy credential” conventions

§  What do I need to say about the holder – if you say “this holder has the following biometrics,” you’ve bound it. There are other possible ways. If we are going to say something about the holder that has received the delegated privilege, we need the name to go look for it.

§  Public key isn’t good enough

§  Need to be able to describe the party that did the delegating

§  Then there needs to be a place where you can say the holder has the following role, and here’s the permission model that’s associated with some roles that interact with that so you can derive what the actual authorization is.

§  Need to be able to impose constraints (alice can only do this for x time, days, whatever)

o   Field name `trustFrameworkURI`

§  Needs to be a relationship to define the problem domain. Example – guardianship in a refugee camp – which would have rules like not letting a child leave the camp. Or “every time -this- event happens in a camp, we need to check credentials.”

§  In a car scenario, check them when they leave the lot, check them when they get back, or anything in between.

·       Pulled over by the police.

§  Any given problem domain will have its own framework.

§  How do you propagate new frameworks?

§  If the trust framework evolves: you can probably manage that either way – you can say trust frameworks are immutable in respect to the credential which would be safe, or you can make it a URI with no version number.

§  I disagree, that’s very dangerous

·       My preference would be to lock it.

·       Generally speaking, you don’t want to change the rules.

·       You can also have a Malware attack

·       Couple places where you can change these frameworks, but my question is: do you think the car is enforcing these things?

o   That would be a decision that the trust framework would make

o   Public key of downstream holder

·       Embedded `delegationProof`

o   There’s a simple way that we can do delegatable credentials without fancy fields: simply Alice has a credential in her hand when she gets stopped by the police and Alice can tell them who she got it from. Police calls the office up and checks and wants an email about it. We don’t want to have to do this. The delegation proof field is a way to short circuit all of that.

o   It pre-calculates for whatever point you’re at, what are all the reasons to believe that this is a legitimate chain.

o   The first credential is a car title which generates a presentation that proves ownership which is embedded in the first delegatable credential.

§  This then moves to the next delegatable credential.

§  You missed the best advantage – alice can delegate without asking the car rental company.

o   So the ownership goes downstream. Is there a possibility that each entity can add their own proofs without the upstream entity knowing about it?

§  We’re making assumptions about the problem domain. Or if you get further down the chain, you replace the trust framework.

§  So the assumption is that corporate trusts Houston, Houston trusts corporate,  but there’s no way to enforce Houston from adding things on its own.

§  Everything that Houston does has to be subsetted.

§  So this doesn’t drive control of the surrogates in the chain. Example, national doesn’t want regional to maintain their cars. Regional decides they want to do that so they assert authority themselves

§  Let’s assume everything is defined at the top with all forms of meaning.

§  Let’s say regional wanted to add car-washing – new things (they can just make it up and add it in the chain)

o   [Multiple voice discussion on nuances with trust frameworks]

·       Here’s the point: in an ordinary credential, the reason that someone would accept this is because you trust the root issuer’s reputation. There’s probably a trust framework for large bodies/organizations/types. Only the top organization needs to have some form of reputation – all you care about is whether or not you can follow the lines back to the owner of the vehicle.

o   If at the end when someone is verifying it- I think what’s better is different kinds of credentials, trying to remove definition issues.

o   So there’s another assumption I should make explicit: automated  software doesn’t have to understand every nuance. Human’s evaluate whether something is a valid problem. Guardianship is a human evaluated thing.

o   Trust frameworks can be written with humans involved

·       I don’t dispute guardianship trust frameworks, I think the thing to keep in mind is that there are all of these external mechanisms that we repeatedly appeal to those in order to understand and intemperate what those frameworks mean.

·       RFC104