MedMij beheer publiceert uiterlijk 31 oktober 2023 de eerste versie van het Aanbiedersregister op de publiek toegankelijke locatie.

De DAP wordt in de maanden na de eerste publicatie van versie 2.0.0 aangepast en mogelijk voorzien van bijlagen. Deelnemers hoeven daarom pas aan deze eisen te voldoen zodra 2.0.0 de verplichte versie is van het afsprakenstelsel.

MedMij beheer levert uiterlijk 31 oktober 2023 de eerste versie van de lijst waarop het Aanbiedersregister gebaseerd is.

Het ontsluiten van een Gegevensdienst door een Dienstverlener aanbieder is, in deze versie van het MedMij Afsprakenstelsel, hetzij in het kader van Verzamelen of in het kader van Delen van zekere gezondheidsinformatie. De term 'ontsluiten' wordt hier gebruikt in plaats van de term 'aanbieden', omdat als aanbieder van een Gegevensdienst de Aanbieder wordt gezien, niet de Deelnemer (Dienstverlener aanbieder). De Deelnemer ontsluit de Gegevensdienst dus namens de Aanbieder die die Gegevensdienst aanbiedt.

De termen 'aanbieden' en 'ontsluiten' vertegenwoordigen een tweedeling in de verantwoordelijkheid voor een geleverde Gegevensdienst. De Aanbieder is, ook als verwerkingsverantwoordelijke in de zin der AVG, verantwoordelijk voor het aanbieden van een Gegevensdienst aan de Dienstverlener persoon; de Dienstverlener aanbieder is, ook als verwerker in de zin der AVG, verantwoordelijk voor het ontsluiten van diezelfde Gegevensdienst aan diezelfde Dienstverlener persoon. Aanbieden en ontsluiten zijn dus niet achter elkaar geschakeld: de Aanbieder biedt de Gegevensdienst niet zozeer aan de Dienstverlener aanbieder aan, maar aan de Dienstverlener persoon. Aanbieden en ontsluiten zijn aspecten van eenzelfde geleverde Gegevensdienst: het eerste het verwerkingsverantwoordelijke, het tweede het verwerkende.

De DAP wordt in de maanden na de eerste publicatie van versie 2.0.0 aangepast en mogelijk voorzien van bijlagen. Deelnemers hoeven daarom pas aan deze eisen te voldoen zodra 2.0.0 de verplichte versie is van het afsprakenstelsel.

Zo wordt geborgd dat de juiste functie-implementaties en informatiestandaarden worden gebruikt. Ook wordt het correcte gebruik geborgd, wat bijdraagt aan interoperabiliteit en vertrouwen.

Conform wettelijke verplichting geeft Persoon, in de functie Verzamelen, actief toestemming aan de Aanbieder. In de functie Delen is deze verplichting niet aan de orde, maar vindt op dit moment evengoed een bevestiging door de Persoon plaats. De User Agentpresenteert, in opdracht van de Authorization server of Resource server, een scherm waarin de Persoon deze toestemming, respectievelijk bevestiging, kan geven. Aangezien in het persoonsdomein niet met BSN gewerkt mag worden, moet er een vervangende identificatie van de Persoon gebruikt worden.

Met deze ene soort kunnen alle situaties die in het MedMij Afsprakenstelsel voorkomen worden bediend. Voor het maximaliseren van de interoperabiliteit kiest MedMij ervoor de andere drie soorten uit te sluiten.

De OAuth-standaard laat het (access) token type vrij. Token types verschillen in het vertrouwen waarmee de OAuth Resource Server aan de OAuth Client de gevraagde resources kan prijsgeven als laatstgenoemde het access-token aan eerstgenoemde overlegt. Bij de eenvoudigste vorm (bearer-token) geeft de OAuth Resource Server eenvoudigweg aan elke OAuth Client die een geldig access-token overlegt, de resources die daarbij horen. "Aan toonder", net zoals een bank een cheque kan verzilveren aan toonder. Daaraan kleven evenwel veiligheidsrisico's, omdat het access-token na uitgifte gestolen kan zijn, of anderszins vervreemd van de OAuth Client aan wie het uitgedeeld was. Andere token types kunnen daarom vragen om meer garanties, zoals een identiteit van de OAuth Client of een client-secret. Bearer-token is echter het enige goed gestandaardiseerde en breed gebruikte token type. Het legt wel veel verantwoordelijkheid voor beheersing van de veiligheidsrisico's bij OAuth Client en OAuth Authorization Server. In hoofdstuk 5 van de specificatie van de standaard RFC6750 is daarom expliciete aandacht voor die beveiligingsrisico's en maatregelen om die het hoofd te bieden.

