Activeren en deactiveren van een gegevensuitwisseling
Titel | Activeren en deactiveren van een gegevensuitwisseling |
Status | DRAFT ARCHITECTenraad REDACTIE BEsluitvorming CONCEPT |
Stadium | POC PILOT BEHEER |
Versie | 0.0.6 |
Datum | 13 Juli 2023 |
Auteur | Architectenraad Edu-V |
Acties | Architectenraad Edu-V
|
Binnen Edu-V is een Applicatiebeheerder van een Onderwijsorganisatie in staat om gegevensuitwisselingen van gegevenssoorten te activeren of deactiveren voor een specifieke Onderwijsaanbieder. Op deze pagina wordt toegelicht op welke wijze een (de)activering plaatsvindt.
De werking hiervan wordt toegelicht in de volgende paragrafen:
- 1 Conceptueel model (de)activeren gegevensuitwisseling
- 2 Proces: randvoorwaarden activeren gegevensuitwisseling
- 3 Proces: randvoorwaarden voor controle registratie verwerkersovereenkomst
- 4 Proces: interactiespecificatie activeren gegevensuitwisseling
- 5 Proces: Interactiespecificatie deactiveren gegevensuitwisseling
- 6 Gebruikersinterface Consentmangement: verplicht te tonen informatie
- 7 Operationeel: periodiek controleren verwerkersregister
- 8 Technisch: APIs
POC Scope
Tijdens de POC wordt geverifieerd of de huidige uitwerking van (de)activeren van gegevensuitwisselingen een passende oplossing is voor de trade-off van de ontwerpprincipes:
Open en flexibel (#2)
Laagdrempelig en gebruiksvriendelijk (#3)
Instemming vanuit de rechthebbende (#7)
Informatiebeveiliging (#9)
Conceptueel model (de)activeren gegevensuitwisseling
In het Ecosysteem worden gegevenssoorten waarvan de Onderwijsorganisatie eigenaar is ge(de)activeerd. Het betreft gegevenssoorten van de classificatie II en IV. Bij het (de)activeren van gegevensuitwisselingen zijn Leveranciers en Onderwijsorganisaties betrokken. In Figuur 1 is het conceptueel model uitgewerkt.
Het activeren of deactiveren van een gegevensuitwisseling gebeurt op een operationeel niveau. Een gegevensuitwisseling wordt geactiveerd op het niveau van een gegevenssoort en voor een Onderwijsaanbieder. In het conceptueel model is Leverancier A de Verzender (en bron) van de gegevenssoort en Leverancier B de Ontvanger (en afnemer) van de gegevenssoort.
Een gegevensuitwisseling wordt immer geactiveerd bij de Verzender (en bron). De Applicatiebeheerder A kan namens de Onderwijsorganisatie een gegevensuitwisseling activeren (O1) in de component Consentmanagement van Leverancier A voor de Onderwijsaanbieder. De activering wordt door de component Consentmanagement van Leverancier A naar de component Consentmanagement van Leverancier B gestuurd (O2a) en door de component Consentmanagement van Leverancier B aan de component Consentmanagement van Leverancier B bevestigd (O2b).
Optioneel kan de component Consentmanagement ook een verificatie van de verwerkersovereenkomst van Leverancier A uitvoeren bij het verwerkersregister van het Onderwijsbestuur (O2c) en kan Leverancier B aan Applicatiebeheerder B vragen om de gegevensuitwisseling te bevestigen (O2d). Deze toestemming is bijvoorbeeld van toepassing voor gegevenssoorten waarvoor de integriteit is geclassificeerd als Hoog voor de Ontvanger.
Voorbeeld
Toetsresultaten hebben een Integriteit classificatie van Hoog voor de component Cijferadministratie. Voor deze gegevenssoort is het aan te bevelen om ook in de component Consentmanagement van de Ontvanger (afnemer) door een Applicatiebeheerder te laten toestemmen dat de gegevensuitwisseling wordt geactiveerd vanuit de Verzender, zijnde in dit voorbeeld de leverancier van de component Cijferadministratie. Ook is het hier aan te raden om als Ontvanger te verifiëren of de Verzender een geldige verwerkersovereenkomst heeft met het Onderwijsbestuur om gegevens te verwerken.
Een gegevensuitwisseling kan worden gedeactiveerd bij zowel Verzender als Ontvanger. In deze beschrijving gaan we uit van een deactiveren door Applicatiebeheerder A. De Applicatiebeheerder A deactiveert (O3) namens de Onderwijsorganisatie een gegevensuitwisseling. De deactivering wordt door de component Consentmanagement van Leverancier A naar de component Consentmanagement van Leverancier B gestuurd (O2a) en door de component Consentmanagement van Leverancier B aan de component Consentmanagement van Leverancier B bevestigd (O2b). Zoals aangegeven kan Applicatiebeheerder B de gegevensuitwisseling deactiveren. In dat geval worden de deactiveringen in omgekeerde volgorde, zijnde eerst O2b en dan O2a, door de componenten Consentmanagement verstuurd.
Voor gegevenssoorten waarvoor de Onderwijsorganisatie een verwerkersovereenkomst dient af te sluiten met de Leveranciers A en B wordt een additionele controle op het verwerkersregister van het Onderwijsbestuur uitgevoerd. Het betreft gegevenssoorten van de classificatie IV.
Een Onderwijsbestuur is als verwerkersverantwoordelijke verantwoordelijk voor het ondertekenen van verwerkersovereenkomsten met Leveranciers. Bestuurder C ondertekent de verwerkersovereenkomst met Leverancier (J1) namens het Onderwijsbestuur. Dit leidt tot de registratie van de verwerkersovereenkomst voor de Leverancier in de component Verwerkersregister van de Registerhouder van het Onderwijsbestuur (J2). In het conceptueel model wordt gewerkt met twee Leveranciers: Leverancier A en Leverancier B. Beide Leveranciers beschikken over een Verwerkersovereenkomst dat geregistreerd is in de component Verwerkersregister van de Registerhouder van het Onderwijsbestuur.
Zodra een gegevenssoort van de classificatie V wordt geactiveerd door Applicatiebeheer A dan wordt er door de component Consentmanagement van Leverancier A de registratie van Leverancier B gecontroleerd (O1a) in het verwerkersregister van het Onderwijsbestuur. Indien Leverancier B beschikt over een geldige registratie dan wordt het proces vervolgd met stap O2a. Indien Leverancier B niet over een geldige registratie beschikt dan wordt er een melding gemaakt aan Applicatiebeheerder A dat er geen geldige verwerkersovereenkomst is geregistreerd.
Een Verwerkersovereenkomst kan ingetrokken worden door Bestuurder C (J3). Dit leidt ertoe dat het deactiveren van de gegevensuitwisseling wordt geïnitieerd bij Verzender. Op deze manier kan er nimmer een gegevensuitwisseling geactiveerd zijn waarvoor geen geldige verwerkersovereenkomst meer is.
Zodra de componenten Consentmanagement van zowel Leverancier A als Leverancier B de gegevensuitwisseling hebben geregistreerd is de gegevensuitwisseling actief en kan Ontvanger Leverancier B gegevens gaan ontvangen van Verzender Leverancier A. Op eenzelfde wijze is een gegevensuitwisseling gedeactiveerd als beide Leveranciers de gegevensuitwisseling als inactief hebben geregistreerd. In de componenten Consentmanagement van zowel Leverancier A als Leverancier B is voor respectievelijk Applicatiebeheerder A en B de status van een gegevensuitwisseling in te zien.
Proces: randvoorwaarden activeren gegevensuitwisseling
De Onderwijsorganisatie is verantwoordelijk voor een correcte registratie van het Onderwijsbestuur en al haar Onderwijsaanbieders (inclusief identifiers) bij de Registerhouder met de referentiecomponent Scholenregister.
Zowel Verzender als Ontvanger beschikken over een component Consentmanagement. De component Consentmanagement voldoet aan de eisen:
De component is strikt beveiligd en alleen toegankelijk voor Applicatiebeheerders van de onderwijsorganisatie.
Applicatiebeheerders worden door de component Consentmanagement met een betrouwbaarheidsniveau gemiddeld/hoog geïdentificeerd en geauthenticeerd.
De component voldoet aan de functionele, operationele en technische eisen zoals toegelicht op deze pagina.
Proces: randvoorwaarden voor controle registratie verwerkersovereenkomst
Om een gegevensuitwisseling van een gegevenssoort met classificatie IV te kunnen activeren is het van belang dat zowel Verzender als Ontvanger beschikken over een registratie voortkomend uit een getekende verwerkersovereenkomst van het Onderwijsbestuur.
De Onderwijsorganisatie is verantwoordelijk voor:
De keuze voor een Registerhouder met de referentiecomponent Verwerkersregister.
De volledige en correcte registratie van Verwerkersovereenkomsten die het Onderwijsbestuur heeft ondertekend met zowel Verzender als Ontvanger.
De Leverancier in de ondersteunende rol van Registerhouder met de component Verwerkersregister voldoet aan de volgende eisen:
Verwerkersovereenkomsten kunnen door een Onderwijsbestuur worden geregistreerd door een tekenbevoegd Bestuurder. Bestuurders worden door de component Verwerkersregister met een betrouwbaarheidsniveau hoog geïdentificeerd en geauthenticeerd.
Voor zowel Verzender als Ontvanger is het niet mogelijk om via het Verwerkersregister marktinformatie te verzamelen over contracten die andere Leveranciers hebben met Onderwijsbesturen. Dit is bedrijfsgevoelige informatie en is derhalve niet publiek beschikbaar. De component Verwerkersregister bevat technische maatregelen om het verzamelen van marktinformatie te voorkomen.
De component voldoet aan de functionele, operationele en technische eisen zoals toegelicht op deze pagina.
Proces: interactiespecificatie activeren gegevensuitwisseling
In Figuur 2 is het sequentiediagram voor het proces van activeren van een gegevensuitwisseling weergegeven. Het proces start bij de component Consentmanagement van de Verzender van de informatie. In dit voorbeeld is Leverancier A de verzender en ook de bron van de gegevens.
In de interactieanalyse zijn een aantal stappen voorzien van een kleurcode. Dit betreft de volgende situaties:
Classificatie IV: alleen van toepassing bij activeren van een gegevenssoort van classificatie IV.
INTEGRITEITSCONTROLE: alleen van toepassing bij een gegevenssoort waarbij de Ontvanger een integriteitscontrole wil toepassen.
Het proces van activeren bestaat uit de volgende stappen:
Stap | Toelichting |
|---|---|
1. | De Applicatiebeheerder die bekend is bij Verzender Leverancier A geeft in de component Consentmanagement van Leverancier A toestemming voor de gegevensuitwisseling met Ontvanger Leverancier B voor een specifieke gegevenssoort en een Onderwijsaanbieder. |
2. | Classificatie IV De component Consentmanagement van Leverancier A controleert of Leverancier A een registratie heeft vanuit Onderwijsbestuur van Onderwijsaanbieder voor het verwerken van gegevens. Hiervoor beschikt de component Consentmanagement in veel gevallen over een eigen register met verwerkersovereenkomsten die door Onderwijsbesturen aan Leverancier A zijn verstrekt. Als alternatief (2a) kan Leverancier A ook bij het verwerkersregister van het Onderwijsbestuur controleren of er een registratie is. In dit proces gaan we er vanuit dat Leverancier A beschikt over een geldige registratie van de verwerkersovereenkomst met het Onderwijsbestuur. |
3. | De component Consentmanagement van Leverancier A controleert de registratie van Leverancier B bij het verwerkersregister van Onderwijsbestuur van Onderwijsaanbieder. In dit proces gaan we er vanuit dat Leverancier B beschikt over een geldige registratie van de verwerkersovereenkomst met het Onderwijsbestuur. |
4. | De component Consentmanagement van Leverancier A registreert de activering van de gegevensuitwisseling aan de eigen zijde: Verzender, Leverancier A. |
5. | De component Consentmanagement van Leverancier A hanteert het transactiepatroon asynchrone uitwisseling om melding te maken bij Ontvanger Leverancier B van de activering van de gegevensuitwisseling. Allereerst wordt er een melding door de component Consentmanagement van Leverancier A naar de component Consentmanagement van Leverancier B gestuurd. In de melding wordt de activering van een gegevensuitwisseling vermeld:
De component Consentmanagement van Leverancier B reageert met een bevestiging ontvangst. De verwerking vindt asynchroon plaats. |
6. | De component Consentmanagement van Leverancier B registreert de activering van de gegevensuitwisseling voor de zijde van de Verzender (Leverancier A). |
7. | De component Consentmanagement van Leverancier B verstuurt een terugmelding naar de component Consentmanagement van Leverancier A dat de gegevensuitwisseling voor de zijde van de Verzender (Leverancier A) is geactiveerd met de status Accepted. |
8. | De componenten Consentmanagement van Leverancier A en Leverancier B kunnen nu aan hun eigen Applicatiebeheerders tonen dat de gegevensuitwisseling is geactiveerd aan de zijde van de Verzender. |
9. | Classificatie IV De component Consentmanagement van Leverancier B kan vervolgens controleren of ook aan de eigen zijde er een registratie van een verwerkersovereenkomst is vanuit het Onderwijsbestuur. Hiervoor beschikt de component Consentmanagement in veel gevallen over een eigen register met verwerkersovereenkomsten die door Onderwijsbesturen aan Leverancier B zijn verstrekt. Als alternatief (9a) kan Leverancier B ook bij het verwerkersregister van het Onderwijsbestuur controleren of er een registratie is. In dit proces gaan we er vanuit dat Leverancier B beschikt over een geldige registratie van de verwerkersovereenkomst met het Onderwijsbestuur. |
10. | INTEGRITEITSCONTROLE De component Consentmanagement van Leverancier B activeert de gegevensuitwisseling aan eigen zijde niet automatisch en wil graag bevestiging ontvangen van de eigen Applicatiebeheerder B. Allereerst wordt er een melding door de component Consentmanagement van Leverancier B naar de component Consentmanagement van Leverancier A gestuurd (10a). In de melding wordt de status Pending opgenomen. De component Consentmanagement van Leverancier A reageert met een bevestiging ontvangst. De component Consentmanagement van Leverancier B controleert de registratie (10b) van Leverancier A bij het verwerkersregister van Onderwijsbestuur van Onderwijsaanbieder. In dit proces gaan we er vanuit dat Leverancier A beschikt over een geldige registratie van de verwerkersovereenkomst met het Onderwijsbestuur. De component Consentmananagement van Leverancier B verifieert (10c) bij de eigen Applicatiebeheerder of er gegevens van gegevenssoort mogen worden ontvangen van Verzender Leverancier A voor Onderwijsaanbieder. De Applicatiebeheer bevestigt (10d) bij de component Consentmanagement van Leverancier B dat de gegevens ontvangen mogen worden. |
11. | De component Consentmanagement van Leverancier B registreert de activering van de gegevensuitwisseling voor de zijde van de Ontvanger (Leverancier B). |
12. | De component Consentmanagement van Leverancier B hanteert het transactiepatroon asynchrone uitwisseling om melding te maken bij Verzender Leverancier A van de registratie van de activering aan de zijde van de Ontvanger. Allereerst wordt er een melding door de component Consentmanagement van Leverancier B naar de component Consentmanagement van Leverancier A gestuurd. In de melding wordt de activering van een gegevensuitwisseling vermeld:
De component Consentmanagement van Leverancier A reageert met een bevestiging ontvangst. De verwerking vindt asynchroon plaats. |
13. | De component Consentmanagement van Leverancier A registreert de activering van de gegevensuitwisseling voor de zijde van de Ontvanger (Leverancier B). |
14. | De component Consentmanagement van Leverancier A verstuurt een terugmelding naar de component Consentmanagement van Leverancier B dat de gegevensuitwisseling voor de zijde van de Ontvanger (Leverancier B) is geactiveerd met de status Accepted. |
15. | De componenten Consentmanagement van Leverancier A en Leverancier B kunnen nu aan hun eigen Applicatiebeheerders tonen dat de gegevensuitwisseling is geactiveerd aan de zijde van zowel Verzender als Ontvanger. De gegevensuitwisseling is geactiveerd. |
Nadat er een gegevensuitwisseling is geactiveerd kan Ontvanger (Leverancier B) gegevens van gegevenssoort voor Onderwijsaanbieder gaan opvragen bij Verzender (Leverancier A).
Proces: Interactiespecificatie deactiveren gegevensuitwisseling
In Figuur 3 is het sequentiediagram voor het proces van deactiveren van een gegevensuitwisseling weergegeven. Het proces start bij de component Consentmanagement van de Verzender van de informatie. In dit voorbeeld is Leverancier A de verzender en ook de bron van de gegevens.
Het proces van deactiveren bestaat uit de volgende stappen:
Stap | Toelichting |
|---|---|
Het deactiveren van een gegevensuitwisseling kan verschillende triggers hebben: 1a. De Applicatiebeheerder die bekend is bij Verzender Leverancier A geeft in de component Consentmanagement van Leverancier A geen toestemming meer voor de gegevensuitwisseling met Ontvanger Leverancier B voor een specifieke gegevenssoort en een Onderwijsaanbieder. 1b. De verwerkersovereenkomst van het Onderwijsbestuur met Leverancier A is verlopen of ingetrokken. 1c. De verwerkersovereenkomst van het Onderwijsbestuur met Leverancier B is verlopen of ingetrokken. In dit proces gaan we er vanuit dat één van deze triggers aanleiding is geweest voor de deactiveren van de gegevensuitwisseling. In het geval van het verlopen of intrekken van een verwerkersoverreenkomst (triggers 1b of 1c) worden alle gegevensuitwisselingen tussen Leverancier A en Leverancier B gedeactiveerd. De stappen 2 tot en met 6 worden in dat geval voor de desbetreffende gegevensuitwisselingen uitgevoerd. | |
2. | De component Consentmanagement van Leverancier A registreert het deactiveren van de gegevensuitwisseling voor Verzender en Ontvanger. |
3. | De component Consentmanagement van Leverancier A hanteert het transactiepatroon asynchrone uitwisseling om melding te maken bij Verzender Leverancier B van het deactiveren van gegevensuitwisseling. Allereerst wordt er een melding door de component Consentmanagement van Leverancier A naar de component Consentmanagement van Leverancier B gestuurd. In de melding wordt het deactiveren van de gegevensuitwisseling vermeld:
De component Consentmanagement van Leverancier B reageert met een bevestiging ontvangst. De verwerking vindt asynchroon plaats. |
4. | De component Consentmanagement van Leverancier B registreert het deactiveren van de gegevensuitwisseling voor Verzender en Ontvanger. |
5. | De component Consentmanagement van Leverancier B verstuurt een terugmelding naar de component Consentmanagement van Leverancier A dat de gegevensuitwisseling voor de zijde van Verzender en Ontvanger is gedeactiveerd met voor zowel Verzender als Ontvanger de status Revoked. |
6. | De componenten Consentmanagement van Leverancier A en Leverancier B kunnen nu aan hun eigen Applicatiebeheerders tonen dat de gegevensuitwisseling is gedeactiveerd aan de zijde van zowel Verzender als Ontvanger. De gegevensuitwisseling is gedeactiveerd. |
Nadat er een gegevensuitwisseling is gedeactiveerd kan Ontvanger (Leverancier B) niet langer gegevens van gegevenssoort voor Onderwijsaanbieder opvragen bij Verzender (Leverancier A).
Gebruikersinterface Consentmangement: verplicht te tonen informatie
Binnen Edu-V wordt pre-competitief samengewerkt. De gebruikersinterface is een belangrijk onderdeel van de meerwaarde van de ene applicatie ten opzichte van de andere applicatie. Edu-V bevat vanwege dit competitieve karakter nagenoeg geen afspraken over de gebruikersinterface. Het (de)activeren van gegevensuitwisselingen binnen de component Consentmanagement is hierop een uitzondering.
Iedere Leverancier die gegevens deelt of ontvangt waarover een Onderwijsaanbieder zeggenschap heeft stelt een component consentmanagement beschikbaar. In deze component kan de Applicatiebeheerder van de Onderwijsorganisatie het volgende zien:
Alle Leveranciers die deelnemer zijn van Edu-V en die op basis van hun rol, gegevens kunnen ontvangen of delen.
Per leverancier, rol én gegevenssoort of de gegevensuitwisseling is geactiveerd vanuit de Verzender van de gegevens en de Ontvanger van de gegevens.
Het tijdstip waarop de gegevensuitwisseling is ge(de)activeerd.
Een indicator of de gegevensuitwisseling tweezijdig (Verzender én Ontvanger) is geactiveerd en de gegevensuitwisseling actief is.
In onderstaande tabel is een voorbeeld weergegeven van de te tonen informatie:
Verzender | Ontvanger | Gegevenssoort | Actief Verzender | Actief | Uitwisseling Actief |
Leverancier B | Leverancier A | Onderwijsdeelnemers Onderwijsmedewerkers SchoolVakken SchoolPeriodes SchoolLesgroepen | V | V | V |
Leverancier C | Leverancier A | Aanspraken | V | V | V |
Leverancier D | Leverancier A | Gebruiksgegevens | V | V | V |
Leverancier D | Leverancier A | Voortgangsgegevens | - | - | - |
Leverancier D | Leverancier A | Toetsresultaten | V | - | - |
Leverancier E | Leverancier A | Gebruiksgegevens | V | V | V |
Leverancier E | Leverancier A | Voortgangsgegevens | - | - | - |
Leverancier E | Leverancier A | Toetsresultaten | V | - | - |
Tabel 1. Voorbeeld overzicht van (de)actieve gegevensuitwisselingen
In dit voorbeeld ontvangt Leverancier A in de Business rol van Leermiddelenportaal:
Gegevens uit de leerlingadministratie (Onderwijsdeelnemers, Onderwijsmedewerkers, SchoolVakken, SchoolPeriodes en SchoolLesgroepen) van Leverancier B in de Business rol van Administratiesysteemaanbieder.
Aanspraken van Leverancier C in de Business rol van Leermiddelenshop.
Gebruiksgegevens van Leveranciers D en E in de Business rol van Leermiddelenaanbieder
Geen voortgangsgegevens van Leveranciers D en E in de Business rol van Leermiddelenaanbieder.
Nog geen toetsresultaten van Leveranciers D en E in de Business rol van Leermiddelenaanbieder vanwege respectievelijk:
De instemming moet nog handmatig bevestigd door de Applicatiebeheerder bij de ontvanger, zijnde Leverancier A
Een gegevensuitwisseling wordt binnen Edu-V gegeven op het niveau van Onderwijsaanbieder. In de component Consentmanagement kan een Leverancier ervoor kiezen om instemming op een hoger niveau te laten geven (bijvoorbeeld op Onderwijsbestuur). Dit leidt tot het genereren van instemmingen voor alle Onderwijsaanbieders die in de hiërarchie onder dit hogere niveau vallen.
Operationeel: periodiek controleren verwerkersregister
Trigger voor het deactiveren van een gegevensuitwisseling kan het verlopen of intrekken van een verwerkersovereenkomst vanuit het Onderwijsbestuur voor Verzender of Ontvanger zijn.
Verzender controleert periodiek of de verwerkersovereenkomst van Ontvanger waarbinnen de activering van de gegevensuitwisseling valt nog geldig is. Hiervoor is de volgende operationele afspraak gemaakt:
Verzender controleert minimaal dagelijks of verwerkersovereenkomsten nog geldig zijn.
In aanvulling hierop dragen Verzender en Ontvanger zorg voor het tijdig melding maken van het verlopen van een verwerkersovereenkomst bij hun eigen Applicatiebeheerder(s). Dit stelt de Applicatiebeheerder in om de verwerkersovereenkomst (indien gewenst) te verlengen.
Verzender en Ontvanger sturen minimaal 60 dagen, 30 dagen, 14 dagen en 3 dagen voordat een verwerkersovereenkomst verloopt een melding naar de Applicatiebeheerder.
Technisch: APIs
De interactieanalyse maakt gebruik van de volgende APIs:
Release notes
Deze uitwerking is gebaseerd op basis van de volgende stappen:
0.0.1: De documentatie is overgenomen vanuit het SEM Ecosysteem. De terminologie is in lijn gebracht met de gegevensdefinities van Edu-V.
0.0.2: De interactieanalyse voor het activeren en deactiveren van een gegevensuitwisseling is aangepast op basis van een controle via het mandatenregister. Tevens zijn randvoorwaarden voor het proces en operationele afspraken toegevoegd.
0.0.3: Interactieanalyse voor intrekken mandaat toegevoegd. Conceptueel model toegevoegd.
0.0.4: Op basis van feedback uit de bijeenkomst van de Architectenraad Edu-V van 12 mei 2023. is aangepast:
Conceptueel model aangepast
De classificaties I, II, III en IV van gegevenssoorten leiden tot een andere flow van dit proces. Mandaatcheck vindt alleen plaats voor classificatie IV.
Optionele integriteitscontrole toegevoegd aan de zijde van de Ontvanger.
Consent API verplaatst naar sectie APIs en draft documentatie toegevoegd.
Mandate API aangemaakt en als voorstel voor de POC de API van het OSR van Kennisnet opgenomen. Op een later moment kunnen we deze mogelijk verder definiëren.
Trade-off van relevante ontwerpprincipes geëxpliciteerd die gevalideerd dienen te worden in de POCs
0.0.5: In de bijeenkomst van de Architectenraad van 24 mei 2023 is de herziene uitwerking besproken.
Op basis van de feedback is de mandaatverificatie vanuit de Ontvanger toegevoegd in het geval de optionele integriteitscontrole. Voor de duidelijkheid is in het conceptueel model deze (optionele) integriteitscontrole als stippellijn weergegeven.
In de Architectenraad Edu-V is vastgesteld dat de huidige uitwerking een passende oplossing is voor het invulling geven aan regie op de gegevensuitwisseling voor Onderwijsorganisaties en het voldoen aan privacy en veiligheidseisen. Tegelijkertijd wordt ook aangegeven dat het uitvoeren van een mandaatverificatie op deze laag kan leiden tot een hogere toetredingsdrempel. Het is daarom van belang om in de POC ervaring op te doen met dit protocol en inzicht te krijgen of er onoverkomelijke drempels zijn om deze werkwijze te gaan implementeren.
Het finaliseren van de Consent en Mandate API is nog niet volledig gebeurt en blijft onderhanden werk voor de 100% specificatie die gepubliceerd wordt uiterlijk september 2023.
0.0.6: De Consent API en Mandate API zijn technisch uitgewerkt. Tevens is de benaming mandatenregister in de documentatie gewijzigd naar verwerkersregister. Dit is verwerkt in de figuren en de tekst.