Make the usage of `@context` optional

[msporny]

It has been suggested that the use of @context should be made optional. This would be a normative change to the current specification, as the use of @context is 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.

[OR13]

Although I believe in the same semantic web vision, just forcing JSON-LD into the specification at all cost may lead to issues in adoptability.

Agreed, how JSON-LD is supported will cause adoptability issues for JSON-LD.

Details matter here a lot, there are other issues focusing on how we can improve things, without making context optional.

I don't think making things optional helps with interoperability.

In this case, making context optional will 100% destroy interoperability we are aiming at... which is semantic interoperability.

We already have good interoperability for securing JSON with JWS, JWE, JWP or SD-JWT.

[talltree]

Because the global infrastructure is made up of millions of wallets, issuers and verifiers. And an issuer cannot know if any wallet or verifier that will obtain the VC will be a JSON-only or a JSON-LD processor. By adding the two @contexts that are being proposed for JSON-only issuers, allows all of the wallets and verifiers to upload and process the VC without the issuer being aware of their JSON-LD capabilities. It avoids the great divide. (Because a JSON-LD issuer will obviously add the full set of @contexts that are needed for full and complete JSON-LD processing, which presumably JSON-only implementations can already process)

@David-Chadwick I'm afraid you've lost me completely. If an issuer intends to issue a JSON-LD-based credential, then of course the issuer would include the necessary @contextstatements. By why would an issuer who intends to issue a plain JSON credential (that does use JSON-LD) benefit in any way from adding @contextstatements? Isn't the opposite actually true: that verifiers would benefit from having a clear, completely unambiguous way of knowing whether a JSON credential does or does not use JSON-LD (by having or NOT having @contextstatements)?

[stenreijers]

Is this case, making context optional will 100% destroy interoperability we are aiming at... which is semantic interoperability.

Perhaps a hybrid solution as your suggestion in #953 makes sense. Instead of making @context optional, leave the choice to the implementator but at least give him a way out. This could indeed be done by something that makes a default vocabulary possible for develops to still produce a valid LD document for the libraries that actually process the VC using JSON-LD.

What more hybrid solutions exist to give developers a way out instead of just adding @vocab in @context without making @context optional?

[David-Chadwick]

@talltree The two @contexts we are talking about are a) the standard v2 context, and b) one for JSON-only issuers to add that effectively says "my undefined terms are in this VC". The JSON-only issuer needs to add a) since this is required for all the existing standard properties (issuanceData, type, id etc) to be used and b) is needed for all the new terms that the issuer is defining, such as "degree" or "credit-card" or "AAA membership" etc. to be used. In this way all verifiers can verify this issuer's VCs, regardless of whether they support JSON-LD or not. In other words, the issuer can now issue its VCs to the global community of verifiers and wallets rather than to a subset who only support JSON-only processing.

[David-Chadwick]

Footnote. There will be orders of magnitude more verifiers and wallets than issuers. The aim should be to reduce the burden of verifiers, not increase it. By issuing a VC that all verifiers can process reduces their burden

[TallTed]

@dhh1128 -- Please edit your https://github.com/w3c/vc-data-model/issues/947#issuecomment-1289177405 and put code fences around the unfenced @context instances in the second and fourth paragraphs. Single backticks should suffice, as `@context`.

[TallTed]

the eIDAS 2.0 guidelines from the European Commission that state that the privacy of the holder is a very important topic

Anyone who's both here and involved with the eIDAS 2.0 (and/or related) guidelines should please let them know that privacy of the holder (who/which just possesses the VC at some point in time) should be less their concern than privacy of the subject (about whom/which the statements in the VC are made).

[TallTed]

@stenreijers — Please edit your https://github.com/w3c/vc-data-model/issues/947#issuecomment-1289288005 and put code fences around the unfenced instances of @vocab and @context, as `@vocab` and `@context`. Single-backticks will suffice in this case. Neither single nor double quotation marks serve the purpose. Failing to wrap @entities in code fences means those GitHub users will get pinged for every update to the thread, in which they are otherwise not participating and probably have no interest.

[stenreijers]

the eIDAS 2.0 guidelines from the European Commission that state that the privacy of the holder is a very important topic

Anyone who's both here and involved with the eIDAS 2.0 (and/or related) guidelines should please let them know that privacy of the holder (who/which just possesses the VC at some point in time) should be less their concern than privacy of the subject (about whom/which the statements in the VC are made).

Indeed the privacy of the subject is important, but typically the value of these statements are revealed to the verifier in plain text. So this is not always the case where privacy matters the most. In fact, the privacy of the actual holder matters when a presentation is created and we should prevent that multiple presentations are linked to the same holder. Here, zero-knowledge proofs play an important role in shielding the identifier of a holder and hence ensuring the privacy of the holder itself.

[talltree]

@David-Chadwick Thank you, your explanation was very helpful. If I understand correctly, what you are describing is an approach that can be called "JSON-LD enveloping". If I have it right, this approach means an issuer would:

1. Start with a valid JSON-LD instance of a basic VC (so that JSON-LD validation could be run against the default JSON-LD context).
2. Add a second JSON-LD context statement that effectively says — to use your wording — "my undefined terms are in this VC".
3. Then add the rest of the non JSON-LD terms the issuer wants to use for which they do not intend JSON-LD processing.

So under this model, all verifiers would perform JSON-LD processing on a W3C VC, but they would know that if the W3C VC contains the second "undefined terms" context statement, then the VC contains terms on which the verifier cannot perform JSON-LD processing.

So if the verifier wants to perform validation on the non-JSON-LD terms, the verifier has to perform a different kind of validation appropriate for those terms.

If I have that right, then I need to ask: what benefit does the JSON-LD enveloping actually provide to verifiers? Here's the decision tree as I understand it:

1. If the verifier doesn't plan to do any validation processing — of the JSON-LD terms or the non-JSON-LD terms—then the JSON-LD enveloping doesn't add any value.
2. If the verifier plans to do validation processing, JSON-LD enveloping means the verifier must now do two different types of processing: a) JSON-LD processing of the JSON-LD terms, b) another type of processing for the non-JSON-LD terms.

In the latter case, wouldn't it be easier for the verifier to simply perform the non-JSON-LD processing on the entire JSON document and be done with it?

This question takes on even greater importance when you consider the Great Divide. I know @msporny has said the Great Divide is a false dichotomy because the VC WG can simply require JSON-LD enveloping and that can handle all the non-JSON-LD forms of credentials. But I know for a fact that there are major parties using (or planning to use) non-JSON-LD credential formats (e.g., ISO mDL/mDOC, ACDC, AnonCreds) who are never going to use JSON-LD enveloping (for reasons that may have nothing to do with JSON-LD's merits).

So the Great Divide is very real in the following way:

1. If the WG decides to require JSON-LD enveloping, the W3C VC standard will be the "small tent" that encompasses only JSON-LD-based credentials. Others who want to use non-JSON-LD credentials will need to pursue their own standards.
2. If the WG decides to support both JSON-LD and plain JSON credentials, then the W3C VC standard will be the "big tent" where the JSON-LD and non-JSON-LD folks can work out the "golden middle" that provides maximum interoperability.

The sooner we make a firm decision one way or the other, the better.

[decentralgabe]

I am heartened by this conversation, which, over the past few years seems the most pragmatic in settling the great divide.

I agree with @talltree's analysis, specifically..

If the verifier plans to do validation processing, JSON-LD enveloping means the verifier must now do two different types of processing: a) JSON-LD processing of the JSON-LD terms, b) another type of processing for the non-JSON-LD terms.

