On Aug 12, 2025, at 10:06 AM, Q Misell <[email protected]> wrote: > This draft seems to only be for EAP-TLS, but uses the eap.arpa domain, not > tls.eap.arpa. Should this be changed?
Yes. > Secondly, for the 'laptop in coffee shop' example, which I see as the most > useful use for something like this, the draft seems a little lacking. After > I've connected to the local coffee shop WiFi with this protocol, what do I > (as a device) do next? Is a captive portal API mandatory? This draft is for onboarding, not for captive portal. The eap.arpa document defines "[email protected] <mailto:[email protected]>" for captive portal use. i.e. the unauthenticated coffee shop / airport WiFi. The existing captive portal processes can continue to be used for those situations. The onboarding document is for a different use-case. Perhaps the use here of "captive portal" in the introduction is confusing. It could instead be "limited network". The idea is that a device can get network access, perhaps using "[email protected] <mailto:[email protected]>". It then uses one of the onboarding protocols mentioned in the document to do the actual onboarding. > How do I transition to an unrestricted connection? This is the "full network access" mentioned in Section 3 (but not elsewhere). Once credentials have been provisioned, the device drops its current connection, and re-authenticates using the newly provisioned credentials. > What do I do with the output of EAP-TLS i.e. the verified domain name of the > server? The domain name of the server is typically not verified, so it doesn't matter. If it can be verified, it could perhaps be related to the actual onboarding protocol used? But I'm just talking out loud here. Alan DeKok. _______________________________________________ Emu mailing list -- [email protected] To unsubscribe send an email to [email protected]
