...
.7
De naam wordt geregistreerd in kleine letters;De naam wordt geregistreerd (ook in de Zorgaanbiederslijst) in het volgende formaat:
- een reeks van één of meer segmenten, gescheiden door
- hetzij één koppelteken,
- hetzij één ampersand,
- hetzij één punt;
- gevolgd door
@medmij
, waarin- elk segment een reeks van één of meer fragmenten is, zodanig dat
- elk fragment bestaat uit een reeks van
- minimaal één kleine letter uit het Nederlandse alfabet (bestaande uit de zesentwintig letters
a..z
),- gevolgd door een reeks van maximaal vier Arabische cijfers (
0..9
)..8
De naam mag alleen bestaan uit karakters die voorkomen in het Nederlandse alfabet (bestaande uit zesentwintig letters). Diakrieten, speciale tekens (zoals spatie, koppelteken en punt) zijn dus niet toegestaan;Van de naam mogen, buiten de registratie, varianten voorkomen waarin een kleine letter is vervangen door de corresponderende hoofdletter en/of diakritische varianten van letters voorkomen. Deze lettervarianten worden echter als identiek gezien aan de kleine basisletter. De naam is dus niet hoofdletter-gevoelig en evenmin diacriet-gevoelig.
Nav https://pim.vzvz.nl/browse/AF-1044:
Op pagina Token interface aanpassen:
client_id
niet gebruiktde hostname van de Node van de OAuth Client die de authorization request deed die de nu aangeboden authorization code opleverde
Zie de toelichting bij verantwoordelijkheid 1b.De OAuth 2.0-specificatie stelt deze parameter niet verplicht indien de OAuth Client zich authenticeert, hetgeen in het MedMij Afsprakenstelsel gebeurt door middel van mutual TLS. En de noodzaak van het gebruik ervan wordt beperkt door verantwoordelijkheid 4 op deze pagina, die borgt dat het access token alleen wordt verstrekt aan de OAuth Client aan wie de OAuth Resource Owner toestemming heeft verleend. In hoofdstuk 2 van een Internet-Draft ter zake wordt echter gesteld dat de
client_id
toch gebruikt moet worden ingeval mutual TLS wordt gebruikt. Dat laatste is het geval in het MedMij Afsprakenstelsel (zie Netwerk-laag).
1b. Hoewel de Client geenclient_id
opneemt in de access token request, accepteert de Authorization Server access token requests zonder én metclient_id
. In dat tweede geval controleert de Authorization Server bovendien of declient_id
overeenkomt met declient_id
die hij heeft ontvangen in de authorization request op basis waarvan hij de authorization code heeft uitgegeven die in deze access token request wordt aangeboden. Als deze controle faalt, behandelt de Authorization Server dit conform uitzondering 'Token interface 1' uit verantwoordelijkheid 6 en wel met de error responseinvalid_client
.
Client_id in access token request
De OAuth 2.0-specificatie stelt declient_id
niet verplicht in de access token request indien de OAuth Client zich authenticeert, hetgeen in het MedMij Afsprakenstelsel inderdaad gebeurt door middel van mutual TLS. De noodzaak van het gebruik van deze parameter wordt bovendien beperkt door verantwoordelijkheid 4 op deze pagina. In hoofdstuk 2 van een Internet-Draft ter zake wordt niettemin gesteld dat declient_id
gebruikt moet worden wanneer mutual TLS wordt gebruikt. Dat laatste is het geval in het MedMij Afsprakenstelsel (zie Netwerk-laag).
Daarom bereidt het MedMij Afsprakenstelsel zich voor op het verplicht stellen van declient_id
. In deze release 1.1.2 neemt de Client nog geenclient_id
op in het access token request, maar wordt de Authorization Server al wel geacht access token requests te accepteren die eenclient_id
bevatten en daar dan ook op te controleren. In een volgende release wordt beoogd de parameter verplicht te gaan stellen.
Risico's
Omschrijf de (privacy)risico's die kunnen ontstaan als deze RFC wordt aangenomen. In het onwaarschijnlijke geval dat deze RFC's geen risico's introduceert, geef dat dan wel aan.
...