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

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>
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/
>
> 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> 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>
>> *Sent:* Wednesday, April 29, 2020 6:51 AM
>> *To:* Manu Sporny <msporny@digitalbazaar.com>
>> *Cc:* public-did-wg@w3.org; Dan Bolser <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>
>> 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%7C8216aa689aba46ca510108d7ec4471e5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637237651027389404&sdata=QF53MBGLuJLfjYukvxjP%2B%2FZJIgrZa8WVpMZd64Pi64w%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%7C8216aa689aba46ca510108d7ec4471e5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637237651027389404&sdata=XApQGIpLKzR2MXeF7UgqLR0FQE01%2FwqICD0dGP8%2FB70%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%7C8216aa689aba46ca510108d7ec4471e5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637237651027399403&sdata=zBkkH8xVTZ3ZmpUnnf4bN7dc1sCd%2BG5K8XY9vPhi%2BQo%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%7C8216aa689aba46ca510108d7ec4471e5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637237651027399403&sdata=5PebANwgB672SgXUTJr2CARC5gPvxP9m9cou6gBhS74%3D&reserved=0>
>>
>>