expand on privacy considerations for id_tokens returned in front channel

Issue #264 closed
Joseph Heenan created an issue

As I mentioned on https://bitbucket.org/openid/fapi/pull-requests/131/first-proposal-to-integrate-jarm-as-equal/activity it might be worth adding a bit more text about returning privacy related info in id_tokens.

We currently have a ‘should’ for the use of encrypted id_tokens; I think many ecosystems are likely to choose not to use encrypted id_tokens for various complexity reasons.

OIDCC ( https://openid.net/specs/openid-connect-core-1_0.html#HybridIDToken2 ) already says:

“Note that the OP MAY choose to return fewer Claims about the End-User from the Authorization Endpoint, for instance, for privacy reasons.”

It may be worth strengthening this by saying something like ‘shall not return sensitive personally identifiable information (PII) in the id_token returned from the Authorization Endpoint’. I presume we need to exempt ‘sub’ or at least say something further about the potential privacy implications of ‘sub’ .

(JARM of course already solves this issue.)

Comments (6)

  1. Ralph Bragg

    Just a note to say that OBIE allows Pairwise SUB’s to be used to allow correlation and a static ID but also a completely random value... This could be an opportunity to acutally try and solve some of the data attribution issues that DO result in security issues in a financial world where an RP can’t definitively identify the same user that’s releasing data too it.


    First Login (Bank A → PSU A → TPP A). The Bank returns an ephemeral random completely useless value in “sub”. Second request for data (Bank A → (PSU passes phone to his dad) → TPP A). From the TPP’s view PSU A has logged into the TPP, but because Bank A doesn’t use either pairwise or a static identifier for “sub” the TPP can’t be 100% sure that it is the same PSU authenticating.

    In my opinion it’s important that the TPP can identifiy return customers to prevent customers from deliberately adding data sets from multiple parties or at the very least have a way of detecting it.

    It doesn’t have to be a static ID or can be completely random but provided it’s consistently the same value shared amongst each (TPP, ASPSP, PSU) combination.

  2. Tom Jones

    Ralph’s comments are great, but – the issue then gets back to unique with who exactly. The problem here is the one of the many “brands” operating out of one “conglomerate”. We have the same problem is US Helathcare. The operational idea is that there is a “record locator ID” (aka locator) which is created by the entity holding the record and a sub which is the id that is used for authentication. The first is controlled by the conglomerate, the second by the user and their binding to the brand.

  3. Dave Tonge

    Merged in auth-endpoint-id-token (pull request #180)

    Add note that AS may return fewer claims in auth endpoint id token

    • Add note that AS may return fewer claims in auth endpoint id token

    This is just to reenforce that there is no need to return privacy sensitive claims in the id_token from the authorization endpoint, as the sensitive claims can be included in the id_token returned from the token endpoint.

    This is already explicitly allowed by the OpenID Connect spec:


    Also convert an existing note into a clause, as it contains a 'should'.

    closes #264

    Approved-by: Dave Tonge

    → <<cset 0f7d3ab8c78f>>

  4. Log in to comment