Verzender en Ontvanger met Consent API
- Koen Voermans
Titel | Verzender en Ontvanger met Consent API |
Status | In ontwikkeling ROSA-Architectuurscan BEsluitvorming implementatie in beheer |
Versie | 0.9.0 |
Datum | 27 Mei 2024 |
Auteur | Architectenraad Edu-V |
Acties | Geen openstaande acties |
Deze pagina beschrijft de functionele specificatie van de werking van de implementatievariant Verzender en Ontvanger met Consent API. De pagina bestaat uit de volgende paragrafen:
Must SHOULD COULD Proces: verlenen of intrekken van consent bij Verzender
In Figuur 1 is het sequentiediagram voor het proces van verlenen of intrekken van consent weergegeven. Het proces start bij de component Consentmanagement van de Verzender van de gegevens. In dit voorbeeld is Leverancier A de Verzender.
Bevestiging door Ontvanger
Bij een Verzender en Ontvanger is het van belang dat de consentregistratie van de Ontvanger bijgewerkt is. De Ontvanger heeft immers de API waar de Verzender de gegevens naar toe gaat sturen. Indien de consentverlening niet correct is verwerkt zal de Verzender bij een poging om gegevens naar de Ontvanger toe te sturen stuiten op een foutmelding 403 Unauthorized.
Om deze reden is het sequentiediagram van deze implementatievariant uitgebreid met een bevestiging door de Ontvanger. Deze bevestiging kan automatisch gegeven worden door de Ontvanger. Als optie kan de Ontvanger ook de applicatiebeheerder vragen om met de consentregistratie akkoord te gaan. In dat geval wordt er een bevestigingverzoek gestuurd naar applicatiebeheerder B.
Het proces bestaat uit de stappen zoals hieronder toegelicht:
Stap | Toelichting |
|---|---|
| MUST De applicatiebeheerder A die bekend is bij Verzender leverancier A geeft in de Consent UI van de referentiecomponent Consentmanagement van leverancier A toestemming voor de gegevensuitwisseling met Ontvanger leverancier B voor een specifieke gegevensdienst en een Onderwijsaanbieder. |
2. | MUST De referentiecomponent Consentmanagement registreert de verlening (of intrekking) van de toestemming in een eigen Consentregistratie. |
3. | MUST De applicatiebeheerder A ziet in de Consent UI dat de consentverlening of -intrekking succesvol is geregistreerd aan de zijde van de Bron. |
4. | SHOULD Periodiek verzamelt leverancier A alle consentverleningen of -intrekkingen en gaat deze melden bij de relevante leveranciers. In dit voorbeeld is dat de Ontvanger leverancier B. Dit proces kan overigens ook direct na indienen van een consentverlening of -intrekking geïnitieerd worden. Dat is een implementatiekeuze. |
5. | COULD Leverancier A hanteert het transactiepatroon Melding-bevestiging om de consentverleningen of -intrekkingen te melden bij Leverancier B. Hiervoor gebruikt Leverancier A een Client. |
6. | COULD Leverancier B bevestigt aan Leverancier A dat de consentverlening of -intrekking correct is ontvangen. |
7. | COULD De melding uit de vorige stap stelt leverancier B in staat om de eigen consentregistratie bij te werken. Een nieuwe consentverlening wordt toegevoegd en een intrekking wordt gewijzigd in status naar inactief. |
 | Leverancier B heeft nu de optie om de consentverlening direct te activeren aan de eigen zijde of om eerst om bevestiging te vragen bij Applicatiebeheerder B van de onderwijsaanbieder. De stappen 8-14 zijn in het laatste geval van toepassing. |
8. | COULD Applicatiebeheerder B van de onderwijsaanbieder waarvoor een consentverlening is ingediend wordt via een notificatie (in het voorbeeld een e-mailnotificatie) op de hoogte gebracht van een nieuw bevestigingsverzoek. |
9. | COULD Applicatiebeheerder B van de onderwijsaanbieder opent de Consent UI en navigeert naar de bevestigingsverzoeken. |
10. | COULD De bevestigingsverzoeken voor de onderwijsaanbieder worden verzameld uit de consentregistratie. |
11. | COULD De bevestigingsverzoeken worden getoond aan applicatiebeheerder B. |
 | Stappen 12-14 worden uitgevoerd voor alle bevestigingsverzoeken die er op dat moment zijn voor de onderwijsaanbieder. |
