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
_______________________________________________
security mailing list
[email protected]
http://openid.net/mailman/listinfo/security
