w3c / vc-data-model

W3C Verifiable Credentials v2.0 Specification
https://w3c.github.io/vc-data-model/
Other
298 stars 106 forks source link

Add a summary text as meta information #248

Closed RieksJ closed 2 years ago

RieksJ commented 6 years ago

When a party in the role of holder uses an app in which to manage his credentials, this app is likely to have functionality that allows the holder to view the credentials that the app manages. Such functionality might benefit from VCs that have a short text that indicates what the VC is about - a 'summary text'.

For example, a credential that some government agency has issued attesting to my being allowed to drive a car, might have Driving license as its summary text.

How about specifying "summary" as a key, similar to "id", "type", etc.

David-Chadwick commented 6 years ago

This is a GUI issue and as such needs to take I18N into account. I think the label that the app attaches to the VC should be determined by the end user when the VC is stored in the app, in just the same way that I can label my different credit cards that are stored by online stores. I use text in my own language that is meaningful to me (and that I can edit whenever I want to). So I would not support the addition of this field to a digitally signed VC.

ChristopherA commented 6 years ago

-1

The issuer signs, not the bearer. Labels are a pet names for the convenience of the bearer. Can be added to graph like any other graph data, but do not belong in the credential, only pointed to.

— Christopher Allen [via iPhone]

On Wed, Oct 10, 2018 at 9:38 AM David Chadwick notifications@github.com wrote:

This is a GUI issue and as such needs to take I18N into account. I think the label that the app attaches to the VC should be determined by the end user when the VC is stored in the app, in just the same way that I can label my different credit cards that are stored by online stores. I use text in my own language that is meaningful to me (and that I can edit whenever I want to). So I would not support the addition of this field to a digitally signed VC.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/vc-data-model/issues/248#issuecomment-428643129, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEN7-2vqCYC7SkNmfTQCumTkq6KjjUAks5ujiKAgaJpZM4XVIqx .

RieksJ commented 6 years ago

In my way of thinking, the number of VCs a holder will need to manage will not be limited to the number of creditcards (and other id-related cards/documents) that people have; rather, they will have to deal with hundreds of them, perhaps even thousands (which could e.g. come to pass when verifiers would issue VCs/attestations for entitlements the holder has such as the right to attend some event, the right to continuously purchase some prescription drug, etc.) If the number of VCs a holder has to manage becomes too large for him to manage manually, (s)he shouldn't be required to type a friendly name for each, but rather be provided with such a friendly name that (s)he may change. Apps might have enough creativity built in to come up with a suggestion for that by themselves. But if VCs are sufficiently different, there may not be an easy way to do so. Allowing issuers to provide a suggestion for that might help here.

Christophers suggestion to put this in graph data is theoretically valid, but practically that's not the case as it still requires apps to find out where such pet-data is in the graph, which will be in different places unless such a thing is standardized.

But ok, perhaps it's a bit too far fetched for now.

msporny commented 6 years ago

@RieksJ has a solid point wrt. having to name 1000s of VCs. @ChristopherA, I do think petnaming should be an option for VCs, but also remember that you can have suggested names (such as by the issuer). For example, the Department of Motor Vehicles in the State of California would most likely want to put a label of "California Driver's License" on their Driver's License credentials. I expect many credential repositories (e.g. digital wallets) will generate a label based on the type of credential and the claims made by the credential and may override the label provided by the issuer.

In any case, I'm a +1 on an issuer being able to provide a human-readable name for their credential. @David-Chadwick, also note that JSON-LD has I18N capabilities, so you can provide labels in a variety of different languages and the UI can choose an appropriate label given the holder's language preferences.

RieksJ commented 6 years ago

Reading up on stuff, I noticed that this might be a simple way to satisfy #42, which says we should consider having something in the data model that specifies how to display a credential in a consistent way, but seems to seek the solution in third party Web Components for displaying VCs. Having a summary would get rid of the associated issues, as it is a simple line of plain text.

stonematt commented 6 years ago

Discussion in TPAC 2018 didn't result in consensus. Deferring to future spec.

wyc commented 3 years ago

Discussed in VC maintenance WG, decided to defer to V2.

iherman commented 3 years ago

The issue was discussed in a meeting on 2021-08-11

