Dit is een maatregel tegen beveiligingsrisico 4.4.1.3 uit RFC 6819. Aan de in omloop gebrachte authorization codes en access tokens zijn twee belangrijke eisen te stellen: uniciteit en vertrouwelijkheid. De eis van vertrouwelijkheid weegt in het MedMij Afsprakenstelsel zwaar. Omdat de authorization code (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 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 Authorization Server-sessie waarin het token werd uitgegeven, zodat de 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 8a blijft erop van kracht. Wanneer een verloopmoment is opgenomen in het access token, wordt het mogelijk om de Resource Server te laten afzien van onnodige raadpleging van de 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 of het access token waarbij het verloopmoment verlaat zou worden, leidt tot onterechte toegang tot, of onterechte plaatsing van gezondheidsinformatie. Het accepteren van een authorization code of een access token gebeurt altijd in het licht van de interne administratie van de 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 of access token nog aan te bieden. De meerwaarde van het opnemen van een verloopmoment in de authorization code of het access token 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 Resource Server samenwerkt met meerdere van hem gescheiden geïmplementeerde Authorization Servers, moet deze bij een aangeboden access token kunnen bepalen welke 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, de scope die hij eerder in de authorization request heeft ontvangen van de OAuth Client (zie Authorization interface, verantwoordelijkheid 1). Zo hoeft de Resource Server niet apart door de PGO Server van de scope op de hoogte gebracht te worden. De authorization code of het access token draagt zo weliswaar extra betekenis, maar de risico's daarvan wegen niet op tegen de risico's van het apart door de PGO Server laten sturen van de scope, die bijvoorbeeld zou kunnen afwijken van die waarvoor de authorization code of het access 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 Zorgaanbieder 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 Zorgaanbiederslijst de autoriteit: als de OAuth Client een access token heeft opgehaald op een plek die daartoe in de Zorgaanbiederslijst stond, dan moet hij dat access token kunnen aanbieden aan de plek die daartoe in de Zorgaanbiederslijst staat.
Het verbod op interpretatie door de OAuth Client van authorization code en access token zorgt ervoor dat er een minimale afhankelijkheid wordt gecreëerd tussen de dienstverleners in het Persoonsdomein enerzijds en die in het Zorgaanbiedersdomein anderzijds, zodat principes P1 en P7 maximaal worden nageleefd en interne complexiteit en implementatiekeuzes in het Zorgaanbiedersdomein niet doorschemeren in, of invloed uitoefenen op, de implementatie in het Persoonsdomein. De beperkingen van betekenisdragendheid van de authorization code en het access 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 zorgaanbiedersdomein, 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.
| 