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

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