RE: Agency First

This really isn’t about one particular technical person/hobbyist who may have a high tolerance for extreme costs related to something they are passionate about. I hope Agents (things with keys that can do things as you) will for the most part be in physical custody of the user, be it a person, business, or other. If we desire that default security premise (and I think we should), it inherently means placing an Agent in front of Hub interactions will send all your app/service traffic through your Agent endpoint that resides somewhere under your care/custody.

The issue here, and please consider the scale involved, would be that a large number of high-traffic/consumption apps and services must be needlessly routed through it, even though they already have the auth/keys to go to the Hub itself. This means your Agent becomes a bottleneck that must be able to handle the immense traffic of random data reads/writes from all the apps and services a user is consuming, either actively on their devices or via the app/service background tasks. The reality of that choice for 99% of the populace who can’t feasibly handle TBs/month of traffic to a static IP at their house (ISPs would frown on this, to put it midly), it will force Agents to the cloud, which means keys would be there as well. If pretended to be a Greedy Corporate Cloud Guy for a second (yick), I would thank everyone for effectively pushing all Agent/Hub business to large cloud infra providers. I don’t want that future, personally, so this is why I advocate the opposite setup.

There are large, systemic reasons why the relatively powerless, cache-friendly, cloud/large infra suited Hubs were placed in front: because if you put something like an Agent in front (which makes sense when you’re talking about the 1-5% of identity: credential flows), the system is no longer feasible to address the 95% of the total identity use case.

- Daniel

From: Adrian Gropper <agropper@healthurl.com>
Sent: Wednesday, July 3, 2019 8:16 AM
To: Daniel Buchner <Daniel.Buchner@microsoft.com>
Cc: W3C Credentials Community Group <public-credentials@w3.org>; daniel.hardman@evernym.com
Subject: Re: Agency First

Thank you all for the thoughtful responses. Agency First does not argue against issuance of VCs, availability of VPs, or people having Holders. Also, I understand that some applications will be well-served by ZKPs.

The agenda being proposed for the call is strictly about the Service Endpoint(s) in a DID Document. I propose that for reasons of DID adoption and substitutability (aside from the better-understood DID method issues) we discuss the role of an authorization agent vs. a personal data store as the reference use-case for the service endpoint. For example, we could specify that the agent SHOULD support refresh tokens to improve the performance and user experience of owning an agent.

Also, speaking primarily for myself now, I am not very concerned with the cost of operating the Agent. My assumption is that the agent will more than pay for itself through machine learning and attention to increasing the value of personal data by being ever more discerning in how data is used.

Adrian

On Wed, Jul 3, 2019 at 10:07 AM Daniel Buchner <Daniel.Buchner@microsoft.com<mailto:Daniel.Buchner@microsoft.com>> wrote:
Thanks Adrian! I agree with Daniel, I would like to do a dedicated call as well.

One thing to note: credentials, like the one you described below, are maybe 5% of identity (5% is probably very generous, it might be 1%). The vast majority of your digital identity (everything you say, do, write, and digitally engage in) is done via app/service interactions that have no credential proving purpose – e.g. Google Keep, Instagram, Slack, etc. Given apps/services will make up 95+% of the traffic, which is typically traffic that’s extremely demanding of velocity, throughput, and caching, I just hope everyone understands that whatever you might put between apps/services and the user’s Hubs will sustain an apocalyptic, unceasing pounding from the client and server sides of the user’s apps, services, and bots. Most of that traffic will be from apps that already have authorization and keys to decrypt the encrypted data that lies at rest in the Hub, so putting another component in the middle is going duplicate a massive amount of the load and needlessly create higher costs for the user. Just something to think about as we step out of the relatively small world of credentials to the wider world of decentralized identity.

- Daniel

