Some comments (will not be at meeting)
Section 1. The introduction states the purpose of the API as:
The state of captivity (whether or not the host has access to the
o A URI that a host's browser can present to a user to get out of
o An encrypted connection (TLS for both the API and portal URI)
The state of captivity is not all or nothing and being detailed about "captivity" (e.g. listing walled garden resources up front, down to protocol, port, hostnames, etc) will be complex and error prone. The URI for the captive portal can be gotten by RFC 7710. Captivity signaling should be granular; because we can, and it includes more use-cases.
Section 2. The workflow is stated as:
1. Provisioning, in which a host discovers that a network has a
captive portal, and learns the URI of the API server
2. API Server interaction, in which a host queries the state of the
captive portal and retrieves the necessary information to get out
3. Enforcement, in which the enforcement device in the network
blocks disallowed traffic, and sends ICMP messages to let hosts
know they are blocked by the captive portal
My issue is with the ordering... At step 2, we have Capport compliant devices enforcing themselves.. while non-Capport devices wait for the network enforcement. We have the (likely) scenarios of API server saying one thing (implying "self enforcement"), while the network "Enforcement" is telling the UE something else... who is right? Answer: always the network.
Section 3.2. I think the JSON keys represent a too narrow view of walled gardens, and while simplicity is good, here it artificially and severely limits use-cases.
Obviously, the "permitted" field is a boolean, not reflecting the fact the location very likely has freely available resources in the walled garden.
The "expire-date" and "bytes-remaining" will be hard to synchronize with network enforcement... the enforcement function might not be counting *all* bytes (some might be "free"), session expiry could happen because of time and/or data limits - possibly being consumed by multiple concurrent devices/sessions - but also things like Idle Time or software restart (NAS / AP / etc) or a number of reasons.
What would be useful in the API, in my opinion, is for the API to provide a sort of validation, authentication, and additional information for and about network notifications.