Re: [Captive-portals] Remediation url for CAPPORT

Lorenzo Colitti <lorenzo@google.com> Mon, 20 January 2020 04:50 UTC

Return-Path: <lorenzo@google.com>
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 F3084120077 for <captive-portals@ietfa.amsl.com>; Sun, 19 Jan 2020 20:50:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.501
X-Spam-Level:
X-Spam-Status: No, score=-17.501 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, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 vWVMeAWN6fbS for <captive-portals@ietfa.amsl.com>; Sun, 19 Jan 2020 20:50:16 -0800 (PST)
Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 A7990120099 for <Captive-portals@ietf.org>; Sun, 19 Jan 2020 20:50:16 -0800 (PST)
Received: by mail-io1-xd2f.google.com with SMTP id n21so32242067ioo.10 for <Captive-portals@ietf.org>; Sun, 19 Jan 2020 20:50:16 -0800 (PST)
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:content-transfer-encoding; bh=0IenJWv/IxAn1+7LDYYg6DNb8kupWPBh45QchTRdDEU=; b=FpHpIV3yvYZMYDzO21J0HUg5wGgJcOVkqjA2QAn6PmOYOCU713y1V0vabIDTCV6cI9 7IThIS3T10LaJ7lbuEDqpPUfbBe6YzlQUGqo8kXJVwJ8xecpVMVDJ5qGMsG7ULZdbqMr MowtgP/YJW6KOzceeC9GT/vrDnIipFdgThxskObCa1JFUd+anYs2LvSFr1Mct/g875P6 wWsvDHJpOkrNdeqFRAdFWOPrsuhymwCa1qyblFh0n3kGKMTqNAHSaRU+N8sv41Fj8cYq JQNA83gXOsPzqbeLu5oP+1/hLW8A4NvbETehKCsvi4CgwIRxj+xVQJOYnVa+BxYbRwR5 ekoQ==
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:content-transfer-encoding; bh=0IenJWv/IxAn1+7LDYYg6DNb8kupWPBh45QchTRdDEU=; b=GYwTpZpfEn3h3pd6IPiuO4A4U1EiWs7uJyAv0c8Ffr6oOc683cCuzGRcGQpV2GmG/1 7uoSGPc0LP+4S7vWzVS6poiHlB7R8BYyaOtY4FtI2Tc9N0gxjHv1KELrC43+PCBLXhj9 eqWtHj/MMZ8IXbSGqY0sUN/EmVk7X6rC3mlMyFajYcKy+sziS2Hr/V0+8i0yIV8kAgJh 8GuISEW9k2Blukc8cmGG4HdgT1cOGZJ942bdHR8P1JryIG3LCZjWPBZU7B+LqPG4HQ19 kCmYPpzUVrb2RFh26adPf8Zv03Yt09iZnQkiepbq3mb/L4oJu+eO+z8Hatjmxj5mbEgz qhTw==
X-Gm-Message-State: APjAAAUnHgdZJNm8JHgsoDzu0eOsv5TDE+VmSSRKkogKM86GO+vt1/qu SumLdLxapwixDP/W87leWpsTRpECUtf9uQz3kaGPrQ==
X-Google-Smtp-Source: APXvYqxr4bQ60m5h04M/wfDYm4TUwjBm0AtUcCd5gdyxQumIjePEsmMHqKdFHN0qm6FKEx1uirPHClTklAfGqPvuKfM=
X-Received: by 2002:a6b:3a03:: with SMTP id h3mr29438130ioa.241.1579495815616; Sun, 19 Jan 2020 20:50:15 -0800 (PST)
MIME-Version: 1.0
References: <CAKMty=Ks0j6dxPvsDHTpWBCrujihCe7Yzsb4zaV5SkRfh8fx9Q@mail.gmail.com> <CAKxhTx_uaZVFs4VhM+nro61XxTjPtwZ+pZ_gsJtNQXiNHtf2vQ@mail.gmail.com> <CAMGpriX1ct9y53HZ2FtbK00TfVm3uNRFMwYQW0Wb_18XoXjFJw@mail.gmail.com> <CAKMty=KhYr4XfJWzXeBiod1oiyG-qVp7-ANKJaZF1-_nPZhrTw@mail.gmail.com> <CAAedzxocTUhQ-z+_Cpz8PhG=o3CR4aZHOGddngiEjZ1HZChP1A@mail.gmail.com> <D00FBAF2-3825-4435-8426-10C300E491F2@apple.com> <CAKxhTx9g3WrKM=BP2fifv08CVcMrZvhuvnZjapb3ugN=WX1fhg@mail.gmail.com> <DBEFCCF8-0677-490F-A305-14C880B3DC7A@apple.com> <CAKMty=JqBHb3fqrBy1yhrfxuJVMATP=HByD+bxRezKUN5WYqQA@mail.gmail.com> <CAAedzxpXPdUw+LpfLK15T1YRghSO973pHUaQZQara5GH1QYiPA@mail.gmail.com> <CAKxhTx_8Bik5HnCae4OtYv7Q0gtv7bmKY3PamQN4aGb=S0V7dw@mail.gmail.com>
In-Reply-To: <CAKxhTx_8Bik5HnCae4OtYv7Q0gtv7bmKY3PamQN4aGb=S0V7dw@mail.gmail.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Mon, 20 Jan 2020 13:50:04 +0900
Message-ID: <CAKD1Yr1G8peXKMjjz_K-=CgHdZnj_+E0ZOS6s9bLK0X9DitBMw@mail.gmail.com>
To: Remi NGUYEN VAN <reminv=40google.com@dmarc.ietf.org>
Cc: Erik Kline <ek@loon.com>, Erik Kline <ek.ietf@gmail.com>, captive-portals <Captive-portals@ietf.org>, Tommy Pauly <tpauly@apple.com>, Heng Liu <liucougar@google.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/Nc2QUiaBYBDEewkdKroO5gIP9cY>
Subject: Re: [Captive-portals] Remediation url for CAPPORT
X-BeenThere: captive-portals@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of issues related to captive portals <captive-portals.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/captive-portals/>
List-Post: <mailto:captive-portals@ietf.org>
List-Help: <mailto:captive-portals-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Jan 2020 04:50:19 -0000