From: Daniel Hardman <daniel.hardman@evernym.com<mailto:daniel.hardman@evernym.com>>
Sent: Tuesday, July 2, 2019 6:41 PM
To: Adrian Gropper <agropper@healthurl.com<mailto:agropper@healthurl.com>>
Cc: W3C Credentials Community Group <public-credentials@w3.org<mailto:public-credentials@w3.org>>; Daniel Buchner <Daniel.Buchner@microsoft.com<mailto:Daniel.Buchner@microsoft.com>>
Subject: Re: Agency First

This reasoning makes sense to me. I have always felt like agents are a precondition to data management.

I would be supportive of such a dedicated call.

On Tue, Jul 2, 2019 at 7:33 PM Adrian Gropper <agropper@healthurl.com<mailto:agropper@healthurl.com>> wrote:
This is a fork of the Data Hubs / Aries / DIF Thread asking for a dedicated call in CCG to discuss whether agent endpoints should be specified _before_ data storage endpoints.

Here's the use case and logic:

  *   Alice is on the dating scene and wants an anonymous HIV test.
  *   Anonymous HIV tests are good public health and often free from government or non-profits.
  *   Alice has her choice of where to get the HIV test. Since cost is not an issue, she will pick the one that is most private.
  *   Some of the HIV test labs will support Alice's pairwise pseudonymous DID. She picks that one.
  *   Alice can pick the dating service too. Other things being equal, she will pick the one that is most privacy-preserving.
  *   Alice picks a dating service that supports pairwise pseudonymous DIDs.
  *   Alice does not have a personal data store or a credential wallet.
  *   Alice's test result is available directly from the lab that does the test to anyone with a suitable access token. The format of the result is irrelevant as long as the recipient can understand the difference between Positive and Negative and a Date.
  *   Alice operates an agent that decides semi-autonomously whether Bob should see her test result. The agent could be proprietary to the dating service or self-sovereign to Alice. However it's implemented, the agent must issue a token that the lab will accept to Bob
  *   Although Alice has separate DIDs with the lab and the dating service, she could be correlated if the two DIDs point to the same agent. This is a concern that would need to be mitigated for an agent or a h.ub or a personal data store as endpoint in her DIDs.
  *   From Alice’s agent, Bob's client gets a pointer to the lab and the DID that Alice used at the lab.
  *   Bob's client comes to the lab bearing Alice’s DID. The lab points Bob’s client back to Alice’s agent to get an access token.
  *   If Bob is evil and leaks Alice’s lab and lab DID to Carol, then Carol’s client will likely not be able to get an access token from Alice’s agent so Alice’s HIV status will remain confidential.
  *   If Bob is evil and leaks Alice’s HIV status, it will not be direct from the lab and could have been forged by Bob.
This use-case is important because:

  *   It gives Alice market power to choose privacy-preserving service providers (lab, dating service). This will drive adoption. Any service provider can decide to accept a DID regardless of any other service provider as long as the DID resolves to Alice's agent.
  *   Alice does not have to trust the dating service or a personal data store intermediary.
  *   Alice may not need a wallet or Holder at all because no VC is issued.
  *   The data model and protocol for presenting the test result is more or less irrelevant. In practice, it is not totally irrelevant because most labs and services are multi-purpose and the access token will have to be scoped and that implies some data model schema shared between the service provider and the agent.
I'm calling this "Agency First" because:

  *   If Alice does choose to control a personal data store, then she can choose a personal data store that respects her agent. Again, the market power is in Alice's hands, or
  *   If Alice chooses to control a Holder then she needs to find a lab that's willing to issue a VC and a Verifier that trusts the DID method, VP, etc...
Adrian



--

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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatientprivacyrights.org%2Fdonate-3%2F&data=02%7C01%7CDaniel.Buchner%40microsoft.com%7C4bcc57c62e694b7b47b508d6ffc96736%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636977637821013184&sdata=2LsaYI%2Bzcb26q9oA6RR0Hx5Y7FSXmAm279aD5kZecvk%3D&reserved=0>