Re: Use Case: Transaction Identification (travel use cases)

Clarification below...

On Wed, Jul 11, 2018 at 9:25 AM, heather vescent <heathervescent@gmail.com>
wrote:

> Just some quick thoughts...
>
> I see that there are several use cases why people want your
> PII/identity/reputation for both innkeepers and AirBnB (slightly different).
>
> 1. Damages, where the data is needed in time limited way
> 2. Left items, to get in touch if a guest has left an item
> 3. Registry of guests - this is sticky here, but there may be legal
> requirements to have names in cases where those businesses have to interact
> with law enforcement. How long does that information need to be held?
>
> Finally, I see a reputation use case as well, that goes both ways - and
> this is specifically for AirBnB type stuff.
> 4. Reputation of the person before they arrive.
> 5. Giving reputation to the person/s after the guest experience.
>
> When I rent my place on AirBnB, the reputation information is more
> important than the PII. Although the PII is important, especially in damage
> cases. I can also see law enforcement issues as well, e.g. unauthorized
> party, unauthorized number of guests, unauthorized film shoot, etc.
>
> I am most unclear on the legal/regulatory requirements for
> collecting/keeping this kind of PII. But I can imagine it might be
> important for human/sex trafficking.
>

It would be important for *law enforcement / detective work * in cases such
as human/sex trafficking.


>
> Would it make sense to have some of this discussion on a future CCG call?
>

