RE: Verifiable credentials - wiki page updated

I have now updated the “accessibility conformance claims” example to note the interesting issues raised at the meeting today. See
https://www.w3.org/WAI/APA/task-forces/research-questions/wiki/Some_use_cases_for_verifiable_credentials#Asserting_Conformance_to_Accessibility_Standards


I also clarified the “needs and preferences” use case. Importantly, I tried to respond to the issue that Janina thoughtfully raised last week about whether individual needs/preferences are sufficiently persistent to be appropriate for capturing in Verifiable Credentials.

I briefly consulted a paper on GPII:
Iglesias-Pérez, A., Loitsch, C., Kaklanis, N., Votis, K., Stiegler, A., Kalogirou, K., ... & Weber, G. (2014, June). Accessibility through preferences: context-aware recommender of settings. In International Conference on Universal Access in Human-Computer Interaction (pp. 224-235). Springer, Cham.

As I read it, the contextual dependencies (e.g., on ambient lighting and noise conditions) that vary over time are handled in the software that maps a user’s preferences to the settings supported by operating systems, applications, and assistive technologies. The contextual dependencies do not actually change the preferences themselves – at least, that seems to be the general case. The matchmaking process applies rules or statistical techniques to convert users’ preferences to the context-specific settings which are then automatically configured in the operating system, assistive technology, browser, application, etc.

It therefore seems to me that (at least in a GPII-like scenario) there is a persistent set of needs/preferences that doesn’t change as the user moves between different devices or different environmental conditions.

I’ve tried to capture this in a brief note on the wiki page. Improvements to the note would of course be welcome. The underlying thought is that Verifiable Credentials would only be an appropriate technology if there is a persistent set of needs/preferences associated with the user, which would only be changed at the user’s discretion.

The next stage of working on this topic is for us to add any further use cases that come to mind, and to prioritize those which are already documented.

Two of our use cases (service animals, and verification of disability status) would involve governments, presumably raising regulatory and implementation issues. Indeed, “service animals” would require international cooperation. They’re both very good examples of how Verifiable Credentials could be used, but probably not good candidates for quick implementation – if that’s what the Verifiable Credentials community is seeking. Perhaps there are non-governmental uses for verification of disability status that are persuasive; opinions are of course welcome. An example might be a library or an educational institution that requires proof of disability status as a condition of providing some disability-related services. Obviously, requiring disclosure of disability status legitimately raises concerns about ethics and policy – and not just those related to privacy. For this reason, I’m don’t feel comfortable recommending this kind of use case as among our highest-priority, most compelling examples.

I think the privacy-preserving attestation that a user is human (i.e., the alternative to a CAPTCHA challenge) is interesting. However, it isn’t clear to me whether Verifiable Credentials can achieve it – and, if they can, with what level of privacy for the user. I expect the assertion that I am a person would ultimately need to be grounded in a credential that I can only acquire by proving my identity, and hence that I am human, to the issuer. For example, a government-issued ID would be a good basis. Then the assertion of personhood would need to be made without revealing my name or other identifying information, if we want to support anonymity. How feasible is this application? Can the privacy-preserving techniques put forward for use with Verifiable Credentials support this use case?

I agree with Janina that the ”individual needs and preferences” use case is rather atypical for Verifiable Credentials. I think we should give further thought to the issue of how appropriate this technology is for such applications. There is a wider architectural question here of which mechanisms (especially, which Web technologies) are appropriate for conveying needs/preferences to systems that can respond to them. As discussed above, I have tried to address some of the issues in the text already.

Let’s discuss these issues further on the mailing list and at the next meeting.

From: White, Jason J
Sent: Tuesday, February 4, 2020 4:42 PM
To: RQTF <public-rqtf@w3.org>
Subject: Verifiable credentials - wiki page updated

I’ve made some changes to the wiki page, while adding a few more use cases that we’ve discussed at meetings.

Additional changes, suggestions and use cases are most welcome. I think we’re still in the use case gathering phase, prior to prioritization and refinement. This topic is included in the meeting agenda for tomorrow.

https://www.w3.org/WAI/APA/task-forces/research-questions/wiki/Some_use_cases_for_verifiable_credentials



________________________________

This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.


Thank you for your compliance.

________________________________