Discovery of an OpenID session at an OP

Mon Dec 14 15:55:24 UTC 2009

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> 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> 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://lists.openid.net/mailman/listinfo/openid-specs
>>> 
> 
> _______________________________________________
> 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/20091214/c8c91ad4/attachment.htm>