Representing Delegated Credentials in the VCDM

[decentralgabe]

As per the discussion at TPAC on September 16:

Overview

This issue mostly lays out information. I'm interested in what the community thinks, and moving towards a concrete proposal (with suggestions from you).

Let's define delegated credentials: where a subject assigns a subset of their rights provided by a credential to a new party.

Related To

• Representing Mutli Subject Credentials in the VCDM #931
• Representing Multi Issuer Credentials in the VCDM #932

Prior Art

• How do we support delegation and attenuation of rights? - September 2017
• Review & Clarify Trust Model Section re: No Transitive Trust & Delegated Keys - October 2018
• Subjectnotequal holder - July 2018
• zcap with Data Integrity Proofs
• ucan with Json Web Tokens
• dpop with Json Web Tokens
• transferable non fungible tokens
• non transferable non fungible tokens

Use Cases

• Parent / child relationship representations
• Medical proxy
• Legal representation

What Would It Look Like?

[awoie]

I am wondering whether delegation is a specific case of holder binding where the holder binding can be verified based on a delegation. We are using delegations for this as well where we would include a delegation object (similar to ZCaps) to allow the holder to present specific credential types and/or IDs to a verifier on behalf of the credential subject.

[kdenhartog]

Here's a few quick thoughts to get things started.

Seems odd that the delegateId gets defined by the issuer based on the example I see. This would limit the ability for the holder to determine who the delegate is other than at the time of issuance. The alternative is that the holder returns to the issuer each time they want to get a delegate credential, but that seems like it wouldn't scale very well.

I'd suggest looking at finding a way that the holder can become the issuer of a new credential and defining a method to bind the new credential to the old one.

One point of consideration here is that the semantics of the claims will matter here. For example, most credentials today focus on claims describing who the subject is. In this case we're turning a credential into what it's useful for. In some cases, knowing an attribute about a subject is useful enough to determine authorization such as age, but age is not a delegatable claim.

I'd suggest instead that we look to add a new term here as well such as credentialCapability which focuses the semantics on what the credential is used for and credentialSubject on claims about who the credential is for.

[jandrieu]

I'll reiterate what I said at the TPAC session.

I think there is serious conflation between the literal impossibility of "delegating statements" and the legitimate need for VCs to use statements to delegate privileges.

VCs, as statements, are fundamentally NOT delegatable.

A statement is what it is: an attestation by a knowable author (the issuer) about a subject.

That attestation is a fact. Somebody either made or did not make that statement. It either has or has not be tampered with. And it is either revoked or is still valid.

That's it.

That's all we get for statements. There's no legitimate semantic meaning to delegating a statement. Counter examples are welcome.

Consider the following statements as VCs:

1. State of California says "Joseph Andrieu" was born on a specific date and place.
2. California DMV says Joe currently has a Class C driver's license from the state of California.
3. County of Ventura, CA, says "John Smith" and "Naomi Tanaka" were wed on a particular date and place by a particular officiant with particular witnesses.
4. Bob says Mary is allowed to view his bank account information

The first three are examples of what VCs were designed for. Traditional credentials familiar to most of us: a birth certificate, a driver's license, and a marriage license. None of those are delegatable in any way. One doesn't delegate their birth certificate. I don't even know what that would mean.

The fourth is also a statement, a statement that many would interpret as a delegation. However, that statement itself is NOT delegatable. You can't delegate the statement Bob made. In fact, I can't think of any meaningful way to interpret delegating that statement. I don't even know who gets to delegate it. Presumably Mary. She might want to delegate her alleged privilege of being allowed to view Bob's bank account information, but who is to say that Bob is ok with that? Or if the bank will acknowledge any of that. You could have a second statement "Mary says Anne is allowed to view Bob's bank account information". But that is just a second statement. Even if we could interpret it correctly, it is not a delegation of the first statement. It is a completely separate statement.

However, Bob's initial statement could be interpreted as delegation. And, in the right semantic context, could in fact be used successfully as a delegation. This is after all what a power of attorney does: it uses signed statements to delegate authority. Note PoA is complicated. Even within the USA, there is no standard for Power of Attorney. So, interpretation matters.

