Re: [W3C Web Crypto WG] Rechartering discussion - Gemalto contribution

Yes, Apple Pay is an application that uses EMV Tokenization running on a GP
compliant smart card secure element. Web architecture that would enable an
Application A that uses a Security Applet S running on a Hardware secure
element H is what we should enable. For example one could say -- A = BofA
App, S = FIDO, H = Yubikey NEO.

Attached is that proposal that would allow for flexibility in A, S, and H.
Not just in A and H.


*--*


*Siva G. Narendra Ph.D. CEO - Tyfone, Inc.Portland | Bangalore |
Taipeiwww.tyfone.com <http://www.tyfone.com>*
*Voice: +1.661.412.2233*


On Mon, Feb 2, 2015 at 1:06 PM, Anders Rundgren <
anders.rundgren.net@gmail.com> wrote:

> Hi Siva,
> Apple Pay is an application.
>
> There's no application in Gemalto's presentation since they (apparently)
> believe that the merchant by definition is trusted for directly accessing
> the card.
>
> This is a downright horrible assumption and would never pass EMVCo
> certification either.
>
> Regards
> Anders
>
> On Feb 2, 2015 9:29 PM, "Siva Narendra" <siva@tyfone.com> wrote:
> >
> > Hi Anders. While traditional EMV on GP Smart Card does not easily allow
> for it, that is exactly what EMV Tokenization enables. Apple Pay implements
> EMV Tokenization on a GP Smart Card chip. Google Wallet can leverage EMV
> Tokenization independent of Apple for the same credit card number. And so
> can other independent GP hardware. Similar to Tokenization for EMV, atleast
> in the US even the government standards for CAC/PIV recently released what
> is called as Derived Credential. This space is rapidly evolving and we
> shouldn't get tied up with one approach such as FIDO assuming rest of the
> world will adopt it.
> >
> > Best,
> > Siva
> >
> >
> >
> > --
> > Siva G. Narendra Ph.D.
> > CEO - Tyfone, Inc.
> > Portland | Bangalore | Taipei
> > www.tyfone.com
> > Voice: +1.661.412.2233
> >
> >
> > On Mon, Feb 2, 2015 at 12:18 PM, Anders Rundgren <
> anders.rundgren.net@gmail.com> wrote:
> >>
> >> On 2015-02-02 19:54, Siva Narendra wrote:
> >>
> >> Hi Siva,
> >> Disregarding the privacy and authentication issues for a moment, I
> still don't understand how you could perform EMV-like payments using the
> posted proposals unless you bind the EMV-token to a single domain and used
> some kind of IFRAME+postMessage() arrangement which is [sort of] FIDO
> anyway.
> >>
> >> Gemalto needs to do this exercise and show it to the world (which they
> BTW to date have had more than three years to carry out):
> >> https://lists.w3.org/Archives/Public/public-identity/2011Nov/0030.html
> >>
> >> I'm dead-sure Apple won't build on the ideas presented in this list,
> they will rather "call" their Apple Pay wallet application from the web
> which is a MUCH better idea than (which already has been said), trying to
> shoehorn in legacy stuff that never was designed for the [UNTRUSTED] web:
> >>
> https://lists.w3.org/Archives/Public/public-webcrypto-comments/2015Jan/0000.html
> >>
> >> Anders
> >>>
> >>> Brad,
> >>>
> >>> Great points.
> >>>
> >>> I believe your analysis about control exerted by carriers and device
> makers on global platform (GP) hardware is absolutely true, but that is not
> the complete story.
> >>>
> >>> Several independent GP hardware containers such as SD Cards, USB
> tokens, NFC tokens, BTLE tokens support GP security through smart card
> secure elements and that is not controlled by the carriers or device
> makers. These solutions are becoming more common.
> >>>
> >>> I beleive, unless I'm mistaken, FIDO leverages such GP secure elements
> in its devices. This was possible only because several companies already
> built such standards (GP) based secure elements and devices, for use with
> the web, even though web did not standardize its interfacing to such
> hardware.
> >>>
> >>> These devices allow any application developer to take advantage of
> hardware security, just like FIDO based application developers can.
> >>>
> >>> What some of us are asking for is to make sure that when web supports
> hardware security, that it be generic to support further innovation and not
> be limited to FIDO.
> >>>
> >>> I assume you do not object to this. Or is your view that all roads
> shall lead only to FIDO?
> >>>
> >>> Siva
> >>>
> >>> On Feb 2, 2015 8:10 AM, "Brad Hill" <hillbrad@fb.com> wrote:
> >>>>
> >>>> It's not so much that I don't think a solution might be found.  It's
> that I think the proposed solution in front of us is absolutely terrible
> for users, innovators, and the future of the Web.
> >>>>
> >>>> The proposal on the table suggests that privacy and key scoping for
> WebCrypto would be managed by the GlobalPlatform/TEE model.  This is the
> model in which only specially signed code installed on your device, in a
> way that is by-design exclusive and limited, could talk to end-user crypto
> devices, even general-purpose ones.
> >>>>
> >>>> This puts your network carrier and device manufacturer are in an
> (even more) privileged position to decide which applications users can
> access on the Web.  Nothing you want to do involving a cryptographically
> strong authentication, payment, identity, etc. could happen without a prior
> business arrangement between that entity and the entities in control of
> your device.
> >>>>
> >>>> I don't have to work hard to imagine a world in which this becomes a
> powerful weapon against consumer choice and disruptive innovation because
> it is already here.  Look at the mobile  payments space where a similar
> model gateways installation of apps and access to handset hardware crypto.
> Handset makers pay have exclusive deals only with some banks, or only with
> one bank.  They retaliate against payment providers that dare to launch
> features on rival platforms.  Merchants deny users the choice of payment
> providers through compatible APIs because they want to launch their own
> system.  Disruptive innovators like bitcoin wallets are denied access to
> the platform entirely.
> >>>>
> >>>> The online economy soldiers on, in no small part because there is
> always the Web to fall back to.  That the Web has been so powerful in
> creating value for people and the global economy is in no small way
> attributable to its being an open platform for innovation that has mostly
> managed to avoid this kind of Balkanization.
> >>>>
> >>>> If the mechanism of access to W3C-standard APIs for accessing strong
> cryptographic services is premised on side-channel arrangements between
> powerful organizations instead of user choice, it will be a disaster for
> users and for the Web.  To paraphrase an apocryphal quote by Admiral
> Yamomoto, there will be rent-seeking behind every blade of grass, as my
> access to banking, health care, payments, shopping, secure communications,
> and more are determined not by my free choice in a competitive market (or
> which URL I choose to browse to), but by which player in each industry is
> willing to pay the most to my mobile network provider and/or handset
> manufacturer for exclusive access to their customers.
> >>>>
> >>>> This is unacceptable.  And positing regulation to enforce open access
> is not an acceptable answer - the technologies of the Open Web Platform
> should encourage competition and innovation by default, not only with
> permission and legislation.
> >>>>
> >>>> -Brad Hill
> >>>>
> >>>>
> >>>> From: POTONNIEE Olivier <Olivier.Potonniee@gemalto.com>
> >>>> Date: Monday, February 2, 2015 at 1:22 AM
> >>>> To: Bradley Hill <hillbrad@fb.com>, "PHoyer@hidglobal.com" <
> PHoyer@hidglobal.com>
> >>>> Cc: Harry Halpin <hhalpin@w3.org>, Lu HongQian Karen <
> karen.lu@gemalto.com>, "public-web-security@w3.org" <
> public-web-security@w3.org>, "public-webcrypto@w3.org" <
> public-webcrypto@w3.org>, GALINDO Virginie <Virginie.Galindo@gemalto.com>,
> Wendy Seltzer <wseltzer@w3.org>
> >>>> Subject: RE: [W3C Web Crypto WG] Rechartering discussion - Gemalto
> contribution
> >>>>
> >>>>> Brad,
> >>>>>
> >>>>>
> >>>>>
> >>>>> The same-origin policy does not necessarily make sense for all
> resources used on the web, in particular those that are not web-originated,
> such as the tokens we’re talking about here. Just consider WebRTC, and the
> access it gives to the (uniquely identifying) user voice: does this means
> that WebRTC should be banned from the web? On a different aspect, is your
> geolocation protected by SOP?
> >>>>>
> >>>>> For such non web-originated resources, a specific security model
> applies.
> >>>>>
> >>>>> This is exactly what we want to set up with a proper access control
> mechanism for the hardware tokens. Without assuming a priori that “hardware
> will need to be adapted”, but not necessarily excluding it (although we’re
> actually talking about software changes here…).
> >>>>>
> >>>>> --
> >>>>>
> >>>>> Olivier
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> From: Brad Hill [mailto:hillbrad@fb.com]
> >>>>> Sent: dimanche 1 février 2015 22:26
> >>>>> To: PHoyer@hidglobal.com
> >>>>> Cc: Harry Halpin; Lu HongQian Karen; public-web-security@w3.org;
> public-webcrypto@w3.org; GALINDO Virginie; Wendy Seltzer
> >>>>> Subject: Re: [W3C Web Crypto WG] Rechartering discussion - Gemalto
> contribution
> >>>>>
> >>>>>
> >>>>>
> >>>>> I agree entirely with (b), but I think we need to start with the Web
> security model as our first principle to build on, and hardware will need
> to be adapted to and find ways to operate within that model.  That is what,
> e.g. FIDO has done.
> >>>>>
> >>>>>
> >>>>>
> >>>>> This proposal is about starting with the first principle that legacy
> hardware devices that were never designed for the web environment must be
> supported, and finding ways to shoehorn them into browser APIs, with the
> best excuse being that the "damage is already done" by things like
> ActiveX.  We've spent a long time walking back the mistakes of ActiveX, I'd
> not like to backtrack.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Basically I think this is a priority of constituencies issue.  It is
> more important that we consider the priorities of the user in having a web
> that isn't authenticating and cross-linking them in a cryptographically
> strong manner without their consent, and that whatever devices they do
> purchase or have provisioned to them are able to be used in an open, safe
> and privacy-respecting manner.
> >>>>>
> >>>>>
> >>>>>
> >>>>> I understand the concerns of application and service providers who
> want to leverage their existing investment in billions of legacy devices
> already in the hands of the user, but I just don't think those concerns
> outweigh doing what is best for users and taking security on the web
> forward instead of backwards.
> >>>>>
> >>>>>
> >>>>>
> >>>>> In particular, I think if the best we can do for "privacy" for these
> devices is to say that it is managed on your behalf through back-room
> arrangements between your bank, government, handset provider and network
> carrier, acting in their interests first and without your consent, (I.e.
> GlobalPlatform / TEE solution in which your hardware token can only talk to
> signed applications "approved" by someone else) that isn't good enough, and
> goes against the entire open innovation model that's made the web a success.
> >>>>>
> >>>>>
> >>>>>
> >>>>> -Brad
> >>>>>
> >>>>>
> >>>>>
> >>>>> From: "PHoyer@hidglobal.com" <PHoyer@hidglobal.com>
> >>>>> Date: Friday, January 30, 2015 at 10:28 AM
> >>>>> To: Bradley Hill <hillbrad@fb.com>
> >>>>> Cc: Harry Halpin <hhalpin@w3.org>, Lu HongQian Karen <
> karen.lu@gemalto.com>, "public-web-security@w3.org" <
> public-web-security@w3.org>, "public-webcrypto@w3.org" <
> public-webcrypto@w3.org>, GALINDO Virginie <Virginie.Galindo@gemalto.com>,
> Wendy Seltzer <wseltzer@w3.org>
> >>>>> Subject: Re: [W3C Web Crypto WG] Rechartering discussion - Gemalto
> contribution
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> Brad,
> >>>>>> one point that I made at the workshop is that currently centrally
> issued eIDs are being used on the web and with web applications.
> >>>>>>
> >>>>>> So it is not that we are talking about introducing something new
> that breaks privacy or security we are already in a world where this
> happens.
> >>>>>>
> >>>>>> The people in W3C and in the W3 are uniquely positioned as willing
> experts in the field to find a solution that is
> >>>>>>
> >>>>>> a) homogenous in the approach and does not mean inexperienced web
> developers have to wrestle with java / activX plugins potentially putting
> other web apps accessed by the same browser at risk due to security lapses
> in the plugins
> >>>>>> b) can actually improve the situation and potentially find a way to
> increase privacy and security of the existing solution especially as we
> have mindshare of the browser development community
> >>>>>>
> >>>>>> I completely share your view that we need to tackle this issue but
> is a WG not exactly the right place to do this?
> >>>>>>
> >>>>>> Philip
> >>>>>>
> >>>>>>
> >>>>>> Brad Hill ---29/01/2015 22:52:23---I would like to see details of
> how this kind of API would or could interact with the Same-Origin mod
> >>>>>>
> >>>>>> From: Brad Hill <hillbrad@fb.com>
> >>>>>> To: Lu HongQian Karen <karen.lu@gemalto.com>, GALINDO Virginie <
> Virginie.Galindo@gemalto.com>, "public-webcrypto@w3.org" <
> public-webcrypto@w3.org>
> >>>>>> Cc: "public-web-security@w3.org" <public-web-security@w3.org>,
> Wendy Seltzer <wseltzer@w3.org>, Harry Halpin <hhalpin@w3.org>
> >>>>>> Date: 29/01/2015 22:52
> >>>>>> Subject: Re: [W3C Web Crypto WG] Rechartering discussion - Gemalto
>   contribution
> >>>>>>
> >>>>>> ________________________________
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> I would like to see details of how this kind of API would or could
> interact with the Same-Origin model of web security, specifically:
> >>>>>>
> >>>>>> 1. Privacy and tracking.  How does the presence of specific crypto
> elements and discoverable keys which are not Origin-scoped not create
> privacy violations?
> >>>>>>
> >>>>>> 2. Origin security.  How are risks around identification of or
> impersonation of the server-side of a transaction, and potential abuse of a
> globally-scope key mitigated by  this kind of API design?
> >>>>>>
> >>>>>> Without a clear discussion of how this API fits into the existing
> Web security and threat model, I think it is inappropriate to proceed.  We
> can't just throw away the fundamental security model that billions of users
> and deployed applications depend on, and I see no evidence (at least in
> these few slides) that such issues have been considered by this proposal.
> >>>>>>
> >>>>>> Brad Hill
> >>>>>>
> >>>>>> From: Lu HongQian Karen <karen.lu@gemalto.com>
> >>>>>> Date: Wednesday, January 28, 2015 at 10:01 AM
> >>>>>> To: GALINDO Virginie <Virginie.Galindo@gemalto.com>, "
> public-webcrypto@w3.org" <public-webcrypto@w3.org>
> >>>>>> Cc: "public-web-security@w3.org" <public-web-security@w3.org>,
> Wendy Seltzer <wseltzer@w3.org>, Harry Halpin <hhalpin@w3.org>
> >>>>>> Subject: RE: [W3C Web Crypto WG] Rechartering discussion - Gemalto
> contribution
> >>>>>> Resent-From: <public-web-security@w3.org>
> >>>>>> Resent-Date: Wednesday, January 28, 2015 at 10:04 AM
> >>>>>>
> >>>>>> Please review Gemalto’s contribution. We welcome your comments.
> >>>>>>
> >>>>>> Regards,
> >>>>>> Karen
> >>>>>>
> >>>>>> From: GALINDO Virginie [mailto:Virginie.Galindo@gemalto.com]
> >>>>>> Sent: Wednesday, January 07, 2015 3:48 AM
> >>>>>> To: public-webcrypto@w3.org
> >>>>>> Cc: public-web-security@w3.org; Wendy Seltzer; Harry Halpin
> >>>>>> Subject: [W3C Web Crypto WG] Rechartering discussion
> >>>>>>
> >>>>>> Dear all,
> >>>>>>
> >>>>>> Web Crypto WG charter [1] will end by the end of March. We need to
> prepare the next charter of Web Crypto.
> >>>>>>
> >>>>>> As a reminder, the conversation has started on this page :
> https://www.w3.org/Security/wiki/IG/webcryptonext_draft_charter
> >>>>>> Feel free to add you ideas and suggestions on the wiki and/or
> expose your opinion and question on the public-webcrypto@w3.org or
> public-webcrypto-comment@w3.org (for non W3C Web Crypto WG members).
> >>>>>>
> >>>>>> Regards,
> >>>>>> Virginie
> >>>>>>
> >>>>>> [1] http://www.w3.org/2011/11/webcryptography-charter.html
> >>>>>>
> >>>>>>
> >>>>>> ________________________________
> >>>>>>
> >>>>>> 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 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 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
> >>>>>>
> >>>>>>
> >>>>>> ------------------------------------------------------------
> >>>>>> HID Global GmbH
> >>>>>> registered office: 65396 Walluf, Germany
> >>>>>> municipal court: Wiesbaden, Germany
> >>>>>> commercial register number: HRB 20928
> >>>>>> Management board: Denis Hebert, Juergen Schnoebel, Marc Bielmann
> >>>>>>
> >>>>>> Confidentiality Note:
> >>>>>> This message is intended for use only by the individual or entity
> to which it is addressed and may contain information that is privileged,
> confidential, and exempt from disclosure under applicable law. If the
> reader of this message is not the intended recipient or the employee or
> agent responsible for delivering the message to the intended recipient, you
> are hereby notified that any dissemination, distribution or copying of this
> communication is strictly prohibited. If you have received this
> communication in error, please contact the sender immediately and destroy
> the material in its entirety, whether electronic or hard copy. Thank you.
> >>>>>
> >>>>> ________________________________
> >>>>> 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 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
> >>
> >>
> >
>
>