Date   
concerns about personal data hubs, identity hubs, EDV

Daniel Hardman
 

This email is a comment about the architecture that's beginning to coalesce around the data hub concept. It is not me trying to derail the effort--I think it's good and important--but me trying to raise a cautionary flag and trigger some thoughtful dialog.

In our understandable enthusiasm to solve a nagging problem for everyone, I am worried that we might end up losing two aspects of SSI that matter a lot:

1. disintermediation
2. identity through DIDs

Regarding disintermediation, a core value that I see in SSI is the notion that I--not some third party with a paternalistic posture that I have to trust to get anything done--am the authority for myself. If people want my data, they have to get it from me. If they want to see my credentials, they have to ask me for them, not somebody else. If they want my consent, they have to ask me for it, not somebody else. If I want to audit what's happening, I audit my own records, not somebody else's.

To the extent that the posture of a hub is closer to a brokering service for my data, configured by me but operated by a third party that requires me to trust it, I think this aspect of self-sovereignty is seriously weakened. The notion that I am putting the data into the hub in encrypted form does not, in and of itself, alleviate this concern for me; however, how the encryption is controlled might make me more or less concerned. Portability of data out of the hub into a different hub or something that's not a hub at all would make a difference, too.

Now, I get that not everybody in our decentralized identity circles is explicitly pursuing SSI. Some of us will be perfectly content to building something that's decentralized but not self-sovereign. And that is fine, IMO. But I would like the architecture of hubs not to preclude self-sovereign versions of hubs. This means that I would like it to be possible for Alice to put a hub interface behind her own identity (and her own DID) rather than the identity of a third party hub-serving intermediary. If we can design hub interfaces such that this is a first-class mode of operation, I will feel cheerful about this issue.

Regarding identity through DIDs: it feels ironic to me that we have spent vast amounts of energy talking about how to prove control of an identifier associated with a particular identity subject, through the DID mechanism--and we then throw our wood/energy behind an approach that exposes all personal data through intermediaries, where those intermediaries interact in both directions through a different security mechanism (TLS with certs and logins/API keys). If hubs are as important to identity as we think, and they take off, and if they are exclusively TLS-centric, we've basically cut the legs out from under DIDs.

I get that RESTful, TLS-central interaces are ubiquitous and easy, so it's worth exposing them. I am not opposed to a hub mechanism that includes that sort of interface; what I am worried about is a hub mechanism that doesn't also include a mechanism secured by DIDs and their keys, such that builders of hubs don't get limited just to orgs with certs and trust derived from CAs (the very trust architecture we are hoping to upgrade). Therefore, I am looking for any spec that gets written to include the ability to interface with hubs over DIDComm. This means that in the non-TLS mode, I ought to be able to authenticate the hub itself, plus any party that interacts with a hub, using the keys in my DID doc, NOT using certs and logins and API keys.

Re: Scope of PDS/IdH/EDV Discussion (Re: Invitation to Personal Data Hubs, Identity Hubs, EDV Roadmap Discussion)

Daniel Hardman
 

My point was that the contrast is misleading.

A more insightful contrast would be DIDComm vs. RESTful web services secured by certificates + user login. Both run over HTTP, and both are a "whole extra layer over simple HTTP."

On Sun, Nov 17, 2019 at 6:43 PM Lucas Tétreault <lucas@...> wrote:
The discussions I've heard indicate one of the goals of DIDComm is to be transport agnostic. Either way, it's still a whole extra layer over simple HTTP....


From: Daniel Hardman <daniel.hardman@...>
Sent: Sunday, November 17, 2019, 7:10 p.m.
To: Manu Sporny
Cc: Michael Herman (Parallelspace); Daniel Buchner; Sam Curren; aries@...; indy@...; Rouven Heck; W3C Credentials CG; Tobias Looker; Orie Steele; Dmitri Zagidulin
Subject: Re: Scope of PDS/IdH/EDV Discussion (Re: Invitation to Personal Data Hubs, Identity Hubs, EDV Roadmap Discussion)

Other protocol work, like communication over DIDComm,
  Bluetooth, CoAP, etc. should continue to be incubated at DIF and
  Aries.

HTTP and DIDComm are not alternatives to one another. DIDComm runs over HTTP.

Re: Scope of PDS/IdH/EDV Discussion (Re: Invitation to Personal Data Hubs, Identity Hubs, EDV Roadmap Discussion)

Daniel Hardman
 

Other protocol work, like communication over DIDComm,
  Bluetooth, CoAP, etc. should continue to be incubated at DIF and
  Aries.

HTTP and DIDComm are not alternatives to one another. DIDComm runs over HTTP.

Re: Invitation to Personal Data Hubs, Identity Hubs, EDV Roadmap Discussion

Daniel Hardman
 

After collaboration by a number of people in each community, there is a
technical/architectural approach that seems to be gaining momentum. ..
The conversation absolutely should not attempt to suggest new
technical/architectural approaches

That's fine.

However, I feel a need to express some concerns. Would you recommend that I do that by email?

Re: Invitation to Personal Data Hubs, Identity Hubs, EDV Roadmap Discussion

Stephen Curran
 

I don't really understand the points raised in the first reference - the slide deck. I know that Adrian presented this slide deck at this week's CCG Meeting. Is there a recording of that presentation available so we can better understand what we should gain from the presentation?

Thanks

On Fri, Nov 15, 2019 at 2:34 PM Manu Sporny <msporny@...> wrote:
Hi all,

There have been a set of discussions happening over the past several
months across the DIF, Aries, IIW, RWoT, and W3C CCG communities related
to personal data storage (aka Identity Hubs, Encrypted Data Vaults,
Secure Data Hubs, Solid Pods, etc.).

I've been speaking with a number of people in each community and it
seems like there is momentum to avoid duplication of effort. Key
individuals in the various communities have agreed to participate in a
call on neutral territory to work on the following items:

1. Discuss a plan on how we work together.
2. Discuss where the work could happen.
3. Discuss the Intellectual Property regime for the work.

To be clear, this call will not involve any discussion concerning
Intellectual Property or technical details. The purpose of the call is
to come to consensus out how all three communities will work together on
a common foundational layer related to personal data storage.

