V1 specification doesn't definitively state that the credentialSubject.id, if specified, is always the id of the Subject of the Credential

mwherman2000 commented 3 years ago

V1 specification doesn't definitively state that the credentialSubject.id, if specified, is always the id of the Subject of the Credential.

(Presumably, credentialSubject.id might simply be a Claim (name-value pair )named id.)

msporny commented 3 years ago

V1 specification doesn't definitely state that the credentialSubject.id, if specified, is always the id of the Subject of the Credential.

The specification currently states three things:

This specification defines a credentialSubject property for the expression of claims about one or more subjects[1].
Each [credentialSubject] object MAY contain an id, as described in Section § 4.2 Identifiers[2].
When expressing statements about a specific thing, such as a person, product, or organization, it is often useful to use some kind of identifier so that others can express statements about the same thing. This specification defines the optional id property for such identifiers. The id property is intended to unambiguously refer to an object, such as a person, product, or organization.[3]

Please provide a concrete suggestion on how you would like to improve upon that text.

mwherman2000 commented 3 years ago

Please provide a concrete suggestion on how you would like to improve upon that text.

The bullets talk all around the issue but don't simply come out and state: If a credential contains a credentialSubject property and it, in turns contains an id claim, the value of the id property is to be interpreted as the identifier for a corresponding credential subject.

More simply, no where does the specification simply state the value of the credentialSubject id claim (if present) is to be interpreted the identifier of a corresponding credential subject.

p.s. How is a id property of a credentialSubject supposed to be differentiated as: a. A claim named id (like the other claims that might appear under the credentialSubject) vs. b. The identifier of a corresponding credential subject

When is the id property one or there other? When is it both?

msporny commented 3 years ago

@mwherman2000 wrote:

If a credential contains a credentialSubject property and it, in turns contains an id claim, the value of the id property is to be interpreted as the identifier for a corresponding credential subject.

If the specification stated that exact sentence, would your view this particular issue as being addressed?

mwherman2000 commented 3 years ago

@msporny It does address an important aspect of the issue. Then there's "part b"...

p.s. How is a id property of a credentialSubject supposed to be differentiated as: a. A claim named id (like the other claims that might appear under the credentialSubject) vs. b. The identifier of a corresponding credential subject When is the id property one or there other? When is it both?

I'll open a new issue for "part b" (https://github.com/w3c/vc-data-model/issues/793) - then https://github.com/w3c/vc-data-model/issues/792 can be closed with a PR containing...

If a credential contains a credentialSubject property and it, in turns contains an id claim, the value of the id property is to be interpreted as the identifier for a corresponding credential subject.

David-Chadwick commented 3 years ago

@msporny wrote

If a credential contains a credentialSubject property and it, in turns contains an id claim, the value of the id property is to be interpreted as the identifier for a corresponding credential subject.

If the specification stated that exact sentence, would your view this particular issue as being addressed?

I have a problem with this. Consider the following use case. A company director presents two VCs in a VP, both containing the same subjectID. The VP is signed using the private key corresponding to the subject ID, so the verifier knows they both belong to and being held by the company director. The first VC contains subject properties holding the name of the director and passport number, the second VP contains the name of the company and its registration number. The first VC is signed by the country's passport office, the second by the country's companies registration authority. The director is entitled to hold both VCs as both were issued to her.

Your proposed sentence is no longer true for the second of these VCs.

mwherman2000 commented 3 years ago

What/where exacty is the root cause of the problem @David-Chadwick has highlighted above?

The specification wants to support multiple subjects within a singe VC? .
Something else?

IMO I don't think the problem is with the proposed statement. The statement below is simply trying at a basic syntactic level (i.e. parsing level) to discern how a credentialSubject id is to be interpreted.

SIDE OBSERVATION: These are very very basic core issues. They are examples of the immaturity of the specification. Is the spec ready to progress any further? I, for one, don't think so.

dlongley commented 3 years ago

