Bron met Consent API en Afnemer als Consent Consumer
- Koen Voermans
Titel | Bron met Consent API en Afnemer als Consent Consumer |
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 Bron met Consent API en Afnemer als Consent Consumer. De pagina bestaat uit de volgende paragrafen:
MUSTSHOULD Proces: verlenen of intrekken van consent bij Bron
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 Bron van de gegevens. In dit voorbeeld is Leverancier A de Bron.
Het proces bestaat uit de stappen zoals hieronder toegelicht:
Stap | Toelichting |
|---|---|
| MUST De applicatiebeheerder A die bekend is bij Bron leverancier A geeft in de Consent UI van de referentiecomponent Consentmanagement van leverancier A toestemming voor de gegevensuitwisseling met Afnemer 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 B heeft geen eigen Consent API en opereert in deze implementatievariant als Consent Consumer. Periodiek bevraagt leverancier B de Consent API van leverancier A of er nieuwe verleningen of intrekkingen van consent zijn voor leverancier B. De referentiecomponent Consentmanagement van leverancier B hanteert het transactiepatroon Bevraging om de gewijzigde consentstatus bij leverancier A op te vragen. Dit doet leverancier B met een Client. |
5. | SHOULD Leverancier A verwerkt de bevraging synchroon en haalt alle gewijzigde consentregistraties (nieuwe verleningen of intrekkingen) voor leverancier B op in de eigen Consentregistratie. |
6. | SHOULD De gewijzigde consentregistraties wordt door de Consent API van leverancier A als response gegeven op het request gedaan in stap 4. |
7. | SHOULD De response uit de vorige stap stelt leverancier B in staat om de eigen consentregistratie bij te werken. De nieuwe consentverleningen worden toegevoegd en de intrekkingen worden gewijzigd in status naar inactief. Indien er meerdere consentregistraties gewijzigd zijn dan worden alle wijzigingen verwerkt in de Consentregistratie. |
8. | 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. |
9. | MUSTSHOULD De Consent UI haalt de laatste status op uit de eigen Consentregistratie. |
10. | In de Consent UI wordt de laatste status weergegeven aan de applicatiebeheerders A MUST of B SHOULD. |
COULD Proces: consentverzoek vanuit Afnemer
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 Afnemer van de gegevens. In dit voorbeeld is Leverancier B de Afnemer.
Het proces bestaat uit de stappen zoals hieronder toegelicht:
Stap | Toelichting |
|---|---|
| De applicatiebeheerder B die bekend is bij Afnemer leverancier B doet in de Consent UI van de referentiecomponent Consentmanagement van leverancier B een verzoek voor de gegevensuitwisseling vanuit de Bron 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 Afnemer. |
5. | Leverancier B verzamelt periodiek alle consentverzoeken en verstuurt deze naar de leveranciers. In het voorbeeld worden de consentverzoeken voor leverancier A verzameld. Dit proces kan overigens ook direct na indienen van het consentverzoek geïnitieerd worden. Dat is een implementatiekeuze. |
6. | Een nieuw consentverzoek wordt gemeld bij leverancier A. In het consentverzoek staat de gegevensdienst, leverancier A en de onderwijsaanbieder. |
7. | Leverancier A meldt bij leverancier dat het consentverzoek correct ontvangen is. |
8. | Het consentverzoek wordt door leverancier A verwerkt in de eigen 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. |
 | Leverancier B kan te alle tijden via het opvragen van de consentstatus inzicht krijgen of het consentverzoek reeds is verwerkt. Dit proces verloopt gelijk aan een normale consentverlening of intrekking zoals toegelicht in de vorige paragraaf. Het proces vervolgt dan vanaf stap 4. |
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.