Please come to the call if you have an opinion about how you would like
this personal data storage work to progress across these various
communities. Please share this message with anyone that you feel should
be on this upcoming call.

Reading the following documents will help prepare yourself for the call:

https://docs.google.com/presentation/d/1OBgDCUNPsd6LKApO1nrQ3RuriCoZgls5_UsUN0rZOvk/edit?usp=sharing

https://github.com/decentralized-identity/identity-hub/blob/master/explainer.md

https://github.com/WebOfTrustInfo/rwot9-prague/raw/master/final-documents/encrypted-data-vaults.pdf

Dial in information for the call can be found below:

Time : 12pm ET - Friday, November 22nd, 2019 (next Friday)
Where: https://zoom.us/j/358615366

One tap mobile
+16468769923,,358615366# US (New York)
+14086380968,,358615366# US (San Jose)
Meeting ID: 358 615 366

Dial by your location
        +1 646 876 9923 US (New York)
        +1 408 638 0968 US (San Jose)
        +1 669 900 6833 US (San Jose)
Meeting ID: 358 615 366
Find your local number: https://zoom.us/u/acqUJFUODw

-- manu

--
Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Veres One Decentralized Identifier Blockchain Launches
https://tinyurl.com/veres-one-launches



--

Stephen Curran
Principal, Cloud Compass Computing, Inc. (C3I)
Technical Governance Board Member - Sovrin Foundation (sovrin.org)

Schedule a Meeting: https://calendly.com/swcurran

invitation to meeting about personal data hubs

Daniel Hardman
 

Posting this at Manu Sporny's request:

Hi all,

There have been a set of discussions happening over the past several
months across the DIF, Aries, IIW, RWoT, and W3C CCG communities related
to personal data storage (aka Identity Hubs, Encrypted Data Vaults,
Secure Data Hubs, Solid Pods, etc.).

I've been speaking with a number of people in each community and it
seems like there is momentum to avoid duplication of effort. Key
individuals in the various communities have agreed to participate in a
call on neutral territory to work on the following items:

1. Discuss a plan on how we work together.
2. Discuss where the work could happen.
3. Discuss the Intellectual Property regime for the work.

To be clear, this call will not involve any discussion concerning
Intellectual Property or technical details. The purpose of the call is
to come to consensus out how all three communities will work together on
a common foundational layer related to personal data storage.

Please come to the call if you have an opinion about how you would like
this personal data storage work to progress across these various
communities. Please share this message with anyone that you feel should
be on this upcoming call.

Reading the following documents will help prepare yourself for the call:

https://docs.google.com/presentation/d/1OBgDCUNPsd6LKApO1nrQ3RuriCoZgls5_UsUN0rZOvk/edit?usp=sharing

https://github.com/decentralized-identity/identity-hub/blob/master/explainer.md

https://github.com/WebOfTrustInfo/rwot9-prague/raw/master/final-documents/encrypted-data-vaults.pdf

Dial in information for the call can be found below:

Time : 12pm ET - Friday, November 22nd, 2019 (next Friday)
Where: https://zoom.us/j/358615366

One tap mobile
+16468769923,,358615366# US (New York)
+14086380968,,358615366# US (San Jose)
Meeting ID: 358 615 366

Dial by your location
        +1 646 876 9923 US (New York)
        +1 408 638 0968 US (San Jose)
        +1 669 900 6833 US (San Jose)
Meeting ID: 358 615 366
Find your local number: https://zoom.us/u/acqUJFUODw

-- manu

Re: Invitation to Personal Data Hubs, Identity Hubs, EDV Roadmap Discussion

Daniel Hardman
 

Thanks.

I have reposted this on the Rocket.Chat instance used by the Aries community.

On Fri, Nov 15, 2019 at 3:32 PM Manu Sporny <msporny@...> wrote:
Hi all,

There have been a set of discussions happening over the past several
months across the DIF, Aries, IIW, RWoT, and W3C CCG communities related
to personal data storage (aka Identity Hubs, Encrypted Data Vaults,
Secure Data Hubs, Solid Pods, etc.).

I've been speaking with a number of people in each community and it
seems like there is momentum to avoid duplication of effort. Key
individuals in the various communities have agreed to participate in a
call on neutral territory to work on the following items:

1. Discuss a plan on how we work together.
2. Discuss where the work could happen.
3. Discuss the Intellectual Property regime for the work.

To be clear, this call will not involve any discussion concerning
Intellectual Property or technical details. The purpose of the call is
to come to consensus out how all three communities will work together on
a common foundational layer related to personal data storage.

Please come to the call if you have an opinion about how you would like
this personal data storage work to progress across these various
communities. Please share this message with anyone that you feel should
be on this upcoming call.

Reading the following documents will help prepare yourself for the call:

https://docs.google.com/presentation/d/1OBgDCUNPsd6LKApO1nrQ3RuriCoZgls5_UsUN0rZOvk/edit?usp=sharing

https://github.com/decentralized-identity/identity-hub/blob/master/explainer.md

https://github.com/WebOfTrustInfo/rwot9-prague/raw/master/final-documents/encrypted-data-vaults.pdf

Dial in information for the call can be found below:

Time : 12pm ET - Friday, November 22nd, 2019 (next Friday)
Where: https://zoom.us/j/358615366

One tap mobile
+16468769923,,358615366# US (New York)
+14086380968,,358615366# US (San Jose)
Meeting ID: 358 615 366

Dial by your location
        +1 646 876 9923 US (New York)
        +1 408 638 0968 US (San Jose)
        +1 669 900 6833 US (San Jose)
Meeting ID: 358 615 366
Find your local number: https://zoom.us/u/acqUJFUODw

-- manu

--
Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Veres One Decentralized Identifier Blockchain Launches
https://tinyurl.com/veres-one-launches

Re: Trust of first use question - invitations between DIDs and MITM

Daniel Hardman
 

Manas, your scenario could theoretically happen, but it assumes a carelessness by B that feels unrealistic to me. Essentially, B is deciding to share private info with an unknown stranger. If B decides to do that, then of course bad things can happen--but the bad things are the result of B's bad decision, not the result of a protocol that lacks key protections.

