W3C Workshop on Identity in the Browser 24/25th May 2011, Mountain View (USA)

Workshop Report

The W3C organized an Identity in the Browser Workshop on 24-25 May in Mountain View (California, USA) to discuss how to modify the Web-browsing experience to effectively manage, access, and share online identity and related personal data in a secure, privacy-respecting manner.

Over the last ten years, for most end-users there has been no visible progress beyond cookie-managed usernames and passwords entered via HTML forms. Current password-based logins offers little value to the end-user, as they are forced to bear the onerous responsibility of remembering too many passwords or simply re-using low-security passwords. As passwords and cookies are easily compromised, both web-site operators and users then expose themselves to massive security breaches. Despite the large amount of valuable standardization work on identity, it is unclear how user agents such as Web browsers can interact with both identity-consuming applications and server-side federated identity services, and many current identity specifications either assume or underspecify secure authentication in the browser. The key missing component to enable trusted identity on the Web is likely then to be found in user-centric cross-browser standards for secure authentication and session management.

The goal of the workshop was to bring active practitioners together to explore what can be done to increase security and privacy relating to Web-based user identity and to explore harmonizing technologies within the ecosystem of groups working on identity on the Web. Over 80 representatives from various organizations attended the two-day workshop, including participants from the major browser developers such as Google, Microsoft, Apple, and Mozilla. Companies producing browser-like applications like Netflix also attended along with ones needing to support secure identity such as Paypal and Yahoo!. Present were also security expertise from the IETF and companies like RSA.

See also: minutes from May 24th and May 25th.

Executive Summary

The discussion was very diverse, ranging from high-level questions of scope and priorities to detailed analysis of technical proposals. A number of recurring points of emerging consensus were:

As the workshop has identified various areas where multi-stakeholder standardization would dramatically improve the Web for all, the W3C should consider chartering new work focused on identity on the Web. However, much of this work is still experimental and there need to be draft proposals to effectively scope this work. At least one Working Group should be launched, depending on the maturity of the proposals for future work, if there is sufficient support from both browser vendors and the larger Web community. This work should begin with the crytographic API, but perhaps include identity management using account managers and APIs for that functionality.

Work that is more research-oriented or less mature, such as security indicators and non-phishable credentials, should begin in the new lightweight Community Group process. Standardization in this area will also require the co-operation with work within other standards bodies like the IETF around possible areas like mutual authentication.

The general scope, requirements, and each concrete area of future work are detailed below, along with possible relevant draft proposals. This report concludes with a more detailed analysis of next steps for broad, multi-stakeholder standardization.

Requirements and Scope

For a clear articulation for why to begin in the browser, John Linn of RSA (slides) noted that browsers are a logical place to start given that users frequently interact with and have a natural trust in browsers. He also pointed out that any protocol must have value to site operators and regulators as well. However, browsers are no longer simple, stand-alone desktop applications. For example, Netflix produces browsers, even though there may be no visible chrome. Similarly, many smartphone applications are often just Web applications running in an execution environment that doesn't look like a traditional browser – and today, each of these mobile applications has their own sign-on. As stated by Jeff Hodges (Paypal), a browser should ultimately be broadly scoped as an execution environment for mobile code.

As put by Dirk Pranke of Google (slides), identity is a "wicked problem" where solutions are not either definitely good or definitely bad; instead one solution is merely considered better than another within a specific context. There is not an immediate test of what will happen when a particular technology to solve "identity" is deployed, and unlike the trial-and-error process in science, failures in this area are not celebrated by the marketplace.

Why should standardization of identity in the browser happen now, and why will it succeed where previous attempts have failed to reach massive deployment? RL 'Bob' Morgan of University of Washington and the InCommon Federation (slides) touched on what has been dubbed the "NASCAR problem": a user is presented with multiple logos or dropdown boxes of identity providers, from which they must select the appropriate provider. Paul Trevithick from Azigo (slides) then showed how InfoCards attempted to solve the problem by using a simple online "card" metaphor to represent a user's identity, various personae, and related personal data. Upon browser initiation, the user could then select the card that matched the site's requirements. According to Morgan, due to both user experience issues and being viewed as an overly complex Microsoft-only initiative, InfoCards did not receive widespread support.

