- From: Mike Prorock <mprorock@mesur.io>
- Date: Tue, 6 Sep 2022 12:34:17 -0400
- 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>
- Message-ID: <CAGJKSNRwmc+_x9OL2rkp8R6OTJ8M5ux91rYp3pGajto927Cxig@mail.gmail.com>
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