search

w3c / vc-data-model

W3C Verifiable Credentials Working Group — VC Data Model and Representations specification
https://w3c.github.io/vc-data-model/
Other
285 stars 99 forks source link

Verification algorithm drops an input map on the floor #1518

Closed jyasskin closed 4 days ago

jyasskin commented 2 weeks ago

https://w3c.github.io/vc-data-model/#verification says

This algorithm takes inputs of a media type (string inputMediaType) paired with either a sequence of bytes (byte sequence inputBytes) or a document (map inputDocument)

But inputDocument is never mentioned again in the rest of the algorithm.

msporny commented 2 weeks ago

Yeah, we'll have to clean that up. There was an implementer comment that noted that they allowed input documents as well as input bytes and wanted that to be highlighted in the algorithm (to make sure people knew that it's fine to pass in either and libraries could deal with either).

The challenge here is that the algorithms can be implemented in any way that a developer would like to implement them (as long as the final result is the same). I'm not sure we need to document every variation, but at the same time, some developers are concerned that their implementation will be viewed as "non-conforming" if they don't follow the algorithms closely.

I'll try to see how we can balance the two desires with the spec text.

jyasskin commented 2 weeks ago

Thinking about how to express that concern in the spec ... it's the application as a whole that'd be conforming or not, but you're right that it's useful for libraries to be able to say "call me to make your application conform to VC." You could have the first step be 

1. Let _inputDocument_ be the result of [=parsing JSON bytes to an Infra value=] given _inputBytes_.

    Note: Libraries that implement this specification might leave this step to the calling application.

(I considered making that a normative "Libraries ... may ...", but you don't have a conformance class for libraries.)

msporny commented 1 week ago

PR #1523 has been raised to address this issue. This issue will be closed once PR #1523 has been merged.

msporny commented 4 days ago

PR #1523 has been merged, closing.