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

Regarding to the need of prior business agreement, it really depends on the sensitive and security levels of the applications. Some of them may not need such agreement and others will need.

This is exactly my point.  For any application where there is value at stake, rent-seekers will appear.  A platform that is only "open" for toy applications is not actually open.


A couple of years ago, the OpenID Foundation said one of the advantages of OID comparing to SAML-based solutions was that it does not require prior business agreement. Later it realized the need and Open Identity Exchange (OIX) was established, following the model of the InCommon trust framework of the Internet2.

The analogy to OIX is incorrect.  OID standardized the technical mechanisms for self-assembling information exchange – and did so in a way that respected the existing security and privacy model of the web.  What OIX is for is to standardize the contractual parts of those relationships between the parties actually involved.  Yes, the service provider and identity provider may need a contract to work together on some things, but my choice to interact with either one as a user is still my choice and not contingent on unrelated parties who just happen to be in a position to block or enable it.  OIX is absolutely not about saying that only providers that have established OIX status can use OID APIs – it's a voluntary arrangement that can layer on top of those APIs.  And OIX is definitely not about saying that only providers that have paid an unrelated third party like my browser vendor, phone manufacturer, or ISP will be allowed to use OID APIs.


The fact is that many companies have provided proprietary solutions for web applications to use secure hardware tokens for strong authentication, ebanking, online payment, digital signature, data encryption, and so on. Proprietary solutions have a lot of limitations. We wish to get support from the W3C community and browser makers to improve the situation and to server more people with security and privacy.

The proposal may be terrible, but it at least stirred up discussions. What are your suggestions?


I'm not saying that the FIDO proposals are the only solution possible, but they do provide an example of how strong authentication services can be offered in an open manner, enabling user choice, and working within the Web security and privacy model.

Things like TEE can be used to enhance FIDO, by e.g. adding to the protections against malware for components that are part of the TCB, but they are optional implementation choices.  Nothing in the FIDO protocols or APIs mandates that you must use a certified FIDO client or authenticator.  All of the essential security and privacy properties of the solution are inherent in the protocol and APIs.  Attestable authenticators and TEE-based FIDO clients can add assurance for sophisticated, risk-based management strategies, but the fundamental protections for the user do not depend on them.

That is the kind of pattern I think we need for any W3C hardware crypto APIs. Provide fundamental value to service providers and users, while respecting user privacy, security and choice, as a foundational part of the protocol and API design, and allow higher-value services to be optionally layered on top with appropriate safeguards that they are in the user's interest.

The problem with this proposal is that is has absolutely no story for how to protect users or provide useful and safe services in the absence of gatekeepers who happen to be in a natural position (and have a historical track record of) of rent-seeking.  If that entity is strict, the user is "protected" from those outside the system, but exploited economically by those on the inside.  If that entity is lax, then the user has no meaningful protections.

That is a failure of fundamental requirements.

I don't think it is incumbent on us to "do something, anything!" immediately on this front.  It is incumbent to only do things that respect our priority of constituencies, the values of the Open Web Platform and which we have every reason to believe will lead to good outcomes which preserve freedom of choice and freedom to innovate while enhancing security and privacy.  If we can't meet that bar, we should do nothing rather than do something harmful.

It is not my obligation to provide a counter-proposal, (though FIDO certainly provides and example) rather it is on those who want this proposal to advance to demonstrate that it would be a good thing if it did.

-Brad




