<?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: OpenID is useless</title>
	<atom:link href="http://www.chickenwingsw.com/scratches/programming/openid-is-useless/feed" rel="self" type="application/rss+xml" />
	<link>http://www.chickenwingsw.com/scratches/programming/openid-is-useless</link>
	<description>Developing ideas on developing.</description>
	<lastBuildDate>Fri, 20 May 2011 10:39:44 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.1.2</generator>
	<item>
		<title>By: Mike</title>
		<link>http://www.chickenwingsw.com/scratches/programming/openid-is-useless/comment-page-1#comment-21228</link>
		<dc:creator>Mike</dc:creator>
		<pubDate>Sat, 29 Jan 2011 17:51:03 +0000</pubDate>
		<guid isPermaLink="false">http://www.chickenwingsoftware.com/scratches/programming/openid-is-useless#comment-21228</guid>
		<description>Love Scopa, btw.
&lt;br /&gt;&lt;br /&gt;
Anyway, not sure when this article was written, but janrain&#039;s RPXnow completely eliminates the barriers to OpenID.
&lt;br /&gt;&lt;br /&gt;
I had similar issues trying to implement on my own site.  My biggest one, though, was the barrier to entry because the user had to know what his/her &#039;uri&#039; was!
&lt;br /&gt;&lt;br /&gt;
I currently use the free version of RPXnow, where the only real drawback is that the redirect is to .rpxnow.com instead of my own domain, which may make some people feel uneasy.
&lt;br /&gt;&lt;br /&gt;
From what I&#039;ve seen from your site, I imagine that you could probably write your own framework to simplify the experience for users and get back the info that you need (that they allow you to see).
&lt;br /&gt;&lt;br /&gt;
One more comment about getting &quot;info&quot; on the users.  &lt;br /&gt;
While it would be great for users to be able to fill in their personal info (name) with their openid provider and then share that with the openid consumers, many people would feel more comfortable simply authenticating and filling in their details separately for each site.
&lt;br /&gt;&lt;br /&gt;
Basically, to use your sites with openid, you would still need to register, but use an openid instead of creating a new username/password on your site.
&lt;br /&gt;&lt;br /&gt;
You still need to have a user db, but don&#039;t have to deal with passwords, etc.
&lt;br /&gt;&lt;br /&gt;
You could still even allow people to use the site unregistered, and just enter a temporary name and not store any info about him/her.&lt;br /&gt;</description>
		<content:encoded><![CDATA[Love Scopa, btw.
<br /><br />
Anyway, not sure when this article was written, but janrain's RPXnow completely eliminates the barriers to OpenID.
<br /><br />
I had similar issues trying to implement on my own site.  My biggest one, though, was the barrier to entry because the user had to know what his/her 'uri' was!
<br /><br />
I currently use the free version of RPXnow, where the only real drawback is that the redirect is to .rpxnow.com instead of my own domain, which may make some people feel uneasy.
<br /><br />
From what I've seen from your site, I imagine that you could probably write your own framework to simplify the experience for users and get back the info that you need (that they allow you to see).
<br /><br />
One more comment about getting "info" on the users.  <br />
While it would be great for users to be able to fill in their personal info (name) with their openid provider and then share that with the openid consumers, many people would feel more comfortable simply authenticating and filling in their details separately for each site.
<br /><br />
Basically, to use your sites with openid, you would still need to register, but use an openid instead of creating a new username/password on your site.
<br /><br />
You still need to have a user db, but don't have to deal with passwords, etc.
<br /><br />
You could still even allow people to use the site unregistered, and just enter a temporary name and not store any info about him/her.<br />]]></content:encoded>
	</item>
</channel>
</rss>

