Subject: [Din] WSJ article on Identity and Blockchains

From: Thomas Hardjono <[email-masked]>
Date: Fri, 6 Apr 2018 16:34:16 +0000

Folks,

I thought to share this WSJ article with the DIN group. Relevant in the light of recent interest in using BC for identity.

Advance apologies if it offends some people :-)

https://blogs.wsj.com/cio/2018/04/03/digital-identity-is-broken-heres-a-way-to-fix-it/

Below is a link to a PDF version.

http://hardjono.mit.edu/sites/default/files/documents/WSJ_Digital_Identity_is_Broken.pdf

Best

-- thomas --

---

From: Jon Crowcroft <[email-masked]>
Date: Sun, 08 Apr 2018 11:38:53 +0100

very nice article...

so you _are_ your social network...in terms of trustworthy identity...sure...

there's two problems with this though in details...
i.e. how we build on this idea technically in the Din context...

1/ its still dependent on technologies, 
and there's a seperate issue of why we trust them to proxy our social net -
i certainly would it find it hard to trust any social media app, running on a cloud platform,
using a smart mobile device, to vouch for all these friends & colleagues - too many layers, too many
vested interests, too much Cambridge Analytica :)

2/ I though many people in the security community were moving away from
proving identity, towards systems that prove entitlement (i.e. credentials
are on a need-to-know basis, so if you were say 19, you don't need to say yur age or show id, 
but you can't buy a drink in cambridge MA, but you can in cambridge, UK :)

bootstrapping something from a BC to provide the credentials is also problematic, in that
BC needs a PKI to know whether nodes are not sybils, spoofs, etc, so we have a circular dependance, no?

maybe i missed an important step, if so, sorry!

> Folks,
> 
> I thought to share this WSJ article with the DIN group. Relevant in the 
> light of recent interest in using BC for identity.
> 
> _______________________________________________
> Din mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/din
>

---

From: Thomas Hardjono <[email-masked]>
Date: Sun, 8 Apr 2018 14:06:18 +0000

Thanks Jon.

Aside from the obvious goal of cutting through the current hype about "Self-Sovereign Identity" and how Blockchains (BC) will achieve "my sovereignty",  we wanted to communicate to the general  reader that the problem of "identity" is not so simple.

>>> so you _are_ your social network...in terms of trustworthy identity...sure...

No, not so simple, particularly when the social network is FB :-) 

>>> vested interests, too much Cambridge Analytica :)

You've hit the nail, as usual - thank you Jon :-)

The question is how to capture/use/protect the human-to-human interaction as the basis for trust ("local trust").

Here is an example. So my local town here in the US has a private mailing-list for local residents only. I have to attend town meetings in-person before I can get on to that mailing-list.

There is no reason why my local town cannot run their own "social platform" (we are in the age of VMs, Containers, Clouds).  It must legally owned by the town/community, and available to residents only (i.e. who pay local tax), etc.

How do we create next-gen architectures/protocols/legal that support local communities to interact  on their own "social platform" , and become the starting point for "trust" that can scale out (called "local trust" in the WSJ paper).

I think there is huge role for DIN to help. For the future distributed Internet infrastructure, is it possible to have the following:

-- Can my town obtain a "social-platform-on-demand" from a cloud service provider.
-- Can I legally prevent the service-operator from "making use" of my data (yes they still may be able to steal my data).
-- Can I retain legal ownership of my data (same with my town).
-- Can I encrypt my data on my town's social-platform so that the service-operator doesn't steal it.
-- How to do key management.
-- How can I use legal smart-contracts to bind the service-operator.
-- Etc. etc. lots more questions for DIN RG.

>>> but you can't buy a drink in cambridge MA, but you can in cambridge, UK :)

Yes, correct. Currently people are focusing on proving entitlements via signed assertions. Great, no issue there. But the real question is about the *data* and *algorithms* behind those assertions (that impact my life, like credit-score):

-- How do I know that an organization has subject-data about me (usual questions of "how, what, when, what are you doing to my data").
-- What is the provenance of the data in their possession  (Did they get it from a data-aggregator? Do they even know?)
-- Does the data set have in-built bias? (not intentionally)
-- Is the data "fair"  (fairness in the sense of machine learning).
-- What is the accuracy of the algorithms computed on my data. Does it propagate the bias in the data.
-- Do I get to see the algorithms that impact my life.
-- Can I hire an expert to provide objective review of these algorithms.
-- etc. etc. etc.

>>> BC needs a PKI to know whether nodes are not sybils, spoofs, etc, so we have a circular dependance, no?