This is quite similar to what @selfissued mentioned (and I +1'd) stating that (heavily paraphrasing) there are already two data models: broken, non-compliant LD because we have to include a context property, and LD.

The two choices are as stated above:

1. Continue to require @context as a property even for those who will never use a JSON-LD processor and have no desire to use Data Integrity style proofs.
2. Stop requiring a meaningless property for the half of the ecosystem that chooses not to use it.

For (1) I see a sensible proposal from @David-Chadwick to include a field/context/property in the @context that pretty much says "I'm using this to show you a spec-gun is being held to my head" or to quote Marshawn Lynch: I'm just here so I won't get fined.

For (2) I have seen a call for concrete answers to how do we interoperate? which continues to be a valid question. To this, I've seen some suggestions...a W3C or IANA registry, using JSON Schemas, or the more apathetic who cares, I'll figure it out if I need to.

I tend to lean towards the mindset of (2) with a "let's have a registry or figure it out if we need to" attitude. The VCDM spec has, and will continue to, define normative properties and semantic logic (e.g. a credential ceases to be valid after its expirationDate has passed). The data model itself can be used to prove out interoperability to a reasonable degree. Further interoperability: supporting vc-jwt, a specific data integrity suite, or non-normative terms should be additional axes of interop which the group works out independent of a @context property.

I also don't think the world ends at JSON/JSON-LD. There will be other formats.

[talltree]

I also don't think the world ends at JSON/JSON-LD. There will be other formats.

+1. CBOR for sure, given that's already the "native" format for ISO mDL, and also favored by the EU.

[msporny]

@decentralgabe wrote:

I tend to lean towards the mindset of (2) with a "let's have a registry or figure it out if we need to" attitude.

"Figure it out if we need to" sounds like quite a reckless way to proceed. "Let's have a registry" does not provide any details on one of the key questions of how decentralized extensibility will be supported without the @context mechanism?

For example, how is such a centralized mechanism going to scale? Let's just pick a few JSON-LD Contexts... OpenBadges v3, Traceability Vocabulary, and schema.org... and let's put them in this "IANA Registry" that's been proposed. So thats, ~100 terms for OpenBadgesv3, ~150 terms for Traceability, and ~2,800 terms for schema.org. So, right off the bat, we have over 3,000 terms in this centralized IANA registry. That's with just THREE vocabularies. There are NINE HUNDRED THIRTY SIX top-level vocabularies on w3id.org, if we only assume that half of them are vocabularies, and they only have ~10 terms each... that's another ~9,360 properties in the IANA registry. So, what's the plan to deal with this level of complexity?

In order for the group to rally behind the "make @context optional" banner, there needs to be a plan. What is the plan to make @context optional? How are you going to support decentralized extensibility? How is a wallet or a verifier going to know what a VC means if there is no global way of identifying a property. What happens when the verifier doesn't have a direct connection to the IdP? These are all problems that @context solves. Please detail the alternative approach -- you can't hand-wave yourself past the problem that would be created by making @context optional.

Stop requiring a meaningless property for the half of the ecosystem that chooses not to use it.

Citation required. "half of the ecosystem" measured in what way? Where are you getting these numbers from?

@talltree wrote:

If the WG decides to support both JSON-LD and plain JSON credentials, then the W3C VC standard will be the "big tent" where the JSON-LD and non-JSON-LD folks can work out the "golden middle" that provides maximum interoperability.

How exactly is "maximum interoperability" going to be achieved? What does that solution look like? How are mDL/mDoc, ACDC, and AnonCreds going to become compatible given that they're completely different solutions today?

also favored by the EU.

Citation required. "The EU favors CBOR" -- please point to a study or something that backs up these claims. We do know that people generate bad data; we don't have to be convinced of that. That those people are going to create good data if we remove @context is what needs to be argued in favor of. We have yet to see that argument, with important details filled in, in this thread. We can keep lowering the bar until we get all the way back to JSON... but we shouldn't pretend that we don't lose anything by doing that. In fact, there are people in this thread that are claiming that what we lose is one of the big technical goals of the VCWG... it's the thing that differentiates it from "just use a plain 'ol JWT".

We need a concrete plan for making @context optional and supporting the use cases in the group, not vague talking points that ignore the details of a compelling plan.

[David-Chadwick]

@talltree said "So under this model, all verifiers would perform JSON-LD processing on a W3C VC" I don't think that is correct. Lets be clear about one thing. We are only talking about issuers who don't want to do JSON-LD processing on the VCs they issue. If all issuer's issue VCs with correct @contexts then neither wallets nor verifiers need to do any JSON-LD processing because the type, @context and credentialSchema properties provide all they need to know to ensure that the VC is correctly formatted and contains only those properties that it should. The type coupled with @context values provide the globally unique type for the VC. Then JSON schema processing provides all the syntax information that is needed for processing the remaining properties. Of course, such an implementation does not explicitly know the semantics of property X, but the processing code implicitly knows it as this is built into the logic of processing property X from credentials of this type, which is globally unique because of the correct @context. So now consider those few issuers (yes few compared to the orders of magnitude more verifiers and holders) who don't wish to globally define their terms and add the "my locally defined terms are in this VC" @context. (Note the subtle change of semantics here, which is actually more correct.) Now these issuers are inconveniencing all verifiers and holders who wish to process this VC (using either pure JSON or JSON-LD it does not matter), because now they have to use some out of band means to determine the semantics of property X, because X is no longer globally unique. As @msporny pointed out, an IANA register cannot cope with the scale of this problem. The only sensible solution is for this issuer to bite the bullet, decide on global uniqueness, and add the correct @context value to their VCs that defines their properties. What this issuer needs is some user friendly plug and play tools that, given a set of properties, A, B, C... and a URL that the issuer owns, will return a properly formatted @contextfile and reference for it to insert into the VCs that it issues. So I launch this challenge to the JSON-LD group. Please give JSON-only issuers a very simple tool to use to enable them to issue JSON-LD conformant VCs without them having to do any JSON-LD processing.

[stenreijers]

@msporny said:

For example, how is such a centralized mechanism going to scale? Let's just pick a few JSON-LD Contexts... OpenBadges v3, Traceability Vocabulary, and schema.org... and let's put them in this "IANA Registry" that's been proposed. So thats, ~100 terms for OpenBadgesv3, ~150 terms for Traceability, and ~2,800 terms for schema.org. So, right off the bat, we have over 3,000 terms in this centralized IANA registry. That's with just THREE vocabularies. There are NINE HUNDRED THIRTY SIX top-level vocabularies on w3id.org, if we only assume that half of them are vocabularies, and they only have ~10 terms each... that's another ~9,360 properties in the IANA registry. So, what's the plan to deal with this level of complexity?

This is an interesting point you are trying to make, indirectly you argue that JSON-LD will provide a scalable way of giving thousands if not ten thousands of properties a meaningful vocabulary such that properties like (for example) firstName or alumniOf automatically have a meaning. Although I agree that JSON-LD already provides a vocabulary for a lot of properties, we have to be very precise here how JSON-LD helps us create VCs of a certain quality level.

I guess its not enough to just force a new decentralised way of defining new semantics and let it loose on the implementors of a VC. We want to create ecosystems in which VCs have a certain long lasting quality. If we do not go the last mile to help developers in this endeavour, we might create an ecosystem that ends up with too much noise in loosely defined terms, context URIs that do not resolve after a certain time, bad quality in how properties of extensions are defined, hell even faulty JSON-LD contexts. All doing exactly the opposite of creating an "interoperable" ecosystem, just because we are forcing JSON-LD for nothing other than a decentralisation argument. I guess when we want @context not optional, we really do need to understand exactly HOW JSON-LD is going to help us to create an ecosystem of VC extensions that are peer-reviewed, have quality semantics, ensure that custom context URIs stay available for a long period of time, etc.

The VC IMP Guide gives a short explanation how to create a new credential type with the corresponding JSON-LD context. If we really want to force JSON-LD and not make @context optional, we should also go the next mile and really define templates for implementers in how to properly define a new credential of a certain quality, instead of just referring to https://schema.org in an example. Help to educate the community in doing it the right way..

Whenever we use a centralised approach of defining new semantics, we can be sure of a well defined definition, peer-review, the registry is always available, specifications can easily point to a central registry of definitions. This allowed us in the past to create very robust specifications because of these additional features, not by just a scalable way of defining them. If we not go to the last mile in a decentralised way of organising this, or at least try to reach a certain quality level, JSON-LD will do more harm than good.

[msporny]

@stenreijers

Help to educate the community in doing it the right way.

This is already happening, and has been happening for a while now:

https://imsglobal.github.io/openbadges-specification/ob_v3p0.html

https://w3c-ccg.github.io/traceability-vocab/

https://w3c-ccg.github.io/citizenship-vocab/

https://json-ld.org/spec/latest/json-ld-api-best-practices/

https://w3c.github.io/vc-imp-guide/

https://playground.chapi.io/

There are market verticals that are adopting VCs and providing guidance (see examples above). We can always do better, and I'm glad to hear you have an interest in improving this particular aspect of the ecosystem @stenreijers. I look forward to you raising PRs on https://w3c.github.io/vc-imp-guide/ with guidance that you feel will help improve guidance for VC authors and implementers.

[msporny]

@decentralgabe wrote:

I also don't think the world ends at JSON/JSON-LD. There will be other formats.

JSON-LD formatted Verifiable Credentials can already be losslessly round-tripped to CBOR and back (via auto-translation to/from CBOR-LD).

YAML-LD is currently being developed, which allows JSON-LD formatted VCs to be losslessly round-tripped to YAML and back.

As the VCWG, if we keep @context, we get translation to/from CBOR and YAML without having to lift a finger in the VCWG. We literally don't have to do anything more because the design of JSON-LD allows for auto-translation between CBOR and YAML, and any other *-LD compatible syntax, by design. Add to that the fact that we ALSO don't have to re-sign the data if we use Data Integrity and I hope people can start to see why removing @context destroys all of those features. If we remove @context, even by making it optional, we lose auto-translation and cross-syntax digital signing.

What is the plan to support those features with the "make @context optional" plan?

[stenreijers]

@msporny Agreed that some very nice to have features will disappear if we drop JSON-LD. But that in my opinion is all it is: some nice to haves that have nothing to do with the core problem that W3C VC is trying to solve for us.

For the sake of argument, lets just say that we hypothetically make @context optional in the VC specification. Let us just for a moment see how a new VC without JSON-LD could look like and what kind of new problems we would introduce by doing so...

If we drop @context, the least that we must do is the following:

• We must specify default uris for the type property for mission critical objects defined by the core specification, plain text like VerifiableCredential is not URI compliant anymore.
• We must specify how extensions for mission critical objects (or new objects) used in a VC can be typed using the type property.
• We must specify something about credentialSubject or at least force implementors to use some kind of predefined schema via credentialSchema.

A possible way to introduce new uris for the type property could for example be to force Uniform Resource Names (URNs) as types, see https://www.rfc-editor.org/rfc/rfc8141.html, when there is no @context. These types can be forced to be globally unique as long as we give a clear way how to implement them. This ensures that the probability of a collision in the type can be made arbitrary small and code implementations can still differentiate between different objects and make validations against URNs.

A possible way of doing that could be to introduce a URN with a vc namespace as follows: URN Syntax: urn:vc:<service>:<component>@<resource>:<version>

Allowed regex: /^urn:vc:(?<service>\*|[A-Za-z0-9/.-]+):(?<component>\*|[A-Za-z0-9/.-]+)@(?<resource>\*|[a-zA-Z0-9/.-]+):(?<version>\*|[a-zA-Z0-9/.-]+)$/;

For the sake of this argument, let us look at the following set of w3c URNs in the specification:

• urn:vc:w3c:types/vc@<resource>:<version>,
• urn:vc:w3c:types/vc/proof@<resource>:<version>,
• urn:vc:w3c:types/vc/credentialSchema@<resource>:<version>,
• urn:vc:w3c:types/vp@<resource>:<version>,
• urn:vc:w3c:types/vp/proof@<resource>:<version>,

Extensions can be created by allowing <resource> to be namespaced according to specific rules, see JSON example below that uses a simple directory structure.

An example JSON could look like:

{
  "id": "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6",
  "type": [
    "urn:vc:w3c:types/vc@core:v2",
    "urn:vc:w3c:types/vc@myCompany/myCredential:v1"
  ],
  "issuer": "urn:uuid:490a507a-2668-41cd-babd-bdf5f1b7bc72",
  "issuanceDate": "2010-01-01T19:23:24Z",
  "credentialSchema": {
    "id": "urn:uuid:390cec1e-0e3c-4088-93a5-b31f9e6f8e4c",
    "type": "urn:vc:w3c:types/vc/credentialSchema@myCompany/myCustomSchema:v1",
  },
  "credentialSubject": {
    "id": "urn:uuid:be980599-c670-4976-819f-40a0c54fc34c",
    "alumniOf": {
      "id": "urn:uuid:05317fb8-1464-4076-895b-16c4e82ce77f",
      "name": [{
        "value": "Example University",
        "lang": "en"
      }, {
        "value": "Exemple d'Université",
        "lang": "fr"
      }]
    }
  },  
  "proof": {
    "type": "urn:vc:w3c:types/vc/proof@core/exampleSignature:v1",
    "created": "2017-06-18T21:19:10Z",
    "jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2..."
  }
}

Let us avoid having a discussion on the example itself, there are infinite possibilities in creating semantics with just plain JSON. But at least this example shows how we can still create a perfectly fine VC ecosystem without the use of JSON-LD that is both machine readable and easy to extend with new types.

What downsides or upsides does such a new representation have?

[dhh1128]

Manu said:

In order for the group to rally behind the "make @context optional" banner, there needs to be a plan. What is the plan to make @context optional? How are you going to support decentralized extensibility? How is a wallet or a verifier going to know what a VC means if there is no global way of identifying a property.

If we remove @context, even by making it optional, we lose auto-translation and cross-syntax digital signing.

What happens when the verifier doesn't have a direct connection to the IdP? These are all problems that @context solves. Please detail the alternative approach -- you can't hand-wave yourself past the problem that would be created by making @context optional.

ACDCs provide all of the things that you are enumerating here, Manu. There is schema formality and decentralized extensibility without a registry using autonomic namespaces, which are way more elegant. There is a seamless transition between CBOR, JSON, and MsgPack -- with a single signature that is valid for all of them, meaning that anybody can render or transmit the credential in any of these formats (or, interestingly, in any mixture of these formats on an individual field basis) without help from the issuer. There is full data graph modeling and extremely efficient credential chaining -- including things that are awkward in LD, like decorating a particular edge with a degree of certainty, or like having two edges that are independent instances of the same predicate. You asked for citations. I believe they are well known to the CCG, but for those who are encountering my comments without the benefit of several years worth of conversation on the topic: the KERI whitepaper, the CESR draft IETF RFC, and the ACDC draft IETF RFC.

I'm not bringing all this up to convince the world to use ACDCs. Use whatever you want. The JOSE world has answers for much of this, too, as Orie has pointed out. My point is rather that this is not a debate about whether we want semantic power. It is a debate about whether the spec should require anybody who wants that semantic power to do it the LD way. It is NOT the case that the only answer to these issues is to use LD, and it is NOT the case that ceasing to require LD-isms equals giving up semantic features. What we would be giving up is the false notion that anybody who doesn't like LD hasn't thought about this deeply enough, or that a spec that wants interoperability must accept LD as an axiom because it is the only viable lingua franca.

It is also a debate about whether that semantic power is really the proper focus of the spec. I accepted that assertion in VC 1.0 days, but I've evolved to a feeling of skepticism. @David-Chadwick talks about a vast array of verifiers and issuers, and about them verifying arbitrary credentials that holders present to them. I LOVE that vision; it's what's kept me here for the last 6 years or so. But practically speaking, none of us have been able to build an ecosystem like that. AFAIK, most ecosystems have hundreds of verifiers, at most, and only a handful of schemas that all of the verifiers know about in advance.

And I think not coincidentally, that's exactly what your own advice has been about LD security with respect to @context. To make sure that hackers don't co-opt a credential ecosystem by hacking a server that hosts a @context URI, know and cache the schema in advance; never processes unfamiliar contexts dynamically. This feels to me like it seriously undermines the utopic extensibility we describe in other parts of our conversation; we can't really allow people to do that, if they're using the URI-oriented web way that LD advocates. Indy solved that problem by putting schemas on the ledger, and was pilloried for it. ACDCs solve it a totally different way that is both more decentralized and more secure. Is that going to be legitimized by a group that really wants a big tent -- or is it going to be ruled out because it makes vendors venture beyond their pure LD stacks to conform to a tent that is actually bigger than LD?

At this point I can imagine several possible answers to this question. I think my preferred answer looks like this:

Approach the relationship between JSON and -LD the same way that XML and XML namespaces relate. What I mean by this is not to slavishly parallel every aspect of the XML-namespace dynamic, but to achieve something similar to what is possible with XML today. You can learn XML and use it without namespaces, and in local contexts where everyone understands one another, it works fine. You can also* add namespaces to XML, and it gets a useful formality.

I would do this by writing 2 specs: one for the non-extensible data model (VC core), and one for extensibility (VC namespaces). And then I would personally ignore VC namespaces because I think there are better ways to achieve those goals. But I'd let the market decide.

I don't actually think this split spec would undermine interop in the way David predicted, because the important goal in front of us today is to interoperate around a handful of schemas in nascent ecosystems, NOT to implement the dynamic interop that a mature ecosystem might eventually want. If we can get traction on the more basic form of interop today, we'll all live to do fancier interop later. But if we don't make the tent big for the non-extensible fundamentals, we'll keep spinning our wheels.

I don't think the preceding two paragraphs qualify as a "plan" by Manu's definition, but I do think they could be turned into a plan if enough consensus existed to pursue them. Making a plan is only justified if that condition holds.

[OR13]

If ACDCs, JWP and SD-JWT get published as IETF RFCs, they can be used to protect arbitrary data.

If W3C WG wants to define a mapping for JWP, SD-JWT or ACDCs to the W3C JSON-LD Verifiable Credentials model, that is for the working group to decide.

I don't think the working group will proceed well, in defining mappings if we allow both sides of the mapping to "be whatever we want'... folks are proposing a lot of changes that will increase the cost for verifiers and issuers tremendously, while destroying interoperability.. its not a good idea :)

