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 <[email protected]> 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 [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
