Hi, sounds like you are describing something similar to navigator.credentials API? Since this is a feature request and not a vulnerability so I'm removing view restrictions.
Mike: Can you please triage?

This indeed sounds like Credential API [1] -- it allows websites to be more explicit about what is sign-in and sign-up, and results in Chrome not having to rely on heuristics, making it more reliable.

Other than that, this report is vague, so closing as WontFix.

[1] https://w3c.github.io/webappsec-credential-management/

It is not about production scenarios, sorry for the confusion. During production scenarios we have windows integrated authentication enabled and everything runs smoothly.

My request is about dev and test scenarios, we disable windows integrated authentication and we want explicit control about the identities we are applying during the scenarios. We have created several Chrome users and within each context we are using a separate identity. It is quite elaborate to having to log in to every domain separately in this case. Ideally the browser's identity management features enable us to really have a similar experience as if the windows integrated authentication were enabled.

I don't know how this new Credential API would apply to us, but unfortunately we don't have control on the http headers or authentication negotation that is happening so we cannot enforce any change in server-side behavior.

Thanks for the response. What exactly do you mean by identity management, though?

There is a password manager, which lets you save and fill usernam/password pairs.
There is also a cookie jar, which stores your login cookies as sites create and read them.

Could you elaborate what do you want Chrome to do instead of needing to log in sites on different domains separately?

Every once in a while when we work with a variety of our solutions we need to enter our credentials again. One of the causes could be because every deployment triggers a new dynamic hostname to be generated - the inherent mechanism of SharePoint hosted add-ins.
We work with a range of Chrome user sessions with a separate Windows identity each in order to test all the various security contexts. It is quite elaborate to always having to provide the username/password pair again and again. Evidently the password manager is not filled for these newly generated dynamic hostnames.
Ideally we store "identities" into the Chrome user sessions that can be easily reused across the different dynamic hostnames. Being able to define a rule like "apply this identity to the following hostname wildcard: *.toplevel.domain" would even more fantastic. The user experience would be almost the same if Windows integrated authentication were turned on.

Thanks for the explanation.

Does the "public suffix list matching" not work for your use-case? If you store a password on a.example.com and then visit a password form on b.example.com, the password stored on a.example.com will not be filled automatically, but you can just click the username field and get Chrome to fill it for you on-demand.

Failing that, the closest work-around I can think of is using the new (still experimental) import/export feature (bug 504138). You'll need Chrome version 52 or newer and you'll also need to activate the flag chrome://flags/#password-import-export for it (don't forget to restart Chrome afterwards). Once activated, chrome://settings/passwords will show Import and Export buttons.

You can use Export for a sample credential to figure out the format, it is a simple 4-column CSV with name (not useful for you), origin, username and password. If you are able to generate passwords for all domains you need (unfortunately, no wildcard is supported), then you can manually import those passwords. After that, Chrome should be filling them for you.

vabr: None of this solves the HTTP auth case, which is how some such systems work. This is different than, say, Safari on OS X, as HTTP auth is integrated into Keychain which has such wildcard rules.

That is, based on my understanding of the bug, there's a reasonable chance that the submitter is talking about the HTTP Auth flow (not forms auth), and how that is not integrated at all into the Password Manager flow, and thus doesn't take advantage of that password management functionality.

Thanks, rsleevi!

If this is about HTTP auth, then PSL matching won't work.

The import/export (tracked by bug 341477, in #7 I pasted the launch bug by accident) does not work for HTTP auth yet, but that's planned to be fixed ( bug 605934 ).

I leave this open for the requester to confirm which type of auth this is about, and whether some of the proposed solutions would work.

yes you have guessed correctly, it is about http auth. 

vabr: I don't think  Issue 605934  would fully meet this use case, then. Or at least, it'd be a workaround. It seems like supporting persisting credentials used in such auth scenarios would be a more complete solution. 

Wouldn't an extension work to address this? Namely, webRequest.onAuthRequired? Seems like all of the HTTP auth case could be met through that flow

The previous comments have been deleted for reasons unknown to me, but I'll post my answer anyway:

I'm afraid there is no extension API to access the password store.

For the webRequest API, please refer to the online documentation. It also contains a link to available sample code https://developer.chrome.com/extensions/samples#search:webrequest. I do not know more than what is written in the documentation.

I'm closing this feature request for now, because it does contain any concrete feature request. For support and advice, there are better places than the bugtracker: Google product forums, mailing lists or platforms like Stack Overflow.

I have been playing around with webRequest.onAuthRequired a bit today, and it looks very promising. Ideally such an extension should already be available, but we could also decide to build a simple one ourselves. 

Having used the documention on https://developer.chrome.com/extensions/webRequest, a couple of things are not clear yet:
1) I think there is an error in the documentation with regards to an unclear callback parameter to the callback-function of the addListener parameter. The callback parameter should contain a function that accepts a parameter of type BlockingResponse. I don't understand how a callee can specify a callback function. Reading further, outside of the onAuthRequired documentation, part of the general introduction of the webRequest API it is explained that every eventhandler of the blocking type can set a return object of type BlockingResponse. I tried to just specify the credentials in the return object by using the following code and this works:
return {
		authCredentials: {
			username: "username",
			password: "password"
		}
	}
2) Shared in the introduction of the onAuthRequired eventhandler the documentation states that one can explicitely take no action. But I don't understand how. Can you share an example. I guess just to return undefined.
3) how can I build user interaction that integrates with the chrome password store? E.g. when a username/password is available from the store let the user pick that, or else let the user enter new data and enter that into the store or my custom extension. My extension should only _extend_ the current password manager, not replace it.
4) My concern is that the extension can arrive in an endless loop, always providing wrong credentials, always triggering the event handler again and again. How can we prevent this? Maybe you can provide some sample code.

Thanks for all your help. Through Stack Overflow I found an extension that that does what we want: https://chrome.google.com/webstore/detail/basic-authentication-auto/dgpgkkfheijbcgjklcbnokoleebmeokn

Rectification; https://chrome.google.com/webstore/detail/multipass-for-http-basic/enhldmjbphoeibbpdhmjkchohnidgnah does what we want, i.e. includes regex for matching.