search

w3c / vc-data-model

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

Design choices in expressing a verifiable claim #30

Closed jtibbetts closed 6 years ago

jtibbetts commented 7 years ago

There are a number of design choices needed in expressing a real verifiable claim. I’m working with an IMS group that is designing a VC to represent a college transcript. The questions that are emerging here might very well be generic and could be the basis of normative best practices for the data model document.

The central issue is how skinny or fat should a VC be. For example, the group wants a number of informational fields about the issuer: address, phone, name of issuing person. Should these be included in the VC or is it assumed that they should be gotten by dereferencing the issuer URI?

Arguments in favor of including informational fields embedded in the VC:

  1. The transcript data model can standardize the vocabulary of these fields whereas the “foreign information” in the dereferenced URI might not follow any standardized practices for such vocabulary.
  2. The foreign information isn’t itself verifiable. That is, unless the URI itself points to another VC from the issuer.
  3. Even if the foreign information is signed that signed data might not be synchronized with the claims made about the issuer within the local VC. For example, an issuer might be an institution that had an engineering program at the time the local VC was signed but no longer has such a program.
  4. The VC becomes more readable without needing to dereference anybody. Especially important for disconnected devices.

Arguments against including informational fields embedded in the VC:

  1. Some of the informational data is not critical in the signing. For example, the textual course description might change frequently in minor ways without implying in real change of underlying competencies.
  2. Such an approach violates principles of data normalization that we’ve used for years in database design. (Which BTW may be irrelevant in this context).
  3. “Identity Minimalization” (as stated in the Christoper Allen’s (@ChristopherA) blog post “The Path to Self-Sovereign Identity”) asserts that “When data is disclosed, that disclosure should involve the minimum amount of data necessary to accomplish the task at hand”.

What I think we need are a set of guidelines for what properties is meaningful to include in the VC.

msporny commented 6 years ago

Hey @jtibbetts, trying to address this issue for the VC 1.0 work, which we're trying to wrap up so we can start implementations/test suites.

Should these be included in the VC or is it assumed that they should be gotten by dereferencing the issuer URI?

This is really a design choice that the issuer community should make. The spec contains properties that it thinks are the bare minimum today. If someone wants other properties, we should raise specific issues on those.

What I think we need are a set of guidelines for what properties is meaningful to include in the VC.

The 1.0 spec lists properties that are meaningful to include in the VC. If there are specific properties that the spec is missing, based on input from the issuer community (for example), then the issuer community should suggest additional fields at this time before we wrap up the 1.0 work.

I'm closing this issue as it seems as if the group has consensus over the current set of issuer fields. If new fields are required, a new issue should be opened for the suggested field.