Call for Focal DID Use Cases

      
  

  
  
  
  
  

  
  
  
  

  
  Hi Joe,
  
  
  
  We have been working with you to develop two use cases around user safety/privacy, and are thinking of adding a third. I thought I’d share this with the community:
  
  
  
  Use Case #1: In October 2017, at least 34 people have been arrested in Egypt as part of an expanding crackdown on the gay and transgender community. The crackdown was enabled by Egyptian police who used social media, gay dating apps and other websites to identify and target gay and transgender activists. If people could use pseudonymous Decentralized IDs linked to a new kind of reputation, it would (a) safeguard the identities of gay and transgender people exercising personal freedom, (b) provide a system for preventing entrapment, and (c) offer a community driven system to report abuses yet honors the human condition.   
  
  
  

  
   Use Case #2: To enable greater privacy for ICO investors. There are certain repressive regimes where investing in ICOs could lead to government sanctioned extortion. Their ID must be safeguarded just as securely as the person in Use Case #1 above.   Please see: https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2018/blob/master/topics-and-advance-readings/self-sovereign-compliance.md where some of these ideas are introduced.   
  
    
  
   Use Case #3: We’re developing a use case around DID usage with mobile telephony. This is part of my work with HTC around their announced “blockchain phone” which will embed DID capabilities. See:   https://thenextweb.com/hardfork/2018/05/15/htc-blockchain-powered-phone/
  
  
  
  Moses
  
  
    
  
  
  
-
  
Moses Ma | NextGEN Ventures Inc
  
moses@ngenven.com | moses.ma@futurelabconsulting.com
  
v  +1.415.952.7888 (tel:+1.415.952.7888)  | m  +1.415.568.1068 (tel:+1.415.568.1068)  | skype mosesma
  

      

  
  
>   
>   
> On Tue, May 8, 2018 at 12:09 PM Joe Andrieu  <joe@joeandrieu.com (mailto: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 (mailto:joe@joeandrieu.com)
> >   
> > +1(805)705-8651 (tel:(805)%20705-8651)
> >   
> > http://blog.joeandrieu.com
> >     
> >
> >        --
>   
>   
>   
>
>   
>
>   
>   
>
>
>
>   
>   
>   
>