Titel | M2M gegevensuitwisselingen | ||||||||||||||||||
Status |
| ||||||||||||||||||
Versie | 1.0.1 | ||||||||||||||||||
Datum | 25 Juni 2024 | ||||||||||||||||||
Auteur | Architectenraad Edu-V | ||||||||||||||||||
Acties | Geen acties |
In het Ecosysteem Edu-V afsprakenstelsel worden gegevens uitgewisseld tussen Leveranciers ten behoeve van Onderwijsorganisaties. De gegevensuitwisselingen vinden tussen referentiecomponenten (M2M, van systeem naar systeem) plaats. Deze gegevensuitwisselingen dienen veilig te zijn en kunnen in sommige gevallen alleen plaatsvinden nadat een onderwijsorganisatie de uitwisseling van een informatieobject voor een Onderwijsaanbieder heeft geactiveerd.
...
Beveiligingslaag | Toelichting | Relatie |
|---|---|---|
1. RegistratieToetreding | Een Leverancier (L) registreert zich bij het Edu-V afsprakenstelsel en wordt Deelnemer (D). | L → D |
2. AansluitingRegistratie | 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. Uitwisseling | Een Verzender (DV) wisselt gegevens uit met een Ontvanger (DO). De uitwisseling (u) tussen de Verzender en Ontvanger is veilig. | DV <-u-> DO |
4. Activering | Een Applicatiebeheerder van een Onderwijsorganisatie activeert de uitwisseling van een informatieobject tussen een Verzender (DV) en Ontvanger (DO) voor een specifieke Onderwijsaanbieder (Oa) binnen een Onderwijsbestuur (Ob). | DV <-u-> DO voor Oa |
5. Verwerker | Het Onderwijsbestuur (Ob) verleent als verwerkersverantwoordelijke toestemming aan een Deelnemer voor het verwerken van gegevens. De Deelnemer wordt Deelnemer met Verwerkersovereenkomst (Dvo) voor het desbetreffende Onderwijsbestuur. Indien de informatieobject dit vereist, dan hebben zowel Verzender (DvoV) als Ontvanger (DvoO) een verwerkersovereenkomst voor het uitwisselen van de gegevens namens Onderwijsbestuur (Ob). | D → Dm voor Ob DvoV <-u-> DvoO voor Oa binnen Ob |
...
Op de pagina Informatieobjecten is voor alle informatieobjecten in het afsprakenstelsel de classificatie bepaald conform bovenstaande richtlijn.
Laag 1.
...
Toetreding – Leveranciers zijn bekend
Alle Leveranciers in het Ecosysteem Edu-V afsprakenstelsel 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 Ecosysteemafsprakenstelsel. Bij de registratie toetreding wordt tevens de identiteit van de Leverancier vastgelegd. Op deze manier kan een Leverancier in het Ecosysteem afsprakenstelsel worden geïdentificeerd en kan een Leverancier op een veilige manier deelnemen aan gegevensuitwisselingen.
| Info |
|---|
Onderwijsorganisatie als Leverancier Indien Onderwijsorganisaties in-house applicaties hebben ontwikkeld dan kunnen ze als zijnde ‘eigen’ Leverancier deelnemen aan het Ecosysteemafsprakenstelsel. Ze vervullen dan net als alle andere Leveranciers één of meerdere gekozen referentiecomponenten en worden hiermee Deelnemer aan het Afsprakenstelsel Edu-V. Ze conformeren zich net als alle Leveranciers die de gekozen referentiecomponenten vervullen aan de bijbehorende afspraken. Een voorbeeld is bijvoorbeeld een MBO-instelling die de referentiecomponent Leermiddelendashboard gaat vervullen en leermateriaalgebruik en leerresultaten combineert in een eigen ontwikkeld Dashboard leervoortgang en -resultaten. |
Alvorens een Leverancier gegevens kan gaan uitwisselen in het Ecosysteemafsprakenstelsel, dient een Leverancier te beschikken over:
Organisatie Identificerend Nummer (OIN). Binnen Edu-V hanteren we de richtlijn vanuit Edukoppeling voor het opbouwen van het OIN voor Leveranciers wordt conform de standaard Edukoppeling het Handelsregisternummer (HRN) gebruikt.
Een geldige registratie toetreding bij Edu-V. De volgende informatie is tenminste bij Edu-V bekend:
Organisatie Identificerend Nummer (OIN)
Referentiecomponenten en gegevensdiensten
Endpoints
Contactgegevens
Technische kwalificatie voor de gekozen referentiecomponenten en gegevensdiensten.
De Leverancier is na toetreding te herkennen binnen het Ecosysteem afsprakenstelsel op basis van het OIN.
Laag 2.
...
Registratie – 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 referentiecomponent.
...
| Info |
|---|
Voorbeeld Als referentiecomponent Distributiefaciliteit is het mogelijk om adresgegevens van Onderwijsdeelnemers te ontvangen van een Administratiesysteem onderwijsdeelnemers. Zo kan een leverancier in de fijndistributie Leermiddelen op thuisadres laten bezorgen. |
Deelnemers testen de aansluiting. Deelnemers delen hiervoor Leveranciers delen de noodzakelijke gegevens met elkaar:
Acceptatieomgeving (endpoints voor testdoeleinden)
Productieomgeving (endpoints)
Technische documentatie
Client credentials voor M2M identificatie, authenticatie en autorisatie
Client id per referentiecomponent
(optioneel) secret per Client Id
Scopes per Client id
Naam van Applicatie AStatus colour Green title MUST
Omschrijving van Applicatie AStatus colour Blue title SHOULD
Icon van Applicatie A om te tonen in de Consent UI van Leverancier B.Status colour Purple title COULD
Gewenste scopesStatus colour Green title MUST
Naam van leverancier AStatus colour Green title MUST
OIN van leverancier AStatus colour Green title MUST
wks_uri van leverancier AStatus colour Green title MUST
Leverancier A die met Applicatie A wil koppelen aan Applicatie B van Leverancier B deelt de volgende informatie:
Leverancier B deelt de volgende informatie met Leverancier A:
Naam van Applicatie AStatus colour Green title MUST
Omschrijving van Applicatie AStatus colour Blue title SHOULD
Icon van Applicatie A om te tonen in de Consent UI van Leverancier B.Status colour Purple title COULD
Acceptatieomgeving (endpoints voor testdoeleinden)Status colour Blue title SHOULD
Productieomgeving (endpoints)Status colour Green title MUST
Technische documentatieStatus colour Blue title SHOULD
Client credentials voor M2M identificatie, authenticatie en autorisatieStatus colour Green title MUST client_idper applicatieDe
client_idwordt bepaald door Leverancier B.Status colour Red title SHOULD NOT client_idis bij voorkeur niet gelijk aan het OIN. Het OIN wordt gehanteerd om de organisatie vast te stellen. Hetclient_idis gericht op de identificatie en de authenticatie van de applicatie van de leverancier.
Scopes per
client_id
Leveranciers testen de aansluiting.
| Info |
|---|
Een Leverancier kan meerdere Clients hebben Doordat in het Edu-V afsprakenstelsel een Leverancier meerdere referentiecomponenten kan vervullen en organisaties meerdere applicaties aan kunnen bieden, is het van belang om in de gegevensuitwisseling te kunnen bepalen vanuit met welke hoedanigheid applicatie een Leverancier deel gaat nemen aan een gegevensuitwisseling. Zoals in het vorige informatieblok toegelicht bepaalt namelijk de referentiecomponent welke gegevens beschikbaar zijn om uit te kunnen wisselen. Dit dient ook geborgd te zijn bij de identificatie, authenticatie en autorisatie. Bij het aansluiten van twee Leveranciers wordt voor iedere referentiecomponent applicatie een eigen Client In aanvulling hierop wordt bij het Client id geregistreerd welke informatieobjecten uitgewisseld mogen worden. Dit wordt vastgelegd in de scopein de Clientregistratie het OIN en de scopes vastgelegd. De scopes representeren de gegevensdiensten die met deze Client worden uitgewiseld. Een Leverancier kan vervolgens in de uitwisseling (laag 3) een gegevensuitwisseling starten in een bepaalde scope. Zo kan geverifieerd worden of de Leverancier ook deze gegevens mag uitwisselen op basis van de scopes die beschikbaar zijn voor de client. |
...
Deze uitwerking is gebaseerd op basis van de volgende stappen:
0.0.1: Documentstudie van Edukoppeling en SEM Ecosysteem.
0.0.2: Voorbereidende bijeenkomst voor de Architectenraad van RdB en KV.
0.0.3: Uitwerking in een concept inclusief voorstellen tot besluit.
0.0.4: Verwerking van feedback vanuit Architectenraad naar een nieuwe iteratie met expliciete operationele afspraken op de vijf niveaus.
0.0.5: De uitwerking is besproken en aangescherpt tijdens de werkconferentie van de Architectenraad Edu-V op 18 april 2023. Dit heeft geleid tot een scherpere scheiding tussen laag 4 mandaat (juridisch) en laag 5 activering (operationeel) van een gegevensuitwisseling waarover een Onderwijsorganisatie zeggenschap heeft. Tevens is de technische invulling van de uitwisseling (laag 3) aangescherpt.
0.0.6: De beveiligingslagen zijn herschreven op basis van feedback uit de bijeenkomst van de Architectenraad van 12 mei 2023 en het overleg met de Werkgroep Edukoppeling binnen Edustandaard. Dit heeft geleid tot:
De lagen Activering en Mandatering zijn omgewisseld.
Er zijn vier classificaties van gegevenssoorten toegevoegd.
Het proces van activeren is vereenvoudigd waarbij controle voornamelijk bij de bron (Verzender) plaatsvindt.
PKIoverheid-certificaat is toegevoegd.
De werkgroep Edukoppeling werkt nog aan een nieuwe versie van het REST/SAAS profiel. Dit wordt in een volgende iteratie verwerkt.
0.0.7: De specificatie voor het /wiki/spaces/AFSPRAKENS/pages/9175055 inclusief een mandaatcontrole voor classificatie IV gegevenssoorten is bijgewerkt op basis van de feedback uit de Architectenraad van 12 mei 2023.
0.0.8: In de Architectenraad van 24 mei 2023 is gesproken over de toevoeging van de classificatie van gegevenssoorten.
Het kenmerk Eigenaar is aangepast. Het is niet mogelijk om eigenaar te zijn van een gegeven. Als andere voorstellen zijn verantwoordelijke en zeggenschap genoemd. Deze hebben echter een sterke relatie met de AVG, terwijl de classificatie juist ook gaat over gegevens waar de AVG niet op van toepassing is. Als voorstel is het kenmerk verandert naar Regie op gegevensuitwisseling.
Er is een link toegevoegd naar een hulpmiddel van de Autoriteit Persoonsgegevens om te bepalen of er sprake is van een Verwerkersverantwoordelijke en/of een Verwerker.
0.09: Uitkomsten uit werkgroep Edukoppeling ten aanzien van het Secure API OAuth profiel gewerkt in laag 3 uitwisseling. In aanvulling hierop is ook een tijdelijke pagina toegevoegd over de beoogde werking van deze profielen. Deze pagina wordt verwijderd zodra de specificatie van de profielen is afgerond door de Werkgroep Edukoppeling. Er zal dan een verwijzing gemaakt worden naar de specificaties bij Edustandaard.
0.0.10: Op basis van de werkgroep Edukoppeling van 27 juni is de verwijzing naar het Secure API OAuth profiel aangepast. De documentatie wordt nog opgeleverd door de werkgroep. De tijdelijke pagina M2M identificatie, authenticatie en autorisatie beschrijft de beoogde werking voor in de proof of concept.
0.0.11: De term mandatenregister is vervangen door verwerkersregister. In de tekst is dit consistent doorgevoerd en wordt gesproken over toestemming die verleend is door het Onderwijsbestuur (Verwerkersverantwoordelijke) aan Leverancier om als verwerker persoonsgegevens te verwerken. Dit wordt geregistreerd in het verwerkersregister van het onderwijsbestuur. De registratie van de verwerkersovereenkomst is opvraagbaar voor Leveranciers. Met deze wijziging is ook de term mandaat vervangen.
0.0.12: Verwijzing gemaakt naar Edukoppeling profiel: 2023-07-24 Edukoppeling - Secure API OAuth Client Credentials profielen v0.8 (concept)
0.0.13: Verwijzing naar herziening consent aangepast. Nieuwe documentatie is te vinden in een separate sectie op Confluence: Regie op gegevens.
0.0.14: De pagina is besproken tijdens de bijeenkomst van de Architectenraad Edu-V en is gereed voor de ROSA-architectuurscan.
0.0.15: De werkgroep Edukoppeling gaat het Secure API OAuth Client Credentials profiel niet verder ontwikkelen en direct verwijzen naar het NL GOV Assurance profile voor OAuth 2.0. Dit leidt ook tot wijzigingen binnen de toepassing van M2M identificatie, authenticatie en autorisatie voor Edu-V. De wijzigingen zijn verwerkt op deze pagina.
1.0.0: Het Architectuurkader Edu-V is vastgesteld als startpunt voor de implementatie. Tevens is instemming verleend op verdere doorontwikkeling van het Architectuurkader Edu-V op basis van de Architectuurprincipes. Dit akkoord is verleend op het Bestuurlijk Overleg van 27 mei 2024.
1.0.1: Verwijzing naar Best Practice Edukoppeling voor NL GOV Assurance profile voor OAuth 2.0 toegevoegd en op laag van Registratie verwezen naar beheerproces Toetreding.
1.0.2: Verduidelijking van de onderlinge registratie en aansluiting van leveranciers die met elkaar gegevens gaan uitwisselen:
Verduidelijkt welke gegevens er uitgewisseld worden.
Verduidelijkt op welke wijze de
client_idwordt bepaald.