<br><div><br><div class="gmail_quote">On Wed, Jul 20, 2011 at 3:01 PM, Henry Story <span dir="ltr"><<a href="mailto:henry.story@bblfish.net">henry.story@bblfish.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
On 20 Jul 2011, at 03:26, John Kemp wrote:<br>
<br>
> Hi Dick,<br>
><br>
> On Jul 19, 2011, at 9:08 PM, Dick Hardt wrote:<br>
><br>
>> As for one of the major advantages of BrowserID: it is a user-centric architecture unlike OpenID Connect.<br>
><br>
> Can you explain what you mean by "user-centric" in this context? As far as I can tell, the "verified email" protocol (<a href="https://wiki.mozilla.org/Identity/Verified_Email_Protocol/Latest" target="_blank">https://wiki.mozilla.org/Identity/Verified_Email_Protocol/Latest</a>) in use for BrowserID requires that the email provider generates a certificate verifying the email address, to the browser - I'm not sure how that is more user-centric than OpenID Connect... The default (canonical?) verifier is currently <a href="http://browserid.org" target="_blank">browserid.org</a>, but I'd imagine that they expect that FB et al will verify the email addresses of their users and essentially produce identity assertions for their users, albeit in this browser-mediated manner... doesn't seem too different from what your Sxipper plugin or Infocards were trying to do with OpenID really...<br>

<br>
</div>If you want a user centric protocol that works now - and with 10 years old browsers even - then you may want to try<br>
WebId <a href="http://webid.info/" target="_blank">http://webid.info/</a> - That was inspired by OpenID. It uses an http(s) url, but the user never sees it. It does not require control of an e-mail server to get one, so it is much more friendly to social networking services, and many other services that don't control the e-mail.<br>

<br>
It requires TLS Client certificates as of now.<br>
<br>
I have argued that if BrowserID does their thing right WebID authentication could also work with their JSON certificates, giving them RESTful attribute exchange too. By the way OpenId could also have RESTful attribute exchange.<br>

<br>
<a href="http://security.stackexchange.com/questions/5406/what-are-the-main-advantages-and-disadvantages-of-webid-compared-to-browserid/5424" target="_blank">http://security.stackexchange.com/questions/5406/what-are-the-main-advantages-and-disadvantages-of-webid-compared-to-browserid/5424</a><br>

<br>
What OpenID showed is that users don't like to type a http URL in their box. I'd go even further: it is better not to have to type anything, but just click. BrowserId does that but for some reason has a fixation on not distinguishing between the  identifier that the user *sees* and the identifier used by the protocol.<br>
</blockquote><div><br></div><div>I agree. If this "fixation" is removed, things gets much more palatable for many people. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
So if we were all a bit flexible we could all work with web architecture and together.<br></blockquote><div><br></div><div>+1 </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
Henry<br>
<div><div></div><div class="h5"></div></div></blockquote><div><br></div><div>-- </div></div>Nat Sakimura (=nat)<div>Chairman, OpenID Foundation<br><a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>
@_nat_en</div><br>
</div>