[security] PAPE Policy for RPs to force authentication without browser cookie
Allen Tom
atom at yahoo-inc.com
Wed Jul 1 06:15:35 UTC 2009
Nate Klingenstein wrote:
>
> 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.
>
From an implementation and interoperability standpoint, there does not
seem to be any clear guidance as to what the right value of max_auth_age
the RP should pass to the OP, nor does there seem to be clear what
exactly the OP is supposed to do.
> 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.
>
OpenID is supposed to define a consistent and interoperable interface.
If an RP has a requirement that they want to re-auth users for certain
flows, then it would really hurt the interoperability story if the RP
had to use different values for max_auth_age for each OP.
> 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)
>
RPs that want to be able to force a re-authentication flow on the OP
should have a fairly clear way to do this.
> And, just for fun, I'd like to restate my belief in the importance of
> signed authentication requests for situations like this.
I always thought that OpenID was weird for not signing the
authentication request.
Allen
More information about the security
mailing list