@mwherman2000,

If a credential contains a credentialSubject property and it, in turns contains an id claim, the value of the id property is to be interpreted as the identifier for a corresponding credential subject.

To be clear, in the VC data model spec, properties are not claims and neither are property+value tuples -- they are only components of one. A claim is the combination of a subject-property-value relationship. In other words, it has three components. I think at least some of the confusion here may be stemming from not using the definition of "claim" from the spec?

I think perhaps the rest of the confusion may have to do with the fact that the id property is to be used to express the identifier for any object, not just the credentialSubject -- and the language used to convey that. In just typing that, I can see at least two different interpretations. To help clarify, one may ask, "Then which object does the identifier reference?". The answer is "the object on which the id property appears".

So, I think it would contradict other parts of the spec to refer to the id property or it plus its value as a "claim". Rather, the id property expresses the identifier for an object on which it appears. By declaring a globally unambiguous identifier for an object, one can make other statements expressed about the same subject (that object) in other VCs, in a VP, or some other document -- this is open ended. The id is only necessary if this sort of linkage / common point of reference is desirable. Whether the id property is present or not, the other property-values listed within an object are understood to be the property-value components of statements (or "claims") where the subject of those statements is the object on which the properties appear.

Now, we need the spec to convey this concept generally for all objects (since it applies to all of them). Therefore, looking for a specific statement that discusses this on just one particular object (e.g., one expressed as a value of the credentialSubject property) wouldn't turn anything up except as an example (note: below I do quote from the spec where exactly that example happens to be used). My point is that we don't want readers to think credentialSubject is special with respect to the id property; that property can be used on any object.

I may also draw your attention to the part of section 4.2 that attempts to explain identifiers by example. That section first states:

When expressing statements about a specific thing, such as a person, product, or organization, it is often useful to use some kind of identifier so that others can express statements about the same thing. This specification defines the optional id property for such identifiers. The id property is intended to unambiguously refer to an object, such as a person, product, or organization. Using the id property allows for the expression of statements about specific things in the verifiable credential.

It then provides normative statements about the format of the id value, followed by an example showing its usage. The example shows the usage of credentialSubject.id as the second identifier in the example. Just after that example it states:

The example above uses two types of identifiers. The first identifier is for the verifiable credential and uses an HTTP-based URL. The second identifier is for the subject of the verifiable credential (the thing the claims are about) and uses a decentralized identifier, also known as a DID.

Does this provide the language you're looking for? If so, does it just need to be made more prominent in some way? How can we alleviate your concern whilst still having general language that covers all objects?

mwherman2000 commented 3 years ago

This is good in that we're getting down to some very distinct fundamental issues (which I believe are solvable).

A claim is the combination of a subject-property-value relationship.

At least for me, one of the foremost issues is that the physical data model of a VC (for an example, see below) in the specification doesn't match the specification's conceptual data model of a VC (as described by @dlongley above). This doesn't work well in the long run from a developers' perspective. ...after all, this is supposed to be a data model specification.

{
    "@context": [
      "https://www.w3.org/2018/credentials/v1",
      "https://www.w3.org/2018/credentials/examples/v1"
    ],
    "id": "did:colors:primarycolors",
    "type": ["VerifiableCredential", "ColorPalette"],
    "credentialSubject": {
      "colors": [
          "red",
          "green",
          "blue"
      ]
    },
    "proof": "..."
  }
}

Based on the above perfectly acceptable example of a physical data model of a VC, a claim is name-value pair - plain and simply for all to see. It's not arguable.

