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

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.

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