(Unlike my other posts this post will be written in English since it might be useful for a wider audience.)
Many services benefits from knowing users needs and preferences. The service might adapt it’s content to any special needs the user have, such as a high contrast design and larger fonts, or that flash animations and videos aren’t useful for me. Today you have to register and update this kind of information in every service. A federated needs and preferences service could provide these and other preferences information to several service providers and still ensure the user’s privacy and consent.
This is just a rough draft of a conceptual solution to the challenge described above. The solution could also be used for other repositories of specialized information/attributes about identities in a SAML–based federation. The technical viability of the solution has to be verified but after a discussion with Andreas it seems doable.
The needs and preferences service
The needs and preferences service (NP) may be as simple or complex as necessary. The important part is that it associates an identity with a set of needs and preferences. In it’s simplest form it could be a web interface to register information and a database.
| UserID | Preference | PreferenceScope |
|---|---|---|
| 1a238565b | High Contrast | VocabularyA |
| 1a238565b | Larger fonts | VocabularyA |
| 1a238565b | Uuid:238146723… | VocabularyB |
The NP service should not know who the user is or any other information about the user. We assume the user register his own information so we can use a targeted ID, which is only used with this service. In theory the NP service can be used in several federations.
| UserID | TargetedID | TargetedIDScope |
|---|---|---|
| 1a238565b | 123456789012345 | FederationA |
| 1a238565b | 987654321098765 | FederationB |
Associating the same UserID with several targeted IDs should be possible by authenticating with the different IdPs in succession. This functionality might not be desirable.
The NP would be a Service Provider and an Attribute Authority.
The content providers
The content providers (CPx) are service providers who use information from the NP. These services might or might not know the identity of the user. In our setting these services could be intranets, learning management systems, learning object repositories etc.
The CPx would be Service Providers.
The identity providers
The identity providers (IdPx) authenticate the user and facilitate the attribute transfer between service providers with no common identifying information about the users.
The IdPx would be Identity Providers with SSO services.
The conceptual model
The actual messages would be transmitted through the user’s browser and be more complex but for simplicity:
The flow could be something like this:
- CP1 to IdP1: I have a user who wants to use my services. Could you authenticate him and give me some information about him?
- IdP1 to CP1: He is authenticated. You know him as 74295abe5 and he is still a student
- CP1 to NP: I have a user with an active session on IdP1. My resource supports these preferences: High Contrast, Monochrome, Larger Fonts. Does the user have any of these preferences set?
- NP to IdP1: I need to know who the user in the current session is.
- IdP1 to NP: You know him as 123456789012345
- NP to User: Are you sure you want to allow CP1 to know that you want High Contrast and Larger Fonts? … OK.NP to CP1: He wants High Contrast and Larger Fonts.
A larger picture
With several federations and content providers the picture could look something like this:
Edit 2008-09-24: Updated the message flow to indicate that the content provider should state it’s capabilities and only receive preferences derived from these capabilities.)