FAPI part 2 - JWE encrypted ID Tokens

[bitbucket-import-issues]

Originally submitted by tlodderstedt (Torsten Lodderstedt) on 2018-08-04

§5.2.4,#2 requires confidential clients to request encrypted ID Tokens

What's the reason for this requirement?

---

Bitbucket status: resolved

Bitbucket origin: issue 159

[bitbucket-import-issues]

Originally submitted by Ralph Bragg (Ralph Bragg) on 2018-08-04

If OPs can generate different ID Tokens from the "detached signature" to the id_token then encryption is less of an issue. If they can't then the id_token's claims will need to be encrypted if they're sent through the front channel.

Arguably even the "sub" could be PII or sensitive depending on the value used for it.

[bitbucket-import-issues]

Originally submitted by tlodderstedt (Torsten Lodderstedt) on 2018-08-04

Thanks for the explanation.

It think this is another good reason to separate signed authorization response and ID token (https://bitbucket.org/openid/fapi/issues/155/support-authorization-and-identity). The signed response does not contain PII (even so it could be encrypted to not expose the code to the browser). The ID token is served via the TLS protected connection from the token endpoint w/o the need to encrypt.

[bitbucket-import-issues]

Originally submitted by dgtonge (Dave Tonge) on 2018-08-06

I think the wording could be tidied up here. I think the intent is that clients should be able to handle encrypted tokens, not that they are required to request them for every interaction.

[bitbucket-import-issues]

Originally submitted by tlodderstedt (Torsten Lodderstedt) on 2018-08-06

The should be "able to handle" or they "should be able to request"?

[bitbucket-import-issues]

Originally submitted by dgtonge (Dave Tonge) on 2018-08-06

should be able to request

Thanks

[bitbucket-import-issues]

Originally submitted by tlodderstedt (Torsten Lodderstedt) on 2018-08-07

make it a should and explain the reason

[bitbucket-import-issues]

Originally submitted by tlodderstedt (Torsten Lodderstedt) on 2018-08-11

please review the pull request

[bitbucket-import-issues]

Originally submitted by Nat (Nat Sakimura) on 2018-08-14

Looked at the (Bitbucket #65). It is using "shall" instead of "should". Did we agree to it? From what I see on the ticket, it seems that we wanted it to be "should".

Note: even if the response contains PII (actually, everything is PII at this point anyway), if it only contains a low-risk PII only, unencrypted ID Token may be OK.

[bitbucket-import-issues]

Originally submitted by Ralph Bragg (Ralph Bragg) on 2018-08-14

Hi, this needs to be a should not a shall. If a pairwise single use identifier is used then there is no PII that leaks. The OB guidance states that if PII is to be conveyed then it’s a shall.

Tightening this would have significant implications for existing implementations and whilst I’m all for mandating universally more secure tokens the political capital to get the aspsp’s to fall inline isn’t worth it in my opinion.

Those that want to be id providers/players will opt in to encrypted towns .

[bitbucket-import-issues]

Originally submitted by tlodderstedt (Torsten Lodderstedt) on 2018-08-15

changed it to should