Subject: [Captive-portals] Remediation url for CAPPORT

From: Heng Liu <[email-masked]>
Date: Thu, 9 Jan 2020 22:45:50 -0800

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

---

From: Remi NGUYEN VAN <[email-masked]>
Date: Fri, 10 Jan 2020 17:31:39 +0900

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=
[email-masked]> 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:
>
> 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
> • User remediation means the problem(s) with the subscription requires
> user intervention.
>
> _______________________________________________
> Captive-portals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/captive-portals
>

---

From: Erik Kline <[email-masked]>
Date: Sun, 12 Jan 2020 14:33:56 -0800

<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
(remediation-supported={true|false})?

On Fri, Jan 10, 2020 at 12:32 AM Remi NGUYEN VAN <reminv=
[email-masked]> wrote:

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

---

From: Heng Liu <[email-masked]>
Date: Mon, 13 Jan 2020 15:26:20 -0800

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

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

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

---

From: David Bird <[email-masked]>
Date: Mon, 13 Jan 2020 15:49:50 -0800

I think one difference is that with Passpoint it is the network signaling
the device... not just some API that may or may not really be
integrated with the network policy changes in the network.

I'd be careful allowing hotspot operators a new avenue to prompt the user
for pure "annoyance" purposes -- only for users using a capport device :-)

On Mon, Jan 13, 2020 at 3:26 PM Heng Liu <liucougar=
[email-masked]> wrote:

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

---

From: Erik Kline <[email-masked]>
Date: Mon, 13 Jan 2020 16:06:53 -0800

> remediation of a session. By providing a 3rd URL, we can accommodate this

If the remediation URL is available but the user (somehow) navigates to the
user-portal-url, what do they see?

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

---

From: Tommy Pauly <[email-masked]>
Date: Mon, 13 Jan 2020 17:02:08 -0800

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 <[email-masked]> wrote:
> 
> 
> 
> On Mon, 13 Jan 2020 at 15:26, Heng Liu <liucougar=[email-masked] <mailto:[email-masked]>> wrote:
> On Sun, Jan 12, 2020 at 2:34 PM Erik Kline <[email-masked] <mailto:[email-masked]>> 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
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/captive-portals <https://www.ietf.org/mailman/listinfo/captive-portals>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/captive-portals <https://www.ietf.org/mailman/listinfo/captive-portals>

---

From: Remi NGUYEN VAN <[email-masked]>
Date: Tue, 14 Jan 2020 11:00:17 +0900

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=
[email-masked]> 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
>

---

From: Tommy Pauly <[email-masked]>
Date: Tue, 14 Jan 2020 12:38:39 -0800

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=[email-masked]> 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=[email-masked] <mailto:[email-masked]>> wrote:
>> On Jan 13, 2020, at 4:06 PM, Erik Kline <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>>

---

From: Heng Liu <[email-masked]>
Date: Tue, 14 Jan 2020 16:20:48 -0800

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 <[email-masked]> 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=[email-masked]> 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.
>>>
>>

---

From: Erik Kline <[email-masked]>
Date: Tue, 14 Jan 2020 16:30:41 -0800

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 <[email-masked]> wrote:

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

---

From: Remi NGUYEN VAN <[email-masked]>
Date: Fri, 17 Jan 2020 16:25:03 +0900

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 <[email-masked]> wrote:

