expand on privacy considerations for id_tokens returned in front channel

[Joseph Heenan]

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.)

[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.

e.g

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.

[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.

[Joseph Heenan]

pull request opened: https://bitbucket.org/openid/fapi/pull-requests/180/add-note-that-as-may-return-fewer-claims/diff

[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:

https://openid.net/specs/openid-connect-core-1_0.html#HybridIDToken2

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

closes #264

Approved-by: Dave Tonge

→ <<cset 0f7d3ab8c78f>>