Orie Steele
Orie Steele
How can I help to address this concern?
yes, i have also struggled with this.... I agree with the proposed approach: define a table, include the public key bytes, public key kty / crv, multicodec prefix, base58 encoding....
Thats correct, you may also be interested in https://github.com/decentralized-identity/did-jose-extensions
Also possibly this: https://github.com/transmute-industries/did-key.js/blob/master/packages/secp256k1/src/ES256K.test.ts
IMO the use of id fields such as `#key-1` is a bad practice, we should be encouraging the use of compound identifiers, such as `${did}#key-${kid}` where kid is generated according...
^ apparently commenting unassigned @alundeen, i'm not able to reassign.
Related spec conversation regarding supported public key formats: https://github.com/w3c/did-spec/issues/67 My preference is for the following structure: ``` { "id": "did:btcr:xxcl-lzpq-q83a-0d5#key-JUvpllMEYUZ2joO59UNui_XYDqxVqiFLLAJ8klWuPBw", "type": "EcdsaSecp256k1VerificationKey2019", "publicKeyJwk": { "crv": "secp256k1", "kid": "JUvpllMEYUZ2joO59UNui_XYDqxVqiFLLAJ8klWuPBw", "kty": "EC",...
Also related DIDComm thread on JWE format and kid interop: https://github.com/decentralized-identity/DIDComm-js/issues/8
What is blocking this PR from getting merged? I suggest we use the CR tools on github and request changes or approve them.
There is also this library https://www.npmjs.com/package/chloride Which may not help, just pointing it out here.