Security and maintaining user privacy were also stated as a strong requirement. Brad Hill (slides), an independent participant at the workshop, presented on some common flaws of distributed authentication and identity systems. Among his concerns were drawing out unconstrained delegation (particularly OAuth2 "bearer token" leaks), unscoped or overscoped authorities (certificates), and other mechanisms that can be very dangerous and yet are still widely deployed. It should be considered that while users don't know how to ask about or express security requirements, they still have important expectations that cause technology to fail if ignored. Frederick Hirsch of Nokia and chair of the W3C DAP Working Group (slides) noted that seemingly simple requirements, such as "preventing correlation of identifiers at service providers" can have large implications on implementation and adoption. He also noted the importance of "Privacy by Design", incremental deployment and applicability of the FTC "Do No Track" requirements of universality, usability, persistent user choice, effectiveness, and applicability across services. John Tolbert of The Boeing Company (slides) expressed that any solutions bringing identity into the browser solution should be compatible with widely deployed standards like SAML used for enterprise identity.

In conclusion, the scoping of identity in the browser must consider a consistent role for the browser in terms of security and privacy for the entire identity ecosystem from end-users to enterprise identity, and any new standards should be required to work with existing username-password based sites while providing an upgrade path to higher security non-phishable credentials. There was feeling that if new standards were scoped minimally, had cross-browser support, and began with existing username-password websites rather than providing a whole new technology stack, there would be a better chance of success. In particular, there is increased pressure from drivers like social networking, smartphones, cybersecurity concerns, and government initiatives. However, ultimately the user-facing experience – especially given the low-value of current login procedures for users – would likely be the deciding factor.

Cryptographic APIs

Any new secure identity solution will have to build on top of strong and reliable cryptography. Currently there is no common API to access cryptography hard-coded into the browser, forcing developers to either roll their own or download freely available cryptographic libraries that may not be implemented correctly or safely. Furthermore, Javascript as a language lacks support for truly random large numbers. Given that high-quality cryptographic procedures do exist within most browsers, it should be possible to make a set of commonly-used cryptographic primitives available via standardized APIs. The most well-developed draft specification in this domain is the DomCrypt API from the Mozilla project, which facilitates asymmetric encryption key pair generation, encryption, and generation, as well as symmetric encryption, hashing, and signature verification.

The REST-GSS API, built upon commonly available IETF GSS-API implementations was put forward by Nico Williams from Cryptonector (slides) as the right level of abstraction for most Web application developers to access security in the browser. REST-GSS offered a common pluggable interface for authentication that was compatible with passwords, Kerberos, PKI, EAP/AAA, SAML, OpenID, and OAuth. It is also entirely above HTTP, as REST-GSS authenticates message exchanges via POST and and log-outs with DELETE.

There was some concern voiced at the workshop that using any proposed cryptographic primitives requires considerable skill and that releasing them to the public could possibly do more harm than good.In a personal capacity, Hannes Tschofenig of Nokia Siemens Network (slides) listed a number of items, including a common Javascript cryptographic API, that would help deployment and security of IETF standards like OAuth. Jeff Hodges of Paypal (slides) presented the need for a powerful cryptographic API on behalf of the IETF Security Area Directors, noting that currently it is sub-optimal to rely on TLS for browser interactions outside the traditional client-server model. Mike Jones of Microsoft (slides) presented the emerging number of JSON serializations being developed at the IETF – such as JSON Web Token, JSON Web Signature, JSON Web Encryption, JSON Web Key, and Simple Web Discovery – that could be an appropriate set of building blocks for enabling identity in the browser via their use in a common Javascript API.

The vast majority of the attendees supported a common API being developed as soon as possible and all browser vendors expressed informal support. It seemed such work should be done at the W3C in consultation with the IETF, and discussion of such work has already begun in the HTML and WebApps Working Groups.

