Re: [Captive-portals] Arguments against (any) Capport "API"

[David Bird <[e-mail]>]

There are problems with WISPr, one being that it has somewhat ambiguous
copyrights, which is why you will not find it easily on-line.

It was proposed by WFA, but never ratified. With that said, there are some
lessons to be learned from it:

- It probably would be good to have something with cleaner specifications,
but adoption by the long-tail hotspot operators could be slow (even slower
thank upgrading NAS capabilities). Critical to vendor/venue adaption will
be roaming aggregator adoption, and you have the chick and egg problem.

- WISPr XML wasn't overly complicated, but it being implemented by all
sorts of portals, in all sorts of ways, gave it a very bad reputation as
being broken. (A fear I have for our API as well.)

- WISPr only defined, basically, a Username / Password login method, which
fits AAA/RADIUS models, and the industry has largely adapted to (for
instance, it is common to do 'Mac Auth' using a shared 'Password' field or
to fit voucher codes into a username/password combinations).




On Wed, Apr 5, 2017 at 10:30 AM, Christian Saunders <
[e-mail]> wrote:

> Does WISPr support all of the use cases?  Is there a publicly available
> source for the WISPr XML spec?
>
> Cheers!
>
> Christian
>
>
> On 17-04-05 11:15 AM, David Bird wrote:
>
> I agree with that... but, to be clear, it really is just an improvement on
> WISPr XML, and with WISPr XML already, not only used, but used to make
> money, the reasons for supporting this API MUST be inline with the
> venue/Operator needs. 'Automating login' (as a focus for the API) quickly
> becomes venue / regional / legal / vertical / application / access policy
> dependent.. Not to mention, I question the value for the user in making it
> super simple for their devices to auto-login into public access networks
> (without clear user intent). This seems irresponsible, on our part, when
> there are solutions out there already that do automate this login, but only
> after taking extra security measures (presumably, hotspot aggregators
> conceal your identity when roaming, and their Apps can do more things).
>
> On Wed, Apr 5, 2017 at 9:51 AM, Dave Dolson <[e-mail]> wrote:
>
>> This is OK if you only need to serve devices with browsers and attentive
>> humans.
>>
>> The API offers possibilities for automation in the device by making a
>> formal data model (vs. HTML).
>>
>>
>>
>>
>>
>> *From:* Captive-portals [mailto:[e-mail]] *On
>> Behalf Of *Christian Saunders
>> *Sent:* Wednesday, April 5, 2017 12:38 PM
>> *To:* David Bird
>> *Cc:* [e-mail]
>> *Subject:* Re: [Captive-portals] Arguments against (any) Capport "API"
>>
>>
>>
>> The currently proposed solution has 3 components:
>>
>>
>> 1. The ICMP component is used to detect a captive network.
>>
>> 2. The DHCP component is used to discover the address of the Captive
>> Portal.
>>
>> 3. The API is an information service with a standardized interface that
>> allows discovery and potentially remediation of the requirements for
>> network access.
>>
>> The ICMP and DHCP components are sufficient to resolve the redirection
>> and HTTPS issue.
>>
>> I would consider the API as an optional component - it might create some
>> user experience benefits if the device developers and network operators
>> choose to use it.
>>
>> The difficulty with the API is having a way of codifying all of the
>> possible network access requirements.  I'm not sure this is reasonably
>> possible.
>>
>> Assuming that such a definition is possible, then there is some benefit
>> to the common definition.
>>
>> (It also strikes me that this definition would make a nice back end
>> design for the Captive Portal itself.)
>>
>> Cheers!
>>
>> Christian
>>
>>
>>
>> On 17-04-05 10:25 AM, David Bird wrote:
>>
>> Edits in-line :)
>>
>>
>>
>> On Wed, Apr 5, 2017 at 9:06 AM, David Bird <[e-mail]> wrote:
>>
>> A few more key benefits of the ICMP approach :
>>
>>
>>
>> - Capport detection is made easier for the client, even when RFC 7710 (or
>> any API) is *NOT* implemented (as long as the NAS is Capport compliant).
>>
>>
>>
>> - "Signaling" can be done by different components (NAS, iptables,
>> rate-limiter, PCEF, etc), without (necessarily) needing to coordinate with
>> a central service.
>>
>>
>>
>> - In defining the RFC in how a NAS should handle blocking traffic for
>> Capport compliant devices, we are also defining how the NAS should handle
>> Legacy devices - which is, there is no difference - they both get ICMP Dest
>> Unreach w/Capport extension) - which is helpful.
>>
>>
>>
>>
>>
>>
>>
>
>
>
> _______________________________________________
> Captive-portals mailing [e-mail]://www.ietf.org/mailman/listinfo/captive-portals
>
>
>