Re: DID Docs stored on or off the ledger? ... was Re: DNS -> DIDs

The model we've been talking about in the Indy/Sovrin Agent Working Group
is to recommend (although at this early point, that might be too strong a
word) that each pairwise DID have an endpoint in each pairwise DIDDoc that
is assumed to be for an Agency (e.g. "www.AgentsRUs.com") and that the
endpoint be in the form of a DID (which is of course a URI) for the
Agency.  For example: service_endpoint: "did:sov:23efeda45693deb5". That
"endpoint DID" is owned by the Agency, not by the Identity.

To send a message to an Identity:

   - Get and resolve the endpoint DID from the pairwise DIDDoc
   - Send the message as a "Forward" and encrypted to that shared endpoint.
   - The Agency endpoint would decrypt the message to get one additional
   piece of information - the destination DID for the message (the actual
   message is encrypted only for the ultimate recipient).
   - From that, the Agency would use something like a mapping table to know
   the Identity to which the message needs to go (but nothing about the
   message itself).
   - It's implementation specific how the Agency handles this.
   - At that point - the message is in the hands of an Agent controlled by
   the recipient Identity and is assumed will "Do the Right Thing" for that
   Identity.

By having the endpoint URI as a DID, the Agency has control over it's
DIDDoc (which is published on a Public Ledger) and can rotate keys, change
the endpoint URL, etc.  That means the pairwise DIDDocs don't have to worry
when the Agency changes it's keys.  The Identity would only change the
endpoint in the pairwise DIDDocs when it changes Agencies - a much rarer
event.

This model implies one other thing.  When an Identity shares a pairwise DID
with another identity, it must tell the Agency "Hey, when you see this DID
- send it to my Agent". That is part of the Agency implementation - up the
Agency code to handled that.

The goal is to make it "assumed" (and hence, interoperable) that there is a
shared Agency endpoint that services many Identities, each with many
pairwise DIDs. That hides the Identity-to-Identity interactions in a crowd.

The recommendation is to enable interoperability, Senders should assume ALL
identities are structured that way.  As such, an Identity that does
something different should still structure it's DIDDoc to look like that,
so that the Sender knows how to send the Identity a message.

A bit in the weeds, but hopefully that helps.


On Fri, Aug 10, 2018 at 5:52 PM, Adrian Gropper <agropper@healthurl.com>
wrote:

