Closed andorsk closed 1 year ago
@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.
@AFlowOfCode : Sure. It can be found in several places:
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.
@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.
Feels like we might be able to add a diagram in an appendix about the "id"?
The issue was discussed in a meeting on 2023-04-19
No objections raised since being marked pending close
. Closing.
The example https://www.w3.org/TR/vc-data-model/#identifiers gives the following description for 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:
I would be happy to raise a PR on this, given some direction.