A Guide to Supporting Information Cards within Web Applications and Browsers as of Windows CardSpace v1.0
Michael B. Jones
© 2006 . All rights reserved.Abstract
The Identity Metasystem allows users to manage their digital identities from various identity providers and employ them in different contexts where they are accepted to access online services. In the Identity Metasystem, identities are represented to users as "Information Cards" (a.k.a. "InfoCards"). One important class of applications where Information Card-based authentication can be used is applications hosted on web sites and accessed through web browsers.
This paper documents the web interfaces utilized by browsers and web applications that support the Identity Metasystem. The information in this document is not specific to any one browser or platform.
This document supplements the information provided in two other Windows CardSpace references: the CardSpace Guide [CardSpace-Guide], which provides a non-normative description of the overall Information Card model, and the CardSpace Technical Reference [CardSpace-Ref], which provides the normative schema definitions and behaviors referenced by the CardSpace Guide.
This draft corresponds to the Information Card support that Microsoft has implemented in Windows CardSpace v1.0, which is part of Microsoft .NET Framework 3.0 [.NET3.0], and Internet Explorer 7. Other implementations following these specifications should be able to interoperate with the Microsoft implementation.
Table of Contents
2. Design Goals
3. Browser Behavior with Information Cards
3.1 Basic Protocol Flow when using an Information Card at a Web Site
3.2 Protocol Flow with Relying Party STS
3.3 User Perspective and Examples
3.4 Browser Perspective
3.5 Web Site Perspective
4. Invoking an Identity Selector from a Web Page
4.1 Syntax Alternatives: OBJECT and XHTML tags
4.1.1 OBJECT Syntax Examples
4.1.2 XHTML Syntax Example
4.2 Identity Selector Invocation Parameters
4.2.1 issuer (optional)
4.2.2 issuerPolicy (optional)
4.2.3 tokenType (optional)
4.2.4 requiredClaims (optional)
4.2.5 optionalClaims (optional)
4.2.6 privacyUrl (optional)
4.2.7 privacyVersion (optional)
4.3 Data Types for use with Scripting
4.4 Detecting and Utilizing an Information Card-enabled Browser
Appendix A: HTTPS POST Sample Contents
Appendix B: Detecting Information Card Browser Support by Internet Explorer
The Identity Metasystem allows users to manage their digital identities, whether they are self-issued or issued by third-party identity providers, and employ them in contexts where they are accepted to access online services. In the Identity Metasystem, identities are represented to users as "Information Cards" (a.k.a. "InfoCards"). One important class of applications where Information Card-based authentication can be used is applications hosted on web sites and accessed through web browsers.
This paper documents the web interfaces utilized by browsers and web applications supporting the Identity Metasystem. The information in this document applies to all platforms, browsers, and Identity Selectors. These mechanisms are documented here to enable web sites and browsers on all platforms to implement and use these mechanisms so they can utilize Information Cards for authentication.
Two other documents should be considered prerequisites for understanding this document: the CardSpace Guide [CardSpace-Guide], which provides a non-normative description of the overall CardSpace model, and the CardSpace Technical Reference [CardSpace-Ref], which provides the normative schema definitions and behaviors referenced by the CardSpace Guide.
Microsoft's Windows CardSpace v1.0 software, which is part of Microsoft .NET Framework 3.0 [.NET3.0], implements an Identity Selector that allows users to select Information Cards to use for sites and applications that accept them. Internet Explorer 7 uses Windows CardSpace, if installed. The information in this document corresponds to the features supported in CardSpace v1.0 and Internet Explorer 7.
Numerous alternatives were considered for ways of bringing Information Card-based authentication to web sites. The design goals that led to the eventual decisions described in this document are:
- Browser independent: A goal was to ensure that the protocols developed for Information Card-based authentication to web sites could be implemented by a broad range of web browsers on the platforms of their choice.
- Web server independent: A closely-related goal was to ensure that the protocols developed for Information Card-based authentication to web sites could be used by web-based applications running on a broad range of web servers on the platforms of their choice.
- Minimal impact on web sites: A goal was to facilitate the adoption of Information Card-based authentication for existing web sites by requiring as few changes to them as possible.
- Seamless browser integration: A goal was that Information Card-based authentication should be viewed as a seamless security feature that is a natural extension of the browser(s) being used.
- Seamless user experience: A goal was that the Information Card web integration design should permit graceful fall-back when a browser or platform does not have Information Card support available.
- Work with browser high security settings: A goal was that the mechanisms chosen should remain enabled even when browser security settings are set to "high".
The choices described in this document are an attempt to balance among all these sometimes-competing goals and to achieve all of them as well as possible, given the realities of how the web is used today.
This section explains the steps that a web browser takes when using an Information Card to authenticate to a web site. Two cases are described. The basic case is where the web site provides all the relying party functionality via HTML extensions transported over HTTPS. The second case is where the relying party employs a relying party Security Token Server (STS), which it references via HTML extensions transported over HTTPS.
This section explains the protocol flow when using an Information Card to authenticate at a web site where no relying party STS is employed.
Figure 1. Basic protocol flow when using an Information Card to authenticate at a Web site
Figure 1 gives an example of the basic protocol flow when an Information Card is used to authenticate at a web site that employs no relying party STS. Steps 1, 2, and 5 are essentially the same as a typical forms-based login today: (1) The user navigates to a protected page that requires authentication. (2) The site redirects the browser to a login page, which presents a web form. (5) The browser posts the web form that includes the login credentials supplied by the user back to the login page. The site then validates the contents of the form including the user credentials, typically writes a client-side browser cookie to the client for the protected page domain, and redirects the browser back to the protected page.
The key difference between this scenario and today's site login scenarios is that the login page returned to the browser in step (2) contains an HTML tag that allows the user to choose to use an Information Card to authenticate to the site. When the user selects this tag, the browser invokes an Identity Selector, which implements the Information Card user experience and protocols, and triggers steps (3) through (5).
In Step (3), the browser Information Card support code invokes the Identity Selector, passing it parameter values supplied by the Information Card HTML tag supplied by the site in Step (2). The user then uses the Identity Selector to choose an Information Card, which represents a digital identity that can be used to authenticate at that site. Step (4) uses the standard Identity Metasystem protocols [CardSpace-Guide] to retrieve a security token that represents the digital identity selected by the user from the STS at the identity provider for that identity.
In Step (5), the browser posts the token obtained back to the web site using a HTTPS/POST. The web site validates the token, completing the user's Information Card-based authentication to the web site. Following authentication, the web site typically then writes a client-side browser cookie and redirects the browser back to the protected page.
It is worth noting that this cookie is likely to be exactly the same cookie as the site would have written back had the user authenticated via other means, such as a forms-based login using username/password. This is one of the ways that the goal of "minimal impact on web sites" is achieved. Other than its authentication subsystem, the bulk of a web site's code can remain completely unaware that Information Card-based authentication is even utilized. It just uses the same kinds of cookies as always.
In the previous scenario, the web site communicated with the client Identity Selector using only the HTML extensions enabling Information Card use, transported over the normal browser HTTPS channel. In this scenario, the web site also employs a relying party STS to do part of the work of authenticating the user, passing the result of that authentication on to the login page via HTTPS POST.
There are several reasons that a site might factor its solution this way. One is that the same relying party STS can be used to do the authentication work for both browser-based applications and smart client applications that are using Web services. Second, it allows the bulk of the authentication work to be done on servers dedicated to this purpose, rather than on the web site front-end servers. Finally, this means that the front-end servers can accept site-specific tokens, rather than the potentially more general or more complicated authentication tokens issued by the identity providers.
Figure 2. Protocol flow when using an Information Card to authenticate
at a Web site, where the Web site employs a relying party STS
This scenario is similar to the previous one, with the addition of steps (3) and (6). The differences start with the Information Card information supplied to the browser by the web site in Step (2). In the previous scenario, the site encoded its WS-SecurityPolicy information using Information Card HTML extensions and supplied them to the Information Card-extended browser directly. In this scenario, the site uses different Information Card HTML extensions in the Step (2) reply to specify which relying party STS should be contacted to obtain the WS-SecurityPolicy information.
In Step (3), the Identity Selector contacts the relying party STS specified by the web site and obtains its WS-SecurityPolicy information via WS-MetadataExchange. In Step (4) the Identity Selector user interface is shown and the user selects an Information Card, which represents a digital identity to use at the site. In Step (5), the identity provider is contacted to obtain a security token for the selected digital identity. In Step (6), the security token is sent to the web site's relying party STS to authenticate the user and a site-specific authentication token is returned to the Identity Selector. Finally, in Step (7), the browser posts the token obtained in Step (6) back to the web site using HTTPS/POST. The web site validates the token, completing the user's Information Card-based authentication to the web site. Following authentication, the web site typically then writes a client-side browser cookie and redirects the browser back to the protected page.
The Information Card user experience at web sites is intended to be intuitive and natural enough that users' perspective on it will simply be "That's how you log in". Today, web sites that require authentication typically ask the user to supply a username and password at login time. With Information Cards, they instead ask users to choose an Information Card. Some sites will choose to accept only Information Cards whereas others will give users the choice of Information Cards or other forms of authentication.
A site that accepts Information Cards typically has a login screen that contains button with a label such as "Sign in with an Information Card" or "Login in using an Information Card". Upon clicking this button, the user is presented with a choice of his Information Cards that are accepted at the site, and is asked to choose one. Once a card is selected and submitted to the site, the user is logged in and continues using the site, just as they would after submitting a username and password to a site.
Sites that accept both Information Cards and other forms of authentication present users with both an Information Card login choice and whatever other choices the site supports. For instance, a site login screen might display both "Sign in with your username and password" and "Sign in with an Information Card" buttons.
Very little additional support is required from today's web browsers to also support Information Card-based authentication. The main addition is that they must recognize special HTML and/or XHTML tags for invoking the Identity Selector, pass encoded parameters on to the Identity Selector on the platform, and POST back the token resulting from the user's choice of a digital identity for the authentication.
Web sites that employ Information Card-based authentication must support two new pieces of functionality: adding HTML or XHTML tags to their login page to request an Information Card-based login and code to log the user into the site using the POSTed credentials. In response to the Information Card-based login, the web site typically writes the same client-side browser cookie that it would have if the login had occurred via username/password authentication or other mechanisms, and issue the same browser redirects. Thus, other than the code directly involved with user authentication, the bulk of a web site can remain unchanged and oblivious to the site's acceptance of Information Cards as a means of authentication.
HTML extensions are used to signal to the browser when to invoke the Identity Selector. However, not all HTML extensions are supported by all browsers, and some commonly supported HTML extensions are disabled in browser high security configurations. For example, while the OBJECT tag is widely supported, it is also disabled by high security settings on some browsers, including Internet Explorer.
An alternative is to use an XHTML syntax that is not disabled by changing browser security settings. However, not all browsers provide full support for XHTML.
To address this situation, two HTML extension formats are specified. Browsers may support one or both of the extension formats.
An example of the OBJECT syntax is as follows:
<title>Welcome to Fabrikam</title>
<form name="ctl00" id="ctl00" method="post"
<img src='infocard.bmp' onClick='ctl00.submit()'/>
<input type="submit" name="InfoCardSignin" value="Log in"
<OBJECT type="application/x-informationCard" name="xmlToken">
<PARAM Name="tokenType" Value="urn:oasis:names:tc:SAML:1.0:assertion">
<PARAM Name="issuer" Value=
<PARAM Name="requiredClaims" Value=
This is an example of a page that requests that the user log in using an Information Card. The key portion of this page is the OBJECT of type "application/x-informationCard". Once a card is selected by the user, the resulting security token is included in the resulting POST as the xmlToken value of the form. Appendix A shows a sample POST resulting from using a login page similar to the preceding one. If the user cancels the authentication request, the resulting POST contains an empty xmlToken value.
Parameters of the Information Card OBJECT are used to encode the required WS-SecurityPolicy information in HTML. In this example, the relying party is requesting a SAML 1.0 token from a self-issued identity provider, supplying the required claims "
givenname", and "
surname". This example uses the basic protocol described in Section 3.1 (without employing a relying party STS).
A second example of the OBJECT syntax is as follows:
<form name="ctl01" method="post"
<img src='infocard.bmp' onClick='ctl01.submit()'/>
<input type="submit" name="InfoCardSignin" value="Log in"
<OBJECT type="application/x-informationCard" name="xmlToken"
oCard.issuer = "http://www.fabrikam.com/sts";
oCard.issuerPolicy = "https://www.fabrikam.com/sts/mex";
oCard.tokenType = "urn:fabricam:custom-token-type";
This example uses the enhanced protocol described in Section 3.2, which employs a relying party STS. Note that in this case, the "issuer" points to a relying party STS. The "issuerPolicy" points to an endpoint where the security policy of the STS (expressed via WS-SecurityPolicy) is to be obtained using WS-MetadataExchange. Also, note that the "tokenType" parameter requests a custom token type defined by the site for its own purposes. The "tokenType" parameter could have been omitted as well, provided that the web site is capable of understanding all token types issued by the specified STS or if the STS has prior knowledge about the token type to issue for the web site.
The object parameters can be set in normal script code. This is equivalent to setting them using the "PARAM" declarations in the previous example.
An example of the XHTML syntax is as follows:
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:ic>
<title>Welcome to Fabrikam</title>
<form name="ctl00" id="ctl00" method="post"
<input type="submit" name="InfoCardSignin" value="Log in"
The parameters to the OBJECT and XHTML Information Card objects are used to encode information in HTML that is otherwise supplied as WS-SecurityPolicy information via WS-MetadataExchange when an Identity Selector is used in a Web services context.
This parameter specifies the URL of the STS from which to obtain a token. If omitted, no specific STS is requested. The special value "
http://schemas.xmlsoap.org/ws/2005/05/identity/issuer/self" specifies that the token should come from a self-issued identity provider.
This parameter specifies the URL of an endpoint from which the STS's WS-SecurityPolicy can be retrieved using WS-MetadataExchange. If omitted, the value "<issuer>
/mex" is used. This endpoint must use HTTPS.
This parameter specifies the type of the token to be requested from the STS as a URI. This parameter can be omitted if the STS and the web site front-end have a mutual understanding about what token type will be provided or if the web site is willing to accept any token type.
This parameter specifies the types of claims that must be supplied by the identity. If omitted, there are no required claims. The value of
requiredClaims is a space-separated list of URIs, each specifying a required claim type.
This parameter specifies the types of optional claims that may be supplied by the identity. If omitted, there are no optional claims. The value of
optionalClaims is a space-separated list of URIs, each specifying a claim type that can be optionally submitted.
The object used in the Information Card HTML extensions has the following type signature, allowing it to be used by normal scripting code:
string issuer; // URI specifying token issuer
string issuerPolicy; // MetadataExchange endpoint of issuer
string tokenType; // URI specifiying type of token to be requested
string  requiredClaims; // Array of required claims
string  optionalClaims; // Array of optional claims
boolean isInstalled; // True when an Identity Selector is available
// to the browser
Web sites may choose to detect browser and Identity Selector support for Information Cards and modify their login page contents depending upon whether Information Card support is present, and which of the OBJECT and/or XHTML syntaxes are supported by the browser and supported by the web site. This allows Information Card capabilities to be shown when available to the user, and to be not displayed otherwise.
Detecting an Information Card-enabled browser may require detecting specific browser and Identity Selector versions and being aware of the nature of their Information Card support. A method of accomplishing this for Internet Explorer is described in Appendix B.
- A Guide to Interoperating with Information Cards in Windows CardSpace v1.0, December 2006.
- A Technical Reference for Information Cards in Windows CardSpace v1.0, December 2006.
- Microsoft .NET Framework 3.0 Community Web Site, December 2006.
- Web Services Metadata Exchange (WS-MetadataExchange), August 2006.
- Web Services Security Policy Language (WS-SecurityPolicy), July 2005.
- Web Services Trust Language (WS-Trust), February 2005.
The contents of an HTTPS POST generated by a page like the first example in Section 4.1.1 follows:
POST /test/s/TokenPage.aspx HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-sh
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR
2.0.50727; .NET CLR 3.0.04506.30)
An un-escaped and reformatted version of the preceding xmlToken value, with the encrypted value elided, is as follows:
<enc:EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element" xmlns:enc=
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
Script code can detect browser support for Information Cards within Internet Explorer by testing the userAgent string to determine whether the browser version is greater than or equal to "
MSIE 7.0". A second issue with Internet Explorer 7 is that the Information Card support might not be installed (because Microsoft .NET Framework 3.0 is not installed on the machine). This can be detected within the browser by using the "
isInstalled" property on the Information Card OBJECT from scripting code. .NET 3.0 installation can be detected on web servers by testing whether the userAgent string contains "
.NET CLR 3.0".
For example, the userAgent string on a Windows XP machine using IE 7 and .NET 3.0 will contain at least these elements:
MSIE 7.0; Windows NT 5.1; .NET CLR 3.0.04506.30