Multiple subjects in a single credential

[msporny]

Technically, the data model supports a single credential making claims about multiple subjects:

{
  "@context": ["http://schema.org/", "https://w3id.org/identity/v1"],
  "id": "http://example.gov/credentials/3732",
  "type": ["Credential", "MultiSubjectCredential"],
  "issuer": "https://multi.example.org",
  "issued": "2017-06-05",
  "claim": [{
    "id": "did:v1:9f52df2e-7c96-42af-8dfd-1099980f8467",
    "ageOver": 18
  }, {
    "id": "did:v1:7d866a9f-c5a3-41f5-8ae1-0297b7849801",
    "ageOver": 21    
  }, {
    "id": "did:v1:c4e13c30-31dc-40df-867f-ed678d87ac54",
    "ageOver": 65   
  }],
  "signature": {
    "type": "LinkedDataSignature2015",
    "created": "2017-06-05T07:08:36Z",
    "creator": "https://example.com/jdoe/keys/1",
    "signatureValue": "lQ7VZUeAA...Z5Lk="
  }
}

While this may be a corner case, the data model allows for it. Should we change the definition of entity credential and entity profile from being about "a subject" to "usually about the same subject" or equivalent language.

[jandrieu]

Interesting.

I look at that JSON-LD and I'm wondering how anyone knows those dids refer to different subjects. They could all be the same person. And since the statements in each claim isn't actually about the DID, but about the entity referred to by the DID, I think that's more than a semantic distinction.

The only way we could presume that those DIDs referred to the same subject is if that was the rule, which seems like an unnecessary disclosure.

That suggests it would be a mistake to limit a credential to a single subject. However, using "usually" or "typically" is fine to anchor that most of the time it is.

[David-Chadwick]

The data model should definitely make a strong statement that "a credential must contain a set of claims about the same subject". Otherwise it is not a subject profile - it is a group profile.This does not mean that the IDs of the claims must be the same, although that is the simplest way of ensuring this. A subject could have multiple IDs, as in your example above, but must then she must be able to prove to the verifier that she is the owner of all of the IDs.

[RieksJ]

I agree with @David-Chadwick. I would even say that a credential must contain a single (root-)subject-identifier that identifies the (single!) subject in the context of the issuer. If the need were to arise to use other subject-identifiers (which might identify the same, or other entities), then these can be linked to the root-subject(identifier) by means of a (semantically well-defined) predicate.

[msporny]

@David-Chadwick wrote:

The data model should definitely make a strong statement that "a credential must contain a set of claims about the same subject"

-1 ... seems like an arbitrary restriction. The verifiable credential data model doesn't make this restriction (it's capable of containing a set of claims about different subjects). So, why would we want to arbitrarily restrict the data model from doing so? Keep in mind that every time we restrict the data model in this way, we forever cut off a set of potentially useful corner use cases.

@David-Chadwick wrote:

subject profile / group profile

