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

Re: Web Payments and Identity

From: Ricardo Varela <phobeo@gmail.com>
Date: Tue, 24 Sep 2013 15:26:53 +0100
Message-ID: <CAN46wV8BSq5WuDVuCVP3y-G7=16J-gRL-cbuJeBU-9S+v17E2Q@mail.gmail.com>
To: Manu Sporny <msporny@digitalbazaar.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>
Firstly: do we have anybody from the banking industry on the list who can
further comment on this?

And then in the comments, you mention:
> 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.)

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. It is one thing to make them work in a kind of VISA or
SEPA framework where there is certain uniformity, but they still can use
their own identities, and another one to try to put them into using some
"common" identity that they have to trust

Maybe having some browser-level "passport" of identities is more feasible.
However, I think is very unrealistic to continue thinking that we can have
a financial identity based on something like email. 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

In operator billing we kind of get away with it because we can use the
user's mobile phone number, which is obviosuly linked to a subscriber
account on the operator side, and generally linked to a series of personal
data (in a prepay phone, from the form you had to fill) or even an actual
bank account (if you're a contract user) But still is not very widespread
as an identity mechanism (other than using the phone number as part of
2-factor auth)



On Tue, Sep 24, 2013 at 6:07 AM, Manu Sporny <msporny@digitalbazaar.com>wrote:

> 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/ <http://blog.meritora.com/launch/>

Ricardo Varela -  http://twitter.com/phobeo
"Though this be madness, yet there's method in 't"
Received on Tuesday, 24 September 2013 14:27:22 UTC

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