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

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

Received on Wednesday, 29 April 2020 16:18:53 UTC