A couple questions to clarify...
"lorenzo - if the API is advertised on a non-captive network, that's equivalent to being logged in"
Only if the API is advertised and saying you are captive, right? Or, is this addressing the case there the API is advertised on a network that has no network integration (e.g. no actual captive portal, just open WiFi)? If the latter, how did the UE determine the "logged in" state, with a probe?
"warren - extra edgecase - incorrect API listed, either it is down or the information is wrong"
"tommy - we fall back"
Knowing the information is wrong will be tricky, unless UEs are going to keep probing like they do today...
And, fall back to what? Hoping that infrastructure vendors redirect HTTPS so users don't have bad experiences in case the API was wrong about expiry time?
"eric kinnear - this won't work if the network is suddenly captive after not being captive"
This was an good comment that didn't seem to get replies... Without network signaling, the user would be in limbo when the network puts them in captivity (e.g. Idle timeout, maybe a virus detected) before the UE had time to be notified from polling the API. We aren't any closer to getting rid of HTTPS redirecting... which is part of the 'fall back' solution.
"tommy - should we suggest that the probe use the Accept header we use for the API?"
We are formalizing probing? Wasn't that something we wanted to eliminate the need for?
So... we keep probing, we require the status-quo as our 'fall back', we don't really solve HTTPS redirecting (in fact, we sorta still need it); I'm just not sure we are solving things or just adding layers of complexity.