But "you" say if I add something benign like a credentialSubject id claim to another version of the above example of a physical VC, Dave (I'm not really picking on you personally) says the entire conceptual model that I've built up in my mind is completely wrong. That doesn't work for me as a developer. It's not a path to success to be a platform/specification that wants to have a million apps built on it. Here's the second example...

{
    "@context": [
      "https://www.w3.org/2018/credentials/v1",
      "https://www.w3.org/2018/credentials/examples/v1"
    ],
    "id": "did:colors:primarycolors",
    "type": ["VerifiableCredential", "ColorPalette"],
    "credentialSubject": {
      "id" : "did:colorpaletes:primarycolorpaletes",
      "colors": [
          "red",
          "green",
          "blue"
      ]
    },
    "proof": "..."
  }
}

How can you rationally convince me that "id" : "did:colorpaletes:primarycolorpaletes" isn't simple another claim? ...maybe, a claim with some sort of special business rules or semantics attached to it ...but just the same, it's just a plain old claim syntactically.

mwherman2000 commented 3 years ago

This specification defines the optional id property for such identifiers. The id property is intended to unambiguously refer to an object, such as a person, product, or organization. Using the id property allows for the expression of statements about specific things in the verifiable credential.

The first sentence is a vague, ambiguous, and confusing reference to some sort of VC id property when there are, in fact, two main properties in a VC called id (each of which are optional); hence, the rest of the paragraph, to me, is completely meaningless/useless (IMO).

David-Chadwick commented 3 years ago

@dlongley said "Whether the id property is present or not, the other property-values listed within an object are understood to be the property-value components of statements (or "claims") where the subject of those statements is the object on which the properties appear." So if the object is an ephemeral public key, then the claims are attached to the public key, and whoever possesses the corresponding private key can claim ownership of the properties.

But what about bearer credentials where there is no id, such as a concert ticket. This is still a claim made by the issuer, that this is a valid concert ticket. But it is not bound to any object. Whoever has a copy of this VC has a copy of the concert ticket. To whom or what is it bound?

dlongley commented 3 years ago

@mwherman2000,

Based on the above perfectly acceptable example of a physical data model of a VC, a claim is a name-value pair - plain and simply for all to see. It's not arguable.

I don't understand what this means ... so I guess it's arguable :). Can you state all of the claims using English sentences (an alternative syntax) so I can understand?

As an example of how I would do it with a simple "name credential":

{
    "@context": [
      "https://www.w3.org/2018/credentials/v1",
      "https://www.w3.org/2018/credentials/examples/v2"
    ],
    "id": "example:1",
    "type": ["VerifiableCredential", "NameCredential"],
    "credentialSubject": {
      "id": "example:2",
      "name": "Michael"
    }
  }
}

The above JSON-LD syntax has these statements or "claims" in English syntax:

The object identified by "example:1" has a "type" of "VerifiableCredential".
The object identified by "example:1" has a "type" of "NameCredential".
The object identified by "example:1" has a "credential subject" that is identified by "example:2".
The object identified by "example:2" has a "name" of "Michael".

I'm worried that your model that decoupling claims from subjects would lead to confusion. In the VC data model, statements (or "claims") are like sentences: they have a subject, predicate, and object. Another way of stating this definition is that a claim is a "subject-property-value" relationship. Without a subject, you've got an incomplete sentence.

David-Chadwick commented 3 years ago

@mwherman2000 said "Based on the above perfectly acceptable example of a physical data model of a VC, a claim is name-value pair - plain and simply for all to see. It's not arguable." I tend to agree with this view.

mwherman2000 commented 3 years ago

@dlongley We're talking at 2 different levels of interpretation.

Can you state all of the claims using English sentences (an alternative syntax) so I can understand?

Let's agree to skip @context ...at least initially.
There is a Credential named "example:1".
The "example:1" Credential has a credential type of "NameCredential" associated with it.
The "example:1" Credential has a collection of Claims associated with it.
The collection of Claims contains 2 Claims.
The first Claim is named "id" and has a value of "example:2".
The second Claim is named "name" and has a value "Michael".

This is the entirety of what is expressed by the text of your example (repeated below).

