Allen,
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.
I think you misread me. I said:
"It would be performed immediately when the user presents the message,
I'd imagine, since it's determining how to handle the request."
There's nothing preventing the OP from performing another check after
obtaining consent, of course, but that definitely doesn't strike me as
mandated by spec. It clearly says auth_time is "when the End User has
actively authenticated" and that the user MUST be actively
authenticated.
Both rules were met by the OP when the request was received, and the
RP can dispose of the response and try again if it isn't happy with
the results. The OP can't be certain whether the RP will reject the
response. Their time synch requirements, clock, message processing
rules, etc. are variable.
It can make a reasonable guess, but there's nothing stopping it from
doing that now, which is the behavior you describe. OP's choice, in
my opinion, and I'd rather not see it written into the spec.
Would you propose changing the wording so that auth_time is no longer
when authentication occurred, but when the authentication "process"
concluded(e.g. plus consent)? Could the RP get this information by
combining auth_time with the timestamp in the nonce(presumably when
the message itself is minted)
And, just for fun, I'd like to restate my belief in the importance of
signed authentication requests for situations like this.
Thanks,
Nate.
_______________________________________________
security mailing list
[email protected]
http://openid.net/mailman/listinfo/security
