Remove the outdated portions...

[iherman]

It is the first time I look at this document and it made me realize (unless I miss something) that half of this document is outdated. The way I understand this document is that

• in §2:
  • the Ed25519VerificationKey2020 is meant to be replaced by Multikey
  • the Ed25519Signature2020 proof format is meant to be replaced by DataIntegrityProof plus an extra value of "cryptosuite":"eddsa-2022"
• in §3:
  • Ed25519Signature2020 meant to be replaced by eddsa-2022

In other words, editorially, the sections 2.1.2, 2.2.2, and 3.2 should be removed (and probably a new informative section should be added with some history, referring to those sections as deprecated).

This is, at least I read the text: these sections are, mostly, word-by-word identical, except with the appearance and usage of the cryptosuite property.

If I am right, I would also suggest that the title of the document is also a misnomer, and should either refer to 2022 (and not 2020) or remove the year reference altogether.

If all this is true, I believe this should be done asap. At this moment, for any reader who has not been part of the original development this document is extremely confusing, unclear; we should definitely not publish this document in its present form as a FPWD.

[msporny]

It is the first time I look at this document and it made me realize (unless I miss something) that half of this document is outdated.

You're missing something :), namely, Ed25519Signature2020 and Ed25519VerificationKey2020 have escaped into the wild in at least one large scale production system. That system is TruAge, which is in the process of being deployed to the retail, grocery, and restaurant industry in the US -- 150,000+ retail locations, 50M+ age checks per day, thousands of retailers, many different point of sale systems, etc.). We documented the implementations that have implemented (or plan to implement) Ed25519Signature2020 here:

https://lists.w3.org/Archives/Public/public-vc-wg/2023Jan/0027.html

So, the approach taken here is to document it's usage in a normative way (we can already demonstrate multiple interoperable implementations), and then mark it as deprecated (with a strong suggestion that everyone moves to eddsa-2022).

• the Ed25519VerificationKey2020 is meant to be replaced by Multikey

Yes, new deployments and implementations should use Multikey.

• the Ed25519Signature2020 proof format is meant to be replaced by DataIntegrityProof plus an extra value of "cryptosuite":"eddsa-2022"

Yes, new deployments and implementations should use DataIntegrityProof and cryptosuite.

• Ed25519Signature2020 meant to be replaced by eddsa-2022

Yes new deployments should use "cryptosuite": "eddsa-2022".

In other words, editorially, the sections 2.1.2, 2.2.2, and 3.2 should be removed (and probably a new informative section should be added with some history, referring to those sections as deprecated).

No, definitely not removed and/or be made informative. We might want to move them to a section titled "Deprecated algorithms and key formats", just so we have a REC that documents the reality of the deployment.

If I am right, I would also suggest that the title of the document is also a misnomer, and should either refer to 2022 (and not 2020) or remove the year reference altogether.

Yes, we should probably re-version the spec to v2022, but it should include the "2020" version of the cryptosuite (for the reasons mentioned above).

If all this is true, I believe this should be done asap. At this moment, for any reader who has not been part of the original development this document is extremely confusing, unclear; we should definitely not publish this document in its present form as a FPWD.

Hope the above clarifies the intent.

We could put some language in the FPWD noting that Ed25519Signature2020 is being published to document production usage, but new deployments and implementations should use eddsa-2022, would that work for you?

[iherman]

Thanks for your answer, @msporny

I understand the background and that we have to "navigate" cautiously. I am therefore not objecting against the publication as a FPWD but I still believe we need some more radical surgery on the document at some stage.

What about pushing Ed25519Signature2020 as a normative appendix, making it clear that it is deprecated but, if used, here is the way it MUST be used? Adding to that appendix text that new implementations should use eddsa-2022. At the moment, the two are presented side-by-side on equal ground, so to say, and that, I feel, is misleading.

Again, I am fine to do that post-FPWD if you feel we are running out of time.

[msporny]

@iherman wrote:

What about pushing Ed25519Signature2020 as a normative appendix, making it clear that it is deprecated but, if used, here is the way it MUST be used? Adding to that appendix text that new implementations should use eddsa-2022. At the moment, the two are presented side-by-side on equal ground, so to say, and that, I feel, is misleading.

Yes, that feels like the right path forward. The only part that concerns me a bit is the "normative appendix" part, but then again, there is nothing in W3C Process that says "Appendices can't be normative" :)

[iherman]

@iherman wrote:

What about pushing Ed25519Signature2020 as a normative appendix, making it clear that it is deprecated but, if used, here is the way it MUST be used? Adding to that appendix text that new implementations should use eddsa-2022. At the moment, the two are presented side-by-side on equal ground, so to say, and that, I feel, is misleading.

Yes, that feels like the right path forward. The only part that concerns me a bit is the "normative appendix" part, but then again, there is nothing in W3C Process that says "Appendices can't be normative" :)

Exactly. Formally, most sections are normative unless stated otherwise (exception is, for example, the abstract section).

One thing that may be wise to change before FPWD is the title of the document. Although the short name will not change, and that is what identifies a document within the W3C ecosystem, changing title once published may create some minor issues here and there.

[msporny]

@iherman wrote:

One thing that may be wise to change before FPWD is the title of the document. Although the short name will not change, and that is what identifies a document within the W3C ecosystem, changing title once published may create some minor issues here and there.

Ok, I'll update it to v2022.

[iherman]

@iherman wrote:

One thing that may be wise to change before FPWD is the title of the document. Although the short name will not change, and that is what identifies a document within the W3C ecosystem, changing title once published may create some minor issues here and there.

Ok, I'll update it to v2022.

@msporny I had to send out all the necessary publication requests, preliminary check requests, etc, to make it sure that the decision will be taken tomorrow. What I did is that I have changed the the title from v2020 to v2022, but only on the copy that I have put on the W3C TR. I have not touched the repository; I let you do that...

[msporny]

@msporny I had to send out all the necessary publication requests, preliminary check requests, etc, to make it sure that the decision will be taken tomorrow.

Thank you!

What I did is that I have changed the the title from v2020 to v2022, but only on the copy that I have put on the W3C TR. I have not touched the repository; I let you do that...

Fixed in 31eaa07