Our charter:
The CAPPORT Working Group will define secure mechanisms and protocols to
- allow endpoints to discover that they are in this sort of limited
environment,
- provide a URL to interact with the Captive Portal,
- allow endpoints to learn about the parameters of their confinement,
- interact with the Captive Portal to obtain information such as status
and remaining access time, and
- optionally, advertise a service whereby devices can enable or disable
access to the Internet without human interaction.
I believe RFC7710 and the Capport ICMP I-D cover #1, 2, 3, and even 4 (on a very granular level - e.g. a per flow - or a general - status).
While an API could be used for some of 1-4, I'd argue there are fundamental issues with that direction:
- If a 'Capport RFC compliant' device does RFC7710 and interacts with an API that keeps the user captive, while non-Capport legacy devices have NO limitations (e.g. it was an Open network with mis-configured a DHCP server), then (as a working group) we failed the user. And, UEs will basically learn to do Capport AND Legacy 'Discovery' anyway ...
- One main focus / reason for an API is to address the (optional) #5 - with the desire to automate (or simplify) access. This, to me, is problematic, because:
-- We tend to ignore what the venue/Hotspot operator wants.. They WANT you at the captive portal... Hence, why they went out of their way to have a CAPTIVE portal. We could define an alternative method for the portal, but why? Do Hotspot operators WANT more interfaces, with unknown user experiences, that limit their options? There is a reason why in WISPr the browser method was called the "Universal Access Method"... because, well, it's universal. (Moreover, Hotspot operators are largely marketing companies -- they are very used to designing Web user experiences, that is their business).
-- There IS already an API for automated login and captive portal by-pass, and venues today make money using it. There is an entire industry around the aggregation and automatic login into (and securing access at) Hotspot networks worldwide. Unless there is a business reason for venues and Hotspot operators to support WISPr AND another API for login, I think the technical benefits need to be more than obvious.
The one area I do see value in solving is how to get headless IoT devices on-line on capport networks.. But, in some ways, all we need their is a WISPr client in the device and an out-of-band way of configuring credentials into it. That can be solved with existing protocols and technologies.
David