View source for IdentityBrowser

=Identity in the Browser Workshop Final Report (Draft)=

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.



==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: 

* Standardization across browsers is a key missing component of identity on the Web, and one place to begin standardization work is with the account management systems within each browser.

* A "Web browser" should be broadly construed as a kind of environment for executing mobile code, and so should include devices traditionally not seen as browsers.

* Future Web standards should think beyond the browser, including the entire flow between applications, the browser, servers, the operating system, and device capabilities.

* The Web should become a more secure  platform, enabling identity to be built on top of reliable cryptography in the browser, aiming to support  non-phishable credentials.

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. To get to that point, the W3C should launch a new open Community Group process to begin work on these draft proposals, and launch one or more Working Groups when these draft proposals are ready if there is sufficient support from both browser vendors and the larger Web community. Standardization in this area will also require the co-operation with work within other standards bodies like the IETF. 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 look at [[#Next_Steps|next steps]] for broad, multi-stakeholder standardization.

==Requirements and Scope==

For a clear articulation for why to begin in the browser, John Linn (RSA) 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 (Google), 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 (University of Washington and the InCommon Federation) 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 (Azigo) 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.   However, 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 (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 (Nokia) of the W3C DAP Working Group 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 (The Boeing Company) 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 [https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest 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 [https://tools.ietf.org/html/draft-williams-rest-gss-00 REST-GSS API], built upon commonly available IETF GSS-API implementations  was put forward by Nico Williams (Cryptonector) 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 (Nokia Siemens/IAB) noted a common Javascript cryptographic API would help deployment and security of IETF standards like OAuth. Jeff Hodges (Paypal) 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 (Microsoft) 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 Identity 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 (Google) 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 (Microsoft) 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 (Apple) supported better managing of session state and identity from the browser.  Esteban Manchado Velazquez (Opera) 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 presented a [https://wiki.mozilla.org/Identity-inputs draft] for feedback, and [http://www.w3.org/wiki/HTML/next#Enhancing_Authentication_Forms similar ideas] have been supported by Adrian Bateman (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.

Philip Hallam-Baker (The Comodo Group) 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 [http://www.links.org/files/nigori-protocol.html Nigori Protocol] to store encrypted information in different "parts" of the cloud was brought up as relevant. Sam Hartman (Painless Security) 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 (Google) 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 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 about half of the browser 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 (Personal Data Consortium) 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 (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 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 [http://crypto.stanford.edu/~dabo/pubs/papers/privatebrowsing.pdf ("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. 

The presentation of Wendell Baker (Yahoo!) 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 (Mozilla) 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 [https://wiki.mozilla.org/Identity/Verified_Email_Protocol/Latest Verified Email API] and [https://wiki.mozilla.org/Identity/Verified_Email_Protocol/Latest-Session 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 (Janrain) showcased their [https://sites.google.com/site/backplanespec/ 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 (Google) showed how the [http://web-send.org/introducer/ 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 (Netfix) 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 (Intel) 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 (University of Kent) 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.

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 (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 (FSTC), 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 (Wildman Harrold), the co-Chair of ABA Federated Identity Management Legal Task Force, 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 (OpenID Foundation) 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. 


One example of non-phishable credentials is mutual authentication, where both the server and client mutually authenticate each other. Yutaka Oiwa (AIST Japan) presented a proposal for a [https://www.rcis.aist.go.jp/special/MutualAuth/files/spec/draft-oiwa-http-mutualauth-08.html 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 (Symantec) 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 (Ericsson) 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==

The current certificate system on the Web is broken, and this represents a large security threat to the Web today. 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 Thomas Scheutze (Princeton), a scoped delegated trust model would be better, just as the current domain name system is scoped. Henry Story 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 greater crisis over certificates needs to be solved, but is 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 jointly with ISOC bringing 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 [http://www.w3.org/2006/WSC/ 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 voting, 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:

* There is already close to full consensus on doing work on a '''Cryptographic API''', and work in this area has already been discussed in the W3C WebApps WG and HTML WG, as well as the IETF Web Security area. Therefore, this work should be encouraged to continue in a single forum with a well-defined schedule in the W3C, with tight liaisons to the Web Security area in the IETF.
 
* A majority of browser vendors would see benefits in '''standardizing the browser account manager as an identity manager''' as long as it offered standardized communication with the platform, and there was also some interest in seeing this information exposed via an API for identity in the browser. However, the draft proposals are still in need of further development, with anonymous browsing and multiple personae in a single browser being a requirement. Therefore, an '''"Identity in the Browser" Community Group''' should be formed to mature and gain support for various proposals, which could then quickly form the basis of one or more new W3C Working Groups.

* Webapps, browser extensions, and even platform applications would benefit from secure, user-authorized access to identity data in the account manager in a uniform way; thus we may standardize an '''identity API for data exchange and synchronization''', perhaps using existing '''identity data formats''', in a working group after building consensus in a community group. 

* Work on '''high security and non-phishable credentials for browser-based authentication''' should commence as soon as possible as well, although the work is considerably larger and more research-oriented, and thus may merit a separate '''Community Group''' for standardization of account managers across browsers. This work should happen in close co-ordination with the IETF, in particular if the IETF decides to restart the IETF HTTP Auth Working Group. The W3C should engage with various government initiatives in this area, such as NSTIC.

* A forum, such as a '''Community Group''', should be started to share results on '''security indicators''' and other '''user-experience research on browsers'''.

* Although widely mentioned, no clear steps forward emerged on the increasingly wide problem of certificate management. One path forward could be that the W3C should engage the wider Web community, ranging from the CA/Browser Forum to ISOC, to help '''develop new governance''' and possibly new technological structures for certificates, with a focus on the '''interface between certificate authorities and the browser'''. This could be scoped for another '''workshop''' in order to bring the appropriate parties together.

To participate in the discussion on any of these topics, join us on [[mailto:public-identity@w3.org public-identity@w3.org]] by e-mailing [[mailto:public-identity-request@w3.org 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.

==Acknowledgments:==

The W3C thanks J. Trent Adams, Internet Society Outreach Specialist on Trust & Identity, for co-chairing the workshop with me. Thanks also to the Mozilla Foundation for providing host facilities. Special thanks also go to Yahoo!, Paypal, and RSA (The Security Division of EMC) for sponsoring the workshop.