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 and popup login) 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 list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