> -Heather
>
> On Wed, Jul 11, 2018 at 8:53 AM, Bohdan Andriyiv <
> bohdan.andriyiv@validbook.org> wrote:
>
>> I think in case of Innkeepers, they want your PII *with* your legal name
>> in case they need to bring you responsible for property damage, unpaid
>> bills, etc. Thus, selective disclosure will not work in this case (the same
>> as in other property involving or high stakes cases, like  "car rental"),
>> as they need your legal name to call the police or press charges in court.
>> Just proving your age or citizenship will not work.
>>
>> I guess, the use case becomes - "Secure storage and selective access to
>> sensitive PII (that includes legal identity) in transactions between
>> unreliable parties.".
>>
>> Bohdan
>>
>> On Wed, Jul 11, 2018 at 6:23 PM, Stephen Curran <swcurran@cloudcompass.ca
>> > wrote:
>>
>>> The use of Verifiable Credentials and selective disclosure should
>>> address a large part of this use case. The purpose of the disclosure will
>>> limit the amount of information handed across to the those asking - e.g.
>>> the classic example of the bartender needing only to know that you have
>>> proof from a trusted issuer that you are old enough to drink (picture,
>>> checkmark, ID of trusted issuer).  In some of the contexts of this use
>>> case, the Verifier only needs to know that you have ID issued from a
>>> trusted source, not the details.  That eliminates much of the overly shared
>>> PII.  Further - such organizations would have a liability in holding that
>>> PII.
>>>
>>> In the specific case, I think that the some information is collected by
>>> Innkeepers (to use a quaint term) for correlation by Authorities - e.g. you
>>> provide the ID from your passport or driver's licence so they know where
>>> you were (which is crazy, but...moving on). Payment by a Credit Card is the
>>> same thing - you need to provide the identifier by which the Credit Card
>>> company knows you so you can charge something to your account. However,
>>> those scenarios can be mitigated with Verifiable Credentials by the Issuer
>>> (gov't, credit card company, etc.) providing you with one-time use VerCreds
>>> with a GUID that only they can correlate to their internal identifier for
>>> you. The intermediary can do nothing with that information. Apple Pay and
>>> Google Pay are using one time use Credit Card numbers today.
>>>
>>> Once we get a rich Verifiable Credential ecosystem, the use of a
>>> well-known Identifier (e.g. an SSN, Credit Card Number) will not be
>>> accepted without proof that it was issued to you.  Such identifiers will
>>> still be Bad Things (correlate-able), but not useful to malicious parties.
>>>
>>> On Wed, Jul 11, 2018 at 7:59 AM, Bohdan Andriyiv <
>>> bohdan.andriyiv@validbook.org> wrote:
>>>
>>>> > VC's contain a "Terms of Use" field...
>>>> > ...Issuer and Holder  ...  can attach Terms of Use to the data and
>>>> digitally sign it such that their intent in sharing the [PII] data is
>>>> clear.
>>>>
>>>> At risk of stating the obvious, but to be clear - a "Terms of Use"
>>>> field does not solve the risks of improper PII usage by unreliable
>>>> parties.
>>>> A "Terms of Use" field lessen the ability to use VC that contains PII,
>>>> but PII itself remains unprotected.
>>>>
>>>> To solve the issue of  "sensitive PII in the hands of unreliable
>>>> holder", we will have to use the mix of - unlostable DIDs, e2ee, and hubs
>>>> of encrypted PII guarded by trusted intermediaries. See the logic described
>>>> in my previous email - https://lists.w3.org/Archives/
>>>> Public/public-credentials/2018Jul/0024.html.
>>>>
>>>> Do you think this solution is too complex, unlikely? or you think a
>>>> "Terms of Use" field alone, will be enough in practise?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, Jul 11, 2018 at 4:36 PM, Manu Sporny <msporny@digitalbazaar.com
>>>> > wrote:
>>>>
>>>>> On 07/11/2018 12:53 AM, Carlos Bruguera wrote:
>>>>> > One thing that's not clear to me yet, though, is how can DIDs/VCs
>>>>> > actually avoid the risks of improper personal information management
>>>>> > once credentials and personal data have been shared with a relying
>>>>> > party... Any opinions shared by the community on this regard?
>>>>>
>>>>> VC's contain a "Terms of Use" field:
>>>>>
>>>>> https://w3c.github.io/vc-data-model/#terms-of-use
>>>>>
>>>>> While the contents of that field are still under discussion, the idea
>>>>> is
>>>>> that both the Issuer[1] of the Verifiable Credential and the Holder[2],
>>>>> who creates Verifiable Presentations[3], can attach Terms of Use to the
>>>>> data and digitally sign it such that their intent in sharing the data
>>>>> is
>>>>> clear.
>>>>>
>>>>> This enables issuers to say things like: "This credential can only be
>>>>> used to prove citizenship."
>>>>>
>>>>> It also enables holders (us) to say things like: "I only authorize the
>>>>> use of this credential to establish an account with your service, you
>>>>> are not authorized to store, cache, or share the credential."
>>>>>
>>>>> ... but in a machine-readable way that makes processing and compliance
>>>>> with those statements automatic.
>>>>>
>>>>> -- manu
>>>>>
>>>>> [1] https://w3c.github.io/vc-data-model/#dfn-issuers
>>>>> [2] https://w3c.github.io/vc-data-model/#dfn-holders
>>>>> [3] https://w3c.github.io/vc-data-model/#presentations
>>>>>
>>>>> --
>>>>> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
>>>>> Founder/CEO - Digital Bazaar, Inc.
>>>>> blog: Veres One Decentralized Identifier Blockchain Launches
>>>>> https://tinyurl.com/veres-one-launches
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> Stephen Curran
>>> Cloud Compass Computing, Inc. (C3I)
>>> Technical Governance Board Member - Sovrin Foundation (sovrin.org)
>>>
>>>
>>> *Cell: (250) 857-109Schedule a Meeting: **https://calendly.com/swcurran
>>> <https://calendly.com/swcurran>*
>>>
>>
>>
>
>
> --
> Heather Vescent <http://www.heathervescent.com/>
> The Purple Tornado, Inc
> ~ The Future in Present Tense ~
>
> @heathervescent <https://twitter.com/heathervescent> | Film Futures
> <https://vimeo.com/heathervescent> | Medium
> <https://medium.com/@heathervescent/> | LinkedIn
> <https://www.linkedin.com/in/heathervescent/> | Future of Security Updates
> <https://app.convertkit.com/landing_pages/325779/>
>



-- 
Heather Vescent <http://www.heathervescent.com/>
The Purple Tornado, Inc
~ The Future in Present Tense ~

@heathervescent <https://twitter.com/heathervescent> | Film Futures
<https://vimeo.com/heathervescent> | Medium
<https://medium.com/@heathervescent/> | LinkedIn
<https://www.linkedin.com/in/heathervescent/> | Future of Security Updates
<https://app.convertkit.com/landing_pages/325779/>

Received on Wednesday, 11 July 2018 16:28:44 UTC