M2M gegevensuitwisselingen

Titel	IBP van M2M gegevensuitwisselingen
Status	DRAFT
Datum	2 maart 2023

In het Edu-V Ecosysteem worden gegevens uitgewisseld tussen Leveranciers ten behoeve van Onderwijsinstellingen (hierna: Partijen). De gegevensuitwisselingen vinden tussen systemen (M2M) plaats. Deze gegevensuitwisselingen dienen veilig te zijn en kunnen in sommige gevallen alleen plaatsvinden na een mandaat van een Onderwijsinstellingen en het activeren van een uitwisseling van een gegevenssoort voor een School. In het Edu-V afsprakenstelsel is deze beveiliging op vijf lagen georganiseerd.

Beveiligingslaag	Toelichting	Relatie
1. Registratie	Een Leverancier (L) of een Onderwijsinstelling (O) registreert zich bij het Edu-V afsprakenstelsel en wordt Deelnemend leverancier (DL) of Deelnemend Onderwijsinstelling (DO)	L → DL O → DO
2. Aansluiting	Een Deelnemend leverancier (DL) identificeert en authenticeert zich voor een gegevensuitwisseling bij een andere Deelnemend leverancier en wordt Deelnemend Leverancier Verzender (DLV) of Ontvanger (DLO).	DL → DLV of DLO
3. Connectie (Uitwisseling)	Een Deelnemend Leverancier Verzender (DLV) wisselt gegevens uit met een Deelnemend Leverancier Ontvanger (DLO). Deze uitwisseling wordt gedaan via een veilige connectie.	DLV <-V-> DLO
4. Mandaat (Overeenkomst)	Een Deelnemend Onderwijsinstelling (DO) mandateert een Deelnemend Leverancier voor het verwerken van gegevens. De Deelnemend Leverancier wordt Deelnemend Leverancier met Mandaat (DLM) voor de desbetreffende Deelnemend Onderwijsinstelling.	DL → DLM voor DO
5. Activering (Instemming)	Een Administrator van een School van een Deelnemend Onderwijsinstelling (DO) activeert de uitwisseling van een gegevenssoort tussen een Deelnemend Leverancier Verzender met Mandaat (DLMV) en Deelnemend Leverancier Ontvanger met Mandaat (DLMO) voor een specifieke School (s).	DLMVs <-V-> SLMOs voor s binnen DO

Keuze: Gaan alleen Leveranciers gegevens uitwisselen. Of kunnen ook Onderwijsinstellingen een Business Rol gaan vervullen en gegevens gaan uitwisselen? Denk bijvoorbeeld aan een MBO-instelling die de rol van Leerdashboardaanbieder gaat vervullen en voortgangsgegevens en toetsresultaten combineert in een eigen ontwikkeld Dashboard.

Laag 1. Registratie – Partijen zijn bekend

Alle Partijen in het Ecosysteem dienen zich te conformeren aan de afspraken uit het Afsprakenstelsel Edu-V. Op deze manier beheersen we de continuïteit en de veiligheid van het Ecosysteem. Bij de registratie wordt tevens de identiteit van de Partij vastgelegd. Op deze manier kan een Partij in het Ecosysteem worden geïdentificeerd en kan een Partij op een veilige manier deelnemen aan gegevensuitwisselingen en kan een Onderwijsinstelling mandaten verstrekken aan Leveranciers voor het uitwisselen van gegevens.

Op welke wijze gaan we Leveranciers registreren?
Voorstel: Edu-V met identifier OIN
Voorstel: Leverancier registreert zijn Rollen en gekozen Referentiecomponenten
Voorstel: Leverancier registreert zijn endpoints
Voorstel: Leverancier registreert contactgegevens
Op welke wijze gaan we Onderwijsinstellingen registreren?
Voorstel: RIO met identifier OIN
Voorstel: Een Onderwijsinstelling is een Bevoegd Gezag
Is het noodzakelijk om ook de Schoollocaties te registreren?
Voorstel: Nee. De Onderwijsinstelling volstaat.
Op welke wijze gaan we Schoollocaties binnen een Onderwijsinstelling identificeren?
Voorstel: RIO met identifier combinatie Onderwijsaanbieder en Onderwijslocatie.

