Cardspace & Service Invocation

I got thinking about Cardspace the other day and it struck me that Cardspace does a great job of authenticating me to the relying party, but the relying party can't use that authentication for service invocations on my behalf.

For example...

1. User browses to the relying party (RP) and is prompted by Cardspace to authenticate
2. User selects one of their cards (that they've previously used with the RP) and is logged in to the site
3. Next the RP wants to import the user's AIM buddy list in order to enhance the user's experience at the site (e.g. find other users who also use the RP)
4. The RP either requests AIM credentials and uses a back-channel API call to authenticate the user separately, or it redirects the user to AIM to authenticate
5. AIM validates the credentials and returns a service API token
6. The RP uses the service API token to request the buddy list
7. Note that the user now has two different and distinct authentication sessions (one with the Cardspace or Managed STS and one with AIM)

Now it would be nice if the RP could use the existing authentication “session” with the user (as represented by the Cardspace token) without forcing the user to re-authenticate to AIM. Of course, the RP has no way of knowing whether the token it has is valid at AOL, nor probably, how to transform the token it has into a token that is valid at AOL. I suppose that if the token is a SAML token, then the RP could look at the issuer of the token and check to see if it is the AOL STS and from that try to use the token at AOL. The problem for the RP is that it might need to interact with many different services. What kind of claims does the RP request of Cardspace in order to get a token with the desired capabilities (e.g. service invocation with either Google or AOL)?

In order to solve this problem, it is very common in today's web experience for relying party A to request relying part B's authentication credentials in order to provide a service to the user. However, I always feel very nervous about giving relying party B's authentication credentials to relying party A. As the number of identities that consumers have to manage shrinks, the overlap of an authentication session across multiple relying parties grows. The identity meta-system should allow for the re-use of the authentication session across multiple relying parties as approved by the consumer.

One workable model, though somewhat inefficient, is for relying party A to request a service invocation token from relying party B. Using OpenID as the authentication protocol, the flow goes something like this...

1. User browses to relying party A (RPA) and enters their OpenID to login
2. Relying party A invokes the OpenID authentication flow redirecting the user to their OpenID Provider (OP)
3. The user authenticates to the OP and is redirected back to RPA
4. RPA requests a service token from relying party B (RPB) using a browser re-direct
5. RPB requests an authentication of the user via their OP
6. Since the user is already logged into the OP, this authentication step could be “seamless” to the user
7. RPB creates a service invocation token for RPA and redirects the browser back to RPA
8. RPA requests the data from RPB using the returned service invocation token

All the front-channel redirects make it easy to get the user's consent as necessary. However, depending on the bandwidth of the consumer's internet connection, and the physical locations of RPA, RPB and OP, there can be some significant performance implications.

Tags: Concordia, Cardspace, Identity Meta-System, OpenID, Service Invocation