Heh, yeah, we violently agree. My note about Facebook contemplating being a browser maker was more along the idea that they would be a navigator.auth.get provider, which would tie users back to their revenue engine^W^Wcustomer base, similar to how Chrome works. Possibly they may argue that there be the ability for users to elect a "Trusted Auth Provider" so that users can specify Facebook as their provider of choice. Not terribly sure I'd agree to that, but I get their stand.
On 7/29/2015 2:04 PM, Sean McArthur wrote: > The identifier doesn't have to be an email, though that does seem to > be the most common form. A URL works too, so OpenID isn't excluded. > > I'm not interested in getting Facebook to accept my Gmail login (that > could be nice, though). They have the proper talent and expertise to > safeguard my data (read: password). I want all the other smaller > sites, such as Hacker News, or Feedly, or Evernote, to accept a JWT > from `navigator.auth.get()`, instead of keeping a copy of my password > in their database. > > Also, I don't see Facebook needing to make a browser in order to be > usable with `navigator.auth.get`. As the post mentions, the details of > how are left up to each browser, but it should be possible for any > browser to allow other accounts to be "logged in to the browser". I'd > hope that eventually, Firefox will have me signed in as my Gmail, > Twitter, Facebook, and Github accounts. Then, the picker that Firefox > would show would ask which of these 4 I want to share to the target > website. > > On Wed, Jul 29, 2015 at 12:43 PM JR Conlin <[email protected] > <mailto:[email protected]>> wrote: > > As a site grows, it becomes more and more interested in owning and > monetizing a given user. Taking a slight twist on that, what a > site cares most about is ensuring that a given user is both unique > and accountable. (e.g. they don't care if you're "daniel" or some > long string of crap. They'll ask you for lots of personal info if > they can't get it. "Accountable" means that they can resolve you > as a unique impression regardless of device or location.) > > I know that sites tend to distrust third parties pretty much for > the same reasons that users do, they're unknown and usually > rivals. The interesting take on the browser generating the ID is > that (with one notable exception) the browser manufacturer isn't a > direct competitor. This might entice facebook into offering their > own browser, but that's a different issue. > > My experience is strictly anecdotal, but the sites I dealt with > generally found account management kind of a pain in the butt, to > the point where they'll use some crappy account registry library > with horribly broken-bits. (see http://youfailatemail.com for one > of my response domains). If navigator.auth.get returns a unique, > accountable ID for a given user, there's a plug in for Wordpress, > phpbb and a few shopping portal packages, I think you're probably > golden. > > We're not going to get Facebook, Twitter, Amazon, or even Reddit > using this because they have too much invested in providing their > own login. You *might* get sites like Yahoo and news sites using it. > > On 7/29/2015 11:58 AM, Daniel Coates wrote: >> This is great, Sean! >> >> You wrote: >> >> "A website could ask for credentials from the navigator, and the >> browser can show its own trusted UI asking the user if and which >> ID to share to the website." >> >> I'm curious about "which ID" specifically. I like Persona a lot >> (obviously) but one of the things about it that I think holds it >> back is that it requires sites to give up control (and >> potentially availability) of the login process. So does OpenID, >> et al. >> >> It seems to me like the practice of outsourcing logins to a 3rd >> party service has mostly gone out of style. The story seems to >> go: "We're a startup, lets use Facebook for auth. We're doing >> well, lets transition to our own auth but allow signups with >> Facebook. Ok, lets get rid of Facebook." The more successful the >> site, the more they care about owning the login process because >> its a critical part of their business. Any general solution to >> the login problem needs to respect this. Fortunately, the >> user-agent is in a unique position to do this. >> >> Is your vision of `navigator.auth.get` as sort of an API to an >> enhanced password manager? - It handles the credentials, picker, >> etc, and sync handles distribution. For signups maybe we prefill >> with your sync profile data? I think that would be a significant >> improvement to login page AutoFill. It doesn't eliminate account >> / password growth, but it makes it less painful, and it works >> with the web we already have. >> >> On Wed, Jul 29, 2015 at 9:26 AM, Sean McArthur >> <[email protected] <mailto:[email protected]>> wrote: >> >> I've been thinking again about how we can stop using so many >> passwords across the web. Now that pretty much every browser >> can be signed-in-to, we could try to standardize a way of >> getting *that* account. >> >> Proposed: >> >> navigator.auth.get() -> Promise<JWT> >> >> Larger article: >> http://seanmonstar.com/post/125352745992/whats-the-password >> >> I have a contact on the Microsoft Edge team that largely >> agrees with the idea, and my next steps would be to try to >> contact people on Chromium and WebKit and see if this is >> something we could pursue. >> >> _______________________________________________ >> Dev-fxacct mailing list >> [email protected] <mailto:[email protected]> >> https://mail.mozilla.org/listinfo/dev-fxacct >> >> >> >> >> _______________________________________________ >> Dev-fxacct mailing list >> [email protected] <mailto:[email protected]> >> https://mail.mozilla.org/listinfo/dev-fxacct > > _______________________________________________ > Dev-fxacct mailing list > [email protected] <mailto:[email protected]> > https://mail.mozilla.org/listinfo/dev-fxacct >
_______________________________________________ Dev-fxacct mailing list [email protected] https://mail.mozilla.org/listinfo/dev-fxacct