12. | COULD Applicatiebeheerder A geeft akkoord op het bevestigingsverzoek of wijst deze af. |
13. | COULD Het akkoord of de afwijzing wordt geregistreerd in de consentregistratie. |
14. | COULD De Applicatiebeheerder ziet in de Consent UI dat het akkoord of de afwijzing is geregistreerd. |
15. | COULD Leverancier A beschikt in deze implementatievariant over een eigen Consent API. Hierdoor kan Leverancier A proactief op de hoogte worden gehouden van nieuwe consentregistraties. Leverancier B verzamelt periodiek alle nieuwe consentbevestigingen (of -afwijzingen) voor leverancier B. Dit proces kan overigens ook direct na een nieuwe consentbevestiging geïnitieerd worden. Dat is een implementatiekeuze. |
16. | COULD Leverancier B hanteert het transactiepatroon Melding-bevestiging om een nieuwe consentbevestiging te melden bij Leverancier A. Hiervoor gebruikt Leverancier B een Client. |
17. | COULD Leverancier A bevestigt aan Leverancier B dat de nieuwe consentbevestiging correct is ontvangen. |
18. | COULD De melding uit stap 16 stelt leverancier A in staat om de eigen consentregistratie bij te werken. De nieuwe consentbevestiging wordt verwerkt. |
19. | De applicatiebeheerders A MUST en B SHOULD kunnen nu in respectievelijk de Consent UI van de referentiecomponenten Consentmanagement van leveranciers A en B de status van een consent bekijken. |
20. | MUSTSHOULD De Consent UI haalt de laatste status op uit de eigen Consentregistratie. |
21. | In de Consent UI wordt de laatste status weergegeven aan de applicatiebeheerders A MUST of B SHOULD. |
could Proces: Consentverzoek vanuit Ontvanger
In Figuur 2 is het sequentiediagram voor het doen van een consentverzoek. In dit geval start het proces is in de referentiecomponent Consentmanagement van de Ontvanger van de gegevens. In dit voorbeeld is Leverancier B de Ontvanger.
Het proces bestaat uit de stappen zoals hieronder toegelicht:
Stap | Toelichting |
|---|---|
| De applicatiebeheerder B die bekend is bij Ontvanger leverancier B doet in de Consent UI van de referentiecomponent Consentmanagement van leverancier B een verzoek voor de gegevensuitwisseling vanuit de Verzender leverancier A voor een specifieke gegevensdienst en een Onderwijsaanbieder. |
2. | De referentiecomponent Consentmanagement registreert dit consentverzoek in de eigen Consentregistratie. |
3. | De Consent UI ontvangt een bevestiging dat het consentverzoek is geregistreerd. |
4. | De applicatiebeheerder B ziet in de Consent UI dat het consentverzoek succesvol is geregistreerd aan de zijde van de Ontvanger. |
5. | Leverancier A beschikt in deze implementatievariant over een eigen Consent API. Hierdoor kan Leverancier A proactief op de hoogte worden gehouden van nieuwe consentregistraties. Leverancier B verzamelt periodiek alle nieuwe consentverzoeken voor leverancier B. Dit proces kan overigens ook direct na een nieuw consentverzoek geïnitieerd worden. Dat is een implementatiekeuze. |
6. | Leverancier B hanteert het transactiepatroon Melding-bevestiging om een nieuw consentverzoek te melden bij Leverancier A. Hiervoor gebruikt Leverancier B een Client. |
7. | Leverancier A bevestigt aan Leverancier B dat het nieuwe consentverzoek correct is ontvangen. |
8. | De melding uit stap 6 stelt leverancier A in staat om de eigen consentregistratie bij te werken. Het nieuwe consentverzoek wordt toegevoegd. |
9. | Applicatiebeheerder A van de onderwijsorganisatie waarvoor een consentverzoek is ingediend wordt via een notificatie (in het voorbeeld een e-mailnotificatie) op de hoogte gebracht van een nieuw consentverzoek. |
10. | Applicatiebeheerder A van de onderwijsaanbieder opent de Consent UI en navigeert naar de consentverzoeken. |
11. | De consentverzoeken voor de onderwijsaanbieder worden verzameld uit de consentregistratie. |
12. | De consentverzoeken worden getoond aan applicatiebeheerder A. |
 | Stappen 13-15 worden uitgevoerd voor alle consentverzoeken die er op dat moment zijn voor de onderwijsaanbieder. |
13. | Applicatiebeheerder A geeft akkoord op het consentverzoek of wijst deze af. |
14. | Het akkoord of de afwijzing wordt geregistreerd in de consentregistratie. |
15. | De Applicatiebeheerder ziet in de Consent UI dat het akkoord of de afwijzing is geregistreerd. |
 | Na verwerken van het consentverzoek vervolgt een melding vanuit leverancier A dat er consent is verleend. Dit proces verloopt gelijk aan een normale consentverlening of intrekking zoals toegelicht in de vorige paragraaf. Het proces vervolgt dan vanaf stap 4. In het geval van een consentverzoek is de bevestiging vanuit de Ontvanger reeds vooraf geregistreerd. In de praktijk zullen de stappen 12-14 in dat geval overgeslagen worden. |
Technisch: Consent API
De interactieanalyses maakt gebruik van de Consent API.
Release notes
Deze uitwerking is gebaseerd op basis van de volgende stappen:
0.0.1: Interactieanalyses zijn uitgewerkt voor deze implementatievariant.
0.0.2: De pagina is besproken tijdens de bijeenkomst van de Architectenraad Edu-V en is gereed voor de ROSA-architectuurscan.
0.0.3: Wijzigingsverzoek voor optioneel maken van de uitwisseling van consentgegevens is besproken in de Architectenraad Edu-V en heeft geleid tot een wijziging. Er is duidelijker in de specificatie aangegeven welke onderdelen MUST, SHOULD en COULD zijn.
0.9.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.
De afspraken m.b.t. Regie op gegevens wordt tijdens de eerste release geïmplementeerd. Na een succesvolle implementatie wordt de uiteindelijke 1.0.0 versie vastgesteld.