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....@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 >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