Laag 2. Aansluiting – Leveranciers zijn gekoppeld

Om een gegevensuitwisseling tot stand te brengen tussen Leveranciers dienen de Leveranciers technisch op elkaar aangesloten te zijn. In het Edu-V afsprakenstelsel worden afspraken gemaakt over de specificatie van koppelvlakken voor iedere Business rol en referentiecomponent. Een Leverancier kan met een andere Leverancier koppelen vanuit één of meerdere van deze Business rollen en gekozen referentiecomponenten. Bilateraal kunnen daarnaast afspraken gemaakt worden welke gegevenssoorten er tussen de Leveranciers uitgewisseld worden.

Welke controles worden gedaan voordat een Leverancier wordt aangesloten?
Voorstel: Leverancier is deelnemer van Edu-V
Welke informatie dient er uitgewisseld te worden voor de technische aansluiting?
Voorstel: client credentials voor identificatie en authenticatie middels OAuth (zie volgende laag).
Voorstel: technische documentatie en acceptatieomgeving voor testen.
Voorstel: bilaterale afspraken zoals SLA
Op welke wijze wordt in het Ecosysteem vastgesteld welke gegevenssoorten er uitgewisseld mogen worden tussen Leveranciers?
Voorstel: bij de aansluiting worden afspraken gemaakt over welke APIs en bijbehorende scopes er aangesloten worden.

Laag 3. Connectie – Iedere uitwisseling is veilig

Iedere gegevensuitwisseling dient plaats te vinden via een beveiligde connectie. Deze connectie vindt plaats door een aantal stappen:

Identificeren en authenticeren van Verzender of Ontvanger.
Autoriseren van Verzender of Ontvanger.
De uitwisseling vindt plaats via een beveiligde communicatielijn.
De uitwisseling is gebaseerd op een modern protocol.

Op welke wijze identificeren en authenticeren we een Verzender of Ontvanger?
Voorstel: Hanteren van in ontwikkeling zijnde OAuth profiel van Edukoppeling. Dit profiel is gebaseerd op het OAuth Client Credentials protocol.
Overweging: Edukoppeling Identificatie en Authenticatie heeft expliciete afspraken over het hanteren van PKI-overheidscertificaten voor het identificeren van een Partij. Is dit noodzakelijk of volstaat een geldig TLS-certificaat?
Op welke wijze autoriseren we een Verzender of Ontvanger (de Leverancier die een API bevraagt)?
Voorstel: Autorisatie voor de gegevenssoorten en de bilaterale overeenkomst tussen Leveranciers gebeurt op basis van de beide aansluiting overeengekomen API en scopes. De Verzender of Ontvanger vraagt een Token aan met een specifieke scope.
Voorstel: Voor gegevenssoorten waarbij een mandaat van een Onderwijsinstelling verplicht is wordt periodiek door de Leveranciers gecontroleerd of de andere Leverancier beschikt over dit mandaat. Als alternatief kan dit ook bij iedere aanvraag van een Token, maar dit is mogelijk overkill.
Voorstel: In aanvulling op het mandaat dient een Onderwijsinstelling een uitwisseling van een gegevensoort van een school te activeren. Dit betekent dat bij het benaderen van een endpoint gecontroleerd wordt of de gegevensuitwisseling voor de betreffende school geactiveerd is. Een Verzender of Ontvanger vraagt in het geval van een dergelijke uitwisseling een Token aan voor de School.
Overweging: Edukoppeling Identificatie en Authenticatie heeft expliciete afspraken over routering op basis van het from-to principe bij iedere gegevensuitwisseling. Zo kan een Leverancier achter de voordeur een verzoek achter de voordeur routeren voor en naar de correcte onderwijsinstelling. Dit is een implementatiekeuze voor mandaten. Nemen we deze over?
Op welke wijze beveiligen we de communicatielijn?
Voorstel: Hanteren van Uniforme Beveiliging Voorschriften (UBV) voor M2M gegevensuitwisselingen. Het betreft dan zowel de Headers als TLS afspraken.
Welke standaard hanteren we voor het protocol?
Voorstel: Hanteren van REST/SAAS profiel zoals beschreven in Edukoppling, rekening houdend met de overwegingen zoals geformuleerd op deze pagina.