This is about the distinction between the envelope and the payload of VCs.

The envelope frames a statement, identifying the issuer, providing a signature, and a modest amount of meta-data about the credential envelope itself.

The payload are those statements that are children to the credentialSubject property. These statements can say ANYTHING. As such, you can absolutely build a system of authorization, including delegation. Such as system could realize use case #4 above, allowing Bob to delegate some privileges to Mary. The challenge with this is two fold: semantics and conflation.

Semantics: Those statements have to be understood by the verifier and the holder, potentially with regard to complicated expectations on the initial purpose of the issuance. In particular, VC#4 is issued by Bob, not his bank. So, who is verifying this statement and what are they doing with it? Is the verifier the bank themselves (as might be typical with a power of attorney) or is it some other party who is looking for documentation about Mary's access to Bob's funds? In this latter case, how would the verifier know that the bank will honor this VC issued by one of their account holders? They can't. The bank isn't even involved in Bob's VC. So, while it is POSSIBLE to bootstrap a delegation mechanism with statements in VCs, any such work would necessarily entail a complete authorization architecture with robust semantics, something that has not yet been specified, much less standardized.

I think it will get done. That kind of work is like any domain-specific claims vocabulary such as vaccination proofs, prescriptions, driver's licenses, and passports. Communities of interest will develop their own vocabulary and deliver that statements using that vocabulary as VCs. I think it'll be more robust and more flexible to use a capability-based delegation approach, but no doubt people will use VCs in this manner.

Conflation: Since VCs on their own don't have any of those semantics it is problematic to view the VC spec as providing those features. Delegations are a payload-level functionality, and should have minimal effect, if any, on the envelope, just like none of the standard technology for the web restricts or mandates any particular kind of website. You want to make a personnel directory, great. Want to make a shopping site or a video service, go for it. Those are application layer designs and decisions, with no impact on ethernet, IP, TCP/IP, http, or even HTML. So, if you want to develop a delegation approach, great. Build it in the claims: just don't mess with the clean semantics of VCs as statements: because that's the heart of what they are: just statements.

When we think of VCs as delegations, and we are talking about changing anything at the envelop layer, we are playing with existential layer violations. What started as a clean structure for verifiable attestations risks barnacle-style feature creep as otherwise well-intended ideas erode the bedrock that makes VCs work.

When done well, the envelope & payload pattern is extremely flexible and durable. Most of the web still runs on the IP datagram formally defined in 1980, over 40 years ago. That's the power we have with VCs: anyone can say anything with verifiable authorship, integrity, and timeliness, without recourse to the original issuer.

When we want to use VCs to create statements of delegations, that's fine. Because you can say anything in the credentialSubject property.

But sticking the semantics of delegation into the VC spec is like sticking the semantics of Twitter into tcp/ip.

Yes, there are ways we might learn to improve the core semantics of VCs, just as we added the "s" in https to support specific use cases. However, since delegating a statement is semantically non-operative, it doesn't make sense to expand the VC spec in this direction.

Fix it at the payload, aka vocabulary level, not at the envelope.

[vongohren]

@jandrieu can you reflect on the most obvious delegateable VC, concert ticket, the same way you do here? It was not mentioned but it is something that can be sold onwards and be delegatable. There are issues with this in regards to mutliple reselling, so maybe it is difficult to achieve

[agropper]

@joeandrieu I agree with much of what you’re trying to say but the conflation I see is due to the introduction of “client credentials” as a concept into the purity of VCs. Adrian

…

On Tue, Sep 20, 2022 at 7:56 AM Snorre Lothar von Gohren Edwin < ***@***.***> wrote: @jandrieu <https://github.com/jandrieu> can you reflect on the most obvious delegateable VC, concert ticket, the same way you do here? It was not mentioned but it is something that can be sold onwards and be delegatable. There are issues with this in regards to mutliple reselling, so maybe it is difficult to achieve — Reply to this email directly, view it on GitHub <#930 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABB4YOVDZHHHZPZTRZWYV3V7FG2JANCNFSM6AAAAAAQOQSBEA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[jandrieu]

