Re: When to use pair-wise unique DIDs vs. just individual unique DIDs

On Mon, Apr 16, 2018 at 8:54 AM, Challener, David C. <
David.Challener@jhuapl.edu> wrote:

> ​Let me add some questions, as I think this is a good conversation:
>

David, these are excellent questions, as they begin to explore how
a decentralized social networking service could really work.


> Alice wants to find out where her high school reunion will be - she has
> not been in touch with most of these people for decades.
>
> (Facebook knows a lot about you and can make suggestions of people you may
> know)
>
While it's true that nothing beats a giant centralized global database for
indexing and inferring relationships, I can at least point out how such
a database can start becoming decentralized if there a standard protocol
for doing this.

   1. Alice's high school (or some other group that the members of her
   class trust) publishes a public DID for her class (yes, groups can have
   DIDs). This DID is serviced by Alice's "high school class agent".
   2. Alice and all her classmates create pairwise pseudonymous DIDs with
   the high school class agent (perhaps after having been issued a verifiable
   credential of class membership from the high school).
   3. The high school class agent exposes an introduction service to all
   the members.
   4. Now every member of her class can selectively discover and connect to
   other members (again, with their own pairwise pseudonymous DIDs) with MUCH
   greater privacy and control that Facebook.

And remember, now every single relationship that is formed belongs to those
parties to the relationship and NOT to Facebook or any other service
provider. For life (or as long as the parties want the relationship—either
party can sever it at any time).

>
> Alice wants to contact someone she used to know and offer them a job - but
> doesn't know their current email or address. (A quick search on Facebook
> may find them.)
>
Yes, again, I don't see self-sovereign identity and pairwise pseudonymous
DIDs directly replacing search services. However with the new
"social infrastructure" of pairwise pseudonymous connecttions we're
describing here (probably a better term than "social network" since that
always sounds centralized), Alice's agent could contact any of her
connection's agents (with permisson) to see if they have a connection with
that person she used to know. And if so, one of them could make a trusted
introduction.

The software to do that would work very much like a decentralized search
service—rather than spidering the Web to bring all the connections back to
the search service's central index, it would actually search the
connections and just report back if it found the one you were looking for.

Hope this helps,

=Drummond



