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

Hi Carlos, Heather, all,

I agree that this use case is very real. It can be re-phrased in a more
generic way - "Storing of sensitive PII by unreliable counterparty." You
provided a perfect example for this - "Giving your passport to AirBnB
host".

One straightforward approach to this is to introduce trusted
intermediaries, between identity owners and unreliable counterparty. The
logic goes like this:

   - Identity owner provides sensitive PII to intermediary.
   - Intermediary provides access to PII to "unreliable counterparty" for
   review. "Unreliable counterparty" is able to review PII, but not copy or
   store it.
   - "Unreliable counterparty"  decides if this PII is satisfactory to make
   a transaction with identity owner. After transaction is complete "unreliable
   counterparty"  loses access to PII.
   - If in the future, there is a situation that require identification of
   identity owner, this can be done by requesting PII from trusted
   intermediary.

Of course, this approach creates " PII honey pots". Now we might have big
unreliable processor of PII information (e.g. Equifax), instead or many
small unreliable PII processors.

It looks like we have "select between 2 evils" situation : "one big PII
processor" (potentially with good security practises?) *vs.* "many small
PII processors" (potentially with bad security practises?).

If I had to select, I would probably go with -  "many small PII processors"
and provided them with best tools to keep PII save with rules and laws to
enforce it.
But even if we have this it would still be a bad situation. Some of  "many
small PII processors"  will not have good faith, criminals will be able to
coerce, bribe, collude with them and hackers will be able to hack into
substantial number of "small unreliable PII processors".

Looks like unsolvable problem - "pick your own poison" situation.

Actually, with wide adoption of DIDs, there might be a solution.

This solution will require DIDs, best practises to ensure "*unlostable*
*access*" to DIDs, E2EE and trusted intermediary. The logic for this
solution goes like this:

   - Identity owner provides sensitive PII to intermediary.
   - Intermediary provides access to PII to "unreliable counterparty" for
   review. "Unreliable counterparty" is able to review PII, but not copy or
   store it.
   - "Unreliable counterparty"  decides if this PII is satisfactory to make
   a transaction with identity owner.
   - "Unreliable counterparty"  encrypts sensitive PII with its DID.
   Encrypted PII is stored on servers of intermediary.
      - Access to DID should be "unlostable". Guardians (e.g. government)
      should be able to recover access to DID if needed.
   - If there is a situation that require identification of identity owner,
   DID owner or guardians request PII from trusted intermediary and decrypt it
   using their DID.

By using this scheme, we took best from 2 worlds. We
1) encrypted PII in decentralized E2E way
2) collected encrypted PII into one "tar pot" (not interesting for hackers)
to be guarded by one trusted intermediary with the best security practises,
that ensures that access to encrypted PII is given only in correct
situations + provides additional layer of security

It is quite complex in practise implementation. It requires wide adoption
of DIDs and best practices with DIDs handling to ensure that access to
encrypted DID cannot be lost.
But if all is well done and polished, it should work and provide a lot more
security, than with 2 traditional approaches.

Do you think this approach is feasible? Is this the future? (I think
Microsoft is doing something similar with their hubs - can someone clarify?)

Bohdan









On Wed, Jul 11, 2018 at 7:53 AM, Carlos Bruguera <carlos@selfkey.org> wrote:

> I think this use case is very real and touches the core of self-sovereign
> identity. 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?
>
> On Thu, Jul 5, 2018 at 1:15 AM, heather vescent <heathervescent@gmail.com>
> wrote:
>
>> Hi All,
>>
>> This is a little short and sweet use for transaction/travel
>> identification. I'm unclear if this is a good use of DIDs or there may be
>> technology built to better solve this. Also, to fully solve this problem,
>> you'd need to have a solution that includes the verification of the
>> identification (DID) from a lot of small businesses.
>>
>> It has been added to the DID use case document: https://docs.google.
>> com/document/d/1wz8sakevXzO2OSMP341w7M2LjAMZfEQaTQEm_AOs3_Q/
>> edit?usp=sharing
>>
>> Again, this is a draft concept and can be fleshed out more. I look
>> forward to your comments and questions.
>>
>> -Heather
>>
>> ---
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *Name: Transaction Identification (e.g. travel use cases)Background:When
>> traveling, hotels and other businesses need identification information.
>> This is exacerbated when using new travel sites like AirBnB.Description:The
>> problem: requirement to share personal information with hotels. Their data
>> security is not secure. If one uses a stage name while traveling, you’ll
>> need to reconcile that with financial information that has a legal name.
>> With AirBnbs and other alternative hotels, individual hosts may want a copy
>> of the driver’s license of not just the renter, but all guests (hotels
>> often ask for this). But what are the security practices of these
>> individuals? How can you confirm/share identity information to the
>> satisfaction of the host/business owner and security PII of the user at the
>> same time? Whether the PII is collected in a computer database or on slips
>> of paper, there may be poor security practices. It is not the business of
>> the hotel to secure data, it is their business to provide overnight
>> accommodations. Thomas is a superhost in Joshua Tree and runs 3 AirBnBs.
>> Even though AirBnB validates the guests identification before a
>> reservation, Thomas always asks for a copy of their drivers license, which
>> he stores as a photograph in his person cloud.Angela is traveling for two
>> weeks on a roadtrip. Each night is at a different motel. Each motel asks
>> for identification information when registering for the room. Angela is
>> concerned with the security practices of the PII collected by these motels.
>>  Sticky Wicket: Identity information is needed for transactions, but the
>> people who collect and use this information have poor security practices -
>> thus creating risk for the collected data. These systems may be low hanging
>> fruit targets for hackers.Distinctive: Not sure if this is a good
>> application of DIDs. It might be a heavy weight solution to this problem.
>> There may be a better solution in conjunction with a specific payment
>> mechanism (credit cards).Potential adjacent use cases - Where to use
>> identity when traveling?- Stage names- Dead Name Club- In conjunction with
>> a travel AI/agent- Real estate wire transfer details- Buying property,
>> closing deals. Hacker has successfully phished a real estate agent, but
>> wait quietly until a wire transfer message is sent to one of their buyers.
>> After the legit real estate agent has sent the wire instructions, the
>> hacker emails the buyers with *updated* wire instructions from the phished
>> email account. The updated wire instructions go to the hacker’s bank
>> account. *
>>
>> --
>> 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 13:19:23 UTC