Re: [Captive-portals] Remediation url for CAPPORT

[Erik Kline <[e-mail]>]

<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=
[e-mail]> 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=
> [e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/captive-portals
>>
> _______________________________________________
> Captive-portals mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/captive-portals
>