<?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: Warming up to OpenID</title>
	<atom:link href="http://dubroy.com/blog/warming-up-to-openid/feed/" rel="self" type="application/rss+xml" />
	<link>http://dubroy.com/blog/warming-up-to-openid/</link>
	<description>programming, usability, and interaction design</description>
	<lastBuildDate>Wed, 11 Aug 2010 20:40:29 -0700</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Nic Ferrier</title>
		<link>http://dubroy.com/blog/warming-up-to-openid/comment-page-1/#comment-175</link>
		<dc:creator>Nic Ferrier</dc:creator>
		<pubDate>Sat, 03 Mar 2007 12:45:24 +0000</pubDate>
		<guid isPermaLink="false">http://dubroy.com/blog/2007/02/26/warming-up-to-openid/#comment-175</guid>
		<description>&lt;p&gt;An alternative to Evan&#039;s really cool certifi.ca site it http://prooveme.com. We give you a free certificate as part of your sign up process (though we&#039;re planning to offer support for existing certs as well). In other respects it works the same as Evan&#039;s service. We believe though, that users creating certificates in order to delegate them to other services is a big win feature. Doing that would enable you to, say, delegate authority to flikr to upload photos to your blog.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>An alternative to Evan&#8217;s really cool certifi.ca site it <a href="http://prooveme.com" rel="nofollow">http://prooveme.com</a>. We give you a free certificate as part of your sign up process (though we&#8217;re planning to offer support for existing certs as well). In other respects it works the same as Evan&#8217;s service. We believe though, that users creating certificates in order to delegate them to other services is a big win feature. Doing that would enable you to, say, delegate authority to flikr to upload photos to your blog.</p>]]></content:encoded>
	</item>
	<item>
		<title>By: Evan Prodromou</title>
		<link>http://dubroy.com/blog/warming-up-to-openid/comment-page-1/#comment-169</link>
		<dc:creator>Evan Prodromou</dc:creator>
		<pubDate>Fri, 02 Mar 2007 16:08:05 +0000</pubDate>
		<guid isPermaLink="false">http://dubroy.com/blog/2007/02/26/warming-up-to-openid/#comment-169</guid>
		<description>&lt;p&gt;@Patrick: I&#039;m a big fan of public key encryption and the identity control that it brings. About the closest thing to an SSH key for HTTPS is client-side SSL certificates. That&#039;s what certifi.ca uses. Most Web sites don&#039;t support them because most Web users don&#039;t know they exist, and most Web users don&#039;t know they exist because most Web sites don&#039;t support them.&lt;/p&gt;

&lt;p&gt;There are links on the certifi.ca home page to sites where you can get gratis valid SSL certificates in a few minutes (email confirmation required). It&#039;s probably exactly what you&#039;re looking for. Please give it a try and let me know what you think.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>@Patrick: I&#8217;m a big fan of public key encryption and the identity control that it brings. About the closest thing to an SSH key for HTTPS is client-side SSL certificates. That&#8217;s what certifi.ca uses. Most Web sites don&#8217;t support them because most Web users don&#8217;t know they exist, and most Web users don&#8217;t know they exist because most Web sites don&#8217;t support them.</p>

<p>There are links on the certifi.ca home page to sites where you can get gratis valid SSL certificates in a few minutes (email confirmation required). It&#8217;s probably exactly what you&#8217;re looking for. Please give it a try and let me know what you think.</p>]]></content:encoded>
	</item>
	<item>
		<title>By: Patrick</title>
		<link>http://dubroy.com/blog/warming-up-to-openid/comment-page-1/#comment-156</link>
		<dc:creator>Patrick</dc:creator>
		<pubDate>Thu, 01 Mar 2007 17:21:55 +0000</pubDate>
		<guid isPermaLink="false">http://dubroy.com/blog/2007/02/26/warming-up-to-openid/#comment-156</guid>
		<description>&lt;p&gt;Evan:&lt;/p&gt;

&lt;p&gt;Yes, you&#039;re right that phishing is only a problem when password authentication is used. However, I think that it will be a while before most people will be using an alternative technique. One thing I was thinking about recently was an OpenID provider that could use public key authentication using my ssh key. That would be cool. Log in once (by typing the url in directly, or something safe), upload your public key, and then use ssh-agent authentication from then on. Then you could really have a single login to your machine, and it would work for everything.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>Evan:</p>

