Session 5 - Missing client_id parameter

[Former user]

Should the post_logout_redirect_uri parameter be provided to the end_session_endpoint, the OP needs to verify that the URI was previously registered to the requesting RP. A client_id is required to make that verification. Is the assumption that the OP will get this value from the id_token_hint? If true, that value is "recommended". Should the client_id be an explicit parameter? That's how I've currently got it implemented.

[Michael Jones]

The working group appears to be in favor of adding this.

We would need to add a security consideration saying that the client_id is spoofable, and so should not be used for any security decisions.

People should continue to discuss this possibility.

[Former user]

Why do we need to support two ways to achieve the same effect? The id_token can be used for same effect. Also we recommend that id_token be accepted even if expired. Do we really need to have two mechanisms to address the same requirement?

[Former user]

Why do we need to support two ways to achieve the same effect?

Folks on the call seemed to think that it was not always possible for a client to have the (server-issued) id_token available to return to the server.

[Michael Jones]

Per the 7-Aug-14 and 11-Aug-14 call minutes, this is being resolved as won't fix.

[LinusL]

We host a company-wide account system as OP, and some websites as SPs. One of these SPs has multiple methods of authentication. However, clicking "Sign out" on this SP should always trigger signout from the company-wide OP, as otherwise the user might expect he was logged out from all company services, while in fact it did not happen - and that's a major security problem.

Without client_id param, in the case of non-OP login, we have no way of telling the OP which client has requested the logout - which makes it impossible to redirect the user back to the app.

[LinusL]

There is also the case that the aud claim "MAY also contain identifiers for other audiences", so it's not enough to identify the client in the 100% of cases allowed by the OIDC spec.