Commentary by Mark Wahl, CISA
Organizing principles for identity systems:
The current InfoCard display token (20070711)
In an InfoCard identity metasystem, there are the three traditional parties to an interaction: the end user, the relying party (RP), and the identity provider (IdP). When the user wishes to perform a login at an RP web site from their web browser, the RP's HTML form triggers the web browser to launch identity selector on the user's desktop. By interacting with the identity selector, the user can pick a card (a self-issued generated by the end user themself, or a managed card issued by an IdP), and if it is a managed card, authenticate to the IdP.
There are several key UI design points in the identity selector, including
- the display of information about the RP site,
.gif)
- the presentation of a selection of multiple cards for choosing,
- the visual appearance of each "card",
- the display of the token or claims which are being sent to the RP.
In the CardSpace implementation of an identity selector, the selector developer (Microsoft) controls the user interface: how cards, tokens and claims appear on the screen. The implementation allows a limited ammount of text information to be provided by the IdP, as a "display token", that illustrates the token or claims which are being sent to the RP. This is necessary as the token and its claims are encrypted by the IdP using the public key of the RP: even though the identity selector has this encrypted token in its memory while the token is in transit, the selector doesn't have the RP's private key and so can't decrypt it: the user must trust that the IdP is providing a reasonable token and claims.
In section 3.7 of their paper "Design Rationale behind the Identity Metasystem Architecture", Kim Cameron and Michael Jones of Microsoft present the "display token" concept:
"For a human user to meaningfully control the information that would be released by selecting an identity, he or she must be able to view a human-readable and comprehensible representation of those claims. Hence, the identity selector must be able to display representations of claim values. However, because claims can be represented using any payload format, including new ones yet to be invented, it would be impossible to write identity selector code to meaningfully display claim values based only upon the payload's native representation of those claim values (unless we implemented potentially dangerous extension mechanisms, significantly increasing the vulnerability of the system)."
"Therefore a design decision was to have identity providers send claim values both in their native format and in a human-readable format (the "display token"), with the two sets of values cryptographically bound together to allow auditing of an identity provider either by users or by relying parties that understand the claims."
Section 4.3.6 of the Microsoft InfoCard v1 Technical Reference (pages 26-27) describes how an IdP can provide a display token, upon request from an identity selector authenticating to it. Currently, the request contains only
- a language tag (encoded as xml:lang) for the user's locale
The response from the IdP includes a tag (in xml:lang) to indicate the locale of the response, and either
- a DisplayTokenText string with a MimeType for that string, to provide "an alternative textual representation of the entire token as a whole when the token content is not suitable for display as individual claims.", although display of this is not implemented by the 1.0 release of Windows CardSpace, or
- a set of DisplayClaims.
Each DisplayClaim sent by the IdP has
| Uri | the unique identifier URI of the claim type (this is required) |
| DisplayTag | a "friendly" name of the claim |
| Description | a "description of the semantics" for the claim |
| DisplayValue | the displayable value of the claim to be sent to the RP, currently a short string |
What the "description of the semantics" means is not clear from the documentation; the blog blog post "Requested Display Token For Cardspace Selector to Display" just shows an arbitrary string, and the MSDN Forum post "RequestedDisplayToken not being displayed" and someone's sample STS code puts into the Description a copy of the claim URI.
The US Patent Application 20070143835 "Security tokens including displayable claims" by Kim Cameron and Arun Nanda (filed 2005, published 2007) describes the invention of a display token. The claims include system, method and computer-readable medium embodiments, including
"...a claims transformer programmed to generate a security token including a computational token and a display token,
the computational token including one or more claims associated with an identity of a principal, and
the display token including display information about the claims in the computational token, wherein
the display information is configured to allow the principal to view the display token""...the display token is provided in a plain text format"
"...the display token includes a first display tag programmed to list a name of one of the claims, and a second display tag programmed to list a value of one of the claims. "
In this invention, an interpreter
"... is programmed to interpret display token 152 of security token 150. For example, interpreter 312 can identify the claims that are summarized in display token 152, and interpreter 312 can display the claims for principal 110 using display 314."
"...For example, referring now to FIG. 10, an example user interface 550 is shown. User interface 550 displays information in a display token of a security token. User interface 550 includes a list 555 of the display information from the display token. In the example shown, the display information includes employer information (e.g., "Company A") and home telephone number (e.g., "999-999-9999"). User interface 550 also includes a send element 557 and a cancel element 559. The principal can select send element 557 to send the security token to the relying part (e.g., Travel Agency A), or select cancel element 559 to refrain from sending the security token."
"In alternative embodiments, additional information can be provided in user interface 550. For example, in some embodiments, information about other security tokens that have been sent to a particular relying party can be listed, and/or information about where the particular security token currently being displayed has been sent previously can be listed. In yet other embodiments, information about the particular relying party to which the security token is going to be sent can be provided in the user interface, and/or links to obtain additional information about the relying party can be provided. Other configurations are possible. "