OpenID 2.1: timed priv. assoc. assertions

[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 at yahoo-inc.com> 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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20091030/6e81aaeb/attachment.htm>