[dhh1128]

Let me propose one other possible approach that might make @OR13 and some others happier:

• Decide that VC 2.0 is LD only. Rename it "VC-LD". We have JSON-LD and CBOR-LD; what's wrong with "VC-LD," especially if we are committed to LD-isms?
• Retain the stance that VC-LD is a standard, and encourage people to adopt it for that reason. However, stop dissing other approaches. Let them succeed or fail based on their merits (including their own standards trajectories, if they have them), not based on whether they're part of the "VC-LD" standard, and not based on spurious claims that they lack features or interoperability strategies.

I could TOTALLY get behind this approach.

[OR13]

@dhh1128 If @context is required in 1.0 and 1.1 and they are not titled that way, I see no reason to change the name of the spec.

In fact, a large amount of the damage that has been done to the Verifiable Credentials has come from creating gray areas or muddy water regarding what a "spec compliant" verifiable credential is.

Changing the name of the spec at this point would further erode the clarity, which we should be aiming for, as would retroactively endorsing the non compliant data formats that contributed to the ambiguity in the first place.

I am speaking specifically on AnonCreds and Compressed JWT Smart Health Cards... both of which once claimed to be "Verifiable Credentials" neither of which shipped a conformant data model.

Smart Health Cards provided a "mapping to the core data model" as a work around.

