W3C home > Mailing lists > Public > public-web-security@w3.org > October 2014

RE: [Web Crypto Next] Status and next steps

From: JAVARY Bruno <B.JAVARY@oberthur.com>
Date: Wed, 15 Oct 2014 06:17:46 +0000
To: Siva Narendra <siva@tyfone.com>, Colin Gallagher <colingallagher.rpcv@gmail.com>, "anders.rundgren.net@gmail.com" <anders.rundgren.net@gmail.com>
CC: "virginie galindo@gemalto. com" <virginie.galindo@gemalto.com>, "public-web-security@w3 org" <public-web-security@w3.org>, "wseltzer@w3.org" <wseltzer@w3.org>, Harry Halpin <hhalpin@w3.org>, "hnahari@nvidia.com" <hnahari@nvidia.com>
Message-ID: <4FE578D6EF4FF348BB311EB3E22FD5C9096532@FRPASERV0087.emea.oberthurcs.com>
Hi Everyone,
I do agree with Siva, enabling an access to secure element in general will allow to address many use cases and can multiply implementations.

Kind regards,


De : Siva Narendra [mailto:siva@tyfone.com]
Envoyé : mercredi 15 octobre 2014 00:10
À : Colin Gallagher; anders.rundgren.net@gmail.com
Cc : virginie galindo@gemalto. com; public-web-security@w3 org; wseltzer@w3.org; Harry Halpin; hnahari@nvidia.com
Objet : Re: [Web Crypto Next] Status and next steps

Hopefully we standardize a "pipe" and not be prescriptive on specific ID auth/management methods (e.g. EMV organizations, FIDO, PKCS, Derived credential etc). So all such relevant ID auth methods can co-exist since it is very difficult envision convergence of between these methods.


On October 14, 2014, at 1:30PM, Colin Gallagher wrote:

Briefly adding from my mobile: that integration of secure elements with both user-managed and non-user managed IDs, should be considered... and what kind of hybridized systems may emerge? (Thinking here of keybase.io<http://keybase.io>, onename.io<http://onename.io>, BitID and similar, which hybridize web-based in-browser solutions, hashing into bitcoin blockchain, etc)
On Oct 14, 2014 1:08 PM, "Anders Rundgren" <anders.rundgren.net@gmail.com<mailto:anders.rundgren.net@gmail.com>> wrote:
On 2014-10-14 20:29, Siva Narendra wrote:
To add one more point ... the work that we hope to accomplish as a
> follow up to the recent W3C workshop on hardware tokens, that would
> allow seamless integration of secure elements (with non-user managed IDs)
> to the browsers will enable Apple Pay type convenient and secure ecommerce to the web.

So let's figure out how!

There we have a truly Herculean task!

FIDO "cheated" and took the route which I have advocated years before FIDO started [1], namely building a standardized web-enabled security-element architecture which can be implemented as external tokens, pure software or be a part of a TEE.
A guesstimate is that the specification-set would "only" require 300-400 pages to match existing (non-webby) tokens.

However, "there is more than meets the eye" [2], at least in my take on the matter we are talking about major changes in both browsers and OSes.


1] First public (Y2K8) document:

2] https://www.youtube.com/watch?v=0O1v_7T6p8U


On October 14, 2014, at 11:16AM, Siva Narendra wrote:

Hadi is right. Officially it is expected that visa/mc will put a ecommerce pricing table together that uses tokenization (like Apple Pay) that has has lower rates than traditional CNP ecommerce. Will it approach CP rates depends on ID Validation and Assurance used.

Apple Pay tokens have NIST Level 4 ID Assurance because of the use of hardware secure element. I think iPhone 6 has a SmartMX smart card controller. So CP rates is quite likely for Apple Pay based ecommerce.


On October 14, 2014, at 10:19AM, Hadi Nahari wrote:

Rumor has it that Apple Pay might be getting CP (Card Present) rates for
remote purchases made using iPhone 6/+.

Hadi Nahari, Chief Security Architect,  NVIDIA
M:+1.650.605.3564<tel:%2B1.650.605.3564>  O:+1.408.562.7916<tel:%2B1.408.562.7916>
Dubito ergo mihi licet esse

On 10/11/14, 10:42 PM, "Anders Rundgren" <anders.rundgren.net@gmail.com<mailto:anders.rundgren.net@gmail.com>>
Hi Virginie,

During the 20Y+ we have bought stuff on the web and paid with credit
the method haven't changed.  That is, in spite of a billion s.c. EMV-cards
in circulation, on the web we are currently stuck with highly inconvenient
and (any number of times proved) unsecure CNP (Card Not Present) schemes..

To me it looks like a task for your particular sector coming up with a
proposal on how to address this pretty obvious use case.

Apple have advanced the state of on-line payments by a mile in iPhone 6,
but AFAIK it doesn't include the web.

Anders Rundgren

On 2014-10-10 14:57, GALINDO Virginie wrote:
Dear all,

A short status of where we are in the Web Crypto Next Workshop follow

-As announced [1], a wiki has been set up to receive your ideas about
the re-chartering of Web Crypto WG, taking into account the findings of
the Web Crypto Next Workshop.

-The workshop report will soon made available by Harry Halpin probably
next week, it will be circulated on this mailing list for review during
one week.

-During  W3C TPAC meeting scheduled on 26-31 Oct [2] , there will be
some actions to socialize the workshop findings with W3C members (during
security related WG, during the AC representatives meeting, and during
Wednesday Break-Out sessions)

-Still during the TPAC week, Wendy, W3C security domain leader has
organized a conversation with Web App Sec and Web Crypto chairs to see
how we could re-charter both groups in synchronization, taking into
account workshop findings.

If you need some help to contribute, give your opinion, better
understand direction, do not hesitate to ask question to Wendy, Harry,
or myself !


Virginie Galindo


signing as chair of web crypto / chair of web security ig


[2] http://www.w3.org/2014/11/TPAC/

This message and any attachments are intended solely for the addressees
and may contain confidential information. Any unauthorized use or
disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable
for the message if altered, changed or falsified. If you are not the
intended recipient of this message, please delete it and notify the
Although all reasonable efforts have been made to keep this
transmission free from viruses, the sender will not be liable for
damages caused by a transmitted virus.

This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.

Received on Wednesday, 15 October 2014 10:01:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:09:33 UTC