ALL proving with verifiable credentials, whether it uses Indy or not, and whether it's related to connecting/DID exchange or not, should ALWAYS begin with the question, "Do I really want to prove these facts to the other party?" I would not prove my date of birth and SSN to a complete stranger, remotely, using today's physical credentials--so why would I prove it using tomorrow's verifiable credential ecosystem?

When the verifier is an institution (which is the most common variant of use cases that most people in the VC space are implementing today), then the verifier has less privacy concerns than the private individual, so the verifier should prove first--not in parallel. Example: verifier is Thrift Bank, and asks Alice to prove her SSN and date of birth. Before Alice decides whether to honor the request, she says, "Prove who you are" -- and Thrift Bank does so. Once Alice knows who she's talking to, she then decides whether to reveal the PII that's being requested. Not before.

This gets harder when both parties are private individuals, because then you can have a chicken-and-egg problem. But in those cases, I believe that one or both of the following conditions will usually be true:

A. There's some supporting context that makes the proving more reasonable. For example, the two parties just met face-to-face at a conference, are standing next to one another, and have already reached a certain level of trust. Or one individual is a seller on Amazon and the other is a potential buyer; the the seller can reasonably prove seller reputation to start the sharing.

B. Trust can be ratcheted in stages. Instead of going straight for sensitive PII like a social security number, you could begin by disclosing low-trust things (prove that you're a ticket holder for this plane flight; prove your initials and the zip code you live in), and you only get to the high-risk proofs once you've laid an appropriate foundation. This ratcheting is particularly easy when you have predicates and ZKPs, but it can also be done with other credential types.

Re: Trust of first use question - invitations between DIDs and MITM

Oskar van Deventer
 

Hi Manas,

DID-based communications only happen after establishing a DID relationship. Private persons may not have public invitation information open for phishers to use. Moreover, it is a good practice that the party who contacts you identifies themselves first. One should never pass any sensitive credentials to a party that has been insufficiently identified.

Still, SSI is about self-sovereignty. So your policy how to respond to phishers may be different from mine, including a definition of what constitutes an "arbitrary requests of attributes". We could document some best practices if we deem that useful.

Oskar

Re: Trust of first use question - invitations between DIDs and MITM

Manas Pratim
 

 
Hi Stephen, 
 
How do we use proof of a verifiable credential when establishing a peer DID relationship? I was wondering, if a regular proof request/presentation exchange (eg. the one used in the Aries demo) can be used in this case, but it may open up avenues for data leak. 
 
1. Let us assume the attacker DID A is interested in knowing only certain information, say the date of birth or the SSN Social Security Number, of DID B and nothing more. He sends an invitation to B for a peer connection. Once the invitation is accepted by B, A will request for a proof presentation from DID B (with the DOB or SSN as attributes) to continue the relationship. Let us assume that the information requested is such that predicates cannot be used.
 
2. In return, the honest DID B can ask for the same from DID A. DID A can provide a fabricated claim about itself since it is not interested whether the claim’s verification is successful or not. So proofs of both parties are exchanged.
 
3. By the time DID B knows that A's claim fails, A would have already obtained the required attributes it is looking for from B. B breaks down the peer connection, but A does not care since it has already got the required information. 
 
It is a typical phishing case where DID A forces DID B to reveal some information about itself using a verifiable claim in the initial stages of setting up a peer relationship.
 
Is my understanding correct?
 
Is there a standard/method that specifies what claims can be used for establishing a peer relationship or something that prohibits arbitrary requests of attributes?
 
Regards,
Manas
 
 

Re: Problem with implementing online shopping problem in Hyperledger Indy

Soo Min Lee
 

Daniel Harman:

I agree that it is needed more unique number per person in that scenario. Anyway, another problem is that the online shopping mall have to keep these numbers either credit card number or passport number to identify uniqueness of the number.

I need a way to find out if a number has been used before, without having to keep it all.



2019년 10월 15일 (화) 오전 2:00, Daniel Hardman <daniel.hardman@...>님이 작성:

Zahra:

It sounds like you want each buyer and seller to have a single account, such that they cannot manipulate their reputations by reviewing the same item or the same buyer/seller multiple times to inflate or deflate the average rating. An easy way to do this is to require each buyer and seller to prove to the system, when they create their account, that they control a credit card--and require them to disclose the credit card number to you in that proof. Then, don't allow the same credit card number to be used in more than one account, and don't allow a given account to rate the same item or buyer more than once per transaction.

If you don't want to use credit cards for your uniqueness, there is a way you can use the link secret to do the same thing. That's an advanced topic that I'll skip for now.

You might say, "Yes, but Alice and Bob might each have multiple credit cards, and might be able to set up multiple accounts that way." This is true, and if you truly want to force uniqueness per person, you can do something more draconian, like use a passport number instead of a credit card number as the source of uniqueness.

But before you go to that extremem, oonsider the following scenarios:

A) Alice wants to register multiple DIDs as a seller, because she has two businesses. One is for hand-made crafts that she does. The other is for used books that she sells. She would like her reputation as a seller of hand-made crafts to be different from her reputation as a seller of books.

B) Bob buys a lot of stuff online for himself, but he also buys a lot online for his company. He'd like to have two buyer accounts--one for personal buying, and one for company buying.

If you want to support either of these scenarios, then the credit card uniqueness is probably as far as you want to go.

Re: Address verification service

Daniel Hardman
 

The folks at BCGov have done a proof-of-email-address VC. I don't know if anyone is doing proof-of-physical-address.

Address verification service

malux@...
 

Hi WG members,

Question for the community: address is a common type of verifiable credential for a number of application and I was wondering if anyone in the group was working toward providing reusable proof of address, as POC or production?

Cheers and please do not hesitate to reach out.

Matt

Speaker for Cambridge meet-up in December

Marta Piekarska
 

Hi everyone 
I’m helping to organise Hyperledger Cambridge meet-up. We've tentatively set up the date to 3rd of December. It would be really great if someone who knows Hyperledger Indy could come as a speaker. If anyone of you is available please drop me a line.
Have a few day
m

