Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 367E33A0876 for ; Fri, 3 Jul 2020 06:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id otZZHjv6DDNw for ; Fri, 3 Jul 2020 06:23:56 -0700 (PDT) Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D49853A0874 for ; Fri, 3 Jul 2020 06:23:55 -0700 (PDT) Received: by mail-il1-x129.google.com with SMTP id r12so20062437ilh.4 for ; Fri, 03 Jul 2020 06:23:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XnuFLmjwBauuAA/wKImvBFbF2eBZa7MCG9BGrQdAAE0=; b=CxN9wpjziHyDOqxLb9LYN1P2MEE81s9W/smk9TZfLRXTiqdMIHKqtKdvkpKjV1efZC bcIT/x9lpR7Mv6ftDAVS/laad8EjIL19CTBCGQ4LOQzbLXazoo3SUSKtXM3m5dccd4yP UoQGPszx1jMg0QCLquRODzPMDU0AGKoS6gH4IQUIVun26zAJfgEVsSuUT4bUafM00IuB yVLevNYG9VlQtdYWODpIvvXOpSaHDhxjQyDXGTmYTBXBXfNwLGw58vFuoUFPvL+c8Tz5 jqOIENZHHDNamX41qWAwKpCjbiof8Ee2V7bhrmS0UAtW2u3jaBihu53Ac1zEQ4L6/XWy 9imA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XnuFLmjwBauuAA/wKImvBFbF2eBZa7MCG9BGrQdAAE0=; b=LFuuBGVwdR/ykAEuIcYaDtiTEZv6ecvJSEhkEFr5XMqV+s5AekruQLVSYgJgEskeW9 8Yo9KLxD2yJxIcqKK4p4LImpcyidZ4SIVn2mI2JW4v50heaEdQx4IUUs/EP0uOByNO99 hlfsFKnQAOvjXIuUmtCuKqfsNwY4Zgkranq34zPBfdzZi8RsN7r1SeAxXaJkmreM2IXK tkxyVUfXn6AoaRKszxsaK6qn3TZepPKOhcJLJ66rXmZU1tIsQxHmEkV6ytdWDK/bM/ko w4vNzQeVa5U6W2c3wuGWsXdw63yCvCXqbG8GSJQ04OwQ3RX0ZaZEm9YYjMpd6ar5P0X5 +8AQ== X-Gm-Message-State: AOAM532aTp/4rnWMUlKLPjSgp9znNxizmbnEEqJ9gnBnaWzsR/x2iYmw s70m/3imFiPevbnK/tfrqTFpcGEhp+l4jphhLXHmzw== X-Google-Smtp-Source: ABdhPJz6RvvFy5r4PtO1fNzlotho70edi9kFbzg2SOlLWYMpBEZhIwMyza8T6W5pLSoZORBwwZwwl8eKKmr4MzL2X+8= X-Received: by 2002:a92:48da:: with SMTP id j87mr18690736ilg.197.1593782634619; Fri, 03 Jul 2020 06:23:54 -0700 (PDT) MIME-Version: 1.0 References: <4E013237-9B3C-426B-961A-878EDFCE4806@apple.com> In-Reply-To: <4E013237-9B3C-426B-961A-878EDFCE4806@apple.com> From: David Bird Date: Fri, 3 Jul 2020 06:23:43 -0700 Message-ID: To: Tommy Pauly Cc: Erik Kline , captive-portals Content-Type: multipart/alternative; boundary="000000000000c98bf805a9896f7d" Archived-At: Subject: Re: [Captive-portals] CAPPORT support in iOS 14 and macOS Big Sur betas X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2020 13:23:58 -0000 --000000000000c98bf805a9896f7d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 wrote: > Hi David, > > One point I wanted to clarify: the iOS and macOS betas support for CAPPOR= T > discovery and APIs still goes through the standard and existing UI flow f= or > 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=E2=80=99t require re= directs, > the set of circumstances in which a network can display content to the us= er > is not increased. > > Thanks, > Tommy > > On Jul 1, 2020, at 5:27 PM, David Bird wrote: > > =EF=BB=BF > 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 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 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=E2=80=99ve made for the bet= as of iOS >> > > and macOS released today: >> > > >> > > How to modernize your captive network >> > > >> > > >> > > The betas for iOS and macOS support both draft-ietf-capport-rfc7710b= is >> > > and draft-ietf-capport-api by default. This doesn=E2=80=99t change t= he 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=E2=80=99d enco= urage 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 >> > --000000000000c98bf805a9896f7d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Tommy,

Might you=C2=A0have scree= nshots of the user experience ? I'd be interested to see it...

Agreed, adopting the new CAPPORT spec is very easy to setu= p=C2=A0(just a DHCP server config change at the access point, and an API/Po= rtal server on the Internet). The complexity for network operators comes wh= en fully integrating this new "application" method of captive por= taling with existing "network" (NAS/redirect) methods. The comple= xity is in ensuring the NAS and API are enforcing the same policies, for al= l kinds of users (roaming, paid, free, etc) ... if the network operator doe= sn't do this well, or at all, then the complexity is shifted to client= =C2=A0device support, answering questions like "Why does the WiFi at a= irport X not work only for new devices?". For this reason, I believe= =C2=A0you will eventually start probing for redirects again...=C2=A0
<= div>
You may trust the API, but you may also want to verify..= . :)=C2=A0=C2=A0


<= div dir=3D"ltr" class=3D"gmail_attr">On Thu, Jul 2, 2020 at 7:24 AM Tommy P= auly <tpauly@apple.com> wrote= :
Hi David,

One point I wanted to clarify: the iOS and macOS betas support for CAP= PORT discovery and APIs still goes through the standard and existing UI flo= w 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, whi= le adoption should indeed be easy and only require adding a small bit of in= frastructure in order to provide a flow that doesn=E2=80=99t require redire= cts, the set of circumstances in which a network can display content to the= user is not increased.

Th= anks,
Tommy

On Jul 1, 2020, at 5:27 PM, David Bird <dbird@google.com> wrote:

=EF=BB=BF
That's pretty cool!=C2=A0

This will give n= ew 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 P= M Erik Kline <ek.= ietf@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 <mt@lowentropy.net> wrote:
>
> Tommy, this is great!=C2=A0 Thanks for all your work here, it's go= od 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=E2=80=99ve made for the = betas of iOS
> > and macOS released today:
> >
> > How to modernize your captive network
> > <https://developer.apple.com/news/?id=3D= q78sq5rv>
> >
> > The betas for iOS and macOS support both draft-ietf-capport-rfc77= 10bis
> > and draft-ietf-capport-api by default. This doesn=E2=80=99t chang= e the user
> > experience of logging onto captive networks, but the system will<= br> > > request the DHCP options and handle the RA option, and will prefe= r
> > using the Captive Portal API Server interaction over having a pro= be
> > that is intercepted.
> >
> > If you have a portal system that is already implementing the CAPP= ORT
> > features, please test out these betas and let us know if you see = any
> > issues! And if you have a captive portal solution, we=E2=80=99d e= ncourage you
> > to start supporting this soon.
> >
> > Best,
> > Tommy
> > _______________________________________________
> > Captive-portals mailing list
> > Cap= tive-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/cap= tive-portals

_______________________________________________
Captive-portals mailing list
Captive-porta= ls@ietf.org
https://www.ietf.org/mailman/listinfo/captive-p= ortals
--000000000000c98bf805a9896f7d--