For å kunne få presentert tilpassede websider og læringsressurser i dag må elever og lærere registrere sine tilgjengelighetsbehov og preferanser i de enkelte tjenestene som tilbyr tilpasninger. Dette fører lett til at informasjon som kan utlede helseforhold og annen personlig informasjon registreres og må vedlikeholdes i mange tjenester. Også tjenester utenfor skoleeiers kontroll.

UNINETT ABC setter nå i gang et prosjekt der vi skal vise at dette kan gjøres på en enklere og sikrere måte med allerede eksisterende teknologi og standarder:

• Elever og lærere må kunne vedlikeholde informasjonen en plass, men den skal kunne benyttes av mange tjenester.
• Tjenesten som oppbevarer tilgjengelighetsbehovene for elevene og lærerne skal ikke inneholde personidentifiserende informasjon.
• Tjenester som benytter tilgjengelighetsbehovene til å tilpasse websider og læringsressurser trenger ikke personidentifiserende informasjon.
• Tjenestene som benytter tilgjengelighetsbehovene trenger/bør ikke lagre tilgjengelighetsbehovene i tjenesten.
• Eksisterende standarder og infrastruktur for informasjonsoverføring og tilgjengelighetbehov benyttes.

Under følger et innlegg jeg skrev på bloggen min i fjor høst om dette. Fokuset mitt har vært på det tekniske og personvernmessige, mens jeg regner med at om Kristine eller Cecilie hadde skrevet om dette så hadde det nok vært andre muligheter som hadde vært i fokus. :)

A federated needs and preferences service

(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:

1. CP1 to IdP1: I have a user who wants to use my services. Could you authenticate him and give me some information about him?
2. IdP1 to CP1: He is authenticated. You know him as 74295abe5 and he is still a student
3. 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?
4. NP to IdP1: I need to know who the user in the current session is.
5. IdP1 to NP: You know him as 123456789012345
6. 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: