- From: heather vescent <heathervescent@gmail.com>
- Date: Wed, 11 Jul 2018 09:27:57 -0700
- To: Bohdan Andriyiv <bohdan.andriyiv@validbook.org>
- Cc: Stephen Curran <swcurran@cloudcompass.ca>, Manu Sporny <msporny@digitalbazaar.com>, Credentials Community Group <public-credentials@w3.org>
- Message-ID: <CA+C6qMzFomE4hTDOGqtTLSUV0tz0=ZwTSRL5sTfigV=EX4ogFA@mail.gmail.com>
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