Re: Proposal for forward motion: Aligning with X9/ISO work in Payments

On 2015-03-18 09:33, David Ezell wrote:
> Dear IG members:
> 
> As we have been discussing for some time now, much of the work on
> payments in the standards area has been done either at X9 (ANSI) or at
> ISO.  The work done by these groups has the advantage of regulatory
> standing.  And there is a large body of outstanding work.   In order
> to advance our cause (acceptance of a payment standard for the web)
> I'd like to propose the following plan:
> 
> 1) Review (and approve) ISO12812 - we can't exactly do this yet, since
> it is still out for vote and we can't see it in non-ISO-member space.
> So this part of the proposal depends on our agreeing that it's going
> to work for us (TBD).

+1

FYI: ISO 12812 is the Core Banking – Mobile Financial Services, In our 
opinion there is no difference between Mobile and browser.

ISO 12813 groups has already went through ISO 20022 and ISO 8583 and 
picked out the pieces that are necessary for mobile/browser. They 
reference the messages and data elements/structures that apply to Mobile 
Payments.

> 2) Review X9.119 pt. 2 - this standard is about "tokenization."  It is
> potentially about payment tokenization, but it includes >other uses
> for tokens as well.  This work is gaining wide traction.

+1

I would love to see our first pass standardize a W3C interface for 
supporting Push based payments and pull based tokenization payments. A 
push based payment can be ACH, cryptocurrency, etc. Anyone with more 
examples of push payment?


> 
> 3) Submit our resulting flows to ISO20022 "certification" (RNG) -
> Let's take the flows defined in our use cases/payment agent work and
> refine and submit them to become an "accredited ISO20022 framework."

+1

Please do not think this is a barrier. I wanted to bring up this up at 
the Utrecht F2F but Dave didnt want to open those cans of worms, yet. 
W3C Web Payments members such as myself, DaveE, Federal Reserve Members 
already has the appropriate X9 membership and TC68. We can change an 
existing ISO financial standards. Our combined organizations have the 
authority if we need to change something.

This is important because many countries regulate payments via 
compliance with ISO 20022 standard. Since we will likely need to change 
ISO 20022 we will be grandfathered into various countries regulatory 
compliance.

> This modest plan gives us a defined target, leading to a model that
> might be much more easily accepted in the payment community, since we
> will be ISO20022 "certified."
> 
> There are literally dozens of ISO and X9 standards that might apply to
> corner cases of what we're doing, but I think a focused strategy that
> includes these three[1] standards listed above will help us reach our
> goal of producing credible recommendations for web payments in the
> near term.

I dont mean to scare people but please review this PDF.

http://www.w3.org/2015/03/Financial_Services_Security_Standards_overviews..pdf 
  (members only)

Each layer of the image is a security layer mandating various security, 
public-key cryptography, SSL/TSL, man-in-the-middle, key rotations, key 
management, etc.

Ed Scheidt & Jay Wack from TecSec and I just had a 4 hour F2F 
meeting/lunch. Ed was the head of CIA cryptography and is now the 
Chairman of the X9 subcommittee on data security. I am also on this 
subcommittee.

Ed is leading the data security side of financial services standards. 
Give a little more time I will be able to know which of the listed 
security standards apply to the browser and payments over the public 
internet. This should be easily boiled down to 10-20 bullet points that 
summarizes what we need to do.

Its a bit early for me to share details of security as it applies to the 
browser and payments. Issues arise of whom is responsible if a users 
digital ID, digital property, bank accounts, etc are compromised because 
of a bad implementation of security of a browser vendor. This has been 
brought up in the W3C Web Payments meetings and may likely cause 
friction points with browser vendors.

As stated by Ed, static Public/Private keys can be compromised. He had 
various real use-cases where this was brought up at large firms and 
international levels.

TecSec has a new Constructed Key Management solution where keys are one 
time and generated based on various inputs. I will be sharing this 
information as I start to understand the details. This will alleviate 
many concerns if adpoted.

Additionally, a friend of mine, Juan Llanos, 
http://www.linkedin.com/in/juanllanos/en

Has provided the below 3 slides for W3C Web Payments. It gives a summary 
as to whether or not you will fall within regulatory requirements.

http://www.w3.org/2015/03/2015_02_23_Regulation_Primers_for_Erik.pdf   
(members only)

Please review this slide. Lets put the regulatory concerns to rest as 
they will not apply to W3C Web Payment standards in the browser. 
However, consumer protection will apply to browser vendors but TecSec 
has solved these issues and will provide guidance and/or solutions as it 
applies to consumer protection.

This should help Manu's credential efforts.

> There is substantial work implied in this proposal.  Discussion is
> encouraged.  It's important.

+1

Yes. I spend at least 2+ hours a day and weekend going through all of 
these standards and issues to understanding what we will really need to 
do.

At the F2F at Bloomberg I will be able to provide a lot of details to 
help iron out our roadmap of what it is we will really need to do. Yes, 
we need to provide API standards but we need to provide guidance as well 
as financial standards need to be navigated.

Erik Anderson
Bloomberg R&D & W3C Web Payments IG/SC co-chairman

Received on Thursday, 19 March 2015 20:33:18 UTC