Standardized Account Managers

Almost every browser has some sort of an account manager designed to handle user identity data. Unfortunately, today it is difficult to synchronize identities between between different browsers or between Cloud-based services. There is also little integration of the browser-based account manager to to the underlying account management capabilities of the device platform. Furthermore, secure authentication of the user was outside the scope of many existing identity-related standards (SAML, OpenID, OAuth), so a secure solution in the browser would benefit existing federated identity schemes. Dirk Pranke of Google (slides) presented on how very few people used only a single browser on a single device, so that interoperable and secure synchronization of identities across browsers on different devices should be a clear objective. Craig Wittenberg of Microsoft (slides) presented that contrary to the three-way interaction model of server-side federated identity (featuring interactions between an identity provider, relying party, and user), a two-way interaction model between the user's browser acts and applications which would provide a more secure solution and allows the account manager to be eventually upgraded to using non-phishable credentials. David Singer and Ted O'Connor from Apple (slides) supported better managing of session state and identity from the browser. Esteban Manchado Velazquez of Opera (slides) also strongly supported cross-browser standards for account manager synchronization. There was remarkable consensus from the browser vendors on supporting cryptographic APIs and account manager standardization. Currently, there are no agreed upon account management standards in the browser, but developing draft proposals based on current implementations should be possible fairly quickly.

Most browser-based account managers also facilitate Web interactions by automatically pre-filling HTML form fields and storing usernames-password combinations. While current heuristics assist users in filling out forms, standardized types for session management and identity in HTML forms would help automated authentication via forms. While simple types for email and passwords exist already in HTML Forms, they are not bound explicitly to an identity session which should contain more explicit "logout" and "remember me" functionality. Tantek Celik (slides) presented a draft for feedback, and similar ideas have been supported by Adrian Bateman of Microsoft. All of the browser developers present at the workshop agreed that their current heuristics for form management could be improved by some simple standardization. Another option could be standardized authentication triggers (with a response code like HTTP 401 for automated user-agents), and "trusted pop-ups" for higher security logins.

Dirk Balfanz (Google), Sam Hartmann (Painless Security), and Mark Watson (Netflix) - Photo credit: Karen Myers

Dirk Balfanz (Google), Sam Hartmann (Painless Security), and Mark Watson (Netflix) — Photo credit: Karen Myers

Philip Hallam-Baker of The Comodo Group (slides) pointed out that in order to make the account manager truly portable it has to work on all existing web-sites and legacy browsers, so any standardized identity solution must work with services in the cloud. The Nigori Protocol to store encrypted information in different "parts" of the cloud was brought up as relevant. Sam Hartman of Painless Security (slides) stated that identity in the browser requires the platform to provide features missing from Web applications, such as operating-system level identities, cached credentials, security policy, and channel bindings, and suggested that this work liaise closely with Project Moonshot (IETF AFAB Working Group), which is working on non-Web identity federation in the platform.

Standards also have to be developed to interface beyond the browser. Dirk Balfanz of Google (slides) presented on how the ability of a browser to automatically sign-in and connect with account identities in the operating system is crucial, especially for mobile devices like tablets. However, there needs to be a standardized API for Web applications to ask the platform-based account manager for authorization tokens and for the platform-based account manager to return those tokens. Furthermore, there should be a standardized way to get credentials from servers into the account manager in exchange for tokens, and ideally for a new HTTP header with an attached URL to automatically log-in users.

The vast majority of attendees, including several interested vendors, supported the creation of a common set of standards to deal with account management in the browser, with all browser vendors supporting the addition of better identity mechanisms in forms. This work needs to be further developed into a series of draft proposals as soon as possible, and thus may be suited to a Community Group, which would eventually transform into a W3C Working Group if the Community Group work gains enough support with the browser vendors and the wider community.

Private Browsing and Multiple Personae

