Re: [Captive-portals] Remediation url for CAPPORT

Erik Kline <> Sun, 12 January 2020 22:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 589FD120045 for <>; Sun, 12 Jan 2020 14:34:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 PmAaeo6HALP9 for <>; Sun, 12 Jan 2020 14:34:09 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::52e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A8622120020 for <>; Sun, 12 Jan 2020 14:34:08 -0800 (PST)
Received: by with SMTP id e10so6836787edv.9 for <>; Sun, 12 Jan 2020 14:34:08 -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=i7o8k9sX2jOjkmH0g74gpgvAOu73mF2FiH45KD9hhlk=; b=h+GU83KRu5AXKIW3ArkiHVfiH09T9BSlgbg1cwPJfDFlNUOqRYUOi6BWiuMleZc2qb Tdmf92Zi8qO74Lo7LPQ4z1qWc8uYJVh8+xorXeKH8vUMNL+3/ruggea+XHZ4/9lQCMOM SJBZebz8Q6c8mXXc38u7sznmr76P7k4wC2sGGjebAtFN+nNkuN/jniO0FzzQbPNt8sAT ddxe+tumcmmceCrO0pbZ144ntH07CbOF4IIZbyT2qNbSx4b/VIn1LifiKDnudpsm6Gqf 3At1z00iVEgBH/iHOciK+EwasVpuSbR01Jf8dNrYG3y8nTi5u+a2bhBD9a8y+OmKXlRj zS5A==
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=i7o8k9sX2jOjkmH0g74gpgvAOu73mF2FiH45KD9hhlk=; b=jYeW55pl8rcaPc0jJUQeR98mi12SHFDL34EGW5dIjo6ajCjIZsRXp9jdNOyaRkPTFn K7C2Q7sD3MXG/n4AvNjMhvu8CbZWDXMXed41QNpEg0f0QZDZIfwH9XPakayfSNgnZcoi uV7RRhOSnjqq6+XqxJyfGhfH4RnT8u8DlosYc46vUmKPvEgIaQYtr8zL7VVtgXgR3VPP 4HxZwB+ERk9Qbe4x4NRtCqpTPQ+SYydnx0Ah7OODglhqmDeX743iYR3UR6B1mAm0d1St ldO3Qk3cp3MXwYmxv6QZP0uWSbuxttNSowQrip/ZVjpGPhE0sB4uXGfDo/UhAM0vowsT v73Q==
X-Gm-Message-State: APjAAAUSSt1WYqEKi9dwIHDqG9xeAbNtI4kg32Z70jXPsOpRQdrt99mN b6D3rYK5ST4DEWL6COW/J/OsJv3tEJQb6L8HrdI=
X-Google-Smtp-Source: APXvYqx0CDF88NUDC0BZI7AxCw1sC5O6q9I6BMhAcyVyHj7HKOJuuv0+E7E5o8CjOHH0Ubtn+9aOGACaweCmndYx+B4=
X-Received: by 2002:aa7:d94d:: with SMTP id l13mr12062995eds.328.1578868447163; Sun, 12 Jan 2020 14:34:07 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Erik Kline <>
Date: Sun, 12 Jan 2020 14:33:56 -0800
Message-ID: <>
To: Remi NGUYEN VAN <>
Cc: Heng Liu <>, captive-portals <>
Content-Type: multipart/alternative; boundary="000000000000f0b840059bf8f47b"
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: Sun, 12 Jan 2020 22:34:11 -0000

<no hats>

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.

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 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

On Fri, Jan 10, 2020 at 12:32 AM Remi NGUYEN VAN <reminv=> wrote:

> In the context of Android, having this additional URL would help us as the
> system is not too sure what to do when the session is about to expire: if
> we show a notification saying "your session is about to expire" and the
> user taps it, but the venue info or login page do not show a remediation UI
> (many existing implementations may not have such a page), this would be
> confusing to users.
> Having a clear signal from the portal that sessions that are about to
> expire can be extended at the given URL would help.
> Cheers,
> Remi
> On Fri, Jan 10, 2020 at 3:46 PM Heng Liu <liucougar=
>> wrote:
>> Hi all,
>> In some captive portals, it's possible to extend (or remediate) an
>> existing session without losing connectivity. This use case is covered in
>> the CAPPORT architecture draft:
>> 4.2.  Conditions About to Expire
>>    This section describes a possible work-flow when access is about to
>>    expire.
>>    1.  Precondition: the API server has provided the User Equipment with
>>        a duration over which its access is valid
>>    2.  The User Equipment is communicating with the outside network
>>    3.  The User Equipment's UI indicates that the length of time left
>>        for its access has fallen below a threshold
>>    4.  The User Equipment visits the API again to validate the expiry
>>        time
>>    5.  If expiry is still imminent, the User Equipment prompts the user
>>        to access the web-portal URI again
>> Step 5 in the above section suggests UE visit the user-portal URI again.
>> However, not all CP provides a way to extend sessions. In order to
>> provide a positive signal that extending session is possible, what do you
>> think if an optional remediation-url field is introduced in the API JSON
>> file please?
>> CP provider can set this to the same URL as the user-portal-url if they
>> want, or they can provide a different URL, If present, then in the Step 5
>> above, the remediation url will be used.
>> The presence of this url is a positive signal to the UE that extending a
>> session is possible in this captive portal.
>> Our user research in many markets on Captive Portals indicates that many
>> users dislike having their connection interrupted (e.g., in the middle of a
>> call, download, stream). For operators who are willing to offer a way to
>> extend without an interruption, this is an improvement to the user
>> experience.
>> This remediation-url is similar to the "subscription remediation"
>> mechanism outlined in Passpoint (Hotspot 2.0) Release 2:
>> In the Passpoint Release 2.0 Spec, page 71 "8.1.3 Subscription
>> remediation" section:
>> For the purposes of this document, the term “remediation” refers broadly
>> to the process of fixing a problem in the subscriber’s subscription; this
>> definition includes provisioning updated credentials to a mobile device,
>> updating the PerProviderSubscription MO on a mobile device or performing
>> some online function to update the subscription (i.e., no new
>> credentials/data are provisioned to the mobile device).
>> On page 72:
>> There are two classes of remediation: machine and user remediation:
>> • Machine remediation means the problem(s) with the subscription can be
>> remediated
>> without any user intervention.
>> • User remediation means the problem(s) with the subscription requires
>> user intervention.
>> On the same page 72, in section "8.1.4 Subscription management web
>> content", it states a web page could get more info from a user if "user
>> remediation" is needed.
>> regards
>> Dr. Heng Liu
>> _______________________________________________
>> Captive-portals mailing list
> _______________________________________________
> Captive-portals mailing list