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

Thanks Adrian and Daniel,

Both the 'real-world' analogy and the summary are very much appreciated!

I do like the 'ad hock' approach, from within which standards can emerge
bottom up.

I'll read your message in detail.


Cheers,
Dan

On Thu, 30 Apr 2020 at 09:26, Adrian Gropper <agropper@healthurl.com> wrote:

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