Marta Piekarska-Geater
Director of Ecosystem, Hyperledger

SCHEDULE A MEETING WITH ME: calendly.com/mpiekarska


marta@...
+447802336641 (U.K) - Signal and Whatsapp
Wickr: martap

Skype: martapiekarska

Based in the U.K.

Re: Upcoming Event: Hyperledger Indy Quarterly Update Due #tsc-project-update - Thu, 10/31/2019 #tsc-project-update #cal-reminder

Denis Zenin
 

Dear Indy community, good day to everyone,

Some time ago I received this reminder about Quarterly Update, but unfortunately I could not find any details on how to join the call.
Is it happening today, and if it is could you please share some detail on how to dial in?

Have a great day everyone,
Kind regards,
Denis



On Thu, Oct 24, 2019 at 8:00 AM indy@... Calendar <indy@...> wrote:

Reminder: Hyperledger Indy Quarterly Update Due #tsc-project-update

When: Thursday, 31 October 2019

View Event

Organizer: community-architects@...

Description: The Hyperledger Indy update to the TSC is due 28 October, 2019.

Please be sure that someone from the community completes the update and is available to present it to the TSC on 31 October, 2019
.



--
Kind regards,
Denis

Upcoming Event: Hyperledger Indy Quarterly Update Due #tsc-project-update - Thu, 10/31/2019 #tsc-project-update #cal-reminder

indy@lists.hyperledger.org Calendar <indy@...>
 

Reminder: Hyperledger Indy Quarterly Update Due #tsc-project-update

When: Thursday, 31 October 2019

View Event

Organizer: community-architects@...

Description: The Hyperledger Indy update to the TSC is due 28 October, 2019.

Please be sure that someone from the community completes the update and is available to present it to the TSC on 31 October, 2019
.

Re: Trust of first use question - invitations between DIDs and MITM

Alexander Blom
 

Hello all,


My two cents regarding Rouvens use cases:
The bartender seems to have little confidence in the access protection of the app or wallet containing the verifiable credentials that show the customers age. This can be solved by adding more credentials (i.e. a photo) that can be checked visually of course, but SSI could solve the problem as well, by adding more security such as biometrics to the wallet.

The car rental company could ask the driver for proof of address, to be used in case of an accident, but SSI could offer the same level of recourse, by having the rental company ask the customer for a verifiable credential proving that the customer will pay its share in case of an accident. This credential would need to be backed by the bank etc.

In the same fashion, the relationship between the loan company and the customer can be broken down to a number of verifiable credentials that the customer would have to present.

The bar, the rental company and the loan company and their respective customers, it seems that the legal interdependency of all of these relationships can be broken down to SSI type exchanges of different credentials, and do not need extra personal data to make the transaction legally or financially more secure. It also seems that an SSI-approach would represent the interests of the parties involved in a much more accurate fashion then the current haphazardous practice of exchanging an abundance of credentials can.

(@Oskar) Fortunately, already now there are many cases where at least in GDPR conscious Europe, SSI is the solution that fits the legal environment better than any other identity framework. Think of the approval of the customer at every transaction, the right to refuse the transferene of personal data, the right to be forgotten etc., all of which are natural to SSI but quite complicated to implement in more classical identity environments.

So there is a place to start, but I quite agree that enabling information minimization, while still achieving the purpose of the laws is the SSI discussion of the years ahead of us. Starting by explaining to law makers what SSI is really all about of course:-)

Op 21 oktober 2019 om 16:02 schreef "Oskar van Deventer via Lists.Hyperledger.Org" <oskar.vandeventer=tno.nl@...>:

All,

 

Very interesting discussion.

 

The “asking too much information” issue usually has a legal basis, where there is a law that says what information is required to be requested, verified and archived. Postal mail addresses are rarely used by companies to communicate with customers. Also birth dates and place are rarely needed for the offered service. The technical requirement is often “to have sufficient information to send a lawsuit in case of non-payment or fraud”. Such lawsuits are by law required to be delivered in person to a postal address, at least in my country. Other examples are KYC, AML and ATF legal requirements.

 

How could we/Indy enable information minimization, while still achieving the purpose of those laws? Only then, we could argue/lobby the modernization of such laws.

 

Oskar

 

 

From: indy@... <indy@...> On Behalf Of Samuel Smith
Sent: 19 October 2019 19:46
To: Kyle Den Hartog <kdenhar@...>
Cc: Rouven Heck <rouven.heck@...>; Stephen Curran <swcurran@...>; Richard Esplin <richard.esplin@...>; mbhattac@...; indy@... Calendar <indy@...>
Subject: Re: [Hyperledger Indy] Trust of first use question - invitations between DIDs and MITM

 

As per my previous post all that is needed is some information of the right kind  exclusive to Alice and bob that Eve is not privy too to allow detection of Eve.  For example a public signing key or encryption key is minimal or a live side channel. Absent that, then increasing levels of correlatable information that at some point exceed the ability of Eve to impersonate. The key is exclusive information that exists onsite of the channel Eve controls. Coo relatable in this case means correctable to other information outside of the eve controlled channel



On Oct 19, 2019, at 04:09, Kyle Den Hartog <kdenhar@...> wrote:

Rouven you’re correct in what you’re saying as well. I was looking at the benefits of correlation from a different perspective. The point you raise about business processes requiring additional data typically is complimentary to my thinking that correlation is beneficial to the security guarantees when using verifiable credentials as a method to detect a MITM attack. In both cases, a holder providing additional data can be viewed as beneficial. 

 

My concerns around balancing correlation was more a point of trying to provide a disclaimer to my statement around correlation being beneficial to detect a MITM attack. While it is useful for detecting MITM attacks, I didn’t want to leave the reader with the impression that the solution that requesting as much data as possible is the best solution. Rather, I think there’s a middle ground between requesting too much information and requesting too little information. This is where I think more research would be quite useful. I haven’t seen anyone provide research into what the bounds of “too much” and “too little” really are. For example, is providing my location data to Facebook really necessary? Probably not. But is providing my entire medical history to my doctor useful? Absolutely! This is the balance that I want us to look at more so we can provide good recommendations to industries about the data they should be requesting to balance the needs of privacy with the needs of doing business. 

 

