[Openid-specs-fapi] Issue #264: expand on privacy considerations for id_tokens returned in front channel (openid/fapi)

josephheenan issues-reply at bitbucket.org
Mon Aug 26 11:16:56 UTC 2019


New issue 264: expand on privacy considerations for id_tokens returned in front channel
https://bitbucket.org/openid/fapi/issues/264/expand-on-privacy-considerations-for

Joseph Heenan:

As I mentioned on [https://bitbucket.org/openid/fapi/pull-requests/131/first-proposal-to-integrate-jarm-as-equal/activity](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](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.\)




More information about the Openid-specs-fapi mailing list