RE: [EXTERNAL] Re: Fwd: Protocol for requesting private data?

“- We might need a way to decide a taxonomy of service endpoints before we make progress on SDS.”

^ for this one, I will argue that well-known data objects can be the API, and that very minimal number of actual service endpoints need to be defined once you have an inferentially knowable API based on the semantic data schemas/formats themselves.

From: Adrian Gropper <agropper@healthurl.com>
Sent: Thursday, April 30, 2020 1:27 AM
To: daniel.hardman@evernym.com
Cc: Dan Bolser <dan@geromics.co.uk>; public-did-wg@w3.org
Subject: Re: [EXTERNAL] Re: Fwd: Protocol for requesting private data?

Daniel H describes three essential aspects of DID service endpoint(s) below:
A - Protocol plug-ins that support various transports are important
B - VCs are optional because they add unnecessary complexity
C - Three-party use cases with the DID subject as controller but not proxy are important.

I would note,
- these three aspects are orthogonal to each other and equally relevant to DIDs.
- Secure data stores cross all three of the essential aspects but are not essential in the same way as these three
- We might need a way to decide a taxonomy of service endpoints before we make progress on SDS.

- Adrian


On Wed, Apr 29, 2020 at 2:18 PM Daniel Hardman <daniel.hardman@evernym.com<mailto:daniel.hardman@evernym.com>> wrote:
I do not necessarily disagree with any of the answers that have already been given, but I think they ask us to generalize about data and authorization in ways that the original question didn't require. So let me add a simpler answer.

If we didn't have tech and we wanted to know someone's shoe size, we'd just ask them. If we wanted to make sure that the question and answer happened in private, we'd whisper in their ear, and they'd whisper back. Here's the closest that I know of to doing remotely and securely, with tech.

1. The controller of a DID includes a DIDComm endpoint in their DID doc.
2. The party wanting info sends a DIDComm message to that endpoint, asking their shoe size. This could be done with the BasicMessage protocol or the CommittedAnswer protocol, for example. (DIDComm endpoints can run any number of protocols at the same endpoint; they don't need a new one for each protocol. Protocol support at an endpoint is discoverable.)
3. The controller of the DID responds with a DIDComm message containing the answer.

This can be done over HTTP, over email, entirely offline over BlueTooth or with QR codes/Sneakernet, etc. The protocol doesn't change when a new topic arises. It doesn't require any special authorization by either party, because you're using authenticated encryption and getting the data direct from the source, not a third component that is brokering access to data. It is exactly as secure as DID control (not susceptible to tampering or eavesdropping, if key hygiene is good; both parties know the other party is actually the controller of the DID that's used; can be non-repudiable if desired). It can be done with public DIDs or peer DIDs. Etc.

Note that I didn't use VCs in the 3-step sequence. VCs are about issuers attesting to data, and being believed due to issuer reputation. If the party wanting to know shoe size is willing to believe whatever the DID controller says on the topic, then you *could* model this with a VC where the issuer is the DID controller -- but you could also just get the DID controller to answer a question, and short-circuit the whole VC mechanism, and your level of assurance would be the same.

Now, a bunch of smart people in this group are working on technologies that are more elaborate than this, and may bristle at my simple steps above. Depending on whether your real use case is more elaborate than a one-off self-attested shoe size, they might be totally right to assert that something fancier is needed. So let me point out various ways that the answer above breaks down.

A. If the party requesting data won't believe the data unless it's attested by some third party that they deem trustworthy, then VCs become much more compelling.

You might embody the answer in a VC and request/reply over a credential exchange protocol (CHAPI, streaming JWT-based VCs over OIDC the way Microsoft is advocating, or the Present Proof protocol from Aries RFC 0037, for example) instead. CHAPI is very webby and browser-friendly; the OIDC+JWT approach might offer easy integration with enterprise login workflows; the Present Proof protocol is identical in guarantees and flexibility to the simple question/answer protocols listed above, but is a Hyperledger thing that some in this group dislike. I'm not trying to argue the relative virtues here -- only showing that if you start down the VC route, a new set of considerations comes into play. There is now an issuance process that must have produced the data in question, either long before or just before it's presented, and there's a validation process that includes signature verification on the receiving side. Revocation becomes a thing. Etc.

B. If the data you're after is something repeatable and not requiring third party attestation, and if you want access to the data that doesn't run through its owner directly, then data vault / identity hub / semantic containers technology can add value.

As Daniel B pointed out, fetching your preferred profile photo, your twitter handle, your all time top-10 movies list, and a playlist of your favorite songs can be helpfully modeled as a "Can I please have data item X owned by subject Y?" operation, where the place you're fetching from is not Y directly, but rather a service that dispenses data on subject Y's behalf. Now the question of authorization that Adrian raised also becomes vital, as does consent; the data dispensing service must know that Y actually agrees to release the data, and must enforce terms of service. In exchange for the indirection and complexity of such a mechanism, the service can add value by being online constantly, by serving very large amounts of data in an automated way without bothering Y, by giving back the data over and over again to the same questioner as the data changes, etc.