Hopefully this explains my thinking a bit better.

On Friday, October 18, 2019, Rouven Heck <rouven.heck@...> wrote:

Thanks - this is really helpful!

 

I understand the concerns about 'requesting too much data' and correlation risks but isn't it anyway required in many use-cases? E.g. I assume much more data is required for the replying party to offer a service like a loan, insurance or just renting a car...

 

I'm not an Indy expert at all, so please correct me! 

 

Theoretically, a ZK proof of (non-revoked) driver license might be sufficient? But in reality, wouldn't a rental company want the full name, day of birth, address, etc. - to make sure in case of an incident they have all the information to make legal claims to that specific individual in front of a court? Even if I 'enter the bar' use-case - I likely need to show some kind of biometrics (aka my photo) + the 21+ proof to be correctly identified by the security person? 

 

Do I miss something here? 

 

It would be great to have some additional practical examples to explore these models better. 

 

Best,

Rouven

 

 

 

 

 

On Wed, Oct 16, 2019 at 8:27 PM Kyle Den Hartog <kdenhar@...> wrote:

Stephen is absolutely correct in what he said. The one caveat that pops up with this solution is that the requested proof must be unique enough (aka this is a probabilistic solution) that the active attacker (Eve) is unable to also produce the proof. For example, if the proof request only wanted proof of over 21 then it likely wouldn't be good enough because Eve is probabilistically very likely to be able to prove she's over 21 as Alice. In this case, Bob wouldn't be able to detect the MITM.

This is one of the few times where correlation of attributes can be beneficial. With that said, I would strongly discourage verifiers requesting too much data to have an excess of certainty. It's a balance that has to be struck depending on the risk the verifier is willing to tolerate. A good rule of thumb is that requesting 3 attributes is usually good enough. More investigation should be done around this area to provide stronger recommendations around usage of verifiable credentials to demonstrate probabilistic uniqueness that balances privacy with risk tolerance of a verifier.


Kyle Den Hartog

 

 

On Thu, Oct 17, 2019 at 12:20 PM Stephen Curran <swcurran@...> wrote:

The specific feature that I'm told will be in Anoncreds 2.0 is that self-attested claims will be signed using the same link secret as other claims. That is a requirement of the W3Cs new VC standard. How that applies here is a bit esoteric, but here is the attack and mitigation.

 

Attack:

  • Eve intercepts the invitation from Alice to Bob.  Eve responds to the invitation to Alice.  Eve creates a new invitation and sends it to Bob.  Both invitations/requests are processed and Alice and Bob both think they are speaking to one another.
  • To be sure, Alice sends a proof request to Bob to verify Bob is indeed Bob.  Eve proxies the identical proof request over to Bob, and Bob responds with a proof.  Eve sends the proof to Alice as if she had generated it. Alice checks the proof, sees Bob is Bob and carries on.  Bob might do the same for Alice and Eve would handle it the same way.
  • Eve relays (and can see) all messages between Alice and Bob, intervening when necessary.  
    • Note: It's not easy for Eve to orchestrate these events, so this is likely not an easy attack.

Mitigation with signed self-attested claims:

  • Bob includes in the proof a signed, self-attested claim derived from the peer DID used to establish the relationship (e.g. the public key or even the DID itself).
  • Since the Bob-Eve DID is different from the Eve-Alice DID, if Eve just passes on the proof to Alice, Alice will detect the difference and be aware of the MITM.

 

On Wed, Oct 16, 2019 at 2:21 PM Richard Esplin <richard.esplin@...> wrote:

This is a useful conversation.

Stephen: What features in Anoncreds 2.0 will help detect MITM attacks?

-- Richard

On Mon, 2019-10-14 at 15:30 -0700, Stephen Curran wrote:
> Your scenario is a good one, and is one that should always be
> considered.
>
> In response to your questions:
>
> 1. The creator of the invitation can decide if the invitation is a
> "use once" or "use many times" invitation and hence if Alice is able
> to use it after Eve. If it is a use once, Alice's response would be
> rejected. If a use many times, it would be accepted.  Obviously in
> the latter, the inviter would be expecting many responses and so
> wouldn't care it Eve, Mallory, Alice or anyone else responded.
>
> 2. The basic answer is that unless we are certain of the path of the
> invitation and are certain it is going to Alice (e.g. we are in the
> same room together and you can see Alice responding), we can't know
> for sure that there is no MITM. Hence, there is a need to verify the
> recipient after establishment of the connection. The approach our
> team (BC Gov) is expecting to use for that is a proof of a verifiable
> credential.  If it is crucial for us to know that we are talking to
> Alice, a DID connection is generally not sufficient and we will need
> Alice to prove who she is some other way that we do trust.
>
> Note that even then, there is a slight chance that Eve could
> establish herself between Alice and I and proxy (for example) the
> communications, including proof requests and proofs between the two
> parties (myself and Alice). While extremely unlikely, that is
> possible with the current Indy technology.  We expect in future
> revisions (notably, as part of the "anoncreds 2.0" effort) that there
> will be a way to detect that and prevent that type of attack.
>
> Hope that helps.
>
> On Mon, Oct 14, 2019 at 8:11 AM <mbhattac@...>
> wrote:
> > I am doing some experiments on the trust of first use problem when
> > creating relationships between DIDs on Indy. I setup Alice and
> > Faber agents, generate an invitation from the Faber agent so that
> > Alice can connect and form a relationship. Instead of using the
> > invitation on Alice's agent, I setup another agent Eve and consume
> > the invitation in Eve's agent, instead of Alice's, and Eve gets
> > connected to Faber. Eve is acting as a man-in-the-middle (MITM)
> > here.
> >
> >
> >
> > My questions:
> >
> > 1. Can the same invitation be reused again by Alice after Eve? Are
> > invitation_key, request_id and connection_id the binding factors,
> > if not?
> > 2. How can we make sure that only Alice can use this invitation? OR
> > What can prevent the use of an invitation intercepted by a man-in-
> > the-middle (MITM)?
> >
> >
>
>


 

--