{
    "@context": [
      "https://www.w3.org/2018/credentials/v1",
      "https://www.w3.org/2018/credentials/examples/v2"
    ],
    "id": "example:1",
    "type": ["VerifiableCredential", "NameCredential"],
    "credentialSubject": {
      "id": "example:2",
      "name": "Michael"
    }
  }
}

That's at one level - let's call it the Syntactic level.

We now apply your English statements - they are at the next level up. I'm going to call this level the Business level or Semantics level (because I can't thinking of anything better right now.)

Let's call the things we apply business rules.

Here are some examples of some (VC) business rules: BR1. If the credential's collection of Claims includes a Claim named id, the value of that Claim is interpreted as an identifier associated with a person, organization, or thing. We call this person, organization, or thing a Subject. BR2. If the credential's collection of Claims includes a Claim named id, the remainder of the Claims in the collection are to be interpreted as named properties (metadata) describing or otherwise being attributed to the Subject (identified by the identifier value of the Claim named id). BR3. If the credential's collection of Claims does not include a Claim named id and the Credential is appropriately signed (i.e. has a valid/verifiable proof), the Credential is simply a verifiable data envelope containing a collection of Claims.

dlongley commented 3 years ago

@David-Chadwick,

@dlongley said "Whether the id property is present or not, the other property-values listed within an object are understood to be the property-value components of statements (or "claims") where the subject of those statements is the object on which the properties appear." So if the object is an ephemeral public key, then the claims are attached to the public key, and whoever possesses the corresponding private key can claim ownership of the properties.

Well, presuming that the verifier considered that acceptable (as is always the prerequisite), sure.

But what about bearer credentials where there is no id, such as a concert ticket. This is still a claim made by the issuer, that this is a valid concert ticket. But it is not bound to any object. Whoever has a copy of this VC has a copy of the concert ticket. To whom or what is it bound?

I'm not sure if you were asking me, but if you modeled your VC such that the (non-unambiguously identified) credential subject had a ticket with ID XYZ, then the claim, in English, would be something like:

There exists an object that has a ticket identified by XYZ.

It would be up to the verifier (again, as always), to decide whether to consider the presenter of a VC that included that claim to be the party that rightfully has that ticket.

dlongley commented 3 years ago

@mwherman2000,

There is a Credential named "example:1".

The "example:1" Credential has a credential type of "NameCredential" associated with it.

The "example:1" Credential has a collection of Claims associated with it.

The collection of Claims contains 2 Claims.

The first Claim is named "id" and has a value of "example:2".

The second Claim is named "name" and has a value "Michael".

From my perspective, you have evaluated the id property differently for the credential vs. the credential subject. Why? If you had used the same pattern for the credential and the credential subject, you would have produced a list that was very similar (if not effectively the same) as mine. So, to me, you seem to have switched processing models halfway through.

Also, what does it mean to have a claim with a name of "name" and a value of "Michael"? To what does this pertain? I don't understand how this data model could work. With the VC data model, you can use an entirely different syntax from JSON-LD without losing the connectivity of the claims made about a single subject -- because the subject is part of the claims. I don't see how that is done in your model.

That's at one level - let's call it the Syntactic level.

We now apply your English statements - they are at the next level up. I'm going to call this level the Business level or Semantics level (because I can't thinking of anything better right now.)

We don't need to invent new names for these. We have an abstract data model and a syntax that concretely represents it (JSON-LD). This terminology has been used in many related W3C specs. Another (informal) syntax would be English sentences and yet another (formal) would be N-Quads. JSON-LD, English, N-Quads, Turtle, and so on all operate at the "syntax level". The abstract data model is comprised of subject-property-value relationships. We can come up with all different kinds of ways to express those (syntaxes) but the spec currently just describes JSON-LD and JSON. English is just another one of those ways. It seems some of the confusion here may be conflating "English statements" as being at a different "level" than JSON-LD. They are just different syntaxes for the same information.

dlongley commented 3 years ago

@mwherman2000,

