Re: 3D Secure++ for Push Payments

Hey Anders,

I think we came to the same conclusion when I read your document the other
day :)

Effectively what you are advocating is some form of dual-factor/out-of-band
authorisation of the transaction between the payer and their provider right?
(That's what I see happening in steps 2 - 4).

This is effectively what 3D secure does today between the card holder and
card issuer.

My experience of why the industry has been resistant to 3D secure (mandated
in South Africa by the way) is because initially it required the
buyer/payer to do some work up front to set it up.
i.e. It only protected proactive customers who were usually tech savvy
enough to do it.

The result was that if the acquirer tried to push the customer through the
3D secure process they got lost/confused and dropped off.
i.e. Very little incentive for the merchants (and therefore gateways) to
implement even when considering the reduction in chargeback fraud risk.

Some notes on your steps to clarify where we overlap and how this relates
to the push payments model:

1. The payer gets a digitally signed payment request from the payee
I call this the invoicing step. The payer has chosen the way they want to
pay and is happy with the terms so they request a digitally signed invoice
from the payee.
In the request they express all of these choices/decisions and the payee,
by issuing the invoice, confirms that the choices/decisions are valid and
mutually accepted.

2. The payment request is redirected to the payment provider
I suspect that it many cases the bulk of the "chat" will be done by the
provider and not from the payer's user agent (app/browser/etc).
So the provider would get the available payment options, filter out the
ones it doesn't support and then present the payer with the remainder.
It may even be configured by the payer to auto-select based on some
preferences.

Side note:
This is where I think we should steer clear of dictating too much as the
communications/interaction between the provider and the payer is up to the
provider to design.
I see providers competing to provide the best user experience and if we
remove all possibilities of this by standardising every last step of the
process then I think we will get a lot of resistance.

As such, I have intentionally not gone into detail around this process and
simply state that the channel between the payer and provider will be secure
and trusted by the payer.
The tools the provider gives the payer to establish this link is another
means of competitive differentiation for the providers.
It could be a mobile app, a desktop application, a website, a browser
plug-in, a dedicated piece of hardware even!

The provider will deal with the bulk of the orchestartion of the protocol
and communicate with the payer as required to prompt for input (PINs,
payment method selection, gratuity, confirmation of payment, biometric
data? etc).

So, in most cases I would say that in step 1 it is the payer's provider
requesting and receiving a digitally signed invoice and step 2 is skipped.

3. The payer authorizes the payment request at the payment provider using a
payer key
As I say above, we probably don't want to spec this step explicitly other
than to note that the provider SHOULD:
a. Ensure the channel between them and the payer is secure and cannot be
spoofed (multi-factor auth?)
b. Allow the user to confirm the payment before it is executed unless the
payer has explicitly set preferences around payment scenarios for which
they don't want to perform this extra step
(probably based on payment amount/trusted payees etc)


4. The payment provider counter-signs the payment request with its provider
key
I would put this in the scope of the payment channel being used.
I can see that for an internet based payment channel this may be required
but if the channel is an existing channel out of band of the web this is
unneccessary right?
I.e. At this point the provider has confirmation from the payer to do the
transaction and enough details of the payee to execute it.

Let's assume the channel is a direct bank transfer and the provider is a
local bank and the payee has therefore given the provider their bank
account details.
The provider than communicates directly with the payee's bank and completes
the transaction.

5. The resulting object is returned to the payee
6. The payee pulls money from the received object trough its payment
provider

These are pull-model steps so I wouldn't advocate them but I see how they
fit into the CNP use case you are addressing.
I realise that what these do that I haven't catered for above is provide
the payee with proof of payment
This is where I think some form of digital receipt will be required, either
as specified by the channel or in a generic way that we can describe in a
standard.

To extend the example above, the channel is a local banking transfer
channel so it presupposes an agreement between the participating banks
about how they will deliver a proof of payment and to whom.

If it is from the payee's provider directly to the payee then no further
work is required.
We can assume that the payer's provider has confirmation from the payee's
provider that the transaction completed (this would be part of the payment
execution protocol).
Therefore the payer can get a proof of payment signed by their provider.

If the agreed method of distributing proof of payment is via the payer's
provider then the payee's provider would need to sign some form of digital
receipt and return this to the payer provider.
This can then be sent directly to the payee or to the payer or both.

Our spec should allow a means (during the discovery phase) for the payee to
define how this should be delivered.
i.e. POST to and endpoint, email etc.

Adrian


On 27 June 2014 05:49, Anders Rundgren <anders.rundgren.net@gmail.com>
wrote:

> The merits of 3D Secure haven't been discussed in this list,
> probably because it has [rightfully] been rejected in the US.
> However, 3D Secure is a very cool idea, it just lacks a proper
> platform to run on.
>
> When I read Adrian's push payment manifesto, I realized that the stuff
> I have worked with for a quite some time also could be useful as a
> technical
> foundation for push payments.  Details:
>
> 0. Probably the payer must select payment type (=payment provider)...
> 1. The payer gets a digitally signed payment request from the payee
> 2. The payment request is redirected to the payment provider
> 3. The payer authorizes the payment request at the payment provider using
> a payer key
> 4. The payment provider counter-signs the payment request with its
> provider key
> 5. The resulting object is returned to the payee
> 6. The payee pulls money from the received object trough its payment
> provider
>
> Note that the payer's card details wouldn't be given to the merchant
> when you use your payment provider as the source rather than your card.
> The payer only needs to be authenticated to the payment provider.
>
> Although originally designed with another objective in mind, the following
> steps and platform ought to work for push payments as well:
> http://webpki.org/papers/payments/securing-card-not-
> present-transactions.pdf
>
> I strongly believe that BaM-payments and Web-payments could/should be
> identical.
>
> There are several hurdles.  Banks are slow as h**l, Standardization takes
> forever,
> and Google can do whatever they want:
> http://www.cnet.com/news/google-spells-out-ambitious-
> plan-android-world-domination
>
> Cheers,
> Anders
>
>