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

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