This document describes how clinical information, modeled in FHIR, can be presented in a form based on W3C Verifiable Credentials (VC).

https://spec.smarthealth.cards/credential-modeling/

I'm not up to speed with respect to AnonCreds and the proposed standardization, but I see them as an alternative to JWP, SD-JWT and ACDCs... meaning that they secure arbitrary data, and can therefore be applied to the VC Data Model to create a "W3C Verifiable Credential secured with ____"....

That is the layering that makes the most sense to me, and that was discussed at TPAC.

In other words, W3C Verifiable Credentials are about a shared data model, not arbitrary data or cryptographic assertion / proof formats.

[stenreijers]

@OR13 wrote:

I am speaking specifically on AnonCreds and Compressed JWT Smart Health Cards... both of which once claimed to be "Verifiable Credentials" neither of which shipped a conformant data model.

(AnonCreds early versions are based up on Identity Mixer from IBM)

We are currently actively working on an Idemix Signature Suite in conformance with the W3C Verifiable Credential Data Integrity v1.0 specification. Such that Idemix proofs can be easily added as proof type in a VC that is conformant to the Verifiable Credentials Data Model v2.0. This new proof suite should allow for a simple one-to-one conversion between Idemix based anonymous credential systems and systems that want to use the VC data model as a way to represent the VC.

