Re: Secure Element API for Payments

On 2014-01-21 08:05, Brian Thompson wrote:
> I see this as analogous to PCI permitting consumer transactions under X value to not require consumer signature. It is probably aimed at reducing administrative overhead and consumer burden while attempting to decrease fraud risk.
>
> Any resulting framework aimed to reduce risk of fraud will undoubtedly be scoped small and low targeting only low monetary value consumer to merchant transactions and should not be perceived as a replacement for a 7816 web interface (at the moment). 

I don't see why the payment industry would bother introducing inferior technology.
Getting away from non-authenticated card numbers looks like a very important step forward.

>
> Unless there is some hardware cryptographic component as part of their efforts, then I predict this to be a temporary stop-gap until there is a true 2-factor solution. 
>
> BT

Indeed, two-factor authentication and security HW are probably prerequisites.

However, U2F and SKS show that there are other ways achieving this than by adopting smart card schemes that were designed in another time and for an entirely different purpose.

Anyway, 7816 is not my biggest concern; it is the architecture aftermath that bothers me.  The SE API draft doesn't say much about the architecture, it takes it for granted that the SysApps model fits "As Is".  AFAICT, Google's U2F does not build on this assumption.  SKS takes this one step further by not exposing a single API to untrusted web code while still enabling web apps to use advanced cryptography without installing any extra code.  Since merchant code "By Definition" must be regarded as untrusted I'm very curious to know how the SE API would be used for payments.

Cheers,
Anders

>
>> On Jan 20, 2014, at 11:38 PM, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:
>>
>> It has been said the the rationale for having a 7816-interface on the web
>> is for supporting payments. I wouldn't bee too concerned with that:
>>
>> https://newsroom.mastercard.com/press-releases/mastercard-visa-and-american-express-propose-new-global-standard-to-make-online-and-mobile-shopping-simpler-and-safer
>>
>> "Once a standard is agreed to and implemented, issuers, merchants
>> or digital wallet providers would be able to request a token so that
>> when an account holder initiates an online or mobile transaction,
>> the token – and not the traditional card account number"
>>
>> My interpretation of the above is that the payment giants are proposing a high(er)
>> level interface which probably can be realized using WebCrypto, U2F, SKS and friends.
>>
>> If this is correct it means that SE support needs to be integrated in the platform
>> (or wallet) which I think have major usability-, interoperability- and security-
>> advantages over the current approach which seems to be based on the idea that
>> web-apps are talking directly to the SE and thus bypassing the whole platform issue.
>>
>> Since there are many and to date generally unknown issues around direct Web-2-SE
>> communication without having the platform + user as mediator, this path is really
>> only suited for true dare-devils.  I prefer remaining a coward :-)
>>
>> Cheers,
>> Anders
>>

Received on Tuesday, 21 January 2014 09:55:45 UTC