-A data integrity proof is designed to be easy to use by developers and therefore -strives to minimize the amount of information one has to remember to generate a -proof. Often, just the [=cryptographic suite=] name (e.g. -`eddsa-rdfc-2022`) is required from developers to initiate the creation of -a proof. These [=cryptographic suite=]s are often created or reviewed by -people that have the requisite cryptographic training to ensure that safe -combinations of cryptographic primitives are used. This section specifies the -requirements for authoring cryptographic suite specifications. +A [=data integrity proof=] is designed to be easy to use by developers and +therefore strives to minimize the amount of information one has to remember to +generate a proof. Often, just the [=cryptographic suite=] name (such as +`eddsa-rdfc-2022`) is required from developers to initiate the creation of a +proof. These [=cryptographic suite=]s are often created and reviewed by people +that have the requisite cryptographic training to ensure that safe combinations +of cryptographic primitives are used. This section specifies the requirements +for authoring cryptographic suite specifications.
@@ -1746,17 +1746,6 @@
-The following language was deemed to be contentious: The specification MUST
-provide a link to an interoperability test report to document which
-implementations are conformant with the cryptographic suite specification.
-
-
-The Working Group is seeking feedback on whether or not this is desired given
-the important role that cryptographic suite specifications play in ensuring
-data integrity.
-