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

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

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

Yes, Tor-style routing would make it even more private. And that of course
could take place between cooperating Agencies.


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