[wbs] Response to 'Call for Review: Verifiable Credentials Data Model, Data Integrity, EdDSA and ECDSA Cryptosuites, Credentials using JOSE/COSE, Controlled Identifiers, and Status List are Proposed Recommendations'

The following answers have been successfully submitted to 'Call for Review:
Verifiable Credentials Data Model, Data Integrity, EdDSA and ECDSA
Cryptosuites, Credentials using JOSE/COSE, Controlled Identifiers, and
Status List are Proposed Recommendations' (Advisory Committee) for SPRIND
GmbH by Torsten Lodderstedt.

Answers to this questionnaire can be set and changed until 2025-04-17 at:
  https://www.w3.org/wbs/33280/vc20/

> 
> 
> 
> ---------------------------------
> Decision for Verifiable Credentials Data Model v2.0
> 
> ----
> 
> In case of Formal Objection: Per section 5.5 of the W3C Process
Document
> requiring that a record of each Formal Objection must be publicly
> available, we encourage your organization to make their response public.
> You may do so by setting the visibility of your response to this
> questionnaire to public. If it instead chooses to make it Member-visible,
> or Team-only, and does not provide an alternate public version, the Team
> may make the Formal Objection public without attribution, per section
> 7.3.
> Regarding the Verifiable Credentials Data Model v2.0 specification,
my
> organization:
> 
> 
> 


 * ( ) supports 
publication as a W3C Recommendation as is.
 * ( ) 
suggests changes, but supports publication as a W3C Recommendation

whether or not the changes are adopted (your details below).
 * ( ) does not support publication as a W3C Recommendation for the
reasons
cited in comments but is not raising a Formal Objection (your
details
below).
 * ( ) 
suggests changes, and only supports publication as a Recommendation
if
the changes are adopted [Formal Objection] (your details below).
 * ( ) 
suggests the document not be published as a Recommendation [Formal
Objection]
(your details below).
 * (x) abstains from this review.

Comments: 



> 
> 
> 
> 
> 
> ---------------------------------
> Decision for Verifiable Credential Data Integrity 1.0
> 
> ----
> 
> In case of Formal Objection: Per section 5.5 of the W3C Process
Document
> requiring that a record of each Formal Objection must be publicly
> available, we encourage your organization to make their response public.
> You may do so by setting the visibility of your response to this
> questionnaire to public. If it instead chooses to make it Member-visible,
> or Team-only, and does not provide an alternate public version, the Team
> may make the Formal Objection public without attribution, per section
> 7.3.
> Regarding the Verifiable Credential Data Integrity 1.0
specification, my
> organization:
> 
> 
> 


 * ( ) supports 
publication as a W3C Recommendation as is.
 * ( ) 
suggests changes, but supports publication as a W3C Recommendation

whether or not the changes are adopted (your details below).
 * (x) does not support publication as a W3C Recommendation for the
reasons
cited in comments but is not raising a Formal Objection (your
details
below).
 * ( ) 
suggests changes, and only supports publication as a Recommendation
if
the changes are adopted [Formal Objection] (your details below).
 * ( ) 
suggests the document not be published as a Recommendation [Formal
Objection]
(your details below).
 * ( ) abstains from this review.

Comments: 

In our opinion, one of the lessons learned from XML Signatures was that
complex canonicalization tied to a signature mechanism tends to lead to
complex implementations and a higher likelihood of security
vulnerabilities. Those lessons learned lead to the design of simpler
signature mechanisms like those in JWT/CWT to avoid the complexity of
canonicalization at least when doing cryptographic operations.
We understand
the general appeal of the ideas behind Data Integrity Proofs
but fear that it will lead to overly complex and insecure implementations
by forcing implementations to perform rather complex RDF Dataset
Canonicalization before any basic signature operation (sign, prove, verify)
as is the case for some of the DI Cryptosuites, e.g., the ECDSA one.
Semantics and signature mechanisms should be in their own respective layers
to facilitate robust and secure implementations.

> 
> 
> 
> 
> 
> ---------------------------------
> Decision for Data Integrity EdDSA Cryptosuites v1.0
> 
> ----
> 
> In case of Formal Objection: Per section 5.5 of the W3C Process
Document
> requiring that a record of each Formal Objection must be publicly
> available, we encourage your organization to make their response public.
> You may do so by setting the visibility of your response to this
> questionnaire to public. If it instead chooses to make it Member-visible,
> or Team-only, and does not provide an alternate public version, the Team
> may make the Formal Objection public without attribution, per section
> 7.3.
> Regarding the Data Integrity EdDSA Cryptosuites v1.0 specification,
my
> organization:
> 
> 
> 


 * ( ) supports 
publication as a W3C Recommendation as is.
 * ( ) 
suggests changes, but supports publication as a W3C Recommendation

whether or not the changes are adopted (your details below).
 * ( ) does not support publication as a W3C Recommendation for the
reasons
cited in comments but is not raising a Formal Objection (your
details
below).
 * ( ) 
suggests changes, and only supports publication as a Recommendation
if
the changes are adopted [Formal Objection] (your details below).
 * ( ) 
suggests the document not be published as a Recommendation [Formal
Objection]
(your details below).
 * (x) abstains from this review.

Comments: 



> 
> 
> 
> 
> 
> ---------------------------------
> Decision for Data Integrity ECDSA Cryptosuites v1.0
> 
> ----
> 
> In case of Formal Objection: Per section 5.5 of the W3C Process
Document
> requiring that a record of each Formal Objection must be publicly
> available, we encourage your organization to make their response public.
> You may do so by setting the visibility of your response to this
> questionnaire to public. If it instead chooses to make it Member-visible,
> or Team-only, and does not provide an alternate public version, the Team
> may make the Formal Objection public without attribution, per section
> 7.3.
> Regarding the Data Integrity ECDSA Cryptosuites v1.0 specification,
my
> organization:
> 
> 
> 


 * ( ) supports 
