Re: [Web Crypto Next] Status and next steps

Briefly, I will add this link here as a resource for those interested in
updates to tools that explore EMV (etc.) vulnerabilities.
http://pannetrat.com/Cardpeek (Updated as of Aug 15, 2014)

On Tue, Oct 14, 2014 at 11:17 PM, JAVARY Bruno <B.JAVARY@oberthur.com>
wrote:

>  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,
>
>
>
> *Bruno *
>
>
>
> *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.
>
> -Siva
>
>
>
> 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,
> onename.io, BitID and similar, which hybridize web-based in-browser
> solutions, hashing into bitcoin blockchain, etc)
> Cheers,
> C
>
> On Oct 14, 2014 1:08 PM, "Anders Rundgren" <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.
>
> Cheers,
> Anders
>
> 1] First public (Y2K8) document:
> http://webpki.org/papers/keygen2/keygen-all-protocol-steps.html
>
> 2] https://www.youtube.com/watch?v=0O1v_7T6p8U
>
>
> -Siva
>
> 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.
>
> -Siva
>
> 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/+.
>
> Regards,
> -Hadi
> \----------------------------------------------
> Hadi Nahari, Chief Security Architect,  NVIDIA
> M:+1.650.605.3564  O:+1.408.562.7916
> ----------------------------------------------\
> Dubito ergo mihi licet esse
>
>
>
>
>
> On 10/11/14, 10:42 PM, "Anders Rundgren" <anders.rundgren.net@gmail.com>
> wrote:
>
> Hi Virginie,
>
> During the 20Y+ we have bought stuff on the web and paid with credit
> cards,
> 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.
>
> Sincerely,
> 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
> up.
>
> -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 !
>
> Regards,
>
> Virginie Galindo
>
> gemalto
>
> signing as chair of web crypto / chair of web security ig
>
> [1]
> http://lists.w3.org/Archives/Public/public-web-security/2014Oct/0001.html
>
> [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
> sender.
> 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.
>
> -----------------------------------------------------------------------------------
>
>
>