Re: [Captive-portals] Remediation url for CAPPORT

Remi NGUYEN VAN <> Fri, 10 January 2020 08:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2575F120058 for <>; Fri, 10 Jan 2020 00:31:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.499
X-Spam-Status: No, score=-17.499 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, 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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HWtI8IQiSEzr for <>; Fri, 10 Jan 2020 00:31:51 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 77617120251 for <>; Fri, 10 Jan 2020 00:31:51 -0800 (PST)
Received: by with SMTP id v3so1187894ioj.5 for <>; Fri, 10 Jan 2020 00:31:51 -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=1taTTT1pWaoEw8PSIK6XAX3M5o4iyHWMtGzrMtepzBk=; b=BSb+NSlEajfQzKakHfzOaxdAO6A5ZdCjsrjZBXHuZP+BDTRJMdKHzjFLIzOtHTmW8d a0y93ugB+xDLg5o8/hpwJAtMSFBzZSoDrfQWpK0zd9mfxRXKX1pLRWVWezpzpITGWxXB hiOvv7l4sKr3SQq73RipnApyisTRxamoccM3eBXaBk7BEj+odubwnTM7fIEFMfZpTHLr W8VomqlgvKguYOwEg96jFDZ0pMUku+dXx8I5JrCdKqcdjTtsKc474CO+K6eTa+xOqr/9 nlAyd0Qis6OThzDPilbE0V5IiQ3cb+5898dOa5vpI9oSAS+QZx2jLPDGtlryiYYp9x64 xsuA==
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=1taTTT1pWaoEw8PSIK6XAX3M5o4iyHWMtGzrMtepzBk=; b=qqCRjT0La5sjn6p6A0TpNOxgyb7GvzC/Tfj8p/zpijXty491Ipqthm4+Qjmzr12/72 hN1TRKpc8RAjcxOIjGDipgttDMf5cxosjpO9ZMhUbcMwUyZxYRJ9OgYCU+hbhX7kR4s1 OPAd+wdCycazgviR12OlZp8S1piJ7vb3Cr3mtZtpWx15PeO3pBqW32M11/vXyCpMhkCT MBRJKc/mdOeiuvcPdINzkWlhVDH79c87Ymx4Y/8YQiMsN+Slw3o833XqedpFKoqXTDn7 hpTQhKWfTJJksaVeFIkbqhqbd7shGcQLBccPb55TmIfnHka53p6ruIBzAzI/ow2JrNiH zWBw==
X-Gm-Message-State: APjAAAWRNyA2VNhNinQJdoDevxXy2mzHhLo0d7PqmOzofhiXTTHDV4Wt RfPf9gYmxLzI7K/7Fofgky3z1uNo7F0dmyzffyv9bNdjUB4=
X-Google-Smtp-Source: APXvYqzoiyxAyeAYayFKVl87wj+NawHELRxd4t7uz4C94NDV/HryzCr+jpj9/THehj5Lsh6B5pJKstChetef4zdUjkw=
X-Received: by 2002:a5d:8846:: with SMTP id t6mr1358971ios.63.1578645110369; Fri, 10 Jan 2020 00:31:50 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Remi NGUYEN VAN <>
Date: Fri, 10 Jan 2020 17:31:39 +0900
Message-ID: <>
To: Heng Liu <>
Cc: captive-portals <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000010f99e059bc4f54f"
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: Fri, 10 Jan 2020 08:31:54 -0000

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.



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