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

Re: Web Payments and Identity

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Tue, 24 Sep 2013 01:07:43 -0400
Message-ID: <52411E1F.6040406@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/22/2013 05:32 PM, Ricardo Varela wrote:
> Just for clarity, what use case exactly is that they "desperately
> need" that online identity for?

It's specifically for the case where they would like to re-use Know Your
Customer (KYC) data provided by other organizations, like the US
Government's assertions on Social Security numbers, for example.

Many of the banks that I spoke with would like to do KYC on their
customers once and then have some way of sharing the data (so they don't
have to pay for the KYC process again when the customer goes to another
bank to get a loan, line of credit, etc.)

> For the sake of background: I reckon the banks do not currently have
>  widespread federated authentication schemes because it is up to
> individual bank-to-bank agreements to trust the KYC of the other bank
>  and they need rules about whose liability it is if the transaction
> goes wrong.

Yes, this is true. However, they are paying a sizeable amount of money
with this approach because none of the data is shared (or rather, there
is no way to share the data between institutions). It's a pretty classic
data portability issue. Many Web identity folks would like the customers
to own this data and have control over who can get access to it. Banks
don't really care as long as they can get Know Your Customer (KYC)
assertions and they don't have to keep paying for the same data over and
over and over again. Everyone would like this to be as simple as just
entering your email address.

> By the way, to add to the mix: one of the comments in SEPA is that it
>  makes sense that in some cases identity cannot be formulated in a
> cross-border manner as there may be country-level regulations to add
> to the EU ones (eg: data protection and retention policies in
> Germany)

Yes, and this depends entirely on who is safeguarding the identity for
the customer. If it is a bank in Germany, then they fall under a
different set of rules and regulations as a bank in the US. That said,
these banks already have to deal with those headaches... nothing about
that changes with any of the technologies that are currently being
explored (Persona / PaySwarm).

> So, back to the original bank question: are they proposing a specific
>  scenario where the issue is actually technical?

There is a specific scenario where the issue is actually technical, yes.
Namely, getting an assertion on an identity that includes a government
issued claim that the customer has a name, government issued ID number,
and digital signature on this information by the government that asserts
that they are a real person.

> or was this more the "visible excuse" for the reality that they have
> other issues to solve before getting to that common solution because
> a common identity still requires trust?

A common identity requires trust, and the banks will still have to trust
a common set of partners, such as private institutions that have been
cleared by banks to do KYC along with governments with jurisdictional
authority over the banks.

> PS: so that this is not just bank-bashing: I work with mobile
> operators and the issues are more or less the same, more
> legal/process than tech, and banks are even in a more advanced phase

There are legal/process issues at play here, but there are also
technical solutions that we can provide that would at least address the
technical side of the problem.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Meritora - Web payments commercial launch
http://blog.meritora.com/launch/
Received on Tuesday, 24 September 2013 05:08:00 UTC

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