...
| De Resource Client is de applicatie die verbinding maakt met een Resource Server. | ||||||
| Een OAuth Client is een Resource Client die gebruik maakt van het OAuth 2.0 raamwerk. | ||||||
| Een Authentication Client is een applicatie die gebruikmaakt van een Authentication Server om de identiteit van een OAuth Resource Owner vast te stellen. | ||||||
| De Resource Server is de applicatie waar gegevens kunnen worden verzameld of waarmee gegevens gedeeld kunnen worden. | ||||||
| Een OAuth Resource Server is een Resource Server die gebruikmaakt van het OAuth 2.0 raamwerk. | ||||||
| Een OAuth Authorization Server is een Authorization Server die gebruikmaakt van het OAuth 2.0 raamwerk. |
Technologie
| Begrip | Definitie | ||||||
|---|---|---|---|---|---|---|---|
| Een Frontchannel Node communiceert met de User Agent van de Persoon, waarbij de communicatie internet facing is. De rol van User Agent wordt hierbij ingevuld door een webbrowser. | ||||||
| Een Backchannel Node communiceert met andere backchannel nodes, waarbij voor identificatie gebruikgemaakt wordt van de verschillende lijsten die door MedMij Registratie worden geboden. |
Persoonsdomein
...
In het Persoonsdomein is er naast de rol Dienstverlener persoon ook de rol Persoon. Hoewel Dienstverlener persoonnamens Persoonhandelt, kan Persoon niet ongenoemd blijven in de afspraken op deze en onderliggende lagen. Dat komt doordat Persoon niet enkel de gebruiker van Dienstverlener persoonis, maar allereerst het onderwerp van de gezondheidsinformatie die Deelnemers ter beschikking moet stellen; daarvoor is authenticatie en autorisatie nodig. In de architectuur van het afsprakenstelsel heeft Persoon een operationele rol bij authenticatie en autorisatie van het gegevensverkeer.
...
In het persoonsdomein zijn twee rollen onderscheiden: de User Agent en de DVP Server. Dat is nodig om de verbinding te kunnen leggen met de rollen volgens OAuth. User Agent is de front-end-rol voor de DVP Server, en kan bijvoorbeeld in een browser zijn geïmplementeerd. Zoals ook elders in het MedMij Afsprakenstelsel gaat het hier om rollen, om setjes verantwoordelijkheden dus, niet om implementatiecomponenten.
...
In het Aanbiedersdomein is er naast de rol Dienstverlener aanbieder ook de rol Aanbieder. Deze rol wordt operationeel geheel vertegenwoordigd door de Dienstverlener aanbieder.
Application
Waar een Persoon zelf operationeel betrokken wordt in het informatieverkeer — namelijk om zich te laten authenticeren, en het verkeer te laten autoriseren — laat de Aanbieder zich operationeel geheel vertegenwoordigen door zijn Dienstverlener en diens Authorization Serveren Resource Server. Ook al zal in veel gevallen de gezondheidsinformatie uiteindelijk uit een achterliggend systeem worden betrokken, voor het MedMij Afsprakenstelsel is dat geen kwestie. Het is voldoende om bij de Authorization Server en Resource Server de eindverantwoordelijkheid neer te leggen (black box).
...
Hoezeer ook alle eindverantwoordelijkheden gedragen worden door de Dienstverleners die deelnemer zijn in het MedMij Afsprakenstelsel, zij kunnen ervoor kiezen de uitvoering van die verantwoordelijkheden deels of zelfs geheel uit te besteden. In een mogelijke systeemarchitectuur maken meerdere Resource Server-systemen gebruik van eenzelfde (al dan niet uitbesteed) Authorization Server-systeem. Het is mogelijk dat die Resource Server-systemen samen onder de eindverantwoordelijkheid van één Dienstverlener aanbieder vallen, met de uitvoering al dan niet uitbesteed. Het is ook mogelijk dat twee verschillende Dienstverlener aanbieders voor de Authorization Servergebruik maken van eenzelfde onderaannemer.
De architectuur heeft zo maximale ruimte aan de eigen businessmodellen en architecturen van Dienstverlener aanbieder willen geven zonder daarbij de interoperabiliteit en strakke eindverantwoordelijkheden geweld aan te doen.
...
Al het MedMij-verkeer is over domeingrenzen. Verkeer binnen het Persoonsdomein of het Aanbiedersdomein maakt geen deel uit van MedMij-verkeer. Ook authenticatieverkeer is uitgesloten, omdat het MedMij Afsprakenstelsel geen eisen oplegt over welke (externe) Authentication Server wordt gebruikt. Het MedMij Afsprakenstelsel vereist dát er een passende authenticatie door Aanbieder moet plaatsvinden, maar het verkeer dat daarvoor nodig is — tussen Authorization Server, Authentication Server en User Agent — is geen MedMij-verkeer. Het is de Aanbieder die niettemin als verwerkingsverantwoordelijke verantwoordelijk blijft voor een passende keuze van een Authentication Server en voor het laten inrichten van het authenticatieverkeer.