Van 'wie ben je' naar 'wat mag je':
Vastleggen wie welke data mag gebruiken. Geef als organisatie gecontroleerde toestemming om data en datadiensten te gebruiken.
Rol Fluxility: architectuur, ontwikkeling en doorontwikkeling
Domein: autorisatie en toegang binnen ketensamenwerking
Gerelateerd aan: DSGO, Participantenregister, datadiensten
Leg vrijblijvend jouw casus voor
Bekijk alle DigiGo projecten
Bekend zijn staat niet gelijk aan overal bij mogen
Zodra vaststaat wie er communiceert (participantenregister), komt de volgende vraag: wat mag die partij eigenlijk doen? Want ook als een organisatie bekend is binnen het stelsel, betekent dat nog niet dat zij alle data mag gebruiken. En het betekent zeker niet dat iedereen binnen die organisatie overal bij mag.
Daar komt het autorisatieregister in beeld. Daarin wordt vastgelegd wie toestemming geeft aan wie, voor welke data of datadienst, en welke actie daarbij is toegestaan.
Zo gezegd klinkt het eenvoudig. In de praktijk van ketensamenwerking wordt het al snel complex. Data is vaak niet van de partij die het beheert, maar van de eigenaar, bijvoorbeeld de eigenaar van een pand. Die moet toestemming geven aan de ene partij om gegevens over te dragen aan de andere. En daarbovenop spelen medewerkers, vestigingen, certificaten en aanvullende voorwaarden een rol.
Vragen over Formulieren-App👇🏼
Een autorisatieregister legt vast wie toestemming heeft om bepaalde data of datadiensten te gebruiken.
In de basis is dat één regel: partij A geeft partij B toestemming voor een bepaald document of een bepaalde dienst. Klopt B later aan, dan controleert het systeem: is dit van A, en heeft A toestemming gegeven aan B? Zo ja, dan gaat de deur open.
Omdat het niet bij "A en B geven elkaar toestemming" blijft.
Toestemming kan worden doorgezet. A geeft B toestemming in brede zin, en staat daarbij toe dat B op zijn beurt toestemming geeft aan onderaannemer C, voor data die eigenlijk van A is.
C klopt dan aan voor gegevens van A, op basis van een recht dat via B is doorgegeven. Dat mag alleen als B zelf gemachtigd is om toestemming door te zetten.
Technisch blijft elke regel simpel: "A geeft toestemming aan B". Maar in werkelijkheid ontstaat een boom die je helemaal moet doorlopen om één verzoek te beoordelen.
Daar bovenop kun je voorwaarden hangen (bijvoorbeeld een vereist certificaat) en verschilt het niveau: bedrijf, medewerker of een systeem dat namens een bedrijf aanklopt. Die combinatie maakt het complex.
Het participantenregister beantwoordt de vraag wie er aanklopt. Het autorisatieregister beantwoordt de vraag wat die partij vervolgens mag. Het eerste is herkenning, het tweede is toestemming. Ze werken samen: pas als vaststaat wie iemand is, kun je betrouwbaar bepalen waar hij bij mag.
Meer over het participantenregister
Of meteen aan de slag gaan!
Eén model, dat elke laag van de keten aankan
De kracht van het register zit in een eenvoudig grondprincipe dat veel situaties dekt. In alle gevallen komt het neer op: een eigenaar geeft toestemming, en die toestemming wordt vastgelegd als een controleerbare regel.
Dat principe werkt op verschillende niveaus:
- Bedrijf naar bedrijf. Organisatie A staat toe dat organisatie B bepaalde gegevens opvraagt. Kan B aantonen dat zij dat bedrijf is, dan krijgt zij toegang.
- Op medewerkerniveau. Medewerkers van een bepaald bedrijf mogen een bepaalde handeling uitvoeren.
- Op systeemniveau. Er komt geen persoon aan te pas: de software van een bedrijf klopt aan en wordt via een e-seal bevestigd als dat bedrijf.
- Met toestemming van de eigenaar. Zoals bij de huisarts en de apotheek: de eigenaar van de gegevens geeft toestemming dat de ene partij ze bij de andere mag opvragen.
Waar het echt interessant wordt
Waar het echt interessant wordt, is het doorzetten van toestemming door de gehele keten. A staat ook toe dat B de data mag ontsluiten aan andere partijen. Hiervoor is B gemachtigd door A. Hierdoor ontsluit B data (van A) voor C.
Het gaat niet meer alleen over het delen van data tussen twee partijen, maar over het ontsluiten van data binnen een hele keten van samenwerkende bedrijven en onderaannemers. Data vloeit van en naar organisaties die hiertoe zijn geautoriseerd én geïdentificeerd.
Daar bovenop legt elke autorisatieregel vast welke actie is toegestaan. Inzien is iets anders dan aanpassen of doorsturen. Modeltechnisch blijft elke regel gelijk, maar in werkelijkheid ontstaat een vertakte structuur die je volledig moet doorlopen om een verzoek betrouwbaar te beoordelen.
Inhoudelijk modelleren van een register
Dit is geen register dat we voor één partij hebben gebouwd. Een autorisatieregister is een onderdeel van het DSGO-stelsel, en wij bouwen het voor meerdere partijen binnen dat stelsel.
Daardoor houden we één uniforme aanpak aan voor hoe we toestemming modelleren en waarmee we die vastleggen.
Dat is het soort onderdeel dat pas echt lastig wordt wanneer je het inhoudelijk goed wilt modelleren, en niet alleen technisch wilt laten werken.
De relatie met DSGO en digiGO?
Betrouwbaar data delen in de gebouwde omgeving vraagt om meer dan een koppeling. Het vraagt om afspraken over wie welke data mag gebruiken en om software die die afspraken kan uitvoeren. Autorisatie is daarin een kernvraagstuk, naast deelname en herkenning.
Het autorisatieregister is daarmee een vast onderdeel van het stelsel, en niet iets van één partij. Dat sluit aan bij de manier waarop het DSGO datadeling in de keten mogelijk maakt.
Een autorisatievraag is daarbij nooit alleen technisch. Ze is ook inhoudelijk en organisatorisch:
- Wie is de datarechthebbende?
- Welke partij biedt de datadienst aan?
- Gaat het om een bedrijf, een medewerker of een systeem?
- Is er toestemming nodig van meerdere partijen?
- Mag een partij de toestemming doorzetten?
- Welke actie mag worden uitgevoerd?
Lees meer over ons partnerschap met digiGO
→ Of neem contact op voor jouw vraagstuk
Wat levert dit op?
Wanneer toestemming eenduidig is vastgelegd en controleerbaar is, kan data door de keten stromen zonder handmatige tussenstappen.
Dat kan leiden tot:
✓ Gecontroleerde toegang tot data en datadiensten
✓ Onderscheid tussen inzien, aanpassen en doorsturen
✓ Juridisch vastgestelde overeenkomsten
Meer projecten binnen het digiGO-stelsel
De bijdrage van Fluxility: logica modelleren, daarna bouwen
Fluxility ontwikkelt een autorisatieregister voor meerdere partijen binnen het DSGO en denkt mee over de structuur eronder. Omdat we het voor verschillende partijen in de sector bouwen, herkennen we sneller waar toestemming in de praktijk stukloopt.
Onze rol bestaat onder andere uit:
- het modelleren van toestemming op bedrijfs-, medewerker- en systeemniveau
- het uitwerken van toestemming: B die C toegang geeft tot data van A
- het respecteren van de data-eigenaar wanneer een ander de data beheert
- het vastleggen welke actie bij welke autorisatieregel hoort
- het technisch vertalen van die logica naar een betrouwbaar register
- het aanhouden van één uniforme aanpak over meerdere partijen binnen het stelsel
Daarom kijken we bij Fluxility altijd naar drie lagen:
Welke data wordt gedeeld? Wie is eigenaar? Wie mag wat doen? Welke uitzonderingen zijn er? En welke afspraken moeten juridisch of organisatorisch goed worden vastgelegd?
Welke API's, standaarden, authenticatiemiddelen en datamodellen zijn nodig? Hoe sluit de oplossing aan op bestaande systemen? En hoe zorgen we dat de software onderhoudbaar blijft?
Hoe gebruiken organisaties de oplossing straks echt? Welke stappen moeten logisch aanvoelen? Waar kan automatisering helpen? En waar is juist extra controle nodig?
Toestemming die klopt op papier en werkt in de praktijk
Werk jij aan een register, datadienst of samenwerking waarbij meerdere partijen toestemming moeten regelen? Wij helpen die logica goed te modelleren en betrouwbaar te bouwen.
Leg je datavraagstuk aan ons voor
Je hoeft nog geen volledig uitgewerkt technisch plan te hebben. We brengen eerst de gebruikers, gegevens, standaarden en koppelingen in kaart.
Plan een vrijblijvende kennismaking met Dennis of Wouter.
Ik wil graag een afspraak maken
→ Of eerst al onze digiGO-projecten bekijken
Senior developer & Partner
Wouter Klein Heerenbrink
"Goede software begint bij een stevige basis. Jij wilt iets dat werkt, vandaag én over een paar jaar.
Geen ducttape oplossingen, maar een solide architectuur waarop je kunt bouwen."