Closed RieksJ closed 2 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.
-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 .
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.
@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.
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.
Discussion in TPAC 2018 didn't result in consensus. Deferring to future spec.
Discussed in VC maintenance WG, decided to defer to V2.
The issue was discussed in a meeting on 2021-08-11
I believe this is addressed by PR #752
@brentzundel : that doesn't seem to be the case - see https://github.com/w3c/vc-data-model/pull/752#issuecomment-1196793071
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.
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.
The issue was discussed in a meeting on 2022-07-27
The Verifiable Credential "name" and "description" properties were added in https://github.com/w3c/vc-data-model/commit/d82b52a889df934300451ce922ee78b83407162e. Closing as resolved.
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.