OpenID 2.1: timed priv. assoc. assertions

[John Bradley]

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  
>> 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
>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20091026/9871bd20/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2486 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20091026/9871bd20/attachment.bin>