>
>
> ------------------------------
> *From:* Chris Boscolo <chris@boscolo.net>
> *Sent:* Monday, April 16, 2018 11:44 AM
> *To:* =Drummond Reed; W3C Credentials CG (Public List)
> *Subject:* Re: When to use pair-wise unique DIDs vs. just individual
> unique DIDs
>
> Drummond,
> Can I try to unpack this discussion with a concrete example?
>
> Scenario:
> Alice, a brand new adult user of the Internet gets her first iPhone, and
> wants to join the social network that all her friends are using called
> MyNewerSpace.com.  Alice downloads the MyNewerSpace.com App, and clicks
> "Create New User".  MyNewerSpace.com decided to roll their own SSI
> implementation with a DID method name of "mynewer", but they allow users to
> choose their own SSI provider, and Alice chose Sovrin.
>
> did:sov:aaa-bbb-1: is the DID Alice gives to MyNewerSpace.com.
> did:mynewer:xxx-yyy-1: is the DID MyNewerSpace.com gives to Alice to
> communicate with the service.
>
> 1) After Alice clicks, "Create New User".  Where are" did:sov:aaa-bbb-1"
> and "did:mynewer:xxx-yyy-1" stored?
>
> 2) Where does MyNewerSpace.com go to lookup the DDO for "did:sov:aaa-bbb
> -1"
>
>    2a) Is this some type of walled-garden to provide the privacy you speak
> of?
>
> 3) Where does the App Alice uses to login into MyNewerSpace.com go to
> lookup the DDO for "did:mynewer:xxx-yyy-1"?
>
>    -chrisb
>
>
>
> On Mon, Apr 16, 2018 at 1:14 AM, =Drummond Reed <drummond.reed@evernym.com
> > wrote:
>
>> [sorry—caught a typo that could be very confusing—see correction in red
>> below]
>>
>> On Sun, Apr 15, 2018 at 7:50 PM, =Drummond Reed <
>> drummond.reed@evernym.com> wrote:
>>
>>> On Sun, Apr 15, 2018 at 9:42 AM, Chris Boscolo <chris@boscolo.net>
>>> wrote:
>>>
>>>> Drummond,
>>>> I must admit, this answer caught me by surprise...
>>>>
>>>> How is what you are describing any different than our current federated
>>>> ID nightmare?
>>>>
>>>
>>> Chris, I must have mis-communicated something. Keep reading.
>>>
>>>
>>>>
>>>> In the age of the Internet and hackers being mostly smarter than those
>>>> building infrastructure, the term "private" is meaningless.
>>>> "Private" just means hidden from the public until at some point in the
>>>> future it is no longer hidden.
>>>>
>>>
>>> Yes, of course, the "privacy" of a microledger is not just that it's
>>> *not* a public ledger. The DIDs and DID documents on a microledger
>>> should still be as privacy-protecting as they would be on a public ledger,
>>> i.e., they shouldn't leak any information about the identity owner or
>>> relationship. They just are not publicly searchable or viewable.
>>>
>>>
>>>
>>>>
>>>> Furthermore, I thought the whole point of the DID approach is that the
>>>> DID owner can update the DDO if, for example, they want to update the
>>>> keys.  How would this work if as you say "and that each can maintain a copy
>>>> of the other's DID document".
>>>>
>>>
>>> That may have been the phrase that tripped you up. The "copy" of the
>>> shared DID document on the microledger is just like the "copy" maintained
>>> by all the nodes on a distributed public ledger. In other words, only
>>> the identity owner has the ability (or can delegate the ability) to make
>>> any chances to the DID document.
>>>
>>> To be clear, if Alice maintains a microledger with Bob, then Bob's node
>>> on the microledger has a copy of the pairwise pseudonymous DID and DID
>>> document that Alice has created for Bob, and Alice's node has a copy of the
>>> pairwise pseudonymous DID and DID document that Bob has created for Alice.
>>> Since both DID documents contain the service endpoints for their respective
>>> agents, the two agents are the only "nodes" that need to keep
>>> the microledger in sync (i.e., "consensus" is pretty easy). But it's still
>>> an actual ledger, i.e., all transactions are signed, hashed together into a
>>> chain, and replicated to all nodes.
>>>
>>>
>>>
>>>> Looks like I either need to re-evaluate my support for this approach or
>>>> hopefully some can help clarify this a bit more.
>>>>
>>>
>>> Hopefully I've done that; let me know if it's still not clear.
>>>
>>> =D
>>>
>>>>
>>>>   -chrisb
>>>>
>>>>
>>>> On Sun, Apr 15, 2018 at 3:50 AM, Carlos Bruguera <carlos@selfkey.org>
>>>> wrote:
>>>>
>>>>> Hey Drummond,
>>>>>
>>>>> The approach of "private" pairwise DID seems totally reasonable as it
>>>>> fits the very purpose of pairwise identifiers which is (in my
>>>>> understanding) to establish a *private* channel for authentication
>>>>> and authenticated comunication between entities. Also, leaving the ledger
>>>>> for the data that is making purposedly public works not only as an
>>>>> anti-spam measure on the ledger but also solves multiple privacy and
>>>>> anonymity issues.
>>>>>
>>>>> I'm guessing this approach can also be used in cases where
>>>>> correlativity is desired or at least tolerated (by using the same DID or
>>>>> "facet" for authenticating to multiple (possibly related) services, even if
>>>>> generated locally and exchanged privately)?... On a different line, is
>>>>> there any level of "anchoring" for these "private DIDs" against the public
>>>>> ledger? Or it's not necessary at all?
>>>>>
>>>>>
>>>>> On Sun, Apr 15, 2018 at 9:38 AM, =Drummond Reed <
>>>>> drummond.reed@evernym.com> wrote:
>>>>>
>>>>>> On Sat, Apr 14, 2018 at 9:46 AM, Chris Boscolo <chris@boscolo.net>
>>>>>> wrote:
>>>>>>
>>>>>>> First, Adam, thanks for posting the "WebAuthn & DID" presentation
>>>>>>> that surfaced the discussion of using pair-wise unique DIDs.  And thank
>>>>>>> you, Drummond, for linking to the discussion taking place at Sovrin on the
>>>>>>> subject. (https://forum.sovrin.org/t/th
>>>>>>> e-benefit-of-pairwise-dids/628/3
>>>>>>> <https://sslvpn.jhuapl.edu/t/the-benefit-of-pairwise-dids/628/,DanaInfo=forum.sovrin.org,SSL+3>)
>>>>>>>
>>>>>>>
>>>>>>> I decided to pull this one question out into its own thread to get
>>>>>>> clarification and to help inform how the WebAuthn protocol might be
>>>>>>> modified to support DIDs.
>>>>>>>
>>>>>>> I think the community would benefit if we had a clear understanding
>>>>>>> of when pair-wise unique DIDs should be used vs. when a per-user unique
>>>>>>> DIDs will suffice.
>>>>>>>
>>>>>>> In the example, where a user is creating a new account on a popular
>>>>>>> website it is clear to me that the user will want to use a unique DID for
>>>>>>> only that site.  But, I question whether it is a good idea for the website
>>>>>>> to create a unique DID to communicate with that one user.  In fact, I
>>>>>>> wonder if doing so will open the door to other unintended ways of
>>>>>>> correlating users with the site. (When these DIDs are in public ledgers.)
>>>>>>>
>>>>>>
>>>>>> Chris, I just wanted to point out why your final parenthetical is
>>>>>> important to this discussion. In Sovrin architecture, pairwise
>>>>>> pseudonymous DIDs *are not written to the public ledger*.
>>>>>>
>>>>>> It's true that a year ago, even as we started to use pairwise
>>>>>> pseudonymous DIDs, we assumed they were all being written to the Sovrin
>>>>>> public ledger because: a) they did not provide any correlate-able data, and
>>>>>> b) we didn't have an alternative.
>>>>>>
>>>>>> We subsequently realized that, since the whole point of pairwise
>>>>>> pseudonymous DIDs is that they are only needed by the two parties
>>>>>> involved—and that each can maintain a copy of the other's DID
>>>>>> document—there was no reason to write them to a public ledger. Rather the
>>>>>> two parties could maintain them on their own private microledger.
>>>>>>
>>>>>> This has several significant advantages:
>>>>>>
>>>>>>    1. It is even better from a privacy perspective since neither the
>>>>>>    pairwise pseudonymous DIDs nor their DID documents needed to be public.
>>>>>>    2. It is wonderful from a scalability perspective since
>>>>>>    the microledgers add almost no load to the public ledger.
>>>>>>    3. It means the Sovrin public ledger can be optimized for public
>>>>>>    DIDs and other SSI infrastructure data that needs to be fully public and
>>>>>>    widely shared.
>>>>>>
>>>>>> Should these considerations be added to the DID spec?
>>>>>>>
>>>>>>
>>>>>> That's a very good question. I don't think the DID spec (or any other
>>>>>> spec) should be weighed down with lots of implementation guidelines and
>>>>>> advice, but we should probably mention the basic option that DIDs can be
>>>>>> registered on public ledgers, private ledgers, or microledgers.
>>>>>>
>>>>>> What do you think?
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>