If it helps, imagine going through the process of parsing a VC into an abstract data model and then exporting it into some other syntax. How would you make sure that the claims remain attached to the appropriate objects if you don't capture that information in your abstract model? For example consider when there are two credential subjects:

{
    "@context": [
      "https://www.w3.org/2018/credentials/v1",
      "https://www.w3.org/2018/credentials/examples/v2"
    ],
    "id": "example:1",
    "type": ["VerifiableCredential", "NameCredential"],
    "credentialSubject": [{
      "id": "example:2",
      "name": "Michael"
    }, {
      "id": "example:3",
      "name": "Dave"
    }]
  }
}

Or consider that the credential subject is related to other objects:

{
    "@context": [
      "https://www.w3.org/2018/credentials/v1",
      "https://www.w3.org/2018/credentials/examples/v2"
    ],
    "id": "example:1",
    "type": ["VerifiableCredential", "KnowsCredential"],
    "credentialSubject": [{
      "id": "example:2",
      "name": "Michael",
      "knows": {
        "id": "example:3",
        "name": "Dave"
      }
    }]
  }
}

There are obviously even more complicated VCs we could consider. It is important that the abstract data model include the information necessary to differentiate to which subjects the property+values belong.

mwherman2000 commented 3 years ago

From my perspective, you have evaluated the id property differently for the credential vs. the credential subject. Why?

Because they're different and at different scopes. "id": "example:1" is the name-value pair (aka named property) that provides the credential itself with an identifier. "id": "example:2" is a Claim and has no semantic meaning until you apply some sort of business rule or other semantic interpretation to it (e.g. BR1, BR2, and/or BR3 from my previous posting). "id": "example:2" has nothing to do with the credential at the top-level - it doesn't have anything to do with naming or identifying the credential (as a whole).

Also, what does it mean to have a claim with a name of "name" and a value of "Michael"? To what does this pertain? I don't understand how this data model could work. With the VC data model, you can use an entirely different syntax from JSON-LD without losing the connectivity of the claims made about a single subject -- because the subject is part of the claims. I don't see how that is done in your model.

At the syntactic level, it doesn't pertain to anything really. It's just (signed) data - a signed, verifiable collection of data (collection of name-value pairs). It isn't until you associate an interpretation to these Claims that they have any meaning.

That's at one level - let's call it the Syntactic level. We now apply your English statements - they are at the next level up. I'm going to call this level the Business level or Semantics level (because I can't thinking of anything better right now.)

... but the spec currently just describes JSON-LD and JSON.

It does not. Please send me a link to a section in the current version of the specification where the connection between what we've talked about above and JSON-LD (if you disagree)? JSON-LD is mentioned in passing in Section 6 (https://www.w3.org/TR/vc-data-model/#json-ld) but where is there a a concrete connection established between the VC data model description and JSON-LD. @msporny , for example, couldn't find it?

mwherman2000 commented 3 years ago

@dlongley (Gently) we're sort of talking past each other. :-)

How would you make sure that the claims remain attached to the appropriate objects if you don't capture that information in your abstract model?

We differ in your interpretation and my interpretation of appropriate objects. For you, I think appropriate objects are Subjects (at this higher semantic level).

At (my) syntactic level, they're claims associated with a Credential ...that is, very much at the syntactic level. At the syntactic level, there's no concept of there being a Subject. There's strong parallels between what I'm trying to describe and how programming language compilers or interpreters work. I'm describing things at the AST level (abstract syntax three) level that can then be subjected to semantic analysis/interpretation by a set of rules/transformations.

dlongley commented 3 years ago

@mwherman2000,

So it now seems clear to me that what you're describing is just an entirely different approach than what was taken by the VCWG. That's ok -- I'm just letting you know you're talking about something wholly different that doesn't match what's in the VC data model spec. From here I would suggest trying to align your mental model with the VC data model spec approach and then if there's still confusion with the spec language to make a concrete proposal from there to try and address it. Starting from a different model instead of what's in the spec, I think, is only going to lead to more confusion.