Laag 4. Mandaat – Leverancier is gemandateerd als Verwerker

De gegevens die uitgewisseld worden zijn van de Onderwijsinstelling of van de Leverancier. Zo vallen gegevens over gebruikersgegevens (onderwijsdeelnemers of onderwijsmedewerkers) en gebruiksgegevens (onder meer gebruiksgegevens over leermiddelen, voortgangsgegevens over leermaterialen en toetsresultaten over toetsen) onder de verwerkersverantwoordelijkheid van een Onderwijsinstelling. Een uitwisseling van deze gegevenssoorten kan alleen plaats vinden nadat de Onderwijsinstelling de Leverancier heeft gemandateerd. Hiertoe heeft de Onderwijsinstelling een verwerkersovereenkomst getekend met de Leverancier.

Let op: Een mandaat is een overeenkomst tussen een Onderwijsinstelling (Bevoegd Gezag) en een Leverancier. Dit staat niet gelijk aan een instemming op de activatie van een uitwisseling van een specifieke gegevenssoort voor een School (zie laag 5).

Dit betekent dat afspraken gemaakt worden over:

De verantwoordelijke voor de registratie van mandaten.
De wijze waarop mandaten worden gecontroleerd.
De locatie waar mandaten worden geregistreerd.

Wie is verantwoordelijk voor het registreren van mandaten?
Overweging: De Onderwijsinstelling is Verwerkersverantwoordelijke.
Overweging: De praktijk leert dat Verwerkersovereenkomsten onvoldoende worden ingevuld ook na actief versturen van Leveranciers.
Voorstel: De Onderwijsinstelling is verantwoordelijk voor het registreren van mandaten.
Op welke wijze worden mandaten gecontroleerd?
Overweging: Een Leverancier die gemandateerd is door een Onderwijsinstelling heeft een verantwoordelijkheid om te controleren of een andere Leverancier ook gemandateerd is voor de Onderwijsinstelling.
Voorstel: Leveranciers controleren periodiek of aangesloten andere Leveranciers nog een actief mandaat hebben van een Onderwijsinstelling. Indien dit niet het geval is dan worden alle uitwisselingen van gegevenssoorten voor de scholen die vallen onder de Onderwijsinstelling gedeactiveerd.
Waar worden mandaten geregistreerd?
Overweging: Aangezien de Onderwijsinstelling verantwoordelijk is voor de registratie, is er een voorkeur voor één systeem voor een school.
Overweging: Scholen maken reeds gebruik van OSR voor het mandateren van gegevensuitwisselingen tussen LAS en DUO.
Voorstel: Advies om het OSR te hanteren voor het registreren van mandaten. Leveranciers kunnen bij het OSR, indien ze gemandateerd zijn voor een Onderwijsinstelling, opvragen of een andere Leverancier ook gemandateerd is voor de desbetreffende Onderwijsinstelling.

5. Uitwisseling na activering door een school of individu

De Leveranciers die optreden als Verzender en Ontvanger zijn beide reeds gemandateerd door de Onderwijsinstelling om gegevens uit te wisselen. Dit is reeds vastgesteld in stap 2. Echter dit wil niet zeggen dat voor alle scholen die onder deze verwerkersverantwoordelijke vallen ook alle gegevenssoorten uitgewisseld kunnen gaan worden.

In het Ecosysteem gaan we uit van het principe: ‘gegevens worden uitgewisseld na instemming van de rechthebbende’ en meer in het bijzonder ‘De rechthebbende (school of individu) heeft zeggenschap over zijn of haar gegevens’. De implicatie hiervan is dat een rechthebbende expliciet instemming verleent voor het uitwisselen van een gegevenssoort tussen Verzender en Ontvanger.

OUD

Niveau	Inhoud	Transactie	Beveiliging
Instemming	Informatie van school	Instemming school	Consentregistratie
Rol	API en Scope	Aansluiting leveranciers	OAuth Client Credentials
Referentie-component	Entiteiten en Berichten	Gegevensuitwisseling	OAuth Client Credentials flow met Token en Scopes
Verzender en Ontvanger	Data	Communicatieprotocol	Uniforme Beveiligingsvoorschriften

OAuth2.0 Client Credentials flow

OAuth2.0 Token en scopes

Consentregistratie