No normative statement on id_token encryption

[Joseph Heenan]

The FAPI2 comparison table in the spec (see screenshot & red circle) currently says “No encryption and no ID Tokens in the front channel”.

However I cannot find normative text in the specification that says encryption must not be used for id_tokens, so I think encryption is permitted.

This is a potential source of interoperability problems. In particular I believe the FAPI2 conformance tests allow OPs to return encrypted id tokens, but do not test that clients can handle encrypted it tokens.

‌

[Daniel Fett]

As said on the call, I’m not sure if prohibiting encryption of ID Tokens is a good idea. Reason being that I know that some people have strong feelings about encrypting personal data on the application layer (=using encrypted ID Tokens). But we should at least add some text saying that doing so will be a problem for interoperability.

[Filip Skokan]

To reiterate my position from the call, I am not supportive of prohibiting encryption but at the same time would be strongly opposed to requiring clients requesting the FAPI 2.0 conformance profile stamp to accept it.

[Joseph Heenan]

As mentioned on the call we should have a base position where certified clients and certified Authorization Servers are guaranteed to interoperate, and id token encryption is a particular issue for anyone doing FAPI1->2 migration as FAPI1 did require OPs to use id_token encryption in some situations.

The working group needs to provide a clear statement to the certification team as to what they want the certification tests to do here. Ideally that position is backed up by normative text in the specification.

[Filip Skokan]

As mentioned on the call we should have a base position where certified clients and certified Authorization Servers are guaranteed to interoperate

A guarantee is a far fetched promise even with/without explicit statement on encryption.

There is already no guarantee per profile per se given the JOSE algorithm selected for testing is not part of the profile. Same would be true if encryption was tested.

The row talks specifically about frontchannel ID Token encryption, not backchannel one.

My recommendation is to remove the row entirely given that “ID Token as detached signature” row already covers its non-existance.

As for the certification tests, requiring ID Token decryption is a rather big hurdle that should be avoided. An interoperability warning for OPs that return an encrypted ID Token would not feel out place.

[Joseph Heenan]

The row talks specifically about frontchannel ID Token encryption, not backchannel one.

It does, but both front & backchannel are controlled with the same piece of client metadata, which is why I am particularly concerned especially in the case where ecosystems migrate from FAPI1 to FAPI2.

There is already no guarantee per profile per se given the JOSE algorithm selected for testing is not part of the profile. Same would be true if encryption was tested.

Agreed, although oddly that has not turned out to be a source of trouble in practice yet - perhaps because many people have selected RSA for their ecosystems. (It was one of the things I wanted to try and rework for FAPI2 certification but we never really came up with an idea that worked on how to incorporate it into the tests / present the data.)

[Joseph Heenan]

An interoperability warning for OPs that return an encrypted ID Token would not feel out place.

I think this should be our minimum position. I would prefer we go further if we can, even if it’s only some non-normative text.

[Dave Tonge]

we need to update table, perhaps with a note as to why encryption not required

[Dave Tonge]

https://bitbucket.org/openid/fapi/pull-requests/471

[Dave Tonge]

pr merged