Dick Hardt wrote:
So if the user has authenticated 55 seconds ago, but take 6 seconds to
click the continue button, then the user will be presented with a
login screen after clicking the continue button which tells them they
will be sent to the RP. Jarring user experience. I would suggest we
think this through.
Yes, my point exactly.
How common are continue buttons in OPs now? I would expect that if I
have an active session with my OP that meets the RP's policy, that I
won't even see an OP screen.
I would expect that most OPs would show a continue button, at least the
very first time the user visits a new RP, especially is AX is involved.
What would you suggest?
The RP should have a flag that they can pass in the request to tell the
OP to re-authenticate the user before returning a positive assertion to
the RP, which I think was the intent of max_auth_age=0.
As I mentioned previously, values like max_auth_age=0 or even
max_auth_age=60 are messy to implement because users may take more than
max_auth_age seconds to click the continue button after authenticating.
At least from an implementation standpoint, I can imagine that RPs would
want a "Force Authentication" interface, and it's unclear what the right
value for max_auth_age would be to satisfy this use case. 60? 120? 300? 0?
I suggest that either we say that this special flag actually is
max_auth_age=0, or we define a new PAPE policy for this case.
The requirements for the OP are:
- Authenticate the user without relying previously issued authentication
credentials.
- OPs which use passwords to authenticate the user should re-prompt for
the password (it's OK to pre-fill the userid in the Login form)
- Ideally, the user's IP address should not change between the time the
user authenticated and when the assertion is generated. (this is less
important, but nice to have)
Allen
Thanks
Allen
Nate Klingenstein wrote:
For instance, what if the RP specified max_auth_age=<1 minute>?
Sometimes users take a few minutes to complete the OpenID sign in
flow (they might get distracted), and although the user may have
entered their password immediately after being redirected to the
OP, the user may have taken more than a minute to navigate through
the OP's approval screen, before clicking on the button to return
back to the RP.
Isn't it the OP that is obliged to perform the check? It would be
performed immediately when the user presents the message, I'd
imagine, since it's determining how to handle the request.
It wouldn't matter if they dally at the OP if the RP weren't likely
to complain about the auth_time on the user's arrival, which is a
separate matter(and not mandated by spec from what I can tell). But
some check probably needs to be explicitly performed by the RP on
the return leg until authentication requests can be signed. Sigh.
Either way, the RP would only be sabotaging its own user base here,
so this falls more into the category of recommendations or best
practices, in my opinion.
The SHOULD there reads strangely to, though.
In order to provide a standard "force authentication" interface, I
propose that either we define a new PAPE policy, or we clearly
define max_auth_age=0 as a special value.
Having seen other working group applications and spec revisions move
a little gradually, I feel compelled to first ask: how painful are
these options?
comments?
Yes. Signed authentication requests would be nice and limit the
"trust, but verify" the RP needs to do -- that is to say, limit the
amount of private data the OP needs to expose.
Take care,
Nate.
_______________________________________________
security mailing list
[email protected]
http://openid.net/mailman/listinfo/security
_______________________________________________
security mailing list
[email protected]
http://openid.net/mailman/listinfo/security
