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

Hi Siva,

I think it is up to Gemalto showing how they could "Apple Pay" using their
proposal.

Anders

On Feb 2, 2015 10:19 PM, "Siva Narendra" <siva@tyfone.com> wrote:
>
> 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 | Taipei
> 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
>> >>
>> >>
>> >
>
>