I'm not on any "spec body", but I would suggest a combination of #2 and #5, sort of.<div><br></div><div>Either party (RP or OP) can fix the misbehavior by avoiding the use of near-expiry associations. It is already advisable from a security standpoint to consider clock skew and a maximum timeframe allowable for a user to complete an authentication (for nonce checking). Given then that OPs and RPs already (should) have this time limit built in, it is straightforward to apply this time limit to the remaining lifetime of an association and drop associations not guaranteed to last long enough to complete the authentication. For instance, if an association only has 30 minutes left and you allow for 10 minutes to complete authentication (including allowing for clock skew where applicable), the association has only 20 minutes of meaningful life left, after which it should be discarded. </div>
<div><br></div><div>If the RP implements this, it will drop the near-expiry association and request a new one from the OP 10 minutes before the last association has technically expired. Problem solved.</div><div><br></div>
<div>If the OP implements this, it will see an association handle that it knows is nearly expired, realize the RP will (or should) reject the assertion after the OP makes it, and revert to dumb mode. The OP's time window for considering an association useless may be smaller than an RPs, since by the time the OP is deciding whether to sign the assertion the authentication is nearly complete and the RP should be only moments away from validating the signature. So if the OP reverts to a private association (possibly sending invalidate_handle as well) it will keep the user experience correct, with the only possible side-effect being that the RP had to follow stateless-mode behavior for one or a few authentications.</div>
<div><br></div><div>To summarize, the user experience can be made reliable, without sacrificing security, with work done on either the RP or the OP side. And a decent OpenID library should (IMO) absolutely either have this behavior built-in, or allow through normal configuration or extensibility points for the host site to create this behavior.</div>
<div><br clear="all">--<br>Andrew Arnott<br>"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre<br>
<br><br><div class="gmail_quote">On Fri, May 6, 2011 at 12:59 PM, Drew Clippard <span dir="ltr"><<a href="mailto:dclippard@gmail.com">dclippard@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I'd be interested in hearing clarification on this issue, too.<br>
<br>
In my experience, I've seen issues with both Java and Ruby relying<br>
party libraries and stateful associations. When dealing with a large<br>
volume of log-ins near the boundary of association expiration, some<br>
users end up getting a bad experience (the equivalent of a "log-in<br>
failure" in their eyes) through no fault of theirs.<br>
<br>
It seems the that the only reasonable fix is for relying party<br>
libraries to somehow compensate for this. Is that right?<br>
<br>
I'm guessing that since no such fix has been implemented in these<br>
libraries, that one of (or possibly many) of these less-desirable<br>
outcomes tend to be taking place out in the wild:<br>
1) OPs cranking up their lifespan of associations. This workaround<br>
sacrifices security and doesn't really address the problem. It just<br>
makes the negative side effects happen less frequently.<br>
2) OPs implementing potentially surprising behavior (similar to the<br>
DotNetOpenAuth OP described above)--where the OP is ignoring<br>
association handles that are close to expiring, yet not returning an<br>
invalidate_handle.<br>
3) RPs opting to use stateless associations exclusively (despite the<br>
OpenID spec's encouragement otherwise).<br>
4) RPs having to forgo common libraries and implement their own<br>
association management utilities that continue to accept<br>
"late-arriving" assertions during a grace-period window.<br>
5) RPs having to forgo common libraries and implement their own<br>
association management utilities that establish new associations well<br>
in advance of the expiry of existing, still-valid associations.<br>
<br>
So, I second Mr. Randall's request for clarification on the spec?<br>
Which party (RP or OP) should be addressing this issue and how?<br>
<br>
Of the 5 options described above, 1 and 3 seem clearly undesirable,<br>
and 2 would only feel comfortable with some acknowledgement from the<br>
spec body. 4 and/or 5 seem reasonable. Yet, some guidance from the<br>
spec authors would undoubtedly add some expediency to such<br>
enhancements being implemented in these various projects.<br>
<br>
Thanks for any guidance you can provide.<br>
<br>
--Drew<br>
_______________________________________________<br>
specs mailing list<br>
<a href="mailto:specs@lists.openid.net">specs@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs</a><br>
</blockquote></div><br></div>