RE: Running "Trusted Code" on the Web?

The issuer (the bank) authorizes the token service provider (e.g. Visa or MasterCard) to issue to a cardholder device (e.g. an iPhone) a token that is in effect a unique identifier ("card number" or "PAN"). The specification is publicly available at http://www.emvco.com/specifications.aspx?id=263.


The authorization request does contain an unspecified cryptogram.

It is worthwhile to note that the communication between the token and the token service provider is not necessarily trusted.

Best Regards,

Jonathan Rosenne

054-4246522
-----Original Message-----
From: Anders Rundgren [mailto:anders.rundgren.net@gmail.com] 
Sent: Saturday, February 28, 2015 1:06 PM
To: Jonathan Rosenne
Cc: public-webpayments-comments@w3.org
Subject: 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-i

>> n-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 16:14:56 UTC