<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Client Side OpenID</title>
	<atom:link href="http://blogs.gnome.org/jamesh/2008/02/18/client-side-openid/feed/" rel="self" type="application/rss+xml" />
	<link>http://blogs.gnome.org/jamesh/2008/02/18/client-side-openid/</link>
	<description>Random stuff</description>
	<lastBuildDate>Wed, 28 Oct 2009 02:53:32 +0800</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.5.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Kevin Turner</title>
		<link>http://blogs.gnome.org/jamesh/2008/02/18/client-side-openid/comment-page-1/#comment-615</link>
		<dc:creator>Kevin Turner</dc:creator>
		<pubDate>Tue, 19 Feb 2008 18:34:15 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/jamesh/2008/02/18/client-side-openid/#comment-615</guid>
		<description>&lt;a href=&quot;https://pip.verisignlabs.com/seatbelt.do&quot; rel=&quot;nofollow&quot;&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&#039;t so bad as you might think.  There&#039;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-page-1/#comment-612</link>
		<dc:creator>James</dc:creator>
		<pubDate>Tue, 19 Feb 2008 12:18:13 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/jamesh/2008/02/18/client-side-openid/#comment-612</guid>
		<description>The &lt;a href=&quot;http://simile.mit.edu/wiki/Appalachian&quot; rel=&quot;nofollow&quot;&gt;Simile Appalachian OpenID extension&lt;/a&gt; has some amount of &lt;a href=&quot;http://simile.mit.edu/wiki/Appalachian_Anti-Phishing&quot; rel=&quot;nofollow&quot;&gt;phishing protection&lt;/a&gt; in it, I haven&#039;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-page-1/#comment-609</link>
		<dc:creator>James Henstridge</dc:creator>
		<pubDate>Tue, 19 Feb 2008 11:07:55 +0000</pubDate>
		<guid isPermaLink="false">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&#039;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-page-1/#comment-607</link>
		<dc:creator>Dirk Gently</dc:creator>
		<pubDate>Mon, 18 Feb 2008 23:55:08 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/jamesh/2008/02/18/client-side-openid/#comment-607</guid>
		<description>Nice to hear someone is thinking about this.  I&#039;ve heard of this kick and just can&#039;t seem to understand why it&#039;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&#039;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-page-1/#comment-602</link>
		<dc:creator>Frej Soya</dc:creator>
		<pubDate>Mon, 18 Feb 2008 22:19:37 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/jamesh/2008/02/18/client-side-openid/#comment-602</guid>
		<description>I&#039;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&quot;applications&quot; 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&#039;t sure if it actually increased security, and I didn&#039;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 &#8211; so it seems like a good place for an openid-provider.</p>
<p>But the out-of-band extra security dawned on me &#8211; there already is a xmpp connection from mugshot client to server &#8211;  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/tango/face-smile.png' alt=':)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: John Drinkwater</title>
		<link>http://blogs.gnome.org/jamesh/2008/02/18/client-side-openid/comment-page-1/#comment-601</link>
		<dc:creator>John Drinkwater</dc:creator>
		<pubDate>Mon, 18 Feb 2008 18:47:23 +0000</pubDate>
		<guid isPermaLink="false">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-page-1/#comment-600</link>
		<dc:creator>steve</dc:creator>
		<pubDate>Mon, 18 Feb 2008 18:47:02 +0000</pubDate>
		<guid isPermaLink="false">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&#039;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-page-1/#comment-599</link>
		<dc:creator>Owen Taylor</dc:creator>
		<pubDate>Mon, 18 Feb 2008 18:02:02 +0000</pubDate>
		<guid isPermaLink="false">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&#039;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&#039;s and with information card RP&#039;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-page-1/#comment-598</link>
		<dc:creator>Matthew</dc:creator>
		<pubDate>Mon, 18 Feb 2008 14:40:53 +0000</pubDate>
		<guid isPermaLink="false">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-page-1/#comment-597</link>
		<dc:creator>Rob J. Caskey</dc:creator>
		<pubDate>Mon, 18 Feb 2008 13:49:57 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/jamesh/2008/02/18/client-side-openid/#comment-597</guid>
		<description>Christopher:

I&#039;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&#039;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>
