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] > https://mail.mozilla.org/listinfo/dev-fxacct
_______________________________________________ Dev-fxacct mailing list [email protected] https://mail.mozilla.org/listinfo/dev-fxacct
