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

Hi Carlos,

>> "Unreliable counterparty" is able to review PII, but not copy or store
it.
> How do you forbid or avoid the counterparty to copy or store it? That
theoretically definitely sounds appealing (like being able to show a
physical ID card without handing it over, but digitally, is that even
doable?

Glad you asked! This is where 'the subject should not delegate to an
unreliable holder...' comes into play.
Now, I know, in the previous email I wrote 'the subject should not delegate
to an unreliable holder...' is not a solution, but hear me out.

The point in this use case is to release as little control over PII as
possible, and most importantly to _not_ create treasure troves of PII.
Under the current arrangement every service provider (innkeeper, car rental
company, hospital etc) is going to collect honey pots of sensitive PII =>
i.e. breaches inevitable.

There is a solution - "Snapchat for credentials"

Service Provider (innkeeper, car rental company, hospital etc)
Requirements:
* do not want to create treasure troves of PII and bear responsibility for
them
* need to prove that they reviewed PII before they provided service
* need to have access to PII, in case "something happens"

PII owner requirements:
* want to give up as little control over their PII as possible
* do not want to have their PII to be stored in the permanent "PII treasure
troves"
* would like to know when someone used, reviewed their PII (have audit
history of their PII usage)

Solution: "Snapchat for credentials"
* store PII on a cloud (aka "Snapchat for credentials") to manage access to
your PII to keep audit history of access to PII
* encrypt PII with DID of PII owner
* encrypt PII with DID of attorney (who is trusted both by service provider
and PII owner)


Under the proposed arrangement:
* there are no treasure troves of unencrypted or centrally encrypted PII
* service provider is able to review PII, have proof that it has reviewed
PII, have access to PII with permission from PII owner, have access to it
"in case something happens" with permission from PII attorney (attorney
both trusted by service provider and PII owner);
* PII owner have maximum control over his PII, has audit history of access
to his PII

As you can see under this arrangement, you will have to trust service
provider to not store PII at the moment of review. The most service
providers will be glad to be alleviated from the need to store PII.
The main point we have not created treasure troves of unencrypted or
centrally encrypted PII now.

This arrangement may sound complex, but it is not that complex from
technical point of view. I think it provides enough tangible benefits for
PII owners (better control over important credentials), to drive demand for
the market to create "Snapchat for Credentials". Alternatively, it may take
a "Snowden-scale" breach of treasure trove of driving licenses or passports
etc to motivate market or  government to implement it.


Bohdan

On Mon, Jul 16, 2018 at 8:57 AM, Carlos Bruguera <carlos@selfkey.org> wrote:

> Hi Bohdan,
>
> Your idea of "trusted intermediaries" makes me think of Identity Hubs,
> where such an agents MAY be running and hosted on a trusted intermediaries,
> but might also be in complete control of the identity owner. In any case, I
> just don't see how would something like this be implemented:
>
> >"Unreliable counterparty" is able to review PII, but not copy or store
> it.
>
> How do you forbid or avoid the counterparty to copy or store it? That
> theoretically definitely sounds appealing (like being able to show a
> physical ID card without handing it over, but digitally, is that even
> doable?
>
> Realistically, it seems more feasible to rely on a combination of
> selective disclosure with digitally signed terms, agreements and receipts,
> but I just don't see how can information be shared digitally without
> "handing it over".
>
> Best,
> Carlos
>
> On Fri, Jul 13, 2018 at 11:16 PM, Bohdan Andriyiv <
> bohdan.andriyiv@validbook.org> wrote:
>
>> Hi David,
>>
>> I am quite perplexed why you think this use case "Secure storage and
>> selective access to sensitive PII (that includes legal identity) in
>> transactions between unreliable parties." is an extreme edge case.
>>
>> As our paper credentials become digital, we will have a massive issue
>> with making PII in them secure.
>>
>> Just look at this breach: "... a 41-gigabyte file being sold on the dark
>> web that contained 1.4 billion username and password combinations from
>> online services such as Netflix, Last.FM, LinkedIn, MySpace, Zoosk,
>> YouPorn, Minecraft, Runescape, and others. " [1]
>>
>> Now, imagine this 41-gigabyte file contains digital passports and driving
>> licenses with physical addresses and other sensitive PII of millions of
>> people.
>>
>> Obviously, a "Terms of Use" field is not going to solve this situation,
>> as well as  approach - 'the subject should not delegate to an unreliable
>> holder...'.
>>
>> What is needed is decentralized E2EE based on 'unlostable' DIDs and oni
>> top of this additional selective access and security layer from cloud
>> providers.
>>
>>
>> > I think your solution is complex...
>> Yes, solution is complex, but it is doable (at least I hope so). I think
>> making and adopting 'unlostable' DIDs and use them for E2EE will be the
>> trickiest part here.
>>
>> Also. I think with time, sharing credentials with sensitive PII will be
>> largely replaced by digital signing using government validated identities.
>> Eventhough, sharing of credentials with sensitive PII will still happen,
>> and solutions to it will have to be provided.
>>
>> > ... could be omitted from v1 of the data model.
>> I do not understand this comment. This use case describes how to use DIDs
>> to enable decentralized E2EE of sensitive PII, it does not proposes to
>> change data model.
>>
>>
>> Bohdan
>>
>> [1] - https://thenextweb.com/problem-solvers/2018/07/13/authenti
>> cation-cybersecurity/
>>
>>
>> On Thu, Jul 12, 2018 at 5:46 PM, David Chadwick <D.W.Chadwick@kent.ac.uk>
>> wrote:
>>
>>> Hi Bohdan
>>>
>>> On 11/07/2018 15:59, Bohdan Andriyiv 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",
>>>
>>> This is an extreme edge case. Firstly it is expected that the majority
>>> of holders will be the subjects themselves, and they obviously trust
>>> themselves.
>>>
>>> There is then a PR on subject NE holder to address these less common
>>> cases. Your example is a subset of these. We could add text to this PR
>>> to address this edge case if you want. Please add a comment to the PR if
>>> you would like me to do this.
>>>
>>> My initial response to your issue is 'the subject should not delegate to
>>> an unreliable holder, and the issuer should not issue to an unreliable
>>> holder' so this deals with the majority of the edge cases. Do you have a
>>> real use case where it is essential for a subject or issuer to give a VC
>>> to an unreliable holder (who also must not be the verifier, because I
>>> believe Terms of Use deals with Verifiers)
>>>
>>> > 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/2018
>>> Jul/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?
>>>
>>> I think your solution is complex and is for extreme edge cases only, so
>>> could be omitted from v1 of the data model.
>>>
>>> Regards
>>>
>>> David
>>>
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > On Wed, Jul 11, 2018 at 4:36 PM, Manu Sporny <
>>> msporny@digitalbazaar.com
>>> > <mailto: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
>>> >     <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
>>> >     <https://w3c.github.io/vc-data-model/#dfn-issuers>
>>> >     [2] https://w3c.github.io/vc-data-model/#dfn-holders
>>> >     <https://w3c.github.io/vc-data-model/#dfn-holders>
>>> >     [3] https://w3c.github.io/vc-data-model/#presentations
>>> >     <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
>>> >     <https://tinyurl.com/veres-one-launches>
>>> >
>>> >
>>>
>>>
>>
>