- From: Markus Sabadello <markus@danubetech.com>
- Date: Sat, 11 Aug 2018 21:30:45 +0400
- To: =Drummond Reed <drummond.reed@evernym.com>, Adrian Gropper <agropper@healthurl.com>
- Cc: heather vescent <heathervescent@gmail.com>, Stephen Curran <swcurran@cloudcompass.ca>, Christopher Lemmer Webber <cwebber@dustycloud.org>, W3C Credentials CG <public-credentials@w3.org>
- Message-ID: <40ba5c45-3b46-7105-71f6-ea4d78f50eac@danubetech.com>
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 <mailto: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 <mailto:drummond.reed@evernym.com>> wrote:
>
> On Fri, Aug 10, 2018 at 3:12 PM, heather vescent
> <heathervescent@gmail.com <mailto:heathervescent@gmail.com>>
> wrote:
>
>
> On Fri, Aug 10, 2018 at 12:21 PM, Stephen Curran
> <swcurran@cloudcompass.ca
> <mailto: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/
> <https://patientprivacyrights.org/donate-3/>
>
>
Received on Saturday, 11 August 2018 17:31:15 UTC