-
Notifications
You must be signed in to change notification settings - Fork 106
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
JSON-only processors and VCDM 2.0 conformance #1290
Comments
One proposal would be to drop the URL requirement entirely since for JSON-LD processors |
@awoie raises a good question. |
{
"@context": {
"@vocab": "https://vendor.example#"
},
"@id": "urn:uuid:123",
"@type": ["urn:uuid:456", "Foo"]
}
^ this is the behavior of the current v2 context... which uses |
To resolve this issue I suggest some sentences be added to the "value of JSON-LD" section, explaining that
are more valuable to the 3 role models than: Its easy to argue against the value of RDF... its hard to argue for it... unless you actually show RDF that is substantially better than what you get from JSON by itself. |
Yep, and for that reason, a JSON-only processor is not able to understand that "Foo" is actually a URL. I think what we need to do is either of the following:
So, I guess 3. is the best option. Not sure what needs to be added to the JSON processing section though. Any thoughts? |
I'm in favor of dropping the JSON processing section, and instead adjusting the JSON-LD section to address processing the core data model as RDF and processing it as JSON without converting to RDF (subtle difference from what we have today, but makes better technical recommendations imo) I think its a mistake to tell people that the core data model can be treated as JSON, when its based on JSON-LD... we have seen this causing lots of problems with DIDs still. Its also a mistake to ignore what it costs to convert strings to URLS, it costs power, time and energy and sometimes it fails. All of that is important when evaluating the value of processing claims as URLs. |
The problems you raise are correct, but for JSON processors, does it matter? If they do not care about semantics then what good is it to misunderstand semantic processing? I was under the assumption that as long as terms didn't conflict, JSON processors would be fine. |
IMO, if there is a JSON processor that implements the VCDM 2.0 spec and parses The problem gets worse if JSON and JSON-LD processors are mixed. IMO, we should add some guidance in the spec. |
I think there continues to be confusion around "JSON processing" -- and this is really "JSON-LD processing", it's just that newcomers do not always understand that you don't need a JSON-LD library to consume a JSON-LD document. You can read it like you would any other JSON library, following the rules of the spec associated with the document (in the case here, that is the VCDM and JSON-LD specs -- and any additional spec / context from a particular community). I think we should rename the section to "JSON-LD processing" and have it clarify that JSON-LD libraries are not needed to do "JSON-LD processing" when you follow the advice in that section. In that case you are simply using "JSON" -- but in the same way anyone consumes JSON -- following some spec(s) to interpret it appropriately. I think we should say that if a value has a compact form defined in the context, then that's the form that should be used. These "JSON processors" (as we reference them today) already must know the context that is being operated on (as mentioned in the currently named "JSON processing" section) and can therefore rely on checking for non-URL values for anything that would be in the context (including |
Can you provide an example where the difference matters for a JSON processor?
You might as well treat them as two different credentials...I agree. |
I like @dlongley 's suggestion, but it seems something may still be missing (or I am still missing something). The VCDM says the value of |
I would say that there are two cases there. In one case, you are reusing a context where someone else has already done the mapping. You read that someone's spec, it said use context In another case, you're just using the base VCDM context (v2). Here you just use URLs if you want your types to be unique across issuers, or you use issuer-dependent strings (which |
Regardless of what we say, this will continue to be valid:
{
"@context": {
"givenName": "http://schema.org/givenName",
"familyName": "http://schema.org/familyName"
},
"@id": "http://me.markus-lanthaler.com/",
"@type": "http://schema.org/Person",
"givenName": "Markus",
"familyName": "Lanthaler"
} Anything that implies off the shelf behavior is "wrong", needs to be removed from the spec first... then we can profile from the way things are... to what restrictions we can get the WG to agree to impose. I don't see the WG agreeing to restrict |
I agree and that is why I think the entire JSON processing section is completely misleading although some things might be true statements but this doesn't justify their presence if it confuses people. If WG members are debating about those things then implementers will be definitely confused too. |
#1298 might close this issue. |
Since it looks like both #1298 and #1302 might fail to be merged given our new more aggressive (and justified) PR work mode... and in yet another attempt to try to use better language around what we're trying to convey. What if we were to (as suggested in the threads above by @awoie, @OR13, and @dlongley). We do at least the following thing:
It's really (bikeshed) "application-specific processing". That is, you use an application-specific JSON Schema-like mechanism to check the structure of the VC you're expecting, and if it passes your JSON Schema, you process it like you would process any application-specific JSON object -- using a set of static rules in your code. Another name we could use here is "static processing". Then the "other thing" we do is "JSON-LD Processing", which is utilizing a JSON-LD library to process the VC, which might include compact/expand... or converting to RDF. We might also consider an "RDF Processing" section, which is done when doing things like securing via some forms of Data Integrity. There are variations of the above in some of the PRs that @OR13 has raised. The alternate path being proposed here is we take care of the "JSON Processing" language first and see where that takes us. I can try out a PR or three to see if we can make headway there. To be clear, this doesn't change the way some people have written VC software for years... it just changes the way we explain it so that we get more alignment among mental models. |
+1 to application-specific processing. Worth calling out what that means, and the tradeoffs for interop. |
Yes and we should also stop saying that JSON processors can do VCDM 2.0 processing without applying non-standard extra steps, or by only applying steps defined by the VCDM 2.0 standard.
I'm not in favour of this phrasing. "application-specific processing" could literally mean anything but most importantly it means it is not defined by the VCDM 2.0 standard and therefore we cannot make any assumptions on what implementers will do which does not lead to interoperability. I'm in favour of removing the entire section on JSON-processing because I disagree that the above phrasing is helpful. It still implies that JSON-only processors can comply to the standard if they do non-standardized (application-specific) things to comply. This does not sound right to me. |
The issue was discussed in a meeting on 2023-11-01
View the transcript2.5. JSON-only processors and VCDM 2.0 conformance (issue vc-data-model#1290)See github issue vc-data-model#1290. See github pull request vc-data-model#1302. Brent Zundel: JSON only processor and VCDM 2.0 conformance. Raised by Oliver and not assigned to anyone. He brings up good points about how we define it in the spec. If no one gets assigned it can't move forward.
Manu Sporny: I'm wondering if we can get direction from the group. Its clear that people don't like the term "json processing". There have been two alternative terms proposed. We stop calling it JSON processing because certain workgroup members feel its misleading. Do we want to call it status versus dynamic or application specific versus generalized. Can we get feedback?
Ivan Herman: application specific is better than dynamic versus static. I think that application specific is really very broad. In our case what is relevant is that its credential specific. Its what we should do. Brent Zundel: we do have a somewhat related PR open 1302 which is marked post-CR. Maybe it doesn't apply? Does it apply to this issue? How? As far as context specific, I agree that application specific doesn't tell me much. Credential specific might be better. But that begs the question that if there is credential specific processing, why haven't we defined it. I would expect that question to be asked.
Joe Andrieu: I think limited might be what we are talking about. We should do ranked poll and pick. Manu Sporny: We could debate endlessly but a ranked choice poll would be a good option. I can put this out this week and run it for a week and we can review what comes back.
Manu Sporny: Need to get all the options down. Please put your options into the minutes so it shows up in the poll. Joe Andrieu: I think what we are trying to name is not application specific. Its the choice of the verifier what processing they want to do. I think we put the choice at the verifier. Its not a choice of the issuer, application or credential. Thats why they didn't resonate with me. Dave Longley: Agree with Joe. We can fall into a lot of pitfalls if we specify the type of processing. Its really about the specific set of document that you accept. We don't want to confuse people into thinking that data would be understood in a different way. Its whether you accept a lot of things or just what you understand in your context. Brent Zundel: We have another PR and poll going out. But no one is assigned to the issue. Manu Sporny: I could pick it up once the poll is done and its clear what people want it to be changed to. Ivan Herman: can we do it now. Manu Sporny: Not sure over IRC. We have a ranked choice poll tool and I suggest we use it. Brent Zundel: Look forward to seeing the poll. Moving on to the next issue. |
@decentralgabe wrote:
@awoie wrote:
A poll has been created to gather feedback from the WG on what the appropriate term is for the behavior that we're covering in the specification: https://www.opavote.com/en/vote/5254957337935872 Everyone that has strong feelings about the correct terminology should feel free to weigh in on the poll above. |
The issue was discussed in a meeting on 2023-11-15
View the transcript1. poll results.Manu Sporny: We should review the results from the poll.
Manu Sporny: The context is that we decided a few weeks ago to run a poll. We wanted to change the name of a certain aspect. It looks like we'll choose to 'Credential Type-specific' processing.
Manu Sporny: I have already created a PR. I suggest that we close the poll and I can modify the PR to show the chosen result.
See github pull request vc-data-model#1351. See github issue vc-data-model#1290.
Joe Andrieu: I appreciate the term 'limited' but I don't like the term 'unlimited'. I think that could be a problem.
Manu Sporny: The poll is not a binding vote, so we can still take into account other views.
Brent Zundel: It is OK to have a compromise, but I would like to avoid spending further time on the topic during this meeting. |
I don't think the distinction as stated in the poll is the right one:
Rather, I think the decision is
Making that even worse is a third possibility
But my first surprise on the poll was the pairing of names. That's going to lead to weird and likely invalid results. We should probably separate the two and do them separately. Another way to think about these three
In particular, I want to note that Option C is the biggest lift as an ask for anyone in the ecosystem, and we definitely have consensus against requiring that level of complexity for verifiers. Option A is the lightest lift, which is what we might have called json-only processing. Option B is what I understood as json-ld-light. Given these three different notions of processing, I don't think the bound pairs in the poll are going to give us much useful information. |
PR #1351 has been merged, which has resulted in the removal of the term "JSON-only processing" and has been replaced with the "Credential Type-specific Processing" vs. "General JSON-LD Processing". After verification is complete, the former type of processing can be done w/ a simple JSON Schema check (or similar mechanism) and then processing the resulting object directly (no JSON-LD library required, no conversion to RDF required). The latter requires the use of a JSON-LD library. Based on the language in the spec today, the answers to the questions asked in the initial issue are:
No, it does not. For types, short form is strongly encouraged everywhere. Language has been added to the specification that states that interoperability will be harmed if URLs are used for
No, it does not. Issuers that produce VCs with a type using compacted form are expected to have broad interoperability using either Credential Type-specific implementations or General JSON-LD Implementations. I'm marking this issue as pending close to see if there is disagreement that we have addressed the issue via PR #1351. |
I still believe that the current language may give rise to conflicts regarding the JSON-LD expansion serves the purpose of semantic disambiguation by expanding all terms and translating them to IRIs. A calling application may undertake this challenging task and may comprehend that a credential is suitable for a credential type-specific implementation, but the credential type-specific application may not share the same understanding. In my opinion, something should be added to emphasize that the credential type-specific application MUST depend on a calling application to perform this task genuinely, essentially adhering to W3C VCDM processing (as specified in the standard). Otherwise, the current language does not convey that credential type-specific processing is W3C VCDM compliant. There is no normative language that proves otherwise:
|
@awoie What we are hoping to get from you is a suggestion for concrete text that would address your concern if added to the spec. |
The issue was discussed in a meeting on 2023-11-28
View the transcript1.5. JSON-only processors and VCDM 2.0 conformance (issue vc-data-model#1290)See github issue vc-data-model#1290. Brent Zundel: I believe this has been overtaken by events. Manu Sporny: Oliver may be requesting a minor modification to the text.
Brent Zundel: I can tag Oliver. |
@awoie ping (again), do you have a concrete text proposal that the WG could consider? In an attempt to be specific: @awoie wrote:
I don't believe the statement above, based on the re-written text in the spec, is true. Specifically, the specification contains this text now for credential type-specific processors: That, along with the other rules in that section, provides the assurance that the type expansion that you refer to is not necessary. I believe we've made a number of changes to the specification in order to address your concerns. A concrete text proposal is what we need at this point to proceed, if not, the WG will most likely close this issue as we believe that we have addressed the concerns you have raised in this issue. |
We have attempted to address this issue with PR #1351 |
I just want to make sure we cover the following case for JSON-only processors.
According to section 4.4:
According to section 1.4, a conforming processor is defined as follows:
We should describe what a JSON-only processor has to do in that case since they cannot do JSON-LD expansion and would not be able to recognize compacted
type
values as URLs.That brings up two questions:
type
values when issuing VCs to be conformant?type
using compacted form cannot be verified by JSON-only processors?The text was updated successfully, but these errors were encountered: