[OpenID] An Ode to OpenID

Tue Sep 8 21:39:53 UTC 2009

An interesting pointer for you Melvin.

http://www.fiddlercap.com/Fiddler/help/httpsclientcerts.asp

This lets the system proxy perform the SSL clientauth to the foaf+ssl provider, without involving the user's browser. It would be a bit of fun to play with. If your key provisioning site is already generating .p12 files, the link shows how to teach this proxy how to apply it for SSL client auth.

It would make sense for the (uncertified) cert you generate to have a URI that points to the users vanity URL site, whose links are marked to identity the (openid2.provider & openid2.localid relationship) and webid relationship. A foaf+ssl RP site can then apply its additional handling rules, mapping the result of a subsequent openid auth run to the webid based on the controls in the foaf file resolved from the webid. An openid site can choose to view it as a hint of the identifier that logically populates the openid form field on the RP site.

-----Original Message-----
From: Melvin Carvalho [mailto:melvincarvalho at gmail.com]
Sent: Tuesday, September 08, 2009 4:27 AM
To: Santosh Rajan
Cc: Peter Williams; general at openid.net
Subject: Re: [OpenID] An Ode to OpenID

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
>
>