silverpill on Nostr: Mike Macgirvin (dev) They were actually talking about changing eddsa-jcs-2022: ...
Mike Macgirvin (dev) (npub1vcv…9su0) They were actually talking about changing eddsa-jcs-2022: https://github.com/digitalbazaar/data-integrity/issues/19#issuecomment-1847297553
>At this point, we should presume the eddsa-jcs-2022 spec is wrong and we should fix it.
I think we have two options:
1. Define new cryptosuite (e.g. eddsa-jcs-2022-fep-8b32) and use it. Switch to eddsa-jcs-2022` once the spec is stabilized
2. Go with eddsa-jcs-2022 and later try to guess what variant of eddsa-jcs-2022 is used. Run verification procedure according to the new spec, and if it fails, run according to the old spec.
(2) is probably easier at this point, no need to change the FEP, and also makes the argument against breaking the spec stronger
>At this point, we should presume the eddsa-jcs-2022 spec is wrong and we should fix it.
I think we have two options:
1. Define new cryptosuite (e.g. eddsa-jcs-2022-fep-8b32) and use it. Switch to eddsa-jcs-2022` once the spec is stabilized
2. Go with eddsa-jcs-2022 and later try to guess what variant of eddsa-jcs-2022 is used. Run verification procedure according to the new spec, and if it fails, run according to the old spec.
(2) is probably easier at this point, no need to change the FEP, and also makes the argument against breaking the spec stronger