That concept doesn't exist in the spec and I'd argue against introducing the terminology (as it's a corner case and would most likely confuse more than clarify). What we have in the spec right now is "verifiable profile".

@RieksJ wrote:

I would even say that a credential must contain a single (root-)subject-identifier that identifies the (single!) subject in the context of the issuer.

-1, again - why are we arbitrarily drawing the line there? What technical problem is created where we need to limit the data model in this way?

[David-Chadwick]

Manu, I would like to ask you, why would you want a single VC to contain the claims of multiple subjects? Why isn't sending a set of VCs, in which each VC refers to a single subject, good enough for you? In what ways does the latter not solve what you want to solve (actually I don't know what problem you are trying to solve by having multiple subjects inside a single VC. One example might be a club publishing its membership list in a single VC. But I could argue that this isn't really a self-sovereign credential.)

The problem I see is that if the VC contains a set of different IDs and it is not mandated that all the IDs must belong to the same subject, then the IDs may obviously belong to different subjects. And then proof of possession, or right to assert, or to say that these claims are about me, becomes much more difficult to prove. And if the claims are about other people we then get a bunch of data protection issues as well. What right do I have to assert the claims of other people. Did they give me their consent? How can the inspector know that I have the subject's permission etc.

[RieksJ]

Here are some more arguments:

1. The example that @msporny gives is ambiguous. Assuming that "type": ["Credential", "MultiSubjectCredential"] means that the number of subjects is more than one. However, subjects may be identified with multiple DIDs. Therefore, it cannot be determined whether this credential is about two or three distinct subjects.

2. But even if that were resolved, consider a credential with claims referring to different subjects. What would happen if the claim(s) pertaining to one subject had to be revoked. Would that revoke the claims of the other subject as well (as the signature is about ALL claims)? I can imagine situations where this has an adverse effect on the reputation of the subject whose claims remain valid but are nevertheless revoked.

3. If holders can store claims in their wallets/agents, to which holder(s) would issuers provide such claims? Does that align with the privacy principles we want to have?

4. How can an inspector/verifier that receives such a claim from a users wallet determine which subject it should associate with which claim (which it needs to establish which of the claims it should use)?

5. If the claims in a single credential are independent, then it is just as easy to create two credentials, one for each subject, thereby not bothering programmers/business people/users to think about the aforementioned issues. If the claims in a singel credential are dependent, then this dependency should be specified by means of a predicate/property.

I would like to see that we specify that if a credential contains multiple claims (of which subject identifiers may differ), the signature over the credential should mean that

• the issuer vouches for the truth of each such claim, and
• (the subject identifiers of) all claims refer to/have the same subject.

[ChristopherA]

Just off my head are a number of cases where multiple subjects might be useful. * issuer wishes to claim that my car (subject is car DID) may have some priveleges (handicapped parking, garage access, insurance) only when driven by me (subject is my DID). * code libraries a, b, c, d, & e have been security reviewed to work together. * Books co-authored by Shannon & Christopher are rated good. — Christopher Allen

[RieksJ]

@ChristopherA, you are right to say that there are several (I would say: numerous) cases where a claim or credential would involve multiple subjects. However, every such case can be accommodated by selecting a single subject(id), and stuffing the relations that it has with the 'other subjects' in properties (and nodes) of the JSON-LD graph that the claim/credential can associate its (single) subject(id) with.

In your car-example, the issuer could then provide a claim/credential to the car, with the car(id) as subject, and a JSON-LD graph car->me->privilege(s), and/or car->privilege(s)->me. The issuer could also provide claims/credentials to me, with a JSON-LD graph: me->car(s)->privilege(s) and/or me->privilege(s)->car(s).

But in any case, the root of the JSON-LD graph, i.e. the subject(id) of the claim/credential should be a single entity.

[msporny]

every such case can be accommodated by selecting a single subject(id), and stuffing the relations that it has with the 'other subjects' in properties (and nodes) of the JSON-LD graph that the claim/credential can associate its (single) subject(id) with.

False, there are cases where there are no such relations between the subject and other subjects (or where creating one would be only done because you need to create a relationship to address the use case).

Example: These 4 devices are in a geolocated area at lat and long with a radius of 100 meters. There is no single subject identifier that links those 4 devices.

[RieksJ]

In that case i suggest the issuer create two credentials for the reasons I mentioned earlier. Verzonden met mijn Windows Phone

…

________________________________ From: Manu Sporny<mailto:notifications@github.com> Sent: ‎25-‎10-‎2017 19:07 To: w3c/vc-data-model<mailto:vc-data-model@noreply.github.com> Cc: Joosten, H.J.M. (Rieks)<mailto:rieks.joosten@tno.nl>; Mention<mailto:mention@noreply.github.com> Subject: Re: [w3c/vc-data-model] Multiple subjects in a single credential (#55) every such case can be accommodated by selecting a single subject(id), and stuffing the relations that it has with the 'other subjects' in properties (and nodes) of the JSON-LD graph that the claim/credential can associate its (single) subject(id) with. False, there are cases where there are no such relations between the subject and other subjects (or where creating one would be only done because you need to create a relationship to address the use case). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#55 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AIILXU3lP_3ybACL3m1cvSAzXsnNT4Lcks5sv2rmgaJpZM4N19df>. This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

[msporny]

In that case i suggest the issuer create two credentials for the reasons I mentioned earlier.

... and if there are 100 subjects? 100 different credentials? Why are we attempting to arbitrarily restrict the data model in this way? It could be a best practice, but even that I'm a bit concerned about.

[dlongley]

@RieksJ,

I don't think there's any harm in permitting multiple subjects in the data model and we can't possibly enumerate all possible uses of VCs. Therefore, it seems a simple solution would be to say that there's no restriction in the data model, but some systems may require a single root subject in the VCs they are willing to accept.

Similarly, a best practices document could indicate how to avoid using multiple subjects for some broad set of use cases.

[RieksJ]

@msporny: for the 5 reasons I mentioned 2 days ago. But if you think they are invalid, It's ok with me to let it happen, and see how things work out.

[msporny]

The example that @msporny gives is ambiguous. Assuming that "type": ["Credential", "MultiSubjectCredential"] means that the number of subjects is more than one. However, subjects may be identified with multiple DIDs. Therefore, it cannot be determined whether this credential is about two or three distinct subjects.

Yes, but what's the use case where it's important whether a credential is about two or three distinct subjects. To put it another way, the enforcement of that is at a higher policy level, not at the data model layer.

But even if that were resolved, consider a credential with claims referring to different subjects. What would happen if the claim(s) pertaining to one subject had to be revoked. Would that revoke the claims of the other subject as well (as the signature is about ALL claims)? I can imagine situations where this has an adverse effect on the reputation of the subject whose claims remain valid but are nevertheless revoked.

Yes, all claims would be revoked about all subjects because credentials are typically either valid or not... but again, this is a policy decision, not a data model decision.

If holders can store claims in their wallets/agents, to which holder(s) would issuers provide such claims? Does that align with the privacy principles we want to have?

Yes, issuers will provide claims to holders that are not about them. For example, the medication for my pet is about my pet, but I hold on to it.

How can an inspector/verifier that receives such a claim from a users wallet determine which subject it should associate with which claim (which it needs to establish which of the claims it should use)?

This is a part of the protocol (proof of possession), which is higher level than the data model.

If the claims in a single credential are independent, then it is just as easy to create two credentials, one for each subject, thereby not bothering programmers/business people/users to think about the aforementioned issues. If the claims in a singel credential are dependent, then this dependency should be specified by means of a predicate/property.

There are cases where the single credential doesn't work (there is no relationship between A and B, but the issuer would like to bundle them anyway - e.g. the 100s of devices geolocated IoT use case above).

[msporny]

if you think they are invalid, It's ok with me to let it happen, and see how things work out.

I'm not saying what you are asserting is invalid. I'm saying that those decisions should be made at a higher protocol or policy layer, not at the data model layer.