RE: W3C Web Payments: Information Control and Information Flow

... would love to integrate a CKM7 module into our framework. Everybody could use it (perhaps against some license fee) for whatever use.

Looks like the pieces of the puzzle might fall  into places if we start to accept there are many places at all...

Cheers,
                Jörg

From: Erik Anderson [mailto:eanders@pobox.com]
Sent: Sonntag, 5. April 2015 04:15
To: public-webpayments-ig@w3.org
Subject: W3C Web Payments: Information Control and Information Flow

W3C Web Payments Security & Messaging Standards Diagram
https://www.w3.org/Payments/IG/wiki/images/5/53/W3C_payments_Standards_Diagram.png

W3C Web Payments Mind Map
https://www.w3.org/Payments/IG/wiki/images/8/87/W3C_Web_Payments.png

Information Controls and Information Flows pretty much covers the entire transactional messaging world of financial services.

Do you like the sound of the below then read on:
1)  Identity based encryption? Separate credentials and access controls per element of information?
2)  Dynamic & recoverable encryption keys so you can have a unique security for every transaction?
3)  A scalable security architecture so ACH, Browsers, Bitcoins, a decentralized file server can all benefit.
4)  Hacker breaks into your Apple account and your personal pictures/data were stolen but still 100% secure.
5)  Dynamic key constructed at time of need and immediately destroyed after usage. Role based access to protected content. Even bitcoin private keys can be inherited by your loved ones.
6)  Guaranteed confidentiality with that government boogieman because YOU granted them the access controls for x time period but only to that small bit of information the courts Ok'ed.
7)  Manage information control over time be it centralized, decentralized, TOR network, blockchain, bank, web browser. The security of the environment does little to nothing to affect the security of the data itself.
8)  Verifiable Information chain of custody: document went from A, to B, to C. Non-repudiation of an electronic signature.
9)  Protection of transaction/data is maintained regardless of what networks the data transfers over or where the data is finally stored.
10) Each Government, Institution, Bank can manage its own risk vs security tradeoffs. Biometrics, hardware tokens, pins, passwords are theirs to define.
11) Compromise of 1 banks Vendor account, 1 corporate executive PC does little to impact the integrity of the data.
12) Governments and financial institutions all have their own favorite approved algorithms so we need to make sure to use an encryption schema not an encryption algorithm so the solution works across these political barriers.
13) That 1 master key or backdoor shouldn't exist. No more MTGox. One person should never hold THE key. Government boogiemen nor a CEO.
14) User can rent and download digital content that expires after 7 days? Two 3D printings.

>From startups to large organizations. So many are trying to redo financial systems, standards, and boil oceans. I haven't found an approach that isnt trying to boil rivers, lakes, or even the entire ocean.

Everyone wants faster, transparent, and secure transaction systems be they ACH, Bitcoin, Ripple. Everyone is doing their own thing with so little collaboration. Each of their ideas are unique, their approach is the best, and their developers are the best on the planet.

Its obvious, you cant have faster payments without first making them more secure. Chip & Pin cards with a MPOS is the silver bullet?

Wait, along comes the W3C trying to put payments into the browser and woh, brings a whole new meaning to "card not present transaction".

Well, I guess the W3C will help boil the waters just a little bit more.  Can the W3C come up with some new WebCrypto+ to magically protect the worlds financial institutions? Obviously Governments nor financial service have any expertise in protecting their own systems.

FinTech, Federal Reserve, Bitcoin, encryption, federated electronic ID, the answers must be out there without boiling the waters of the world. Its 2015, its inconceivable we need a new technology nor a browser standard to solve these issues.

For the last 6+ months I have been researching existing ISO's, Crypto 2.0, ANSI, NIST, X9 documentation centered around electronic transaction systems and security that can be used as a common infrastructure not just for browser based payments but for everyone. I have been convinced that Financial Services has the answers somewhere but those answers just never made it mainstream.

Bitcoin has all the answers! All of the true innovation is occurring in the cryptocurrency space! Crypto 2.0 started in Bitcoin. OOPS, I lost my bitcoin private key and I lost my entire 401k. Hum... Maybe not. I just dont think that will go over well.

Is there a way to align everyone's approaches? Aligning financial payment standards, internet security standards, Federal Reserve & Government payment system improvements, crypocurrency approaches.

The browser is suppose to be the center of the world when it comes to collaboration & interoperability. Certainly there must be something W3C can do for the financial services world other than adopt an XML messaging standards? Perhaps W3C can leverage its amazing reach to solve browser payment standards and security frameworks.

A co-worker and friend of mine, Matthew Rawlings, is the expert. He has been providing a lot of documentation links, connections, hours of explanations, etc. The most recent connection was with TecSec.