Dit is een maatregel tegen de beveiligingsrisico's 4.4.1.1 en 4.4.1.3 uit RFC 6819. Bovendien wordt de hele flow van de functie Verzamelen ononderbroken uitgevoerd. De 900 seconden moeten dan voldoende zijn voor de OAuth Client om het access-token aan de OAuth Authorization Server aan te bieden. Een refresh-token is dan niet nodig.

Dit is een maatregel tegen beveiligingsrisico 4.4.1.3 uit RFC 6819. Aan de in omloop gebrachte authorization-codes, en access-tokens en refresh-tokens zijn twee belangrijke eisen te stellen: uniciteit en vertrouwelijkheid. De eis van vertrouwelijkheid weegt in het MedMij Afsprakenstelsel zwaar. Omdat de authorization-code en het refresh-token indirect en het access-token direct toegang geven tot persoonlijke gezondheidsinformatie, kiest MedMij voor een formaat dat vrijwel betekenisloos is en alleen betekenis krijgt door confrontatie met lokale en goed beschermde administraties van de OAuth Authorization Server. De maximale raadkans wordt geëist in RFC6749, sectie 10.10. Er mag door vergelijking van meerdere authorization-codes of access-tokens niet doorschemeren hoe zij gegenereerd worden.

Wanneer een identifier is opgenomen in het access-token, kan dat gebruikt worden als identificatie van de OAuth Authorization Server-sessie waarin het token werd uitgegeven, zodat de OAuth Resource Server deze sessie kan hervatten wanneer zij het access-token aangeboden krijgt. Het is ook mogelijk dat een dergelijke identifier niet zozeer is opgenomen in de authorization-code, respectievelijk het access-token, maar geheel overeenkomt met de authorization-code, respectievelijk het access-token. Hoe dan ook, verantwoordelijkheid 6 core.autorisatie.206 blijft erop van kracht.

Wanneer een verloopmoment is opgenomen in het access-token of refresh-token, wordt het mogelijk om de OAuth Resource Server te laten afzien van onnodige raadpleging van de OAuth Authorization Server, wanneer deze apart geïmplementeerd zouden zijn. De tweede voorwaarde bij deze mogelijkheid voorkomt dat een eventuele corrumpering, in het Persoonsdomein, van de authorization-code, het access-token of hetrefreshtoken waarbij het verloopmoment verlaat zou worden, leidt tot onterechte toegang tot, of onterechte plaatsing van gezondheidsinformatie. Het accepteren van een authorization-code, een access-token of een refreshtoken gebeurt altijd in het licht van de interne administratie van de OAuth Authorization Server. Die corrumpering kan het verloopmoment ook vervroegen, maar richt dan weinig schade aan. Overigens kan in de deze versie van het MedMij Afsprakenstelsel, waarin de geldigheidsduur een vaste waarde heeft, de OAuth Client zelf ook al uitrekenen wanneer het geen zin meer heeft een authorization-code, access-token of refresh-token nog aan te bieden. De meerwaarde van het opnemen van een verloopmoment in de authorization-code, het access-token  of het refreshtoken zal dus hooguit in mogelijke toekomstige versies kunnen blijken.

De service die het token heeft uitgegeven is al wel in deze versie van het MedMij Afsprakenstelsel een nuttig informatie-element. In situaties waarin een OAuth Resource Server samenwerkt met meerdere van hem gescheiden geïmplementeerde OAuth Authorization Server, moet deze bij een aangeboden access-token kunnen bepalen welke OAuth Authorization Server moet worden aangesproken. Dat aanspreken kan bijvoorbeeld door middel van Token Introspection volgens RFC7662. De geëigende bron voor die informatie is het access-token zelf, dat weet heeft van zijn afkomst. Die afkomstinformatie levert geen extra privacyrisico's op, omdat de OAuth Client sowieso op de hoogte is van wie hij het access-token heeft ontvangen.

Verder mag de OAuth Authorization Server ook een kopie van de scope opnemen in (de authorization-code of) het access-token en refresh-token, de scope die hij eerder in de authorization request heeft ontvangen van de OAuth Client (zie Authorization interface). Zo hoeft de OAuth Resource Server niet apart door de DVP Server van de scope op de hoogte gebracht te worden. De authorization-code, het access-token en het refresh-token dragen zo weliswaar extra betekenis, maar de risico's daarvan wegen niet op tegen de risico's van het apart door de DVP Server laten sturen van de scope, die bijvoorbeeld zou kunnen afwijken van die waarvoor de authorization-code, het access-token of het refresh-token is uitgegeven.

De lijst van toegestane informatie-elementen is limitatief. Geen andere informatie, ook niet versleuteld, mag in de authorization-code of het access-token zijn opgenomen. Daaronder vallen zeker ook:

• informatie over Persoon;
• informatie over Aanbieder of Gegevensdienst, al dan niet in relatie tot Persoon, buiten de scope;
• benoeming van, en beperkingen aan, de beoogde acceptanten van de authorization-code of het access-token. Op dit punt is namelijk de Aanbiederslijst de autoriteit: als de OAuth Client een access-token heeft opgehaald op een plek die daartoe in de Aanbiederslijst stond, dan moet hij dat access-token kunnen aanbieden aan de plek die daartoe in de Aanbiederslijst staat.