Yes, agree.  There is need to revisit PKI again, maybe opportunity in DIN RG to improve it.

Hashing an identifier (and back-links) to a BC doesn't help the identity/trust problems.
Hashing a pub-key to a BC also doesn't add much.

>>> maybe i missed an important step, if so, sorry!

Nope, you are on the right track :-)  Hope you can help solve some these problems.

Best.

-- thomas -- 

________________________________________
From: Jon Crowcroft [[email-masked]]
Sent: Sunday, April 08, 2018 6:38 AM
To: Thomas Hardjono
Cc: [email-masked]; Jon Crowcroft
Subject: Re: [Din] WSJ article on Identity and Blockchains

very nice article...

---

From: Jon Crowcroft <[email-masked]>
Date: Sun, 8 Apr 2018 15:20:10 +0100

this al sounds excellent - socially rooted, community operated communities
- all good - we could think of building instances of this on the
infrastructure we've been constructing (i know there are lots of other
people building similar, so this is a bit of gratuitous
self-aggrandizing:), viz
http://www.databoxproject.uk/

there are some decentralisation movements in the certificate space (CA
transparency) as wel as self-certifying address allocation. so I assume
there's some hope for using these to bootstrap the platforms-on-demand,
safely for  communities you're envisaging -

we're definitely on same page here!

On Sun, Apr 8, 2018 at 3:06 PM, Thomas Hardjono <[email-masked]> wrote:

>
> Thanks Jon.
>
> Aside from the obvious goal of cutting through the current hype about
> "Self-Sovereign Identity" and how Blockchains (BC) will achieve "my
> sovereignty",  we wanted to communicate to the general  reader that the
> problem of "identity" is not so simple.
>
> Here is an example. So my local town here in the US has a private
> mailing-list for local residents only. I have to attend town meetings
> in-person before I can get on to that mailing-list.
>
> There is no reason why my local town cannot run their own "social
> platform" (we are in the age of VMs, Containers, Clouds).  It must legally
> owned by the town/community, and available to residents only (i.e. who pay
> local tax), etc.
>
> How do we create next-gen architectures/protocols/legal that support local
> communities to interact  on their own "social platform" , and become the
> starting point for "trust" that can scale out (called "local trust" in the
> WSJ paper).
>
>
> I think there is huge role for DIN to help. For the future distributed
> Internet infrastructure, is it possible to have the following:
>
> -- Can I legally prevent the service-operator from "making use" of my data
> (yes they still may be able to steal my data).
> Yes, correct. Currently people are focusing on proving entitlements via
> signed assertions. Great, no issue there. But the real question is about
> the *data* and *algorithms* behind those assertions (that impact my life,
> like credit-score):
>
> -- How do I know that an organization has subject-data about me (usual
> questions of "how, what, when, what are you doing to my data").
> -- What is the provenance of the data in their possession  (Did they get
> it from a data-aggregator? Do they even know?)

---

From: Thomas Hardjono <[email-masked]>
Date: Sun, 8 Apr 2018 20:41:25 +0000

Thanks Jon,

>>> this al sounds excellent - socially rooted, community operated 
>>> communities - all good - we could think of building instances 
>>> of this on the infrastructure we've been constructing 
>>> (i know there are lots of other people building similar, 
>>> so this is a bit of gratuitous self-aggrandizing:), viz

Very interesting.  In the Kantara Initiative we've been looking it
mechanisms for controlling access to "resources" -- which translates
to files etc located in a data store (including personal data store).
There is the access control aspect & and also the consent/receipts aspect.

One thing that would be useful is a "Standardized API" (e.g. REST API)
for personal data stores (regardless where they sit, e.g. in Cloud; on Mobile; on Home-PC).

Would this (APIs) be something DIN RG could explore?

I will take a close look at databoxproject.

-- thomas -- 

________________________________________
From: [email-masked] [[email-masked]] on behalf of Jon Crowcroft [[email-masked]]
Sent: Sunday, April 08, 2018 10:20 AM
To: Thomas Hardjono
Cc: [email-masked]
Subject: Re: [Din] WSJ article on Identity and Blockchains

this al sounds excellent - socially rooted, community operated communities - all good - we could think of building instances of this on the infrastructure we've been constructing (i know there are lots of other people building similar, so this is a bit of gratuitous self-aggrandizing:), viz
http://www.databoxproject.uk/

there are some decentralisation movements in the certificate space (CA transparency) as wel as self-certifying address allocation. so I assume there's some hope for using these to bootstrap the platforms-on-demand, safely for  communities you're envisaging -

