W3C home > Mailing lists > Public > public-webpayments@w3.org > September 2013

Re: Web Payments and Identity

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Sun, 29 Sep 2013 21:01:17 -0400
Message-ID: <5248CD5D.1040404@digitalbazaar.com>
To: Ricardo Varela <phobeo@gmail.com>
CC: Ben Adida <ben@adida.net>, Web Payments CG <public-webpayments@w3.org>, "Joe Cascio, Jr." <joe.cascio.jr@gmail.com>, Dan Callahan <dan.callahan@gmail.com>, Lloyd Hilaiel <lloyd@mozilla.com>
On 09/24/2013 10:26 AM, Ricardo Varela wrote:
> Firstly: do we have anybody from the banking industry on the list
> who can further comment on this?

Madhu was on the call last week and had good things to say about the
need for a solution, exactly what that solution could be is still up in
the air. We'll have Joe Cascio joining us on the call this week to tell
us about how he's trying to tackle KYC in the Bitcoin world. I'm going
to try to get some folks from SWIFT (world banking standards group) in
here to get their input as well.

> However, this is not the current case. Banks could do this now
> without the need of any extra technologies, and they STILL don't do
> it anyway! I don't think they need a better mousetrap, I think they
> just don't want a mousetrap at all.

That's definitely not the feedback I got from /some/ of the banks at the
world banking conference. Many are fine with the cost associated with
KYC because they just pass it on to their customers. However, that cost
is a big problem in emerging nations and results in people not being
able to open bank accounts at all (because the KYC process is either not
in place or would cost the customer several days of pay).

> Maybe having some browser-level "passport" of identities is more 
> feasible.

That's what's being proposed, which might not have been clear.

> However, I think is very unrealistic to continue thinking that we can
> have a financial identity based on something like email.

No one is proposing that as a solution, AFAIK. The email address is just
something that can be used to bootstrap the discovery process via Persona.

In the most extreme case, doing something like asserting information
like a drivers license, may require a digital signature by both the
issuing organization (US Government) and the entity using the claim (the
person that has tied their mobile number + public key to the email
address). Let's say that someone wanted to tie an online identity to a
drivers license. The flow would work something like this:

1. The person navigates to the Department of Motor Vehicles website and
requests a digital drivers license endorsement on an online identity.
The person chooses which online identity is tied to their
Persona-registered email address. A digital signature is created on the
2. The endorsee shows up in person at the DMV, an employee verifies
their identity and their key, and endorses the information, which is
then stored (in some secure manner) with their online identity.
3. In order to use that endorsement at a place like a bank, the
endorsement is transmitted to the bank along with a digital signature of
the identity. Any person holding those two pieces of information (the
endorsement and the private key associated with the endorsee) is
probably the person that was approved at the DMV.

> Your email gives no info about your transaction behaviour and
> patterns, how risky you are, how likely to become overdraft or be
> involved in money laundering, etc... all information that a KYC
> process has got to tackle

The email address is just a tool to kickstart the identity discovery
process, hopefully via Persona. This may help you understand the type of
identity that we're talking about for KYC... it's much more than just an
email address:


To see what one of these identities looks like, you can do the following:

curl https://dev.payswarm.com/i/manu

-- manu

Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Meritora - Web payments commercial launch
Received on Monday, 30 September 2013 01:01:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:24 UTC