Re: 3D Secure++ for Push Payments

p.s. It just occurred to me that your protocol is quit similar to what VISA
and MasterCard tried to do with SET (as I understand SET).
I think it was probably ahead of its time and might have been more
successful today.

I couldn't find anything online other than a wikipedia article about SET
but it looks like almost everything is still available via the internet
archive:
http://web.archive.org/web/20020802134102/http://www.setco.org/





On 27 June 2014 11:07, Adrian Hope-Bailie <adrian@hopebailie.com> wrote:

> 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
>>
>>
>