On Sun, Apr 8, 2018 at 3:06 PM, Thomas Hardjono <[email-masked]<mailto:[email-masked]>> wrote:

Thanks Jon.

Best.

-- thomas --

________________________________________
From: Jon Crowcroft [[email-masked]<mailto:[email-masked]>]
Sent: Sunday, April 08, 2018 6:38 AM
To: Thomas Hardjono
Cc: [email-masked]<mailto:[email-masked]>; Jon Crowcroft
Subject: Re: [Din] WSJ article on Identity and Blockchains

very nice article...

> [email-masked]<mailto:[email-masked]>

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 9 Apr 2018 08:47:13 +1200

This rang some bells for me, going back to some of the discussions about grid
computing 15 years ago. So the paper [1] is quite long but the relevant bit said:

"We contend that all existing SA technologies (most
notably SAML, among the most recent ones) use some
subset of the following semantic fields:
1. User ID (subject NameIdentifier in SAML)
2. Authentication method and strength and context
(authentication method in SAML)
3. Group/attributes (user attributes in SAML)
4. Resources granted (resources in SAML)
5. Entitlements granted (resource attributes in
SAML, “wild cards” in the proposal [13])
6 Operations granted (actions in SAML)
7. Privacy restrictions (conditions in SAML or obligations
in XACML [15] [Extensible Access Control
Markup Language])

It should be noted that the first three of these fields
pertain to and are defined in a user's home service
domain while the last four pertain to and are controlled
by the service domain where the affected resources
reside."

The point being that even if the user name is known, it's actually
irrelevant to the bartender; the only relevant bit is one of the user
attributes certified by the home domain (age) and the entitlement granted
to that age by the visited domain (alcohol or not alcohol).

Our conclusion in 2004 was that a standard abstraction for such assertions
was needed. I think that's still true. Also we thought that inter-domain trust
was an orthogonal question. I'm sure that's still true, and BC doesn't fix it.

Regards
   Brian Carpenter

[1] B.E. Carpenter & P. Janson, Abstract interdomain security assertions: A basis for extra-grid virtual organizations, IBM Systems Journal, 43(4) (2004) 689-701
http://ieeexplore.ieee.org/document/5386759/

On 08/04/2018 22:38, Jon Crowcroft wrote:
> .

---

From: Arjuna Sathiaseelan <[email-masked]>
Date: Mon, 9 Apr 2018 00:28:27 +0200

> but you can't buy a drink in cambridge MA, but you can in cambridge, UK :)

digital id plays a major role for all the KYC/AML - massive market.. + for
employment etc..

like the idea of proving entitlement - works nicely with crypto
charities/aid delivery..

Regards

-- 

Arjuna Sathiaseelan
University of Cambridge | Ammbr Research Labs
Personal: http://www.cl.cam.ac.uk/~as2330/
N4D Lab: http://www.cl.cam.ac.uk/~as2330/n4d

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 9 Apr 2018 13:44:33 +1200

> digital id plays a major role for all the KYC/AML - massive market.. + for

Right, but *international* digital ID is a hopeless mess. Just try dealing
with a USA bank's KYC department when living in New Zealand with a UK
passport. Nothing works.

That isn't a marginal case. Tens or hundreds of millions of people
would need cross-border digital ID these days. Sales argument: would
help to defeat money laundering.

   Brian

---

From: Thomas Hardjono <[email-masked]>
Date: Tue, 10 Apr 2018 16:49:21 +0000

>>> From: Din [[email-masked]] on behalf of Brian E Carpenter [[email-masked]]
>>> ...

Lots of people seem to want to provide digital-identity on a global scale immediately. from day 1.

Some folks even imagine there will be one huge global blockchain for the entire world :-)

But there is a lot to be learned from the history how IP routing emerged (e.g. days when
we only had IS-IS for local routing, not even OSPF).

Just like there is "autonomous systems" (AS) concept in routing and connected via backbone routing,
in the area of identity there needs to be the equivalent of an AS.

I've been calling it "communities" (data communities) for humans and personal data.

Its by interlinking ASes (communities) do we get scale and get identity services to be globally reachable.

So anytime I hear about a global blockchain to rule them all, I cringe :-)

-- thomas -- 

________________________________________
From: Din [[email-masked]] on behalf of Brian E Carpenter [[email-masked]]
Sent: Sunday, April 08, 2018 9:44 PM
To: [email-masked]
Subject: Re: [Din] WSJ article on Identity and Blockchains

   Brian

