Re: Running "Trusted Code" on the Web?

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

Received on Saturday, 28 February 2015 07:11:44 UTC