The only new element is the CAPPORT API Server.
Though, similar things do exists in proprietary environments (e.g. Walled garden entry plus proprietary Apps).
Even though I started the thread 'Arguments against (any) CAPPORT API', I would like to take back the "(any)" part. I just wanted to make a point that we should NOT make the API the enforcer, or otherwise give the API the opportunity to give us wrong, misleading, or misconfigured information about what the network will enforce. I don't think the goal of the API should be to get rid of the portal in all cases. But, there could be other useful information and interaction (like WISPr demonstrates, plus minimally more). For instance, the API could advertise 'access methods' like:
wispr { realm: "abc", login: "https://...", logout: "https://..." }
wispr { realm: "xyz", login: "https://...", logout: "https://..." }
mime-type { name: "application/my-hotspot-app" }
mime-type { name: "application/roaming-partner-foo" }
It can replace WISPr XML, even abilities by allowing the advertising of multiple roaming aggregators. It can also indicate to the UE what apps might assist- or auto- login. If this information is wrong, the Smartclient or App will figure it out (because they are likely doing their own proprietary API in the walled garden).