---

From: "Diego R. Lopez" <[email-masked]>
Date: Tue, 10 Apr 2018 22:40:50 +0000

Hi,

I'd recommend the group to have a look around the digital identity concepts the academic networks shaped during the early 2000s, and that are formulated in a global scope by the REFEDS initiative: https://refeds.org/

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
https://www.linkedin.com/in/dr2lopez/

e-mail: [email-masked]
Tel:         +34 913 129 041
Mobile:  +34 682 051 091
----------------------------------

    -- thomas --

       Brian

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Apr 2018 11:52:02 +1200

> I'd recommend the group to have a look around the digital identity concepts the academic networks shaped during the early 2000s, and that are formulated in a global scope by the REFEDS initiative:…

Agreed. And REFEDS descended from the discussions around grid virtual organisations where the problem first became apparent, plus the old Shibboleth system. There's a lot of current practice to look at, and no particular reason to bring blockchains into the picture. What you need is an explicit, transparent, human-validated model for federating individual trust domains. (Exactly what the crypto-currencies lack, as far as I can see.) REFEDS federates 72 national trust domains, according to their site, and I assume that each of those is itself a federation of local domains.

Here's more info:
https://www.geant.org/Services/Trust_identity_and_security/eduGAIN
"... over 2,500 identity providers ..."

   Brian

---

From: David Mazieres <[email-masked]>
Date: Tue, 10 Apr 2018 17:04:54 -0700

Thomas Hardjono <[email-masked]> writes:

> Just like there is "autonomous systems" (AS) concept in routing and
> connected via backbone routing, in the area of identity there needs to
> be the equivalent of an AS.

Yes, but obviously AS numbers are centrally allocated and a flat
namespace.  If we are going to have various identity providers, I would
argue we need two things unlike AS numbers:

  1. The identifiers should be self-authenticating (public keys, not
     integers), so allocation is "self-server," and

  2. We need some notion of a "symbolic link", so that I can name not
     just someone else's key, but someone else's name, as that's very
     powerful.

These points of course were ones that many of us were making in the
1990s.  See, for instance SPKI/SDSI.

> So anytime I hear about a global blockchain to rule them all, I cringe

The blockchain is useful, but sort of orthogonal to the namespace
itself.  What it provides, that we couldn't do before, is the ability to
voluntarily restrict what you do with your own namespace.  E.g., maybe
you want to delegate a name and then restrict yourself from revoking it
without seven days notice.

David

---

From: Thomas Hardjono <[email-masked]>
Date: Wed, 11 Apr 2018 14:37:46 +0000

Hi David,

>>>        just someone else's key, but someone else's name, as that's very

Yes the symbolic link is needed, but more importantly (and more difficult) is the binding to the owners person.  How do I know that the person Alice for pubkey X is the same Alice who owns pub key Y.

>>> 1990s.  See, for instance SPKI/SDSI.

Agree, that was Car Ellison's proposal.

>>> itself.  

Agree.

>>> What it provides, that we couldn't do before, is the ability to

Could we use DNSSEC for this? 

-- thomas -- 

________________________________________
From: David Mazieres [[email-masked]]
Sent: Tuesday, April 10, 2018 8:04 PM
To: Thomas Hardjono; Brian E Carpenter; [email-masked]
Subject: Re: [Din] WSJ article on Identity and Blockchains

David

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Apr 2018 08:34:56 +1200

> Yes the symbolic link is needed, but more importantly (and more difficult) is the binding to the owners person.  How do I know that the person Alice for pubkey X is the same Alice who owns pub key…

Do you need to know? Surely what you need to know is what capabilities to
grant to the holder of pubkey X, and what capabilities to grant to the
holder of pubkey Y. Alice might prefer to have disjoint identities for
different purposes. In some countries that might be essential for
personal safety.

   Brian

---

From: David Mazieres <[email-masked]>
Date: Wed, 11 Apr 2018 14:08:22 -0700

Thomas Hardjono <[email-masked]> writes:

> Yes the symbolic link is needed, but more importantly (and more
> difficult) is the binding to the owners person.  How do I know that
> the person Alice for pubkey X is the same Alice who owns pub key Y.

This doesn't seem hard conceptually--just have pubkey Y sign some
statement about Alice and pubkey X.

The more interesting question in my mind is tying together non-pubkey
identities.  How do I know this person submitting pull requests to my
project is also the former Stanford student I've been chatting with
online?  I think Keybase in particular has made some pretty good headway
in addressing the problem, but that is a centralized system to some
extent, and could definitely benefit from some decentralized internet
infrastructure...

