Re: Call for Focal DID Use Cases

Joe, thanks for reminding me that a good use-case should be about value
creation and human experience rather than DID or some other tech. Here is
my attempt:

*Name *-- *A pithy name that captures the relevance of the use case*
A Prescription for Alice

*Background *-- *A sentence or three capturing current state of practice,
the motivation, and the value it creates*
Alice wants help with her urinary tract infection (UTI) and is a bit touchy
about her privacy. In the old days, she would have to make an appointment
in-person and get a paper prescription to take to a pharmacy. She wants to
save money and have peace of mind.

*Description *-- *A paragraph capturing the core action of the use case:
what people do*
Because she lives in Seattle, Alice is in a state that allows Planned
Parenthood to diagnose and prescribe online https://www.plannedparenthood.
org/get-care/get-care-online . Alice uses the identity wallet on her iPhone
to register with the online medical practice. She tells
<https://www.youtube.com/watch?v=N7lMxNfb7rw> the online practice her name
is Althea with password-less authentication and a verified driver's license
credential to prove that she's a WA resident. The remote physician, Bob, is
licensed by the WA Board of Medicine and credentialed by Planned Parenthood
of WA, Inc. He's securely signed in using the identity wallet on his
smartphone. Bob issues Alice a digital prescription in the form of a
verifiable credential and allows Alice to download it however she pleases.
Alice is a librarian and trusts her local public library to erase their
logs as allowed by law. She uses one of their computers to sign-in and do
all of this. She snaps a picture of the QR code that is the prescription to
take to the pharmacy. Charlie, the licensed pharmacist, scans the
prescription QR code and fills the prescription. Alice pays cash.


*Sticky Wicket *-- *A sentence or three capturing the awkward challenge in
this particular situation*
The challenge of this particular use-case is that only Bob and Charlie are
verified identities and accountable for their interaction with Alice. Alice
can be anonymous or pairwise-pseudonymous with both Bob and Charlie and
everything just works. Alice, Bob, and Charlie all keep separate and
legally authentic copies of the records of their interaction in case of
dispute.

*Distinction *-- *A brief phrase explaining what makes this use case
distinct*
The Prescription use-case is a common and high-value example of privacy
engineering as we shift to convenient and cost-effective online commerce
among licensed and unlicensed individuals as peers. Bob and Charlie benefit
by reducing or even eliminating the influence of their respective
institutions or employers and therefore make more money. They pass some
savings to Alice who also gets increased peace of mind.

What makes a good use case?

A good use case is one that is:
A. *Unique* -- minimal overlap with other use cases
B. *Relevant* -- highlights the particular value of DIDs
C. *Value Creating* -- there is demonstrable value to the people at the
heart of the use case
D. *Simple yet Sticky* -- simple enough to be accessible, but also captures
a potentially complicated edge case.
E. *Specific *-- Uses real names and real situations to help readers
empathize with the human requirements

Adrian

On Sun, Jun 3, 2018 at 4:00 PM, Joe Andrieu <joe@joeandrieu.com> wrote:

