Bron en Afnemer met Consent API
- Koen Voermans
Titel | Bron en Afnemer 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 Bron en Afnemer met Consent API. De pagina bestaat uit de volgende paragrafen:
MUST COULD 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. | COULD Leverancier B beschikt in deze implementatievariant over een eigen Consent API. Hierdoor kan Leverancier B proactief op de hoogte worden gehouden van nieuwe consentregistraties. Leverancier A verzamelt periodiek alle nieuwe consentverleningen of intrekkingen voor leverancier B. Dit proces kan overigens ook direct na een nieuwe 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. |
8. | De applicatiebeheerders A MUST en B COULD kunnen nu in respectievelijk de Consent UI van de referentiecomponenten Consentmanagement van leveranciers A en B de status van een consent bekijken. |
9. | MUSTCOULD 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 COULD. |
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 door de applicatiebeheerder geïnitieerd worden. Dat is een implementatiekeuze. |
6. | Een nieuw consentverzoek wordt gemeld bij leverancier A. In het consentverzoek staat de gegevenssoort, 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 onderwijsaanbieder 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 krijgt na registratie van het consentverzoek een melding over het akkoord of de afwijzing. 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.