3.2.1 JWT Bearer Tokens - "sub" claim

[jaronaz]

In paragraaf 3.2.1 staat m.b.t. de opbouw/inhoud van het geretourneerde Bearer Token (JWT) naar de client het volgende:

The server MAY issue tokens with additional fields, including the following as defined here:

sub
The identifier of the end-user that authorized this client, or the client id of a client acting on its own behalf (such as a bulk transfer). Since this information could potentially leak private user information, it should be used only when needed. End-user identifiers SHOULD be pairwise anonymous identifiers unless the audiance requires otherwise.

iGov-NL
In iGov-NL the sub claim MUST be present.
/iGov-NL

Voor onze implementatie geldt:

• end-user that authorized this client = burger (bsn mag in geen geval meegegeven worden)
• client id of a client acting on its own behalf = n.v.t.

Vragen:

• Waarom is hier gekozen voor MUST? Voor de implementatie die we nu doen met dit koppelvlak, komt het ons beter uit om dit veld niet op te nemen.
• Waarom staat er dan toch "Since this information could potentially leak private user information, it should be used only when needed." Moet dit niet doorgehaald worden?
• Mag deze waarde ook leeg zijn?
• Het voorbeeld in deze paragraaf mist dit veld?

[mrtn78]

op basis van alleen de tekst is mij dit ook onduidelijk. wellicht kan iemand zich herinneren wat de intentie was en dit beter verwoorden? Dan kunnen we de nieuwe beschrijving bespreken in de volgende werkgroep bijeenkomst.

[jaronaz]

Ik kan wel vertellen hoe we hier uiteindelijk mee zijn omgegaan:
Bij de implementatie van dit OAuth profiel hebben we destijds uiteindelijk gekozen om het sub te vullen met een transient-id, welke we aan de server kant loggen en de relatie leggen met het (static) id van de user (in dit geval BSN).
Op die manier blijft het mogelijk (met hulp van de uitgever) om als ontvanger van het token de relatie te leggen met de user (wanneer dit niet 1-op-1 doorgegeven mag worden).

Ik denk dat het dus wel goed is om dit als MUST op te nemen, omdat je daarmee ook mogelijk maakt dat de resource server zelfstandig de user resource kan ophalen. Andersom, als je dit veld weg zou mogen laten, dan moet je op een andere manier de link met de juiste resource leggen, dat is waarschijnlijk ongewenst.

[rschaar-logius]

Zie bovenstaande pull request voor een gesuggereerde wijzigin van de tekst om de inconsistentie te verhelpen. Gebruik zonder een 'sub' claim zou buiten descope van de use case ondersteund in dit profiel vallen. De inconsistentie komt voort uit het (te) minimalistisch wijzigen t.o.v. het iGov profiel.