Closed decentralgabe closed 1 year ago
awoie
commented
2 years ago 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
commented
2 years ago 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
commented
2 years ago 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:
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
commented
2 years ago @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
commented
2 years ago @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 https://github.com/w3c/vc-data-model/issues/930#issuecomment-1251875098, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YOVDZHHHZPZTRZWYV3V7FG2JANCNFSM6AAAAAAQOQSBEA . You are receiving this because you are subscribed to this thread.Message ID: @.***>
jandrieu
commented
2 years ago @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
commented
2 years ago @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
commented
2 years ago @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
commented
2 years ago 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
commented
2 years ago 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.
kdenhartog
commented
2 years ago 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.
Good call out. That reminded me that I tend to bias towards pushing things into the data model layer rather than solving at the protocol layer for the broadest applicability, but that's certainly not a requirement.
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 :think: -- though perhaps there is some leakage here cnosidering "proofPurpose" and other such fields.
I've traditionally argued that keeping capabilities semantics separate is the better way of approaching this problem. Mainly because I would expect many developers who only look at examples to not truly understand the nuances here in the way that wouldn't inadvertently lead to vulnerabilities when verifying the data and making an Authz decision. This would be similar to RPs not checking signatures or not checking expiration times in JWTs when using OAuth2 which can lead to some nasty application logic bugs.
While it is certainly possible to do this inside a VC, we should first be careful to consider whether combining these semantics is useful and also consider how we can outright eliminate or at least deter those types of application bugs. They'll always still exist if an implementer makes a mistake, but how we describe this will make a pretty big difference on how common these mistakes will occur.
I'd assume that @msporny and @dlongley would also probably be -1 to this approach as they tend to lean into the KISS and encapsulation principles with their code, but I'm not certain if they'd outright object to it.
FWIW, doing this is probably going to be a pretty big undertaking here as well since much of the terminology from the zcaps spec don't look like they'd lend themselves well to a lift and shift of the semantics already defined there. Combine that with the difficulty to achieve consensus on a topic like this and it seems like something that's going to lead to a lot of horsetrading and teeth gritting to get something like this through. Just my $.02 as a bystander these days.
RieksJ
commented
2 years ago Here and here are descriptions of what delegation seems to typically mean (the difference in the descriptions being the responsibility/accountability involved).
A delegation/mandate is about rights and/or duties (to do something/get something done). Hohfeld's model on rights/duties has been used for over a century, so I'll take it as a given. Paraphrasing Hohfeld, a right/duty is a two-party thing, where one party has a right towards the other party, implying that this other party has a corresponding duty to enable/allow the first party to exercise this right. And conversely: where one party has a duty towards the other, this other has a right towards the first to have this duty executed. A right/duty thus come in 'pairs', and has to do with the execution of (a set of of) actions.
A mandate/delegation is a three-party thing about (a set of) rights/duties, where the right/duty of one party (towards a second party) is transferred to a third party. While it is typical that the first party does this transferal (for which it must have appropriate rights/duties, but let's skip that here), a mandate/delegation must be interpretable and verifiable by the second party.
That's what's often forgotten. If a mandate/delegation is created in the form of a VC that the first party issues to the third party, that can only be practical if the second party can interpret and verify that VC. Typically, this would imply that the second party should get to define the structure (schema) of that VC, which the first party would then need to be able to issue instances of to the third party, such that the latter can use it in an interaction with the second party (that would then know what needs to be done).
It also means that there is no necessity to develop any technology other than what we need for your generic VCs.
P.S.: Note how similar this concept works to what is also often referred to as 'permission', 'consent', 'authorization' etc. In my current thinking, they can all fit the same single concept.
msporny
commented
2 years ago @kdenhartog wrote:
I'd assume that @msporny and @dlongley would also probably be -1 to this approach as they tend to lean into the KISS and encapsulation principles with their code, but I'm not certain if they'd outright object to it.
You know us well. :)
I expect that we'd object to overloading the VC data model with authz and cryptographic delegation semantics.
It can be done -- in the same way that a JWT can hold any digitally signed information, but as you said, the JOSE/OAuth/OpenID community has gotten in trouble in the past by overloading JWT semantics. We have lessons to learn from how that has unfolded. One could assert that the whole reason PKCE exists is because the core data model was abused to do something it was never meant to do, thus creating security vulnerabilities that required the creation of PKCE.
I'm still concerned that we continue to talk past each other on this topic. There are the VCs that you can use to prove that you should have a certain right delegated to you, and then there is the authorization token that you use to execute on those delegated rights (including delegating those rights further). The first problem space has to do with VCs, the second one has to do with access tokens and/or capabilities. Conflating the two creates footguns.
The links that @RieksJ points to above about mandate and delegate definitions clearly highlight this almost complete disconnect between the legal definitions and the technical definitions. It's no wonder that we keep going around in circles -- some of us are talking about legal concepts (which are purposefully left up to interpretation by business processes and the courts) while others are talking about technical concepts (which are purposefully NOT left up to interpretation and MUST be interpreted in one way by computing systems that are enforcing those technical concepts).
@RieksJ wrote:
It also means that there is no necessity to develop any technology other than what we need for your generic VCs.
This is the point of contention; the statement has been rejected repeatedly over the last several years. There are at least two questions that some people keep not addressing: 1) Are we talking about expressing the legal concepts of mandate and delegation in a VC? and/or 2) Are we talking about expressing the technical concepts of authorization and delegation in a VC?
The answer to question 1 remains fuzzy, but seems to be what the people arguing for "expressing delegation in a VC" are talking about (such as the "non-transferrable" property for a bus ticket or an "I'm an authorized party on a bank account")... those are fine VC use cases. The answer to question 2 clearly has two camps -- "Repurpose VCs to perform authz and cryptographic delegation", and "Don't do it, that's a footgun". It's question 2 that people seem to be objecting to.
What would really help this conversation is if the "model delegation as a VC" camp would start producing a few examples of what such a thing would look like as a VC (Gabe's example is a good start, but is definitely not workable because it is a textbook example of a confused deputy -- there is no expression of which resource or actions are being delegated). We already have examples of what a ZCAP/GNAP looks like (and have had those for years).
msporny
commented
2 years ago Thinking out loud here, so this idea might be fatally flawed -- if we are worried about people abusing the VC Data Model for capabilities, we might want a new cryptosuite that only covers ZCAPs (or whatever capability mechanism there is) called something like zcap-2022, which MUST check the expected capability fields. We'd do that to prevent some hapless developer from using off-the-shelf VC or DI tooling to check the validity of a ZCAP. In reality, there are probably already enough security layers in place to prevent someone from using a DI library to secure an endpoint that needs ZCAP authz... but as we all know, developers can do some terrible things when they try to home-brew security solutions.
Food for thought, just throwing that into the ether while the idea is fresh in my head.
decentralgabe
commented
2 years ago @msporny
The answer to question 1 remains fuzzy, but seems to be what the people arguing for "expressing delegation in a VC" are talking about (such as the "non-transferrable" property for a bus ticket or an "I'm an authorized party on a bank account")... those are fine VC use cases. The answer to question 2 clearly has two camps -- "Repurpose VCs to perform authz and cryptographic delegation", and "Don't do it, that's a footgun". It's question 2 that people seem to be objecting to.
Agree here, let's get solid on this distinction and just focus on 1. 2 is clearly out of scope for a data model.
What would really help this conversation is if the "model delegation as a VC" camp would start producing a few examples of what such a thing would look like as a VC (Gabe's example is a good start, but is definitely not workable because it is a textbook example of a confused deputy -- there is no expression of which resource or actions are being delegated). We already have examples of what a ZCAP/GNAP looks like (and have had those for years).
Can you help me understand this a bit better? The resource/actions that are being delegated are defined by the law, and clarified by the link above on the American Bar Association site:
A "health care proxy," sometimes called a "health care surrogate" or "durable medical power of attorney," is a durable power of attorney specifically designed to cover medical treatment. You appoint a person and grant to him or her the authority to make medical decisions for you in the event you are unable to express your preferences about medical treatment.
Having a credential represent this relationship would allow the delegate to present a verifiable document representing this relationship, which can be attested to by the patient and a couple witnesses or whatever is legally required. Having the proper issuance scheme (set of signatures) would insure this is not a confused deputy problem.
RieksJ
commented
2 years ago As @msporny, I also object to overloading the VC data model with authz and cryptographic delegation semantics. A VC data model should focus on its core, which roughly is:
I,is the party that is certified by certificate,<certificate, issued by an accredited certification agency>), or (subject,is a party in marriage certificate,<marriage certificate>).integer - take a date and turn it into something that proves that date + integer years is smaller than today's date. It also covers signatures. Under this topic, you may want to discuss whether or not to support the functional encryption of attributes (enabling methods that can enforce that attributes can only be interpreted by parties (in the role of holder/verifier) that satisfy some policy of the issuer)Everything that has to do with content/semantics of claims should be out of scope of the VCDM. The place to be for that is the specifications of claims-types (or VC-types), i.e.: schema's, which are typically to be specified in/by/on behalf of 'the business' (which includes legal business). VCDM is, and should remain, a technical spec.
The way I see it is that we should not present use-cases to argue we need this or that extension. Rather, use-cases should be discussed in the use-cases document, where you explain how the current VCDM offers ways in which the use-case can (or cannot) be done. When there are several use-cases of which there is consensus about their relevance, which cannot be done in the VCDM (in a sufficiently practical way), but could be done if some technical feature were added, then that would be acceptable as a proposal for introducing a new feature.
Consequently, I think that any further discussions about mandates, delegation, guardianship, authorization, permissions etc. should be moved to the use-cases repo, properly described/documented there (and if I had it the way I like it: also grounded in solid conceptual thinking).
kdenhartog
commented
2 years ago 1) Are we talking about expressing the legal concepts of mandate and delegation in a VC? and/or 2) Are we talking about expressing the technical concepts of authorization and delegation in a VC?
Ahh this is a good delineation I've not caught until you pointed this out. I almost always assume we're discussing delegate in the technical sense not the legal sense. I think it makes sense to leave the technical considerations out of scope.
As for 1, this seems like it's a great example of a holder !== subject case and having some examples here may actually help to achieve better consensus on the topic.
Here's an idea to toss out there as to a way to represent this:
A use case where the issuer also acts as a custodian of the data
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "http://example.edu/credentials/3732",
"type": ["VerifiableCredential", "UniversityDegreeCredential"],
"issuer": "https://example.edu/issuers/565049",
"issuanceDate": "2010-01-01T00:00:00Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"degree": {
"type": "BachelorDegree",
"name": "Bachelor of Science and Arts"
}
"credentialHolder": "https://example.edu/issuers/565049"
}
}A use case where the subject == holder
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "http://example.edu/credentials/3732",
"type": ["VerifiableCredential", "UniversityDegreeCredential"],
"issuer": "https://example.edu/issuers/565049",
"issuanceDate": "2010-01-01T00:00:00Z",
"credentialSubject": {
"id": "did:example:subject",
"degree": {
"type": "BachelorDegree",
"name": "Bachelor of Science and Arts"
}
"credentialHolder": "did:example:subject"
}
}A use case where the subject != holder
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "http://example.edu/credentials/3732",
"type": ["VerifiableCredential", "UniversityDegreeCredential"],
"issuer": "https://example.edu/issuers/565049",
"issuanceDate": "2010-01-01T00:00:00Z",
"credentialSubject": {
"degree": {
"type": "BachelorDegree",
"name": "Bachelor of Science and Arts"
}
"credentialHolder": "did:example:custodian"
}
}Then, by separating out the holder into it's own separate category it also allows us to more strongly couple the proof property to the actual holder of a credential in a way that we can have strong normative definitions of logic in terms of how to verify a VP when it's being presented later.
Some questions that would emerge for me on this are:
credentialHolder property?jandrieu
commented
2 years ago @kdenhartog We must still be talking past each other.
The holder is a functional term. It is, by definition, whoever holds the serialized form of a VC.
As such, it is a mistake to attempt to identify, in the VC itself, who the holder is. Because it is only ever true by happenstance. It's not possible to know who holds a VC at the current moment except by proof of possession. If they can deliver the VC, they are the holder. Regardless of what the VC itself says.
I think what you are trying to encode is a restriction on the use of a VC. Whether or not we call that Digital Rights Management (DRM) or censorship, neither have any place in VCs. Statements are not delegatable. The issuer of a VC does not get to dictate how that VC is used. Period.
It's up to each verifier to decide what business rules apply when interpreting the statements in a VC. It is not up to the issuer to decide who gets to use the VC for what purpose. The latter is "validation" and leaves the ultimate decision up to the verifier. The issuer has already played their part at the point of issuance. The holder plays their part creating a VP. There is no role here for the issuer to constrain usage except through revocation. Restricting the use of statements would make about as much sense as issuing a statement that "The Guardian asserts Charles III is King" but restrict it so that only official recipients of that message get to use it.
As statements, VCs simply are. They are verifiable vis-a-vis authorship, tampering, and timeliness. They can be referred to and refuted. And they can be transmitted by any digital medium.
What they can't do is be delegated. The Guardian can't delegate its statement about King Charles any more than they could delegate a statement made about yesterday's weather.
What you want, I think, is better described by @RieksJ as
The place to be for that is the specifications of claims-types (or VC-types), i.e.: schema's, which are typically to be specified in/by/on behalf of 'the business' (which includes legal business). VCDM is, and should remain, a technical spec.
Creating vocabularies of claims that express authorizations, delegations, revocations, etc. is a fine goal. We need such vocabularies. We'll almost certainly need many of them.
What we don't need to do is treat statements, as made verifiable by VCs, as anything other than just statements. We will have a hard enough challenge ahead keeping the data and security models intact with that simple, narrow focus.
kdenhartog
commented
2 years ago @jandrieu I don't believe we're talking passed each other here, I think we just have a different set of principles guiding our views. From my understanding you want to keep this aspect undefined as you believe that this is going to act as a mechanism for censorship. However, the reality is the market wants this capability and defining that the spec shouldn't define this on a principled stance won't stop it from being shipped. There's been numerous conversations with customers in the past who've requested this capability as it is a mechanism for reducing risk.
They're concerned that without limitations around transferability and clear provenance chains of the data between the time of issuance to the time of verification that there's the possibility of malfeasance which could invalidate the integrity of the statements made by the issuer. By establishing clear methods of delegating a credential we're establishing clear methods validating the arbitrary claims that exist and what sorts of security protections were used to maintain the integrity of the claims.
The point I was trying to make here is that in order to actually achieve this chain of provenance we need to delineate the holder from the subject as the conflation currently has caused confusion about how businesses should be validating these claims. Hence the continued conversation about the separate purposes of a holder and subject and the need to keep rehashing this long standing debate.
I agree with you that it's the businesses job to define the specific logic of the claims. They are domain specific so it's not something we could define anyways. However, for claims that are applicable enough to any use case, such as a holder generating a verifiable presentation, it makes sense to address these low hanging fruit in a standardized way.
RieksJ
commented
2 years ago @kdenhartog I'm curious to find out what the actual use case is you have in mind.
I'm not convinced that the market at large is asking for "this" (not sure what you're referring to). I do know that in actual cases, customers tend to ask for (preferably technical) things that they think might solve their problems, whereas if you get them to think about it, it often turns out that is not a real solution, or there is a (better) alternative. As it happens I've recently been asked by a customer that is part of the national registration for vehicles to help them come to grips with what they call the mandate/delegation stuff involved. It has nothing to do with technology (yet), and I'm convinced when it comes to that, the current VC stuff has all we would need.
I would really like to see a concrete case that proves me wrong.
RieksJ
commented
2 years ago @jandrieu At risk of changing the topic of this issue (which is not my intention): I can think of cases where issuers do need/want to restrict the verifier-audience that can read (claims in) credentials that they have issued.
One example is that the Netherlands has a law that restricts the use of the BSN (the Dutch equivalent of the US SSN), basically to be used within the context of government, health and banking processes. Compliance to that law would benefit from a capability that would allow issuers create VCs where this attribute was 'for their eyes only'.
Another example (that needs to be worked out better perhaps) might be that in a voting scheme, voters could issue VCs that would limit visibility of their vote to the body that collects and counts them (functional cryptography would allow this to happen. It would even make it possible that this body would only be able to see these votes after the ballot has closed).
I acknowledge that this can also be misused. For example, a maffia capo could issue a VC to a subordinate that (openly) says that its bearer must be paid 1M, and also contains a 'for your eyes only' attribute that only the financial guy can read, that states "kill the bearer of this VC".
kdenhartog
commented
2 years ago Covid Passes had this exact problem. When an issuer issued a covid pass it was possible for a user to hand their covid pass to another person and if the validators process didn't do an additional IAL check (confirm the person in front of them is the subject of the covid pass via a secondary DL with a photo) then it was possible to bypass the checks in a semi legitimate way. For example, this could have been done by printing a second sheet of paper. Since many of the validators didn't understand (or found it too cumbersome such as a restaurant) that they needed to perform this additional check then one person could provide passes to many people. So how do you solve this from an architecture point of view?
Webauthn does something to address this via attestations that are defined in the spec as attestation formats where a validator can request the authenticator (basically the device that holds the key) to attest that the device is valid and the key hasn't been tampered with. So this is a second example of how it can be used.
mDLs are likely going to end up down this path as well where not only do you need to provide integrity protection of the claims, but also of the devices that store them in order to have provenance that the claims haven't been transferred. This is so that the check can be fully automated based on AAL checks rather than the validator needing to re-validate the IAL checks done by the issuer.
Now @jandrieu point here aligns very well with the debate that occurred with DRM. It boils down to, It's my device, I get to decide what runs on it and there should be legitimate ways to achieve this if I don't want to run your software. There's a good principled stance in this argument and I get where it's coming from. In fact, I tend to lean towards that opinion. However, I also acknowledge that the whole business model behind claims based authz (including with OIDC) rests on the assumption that validation only needs to be done once by the issuer and then the validators get to take the easy automated way out because all the costly checks were done up front. However, that model is broken with the VC model unless the holder can provide the assurances that the data has been maintained in a trusted manner. Enter the FIDO alliance who does this for Webauthn authenticators and collects $ for auditing and verifying the devices did it properly and maintaining a list of trusted authenticators.It's basically the CA model business model all over again, but for user devices rather than servers.
My point to this is, this capability is here to stay as the cats out of the bag in so many other ways[1][2][3] already. Rather, this is a feature that's necessary for VCs to maintain feature parity with already built systems and as such should be included. It's clear it's technically possible. Do I like it... no not really but it's the realistic situation we're faced with. In fact, my biggest worry is that by making it so easy for validators to automate checks, and incentivize issuers to issue credentials for every thing under the sun (via a generic open world claims model), we could end up with a day where retail stores don't allow you to enter unless you use trusted device X and can prove you've never been arrested for shoplifting. It would suck to see this happen, but if we want to limit these things we have to take the principled arguments like this to the legal arena and sort it there. Not have them here otherwise we risk the VC data model falling behind to alternative approaches like mDLs which will expand beyond just DLs eventually and ship with this sort of feature to attract high value credentials to get issued in that format rather than VCs. At least if we can get the VC data model to be the dominant (not only) format used in this space then people in our community can help influence these legal conversations later with greater legitimacy as the technical experts. If we can't achieve that, then we'll always be the players who live in glass houses throwing rocks at the Google/Apple fortresses.
RieksJ
commented
2 years ago @kdenhartog Thanks for clarifying and mentioning the COVID-pass example.
Applying the case to the VCDM context, it is my view that this is another example of the issue I tried to convey in #760: if you see a claim within a VC as a (linked-data) tree, with nodes and edges, where subjects and objects are represented by nodes, and predicates by edges, then I think it is very useful if verifiers were able to link the real-world entities that a node represents to an actual real-world entity. It would allow me to present a COVID-credential for my kid, which the verifier then see and verify as belonging to the little person at my side.
Note that while such situations typically arise in contexts about guardianship etc., they are not limited to such use-cases and should also NOT be confused with that. Guardianship, delegation, mandates, ownership and any other kind of relationship between two entities are business stuff. They belong at the business/information level (that defines what kinds of relationships there are, their semantics, etc.).
What, in my opinion, DOES belong in VCDM, is the discussion of whether or not to specify a construct that can optionally be applied to every node in a claim, and that enables the specification of methods that (human or machine) verifiers might use to identify and authenticate the real-world entity to which that node refers, as per #760. And similar to the signature/proof mechanisms, we can perhaps specify a minimal, yet extendable set of types/methods that issuers can decide of whether or not to populate, and verifiers could choose from. That would also really help in the offline use of wallets, as required for (upcoming) EU ID Wallets.
kdenhartog
commented
2 years ago -1 from me on turning this into a graph theory problem. I don't believe we need that level of abstraction to achieve the goals of the use cases you've descrived. We can barely get people to understand JSON-LD right, let's not turn VCs into academic shelfware.
RieksJ
commented
2 years ago It's not a graph theory problem per se. You could also see it as a more general solution to your proposal to add the credentialHolder field, which as I see it would then be replaced by a construct that specifies one (or more) method(s) that (human or machine) verifiers might use to identify and authenticate the real-world entity to which the subject of the claim refers.
I wholeheartedly agree that we shouldn't turn VCs into academic shelfware, and I think we're very far from doing that. However, the lack of education that 'people' demonstrate by not understanding JSON-LD right should not imply that we only standardize stuff they do understand. It's like crypto: we should do the right things, and do them right as well. People that have trouble understanding should educate themselves, or leave it to others that are.
jandrieu
commented
2 years ago @kdenhartog wrote
From my understanding you want to keep this aspect undefined as you believe that this is going to act as a mechanism for censorship. However, the reality is the market wants this capability and defining that the spec shouldn't define this on a principled stance won't stop it from being shipped.
A minor nuance: "this aspect" is not undefined.
The holder is defined. It is whoever holds the credential.
It has nothing to do with what any property in the VC says, which is why holder as a property is a intentionally not defined.
Your proposal is like spraypainting a "Baby on board" sign onto your vehicle because you think that will communicate to people that there is a baby on board. It won't. Because people will realize the sign is not reflective of the actual state of the vehicle. It's indicating a baby regardless of the facts in the moment.
This is the same problem. The holder is not defined by a property in the VC. That is an impossibility.
That's where I think we are talking past each other.
The fact that, IMO, you are asking for a feature would both restrict the flow of information and create a false sense of assurance is an different kettle of fish. We can debate the politics another time.
My argument is ontological.
The holder is a fact, unchanged by any property of the VC. The actual holder at any point in time is fundamentally unknowable at the point of issuance.
It would be a bad idea to add a property to the VCDM that is fundamentally unknowable at the point that VC is minted. Since the primary verification of VC integrity depends on the an absence of tampering, you also can't change it to reflect the actual holder after it is issued.
TL;DR:
As for the rest of your argument:
They're concerned that without limitations around transferability and clear provenance chains of the data between the time of issuance to the time of verification that there's the possibility of malfeasance which could invalidate the integrity of the statements made by the issuer.
I disagree with this conclusion. The statements contained within the VC have an integrity that is a separate matter of fact than whether or not those statements apply to the current presenter. If my kid brother presents my driver's license to buy alcohol, that says nothing about the integrity of the driver's license's attestation that Joe Andrieu is licensed to drive (and has reported certain biometrics and here's his photo). Those statements retain their integrity as long as the VC isn't tampered with. It's the presentation's integrity you are concerned about.
[I'll note that your language here does give me an opportunity to maybe find a way forward.]
By establishing clear methods of delegating a credential we're establishing clear methods validating the arbitrary claims that exist and what sorts of security protections were used to maintain the integrity of the claims.
No, we would not establishing clarity. Adding a property that CANNOT be accurate does not establish a clear method for validating anything.
The point I was trying to make here is that in order to actually achieve this chain of provenance we need to delineate the holder from the subject as the conflation currently has caused confusion about how businesses should be validating these claims.
You presuppose that there is some chain of provenance that is knowable. It isn't. VCs do not, on their own, provide provenance or traceability. They simply memorialize a statement made at a particular point in time by a particular issuer.
I agree with you that it's the businesses job to define the specific logic of the claims. They are domain specific so it's not something we could define anyways. However, for claims that are applicable enough to any use case, such as a holder generating a verifiable presentation, it makes sense to address these low hanging fruit in a standardized way.
I'm not sure what claims you think are "applicable enough to any use case". Because the holder property--even as you proposed it--is not a claim.
Perhaps more to my point: low hanging fruit is not that which
That said, let me return to the ray of hope from your comments:
holder generating a verifiable presentation
THIS is where I do believe we have significant opportunity for improvement.
Currently the best practice for the identity binding you are looking for is a two-phase DID Auth process. First prove control of the subject DID before issuing, then prove it again when creating the Verifiable Presentation. This is described in Section A.1 https://www.w3.org/TR/vc-data-model/#credential-subject-0
At the moment, this is the only mechanism for relating the creator of the VP (the holder) with the subject of the VC.
I've proposed in #860 that we standardize a better way for relating the VP creator to the statements made in the claims. This is where I believe we can standardize some common patterns for validating that the holder is the right party for the current interaction. For example, we don't currently make an explicit assertion that by creating a VP, the holder is attesting to being a subject of any particular VC. It's implied. Which I think is a disservice.
What we probably want to do is have a view common ways for the presenter to establish their relationship to the claims. For example:
Approach #1 & #2 make explicit what we already support implicitly. Approach #3 is where you could, if you wanted, put as many statements of authorization and delegation as you please, with room to explain exactly what's going on. It still has the open-world semantics and the actual vocabulary needs definition for any hope of interoperability, but it is at least at the right place in the flow for the holder to explain why they are presenting the claims they are.
jandrieu
commented
2 years ago @jandrieu At risk of changing the topic of this issue (which is not my intention): I can think of cases where issuers do need/want to restrict the verifier-audience that can read (claims in) credentials that they have issued.
Yes. Lots of authorities would like to restrict what people do with the information they create. Secret warrants. Secret evidence. Secret proceedings.
If you want to keep it secret, don't put it in a VC that you give away to a party outside of your control. There are plenty of mechanisms to restrict data flow.
VCs aren't one of them.
One example is that the Netherlands has a law that restricts the use of the BSN (the Dutch equivalent of the US SSN), basically to be used within the context of government, health and banking processes. Compliance to that law would benefit from a capability that would allow issuers create VCs where this attribute was 'for their eyes only'.
Compliance is not a technical justification. To wit: compliance with laws would arguably be enhanced if all activities were surveilled 24x7 in all locations. Fortunately, society largely acknowledges that complete surveillance would be an unconscionable violation of privacy, a policy so egregious we have extensive legal protections and processes that protect our rights despite the fact that these same processes necessarily make compliance harder to enforce.
So, yes, people want to control information. I get it. There's much value to be had in information asymmetry.
However, that doesn't justify embedding systemic restriction of the flow of information in the VCDM. This is a problem to be resolved at the legal institutions, not the technical ones.
msporny
commented
2 years ago @RieksJ @decentralgabe @kdenhartog -- now we're getting somewhere! I hope :P ... I think we're agreed that cryptographic delegation for the purposes of authz (zcaps, gnap, etc.) are out of scope for VCs (even though it is possible to model that in a VC -- the dangers of misuse are too great). Hooray! Now all we need is for @swcurran, @awoie, and @David-Chadwick to weigh in to see if they agree. :)
It also sounds like there is a strong argument for NOT establishing a censorship-enabling mechanism in the VC Data Model that would restrict the holder from presenting a VC anywhere (if they really want to do that).
It does sound like there is some sort of business-layer data that a subset of us want to include in a VC that is advisory to a Verifier as to what the Issuer intended in a way that is "just more claims the issuer is making". For example, the Issuer can scream that a VC is non-transferable until they're blue in the face, but it's really up to the Verifier if they want to enforce that or not if a Holder hands the VC over to them. Some are calling this holder, intendedHolder, or delegate... it's advisory information to the Verifier (but MUST NOT result in spec language stating that it's always illegal for a Holder to violate that advisory information). This, I believe, helps us avoid what @jandrieu has clearly articulated as an authoritarian area that we must not memorialize in any technical specification.
The phrase "delegate" is helping us here, because while that's happening at the "business layer", as @RieksJ put it, it's nebulous, easily misunderstood to mean other things, is highly use case specific. It's a bad word that has led to years of misunderstanding, IMHO.
Perhaps @kdenhartog is on to something here when he mentions "assurance levels". Maybe that's all we need here, IIUC. When an issuer states "This is who I issued the credential to", what they're really asserting is that "I did some level of identity assurance when I issued the VC, and here is what I did". Perhaps they only checked to make sure the Holder could perform DID Authentication, or perhaps they saw the Holder in person and did a physical identity check against their own records, or perhaps they did some form of Turing test? These use cases have typically fallen into the evidence property... but as everyone knows, that's poorly defined in the specification at present.
So, all this to say, is what we're talking about here advisory information from an Issuer to a Verifier around what they believe constitutes a legitimate Holder of the VC? Can it be boiled down into an "Expected Identity Assurance Level"? The Holder and the Verifier are free to completely ignore that information if they see fit, right? Does that strike the right balance wrt. @jandrieu's concerns around abuse?
msporny
commented
2 years ago -1 from me on turning this into a graph theory problem. I don't believe we need that level of abstraction to achieve the goals of the use cases you've descrived. We can barely get people to understand JSON-LD right, let's not turn VCs into academic shelfware.
Manu lols.
I agree with @kdenhartog. We have to a find a way to solve all of these problems without falling into the "just use a semantic reasoner" trap. :)
There's a fine line between "just enough semantics to solve the problem" and "so much reliance on semantic theory that 99% of developers will be unable to use the solution".
This is why I (and Dave Longley) were arguing for "JSON-LD compatible JSON" as the data model for VCs... we don't want to fall into the trap of saying "VCs are directed graphs formalized as RDF and you can use any RDF syntax, including JSON-LD expanded form (and/or any directed graph or labeled property graph syntax)" -- this technology needs to remain accessible to a large subset of developers, and as @kdenhartog said, we're having a hard enough time as it is teaching developers the current set of concepts.
All that said, I don't think anyone is suggesting we tell developers that they need to understand graph theory to find VCs useful... though, the implementers of VC software libraries might not be able to escape learning more than they'd like about the fundamentals in order to make sure they're getting their implementations right. :)
agropper
commented
2 years ago @joeandrieu You seem to be arguing for the same thing as I am which is also consistent with Anil’s perspective in the OWF thread https://lists.w3.org/Archives/Public/public-credentials/2022Sep/0202.html
Paraphrasing Anil about how to handle VCs: A The subject’s choice of digital or physical credential B Eliminate “phone home” architecture C Eliminate “back channel” interaction between verifier and issuer which is not visible to the credential presenter D Encourage independent standards-based implementations
In the context of this thread: A The VC can be issued in a way that does not restrict how the recipient holds it or shares it. In other words, the issuer cannot insist on certified clients although it might insist on delivering to an authenticated human (subject). B The VC can be verified without the issuer being aware of the transaction. Note that can is very different from must. Which leads to… C The presenter of the VC can choose to authorize the verifier to contact the issuer. This is still consistent with A and B. D Protocols for how VCs are issued, stored, copied, shared, and verified should be standards-based, interoperable, and not restricted through client certification that would promote lock-in through regulation or market (platform) economics.
Simply put, delegated authorization is consistent with VC issue and presentation while the (normative) introduction of holder just adds confusion in the DHS context and is harming adoption by others.
Adrian
On Fri, Sep 23, 2022 at 2:29 PM Joe Andrieu @.***> wrote:
@jandrieu https://github.com/jandrieu At risk of changing the topic of this issue (which is not my intention): I can think of cases where issuers do need/want to restrict the verifier-audience that can read (claims in) credentials that they have issued.
Yes. Lots of authorities would like to restrict what people do with the information they create. Secret warrants. Secret evidence. Secret proceedings.
If you want to keep it secret, don't put it in a VC that you give away to a party outside of your control. There are plenty of mechanisms to restrict data flow.
VCs aren't one of them.
One example is that the Netherlands has a law that restricts the use of the BSN (the Dutch equivalent of the US SSN), basically to be used within the context of government, health and banking processes. Compliance to that law would benefit from a capability that would allow issuers create VCs where this attribute was 'for their eyes only'.
Compliance is not a technical justification. To wit: compliance with laws would arguably be enhanced if all activities were surveilled 24x7 in all locations. Fortunately, society largely acknowledges that complete surveillance would be an unconscionable violation of privacy, a policy so egregious we have extensive legal protections and processes that protect our rights despite the fact that these same processes necessarily make compliance harder to enforce.
So, yes, people want to control information. I get it. There's much value to be had in information symmetry.
However, that does justify systemic restriction of the flow of information in the VCDM. This is a problem to be resolved at the legal institutions, not the technical ones.
— Reply to this email directly, view it on GitHub https://github.com/w3c/vc-data-model/issues/930#issuecomment-1256149023, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YK7JQ6HYVTXEXV42ETV7WPCLANCNFSM6AAAAAAQOQSBEA . You are receiving this because you commented.Message ID: @.***>
TallTed
commented
2 years ago @jandrieu -- For clarity, you might edit the last snippet of https://github.com/w3c/vc-data-model/issues/930#issuecomment-1256135465, and use (1), (2), (3) to refer to the numbered approaches, instead of #1, #2, #3 which created unintentional (and potentially confusing) links to (and significance-less cross-references from!) issues 1, 2, and 3 (intentionally not linked here).
TallTed
commented
2 years ago Perhaps we might consider a new standardized VC property, issuedTo, which would identify the entity to whom the Issuer intended to, and believes they did, issue the VC, whether or not that entity actually was the VC's original recipient upon issuance a/k/a first Holder, and whether or not that entity is (one of) the Subject(s) of the VC.
Certainly, the Issuer can include some property, whether nonTransferable or validOnlyIfPresentedBy or whatever, which value they hope their planned Verifiers will act on, based on their mutual business logic, but as you said -- there is currently, and I believe we should create, no technical enforcement available for this.
swcurran
commented
2 years ago @msporny -- per your question about whether I would agree that adding to the W3C VC Data Model to support some form of cryptographic delegation for authz is a bad idea -- yes, I fully agree it is a bad idea. I think that the W3C VC Data Model already has too much "use case specific" data elements in it, and prescribing more is a bad idea. I do think that if the W3C were to go down the path of coming up with a new Data Model for such a thing -- the interactions (issuer - holder - verifier) are going to be pretty much the same as the VC Data Model interactions. My support of using the (lower case) verifiable credential container for delegation was premised on such a container being able to hold anything that the issuer might want to put in it. However, the existing VC Data Model metadata negates that possibility, and adding more metadata for another use case would make things worse.
We would strongly push against the use of "level_of_assurance" (LoA) as a "core" metadata element of the VC Data Model. A set of issuers might decide to include LoA in their common schema and credentials and there is nothing to stop them doing so as a non-metadata claim in their schema. However, the use of such data is very much use case specific. In a recent Pan-Canadian group designing a schema for a common "Person" credential, we had long discussions about including LoA or not, and in the end left it out. In our use case it was because of the signal of saying (or not) the "LoA" to residents -- triggering questions about why a government must to advertise the LoA to people that have no idea what it means. Verifiers can learn about an issuers LoA from a governance framework (human or machine readable) to decide if they understand/trust the LoA of the issuer(s). Regardless of our specific decision, we don't think anyone should be forced to declare to use or not use LoA in a core VC Data Model attribute. Further -- the LoA would be self-attested, as noted previously. What help is that to a verifier within the credential itself? They still must look elsewhere to decide if they trust the issuer and credential. Similarly, we discussed other claims like "issue_date" and "expiry_date" and again decided against the use of those, mostly because in many jurisdictions, such data reveals PII -- partial birth date, and the data elements create correlating identifiers. There are absolutely use cases for them, but it should not be at the W3C VC Data Model level that they are specified.
I will argue the other way on the idea of adding an issueTo-type of data element since it goes directly to the Issuer-Holder-Verifier interactions, allowing the Verifier to request some sort of (here it comes...) cryptographically-based holder-binding mechanism (e.g. prove the presenter is the issued_to entity). We (of course :-) ) would push for it to be possible to use a non-correlating identifier for that (e.g. some sort of ZKP-based mechanism), but if such an element gets us closer to holder-binding, we would be much happier.
RieksJ
commented
2 years ago We first need to get the semantics of 'issuedTo' specified; saying it is followed by a URI, DID or something similar isn't enough. It should be clear to what kind of entity such an identifier must be pointing. Here are two possibilities:
Then, when the semantics are specified, we also need use-cases that demonstrate the necessity (not: the nice-to-haveness) for having it. Given the discussion above, I'm curious to learn where this will go.
RieksJ
commented
2 years ago Concerning the binding to a holder of a VC, I see lots of (semantic) difficulties; might we discuss that at RWOT?
agropper
commented
2 years ago There’s also the distinction around copying a VC. In the physical world, an issuer can make it very hard to copy the credential through physical safeguards such as holograms.
VCs are trivial to duplicate. This may lead issuers to try to bind the VC to a particular client and that client to a particular biometric. If so, then subjects, given a choice like DHS offers, will prefer physical credentials to being given an ankle bracelet.
Adrian
On Sat, Sep 24, 2022 at 3:48 PM Rieks @.***> wrote:
We first need to get the semantics of 'issuedTo' specified; saying it is followed by a URI, DID or something similar isn't enough. It should be clear to what kind of entity such an identifier must be pointing. Here are two possibilities:
- the party https://essif-lab.github.io/framework/docs/essifLab-glossary#party - i.e. an organization or a person that is known at the business level and hence can e.g. be sued.
- the (digital) agent https://essif-lab.github.io/framework/docs/essifLab-glossary#agent, that actually sent the electronic request and to which the VC is electronically issued, e.g. a specific app on a mobile phone, or an app somewhere in the cloud.
Then, when the semantics are specified, we also need use-cases that demonstrate the necessity (not: the nice-to-haveness) for having it. Given the discussion above, I'm curious to learn where this will go.
— Reply to this email directly, view it on GitHub https://github.com/w3c/vc-data-model/issues/930#issuecomment-1256973357, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YMLSAT4FL5BHR66VULV74BD3ANCNFSM6AAAAAAQOQSBEA . You are receiving this because you commented.Message ID: @.***>
agropper
commented
2 years ago @joeandrieu, your point “If they can deliver the VC they are the holder.” is essential. It also captures the difference between a statement and (delegated) authorization. It may show us a way to mitigate confusion around the normative use of “holder”.
By definition, the issuer “can deliver the VC,”. Logically, this makes them a holder. Whether and how the issuer delivers a VC, you might agree, is merely a matter of authorization.
Adrian
On Thu, Sep 22, 2022 at 4:50 PM Joe Andrieu @.***> wrote:
@kdenhartog https://github.com/kdenhartog We must still be talking past each other.
The holder is a functional term. It is, by definition, whoever holds the serialized form of a VC.
As such, it is a mistake to attempt to identify, in the VC itself, who the holder is. Because it is only ever true by happenstance. It's not possible to know who holds a VC at the current moment except by proof of possession. If they can deliver the VC, they are the holder. Regardless of what the VC itself says.
I think what you are trying to encode is a restriction on the use of a VC. Whether or not we call that Digital Rights Management (DRM) or censorship, neither have any place in VCs. Statements are not delegatable. The issuer of a VC does not get to dictate how that VC is used. Period.
It's up to each verifier to decide what business rules apply when interpreting the statements in a VC. It is not up to the issuer to decide who gets to use the VC for what purpose. The latter is "validation" and leaves the ultimate decision up to the verifier. The issuer has already played their part at the point of issuance. The holder plays their part creating a VP. There is no role here for the issuer to constrain usage except through revocation. Restricting the use of statements would make about as much sense as issuing a statement that "The Guardian asserts Charles III is King" but restrict it so that only official recipients of that message get to use it.
As statements, VCs simply are. They are verifiable vis-a-vis authorship, tampering, and timeliness. They can be referred to and refuted. And they can be transmitted by any digital medium.
What they can't do is be delegated. The Guardian can't delegate its statement about King Charles any more than they could delegate a statement made about yesterday's weather.
What you want, I think, is better described by @RieksJ https://github.com/RieksJ as
The place to be for that is the specifications of claims-types (or VC-types), i.e.: schema's, which are typically to be specified in/by/on behalf of 'the business' (which includes legal business). VCDM is, and should remain, a technical spec.
Creating vocabularies of claims that express authorizations, delegations, revocations, etc. is a fine goal. We need such vocabularies. We'll almost certainly need many of them.
What we don't need to do is treat statements, as made verifiable by VCs, as anything other than just statements. We will have a hard enough challenge ahead keeping the data and security models intact with that simple, narrow focus.
— Reply to this email directly, view it on GitHub https://github.com/w3c/vc-data-model/issues/930#issuecomment-1255140253, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YJIDCGQ3HCWWLEE7FLV7RW3XANCNFSM6AAAAAAQOQSBEA . You are receiving this because you commented.Message ID: @.***>
decentralgabe
commented
1 year ago Closing to work on adding a use case to represent delegation statements as part of the credentialSubject. https://github.com/w3c/vc-use-cases/issues/126
Will consider referencing this use case and approach in the VCDM after it is in the use case doc.
iherman
commented
1 year ago The issue was discussed in a meeting on 2022-12-14
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
Prior Art
Use Cases
What Would It Look Like?