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

Dan,

The standard for the authorization server endpoint in the DID is likely to
be something like Transactional Authorization https://oauth.xyz/ There was
a great session at IIW on Wednesday (Session 10G "TxAuth and XYZ (and Maybe
someday OAuth 3)" ) with notes posted in a week or so. The current standard
for this is Kantara UMA 2 (by mostly the same people) but it has only a few
commercial implementers. My wild guess is that DID, SDS, and OAuth3 as
standards will come out about the same time.

Sorry, I used operator and authorization server too loosely. Operator is a
MyData term and refers to a role whereas authorization server is an OAuth2
/ UMA 2 / OAuth 3 term that refers to a standard. If you're curious about
the MyData perspective this is the white paper hot off the presses:
https://mydata.org/operators/

As for your first question about specifying a subset of the protected
resources that the authorization server controls, that is a matter for the
resource server's API data model and standard. For example, in healthcare
we have the HL7 FHIR standard. (Sorry, I really don't know if shoe size is
in there but polydactyly probably has a slot). Transactional authorization
expects the "Client" representing the requesting party to present three
things to the authorization server endpoint:
- Who's asking: Credentials
- Scope of request: based on the API of the resource server
- Reason for asking
The authorization server then issues stuff back to the client that the
client can use at the resource server.

- Adrian

On Thu, Apr 30, 2020 at 7:30 AM Dan Bolser <dan@geromics.co.uk> wrote:

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