Re: A node.js did:jwk implementation

I can see supporting this over DID Key, and I'll have our folks take a look
to potentially pull it in.

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

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