Het verbod op interpretatie door de OAuth Client van authorization-code, access-token en refresh-token zorgt ervoor dat er een minimale afhankelijkheid wordt gecreëerd tussen de dienstverleners in het Persoonsdomein enerzijds en die in het Aanbiedersdomein anderzijds, zodat P1 en P7 maximaal worden nageleefd en interne complexiteit en implementatiekeuzes in het Aanbiedersdomein niet doorschemeren in, of invloed uitoefenen op, de implementatie in het Persoonsdomein.

De beperkingen van betekenisdragendheid van de authorization-code, het access-token en het refresh-token, zelfs indien versleuteld, bevorderen de privacy door middel van dataminimalisatie. Bovendien voorkomen zij nieuwe risico's op compromittering van die informatie-inhoud. Zulke compromittering zou moeilijk te ontdekken en te pareren zijn in het Aanbiedersdomein, ingeval men er daar toe besloten zou hebben van interne autorisatie-administratie af te zien omdat de informatie toch al meereist op de authorization code of het acces token, via de OAuth Client.

De controle van het in de TLS verbinding gebruikte certificaat is vooralsnog optioneel. De implementatie van deze controle wordt sterk aangeraden, zodat met een hogere mate van zekerheid de verzoekende partij kan worden vastgesteld.

Om de privacy te kunnen borgen is het van belang dat de OAuth Authorization Server voldoende zekerheid heeft over de identiteit van de OAuth Client. Die zekerheid is afhankelijk van hoe goed de OAuth Client zijn credentials vertrouwelijk kan houden. Daartoe maakt de OAuth-specificatie onderscheid tussen twee client types: confidential en public. De eerste soort kan een voor de OAuth Authorization Server afdoende mate van vertrouwelijkheid van zijn credentials bieden, de tweede niet. Het is een hoofddoel van MedMij om zulk vertrouwen te borgen in een afsprakenstelsel en niet over te laten aan individuele spelers. Daarom verbindt het MedMij Afsprakenstelsel verantwoordelijkheden aan OAuth Clients ten behoeve van hun betrouwbaarheid jegens OAuth Authorization Server. We verwachten dat een groot deel van de implementaties van de OAuth Client (van de DVP Server dus) deze vertrouwelijkheid sowieso kunnen bieden, omdat ze de architectuur hebben van wat de OAuth-specificatie web application noemt. Andersoortige DVP Server-architecturen, zoals die van een app, zijn ook mogelijk, maar alleen onder de voorwaarde dat de OAuth Client al het credentials-verkeer in de achtergrond op een server afhandelt, niet via het user device.

De eis dat https in lowercase staat volgt de canonical form zoals gespecificeerd in sectie 3.1 van RFC 3986. De eisen aan de hostname zijn o.a. gebaseerd op RFC 952 en RFC 1123. Het laatste segment is het zogeheten top-level domain.

Dat geldt dus ook voor de redirect_uri.

In release 1.1.1 van het MedMij Afsprakenstelsel was deze verantwoordelijkheid alleen van toepassing op frontchannel-verkeer en had de Dienstverlener aanbieder voor back-channelverkeer de vrijheid om een ander poortnummer te kiezen dan dat conform de IANA-lijst bij https hoort (443). Dat zorgt echter voor een extra beveiligingsbeheerlast bij de DVP Server die rekening houden met meerdere bestemmingspoortnummers bij uitgaand verkeer. Die beheerst brengt indirect ook extra beveiligingsrisico's met zich mee. Daartegenover staat dat de in deze release aangebrachte aanscherping naar verwachting geen wezenlijke beperking voor Dienstverleners aanbieder zal zijn, omdat zij toch al gebruik maken van het voor https bedoelde poortnummer uit de IANA-lijst. Een mogelijke uitzondering vormt de situatie waarin de Authorization Server en/of Resource Server in een multi-tenant omgeving draaien.

Dit is een maatregel tegen beveiligingsrisico's 4.4.1.1, 4.4.1.3, 4.4.1.4 en 4.4.1.5 in RFC 6819. De PKI-certificaten worden in deze release van het MedMij Afsprakenstelsel gebruik voor twee doelen op de tehnologielaag: authenticatie van servers en versleuteling, waarmee de vertrouwelijkheid en integriteit van de inhoud van het gegevensverkeer wordt geborgd.

Deze verantwoordelijkheid is opgenomen omdat met het bearer token informatie verkregen kan worden zonder dat nogmaals de identiteit wordt gecontroleerd. Daarom moeten maatregelen getroffen worden om te waarborgen dat het token alleen correct gebruikt kan worden.