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

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