Re: A node.js did:jwk implementation

Very nice job!

I too would be interested in how this evolves for CBOR/COSE, thought outside the CWK context – for a “stand-alone” COSE signature, such as those used in C2PA (https://c2pa.org/specifications/specifications/1.0/specs/C2PA_Specification.html#_digital_signatures) where we also use a certificate chain.

(yes, I know our current signatures are separate from our credentials in C2PA – but having a way to align them would mean that we could then use VC/DID’s as a signing credential and part of our trust model!)

Leonard

From: Orie Steele <orie@transmute.industries>
Date: Tuesday, September 6, 2022 at 12:33 PM
To: W3C DID Working Group <public-did-wg@w3.org>, W3C Credentials CG (Public List) <public-credentials@w3.org>
Subject: A node.js did:jwk implementation

EXTERNAL: Use caution when clicking on links or opening attachments.


Friends,

This was my weekend project: https://github.com/OR13/did-jwk<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FOR13%2Fdid-jwk&data=05%7C01%7Clrosenth%40adobe.com%7C040d2a1f24c64f55f9cc08da90258555%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637980788095479741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=J9rEUPz7zWn6tnKNbAXzBHu6ZjY6glH19t29Z98RbiA%3D&reserved=0>

It's an implementation of https://github.com/quartzjer/did-jwk<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquartzjer%2Fdid-jwk&data=05%7C01%7Clrosenth%40adobe.com%7C040d2a1f24c64f55f9cc08da90258555%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637980788095479741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=gigbsmJ9KwJB3H4KT7PpXAugRZgfmVnco0%2BbAHwCcmI%3D&reserved=0>

It's only dependencies are:

-  https://github.com/yargs/yargs<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fyargs%2Fyargs&data=05%7C01%7Clrosenth%40adobe.com%7C040d2a1f24c64f55f9cc08da90258555%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637980788095479741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=G4jKBWHp8oO5J%2BH9HHMvX2zDgX%2BY7tfVJMNqhDixXDA%3D&reserved=0>
-  https://github.com/panva/jose<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpanva%2Fjose&data=05%7C01%7Clrosenth%40adobe.com%7C040d2a1f24c64f55f9cc08da90258555%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637980788095792187%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ymaXwNosMK%2BPtl5DGGqhWxH4Aj64WACjAKzvjtI5%2BhU%3D&reserved=0>

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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fvc-jwt&data=05%7C01%7Clrosenth%40adobe.com%7C040d2a1f24c64f55f9cc08da90258555%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637980788095792187%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=TrnICeVUy%2BKApUR1WxgkmylE8dpz0Q8QrRTTNvDvXGA%3D&reserved=0>
- https://github.com/w3c/vc-jws-2020<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fvc-jws-2020&data=05%7C01%7Clrosenth%40adobe.com%7C040d2a1f24c64f55f9cc08da90258555%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637980788095792187%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=J515D3iPbPXgzGpj1PF7XbB1g8OH5jOJAb3xLO5Y1uQ%3D&reserved=0>

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<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc7517%23section-4.3&data=05%7C01%7Clrosenth%40adobe.com%7C040d2a1f24c64f55f9cc08da90258555%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637980788095792187%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2B3EwFZrqp5UcYmtxvNJL%2F3hscGuI3Zmv5kWCQo1RWGY%3D&reserved=0>, 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<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc7517%23section-4.7&data=05%7C01%7Clrosenth%40adobe.com%7C040d2a1f24c64f55f9cc08da90258555%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637980788095792187%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=FzypUg1pG3evYXgU0sfgQ4SgJYX1HP1b7goRDUq8GjI%3D&reserved=0>

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<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcose-wg%2FCBOR-certificates&data=05%7C01%7Clrosenth%40adobe.com%7C040d2a1f24c64f55f9cc08da90258555%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637980788095792187%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=LouYx8q4cdlMWNOqgFFEsQ5IBQBIq0XvYpYm0Zc38Lo%3D&reserved=0>

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

[Image removed by sender.]<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.transmute.industries%2F&data=05%7C01%7Clrosenth%40adobe.com%7C040d2a1f24c64f55f9cc08da90258555%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637980788095792187%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=APQT4Z4PajV0%2F9n3kVCtWS%2F8q2z1zuRj%2FdbEVMhs73Y%3D&reserved=0>