>>>>> this use case..
>>>> another person's complexity..  I think this just doubles the number of URLs
>>>>> (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

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 17 Jan 2020 08:52:33 -0800

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=[email-masked]> 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 <[email-masked] <mailto:[email-masked]>> 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 <[email-masked] <mailto:[email-masked]>> 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.
> 
> On Tue, Jan 14, 2020 at 12:38 PM Tommy Pauly <[email-masked] <mailto:[email-masked]>> wrote:
>> On Jan 13, 2020, at 6:00 PM, Remi NGUYEN VAN <reminv=[email-masked] <mailto:reminv=[email-masked]>> wrote:
>> 
>>> 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..
>>> 
>>> 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.
>>>

---

From: Remi NGUYEN VAN <[email-masked]>
Date: Mon, 20 Jan 2020 12:30:33 +0900

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=
[email-masked]> 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 <
> 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.
>> 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.
>>
>>>> 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
>>>>>> 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?
>>>>>>>

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 20 Jan 2020 13:50:04 +0900

I do think something is needed here because we don't want the device
to put up a "you're running out of time, please click here to extend"
prompt/notification, if tapping that prompt goes to a page that just
says "you're logged in" without allowing the user to extend. If the
network doesn't support extending sessions, then the device should not
display the prompt. So we should give the network a way to express via
the API whether it's possible to extend the user's time or not.

Once we do decide to have something like that in the API, ISTM that a
separate URL is more useful than just a boolean. Whether the URL is
present or not gives you the boolean; the content of the URL makes it
easier for network operators because it means they can provide a
specific "manage my connection" page that is different from the login
page. The operator could of course decide what to display based on the
login state of the user; this just makes it easier.

But as long as this is not the same as the venue URL, that works for
me. We do want it to be separate, because we expect most operators
will primarily want to surface the venue URL, and we don't want them
to have to make a choice between surfacing the venue URL and making
the session easy to extend.

Cheers,
Lorenzo

On Fri, Jan 17, 2020 at 4:25 PM Remi NGUYEN VAN
<reminv=[email-masked]> wrote:
>>>> On Tue, Jan 14, 2020 at 10:02 AM Tommy Pauly <tpauly=[email-masked]> wrote:
>>>>>
>>>>> On Mon, 13 Jan 2020 at 15:26, Heng Liu <liucougar=[email-masked]> wrote:
>>>>>>

---

From: Tommy Pauly <[email-masked]>
Date: Sun, 19 Jan 2020 21:05:05 -0800

Lorenzo, my impression is that the User Portal URL (already distinct from the Venue URL) should cover that use case; or at least we should encourage it to be so. Once a user is logged in, the page generally won’t just show a new log in. If for some reason the renew page needs to be a different URL, it could simply redirect the user portal URL whenever the user is logged in.

If we have three URLs, then we’d have two URLs, the User Portal the new Extend URL, that would each only be useful at certain mutually exclusive times: one before log in and one while logged in. That seems like an easy opportunity to encourage portal designers to have a single page, so we don’t have a UI in android or iOS that ever presents a link that takes you to a useless “you’re logged in” page.

I’m all for having the venue URL be distinct, but let’s just use a Boolean to indicate if the user portal URL is a useful URL while logged in or not. 

Tommy

> On Jan 19, 2020, at 8:50 PM, Lorenzo Colitti <[email-masked]> wrote:
>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 20 Jan 2020 01:54:35 -0500

There are a number of locations where you get 20 minutes free, and then you
have to purchase the extension.  That doesn't seem to fit into remedial to
me. (Montreal Airport comes to mind)

I guess such locations have an incentive to put something other than "you're
logged in" on that page.   What should such a location do?  Do they say the
offer extensions, or not?

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 20 Jan 2020 18:04:19 +1100

> offer extensions, or not?

I don't see why not.  Now you might not be inclined to sell your first-born child [1] to continue, but it's not like the option isn't there.

[1] ...or kidney, or whatever more reasonable terms the network might offer.

---

From: Martin J. Dürst <[email-masked]>
Date: Mon, 20 Jan 2020 07:45:01 +0000

> offer extensions, or not?

Purely as a user, I'd guess something like "you have 12 minutes 30 
seconds of free time left, extend here for 5$ per hour" (where the '12 
minutes 30 seconds' is a counter counting down) would be most useful on 
that page. "logged in" doesn't give much information.

Regards,   Martin.

---

From: Dan Wing <[email-masked]>
Date: Mon, 20 Jan 2020 07:05:56 -0800

To that point, the remediation URL only works if the client and the CP are in sync; that is, if the client wondered off to another network for a while (LTE, because of whatever reason) and then re-connected to WiFi, is the remediation URL supposed to be visited because the wall-clock time expired, or not visited because the time-on-network has not yet expired.  The CP may have abandoned that client, figuring it went away permanently when it disconnected from WiFi.

-d

> On Jan 13, 2020, at 5:02 PM, Tommy Pauly <tpauly=[email-masked]> wrote:
>