M2M gegevensuitwisselingen

Titel	M2M gegevensuitwisselingen
Status	CONCEPT
Datum	6 maart 2023

Voorstellen tot besluit voor werkconferentie 18 april:

De lagen zijn vereenvoudigd conform de bijeenkomst Architectenraad 12 april. Leveranciers registreren zich als Deelnemer van Edu-V. Onderwijsinstellingen met een eigen softwarehuis zijn ook een soort van ‘eigen’ leveranciers.
M2M gegevensuitwisselingen in huidige vorm publiceren met status CONCEPT.

In het Edu-V Ecosysteem worden gegevens uitgewisseld tussen Leveranciers ten behoeve van Onderwijsinstellingen. 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) registreert zich bij het Edu-V afsprakenstelsel en wordt Deelnemer (D).	L → D
2. Aansluiting	Een Deelnemer (D) sluit zich voor een gegevensuitwisseling aan bij een andere Deelnemer en wordt Verzender (DV) of Ontvanger (DO).	D → DV of DO
3. Connectie	Een Verzender (DV) wisselt gegevens uit met een Ontvanger (DO). Deze uitwisseling wordt gedaan via een veilige connectie (v).	DV <-v-> DO
4. Mandaat	Een Onderwijsinstelling (O) mandateert een Deelnemer voor het verwerken van gegevens. De Deelnemer wordt Deelnemer met Mandaat (DM) voor de desbetreffende Onderwijsinstelling.	D → DM voor O
5. Activering	Een Administrator van een School activeert de uitwisseling van een gegevenssoort tussen een Verzender met Mandaat (DMV) en Ontvanger met Mandaat (DMO) voor een specifieke School (s) binnen een Onderwijsinstelling (O)	DMVs <-v-> DMOs voor s binnen O

Indien Onderwijsinstellingen in-house applicaties hebben ontwikkeld dan kunnen ze als zijnde ‘eigen’ Leverancier deelnemen aan het Ecosysteem. Ze vervullen dan net als alle andere Leveranciers een Business of Ondersteunende rol en kunnen voor de desbetreffende rol deelnemer worden.

Een voorbeeld is bijvoorbeeld een MBO-instelling die de rol van Dashboardaanbieder gaat vervullen en voortgangsgegevens en toetsresultaten combineert in een eigen ontwikkeld Dashboard.

Laag 1. Registratie – Leveranciers zijn bekend

Alle Leveranciers 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 Leverancier vastgelegd. Op deze manier kan een Leverancier in het Ecosysteem worden geïdentificeerd en kan een Leverancier op een veilige manier deelnemen aan gegevensuitwisselingen en kan een Onderwijsinstelling mandaten verstrekken aan Leveranciers voor het uitwisselen van gegevens.

Alvorens een Leverancier gegevens kan gaan uitwisselen in het Ecosysteem, dient een Leverancier te beschikken over:

Een unieke identifier zijnde het OIN gebaseerd op het KvK-nummer.
Een geldige registratie bij Edu-V. De volgende informatie is tenminste bij Edu-V bekend:
- Business of Ondersteunende rollen, referentiecomponenten en koppelvlakken
- Endpoints
- Contactgegevens
Technische kwalificatie voor de gekozen rollen, referentiecomponenten en koppelvlakken.

Laag 2. Aansluiting – Deelnemers zijn gekoppeld

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

Deelnemers hebben hun eigen procedure voor het aansluiten van andere Deelnemers. Voor deze procedure gelden de volgende operationele afspraken:

Deelnemers controleren of de wederpartij geregistreerd is als Deelnemer bij Edu-V (zie laag 1)
Deelnemers bepalen welke gegevenssoorten er onderling uitgewisseld gaan worden.
- De mogelijkheden voor de gegevenssoorten zijn beperkt tot de Business rollen, referentiecomponenten en koppelvlakken die beide Deelnemers ondersteunen.
- De gegevenssoorten en bijbehorende scopes zijn beschreven in Classificatie en scopes gegevensoorten.

Voorbeeld

Als Leermiddelenshop is het mogelijk om adresgegevens van Onderwijsdeelnemers te ontvangen van de Administratiesysteemaanbieder indien de Leermiddelenshop beschikt over de referentiecomponent ‘Distributiefaciliteit voor levering van fysieke leermiddelen’. Zo kan een Leermiddelenshop in de fijndistributie Leermiddelen op thuisadres laten bezorgen.

Deze gegevensuitwisseling is binnen het Ecosysteem niet beschikbaar voor andere Business en Ondersteunende rollen.

