In een aantal blogs heb ik het al eerder gehad over de inrichting van de ‘ideale’ content-distributieketen voor digitaal lesmateriaal. In zo’n situatie is er een belangrijke rol voor een onafhankelijke partij die de identiteiten van de gebruikers (lees: studenten en leraren) beheerst. Deze partij (in ons geval de Kennisnetfederatie Entree) checkt of de student die lesmateriaal bij een uitgever wil inzien inderdaad diegene is die hij zegt te zijn en geeft de resultaten hiervan aan de uitgever door. De uitgever beslist dan op basis van deze info of hij de student toegang verleent tot zijn materiaal.
De school die de gegevens rond de identiteit levert is in dit geval een IdentityProvider (idP) en de content leverende uitgever een Serviceprovider (SP).
Technisch loopt dit allemaal als een zonnetje. Als iedereen zich maar aansluit bij de federatie is toegang verlenen relatief simpel en zijn we in veel gevallen af van toegangscodes en meer van die ellende.
Het wordt lastiger als we gaan kijken welke informatie we nu via de federatie naar de uitgevers gaan sturen. Standaard stuurt Kennisnet al wel wat studenteninfo mee naar de serviceprovider: om te checken of de student wel is wie hij zegt te zijn moet de gebruikersnaam toch echt wel bekend zijn alsmede de school waar deze student vandaan komt. Deze gegevens worden in de vorm van ‘attributen’ meegestuurd en komen bij de uitgever terecht.
In N@tschool kan heel simpel aangeklikt worden welke attributen er meegestuurd moeten worden. Denk bijvoorbeeld aan de nawgegevens, het mailadres of de geboortedatum van de student. Sommige uitgevers vinden het prettig deze info te krijgen, zoals u begrijpt.
Gelukkig is er een wet die dit doorsluizen van persoonsgebonden gegevens regelt en vooral in de meeste situaties verbiedt. Kennisnet anticipeert daarop en zal alle aangeleverde attributen van studenten leraren filteren en ze normaal gesproken niet doorgeven aan de uitgever.
En als ik dat school toch wil? Dan moet de school Kennisnet per serviceprovider voor de gevraagde attributen vrijwaren, een handtekening zetten en zelf een en ander juridisch regelen met de eigen studenten- en lerarengroep.
Wat zou je door willen geven?
In welke gevallen wil een school bepaalde extra attributen doorgeven? Denk in dit geval bv aan de koppeling die een aantal ROC’s hebben met Deviant, leverancier van digitaal taal- en rekenmateriaal. Deviant heeft er (helaas) voor gekozen een eigen leerlingvolgsysteem te bouwen. Een school wil natuurlijk dat zo’n extern systeem er wat betreft organisatie hetzelfde uitziet als het interne systeem en herkenbaar is voor student en leraar. Groepen en gebruikersnamen moeten zo dus hetzelfde heten als op school het geval is. Door een rechtstreekse koppeling van de ELO N@tschool aan het Deviantsysteem ziet de externe database er inderdaad exact hetzelfde uit als de schoolorganisatie.
De attributen komen in beeld als een student die naar de site van Deviant gaat aan de hand van de meegeleverde attributen in de goede groep geplaatst wordt en onder zijn eigen studentennaam weer terug te vinden is in het Deviantsysteem.
Een ander voorbeeld is als de school een ‘schoollicentie’ afsluit voor bepaalde lesmaterialen. Studenten van het cluster gezondheidszorg mogen tegen een bepaalde (onderhandelde) prijs gebruik maken van materiaal Y. Door het attribuut mee te geven waarin het cluster staat garandeer je de uitgever dat alleen studenten van dit cluster toegang verleend wordt tot het materiaal.
Standaard
De afgelopen weken heeft een aantal leden uit de werkgroep distributie contentketen zich beziggehouden met deze attributenlijst. Mensen van ROC6, Kennisnet Entree, Threeships, saMBOict en de uitgevers (waaronder Deviant) hebben een generieke lijst met attributen opgesteld die de komende jaren als standaard geldt voor de attributenset die meegegeven kan worden van Identityprovider > Entree > Serviceprovider. Deze standaard is essentieel om te kunnen komen tot een uniforme koppeling tussen idP en SP.
Download hier de standaard
Download hier de standaard
Moet je atributen meegeven?
Er bestaat nu enkel een mogelijkheid dat te doen. Behalve een klein aantal verplichte attributen hoef je verder niets mee te geven. Dat is de keus van de school.
Daarnaast zal jouw eigen ELOleverancier deze attributen moeten opnemen in haar systeem. Threeships zal dit met n@tschool in ieder geval gaan doen.
Daarnaast zal jouw eigen ELOleverancier deze attributen moeten opnemen in haar systeem. Threeships zal dit met n@tschool in ieder geval gaan doen.
Kennisnet heeft aangegeven een selfserviceportaal te gaan bouwen om de doorgifte van attributen als school zelf te kunnen gaan regelen. Op een eigen pagina kun je per serviceprovider aanvinken welke attributen er meegestuurd moeten worden en kun je Kennisnet vrijwaren.
En verder...
Binnenkort zal ik ingaan op de jurische aspecten van dit gebeuren en een voorbeeld geven hoe je als school een en ander moet organiseren om de contentketen binnen je eigen instelling te optimaliseren.
Reacties
Een reactie posten
Bedankt voor jou bijdrage aan dit blog.
JaapJan Vroom