OpenID 2.1: timed priv. assoc. assertions

[Nat Sakimura]

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 list
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>    
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20091026/677be2f0/attachment.htm>