<p>Yes, you&#8217;re right that phishing is only a problem when password authentication is used. However, I think that it will be a while before most people will be using an alternative technique. One thing I was thinking about recently was an OpenID provider that could use public key authentication using my ssh key. That would be cool. Log in once (by typing the url in directly, or something safe), upload your public key, and then use ssh-agent authentication from then on. Then you could really have a single login to your machine, and it would work for everything.</p>]]></content:encoded>
	</item>
	<item>
		<title>By: Evan Prodromou</title>
		<link>http://dubroy.com/blog/warming-up-to-openid/comment-page-1/#comment-155</link>
		<dc:creator>Evan Prodromou</dc:creator>
		<pubDate>Thu, 01 Mar 2007 14:05:16 +0000</pubDate>
		<guid isPermaLink="false">http://dubroy.com/blog/2007/02/26/warming-up-to-openid/#comment-155</guid>
		<description>&lt;p&gt;I think that the phishing problem is mostly a red pherring (tee-hee). &lt;a href=&quot;http://certifi.ca/&quot; rel=&quot;nofollow&quot;&gt;certifi.ca&lt;/a&gt;, for example, is an OpenID provider that only uses SSL certs for authentication. There is never a password, so there&#039;s not a risk of phishing. I use certifi.ca as my main OpenID delegate, and I actually find using my OpenID considerably streamlined because of the certs-based authentication.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>I think that the phishing problem is mostly a red pherring (tee-hee). <a href="http://certifi.ca/" rel="nofollow">certifi.ca</a>, for example, is an OpenID provider that only uses SSL certs for authentication. There is never a password, so there&#8217;s not a risk of phishing. I use certifi.ca as my main OpenID delegate, and I actually find using my OpenID considerably streamlined because of the certs-based authentication.</p>]]></content:encoded>
	</item>
	<item>
		<title>By: Patrick</title>
		<link>http://dubroy.com/blog/warming-up-to-openid/comment-page-1/#comment-148</link>
		<dc:creator>Patrick</dc:creator>
		<pubDate>Tue, 27 Feb 2007 20:08:17 +0000</pubDate>
		<guid isPermaLink="false">http://dubroy.com/blog/2007/02/26/warming-up-to-openid/#comment-148</guid>
		<description>&lt;p&gt;Hmmm, I had to look at the spec to see where the crypto was involved, and I&#039;ll be honest, I don&#039;t fully understand it. I don&#039;t see why your proposal wouldn&#039;t work just as well.&lt;/p&gt;

&lt;p&gt;As for the phishing, I think browser integration is a good way to go. I don&#039;t think people would be changing their identity providers that often, so it wouldn&#039;t be a hassle to have to specify them in the plugin options. But I still think the bookmark-based solution described &lt;a href=&quot;http://usablesecurity.com/2007/01/20/phishing-and-openid/&quot; rel=&quot;nofollow&quot;&gt;here&lt;/a&gt; is the simplest.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>Hmmm, I had to look at the spec to see where the crypto was involved, and I&#8217;ll be honest, I don&#8217;t fully understand it. I don&#8217;t see why your proposal wouldn&#8217;t work just as well.</p>

<p>As for the phishing, I think browser integration is a good way to go. I don&#8217;t think people would be changing their identity providers that often, so it wouldn&#8217;t be a hassle to have to specify them in the plugin options. But I still think the bookmark-based solution described <a href="http://usablesecurity.com/2007/01/20/phishing-and-openid/" rel="nofollow">here</a> is the simplest.</p>]]></content:encoded>
	</item>
	<item>
		<title>By: e</title>
		<link>http://dubroy.com/blog/warming-up-to-openid/comment-page-1/#comment-146</link>
		<dc:creator>e</dc:creator>
		<pubDate>Tue, 27 Feb 2007 14:31:25 +0000</pubDate>
		<guid isPermaLink="false">http://dubroy.com/blog/2007/02/26/warming-up-to-openid/#comment-146</guid>
		<description>&lt;p&gt;I&#039;m not sold on OpenID. The idea behind it is very good, but it puts too much weight on crypto. I tried writing a WordPress plugin for it when the protocol first came out, but I didn&#039;t have the crypto extensions that I needed compiled into PHP. &lt;/p&gt;

&lt;p&gt;The goal of the system is to verify that a given user is associated with a website. I would like to see a lighter version of OpenId that performs its verification through publishing. In other words, the challenger would ask the user to verify themselves by making altering a webpage on the site to display a nonce of the challenger&#039;s choosing. &lt;/p&gt;

&lt;p&gt;Regarding OpenId and phishing: what about adding some browser integration to get around the phishing attack? That or a long-lived cookie that gave the site providing the auth service a different look would both allow the user to verify that they are at the site the expect, rather than a site of the attacker&#039;s choosing.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>I&#8217;m not sold on OpenID. The idea behind it is very good, but it puts too much weight on crypto. I tried writing a WordPress plugin for it when the protocol first came out, but I didn&#8217;t have the crypto extensions that I needed compiled into PHP. </p>

<p>The goal of the system is to verify that a given user is associated with a website. I would like to see a lighter version of OpenId that performs its verification through publishing. In other words, the challenger would ask the user to verify themselves by making altering a webpage on the site to display a nonce of the challenger&#8217;s choosing. </p>

<p>Regarding OpenId and phishing: what about adding some browser integration to get around the phishing attack? That or a long-lived cookie that gave the site providing the auth service a different look would both allow the user to verify that they are at the site the expect, rather than a site of the attacker&#8217;s choosing.</p>]]></content:encoded>
	</item>
</channel>
</rss>
<!-- WP Super Cache is installed but broken. The path to wp-cache-phase1.php in wp-content/advanced-cache.php must be fixed! -->