@vongohren wrote:

@jandrieu can you reflect on the most obvious delegateable VC, concert ticket, the same way you do here? It was not mentioned but it is something that can be sold onwards and be delegatable. There are issues with this in regards to mutliple reselling, so maybe it is difficult to achieve

Depends on how you model the statement that is the ticket. Because the ticket itself is its own thing. Like any VC, it's always transferable to another holder. The question is whether or not the privileges stated in the VC transfer to some new party through some explicit mechanism.

If the VC says "The bearer of this ticket is entitle to admission to event XYZ on date ABC at location alpha". Then, that's a bearer token and whoever has a copy gets in. No delegation needed. Also, no control on duplication. It's useful for pure viral marketing, but has some obvious downsides for any limited resource.

If the VC says "The person who can satisfy an authentication challenge for did:ex:abc is entitle to admission to event XYZ on date ABC at location alpha". Then, that's a negotiable instrument that requires a signing ceremony to invoke. Without any additional design, there are two main ways to "delegate". The first is trivial but uninteresting: you can share the private keys for satisfying that challenge. This, of course, violates the security premise of modern cryptography, so it is not recommended.

The second is by setting an authentication method in the did:ex:abc DID document for the delegatee's preferred verification method. Unfortunately, that also allows the delegatee to authenticate anywhere that DID might be used, including logging in to websites that have never even seen the VC.

You could augment that design to say "The person who can (a) satisfy an authentication challenge for did:ex:abc or (b) satisfy an authentication challenge for a DID that is the subject of a delegation credential (of type http://example.org/delegationCredential) signed by the attestationMethod of did:ex:abc, is entitled to admission to event XYZ on date ABC at location alpha".

Now we are starting to see the complexity of modeling a authorization as a set of claims. This simple extension already depends on extra third party vocabulary, in the form of a delegationCredential, and, because I tried to keep with the "credentials for everything" motif, uses the attestationMethod for signing the delegation VC. Which is unfortunate, because capabilityInvocation and capabilityDelegation would be more aligned with the actual functionality (but those verification relationships are for capabilities not attestations).

And, even now, we haven't enabled any form of revocation, much less some mechanism for anyone in the delegation chain (the initial issuer or one of the delegators) to add a caveat or even restrict further delegation.

The biggest problem with this example "delegateable VC, concert ticket" is that concert tickets are generally a constrained resource and you must protect against double spends. VCs don't do that. There is no way, within VCs alone, to ensure that there is one and only one delegation. Frankly, this is one of those cases where a "transferable NFT, concert ticket" is a better fit.

In short, the devil is in the details and once you start modeling a real use case with the nuances you need for authorization, you are basically creating an entirely new kind of digital construct, built within the claims (statements) of the VCs.

IMO, you're better off modeling such authorization activity as capabilities, which have support for all of the complexity I just mentioned.

[TallTed]

@jandrieu -- I mostly agree with what you said, but --

That attestation is a fact.

No, that attestation is an attestation.

(It is a cryptographically verifiable fact that the attestation exists, and was issued by the issuer. This is probably roughly what you meant.)

You and your business logic may treat (some or all) such attestations as if they were facts for some purposes, but I think it vitally important that they MUST NOT be short-handed in description or handling as if they were unassailable statements of fact (as still happens too often to lots of RDF and Linked Data that was not constructed with such universal reliance in mind, and can lead to catastrophic failure when, for instance, geo-coordinates of a feature of the Martian landscape are handled as if they were in one of the several(!) incompatible(!) geo-coordinate systems applicable to the Terran landscape).

(I think this kind of unfortunate loose reference is an element of what brings people to think that the VCDMv1, or at least VCDMv2, is ready out-of-the-box to support a full-fledged authorization & delegation toolkit which may even already exist, just under the covers.)

[TallTed]

@jandrieu -- Another nit.

If the VC says "The bearer of this ticket is entitle to admission to event XYZ on date ABC at location alpha". Then, that's a bearer token and whoever has a copy gets in. No delegation needed. Also, no control on duplication.

