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

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