Re: Running "Trusted Code" on the Web?

Are you aware of EmvCo Tokenisation and its use with ApplePay?

????? ????

054-4246522


??-28 ????? 2015, ???? 09:12, ??Anders Rundgren ?<anders.rundgren.net@gmail.com<mailto:anders.rundgren.net@gmail.com>> ???/?:?

On 2015-02-28 03:30, Manu Sporny wrote:
<snip>
What you're suggesting, though, is a demonstrable non-solution.

We were addressing different uses of payment instruments.  In my
example there's no magstrip only "cryptograms".  Your example presumed card data.

BTW, this actually raises an interesting question: How can you get away from unsecure
card data but still be able storing something "card-ish" in places like PayPal?

A possibility is creating a cryptogram with the payment credential which gives
the specific party rights to withdraw money.  Such a system would not be sensitive
to theft.


> What is
wrong with the current proposal of "don't expose the sensitive payment
data to any system held by the customer or the merchant?" Isn't this
approach simpler than creating a secure execution environment for Web
code (if that's even possible)?

Both are needed.  IMO.


I think you're right in that we need something like web intents to
transmit non-sensitive payment messages and cryptograms from browsers to
native apps (like wallets) and back.

Yes, that's what I work with, currently on a PoC level. An "early version" is available today:
http://www.cnet.com/news/google-paves-over-hole-left-by-chrome-plug-in-ban/


> I'm not so sure we need a secure execution environment for Javascript code.

If you are going to expose things like EMV keys to web-code the code must
(in order to pass EMV certification) be fixed in some way.  I started here but have
given up this path not because it is undoable, but because the number of things
to be standardized could easily make this a 10 year project and I don't think we
need such.

Anders