The enforcement device and the API endpoint can be the same device, if you like.
On Fri, Jul 3, 2020 at 9:37 AM Steve Haskew <st...@boaz.org.uk> wrote: > > David, > > This is a very good observation - and one that we have had to consider in our > implementation. The source of the captive status needs to be reliable and > quick enough to achieve the flow described in section 6 (Example Interaction): > > "Once the user satisfies the requirements for external network access, the > client SHOULD query the API server again to verify that it is no longer > captive.”. > > For us, the API saying the user is online but the enforcement device still > blocking them would be a major support headache, but could be caused by a > number of different scenarios. This sentence was key in making us seek a > robust solution to that possibility. > > Thanks, > > Steve > > > On 3 Jul 2020, at 17:23, David Bird <dbird=40google....@dmarc.ietf.org> wrote: > > Thanks Steve, I have no doubt that some operators will implement this very > well! :-) > > Indeed, the login flow is the same through the Portal via API (assuming you > figure out the "unique device identity" question).. and I'm sure you'll have > the API server fully integrated with your AAA so that all sorts of logout > events are handled (e.g. NAS restart, idle timeout, etc). > > In the long-tale of public access, I believe users will experience a wide > range of networks, with various levels of integration. My concern is more > that users learn (or even told by venue staff) to disable CAPPORT support if > they find it often "wrong" (e.g. there is a CAPPORT API but no NAS > enforcement; API says you are logged in, but NAS is dropping/redirecting; > etc)... > > [I personally believe we missed an opportunity to make a more robust protocol > by directly involving the NAS (for notification of captivity), providing a > single source of truth...] > > On Fri, Jul 3, 2020 at 7:13 AM Steve Haskew <st...@boaz.org.uk> wrote: >> >> Hi David, Tommy, all, >> >> Just to add the the discussion, from the perspective of a network operator! >> We are just implementing and going to be testing this very soon. We don’t >> see any issues in terms of policy application, because the final step to log >> the user in will be the same with either approach. Actually, this provides a >> really nice route for us to resolve the ever-increasing issue of the >> ugliness of forcing redirects, especially with the decreasing use of plain >> HTTP (and therefore causing SSL warnings). We can only hope that other >> vendors roll this out soon too! I see it as a big step forward. >> >> However, the challenge for us that is linked revolves around identity. MAC >> Randomisation (also coming in iOS 14) is great for privacy, but in the >> short term is poor for user experience on any form of guest wifi, >> particularly for longer stays (e.g. hotel, vs cafe). We’ve actually seen a >> deterioration of support for Hotspot2.0/Passpoint, in that installation of a >> profile from within the Captive Network Assistant on iOS no longer works. >> >> It feels like the dichotomy of privacy vs user experience here has no >> practical solutions - could this be something that the wider WG has >> previously considered, and is it within the remit of the group to look at? >> >> Thanks, >> >> Steve Haskew >> >> >> On 3 Jul 2020, at 14:23, David Bird <dbird=40google....@dmarc.ietf.org> >> wrote: >> >> Thanks Tommy, >> >> Might you have screenshots of the user experience ? I'd be interested to see >> it.... >> >> Agreed, adopting the new CAPPORT spec is very easy to setup (just a DHCP >> server config change at the access point, and an API/Portal server on the >> Internet). The complexity for network operators comes when fully integrating >> this new "application" method of captive portaling with existing "network" >> (NAS/redirect) methods. The complexity is in ensuring the NAS and API are >> enforcing the same policies, for all kinds of users (roaming, paid, free, >> etc) ... if the network operator doesn't do this well, or at all, then the >> complexity is shifted to client device support, answering questions like >> "Why does the WiFi at airport X not work only for new devices?". For this >> reason, I believe you will eventually start probing for redirects again... >> >> You may trust the API, but you may also want to verify.... :) >> >> >> On Thu, Jul 2, 2020 at 7:24 AM Tommy Pauly <tpa...@apple.com> wrote: >>> >>> Hi David, >>> >>> One point I wanted to clarify: the iOS and macOS betas support for CAPPORT >>> discovery and APIs still goes through the standard and existing UI flow for >>> captive portals. The times in which the captive portal UI is shown is >>> limited, for example to times when the user is in WiFi settings. Thus, >>> while adoption should indeed be easy and only require adding a small bit of >>> infrastructure in order to provide a flow that doesn’t require redirects, >>> the set of circumstances in which a network can display content to the user >>> is not increased. >>> >>> Thanks, >>> Tommy >>> >>> On Jul 1, 2020, at 5:27 PM, David Bird <db...@google.com> wrote: >>> >>> >>> That's pretty cool! >>> >>> This will give new opportunities in monetizing WiFi for new iOS and macOS >>> devices with only a DHCP server change and an API server! >>> >>> On Wed, Jul 1, 2020 at 4:22 PM Erik Kline <ek.i...@gmail.com> wrote: >>>> >>>> +1 >>>> >>>> Out of curiosity, does the implementation handle the 7710bis options' >>>> urn:ietf:params:capport:unrestricted value? >>>> >>>> On Mon, Jun 22, 2020 at 5:00 PM Martin Thomson <m...@lowentropy.net> wrote: >>>> > >>>> > Tommy, this is great! Thanks for all your work here, it's good to see >>>> > this turn into something concrete. >>>> > >>>> > On Tue, Jun 23, 2020, at 07:30, Tommy Pauly wrote: >>>> > > Hello CAPPORT, >>>> > > >>>> > > I wanted to highlight an announcement we’ve made for the betas of iOS >>>> > > and macOS released today: >>>> > > >>>> > > How to modernize your captive network >>>> > > <https://developer.apple.com/news/?id=q78sq5rv> >>>> > > >>>> > > The betas for iOS and macOS support both draft-ietf-capport-rfc7710bis >>>> > > and draft-ietf-capport-api by default. This doesn’t change the user >>>> > > experience of logging onto captive networks, but the system will >>>> > > request the DHCP options and handle the RA option, and will prefer >>>> > > using the Captive Portal API Server interaction over having a probe >>>> > > that is intercepted. >>>> > > >>>> > > If you have a portal system that is already implementing the CAPPORT >>>> > > features, please test out these betas and let us know if you see any >>>> > > issues! And if you have a captive portal solution, we’d encourage you >>>> > > to start supporting this soon. >>>> > > >>>> > > Best, >>>> > > Tommy >>>> > > _______________________________________________ >>>> > > Captive-portals mailing list >>>> > > Captive-portals@ietf.org >>>> > > https://www.ietf.org/mailman/listinfo/captive-portals >>>> > > >>>> > >>>> > _______________________________________________ >>>> > Captive-portals mailing list >>>> > Captive-portals@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/captive-portals >>>> >>>> _______________________________________________ >>>> Captive-portals mailing list >>>> Captive-portals@ietf.org >>>> https://www.ietf.org/mailman/listinfo/captive-portals >> >> _______________________________________________ >> Captive-portals mailing list >> Captive-portals@ietf.org >> https://www.ietf.org/mailman/listinfo/captive-portals >> >> >> _______________________________________________ >> Captive-portals mailing list >> Captive-portals@ietf.org >> https://www.ietf.org/mailman/listinfo/captive-portals > > _______________________________________________ > Captive-portals mailing list > Captive-portals@ietf.org > https://www.ietf.org/mailman/listinfo/captive-portals > > > _______________________________________________ > Captive-portals mailing list > Captive-portals@ietf.org > https://www.ietf.org/mailman/listinfo/captive-portals _______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