Various ticketing agencies would disagree with the last sentence of the above quote. Scannable codes (QR, BAR, and other) do quite well (though certainly not perfectly well) at controlling duplication (though I can print 1000 copies of my ticket, if I really care to, the basic enforcement is to prevent a second entry on the same scan code, which may then lead to an usher or superior checking through various means whether the purchase was actually made by the seated person or the later entrant, etc.)...

Just as it's important that we not over-represent the capabilities of what we're building, it's important not to under-sell.

[decentralgabe]

lots of good thoughts in here, let me respond:

@awoie

I am wondering whether delegation is a specific case of holder binding where the holder binding can be verified based on a delegation. We are using delegations for this as well where we would include a delegation object (similar to ZCaps) to allow the holder to present specific credential types and/or IDs to a verifier on behalf of the credential subject.

I don't see why not. If holder bindings make it to the spec, I believe delegated binding relationships could be handled by the construct.

@kdenhartog

Seems odd that the delegateId gets defined by the issuer based on the example I see. This would limit the ability for the holder to determine who the delegate is other than at the time of issuance. The alternative is that the holder returns to the issuer each time they want to get a delegate credential, but that seems like it wouldn't scale very well.

The example is contrived. For all we know there is an interactive protocol by which the issuer requests from the delegate/subject an ID or set of IDs to use or to better understand the relationship. Just focusing on the end state here.

Broadly, I think the question of 'how does an issuer become aware of who they should issue a credential to' is out of scope of the data model itself.

One point of consideration here is that the semantics of the claims will matter here.

100% agreed. We would need normative language to specify semantics, or at the least some non-normative statements with sufficient coverage in the use-case/impl guides. I like your idea for credentialCapability, though I imagine capabilities are a separate concept -- layered onto VCs rather then in them itself 🤔 -- though perhaps there is some leakage here considering "proofPurpose" and other such fields.

@jandrieu

VCs, as statements, are fundamentally NOT delegate-able.

Yes, but there is a concept of an attestable claim, right? And the claimant may be a part of a delegation relationship? If so - the question is how is this to be communicated.

I assumed the data model is the right place, given how it already specifies terms like "subject", "holder, and "issuer", this would be a refinement of what those terms means and how their meaning influences business logic decisions.

The first three are examples of what VCs were designed for. Traditional credentials familiar to most of us: a birth certificate, a driver's license, and a marriage license. None of those are delegate-able in any way. One doesn't delegate their birth certificate. I don't even know what that would mean.

I agree with you here, but I don't believe this is serving your point. Certainly not all credentials can or should be delegated (you wouldn't delegate a car??), but that doesn't mean there are some credentials that can represent relationships where delegation does make sense.

Specifically I'd like to focus on the use case of a health care proxy. There are legal restrictions for how one sets up such a proxy, involving multiple witnesses, following a legal process, recorded on an official legal document.

I can imagine the witnesses (or a court) issuing a credential to Alice attesting that she is a delegate of Bob for her medical proxy. The signature scheme may get complex here, but let's put that aside for a minute. The relationship represented by the credential is legitimate.

Now, I believe you are referring to a different type of scenario. One where Bob has an official "health care proxy" credential and then takes some action to delegate this credential to Alice. I did not intend to address such a use case here and I'd like to state that transferring credentials or altering trust relationships post-issuance is out of scope of this issue.

Let's focus on statements representing relationships of delegation known at the time of issuance.

[decentralgabe]

re: the ticket example @vongohren @jandrieu

this is similar to a use case I've encountered -- signing over a pink slip of a vehicle. I have a credential (pink slip) issued to me by the DMV. I am able to sign over that document to a new party, effectively transferring ownership away from myself.

This I would not consider a delegation use case at all. In fact I think it's a re-issuance application where the DMV has a process set up to accept a self-signed credential from the holder of a pink-slip credential (vehicle owner). Upon receipt and verification of that self-signed transferred pink slip, the DMV revokes the original credential (the title no longer belongs to the original owner of the vehicle) and issues a brand new credential (pink slip, registration, etc.) to the new holder.

Such cases are tangential to my conception of delegation, since the credentials themselves did not initiate with a delegate-ive relationship.