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>
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>
> 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>
>>>
>>>