This connection was the jackpot. I grabbed my family and took 2 days of "workation" at TecSec near DC.

Thanks Jay, Ed, John, and Ron from TecSec.

TecSec has a wonderful set of technologies and ISO/X9 standards that can be used to eliminate a lot of the issues with today's information flow and information control.

>From an existing standards aspect W3C can accomplish Web Payments with 3 standards
X9.69 = Framework for Key Management Extensions (aka Constructive Key Management and Key Usage Control)
X9.73 = Cryptographic Message Syntax
ISO 20022 = XML messaging standard for financial services

Can be used to solve all of the above bullet points and so muchhhh more.

However the technology and cryptography of this approach is immensely challenging. Its very easy to get it wrong and 1 bug can make data unrecoverable.

TecSec chairs the data security group of financial services (X9). TecSec has a runtime engine called Constructive Key Management 7 (CKM7) that they have agreed to open source. TecSec CKM7 + Enterprise Builder is an implementation of X9.69 & X9.73.

If we add CKM7 runtime as an open source to the browser world we can use it as a wrapper around financial messaging like ISO 20022, chat protocols, password management systems, secure user interfaces, user identity protection, merit based identity, dynamic electronic signatures, dynamic cryptographic keys, time based access controls. CKM already has support for biometrics (fingers, facial, voice, retina), passwords, hardware tokens, geolocation & geofencing.

CKM7 has incredibly advanced cryptography but it has a cryptographic schema to manage access to the raw cryptographic algorithms and dynamic key management. CKM has a schema so its easily extensible to include new innovations, mobile and biometric sensors, etc.

I am sure lots of you have heard about ISO 12812. Secure element, trusted execution environment, managed dedicated execution contexts, trusted user interface, Mobile Financial Service Provider, Trusted Service Manager, authenticate the application downloaded, ensuring the secure execution of the mobile financial applications. Some of the approaches ISO 12812 is about physical security of the device. This is not necessary if you provide the proper implementations of information security.

I don't believe ISO 12812, in its current form, can be directly used by the browser world. This would likely mean a lot of custom browser development for different devices. If its mathematically infeasible to impersonate the financial institution or individual even on a compromised device. A mathematical approach can still is superior to trying to maintain the security of hardware elements themselves. The browser must always assume itself to be a compromised environment so I think W3C stance must be stronger on information security side and more agnostic to the physical hardware.

A more generic approach like CKM's architecture for administering credentials, keys and for an encryption schema will allow all to benefit from a stronger information security stance. This will provide a common and inter-operable approach from native applications to the browser.

IMO, the only unusable part of W3C Web Payments approach should be the transactional message format itself (like ISO 20022)

ISO 12812, in its current implementation, will end up creating a lot of inoperable services with incompatible messaging and security mechanisms. ISO 12812 is too specific to a financial transaction.

"AS IS" ISO 12812 will cause a lot of issues for W3C and browser vendors so we should probably need to get involved ISO 12812 while it is still a draft.

Dont get me wrong, I agree with the general direction ISO 12812 is trying to go, but its just not easily achievable. There is too much wiggle room in 12812 to make bad architecture decisions. Most certainly ISO 12812 cant achieve success without W3C and browser vendor support. W3C Web Payments needs to get very active with ISO 12812 if we are going to adopt it.

TecSec CKM7 runtime is a great security architecture wrapped with standards. It will give financial institutions and browser vendors a plug-n-play engineering solution to some very difficult problems.

CKM7 by no means restricts the world to a TecSec only solution. Its built from standards so other can try and implement the X9.69 & X9.73 backends to the CKM7 runtime. This will be a heck of a challenge but other companies can try. TecSec has over 25 years of experience in this field so lets leverage those standards and their experience to accomplish success.

IMO, its in W3C Web Payments interests to:
1) Adopt X9.69 and X9.73
2) Adopt CKM7 a browser standard implementation of X9.69 and X9.73. Add to WebCrypto charter.
3) Adopt ISO 20022
4) If we are going to adopt ISO 12812 then we need to get involved in its final drafts.
5) Write a W3C standard covering JavaScript payment API and adoption of the above

The above "W3C Web Payments Security & Messaging Standards Diagram" is a rough overview of the approach we came to consensus at the TecSec office. This approach has been provided to the Federal Reserve to see if this is compatible with the direction financial services is heading.

The "W3C Web Payments Mind Map" is a brainstorm of mine, a mind map, of how I see W3C fitting into the finance transactional space. Not just payments but any financial transaction conducted over a browser.

Comments are welcome.

Erik Anderson
Bloomberg R&D & W3C Web Payments Co-Chair