<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.3.3" -->
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	>
<channel>
	<title>Comments on: Client Side OpenID</title>
	<link>http://blogs.gnome.org/jamesh/2008/02/18/client-side-openid/</link>
	<description>Random stuff</description>
	<pubDate>Sun, 06 Jul 2008 16:43:43 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.3.3</generator>
		<item>
		<title>By: Kevin Turner</title>
		<link>http://blogs.gnome.org/jamesh/2008/02/18/client-side-openid/#comment-615</link>
		<dc:creator>Kevin Turner</dc:creator>
		<pubDate>Tue, 19 Feb 2008 18:34:15 +0000</pubDate>
		<guid>http://blogs.gnome.org/jamesh/2008/02/18/client-side-openid/#comment-615</guid>
		<description>&lt;a href="https://pip.verisignlabs.com/seatbelt.do" rel="nofollow"&gt;Seatbelt&lt;/a&gt;, Sxipper, and Information Cards are browser extensions that can all integrate with some existing OPs today.

The infocard WS-* goo isn't so bad as you might think.  There's a BSD-licensed python implementation for self-issued infocards that you can refer to at http://code.google.com/p/py-self-issued-rp/</description>
		<content:encoded><![CDATA[<p><a href="https://pip.verisignlabs.com/seatbelt.do" rel="nofollow">Seatbelt</a>, Sxipper, and Information Cards are browser extensions that can all integrate with some existing OPs today.</p>
<p>The infocard WS-* goo isn&#8217;t so bad as you might think.  There&#8217;s a BSD-licensed python implementation for self-issued infocards that you can refer to at <a href="http://code.google.com/p/py-self-issued-rp/" rel="nofollow">http://code.google.com/p/py-self-issued-rp/</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: James</title>
		<link>http://blogs.gnome.org/jamesh/2008/02/18/client-side-openid/#comment-612</link>
		<dc:creator>James</dc:creator>
		<pubDate>Tue, 19 Feb 2008 12:18:13 +0000</pubDate>
		<guid>http://blogs.gnome.org/jamesh/2008/02/18/client-side-openid/#comment-612</guid>
		<description>The &lt;a href="http://simile.mit.edu/wiki/Appalachian" rel="nofollow"&gt;Simile Appalachian OpenID extension&lt;/a&gt; has some amount of &lt;a href="http://simile.mit.edu/wiki/Appalachian_Anti-Phishing" rel="nofollow"&gt;phishing protection&lt;/a&gt; in it, I haven't investigated how much though.</description>
		<content:encoded><![CDATA[<p>The <a href="http://simile.mit.edu/wiki/Appalachian" rel="nofollow">Simile Appalachian OpenID extension</a> has some amount of <a href="http://simile.mit.edu/wiki/Appalachian_Anti-Phishing" rel="nofollow">phishing protection</a> in it, I haven&#8217;t investigated how much though.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: James Henstridge</title>
		<link>http://blogs.gnome.org/jamesh/2008/02/18/client-side-openid/#comment-609</link>
		<dc:creator>James Henstridge</dc:creator>
		<pubDate>Tue, 19 Feb 2008 11:07:55 +0000</pubDate>
		<guid>http://blogs.gnome.org/jamesh/2008/02/18/client-side-openid/#comment-609</guid>
		<description>alex, steve: the image/text customisation method is already in use at sites like myopenid.  Note however that the image needs to be associated with the computer (e.g. via a cookie with a large expiry time) rather than to anything the user types in.  If the OP displayed these sorts of customisations during an authentication request at a new computer, then a rogue RP could do the same by proxying the page.

Matthew, John: I am not too surprised to see that someone has done the out-of-band XMPP authentication solution (which is pretty cool!).  I haven't seen anything along the lines of the browser extension I outline, which I think could provide an interesting user experience.</description>
		<content:encoded><![CDATA[<p>alex, steve: the image/text customisation method is already in use at sites like myopenid.  Note however that the image needs to be associated with the computer (e.g. via a cookie with a large expiry time) rather than to anything the user types in.  If the OP displayed these sorts of customisations during an authentication request at a new computer, then a rogue RP could do the same by proxying the page.</p>
<p>Matthew, John: I am not too surprised to see that someone has done the out-of-band XMPP authentication solution (which is pretty cool!).  I haven&#8217;t seen anything along the lines of the browser extension I outline, which I think could provide an interesting user experience.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dirk Gently</title>
		<link>http://blogs.gnome.org/jamesh/2008/02/18/client-side-openid/#comment-607</link>
		<dc:creator>Dirk Gently</dc:creator>
		<pubDate>Mon, 18 Feb 2008 23:55:08 +0000</pubDate>
		<guid>http://blogs.gnome.org/jamesh/2008/02/18/client-side-openid/#comment-607</guid>
		<description>Nice to hear someone is thinking about this.  I've heard of this kick and just can't seem to understand why it's catching on.  The browser stores every password I possibly need and though OpenID would be super nice to joining a new site (heck it could even get rid of the signin form in alot of instances), I'm not about to trade security for it.  

FF3b4!??? hmmm.</description>
		<content:encoded><![CDATA[<p>Nice to hear someone is thinking about this.  I&#8217;ve heard of this kick and just can&#8217;t seem to understand why it&#8217;s catching on.  The browser stores every password I possibly need and though OpenID would be super nice to joining a new site (heck it could even get rid of the signin form in alot of instances), I&#8217;m not about to trade security for it.  </p>
<p>FF3b4!??? hmmm.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Frej Soya</title>
		<link>http://blogs.gnome.org/jamesh/2008/02/18/client-side-openid/#comment-602</link>
		<dc:creator>Frej Soya</dc:creator>
		<pubDate>Mon, 18 Feb 2008 22:19:37 +0000</pubDate>
		<guid>http://blogs.gnome.org/jamesh/2008/02/18/client-side-openid/#comment-602</guid>
		<description>I've been thinking/trying to get openid in mugshot/online.gnome.org (only broken patch so far on local disk). Mugshot would improve if it could auto-detect other web"applications" at sign-up time - so it seems like a good place for an openid-provider.

But the out-of-band extra security dawned on me - there already is a xmpp connection from mugshot client to server -  but I wasn't sure if it actually increased security, and I didn't stop to think about it.

Motivating that other people believes it does :)</description>
		<content:encoded><![CDATA[<p>I&#8217;ve been thinking/trying to get openid in mugshot/online.gnome.org (only broken patch so far on local disk). Mugshot would improve if it could auto-detect other web&#8221;applications&#8221; at sign-up time - so it seems like a good place for an openid-provider.</p>
<p>But the out-of-band extra security dawned on me - there already is a xmpp connection from mugshot client to server -  but I wasn&#8217;t sure if it actually increased security, and I didn&#8217;t stop to think about it.</p>
<p>Motivating that other people believes it does <img src='http://blogs.gnome.org/jamesh/wp-content/mu-plugins/tango-smilies/face-smile.png' alt=':)' class='wp-smiley' width='16' height='16' /></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: John Drinkwater</title>
		<link>http://blogs.gnome.org/jamesh/2008/02/18/client-side-openid/#comment-601</link>
		<dc:creator>John Drinkwater</dc:creator>
		<pubDate>Mon, 18 Feb 2008 18:47:23 +0000</pubDate>
		<guid>http://blogs.gnome.org/jamesh/2008/02/18/client-side-openid/#comment-601</guid>
		<description>James, You can achieve this using http://openid.xmpp.za.net/ (this does over-XMPP openid auth like you said), and sameplace.cc, an XMPP firefox extension. You receive a message when you go to log-in, and all you have to do is reply, and then the stall while waiting for http://openid.xmpp.za.net/ to load, unblocks and you log in to the RP. Pretty simple.

Personally I’m not going to touch all the *Card* stuff, seems a little ott and.. controlling, I’m quite happy using regular browser certs, the only thing needing improvement is the usability and awareness for newbs.</description>
		<content:encoded><![CDATA[<p>James, You can achieve this using <a href="http://openid.xmpp.za.net/" rel="nofollow">http://openid.xmpp.za.net/</a> (this does over-XMPP openid auth like you said), and sameplace.cc, an XMPP firefox extension. You receive a message when you go to log-in, and all you have to do is reply, and then the stall while waiting for <a href="http://openid.xmpp.za.net/" rel="nofollow">http://openid.xmpp.za.net/</a> to load, unblocks and you log in to the RP. Pretty simple.</p>
<p>Personally I’m not going to touch all the *Card* stuff, seems a little ott and.. controlling, I’m quite happy using regular browser certs, the only thing needing improvement is the usability and awareness for newbs.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: steve</title>
		<link>http://blogs.gnome.org/jamesh/2008/02/18/client-side-openid/#comment-600</link>
		<dc:creator>steve</dc:creator>
		<pubDate>Mon, 18 Feb 2008 18:47:02 +0000</pubDate>
		<guid>http://blogs.gnome.org/jamesh/2008/02/18/client-side-openid/#comment-600</guid>
		<description>I was going to suggest the exact same as Alex above. Require the user to upload some picture(or text for accessibility) that they'll recognise and expect when they go to their genuine site.</description>
		<content:encoded><![CDATA[<p>I was going to suggest the exact same as Alex above. Require the user to upload some picture(or text for accessibility) that they&#8217;ll recognise and expect when they go to their genuine site.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Owen Taylor</title>
		<link>http://blogs.gnome.org/jamesh/2008/02/18/client-side-openid/#comment-599</link>
		<dc:creator>Owen Taylor</dc:creator>
		<pubDate>Mon, 18 Feb 2008 18:02:02 +0000</pubDate>
		<guid>http://blogs.gnome.org/jamesh/2008/02/18/client-side-openid/#comment-599</guid>
		<description>To me, reducing the threat of phishing boils down to to one or both of two things: change around the interaction so that the user never expects to have to enter a password on the web, or to eliminate entirely the existence of a password that is useful to phish. Current methods of improving OpenID (require logging in beforehand, make your OP's page more verifiably authentic etc), all fall down, because they assume the existence of an alert user who understands what is going on and has a good sense of when something unusual happens.

Information Cards have some nice properties... in particular they have a well thought-out user interaction model that does not involve entering passwords into a web page. The biggest problem is probably is that implementing them brings in all sorts of WS-* goo. A client side OP sounds a bit like reinventing information cards. But I think at that point you have to ask what the goals are: to integrate into the OpenID ecosystem? to make things easier to implement by not having WS-*? etc. The worst thing would be to end up with the broken OpenID user interaction, but incompatible with both most OpenID RP's and with information card RP's.</description>
		<content:encoded><![CDATA[<p>To me, reducing the threat of phishing boils down to to one or both of two things: change around the interaction so that the user never expects to have to enter a password on the web, or to eliminate entirely the existence of a password that is useful to phish. Current methods of improving OpenID (require logging in beforehand, make your OP&#8217;s page more verifiably authentic etc), all fall down, because they assume the existence of an alert user who understands what is going on and has a good sense of when something unusual happens.</p>
<p>Information Cards have some nice properties&#8230; in particular they have a well thought-out user interaction model that does not involve entering passwords into a web page. The biggest problem is probably is that implementing them brings in all sorts of WS-* goo. A client side OP sounds a bit like reinventing information cards. But I think at that point you have to ask what the goals are: to integrate into the OpenID ecosystem? to make things easier to implement by not having WS-*? etc. The worst thing would be to end up with the broken OpenID user interaction, but incompatible with both most OpenID RP&#8217;s and with information card RP&#8217;s.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Matthew</title>
		<link>http://blogs.gnome.org/jamesh/2008/02/18/client-side-openid/#comment-598</link>
		<dc:creator>Matthew</dc:creator>
		<pubDate>Mon, 18 Feb 2008 14:40:53 +0000</pubDate>
		<guid>http://blogs.gnome.org/jamesh/2008/02/18/client-side-openid/#comment-598</guid>
		<description>Folks are already using XMPP to do it:
http://openid.xmpp.za.net/
http://sameplace.cc/wiki/openid-integration
for example.</description>
		<content:encoded><![CDATA[<p>Folks are already using XMPP to do it:<br />
<a href="http://openid.xmpp.za.net/" rel="nofollow">http://openid.xmpp.za.net/</a><br />
<a href="http://sameplace.cc/wiki/openid-integration" rel="nofollow">http://sameplace.cc/wiki/openid-integration</a><br />
for example.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Rob J. Caskey</title>
		<link>http://blogs.gnome.org/jamesh/2008/02/18/client-side-openid/#comment-597</link>
		<dc:creator>Rob J. Caskey</dc:creator>
		<pubDate>Mon, 18 Feb 2008 13:49:57 +0000</pubDate>
		<guid>http://blogs.gnome.org/jamesh/2008/02/18/client-side-openid/#comment-597</guid>
		<description>Christopher:

I'm going to me-to the anon fellow above me. Certs are the way of the future, and they should live on the Gnome keychain and be presented in a Cardspace like selector. RPs can select with set of authentication mechanisms they wish to support: my personal preference is that Infocard be the dominate one because Cardspace on windows solves the same problem fairly well, and there are no show-stopper problems with it. The MS-blessed term for generic implementations of Cardspace is Infocard.

There is already a Firefox plugin that sorta-worked last time I checked on it about 9 months ago, it lives at http://code.google.com/p/openinfocard/downloads/list, but I would love to see it in Gnome proper. SSL certs wouldn't be bad either, but gnome-integration is a must.</description>
		<content:encoded><![CDATA[<p>Christopher:</p>
<p>I&#8217;m going to me-to the anon fellow above me. Certs are the way of the future, and they should live on the Gnome keychain and be presented in a Cardspace like selector. RPs can select with set of authentication mechanisms they wish to support: my personal preference is that Infocard be the dominate one because Cardspace on windows solves the same problem fairly well, and there are no show-stopper problems with it. The MS-blessed term for generic implementations of Cardspace is Infocard.</p>
<p>There is already a Firefox plugin that sorta-worked last time I checked on it about 9 months ago, it lives at <a href="http://code.google.com/p/openinfocard/downloads/list," rel="nofollow">http://code.google.com/p/openinfocard/downloads/list,</a> but I would love to see it in Gnome proper. SSL certs wouldn&#8217;t be bad either, but gnome-integration is a must.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
