Re: [Captive-portals] Ben Campbell's Yes on charter-ietf-capport-00-01: (with COMMENT)

[David Bird <dbird@google.com>]

<snip>

- While I agree that roaming and federated solutions are out of scope, it might be too strong to outright exclude HS2.0/Passpoint, iPass, Boingo, and the like. In HS2.0 release 2, for example, an OSU network can have a captive portal (and I think capport work could apply here) - likewise, I think iPass and Boingo (apps) could benefit form the simplifying of captive portal interactions. (Additionally, even if a network uses 802.1x or an application to authenticate, that doesn't necessarily mean it will be and remain captive portal free -- consider the scenario where a user is being required to top-up their account balance to continue using the 802.1x network).

I'm far from an expert, but my reading of the Hotspot 2.0 OSU buts suggest that it 'fixes' the captive portal problem by giving the client the sign-up/portal address in the OSU handshake (ANQP). Have I misunderstood this?

That is correct... My point is just that HS2 might likely be deployed alongside a captive portal network also used by legacy devices.. the OSU network can be the Open SSID w/captive portal network. HS2 clients wouldn't interact with the captive portal, but it might still be there. Additionally, I don't think HS2 addresses how OSEN networks should enforce a walled garden (restricting clients only to OSU resources). 

My main point is that I don't necessary think "Passpoint, Boingo, iPass" need to be mentioned by name as they are. They are more than "federated" logins and capport solutions _can_ be used by these Apps and deployments. 

The bigger point is to exclude the 'on-boarding/provisioning of clients onto alternative (secure) networks' from the charter explicitly.