I'd be interested in hearing clarification on this issue, too. In my experience, I've seen issues with both Java and Ruby relying party libraries and stateful associations. When dealing with a large volume of log-ins near the boundary of association expiration, some users end up getting a bad experience (the equivalent of a "log-in failure" in their eyes) through no fault of theirs.
It seems the that the only reasonable fix is for relying party libraries to somehow compensate for this. Is that right? I'm guessing that since no such fix has been implemented in these libraries, that one of (or possibly many) of these less-desirable outcomes tend to be taking place out in the wild: 1) OPs cranking up their lifespan of associations. This workaround sacrifices security and doesn't really address the problem. It just makes the negative side effects happen less frequently. 2) OPs implementing potentially surprising behavior (similar to the DotNetOpenAuth OP described above)--where the OP is ignoring association handles that are close to expiring, yet not returning an invalidate_handle. 3) RPs opting to use stateless associations exclusively (despite the OpenID spec's encouragement otherwise). 4) RPs having to forgo common libraries and implement their own association management utilities that continue to accept "late-arriving" assertions during a grace-period window. 5) RPs having to forgo common libraries and implement their own association management utilities that establish new associations well in advance of the expiry of existing, still-valid associations. So, I second Mr. Randall's request for clarification on the spec? Which party (RP or OP) should be addressing this issue and how? Of the 5 options described above, 1 and 3 seem clearly undesirable, and 2 would only feel comfortable with some acknowledgement from the spec body. 4 and/or 5 seem reasonable. Yet, some guidance from the spec authors would undoubtedly add some expediency to such enhancements being implemented in these various projects. Thanks for any guidance you can provide. --Drew _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