On Wed, Apr 29, 2020 at 10:19 AM Adrian Gropper <agropper@healthurl.com<mailto:agropper@healthurl.com>> wrote:
MyData has spent the past 7 months doing a spectacular job of driving to a consensus around the MyData Operators construct. Hot off the presses today: https://mydata.org/operators/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmydata.org%2Foperators%2F&data=02%7C01%7Cdaniel.buchner%40microsoft.com%7C39f61cf46a9f4265d18608d7ece0529c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637238320527853352&sdata=%2BKf9fe3EV2tb8nVlvrtJ6s9IXWBPkkt8bN4OqEukk6c%3D&reserved=0>

The Operators paper doesn't get into standards but it does reach a consensus among 50 or "proto-operators" over how they might be governed and interoperate as fiduciary or at least neutral agents for the individual data subject.

When data changes over time, like your temperature and respiratory rate in a pandemic, issuing serial VCs from that wearable or its online proxy, becomes a problem. Even worse, as the person walks around, there might be constant queries for their personal data that will need to be considered. Who is asking (based on their VCs)? What do they want to know? Why do they want to know? Whether it's a VC of my temperature or a access to a stream from my thermometer, the response to this query will need to be automated by the operator.

- Adrian

On Wed, Apr 29, 2020 at 12:01 PM Daniel Buchner <Daniel.Buchner@microsoft.com<mailto:Daniel.Buchner@microsoft.com>> wrote:
I think we should consider the multitude of cases where you want to grant access to a preference or some other type of data that changes over time, such that the party you want to have the info is able to see its latest state over time. For this, basic credential exchange won’t suffice, unless we want users inundated with endless mobile notifications as entities attempt to ascertain the current state of the preference you wanted them to know about. An example would be sharing your shipping address for UPS, Fedex, etc., because people often move, or what type of music you are most into presently, because your go to playlist changes composition.

- Daniel

From: Brent Zundel <brent.zundel@evernym.com<mailto:brent.zundel@evernym.com>>
Sent: Wednesday, April 29, 2020 6:51 AM
To: Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>>
Cc: public-did-wg@w3.org<mailto:public-did-wg@w3.org>; Dan Bolser <dan@geromics.co.uk<mailto:dan@geromics.co.uk>>
Subject: [EXTERNAL] Re: Fwd: Protocol for requesting private data?

And, as Many had hinted at by referring you to the credential handler API, this sort of problem is what verifiable credentials are great for, rather than DIDs.

On Wed, Apr 29, 2020, 07:24 Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>> wrote:
On 4/29/20 5:10 AM, Ivan Herman wrote:
> Are there specific / concrete proposals on how to negotiate this data?

Yes, several. One is the Credential Handler API:

https://github.com/digitalbazaar/credential-handler-polyfill/blob/master/README.md<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdigitalbazaar%2Fcredential-handler-polyfill%2Fblob%2Fmaster%2FREADME.md&data=02%7C01%7Cdaniel.buchner%40microsoft.com%7C39f61cf46a9f4265d18608d7ece0529c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637238320527863347&sdata=kUoL8k2UR%2F3fnnk5Xap2PmlVqOTn15MxkYsexiTsVAc%3D&reserved=0>

Very old but still relevant video here:

https://www.youtube.com/watch?v=bm3XBPB4cFY<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3Dbm3XBPB4cFY&data=02%7C01%7Cdaniel.buchner%40microsoft.com%7C39f61cf46a9f4265d18608d7ece0529c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637238320527863347&sdata=cQgLB6jivAwal8pz4WuWl%2BlA6wv9ftvqzn2wTtFrQsA%3D&reserved=0>

-- manu

--
Manu Sporny - https://www.linkedin.com/in/manusporny/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fin%2Fmanusporny%2F&data=02%7C01%7Cdaniel.buchner%40microsoft.com%7C39f61cf46a9f4265d18608d7ece0529c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637238320527873341&sdata=BjCs3XKZPD%2FBgNRY5qYrizLrxn1Gkl8cGZPRmpoMTEM%3D&reserved=0>
Founder/CEO - Digital Bazaar, Inc.
blog: Veres One Decentralized Identifier Blockchain Launches
https://tinyurl.com/veres-one-launches<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftinyurl.com%2Fveres-one-launches&data=02%7C01%7Cdaniel.buchner%40microsoft.com%7C39f61cf46a9f4265d18608d7ece0529c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637238320527873341&sdata=Zm37tSpIc%2BZzCBznISUwDtH6zI4SVOxgcszEb%2Bbm9ZQ%3D&reserved=0>