Make the usage of @context optional
#947
Comments
|
Since making First, in my view, any argument that makes a VC look and function just like a JWT (and uses the same centralized registry extensibility mechanism) is not a good argument -- because the JWT spec already exists and people can just use a JWT if that's what they really want. Instead, we should assume that some additional constraints will be needed in order for people to achieve interop with VCs -- especially given the three-party model, data linkability / mergeability, and level of openness that they intentionally introduce. Second, if an argument is made that having to process |
|
I was lead here by the interesting post by @decentralgabe The system being designed is of a decentralized nature This comment is more of an observational nature, rather than a solution or proposal. I would like to record it, but there isnt an expectation of a response here, so do not feel the need to reply, unless you really want to It strikes me that the verifiable claims data model, if
There seem to be secondary soft dependencies within that web page:
Additionally linked vocabs may depend on
That's all fine and I appreciate this is versioned by specific year (2018) and number (1.1) and expected to be set in stone, assuming the vocabs are well maintained, which I expect it to be However, adding this What would the solution be for systems that would like to use ability to verify claims, but not necessarily download and cache the I dont have a solution here, this is more an observation. But, I can picture dweb implementers complying with the spec 90% but leaving out parts they dont like. Which might be the reality today. Maybe that's OK. Any advice for projects in the decentralized web looking at this technology? |
|
@melvincarvalho wrote:
Yes, treat the values in We had contemplated all that you say above in v1.0 and v1.1 and that is why the specification provides the entirety of the content and a hash for the base VC context. https://w3c.github.io/vc-data-model/#base-context -- and we'll continue to do that. Also keep in mind that the "dependencies" you call out are not required for operation of the system -- if you can resolve them, great, but don't build your PRODUCTION software such that you have to depend on resolving them. I'll address your concerns one by one below:
You can perma-cache JSON-LD Contexts; ship your production software w/ static copies of all contexts if you're doing JSON-LD processing. If you're not doing JSON-LD processing, you can just check that each value in
Again, you don't have to download anything from there. Even if w3.org were to go away, it's backed up in Internet Archive and the US Library of Congress. There is an archival policy that would require multiple nation states to fail for the domain and its content to disappear completely. Same as above.
None of these are required to exist forever. That said, for these to go away, multiple companies and people would have to fail at the same time, Microsoft would have to take down Github, all cloned w3id.org repos on hundreds of peoples systems would all have to simultaneously disappear. The greatest single risk is probably the domain disappearing (which is pre-paid up to a decade in advance). We have redundancies (listed on the public web page) when it comes to domain management for w3id.org.
As long as the w3id.org service or w3.org is available, we expect those vocabulary documents to be reachable. If the vocabulary documents are not reachable, nothing breaks (except possibly semantic reasoners, of which there are zero operating today... and if there were, we'd expect them to download and perma-cache the vocabulary documents in a production setting). For those reasons, I don't believe your concerns are as dire as you might believe them to be. Can we do better? Yes, of course, we want to... but we're getting to the point where large companies (Microsoft / Github / Rackspace / Internet Archive / US Library of Congress / Arctic Code Vault) have to simultaneously fail for us to be put in a sticky situation... and that, after we've told people for YEARS that they should not load from the network in production. Does that address most of your concerns, @melvincarvalho ? |
Thanks for the detailed explanation. I think the trade-offs have been well expressed. There remains some nuances and mitigations, but probably off-topic for this thread, at this point. |
|
I'm a strong -1 to making In my opinion, it defeats the entire purpose of the VCDM. If you want to sign or encrypt JSON or CBOR, there are excellent standards at IETF, which you should use. We don't need to make |
|
The issue was discussed in a meeting on 2022-10-19
View the transcript3.1. followup of the TPAC discussion on JSON/JSON-LD.Manu Sporny: original issue has come from TPAC, but it seemed as if there were two separate issues.. See github issue vc-data-model#947. Manu Sporny: first one requests @context to be optional. See github issue vc-data-model#948. Manu Sporny: so that a JSON only developer wont need to worry about JSON-LD processing.
Manu Sporny: intention is that you wont need a JSON-LD processor to use @context. Brent Zundel: folks should read the original issue for background and good information. |
|
I'm obviously in favor of making |
If that is the goal, it sounds like it might be solvable in other ways which is the discussion in #948. Being specific about what is difficult should also be raised in that other issue so it can be more adequately discussed / addressed. |
|
I have not had the bandwidth to more fully participate in this WG, however since this particular issue received many months of discussion in the W3C DID WG — where it was ultimately decided that @context would not be required in the plain JSON representation of a DID document — I wanted to share some of those learnings here. Although I am not a developer myself, in my discussions over the past few years with developers of various types of "verifiable credentials" (meaning the generic term as defined by the VC 1.0 spec: "A set of one or more claims made by an issuer that has authorship that can be cryptographically verified"), the feedback I have gathered is: while JSON-LD and the RDF graph model is one perfectly good solution to decentralized semantic interoperability, it is not the only one. What I have seen in the wild is at least three other solutions:
None of these are abstract examples — all in use today. For example, LPGs (expressed using JSON Schema) are the basis for semantic interoperability of the ACDC credential format used by GLEIF vLEI credentials that are on a path to be adopted by over 70 financial services regulators around the world. My point being: by all means use But if a credential uses a different representation, that representation should define its own mechanism to control semantic validation. I believe that's what @selfissued meant when he said, "Let JSON be JSON". |
Yes, but I would add here that the goal of the DID WG was to support multiple representations that could be losslessly converted! Whether or not the DID WG succeeded in that, or how complex that process has become, is another story. If the VC WG ends up deciding that additional representations (such as JSON without |
That makes sense to me.. If someone wants to use plain JSON (without What would a |
|
Here are some examples: Especially this one: {
"iss": "https://spec.smarthealth.cards/examples/issuer",
"nbf": 1663010381.698,
"vc": {
"type": [
"https://smarthealth.cards#health-card",
"https://smarthealth.cards#immunization",
"https://smarthealth.cards#covid19"
],
"credentialSubject": {
"fhirVersion": "4.0.1",
"fhirBundle": {
"resourceType": "Bundle",
"type": "collection",
"entry": [
{
"fullUrl": "resource:0",
"resource": {
"resourceType": "Patient",
"name": [
{
"family": "Anyperson",
"given": [
"John",
"B."
]
}
],
"birthDate": "1951-01-20"
}
},
{
"fullUrl": "resource:1",
"resource": {
"resourceType": "Immunization",
"status": "completed",
"vaccineCode": {
"coding": [
{
"system": "http://hl7.org/fhir/sid/cvx",
"code": "207"
}
]
},
"patient": {
"reference": "resource:0"
},
"occurrenceDateTime": "2021-01-01",
"performer": [
{
"actor": {
"display": "ABC General Hospital"
}
}
],
"lotNumber": "0000001"
}
},
{
"fullUrl": "resource:2",
"resource": {
"resourceType": "Immunization",
"status": "completed",
"vaccineCode": {
"coding": [
{
"system": "http://hl7.org/fhir/sid/cvx",
"code": "207"
}
]
},
"patient": {
"reference": "resource:0"
},
"occurrenceDateTime": "2021-01-29",
"performer": [
{
"actor": {
"display": "ABC General Hospital"
}
}
],
"lotNumber": "0000007"
}
},
{
"fullUrl": "resource:3",
"resource": {
"resourceType": "Immunization",
"status": "completed",
"vaccineCode": {
"coding": [
{
"system": "http://hl7.org/fhir/sid/cvx",
"code": "229"
}
]
},
"patient": {
"reference": "resource:0"
},
"occurrenceDateTime": "2022-09-05",
"performer": [
{
"actor": {
"display": "ABC General Hospital"
}
}
],
"lotNumber": "0000001"
}
}
]
}
},
"rid": "MKyCxh7p6uQ"
}
}^ note that this data is not a valid W3C Verifiable Credential... but it looks a lot like one... This kind of thing muddies the waters and makes the standards less useful, and should be discouraged because it creates confusion and is harmful... it would have been better for them to just use a vanilla JWS / JWE. |
|
I think that "saying there are a lot of other ways to do things out there in the wild" is not a good enough argument to make context optional -- it's an argument that will harm interoperability. Those other things "out there in the wild" aren't being standardized -- and if we say "you can pretty much do anything", then we're not standardizing anything here either. I should add -- if any of those things "out in the wild" are already standardized and they solve someone's use case, then that person should go use them, not try to change what we're doing here to be the same thing with a different name. |
|
@dlongley Your comment goes to the very heart of the fundamental question for this WG: Is the goal of the W3C VC 2.0 standard to be:
If the former, then simply bite the bullet and require all W3C-conformant digital credentials to use JSON-LD, period. But recognize that means there's no bridge with JWT/JWP, ISO mDL/mDOC, ToIP ACDC, AnonCreds, ICAO DTC, and potentially others coming out of the EUDI work. If the latter, then the VC WG needs to tackle the issue of multiple representations of the VC Data Model. |
@peacekeeper Lossless conversion of DID documents was possible because DID documents are not required to be digitally signed. VCs must be digitally signed. So that means lossless conversion is not an option with VCs (crypto engineers please correct me if I'm wrong). However lossless conversion is not the only way to achieve semantic interoperability. The data in a a claim is still the data no matter what representation is used to serialize it and what cryptographic algorithm is used to sign it. In my mind, the question is whether a machine can do the mapping of the data between the different representations. Per my comment above, if W3C VC 2.0 is JSON-LD only, then that mapping is achieved entirely using JSON-LD contexts. If W3C VC 2.0 supports multiple representations, then it needs to specify how each representation supports mapping of claims to another representation. |
@talltree I think that's what I meant by "lossless conversion". Sorry if I didn't make it clear. Of course signatures and proofs only work on the original representation, but the question is whether or not it should be possible to map the actual claim data and semantics between representations. |
Yes, and in hindsight, that was a huge mistake. To this day, we only have two JSON-based representations that only differ in the use of
Defining multiple representations (as it pertains to supporting ISO mDL/mDOC, ToIP ACDC, AnonCreds, ICAO DTC, and potentially others coming out of the EUDI work) is not listed as "in scope" for the Verifiable Credentials 2.0 Working Group Charter. Those things are not Verifiable Credentials -- they are different technologies, with different data models, and different representations/serializations. It is possible to logically express the information in each of those technologies using the VC Data Model, but that is not what those other technologies have chosen to do. All we can do is provide an example of how those other data models can be represented using the VC Data Model in a "logically equivalent" way. Calling those other things "W3C Verifiable Credentials" will only confuse the market... even calling them "verifiable credentials" is problematic and misleading, given the name and status of the W3C Verifiable Credentials specification. |
|
Neither is keeping only the exiting data model and there is no out of scope for multiple.
Get Outlook for Android<https://aka.ms/AAb9ysg>
…________________________________
From: Manu Sporny ***@***.***>
Sent: Thursday, October 20, 2022 10:12:13 PM
To: w3c/vc-data-model ***@***.***>
Cc: Subscribed ***@***.***>
Subject: Re: [w3c/vc-data-model] Make the usage of ***@***.***` optional (Issue #947)
the VC WG needs to tackle the issue of multiple representations of the VC Data Model.
Defining multiple representations of the VC Data Model is not listed as "in scope" for the Verifiable Credentials 2.0 Working Group Charter<https://www.w3.org/2022/06/verifiable-credentials-wg-charter.html>.
—
Reply to this email directly, view it on GitHub<#947 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AB4R4Y4POQXQ6UK5XTT45TLWEGRR3ANCNFSM6AAAAAARCQJW3A>.
You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
+1 Seriously opposed to making context optional. There are other paths here that can preserve the semantics on a VC / VP while allowing for easier developer onboarding etc. Notably 953 would simplify the developer side, while ensuring that we keep semantics at the core data model level |
|
@mprorock I certainly understand your perspective — and that of many other members of the WG — that JSON-LD (and its underlying RDF graph model) is a fundamental component of the W3C VC standard and should not be compromised in any way. I also understand the perspective of other members of the WG who feel that the W3C VC standard should support a plain JSON representation that does not use either JSON-LD or the RDF graph model because they wish to use other solutions to semantic interoperability such as JSON Schema. So it strikes me that the WG is coming to a Great Divide. It can go down one path or the other. But not both. The sooner the WG makes a decision, the sooner these questions can finally be laid to rest. |
@dlongley It might be helpful if you could elaborate on the issue with interop. More than one way of doing what? Given that Does it, for example, identify the thing you are parsing as a verifiable claim, in cases where the parser didnt know that before? Could it be instead got from the Does it give the version of the VC being used (2018) to help the parser canonicalize it and verify it. Possibly yes. However there's only one version (ie URI) right now in the spec, so I dont see parsers getting confused. 1-2 sentences on what specifically the barriers to interop would be, might help give a background to those following. There might be a compromise along the lines of |
|
@talltree "because they wish to use other solutions to semantic interoperability such as JSON Schema." I do not see using JSON schema, whilst keeping a nominal |
I have to say, if I look at the example in #947 (comment), to me this looks like a good old JWT, not like a VC. This example doesn't have the It doesn't have a Yes that example has Perhaps It’s time to let VCs be VCs :) |
|
Most of this discussion about using Without |
With respect to interoperability, it actually doesn't matter "what". Generally speaking, having more than one way to do something harms interoperability, so a good argument needs to be made that any optionality is worth it. Sometimes it is -- sometimes it isn't. If
This is not accurate. You're mistaking the core context from the extensions, both of which use the It also establishes and demonstrates the extensibility model. Today, every VC must have at least two contexts, the first is the core context and the second provides the term definitions for the specific VC type.
No. This would not sufficiently provide term definitions -- and used in isolation would require types to be full URLs, disallowing idiomatic JSON typing. It would also fail to provide the other features mentioned above.
VCs require at least two contexts, the core context that defines the core terms, and a secondary context that defines the terms for the specific VC type. If |
This is not true today, and it should not be true tomorrow. You can't represent anything useful in v1.1. with only 1 context.... but that does not need to be true of 2.0. |
To clarify, if you want to use idiomatic JSON, this is a requirement today. It is true that you can instead use full URLs for your JSON keys and type values otherwise.
Yes, we can do all kinds of things in 2.0 (good or bad). |
|
I have moved (copied) my proposal above for resolving the |
|
The issue was discussed in a meeting on 2022-11-01
View the transcript1. Make the usage of
|
|
My 5 cents. As an implementer I have had my fair share of struggle with JSON-LD, Reading the transcript I truly dont see an issue of ignoring context if you want to do just JWT, as David Chadwik is saying, it doesn't cost their JWT implementation anything. Why does it cost all this clients that is mentioned so much hassle, or any of the other implementors so much hassle? I dont understand that. For open world to work, there has to be a map to use, that map is I want a map, and WHEN Im really good at reading the map, read understanding and tooling with JSON-LD, i really appreciated that the earlier me wanted to add this map, |
This comment was marked as resolved.
This comment was marked as resolved.
|
@TallTed thanks for this notice, changed now. |
|
Another DID Method registered with undefined terms, due to the did core v1 context not including a vocab: |
|
@OR13 Could you map that to VC work? I'm not seeing how someone filling in a Github template form inappropriately is addressed by anything in the VC specification. |
|
@jandrieu Sure. VCDM 1.1 and DID Core v1 both don't include an Every week I see a new DID Method registered with terms undefined because of this. The VCWG has agreed to add an The links I provide above are evidence that this decision was a wise one, and that the DID WG should make a similar decision under its next charter / operational period. In relation to the current issue we are threaded on, an Currently, if you were to inject a v1 context, you have no reason to believe it would define all terms... Which speaks to the un resolved problems associated with this current issue. |
Those terms will still be undefined. They'll just map to a URL that 404s or dereferences to an equally uninformative page instead of remaining a non-URL term. I do not see this as being much, if even any, improvement in the overall situation for these DID methods! |
|
Well, for VCs, a default / auto-generated vocab URL could actually resolve to a page that says something like "This term is issuer-dependent. See the specific issuer's documentation for a definition of this term." That's not good for scalability and can result in a sort of "NASCAR problem" situation within digital wallets where they only support the most popular issuers vs. the most popular commonly shared vocabularies (issuer-independent), but I digress. Now, doing the same for DIDs seems like it would be a little bit odd -- since I wouldn't expect the terms to be "DID-method-dependent" nor would I expect having them be "DID-controller-dependent" would be that helpful in terms of finding documentation. So it's perhaps not really comparable -- but we should focus on VCs over here anyway. |
|
RESOLVED: The base media type for the VCDM is credential+ld+json. |
This comment was marked as resolved.
This comment was marked as resolved.
|
The issue was discussed in a meeting on 2023-02-16 List of resolutions:
View the transcript3.
|
|
The issue was discussed in a meeting on 2023-02-16
View the transcript1.
|
|
It might be an idea to bottom post the resolution to this closed issue in 1-2 sentences, for those that have followed it for 200+ comments. If I'm right a new |
|
RESOLVED: The base media type for the VCDM is credential+ld+json. @context is required (MUST) in the base media type; other media types MAY choose to include @context. Serializations in other media types (defined by the VCWG) MUST be able to be transformed into the base media type. Another media type MUST identify if this transformation is one-directional or bi-directional. Bi-directional transformation MUST preserve @context. Transformation rules MUST be defined, but not necessarily by this WG. |
and others
It has been suggested that the use of
@contextshould be made optional. This would be a normative change to the current specification, as the use of@contextis required in both JSON and JSON-LD. This issue is to discuss if this is a good idea and the mechanism(s) that could be used to accomplish the task.The text was updated successfully, but these errors were encountered: