Unlike WPA PSK, all of the real-world-usable EAP methods used in IEEE 802.1X EAPOL (&quot;WPA Enterprise&quot;) <i>require</i> client authentication, which must be provisioned out-of-band. Thus, effectively, they cannot be used for such deployments being discussed.<p>For example, EAP-TLS, unlike the TLS used in HTTPS, requires a client to provide a X.509 certificate signed by an AP-side trusted authority. This is because people like Jouni Malinen (hostapd&#x2F;wpa_supplicant), in all their wisdom, decided to spurn RFC 5216 (&quot;While the EAP server SHOULD require peer authentication, this is not mandatory, since there are circumstances...&quot;) and completely disallow any and all configuration to disable the client-cert requirement, regardless of any circumstances (such as those behind HTTPS). NYC DoITT is no more equipped to provision X.509 certs for free wifi users than the NYS DMV is to provision X.509 certs for $80 DL&#x2F;ID card holders (so people can securely prove their identity everywhere).<p>As trollian stated, Wi-Fi Alliance&#x27;s &quot;Passpoint&quot; (Hotspot 2.0) does allow for such setups, <i>technically</i>.  E.g., the vendor-specific WFA-UNAUTH-TLS version of EAP-TLS does not do client-side authentication at the WPA-level, as per RFC 5216. But WFA-UNAUTH-TLS, even among Passpoint-aware devices, is likely not widely supported.