A common theme was that some aspects of identity management in a browser could be contradictory to current proposals for “do-not-track” and “anonymity protection”. Mary Hodder of the Personal Data Consortium (slides) argued that the browser should provide tools to deal with data disclosure around identity, in particular as anonymous and multiple (possibly pseudonymous) personae were exceptionally important to women. Aaron Brauer-Rieke of the Center for Democracy and Technology reminded the audience not to save the privacy discussion for later (pointing to OECD/FTC privacy principles) and that browsers were a good point for policy enforcement around privacy.

Mike Perry of the Tor Project (slides) described the giant disconnect between how users perceive their identity in the browser and the reality of current tracking on the Web. In particular, he suggested that users need to understand that simple approaches are insufficient to describe how their activity on one domain can be "linked" cross-domain by other domain. A possible solution could be a dual-origin policy that checks tokens for both compatibility of the origin domain and the third-party domain. Current private browsing modes do not detect against third-party linkability and different browsers have different flaws as regards private browsing as shown by researchers ("Private Browsing", PDF). Second, a user's identity could be thought of as the state of all their relationships, known or unknown, with other sites. Therefore, anonymous browsing could just be considered a special case of identity in the browser where users could click a button to get a clean slate for a new identity.

Attendees at workshop - Photo credit: Karen Myers

Attendees at workshop — Photo credit: Karen Myers

The presentation of Wendell Baker of Yahoo! (slides) argued that improved identity management in Web browsers can help advertising mechanisms which are currently disconnected from "user-centric identities", as the ability of advertising systems to interact with more detailed identities can more effectively tie advertising mechanisms to particular users and reduce the computational overhead of current Web-tracking systems. Thus better identity in the browser is actually not a threat to advertising, but a win-win for both privacy advocates and Web advertising, as it allows users to disclose information in a way that can provide more accurate information to advertisers but also hide their identity when necessary.

No clear agreement existed on moving forward in this area. The majority of the browser vendors and a few participants thought that developing private browsing harmonization and standards would be a useful role for the W3C. Therefore, any work on standardized account managers and APIs need to take into account the cases of multiple personae and anonymous "private" browsing. More discussion in the community groups around account managers needs to happen to determine what exact parts of the state of the browser (such as cookies, client certificates, and so on) serve as the user-centric identity in the browser.

Identity API

Currently there is no uniform API for Web application developers to access identity data, which prevents highly personalized cross-platform Web applications from developing. Rather than forcing users to quit the browser to end any current identity-based sessions, identity-based session management can by browser controls, and this information should be accessible to applications. Such a proposed API for identity management could also access identity information possessed on the server-side as well. Furthermore, such an identity API allows the transfer of signed (and therefore trusted) attributes from the browser or other identity service to service providers, solving issues around data portability. It could also lead to new types of browsing experiences. Currently, web-browsing is a "lonely" experience and the current social networking sites provide the feeling of "being around other people". Trusted attribute sharing between service providers and their users could give users the ability to see what their other friends are doing across the entire Web without being limited to interactions on select social networking sites.

What is the right primary identifier for any user? Michael Hanson and Dan Mills from Mozilla (slides) noted that email addresses are the right identifier, since e-mail addresses are federated by design, users already understand them, and they offer a way to communicate to the user easily. The Verified Email API and Protocol by Mozilla using verified e-mail addresses to determine user session state and allows the browser to directly share verified (signed) attributes with relying parties. Brian McGinnis of Janrain (slides) showcased their Backplane specification, which provided similar functionality for "widgets"; in particular, sites composed of widgets coming from different servers that listen (and could not post) to a "backplane" could get identity information tied to a browser. Tyler Close of Google demonstrated how the Web Introducer API could solve both some of the security problems associated with the exchange of identity information (specifically by using iframes and pop-ups for completion of actions), thereby preventing clickjacking and getting reliable confirmation of intent.

The technique of trusted attribute exchange provided directly from the browser could enable "Device ID", i.e. for attributes about the device the user is using to be transmitted in a secure and reliable manner. Mark Watson and Wesley Miaw from Netfix (slides) noted that many use-cases ranging from medical records to digital content rely on guarantees of device behavior, and offered to draft an API. Jack Matheson of Intel (slides) demonstrated that trusted hardware could be a component of the flow, but that hardware manufacturers are wary of introducing "legacy" or "premature" solutions. There were other variations upon trusted attribute exchange, such as David Chadwick's from the University of Kent (slides) work on letting a service provider sites transfer their security policy as a standard MIME type. The option of using zero-knowledge proofs (e.g. proving membership in a group without revealing one's identity) to prevent collusion between identity providers and relying parties was of interest.

Esteban Manchado Velazquez (Opera), David Singer (Apple), Mike Hanson (Mozilla), Harry Halpin (W3C), Dirk Pranke (Google), and Craig Wittenberg (Microsoft) - Photo credit: Karen Myers

Esteban Manchado Velazquez (Opera), David Singer (Apple), Mike Hanson (Mozilla), Harry Halpin (W3C), Dirk Pranke (Google), and Craig Wittenberg (Microsoft) — Photo credit: Karen Myers

Overall, there was some desire from the attendees to standardize some kind of "identity API", but only a few browser vendors seemed interested in implementing it. Therefore, it seems like the best route forward would be to form a W3C Community Group to define use cases and requirements and begin to specify an identity API that builds upon a common cryptographic API, and then iterate the design until agreement converges between the wider identity community, Web application developers, and browser vendors. Once this converges, it would appropriate to charter this work in the standardized identity manager working group or in a new working group that would liaise with them.

Non-Phishable Credentials and Mutual Authentication

Jeff Hodges of Paypal pointed out that "phishing will be fun and profitable" until the re-usable shared-secrets used by username-password based systems are replaced by non-phishable credentials such as asymmetric keys. Better credentials should use techniques such as channel-binding to increase security, and go beyond even automatically generated high-entropy passwords. This view was reinforced by Dan Schutzer from FSTC (slides), who noted that for financial and other high-risk and high-value transactions, the entire flow between user, device, and the service had to be secured both technically and with legally enforceable contracts. Thomas J. Smedinghoff of Wildman Harrold , the co-Chair of ABA Federated Identity Management Legal Task Force (slides), said that any legal rules as regards identity on the Web must either be drawn from existing law statues or be specified in new contracts. Therefore, new contracts should be drawn for liability for identity in the browser standards. New government initiatives, such as the National Strategy for Trusted Identity in Cyberspace (NSTIC), are already expecting standards bodies to help push industry to go beyond password-based solutions as well. Don Thibeau of the OpenID Foundation (slides) presented on how increasing security in browser-based authentication is complementary to ongoing work on in other groups like the Open Identity Exchange on trust frameworks. Francisco Corella from Pomcor (slides) argued that if NSTIC only used current OAuth-based architectures it would lead to increased user-tracking and phishing attacks, so that a decentralized alternative was needed.


One example of non-phishable credentials is mutual authentication, where both the server and client mutually authenticate each other. Yutaka Oiwa from AIST Japan (slides) presented a proposal for a Mutual Authentication Protocol for HTTP, where user authentication only succeeds if both the site and the user independently verify in a secure manner. This could be a correct password provided by the user in some secure part of the chrome, but historically the general weakness of this schema is the reliance on a "secure" login, which can only be done in the chrome. Therefore, one possible solution is some kind of "trusted" pop-up, but there is already a lack of support for traditional HTTP Auth "pop-up" mechanisms. Historically many sites are unwilling to give up their "log-in" forms, but there is increasing evidence sites might give up their customized log-in procedures if it increased traffic to their site. Another proposed solution would be to use credentials stored in the operating system when the user "logs-in" to the operating system, allowing access to various non-browser credential vaults.