Stephen Curran
Principal, Cloud Compass Computing, Inc. (C3I)
Technical Governance Board Member - Sovrin Foundation (sovrin.org)

Schedule a Meeting: https://calendly.com/swcurran



--

Kyle Den Hartog

 

 

 

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.


 

Re: Trust of first use question - invitations between DIDs and MITM

Oskar van Deventer
 

All,

 

Very interesting discussion.

 

The “asking too much information” issue usually has a legal basis, where there is a law that says what information is required to be requested, verified and archived. Postal mail addresses are rarely used by companies to communicate with customers. Also birth dates and place are rarely needed for the offered service. The technical requirement is often “to have sufficient information to send a lawsuit in case of non-payment or fraud”. Such lawsuits are by law required to be delivered in person to a postal address, at least in my country. Other examples are KYC, AML and ATF legal requirements.

 

How could we/Indy enable information minimization, while still achieving the purpose of those laws? Only then, we could argue/lobby the modernization of such laws.

 

Oskar

 

 

From: indy@... <indy@...> On Behalf Of Samuel Smith
Sent: 19 October 2019 19:46
To: Kyle Den Hartog <kdenhar@...>
Cc: Rouven Heck <rouven.heck@...>; Stephen Curran <swcurran@...>; Richard Esplin <richard.esplin@...>; mbhattac@...; indy@... Calendar <indy@...>
Subject: Re: [Hyperledger Indy] Trust of first use question - invitations between DIDs and MITM

 

As per my previous post all that is needed is some information of the right kind  exclusive to Alice and bob that Eve is not privy too to allow detection of Eve.  For example a public signing key or encryption key is minimal or a live side channel. Absent that, then increasing levels of correlatable information that at some point exceed the ability of Eve to impersonate. The key is exclusive information that exists onsite of the channel Eve controls. Coo relatable in this case means correctable to other information outside of the eve controlled channel



On Oct 19, 2019, at 04:09, Kyle Den Hartog <kdenhar@...> wrote:

Rouven you’re correct in what you’re saying as well. I was looking at the benefits of correlation from a different perspective. The point you raise about business processes requiring additional data typically is complimentary to my thinking that correlation is beneficial to the security guarantees when using verifiable credentials as a method to detect a MITM attack. In both cases, a holder providing additional data can be viewed as beneficial. 

 

My concerns around balancing correlation was more a point of trying to provide a disclaimer to my statement around correlation being beneficial to detect a MITM attack. While it is useful for detecting MITM attacks, I didn’t want to leave the reader with the impression that the solution that requesting as much data as possible is the best solution. Rather, I think there’s a middle ground between requesting too much information and requesting too little information. This is where I think more research would be quite useful. I haven’t seen anyone provide research into what the bounds of “too much” and “too little” really are. For example, is providing my location data to Facebook really necessary? Probably not. But is providing my entire medical history to my doctor useful? Absolutely! This is the balance that I want us to look at more so we can provide good recommendations to industries about the data they should be requesting to balance the needs of privacy with the needs of doing business. 

 

Hopefully this explains my thinking a bit better.

On Friday, October 18, 2019, Rouven Heck <rouven.heck@...> wrote:

Thanks - this is really helpful!

 

I understand the concerns about 'requesting too much data' and correlation risks but isn't it anyway required in many use-cases? E.g. I assume much more data is required for the replying party to offer a service like a loan, insurance or just renting a car...

 

I'm not an Indy expert at all, so please correct me! 

 

Theoretically, a ZK proof of (non-revoked) driver license might be sufficient? But in reality, wouldn't a rental company want the full name, day of birth, address, etc. - to make sure in case of an incident they have all the information to make legal claims to that specific individual in front of a court? Even if I 'enter the bar' use-case - I likely need to show some kind of biometrics (aka my photo) + the 21+ proof to be correctly identified by the security person? 

 

Do I miss something here? 

 

It would be great to have some additional practical examples to explore these models better. 

 

Best,

Rouven

 

 

 

 

 

On Wed, Oct 16, 2019 at 8:27 PM Kyle Den Hartog <kdenhar@...> wrote:

Stephen is absolutely correct in what he said. The one caveat that pops up with this solution is that the requested proof must be unique enough (aka this is a probabilistic solution) that the active attacker (Eve) is unable to also produce the proof. For example, if the proof request only wanted proof of over 21 then it likely wouldn't be good enough because Eve is probabilistically very likely to be able to prove she's over 21 as Alice. In this case, Bob wouldn't be able to detect the MITM.

This is one of the few times where correlation of attributes can be beneficial. With that said, I would strongly discourage verifiers requesting too much data to have an excess of certainty. It's a balance that has to be struck depending on the risk the verifier is willing to tolerate. A good rule of thumb is that requesting 3 attributes is usually good enough. More investigation should be done around this area to provide stronger recommendations around usage of verifiable credentials to demonstrate probabilistic uniqueness that balances privacy with risk tolerance of a verifier.


Kyle Den Hartog

 

 

On Thu, Oct 17, 2019 at 12:20 PM Stephen Curran <swcurran@...> wrote:

The specific feature that I'm told will be in Anoncreds 2.0 is that self-attested claims will be signed using the same link secret as other claims. That is a requirement of the W3Cs new VC standard. How that applies here is a bit esoteric, but here is the attack and mitigation.

 

Attack:

  • Eve intercepts the invitation from Alice to Bob.  Eve responds to the invitation to Alice.  Eve creates a new invitation and sends it to Bob.  Both invitations/requests are processed and Alice and Bob both think they are speaking to one another.
  • To be sure, Alice sends a proof request to Bob to verify Bob is indeed Bob.  Eve proxies the identical proof request over to Bob, and Bob responds with a proof.  Eve sends the proof to Alice as if she had generated it. Alice checks the proof, sees Bob is Bob and carries on.  Bob might do the same for Alice and Eve would handle it the same way.
  • Eve relays (and can see) all messages between Alice and Bob, intervening when necessary.  
    • Note: It's not easy for Eve to orchestrate these events, so this is likely not an easy attack.

