Open brentzundel opened 2 years ago
The issue was discussed in a meeting on 2022-01-26
I volunteered last week to help scope or specify the requirements here, but I have to cry uncle and request additional assistance because I'm having even more trouble than Charles understanding the scope of
the full set of values that can be generated for the
id
,proof
, andcredentialSchema
properties
Which of the following need to be included in the test vectors to say we have fully addressed this?
A.) How many of the following have to be represented as valid (positive-case) values for a top-level id
property:
urn:uuid:
?B.) Does the [optional] credentialStatus
section of the test suite have to cover the same exhaustive range of options for credentialSchema.id
?
C.) As discussed on today's call, it seems that the requirements of refreshService.id
are determined by refreshService.type
- so the behavior of a consuming party as to refreshService.id
seems to me untestable without a normative reference as to how one or more specific types further constrain refreshService.id
.
D.) As for the proof
section, this seems even harder to define vectors for, since these vary even more depending on proof.type
. Changes 3.1 and 3.2 make this even more the case than before, but as the NOTE under example 25 already stated explicitly, the ZKP section does not specify how to evaluate or parse a ZKP VP normatively. Am I wrong in concluding that the only two normative statements it makes can't be evaluated by this test suite alone?
The issue was discussed in a meeting on 2022-02-02
The above discussion matches my impression that this probably can't be fixed before 2.0. The large number of 'MAY' constraints add up to a spec that says that interoperability might or might not be achieved between the actual implementations. Since the purpose of a REC is to ensure that implementations are interoperable, that's a problem. But it's not a problem we expect you to be able to fix under the current charter.
I agree that the bulk of the changes mentioned in this thread will need to happen in the next WG under v2.0.
My question to @msporny @clehner @bumblefudge: has the test suite been updated to reflect the normative corrections we made in v1.1? If not, imo that is the scope of work that needs to be undertaken at this point.
has the test suite been updated to reflect the normative corrections we made in v1.1
Two PRs are open for this: #123 for the URL/URI changes, and #127 for the ZKP changes. The test suite still refers to VC Data Model 1.0 though - e.g. the test directory name test/vc-data-model-1.0. Should a new copy be made for 1.1, or the current one renamed in-place?
I agree it looks like a change in methodology may be needed to test a greater range of values. The tests focus on required properties. We have changes where some properties used to be required and are now optional - or may be required in some situations, such as with proof properties - or may be required depending on the object type. Maybe these should have new tests added, to ensure that the omission of those properties is allowed where relevant?
The issue was discussed in a meeting on 2022-02-09
The issue was discussed in a meeting on 2022-02-16
The issue was discussed in a meeting on 2022-02-23
@jyasskin I've raised this issue to track the WG response to the feedback you provided on the test suite and to track the work required to address the limitations you've uncovered.
From feedback on VC Data Model v1.1
@clehner has volunteered to work on this, but assistance from others is also welcome.