Requesting ID Token with max_age=10000 seconds restriction expects same authentication

[quartje]

We run into a problem regarding the Requesting ID Token with max_age=10000 seconds restriction test. Our OpenID Connect OP implementation is implemented as a proxy, and all authorization requests are proxied to another SAML proxy, since all authorization and authentication policies live there. We do support the max_age parameter, in a sense that we do a forced authn when the time in the max_age parameter has elapsed. However, when the time has not elapsed, we also re-authenticate the user. This leads to the following certification test error:

same-authn: status=ERROR, message=Not one authentication! [Verifies that the same authentication was used twice in the flow.]

I would like to argue that this does not violate the spec:

max_age
   OPTIONAL. Maximum Authentication Age. Specifies the allowable elapsed time in seconds since the last time the End-User was actively authenticated by the OP. If the elapsed time is greater than
this value, the OP MUST attempt to actively re-authenticate the End-User. (The max_age request
parameter corresponds to the OpenID 2.0 PAPE [OpenID.PAPE] max_auth_age request parameter.) When max_age is used, the ID Token returned MUST include an auth_time Claim Value.

It doesn't say that you need to reuse the authentication when the time elapsed since the last authentication is smaller than the max_age parameter.

[selfissued]

OpenID Connect assumes that once the user has been signed in, that the sign-in lasts for a non-zero period of time. Both the normal prompt=none functionality and max_age functionality are predicated on this. Performing a new authentication every time prompt=none is used to ask whether the user is already signed in or when max_age is similarly used is certainly legal from a spec perspective, but defeats the purpose of these mechanisms. These mechanisms are in the spec because they can be used to build less obtrusive user experiences. But if the user is prompted every time the question is asked, it defeats the purpose of these mechanisms that are there to improve user experiences.

[quartje]

I wasn't aware that the OpenID Connect specification assumes that the sign-in lasts for a non-zero period of time. Where can I find that in the specification? There's no mention of Single Sign On or authentication session periods.

Mandating SSO, or sign-in sessions for a non-zero period of time, excludes OIDC OP's that act as a proxy and are unable to figure out user sessions upstream.

[zandbelt]

@selfissued shall I send an e-mail to the WG to discuss?

[selfissued]

I'd rather that we start the discussion on a working group call, as voice conversations tend to result in more thoughtful engagement and mutual understanding than e-mail threads. There's a call on Thursday, September 12th at the European-friendly time. Let's plan to bring it up then.

(And by the way, I think starting by discussing prompt=none error versus success responses will result in more clarity than starting by discussing max_age=10000.)

[DecorteHannes]

Our view (see #186) is also that asking authentication every time (no SSO Session) is allowed by the specification. Security restrictions of the authentication provider (Goverment) requires this. Although this can be experienced as obtrusive, we agree, but certification should not fail because of something being obtrusive, if it does not violate the specification (our opinion).

[selfissued]

It's not a question about whether always returning from authentication requests as if there is no session is permitted by the OpenID Connect Core spec. It clearly is, syntactically.

It's a question of whether the working group wants to continue requiring certified implementations to establish at least short-lived sessions upon successful authentication, among other things, so that prompt=none requests actually do what they're intended to do - silently indicate whether the user is already logged in. Also, the whole point of the logout specs is to be able to manage the sessions that are expected to be established.

This is about having certified implementations have baseline behaviors intended to provide quality user experiences. That's why the question was sent to the working group. Because it's not a spec question - it's a certification goals question. I can appreciate both sides of the issue.