RFC0008 Attribuut gebaseerde authenticatie
- Former user (Deleted)
Samenvatting
| Waarom is deze RFC nodig? | Gebruiksvriendelijk inloggen |
|---|---|
| Oplossingsrichting | Meer attributen gebruiken |
| Aanpassing van | MedMij |
| Impact op rollen | Ja |
| Impact op beheer | Nee |
| Gerelateerd aan (Jira issues) | |
| Eigenaar | Joris |
| Implementatietermijn | |
| Motivatie verkorte RFC procedure (patch) |
Goedkeuring
| Beoordelaar | Datum | Reactie | Toelichting |
|---|---|---|---|
| Productmanager | |||
| Ontwerpteam | |||
| ? |
Principe's
| Principe | Principe | ||
|---|---|---|---|
1 Het MedMij-netwerk is zoveel mogelijk gegevensneutraal | Positief | 11 Stelselfuncties worden vanaf de start ingevuld | Positief |
| 2 Dienstverleners zijn transparant over de gegevensdiensten | Positief | 12 Het afsprakenstelsel is een groeimodel | Positief |
| 3 Dienstverleners concurreren op de functionaliteiten | Positief | 13 Ontwikkeling geschiedt in een half-open proces met verschillende stakeholders | Positief |
| 4 Dienstverleners zijn aanspreekbaar door de gebruiker | Positief | 14 Uitwisseling is een keuze | Positief |
| 5 De persoon wisselt gegevens uit met de zorgaanbieder | Positief | 15 Het MedMij-netwerk is gebruiksrechten-neutraal | Positief |
| 6 MedMij spreekt alleen af wat nodig is | Positief | 16 De burger regisseert zijn gezondheidsinformatie als uitgever | Positief |
| 7 De persoon en de zorgaanbieder kiezen hun eigen dienstverlener | Positief | 17 Aan de persoonlijke gezondheidsomgeving zelf worden eisen gesteld | Positief |
| 9 De dienstverleners zijn deelnemers van het afsprakenstelsel | Positief | 18 Afspraken worden aantoonbaar nageleefd en gehandhaafd | Positief |
| 10 Alleen de dienstverleners oefenen macht uit over persoonsgegevens bij de uitwisseling | Positief | 19 Het afsprakenstelsel snijdt het gebruik van normen en standaarden op eigen maat | Positief |
Uitwerking
Deze RFC is de eerste in een serie die ervoor moet zorgen dat authenticatie in het afsprakenstelsel blijft aansluiten bij ontwikkelingen in de buitenwereld. Hierbij wordt tegelijkertijd ook gekeken naar mogelijkheden om authenticatie gebruiksvriendelijker te maken.
Omgevingsanalyse
Een aantal belangrijke ontwikkelingen in de buitenwereld. Namelijk de brief van de staatssecretaris BZK waarin aangegeven wordt over te gaan naar een "systeem van meer open toelating" om authenticatiemiddelen naast DigiD te introduceren. De staatssecretaris schrijft onder andere:
Het innovatietempo ligt zeer hoog, de ontwikkeling van inlogmiddelen versnelt en het aantal partijen dat innovatieve oplossingen aanbiedt neemt toe. Hierbij past een meer wendbare en daarmee meer toekomstvaste toelatingssystematiek.
In aansluiting op deze door de staatssecretaris ingegeven richting komt in deze RFC de verplichting voor DVZA om DigiD te gebruiken te vervallen.
Verder heeft de Autoriteit persoonsgegevens een brief geschreven over betrouwbaarheidsniveaus in de zorg. De Autoriteit Persoonsgegevens (AP) is de handhavende instantie voor de Algemene Verordening Gegevensbescherming (AVG). Wanneer MedMij deelnemers onvoldoende (conform de AVG en gerelateerde regelegeving) privacy- en beveiligingsmaatregelen toepassen dan kan de AP (hoge) boetes opleggen. De taak van MedMij strekt zich uit om deelnemers goed te informeren over hun verantwoordelijkheden conform AVG. MedMij kan dergelijke verantwoordelijkheden niet overnemen en moet actief de schijn tegengaan dat wanneer er aan MedMij voldaan wordt er automatisch ook aan de AVG voldaan wordt.
Door de verplichting voor DigiD te laten vallen, komt mogelijk IRMA in beeld als authenticatiemiddel bij DVZA's. Recent hebben de ministers van VWS en BZK vragen beantwoord over de toepassing van IRMA bij een huisartsenpost.
In de beantwoording van vraag 7 geven de ministers aan dat het gebruik van DigiD geen verplichting is en in vraag 17 wordt gevraagd of de minister bezwaar heeft tegen het gebruik van IRMA. Het antwoord hierop luidt:
Het is belangrijk dat burgers een adequate beveiliging wordt geboden bij de digitale toegang tot hun medische gegevens. Betrouwbaar inloggen is daarvoor essentieel. Onder de Wet digitale overheid kies ik bewust voor het toelaten van private middelen (op minimaal betrouwbaarheidsniveau
substantieel) vanuit het oogpunt van brede dekking en innovatie. De Wet digitale overheid stelt hier regels voor die aansluiten bij de Europese regels (eIDAS) voor inlogmiddelen. Ook IRMA zal hieraan moeten voldoen, om na inwerkingtreding van de Wet digitale overheid als Nederlands middel
toegelaten te kunnen worden. Dit is nog niet vastgesteld. Daarnaast geldt dat IRMA ook als Europees middel niet genotificeerd is. In Europa zijn op dit moment enkele tientallen middelen eIDAS-genotificeerd. Voor IRMA geldt dat dit nog niet heeft plaatsgevonden.
In de pensioen- en verzekeringssector is onlangs onderzoek naar IRMA gedaan, in de samenvatting van dat onderzoek staan (op pagina 34) de volgende zwaktes:
- Betrouwbaarheidsniveau van IRMA-attributen is voor sommige toepassingen te laag.
- Governance nog te onvolwassen om eventueel toekomstige groei en serieuze zakelijke toepassingen van IRMA in goede banen te leiden.
- Beveiliging van de IRMA-app moet zich nog bewijzen en lijkt nog niet te voldoen aan alle eisen voor betrouwbaarheidsniveaus Substantieel en Hoog.
- Beoogde businessmodel moet zich nog verder uitkristalliseren en bewijzen.
- Op dit moment nog weinig controleurs aangesloten, wat de adoptie van IRMA in de weg staan.
- Nog onduidelijk wat de gebruiker/consument ervan vindt qua gebruikerservaring en vertrouwen.
- Uitstraling IRMA en stichting Privacy by Design als trusted party voor de gebruiker moet nog worden opgebouwd.
Wijzigingsvoorstel
De verplichting tot DigiD te laten vervallen zoals deze in processen en informatie staat (https://vzvz.atlassian.net/wiki/display/PUBLIC/Processen+en+informatie). Het juridisch kader van MedMij (https://vzvz.atlassian.net/wiki/display/PUBLIC/Juridisch+kader) verplicht geen DigiD maar spreekt van “een door BZK aangewezen authenticatiemiddel”. Dit loopt vooruit hier vooruitgelopen op het wetsvoorstel Digitale Overheid (https://zoek.officielebekendmakingen.nl/kst-34972-2.html ) specifiek artikel 9. Op dit moment bestaan er nog geen door BZK aangewezen authenticatiemiddelen (ook niet DigiD). De wet is ook nog niet aangenomen. Dit zou ter verduidelijking aan het bestaande juridische kader toegevoegd moeten worden en hierbij tegelijkertijd verwijzen naar de verplichtingen onder de AVG en de zienswijze van de handhaver van de AVG, namelijk de brief van de AP.
Bij het vervallen van de verplichting voor DigiD is het waarschijnlijk nodig om een factsheet te publiceren over de mogelijkheden, de voor- en nadelen van IRMA (met verwijzing naar de bestaande bronnen). In deze factsheet zou ook aandacht moeten zijn voor de dekkingsgraad onder zorggebruikers.
Gedetailleerd wijzigingsvoorstel
Hieronder een tabel met een opsomming wanneer DigiD genoemd wordt. Het wijzigingsvoorstel kent een aantal kleuren. Groen wanneer er geen wijziging noodzakelijk is, rood wanneer er alleen sprake is van verwijdering, en paars wanneer de tekst gewijzigd wordt. Wanneer de locatie cell gevuld is met een kleur behoeft de wijziging misschien discussie.
| locatie | tekst | wijzigingsvoorstel |
|---|---|---|
| Afsprakenstelsel in de praktijk | Toen ik weer thuis was, ging ik verder in de app. Ik klikte op de optie om verbinding te maken. Vervolgens kon ik DigiD gebruiken, dat had ik al eens samen met mijn zoon gebruikt voor toeslagen bij de Belastingdienst. | laten staan |
| Changelog release 1.1.1 | Eisen van DigiD inzake uitloggen. | laten staan |
| Changelog release 1.1.2 | In release 1.1.2 wordt naast het SAML-koppelvlak ook het CGI-koppelvlak van DigiD toegestaan, onder de kanttekening dat voor DigiD het SAML-koppelvlak de toekomstvast keuze is. | laten staan |
| Processen en informatie | Toelichting Op de Applicatie-laag wordt beschreven dat de identiteit van de Zorggebruiker uitgedrukt wordt door een BSN en die passende zekerheid wordt verkregen door middel van DigiD. | verwijderen |
| Applicatie | Het is de rol PGO User Agent die verbonden wordt met de rollen OAuth User Agent en Authentication User Agent. De PGO User Agent spreekt uiteindelijk dus ook de Authentication Server van DigiD aan. | Het is de rol PGO User Agent die verbonden wordt met de rollen OAuth User Agent en Authentication User Agent. De PGO User Agent spreekt uiteindelijk dus ook de Authentication Server. |
| Applicatie | DigiD DigiD is dus de enig toegestane Authentication Service in de deze release van het MedMij Afsprakenstelsel. Zie hiervoor verder het Authorization interface. | verwijderen |
| Applicatie | De Authorization Server heeft de rol om, namens de Zorgaanbieder, op verzoek van de Persoon, autorisaties uit te delen aan de PGO Server. Om dat betrouwbaar te kunnen doen, en om aan een wettelijke verplichting van de Zorgaanbieder invulling te geven, schakelt de Authorization Server de Authentication Service van DigiD in. | De Authorization Server heeft de rol om, namens de Zorgaanbieder, op verzoek van de Persoon, autorisaties uit te delen aan de PGO Server. Om dat betrouwbaar te kunnen doen, en om aan een wettelijke verplichting van de Zorgaanbieder invulling te geven, schakelt de Authorization Server de (externe) Authentication Service in. |
| Applicatie | Bij beide krijgt de Client (bij OAuth de Client en bij SAML de Service Provider) niet onmiddellijk de gewenste informatie (bij OAuth het access token en bij SAML de gebruikersidentiteit, bij DigiD het BSN), maar via een ophaalbewijs (bij OAuth de authorization code, bij SAML het artefact). Het ophaalbewijs gaat voorlangs (via de User Agent), waarna achterlangs met het ophaalbewijs de gewenste informatie wordt opgehaald. | Bij beide krijgt de Client (bij OAuth de Client en bij SAML de Service Provider) niet onmiddellijk de gewenste informatie (bij OAuth het access token en bij SAML de gebruikersidentiteit), maar via een ophaalbewijs (bij OAuth de authorization code, bij SAML het artefact). Het ophaalbewijs gaat voorlangs (via de User Agent), waarna achterlangs met het ophaalbewijs de gewenste informatie wordt opgehaald. |
| Applicatie | MedMij-verkeer In artikel 7 wordt het MedMij-verkeer afgebakend, met het oog op de Netwerk-laag. Al het MedMij-verkeer is over domeingrenzen. Bovendien maakt noch eventueel verkeer tussen PGO Presenter en PGO User Agent, noch eventueel verkeer tussen Authorization Server en Resource Server deel uit van MedMij-verkeer. Authenticatieverkeer is uitgesloten, omdat het MedMij Afsprakenstelsel geen eisen oplegt aan het koppelvlak met DigiD. Deze afbakening is bovendien de opmaat voor punt 8 erna. Het daarin gemaakte onderscheid tussen frontchannel- en backchannelverkeer is nodig voor het formuleren van verantwoordelijkheden over beveiliging (zie Netwerk-laag). In punt 7 moet ermee rekening gehouden worden dat er ook een use case-implementatie is op de Netwerk-laag: UCI Opvragen WHL. | MedMij-verkeer In artikel 7 wordt het MedMij-verkeer afgebakend, met het oog op de Netwerk-laag. Al het MedMij-verkeer is over domeingrenzen. Bovendien maakt noch eventueel verkeer tussen PGO Presenter en PGO User Agent, noch eventueel verkeer tussen Authorization Server en Resource Server deel uit van MedMij-verkeer. Authenticatieverkeer is uitgesloten, omdat het MedMij Afsprakenstelsel geen eisen oplegt over welke authenticatieserver gebruikt moet worden. Deze afbakening is bovendien de opmaat voor punt 8 erna. Het daarin gemaakte onderscheid tussen frontchannel- en backchannelverkeer is nodig voor het formuleren van verantwoordelijkheden over beveiliging (zie Netwerk-laag). In punt 7 moet ermee rekening gehouden worden dat er ook een use case-implementatie is op de Netwerk-laag: UCI Opvragen WHL. |
| Applicatie | het gebruik van DigiD (Applicatie-laag); | het gebruik van een (externe) authenticatieserver (Applicatie-laag); |
| Authorization Interface | Authenticatie Conform stroomdiagram onder 1. De zorgaanbieder in het Zorgaanbieders- en dus BSN-domein is verplicht bij het verstrekken van gegevens vanuit een gezondheidsdossier de identiteit van de persoon te verifiëren aan de hand van het BSN. Uit het Juridisch kader volgt vooralsnog gebruik van DigiD voor dit doel. Omdat DigiD de enige is die de rol van Authentication Service kan spelen in deze release van het MedMij Afsprakenstelsel, is Logius de enige Authentication Provider ZA. Het MedMij Afsprakenstelsel brengt het aanroepen van DigiD onder in de OAuth-flow, onder operationele verantwoordelijkheid van de Authorization Server. Laatstgenoemde handelt in dezen onder verantwoordelijkheid van individuele Zorgaanbieders, want die zijn het waarvoor de Persoon zich authenticeert. Voor DigiD in haar huidige status is dat in zoverre bijzonder dat de zich authenticerende Persoon niet de directe gebruiker is van de aanroeper van DigiD (en daar een gebruikerssessie krijgt), maar een indirecte gebruiker, namelijk door tussenkomst van de PGO Server. De directe interactie van de Persoon met de Authorization Service is bedoeld om de PGO Server te autoriseren om de Resource Server aan te spreken. Die levert de uiteindelijke Gegevensdienst pas. Van oudsher is DigiD echter opgezet voor het authenticeren (inloggen en uitloggen) in gebruikerssessies bij dienstverleners. De MedMij-context is complexer dan dat. Voor de toekomst van DigiD wordt ook nagedacht over gebruikscontexten zoals die van MedMij. | Authenticatie Conform stroomdiagram onder 1. De zorgaanbieder in het Zorgaanbieders- en dus BSN-domein is verplicht bij het verstrekken van gegevens vanuit een gezondheidsdossier de identiteit van de persoon te verifiëren aan de hand van het BSN. Het MedMij Afsprakenstelsel brengt het aanroepen van de Authentication Service onder in de OAuth-flow, onder operationele verantwoordelijkheid van de Authorization Server. Laatstgenoemde handelt in dezen onder verantwoordelijkheid van individuele Zorgaanbieders, want die zijn het waarvoor de Persoon zich authenticeert. De directe interactie van de Persoon met de Authorization Service is bedoeld om de PGO Server te autoriseren om de Resource Server aan te spreken. Die levert de uiteindelijke Gegevensdienst pas. |
| Authorization Interface | 3b. In deze release van het MedMij Afsprakenstelsel is DigiD de enige toegestane Authentication Service. Het staat de Authorization Server vrij te kiezen uit de door DigiD geboden koppelvlakken. | verwijderen |
| Authorization Interface | DigiD Het staat de Authorization Server dus vrij te kiezen tussen het SAML-koppelvlak en het CGI-koppelvlak van DigiD. Wel is het van belang op te merken dat Logius aangeeft dat niet het CGI-koppelvlak, maar het SAML-koppelvlak de toekomst-vaste keuze is (zie paragraaf 2.4.4 van dit document). Mocht DigiD het CGI-koppelvlak gaan afvoeren, raakt dat voor die MedMij-Deelnemers die dat koppelvlak gebruiken ook hun deelname in MedMij. Het staat de Authorization Server ook vrij om ervoor te kiezen via de Toegangsverleningsservice aan te sluiten op DigiD. Enkele DigiD-aansluiteisen vragen in de MedMij-context om toelichting. Ten eerste eist DigiD dat de eindgebruiker “gedurende de gebruikerssessie” de gelegenheid houdt uit te loggen. Voor de UC(I) Verzamelen en UC(I) Delen mag deze “gebruikerssessie” geacht worden zich niet verder uit te strekken dan de Authorization Server. Daarna is immers de Persoon geen “gebruiker” meer van de Authorization Server, maar van de voor DigiD irrelevante PGO Server, die op zijn beurt de (daartoe door Persoon geautoriseerde) gebruiker van de Resource Server is geworden. Tijdens de sessie bij de Authorization Server is er bovendien slechts één eindgebruikersinteractie, namelijk bij het voorleggen van de toestemmings/bevestigingsvraag. Het afwijzen van die toestemming/bevestiging door de Persoon mag worden opgevat als uitloggen. Wanneer de gebruiker vijftien minuten niets doet op het autorisatiescherm, of wanneer de gebruiker dit scherm sluit, moet de sessie beëindigd worden. Er zijn geen verdere uitlogvoorzieningen nodig. Ten tweede stelt DigiD eisen aan de “DigiD-sessiegegevens” en de daarvan afgeleide gegevens. Dat roept de vraag op om welke gegevens dat gaat en of de authorization code en het access token moeten worden opgevat als afgeleide gegevens. De reden voor deze eis is dat de bedoelde gegevens nodig zijn om weer uit te loggen, vooral in het geval van single sign-on. In UC(I) Verzamelen en UC(I) Delen worden echter geen door DigiD geleverde gegevens, noch daarvan “afgeleide”, voor uitloggen gebruikt. Aan deze eis wordt daarom bij voorbaat voldaan. Wanneer single sign-on ook mogelijk wordt in MedMij, moet dit natuurlijk worden herbezien. Ten derde eist DigiD dat na de authenticatie wordt geredirect naar hetzelfde domein van waaruit DigiD is aangeroepen. Daaraan wordt sowieso voldaan in het MedMij Afsprakenstelsel, zij het dat deze DigiD-aanroep en -redirect zijn ingebed in een vergelijkbare Oauth-aanroep en -redirect. De situatie is dus genest: de PGO Server roept de Authorization Server aan, die DigiD aanroept, die redirect naar de Authorization Server, die de OAuth-flow vervolgt, waarin onder meer een redirect naar de PGO Server plaatsvindt. Die nesting maakt het weliswaar complexer, maar de conformiteit aan de eis blijft intact. | verwijderen |
Aandachtspunt
Misschien bij het verwijderen van de DigiD verplichting ook meer rekening houden met het feit dat een Identity Provider (IDP) een andere protocol dan SAML gebruikt.
Risico's
Zorgaanbieders realiseren zich onvoldoende dat de keuze voor een authenticatiemiddel grotendeels een eigen verantwoordelijkheid is.