Re: Running "Trusted Code" on the Web?

On 2015-02-28 17:13, Jonathan Rosenne wrote:
> 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.

Agreed.

This picture shows more exactly what I'm talking about:
http://webpki.org/papers/decentralized-payments.pdf

I.e. the Amount, PIN, Card image etc. represent a virtual EMV terminal.
A merchant web-site wouldn't be trusted for doing this, at least not in my vision.

So using current web tech you would have to do this on a trusted web-site rather than locally.
Which is why I'm trying to develop new technology that enables this.

Best regards,
Anders

>
> 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:45:30 UTC