Publish Box goes here

Profiel en standaarden

Profiel en standaarden

Deze uitwerking combineert standaardmechanismen met Nederlandse interoperabiliteitskeuzes. Om te voorkomen dat referentiecode onbedoeld norm wordt, gebruikt de guide vier statuscategorieën:

Status	Betekenis
Standaardbasis	gedrag of formaat dat uit een externe standaard wordt overgenomen
Profielregel	concrete afspraak die deze systemen onderling nodig hebben
Referentiekeuze	veilige invulling in code en workbench, niet automatisch normatief
Open ontwerpkeuze	onderwerp waarvoor productie- of landelijke governance ontbreekt

Herkomst per onderdeel

Onderdeel	Basis	Status in deze guide
Actoren en token/resource-transacties	IHE IUA ITI-71/ITI-72	standaardbasis, richtinggevend
Client credentials	OAuth 2.0	standaardbasis
JWT clientauthenticatie	RFC 7523	standaardbasis plus profielclaims
Assertion-aud gelijk aan AS issuer	FAPI 2.0	standaardbasis
RAR authorization_details	RFC 9396	standaardbasis
RAR-type nl-gis-v1 en velden	Nederlandse uitwerking	profielregel in wording
JWT en JWKS	RFC 7519 en RFC 7517	standaardbasis
Vereiste access-tokenclaims	Nederlandse uitwerking	profielregel in wording
DPoP	RFC 9449	standaardbasis plus verplichte toepassing
mTLS-clientauthenticatie	RFC 8705 en PKI-principes	profielregel in wording
Hoogwaardige API-maatregelen	FAPI 2.0	richtinggevend
URA en organisatieregistratie	Nederlands zorgkader	profielconcept, governance open
Client valideert access token	Nederlandse uitwerking	expliciete profielregel in wording
Certificaatgebonden organisatiesleutels	VWS/Twiin-conceptmemo	conceptkeuze; productieprofiel open
P-256, ES256 en concrete termijnen	repository	referentiekeuze
Lokale directory, demo-CA en in-memory stores	repository	referentiekeuze

Waarom niet ongewijzigde IHE IUA

IHE IUA behandelt het access token bij de authorization client als opaque en ITI-72 beschrijft Bearer-gebruik. Deze uitwerking laat het clientsysteem juist:

• het JWT openen en de handtekening via vertrouwde JWKS controleren;
• de geaccepteerde RAR als beveiligingsinput gebruiken;
• issuer, doelorganisatie, location en audience onderling verbinden;
• een DPoP-gebonden token via het DPoP-schema verzenden.

Dat zijn wezenlijke profieltoevoegingen. “IUA-geïnspireerd” beschrijft de herkomst van rollen en transacties, niet volledige IUA-conformiteit.

Spanning rond client-side tokenvalidatie

RFC 9068 instrueert clients access tokens niet te inspecteren. Deze profieluitwerking vraagt juist client-side verificatie om de vertrouwde bronhouder, geaccepteerde autorisatie en aangewezen resource vóór gebruik te verbinden.

Die spanning moet niet met vrijblijvende formulering worden verborgen. Een definitief profielbesluit moet vastleggen:

• dat het access token voor deze client een controleerbare JWT is;
• welke claims verplicht zijn en hoe zij worden gevalideerd;
• hoe issuer en JWKS via discovery worden vertrouwd;
• welk foutgedrag geldt bij ontbrekende of tegenstrijdige claims;
• hoe sleutelrotatie en meerdere geldige keys werken;
• welke interoperabiliteitsgevolgen dit heeft voor standaard OAuth-componenten.

Open ontwerpkeuzes

Nog niet vastgesteld zijn onder meer:

• bron, beheer en beschikbaarheid van het organisatieregister;
• productieprofiel en governance voor de binding tussen URA, systeemidentiteit, signing key en UZI/PKI-certificaat;
• productie-algoritmen en crypto-agility;
• maximale levensduur en klokafwijking voor assertion, token en proof;
• meerdere resource-locaties en gebruiksdoelen;
• sleutelrotatie en JWKS-cachegedrag;
• consent, behandelrelatie en lokale mandatering;
• duurzame replay- en auditvoorzieningen;
• foutteksten, correlatie en operationele monitoring.

De guide neemt de certificaatgebonden organisatiehandtekening over uit het conceptmemo Harmonisatie van authenticatie en autorisatie voor de gegevensuitwisselingen BgZ en eOverdracht (VWS / Review, versie 0.9, 13 juli 2026). Dat document is ontwerpinput en geen formeel vastgesteld landelijk conformiteitsprofiel.

Totdat deze keuzes bestuurlijk zijn vastgesteld, presenteert de guide de repository-invulling als toetsbare referentie en niet als landelijke norm.

Conformiteit en bewijs

Een implementatie is niet conform alleen omdat zij OAuth, mTLS of DPoP gebruikt. Zij moet ook de samenhangende profielregels aantoonbaar uitvoeren. De implementatiechecklist vertaalt die regels naar observeerbare verificatiecriteria.

De referentiecode en tests bewijzen uitsluitend dat de gedocumenteerde prototypeflow uitvoerbaar is. Zij certificeren geen landelijke interoperabiliteit en geen inhoudelijke BgZ- of eOverdracht-conformiteit.