More implementation issues

[nadalin]

I have a very simple claim, uses JSON-LD so I went to try to see if I could create a proof for this claim, so I read the latest JSON-LD Signature specification pointed to by the VC specification and its incomplete, it has wrong pointers to the algorithms and suites, broken links, etc. I wanted to create the hash (7.3) but the section does not tell me exactly what the input should be or in what order the signature option should be in, why UTF8 and not URLBASE64 encoding is used , what keys do I use, how do I get the publickey, etc. so can’t do that. People may have implemented JSON-LD Signature specification but you can't implement it from just reading the specification as it's incomplete.

My point is that the JSON-LD Signature specification should not be referenced in specification because it’s incomplete and one can not create an implementation from reading.

My head explodes when I read the RDF Dataset Normalization specification, what I have to do there, this will take me some time to see if that can be implemented per specification.

The only VC that I can implement so far with a proof is using a JWT since the claim format is well documented, the signature algorithms are documented along with the process to sign and verify, I used the JOSE4J library and all worked fine, creation and verification. There is one problem in that I can’t do what the specification says and that …

“All libraries or processors MUST ensure that the order of the values in the @context property is what is expected for the specific application. Libraries or processors that support JSON-LD can process the @context property using full JSON-LD processing as expected.”

As I have no need to parse the @context for a JWT and thus I can’t ensure that order is correct, I don’t believe this needs to be in the specification at all and should be removed or be a RCOMMENDED at best.

I don't see a usecase for why the @context has to be there, I'm willing to just put it there with garbage (since it’s not used in my usecases) but there no reason that I can see that you MUST ensure that the order of the values in the @context property is what is expected for the specific application. Unless that MUST is do nothing, which is not in the note, which it should be if that is what is meant by the MUST.

[brentzundel]

I don't see anything in this issue that differentiates it significantly from issues:

• Section 4.1 Context #483
• 5.3.1 Semantic Interoperability #491
• 5.3.1 Semantic Interoperability #525
• Explain why @context provides interop #548
• @Context #557
• @Context Processing  #558
• @Context #604
• Tracking Issue: JSON-LD concerns #633

I should also point out that as this issue was received after the end of the public comment period for the CR, even if it raises a concern not already addressed by one the previously closed issues, it may be officially deferred to after version 1.0 of the specification.

[David-Chadwick]

@nadalin Tony you are familiar with X.500 attribute types and the use of OIDs to uniquely identify them, and the mess that LDAP got us into by using user friendly names instead of OIDs. The @context feature is there to stop this happening for VCs. The @context lists the globally unique ids for VC properties (as URIs) and the user friendly aliases that can be used instead when creating VCs. So clearly it cannot contain garbage as you assert, otherwise no other VC implementation would be able to understand your VC properties. The @context is an essential feature of VCs to ensure global naming of all the properties.
The ordering is necessary to stop a later @context value re-assigning the same alias to another URI.

[nadalin]

@brentzundel Per the note that went out on July 25 "Verifiable Credentials Data Model 1.0 Candidate Recommendation revised (Call for Implementations)" the comment date is August 21st, so the comment period has not closed yet.

[nadalin]

@David-Chadwick I can see your point for non JWT based VC's but not for JWT based VCs

[brentzundel]

@nadalin to quote from the current CR:

This is the second publication of a Candidate Recommendation document and is being made for specific feedback on a change to the JWT section related to the nbf and iss attributes. The Working Group is only seeking feedback on these changes from implementers and is specifically not seeking feedback on other parts of the document. The comment period for these features expire on 21 August 2019

The issue you have raised is completely unrelated to the change we made to the JWT section, which is the only aspect of the spec that is open for feedback.

[nadalin]

@brentzundel I have commented on the JWT section as requested in the call that went out on July 25th, I have implemented the JWTs but with an issue that I raised. The JWT is the only part that I have been able to implement so far.

I'm also giving feedback to the community on implementation issues I have been encountering.

[David-Chadwick]

@nadalin My comment is just as relevant to JWT based VCs as to another proof based mechanism. This is because the properties in the verifiable credential (which is the vc claim in the JWT) are identical regardless of the proof mechanism. Therefore in order to avoid name clashes you still need the @context in the JWT vc claim

[nadalin]

@David-Chadwick The JWT is just not used as a proof (it's actually the proof that I could get to work), but the claim also, and I still don't see the need as I'm not creating a name clash at all.

[David-Chadwick]

@nadalin You are not creating a name clash in the JWT because we have registered (or are in the middle of registering) 'vc' with IANA. The name clash will be in the properties of the vc claim, which contains the claims of the VC subject (as well as other properties such as termsOfUse etc.

[nadalin]

@David-Chadwick There is no processing requirements of the @context statement, thus there will not be any name clashes unless you are using JSON-LD processing

[David-Chadwick]

@nadalin There is a requirement for JSON and JSON-LD implementations to understand the @context. It is obvious why. Two issuers could independently define the "role" property for a subject, and give it different URIs, but the same JSON property name. These role properties would probably have different semantics and different syntaxes. How is a verifier, that gets VCs from both issuers, meant to know that the role property is different if the @context in the VC is ignored?

[nadalin]

@David-Chadwick There is absolutely no requirement to understand or do anything with the @contText per the specification and there are also no "security considerations" listed in the specification that state collisions issues.

There is no "role" property.

The VC could have claims that distinguish it apart, or it may not ever need to distinguish it apart, could always assume single role as I can lots of usecases for this.

You are using @context in a partiular way for your usecase that other may not be as there would be many other ways for a verifier to deterine the context of the claims. The "id" property could be used to signify a specific/different role.

If the @context must be understood then the specification must state so and what it means to "understand" otherwise content can be garbage (cavet that the 1st item of the ordered set being https://www.w3.org/2018/credentials/v1)

[aljones15]

@nadalin @David-Chadwick you might try using @context with back ticks in order to avoid pinging the github user with the name context who is not part of this issue. It looks like the user context is not that active on github anymore, but it does help to differentiate if you are talking about a json-ld @context or referring to another user.

[burnburn]

In 20 Aug 2019 VCWG call:

RESOLVED: The WG believes that it has answered many of the questions raised in issue #712 multiple times before to the issue submitter, the group has agreed to defer the conversation until another group picks up the specification.

[iherman]

The issue was discussed in a meeting on 2022-08-03

• no resolutions were taken

View the transcript

6.3. More implementation issues (issue vc-data-model#712)

See github issue vc-data-model#712.

Brent Zundel: concerns about issuing JSON-LD stuff.
… At first thought would be data-integrity....

Orie Steele: This seems like a core spec issue..

Manu Sporny: I think because it covers things in the core spec, we need to deal with it in the core spec first.

Brent Zundel: Deal with in core spec first?.

Manu Sporny: Rather not debate, but it is a data model issue.

Michael Prorock: I fully agree, it's a core spec item; there may be issues in data-integrity, depending on what happens..

David Chadwick: Potentially also an issue for the JWT work... because there there is no context requirement..

Orie Steele: +1 David... its a core spec issue, that will impact all the "securing the core data model" specs..

Brent Zundel: OK, taking the label off..

[brentzundel]

closing this issue as it has been superseded by #947