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

On Wed, 29 Apr 2020 at 17:18, Adrian Gropper <agropper@healthurl.com> wrote:

<snip>

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

Right, this is the kind of data I'm thinking about.


the response to this query will need to be automated by the operator.
>

By the operator, or by the authorization server on the operators behalf?


Ta,

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