Register JwtProof2020 or warn users not to use this library
OR13 opened this issue · comments
Register it here:
its 2021, where is the full IRI for JwtProof2020 ?
https://w3id.org/did/v1 does not define JwtProof2020...
https://www.w3.org/ns/did/v1 does not define ANY proof formats (only verification methods)....
You should review https://w3c.github.io/vc-data-model/#dfn-context
and define a context which you control, where you can define all your terms for your users... see:
https://w3c.github.io/did-spec-registries/#schnorrsecp256k1verificationkey2019
https://w3c.github.io/did-spec-registries/#gpgverificationkey2020
Feel free to register your extensions in did spec registries as well.
Thank you for being vigilant about @context issues.
We came up with JwtProof2020 as a means of defining a common data type that can be used by credentials and presentations once they've been parsed and verified. This data type would more closely match the w3c spec while allowing devs to work with JWT credentials.
I'm not sure if this is the right approach for this, and this is why it's not yet registered.
I'd appreciate any input on this matter.
there is also https://w3id.org/jws/v1 and this thread on context splitting:
If I can register what you are doing I will, I just don't understand why you need a proof.type for a JWT.. the header has the necessary information, and the vc-data-model does not describe type as being relevant to JWT.
If you want to use JOSE to produce linked data proofs, you can. If you want to use JOSE to produce JWT or VC-JWT you can.
https://w3c.github.io/vc-data-model/ does not refer to "JwtProof".
If no JWS is present, a proof property MUST be provided. The proof property can be used to represent a more complex proof, as may be necessary if the creator is different from the issuer, or a proof not based on digital signatures, such as Proof of Work. The issuer MAY include both a JWS and a proof property. For backward compatibility reasons, the issuer MUST use JWS to represent proofs based on a digital signature.
It seems like the best course of action would be to simply remove "JwtProof2021" and show examples of JWT's that were decoded, when you want a nice JSON view.
There is also https://github.com/decentralized-identity/did-jose-extensions which is supposed to help with JOSE / DID issues, and which also does not describe proof.type.
We don't use VC-JWT for anything, but we do support it as described in the vc data model in these tests: https://github.com/transmute-industries/vc.js/tree/master/packages/vc.js/src/__fixtures__/test-vectors/vc-jwt
Note that none of our tests have JwtProof because it's not described by the vc data model.
I am trying to tighten up all the connection points to DID Core which includes providing examples in DID Core.... The DID Core example also does not include JwtProof, https://w3c.github.io/did-core/#example-38-verifiable-credential-as-decoded-jwt
I am concerned that this library titled "did-jwt-vc" appears to have significant differences from both W3C standards, which are not documented.
It also seems to be mostly focused on secp256k1 and ethereum.
If the library is meant to remain generic and support jwt-vc, I would recommend following both standards (DID and VC) to the letter, and if you want to innovate, make it clear that the innovation is not registered / experimental.
You might also consider replacing did:ethr in examples to convey that these libraries are meant to be generic.
If these proposals are agreeable I am happy to help make them.
@OR13 I guess the intention of this was to produce JWT-based VCs together with the pre-transformed unsigned JSON-LD VC payload and having both as the result of the creation process. One of the reasons for this is to have simpler searching and querying for VCs by operating on the pre-transformed unsigned JSON-LD VC payload only rather than supporting two different formats and "data models". This can be useful if both JWT-based VCs and LD-Proof-based VCs live in the same data storage. I agree that Jwt2020 is unnecessary and we could probably drop that from the output as it creates the impression this is a specific LD-Proof. Also note that verifyCredential won't use any information other than the actual JWT for verification purposes.
for making JWTs searchable as JSON, I would recommend simply storing them as decoded objects.... however that is an "internal" not a standards concern....
The following should all be true of a library that implements a standard:
- the library uses the standard test vectors if they exist.
- the library clearly explains methods that support the standard data model, and methods that expose internal or custom data models for usability.
I don't see any value other than confusing developers by including JwtProof2020, but it could be preserved by adding a note saying something like: "all though its not standard or required, we find adding this extra json member helpful"... assuming that including it produces valid JSON-LD, which is currently false.
@OR13 Please see #56 as a potential solution to the lack of clarity.
If the library is meant to remain generic and support jwt-vc, I would recommend following both standards (DID and VC) to the letter, and if you want to innovate, make it clear that the innovation is not registered / experimental.
It is more about the lack of bandwidth to keep up with a shifting spec than innovation.
You might also consider replacing did:ethr in examples to convey that these libraries are meant to be generic.
Noted!
If these proposals are agreeable I am happy to help make them.
If you have time to spare for this, then definitely yes!
awesome looks like #56 is headed in the correct direction.
🎉 This issue has been resolved in version 1.1.0 🎉
The release is available on:
Your semantic-release bot 📦🚀