W3C home > Mailing lists > Public > public-webpayments@w3.org > June 2014

SET (Safe Electronic Transaction) Was: 3D Secure++ for Push Payments

From: Anders Rundgren <anders.rundgren.net@gmail.com>
Date: Fri, 27 Jun 2014 16:14:13 +0200
Message-ID: <53AD7C35.2090800@gmail.com>
To: Adrian Hope-Bailie <adrian@hopebailie.com>
CC: Web Payments CG <public-webpayments@w3.org>
On 2014-06-27 15:08, Adrian Hope-Bailie wrote:
> 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).

That's right!  Being an old fart I actually tried SET 1998 since Swedish banks were one of the first to launch it.

The SET "business process" description is quite good:

> I think it was probably ahead of its time and might have been more successful today.

It was a very ambitious effort requiring a (for that time) advanced pretty fat browser plugin/wallet.
Regarding successful today, EMV cards remain unusable on the Internet.

Gemalto is trying though: http://opoto.github.io/secure-element
I find this approach pretty much at odds with how the web works.

Some people claim the the "final solution" will be unveiled at:

We'll see about that.  Personally, I believe mobile devices will perform this task (device = holds a bunch of embedded credentials).
Then you get away from cards, readers, third-party middleware and APIs designed like 20 years ago.

Unfortunately most things in this space is NDA-protected including the Google Wallet and ARM's TrustZone.

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

Thank you very much.  I must have had that old spec. somewhere in my head when I did this writeup!

Mixing the two failed predecessors (3D Secure and SET) will surely create DOUBLE EPIC FAILURE :-) :-)


> On 27 June 2014 11:07, Adrian Hope-Bailie <adrian@hopebailie.com <mailto: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 <mailto: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 <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 <http://www.cnet.com/news/google-spells-out-ambitious-plan-android-world-domination>
>         Cheers,
>         Anders
Received on Friday, 27 June 2014 14:14:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:32 UTC