Mitigation with signed self-attested claims:

  • Bob includes in the proof a signed, self-attested claim derived from the peer DID used to establish the relationship (e.g. the public key or even the DID itself).
  • Since the Bob-Eve DID is different from the Eve-Alice DID, if Eve just passes on the proof to Alice, Alice will detect the difference and be aware of the MITM.

 

On Wed, Oct 16, 2019 at 2:21 PM Richard Esplin <richard.esplin@...> wrote:

This is a useful conversation.

Stephen: What features in Anoncreds 2.0 will help detect MITM attacks?

-- Richard

On Mon, 2019-10-14 at 15:30 -0700, Stephen Curran wrote:
> Your scenario is a good one, and is one that should always be
> considered.
>
> In response to your questions:
>
> 1. The creator of the invitation can decide if the invitation is a
> "use once" or "use many times" invitation and hence if Alice is able
> to use it after Eve. If it is a use once, Alice's response would be
> rejected. If a use many times, it would be accepted.  Obviously in
> the latter, the inviter would be expecting many responses and so
> wouldn't care it Eve, Mallory, Alice or anyone else responded.
>
> 2. The basic answer is that unless we are certain of the path of the
> invitation and are certain it is going to Alice (e.g. we are in the
> same room together and you can see Alice responding), we can't know
> for sure that there is no MITM. Hence, there is a need to verify the
> recipient after establishment of the connection. The approach our
> team (BC Gov) is expecting to use for that is a proof of a verifiable
> credential.  If it is crucial for us to know that we are talking to
> Alice, a DID connection is generally not sufficient and we will need
> Alice to prove who she is some other way that we do trust.
>
> Note that even then, there is a slight chance that Eve could
> establish herself between Alice and I and proxy (for example) the
> communications, including proof requests and proofs between the two
> parties (myself and Alice). While extremely unlikely, that is
> possible with the current Indy technology.  We expect in future
> revisions (notably, as part of the "anoncreds 2.0" effort) that there
> will be a way to detect that and prevent that type of attack.
>
> Hope that helps.
>
> On Mon, Oct 14, 2019 at 8:11 AM <mbhattac@...>
> wrote:
> > I am doing some experiments on the trust of first use problem when
> > creating relationships between DIDs on Indy. I setup Alice and
> > Faber agents, generate an invitation from the Faber agent so that
> > Alice can connect and form a relationship. Instead of using the
> > invitation on Alice's agent, I setup another agent Eve and consume
> > the invitation in Eve's agent, instead of Alice's, and Eve gets
> > connected to Faber. Eve is acting as a man-in-the-middle (MITM)
> > here.
> >
> >
> >
> > My questions:
> >
> > 1. Can the same invitation be reused again by Alice after Eve? Are
> > invitation_key, request_id and connection_id the binding factors,
> > if not?
> > 2. How can we make sure that only Alice can use this invitation? OR
> > What can prevent the use of an invitation intercepted by a man-in-
> > the-middle (MITM)?
> >
> >
>
>


 

--

Stephen Curran
Principal, Cloud Compass Computing, Inc. (C3I)
Technical Governance Board Member - Sovrin Foundation (sovrin.org)

Schedule a Meeting: https://calendly.com/swcurran



--

Kyle Den Hartog

 

 

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

Invitation: Hyperledger Indy SDK coordination @ Every 2 weeks from 07:00 to 07:50 on Wednesday (PDT) (indy@lists.hyperledger.org)

Ry Jones <rjones@...>
 

You have been invited to the following event.

Hyperledger Indy SDK coordination

When
Every 2 weeks from 07:00 to 07:50 on Wednesday Pacific Time - Los Angeles
Where
https://zoom.us/j/6385450258 (map)
Calendar
indy@...
Who
Ry Jones - creator
richard.esplin@...
indy@...
ibrahim.elrhezzali@...
mattr@...
Reserving a time every two weeks to coordinate efforts on the Indy SDK.
This does not replace our asynchronous collaboration, but should help
us keep everyone up-to-date and moving forward.

Agenda:

https://docs.google.com/document/d/12thubl-h8L09drqt3Bjb3EOqr4-32UJtUAqALc928I8/edit

Discussion items:
* Upcoming releases
* Current PRs
* Work that will generate future PRs
* Architecture changes that will impact downstream teams
* Project standards, best practices, design, etc.

Going (indy@...)?   All events in this series:   Yes - Maybe - No    more options »

Invitation from Google Calendar

You are receiving this courtesy email at the account indy@... because you are an attendee of this event.

To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.

Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn More.

Re: Trust of first use question - invitations between DIDs and MITM

Samuel Smith
 

As per my previous post all that is needed is some information of the right kind  exclusive to Alice and bob that Eve is not privy too to allow detection of Eve.  For example a public signing key or encryption key is minimal or a live side channel. Absent that, then increasing levels of correlatable information that at some point exceed the ability of Eve to impersonate. The key is exclusive information that exists onsite of the channel Eve controls. Coo relatable in this case means correctable to other information outside of the eve controlled channel


On Oct 19, 2019, at 04:09, Kyle Den Hartog <kdenhar@...> wrote:

Rouven you’re correct in what you’re saying as well. I was looking at the benefits of correlation from a different perspective. The point you raise about business processes requiring additional data typically is complimentary to my thinking that correlation is beneficial to the security guarantees when using verifiable credentials as a method to detect a MITM attack. In both cases, a holder providing additional data can be viewed as beneficial. 

My concerns around balancing correlation was more a point of trying to provide a disclaimer to my statement around correlation being beneficial to detect a MITM attack. While it is useful for detecting MITM attacks, I didn’t want to leave the reader with the impression that the solution that requesting as much data as possible is the best solution. Rather, I think there’s a middle ground between requesting too much information and requesting too little information. This is where I think more research would be quite useful. I haven’t seen anyone provide research into what the bounds of “too much” and “too little” really are. For example, is providing my location data to Facebook really necessary? Probably not. But is providing my entire medical history to my doctor useful? Absolutely! This is the balance that I want us to look at more so we can provide good recommendations to industries about the data they should be requesting to balance the needs of privacy with the needs of doing business. 

Hopefully this explains my thinking a bit better.