> Could we use DNSSEC for this? 

I don't see how to do this without some new kind of system for encoding
such update rules and a consensus mechanism for enforcing it.  And
obviously I believe the SCP draft is a step in the right direction for
the enforcement side of this problem...

https://datatracker.ietf.org/doc/draft-mazieres-dinrg-scp/

David

---

From: Arjuna Sathiaseelan <[email-masked]>
Date: Mon, 16 Apr 2018 09:42:37 +0100

this is something we are working on via https://www.verif-y.com/

hope to get some experiences and I would share here for sure.

Regards

On 9 April 2018 at 02:44, Brian E Carpenter <[email-masked]>
wrote:

> >> are on a need-to-know basis, so if you were say 19, you don't need to
> say
> >> yur age or show id,

-- 

Arjuna Sathiaseelan

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 23 Apr 2018 14:29:54 +1200

Arjuna

> this is something we are working on via https://www.verif-y.com/

"The Verif-y KYC service allows businesses utilizing blockchain technology to trust unknown customers and token purchasers in an efficient, auditable and secure manner."

I'm confused. KYC is largely about detecting money laundering, and other malfeasance, so the last thing a KYC desk cares about is unknown customers. On the contrary, they want to know the legal identity of the customer and of the source of funds. Direct access to PII is part of the process.

Believe me, I've been there, not 10 km from cl.cam.ac.uk, when my bank tried to cut me off from my money soon after I relocated from Auckland to Cambridge in 2012. Somehow they had failed to update my residence address and I had to get documents certified and rubber-stamped at Cambridge police station, and sent by snail mail to the bank's KYC desk, before we got our money back. How does block chain solve that? (Not a rhetorical question; I would really like to understand.)

    Brian

---

From: Jehan Tremback <[email-masked]>
Date: Mon, 23 Apr 2018 12:10:17 -0700

As far as I understand the use-case of blockchain in KYC (from the perspective of someone who is vouching for an identity), the main thing is that you can sign off that someone meets some standard of identification (they have a certain address, net worth, etc) and then put it on the blockchain. Of course you could also just give them the signature to present when they need to use it.

But putting it on the blockchain allows you to revoke it later.

-- 
  Jehan Tremback
  [email-masked]

On Sun, Apr 22, 2018, at 7:29 PM, Brian E Carpenter wrote:
> "The Verif-y KYC service allows businesses utilizing blockchain 
> technology to trust unknown customers and token purchasers in an 
> efficient, auditable and secure manner."
> 
> I'm confused. KYC is largely about detecting money laundering, and other 
> malfeasance, so the last thing a KYC desk cares about is unknown 
> customers. On the contrary, they want to know the legal identity of the 
> customer and of the source of funds. Direct access to PII is part of the 
> process.
> 
> Believe me, I've been there, not 10 km from cl.cam.ac.uk, when my bank 
> tried to cut me off from my money soon after I relocated from Auckland 
> to Cambridge in 2012. Somehow they had failed to update my residence 
> address and I had to get documents certified and rubber-stamped at 
> Cambridge police station, and sent by snail mail to the bank's KYC desk, 
> before we got our money back. How does block chain solve that? (Not a 
> rhetorical question; I would really like to understand.)
> 
>     Brian
> 
> >

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 Apr 2018 10:48:54 +1200

> But putting it on the blockchain allows you to revoke it later.

Yes. But it was the "unkown" in "trust unknown customers and token purchasers" that puzzled me on the verif-y.com site. As you imply, KYC is about *knowing* your customer.

If it said "identify and trust new customers and token purchasers" I would not have asked my question.

   Brian

---

From: Jehan Tremback <[email-masked]>
Date: Mon, 23 Apr 2018 16:31:12 -0700

There are many jurisdictions in which it may be illegal to sell tokens to people not meeting certain criteria (they must be rich), so sellers must be careful to make sure that the buyers meet this criteria. However, proving this requires a lot of personal information, that the seller neither wants nor needs.

Having a service which would let you set up a smart contract and sell tokens to only those who you are allowed to sell to, while all of their actual personal details remained unknown. Not sure if this is what they are trying to do.

-- 
  Jehan Tremback
  [email-masked]

On Mon, Apr 23, 2018, at 3:48 PM, Brian E Carpenter wrote:
> Yes. But it was the "unkown" in "trust unknown customers and token 
> purchasers" that puzzled me on the verif-y.com site. As you imply, KYC 
> is about *knowing* your customer.
>