Historically we disable security types requiring a network for shared configurations since we did not have device certificate support.

Since that has changed we can change the UI, but that's really a feature request.

What is the priority for this? 72 might be doable, but 73 would be more reasonable.

(If priority is high and someone from Enterprise can take this, that would be great :) )

I had the impression that this used to work on the old settings on the sign-in screen, since we implemented device-wide EAP-TLS networks in M-60 (mainly  bug 655266  / https://codereview.chromium.org/2858113003) and I think I tested it back then. But I may be misremembering (and I suspect that customers using this usually just use the device policy to configure it).

Anyways, I can implement this for the new network settings UI, however I did not understand this sentence in the code:
    // If a network must be shared, hide the TLS option. Otherwise selecting
    // TLS will turn off and disable the shared state. NOTE: Ethernet EAP may
    // be set at the Device level, but will be saved as a User configuration.

"Otherwise selecting TLS will turn off and disable the shared state"
-> How would it do that / what exactly does this refer to?

https://cs.chromium.org/chromium/src/ui/webui/resources/cr_components/chromeos/network/network_config.js?type=cs&q=%22TLS+will+turn+off+and+disable%22&g=0&l=698

Thanks, now I'm set to implement this :-)

Thank you for splitting the original bug and taking this second point.

Hello!
This bug is receiving this notice because there has been no acknowledgment of its existence in quite a bit of time.
- If you are currently working on this bug, please provide an update.
- If you are currently affected by this bug, please update with your current symptoms and relevant logs.

If there has been no updates provided by EOD Thursday, 01/17/19 (5pm EST), this bug will be archived and can be re-opened at any time deemed necessary.

Thank you!

*activity*
I will discuss with pmarko@ in the next few days and can tackle this (assigning this bug to me then). I don't know how busy I will be until begining/mid of February, but can definitely do it then.

Handing over to acostinas@ instead (as discussed with atwilson@).
Happy to help, if you have any questions.

Thank you for the update!

@acostinas - would you be able to provide an ETA on when an update can be expected?

Hi! I'll talk to pmarko@ on Monday. Can't give an ETA now, but it doesn't look like a big change. Will keep you updated. 

I think that we should arrive at a state where
(*) On the sign-in screen, EAP-TLS wifi networks are unconditionally configurable. This is OK, because the client certificates available through the NetworkCertLoader will be exactly all device-wide client certificate while no user has signed in yet.
(*) In a user session, EAP-TLS wifi networks are configurable
   - with all available certificates for networks that are not shared (with other users on the device)
   - with device-wide certificates only for networks that are shared.

The question is how to do the second part with a UI that is not weird.
I guess we could repopulate the "User certificate" combobox when the "Shared network" checkbox' state changes.
For "Shared networks", we would populate with NetworkCertLoader::system_ca_certs, proxied through NetworkCertificateHandler.
For not "shared" networks, we would populate with all certificates.

For simplicity, we would probably just clear the current user certificate selection when switching between shared and not shared networks. Otherwise we'd have to see if the certificate is also in the other list and select that, and that's more work. But we could do that too :-)

One additional thing we may want to do is mark device-wide certificates in the selection list, so they'd look like:
Cert A [hardware-backed]
Cert B [device-wide, hardware-backed]

WDYT?

To be clear, I'd start with one CL doing the simple thing that's necessary to fix this bug. Then we can do the other things (reselecting cert if it's in the list we've switched to, marking certs as device-wide in the UI) when we have time.

I commented on the CL; the "simple" thing is not so simple. I suggested an option where we just allow TLS for shared networks in the login screen, but I think that filtering certificates for shared networks as suggested in comment #13 would actually be easiest (and best long term).

I also agree that specifying [device-wide] or [user-only] or somesuch would be a good idea.