Add @vocab for private claims in /credentials/v2 @context
#953
Comments
|
Related issues:
In my opinion, accepting this proposal will obviate the need to adopt a number of more complicated and less elegant proposals that have been floated to the working group in the issues above, at TPAC, and on various other industry specific calls such as ones addressing Education, Finance or Supply Chain Specific verticals. |
|
Orie's reasoning makes sense to me. |
|
👍 from me, I agree with this reasoning. |
|
Very big fan of this! |
|
As a person still learning JSON-LD and have had its fights with it, all I can contribute with are questions. What is the drawback of doing this? I dont know, but I would love to hear this side as well to populate this issue with further opinions |
|
Big +1 from me. |
|
Strong support for this, for the reasons highlighted by @OR13 |
|
One question to Orie. Say Issuer 1 in the UK creates a credential of the type you suggest, but uses a specific property of "value":"20" instead of "claimName":"claimValue". Then you in the US produce a similar credential with "value":"20", and someone in Japan does a similar thing. A verifier is likely to think that all of these VC are the same, whereas in fact each issuer, oblivious of the other ones, intended the value to be denominated in their national currency. Comments? |
|
You might consider setting the default vocabulary to be document relative. Using the Document Base for the Default Vocabulary. This has the advantage of not having two documents use equivalent term forms and have them be semantically confused with each other. |
|
This seems to lower the barrier to 'compliant' LD, which I'm all in favor of! My ignorance makes me wonder how is this any different than what is possible today? Couldn't the existing |
For the reasons stated over here: #948 (comment) There's a better solution -- which is to create another standard context anyone can use that includes |
|
See also this comment with more concrete proposals for how it would look. |
|
Maybe we should consider a slight variation of this where we use Outside of those, especially at the top level of the VC document, I'm not so sure if it's a good idea to allow undefined/ambiguous terms. |
|
Thanks again to @vongohren for putting forth questions to tease out the ergonomics of proposed solutions.
This is a meta-question that I think deserves a separate tracking issue. Whatever functional solution is decided on by the group, the WG would do well to explain it thoroughly in non-normative text and implementation guidance, I would think! A good solution insufficiently documented might be a smaller (but still dangerous) footgun for interop.
One reason I like the "second developer context" approach (soon to be renamed***) is that anyone who sees it knows they're in the
Am I understanding correctly that the separate "developer context" (soon to be renamed***) would allow consuming parties to filter by *** = here are some funner names:
|
|
I also think Markus' suggestion of scoping laxity just to credentialSubject is an interesting one, although I wonder how many people are using undefined props outside of Can anyone with LD experience speak to Gregg's suggestion (which might have gotten lost in the mix) of using Base to change how these credentials get graphed by LD parsers? I wasn't sure if Gregg was proposing it as a solution for the second context, or if the idea was to explain this option in non-normative text as a 3rd way of lowering the threshold for achieving valid LD. |
|
I support that we have to find a solution to giving some flexibility. But I also support the reasoning happening over here: #948. +1 to Markus suggestion of limiting it to credential subject, unless you want to have a VC development sanbox to test out new ideas that are being created. Such as holderBinding or rendering or whatever was cooked together during RWoT 11 f.ex. |
|
@bumblefudge "although I wonder how many people are using undefined props outside of credSubj in the wild?" |
In my view, what we're trying to do here is give people an easy onramp to VCs where they don't have to absorb or understand everything all at once. So I think if we're going to give people (some who are struggling to create their own contexts) a common way to use
I think it's an even more complex ask of the people we're trying to help. In order for it to work, different In short, I think the people we're trying to help by lowering the learning curve would be introduced to too many new concepts. It's much easier to keep the concepts simple:
Then we can say: "If you don't want to, aren't able to, or aren't ready to provide your own context, use this one: "URL X". It will indicate that your terms aren't globally defined and let you ease into defining them if and when you're ready." In other words, the guidance for authoring a new VC type would be:
|
|
@OR13 wrote:
-1 (a very strong one), because it disables all undefined term error reporting for everyone in production, whether they want it disabled or not. It doesn't give a choice to implementers that want these sorts of errors to be caught by common tooling. There are implementers, such as ourselves, that want the common tooling to report errors, so that we can provide a better experience for our production customers. @vongohren wrote:
Let's review where it seems like we all agree:
Based on that, I think that @bumblefudge's proposals seem to have the best chances of achieving consensus. That is, this: really doesn't seem much more difficult than this: Everyone should take heed that these discussions are not popularity contests. Technical concerns raised on any proposal will need to be addressed by the group. Technical concerns will need to be mitigated, or an alternative path chosen. At least five technical concerns have been raised on the "Add |
|
👍 I am for this, adding This will allow quicker adoption and prevent broken linked data. As certain developers learn more about the spec they can add more precise semantic purity as their knowledge and needs grow. This will help us broaden the community and create a larger Open Web Of Trust. 🔐☑️ |
This comment was marked as resolved.
This comment was marked as resolved.
The problem is that this proposal requires developers to explicitly bring in a second context in order to use this default terms feature. I'm a -1 for it being a seperate context that has to resolved, managed and educated upon by the community,
No it doesn't you could quite easily write an expansion map that a) warns or errors on term expansion that is using |
|
Based on that there are two camps here now. Are there any middle ground? This is a thing that is going into a spec we will have to live with for a long time |
Having a pattern (which is already true today) that requires developers to bring in a second context to provide their VC-type-specific terms is consistent. I don't see it as harmful -- everyone needs to do this. The only question in v2, is whether the second context is the "undefined terms" context provided by the WG or a custom one provided (or otherwise selected) by the VC author. It's also a very easy framing for people to understand: For the second context, create your own or choose X, provided by the WG. This approach just builds on what we have already done in v1; the WG would just now be providing an "easy to use (but has ambiguity drawbacks)" second context for people to use.
You're referring to a specific implementation feature. Furthermore, it was removed from that implementation a while back in favor of a far simpler "safe" mode that throws on standard warnings from the JSON-LD spec instead (which was the "expansion map" feature's only use case). In other words, what was said earlier is true: standard tools do not support this and custom processing has to be implemented. It's much simpler for people to decide that their second context of choice is the "undefined terms context" instead of a custom one they provide -- and all the VC tooling can then be consistent and the choice can be easily detected. |
|
To answer your first question:
IMO, the two camps started with:
So, the middle ground is already what has been proposed above: "Ok, let's allow semantic ambiguity for developers that don't want to / can't easily define and host their own |
|
@dlongley . I agree. The simplest solution is that every JSON-only implementor always includes just two |
|
@OR13 nice idea of how to use unregistered JSON terms in JSON-LD but it gets messy for a few reasons
Is there a solution to all of this? Possibly, but it would require some work and consensus.
This could be done in stages. First rolled out in one child spec (this). Then promoted to best practices doc. Then suggestion promoted to full JSON-LD There might be some flaws in this logic, but perhaps could be a compromise solution that allows JSON and JSON-LD to live happily every after. Or at least some food for thought in that direction. If every spec of this kind chooses their own @vocab, I can picture some objections that are hard to clear up. But there might be some compromise solution that everyone can live with. |
|
-1 very bad idea as now parser has to change even more than before, I bet there will be far more implementations of pure JSON.
Get Outlook for Android<https://aka.ms/AAb9ysg>
…________________________________
From: David Chadwick ***@***.***>
Sent: Friday, October 21, 2022 7:39:28 PM
To: w3c/vc-data-model ***@***.***>
Cc: Subscribed ***@***.***>
Subject: Re: [w3c/vc-data-model] In support of adding ***@***.***` to `/credentials/v2` (Issue #953)
@dlongley<https://github.com/dlongley> . I agree. The simplest solution is that every JSON-only implementor always includes just two @contexts in every VC they issue, and these are defined in the v2 standard, namely: the v2 standard context and the 'unregistered' context which contains the @vocab.
—
Reply to this email directly, view it on GitHub<#953 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AB4R4Y6MW2QJABIPX3SLMUTWELINBANCNFSM6AAAAAARJLM3XA>.
You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
|
@jimschoening1 Yes, once you have made your claims... the natural next question is, can you make your claims / evidence clearer or less ambiguous. I did a review of vocabulary related to https://github.com/ietf-scitt recently, and I was surprised at the ambiguity and overlap between certain terms. Here are a couple examples:
It's a very popular occurrence in standards organizations too prefix a term with. "NIST" or "W3C" or "RATs"... so that people know which meaning / term you are intending to refer to... Referring to a well established ontology is one of the best ways to provide better semantic precision. Here are a few of my favorites, which we use to provide clarity regarding supply chain credentials: |
|
@OR13, |
|
I'm happy to explore an example, and if the working group approves, we can include it in the next version of the TR. I've added a separate issue to track that, please provide a JSON example on #963. |
Even with explicitly defined terms this issue doesn't go away, developers can pull in a bad mix of context URL's into a credential and find themselves in a situations where the IRI for a term isn't what they expected (that is if they even check). Semantics should be viewed as a useful feature that can be scaled into as the ecosystem needs it more. It shouldn't be table stakes to understand JSON-LD just to get started.
+1 and this should exist in the core v2 context, it shouldn't have to be dragged in separately. When it comes to the url I think "privateTerm/Claim" vs "undefined" is better because term expansions via |
|
Now that @OR13 has modified the initial proposal, the following issues (with strikethroughs) have been address... the ones without remain:
I'll also note that @melvincarvalho raised the following concerns, with strike-throughs based on the now modified (better) proposal from @OR13:
These concerns will need to be addressed OR a reasonable compromise position proposed. I'll re-state the counter-proposal and elaborate in an attempt to make sure we're all on the same page: COUNTER-PROPOSAL: Define a JSON-LD Context for at least "private claims". Require that any Verifiable Credential specify at least two contexts (the base context in the first position, and a market-vertical-specific context in the second position). This has always been a requirement to have a useful VC, and every conformant pilot/production deployment that we've seen has used this pattern (demonstrating that developers are capable of doing this): If a developer isn't capable of copy-pasting that ^ into their code, there is probably very little that we can do to help them. Creating a property that consists of an array with two string values is not a difficult ask of a developer, especially since we require far more complex properties in the rest of the VC Data Model. To be clear, Digital Bazaar remains a very strong -1 on the proposal stated here, for the reasons elaborated upon above. We are, however, a +1 on the counter-proposal stated above, which is a compromise position (we would rather |
|
+1 to 2 |
|
@David-Chadwick You can only ever have one However, I want to push back on the term "private" to describe any of this. Private v public is a red herring of a distinction that I have written about for over a decade now. The word itself has almost no meaning in this context (no pun intended). If someone wants to define a new context (perhaps the exact same one as envisioned as this "private" context), then, by all means do so. Anyone can create a context. That's how it works. Can someone explain what "private" means here? Maybe we can come up with a better term for the functional purpose of this additional context that any VC issuer would, of course, be able to add if it matches their use of the data model. It doesn't seem that it should be required. Anything required should be in the VC context that defines required terms. Given that it shouldn't be required, it seems like a fine NOTE for the WG to consider. |
I think what is meant by "private" here is something along the lines of "issuer-dependent". That is, you cannot tell what such a term actually maps to without the issuer telling you via some out-of-band mechanism. The URL such a term maps to (via |
|
@jandrieu Thankyou. Fixed my comment now. |
I am arguing that this proposal is the "safe default". Advanced processors can detect terms that are expanded using this default. The chances of developers creating valid (processable) JSON-LD goes up, this leads to the ability ingest more data albeit at a "lower" semantic quality. If you think about it, the data you get from a single context with a default vocab is always better than the data you don't get because the JSON-LD processor errored.
Everyone is already buying into: And in particular: "@version": 1.1,
"@protected": true,
"id": "@id",
"type": "@type",
The aliasing above is a great example of other places where we have tried to smooth the experience for JSON developers, to produce JSON-LD... Adding a default vocab completes this unfinished work.
This is false, the JSON-LD tooling can detect when vocabs are used to expand things. Experience has shown us that the JSON-only (not a thing btw), are best served by a default vocabulary... because it aligns with their intuition.... they can add new terms, and no errors will be thrown, and terms they don't understand are ignored and preserved. I am a "JWS secured valid JSON-LD" is the best way to issue credentials person at this point.
It does, see the namespace differences, for example:
It seems like there might be more to this bullet point, especially related to the use of
See the HTTP vocabs listed above, this ship sailed already, but its not too late.... we can make all the IRIs non http, here is an example for chebi: https://www.ebi.ac.uk/chebi/searchId.do?chebiId=CHEBI%3A16526
I don't think we need any IRIs (including the context or the vocab terms inside it be based on http... we have chosen to do so because of the usability benefits... which is what adding a vocab would be... we could add a vocab that expanded terms to NON http IRIs... if the WG wants to do that for the default vocab, I am open to discussing.
Yes, that is how vocab expansion works... instead of exploding, you might land on an issue that asks for help defining the term... See also schema.org, and their setup.
I'd like a citation for the best practice on this. It is true, that you can override the default vocab trivially, for example: Then the organization behind BTW, all the terms we have defined in v1 are hosted on https:
^ We can ask
^ This proposal is workable. But maybe it would be better to save the resolution and just do this: This way, anyone who copy pastes an example will be free to edit it, and add new terms... and they won't be forced to add another IRI to their document loader, and W3C won't be forced to serve another context file, that people will forget to add to their document loader. I think we should unpack the benefits of "JSON" that isn't valid "JSON-LD"... why would we want to expose users to these errors? We discussed this with our engineering team, and a lot of them felt that throwing errors was a good way to "teach lessons on JSON-LD". They also noted that, as experts in this space, the more errors that we process / handle the better our job security... people will need us to help them figure out how to define their terms! That could help us gate keep terms, so the terms that make it through are always of the highest quality... but it also feels a bit like a "premine"... where the value accrues to the people who understand the system first. As an editor / maintainer of term registries in W3C and DIF... I don't think this stance is helping us with adoption, and I don't think its "gatekeeping".... I think it's "censorship". We have built a system, where the average developer cannot produce data that is semantically valid, and our justification is that they should "become JSON-LD experts.... or hire one". Instead, we could make it such that they can produce data, and it is valid / has usable graph structure... and then they can learn or hire an expert to improve from the foundation and the safe defaults we have encoded into the spec... that is what we should be doing. |
|
Just to shoot in that if the info is clearly documented places in the spec, we create an issue on stackexchange related to invalid JSON-LD and answere it ourselves with the solution, add this to vocab. I dont think this will be such a hinder. I start making a VC, and it fails in the lib. Future libs can help to say want dev capabilities, do this. One will search for solutions and if done right the questions will pop up when searching. Or one will reread the spec to see what is up. So I dont really understand why explicitly flagging a free for all VC is difficult? |
|
Here is an example of exactly the problem that this proposal will address:
Also, the context is not correct, it should be Notice that |
Not quite.
|
Yes there is it just requires a JSON-LD processor able to detect that the term expansion is using this default vocab
Kind of, just because the default exists, it doesn't mean everyone has to use the default. There are many standards that can be cited that have used this strategy to great affect. See OpenID Connect Core and FAPI as one such example, the constrains applied by FAPI to the protocol required for financial service related interactions would be prohibitive if all implementers were forced to meet this bar. |
|
Instructions for making the context immutable using IPFS, and examples of the changes requested in this issue to the v1 context: https://github.com/transmute-industries/ns.transmute.org https://cloudflare-ipfs.com/ipns/vocab.v1.credentials.ns.transmute.org See examples here: #947 (comment) Notable that if even the examples in our spec are wrong (terms not defined in context), we're really setting developers and implementers up for failure, and a 1 line change to the current v1 context would have fixed this issue; |
|
Another DID Method registration that would have benefited from a vocab in DID Core v1 context. |
|
@iherman I believe we had resolutions related to this on a special topic call, but I do not see them here. |
|
PR is up: #1001 |
|
PR #1001 has been merged, which addresses this issue. Closing. |
PROPOSAL: Add an
@vocabto the/credentials/v2@context.Reasoning:
We (as editors of the did spec registries, and reviewers of various VC-JWT implementations) have seen a consistent failure to leverage
@contextproperly in DID Core and Verifiable Credentials... due to the "term not defined in the context" issue.The problem is not that "people don't want to define semantics"... its the opposite, they are eager to rely on semantics defined by the standards, but they don't know how to define new terms, or they don't want to take responsibility for hosting a vocabulary for their new terms as the first step in using or leveraging a new term... this is a barrier to adoption created by the W3C Working Groups, based on an argument for semantic purity... that has in my opinion, greatly harmed the adoption of semantic technologies and standards, including Decentralized Identifiers and Verifiable Credentials.
By adding
@vocabto the core data model context, we can give these developers the same experience they have with JWT private claims, which you should read about here: rfc7519#section-4.3If this proposal is adopted, developers will be allowed to do this:
and
claimNamewill get a default IRI, assigned byhttps://www.w3.org/ns/credentials/v2... something like:https://www.w3.org/ns/credentials/#claimName.https://www.w3.org/ns/credentials/claims/private#claimNameThis will produce beautiful and valid JSON-LD, which can immediately be processed in an interoperable way, using SPARQL, RDF, or other semantic standards developed at W3C and elsewhere, including conversion to Cypher, GQL or Labeled Property Graphs (Automatically).
The issuer's of such credentials might later decide to refine term definitions for such credentials by either:
This allows for issuers to gradually improve their semantic precision over time, as they become more skilled and knowledgable about graph interoperability... Its been our experience this leads to better engagement, and better semantics in the long run.
The alternative to this proposal is the status quo, where we see a new DID Method registered every week, that fails to define
JsonWebKey2020orEd25519VerificationKey2020properly, but includes references to them and includes an@contextthat simply points at the did core v1 context.... These folks are only making a "mistake" because our working group chose not to take the same path I am proposing here when publishinghttps://www.w3.org/ns/did/v1.We can see why people are assuming what they are doing is legal, we expect them to keep doing what they are doing... we can make what they are doing legal and interoperable, and useful.... why would we choose not to accept this proposal?... especially given that it does not block advanced context users from improving precision in the 2 ways mentioned above.
The text was updated successfully, but these errors were encountered: