Another comment since Manu pointed out that this could complicate the ecosystem further, the suites defined in Verifiable Credential Data Integrity 1.0, have the same issue:
https://www.w3.org/TR/vc-data-integrity/#cryptographic-suites IIRC: "cryptosuite": "eddsa-2022", is actually Ed25519EdDSA "cryptosuite": "eddsa-2025", could be Ed448EdDSA "cryptosuite": "eddsa-2022", is actually ECDSA with secp256r1 "cryptosuite": "eddsa-2025", could be ECDSA with secp384r1 As I understand it, data integrity cryptosuites are fully specified, and even beyond cryptographic dependencies, there is application pre-processing that is fully specified for example: "cryptosuite": "jcs-eddsa-2022", uses JCS, whereas the other suites use RDF Data Set Canonicalization. Of course none of these suites rely on JOSE or COSE algorithm definitions, but since they are new work, and seem to be attempting to provide easy to understand names for fully specified algorithms, perhaps they should also take Neil's advice and omit these algorithm identifiers all together and simple rely on the key type to restrict the algorithm used... His blog post appears to be just as relevant to data integrity as it is to "alg" being mandatory in JOSE headers: https://neilmadden.blog/2018/09/30/key-driven-cryptographic-agility/ Manu, if the draft in question did not make any new registrations, but did provide guidance that reduced debate on naming and captured IETF consensus on how to name suites (as you appear to be doing for data integrity suites in W3C), would that be worth adopting? OS On Mon, Jan 8, 2024 at 8:33 AM Manu Sporny <[email protected]> wrote: > On Mon, Jan 8, 2024 at 4:19 AM Neil Madden <[email protected]> > wrote: > > It’s pretty clear that we’re just talking past each other now. I’ve made > the points I wanted to make. I don’t think you have addressed any of them, > so I still don’t support adoption of this draft. > > I found Neil's concerns compelling. > > For better or worse, JOSE uses "polymorphic" algorithm identifiers and > that's the way things have worked for a long time. The Working Group > was warned that this was not a good idea at the time, but rough > consensus landed in the "polymorphic" camp and that's what the > ecosystem does today. > > Adding more options to support both "polymorphic" and "fully > specified" approaches creates additional complexity that will lead to > interoperability failures. Don't complicate the ecosystem more than it > already is. > > I do not support the adoption of this draft for the reasons Neil > mentioned as well as the reasons stated above. > > -- manu > > -- > Manu Sporny - https://www.linkedin.com/in/manusporny/ > Founder/CEO - Digital Bazaar, Inc. > https://www.digitalbazaar.com/ > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
