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

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/