Deelnemers testen de aansluiting. Deelnemers delen hiervoor de noodzakelijke gegevens met elkaar:
- Acceptatieomgeving
- Client credentials en certificaten
- Technische documentatie
Deelnemers wisselen alle noodzakelijke gegevens met elkaar uit voor de uitwisseling:
- Client credentials
- Certificaten
- (Endpoints zijn eventueel op te vragen bij de registratie van Edu-V)
Deelnemers sluiten optioneel een Service Level Agreement
Deelnemers zijn collegiaal in het aansluiten op elkaar. De hiervoor noodzakelijke gegevens, overeenkomsten en documentatie wordt tijdig verstuurd, behandeld en ondertekend.

Laag 3. Connectie – Iedere uitwisseling is veilig

Iedere gegevensuitwisseling dient plaats te vinden via een beveiligde connectie en vanuit systemen die voldoen aan de eisen voor informatiebeveiliging. Edu-V benut op dit vlak de door Bureau Edustandaard ontwikkelde en beheerde technische afspraken van Edukoppeling.

Iedere Verzender of Ontvanger in het Ecosysteem van Edu-V dient te voldoen aan de volgende eisen:

De koppelvlakken voldoen aan het REST/SAAS profiel van Edukoppling.
Identificatie en authenticatie vindt plaats via het in ontwikkeling zijnde OAuth profiel van Edukoppeling met de volgende additionele afspraken:
- Edukoppeling schrijft het gebruik van PKI Overheidscertificaten voor. Als alternatief is het ook mogelijk om een client certificaat uitgegeven door de Verzender te hanteren.
- Edukoppeling 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. Binnen Edu-V werken we niet met dit principe.
- Bij het aanvragen van een Token hanteren we twee additionele afspraken:
  - Het is mogelijk om een Token aan te vragen voor een specifieke scope.
  - Het is mogelijk om een Token aan te vragen voor een specifieke School, zodat communicatie plaats kan vinden in een veilige context. Binnen deze veilige context kunnen vervolgens persoonsgegevens uitgewisseld worden. Voor het uitwisselen van deze gegevens zijn de lagen Mandaat en Activering ook van toepassing.
Verzender en Ontvanger voldoen aan alle technische, operationele en organisatorische eisen die voortkomen uit het kader voor Informatiebeveiliging. In dit kader zijn voorgeschreven:
- Certificeringsschema informatiebeveiliging en privacy ROSA
- Uniforme Beveiligingsvoorschriften Veilig en Betrouwbaar e-mailverkeer
- Uniforme Beveiligingsvoorschriften Security Headers
- Uniforme Beveiligingsvoorschriften – Transport Layer Security (TLS)

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 – Deelnemer is gemandateerd als Verwerker

De gegevens die uitgewisseld worden zijn van de Onderwijsinstelling of van de Deelnemer. 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. Voor het uitwisselen van gegevens van de Deelnemer, zoals bijvoorbeeld catalogusinformatie, is dit mandaat niet noodzakelijk.

Indien er gegevens worden uitgewisseld waar een Onderwijsinstelling zeggenschap over heeft dan voldoen Verzender en Ontvanger aan de volgende additionele eisen:

Verzender en Ontvanger beschikken allebei over een geldige en door het Onderwijsbestuur getekende verwerkersovereenkomst.
De mandaten voortkomend uit de verwerkersovereenkomst zijn door het Onderwijsbestuur geregistreerd bij één Ondersteunende rol Registerhouder in de referentiecomponent Mandatenregister.
Mandaten worden in dit Mandatenregister gespecificeerd op het niveau van:
- School: daar waar een onderwijsdeelnemer is ingeschreven en waar het onderwijs wordt uitgevoerd.
- Leverancier: deze Leverancier is Verwerker van het Verwerkersverantwoordelijke Onderwijsbestuur voor de gespecificeerde Scholen.

Een mandaat is een overeenkomst tussen een Onderwijsbestuur 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). In het mandaat hoeft hierdoor ook niet vastgelegd te worden welke gegevenssoorten er uitgewisseld gaan worden.

Zijn dit voldoende niveaus?
Overweging: dienen hier ook Producten gespecificeerd te zijn?

Verzender en Ontvanger zijn aangesloten op dit Mandatenregister van de door de Onderwijsinstelling gekozen Registerhouder.
Het Onderwijsbestuur heeft de gegevensuitwisseling vanuit dit Mandatenregister naar het consentmanagement van de Verzender of Ontvanger geactiveerd. Op deze wijze kan bijvoorbeeld:
- Verzender (of Ontvanger) controleren of een nieuwe Ontvanger (Verzender) een geldig mandaat heeft gekregen vanuit het Onderwijsbestuur.
- Bij het intrekken van een mandaat door Onderwijsbestuur de Verzender en Ontvanger op de hoogte worden gesteld en alle gegevensuitwisselingen worden gedeactiveerd.
- Verzender (of Ontvanger) periodiek controleren of een mandaat voor Ontvanger (of Verzender) nog actief is.
Verzender en Ontvanger controleren minimaal dagelijks of de wederpartij nog beschikt over een geldig mandaat.
Verzender en Ontvanger beschikken over de referentiecomponent Consentmanagement en voldoen aan de voor hen geldende functionele, technische en operationele afspraken zoals beschreven in Verlenen van mandaten.
De door de Onderwijsinstelling gekozen Registerhouder beschikt over de referentiecomponent Mandatenregister en voldoet aan de van toepassing zijnde functionele, technische en operationele afspraken zoals beschreven in Verlenen van mandaten en /wiki/spaces/AFSPRAKENS/pages/9175055.

