...
Tip |
---|
Voorstellen tot besluit voor werkconferentie 18 april:
|
...
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 vragen een Token aan zoals uitgewerkt in M2M Identificatie en authenticatie.
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?
...
)
...
Laag 4. Mandaat – Deelnemer is gemandateerd als Verwerker
...
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 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) Onderwijsinstelling 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.
...
gegevens van en over onderwijsdeelnemers en -medewerkers’.
Indien er gegevens worden uitgewisseld waar een Onderwijsinstelling zeggenschap over heeft dan voldoen Verzender en Ontvanger aan de volgende additionele eisen:
Verzender en Ontvanger zijn gemandateerd door de Onderwijsinstelling (zie laag 4).
Een hiertoe gemachtigde Administrator van de Onderwijsinstelling activeert de gegevensuitwisseling tussen Verzender en Ontvanger voor een specifieke:
Gegevenssoort (bijvoorbeeld onderwijsdeelnemers of gebruiksgegevens)
School binnen de Onderwijsinstelling
Verzender en Ontvanger beschikken over de referentiecomponent Consentmanagement en voldoen aan de voor hen geldende functionele, technische en operationele afspraken zoals beschreven in Activeren en deactiveren van een gegevensuitwisseling.
Bij iedere uitwisseling van gegevens van de gegevenssoort van de School wordt een Token aangevraagd met de schoolIdentifier van de School.
Bij iedere uitwisseling van gegevens van de gegevenssoort van de School controleren Verzender en Ontvanger of de gegevensuitwisseling geactiveerd is. Hiervoor wordt de schoolIdentifier van de School uit het Token gebruikt.
Onderwijsinstelling is verantwoordelijk voor een correcte registratie van al haar Scholen (inclusief identifiers) in het Scholenregister.
...
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.
Verwerking van feedback vanuit Architectenraad naar een nieuwe iteratie met expliciete operationele afspraken op de vijf niveaus.