w3c-ccg / security-vocab

The Linked Data Security Vocabulary
https://w3id.org/security
Other
21 stars 21 forks source link

Add EcdsaSecp256k1RecoverySignature2020 #95

Closed clehner closed 3 years ago

clehner commented 3 years ago

And EcdsaSecp256k1RecoveryMethod2020.

Specification: https://identity.foundation/EcdsaSecp256k1RecoverySignature2020/ https://github.com/decentralized-identity/EcdsaSecp256k1RecoverySignature2020

Cryptographic suite registered: https://w3c-ccg.github.io/ld-cryptosuite-registry/#ecdsasecp256k1recoverysignature2020 https://w3c-ccg.github.io/ld-cryptosuite-registry/#ecdsasecp256k1recoverymethod2020

DID verification method type registered: https://www.w3.org/TR/did-spec-registries/#ecdsasecp256k1recoverymethod2020

For the JSON-LD context, I did not use the context file or IRIs from the specification, but instead copied what is already here for JsonWebKey2020/JsonWebSignature2020, defining new IRIs under the security context.

OR13 commented 3 years ago

I suggest only adding https://w3id.org/#EcdsaSecp256k1RecoverySignature2020 to the html so its documented here and then setup a on w3id.org to an context file for just that suite as manu mentioned.

examples: https://github.com/perma-id/w3id.org/pulls?q=is%3Apr+author%3AOR13+is%3Aclosed

OR13 commented 3 years ago

@msporny @dlongley how will we handle jsonld-signatures without sec-v3 or similar, do you think folks will just document all the contexts their libraries support?

I agree with we should make it possible for folks to pull only what they need, but we should also make it easy to implement VCs and LD Proofs and I'm not sure how you plan to move beyond sec-v2 in your libraries....

I would suggest that we keep using kitchen sinks for that... but that they load each of the suites your tooling supports... I know I argued against that with @kdenhartog but I think its the only way to make those tools reasonable.

msporny commented 3 years ago

I would suggest that we keep using kitchen sinks for that...

Yes, you raise a good point... which is that we want an easy on-ramp for people using this technology... and kitchen sinks certainly help there. My concern is that those kitchen sinks keep being used in production (and they will).

I'm torn on this one... will try to think about it more over the coming week. Maybe kitchen sink approach isn't as bad if we cull it aggressively from version to version?

OR13 commented 3 years ago

@msporny I think this is not actually a big deal.

sec-v3 ~= module/version/3/index.js

all it should do is export the suites and terms that v3 supports... from their respective contexts.

At some point in the future everyone will upgrade from sec-v2 to sec-v3... and hopefully nothing breaks....

The more often we as a community do this, they more confident we are in JSON-LD Signatures.

Developers need to know which version of credentials they support and which version of ld signatures they support.

We should make this very clear.

dlongley commented 3 years ago

@dmitrizagidulin,

Do you mind chiming in here on @OR13's question (quoted below) -- based on what we've been doing with the latest updates to jsigs and related suites and what the plan is there?

how will we handle jsonld-signatures without sec-v3 or similar, do you think folks will just document all the contexts their libraries support?

clehner commented 3 years ago

@OR13 @msporny @dlongley Thanks for the pointers.

I've removed the changes to the security context file. I also reverted to using the original type IRIs defined in the suite specification, for consistency with existing usage and as it is in did-spec-registries.

I also opened a PR to add a redirect for w3id.org/security/suites/secp256k1recovery-2020/v1 to the existing JSON-LD context file, although I am not sure if this is still needed: https://github.com/perma-id/w3id.org/pull/2108

msporny commented 3 years ago

@clehner I'm seeing merge conflicts on this PR, can you please rebase?

@clehner, after that, are we good to merge -- have all concerns been addressed?

clehner commented 3 years ago

@msporny Rebased.

There are still issues with the JSON-LD context, but this PR no longer adds or references JSON-LD context, only the following terms:

The JSON-LD context previously proposed and commented on in this PR has been dropped, but the discussion here should inform a next version of the context file in the specification repo.

OR13 commented 3 years ago

I wonder if we ought too change the IRI base from https://identity.foundation to https://w3id.org...

related: https://github.com/perma-id/w3id.org/pull/2153