Als developer wil ik voor het Instemming component de ICO standaard gebruiken

[matthiasoliveiro]

Zodat het component breder te gebruiken is en beter aansluit bij internationale standaarden.

Voor het opstellen van de gegevens die we voor een instemming nodig hebben stellen wij een ICO standaard voor. Deze richtlijn laat een minimale standaard zien om instemming op te slaan.
ICO: https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/consent/how-should-we-obtain-record-and-manage-consent/

Taken lijst todo:

• Architectuur afstemming
• Ontwerp gegevens model
• Realisatie
• Postman testscripts
• Documentatie Redoc
• Testscripts aan leveren aan testvoorziening
• Voorbeeld implementatie
• Code opleveren in Utrecht repo

Checklist Definition of done

• Oas documentatie
• Postman scripts (test scripts)
• Aangeleveren testscripts aan de api test voorziening
• Containers moeten gepubliceert zijn
• Gereviewd op de design decisions
• Voorbeeld implementatie beschikbaar
• Redoc moet beschikbaar zijn
• Documentatie moet beschikbaar zijn op github-pages
• NLX integratie moet werken

[rubenvdlinde]

De bovenstaande tekst gaat natuurlijk specifiek in op consent in de context van GDPR en algemene voorwaarden. Daar waar wij het meer zien in de context van handelingen, toegang en machtigingen.

Het basis principe blijft echter overeind staan, en de richtlijnen zijn breder toepasbaar. We hebben een “instemming” die bestaat uit vier delen.
1- Iets of iemand die toestemming geeft
2- Iets of iemand die toestemming ontvangt
3- Het doel waarvoor deze toestemming is gegeven
4- Hetgeen waarvoor toestemming is gegeven.

Daarnaast hebben we natuurlijk wat algemeen dingen nodig zo als een id, tijdelijke gegevens in het geval van een verzoek tot instemming, de status van de instemming en wat gegevens rondom het afgeven van de instemming (methode, ip, tijs etc). Als laatste zou het zinnig zijn om een optionele duratie mee te kunnen geven aan een instemming.

Het mooi is dat dit een relatief simpel datamodel oplevert waar we wel een hoop kanten mee op kunnen, van algemene voorwaarden, cookie instemmingen tot aan getuigen, partners, contracten, belasting aangiften etc. Met andere woorden dit component heeft groei potentieel.

Voor nu echter de focus houden op het omzetten van huidige component van 1 object naar de bovenstaande 4 objecten met als DOD getuigen en partners.

[matthiasoliveiro]

• Test voorziening geeft niet thuis en kunnen we niet afronden.
• Github pages is een strech goal en een nice to have, we hebben het nu ander opgelost via de readme (zie tabel)
• NLX hebben we een andere afspraak voor gemaakt en wordt los opgepakt. Het component is NLX ready maar het staat nog niet aan dat is een andere story

[CMasselink]

Wat is precies de review vraag? Is de ico werkwijze inderdaad geïmplementeerd in de spec?
Kleine opmerking bij de spec: bij requester staat in de documentatie dat hier middels een bsn naar een persoon verwezen kan worden. Ik neem aan dat we hier niet een BSN gaan registreren maar de resource identifier/uri van die persoon?

[matthiasoliveiro]

@CMasselink "Is de ico werkwijze inderdaad geïmplementeerd in de spec?"ja dat is de vraag.

Op dit moment registreren we het BSN maar inderdaad je zou hier een uri willen loggen. Dat zit er nog niet in maar als dat wel moet dan moet deze even terug naar todo

[CMasselink]

Laten we nu simpel een URI mogelijk maken voor persoon

[rubenvdlinde]

Even gesized, dit kan maar vraagt wat wijzigingen in de huwelijksplanner-ui bl. Omdat we dan personen op een andere manier gaan koppelen. Dus daar moeten we even kijken wat de gevolgen zijn en dus ready maken.

Later deze morgen even prioriteren.