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
Adopt ES256K JWT as Credential Format #5
Comments
|
If this issue does not receive significant comments / criticism, I recommend we adopt JWT as the format, and rely on credential wrapping as needed to support wallet integration down the road. |
@OR13 Do any of the major JOSE/JWT libraries support ES256K out of the box? I would guess they only support ES256 (which is NIST P-256 curve). |
@OR13 Just checked here https://www.npmjs.com/package/@panva/jose and it seems this library has indeed implemented ES256K support. |
@christianlundkvist I have tested https://github.com/uport-project/did-jwt and found that it does work with node 12 / panva/jose. I have not tested https://github.com/decentralized-identity/did-auth-jose , but in theory it should work. node 12 supports secp256k1 out of the box, with non deterministic k signatures. But node 12 is not usable with many versions of web3, I think we will likely need a small ES256K library. I have one built with web assembly runs in browser and on node but it is not published yet. If wallet apps need to verify signatures on credentials, we will need a list of supported architectures. |
I would like to make the case for supporting three variants: secp256k1, RSA, and ED25519. We did a DIF member survey a while back, and literally everyone fell into these three. If we must reduce to one, secp256k1 was by far the most used. Just my 2c |
If we accept standard JOSE and soon to be adopted JOSE, we will have support for these 3. These are the related RC RFC / drafts. They are well enough documented to be implemented, and there are implementations out there, like the one above. https://tools.ietf.org/html/rfc8037 For the Credential format to be fully specified, additional information is required however.
These are 3 fully supported JWT On a related note, I believe we should require all publicKeyJwk to include a conformant |
@kdenhartog Does DIDComm support these 3 formats ^ ? / can we agree it will ; ) |
A JSON-LD alternative to JWT: https://github.com/digitalbazaar/vc-js I don't think this is a good idea for the interop project because there seems to be less support for JSON-LD Signatures and Credential formats than JWT, but I could be convinced by a strong counter argument. I do love JSON-LD, and I have used related libraries before. |
Yes DIDComm credential exchange protocol can support any arbitrary credential format and support a variety of crypto suites. However, the project in DIF (DIDComm-crypto-js) is not related to handling VCs. It's intended to be the "cryptographic envelope" to send arbitrary semantic messages. One of which might be the credential exchange protocol messages. I have been exploring what it would take to support additional cryptosuites for the "crypto envelopes". More details to come later on that. |
I agree with @csuwildcat observation. We did a survey and secp256k1 (ES256K) was supported by most ppl. In the DID Auth WG we reconfirmed that ES256K, Ed25519 and RS256 are the algorithms we want to support. uPort is working on a VC JWT library and we are intending to move that library to DIF. The library will have support for ES256K, ES256K-R and Ed25519 (Nacl). @pelle could you provide more info when this will happen? |
@OR13 @rado0x54 The credential format that you proposed is not W3C compliant. We could use the following minimal W3C VC JWT profile: updated
And for the W3C presentation we could use:
|
@awoie thanks, my proposal was a straw-man. These are excellent format suggestions, I'll edit the issue to reflect using them. |
I'm going to consider this adopted, and update the readme to reflect the decision. |
I recommend ES256K (Unencrypted) JWT for Credential and Presentation, see the format proposed by @awoie below.
The text was updated successfully, but these errors were encountered: