W3C home > Mailing lists > Public > public-credentials@w3.org > September 2022

Re: A node.js did:jwk implementation

From: Mike Prorock <mprorock@mesur.io>
Date: Tue, 6 Sep 2022 12:34:17 -0400
Message-ID: <CAGJKSNRwmc+_x9OL2rkp8R6OTJ8M5ux91rYp3pGajto927Cxig@mail.gmail.com>
To: Orie Steele <orie@transmute.industries>
Cc: W3C DID Working Group <public-did-wg@w3.org>, "W3C Credentials CG (Public List)" <public-credentials@w3.org>
Very cool! Will definitely put it on our radar as we have interest in this
for the reasons you outlined vs did:key.

Mike Prorock
mesur.io

On Tue, Sep 6, 2022, 12:31 Orie Steele <orie@transmute.industries> wrote:

> 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:34:41 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 6 September 2022 16:34:42 UTC