Add guidance on Representations of Verifiable Credentials #1101
Conversation
selfissued
requested review from
mprorock,
decentralgabe,
OR13,
brentzundel and
Sakurann
index.html
Outdated
| Verifiable Credentials can utilize representations other than the standard one defined in this specification. | ||
| They can do so provided that a mapping is defined between that representation and the standard one defined in this specifiction, | ||
| so that deployments that choose to do so can map that representation to the standard one and process it accordingly. | ||
| This mapping definition should state whether it is unidirectional or bidirectional. |
There was a problem hiding this comment.
I think we should also define what we mean here by unidirectional and bidirectional.
There was a problem hiding this comment.
Unidirectional and bidirectional are English words that already have defined meanings.
There was a problem hiding this comment.
It says "This mapping definition should state whether it is unidirectional or bidirectional", this means the mapping is responsible for providing sufficient clarity on this topic.
Mappings might choose to go into great detail on how they accomplished directionality, and it would be inappropriate to assume those details in this section of the spec.
I don't think we need to elaborate further.
There was a problem hiding this comment.
It says "This mapping definition should state whether it is unidirectional or bidirectional", this means the mapping is responsible for providing sufficient clarity on this topic.
We are requiring that the mapping definition declare its directionality.
We should likewise define what we mean by this directionality — e.g., do we care about the field ordering changes and date format disruptions that may result from CBOR-LD conversions? — such that the mapping authors may declare their mapping's directionality according to our requirements!
There was a problem hiding this comment.
@msporny I've incorporated suggestions to revise the title and first sentence. Please re-review.
There was a problem hiding this comment.
Almost there, the title is still ambiguous, I suggested an alternate title that isn't as ambiguous.
|
Noticed after my comments above — this seems rather duplicative (and a bit less clear, if the paragraphs of the other's source are preserved in the rendering [it needs some more |
|
IMO, this language is overly broad. The resolution only addressed what the working group would do. This language could be read to mean that standards developed elsewhere can be VCs. I oppose that language. I'll separate my argument into two parts.
If #1 is incorrect, then any entity anywhere could create a variation on VCs and call it a W3C VC. In other words, we would just be creating a term that people can use rather than a standard for realizing specific functionality. And, after correspondence with Ralph Swick about the organization's trademark policy, they would defend the W3C VC trademark should other organizations claim they created a W3C VC standard. If #2 is incorrect, then everywhere in the specification we would need to change to W3C VCs for everything that is normative for W3C VCs and use separate language for some generic VC term. This would be a spec editor's nightmare and ultimately would completely confuse users who are not going to maintain the nuance between the two. IMO, we should ONLY be defining W3C VCs without confusing people by talking about some generic notion of VCs as some have advocated. In short, this PR seems like an attempt to enable other organizations to take the name of our work and present their work as if its the same thing. Frankly, that's not a standard, it's just vocabulary. What we've all built together is a standard with normative requirements for a particular way to solve particular use cases. IMO, it is vital that we defend the uniqueness of this work rather than dilute its meaning by advocating for misuse to be categorized as authorized used. |
If you're going to be a stickler for language, then please apply that to your own writing, first. ANY entity can "create W3C VCs" by operating as an issuer. The limitation is on the definition of W3C VCs, which can indeed only be done by the W3C, currently through the W3C chartered VCWG. |
|
Agreed. I should have said "any entity could define a W3C VC specification". |
There was a problem hiding this comment.
This language captures the key elements of the resolution.
It aligns with discussions we have had regarding ACDCs, Gordion, Data Integrity, JSON Web Tokens and CBOR Web Tokens.
Many of our working group members are passionate about these security format representations and these changes give us a shared model for inclusivity and diversity which is needed to support securing the core data model.
index.html
Outdated
| <h3>Representations of Verifiable Credentials</h3> | ||
|
|
||
| <p> | ||
| Verifiable Credentials can utilize representations other than the standard one defined in this specification. |
There was a problem hiding this comment.
Yeah, this was the kind of slippery slope definition of "Verifiable Credential" that I was concerned about... I know others in the group want to call other things "Verifiable Credentials" and some are asserting that we state "W3C Verifiable Credentials" to disambiguate... but this is begging for their to be confusion around the term. Some might argue that this is being done to deliberately confuse the market into believing that things that have almost nothing to do with Verifiable Credentials, are in fact, Verifiable Credentials.
Fundamentally, this comes across as the "JWTs /are/ VCs" rhetoric, and that's problematic. I doubt that is the intent of this PR, but it can certainly be mistakenly interpreted that way.
We might want to be careful about how we speak to the "compatability" between two media types.
We might want to break this down into multiple categories:
- Media types can full envelope the Verifiable Credentials data model (e.g. VC-JWT, VC-CWT, that contain an
@context-- these areapplication/vc+ld+jsonVCs that are secured using JWT or CWT), and - Media types that express information that can be transformed into the Verifiable Credentials data model (JWTs w/ a default
@context, ACDC, Gordian, etc. -- these are not VCs until after they are transformed)
What we want to say is probably more along the lines of these categories being *compatible* with the VCDM (if you can unidirectionally or bidirectionally transform to application/vc+ld+json).
There was a problem hiding this comment.
Fully agreed, @msporny.
(Please go back and code-fence the @context in your category 2.)
There was a problem hiding this comment.
The title of the section and the first sentence are the only things that I find issue with in this PR. The rest of it seems fine.
It also seems like a dupe of #1100, which does a better job of stating what a specification has to do to establish itself as "Transformable to/from Verifiable Credentials".
Co-authored-by: Ted Thibodeau Jr <[email protected]>
There was a problem hiding this comment.
agree with the direction - short and concise. few suggestions to address Manu's concern around the first sentence. The section title seems ok to me.
This PR seems to have more approvals than #1101 now. Suggest we work on this one and merge this one first and refactor #1101 to add anything that might be missing.
Co-authored-by: Kristina <[email protected]>
Co-authored-by: Kristina <[email protected]>
index.html
Outdated
| <p> | ||
| The standard representation of a Verifiable Credential is defined in this specification (which uses the media type <code>application/vc+ld+json</code>). | ||
| Other representations can be used, provided that a mapping is defined between that representation and the standard one. | ||
| This mapping definition should state whether it is unidirectional or bidirectional. |
There was a problem hiding this comment.
This sounds like an RFC SHOULD <-- instruction to specification author.
There was a problem hiding this comment.
A few more minor changes requested, should be good to go after this set of changes. I'll note that this language is fairly toothless w/o any normative statements... and expect that #1100 will have to be layered on top of this one.
|
|
||
| <p> | ||
| The standard representation of a Verifiable Credential is defined in this specification (which uses the media type <code>application/vc+ld+json</code>). | ||
| Other representations can be used, provided that a mapping is defined between that representation and the standard one. |
There was a problem hiding this comment.
In order to avoid confusion, we should say that the required mapping must be for all instances in a given representation to the standard one (i.e., at least one "general" mapping exists). A bespoke, one-off mapping for some particular instance in that representation is insufficient.
Of course, anyone can use whatever mappings they want to (including doing bespoke mappings) for application-specific purposes, but that is orthogonal to the need for a general purpose mapping.
| Other representations can be used, provided that a mapping is defined between that representation and the standard one. | |
| Other representations can be used, provided that a mapping is defined for all | |
| instances in that representation to the standard one. |
There was a problem hiding this comment.
I can live with this, although I don't know that everyone understands existential qualifiers, or that they are adding anything here.
There was a problem hiding this comment.
there could be more than one mapping per representation, as long as it maps back to the same base data model, so I do not understand for all part.
There was a problem hiding this comment.
| Other representations can be used, provided that a mapping is defined between that representation and the standard one. | |
| Other representations can be used, provided that a mapping is defined for any | |
| instances in that representation to the standard one. |
i can live with for any I think.
There was a problem hiding this comment.
What I want us to say is: for all x in some other representation, there must be an f such that f(x) is the standard representation. This might be the same as saying "for any x" and we're just stuck on a language issue but really mean the same thing. What is important is that there must not be any x such that f(x) is undefined; f must be a complete mapping ... which rules out handcrafted mappings as being sufficient here.
Again, this doesn't mean someone can't make a handcrafted mapping for some particular use case (not that we could ever stop that with spec text anyway), nor does it mean that there can't be some other function g with the same properties as f. It just means that at least some f must be defined.
Co-authored-by: Ted Thibodeau Jr <[email protected]>
Co-authored-by: Ted Thibodeau Jr <[email protected]>
Co-authored-by: Manu Sporny <[email protected]>
|
|
||
| <p> | ||
| The standard representation of a Verifiable Credential is defined in this specification (which uses the media type <code>application/vc+ld+json</code>). | ||
| Other representations can be used, provided that a mapping is defined between that representation and the standard one. |
There was a problem hiding this comment.
| Other representations can be used, provided that a mapping is defined between that representation and the standard one. | |
| Other representations created by the VCWG can be used, provided that a mapping is defined between that representation and the standard one. |
Representations defined by other organizations will never be W3C VCs. This language currently implies that any other representation that maps to VCs can call itself a VC.
It would be trivial to construct an arbitrarily ridiculous representation, create a mapping and call that a VC.
I don't believe this language would pass muster when it comes to CR.
This is why the resolution itself is explicit about limiting the scope of the resolution:
(defined by the VCWG)
It is not our place to direct others about what they may call Verifiable Credentials.
I also don't know what "Other representations can be used" means. Of course, people can use whatever representations they want for whatever they want. What does that have to do with W3C Verifiable Credentials?
It's also not appropriate to state that representations created by something other than the W3C are in, fact, W3C Verifiable Credentials.
It is also not appropriate to use the term Verifiable Credentials to mean anything OTHER than W3C Verifiable Credentials.
I've suggested this change to clarify that scoping.
There was a problem hiding this comment.
-1 to "created by the VCWG"
Broad adoption of VCs would be hamstrung if every use case required a special dispensation from the WG. This becomes impossible once the WG disbands.
There was a problem hiding this comment.
I agree it would be hard if the W3C VCWG has to create all mappings. The VCWG does not have subject matter or domain expertise to create all possible mappings.
For that reason, also -1 "created by the VCWG".
There was a problem hiding this comment.
I'd be ok with "registered in the VC Directory" though if the registration process stays slim and non-political.
There was a problem hiding this comment.
-1 to "created by the VCWG", we passed a resolution specifically to remove this requirement.
There was a problem hiding this comment.
agree with Orie, we explicitly noted that representations need not be created by the W3C
There was a problem hiding this comment.
-1 to "created by the VCWG", we passed a resolution specifically to remove this requirement.
agree with Orie, we explicitly noted that representations need not be created by the W3C
It would be helpful if you could include/add a link to the resolution being cited.
There was a problem hiding this comment.
There was a problem hiding this comment.
Transformations can be defined by parties other than the working group.
There was a problem hiding this comment.
The resolution explicitly includes:
Transformation rules MUST be defined, but not necessarily by this WG.
@OR13 that language was literally in the resolution. IMO, it's more appropriate to call this PR a "rug pull" trying to reverse that aspect of the resolution just because some people want something OTHER than what was in fact agreed to. You don't get to re-write the fundamentals of that resolution in a PR that says
Quoting that resolution
Until this PR accurately represents the actual resolution as adopted, it should not be considered. Alternatively, create a new issue that starts from acknowledging that the resolution was a bad idea. Then we can revisit the question of whether or not any old group can define a specification for Verifiable Credentials. However, attempting to rewrite the resolution in the name of upholding the resolution is at best an unfortunate error, at worst, an unethical attempt to misrepresent the history of our work. What we did agree about was a path for outside groups to get their specifications adopted as W3C Verifiable Credentials. Unfortunately, the ACDC proposal got crunched in the feature freeze and related matters of timing. I want to be clear. I think ACDC should have the opportunity to establish a version of itself that are legitimate W3C VCs. To do that, this Working Group would need to vet the proposed specification in exactly the same way we are collaboratively iterating on VC-JWT. WE SHOULD DO THAT. What we should not do is abdicate the authority of the W3C to define what VCs actually are. The right answer to the ACDC question is to extend our charter to give us additional time to consider additional serializations that can map to our base media type. |
I agree with this, I would not recommend ANY media types be defined in this working group, that might make use of a "mapping" this includes If we can't agree to this working group getting a representation correctly, this working group should not be doing the work. I don't see any evidence that This is exactly what made the last version of I think rechartering might be a good option. To be clear, I would sooner kick out
|
|
Also @jandrieu I have to say that I read your caps replies in your voice, and I appreciate the emphasis, and your passion on this point. : ) |
msporny
added
DO NOT MERGE
| Other representations can be used, provided that a mapping is defined between that representation and the standard one. | ||
| This mapping definition is expected to state whether it is unidirectional or bidirectional. | ||
| Deployments that choose to do so can map the representation to the standard one and process it accordingly. | ||
| A media type is expected to be defined for each Verifiable Credential representation, which can then be used to distinguish between representations. |
There was a problem hiding this comment.
| A media type is expected to be defined for each Verifiable Credential representation, which can then be used to distinguish between representations. | |
| A media type is expected to be defined for each verifiable credential representation, which can then be used to distinguish between representations. |
|
The issue was discussed in a meeting on 2023-05-17
View the transcript3.3. Add guidance on Representations of Verifiable Credentials (pr vc-data-model#1101)See github pull request vc-data-model#1101. Michael Jones: Manu is the only one left. Joe Andrieu: I'm opposed to this, I'm not one of the requested reviewers, didn't review negatively. This does not address resolution in Miami, this has to do with media types in WG... This PR fundamentally changes the meaning of that resolution. If this is a representation of that resolution, we need to have that language in there.
Dave Longley: I had some change requests as well that I would like applied. Manu Sporny: I was holding off on re-review because of Joe's and Dave's outstanding comments.
Manu Sporny: I felt the other PR has better language. This doesn't have any teeth.
Manu Sporny: this has to do with the Miami resolution. Michael Jones: Kevin's PR talks about unrelated issues that are controversial, including testing requirements which the Miami resolution did not.
Michael Jones: unless Kevin removes that PR it should not be merged. Brent Zundel: I expect this to be the special topic call next week. |
|
The issue was discussed in a meeting on 2023-05-23
View the transcript1.1. Add guidance on Representations of Verifiable Credentials (pr vc-data-model#1101)See github pull request vc-data-model#1101. Brent Zundel: raised by Mike Jones but not on the call today. In absence of Mike is there someone who can give a summary of PR. See github pull request vc-data-model#1101. Brent Zundel: this PR adds some non-normative guidance in added section for guidance for representation provided mapping between mapping and standard one. Takes the language of miami removes the normative text and puts it in spec as non-normative. Kevin Griffin: In terms of concrete changes I think PR is aiming to go in ratifying Miami is good but would like to see substantive guidance of what a transformation means (such as pr 1100 or section in DID method spec of what must a method do to be a DID method) if we are going down path of other representations we should provide more substantive guidance of If your are going to do this this is how you should do it. Give developers a path to emit compatibles.
Joe Andrieu: pretty important point in the resolution which to me is vital to scoping the maimi agreement. 1101 language reverses the scope of the miami resolution. As I mentioned on last call I don't think this is an appropriate representation either honest mistake or an attempt to rewrite miami.
Brent Zundel: which specific language? Joe Andrieu: in chat is pull request with adding back language.
Orie Steele: I think Kevin summed it up. Supporters of pull request 1101 don't want to get into the business of giving normative requirements testability. PR 1101 tries to say that people outside the WG can do it by mapping. Joe was correct that there was language that said if we define those mappings here we have to go into extra effort to do this. The other PR 1100 does add those extra teeth to cover in tests. One thought is that if the WG is not defines what value does the language do. The only other one is the mapping in other work item I would rather not define that particular thing. But perhaps there is a shorter resolution that require a mapping.
Dave Longley: Had put in PR a while back a change before I could support PR to make sure we are clear what we expect from a mapping. The transformation rules must allow any instance to generally convert back to the base representation. That case by case mapping a insufficient.
Manu Sporny: My biggest concern about this PR 1101 is that it lacks any kind of normative statement. It informative that allows anyone to be compliant and there is no way for someone to vet if arbitrary transform is legitimate or not. There is one test that you could use. Such as if it results in the core data model. The what does ACDC gordian envelope need to define to transform. I says a bunch of things that should be said normatively in an informative way. Brent Zundel: My understanding is that the normative guidance is that it applied to things outside the WG I did not think it meant that it only applied to things exclusively done by this WG. My understanding, this PR is a good faith representation of the Author (mike jones) understanding of Miami.
Joe Andrieu: I agree in part with what you said, we do agree that other entities can define transformations. not a burden on this WG. My support specifically for that resolution is the scoping fo things we were doing. Important, I was the one who asked for that language. I can accept that other people would prefer that other orgs be able to do this. Want to know how we can reconcile. Manu Sporny: the way I am looking at this I am not thinking about the resolution that much clearly we have different interpretations of the resolution so I am looking at the two PRs. either we are going to non-normative -1 on that. or we are going to make normative statements. Prefer we write spec text that guides implementers. Kevin had a good questions. What is the minimum guidance we can all agree to as a group but as minimum it should be normative.
Manu Sporny: the min guidance is you can call whatever you are doing as Compatible with w3c VC as long as after the transform you are compliant with the core data model using a normative transformation. Putting that up as straw man. As guidance to spec writers in other WG.
Brent Zundel: I heard statement with normative guidance if the result of that transform (summary) of Manu's comment. Joe Andrieu: Anyone can say compatible its can they say its a VC w3cx VC. decide if it meets our standards. Giving some other org license to make a compliant w3c VC is wrong.
Kristina Yasuda: Who is this group to dictate what other standards bodies do. We can only dictate what happens in this WG. we are pretty much at deadlock as I am against any normative statements and Manu wants to see normative statement. So how to move forward. Bottom line that where I am right now.
Orie Steele: Kevin mentioned did specs. Maybe thats aligned with what Manu is saying. Did WG says here are minimum. Our spec becomes like the did core. that is a fundamentally untestable statement. You could create a registry and then the registry entry can assert they meet the spec. We could do the same for verifiable credentials. You could say that for a transform. But from a did core testability there would not be any tests and there would be a burden.
Orie Steele: to ensure conformance. And we did receive a lot of complaints around did method interoperability. But it is a potential minimal approach.
KevinGriffin: I got on queue to agree with Manu to define normative language forward. in order to facilitate to help other create transformations. We are possibly naive in saying the w3c can exclusively say what is a vC. We are in a position to normatively state what is possible to be what is a VC data model. We can relax how hard but there is a path forward. You can't call yourself a w3cvc unless you meet that test spec. Can we go to the VC spec is passing the test that transform loose enough.
Samuel Smith: I was wondering if we could do a poll to get temperature -- spectrum of opinions and maybe Manu, Kevin, Orie, and Kristina are closer together than Joe? I'd like to see if we could try to get between two closest opinions? Brent Zundel: I think a poll would be a good idea. ChristoperA: three issues we are conflating. VC is not a trademarked term we cannot do anything about lower case vc. In general they don't care about w3c and we maybe don't care about them. 2nd vc-acdc vc-gordian vc-jwt desire to have imprimatur of VC there is a process which should be part of the registry process. I was disappointed we did not get very far. we never got beyond provisional. We can do same with VCs. But in order to get it to get to next level we need something you can test it go make it more that provisional. But then anyone should be able to say that it passes the test. 3rd then once it passes a conformance test then it becomes an action item for group to change from passing test to conformant implementation. third big area I plan on my roadmap to make a transform of Gordian at that with conform with base set of testing tools. But I never plan on making [CUT]. ChrisAllen: I think gordian can do better can do more so the majority of gordian can be beyond the VC data model but if one wants to use our libraries to accept a conformant subset. But I shouldn't be a second class citizen if I am able to pass conformance test.
Manu Sporny: I wanted to clarify, heard the phrase then we are w3c VC that these are equivalent things have strong -1 reaction to that. There is one data model that is a W3C VC. Those things like Gordian are their own thing, there may be transforms that lossless transform. The language we are trying to use is that these are compatible with bi-directional transform. The thing I am most concerned about is that someone is going to game it in such a way has having a negative impact on interop like big vendor pushing W3C VC when then are not. We want to enable ACDC, JWT, Gordian because strongly legitimate attempts to do mapping correctly. What we are talking about is a mountain of work. We DID core not testable. Concerned that WG is about to bite off mountain of work with 4 months left. Feels like this conversation keep going.
Orie Steele: queued to suggest concrete thing we can poll on. "Remove the media type for vc-jwt which is the only media type that requires a mapping and then close both PRs 1100 and 1101. The primary contentious point is no longer valid.
Orie Steele: but not because we don't like vc-jwt -- because it's the "transformation" part of that spec, which will send us in circles.
Brent Zundel: only -1 is Christina.
Samuel Smith: If we remove the language, what does it do to external proof formats?
Christopher Allen: wanted to ask for christina for people not on this special meeting. My take on process perspective is it possible to move details around vc+jwt into a note not normative these are where we are at.
Christopher Allen: concentrate on closing. without acknowledging jwt not show up to community. maybe that causes us to get us knocked out due to objections. Orie Steele: answer sam's question about proof can be optional internal or external and is not operative in determining if VC or not. Unlike what spec says. adding a proof does not make it verifiable. Brent Zundel: Chairs take it under advisement. maybe excise those portions that transform leaving those that sign VC data model. Three paths. 1, add non normative guidance for tranforms. 2 add normative spec text minimum guidance for transforms 3. excising from vc-jwt the transforms with keeping jwt a securing mechanism.
Brent Zundel: appreciate participation today everyone was nice. |
|
The issue was discussed in a meeting on 2023-06-27
View the transcript4. Add guidance on Representations of Verifiable Credentials (pr vc-data-model#1101)See github pull request vc-data-model#1101. Michael Jones: I re-reviewed the status of 1101 and the related PR 1100 and I feel like we are at an impass. It was intended to be a short summary of. Manu Sporny: mike, that might work. I think you are right. we are at an impass with the proposal. You did your best to captures something. One approach. Michael Jones: I could not write text into the specification with negativity about the working group.
Kristina Yasuda: closing the meeting. |
|
we are expecting @selfissued to raise another PR and then this one can be closed. |
|
The issue was discussed in a meeting on 2023-07-11
View the transcript1.2. Add guidance on Representations of Verifiable Credentials (pr vc-data-model#1101)See github pull request vc-data-model#1101. Brent Zundel: this P.R is around trying to make Miami resolution actionable. |
1 similar comment
|
The issue was discussed in a meeting on 2023-07-11
View the transcript1.2. Add guidance on Representations of Verifiable Credentials (pr vc-data-model#1101)See github pull request vc-data-model#1101. Brent Zundel: this P.R is around trying to make Miami resolution actionable. |
brentzundel
added
pending close
|
PR #1203 merged. |
Makes the results of the Miami day 3 resolution referenceable and actionable. See https://www.w3.org/2017/vc/WG/Meetings/Minutes/2023-02-16-vcwg#res for the text of the approved resolution.
Preview | Diff