Re: ANSI X9.122 Secure Customer Authentication for Internet Payments

> On Jul 5, 2016, at 7:40 AM, Erik Anderson <eanders@pobox.com> wrote:
> 
> X9.122 is about to pass votes in X9. My last email about this topic was
> "Mon, Dec 7, 2015".
> 
> This standard will be a requirement for authentication  to financial
> payment systems in the US. I am sure this will propagate internationally
> as well.
> 
> I have put it on WatchDox system. If you need access to the special X9
> instance of Watchdox please email me.
> 
> Below is a few snippets of requirements throughout financial services.

Hi Erik,

Thanks for sending this. Here are some first pass observations.

Ian

> - To ensure segregation of authentication data and PAN data, the
> authentication data and the PAN must be transmitted in separate sessions
> from the consumer’s browser and the merchant to the authenticating
> vendor.

I think the payment app model supports this. The user authenticates
through the payment app. The payment app returns data to the browser.
The browser returns it to the merchant. So authentication and data-to-the-merchant
are independent.

> 
> - To ensure privacy of the payment instrument, the transmission of the
> PAN must be in a separate browser session than the merchant checkout
> process. The Merchant must not be exposed to the users payment
> instrument details.

I believe our expectation is that payment service providers will be
able to get data from the API so that the merchant never sees the
response to the payment request API.

> 
> - The authentication data shall be secured and processed separately from
> other sensitive consumer data until it is encrypted in an HSM or other
> SCD.

Out of scope for WPWG. Might be relevant to Web Auth WG.

> 
> - The merchant shopping and payment must be in separate browser
> sessions. Acceptable methods below using internet redirection.

I believe our payment app model addresses this.

> 
> - Encryption key storage requirements – The keys should be securely
> stored, and more specifically encrypted using tamper-resistant hardware
> encryption, using them only when required.

Hardware security CG discussions seem relevant.


Most of the following security-related topics seem out of scope for the WPWG
but might be in scope for other security work at W3C; I have snipped them.

> 
>   - Device geolocation information (e.g., mobile tower, IP address, GPS
> coordinates) should be captured for audit-ability when such information
> is accessible.  Note that for some token devices (e.g., credit card,
> access token), geolocation information may not be available

(This seems like a privacy issue.)

[snip]

> - The online/web merchant SHOULD never ask the consumer to enter their
> actual payment card information.

That aligns with our payment app model, I think.

>   - Internet Redirect Method
>     - The consumer is redirected at the time of checkout to the
> financial institution’s secure online banking web site where a one-time
> use, pseudo payment card number is generated by the financial
> institution for use in subsequent internet payments. The pseudo payment
> card number should also have a minimum lifespan.
>     - Prior to an online debit transaction, the consumer is required to
> register and agree to online banking through his/her financial
> institution.
>     - The Merchant’s checkout page SHOULD redirect the consumer
> seamlessly into the online banking platform of the consumer’s financial
> institution.
>     - The consumer SHOULD be able to validate the financial institution
> website
>     - The financial institution SHOULD authenticate the consumer and
> then generate a one-time use pseudo payment card number for each online
> purchase.
> 
> 

--
Ian Jacobs <ij@w3.org>      http://www.w3.org/People/Jacobs
Tel:                       +1 718 260 9447