> On Sat, Jun 2, 2018, at 9:27 PM, Jordan, John CITZ:EX wrote:
>
> So, thanks Manu .. as I wrote that email I recognized the use case didn't
> specifically say only one DID / organization as you point out below ..
> however it is good if we are specific about that NOT being the case as
> there are many that still think this way as it seems "natural".
>
> I think I understand that we need use cases for the W3C process (I'm new
> to that process) ... what is a bit fuzzy to me is that DIDs are probably
> not something the people will be normally exposed to in their day to day
> digital interactions. It is sort of like IP addresses (except many per
> person and not geo located of course!) in that DIDs are addresses and they
> are for machines. Should the use cases be a bit more low level in that they
> could describe the types of peer to peer connections they enable, the
> ability to have verifiable credentials issued to them, and so forth. Having
> the DID addressable layer is 100% critical to the goals of being able to
> exchange trustworthy bits but they are a little under the covers.
>
>
> For better or worse, there isn't a definitive "W3C Use Case" template or
> process. "Use cases" in the W3C sense are the preferred mechanism for
> demonstrating the value proposition of proposed standards; however, every
> use case document I've seen does it a little differently.
>
> In ours, we are building on the work I did with the VCWG and the
> Verifiable Credentials use case document [1]. That is currently going
> through a major revision, where the "Focal Use Case" is how we do a deeper
> dive on key use cases that illustrate in some detail the human requirements
> driving the technical decisions.
>
> My approach to use cases--and hence the approach I'm leading with to get
> these written up for the chartering process--is to seek use cases that
> illustrate* value-creating *interactions with a system, as far ahead of
> technology design & implementation decisions as possible.
>
> For example, in the domain of ATMs, "entering a PIN code" or "inserting
> card" are not, in and of themselves, value creating and they embed design
> choices. A few common ATM use cases that do create value are:
>    o Withdraw cash
>    o Check balance
>    o Transfer balance
>
> It is possible to describe how each of these use cases occur with minimal
> reliance on implementation choices. For example, you don't need to mention
> a screen, keypad, card & reader, and a PIN. Instead, you can talk about
> presenting options, identifying the correct account, inputting the amount,
> authenticating the user, and authorizing the withdrawal / balance check /
> balance transfer. This type of essential representation allows downstream
> implementers to innovate how each particular use case is satisfied, for
> example by using voice or biometrics instead of a screen and card reader.
>
> So, ideally, a good use case will illustrate that *because of DIDs*
> individuals get uniquely valuable transactions with specific systems,
> described with minimal reliance on the underlying tech. This will help us
> understand the human requirements independent of the solution designed to
> meet those requirements. If it is clearer to write it up with the design
> choices, start there; we can tease out the most relevant bits.
>
> I encourage you to focus on the human experience that is enabled by DIDs
> rather than the underlying mechanisms or protocols, except where they MUST
> be described to illustrate the use case. My Joram paper from RWOT [2] has
> several examples where we distilled the human experience with minimal
> dependence on the technology.
>
> The use case should describe *why* a use is uniquely valuable to real
> people and *what* the persons involved do in their interactions, but not
> *how* the technology does it. The latter part is the work of the
> technical specification. The use cases should tell the tale of why DIDs are
> different and valuable, independent of downstream design & implementation
> choices. They should explain why people will value DIDs--even, or perhaps
> especially--when they have no idea what's going on under the hood.
>
> To wit re: IP addresses: while IP addresses are generally hidden from most
> users most of the time, they are vital to how the Internet works. Key use
> cases that drove the development of IP were about network users being able
> to maintain connectivity in the face of catastrophic failure of particular
> servers on the network. What matters isn't how NATs or switches or address
> blocks work, but rather that under distress (the loss of components in the
> network), the rest of the network is able to re-route and to the end user,
> "it just works".
>
> In any case, I'll be working with use case authors to flesh out their
> submissions.
>
> Hopefully that helps.
>
> [1] https://w3c.github.io/vc-use-cases/
> [2] https://bit.ly/joram100
>
>
> I like the characterization of "single long lived identifier / single
> entity" ... I may borrow that if that is ok (
>
> Best
> J
>
>
> On 2018-06-02, 11:33 AM, "Manu Sporny" <msporny@digitalbazaar.com> wrote:
>
>     On 06/01/2018 03:37 PM, Jordan, John CITZ:EX wrote:
>     > I don’t think we need a single identifier like we have been trying to
>     > unsuccessfully have in some places for years. I feel like those
>     > numbers are a bad side effect of centralized database primary keys.
>
>     Agreed.
>
>     > I think the reason I am quite resistant to a single identifier (if
>     > that is what is being contemplated) for an organization is that in
>     > the real world stuff happens.
>
>     It was not what was being contemplated nor proposed, but I can see how
>     one could interpret the use case as such, so we should make it clear
>     that organizations/entities are expected to have more than one DID.
>
>     I said an "Organization gets a DID"... that doesn't mean its the /only
>     DID/ the organization has.
>
>     This group has identified the "single long lived identifier / single
>     entity" (e.g. SSN, DUNS, email address for identification) design as a
>     privacy concern in the VC spec here:
>
>     https://w3c.github.io/vc-data-model/#identifier-based-correlation
>
>     and here:
>
>     https://w3c.github.io/vc-data-model/#long-lived-identifier-
> based-correlation
>
>     We list the "desirable ecosystem characteristics" that we want here:
>
>     https://w3c.github.io/vc-data-model/#use-cases-and-requirements
>
>     So the change that needs to be made to the Decentralized Corporate
>     Identifiers use case is:
>
>     Clarify that organizations will have more than one DID, typically
> scoped
>     appropriately to the interactions that they will perform using the DID.
>
>     -- manu
>
>     --
>     Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
>     Founder/CEO - Digital Bazaar, Inc.
>     blog: The State of W3C Web Payments in 2017
>     http://manu.sporny.org/2017/w3c-web-payments/
>
>
>
>
> --
> Joe Andrieu, PMP
> joe@joeandrieu.com
> +1(805)705-8651
> http://blog.joeandrieu.com
>
>


-- 

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE: https://patientprivacyrights.org/donate-3/