-
Notifications
You must be signed in to change notification settings - Fork 87
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Request] Support JWK
& JWS
representation and secp256r1
& secp256k1
encryption
#939
Comments
JWK
& JWS representation and secp256r1 & secp256k1 encryption
JWK
& JWS representation and secp256r1 & secp256k1 encryptionJWK
& JWS
representation and secp256r1
& secp256k1
encryption
It is unlikely that we will be able to add full We will, however, look into allowing arbitrary verification method types and public key material (including Would you require the top-level signature/proof on published DID Documents to use those methods too, as opposed to Ed25519+JCS? |
Yes.
Why would Stronghold need to support this as well? |
For secure key management and operations, Stronghold has to expose the cryptographic operations required for us to call via the It probably won't affect you if you're using specialised hardware and not going through Stronghold or the
I speak for myself but I would be opposed to changing the protocol to support both Ed25519 and secp256*/JWS for the DID Document itself, since that affects the DID tag identifier (which is derived from the public key). Supporting them in verification methods for encrypting/signing/verifying external data is far simpler as it would not require changing the DID method specification. |
That makes sense, thank you 👍 |
I agree, changing the top-level proof would change the DID method quite significantly, while also making backwards- and forwards-compatibility difficult. |
General cryptographic agility is now tracked in #1037. |
Description
Add support for
JWK
&JWS
representations as well assecp256r1
&secp256k1
encryption and verification.Motivation
We parse DID Documents and VCs byte-wise in hardware. In order for our hardware to be compatible with identity.rs, we need to be able to represent keys as
JWK
/JWS
instead ofJCS
, and to encrypt/verify usingsecp256r1
&secp256k1
.Note that all of this is of course supported by the W3C DID/VC Standards.
Requirements
Encoding types
JWK
(JSON Web Key) for keys. In e.g. DID Documents, this representation would look like this instead of e.g. this.JWS
(JSON Web Signature) for signatures (within e.g.proof
fields), e.g. thisEncryption types
secp256r1
akaP-256
secp256k1
Are you planning to do it yourself in a pull request?
No, as of now.
The text was updated successfully, but these errors were encountered: