Discovery of an OpenID session at an OP

Mon Dec 14 17:35:27 UTC 2009

Santosh,

First of all let me say that what you're building sounds promising.

On your point 1) below, you mention that direct verification would have to
be used.  That seems to be only true if discovery on identifiers is
performed from the user agent too so that the RP truly isn't involved.  But
discovery from the browser right now is impractical because browsers block
cross-site discovery for XSS protection.  But since you're talking about
discovering OPs rather than claimed identifiers, perhaps this isn't as much
of a blocker for you -- which is fine.

If you combine the RP with the user agent in discovery and background
authentication, you can achieve much in just OpenID 2.0.  Have you seen the
http://openidux.dotnetopenauth.net/ site that I published for demo purposes?
 You can play around with both the OP buttons and the user-supplied
identifiers that the login box accepts.  The identifiers are discovered by
the RP (server), the discovery results, complete with formulated checkid_*
request URLs are sent from the RP back to the user agent via ajax, and the
user agent initiates authentication at that point.  But because the RP
performed the discovery, association handles are available and included in
the request the RP sends to the user agent.  Thus, direct verification is
merely an option though not required.  The downside of this approach of
course is that the user agent and the RP (server) are bound together in
speaking AJAX to each other and server-side script must exist.

--
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 Mon, Dec 14, 2009 at 9:18 AM, Santosh Rajan <santrajan at gmail.com> wrote:

