Re: A node.js did:jwk implementation

This is awesome:
https://c2pa.org/specifications/specifications/1.0/specs/C2PA_Specification.html#_digital_signatures



On Tue, Sep 6, 2022 at 12:18 PM Leonard Rosenthol <lrosenth@adobe.com>
wrote:

> 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!)
>

Yes, a major reason to prefer did:jwk or a future did:cwk would be to
support signing and encryption outside of the "web", "ssi" or "verifiable
credentials" context...

For more arbitrary use cases, such as protecting CDNs (
https://datatracker.ietf.org/doc/rfc9246/
), Software Bills of Material, Digital Bills of Lading, and `access_token`s.


>
> 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: 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>
>


-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>