My blunder. I wonder whatever I was thinking... Must be too tired... Thanks for pointing out.
=nat On Tue, Oct 27, 2009 at 12:05 AM, John Bradley <[email protected]>wrote: > Nat you are referring to the assertion lifetimes for a enterprise LAN > environment. > > For a environment where the RP is not part of the same domain as the IdP. > Level 1: 5min > Level 2: 5min > Level 3: 5min > Level 4: MUST NOT use bearer tokens. (Rules out openID) > > The Nonce contains a time stamp that should be used for this. > Clock synchronization can become an issue with times this small. NNTP > please. > > We could add a TTL to the assertion however it may be as easy to say that > OP keep private assertions for a minimum of 5 min. > > Andrew's app should refresh any unsolicited positive assertions older than > 5 min. > > It is interesting that JS can cache assertions like this. > > It perhaps also points out the possibility of people using this technique > for cross site scripting to sites that a user thinks they are logged out of. > > John B. > On 2009-10-26, at 3:40 AM, Nat Sakimura wrote: > > I fully agree on this. > > It is required not only from AJAX scenario, but also from Assurance Level > discussions. > > For example, in SP800-63rev.1, Level 1 assertion must expire in 12 hours, > Level 3 assertion in 30 min, > and in IDABC Authentication Policy, > > Level 1: 24 hours, > Level 2: 12 hours > Level 3: 2 hours > Level 4: Immediate (whatever it means...) > > Regards, > > =nat > > Andrew Arnott wrote: > > With the recent OpenID AJAX work I've been doing (blog > commenting<http://samples.dotnetopenauth.net/v3.2/openidrelyingpartywebforms/ajaxlogin.aspx>and > popup > login <http://openidux.dotnetopenauth.net/>) I've run across a problem > that while small now, may grow as OpenID popularity increases and AJAX use > becomes more mainstream. > > When an OP sends a positive assertion signed with a private association, > the RP currently has no idea how long this assertion is valid. The OP has > their own policy regarding how long before it expires the assertion based on > the response_nonce' timestamp. Some OPs may reason "well, it should only > take a few seconds for an RP to get back to us to verify this, so any nonce > more than 30 seconds old is expired" in order to keep the used nonce bin > from filling up too fast. > > Here's the problem: at least with my own AJAX designs, the positive > assertion the user agent obtains from the OP is *not* forwarded > immediately to the RP. Several assertions are gathered, and the user picks > which one to log into the RP with, and to help protect the user's privacy, > it's not ideal to send all assertions to the RP or else it's easy for the RP > to tie several identities together without the user's consent.* * If the > login screen is left open for several minutes, these assertions can get > stale. Particularly in the blog commenting scenario where the user my > acquire the positive assertion before writing his blog comment and thereby > could wait 15 minutes or more before posting his comment. > > So far, I'm mitigating this at the RP by choosing a "reasonable" maximum > lifetime for the assertion and the javascript automatically renews the > positive assertion after the assertion is assumed to have expired. But > since this guess at the assertion's lifetime is not correct for an arbitrary > OP, it would be great if with the positive assertion signed with a private > association the OP could indicate with another parameter how long the > assertion is valid for so the RP javascript code can renew at the optimal > interval. > > What do you think? > -- > Andrew Arnott > "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 > > ------------------------------ > _______________________________________________ > specs mailing > [email protected]http://lists.openid.net/mailman/listinfo/openid-specs > > _______________________________________________ > specs mailing list > [email protected] > http://lists.openid.net/mailman/listinfo/openid-specs > > > > _______________________________________________ > specs mailing list > [email protected] > http://lists.openid.net/mailman/listinfo/openid-specs > > -- Nat Sakimura (=nat) http://www.sakimura.org/en/
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
