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

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).
>

Yes, and I now add a third: authentication methods (the "authentication"
property)—it is very useful as well.


> 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.
>

Agreed.


>
> 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.
>

While I agree with the overall point that your service endpoints also
should be pairwise pseudonymous, I just want to point out that the exchange
of verifiable claims themselves does not require you to use a pseudonymous
endpoint. You could in fact use a very public endpoint—such as an
agency—that hides the ultimate destination of the messages.


> 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.
>

Agreed. The way I put it is that you need "triple pseudonymity":
DIDs, public keys, and agent endpoints—but that the last one can be a
public pseudonym, such as your agency.


>
> 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.
>

Why a loss of self-sovereignty? You control all your private keys. You
control all updates to our microledgers. Thus you can move from any service
endpoint (at any agency) to any other service endpoint (at any agency) with
no loss of control, ever. And that doesn't require self-hosting your own
agency. It just requires agencies that grant you full control of your cloud
agents. Which I believe will be the standard in a self-sovereign ecosystem
(it is one of the requirements we put into the Sovrin Trust Framework
<https://sovrin.org/trust-framework/>).


>
> What is the recommended way for me to operate an off-chain self-sovereign
> agent / identity hub?
>

Again, you can host your own (full agency capability is being built in
the Hyperledger Indy codebase) or use any commercial or non-profit agency
that guarantees you control of your cloud agents.

See the DKMS Design and Architecture doc <http://bit.ly/dkmsv3>
at Hyperledger Indy for more details.

Best,

=Drummond


>
> 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/
>