Obviously, you are also free to propose a completely different model and see what the VCWG thinks of that, but you may be more likely to get consensus around clarifying text as opposed to a total rewrite. That's just my personal opinion -- you can do whatever you'd like, present it to the VCWG (via github issues or by scheduling time on a call if you'd like), and try and see if there's consensus for it.

mwherman2000 commented 3 years ago

@dlongley cool ...it seems we have connected on understanding each other.

I believe that as you unwind all the little detailed issues that I've highlight elsewhere in the Issues list (I'm running short of time at the moment), I think you'll find it hard to solve with that's currently in the spec ...more specifically, that the physical data models and abstract data models are too far apart to be reconcilable ...to create an acceptable level of end-to-end cohesion.

I brought my approach forward because: a) that's how I think as an architect, and b) I can't see/visualize a successful intermediate solution (e.g. patching what's already in the spec). Maybe there is ...I can't see it.

David-Chadwick commented 3 years ago

@dlongley wrote "There exists an object that has a ticket identified by XYZ." I don't think that is quite correct. Rather it is "there exists a ticket identified by ID XYZ, that belongs to whichever object presents it to the verifier". Just like cash, it belongs to the person whose wallet it is in. Cash is different to a cheque as the latter contains the name of the object that it is assigned to. Cash (and bearer credentials) do not.

dlongley commented 3 years ago

@David-Chadwick,

@dlongley wrote "There exists an object that has a ticket identified by XYZ." I don't think that is quite correct.

Well, I left out the other statements to avoid confusion that may have arisen on the other topic that was happening in this thread, but now that that has been resolved (I believe), another way of writing the English that combines the relevant statements would be:

"This is bearer ticket credential has a credential subject that has a ticket identified by ID XYZ."

This is written using deictic language and a single sentence to avoid the fact that the objects here don't have identifiers to enable us to link separate statements about them. I could have minted some temporary/contextual identifiers just to be able to talk about all of the information as a set of separate sentences to more closely match the VC data model:

The credential identified by temporary ID "temp_id1" is a bearer ticket credential.
A bearer ticket credential is a type of credential whereby whoever presents it is considered the credential subject.
The credential identified by temporary ID "temp_id1" has a credential subject identified by temporary ID "temp_id2".
The object identified by "temp_id2" has a ticket identified by ID XYZ.

This is semantically the same as the combined sentence. The fact that the object that "has the ticket" is also the "credential subject" and that the type of credential indicates the credential subject is the bearer is the connecting piece that was left out in my earlier attempt to avoid some different confusion. Taken together, I think it is now very similar to your rephrasing: "there exists a ticket identified by ID XYZ, that belongs to whichever object presents it to the verifier".

mwherman2000 commented 3 years ago

@dlongley and @David-Chadwick where is the full text of the ticket bearer VC you're discussing?

David-Chadwick commented 3 years ago

section 7.9 bearer credentials

mwherman2000 commented 3 years ago

section 7.9 bearer credentials

@David-Chadwick Are you sure the ticket example is in Section 7.9 Bearer Credentials?

I can only find this example and it is not the ticket example: https://www.w3.org/TR/vc-data-model/#example-33-usage-of-issuer-properties

mwherman2000 commented 3 years ago

Going back to the primarycolors Unbound and Bound VC examples, let me suggest something. I have no idea if it is technically valid/viable but if it is, it's a way out. Initially, I'm looking for a single person who finds some form of this approach (or a variation) acceptable. Here's two examples to start with (...same as above with some typos removed).

Example 1. Unbound primarycolors VC

{
    "@context": [
      "https://www.w3.org/2018/credentials/v1",
      "https://www.w3.org/2018/credentials/examples/v1"
    ],
    "id": "did:colors:primarycolorpalette",
    "type": ["VerifiableCredential", "ColorPalette"],
    "credentialSubject": {
      "colors": [
          "red",
          "green",
          "blue"
      ]
    },
    "proof": "..."
  }
}