Laag 5. Activering – Uitwisseling van gegevenssoort voor school

De Leveranciers die optreden als Verzender en Ontvanger zijn beide reeds gemandateerd door de Onderwijsinstelling om gegevens uit te wisselen (zie laag 4). Echter dit wil niet zeggen dat voor alle scholen die onder deze Onderwijsinstellingen vallen ook alle gegevenssoorten uitgewisseld kunnen gaan worden. In deze vijfde laag geven we iedere School de flexibiliteit om de uitwisseling van een gegevenssoort te activeren of deactiveren.

De combinatie van mandaat (laag 4) en activering (laag 5) is een uitwerking 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’.

Voor de activatie van een uitwisseling van een gegevenssoort voor een school zijn de volgende afspraken van belang:

De verantwoordelijke voor het (de)activeren van een uitwisseling.
De wijze waarop een (de)activatie uitwisseling wordt gecontroleerd.
De locatie waar de uitwisselingen worden ge(de)activeert.
De eisen aan het register van de (de)actieve uitwisselingen.

Wie is verantwoordelijk voor het (de)activeren van een uitwisseling?
Overweging: De Leverancier is reeds gemachtigd door het de Onderwijsinstelling en kan optreden als Verwerker.
Overweging: De Leverancier heeft in zijn applicaties een Admin omgeving waarin een persoon vanuit een School met Administrator rechten in staat is om de applicatie te configureren en beheren.
Voorstel: De persoon met Administrator rechten vanuit een school (de)activeert een uitwisseling.
Op welke wijze worden (de)activatie uitwisselingen gecontroleerd?
Overweging: Zoals beschreven in laag 3. Connectie, wordt er bij een uitwisseling gecontroleerd of een Leverancier beschikt over het recht om een gegevenssoort uit te wisselen.
Overweging: Een uitwisseling van een gegevenssoort kan op ieder moment worden ge(de)activeert. Vanaf dat moment moeten alle gegevensuitwisselingen betreffende de gegevenssoort niet meer mogelijk zijn. Dit impliceert dat deze controle zo laat mogelijk plaatsvindt.
Voorstel: De controle vindt plaats vlak voordat de gegevensuitwisseling plaatsvindt en bij iedere bevraging van een API. Het alternatief is om de controle te doen bij het aanvragen van het Token. Echter een Token heeft een geldigheidsduur. In de tussentijd kan een uitwisseling gedeactiveerd zijn.
Waar worden uitwisselingen ge(de)activeert?
Overweging: Iedere Leverancier heeft zijn eigen rollen en rechtenbeheer en vertrouwt zijn eigen Administrators. Een Leverancier kan er niet vanuit gaan dat een Administrator van een andere Leverancier ook Admin-rechten heeft voor zijn applicatie.
Voorstel: De uitwisseling wordt voor beide Leveranciers – Verzender en Ontvanger – ge(de)activeert.
Overweging: De controle op het actief zijn van een uitwisseling vindt plaats bij iedere bevraging. Dit betekent dat deze controle een grote impact heeft op de performance van de gegevensuitwisseling. Hier is het niet wenselijk als een Leverancier hiervoor afhankelijk is van een andere Leverancier.
Voorstel: Iedere Leverancier hanteert zijn eigen register voor het (de)activeren van uitwisselingen.
Voorstel: In het SEM Ecosysteem is een dergelijke tweezijdige oplossing geïmplementeerd in de Consent API.
Welke eisen zijn er aan het register?
Voorstel: De Leverancier beschikt over een adequaat rollen en rechtenbeheer inclusief een rol van Administrator.
Voorstel: In het register is duidelijk zichtbaar welke uitwisseling voor welke gegevenssoort actief is, en bij welke zijde (Verzender of Ontvanger) de uitwisseling is ge(de)activeert.
Voorstel: Iedere wijziging activering of deactiveren wordt gelogd met een tijdstempel.

Status en totstandkoming

Deze uitwerking is gebaseerd op basis van de volgende stappen:

Documentstudie van Edukoppeling en SEM Ecosysteem.
Voorbereidende bijeenkomst voor de Architectenraad van RdB en KV.
Uitwerking in een concept inclusief voorstellen tot besluit.