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

Thanks all for the responses. I understand the technical how, but I'm still
curious why from a user/usability perspective?

My take away is that storing DID Documents off the ledger is a concept
being put forth by Sovrin/Hyperledger Indy. It's still very much conceptual
and a work in progress. I have more questions: Is it important to
understand in the context that Sovrin is a private, permissioned
blockchain, vs others that are public and permission less? Is this a
solution for primarily human identifiers? How would it work with government
or others who do need access - would they access this through an agent-like
thing?

I'm also curious to hear from ledgers. Is this an overall direction? For
uPort, is this a response to financial constraints to using the ETH
blockchain? Clearly uPort and Sovrin are not the only two ledgers in this
space.

It would be great if there was a session on this at IIW or maybe RWOT...
we're clearly evolving our thinking as we experiment with real tech
scenarios.

-H

On Sat, Aug 11, 2018 at 10:30 AM, Markus Sabadello <markus@danubetech.com>
wrote:

> Good thread, I just wanted to add as a side comment that service endpoints
> are only one way of contacting and interacting with agents.
>
> Depending on which transport is used, a service endpoint may not be
> required at all (e.g. messages can be exchanged via NFC or Bluetooth
> directly between devices).
>
> In the DID Auth paper
> <https://raw.githubusercontent.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2018/master/final-documents/did-auth.pdf>
> we described a lot of different flows, some of which require service
> endpoints in the DID document, and some don't.
> While this was specifically focused on authentication, I believe it will
> be similar for more generic agent/hub communication as well.
>
> This is already visible in some (non-Sovrin) DID-based projects that don't
> require service endpoints for claims exchange.
>
> Markus
> On 08/11/2018 05:53 AM, =Drummond Reed wrote:
>
> 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/
>>
>
>
>


-- 
Heather Vescent <http://www.heathervescent.com/>
The Purple Tornado, Inc
~ The Future in Present Tense ~

@heathervescent <https://twitter.com/heathervescent> | Film Futures
<https://vimeo.com/heathervescent> | Medium
<https://medium.com/@heathervescent/> | LinkedIn
<https://www.linkedin.com/in/heathervescent/> | Future of Security Updates
<https://app.convertkit.com/landing_pages/325779/>