I do think something is needed here because we don't want the device
to put up a "you're running out of time, please click here to extend"
prompt/notification, if tapping that prompt goes to a page that just
says "you're logged in" without allowing the user to extend. If the
network doesn't support extending sessions, then the device should not
display the prompt. So we should give the network a way to express via
the API whether it's possible to extend the user's time or not.

Once we do decide to have something like that in the API, ISTM that a
separate URL is more useful than just a boolean. Whether the URL is
present or not gives you the boolean; the content of the URL makes it
easier for network operators because it means they can provide a
specific "manage my connection" page that is different from the login
page. The operator could of course decide what to display based on the
login state of the user; this just makes it easier.

But as long as this is not the same as the venue URL, that works for
me. We do want it to be separate, because we expect most operators
will primarily want to surface the venue URL, and we don't want them
to have to make a choice between surfacing the venue URL and making
the session easy to extend.

Cheers,
Lorenzo

On Fri, Jan 17, 2020 at 4:25 PM Remi NGUYEN VAN
<reminv=40google.com@dmarc.ietf.org> wrote:
>
> As far as the Android implementation is concerned, I think it would be nice to have capport API support in the next (android R) version; however due to deadlines, it's going to be harder for me to change the attributes read from the API very soon.
> Following this discussion my current plan is to support an optional "remediation-supported" boolean, and only prompt users to extend their session shortly before it expires when it is set to true. Hopefully the boolean can be added to the current draft or in a future, separate draft considering that we seem to roughly agree on it, but if the group eventually realizes that it wants to go in another direction, we'll update behavior in subsequent releases.
>
> Does that make sense ?
>
> Cheers,
>
> Remi
>
> On Wed, Jan 15, 2020 at 9:30 AM Erik Kline <ek@loon.com> wrote:
>>
>> If there's working group consensus to add it to the current API draft then definitely add it.  Otherwise, probably a separate document that would need a call for wg adoption.
>>
>> Separately, and hopefully without starting a massive bikeshed, is there a more apt word than "remediation"?  I think this specific word carries the connotation of "fixing an error" or "correcting damage" and it seems like the use here would be broader.  But perhaps I'm completely mistaken.
>>
>> On Tue, 14 Jan 2020 at 16:21, Heng Liu <liucougar@google.com> wrote:
>>>
>>> It seems most are comfortable with adding a remediation-capable boolean, which is simpler than another url while also making it explicit on whether remediation is provided or not, so UE could display different notifications.
>>>
>>> Anyone have any objections on adding this boolean please?
>>>
>>> If not, what's the next step on moving this forward please?
>>>
>>> Thanks,
>>> Heng
>>>
>>> On Tue, Jan 14, 2020 at 12:38 PM Tommy Pauly <tpauly@apple.com> wrote:
>>>>
>>>> Any captive portal that is newly adopting the CAPPORT API will hopefully be testing the setup in the new model, and will have to think about which URLs to map to different user experiences.
>>>>
>>>> A page that only says "you're logged in!", and has no way of adding more time, etc, is in my opinion a relatively useless page. If we provide a separate URL for remediation, it would seem to encourage such a design. Not including this would hopefully urge the portal design to a cleaner model.
>>>>
>>>> I do think the boolean is nice for highlighting to the captive portal deployer that they should think about remediation. I'd be more ok with that model, although it could also be an extension as we gain experience in deployment.
>>>>
>>>> Thanks,
>>>> Tommy
>>>>
>>>> On Jan 13, 2020, at 6:00 PM, Remi NGUYEN VAN <reminv=40google.com@dmarc.ietf.org> wrote:
>>>>
>>>> If we show prompts to the user shortly before the session expires, we'd like to make sure that we can redirect them to some page where they can fix the problem, instead of landing on a page saying "you're logged in". The user-portal-url would work fine with a remediation-supported boolean for that purpose; having a separate URL gives additional flexibility to the access point operator, but from the point of view of the client I think both are fine.
>>>>
>>>> Cheers,
>>>>
>>>> Remi
>>>>
>>>>
>>>> On Tue, Jan 14, 2020 at 10:02 AM Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org> wrote:
>>>>>
>>>>> I have a similar initial reaction to Erik's. Adding another URL that effectively is just another user portal, but meant to be used at certain times, adds a lot of complexity. I'm certainly not ruling out adding such a key as need arises, but I'd hesitate to make it part of the initial set.
>>>>>
>>>>> Particularly, if we start seeing the "venue URL" be the main landing page we redirect people to once they're logged it, it kind of makes sense to let the user portal be the status/remediation/payment page.
>>>>>
>>>>> Tommy
>>>>>
>>>>> On Jan 13, 2020, at 4:06 PM, Erik Kline <ek@loon.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Mon, 13 Jan 2020 at 15:26, Heng Liu <liucougar=40google.com@dmarc.ietf.org> wrote:
>>>>>>
>>>>>> On Sun, Jan 12, 2020 at 2:34 PM Erik Kline <ek.ietf@gmail.com> wrote:
>>>>>>>
>>>>>>> Why should this different from the user-portal-url?  It seems to me that either the user-portal-url would remediation UI elements or it wouldn't.
>>>>>>
>>>>>> Some CP vendors want to specify a different URL specifically tailored for remediation of a session.. By providing a 3rd URL, we can accommodate this use case..
>>>>>
>>>>>
>>>>> If the remediation URL is available but the user (somehow) navigates to the user-portal-url, what do they see?
>>>>>
>>>>>>
>>>>>>>
>>>>>>> With this 3rd URL, if the bytes/time does expire should the OS try to launch an interaction the remediation URL and then fallback to the user URL if it failed to load?  In which case, why not just leave all interaction with the user-portal-url?
>>>>>>
>>>>>> if a remediation URL is present, and if it fails to load for whatever reason, no need to fallback to user portal URL: CP vendor should make sure the remediation URL is working properly (this is similar to user-portal url should work properly, if not, there is no other way for user to clear a CP)
>>>>>
>>>>>
>>>>> I guess I'm just trying to be mindful of one person's flexibility is another person's complexity..  I think this just doubles the number of URLs that the CP vendor needs to make sure function correctly.
>>>>>
>>>>>>> If the vendor doesn't implement a means to extend your session without completely shutting everything down and forcing to the user to restart the interaction flow anew, I could see that an OS would not want to bother the user with an interaction where they couldn't actually do anything useful.  But that might suggest a boolean capability, rather than a new URL (remediation-supported={true|false})?
>>>>>>
>>>>>> A boolean field could also be a positive signal to notify UE that remediation is possible, but this would prevent CP vendors from using different URLs for remediation.
>>>>>>
>>>>>> (As mentioned in the initial thread, this URL approach is also taken by the Passpoint release 2.0 spec to signal remediation process.)
>>>>>>
>>>>>> regards,
>>>>>> Heng
>>>>>> _______________________________________________
>>>>>> 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