On Friday, October 18, 2019, Rouven Heck <rouven.heck@...> wrote:
Thanks - this is really helpful!

I understand the concerns about 'requesting too much data' and correlation risks but isn't it anyway required in many use-cases? E.g. I assume much more data is required for the replying party to offer a service like a loan, insurance or just renting a car...

I'm not an Indy expert at all, so please correct me! 

Theoretically, a ZK proof of (non-revoked) driver license might be sufficient? But in reality, wouldn't a rental company want the full name, day of birth, address, etc. - to make sure in case of an incident they have all the information to make legal claims to that specific individual in front of a court? Even if I 'enter the bar' use-case - I likely need to show some kind of biometrics (aka my photo) + the 21+ proof to be correctly identified by the security person? 

Do I miss something here? 

It would be great to have some additional practical examples to explore these models better. 

Best,
Rouven





On Wed, Oct 16, 2019 at 8:27 PM Kyle Den Hartog <kdenhar@...> wrote:
Stephen is absolutely correct in what he said. The one caveat that pops up with this solution is that the requested proof must be unique enough (aka this is a probabilistic solution) that the active attacker (Eve) is unable to also produce the proof. For example, if the proof request only wanted proof of over 21 then it likely wouldn't be good enough because Eve is probabilistically very likely to be able to prove she's over 21 as Alice. In this case, Bob wouldn't be able to detect the MITM.

This is one of the few times where correlation of attributes can be beneficial. With that said, I would strongly discourage verifiers requesting too much data to have an excess of certainty. It's a balance that has to be struck depending on the risk the verifier is willing to tolerate. A good rule of thumb is that requesting 3 attributes is usually good enough. More investigation should be done around this area to provide stronger recommendations around usage of verifiable credentials to demonstrate probabilistic uniqueness that balances privacy with risk tolerance of a verifier.

Kyle Den Hartog


On Thu, Oct 17, 2019 at 12:20 PM Stephen Curran <swcurran@...> wrote:
The specific feature that I'm told will be in Anoncreds 2.0 is that self-attested claims will be signed using the same link secret as other claims. That is a requirement of the W3Cs new VC standard. How that applies here is a bit esoteric, but here is the attack and mitigation.

Attack:
  • Eve intercepts the invitation from Alice to Bob.  Eve responds to the invitation to Alice.  Eve creates a new invitation and sends it to Bob.  Both invitations/requests are processed and Alice and Bob both think they are speaking to one another.
  • To be sure, Alice sends a proof request to Bob to verify Bob is indeed Bob.  Eve proxies the identical proof request over to Bob, and Bob responds with a proof.  Eve sends the proof to Alice as if she had generated it. Alice checks the proof, sees Bob is Bob and carries on.  Bob might do the same for Alice and Eve would handle it the same way.
  • Eve relays (and can see) all messages between Alice and Bob, intervening when necessary.  
    • Note: It's not easy for Eve to orchestrate these events, so this is likely not an easy attack.
Mitigation with signed self-attested claims:
  • Bob includes in the proof a signed, self-attested claim derived from the peer DID used to establish the relationship (e.g. the public key or even the DID itself).
  • Since the Bob-Eve DID is different from the Eve-Alice DID, if Eve just passes on the proof to Alice, Alice will detect the difference and be aware of the MITM.

On Wed, Oct 16, 2019 at 2:21 PM Richard Esplin <richard.esplin@...> wrote:
This is a useful conversation.

Stephen: What features in Anoncreds 2.0 will help detect MITM attacks?

-- Richard

On Mon, 2019-10-14 at 15:30 -0700, Stephen Curran wrote:
> Your scenario is a good one, and is one that should always be
> considered.
>
> In response to your questions:
>
> 1. The creator of the invitation can decide if the invitation is a
> "use once" or "use many times" invitation and hence if Alice is able
> to use it after Eve. If it is a use once, Alice's response would be
> rejected. If a use many times, it would be accepted.  Obviously in
> the latter, the inviter would be expecting many responses and so
> wouldn't care it Eve, Mallory, Alice or anyone else responded.
>
> 2. The basic answer is that unless we are certain of the path of the
> invitation and are certain it is going to Alice (e.g. we are in the
> same room together and you can see Alice responding), we can't know
> for sure that there is no MITM. Hence, there is a need to verify the
> recipient after establishment of the connection. The approach our
> team (BC Gov) is expecting to use for that is a proof of a verifiable
> credential.  If it is crucial for us to know that we are talking to
> Alice, a DID connection is generally not sufficient and we will need
> Alice to prove who she is some other way that we do trust.
>
> Note that even then, there is a slight chance that Eve could
> establish herself between Alice and I and proxy (for example) the
> communications, including proof requests and proofs between the two
> parties (myself and Alice). While extremely unlikely, that is
> possible with the current Indy technology.  We expect in future
> revisions (notably, as part of the "anoncreds 2.0" effort) that there
> will be a way to detect that and prevent that type of attack.
>
> Hope that helps.
>
> On Mon, Oct 14, 2019 at 8:11 AM <mbhattac@....ab.ca>
> wrote:
> > I am doing some experiments on the trust of first use problem when
> > creating relationships between DIDs on Indy. I setup Alice and
> > Faber agents, generate an invitation from the Faber agent so that
> > Alice can connect and form a relationship. Instead of using the
> > invitation on Alice's agent, I setup another agent Eve and consume
> > the invitation in Eve's agent, instead of Alice's, and Eve gets
> > connected to Faber. Eve is acting as a man-in-the-middle (MITM)
> > here.
> >
> >
> >
> > My questions:
> >
> > 1. Can the same invitation be reused again by Alice after Eve? Are
> > invitation_key, request_id and connection_id the binding factors,
> > if not?
> > 2. How can we make sure that only Alice can use this invitation? OR
> > What can prevent the use of an invitation intercepted by a man-in-
> > the-middle (MITM)?
> >
> >
>
>



--

Stephen Curran
Principal, Cloud Compass Computing, Inc. (C3I)
Technical Governance Board Member - Sovrin Foundation (sovrin.org)

Schedule a Meeting: https://calendly.com/swcurran



--
Kyle Den Hartog