Future of Account Chooser WG

[Adam Dawes]

Hi Account Chooser WG,

The Account Chooser Working Group has been on a bit of a hiatus for the past year. I wanted to outline Google's perspective on the group and make some suggestions going forward.

From Google's side, we've pulled back investment for the following reasons:

• OpenYolo Android: When we initially started this project, there wasn't a good way for password managers to directly improve the experience of users. But then the Android framework launched the auto-fill framework which allows users to select their preferred password manager to work as the auto-fill provider. This didn't require any developer effort and thereby would get broader coverage with users. 
  
• OpenYolo Web: As we were working through the security implications of providing credentials via a javascript API, Apple launched ITP 2.0. Since then, much of the browser world has been contemplating similar features. The basic cross-site mechanism by which OpenYolo Web was going to work looks to be impossible on Safari and is likely problematic with other browsers. 
  
• Accountchooser.com: With users, developers and the media more focused on privacy, the current consent model of accountchooser.com seems outdated. We currently use a "what you see is what you give" model, providing name, email address and profile photo with a user click on the account chip. Google has several account chooser UIs and we've invested in updating these over the past year. I think accountchooser.com would also benefit from a similar modernization. Unfortunately, Google doesn't have the resources to do that work.
  
  Additionally, the upkeep of accountchooser.com needs changes. Symantec has dropped from corporate support of OIDF and they are no longer willing to support OIDF projects for free. We designed accountchooser.com so that it could not be manipulated by any party, so there was a division of responsibility between Symantec for DNS and security and Google for hosting. Now that Symantec is pulling back, we need to find a new resource to host DNS and provide certificates. Google can do this but it would go against previous goals of not having ac.com fully controlled by a single entity. 

Unless another person or organization would like to step up and lead the working group through these issues, I suggest that we wrap up the Account Chooser WG, move all operations to Google, deprecate accountchooser.com and turn it down in 2 years. The tool has a feature by which users can opt-out of accountchooser.com, so in the last year we would configure accountchooser.com to always respond such that all users would have accountchooser.com disabled. This way the service will provide no value to any implementers and will be the final warning to remove it from their sites. Anyone who wants to continue using it may if they are willing to host it; the code is open-sourced already with documentation. 

I don't view any of this as a failure of the WG at all. In fact, I think it has been a tremendous success. Through this group, we've learned a tremendous amount about good sign-in flows which we have put to wide use in our products. I think there is also an opportunity for building account chooser and identity into the browser, something that I know is being discussed by several browser builders. I think that is where effort would be best focused going forward.

If anyone would like to step forward and lead us to a different path, please do so by Feb 28. If no one does, we'll move forward with this plan.

thanks,

AD

--

Adam Dawes | Sr. Product Manager | ada...@google.com | +1 650-214-2410

[Adam Dawes]

Hi all,

To close this up, no one responded to this earlier message so the Working Group is now closed. 

I've posted the following message on accountchooser.net and will also have this posted on the Working Group site. 

July, 2019

The Account Chooser Working Group has agreed to close. 

The original charter was to explore and standardize new user interface experiences for the login process. The working group developed accountchooser.com, a service that would help users login by storing their different email accounts on the local device and then using those entries to bootstrap the login process at different web sites. 

While the use of accountchooser.com never became popular for a large number of web sites, the UX pattern that it pioneered is now common on major sites like Google, Facebook and others. Ultimately, the working group decided that this pattern is best implemented by browser and platform developers instead of as open source javascript. 

The accountchooser.com javascript tool will continue to operate normally through July 31, 2020. After that date, accountchooser.com will operate in “universal opt-out” mode, mimicking the behavior of users who choose to opt out of the service. This means that it will provide no value to web sites but will not break. On August 1, 2021, accountchooser.com will return 404 errors to any sites that integrate with it. 

Applications that want to continue using this feature can host and run it themselves by downloading the source code. 

I want to thank everyone for their contributions to the group and for improving the state of login UX.

thanks,

AD

On Thu, Feb 14, 2019 at 5:20 PM Steven Soneff <sso...@google.com> wrote:

Well put, very glad this can be closed out. Hope we can make progress on the browser side :)

--

---
You received this message because you are subscribed to the Google Groups "OIDF Account Chooser list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to oidf-account-choos...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Adam Dawes]

Hi all,

As part of the turn down of accountchooser, we've now hit our final milestone. By the end of today, we will be disabling accountchooser.com and accountchooser.net and any future requests will get 404 errors. 

Whois indicates that the accountchooser.com registration is good until July 29, 2022. I'm not sure if Google will automatically renew that next year or not. But if someone from the OIDF wants to do a domain transfer to continue reserving that domain, we can try to facilitate that.