more clarity around the `id` field in the VC data model

[andorsk]

The example https://www.w3.org/TR/vc-data-model/#identifiers gives the following description for id:

The value of the id property MUST be a single URI. It is RECOMMENDED that the URI in the id be one which, if dereferenced, results in a document containing machine-readable information about the id.

with an example http://example.edu/credentials/3732 which doesn't dereference into anything meaningful.

As an implementer, I'm struggling to figure out exactly what type of data the ID field should dereference to and what the recommendation is on it.

It would be helpful to provide more clarity on the data model about:

1. What type of data should the dereferenced id generally contain.
2. A working example of a dereferenced id

I would be happy to raise a PR on this, given some direction.

[AFlowOfCode]

@RieksJ Can you link to the explanation you reference, if you can recall where to find it? It could be helpful & possibly move the conversation toward clearing up some confusion about the positive cases in which you do want to use the credential ID.

If this property is specifically limited to cases such as you describe, then naturally it would make sense to state that the credential ID is actually not meant for cases where this "assumption" as you call it is known to be true. Perhaps this is where my personal lack of clarity stems from - not realizing this credential ID property never was intended to have a use case in such a single-holder context at all.

In my case I'm not assuming anything. As an implementer I can tell you that "every claim in the VC is about the same entity and that entity is holding the VC" in 100% of the cases in the system I'm working on. It's both a logical necessity and a hard requirement stemming from the type of credential the system deals with (similar to a driver's license). My line of inquiry is directly informed by the real-world context of a production system currently issuing VCs in the wild, not a casual theoretical reading of the specification while making assumptions about who might end up using it.

[RieksJ]

@AFlowOfCode : Sure. It can be found in several places:

1. The definition of 'issuer' implies this;
2. The definition of credential (in the terminology section) has the phrase "The claims in a credential can be about different subjects."
3. The two notes just below figure 6 are also illustrative: one is an example of a credential containing claims for unrelated subjects, the other says that a credential may not contain claims for the subject to which it was issued.

My idea of an assumption in this issue is any constraint in a particular context that does not hold in the general case, as described by the VCDM text. Examples of such constraints are "a credential holds exactly one claim", "all claims in a credential have the same subject" (which could be combined with: "the subject of a credential must be the holder"), etcetera. And it is obvious to me that in use-cases where particular constraints apply, you can make use of that and take appropriate shortcuts that would not work in the general case.

Where I have a problem is where you contrast your 'line of inquiry' with the VCDM spec, saying that you are doing the real practical work and VCDM is a casual theoretical reading. If that is your take, I suggest to either go away and don't get mixed up in making contributions to 'casual theoretical reading', or you make concrete proposals to improve its use, which starts by actually reading it (which I guess you haven't done because you would have easily found the references you asked me to provide), understanding it, and using the stuff as specified.

[AFlowOfCode]

@RieksJ I think you misunderstood my point, as that is not my take at all. I wanted to clarify that I am implementing a concrete situation against the spec (therefore I'm not making any assumptions about my use case) vs trying to argue in theory (which might very well involve assumptions about general use cases). In other words it was to clarify my approach to the topic, not contrast it against yours or anyone else's.

I have found that the explanation of use cases for this property as a URI is confusing or lacking and only have sought clarification. Naturally my emphasis is from my specific situation, because it's the one that matters to me right now. If it weren't for a desire to understand the intention here I wouldn't have bothered showing up at all.

I do believe you have been helpful in that I can now disregard the credential ID as simply unintended for the type of VCs I'm using. What you've cited is not something I ever disagreed with in any way, as I have always known it is possible that a VC can contain claims about multiple subjects, just as it is possible that it doesn't. None of that, other than perhaps its general nature as being optional, states that the URI credential ID is typically only intended for this type of VC (unless of course you don't care about facilitating correlatability).

I have read through the spec (last time was in Dec 2022, so I'm not sure what's been added in any updates) and I do not believe this is clear. I'm sorry but I just don't. Sometimes things are not clear even after having read something, it does happen to us lesser beings sometimes and I do offer my sincerest apologies for that. I never would have bothered seeking out this issue and attempted to gain more clarity on the intention behind this property if I thought it was clear. Perhaps you can at least grant me that?

In any case I believe I've finally gotten the clarity I came here for, thus my inquiry is at an end. Weathering some defensiveness and/or condescension is a common coin to pay with when approaching the elites sometimes, but worth the price to be sure I'm not overlooking anything important. Thanks for your contributions and please don't feel obligated to throw any more of your time away on such petty matters.

[msporny]

Feels like we might be able to add a diagram in an appendix about the "id"?

[iherman]

The issue was discussed in a meeting on 2023-04-19

• no resolutions were taken

View the transcript

#### 2.3. more clarity around the `id` field in the VC data model (issue vc-data-model#973) _See github issue [vc-data-model#973](https://github.com/w3c/vc-data-model/issues/973)._ **Orie Steele:** This is also related to those pictures, the graphical representations of what a credential looks like and whether a proof is related to it. … I think this is another case where pictures could help a lot. It means something to have a credential that has an ID -- and it means a lot when you're joining a graph with other graphs which is a thing you do when you process the core data model. … When you don't give it an ID, you make it basically impossible to do a join on that property. That makes visualizing what you're trying to do difficult and getting an identifier for that kind of thing in an application specific way -- all of that difficult. This all impacts app developers, data analysis, a number of things, it's important. > *Orie Steele:* +1 to graph visualization. **Manu Sporny:** Thinking about what Orie said in the other issue and here. We have these tabs in the different types of securing mechanisms -- if we added another tab for graphical visualization I imagine that might address some of the concerns you're raising. > *Orie Steele:* I can provide some code for that if there is desire. **Manu Sporny:** The fall back to that would be to hand create some examples and put them in the appendix. For visualizing the graphs and mental models, etc. I'm struggling to understand what we can concretely do to address the issues to just put into the minutes and given enough spare time people can work on creating those things. They will require a decent bit of time to get into a form that communicates what we want. **Ivan Herman:** I must admit that whenever I work with RDF I am thinking about graphs and visuals myself, very much a +1 to what Manu says. The little problem that relates to the previous issue is that the tools that are around to create more proper visualization of these RDF graphs, to the best of my knowledge, are pretty poor. They certainly cannot handle data sets but only graphs. … That additionally visual glue that is necessary is missing, usually and that's of course a problem. … That means that I'm afraid that they will have to be made by hand using Google Draw or whatever. … It's a small red flag in the direction of what Manu is saying -- maybe not systematically but maybe for some of the bigger examples doing it. … One other comment -- this issue went in a lot of different directions, we might want to close it because it's a conversation anyway, but close with the additional agreement that we will do something with visualization or something. > *Manu Sporny:* +1 to Ivan's suggested path forward.. **Brent Zundel:** So raising an issue to add visualizations as a concrete way to solve this and close it. … Can anyone open the new issue and link it to this one?. **Orie Steele:** I can do that. **Brent Zundel:** I'm going to mark this one pending close. … Thank you. … I'm going to resist the temptation to keep talking about issues even though I really want to be I really want to because we're past the time that was allotted for that. … So, moving onto work item status and PRs.

[brentzundel]

No objections raised since being marked pending close. Closing.