>
> There are two issues we need address, if we wan't to allow Ajax/JQuery type
> authentication in OpenID. I have already worked a bit on this area (with
> very limited success).
>
> 1) Signature verification will have to "Direct Verification", because the
> browser will initiate the authentication process. This is the easier part.
> But not all OP's support this at the moment.
> 2) Discovery. The browser needs to know which OP to use and the return_to
> url for the RP. At the moment this problem can only be solved with a browser
> plugin. I have been able to successfully use the mozilla jetpack javascript
> plugin to do this. With or without a plugin, the RP needs to inform the
> browser what the return_to url is. (So the browser can do the rest of the
> work on finding which OP will be used, we will come to this in a bit).
>
> An easy way for the RP to inform the browser that an OpenID login is
> required and give the return_to url, is to use a link element on the page.
> eg.
>
> <link rel="openid.return_to" href="http://example.com/return_to"/>
>
> Seeing this link element on the page the browser can show an OpenID Uber
> Login to the user. (This can be done with a plugin, or if browsers decide to
> support OpenID).
>
> Now the difficult part. We need the browser to maintain a list of the
> user's OP's with their endpoints, and the browser can ask the user which OP
> he would like to use. This can also be done if all OP's were to advertise to
> the browser, their endpoints whenever a user creates a new account with the
> OP, or when the user visits his home page at the OP. eg.
>
> <link rel="openid.OP" href="http://exampleop.com/openid_endpoint"/>
>
> Of course all this requires agreement from the browser vendors, OP's and
> the OIDF. But it is easy to see that all the OpenID spec needs to do is to
> provide two link elements, one for the RP and one for the OP. After that we
> need the browser vendors to support the idea, and if not we need plugin
> vendor's to do the job.
>
> And of course this only in the idea stage, I am sure if there is a will to
> go in this direction, we can do it.
>
>
> On Mon, Dec 14, 2009 at 9:25 PM, daniel jacobson <fragment37 at yahoo.com>wrote:
>
>> I think the biggest benefit to RPs is to create a library that is robust
>> and portable that would allow for them to designate which OPs they care
>> about.  This is what I was thinking about:
>>
>> 1.  This library should be written in AJAX/JQuery to enable it to be
>> portable across any browser.  The problem here is that these libraries may
>> be limited in alternate platforms like mobile - those cases may require a
>> different library.  Perhaps the JavaScript could be built in such a way that
>> it could execute on the client or the server.
>>
>> 2.  This library would allow the RP to pass in parameters to this
>> encapsulated (but open sourced) library indicating which OPs it cares about
>> most.  For those OPs, the library will surface them as prominently displayed
>> options for authentication.  For any selected option, the library would know
>> how to handle the authentication, whether it can read from a cookie, ping a
>> service, or offer additional user screens.  There could be multiple layers
>> to this library, as well, that would then allow the RP to designate less
>> prominent, but viable, options.
>>
>> 3.  This library would need to be flexible enough to handle any OP for any
>> RP.
>>
>> 4.  This library would be very easy to drop on a page or app.  The only
>> real implementation would be to add the appropriate parameters for the
>> designated OPs.
>>
>> I agree that Federated Identities offers issues that are very different
>> than those found in the proprietary Facebook Connect approach.  That is why
>> building such a generic, black-box library will be so difficult.  That said,
>> it also offers the greatest reward.  OpenID needs to have a single library
>> that can be dropped into any RP and immediately offer a dynamic, effective
>> and seamless UX.
>>
>> What would be the next steps to prototyping some of these ideas?  What are
>> the implications to the OpenID flow that you are talking about, Santosh?
>> -Daniel
>>
>> (By the way, I am relatively new to this list, so I apologize if some of
>> these ideas have already been discussed.)
>>
>>
>>
>>
>> --- On *Mon, 12/14/09, Chris Messina <chris.messina at gmail.com>* wrote:
>>
>>
>> From: Chris Messina <chris.messina at gmail.com>
>>
>> Subject: Re: Discovery of an OpenID session at an OP
>> To: "Chris Obdam" <chris.obdam at holder.nl>
>> Cc: "openid-specs at lists.openid.net" <openid-specs at lists.openid.net>
>> Date: Monday, December 14, 2009, 10:27 AM
>>
>>
>> The biggest issue with this idea is the limitation of choice for the user
>> -- as well as transparency into what's going on.
>>
>> That is, it may well work fine if you want to use a well known provider
>> like Google or Yahoo, but it will fail if you want to use a custom OpenID.
>>
>> Indeed, in the discussions we've had, have the client hint to the RP which
>> OP the user prefers seems like the most plausible way going forward.
>>
>> Additionally, if RPs add discoverable endpoints for
>> registration/authentication/authorization/sign out, then the browser or
>> other advanced client could deal with these interactions with a mire
>> pleasant, forgiving, and appropriate UI.
>>
>> Chris
>>
>> Sent from my iPhone 2G
>>
>> On Dec 14, 2009, at 4:22, Chris Obdam <chris.obdam at holder.nl<http://us.mc1123.mail.yahoo.com/mc/compose?to=chris.obdam@holder.nl>>
>> wrote:
>>
>> > Aaahhh. That's nice!
>> >
>> > Wondering how other people think about this subject!
>> > Where can I find more info on this subject, perhaps previous
>> discussions?
>> >
>> > Cheers,
>> >
>> > Chris
>> >
>> >
>> > Op 14 dec 2009, om 12:21 heeft David Recordon het volgende geschreven:
>> >
>> >> Hey Chris,
>> >> Check out Google's openid.ui.x-has-session parameter, it lets your
>> >> discover if a user has an active session with Google.  This hasn't
>> >> really been used yet, but there's a general consensus to roll this
>> >> sort of functionality into the UX extension once a few RPs and OPs
>> >> have shown that it works.
>> >>
>> >> --David
>> >>
>> >> On Mon, Dec 14, 2009 at 12:48 AM, Chris Obdam <chris.obdam at holder.nl<http://us.mc1123.mail.yahoo.com/mc/compose?to=chris.obdam@holder.nl>>
>> wrote:
>> >>> Hi all (again ;-)),
>> >>>
>> >>> I have implemented OpenID with quite a lot RP's now. Each time I
>> struggle with the UX. Yes it is becoming more and more effective but it's
>> not there yet.
>> >>>
>> >>> What I would like to offer to my user is automatic discovery of OpenID
>> sessions at the OP. I am already logged in at Google, Hyves (large dutch
>> Social Network), Yahoo and others. But each time I have to select on of
>> those out of a set of OP's which I don't use.
>> >>>
>> >>> When I enter a RP, the RP could do a redirect to a OP (in an iframe
>> for example) and ask if the OP has a logged in user. This could be a simple
>> anonymous request which returns a true or false. If true the UX can be
>> different, you know there is a session so you could automatically start a
>> OpenID transaction for the user. The end user only needs to confirm usages
>> of their data (normal first step OpenID).
>> >>>
>> >>> The RP can decide for it self which OP's to check automatically.
>> >>>
>> >>> Of course we need to make sure that the end user still has a choice in
>> using his own OP. But know the RP knows that this (anonymous) user has an
>> OpenID or not, and if so, where.
>> >>>
>> >>> Yes, this means an extra load on the OP's, but I hope they don't mind.
>> If you supply this service as an Op it means that your users will be using
>> their indentity a bit more on other websites, hopefully. Which is a big +.
>> (Maybe Allen Tom can react on this one? ;-))
>> >>>
>> >>> I think there a no real privacy issues with this idea? Ok, you know
>> from this anonymous user that he or she has an OpenID with XXX, but is that
>> a bad thing?
>> >>>
>> >>> Hope to get some comments on my thoughts!
>> >>>
>> >>> Cheers,
>> >>>
>> >>> Chris
>> >>> OpenID Holland
>> >>> _______________________________________________
>> >>> specs mailing list
>> >>> specs at lists.openid.net<http://us.mc1123.mail.yahoo.com/mc/compose?to=specs@lists.openid.net>
>> >>> http://lists.openid.net/mailman/listinfo/openid-specs
>> >>>
>> >
>> > _______________________________________________
>> > specs mailing list
>> > specs at lists.openid.net<http://us.mc1123.mail.yahoo.com/mc/compose?to=specs@lists.openid.net>
>> > http://lists.openid.net/mailman/listinfo/openid-specs
>> _______________________________________________
>> specs mailing list
>> specs at lists.openid.net<http://us.mc1123.mail.yahoo.com/mc/compose?to=specs@lists.openid.net>
>> http://lists.openid.net/mailman/listinfo/openid-specs
>>
>>
>>
>
>
> --
> http://hi.im/santosh
>
>
>
> _______________________________________________
> 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/20091214/d985a50d/attachment-0001.htm>