Verzender als Consent Consumer en Ontvanger met Consent API
- Koen Voermans
Titel | Verzender als Consent Consumer 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 als Consent Consumer 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 Leverancier A heeft geen eigen Consent API en opereert in deze implementatievariant als Consent Consumer. 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. | SHOULD Leverancier A hanteert het transactiepatroon Melding-bevestiging om de consentverleningen of -intrekkingen te melden bij Leverancier B. Hiervoor gebruikt Leverancier A een Client. |
6. | SHOULD Leverancier B bevestigt aan Leverancier A dat de consentverlening of -intrekking correct is ontvangen. |
7. | SHOULD 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 heeft geen eigen Consent API en opereert in deze implementatievariant als Consent Consumer. Periodiek bevraagt leverancier A de Consent API van leverancier B of er nieuwe consentbevestigingen (of -afwijzigngen) zijn. De referentiecomponent Consentmanagement van leverancier A hanteert het transactiepatroon Bevraging om de consentbevestigingen bij leverancier B op te vragen. Dit doet leverancier A met een Client. |
16. | COULD Leverancier B verwerkt de bevraging synchroon en haalt alle consentbevestigingen voor leverancier A op in de eigen Consentregistratie. |
17. | COULD De consentbevestigingen wordt door de Consent API van leverancier B als response gegeven op het request gedaan in stap 15. |
18. | COULD De response uit de vorige stap stelt leverancier A in staat om de eigen consentregistratie bij te werken. De nieuwe consentbevestigingen worden verwerkt. Indien er meerdere consentbevestigingen zijn dan worden alle wijzigingen verwerkt in de Consentregistratie. |
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 heeft geen eigen Consent API en opereert in deze implementatievariant als Consent Consumer. Periodiek verzamelt leverancier A alle consentverzoeken bij de relevante leveranciers. In dit voorbeeld is dat de Ontvanger leverancier B. De referentiecomponent Consentmanagement van leverancier A hanteert het transactiepatroon Bevraging om de consentverzoeken bij leverancier B op te vragen. Dit doet leverancier A met een Client. |
6. | Leverancier B verwerkt de bevraging synchroon en haalt alle consentverzoeken voor leverancier A op in de eigen Consentregistratie. |
7. | De consentverzoeken worden door de Consent API van leverancier B als response gegeven op het request gedaan in stap 5. |
8. | De response uit de vorige stap stelt leverancier A in staat om de eigen consentregistratie bij te werken. De nieuwe consentverzoeken worden toegevoegd. Indien er meerdere consentverzoeken zijn dan worden ze allen verwerkt in de Consentregistratie. |
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.