Closed clehner closed 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
@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.
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?
@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.
@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?
@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
@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?
@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:
https://identity.foundation/EcdsaSecp256k1RecoverySignature2020#EcdsaSecp256k1RecoverySignature2020
https://identity.foundation/EcdsaSecp256k1RecoverySignature2020#EcdsaSecp256k1RecoveryMethod2020
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.
I wonder if we ought too change the IRI base from https://identity.foundation
to https://w3id.org
...
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.