> Drummond,
>
> I'm on the same wavelength with you (as usual) but I'm unclear about the
> next level: the endpoints. A DID document has two principal functions
> (other than housekeeping like key rotation) - to provide public key(s) and
> service endpoint(s). The public keys do have some stand-alone uses for
> signing, but the endpoint is the key to self-sovereign agency and a risk
> for correlation.
>
> Pairwise DIDs can be arbitrarily cheap and scalable but, as soon as my
> identifier needs to be associated with some private claims, I need to
> control those private claims and tokens through a service endpoint.
> Ideally, my service endpoint should be self-sovereign and as correlation
> resistant as the pairwise DID. Which suggests a need to have a separate
> service endpoint for each pairwise DID.
>
> For convenience, a service endpoint should ideally aggregate my various
> policies across hundreds of pairwise DIDs (the number of logins in my
> 1Password file). This could be achieved by tumbling through an Agency that
> I trust with loss of self-sovereignty.
>
> What is the recommended way for me to operate an off-chain self-sovereign
> agent / identity hub?
>
> Adrian
>
>
> On Fri, Aug 10, 2018 at 8:21 PM, =Drummond Reed <drummond.reed@evernym.com
> > wrote:
>
>> On Fri, Aug 10, 2018 at 3:12 PM, heather vescent <
>> heathervescent@gmail.com> wrote:
>>
>>>
>>> On Fri, Aug 10, 2018 at 12:21 PM, Stephen Curran <
>>> swcurran@cloudcompass.ca> wrote:
>>>
>>>> I think the model that some networks are moving to is for most DID Docs
>>>> to be held between the communicating parties, and not pushed out to a
>>>> public ledger.
>>>>
>>>
>>> Is this really the case? Which of the ledgers are moving in this
>>> direction?
>>>
>>
>> The Sovrin ledger is "moving in this direction". So is
>> uPort's architecture (as I understand it).
>>
>>
>>> And if so, I'm curious why?
>>>
>>
>> Two reasons: privacy and scalability. In summary:
>>
>>    1. Some DIDs and DID documents need to be public so that anyone can
>>    search for and verify them. But other DIDs that are only used as pairwise
>>    pseudonyms do not need to be public—they only need to be shared between the
>>    parties to a private relationship. In Sovrin architecture these DIDs are
>>    shared on what's called a *microledger*. Microledger code has not
>>    been fully implemented in Hyperledger Indy yet, but the same basic
>>    functionality has already been implemented in direct agent-to-agent DID/DID
>>    document exchange.
>>    2. This also has the advantage of dramatically increasing
>>    scalability. The vast majority of microledger activity takes place
>>    "off-chain" (i.e., off of the public ledger), so it scales the same way
>>    cloud architecture does. It doesn't require the public ledger to have to
>>    scale to enormous amounts of throughput; essentially the public ledger is
>>    only needed to anchor the public DIDs of issuers of credentials that need
>>    to be widely verifiable.
>>
>> And also if so, can you please point me to documentation.
>>>
>>
>> The Sovrin Technical Governance Board and Hyperledger Indy have not put
>> out any official documentation yet because the code is still in
>> development, but the basic concept is covered in the DKMS Design and
>> Architecture document <http://bit.ly/dkmsv3> release at IIW last April.
>>
>>
>>
>>>
>>>
>>>> Anyone that needs to resolve the DID -> DIDDoc must be able to in some
>>>> local manner (implementation specific), and there must be mechanisms to
>>>> push changes from one party to the other.
>>>>
>>>
>>> But the whole point of putting the DID and DID Doc on the ledger is so
>>> they are always available. It seems counterintuitive to put the DID but not
>>> the DID Doc on the ledger. There is no PII in the DID Doc (just a #, the
>>> public/private key, and any endpoint links)....
>>>
>>
>> A few points:
>>
>>    1. DIDs and DID documents that describe people are all
>>    considered personal data under GDPR ("PII" is now longer the test).
>>    2. Sharing a pairwise pseudonymous DID, public keys, authentication
>>    methods, and endpoints publicly might not appear to have any privacy
>>    implications, but in fact they do. A simple example: if you create
>>    a pairwise pseudonymous DID that originates in your SSI wallet and is
>>    shared with only one other party in the world—and then it later shows up
>>    someplace else—you can be pretty sure who shared it without your
>>    permission. But if all your pairwise pseudonymous DIDs are published on
>>    a public ledger, you have no such assurance.
>>    3. An agent that you control that maintains a microledger that is
>>    properly backed up can be as persistent as a public ledger without these
>>    privacy issues.
>>
>>
>>>
>>>> Those same mechanisms are need for updating the DIDDoc when it is on a
>>>> public ledger.  So, that does to some degree help with preventing
>>>> correlation - there is not an obvious way to get the list of DIDs in active
>>>> use for indexing and searching.  In that model, the DIDs that do go on the
>>>> public ledger are ones that people want known - e.g a public DID for an
>>>> Enterprise to be used to start connections.
>>>>
>>>
>>> This seems like making this way more complex than is necessary - in
>>> response to my question about the black arts of correlation via watching
>>> data flows vs capturing the actual data. I wasn't saying we have to solve
>>> for that extremely crazy corner case, I was curious if it maps to that
>>> similar problem...
>>>
>>
>> Again, with microledgers those public correlation problems simply go
>> away. This is similar to FIDO architecture—the pairwise pseudonymous public
>> keys it uses to authenticate you are never stored on a public repository.
>>
>>
>>>
>>>
>>>>
>>>> Net traffic can be monitored going into and out of a "known endpoint"
>>>> such as an Agency (holding many Agents) or a Hub. The plans I have seen on
>>>> the HyperLedger Indy side are that data will be encrypted in transit - no
>>>> plaintext - and that because the endpoint is shared by all Agents (e.g.
>>>> many identities, each with many DIDs), it will be difficult to learn from
>>>> just seeing the 'Net traffic.
>>>>
>>>
>>> Yeah, but the endpoint is also stored in the DID Doc, and all the PII
>>> data is stored in the wallet, or agent, or hub, or whatever cloud thing or
>>> hardware thing you've decided to use.
>>>
>>> So why/how would it make sense to NOT store the DID Doc on the ledger?
>>>
>>
>> I hope the answers above help. Privacy and scalability are the two
>> driving reasons that pairwise pseudonymous DIDs exchanged "off-ledger" via
>> private microledgers are now the default in Sovrin architecture. Public
>> DIDs are absolutely still there because public issuers of verifiable
>> credentials definitely still need them; they are just the exception rather
>> than the rule.
>>
>> =Drummond
>>
>
>
>
> --
>
> 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/
>



-- 

Stephen Curran
Cloud Compass Computing, Inc. (C3I)
Technical Governance Board Member - Sovrin Foundation (sovrin.org)


*Cell: (250) 857-109Schedule a Meeting: **https://calendly.com/swcurran
<https://calendly.com/swcurran>*