Discovery of an OpenID session at an OP

Santosh Rajan santrajan at gmail.com
Mon Dec 14 15:23:44 UTC 2009


Oops, looks like your post landed in my spam folder, please look into the
reason why this has happened. Also Luke Shepperds posts seems to land in my
Spam folder.

Couple of points I would like to make.

1) Anything to do with iFrames is a bad idea. This is a big security hole.
2) The Ajax/jQuery idea is great! The only problem here is that, Ajax/jQuery
works great with "delegated identity" (Facebook Connect is a good example).
I haven't seen Ajax/jQuery work with "Federated Identity". Though I have
been scratching my head for a last few months on this.
3) If we can do OpenID with Ajax/jQuery that would be fantastic. For that we
will need to change the OpenID flow. (This is entirely possible). And it is
well worth investigating. We will need some help from the Facebook folks. I
think it is really possible.

On Mon, Dec 14, 2009 at 8:04 PM, daniel jacobson <fragment37 at yahoo.com>wrote:

> Chris,
> I agree that the UX definitely needs to be substantially improved to
> increase adoption of RPs. Seems like this approach would require OP adoption
> AND a code library to allow RPs to take advantage of the OP services.
>
> HTML5 may have some nice light-weight options for OPs, but we would need
> another way as well.  Browser-compatibility with HTML5 isn't dominant enough
> to forget about the older, non-compliant browsers.  The iFrame is not a bad
> idea either, but I was thinking about an AJAX or JQuery library since
> JavaScript is more portable than any server-side implementation.
> -Daniel
>
>
> --- On *Mon, 12/14/09, John Panzer <jpanzer at google.com>* wrote:
>
>
> From: John Panzer <jpanzer at google.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
> Date: Monday, December 14, 2009, 9:19 AM
>
> Wondering how to avoid additional round trips... and if there's
> anything in html5 that would let OPs advertise existence of sessions
> client side.
>
> Or if there should be (perhaps generalized to a service discovery
> service on the client).
>
> On Monday, December 14, 2009, 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
> >
>
> --
> --
> John Panzer / Google
> jpanzer at google.com<http://us.mc1123.mail.yahoo.com/mc/compose?to=jpanzer@google.com>/
> abstractioneer.org / @jpanzer
> _______________________________________________
> 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://lists.openid.net/mailman/listinfo/openid-specs
>
>


-- 
http://hi.im/santosh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20091214/d976f172/attachment.htm>


More information about the specs mailing list