NL GOV OpenID Connect profiel (standaard voor veiliger internet)

Reactie

Vraag1

Er staat dat de experts zich zorgen maken over het ontstaan van een mogelijke wildgroei van niet-compatible implementaties van OpenID Connect, zolang er geen afgesproken en gedeeld Nederlands profiel is.
Er is belang bij gebruik van een NL GOV OpenID Connect profiel versie 1.0 vanwege "ondersteuning van het profiel op een toenemend aantal mobiele toepassingen".

Echter in de (originele) functionele beschrijving van de “OpenID Connect” standaard staat dat deze moet worden toegepast bij het beschikbaar stellen van federatieve authenticatiediensten, waarbij sprake is van mobiele toepassingen.
Hierbij is het woord “mobiele toepassing” in het (nieuwe) “NL GOV OpenID Connect profiel” vervangen door "inclusief vertegenwoordiging- en attribuutverstrekking".

Waarom is in paragraaf 1 de functionele beschrijving de "mobiele toepassingen" verwijderd en wordt er niks gezegd over de afspraken over gebruik van OpenID Connect bij de Nederlandse (semi-) overheid.
Wordt de “OpenID Connect” van de aanbevolen standaard lijst afgehaald en vervangen door het “NL GOV OpenID Connect profiel” of wordt dit een verplichte standaard.
Waarom staat er niet in de samenvatting dat OpenID Connect o.a. wordt gebruikt om toegang tot RESTful web-services te reguleren en dat deze standaard veel gebruikt worden in non-web clients, zoals mobiele applicaties.
Hiermee maak je ook meteen duidelijk het onderscheid met SAML, die zijn oorsprong vindt in het bedrijfsmatige domein en die men blijkbaar van de verplichte standaard lijst wil afhalen.

De NL GOV Assurance Profile for OpenID Connect 1.0 dekt niet de lading voor heel Nederland. Ieder domein, b.v. in de zorg heeft zijn eigen eisen en wensen aan authenticatie. Verder wordt specifiek in de zorg Nederlandse profielen primair afgeleid vanuit internationale zorgprofielen, zoals van IHE (IUA profiel) of van HL7 (Smart)- en niet van de NL overheid.

Vraag2

Uit de constateringen en conclusies van de experts met betrekking tot de criteria voor de ‘pas toe of leg uit’-lijst (verplicht) (paragrafen 5.1-5.4 van het expertadvies) wordt geadviseerd om SAML van de standaard lijst af te halen.

Waarom wordt er voor SAML geen Nederlands profiel ontwikkeld, zodat beide standaarden naast elkaar gebruikt kunnen worden voor verschillende toepassingen of aan welke criteria voldaan moet worden.
Bijvoorbeeld SAML wordt ingezet bij SOAP (Service Providers) en OpenID bij RESTful (APIs).

SOAP is een standaard (messaging) communicatieprotocol dat alleen XML-technologieën gebruikt om een uitgebreid berichtenkader te definiëren waarmee gestructureerde informatie kan worden uitgewisseld in een gedecentraliseerde, gedistribueerde omgeving.
Met andere woorden, SOAP stelt applicaties, die op verschillende besturingssystemen draaien, in staat om te communiceren met behulp van verschillende technologieën en programmeertalen. SOAP ondersteunt WS (Web Services) specificaties zoals: WS-Addressing, WS-Policy, WS-Security, WS-Federation, WS-ReliableMessaging, WS-Coordination, WS-AtomicTransaction, en WS-RemotePortlets.
Voor Informatie beveiliging bij SOAP wordt SAML en soms XACML gebruikt.

RESTful daarentegen is een bouwstijl of procedure, geen protocol. Het staat voor Representational State Transfer. Dat betekent dat wanneer een client een resource aanvraagt met behulp van een REST API, de server de huidige status van de resource terugstuurt in een gestandaardiseerde weergave.
Met andere woorden, REST-API's ontvangen aanvragen voor een resource en retourneren alle relevante informatie over de resource in een formaat dat clients gemakkelijk kunnen interpreteren.
De algemene REST API authenticatie methoden zijn HTTP basic authenticatie, JSON Web Tokens, OAuth en API keys.

Bij de kosten wordt een vergelijk gemaakt tussen SAML en de NL GOV OpenID Connect.
Het ene is een algemene (internationale) standaard waar nog niet bepaalde keuzes en invullingen zijn gedaan en bij de NL GOV OpenID Connect zijn deze keuzes al wel gemaakt.
Hierdoor kan je de kosten tussen beide standaarden niet echt vergelijken, ook omdat het voor verschillende toepassingen ingezet wordt.

Vraag3

Gezien de openstaande punten genoemd in hoofdstuk 3, m.n. de ondersteuning van eIDAS wat nog niet heel helder is, komt het vaststellen van dit profiel dan niet te vroeg ?

eIDAS wordt al verplicht op papier, maar de techniek is nog niet geregeld. Angst zit in dat als men het 1.0 profiel heeft ingebouwd er een 1.1 (of 2.0) moet komen die eIDAS geheel ondersteunt en men dit (weer) aan moet passen.

Vraag5

Bij dit profiel is er voor de zorg niet voldoende draagvlak, vanwege de eerdere opmerkingen over de (internationale) een Nederlandse profielen van IHE en HL7/FHIR die door de zorg veel gebruikt wordt.