For the more technical people in this thread, this Idemix Signature Suite does not use any canonicalization algorithms from JSON-LD or any JSON-LD framing algorithms. Instead it relies on a specific credentialSchema format such that the individual attributes can be easily filtered out with a transformation algorithm and hence the verifiability between other implementations can be preserved.

We were under the assumption that the W3C VC Data Model is a big tent specification and we loved the concept that JSON-LD was optional, or at least that types may also be a generic uri... It would reduce the implementation costs at our clients that do not require the burden of also implementing JSON-LD processing. If JSON-LD is enforced, I am no longer sure that W3C will be seen as a big tent spec..

[OR13]

If JSON-LD is enforced, I am no longer sure that W3C will be seen as a big tent spec..

I'm not sure this is a fair characterization of how standards work.

In JOSE, you sign JSON. In COSE, you sign CBOR.

We don't accuse IETF of being a "little tent" for creating excellent interoperability between signing JSON or CBOR... by implementing standards that support securing JSON or CBOR.

If you want to secure arbitrary data that is JSON or CBOR... you should do that work at IETF, the JOSE WG is reformed...

If you want to implement AnonCreds as JWP, thats a very viable option.

If JWP is working well, we can create a mapping for JWP (over JSON) to W3C Verifiable Credentials (over JSON-LD).

We don't need to bring experimental cryptography to W3C for standardization, its not really the best place to get expert review on that kind of thing.

What W3C can provide really great review on is JSON-LD and semantic formats that are relevant to the web platform... because they were created here... and they are being standardized here.

If we want good feedback, we need to ask the right groups for review.

If we are talking about securing JSON or CBOR, we should really be asking IETF.

W3C isn't a good place to "endorse new experimental crypto"... the CFRG and IETF are better for that.

When it comes to securing JSON-LD there are 2 approaches which have been supported since 1.0.

They each have tradeoffs.

The JWT version protects a serialization of data (JSON).

The Data Integrity Proof version protects a canonical representation of the information (n-quads).

You might prefer one over the other...

The first can be implemented using IETF standards, and is very simple.

The second relies on work that is being standardized at W3C or has already been standardized at W3C.

There are other standards organizations that might be a better fit for cryptography / identity work... for example, OIDF, DIF, ISO, OASIS, etc....

Depending on what you are trying to do, you might find those communities would a better place to gather feedback, because experts are already there.

IIRC AnonCreds is being standardized outside of the W3C.... https://github.com/AnonCreds-WG.

If AnonCreds, JWP, SD-JWT get to the point where we (this VCWG) can build a mapping between their JSON protection capabilities and the JSON-LD data model of Verifiable Credentials, I would welcome the working group review such a proposal... there are process rules that have to be followed regarding such actions, we made explicit allowances for this during our chartering.

[msporny]

@stenreijers wrote:

For the more technical people in this thread, this Idemix Signature Suite does not use any canonicalization algorithms from JSON-LD or any JSON-LD framing algorithms. Instead it relies on a specific credentialSchema format such that the individual attributes can be easily filtered out with a transformation algorithm and hence the verifiability between other implementations can be preserved.

To be clear, Data Integrity does not require JSON-LD, JSON-LD Framing, or RDF Dataset Canonicalization. The cryptographic suite can use whatever transformation algorithm you want:

https://w3c.github.io/vc-data-integrity/#how-it-works

We were under the assumption that the W3C VC Data Model is a big tent specification and we loved the concept that JSON-LD was optional, or at least that types may also be a generic uri... It would reduce the implementation costs at our clients that do not require the burden of also implementing JSON-LD processing. If JSON-LD is enforced, I am no longer sure that W3C will be seen as a big tent spec..

As Orie mentioned above, your rationale isn't resonating because of the reasons he highlights above.

With regard to your proposal, you are suggesting that we move away from URLs that can be dereferenced to find useful, human-readable information and idiomatic JSON to a new format that does not use URLs at all and would look quite strange to JSON developers. This, while not explaining how we achieve the encodings in other syntaxes, the cross-syntax digital signatures, how registries would work, what the underlying data model is, how data is merged, or any of the other important details. At least, ACDC attempts to address those concerns (more thoughts on that when I have time).

Thank you for proposing a rough plan, but we've discussed approaches like that before (around 2010-2012, when we were originally working on JSON-LD). URN-based solutions and URN microsyntaxes were rejected as a workable base for any data model that had to become a global information model. The approach you highlighted is one of the reasons OIDs failed to scale.

[dmitrizagidulin]

As an implementer of both the JSON-LD and JWT VC serializations, and as someone who worked hard to convince the group in the VC 1.0 WG to make @context required, I'd like to weigh in here.

By now it's hopefully clear to the casual reader of this issue (and related issues https://github.com/w3c/vc-data-model/issues/948 and https://github.com/w3c/vc-data-model/issues/953), if the awe-some task of following a 100+ comment threads of vehement argument can be casual, that even the most pro JSON-LD members of the group (such as Orie and Manu) have agreed on at least one thing:

As a group, we absolutely cannot REQUIRE VC developers to create new @contexts.

The tooling, documentation, and developer resolve, are just not there to make this painless or practical.

Ok! Hey! At least there's consensus on that much. Now what? Well, the pro-LD side, pointing to the many and varied benefits of using JSON-LD (globally unique properties, extensibility without registries, awesome levels of compression using CBOR-LD, etc), proposed (as hashed out in issue https://github.com/w3c/vc-data-model/issues/953):

We should require @context, but only make the top-level VC 2.0 context required, plus a @vocab mechanism, which turns any non-LD JSON to JSON-LD.

Meaning, if you don't want to deal with JSON-LD, and you don't want to create @contexts, either hosted or inline, you can just add a one- or two-item array to your JSON, and go about your business.

To which (quite reasonably, I think), the anti-LD side points out -- if that field is always required, and if it's going to most often contain the same value anyway, why have it at all? Why waste the precious electrons and bytes of disk space, by requiring a field that by default, has a long but fixed value.

And as a huge fan of JSON-LD, I can't think of any argument agains that. Specifically, what if this group's proposal (and the outcome of this issue 947), was:

PROPOSAL: Make @context optional. If a VC has no @context, processors who wish to perform JSON-LD processing, should simply apply the default @contexts (the base VC one, plus a @vocab).

This proposal is essentially a logical extension of both pro- and anti-LD lines of arguments. If the pro-LD side has agreed that requiring devs to create contexts, inline or remote, is not feasible, and is proposing a required base context.. why not make it a default context? That is absolutely functionally equivalent to having a required context, just saves space.

