Review Ron #4
Description
Architectuurprincipes:
- ik mis nog security by design.
- is het een idee om ook scheiding van data en transport toe te voegen.
- onderste over BSN voor niet private partijen, hoort die niet in de eerste groep. Al is de wetgeving misschien anders, het gaat wel over een privacy-vraagstuk.
- Er zijn er een paar die heel direct zijn, bijvoorbeeld PO6. Ligt daar niet een bovenliggend principe aan ten grondslag dat we voldoen aan europese verordeningen zoals EUDI en SDG-OOTS? of aan wet- en regelgeving vanuit Europa en/of Nederland.
- Is PKI het stelsel waar we iedereen aan willen houden? En zit daar dan ook het gebruik van verfiable credentials in? Moeten we niet aangeven dat we waar mogelijk ruimte bieden aan decentrale oplossingen mits ze gekoppeld/vertaald kunnen worden met/naar centrale voorzieningen/standaarden? Eigenlijk wat bij ontwerpprincipe 1 ook al staat, maar dan vertaald naar een architectuurprincipe
- Algemeen: persoonlijk vind ik deze principes altijd arbitrair. voor het ontwerp van de architectuur voor de zorg op het gebied van generieke functies hadden wij 10 architectuurprincipes. Maar die waren wat algemener gesteld. Dit is een mooie lijst, daar kunnen we mee vooruit. Benieuwd wel of we het ontwerp van GBO 1.0 ook aan deze principes gaan toetsen.
Ontwerpprincipes:
- 1 t/m 4 helemaal mee eens.
- 5 gegevens bij de bron, maar wat is de bron. Ik weet dat ze met UBO bijvoorbeeld naar de BRP kijken, maar dat is een centraal register, maar kent ook de gemeentelijke variant (dus decentraal?). Helpt het bijvoorbeeld als we daar authentieke bron van maken?
- 08, pas toe of leg uit. Ik ken dat principe. Wat mijn ervaring wel is, in de zorg, is dat heel snel gebruik wordt gemaakt van leg uit en dat dat interoperabiliteit niet altijd bevordert.
- D10 zou ik dus ook een architectuurprincipe van maken als security by design.
- D12, is dat een ontwerpprincipe of is dat meer van toepassing op de doorontwikkel- en beheerfase. Hoe kun je daar in je ontwerp rekening mee houden? Voldoen aan de BIO2 bijvoorbeeld, wordt dan niet het ontwerpprincipe? is maar denklijn hoor.
Generieke Functies:
- De benaming komt niet overeen met het GBO Beschrijvend Document én de functies die we eerder hadden vastgesteld. Dat zijn ook subfuncties, maar die geven wel weer waarop we echt zaken moeten afspraken etc. Is er een reden waarom je daar niet voor kiest?
- Ik zou dus verwachten dat we een GF Identificatie hebben en dat we daarbinnen verbijzonderen welke actoren we identificeren en hoe we dat doen. Zoals bijvoorbeeld dat we organisaties en systemen identificeren, maar geen professionals. Maar wel burgers. Dus dan zou generieke functie 2 en 3 terugkomen in Identificatie. Het is maar hoe je het aanvliegt hoor. Ik vind die opbouw per subfunctie zelf wat concreter, maar wie ben ik.
[ ] Capabilities, zijn dit eigenlijk de afspraken en standaarden die we in het gremium GBO vast moeten gaan stellen? Lijkt mij wel toch?
[ ] Ik zie daar nog wel PP (polymorfe pseudonimisering) in terug. Daarover heb ik Peter-Jan en jou een FO gestuurd van een dienst die door iRealisatie (VWS) wordt gebouwd in samenwerking met BZK.
[ ] Ik zou bij Autorisatie de afspraak ook graag opgenomen willen zien dat we daarvoor vertrouwen op de certificaten van private partijen (en publiek) dat ze aan certificeringen voldoen. Zoals de ISO27001 bijvoorbeeld. Als je die certificering hebt dan zit het met de autorisatie-inrichting ook wel goed. Iets in die trend dan 😉