Re: Running "Trusted Code" on the Web?

On 2015-02-28 11:41, Jonathan Rosenne wrote:
> Are you aware of EmvCo Tokenisation and its use with ApplePay?

Hi Jonathan,

Exactly how everything works in detail I don't know; it isn't public.
BTW, this seems to be an issue with just about every payment system...

Anyway, the principle seems to be that the card or the payment terminal
creates a unique payment cryptogram which is given to the merchant.

Whatever method used you depend on "Trusted Code" including PIN input.

Without this element, your only option is strong authentication to a payment provider which does the EMV tokenization for you.

Anders


>
> יונתן רוזן
>
> 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
>>
>>
>>

Received on Saturday, 28 February 2015 11:06:49 UTC