[OpenID] An Ode to OpenID

Tue Sep 8 11:27:24 UTC 2009

On Tue, Sep 8, 2009 at 10:56 AM, Santosh Rajan<santrajan at gmail.com> wrote:
> I also got a post in private from an foaf guy, that he can do authentication
> from the browser. It makes sense to me, though i don't know much about foaf.
> Please do post the same thing here, bcos i can't understand why you did not
> post it for everyone. (I dont think OPenID general, has any IP issues).

As requested:

http://blogs.sun.com/bblfish/entry/join_the_foaf_ssl_community

I didnt post to the main list, as I wasnt sure it was on topic, and
this link has been recently posted by Henry Story from Sun.

We've been using a form of SSO in the browser for a while.  It may not
be for everyone, but I find it works pretty well...

>
> On Tue, Sep 8, 2009 at 2:09 PM, Santosh Rajan <santrajan at gmail.com> wrote:
>>
>> Hey Peter,
>> The article was written on June 23, and was actually meant for the layman,
>> also, I did not understand the ramifications completely at that point in
>> time.
>> As I had promised in that article,that I would demonstrate with an example
>> in a future post. But I never got around to doing that post, because that is
>> when it hit me "the browser will manage your XRD". No matter how you conduct
>> that experiment, the browser will always be at the center. No escaping that.
>> And that is a whole new ball game. No discovery, no delegation. It is all
>> about the user. (Whatever he wants to identify himself with).
>>
>>
>> On Tue, Sep 8, 2009 at 1:53 PM, Peter Williams <pwilliams at rapattoni.com>
>> wrote:
>>>
>>> The article makes scant reference to any federated sso - where federated
>>> means talking to someone in a foreign security domain that you don't
>>> control.
>>>
>>> At the same time, it does seem to validate the infocard message -invoking
>>> a secure window manager for sensitive operations. Can we characterize chrome
>>> (in a secure window manager) as an alternative to the Microsoft infocard
>>> support?
>>>
>>> Let's not forget that openid and infocard signalling have a shared
>>> history.
>>>
>>>
>>>
>>> On Sep 7, 2009, at 10:11 PM, "Santosh Rajan"
>>> <santrajan at gmail.com<mailto:santrajan at gmail.com>> wrote:
>>>
>>> Hehe, the ode was supposed to make you laugh. I am sorry it didn't.
>>>
>>> What is actually most interesting, short of pimping my own blog, is
>>> "federated identity in browsers".
>>>
>>> I have been working on it for a couple on months with some unbeleivable
>>> results.
>>>
>>> A few days back
>>> readwriteweb<http://www.readwriteweb.com/archives/google_chrome_os_to_feature_single_sign-on.php>
>>> posted about Google Single sign on in the new chrome OS. Their conclusions
>>> are ridiculous, even though the actual result of such a move is very
>>> exciting.
>>>
>>>  The results of my experiments in "Federated Identity in browsers" have
>>> proven that, there will be no "Discovery or Delegation" any more. Thats
>>> right!
>>>
>>> Think about it. Your Browser would store and manage your XRD. Browser
>>> vendors would be "KING".
>>>
>>> Thats when you realize what a bunch of idiots the XRI TC is made of.
>>>
>>>
>>>
>>>
>>> On Tue, Sep 8, 2009 at 6:53 AM, Peter Williams
>>> <<mailto:pwilliams at rapattoni.com>pwilliams at rapattoni.com<mailto:pwilliams at rapattoni.com>>
>>> wrote:
>>>
>>> The not particularly interesting ode video led me to your (much more
>>> interesting) blog site, one of whose entries talked about delegation using
>>> Opera Unite. No odes were ever found, but one odyssey did result.
>>>
>>>
>>>
>>> 1. I followed the instructions, and got myself a vanity openid:
>>> <http://home.homepw.operaunite.com/a> http://home.homepw.operaunite.com/a
>>> that delegates to <http://homepw.myopenid.com>
>>> homepw.myopenid.com<http://homepw.myopenid.com>
>>>
>>>
>>>
>>> This is cute, because it only seems to work when I'm online (since only
>>> then is the index.html doing the delegation available to relying party
>>> sites).
>>>
>>>
>>>
>>> Used at Slashdot (based on Janrain’s RPX integration, I believe),
>>> <http://home.homepw.operaunite.com/a> http://home.homepw.operaunite.com/a
>>> got me to the Slashdot account linking screen. It failed at Plaxo.
>>>
>>>
>>>
>>>
>>>
>>> 2. So then I went to another RP, <http://freexri.com>
>>> freexri.com<http://freexri.com> and hit the login button (using the openid
>>> signin option). Obviously, I supplied my shiny new vanity name from
>>> operaunite: <http://home.homepw.operaunite.com/a>
>>> http://home.homepw.operaunite.com/a. Things properly pinged back to
>>> myopenid, and I authorized release of an assertion and the null persona of
>>> attributes.
>>>
>>>
>>>
>>> 3. I created myself a shiny new XRI, which is called
>>> @id*<http://home.homepw.operaunite.com>home.homepw.operaunite.com<http://home.homepw.operaunite.com>,
>>> using my current account which has several XRIs (you may need a new account,
>>> if this is your first time through XRI land), providing the capcha.
>>> Thereafter, I selected the option for the XRI that it would have an openid
>>> i-service attached. That is: I now have
>>> @id*<http://home.homepw.operaunite.com>home.homepw.operaunite.com<http://home.homepw.operaunite.com>
>>> delegating to <http://home.homepw.operaunite.com/a>
>>> http://home.homepw.operaunite.com/a (which ...delegates to ...). If I do XRI
>>> resolution on that name, I see all  that properly reflected in the XRD
>>> markup, using local name of <http://home.homepw.operaunite.com/a>
>>> http://home.homepw.operaunite.com/a (operating under the openid (not XRI)
>>> semantics of an local name since the local name is in the SEP/link, not the
>>> XRD body).
>>>
>>>
>>>
>>> 4. I logged out of the RP, fully. Logging back in to this RP (nominally
>>> to create a synonym to next see if the polyarchical stuff really "works"
>>> with delegation), I obviously now cited my shiny new XRI
>>> @id*<http://home.homepw.operaunite.com>home.homepw.operaunite.com<http://home.homepw.operaunite.com>.
>>> The myopenid page eventually showed, but wants me to  solve this:
>>>
>>>
>>>
>>> "myOpenID is not authorized to verify that
>>> "@!B1E8.C27B.E41C.25C3!5adb.130d.2ac2.be9e" is your identifier. If it is
>>> your identifier, you can set up myOpenID to verify it. See the help page for
>>> more information."
>>>
>>>
>>>
>>> How can I do this in my XRD? (Assume I login to the <http://freexri.com>
>>> freexri.com<http://freexri.com> RP locally, to get back my admin privileges,
>>> since Im operating a master XRI account)
>>>
>>>
>>>
>>> 5. Then I did the same at plaxo, for
>>> @id*<http://home.homepw.operaunite.com>home.homepw.operaunite.com<http://home.homepw.operaunite.com>
>>>
>>>
>>>
>>> This time I got
>>>
>>>
>>>
>>> "myOpenID is not authorized to verify that
>>> "<http://home.homepw.operaunite.com/a/content/>http://home.homepw.operaunite.com/a/content/"
>>> is your identifier. If it is your identifier, you can set up myOpenID to
>>> verify it. See the help page for more information."
>>>
>>>
>>>
>>> To solve THIS one, I think I need merely put the magic "proof" file (that
>>> proves control over the "domain") onto the webserver under the above path.
>>> Does this feel correct? If so, Ill add the myopenid proof file to my file
>>> system (!).
>>>
>>>
>>>
>>> 6. Remembering that my XRI also has a +contact i-service bound to it,
>>> with its own delegations built in to the HXRI variant of my XRI, I had a
>>> look at the contact page that one gets from following 302's issued by the
>>> <https://xri.freexri.com/@id*home.homepw.operaunite.com>
>>> https://xri.freexri.com/@id*home.homepw.operaunite.com.
>>>
>>>
>>>
>>> At the end of the chain, at
>>> <http://contact.freexri.com/contact/@id*home.homepw.operaunite.com>
>>> http://contact.freexri.com/contact/@id*home.homepw.operaunite.com
>>>
>>>
>>>
>>> We see the HTML-centric metadata:
>>>
>>>
>>>
>>> <link rel="openid.server"
>>> href="<http://www.myopenid.com/server>http://www.myopenid.com/server" />
>>>
>>> <link rel="openid2.provider"
>>> href="<http://www.myopenid.com/server>http://www.myopenid.com/server" />
>>>
>>> <link rel="openid.delegate"
>>> href="<http://xri.net/http://home.homepw.operaunite.com/a/content/>http://xri.net/http://home.homepw.operaunite.com/a/content/"
>>> />
>>>
>>> <link rel="openid2.local_id"
>>> href="<http://xri.net/http://home.homepw.operaunite.com/a/content/>http://xri.net/http://home.homepw.operaunite.com/a/content/"
>>> />
>>>
>>>
>>>
>>>
>>>
>>> I find it strange that one resolution of the contact service at XRI proxy
>>> would delegate to the synonmy resolution service at another proxy.
>>> Additionally, the form of the local_id looks weird, but is not actually
>>> illegal, apparently.  But, let’s try it at the plaxo. anyways.
>>>
>>>
>>>
>>> After ignoring the problems with the https variant (since plaxo  doesn’t
>>> know about the freexri SSL cert domain), we got
>>>
>>>
>>>
>>> myOpenID is not authorized to verify that
>>> <http://xri.net/http://home.homepw.operaunite.com/a/content/>
>>> http://xri.net/http://home.homepw.operaunite.com/a/content/ is your
>>> identifier. If it is your identifier, you can set up myOpenID to verify it.
>>> See the help page<https://www.myopenid.com/help#own_domain> for more
>>> information.
>>>
>>>
>>>
>>> Well at least that’s familiar. How do I now fiddle around with XRI/XRD or
>>> my contact page so I can make myopenid happy?
>>>
>>>
>>>
>>>
>>>
>>> 7 I find it strange that Slashdot could get myopenid to assert for my
>>> opera delegation uri but myopenid will not react to more advanced cases.
>>>
>>>
>>>
>>> There seems to be a distinction being drawn, between delegation and
>>> delegation for domains. The former is detected and myopenid finds it
>>> acceptable to make an assertion, but the latter cases require additional
>>> proof over control of the domain/URL.
>>>
>>>
>>>
>>> I wish the spec was clear on all this!
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: <mailto:openid-general-bounces at lists.openid.net>
>>> openid-general-bounces at lists.openid.net<mailto:openid-general-bounces at lists.openid.net>
>>> [mailto:<mailto:openid-general-bounces at lists.openid.net>openid-general-bounces at lists.openid.net<mailto:openid-general-bounces at lists.openid.net>]
>>> On Behalf Of Santosh Rajan
>>> Sent: Monday, September 07, 2009 12:13 PM
>>> To: <mailto:general at openid.net>
>>> general at openid.net<mailto:general at openid.net>
>>> Subject: [OpenID] An Ode to OpenID
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> <http://www.youtube.com/watch?v=ztc4V3ttlso&feature=related>http://www.youtube.com/watch?v=ztc4V3ttlso&feature=related
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> -----
>>>
>>>
>>>
>>> Santosh Rajan
>>>
>>> <http://santrajan.blogspot.com>http://santrajan.blogspot.com
>>> <http://santrajan.blogspot.com> http://santrajan.blogspot.com
>>>
>>> --
>>>
>>> View this message in context:
>>> <http://www.nabble.com/An-Ode-to-OpenID-tp25335016p25335016.html>
>>> http://www.nabble.com/An-Ode-to-OpenID-tp25335016p25335016.html
>>>
>>> Sent from the OpenID - General mailing list archive at
>>> Nabble.com<http://Nabble.com>.
>>>
>>>
>>>
>>> _______________________________________________
>>>
>>> general mailing list
>>>
>>>
>>> <mailto:general at lists.openid.net>general at lists.openid.net<mailto:general at lists.openid.net>
>>>
>>>
>>> <http://lists.openid.net/mailman/listinfo/openid-general>http://lists.openid.net/mailman/listinfo/openid-general
>>>
>>>
>>>
>>> --
>>> <http://santrajan.blogspot.com>http://santrajan.blogspot.com
>>> <http://twitter.com/santoshrajan>http://twitter.com/santoshrajan
>>>
>>> <http://www.facebook.com/santosh.rajan>http://www.facebook.com/santosh.rajan
>>>
>>>
>>
>>
>>
>> --
>> http://santrajan.blogspot.com
>> http://twitter.com/santoshrajan
>> http://www.facebook.com/santosh.rajan
>>
>>
>
>
>
> --
> http://santrajan.blogspot.com
> http://twitter.com/santoshrajan
> http://www.facebook.com/santosh.rajan
>
>
>
> _______________________________________________
> general mailing list
> general at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general
>
>