Re: [Captive-portals] Remediation url for CAPPORT

Remi NGUYEN VAN <reminv@google.com> Mon, 20 January 2020 03:30 UTC

Return-Path: <reminv@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 50A7C120026 for <captive-portals@ietfa.amsl.com>; Sun, 19 Jan 2020 19:30:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Level:
X-Spam-Status: No, score=-17.5 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, HTML_MESSAGE=0.001, 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 yiOO1OeE56t6 for <captive-portals@ietfa.amsl.com>; Sun, 19 Jan 2020 19:30:45 -0800 (PST)
Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 5AC48120024 for <Captive-portals@ietf.org>; Sun, 19 Jan 2020 19:30:45 -0800 (PST)
Received: by mail-il1-x12b.google.com with SMTP id t8so26113280iln.4 for <Captive-portals@ietf.org>; Sun, 19 Jan 2020 19:30:45 -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; bh=LcPnmaJFPkkpAY5FK9a/hXniFgp375rcE19I3GwdS5U=; b=NhRQskLEPZadPB+JugE8GJeWPNZJKTab2s0xa7R5ftoiGvcRNDvpPN5UpUDAXuVAwC wYkdn1/hDk7DhIIXEa0b3zDfVd8MohYeFwwNjIN83uhk1txP2mcEDLV22Eb2hAKag7B1 jGrpZm6Qf7hnvXsgOC2hSjlcCYznF/7YwDvNC6y1/NDjeyIPfXBg/iz36lxYVAaQMX6V rzicfGgk3p1FZkrsSUNaZYpcLSUyT1VX2S5slJ60cj0G4n7gqJhgxJY7AJwvir4vikNm +4FBM5S15yRmfJEZYqJo+xhPYRR853gwVZr9+gOhL8lxS8rFbeNp15PFeYl5E8JYInRQ NLFQ==
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=LcPnmaJFPkkpAY5FK9a/hXniFgp375rcE19I3GwdS5U=; b=rSX/hF+XNlVpUYjLA4bLxII4FNLB9E7sA69maUYbJo4U6xIuL4vpFYNqb/But3pdcv 5DEspNX6rI5CCL2rG38V3CKPoFp4sy4HSLj1VDG1f96EjJrvCzoZjHACdksn87xuG5Cx NiVMJqf+WVyFKpc/zwdhPK15BlvV6ed+FnFGLf9pS3RgmzwW2ISvlXeF4qBpSzPBDmQn gqkWzd/xz5JxBK2BiXYMCjFhq8pBb6m+8zX3fVDiyuOMD5SSKIDu3dM0PSudfiXTe29z CwbVozGgmIoSOloRc86KPz+Op0rFmyQ8uEgAVXVOaJd2Vxz2cJZaX/Q03dF37LwhwNo6 uHHw==
X-Gm-Message-State: APjAAAVhtwuD1mRD0bmk0NdnQiW1zcbp99r3aWaPNkcPdZ5vvMVTTC7j l/39j8nnWsXg5MUkAaF//rjk/S5GwyiiPgyKmO1g5A==
X-Google-Smtp-Source: APXvYqwvXTujlfg2PFABI/G3wmZeCSC+rm9bZfNQDRJdOnCp1SmDEd6wv3Vu7HyJcBVrtiVONgkvIy7rBJAvtyreHvU=
X-Received: by 2002:a92:8d8e:: with SMTP id w14mr8767742ill.187.1579491044421; Sun, 19 Jan 2020 19:30:44 -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> <40F3E8F6-AB27-4F7E-A751-B6C7FB985457@apple.com>
In-Reply-To: <40F3E8F6-AB27-4F7E-A751-B6C7FB985457@apple.com>
From: Remi NGUYEN VAN <reminv@google.com>
Date: Mon, 20 Jan 2020 12:30:33 +0900
Message-ID: <CAKxhTx8aJgLN2dSqKsf9WNWNLtm=UykmvjVizw5UfEu_vjQVzw@mail.gmail.com>
To: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>
Cc: Erik Kline <ek@loon.com>, Erik Kline <ek.ietf@gmail.com>, captive-portals <Captive-portals@ietf.org>, Heng Liu <liucougar@google.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000a8244a059c89eaa5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/1UUBD-eEMy9ZxcGAEQ-8Z-BvEh0>
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 03:30:49 -0000

I also thought "remediation-supported" was not ideal but could not come up
with a better name. "can-extend-session" does sound clearer to me.

Cheers,

Remi


On Sat, Jan 18, 2020 at 1:53 AM Tommy Pauly <tpauly=
40apple.com@dmarc.ietf.org> wrote:

> I'm fine with adding the boolean to the main draft. I discussed this a bit
> with Heng yesterday, and we discussed naming it something like
> "can-extend-session". Thoughts on that name?
>
> Thanks,
> Tommy
>
> On Jan 16, 2020, at 11: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
>
>
>