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

On Fri, Aug 10, 2018 at 9:57 PM, Stephen Curran <swcurran@cloudcompass.ca>
wrote:

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

*I agree that the Agency adds valuable privacy but it seems to reduce
self-sovereignty. The Agency will be prone to compromise and censorship by
a government entity and a single point of failure. Wouldn't Tor routing to
the Agent endpoint be more private?*

*Adrian*

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



-- 

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/