Re: [Captive-portals] Remediation url for CAPPORT

Remi NGUYEN VAN <reminv@google.com> Fri, 10 January 2020 08:31 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 2575F120058 for <captive-portals@ietfa.amsl.com>; Fri, 10 Jan 2020 00:31:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.499
X-Spam-Level:
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: 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 HWtI8IQiSEzr for <captive-portals@ietfa.amsl.com>; Fri, 10 Jan 2020 00:31:51 -0800 (PST)
Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 77617120251 for <Captive-portals@ietf.org>; Fri, 10 Jan 2020 00:31:51 -0800 (PST)
Received: by mail-io1-xd2a.google.com with SMTP id v3so1187894ioj.5 for <Captive-portals@ietf.org>; Fri, 10 Jan 2020 00:31:51 -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=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; d=1e100.net; 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: <CAKMty=Ks0j6dxPvsDHTpWBCrujihCe7Yzsb4zaV5SkRfh8fx9Q@mail.gmail.com>
In-Reply-To: <CAKMty=Ks0j6dxPvsDHTpWBCrujihCe7Yzsb4zaV5SkRfh8fx9Q@mail.gmail.com>
From: Remi NGUYEN VAN <reminv@google.com>
Date: Fri, 10 Jan 2020 17:31:39 +0900
Message-ID: <CAKxhTx_uaZVFs4VhM+nro61XxTjPtwZ+pZ_gsJtNQXiNHtf2vQ@mail.gmail.com>
To: Heng Liu <liucougar=40google.com@dmarc.ietf.org>
Cc: captive-portals <Captive-portals@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000010f99e059bc4f54f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/yECmFFjrFmTahCcb2n2ne_A2cZE>
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: 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.

Cheers,

Remi


On Fri, Jan 10, 2020 at 3:46 PM Heng Liu <liucougar=
40google.com@dmarc.ietf.org> 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@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals
>