Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Een hiertoe gemachtigde Applicatiebeheerder van de Onderwijsaanbieder activeert de gegevensuitwisseling tussen Verzender en Ontvanger of Bron en Afnemer voor een specifieke:

    • Gegevenssoort (bijvoorbeeld de gegevenssoort onderwijsdeelnemers of leermiddelgebruik).

    • Onderwijsaanbieder binnen het Onderwijsbestuur

  • De Applicatiebeheerder activeert de gegevensuitwisseling bij de Bron of Verzender van de gegevenssoort. Hiermee wordt voldaan aan het architectuurprincipe ‘De leverancier van brongegevens is verantwoordelijk voor de integriteit van en mutaties op de gegevens met als doelstelling een enkele bron van waarheid voor gegevens uit de bron.’.

    • De Bron of Verzender van de gegevenssoort identificeert en authentiseert de Applicatiebeheerder met een beveiligingsvniveau van substantieel in de referentiecomponent Consentmanagement.

    • Afnemer en Ontvanger hebben de mogelijkheid om:

      • de activatie automatisch te bevestigen aan Bron of Verzender.

      • aan Bron of Verzender terug te geven dat de activatie wordt gecontroleerd (pending) en bijvoorbeeld een additionele controle uit te laten voeren door de Applicatiebeheerder van de Afnemer of Ontvanger. Dit is bijvoorbeeld van toepassing op een gegevenssoort waarbij een hoge integriteit van toepassing is bij de Afnemer of Ontvanger. Na deze additionele controle bevestigt de Afnemer of Ontvanger de activatie aan Bron of Verzender.

  • Bron en Afnemer of 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 Regie op gegevens.

  • Bij iedere uitwisseling van gegevens van de gegevenssoort van de Onderwijsaanbieder controleren Bron en Afnemer of Verzender en Ontvanger of de gegevensuitwisseling geactiveerd is.

...

Optioneel kunnen Leveranciers gebruik maken van het Verwerkersregister van de het Onderwijsbestuur om te controleren of de Leverancier waarmee gegevens worden uitgewisseld ook Verwerker zijn namens het Onderwijsbestuur. Het verifieren van de geldigheid van een verwerkersovereenkomst is beschreven in de sectie Regie op gegevens.

Note

Verwerkersregister is niet verplicht, wel een optie voor Leveranciers

In een eerdere versie van het Architectuurkader Edu-V was er verplicht gebruik van het Verwerkersregister. Deze verplichting heeft geleid tot principiële bezwaren vanuit leveranciers.

De belangrijkste argumenten zijn:

  1. Niet aanwezig zijn van een verwerkersovereenkomst kan geen operationele blokkade zijn.

    1. Verwerkersovereenkomst kan ook ergens anders opgeslagen zijn.

    2. De huidige dekkingsgraad van verwerkersovereenkomsten is nog te laag.

  2. Het controleren van een verwerkersovereenkomst van een andere leverancier is niet de verantwoordelijkheid van leveranciers

    1. Dit is de verantwoordelijkheid van de andere leverancier en de school.

  3. Als leverancier wil ik de vrijheid hebben om de verwerkersovereenkomsten in mijn eigen applicatie te laten ondertekenen.

  4. Applicatiebeheerders die toegang hebben tot de referentiecomponent consentmanagement zijn hiertoe bevoegd door de onderwijsorganisatie. Ze hebben ook de taak om te controleren of de verwerkersovereenkomst ondertekend is. Het is dus procedureel opgelost en hoeft niet technisch opgelost te worden.

  5. Een verwerkersregister met contracten van alle leveranciers levert veel marktinformatie op één plek op. Is dat wel wenselijk?

Deze argumenten hebben geleid tot het schrappen van het verplicht gebruik maken van het Verwerkersregister. Het verwerkersregister is niet geschrapt uit het Ecosysteem om leveranciers die wel gebruik willen maken van de dienst hier toch mee te laten experimenteren.

De wettelijke verplichting voor het ondertekenen van een verwerkersovereenkomst blijft uiteraard onverminderd van toepassing.

...

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.