On 20 Jul 2011, at 03:26, John Kemp wrote: > Hi Dick, > > On Jul 19, 2011, at 9:08 PM, Dick Hardt wrote: > >> As for one of the major advantages of BrowserID: it is a user-centric >> architecture unlike OpenID Connect. > > Can you explain what you mean by "user-centric" in this context? As far as I > can tell, the "verified email" protocol > (https://wiki.mozilla.org/Identity/Verified_Email_Protocol/Latest) 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 browserid.org, 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...
If you want a user centric protocol that works now - and with 10 years old browsers even - then you may want to try WebId http://webid.info/ - 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. It requires TLS Client certificates as of now. 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. http://security.stackexchange.com/questions/5406/what-are-the-main-advantages-and-disadvantages-of-webid-compared-to-browserid/5424 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. So if we were all a bit flexible we could all work with web architecture and together. Henry > > Cheers, > > - John > >> >> -- Dick >> >> On 2011-07-19, at 12:39 AM, Nat Sakimura wrote: >> >>> Relying party using somebody's email address as login name and site >>> specific password was screwed today as you say. >>> We should fix the problem. >>> >>> Email providers can actually distinguish between the old user and new user, >>> and password reset by email does not cross the old and new accounts so they >>> are not plagued by this problem. They should help the situation. One idea >>> for BrowserID is for the email provider to issue a certificate that >>> includes a canonical identifier of the user. Then, relying parties can use >>> that as the identifier and email as an attribute. In OpenID term, email is >>> the user supplied identifier and the unique string is the canonical >>> identifier. >>> >>> =nat >>> >>> On Tue, Jul 19, 2011 at 2:14 PM, Allen Tom <[email protected]> wrote: >>> Email address recycling is an important issue, but since the status quo >>> (password reset via email) doesn't address the recycling issue, perhaps >>> it's not necessary to solve it. >>> >>> It is important that RPs allow users to change their email address to >>> prevent their RP account from being taken over if they lose the email >>> address that they used to create the account. Perhaps that's good enough? >>> >>> Allen >>> >>> >>> On Mon, Jul 18, 2011 at 10:02 PM, Nat Sakimura <[email protected]> wrote: >>> One of my concern around BrowserID is that it does not seem to take care of >>> the email address recycling. >>> Email address verification "certificate" may be short lived but it does not >>> solve the impersonation problem at all. >>> There has to be some ways of canonicalizing email address into a >>> non-re-assignable identifier. >>> Otherwise we are screwed and BrowserID spec does not yet provide the >>> solution. >>> >>> As a conceptual solution, BrowserID is interesting if the browsers >>> implements it and if we can get rid of BrowserID.org. >>> I would like to see more work towards. it. >>> >>> =nat >>> >>> On Tue, Jul 19, 2011 at 1:05 PM, Allen Tom <[email protected]> wrote: >>> Yeah, I totally agree - I was referring to a hypothetical protocol that's >>> similar to OpenID Connect, but uses email addresses as the true identifier. >>> >>> I don't see how BrowserID would be better than a version of OpenID Connect >>> that only uses email addresses as the one true identifier. >>> >>> Allen >>> >>> >>> >>> On Mon, Jul 18, 2011 at 8:51 PM, Phillip Hallam-Baker <[email protected]> >>> wrote: >>> There is an advantage to throwing out the bad identifiers, It allows the >>> user interface to be made a lot simpler as anything not an email address is >>> wrong. >>> >>> No URLs, no XRIs. >>> >>> >>> As for what to do if the email provider does not provide BrowserID, I don't >>> think it is a problem, I would probably separate the accounts in any case. >>> >>> >>> _______________________________________________ >>> specs mailing list >>> [email protected] >>> http://lists.openid.net/mailman/listinfo/openid-specs >>> >>> >>> >>> >>> -- >>> Nat Sakimura (=nat) >>> Chairman, OpenID Foundation >>> http://nat.sakimura.org/ >>> @_nat_en >>> >>> >>> >>> >>> >>> -- >>> Nat Sakimura (=nat) >>> Chairman, OpenID Foundation >>> http://nat.sakimura.org/ >>> @_nat_en >>> >>> _______________________________________________ >>> specs mailing list >>> [email protected] >>> http://lists.openid.net/mailman/listinfo/openid-specs >> >> _______________________________________________ >> specs mailing list >> [email protected] >> http://lists.openid.net/mailman/listinfo/openid-specs > > _______________________________________________ > specs mailing list > [email protected] > http://lists.openid.net/mailman/listinfo/openid-specs Social Web Architect http://bblfish.net/ _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
