AuthZEN 1.0: waarom deze autorisatiestandaard een mijlpaal is voor dataspaces

In januari 2026 publiceerde de OpenID Foundation AuthZEN 1.0 - één open API tussen Policy Decision Point en Policy Enforcement Point. Waarom dit voor federatieve dataspaces een doorbraak is.

# AuthZEN 1.0: waarom deze autorisatiestandaard een mijlpaal is voor dataspaces

In een dataspace draait elke data-uitwisseling om één kernvraag: welke partij mag welke data opvragen, welke actie uitvoeren, onder welke voorwaarden, en voor hoe lang? Die vraag lijkt eenvoudig, maar vereist technisch een nauwkeurige evaluatie - elke keer opnieuw, voor elke uitwisseling. Jarenlang was de architectuur achter die evaluatie niet gestandaardiseerd. Dat veranderde in januari 2026.

## Beslissen en handhaven: twee rollen, één probleem

Die nauwkeurige evaluatie wordt uitgevoerd door een Policy Decision Point - kortweg PDP. De PDP beoordeelt een toegangsverzoek op basis van vastgelegde policies en geeft een beslissing: toegestaan of geweigerd, voor deze partij, op dit moment, voor deze data.

Maar beslissen is niet hetzelfde als handhaven. Dat doet een ander systeem: het Policy Enforcement Point (PEP). De PEP staat aan de toegangspoort - de API gateway, de connector, de applicatielaag - en laat een request door of blokkeert hem op basis van wat de PDP heeft besloten.

Die scheiding tussen beslissen en afdwingen is geen nieuw idee. Een van de vroegste formele standaarden voor access control, XACML, beschreef het PDP/PEP-model al in de vroege jaren 2000. Het probleem lag niet in de concepten. Het lag in de communicatie ertussen.

## De missing link: geen gemeenschappelijke taal

Elke leverancier van autorisatiesoftware implementeerde de interface tussen PDP en PEP op zijn eigen manier. Eigen request-formaat, eigen response-structuur, eigen foutcodes. Koppel je een policy engine aan een API gateway van een andere leverancier? Maatwerk. Vervang je een component? Opnieuw maatwerk. Wil je autorisatiebeslissingen over organisatiegrenzen heen laten werken? Vrijwel onmogelijk zonder aanzienlijke integratie-overhead.

Autorisatie in dataspaces vraagt om een gestandaardiseerde taal tussen systemen - en die taal was er tot voor kort niet.

## AuthZEN 1.0: één API voor PDP en PEP

In januari 2026 publiceerde de OpenID Foundation de finale versie van de Authorization API 1.0, beter bekend als AuthZEN. De standaard definieert één heldere REST API voor de communicatie tussen PEP en PDP.

Een evaluatieverzoek bevat vier elementen: Subject (wie vraagt toegang?), Action (wat wil die partij doen?), Resource (op welke data of dienst?) en optionele Context (tijdstip, locatie, apparaat). De PDP antwoordt met true of false, aangevuld met optionele context - bijvoorbeeld de reden van een weigering of een instructie voor aanvullende authenticatie.

Dit is een volledig geautomatiseerde evaluatie - geen mens in de loop. De policy is vooraf vastgelegd; de PDP past die toe op elk verzoek, in real time.

Een PDP beslist; een PEP handhaaft - AuthZEN geeft die scheiding een open, vendor-neutrale API. De standaard is transport-agnostisch en schrijft de interne werking van de PDP niet voor. Elke autorisatie-engine die de AuthZEN-interface implementeert, kan communiceren met elke PEP die dat ook doet. Autorisatiecomponenten worden daarmee uitwisselbaar, net als andere gestandaardiseerde bouwstenen in een dataspace.

In een dataspace op schaal worden per seconde tientallen of honderden API-aanroepen geëvalueerd. Een menselijke goedkeuringsflow werkt voor het vastleggen van een policy, niet voor het handhaven ervan bij elke transactie. De PDP/PEP-laag met AuthZEN is de geautomatiseerde motor die dat volume aankan - en een open standaard zorgt ervoor dat die motor niet aan één leverancier gebonden is.

## Waarom dit voor dataspaces specifiek een doorbraak is

In een gesloten systeem van één organisatie met één leverancier was vendor lock-in op autorisatiecomponenten acceptabel. In een dataspace liggen de verhoudingen anders.

Federatief data delen vereist dat autorisatiebeslissingen organisatiegrenzen kunnen oversteken. Een data provider heeft zijn eigen policy engine; een data consumer heeft zijn eigen enforcement laag. Die systemen moeten samenwerken - zonder dat iedere combinatie een apart integratietraject vereist.

AuthZEN maakt dat mogelijk. Een PDP van leverancier A kan beslissingen doorgeven aan een PEP van leverancier B, op basis van dezelfde API. Dat maakt data governance in een multi-organisatie context uitvoerbaar: de regels worden centraal beheerd, de handhaving is gedistribueerd, en de communicatie daartussen is gestandaardiseerd.

Een bijkomend voordeel is auditability. Gestandaardiseerde evaluatievragen en -antwoorden maken het mogelijk om toegangsbeslissingen consistent te loggen, ook over systeemgrenzen heen - een vereiste die in het kader van datasoevereiniteit steeds vaker ook juridisch afdwingbaar wordt.

## Marktadoptie als volgende stap

De publicatie van een finale standaard is één ding; marktadoptie is een ander. Voor organisaties die nu autorisatie-infrastructuur bouwen of vernieuwen, is AuthZEN-compatibiliteit een concreet selectiecriterium geworden. Het verschil tussen een systeem dat de standaard ondersteunt en een systeem dat dat niet doet, is het verschil tussen uitwisselbaarheid en lock-in.

Een open autorisatiestandaard maakt toegangsbeheer uitwisselbaar en controleerbaar - twee eigenschappen die in een federatieve dataspace geen nice-to-have zijn, maar een architecturele voorwaarde.

Poort8 volgt de adoptie van AuthZEN actief. NoodleBar's Access & Authorization module is gebouwd op het PDP/PEP-principe dat AuthZEN nu als open standaard vastlegt. Ben je benieuwd hoe toegangsbeheer en data governance samenkomen in een concrete dataspace-implementatie? We denken graag mee.