Example 2a. Bound primarycolors VC

{
    "@context": [
      "https://www.w3.org/2018/credentials/v1",
      "https://www.w3.org/2018/credentials/examples/v1"
    ],
    "id": "did:colors:primarycolorpalette",
    "type": ["VerifiableCredential", "ColorPalette"],
    "credentialSubject": {
      "id": "did:colorpalettes:primarycolors",
      "colors": [
          "red",
          "green",
          "blue"
      ]
    },
    "proof": "..."
  }
}

Proposal A : What if/Can the @context be used to switch in/out how the credentialSubject id name-value pair is to be interpreted (when it is present)? That is, can the @context be used to switch in/out (or turn on/off) different sets of business rules for interpreting the credentialSubject id name-value pair?

For example, ....note the additional second item in the @context element...

Example 2b. Bound primarycolors VC using @context

{
    "@context": [
      "https://www.w3.org/2018/credentials/v1",
      "https://www.w3.org/2018/credentials/v1/credentialSubject_id_subject",
      "https://www.w3.org/2018/credentials/examples/v1"
    ],
    "id": "did:colors:primarycolorpalette",
    "type": ["VerifiableCredential", "ColorPalette"],
    "credentialSubject": {
      "id": "did:colorpalettes:primarycolors",
      "colors": [
          "red",
          "green",
          "blue"
      ]
    },
    "proof": "..."
  }
}

_credentialSubject_idsubject was chosen to be just some value, a placeholder, until a more suitable value can be agreed upon. Restating my proposal, ...

Proposal A' : Can _"https://www.w3.org/2018/credentials/v1/credentialSubject_id_subject"_ be used in the @context to "turn on/trigger/signal" the processing/business rules that assume the value of credentialSubject id, if present, is to be treated as an identifier associated with a Subject? If it is not present, the name-value pair named "id" is treated as a plain old name-value pair claim like the rest of the claims in the VC (e.g. is treated the same as the "colors" claim).

Thoughts?

David-Chadwick commented 3 years ago

@mwherman2000 You definitely need to add an at-context to define your new properties (colours) and property values (ColorPalette). So depending upon which at-context you use, the same user-friendly property types and values can mean different things (depending upon their URIs)

mwherman2000 commented 3 years ago

@David-Chadwick Thank you for the reply. But my intentions are more subtle. Let me clarify.

If "https://www.w3.org/2018/credentials/v1/credentialSubject_id_subject" is included (or not) in @context, the behavior or interpretation of "credentialSubject": { "id": "did:colorpalettes:primarycolors", ... } would be different in each case:

The Bound Case: If "https://www.w3.org/2018/credentials/v1/credentialSubject_id_subject" is included, the value of credentialSubject.id is interpreted as an identifier associated with a Subject of the claims that follow.
The Unbound Case: If "https://www.w3.org/2018/credentials/v1/credentialSubject_id_subject" is not included, the credentialSubject.id name-value pair would be treated as a plain old claim and not the identifier associated with a Subject.

This enables us to have a physical data model that matches the conceptual data model with a minimum amount of intrusion.

Does that help (with the clarification)? Can this work (from a technical perspective)? ...it's not specific to this VC being about color palettes.

Cc: @kdenhartog @dlongley

kdenhartog commented 3 years ago