Smartphones are now many users' primary device, rather than a secondary case. Identity management in the browser could also make logging into sites, particularly on smartphones, transparent. The goal of identity in the browser should be a single-sign on without the user having to remember any user-name or password for any site they use. For example, not only should the user automatically log-in to social networking and location-based services when starting their phone, but even high-value transactions such as clicking a "purchase" button should work transparently, rather than cause a possibly insecure chain of redirections to a micropayment service.

Due to the ubiquity of smartphones, instead of emulating "1960s technology" like passwords with smartphones, new work should take advantage of video and voice for authentication. Siddharth Bajaj from Symantec (slides) gave a proposal to "hide the complexity under the hood" of techniques such as two-factor authentication over everyday use of mobile devices, such as remembering the PIN number for our devices. Another problem is how to authenticate to begin with, as covered in the overview by Jonas Hogsberg of Ericsson (slides) on how mobile standards like the Generic Authentication Architecture/Generic Bootstrapping Architecture (GAA/GBA) could form the basis for boot-strapping secure authentication for mobile devices. Other solutions point to leveraging social networks for boot-strapping authentication. Any secure authentication mechanism bound to any non-phishable credential on the device should also have a clear revocation mechanism when the device is missing.

Certificates

Insofar as TLS is widely deployed and accepted as a way to secure server authentication, any future identity standardization is endangered by the current critical situation around certificates. The current issue with certificates is that any certificate authority can issue a certificate for any web-site, so once a certificate authority is compromised malicious agents can create "fake" certificates for websites that are very hard to detect. In many of the breaches the announcement of certificate revocation have been public soon afterwards, but browsers have varied in how quickly they process these revocations. What seems to be lacking is a combination of the standards around participation of the browser in the larger certificate-authorization process, client certificates that have some authentication mechanism, and a certificate authority system that presents itself as a single attack surface. As accepted server and client certificates are part of each user's browser state, they are definitely part of identity on the Web, they are crucial to solving the identity problem of the Web.

According to Steve Schultz and Thomas Lowenthal of Princeton (slides), a scoped delegated trust model would be better, just as the current domain name system is scoped. Henry Story (slides) presented the WebID protocol, in which a URI in the client certificate allows for a "Web of Trust", given by connections on a profile URI, to be used for authority instead of a certificate authority. There were concerns that such a user-supplied call-out by servers creates a larger attack surface (with an example being denial-of-service attacks on profile URIs) and incurs a high performance cost. In any case, the work of the IETF DANE WG around DNSSEC to attach certificates to the DNS for "out of band" could end up being vital.

In conclusion, the security issues around certificates need to be resolved, but is likely predicated on larger changes to certificate authorities, a clearer update mechanisms around trusted certificates in the browser, possible changes in the use of client certificates, and interaction with other bodies such as the IETF and the CA/Browser Forum. No agreement came out of the workshop. Thus, the recommendation of this report is to keep awareness of certificates as part of any identity work, but also to host a separate workshop on the robustness of the Web together the relevant stake-holders of the wider certificate system.

Security Indicators

There are currently significant differences between browsers on how they display security indicators to users. They often leverage various colors and icons within the URL bar that relate to the “trustworthiness” of the digital certificates used when setting up a secure connection. Unfortunately, none of them appear compatible, raising questions about their effectiveness. There is also increasing evidence that it is very difficult to train users to recognize security indicators, and there has already been W3C work in the W3C Web Security Context Working Group in this area. While security indicators are currently out of scope for standardization, there was interest from the attendees and browser vendors in building a common place to share research on security indicators as a first step. This could happen in a W3C Community Group.

Next Steps

At the end of the workshop, there was an extended discussion, followed by informal polling, to determine the next actionable steps. As regards standardization, both IETF and W3C process were explained in detail. In particular, it appears that the most promising next steps are as follows:

To participate in the discussion on any of these topics, join us on [public-identity@w3.org] by e-mailing [public-identity-request@w3.org] with "subscribe" in the title. The W3C is looking forward to hearing from you, and wants your help in making identity integrated into the Open Web Platform.

Whiteboard from final session - Photo credit: Thomas Roessler

Whiteboard from final session — Photo credit: Thomas Roessler