Closed andresuribe87 closed 9 months ago
-1 for at least these reasons:
We don't embed the data structure name in the property names for most (if not all?) other properties. We don't use "mediaTypeString", we use "mediaType", we don't use "typeArray", we use "type". So, listing the data structure in the name feels like the wrong thing to do here.
Everything we do in the spec is a part of a graph, so injecting the word "graph" here and not elsewhere doesn't seem to make sense either... and injecting it everywhere feels unnecessary.
I'm not convinced that adding this word is going to "fix" any sort of bug, as the case for why it would prevent bugs hasn't been made.
Finally, implementations have been using verifiableCredential
for years now w/o major issues. We're past what would be theoretically nice to do what's the practical ROI on this change? Presently, it feels like the ROI would be negative on this change: it wouldn't fix any bugs, it would look weird because it's not how we (generally) name properties, and it would be incompatible with all current implementations out there.
It falls into the same category as renaming "credentialSubject" to "subject" -- it would've been nice to do that in v1.0, but given that this is the 3rd version of the specification, changing it now doesn't feel like it would add much value while further complicating processors.
The definition was changed from what VDCM 1.1 stated to say that only verifiable credential graphs are acceptable as the value.
Previously, implementations would use verifiableCredential
to put in externally secured verifiable credentials. Now, the WG is stating that it isn't an acceptable use. This means that implementations are already being asked to update the semantics of the field. The decisions of the WG require implementations to update the handling of the logic of the verifiableCredential
property.
Without renaming, the property is likely to be used in the same way as it was used in VCDM 1.1. Renaming that property prevents implementations from misusing the term.
@andresuribe87,
The definition was changed from what VDCM 1.1 stated to say that only verifiable credential graphs are acceptable as the value.
How this is not a breaking change was discussed here: https://github.com/w3c/vc-data-model/pull/1259#discussion_r1311879185
basically a dupe of https://github.com/w3c/vc-data-model/issues/1365
still basically blocked by
The issue was discussed in a meeting on 2023-12-06
@andresuribe87, I read back over the current specification text and think it does state the domain and range pretty clearly:
What concrete changes are you requesting to this text?
IOW, I agree with @OR13, this seems to be a dupe of #1365 (based on the way the discussions are going in the WG). Marking this as pending close. @andresuribe87 feel free to object if you disagree w/ the above and we're not seeing the nuance between the two issues.
Closing this as a duplicate of #1365
From https://github.com/w3c/vc-data-model/pull/1358#issuecomment-1831580248, it became evident that the name for the property
verifiablePresentation.verifiableCredential
is misleading, and the definition needs further clarification.Relevant excerpt from the conversation below: