Titel | IBP van M2M gegevensuitwisselingen | ||||
Status |
| ||||
Datum | 2 maart 2023 |
...
De verantwoordelijke voor de registratie van mandaten.
De wijze waarop mandaten worden gecontroleerd.
De locatie waar mandaten worden geregistreerd.
De eisen aan het register van de mandaten.
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.
Overweging: Schrijven we OSR voor? Of is het beter om hier expliciet de rol van Mandatenregister voor uit te werken. Het OSR, maar ook andere Leveranciers, kunnen vervolgens deze rol gaan vervullen?Welke eisen zijn er aan het register?
Voorstel: Het OSR beschikt over een adequaat rollen en rechtenbeheer inclusief een rol van Administrator.
Voorstel: In het register is duidelijk zichtbaar welke mandaten zijn verleend (of ingetrokken).
Voorstel: Iedere verlening of intrekking van een mandaat wordt gelogd met een tijdstempel.
Laag 5. Activering – Uitwisseling van gegevenssoort voor school
...
Voor de activatie van een uitwisseling van een gegevenssoort voor een school zijn de volgende afspraken van belang:
Wie mag de uitwisseling De verantwoordelijke voor het (de)activeren van een uitwisseling.
De wijze waarop een (de)activeren?Waar wordt de uitwisseling activatie uitwisseling wordt gecontroleerd.
De locatie waar de uitwisselingen worden ge(de)activeert?
Op welke manier wordt de
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
<TO BE ADDED>
OAuth2.0 Token en scopes
<TO BE ADDED>
Consentregistratie
...
.
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.