[wbs] response to 'Last Call for Review: Verifiable Credentials Data Model v1.1 Proposed Amendments'

The following answers have been successfully submitted to 'Last Call for
Review: Verifiable Credentials Data Model v1.1 Proposed Amendments'
(Advisory Committee) for Google LLC by Jeffrey Yasskin.

Regarding the "Verifiable Credentials Data Model v1.1" specification, the
reviewer  does not support incorporating the proposed corrections in the
W3C Recommendation for the reasons cited in comments but is not raising a
Formal Objection.


Additional comments about the specification:
   The Verifiable Credentials specification doesn't precisely define how to
interpret the credentials it claims to define. Two of the three changes in
this proposed update to the Recommendation increase the set of inputs that
interoperable implementations must be able to understand, without providing
any more precise definitions of how to understand those inputs. We are
concerned that this makes it more difficult to produce implementations that
actually interoperate. Specifically:

* Correction 2, changing "URL" to "URI", moves from a value that can be
fetched to a value that can't necessarily be fetched. The meaning of these
`id` values is undefined both before and after the change, but it moves
from the possibility of defining a general meaning for the fetched
resource, to a need to define the meaning of particular URIs in a table.
That seems like the wrong direction. The WG could cite
https://url.spec.whatwg.org/ if their goal is simply to provide a normative
definition of the "URL" term.

* Correction 3 loosens normative statements in the zero-knowledge proofs
section. 3.1 moves from requiring a Proof "that can be used" to just
requiring a Proof object and makes a Credential definition optional. 3.2
moves from requiring a `credentialSchema` property to simply requiring that
the credential "contain all information necessary" without defining what
information is necessary or how it should be contained. 3.2 also drops the
requirement that a verifiable presentation prove its claims, without an
explanation of how implementations are supposed to deal with a missing
proof. Like with correction 2, the current Recommendation doesn't
adequately define how implementations should use these fields, so making
them even less precise can't hurt very much, but it again seems like the
wrong direction.

The implementation testing described in
https://w3c.github.io/vc-test-suite/implementations/#testing-methodology is
insufficient for these changes, as it doesn't test that the full set of
values that can be generated for the `id`, `proof`, and `credentialSchema`
properties by one implementation can be understood and used by all the
other conforming implementations.

We expect better from Recommendations and will be looking for better in the
future.

We also note that the tools we currently have for reviewing Proposed
Corrections to Recommendations are inadequate for understanding why the
changes were made. We weren't able to find a PR or issue explaining the
changes in the specification's repository, and the Proposed Corrections
don't link to any discussion thread. This omission in the tools and process
is not the fault of the VC Working Group or this specification's editors.


Answers to this questionnaire can be set and changed at
https://www.w3.org/2002/09/wbs/33280/vc-11-2021-corrections/ until
2022-01-18.

 Regards,

 The Automatic WBS Mailer

Received on Tuesday, 18 January 2022 03:39:04 UTC