OAuth2.0 Client Credentials (ClientPassword)

Het DSGO kent de authenticatie variant AdSeal of QSeal, waarbij een datadienstaanbieder bij een datadienst aangeeft welk Authentication Assurance Level ( aal ) wordt gehanteerd: AdSeal of QSeal. Op deze wijze is praktische invulling gegeven aan twee betrouwbaarheidsniveaus: advanced en qualified.

In de Gebouwde Omgeving wordt op dit moment nog veel data gedeeld in documenten, en de overgang naar het uitwisselen van data via APIs is groot. De stap naar datatransacties met onweerlegbaarheid en authenticatie via JWTs is wellicht te groot. Daarnaast hanteren bestaande standaarden ClientPassword als authenticatie-oplossing en maken ze nog geen gebruik van electronic seals. Om de adoptie van het DSGO te vergroten wordt ook deze laagdrempelige variant van Authenticatie op datadienstniveau (Machine namens een partij) ondersteund in een overgangsfase totdat electronic seals gangbaar zijn voor Machine to Machine authenticatie. Het betreft daarmee een aanvullende en tijdgebonden afspraak in het DSGO.

Onder strikte voorwaarden is het mogelijk voor datadienstaanbieders om datadiensten aan te bieden waarbij gebruik gemaakt wordt van de OAuth2.0 Client Credentials Grant met een Client Password variant zoals beschreven in RFC 6749, sectie 4.4 en RFC 6749, sectie 2.3.1.

Deze specificatie staat meerdere methoden toe voor authenticatie van clients met een Client password. Het DSGO staat alleen client_secret_post toe, waarbij de client-ID en client secret worden meegestuurd in de application/x-www-form-urlencoded body van het tokenverzoek.

Deze wijze van authenticeren betreft een betrouwbaarheidsniveau laag en dient in het capabilities_info object aangegeven te worden bij het attribuut aal met de waarde ClientPassword.

Hierbij is het uitgangspunt dat beide partijen elkaar vooraf kennen en er sprake is van structurele uitwisseling van gegevens waarbij een hoge betrouwbaarheid van authenticatie niet vereist is.

Voorbeeld: 1-op-1 datatransacties tussen aanbieder en gebruiker, waarbij aanbieder ook datarechthebbende is en autorisatie verleent aan de gebruiker. (directe transacties)

DSGO.Basis: Voor de Authorisatie variant ClientSecret gelden de volgende restricties:

Partijen moeten de client_secret_post variant gebruiken, waarbij de client-ID en client secret worden meegestuurd in de application/x-www-form-urlencoded body van het tokenverzoek.
Partijen moeten een administratie voor preregistratie van Clients voeren, waarbij passwords minimaal één keer per jaar worden vernieuwd.
Partijen kunnen geen gebruik maken van het iSHARE netwerk.
Partijen kunnen geen gebruik maken van onweerlegbaarheid.
Partijen kunnen geen gebruik maken van een autorisatiebeleid waarbij er een toegangsrecht (access_right) is verleend door een derde partij (in de rol van datarechthebbende).
Partijen kunnen geen gebruik maken van een datadienstbroker.
Partijen zonder Electronic seal kunnen zich niet authenticeren bij het participantenregister, een autorisatieregister of een datadienstbroker.