FAPI part 2 - JWE encrypted ID Tokens

[Torsten Lodderstedt]

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

What's the reason for this requirement?

[Ralph Bragg]

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.

[Torsten Lodderstedt]

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.

[Dave Tonge]

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.

[Torsten Lodderstedt]

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

[Dave Tonge]

should be able to request

Thanks

[Torsten Lodderstedt]

make it a should and explain the reason

[Torsten Lodderstedt]

please review the pull request

[Nat Sakimura]

Looked at the pull request #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.

[Ralph Bragg]

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 .

[Torsten Lodderstedt]

changed it to should

[Joseph Heenan]

Added explanation of when and why clients shall request encrypted ID Tokens

closes #159

→ <<cset 801e1616c16c>>

[Nat Sakimura]

Merged in 159-JWE-encrypted-ID-Tokens (pull request #65) that fixes #159

added explanation when and why clients shall request encrypted ID Tokens

Approved-by: Ralph Bragg [e-mail]

→ <<cset 4a3784b20cbd>>