Profiel Service

Bevat contactvoorkeuren en contactgegevens van een identificeerbaar persoon

Beperkingen

Inleiding

Deze sectie beschrijft de expliciete randvoorwaarden en beperkingen waarbinnen de Profiel Service wordt ontworpen en gerealiseerd. Doel is om gemaakte keuzes en context te borgen en later te kunnen herleiden waarom bepaalde opties zijn overwogen.

Overzicht

De volgende categorieën beperkingen zijn van toepassing. Per punt noemen we wat de beperking inhoudt, door wie/waarom deze is opgelegd en de impact op de architectuur.

Organisatorische en tijd/budget beperkingen

  • Betafase: lever een werkende beta met kernfunctionaliteit binnen beperkte tijd en middelen. Opgelegd door programma. Impact: focus op ‘must haves’; nice-to-haves. Systeem is uitbreidbaar richting productie, maar implementeert in de beta een minimale set.

Identiteit, authenticatie en autorisatie

  • Verplicht ondersteuning van federatieve authenticatie (DigiD, eHerkenning, eIDas) en OIDC/OAuth2 (ADR 0006). Opgelegd door rijksbeleid en interoperabiliteitseisen en benodigde gebruikersinformatie. Impact: eigen credential management is uitgesloten; integratie met IDP's bepaalt login-flows en token-handling. Voor betafase waarschijnlijk alleen eHerkenning.
  • Service-to-service-toegang verloopt via een API-gateway op basis van FSC (contracten) en FTV (tokens) uit het Federatief Datastelsel. Opgelegd door stelselafspraken. Impact: aanroeper-autorisatie (de organisatie achter de aanroep) is een infrastructurele en contractuele zaak; de Profiel Service voert daar geen eigen scope-mapping op uit. De service leidt de handelende dienstverlener af uit de OIN in de FTV-laag; de gateway geeft het gevalideerde FTV-token door (voorgeschreven door fsc-core §4.7.1.3) en de service hervalideert het. Voor de eindgebruikersidentiteit valideert de Profiel Service per request wél een meegestuurd subject-JWT (uitgegeven door DigiD of de eHerkenning-makelaar) tegen de JWKS van de uitgevende identity provider. Impact: de service kent een trustconfiguratie met geaccepteerde iss-waarden en JWKS-URLs, en is afhankelijk van de beschikbaarheid van die JWKS-endpoints. Zie §09 Infrastructuur, Authenticatie en autorisatie en de bijlage Logging, Toegang en Doelbinding.
  • Scope-gebaseerde autorisatie voor dienstverleners via FDS; scopes beperken toegang tot de minimaal noodzakelijke rechten (least privilege), bijvoorbeeld read-only waar van toepassing. Opgelegd door architectuurkader; scopes worden in FSC-contracten vastgelegd en op de gateway afgedwongen.

Juridisch en compliance

  • AVG toepasselijke logging/LDV-vereisten (ADR 0007, 0010). Opgelegd door wet- en regelgeving. Impact: auditeerbare gebeurtenissen, transparantie en bewaartermijnen zijn verplicht, persoonlijk identificeerbare informatie in logging vermijden.
  • Gebruik van KvK-gegevens conform betreffende API-voorwaarden. Impact: caching/bewaren van externe gegevens is ingezet, met beperkingen, en aan voorwaarden gebonden.

Technologiestack en standaarden

  • API’s in OpenAPI 3.0+, JSON over HTTPS; gebruik van standaard HTTP-protocollen. Impact: geen propriëtaire protocol keuzes.

Integraties en afhankelijkheden

  • Afhankelijkheid van externe stelsels/voorzieningen: IDP’s (DigiD/eHerkenning/eIDas), KvK, LDV/FDS. Opgelegd door functionele doelstellingen. Impact: beschikbaarheid en performance worden mede bepaald door externe SLA’s; timeouts, retries en circuit breakers zijn nodig. TODO Willen wij hiervoor circuit breakers gebruiken?

Deploy- en hostingkader

  • Uitrol op een standaard overheidscloud/infrastructuur met centrale voorzieningen (logging, monitoring, secret management). Opgelegd door hostingpartij/beheer. Impact: keuze voor specifieke PaaS-diensten of databases kan beperkt zijn; encryptie-at-rest en netwerkpolicies volgen platform-standaard.
  • Netwerkbeperkingen: alleen uitgaand verkeer naar whitelisted endpoints (bijv. KvK, IDP’s). Impact: service discovery en integraties moeten binnen deze restricties werken.

Ontwikkelproces en team

  • Uitgebreid team, maar gedeelde capaciteit met andere deelprojecten. Opgelegd door programma. Impact: prioritering op kerndoelen, gefaseerde oplevering. Automatisering (CI/CD, tests) is essentieel om snelheid/kwaliteit te borgen.

Data en migratie

  • Geen migratie van historisch profielmateriaal uit legacy. Opgelegd door scopebeperking. Impact: betafase start ‘greenfield’; koppeling aan bestaande datasets gebeurt via bronverificatie (b.v. KvK). Potentiële datamigratie naar productie wordt onderzocht in overleg met de betrokken dienstverleners, om te bepalen of deze technisch haalbaar is en of het meerwaarde biedt.

Waarom deze beperkingen ertoe doen

  • Beperken van keuzes versnelt ontwerp en implementatie, maar stuurt ook de architectuur: federatieve auth en FDS-scopes vereisen strikte scheiding van verantwoordelijkheden en dataminimalisatie; LDV/AVG dwingt auditability en logging-architectuur; hosting- en netwerkstandaarden bepalen integratiepatronen (API-gateway, TLS, secrets). Door deze constraints expliciet te maken, voorkomen we schijnbaar ‘vreemde’ keuzes achteraf.

Verwijzingen

  • ADR 0005 – AuditLog & EventSourcing
  • ADR 0006 – Federatieve authenticatie en autorisatie op basis van OIDC en eIDas
  • ADR 0007 – Logboek dataverwerking (LDV)
  • ADR 0009 – NL Design System
  • ADR 0010 – LDV implementatie