- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Sun, 29 Sep 2013 21:01:17 -0400
- 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 request. 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: https://hacks.mozilla.org/2013/04/web-payments-with-payswarm-identity-part-1-of-3/ 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 http://blog.meritora.com/launch/
Received on Monday, 30 September 2013 01:01:49 UTC