Concluded WG Captive Portal Interaction (capport)
Note: The data for concluded WGs is occasionally incorrect.
| WG | Name | Captive Portal Interaction | |
|---|---|---|---|
| Acronym | capport | ||
| Area | Applications and Real-Time Area (art) | ||
| State | Concluded | ||
| Charter | charter-ietf-capport-01 Approved | ||
| Document dependencies | |||
| Additional resources | GitHub | ||
| Personnel | Chairs | Erik Kline, Martin Thomson | |
| Area Director | Barry Leiba | ||
| Mailing list | Address | captive-portals@ietf.org | |
| To subscribe | https://www.ietf.org/mailman/listinfo/captive-portals | ||
| Archive | https://mailarchive.ietf.org/arch/browse/captive-portals |
Closing note for Working Group
With the recent publication of the Captive Portal Architecture document as RFC 8952, this working group has completed its work. It's time, then, to close the working group. Thanks to everyone who participated in getting this work done, and a big thanks to the document editors: Tommy, Darshak, Warren, Erik, Kyle, David, and Heng. And, of course, special thanks to the chairs, Martin and Erik, for the work they've put into keeping the working group moving. Now let's get the protocol and API deployed. I'll be interested in seeing reports on the mailing list as we get deployment, and as we, as users, notice the effects of having this in place. The mailing list will remain open for that and other related discussion.Final Charter for Working Group
Some networks require interaction from users prior to authorizing
network access. Before that authorization is granted, network access
might be limited in some fashion. Frequently, this authorization process
requires human interaction to arrange for payment or to accept some
legal terms.
Currently, network providers use a number of interception techniques to
reach a human user (such as intercepting cleartext HTTP to force a
redirect to a web page of their choice), and these interceptions are
indistinguishable from man-in-the-middle attacks. As endpoints become
inherently more secure, existing interception techniques will become
less effective or will fail entirely. This will result in a poor user
experience as well as a lower rate of success for the Captive Portal
operator.
The CAPPORT Working Group will define secure mechanisms and protocols to
- allow endpoints to discover that they are in this sort of limited
environment,
- provide a URL to interact with the Captive Portal,
- allow endpoints to learn about the parameters of their confinement,
- interact with the Captive Portal to obtain information such as status
and remaining access time, and
- optionally, advertise a service whereby devices can enable or disable
access to the Internet without human interaction.
(RFC 7710 may be a full or partial solution to the first two bullets)
The working group may produce working documents to define taxonomy and
to survey existing portals and solutions. These might or might not be
published as RFCs, and might or might not be combined in some way.
Out of scope are "roaming" (federation of credentials), network
selection, or the on-boarding/provisioning of clients onto secure (or
any alternate) networks. These are not really captive portals, and have
largely been solved in other ways.
Initially, the working group will focus on simplifying captive portal
interactions where a user is present. A secondary goal is to look at the
problem posed to or by devices that have little or no recourse to human
interaction.
Milestones
| Date | Milestone | Associated documents |
|---|---|---|
| Jul 2019 | API for Captive Portal Interaction | |
| Jul 2019 | API for Captive Portal Interaction | |
| Jul 2019 | Protocol to discover and interact with a Captive Portal |