Re: Some potential accessibility-related Verifiable Credentials use cases

White, Jason J wrote on 09/01/2020 15:00:
> Here's an introductory article on zero-knowledge proofs, which can be used with Verifiable Credentials:
> https://www.wired.com/story/zero-knowledge-proofs/
Thanks for that Jason. It's synchronous for me, as I have been thinking 
today of ways of sending randomised fragments of data, to verify 
personalisation requests (or indeed other settings and data).

Josh

>
> -----Original Message-----
> From: White, Jason J <jjwhite@ets.org>
> Sent: Thursday, January 9, 2020 9:46 AM
> To: Janina Sajka <janina@rednote.net>
> Cc: RQTF <public-rqtf@w3.org>
> Subject: RE: Some potential accessibility-related Verifiable Credentials use cases
>
> I have revised and renamed the wiki page in view of our discussion of Verifiable Credentials - now available at
> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FWAI%2FAPA%2Ftask-forces%2Fresearch-questions%2Fwiki%2FSome_use_cases_for_verifiable_credentials&amp;data=02%7C01%7Cjjwhite%40ets.org%7C0700ae57f8ea4707ce9c08d79512a716%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C637141779678439965&amp;sdata=YX2n8H6ozTVD5onLDzT9x6059aCl4xsYI3%2BDSsq2I4Q%3D&amp;reserved=0
>
> I plan to add some of the other ideas considered in this conversation.
>
> -----Original Message-----
> From: White, Jason J <jjwhite@ets.org>
> Sent: Thursday, January 9, 2020 8:04 AM
> To: Janina Sajka <janina@rednote.net>
> Cc: RQTF <public-rqtf@w3.org>
> Subject: Re: Some potential accessibility-related Verifiable Credentials use cases
>
> Thank you, Janina, for the informative comments.
>
> One way of introducing the more complex scenario is to treat it as a combination of (1) accessibility metadata provided by the application, and (2) an accessibility preference assertion made by the user - verifiably. That is, it represents a combination of simpler use cases that we already describe.
>
> On 1/9/20, 04:36, "Janina Sajka" <janina@rednote.net> wrote:
>
>      Jason:
>
>      This one is a great idea, but possibly more complicated to implement.
>
>      I think one of our early filters should be the low hanging fruit. Let's
>      put forward ones we believe are trivial to implement yet showcase real
>      value. The AAC symbols translation coming out of Personalization TF is
>      one such. People see it and get it. During TPAC last, Lisa Seeman
>      demonstrated such with a Chrome plugin over a Webex connection and
>      inspired a Mozilla developer present in the room to implement the same
>      for Firefox.
>
>      I think we want to start with that kind of impact. I think VC and DID
>      will appreciate that kind of impact, because they're selling their ideas
>      to the wider industry as well.
>
>      Of course, we should keep collecting, so your negotiated suggestion
>      below is excellent. I just don't think it's rev 1 for reasons cited.
>
>      Janina
>
>      White, Jason J writes:
>      > Just a related question to consider at the meeting: for the accessibility needs/preferences use case, is there a good argument for a two-way verification? As a user, I want (1) to know which needs/preferences a given Web-based application responds to, so that I don’t disclose more of my “profile” to this application than necessary, and (2) some assurance – perhaps even from a third party – that the application is likely to preserve the privacy of whatever preferences I disclose.
>      >
>      > Thus, perhaps there is a good reason for some level of verification on both sides, though, obviously, it shouldn’t be more elaborate than necessary.
>      >
>      > From: White, Jason J <jjwhite@ets.org>
>      > Sent: Wednesday, January 8, 2020 3:52 PM
>      > To: RQTF <public-rqtf@w3.org>
>      > Subject: Some potential accessibility-related Verifiable Credentials use cases
>      >
>      > To start the discussion that we plan to continue on the mailing list and at the next task Force meeting, here are some initial ideas regarding potential use cases of Verifiable Credentials.
>      >
>      > An alternative to CAPTCHA: I am wondering whether this is easier than Janina or I thought. If I have a verifiable credential (e.g., government-issued ID, qualification from an educational institution, etc.), and a Web site that I wish to access has a list of trusted credential issuers as well as the ability to make a verification, wouldn’t this be sufficient to establish personhood – as long as the same identifier is used both to access the Web resource and in the credential?
>      >
>      > A fundamental capability of Verifiable Credentials is the capacity to preserve privacy by only revealing necessary aspects of a credential to a verifier. This privacy feature would seem useful in this use case, as it might allow details such as the person’s name to be suppressed, maintaining anonymity.
>      >
>      > Individual user accessibility need/preference profiles: This series of use cases was discussed again at the APA meeting today. I would be interested in understanding the implications of these use cases for privacy and the ways in which the features of Verifiable Credentials could be used to minimize disclosure of personal information to services that adapt to a user’s preferences.
>      >
>      > Janina rightly noted that these use cases extend beyond Web applications to include, for example, payment scenarios. I suppose one could also convey accessibility-related preferences to transport providers, mapping applications, and in other contexts in which the user interface of the application isn’t necessarily affected, but aspects of the service it offers adapt to the user’s needs.
>      >
>      > Verification of disability status: this was also discussed at the meeting. Such verification is often required to obtain government benefits designed to overcome disadvantages incurred by people with disabilities, but it isn’t exclusive to governments, in that other organizations could make use of it as well. Obviously, it has very considerable privacy implications, and, to my mind, it is a very different set of use cases from need/preference profiles. The main difference is that needs/preferences don’t make any claim about a person’s having a disability (even though this can be inferred in some cases with reasonable probability), whereas attestation of disability status obviously does involve this assertion.
>      >
>      > Assertion of accessibility standards conformance: the credential issuer claims that an entity (e.g., Web page/application, set of Web pages, etc.) satisfies the conformance requirements of a specified accessibility standard/specification.
>      >
>      > More generally – accessibility metadata: the credential issuer verifiably asserts that a resource has specified accessibility-related properties, using metadata designed for this purpose.
>      >
>      > Service provider qualifications: this is a straightforward application of the technology, in which credentials are issued to individuals or organizations that offer services related to disability.
>      >
>      > Further examples, and refinements of the above, are most welcome.
>      >
>      >
>      > ________________________________
>      >
>      > 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.
>      >
>      > ________________________________
>      >
>      > ________________________________
>      >
>      > 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.
>      >
>      > ________________________________
>
>      --
>
>      Janina Sajka
>
>      Linux Foundation Fellow
>      Executive Chair, Accessibility Workgroup:https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fa11y.org&amp;data=02%7C01%7Cjjwhite%40ets.org%7C31f6860aa08c4329052a08d794e76589%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C637141593876219656&amp;sdata=aCc7pRIGo2g9r6t2Ey1NYV16e%2FK1W2kuoCyYRLvLWvE%3D&amp;reserved=0
>
>      The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
>      Chair, Accessible Platform Architectureshttps://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%2Fwai%2Fapa&amp;data=02%7C01%7Cjjwhite%40ets.org%7C31f6860aa08c4329052a08d794e76589%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C637141593876219656&amp;sdata=87zxm3OwThnHRONfKxavKIQrKTI1UnxVZU2YV4yUI%2FM%3D&amp;reserved=0
>
>
>
>
> ________________________________
>
> 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.
>
> ________________________________
>
> ________________________________
>
> 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.
>
> ________________________________
>
> ________________________________
>
> 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.
>
> ________________________________


-- 
Emerging Web Technology Specialist/Accessibility (WAI/W3C)

Received on Thursday, 9 January 2020 15:51:44 UTC