From: Brad Hill [mailto:hillbrad@fb.com]
Sent: Monday, February 02, 2015 10:07 AM
To: POTONNIEE Olivier; PHoyer@hidglobal.com<mailto:PHoyer@hidglobal.com>
Cc: Harry Halpin; Lu HongQian Karen; public-web-security@w3.org<mailto:public-web-security@w3.org>; public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>; GALINDO Virginie; Wendy Seltzer; Ryan Sleevi
Subject: Re: [W3C Web Crypto WG] Rechartering discussion - Gemalto contribution

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<mailto:Olivier.Potonniee@gemalto.com>>
Date: Monday, February 2, 2015 at 1:22 AM
To: Bradley Hill <hillbrad@fb.com<mailto:hillbrad@fb.com>>, "PHoyer@hidglobal.com<mailto:PHoyer@hidglobal.com>" <PHoyer@hidglobal.com<mailto:PHoyer@hidglobal.com>>
Cc: Harry Halpin <hhalpin@w3.org<mailto:hhalpin@w3.org>>, Lu HongQian Karen <karen.lu@gemalto.com<mailto:karen.lu@gemalto.com>>, "public-web-security@w3.org<mailto:public-web-security@w3.org>" <public-web-security@w3.org<mailto:public-web-security@w3.org>>, "public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>" <public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>>, GALINDO Virginie <Virginie.Galindo@gemalto.com<mailto:Virginie.Galindo@gemalto.com>>, Wendy Seltzer <wseltzer@w3.org<mailto: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<mailto:PHoyer@hidglobal.com>
Cc: Harry Halpin; Lu HongQian Karen; public-web-security@w3.org<mailto:public-web-security@w3.org>; public-webcrypto@w3.org<mailto: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<mailto:PHoyer@hidglobal.com>" <PHoyer@hidglobal.com<mailto:PHoyer@hidglobal.com>>
Date: Friday, January 30, 2015 at 10:28 AM
To: Bradley Hill <hillbrad@fb.com<mailto:hillbrad@fb.com>>
Cc: Harry Halpin <hhalpin@w3.org<mailto:hhalpin@w3.org>>, Lu HongQian Karen <karen.lu@gemalto.com<mailto:karen.lu@gemalto.com>>, "public-web-security@w3.org<mailto:public-web-security@w3.org>" <public-web-security@w3.org<mailto:public-web-security@w3.org>>, "public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>" <public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>>, GALINDO Virginie <Virginie.Galindo@gemalto.com<mailto:Virginie.Galindo@gemalto.com>>, Wendy Seltzer <wseltzer@w3.org<mailto: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


[Inactive hide details for Brad Hill ---29/01/2015 22:52:23---I would like to see details of how this kind of API would or could]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<mailto:hillbrad@fb.com>>
To: Lu HongQian Karen <karen.lu@gemalto.com<mailto:karen.lu@gemalto.com>>, GALINDO Virginie <Virginie.Galindo@gemalto.com<mailto:Virginie.Galindo@gemalto.com>>, "public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>" <public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>>
Cc: "public-web-security@w3.org<mailto:public-web-security@w3.org>" <public-web-security@w3.org<mailto:public-web-security@w3.org>>, Wendy Seltzer <wseltzer@w3.org<mailto:wseltzer@w3.org>>, Harry Halpin <hhalpin@w3.org<mailto: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<mailto:karen.lu@gemalto.com>>
Date: Wednesday, January 28, 2015 at 10:01 AM
To: GALINDO Virginie <Virginie.Galindo@gemalto.com<mailto:Virginie.Galindo@gemalto.com>>, "public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>" <public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>>
Cc: "public-web-security@w3.org<mailto:public-web-security@w3.org>" <public-web-security@w3.org<mailto:public-web-security@w3.org>>, Wendy Seltzer <wseltzer@w3.org<mailto:wseltzer@w3.org>>, Harry Halpin <hhalpin@w3.org<mailto:hhalpin@w3.org>>
Subject: RE: [W3C Web Crypto WG] Rechartering discussion - Gemalto contribution
Resent-From: <public-web-security@w3.org<mailto: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<mailto:public-webcrypto@w3.org>
Cc: public-web-security@w3.org<mailto: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<https://urldefense.proofpoint.com/v1/url?u=https://www.w3.org/Security/wiki/IG/webcryptonext_draft_charter&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=HU3cThGizwgsko8%2BWBMXZg%3D%3D%0A&m=8aEYXK57JcrrYTY5UknOEonaRlwvLRKmxV6DQQk3Jrw%3D%0A&s=b7fae6689f1d5eb2b98ed9c174f7f4c4ed03d38ac34cbe75917d4024b2985920>
Feel free to add you ideas and suggestions on the wiki and/or expose your opinion and question on the public-webcrypto@w3.org<mailto:public-webcrypto@w3.org> or public-webcrypto-comment@w3.org<mailto:public-webcrypto-comment@w3.org> (for non W3C Web Crypto WG members).

Regards,
Virginie

[1] http://www.w3.org/2011/11/webcryptography-charter.html<https://urldefense.proofpoint.com/v1/url?u=http://www.w3.org/2011/11/webcryptography-charter.html&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=HU3cThGizwgsko8%2BWBMXZg%3D%3D%0A&m=8aEYXK57JcrrYTY5UknOEonaRlwvLRKmxV6DQQk3Jrw%3D%0A&s=40dc19af244e2cc2d487651001041f629287e51acb4e860c354027a7853437c3>

________________________________
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
________________________________
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