Re: Call for Focal DID Use Cases

I promised Joe an EDU DID use case by EOW (last week). I did not do that,
and I still did not finish one. But, I started one here and wanted to share
in case it helps others start theirs.

I hope to fill in more detail before tomorrow's meeting.

https://docs.google.com/document/d/1KfdDBfgYyziigspyITTvbWABzF00MbA4pHyf_rf3XSI/edit?usp=sharing

Thanks,
Kim


On Tue, May 8, 2018 at 12:09 PM Joe Andrieu <joe@joeandrieu.com> wrote:

> TLDR: Nominate your favorite DID use case for inclusion in the DID Use
> Case document
>
> On today's call we started the conversation about what use cases to
> include in the support document for chartering a new working group for
> Decentralized Identifiers.
>
> This is your chance to make a case for the most relevant use case DIDs.
>
> If you have one you'd like to suggest, simple send the list an email with
> some or all of the following:
>
> *Name *-- A pithy name that captures the relevance of the use case
> *Background *-- A sentence or three capturing current state of practice,
> the motivation, and the value it creates
> *Description *-- A paragraph capturing the core action of the use case:
> what people do
> *Sticky Wicket *-- A sentence or three capturing the awkward challenge in
> this particular situation
> *Distinction *-- A brief phrase explaining what makes this use case
> distinct
>
> 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
>
> For D, it's great when the basic functionality is straightforward and we
> fold in a question of "but what if..." and illustrate how DIDs handle a
> particular real-world problem better than existing approaches.
>
> Here's an example Use Case for DIDs:
>
> *Name*: Digital Executor
>
> *Background*: Today, when people die, there are no standard technologies
> for heirs, executors, or probate courts to properly take control of an
> individual's online accounts and digital assets. With a DID linked to
> accounts and assets, a DID owner could define a trigger for a third party
> to assume control over the DID Document. Ideally, this trigger would
> specify (a) an oracle (how to know the death/incapacity occurred), (b) a
> means for the new owner to assert control, and (c) appropriate checks and
> accountability.
>
> *Description*: Kathy uses DIDs to manage her authentications to various
> services. As part of her estate planning, she generates a unique credential
> that she gives to her attorney, Gloria, with provisions specified in her
> will, which initially lists Mike as the digital executor. With appropriate
> obfuscation, that credential is specified in multiple DID documents as a
> probate authority, with the authorization to change the master key in case
> of death, which shall be recorded publicly, on chain, as a notarized
> invocation of the probate authority. As it happens, Kathy had a falling out
> with Mike and notified Gloria just two weeks before her death that her
> friend Miyake should now be her digital executor. Upon Kathy's death,
> Gloria uses the probate credential to publicly record the assertion of
> probate and to replace the DID's master key with a new key, controlled by
> Miyake, who lives in Japan (Kathy, Gloria, and Mike live in the United
> States). Now, any system using Kathy's DIDs for authentication can
> programmatically recognized Miyake's authority *and* specifically know that
> Kathy's credentials were modified under a assertion of probate.
>
> *Sticky Wicket*: The late date change in digital executorship from Mike
> to Miyake could be problematic if Kathy had directly listed Mike's
> credential in the DID Document. Because she instead chose to rely on her
> attorney, Kathy has a more flexible way to direct her wishes, while still
> leveraging the collective control over her authenticated logins to various
> services. In addition, Miyake's geographic location could make it hard for
> them to travel to the United States and may make it difficult to provide
> proof of identity traditionally used by U.S. courts. Also, because Gloria
> invokes the probate mechanism, Miyake need only provide a suitable
> credential at that time; he did not need to create and maintain a
> credential over a long period of time (as would be the case if Gloria
> weren't involved).
>
> *Distinction*: Multiple DIDs with a common, blinded authority for probate
> assumption of control. The legal selection of the new owner is mediated
> through a trusted fiduciary (an attorney of record). Cross-border transfer
> of ownership.
>
>
> The more you can flesh out the details, the better. We will consider a
> variety of options before we whittle down to a few canonical, focal use
> cases.
>
> Please chime in with your preferred Use Case.
>
> -j
>
> --
> Joe Andrieu, PMP
> joe@joeandrieu.com
> +1(805)705-8651 <(805)%20705-8651>
> http://blog.joeandrieu.com
>
> --
Kim Hamilton Duffy
CTO & Principal Architect Learning Machine
Co-chair W3C Credentials Community Group
400 Main Street Building E19-732, Cambridge, MA 02139

kim@learningmachine.com | kimhd@mit.edu
425-652-0150 | LearningMachine.com