View the transcript #### 4.2. Add a summary text as meta information (issue vc-data-model#248) _See github issue [#248](https://github.com/w3c/vc-data-model/issues/248)._ > *Kyle Den Hartog:* Seems like a context change to me, I think we defer to V2 **Wayne Chang:** old issue, about adding summary text to VCs. decided to defer it. Any comments on this? I think deferring to V2 makes sense. > *Dave Longley:* "name" and "description" have been requested already for V2, this is just "description" again **Manu Sporny:** this is definitely V2 as it would result in a context change … other issues ask for short titles and descriptions. > *Kyle Den Hartog:* +1 to this is the same thing as "description **Wayne Chang:** I'll add V2 label now
brentzundel commented 2 years ago

I believe this is addressed by PR #752

RieksJ commented 2 years ago

@brentzundel : that doesn't seem to be the case - see https://github.com/w3c/vc-data-model/pull/752#issuecomment-1196793071

jandrieu commented 2 years ago

This isn't about petnames, which I see as an wallet functionality.

This is about providing guidance for displaying the VC, which includes displaying to the holder before they have a chance to add any particular petname.

TallTed commented 2 years ago

Human friendly naming (which is what I see @RieksJ asking for) will not be a reliable hinting mechanism for tools which automatedly display (info about) VCs.

I think @jandrieu's "guidance for displaying the VC" should be provided via the VC's sub-type (base type being VC), which may be standardized elsewhen, and will have plenty of complication, even just considering Driver's License variations that have been (partially) addressed in the Mobile Driver’s License (mDL) Initiative, which international and other regional variations are all but guaranteed to be present in every other VC subtype.

SHACL, ShEx, and similar efforts have been used for such automated display guidance elsewhere, and may yet be considered to play such a part for VCs.

iherman commented 2 years ago

The issue was discussed in a meeting on 2022-07-27

View the transcript #### 5.3. Add a summary text as meta information (issue vc-data-model#248) _See github issue [vc-data-model#248](https://github.com/w3c/vc-data-model/issues/248)._ **Brent Zundel:** This has received some back and forth alongside another PR. … The proposal here is that we add some summary text/meta info that would allow the issuer or the holder to indicate "this is what this credential is about". … A 'summary property' could be useful. … I suggested that PR752 addressed this, but it seems not. > *Manu Sporny:* +1 to PR that tplooker raised as addressing this.. **Brent Zundel:** There some folks on the call who raised comments.... **Manu Sporny:** My understanding of Tobias's proposal is to add name and description. _See github pull request [vc-data-model#752](https://github.com/w3c/vc-data-model/pull/752)._ **Manu Sporny:** I'd say the description is the summary. … Do we need name, description and summary?. … There are some preliminary proposals for rendering. … if we can't describe the difference between summary and description then go with tplooker. **Ted Thibodeau Jr.:** It seems the me the issuer will have no idea what pet name the holder may use. … The pet name might go into an envelope that contains the credential but that's not within the VC. > *Manu Sporny:* -1 to petnames in VCs... associated metadata, fine, but that's a Holder preference.. **Ivan Herman:** That was a bit of a discussion on the pull request, not the issue. … Are these additional metadata things to be signed/normalised?. > *Manu Sporny:* -1 for "bag of metadata" :) -- like, we have a mechanism for semantics... let's use those.. **Ivan Herman:** That's relevant because one way is to define a bunch of properties. The other way is to say there is a single metadata property that points to a bunch of stuff that is not part of the credential. … Personally I'd prefer to separate the metadata from the core set of statements, but we have to decide on that. > *Tobias Looker:* yeah I agree with manu. **Ivan Herman:** If you don't want to sign it then it's separate. **Brent Zundel:** No time for all comments here. Please add your comments to the issue (not the PR). **Tobias Looker:** The original proposal is to add name and description. I see description and summary as synonyms.. … The other clarification - it is proof format-specific, but it's issuer-signed. … I don't think that stops a wallet also assigning a pet name. **Kristina Yasuda:** Thanks everyone. > *Manu Sporny:* +1 to what tplooker just said.. **Kristina Yasuda:** We're running out of time, so DavidC, JoeAndrieu oliver please comment on the issue.. … Sorry we're over time. ---
msporny commented 2 years ago

The Verifiable Credential "name" and "description" properties were added in https://github.com/w3c/vc-data-model/commit/d82b52a889df934300451ce922ee78b83407162e. Closing as resolved.