On 7/11/07, <b class="gmail_sendername">Immad Akhund</b> <<a href="mailto:i.akhund@gmail.com">i.akhund@gmail.com</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<span class="q"><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote"><font size="2">
As to a local password, I would instead just use email as an account retrieval mechanism if needed.</font><br></blockquote></span><div><br>Assuming they have lost control of their previous openid; after they receive the account retrieval email wouldn't it make sense for them to setup a username/password to retrieve their account or would you think they should have a second openid ready to associate their account to?
</div></blockquote><div><br>I think this is a concern. The email address can be used to retrieve the account but some other authentication method would be needed for the user to access their online profile again. It seems to make sense to have a fallback local authen system so the user experience can be cleaner (no third party OP required to reestablish user access) and because at this time, it's uncertain how successful OpenID will be.
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>I personally think using a local fallback in the form of an optional username/password makes sense. But it's really up to the RP and its needs. Having a "captiveOpenID" doesn't make sense as a solution to this scenario since they would have to authorize that with a username/password anyway (I may be missing the meaning of captiveOpenID).
</div></blockquote><div><br>When I use the term Captive OpenID, I mean an OpenID system that is run by the RP. When the RP and the OP are the same, it is possible to set up the UI to look exactly like username/password and do the OpenID authen behind the scenes and there is no need for or indication to the user that OpenID is being used. It seems like if you restrict local "usernames" to not have periods, a username can never be mistaken for a fully qualified OpenID uri and the RP can just append their own domain name to the username to create the user's fully qualified captive OpenID uri.
<br><br>I've been thinking of having the local username/password be such a "Captive OpenID" under the covers but not necessarily known to the user. Advanced users can may be able to use the Captive OpenID at other sites by appending the RP/OP's domain name but there's no need for the average user to know OpenID is being used under the covers, especially if they won't care and it would slow adoption for the site.
<br><br>To make Captive OpenID work smoother, I'm also thinking of an OpenID authentication server SDK that will remove the need to make a HTTP redirect.</div></div><br>-- <br>John Wang<br><a href="http://www.dev411.com/blog/">
http://www.dev411.com/blog/</a>