Allen,
There is nothing in the PAPE spec about the OP verifying that auth_age
< max_auth_age before returning the assertion.
That could lead to a deadlock situation.
You and others may see a value in that but that is not the intent of
the PAPE spec.
If the time since the last interactive login when the OP receives the
request is > max_auth_time then the OP must immediately re-prompt for
authentication (not using a long lived cookie to authenticate the user.)
Perhaps it would have been clearer if we had stated that the OP must
immediately reauth the user but we never imagined that the OP would
take the user through some other flow.
Part of the reason for this feature was Yahoo who drove a number of
additions to the PAPE spec , such as NIST level 0 to say the user was
authenticated with a long-lived cookie.
Given that Yahoo users may have authenticated up to 14 days
previously, that drove the need for max_auth_age to give a RP some
control over how old an interactive authentication they were willing
to accept.
The spec is worded that if max_auth_age is more than > than the
auth_age the OP can still elect to re-authenticate the user. If the
OP sets there own max_auth_age upper limit of a couple of hours I
think this covers the privacy concerns.
auth_age MUST be returned if max_auth_age is requested.
It is the time in seconds between the last interactive authentication
and the manufacture of the return assertion.
It is up to the RP to decide what to do based on this.
We don't wan't to take flexibility away from the RP if the auth_age in
the return is 2h then the RP has to decide if they get sent back to
the OP again.
PAPE is about giving some control over the login back to the RP. In
the normal openID flow the OP has complete control over the
authentication.
I am not sure why people think max_auth_age=0 is special it is just
0. Unless you are trying to read in the fancy auth_age < max_auth_age
behavior that was never intended.
There may be a better way to achieve the desired behavior with authn
URI to say things like the user must do a password reset (I think
Facebook was looking for that) or other things.
Some RP's are concerned about silent logins after the user has
"Remembered" the RP in there OP config.
This potentially allows for cross site request forgeries against the RP.
I could also see a lighter flow where the RP requests that the user
must consent to logging in but doesn't need to re-authenticate.
Those could be defined as auth methods potentially.
I am concerned that id OPs start creatively interpreting the PAPE spec
it will loose a lot of its value.
We have some of that creative interpretation problem now with AX.
I am glad people are starting to show an interest in implementing and
using PAPE.
John B.
On 1-Jul-09, at 1:32 AM, Allen Tom wrote:
Hi Nate -
Consider the scenario where the RP specified max_auth_age=1minute in
the request, and after being redirected to the OP, the user enters
their password, then sees the OP's approval screen and decides to
take a 10 minute break before clicking the "continue" button.
Should the OP should re-prompt the user for the password again
before returning the assertion to the RP because the RP requested
that the password be verified within 1 minute of returning the
assertion?
I believe that you said that the OP should re-verify the user's
password in this case, which makes plenty of sense.
Now getting back to the original case, where the RP used the magic
max_auth_age=0 value. Unless there is zero network latency, and the
OP does not have a separate approval screen, it is impossible for
the OP to satisfy this requirement.
That's why I was suggesting that we just define max_auth_age=0 as a
special case, and clearly define what is expected for this case.
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.
_______________________________________________
specs-pape mailing list
[email protected]
http://openid.net/mailman/listinfo/specs-pape
_______________________________________________
security mailing list
[email protected]
http://openid.net/mailman/listinfo/security
