[Openid-specs-ab] JWE and end session

[Andreas Åkre Solberg]

On 4. sep.2011, at 22:30, John Bradley wrote:

> There are two possibilities for keeping state.

OK, let's move back to discussion state storage later; first I need to understand a few things...


Right now, there is no processing instructions (as I've mentioned) on the end session service [1]:
[1]: http://openid.net/specs/openid-connect-session-1_0.html#anchor16

I can implement a server that checks that the id_token is present but ignores the content of it. Then terminates the user session based upon a session cookie. And then redirect the user to the provided redirect_uri, without validating the redirect_uri url. I cannot see anything in the spec that conflicts with this approach.

I expect us to add some processing instructions to make sure that the server does not accept 'anything'. It is difficult to discuss states before we have a shared understanding of what kind of validation that the server is expeted to perform. 

I assume that we will run into some trouble when the end session service recieves an assymetrically encrypted JWT (JWE). The services will not be able to descrypt it. One solution could be that the provider keep a index of all issued JWEs mapping them to cached decrypted versions of the JWEs. I think it is obvious that this is not very elegant.

> Given that the JWT is signed by the IdP it can contain some way to connect it to whatever way the IdP is maintaining the state of the user.

If you assumpt that the provider can read the content, yes.

Another dimension of complexity: a single user may have several independent sessions at the provider, and when receiving an incomming id token at the end session endpoint, you most likely want the provider to make sure that the id token is valid for the 'current front-channel' session (and not some other session). This validation would typically be making use of the nonce value; however the fact that the nonce is optional could may add severe complexity to this validation step.

Andreas