search

input-output-hk / prism-did-method-spec

Apache License 2.0
15 stars 1 forks source link

Allowed curves for Verification Method #31

Closed rodolfomiranda closed 1 year ago

rodolfomiranda commented 1 year ago

@EzequielPostan, an initial paragraph says: "the supported verification method type is EcdsaSecp256k1VerificationKey2019 where keys are expressed as JWK. In future versions, more verification method types will be supported."

But later in the document seems that ED25519_CURVE_NAME is also an option. Does that need to be adapted? And for Key Agreement, should we reference X25519 specifically?

EzequielPostan commented 1 year ago

we added Ed25519 curve at request from @lohanspies. The paragraph you quoted needs to be updated, I likely missed it while editing the document

With respect to X25519, I am not aware of the requirements we may need. I can see that X25519 is dependent on Curve25519 which is a different curve from Ed25519. It seems that there is a way to map between the two curves while using the same private key, but I am not sure if we need to support separate curve/keys or not. Could you clarify?

peacekeeper commented 1 year ago

In my experience, while it is possible to map Curve25519 to X25519, this is not always allowed in all environments. We have worked on a use case where security regulations prohibited this kind of key re-use. In our Godiddy platform we have even built a feature that detects such derived keys in DID documents and raises a warning or error: https://docs.godiddy.com/en/advanced/did-resolution

So if X25519 is needed, I think it would be better to add support for that explicitly as a third key type, rather than deriving the keys from Curve25519.

EzequielPostan commented 1 year ago

could you provide me a reference example of a document showing this verification method type in JWK form? I could add the curve name CURVE25519_CURVE_NAME as "curve25519", or should we use "x25519"?

rodolfomiranda commented 1 year ago

I point out X25519 because it is the most common primitive use to encrypt DIDComm messages. It's what the prism agent is using in Peer DID right now, so I'm assuming that you may want to have interop there. @lohanspies ?

rodolfomiranda commented 1 year ago

In JWT the 'cry' field is called X25519. In the DIDDoc normally referred with type "X25519KeyAgreementKey2020". Let me find the Suite document.

EzequielPostan commented 1 year ago

I created a related issue #34 as I see that some examples simply use the same type for all verification method's types, namely JsonWebKey2020

rodolfomiranda commented 1 year ago

Seems that X25519KeyAgreementKey2020 and X25519KeyAgreementKey2020 has no formalized normative, or I just couldn't find them. @peacekeeper you may now better about that. Anyway, I think the JsonWebKey2020 approach is ok. Reference doc https://w3c.github.io/vc-jws-2020/

peacekeeper commented 1 year ago

In the DID Spec Registries we have X25519KeyAgreementKey2019, not X25519KeyAgreementKey2020: https://w3c.github.io/did-spec-registries/#x25519keyagreementkey2019

But I agree we could also use JsonWebKey2020 for all verification methods to simplify things, I could prepare a PR that changes this in the current spec text, and then after that it should be easy to also add X25519.

rodolfomiranda commented 1 year ago

https://w3c.github.io/did-spec-registries/#x25519keyagreementkey2019

and it says: >> ISSUE 164: X25519KeyAgreementKey2019 has no normative definition Normative definition in a suite is required for registration, this entry should be updated or removed.

:(

EzequielPostan commented 1 year ago

thank you for the JsonWebKey2020 PR @peacekeeper I will add the text to support X25519