Re: Some potential accessibility-related Verifiable Credentials use cases

CCing Manu on this Jason, recognizing that it but early thoughts from your
end.

I think however you've done a great job fleshing this out, and I think
keeping Manu somewhat in the loop - at least at this time (and with Manu's
permission of course) would make good sense.

Manu, are you interested in continuing to see this thread? Or would you
prefer we (or more accurately, the RQ TF, of which I monitor but rarely if
ever contribute to) all go off and wood-shed, and circle back when we're
ready? I won't indiscriminately CC you any further (I promise).

JF

On Wed, Jan 8, 2020 at 2:52 PM White, Jason J <jjwhite@ets.org> wrote:

> 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.
> ------------------------------
>


-- 
*​John Foliot* | Principal Accessibility Strategist | W3C AC Representative
Deque Systems - Accessibility for Good
deque.com