publication as a W3C Recommendation as is.
 * ( ) 
suggests changes, but supports publication as a W3C Recommendation

whether or not the changes are adopted (your details below).
 * ( ) does not support publication as a W3C Recommendation for the
reasons
cited in comments but is not raising a Formal Objection (your
details
below).
 * ( ) 
suggests changes, and only supports publication as a Recommendation
if
the changes are adopted [Formal Objection] (your details below).
 * ( ) 
suggests the document not be published as a Recommendation [Formal
Objection]
(your details below).
 * (x) abstains from this review.

Comments: 



> 
> 
> 
> 
> 
> ---------------------------------
> Decision for Securing Verifiable Credentials using JOSE and COSE
> 
> ----
> 
> In case of Formal Objection: Per section 5.5 of the W3C Process
Document
> requiring that a record of each Formal Objection must be publicly
> available, we encourage your organization to make their response public.
> You may do so by setting the visibility of your response to this
> questionnaire to public. If it instead chooses to make it Member-visible,
> or Team-only, and does not provide an alternate public version, the Team
> may make the Formal Objection public without attribution, per section
> 7.3.
> Regarding the Securing Verifiable Credentials using JOSE and COSE
> specification, my organization:
> 
> 
> 


 * ( ) supports 
publication as a W3C Recommendation as is.
 * ( ) 
suggests changes, but supports publication as a W3C Recommendation

whether or not the changes are adopted (your details below).
 * (x) does not support publication as a W3C Recommendation for the
reasons
cited in comments but is not raising a Formal Objection (your
details
below).
 * ( ) 
suggests changes, and only supports publication as a Recommendation
if
the changes are adopted [Formal Objection] (your details below).
 * ( ) 
suggests the document not be published as a Recommendation [Formal
Objection]
(your details below).
 * ( ) abstains from this review.

Comments: 

The way this specification utilizes SD-JWT is sub-optimal as it double
base64 encodes credentials in order to present them and it is more complex
than needed as it uses SD-JWT as container for the presentation where there
is no need for the SD-JWT capabilities.

> 
> 
> 
> 
> 
> ---------------------------------
> Decision for Controlled Identifiers v1.0
> 
> ----
> 
> In case of Formal Objection: Per section 5.5 of the W3C Process
Document
> requiring that a record of each Formal Objection must be publicly
> available, we encourage your organization to make their response public.
> You may do so by setting the visibility of your response to this
> questionnaire to public. If it instead chooses to make it Member-visible,
> or Team-only, and does not provide an alternate public version, the Team
> may make the Formal Objection public without attribution, per section
> 7.3.
> Regarding the Controlled Identifiers v1.0 specification, my
> organization:
> 
> 
> 


 * ( ) supports 
publication as a W3C Recommendation as is.
 * ( ) 
suggests changes, but supports publication as a W3C Recommendation

whether or not the changes are adopted (your details below).
 * ( ) does not support publication as a W3C Recommendation for the
reasons
cited in comments but is not raising a Formal Objection (your
details
below).
 * ( ) 
suggests changes, and only supports publication as a Recommendation
if
the changes are adopted [Formal Objection] (your details below).
 * ( ) 
suggests the document not be published as a Recommendation [Formal
Objection]
(your details below).
 * (x) abstains from this review.

Comments: 



> 
> 
> 
> 
> 
> ---------------------------------
> Decision for Bitstring Status List v1.0
> 
> ----
> 
> In case of Formal Objection: Per section 5.5 of the W3C Process
Document
> requiring that a record of each Formal Objection must be publicly
> available, we encourage your organization to make their response public.
> You may do so by setting the visibility of your response to this
> questionnaire to public. If it instead chooses to make it Member-visible,
> or Team-only, and does not provide an alternate public version, the Team
> may make the Formal Objection public without attribution, per section
> 7.3.
> Regarding the Bitstring Status List v1.0 specification, my
organization:
> 
> 
> 


 * ( ) supports 
publication as a W3C Recommendation as is.
 * ( ) 
suggests changes, but supports publication as a W3C Recommendation

whether or not the changes are adopted (your details below).
 * ( ) does not support publication as a W3C Recommendation for the
reasons
cited in comments but is not raising a Formal Objection (your
details
below).
 * ( ) 
suggests changes, and only supports publication as a Recommendation
if
the changes are adopted [Formal Objection] (your details below).
 * ( ) 
suggests the document not be published as a Recommendation [Formal
Objection]
(your details below).
 * (x) abstains from this review.

Comments: 



> 
> 
> 
> 
> 
> ---------------------------------
> Usage
> 
> 
> ----
> My organization:
> 
> 


 * [ ] produces products addressed by 
          these specifications
        
 * [ ] expects to produce products conforming to
          these specifications
         (your details below).
 * [ ] expects to produce content conforming to 
          these specifications
         (your details below).
 * [ ] expects to use products conforming to 
          these specifications
         (your details below).
 * [ ] does not expect to produce or use products or content addressed by 
          these specifications
        

Comments: 



> 
> 
> 
> 
> 
> ---------------------------------
> Other Comments
> 
> 
> ----
> Please add here any other comments you have.
> 
> 
Comments: 



> 
> 
> 

--
The Automatic WBS Mailer

Received on Wednesday, 16 April 2025 16:25:45 UTC