OpenID 2.1: timed priv. assoc. assertions

Nat Sakimura n-sakimura at nri.co.jp
Sat Oct 31 09:58:00 UTC 2009


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 <john.bradley at wingaa.com>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 listspecs at lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs
>
>  _______________________________________________
> specs mailing list
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>
>
>
> _______________________________________________
> specs mailing list
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>
>


-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20091031/c58135a8/attachment-0001.htm>


More information about the specs mailing list