[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