Commentary by Mark Wahl, CISA
Organizing principles for identity systems:
Beyond the display token (20070711)
In a previous post, I summarized the current specification of the InfoCard DisplayToken, by which an Identity Provider (IdP) can provide to the identity selector a limited amount of text information that illustrates the token or claims which are being sent to the Relying Party (RP) on the user's behalf.
One assumption of the current display token is that an identity selector should best be able to display to the user the claim types and values that are about to be sent to the RP if the information is provided by the IdP as either a single MIME blob for the token (though this is not implemented in CardSpace 1.0), or as a list of "type: value" pairs:
That aspect of the 'ceremony' may not be most appropriate to the user, and should be under the control of the user and/or their identity provider to express the token information in a way that makes sense for the interaction. Some of the limitations with the current DisplayToken include:
- A claim value may be more extensive than just a "short text string". For example, claims may be a large, structured document, such as a user's interaction history, a "reputation", or an access capability, or may be an image. An identity provider may wish to 'scale' the information being sent in the display token based on the functional limitations of the identity selector (an identity selector running on a small-screened small-memory phone/PDA should not be sent as much information to display to the user about a claim as an identity selector running on a workstation-class computer).
- Even for claims in which the value is a "short text string", the identity provider may wish to provide more information about the claim being transferred, such as an authority, a refresh interval, an expiration date or a privacy constraint which the IdP is placing on the RP's use of the claim. While some of these constraints might be expressed by the IdP as token-wide, it is desirable for this meta-data to be different across claims in a token (e.g., a "name" claim and a "bank balance" claim might have very different constraints, and the user would like to know that).
- The identity provider should be able to provide with these claims links to sites which are outside of the InfoCard environment of IdP-user-RP, in order to assist the user learn more about claim types about which they are unfamiliar, or to enable the user to contact an authority that vetted the claim value, without cancelling the InfoCard interaction. In the case of a self-issued card, the user might have claims with types that are URIs from arbitrary sites on the Internet.
- The identity provider should be able to describe the form layout, as layout of information is one aspect of the identity provider's branding.
For a self-issued card, the user might have a set of card "themes" from which to choose. - The identity provider might also wish to provide information "about" the RP or the interaction that is not a claim per se.
- Display order of claims in a list of claims is particularly important, and it may be desirable to allow the end user to customize this ordering.
- If the IdP is sending a large number of claims for each interaction, perhaps the user only wants to vet a few of them each time - the user should be able to group these particular claims to the top of the list so they don't need to scroll around looking for them.
- If the IdP is sending the four claims homePhone, homeAddress, workPhone, workAddress,
does the user want to view the claims grouped by location (home information followed by work information) or by type (phone numbers followed by addresses).
- "Order of components of a person's name" has cultural significance (I discussed this in a 2005 blog post)
- If the IdP is sending a large number of claims for each interaction, perhaps the user only wants to vet a few of them each time - the user should be able to group these particular claims to the top of the list so they don't need to scroll around looking for them.
- The assumption in the first version of the InfoCard protocol, that the token encrypted for the RP contains a single list of claims, may not be the case for an IdP that aggregates information from other providers (identity oracles and the like). In this case, a display token might nest multiple display tokens from other providers, and these boundaries should be visually explicit.
- An identity selector might present the user with choices other than "continue" or "cancel". In particular, the selector might allow the user to edit this information, which would cause the IdP to re-generate the encrypted token and display token. Reasons for this include:
- Once a user has seen a claim type and value, the user might choose to exclude one or more optional claims from a particular interaction.
- As I mentioned in last month's blog posts "Don't touch my claims if you please, Mister IdP" and "Some claims are more verified than others", the IdP might be providing some user-self-asserted information in the set of claims. As such, the user might wish to edit these claim values in the form without leaving the identity selector.
- Once a user has seen a claim type and value, the user might choose to exclude one or more optional claims from a particular interaction.
- The user might wish to preserve this information for auditing purposes. Potentially the DisplayToken element could be signed by the IdP, or include a trusted timestamp.
- It might be worthwhile to investigate scenarios in which the DisplayToken is decoupled from the security token. As discussed in the post "When is selector ceremony time?", the speaker at Catalyst hinted that in some situations the identity selector ceremony might not be invoked for certain federated transactions between business partners, as IdP sends the token and claims directly to the RP. However even if the selector is no longer a modal, the user may wish to view the claims that are transferred in the background about them. One can envisage a background window, something like a RSS feed viewer, that has claims being made about the user scrolling past.
Another concern is the interest of other stakeholders, besides the end user, the identity provider, and the identity selector developer, in the interaction. What other parties should be permitted to control the interaction by tweaking the visual presentation of identity selector elements?
| the RP? | But could this lead to phishing attacks? |
| an identity selector plugin developer? | Personalization and themability are popular in both open source UI platforms and hosted web applications |
| a metasystem "master of ceremonies"? | Are there categories of interactions for which there is an existing well-defined ceremony that should be used instead? |
| the user's local administrator? | What aspects of the interaction should be affected by Group Policy or similar mechanisms? |
| a claim schema creator? | If I define a favoriteDrink claim type, can I include icons for displaying values of "beer"/"wine"/"soda"? |
| a claim schema commentator? | If I declare favoriteBeverage and favoriteDrink to be effectively the same claim type, can I cause the favoriteBeverage UI aspects to affect the favoriteDrink claim presentation? |
| the RP's CA? | Can an CA limit what claims are appropriate for sending to RPs it certifies? |
| advertisers? | Inline advertisements are a hallmark of many free hosted services and are a possibility on the desktop as well |