Sidenote @mwherman2000 @context is an actually user on github and is getting pinged each time you leave it unquoted. Can you wrap the ` mark around the usage of the term unless you're actually trying to notify him.

mwherman2000 commented 3 years ago

Trying to close out this issue...

section 7.9 bearer credentials

@David-Chadwick Are you sure the ticket example is in Section 7.9 Bearer Credentials?

I can only find this example and it is not the ticket example: https://www.w3.org/TR/vc-data-model/#example-33-usage-of-issuer-properties

@David-Chadwick I would like to try a close this issue but would like to see the full-text of the ticket VC example first?

Separately...

@mwherman2000 wrote:

If a credential contains a credentialSubject property and it, in turns contains an id claim, the value of the id property is to be interpreted as the identifier for a corresponding credential subject.

@msporny wrote:

If the specification stated that exact sentence, would your view this particular issue as being addressed?

Yes. @msporny are you offering to incorporate this sentence into a PR? That would be helpful on my part.

David-Chadwick commented 3 years ago

No the example in section 7.9 is not for a ticket, but is for a degree qualification. Regardless of this, you should be able to easily imply the properties of a ticket that will replace the degree properties. e.g. dateOfperformance, timeOfperformance, titleOfperformance, seatNumber etc

mwherman2000 commented 3 years ago

@David-Chadwick But want I wanted to be able to do is correlate the above conversation about ticket VCs with actual example. I wanted to be able to do that before closing this issue.

Do you have a ticket VC example you can paste into this issue?

David-Chadwick commented 3 years ago

sorry no, but I repeat, it is trivial to build one for your specific use case

mwherman2000 commented 3 years ago

@David-Chadwick @dlongley Gently, we talking past each other.

From https://github.com/w3c/vc-data-model/issues/792#issuecomment-900600017, I quote

I'm not sure if you were asking me, but if you modeled your VC such that the (non-unambiguously identified) credential subject had a ticket with ID XYZ

You two were were talking about a ticket VC as if it was a specific example. The conversation doesn't make sense (to me) without the full text of the ticket VC you two are considering. For example, I can't discern which id (or ids) you're referring to in the above quote.

We can let it go.

iherman commented 3 years ago

The issue was discussed in a meeting on 2021-08-25

no resolutions were taken

View the transcript

#### 5.4. V1 specification doesn't definitively state that the `credentialSubject.id`, if specified, is always the id of the Subject of the Credential (issue vc-data-model#792) _See github issue [#792](https://github.com/w3c/vc-data-model/issues/792)._ > *Manu Sporny:* [https://github.com/w3c/vc-data-model/issues/792#issuecomment-900283929](https://github.com/w3c/vc-data-model/issues/792#issuecomment-900283929) **Brent Zundel:** this editorial change could fit into v1.1 **David Chadwick:** Part of the issue is bearer VC -- understanding who it's attached to -- nobody, everybody, etc. … I don't think it covers the "no holder" use case... we should write about "if not specified". **Brent Zundel:** Let's do a separate issue for that **Manu Sporny:** yes, please.

mwherman2000 commented 3 years ago

@msporny and I worked out some "agreed upon" wording - a single sentence. I will create and submit a PR in the next day or so - by Monday at the latest.

mwherman2000 commented 3 years ago

Closed with the creation of PR https://github.com/w3c/vc-data-model/pull/800

TallTed commented 3 years ago

@mwherman2000 -- I've gone through and code-fenced every un-fenced instance of @context in your comments on this issue. It would be great if you could start doing this yourself.

iherman commented 2 years ago

The issue was discussed in a meeting on 2021-10-27

no resolutions were taken

View the transcript

#### 2.3. V1 specification doesn't definitively state that the credentialSubject.id, if specified, is always the id of the Subject of the Credential (issue vc-data-model#792) _See github issue [vc-data-model#792](https://github.com/w3c/vc-data-model/issues/792)._ **Manu Sporny:** one PR opened but closed, and related changes made in a bigger, still-open PR.... **Brent Zundel:** I think this needs to be deferred because it's more than we can get to quickly. … and should be considered by the v2 group. … objections?. > *Juan Caballero:* (none).

brentzundel commented 2 years ago

I recommend closing this issue without further action

brentzundel commented 2 years ago

No response since marked pending close, closing.

w3c / vc-data-model

V1 specification doesn't definitively state that the credentialSubject.id, if specified, is always the id of the Subject of the Credential #792

Trying to close out this issue...

Separately...