Edit: (For those who are reading through the thread and are just encountering this comment -- after reading the arguments later in the thread for why those two things are NOT equivalent (a required context and a default context), I've changed my mind (as outlined in my later comment), and would no longer like to make the proposal.)

[dlongley]

To which (quite reasonably, I think), the anti-LD side points out -- if that field is always required, and if it's going to most often contain the same value anyway, why have it at all? Why waste the precious electrons and bytes of disk space, by requiring a field that by default, has a long but fixed value.

Is the argument being made really "our precious electrons" (I did not think this was the case)? If so, I (and I expect many others) would consider that to be very far down on the priority list. In the case where payload size really matters, using CBOR-LD would make this a few bytes. Also, you would get far better compression if you defined your terms, since you'd get semantic compression. IOW, I don't think that's a good argument.

[dmitrizagidulin]

@dlongley the 'our precious electrons' is just a side effect. The argument is really that the two proposals ("lets require this base context" and "if a VC has no context, assume the base context if you want to do JSON-LD processing") are functionally equivalent.

[dlongley]

@dmitrizagidulin,

Why not make {"type": "VerifiableCredential"} also optional and assume it when it isn't present? Adding special processing code to guess what the context or meaning of some JSON data isn't better, it's worse. It is not a serious burden to include these things in the data.

I worry this is confusing what the real burden concerns are. My understanding is that people do not want to have to include a JSON-LD library to transform their data in their applications; they just want to be able to code their applications against JSON fields. Some people seem to think this isn't possible when @context is present in a VC that has been verified, but that doesn't seem to actually be true.

I am also concerned that some people perhaps continue to implicitly conflate JSON with a data model -- JSON is just a format. The data model (a graph comprised of subject-property-object triples) needs to be followed to make a valid VC. Using "just JSON" doesn't change that requirement. The only real difference between meeting this requirement using "just JSON" vs. JSON-LD is that JSON-LD requires mappings for the JSON keys and types to URLs. A @context that uses @vocab can provide this automatically for people who don't want to create their own contexts -- and then everything all fits together.

[dmitrizagidulin]

@dlongley

Why not make {"type": "VerifiableCredential"} also optional and assume it when it isn't present?

Because nobody is complaining or arguing against the "VerifiableCredential" type. And so it remains a decent indication that this JSON object is a VC. (And before you say "That's content-sniffing!", so is looking at a @context. That's also content-sniffing.)

I worry this is confusing what the real burden concerns are. My understanding is that people do not want to have to include a JSON-LD library to transform their data in their applications

That's one of the concerns. The other concern is quite literally, "we don't want to have to include a @context property".

I am also concerned that some people perhaps continue to implicitly conflate JSON with a data model -- JSON is just a format.

Always a valid concern! However, requiring a @context property is NOT going to fix this, it's not going to have people not conflate JSON with a data model.

A @context that uses @vocab can provide this automatically for people who don't want to create their own contexts -- and then everything all fits together.

My proposal (of assuming a default context & vocab) does this as well!

[dlongley]

@dmitrizagidulin,

My proposal (of assuming a default context & vocab) does this as well!

No, actually, now people have to "be in the know" and write specific VC processing code to consume VC data. Even if I don't even read the VC spec today, I can absorb JSON-LD VC documents into a knowledge graph.

Think of it like this: We have a spectrum of JSON-LD data consumers. At one end, we have people who want to absorb any JSON-LD documents and build a knowledge graph. This includes VCs and other types of JSON-LD documents -- they don't care. At the other end, we have people who only want to accept extremely strict "JSON only", specific VCs. These are very different use cases, but note that the closer you get to "JSON only" the more strict and specific you can be (and the more "out-of-band" knowledge, e.g. from human-readable only specs, you have to work with).

Now, if everyone includes @context, everyone can use the data. If @context is not present, we start cutting away people on part of the spectrum that are not going to write special case code for VCs.

[dmitrizagidulin]

@dlongley - yes, it puts a very small additional burden on JSON-LD processors. I feel that this is an acceptable trade-off (because the other option is to essentially lose the "we hate @contexts" crowd).

I would further posit that the population of processors who want to do JUST json-ld processing, without any VC-specific processing (such as verifying signature, validating expiration, etc) is zero. There are no such processors. Given that everybody does additional special processing for VCs anyway, the step of injecting a context is negligible.

[stenreijers]

@OR13 wrote:

I'm not sure this is a fair characterization of how standards work.

big tent was a poor choice of words and I meant absolutely no disrespect to any other initiatives working on verifiable credentials. The contrary is true, I am aware of all the good work that is done to create a flourishing credential ecosystem on the web. I was referring to the fact that this specification aims to provide a standard way to express credentials on the Web in a way that is cryptographically secure, privacy respecting, and machine-verifiable: a universal credential standard.

If AnonCreds, JWP, SD-JWT get to the point where we (this VCWG) can build a mapping between their JSON protection capabilities and the JSON-LD data model of Verifiable Credentials, I would welcome the working group review such a proposal...

This is exactly what we as a small startup company are trying to do. In our country, we are dealing with different credential ecosystems each with its own custom proof formats, custom vc representation data formats, so we started to map those one-to-one to this W3C VCDM. To make this work, we also have to write signature suites such that they can also be verified in the new W3C format. Thanks for pointing out the AnonCred WG and other initiatives, but we are not looking for information regarding specific cryptographic specifications, we really are focussing on mapping specific credential formats to this W3C VCDM format while preserving the cryptographic verifiability across different formats.

The easiest way for us to do this is by just defining the credentialSchema and a corresponding signature suite that allows it to verify. By introducing additional JSON-LD contexts, we just create an additional burden to our customers because they would need to do additional processing on their side to verify if the credential is valid. We do not want to use the @context if it has no meaning, since we are already giving clear semantics to all our properties in the credential object by clear specifications or using the credentialSchema property. A strict JSON-LD policy would force us to do additional processing and adds additional complexity at our customer side and would make our customer libraries more complex. This is the primary reason why I am joining this discussion.

@msporny wrote:

With regard to your proposal, you are suggesting that we move away from URLs that can be dereferenced to find useful, human-readable information and idiomatic JSON to a new format that does not use URLs at all and would look quite strange to JSON developers.

URN-based solutions and URN microsyntaxes were rejected as a workable base for any data model that had to become a global information model.

I don't think its a very objective statement that it would be strange for JSON developers to not find URLs in their JSON. Dereferencing is not required when the implementation library already knows how to interpret and validate the properties in a correct way. This is how the internet worked for decades, but your larger argument of the vision where we have a fully decentralized way of defining semantics is a vision I share too. However it cannot be at the cost of creating a lot of additional complexity, in my opinion, is most likely not worth the effort if the core problem that the specification is trying to solve is just: to provide a standard way to express credentials on the Web in a way that is cryptographically secure, privacy respecting, and machine-verifiable. I also recognize some of the awesome powers that JSON-LD is bringing to the table, but again keeping things simple may go a long way for global adoptability.

[talltree]

@dmitrizagidulin Thank you for a very constructive proposal. If it can bridge the Great Divide, I am all for it.

I have participated in this (very lengthy) thread in large part because I personally (and Avast commercially) participate heavily in both JSON-LD and non-JSON-LD communities-of-practice.

Avast lives — and codes — on both sides of the Divide.

Since everyone seems to agree — no matter what the W3C VC WG does in VC 2.0 — that we are going to be living in a world not just of multiple credential representation formats but of multiple semantic interoperability models, the question I keep coming back to is: Which of the following two paths does the W3C VC WG want to go down with the VC 2.0 spec:

1. Support only a single semantic interoperability model (JSON-LD using RDF graphs), or
2. Support multiple semantic interoperability models, which in addition to JSON-LD may include:
   1. Centralized schemas (e.g., published in a spec, such as ISO mDL)
   2. Claim/schema registries (centralized, federated, decentralized)
   3. ACDC-style distributed schema discovery
   4. Other mechanisms not-yet-at-the-table

I don't think anyone on this thread is pushing back on the many semantic interoperability benefits of the JSON-LD model.

What those of us wish to also support other semantic interoperability models are asking is the ability to use plain JSON without any JSON-LD.

Your proposal gives us a clean way to do that and would, IMHO, bridge the Great Divide.

[dlongley]

@dmitrizagidulin,

yes, it puts a very small additional burden on JSON-LD processors. I feel that this is an acceptable trade-off (because the other option is to essentially lose the "we hate @contexts" crowd).

No, there's still a misunderstanding here. We can't possibly expect people who write code to consume vanilla JSON-LD documents to read every spec looking for special rules that say which "default contexts" to add for certain types of data. They won't know about these specs, let alone know when to apply the rules. These aren't "VC-only consumers". The @context field says what type of JSON-LD document you're looking at -- and that's all these other tools will know about. So if you don't include it, you're cutting those use cases out.

[dmitrizagidulin]

@dlongley

We can't possibly expect people who write code to consume vanilla JSON-LD documents to read every spec looking for special rules that say which "default contexts" to add for certain types of data.

I'd say that we do understand each other. It's just that I'm claiming the opposite -- yes, we can expect vanilla JSON-LD processors to add specific handling for VCs. That's the proposal. That's the ask. And the reason for the ask is -- I don't think those groups (non-VC-processing JSON-LD processors) exist yet. Whereas the community of people who hate adding a @context to VCs does exist, it's very real, and it's pretty sizeable.

[stenreijers]

@dmitrizagidulin wrote:

PROPOSAL: Make @context optional. If a VC has no @context, processors who wish to perform JSON-LD processing, should simply apply the default @contexts (the base VC one, plus a @vocab). This proposal is essentially a logical extension of both pro- and anti-LD lines of arguments. If the pro-LD side has agreed that requiring devs to create contexts, inline or remote, is not feasible, and is proposing a required base context..

This looks like a very good compromise and a good way to make a solid bridge between communities that want to use JSON-LD and those who do not want to use JSON-LD. This would also be in line with what the specification aims to be: a standard way to express credentials on the Web. It seems more than fitting, in my opinion, that the specification should stay agnostic on different semantic interoperability models.

We can express Great Divide perhaps also in terms of a conservative developer community and a more progressive developer community. Not setting @context optional, would effectively mean that we are forcing the hand of the more conservative developer community.

[dlongley]

@dmitrizagidulin,

I would further posit that the population of processors who want to do JUST json-ld processing, without any VC-specific processing (such as verifying signature, validating expiration, etc) is zero. There are no such processors.

I reject this. Eliminating the possibility for people to publish VCs to websites alongside the other JSON-LD that is already published today -- and have it crawled and consumed as linked data... just because people don't want to include an opaque field (to them) in their VCs is a mistake. There are any number of use cases from battling "fake news", to public business credentialing (e.g., find a business), professional credentials (e.g., find a doctor), to product and service offers, to supply chain provenance (e.g. choose an ethical company) -- the list goes on, to enable intermediaries, such as search engines, to consume and expose trusted data to people. This is one reason this work is being done at W3C -- to benefit the Web. This is not just about personal credentials that will only ever pass through VC-only processors that are "in the know".

This may be easy for some to forget because these use cases aren't their own -- but they exist. We harm these use cases by not requiring @context because it creates interoperability problems and introduces complexity as the power of VCs becomes more realized over time.

[dlongley]

We can define "big tent" / "small tent" based on data or cryptographic format -- or based on whether we interoperably solve more people's higher level use cases using the same technology. I vote for the latter.

Keep requiring @context. Let's just make sure you don't have to do any fancy processing in your applications (you don't need a JSON-LD library unless you're checking a Data Integrity Proof that requires it), i.e., so that @context appears as just another required JSON array / string field. This is more than good enough so that we can have the big tent of use cases I described; it is not a higher burden than checking that "VerifiableCredential" appears as the first value in the "type" field that people do today and that no one is concerned about as @dmitrizagidulin noted.

[dlongley]

VCs provide a data model (graphs of subject-property-object triples) and a decentralized semantic disambiguity mechanism called @context.

If you're not using @context and you're not modeling your data as a graph, then you're not using VCs. That's ok. But we don't need to loosen VCs so much that whatever you are doing is now also a VC. That's not what standards are for; that doesn't help interop.

If you're doing "just JSON", I suspect you're not using @context and you're not modeling your data as a graph. That's ok. If you just want to use the core fields from the VC spec like issuer and credentialSubject, there's good news -- those already map directly to JWT fields. So, VCs probably aren't for you. Use JWT. If this isn't you, let's talk about how we can make @context easier for you, so it's just like the other fields you're already ok with checking like type. We can discuss what you actually need (or don't need) in your application. Please go to #953 to discuss over there.

If you have some new crypto technology that doesn't have a mapping that works with the W3C Verifiable Credential Data Model, please make one, that's great.

If you don't want to create a mapping but you like the name "Verifiable Credentials" for marketing your own technology, that's not really relevant here. Definitely don't put a "W3C" before "Verifiable Credentials" in your marketing materials.

[dmitrizagidulin]

@dlongley

We can discuss what you actually need (or don't need) in your application

I mean, what I want is a WYSIWYG data model builder, that compiles to both @context and JSON-Schema, with a pushbutton "save this newly created context to the cloud", like that one company demo'd during a previous IIW. (I should go dig that up again.) And to standardize the usage of hashlinks with contexts. (To lock 'em down properly).

I think I see what you're saying, regarding the argument being for the use of VCs as a marketing term.

[dlongley]

@dmitrizagidulin,

I mean, what I want is a WYSIWYG data model builder, that compiles to both @context and JSON-Schema, with a pushbutton "save this newly created context to the cloud", like that one company demo'd during a previous IIW. (I should go dig that up again.) And to standardize the usage of hashlinks with contexts. (To lock 'em down properly).

I agree with this! :)

[stenreijers]

@dlongley wrote:

If you're not using @context and you're not modeling your data as a graph, then you're not using VCs.

This is quite a bold statement, because this effectively directs the more conservative developers that do not want to use JSON-LD or graph based modelling to use other standards that are not nearly as far as W3C VCDM. They are just looking for a universal credential standard that they can use to put their own credentials in without too much hassle, something W3C VCDM could probably do for them. I am not against such a statement from W3C VCDM, at least when this has been cleared up we know that we should be looking for something else. But the spec should be explicit about it.

there's good news -- those already map directly to JWT fields. So, VCs probably aren't for you.

In my opinion this is just way too easy to say, credentials are far more complex than just a JWT with some additional properties. The W3C specifications, such as the data integrity spec, give clear directions on how to write new proof suites for verification and signing of credentials. This allows us to easily write new signature suites along the credentials and fulfil a clear market need at the moment.

@dmitrizagidulin wrote:

I mean, what I want is a WYSIWYG data model builder, that compiles to both @context and JSON-Schema, with a pushbutton "save this newly created context to the cloud", like that one company demo'd during a previous IIW. (I should go dig that up again.)

Sure, I would also be all in for this, but as mentioned before the tooling is just not there yet unfortunately.

@talltree wrote:

multiple semantic interoperability models

I think this sums the discussion right up. Make the spec really specific about how it wants to deal with multiple semantic interoperability models. Or if not, make it very explicit that it does not want to deal with multiple models but only wants to use JSON-LD.

Option A: only use JSON-LD, at least everybody is now on the same page that @context cannot be optional, because its the only way how people can define their semantics along with some JSON schemas perhaps. But its mandatory.

Option B: allow multiple models: this would mean that @context is now optional and opens the specification to a broader community.

[jandrieu]

@stenreijers wrote:

@dlongley wrote:

If you're not using @context and you're not modeling your data as a graph, then you're not using VCs.

This is quite a bold statement, because this effectively directs the more conservative developers that do not want to use JSON-LD or graph based modelling to use other standards that are not nearly as far as W3C VCDM. They are just looking for a universal credential standard that they can use to put their own credentials in without too much hassle, something W3C VCDM could probably do for them. I am not against such a statement from W3C VCDM, at least when this has been cleared up we know that we should be looking for something else. But the spec should be explicit about it.

That statement is a fact. Today's specification requires @context. If you are not including it, you are not using VCs, which is a published W3C recommendation with specific requirements.

This shouldn't be controversial.

What many are saying is that they don't like @context and that we should remove it from the spec.

That's a legitimate proposal. However, it would change the specification in a breaking way.

So, yes, until that change is adopted, breaking backward compatibility with the current specification, then "if you're not using @context and you're not modeling your data as a graph, then you're not using VCs."

What I'm still looking for is a proposal for a decentralized disambiguation approach other than JSON-LD. Because that's the extensibility model for VCs. Removing it would require an alternative.

We've seen proposals for centralized disambiguation through IANA. As well-meant as those suggestions are, they would violate the fundamental premise of VCs. It is imperative that anyone be able to say anything about any entity. A centralized disambiguation mechanism would preclude that.

Until we have a viable alternative to JSON-LD contexts for extensibility, removing @context is not a reasonable adjustment to the specification.

[dmitrizagidulin]

@stenreijers

this effectively directs the more conservative developers that do not want to use JSON-LD or graph based modelling to use other standards that are not nearly as far as W3C VCDM

So let's clarify -- what is actually the VCDM? It's a handful of reserved properties, plus an extensibility model (JSON-LD). What properties are reserved? Well, we have the issuer/subject/timestamps properties (that map to the reserved JWT properties). And besides those, the VCDM only talks about a couple fields -- credentialSchema, credentialStatus for revocation, and evidence. That's it.

So, I think this is what @OR13 and @dlongley mean when they say -- if you're not going to use the VCDM extensibility mechanism, what else are you using from the spec? The standard JWT fields? You don't need VCDM for that. The other three fields (schema, status, evidence)? That's.. not that much, to be fighting for.

Hence, what would the more conservative developers (who do not want to use JSON-LD) be losing, if they walk away from the VCDM? Just the 'Verifiable Credentials' marketing term.

[stenreijers]

if you're not going to use the VCDM extensibility mechanism, what else are you using from the spec?

The way we are looking at the spec is not just a handful of reserved properties, but it provides clear directives how to use a corresponding data integrity suite along side it. A proof suite combined with the credential and its attributes is all that gives it a value to start with, since it allows to proof the authenticity and integrity of the attributes that rest in the credentialSubject field.

All I am saying is there are more ways to provide extensibility. And the reason that we ended up in this discussion in the first place is that there exist a Section 6.1 (JSON) that describes the pure JSON representation without making any requirements to use @context, see https://github.com/w3c/vc-data-model/issues/929#issuecomment-1267697526

[dmitrizagidulin]

@stenreijers

the spec is not just a handful of reserved properties, but it provides clear directives how to specify a corresponding data integrity suite along side it

That's a separate spec, though. (Two separate specs -- the Data Integrity spec, and the JWS spec.) Nothing to do with VCDM.

[dmitrizagidulin]

@stenreijers

there exist a Section 6.1 (JSON) that describes the pure JSON representation without making any requirements to use @context.

I think you misunderstand. The VC 1.1 spec requires @context property for all serializations, even the JSON one from section 6.1.

[stenreijers]

@dmitrizagidulin wrote:

That's a separate spec, though. (Two separate specs -- the Data Integrity spec, and the JWS spec.) Nothing to do with VCDM.

The VCDM explicitly states a proof property that is to be used and is exactly what makes a VC verifiable. I understand there is a different specification on writing a new data integrity suite, called the Data Integrity spec. It is the combination of having a specification that allows one to write a new signature suite and a specification that allows one to define a universal credential that makes it the golden ticket to the chocolate factory.

I updated my previous comment, where I have replaced the word specify with the word use in the corresponding sentence.

I think you misunderstand. The VC 1.1 spec requires @context property for all serializations, even the JSON one from section 6.1.

Perhaps I misunderstood this section.

[decentralgabe]

We've seen proposals for centralized disambiguation through IANA. As well-meant as those suggestions are, they would violate the fundamental premise of VCs. It is imperative that anyone be able to say anything about any entity. A centralized disambiguation mechanism would preclude that.

Until we have a viable alternative to JSON-LD contexts for extensibility, removing @context is not a reasonable adjustment to the specification.

The most decentralized method also harms interoperability, because it is the recommend nothing approach. This results in multiple registries. Private registries. Or, a mix of private and public agreements on what certain properties mean in certain context. Maybe there are 20 other ideas that neither I nor anyone else in this group have thought about yet. This, is by definition, decentralization.

@msporny responded to my last comment and said...

"Figure it out if we need to" sounds like quite a reckless way to proceed. "Let's have a registry" does not provide any details on one of the key questions of how decentralized extensibility will be supported without the @context mechanism?

I am claiming that "decentralized extensibility" does not need to be solved, nor is it reckless. I imagine multiple solutions -- both centralized and not -- working out, and I don't think we should prescribe how it shall be accomplished.