Re: [Captive-portals] Remediation url for CAPPORT

Remi NGUYEN VAN <> Mon, 20 January 2020 03:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 50A7C120026 for <>; Sun, 19 Jan 2020 19:30:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.5
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yiOO1OeE56t6 for <>; Sun, 19 Jan 2020 19:30:45 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5AC48120024 for <>; Sun, 19 Jan 2020 19:30:45 -0800 (PST)
Received: by with SMTP id t8so26113280iln.4 for <>; Sun, 19 Jan 2020 19:30:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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: <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Remi NGUYEN VAN <>
Date: Mon, 20 Jan 2020 12:30:33 +0900
Message-ID: <>
To: Tommy Pauly <>
Cc: Erik Kline <>, Erik Kline <>, captive-portals <>, Heng Liu <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000a8244a059c89eaa5"
Archived-At: <>
Subject: Re: [Captive-portals] Remediation url for CAPPORT
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: 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.



On Sat, Jan 18, 2020 at 1:53 AM Tommy Pauly <tpauly=> 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 <
>> 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 <> 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 <> 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 <> 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 <
>>>>> 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=
>>>>> 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 <> wrote:
>>>>> On Mon, 13 Jan 2020 at 15:26, Heng Liu <liucougar=
>>>>>> wrote:
>>>>>> On Sun, Jan 12, 2020 at 2:34 PM Erik Kline <> 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 mailing list
>>>> _______________________________________________
> Captive-portals mailing list