- From: Orie Steele <orie@transmute.industries>
- Date: Tue, 6 Sep 2022 11:30:57 -0500
- To: W3C DID Working Group <public-did-wg@w3.org>, "W3C Credentials CG (Public List)" <public-credentials@w3.org>
- Message-ID: <CAN8C-_+=n4YvoJ5+xFxqcrT11A+Dti8Wj49WcnR8goLqonfvjw@mail.gmail.com>
Friends, This was my weekend project: https://github.com/OR13/did-jwk It's an implementation of https://github.com/quartzjer/did-jwk It's only dependencies are: - https://github.com/yargs/yargs - https://github.com/panva/jose It comes with out of the box support for: - many key types (supported by JWK) - many signature types (supported by JWS) - many encryption types (supported by JWE) - built in cli for testing (see readme) Why spend time on "did:jwk" what's wrong with "did:key" ? There are several things about "did:key" that make it a difficult starting point for the community: 1. Multibase is not yet an IETF RFC, there are limited implementations of it There is `secdispatch` thread on this, AFAIK, its WIP. 2. "did:key" doesn't really have a preference for "publicKeyJwk" vs "publicKeyMultibase" or application/did+json vs application/did+ld+json So if you support "both" you automatically support a superset of "did:jwk". This means did:jwk is by definition even simpler than "did:key" ! 3. Easier to integrate with JsonWebSignature2020 and VC-JWT Both formats prefer keys in JWK format, and produce signatures in JWS format. See: - https://github.com/w3c/vc-jwt - https://github.com/w3c/vc-jws-2020 4. "did:key" does not support certificates Arguably this is a feature of "did:key" in that it makes the keys "simpler"... don't support https://www.rfc-editor.org/rfc/rfc7517#section-4.3, etc... But many use cases, including the "mDoc personal credential" use cases and the "cyber physical supply chain" use cases, require some concept of "certificate chains". This is fairly trivial to support in did:jwk, due to JWK supporting x5c... -> https://www.rfc-editor.org/rfc/rfc7517#section-4.7 5. A path to compact binary DIDs that is familiar to JSON / JOSE developers. Due to the similarities between JOSE / COSE... A similar method for cwk (COSE_Key?) is possible, we're very interested in this use case, particularly due to: https://github.com/cose-wg/CBOR-certificates Conclusion: Keep in mind, I built this entire package yesterday... All I needed was a good JOSE library as a starting point. Other language support is expected to be similarly trivial... especially now that you have an "example implementation" and "test-vectors" to base your implementation on. Regards, OS -- *ORIE STEELE* Chief Technical Officer www.transmute.industries <https://www.transmute.industries>
Received on Tuesday, 6 September 2022 16:31:21 UTC