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

Re: The TPM is dead, long live the TEE!

From: Adrian Hope-Bailie <adrian@hopebailie.com>
Date: Thu, 24 Jul 2014 02:55:47 +0200
Message-ID: <CA+eFz_LC_mjX2_mYnQekaG-43mvMa8FaAw_BN9+yjoncy9KCgw@mail.gmail.com>
To: Joseph Potvin <jpotvin@opman.ca>
Cc: Manu Sporny <msporny@digitalbazaar.com>, Web Payments CG <public-webpayments@w3.org>
Hi guys,

The one time I am awake late enough to join the telecon and it's cancelled!

May I suggest that we consider the concept of a "channel"?
I define a channel as a "means of processing a payment including the rules
around how the payments is processed (unit of account, clearing and
settlement timelines etc)."

In the use cases under review I would substitute many of the uses of
"payment processor" with "channel" so that we have a use case like:

When a payer intends to make a payment, they are given a choice to pick
among the intersection of the channels they support and the channels that
are advertised by the payee.

Example:
Payer supports payment in USD via VISA Credit Card, PayPal Wallet or
MasterCard Debit and in BTC via Bitcoin.
Payee accepts payment in USD, GBP and EUR via VISA Credit, Debit and
MasterCard Credit and Debit. The payee would likely also advertise the
details (endpoint URL) of the gateway for processing payments on each
channel and the interface/API version etc.

With OpenPayee that was what I was striving for ultimately.
The payee simply shares an identifier (could just be a URL) which the payer
(through discovery or some defined protocol) uses to get a document listing
the payment options (Channels) supported by the payee.
If the payee provides a static URL it will simply list the channels, if it
is dynamic (per transaction) it could be specific to that transaction
(exclude certain channels or provide specific pricing in various currencies
etc).

Adrian



On 23 July 2014 14:04, Joseph Potvin <jpotvin@opman.ca> wrote:

> RE: "Visa, Mastercard, PayPal, Bitcoin, Ripple, etc. to all be listed as
> payment options by the merchant and selected freely by the customer"
>
> +0.8
>
> For refinement & clarification (I hope), these brands represent
> different "media-of-exchange" types, two being branded "credit card
> systems", one a branded "block chain system", one a branded "automated
> clearing house (ACH)" system.
>
> The Bitcoin and Ripple communities have been using terms in ways that
> conflate unit of account and medium of exchange.  For example it does
> not make sense that we can say both:  "Visa, Mastercard, PayPal,
> Bitcoin, Ripple"  and  "USD, EUR, BTC, XRP"
>
> In the interest of disambiguation, I would suggest saying:
> "Visa, Mastercard, PayPal, Bitcoin System, Ripple System" with
> reference to the media of exchange
> "USD, EUR, BTC, XRP" with reference to the units of account
>
> --
> Joseph Potvin
> Operations Manager | Gestionnaire des opérations
> The Opman Company | La compagnie Opman
> jpotvin@opman.ca
> Mobile: 819-593-5983
>
> On Tue, Jul 22, 2014 at 9:54 PM, Manu Sporny <msporny@digitalbazaar.com>
> wrote:
> > On 07/13/2014 12:33 AM, Anders Rundgren wrote:
> >> How come the competition didn't buy into the TPM?
> >>
> >> TPMs are based on a "one-size-fits-all" security API philosophy.
> >> Since Intel relies on external vendors supplying TPM-components this
> >> (IMHO fairly unwieldy) API must also be standardized which makes the
> >> process updating TPMs extremely slow and costly.
> >>
> >> TEEs OTOH can be fitted at any time with application-specific
> >> security APIs which both can be standardized or entirely proprietary.
> >> In fact, even third-parties can create new security APIs using
> >> GlobalPlatform's TEE!
> >
> > Hey Anders,
> >
> > Could you elaborate a bit more on how we could apply this approach to
> > the Web Payments initiative? The part that I don't understand is that if
> > you allow entirely proprietary APIs into the mix, how do you achieve
> > interoperability? Does it not matter at that level?
> >
> > To bring this more in line w/ what we're doing. We hope that the payment
> > initiation mechanism that we end up standardizing is going to allow
> > Visa, Mastercard, PayPal, Bitcoin, Ripple, etc. to all be listed as
> > payment options by the merchant and selected freely by the customer
> > depending on which payment mechanism they want to use. Is this an
> > example of the approach that you're suggesting?
> >
> > -- manu
> >
> > --
> > Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> > Founder/CEO - Digital Bazaar, Inc.
> > blog: The Marathonic Dawn of Web Payments
> > http://manu.sporny.org/2014/dawn-of-web-payments/
> >
>
>
Received on Thursday, 24 July 2014 00:56:15 UTC

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