Step-Up

[dteleguin]

For step-up and similar cases, we'll need a way to communicate the existing session information to the authorization challenge endpoint.

We already have id_token_hint, but the problem is that ID tokens would generally contain no session identifiers (in some cases they would, e.g. OIDC Front Channel Logout requires the presence of the sid claim in the ID token; but again, that's not the general case). Refresh token seems a better candidate as it has stronger relation to the session.

[PieterKas]

Can device_session effectively provide this capability? Should we require DPoP for all step-up cases (the public key becomes the indicator).

If we use device_session, what are the security considerations?

Decisions:

We will use device_session and update security considerations to discuss how to sender constrain the device_session parameter.

[dteleguin]

Can device_session effectively provide this capability?

I think it can, but only if we're stepping up a (previously established) native session. If the session was not native (i.e. classic OAuth2.0), we will need a way to obtain a device_session first.

[PieterKas]

We are trying to compensate for the lack of session management (no cookies). We want something that behaves like a browser cookie.

Enumerating use cases:

1. You have a token, but need to step up
2. Token expired and need a new one.
3. Stable identifier that does not las beyond the authorization code being issued.

Can this be solved by a Refresh token or DPoP instead?

Decision: Rename device_session to auth_session

[PieterKas]

Add guidance to store it even after the auth code expired

Extend the token endpoint response to include the auth_session as well.

Security considerations on protecting the auth_session parameter.

[aaronpk]

The auth_session parameter is now defined in the successful token response, so an AS can return a value to the device even if the first access token was obtained through the redirect flow.