Re: Notes from 2019-03-21 DID Resolution Spec First Draft Meeting

Here is a small but relevant data point: given the great work our group has
been doing with B.C.
https://www.cigionline.org/articles/need-national-digital-identity-infrastructure
There’s no mention of standards. No mention of the difference between
Privacy by Design and Privacy by Default. No mention of other attempts,
such as CONNECT in the US or Aadhaar in India to build digital identity
systems with or without standards, respectively.

People like to use drinking and banking to explain digital identity. But
role of government as a health care funder (insurance as well as research)
is much much larger and crossing over from exclusive public use (passports,
welfare payments) to private health care delivery is much more interesting.
Here are two related papers of work I was involved in in India:

   1.

   Reimagining Health Data Exchange: An Application Programming
   Interface–Enabled Roadmap for India <http://www.jmir.org/2018/7/e10725/>;
   J Med Internet Res 2018;20(7):e10725 DOI: 10.2196/10725 - See also
Ref 89: Government
   of India, NITI Aayog. National Health Stack: Strategy and Approach
   <http://www.niti.gov.in/writereaddata/files/document_publication/NHS-Strategy-and-Approach-Document-for-consultation.pdf>.
   2018 Jul. (p30 mentions “health information exchange of one”) Getting
   them to adopt standards and respect privacy in the face of politics and the
   vast amounts of money at stake when you want to impact 500 million people
   is a challenge. (links to the two papers are on my blogroll
   http://healthurl.com/www/Blogs_+.html )

   Whether we start small or big, with or without government, clarity on
   the role of current and emerging standards for digital identity seems
   important to me.

   Adrian


On Mon, Apr 8, 2019 at 3:14 AM Michael Herman (Parallelspace) <
mwherman@parallelspace.net> wrote:

> Adrian, it’s still a question of “where do you start” and “who do you
> start with”.
>
>
>
> From a technology adoption perspective, healthcare has historically (and
> based on my recent experiences), somewhere between mainstream and
> laggards.  Has this changed?
>
>
>
> Here’s a model that relates social evolution to the technology adoption
> life cycle:
> https://hyperonomy.com/2019/04/08/social-evolution-and-technology-adoption/
>
> In simple terms, it suggests starting with small distinct populations of
> users on the left side of the curve and then use them as references as
> target those in the center (main stream) as well as those on the right
> (laggards).
>
>
>
> Best regards,
>
> Michael Herman (Toronto/Calgary/Seattle)
>
> Independent Blockchain Developer
>
> Hyperonomy Business Blockchain / Parallelspace Corporation
>
>
>
> W: http://hyperonomy.com
>
> C:  +1 416 524-7702
>
>
>
>
>
> *From:* Adrian Gropper <agropper@healthurl.com>
> *Sent:* April 7, 2019 10:22 PM
> *To:* Michael Herman (Parallelspace) <mwherman@parallelspace.net>
> *Cc:* Markus Sabadello <markus@danubetech.com>; W3C Credentials CG <
> public-credentials@w3.org>
> *Subject:* Re: Notes from 2019-03-21 DID Resolution Spec First Draft
> Meeting
>
>
>
> i”m not looking for a time estimate. My confusion stems from over a decade
> of working around many of these technologies. In healthcare, for example,
> there is Zero adoption of any of the authentication technologies I listed
> so maybe there’s nothing standing in the way of DID adoption :-)
>
>
>
> I’m not asking for either miracles or predictions. What I am calling for
> is an analysis of what our “marketing” strategy is to the various SDOs and
> thought leaders that we interact with.
>
>
>
> The endless debate over JSON-LD vs. JWT (which I am somewhat guilty of as
> well) prompts my question. We also talk about what developers might or
> might not do with other aspect of our specifications. This is all healthy
> and necessary.
>
>
>
> Resolving my confusion seems like a useful step on the path to
> implementation in DIF, Hyperledger, and pretty much anywhere else.
>
>
>
> Adrian
>
>
>
> On Sun, Apr 7, 2019 at 11:59 PM Michael Herman (Parallelspace) <
> mwherman@parallelspace.net> wrote:
>
> RE: I can't tell which of these current things will remain when DIDs come
> online
>
>
>
> Adrian, we’re much too early in the DID technology adoption lifecycle to
> tell which competing/overlapping technologies/solutions/specifications will
> dominate - let alone, which technologies will survive.
>
>
>
> Mass acceptance/deployment of Decentralized Identifiers is a long ways
> away ….TCP-IP took 30 years.  I’m willing to wager DIDs won’t reach mass
> acceptance/deployment until 2030 or later.
> Checkout: *Phases of Foundational Technology Adoption*
>
>
> https://www.linkedin.com/pulse/blockchain-foundational-technology-michael-herman/
>
>
>
> Here’s what I think the hype cycle for DIDs looks like at the beginning of
> 2019: (https://twitter.com/mwherman2000/status/1103683539592048642)
>
>
>
>
>
>
>
> Best regards,
>
> Michael Herman (Toronto/Calgary/Seattle)
>
> Independent Blockchain Developer
>
> Hyperonomy Business Blockchain / Parallelspace Corporation
>
>
>
> W: http://hyperonomy.com
>
> C:  +1 416 524-7702
>
>
>
>
>
> *From:* Adrian Gropper <agropper@healthurl.com>
> *Sent:* April 7, 2019 2:33 PM
> *To:* Markus Sabadello <markus@danubetech.com>
> *Cc:* W3C Credentials CG <public-credentials@w3.org>
> *Subject:* Re: Notes from 2019-03-21 DID Resolution Spec First Draft
> Meeting
>
>
>
> Markus, thank you so much for picking up on my question!
>
>
>
> I went and reviewed a bunch of papers including:
>
> - https://www.w3.org/wiki/WebID
>
> -
> https://docs.google.com/document/d/1oUDVxWy674ZWG2ElB3YN9bcmSXXR9f2mg60E_Uazigc/edit?ts=5c79597d#heading=h.rfqxmrvt8ml5
>
> -
> https://techcommunity.microsoft.com/t5/Azure-Active-Directory-Identity/Identity-Hubs-as-personal-datastores/ba-p/389577
>
>
>
> I'm more confused than ever.
>
>
>
> Here's what I hope I could explain to a patient or a doctor:
>
>    - DIDs improve on today's choice of email address or Login with
>    Facebook by adding convenience, privacy, and security.
>    - DIDs solve the explosion of passwords for authentication, but
>    require you to have a Web browser or mobile app that holds secret keys
>    - In almost all cases, you will also want to have server / web site /
>    hub somewhere online, away from your Web browser or mobile app
>    - You can choose where this server is, move it, or host it yourself
>    without having to re-register your ID with every website and merchant that
>    you gave a DID to.
>    - You can choose how much of the information you attach to a DID is
>    public and how much is private. For example, you may want to attach a
>    photograph to your DID so that people can match it to your in-person face
>    the way they use a driver's license. You may not, however want the search
>    engines and everyone else to be able to add your face and DIDs to a global
>    database of everyone.
>    - In order to decide who gets to see your face or anything much else
>    about you, you will have some authorization features on your mobile device
>    and / or on your sever.
>    - When this authorization feature is on your mobile device, you will
>    be asked and have to click something.
>    - When this authorization feature is on your server online, the server
>    can act on your behalf without bothering you as long as it can understand
>    and trust the credentials presented by whoever is asking and depending on
>    what they are asking for.
>    - DIDs also help the person who is asking you or your server for
>    authorization present their credentials in a way that protects your privacy
>    as well as theirs.
>
> Right now, I believe that all of the above is true but if someone asked me
> to explain how this relates to WebID, OIDC, UMA, X509, FIDO, I would tell
> them it's too complicated for me to understand. I can't tell which of these
> current things will remain when DIDs come online. Why would anyone ever use
> Sign In with Facebook? Would I still need my 1Password or will 1Password
> change to list a bunch of DIDs instead of usernames and passwords?
>
>
>
> Adrian
>
>
>
>
>
> On Fri, Apr 5, 2019 at 1:02 PM Markus Sabadello <markus@danubetech.com>
> wrote:
>
> Adrian,
>
> I just realized nobody had responded to this question, sorry about that.
>
> We were talking about WebIDs on that earlier call, because just like DIDs,
> WebIDs are also URIs that are designed to identify an individual in the
> real world (e.g. Alice).
> And just like a DIDs can be resolved to a DID document, a WebID can be
> resolved to a WebID profile.
>
> In my mind, the difference between a DID or WebID, and e.g. an OpenID
> Connect UserInfo Endpoint, is that the latter is not an identifier for
> Alice.
> Instead it's a URL of a service associated with Alice that can be used to
> authenticate or interact with Alice.
>
> An OpenID Connect UserInfo Endpoint can be discovered from a DID or from a
> WebID.
>
> Those distinctions are important if we want to be 100% in line with
> (Semantic) Web architecture and principles.
>
> Does that make sense?
>
> Markus
>
> On 3/22/19 12:32 PM, Adrian Gropper wrote:
>
> Question:
>
>
>
> Along with WebID, might we also consider DID Resolution for folks familiar
> with OpenID Connect UserInfo Endpoint?
>
>
>
> Adrian
>
>
>
>
>
> On Fri, Mar 22, 2019 at 6:46 AM Markus Sabadello <markus@danubetech.com>
> wrote:
>
> Zoom recording, chat logs, and slides for the (now weekly) DID Resolution
> Spec First Draft Meeting are here:
> https://github.com/w3c-ccg/meetings/tree/gh-pages/2019-03-21-did-resolution
>
> List of attendees and call notes are here below. You can also read them on
> the meeting page
> <https://docs.google.com/document/d/1BKbwWCS9ZT1Aawxv2YVvGUUOv9WfPqMK9MiWh1s9dLo/>
> .
>
> Markus
>
> *DID Resolution Spec First Draft Meeting Page*
>
> *This page is for taking notes of weekly meetings held in 2019 of members
> of the **W3C Credentials Community Group*
> <https://www.w3.org/community/credentials/>* who are collaborating to
> complete the First Draft of the **DID Resolution specification*
> <https://w3c-ccg.github.io/did-resolution/>*. Meeting notes are listed in
> reverse chronological order.*
>
> *Note: This meeting directly follows the weekly **DID Spec Community
> Final Draft Meeting*
> <https://docs.google.com/document/d/1qYBaXQMUoB86Alquu7WBtWOxsS8SMhp1fioYKEGCabE/>
> *.*
> Call Information
>
> Time: Every Thursday, 14:00-15:00 PT
>
>
>
> https://zoom.us/j/7077077007
>
>
>
> Or iPhone one-tap:
>
>    US: +16465588656,,7077077007#  or +16699006833,,7077077007#
>
>
>
> Or Telephone:
>
>    Dial (for higher quality, dial a number based on your current
> location):
>
>        US: +1 646 558 8656  or +1 669 900 6833
>
>        United Kingdom: +44 (0) 20 3051 2874  or +44 (0) 20 3695 0088
>
>    Meeting ID: 707 707 7007
>
>    International numbers available: https://zoom.us/u/q6mghCSZ
> Links (Generally Useful to the Group)
>
>    - DID Spec <https://w3c-ccg.github.io/did-spec/>
>    - DID Resolution Spec <https://github.com/w3c-ccg/did-resolution/>
>
> Thursday 21 March 2019 Attending
>
>    - Markus Sabadello
>    - Jonathan Holt
>    - Drummond Reed
>    - Joe Andrieu
>    - Michael Herman
>    - Stephen Curren
>    - Dmitri Zagidulin
>    - Dan Burnett
>    - Nader Helmy
>    - Amy Guy
>    - Adrian Gropper
>    - Chris Boscolo
>    - Yancy Ribbens
>
> Agenda
>
> 1. Community governance: issue resolution and closure policies
>
> 2. What does it mean to dereference a DID URL?
>
> 3. Presentation of the above README: did-url-spec - Decentralized
> Identifier URL (did-url) Specification as well as the spreadsheet:
> https://github.com/mwherman2000/did-url-spec/tree/master/src (latest
> numbered version)
> Meeting Notes Topic #1: Understanding DID URLs and “Resolution” and
> “Dereferencing”
>
> Markus explained the overall topic using this slide:
>
>
>
> Michael pointed out that the “defererencing” category also splits into two:
>
>    1. A DID URL that dereferences to a subcomponent of a DID document.
>    2. A DID URL that undergoes a transformation to address a resource
>    external to the DID document via a service endpoint.
>
>
>
> Markus went on to explain the following slide:
>
>
>
> Jonny asked how much DID resolution is actually parallel to DNS resolution.
>
>
>
> Michael said that he has a set of proposals for how a set of DID
> resolution operations can work, e.g., how to query the capabilities of a
> resolver, or how to get a list of DID documents.
>
>
>
> Michael whether returning a DID document is “access”?
>
>
>
> Joe responded that access to a DID document is an open issue. Some
> proposals are to encrypt a DID document.
>
>
>
> Drummond proposed that “DID resolution” be the set of steps that a DID
> method takes to return a DID document. He agreed with Joe that a particular
> DID method may in fact impose access control on obtaining a DID document.
> He then said that once a DID document is returned, you move into the
> “dereferencing” stage, and that can divide into the two types discussed
> above.
>
>
>
> Dan: The DID document is not itself the resource, but a means of
> determining how to access the identified resource.
>
>
>
> Markus next talked about this slide:
>
>
>
> Drummond: Let’s avoid the HTTP Range 14 rathole! Let’s be clear that a DID
> never identifies a DID document! A DID identifies a DID Subject. That DID
> Subject MAY be a network-accessible resource. In that case a DID document
> describes how to access that resource. But the DID document may identify a
> non-network resource (like a person), in which case the DID document
> describes how to access service endpoints associated with the resource.
>
>
>
> Jonny: IPLD is a type of resource that a DID may identify.
>
>
>
> Joe: The resource when a DID is dereferenced is always on the network.
>
>
>
> Markus spoke to this slide:
>
>
>
> Joe and Drummond discussed the analogy with DNS and URL-identified
> resources. Drummond said that the DNS record that is retrieved in order to
> access the web page or RDF document. The DNS record is not the resource
> being identified by a URI. Therefore it is the equivalent of a DID document.
>
>
>
> Markus next discussed this slide:
>
>
>
> Dan dove into this “HttpRange-14” issue by suggesting that a DID subject
> was not actually a person. “+1 that action on a DID for a physical resource
> could be to return a URL for a file.”
>
>
>
> Drummond suggested that if a DID always identifies a DID subject, and that
> DID subject may be *either* a *real-world resource*
> (non-network-retreivable) or a *network resource*. If a DID identifies a
> real-world resource, then the DID document describes options for
> interacting either with that real-world resource via some type of network
> connection, or accessing other descriptions of that real-world resource.
> But the DID itself still identifies the real-world resource.
>
>
>
> If the DID identifies a network-retrievable resource, then resolving the
> DID to the DID document will enable obtaining the actual URL that *also*
> identifies that network-retrievable resource. That means the DID and the
> URL would actually be “synonyms”, but at different layers of abstraction.
>
>
>
> Drummond also said this addresses the “two URI” problem from Web ID. The
> DID that identifies Alice is URI #1, and the URL that identifies some
> resource describing Alice (*not* the DID document) is a second URI.
>
>
>
> Joe mentioned that this means that a “naked DID” by itself should not be
> considered a URL. We should need to add a delimiter at the end of the naked
> DID to turn it into a URL for the DID document.
>
>
>
> Drummond seconded that suggestion. It could be either the empty path, or
> the empty fragment.
>
>
>
> Dan said that he had clarity that a DID document is about how to *describe
> how to interact with a resource*, but not describing the resource itself.
> That’s why a DID document is never the resource identified by the DID.
>
>
> Action Items
>
> --
>
>
>
> 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/
>
>
>
>
>
> --
>
>
>
> 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/
>
> --
>
>
>
> 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/
>
-- 

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/