OpenID 2.1: timed priv. assoc. assertions

[Andrew Arnott]

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@...
http://lists.openid.net/mailman/listinfo/openid-specs

[Nat Sakimura-2]

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@...
http://lists.openid.net/mailman/listinfo/openid-specs
  

_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

[John Bradley-7]

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@...
http://lists.openid.net/mailman/listinfo/openid-specs
  

_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

[Allen Tom-2]

Andrew Arnott wrote:

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,

Can you describe the use case in more detail? The RP has multiple assertions from different OPs for the same user?

Allen




_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

[Andrew Arnott]

Sure, Allen.

Scenario 1

You know the http://openidux.dotnetopenauth.net/ prototype's selector?  Well, all of those OP buttons simultaneously use checkid_immediate to try to obtain a positive assertion.  As you know, any OPs that have previously asserted the user's identity at this RP (with "Remember me" checked at the OP) will succeed if the user is logged into the OP.  As each OP button on the selector succeeds at obtaining a positive assertion, it displays a green checkmark to the user, suggesting to him that this button was one he picked previously, and can now log in immediately (without any further interaction with his OP).  Not only does this optimize the login experience for the user, it helps the user avoid splintering his identity by picking 1 OP the first time, and a different OP the second time by accident.  

Also, since this prototype web site gives the user the ability to bind multiple authentication tokens to the same account, perhaps both Yahoo and Google's OP buttons will get a green checkmark on the selector, and either one is the correct choice for the user since both will take the user to the same account.  In this instance, it's particularly optimal for the user, who may not be logged into both Google and Yahoo, but only one.  The user doesn't care which OP really does the authenticating this time -- but would like to use whichever one he happens to be logged into, and he might not remember which OP he's logged into.  These green checkmarks say "Hey, if you click me, you're guaranteed to be logged in immediately without additional interaction with your OP."

Now the point is, when these positive assertions are obtained and the green checkmark displayed, the positive assertion still has not been sent to the RP (it's web server).  It's held in a Javascript dictionary of discovery results and assertions on the browser.  Why aren't these positive assertions just sent to the RP immediately so it's a non-issue?  Two big reasons:

1. Privacy for the user, particularly where the user is using different OPs at the same RP to manage different accounts at the RP instead of the same account.  This prevents correlating of multiple identifiers at the same RP where the user doesn't ask for it.
2. If the RP verifies these assertions right away, it still must postpone logging the user into the RP until the user chooses which one to use to log in.  The RP must then, since it already invalidated the assertion by verifying it, cross-sign the assertion, send it back to the browser, and wait for one of those assertions to come back, then re-verify the assertion using that proprietary cross-signing mechanism.  Yech on several levels.

Scenario 2

The blog commenting scenario, where the user never actually logs in, but writes his OpenID Identifier and a long comment, during which time the positive assertion previously obtained expires.  The RP doesn't want to maintain state for these... it simply wants to receive the assertion with the comment and thus be able to verify and process the comment in one step.

Now that all said, I so far have implemented John's suggestion of considering 5 minutes the maximum lifetime of a positive assertion and just renewing at that interval.  It seems to work well.  If you go to my prototype right now, open up the selector and see a green check mark, and wait exactly five minutes, you'll see the checkmark disappear momentarily and then reappear as that assertion is refreshed.  

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

On Thu, Oct 29, 2009 at 9:44 PM, Allen Tom <atom@...> wrote:

Andrew Arnott wrote:

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,

Can you describe the use case in more detail? The RP has multiple assertions from different OPs for the same user?

Allen

_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

[Nat Sakimura-2]

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@...> 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 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@...
http://lists.openid.net/mailman/listinfo/openid-specs
  

_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

--
Nat Sakimura (=nat)
http://www.sakimura.org/en/

_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs