<?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.13 -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>

<rfc consensus="true" xmlns:xi="http://www.w3.org/2001/XInclude"
     ipr="trust200902" docName="draft-ietf-capport-api-08" number="8908" category="std"
     obsoletes="" updates="" submissionType="IETF" xml:lang="en"
     tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 2.39.0 -->
  <front>
    <title abbrev="Captive Portal API">Captive Portal API</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-capport-api-08"/> name="RFC" value="8908"/>
    <author initials="T." surname="Pauly" fullname="Tommy Pauly" role="editor">
      <organization>Apple Inc.</organization>
      <address>
        <postal>
          <street>One Apple Park Way</street>
          <city>Cupertino, California 95014</city>
          <city>Cupertino</city>
	  <region>CA</region>
	  <code>95014</code>
          <country>United States of America</country>
        </postal>
        <email>tpauly@apple.com</email>
      </address>
    </author>
    <author initials="D." surname="Thakore" fullname="Darshak Thakore" role="editor">
      <organization>CableLabs</organization>
      <address>
        <postal>
          <street>858 Coal Creek Circle</street>
          <city>Louisville, CO 80027</city>
          <city>Louisville</city>
	  <region>CO</region>
	  <code>80027</code>
          <country>United States of America</country>
        </postal>
        <email>d.thakore@cablelabs.com</email>
      </address>
    </author>
    <date month="September" year="2020" month="June" day="18"/> />
    <workgroup>Captive Portal Interaction</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>
      <t>This document describes an HTTP API that allows clients to interact
      with a Captive Portal system. With this API, clients can discover how to
      get out of captivity and fetch state about their Captive Portal
      sessions.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t>This document describes a HyperText Transfer Protocol (HTTP)
      Application Program Programming Interface (API) that allows clients to interact with
      a Captive Portal system. The API defined in this document has been
      designed to meet the requirements in the Captive Portal Architecture
      <xref target="I-D.ietf-capport-architecture"
	    format="default"/>. Specifically, the API provides:</t>
      <ul spacing="normal">
        <li>The state of captivity (whether or not the client has access to
	the Internet)</li> Internet).</li>
        <li>A URI of a user-facing web portal that can be used to get out of captivity</li>
	captivity.</li>
        <li>Authenticated and encrypted connections, using TLS for connections
	to both the API and user-facing web portal</li> portal.</li>
      </ul>
    </section>
    <section anchor="terms" numbered="true" toc="default">
      <name>Terminology</name>
      <t>This document leverages the terminology and components described in
      <xref target="I-D.ietf-capport-architecture" format="default"/> and
      additionally defines the following terms:</t>
      <ul
      <dl newline="true" spacing="normal">
        <li>Captive
        <dt>Captive Portal Client: The Client</dt>
	<dd>The client that interacts with the Captive
	Portal API is typically some application running on the User Equipment user equipment
	that is connected to the Captive Network. captive network. This is also referred to as
	the "client" in this document.</li>
        <li>Captive document.</dd>
        <dt>Captive Portal API Server: The Server</dt>
	<dd>The server exposing the APIs defined in
	this document to the client. This is also referred to as the "API
	server" in this document.</li>
      </ul>
      <t>The document.</dd>
      </dl>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and
"OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are
    to be interpreted as
    described in BCP 14 BCP&nbsp;14 <xref target="RFC2119" format="default"/> target="RFC2119"/> <xref target="RFC8174" format="default"/> target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>
    </section>

    <section anchor="workflow" numbered="true" toc="default">
      <name>Workflow</name>
      <t>The Captive Portal Architecture defines several categories of
      interaction between clients and Captive Portal systems:</t>
      <ol spacing="normal" type="1"> spacing="normal">
        <li>Provisioning, in which a client discovers that a network has a
	captive portal, portal and learns the URI of the API server.</li>
        <li>API Server interaction, in which a client queries the state of
	captivity and retrieves the necessary information to get out of captivity.</li>
	captivity</li>
        <li>Enforcement, in which the enforcement device in the network blocks
	disallowed traffic.</li>
      </ol>
      <t>This document defines the mechanisms used in the second category. It
      is assumed that the location of the Captive Portal API server has been
      discovered by the client as part of Provisioning. provisioning. A set of mechanisms
      for discovering the API Server server endpoint is defined in <xref target="I-D.ietf-capport-rfc7710bis"
      target="RFC8910" format="default"/>.</t>
    </section>
    <section anchor="api-details" numbered="true" toc="default">
      <name>API Connection Details</name>
      <t>The API server endpoint MUST <bcp14>MUST</bcp14> be accessed over HTTP
      using an https URI <xref target="RFC2818" format="default"/>, format="default"/> and SHOULD
      <bcp14>SHOULD</bcp14> use the default https port. For example, if the
      Captive Portal API server is hosted at "example.org", the URI of the API
      could be "https://example.org/captive-portal/api"</t> "https://example.org/captive-portal/api".</t>
      <t>The client SHOULD NOT <bcp14>SHOULD NOT</bcp14> assume that the URI of the API
      server for a given network will stay the same, same and SHOULD <bcp14>SHOULD</bcp14>
      rely on the discovery or provisioning process each time it joins the
      network.</t>
      <t>As described in Section 3 of <xref target="I-D.ietf-capport-architecture" format="default"/>,
      sectionFormat="of" section="3"/>, the identity
      of the client needs to be visible to the Captive Portal API server in
      order for the server to correctly reply with the client's portal
      state. If the identifier used by the Captive Portal system is the
      client's set of IP addresses, the system needs to ensure that the same
      IP addresses are visible to both the API server and the enforcement
      device.</t>
      <t>If the API server needs information about the client identity that is
      not otherwise visible to it, the URI provided to the client during
      provisioning SHOULD <bcp14>SHOULD</bcp14> be distinct per client. Thus,
      depending on how the Captive Portal system is configured, the URI will
      be unique for each client host and between sessions for the same client
      host.</t>
      <t>For example, a Captive Portal system that uses per-client session
      URIs could use "https://example.org/captive-portal/api/X54PD39JV" as its
      API URI.</t>
      <section anchor="server-auth" numbered="true" toc="default">
        <name>Server Authentication</name>
        <t>The purpose of accessing the Captive Portal API over an HTTPS
	connection is twofold: first, the encrypted connection protects the
	integrity and confidentiality of the API exchange from other parties
	on the local network; and second, it provides the client of the API an
	opportunity to authenticate the server that is hosting the API. This
	authentication allows the client to ensure that the entity providing
	the Captive Portal API has a valid certificate for the hostname
	provisioned by the network using the mechanisms defined in <xref target="I-D.ietf-capport-rfc7710bis"
	target="RFC8910" format="default"/>, by validating
	that a DNS-ID <xref target="RFC6125" format="default"/> on the
	certificate is equal to the provisioned hostname.</t>
        <t>Clients performing revocation checking will need some means of
	accessing revocation information for certificates presented by the API
	server. Online Certificate Status Protocol <xref target="RFC6960"
	format="default"/> (OCSP) stapling, using the TLS Certificate Status
	Request extension <xref target="RFC6066" format="default"/> SHOULD format="default"/>,
	<bcp14>SHOULD</bcp14> be used. OCSP stapling allows a client to
	perform revocation checks without initiating new connections. To allow
	for other forms of revocation checking, especially for clients that do
	not support OCSP stapling, a captive network SHOULD <bcp14>SHOULD</bcp14>
	permit connections to OCSP responders or Certificate Revocation Lists
	(CRLs) that are referenced by certificates provided by the API
	server. For more discussion on certificate revocation checks, see Section 6.5 of BCP 195
	<xref target="RFC7525" format="default"/>. sectionFormat="of" section="6.5">BCP 195</xref>. In
	addition to connections to OCSP responders and CRLs, a captive network SHOULD
	<bcp14>SHOULD</bcp14> also permit connections to Network Time Protocol
	(NTP) <xref target="RFC5905" format="default"/> servers or other
	time-sync mechanisms to allow clients to accurately validate
	certificates.</t>
        <t>Certificates with missing intermediate certificates that rely on
	clients validating the certificate chain using the URI specified in
	the Authority Information Access (AIA) extension <xref
	target="RFC5280" format="default"/> SHOULD NOT <bcp14>SHOULD NOT</bcp14> be used
	by the Captive Portal API server. If the certificates do require the
	use of AIA, the captive network MUST <bcp14>MUST</bcp14> allow client
	access to the host specified in the URI.</t>
        <t>If the client is unable to validate the certificate presented by
	the API server, it MUST NOT <bcp14>MUST NOT</bcp14> proceed with any of the
	behavior for API interaction described in this document. The client
	will proceed to interact with the captive network as if the API
	capabilities were not present. It may still be possible for the user
	to access the network if the network redirects a cleartext webpage to
	a web portal.</t>
      </section>
    </section>
    <section anchor="json-keys" numbered="true" toc="default">
      <name>API State Structure</name>
      <t>The Captive Portal API data structures are specified in JavaScript
      Object Notation (JSON) <xref target="RFC8259"
      format="default"/>. Requests and responses for the Captive Portal API
      use the "application/captive+json" media type. Clients SHOULD
      <bcp14>SHOULD</bcp14> include this media type as an Accept header in
      their GET requests, and servers MUST <bcp14>MUST</bcp14> mark this media type
      as their Content-Type header in responses.</t>
      <t>The following key MUST <bcp14>MUST</bcp14> be included in the top-level top level of
      the JSON structure returned by the API server:</t>
      <ul
<table anchor="tab1">
  <thead>
    <tr>
      <th>Key</th>
      <th>Type</th>
      <th>Description</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>captive</td>
      <td>boolean</td>
      <td>Indicates whether the client is in a state of
        captivity, i.e, it has not satisfied the conditions to access the
        external network. If the client is captive (i.e., captive=true), it
        will still be allowed enough access for it to perform server
        authentication (<xref target="server-auth" format="default"/>).
      </td>
    </tr>
  </tbody>
</table>

<!--      <dl newline="true" spacing="normal">
        <li>"captive" (boolean):
        <dt>"captive" (boolean)</dt>
	<dd>This indicates whether the client is in a state of
	captivity, i.e i.e, it has not satisfied the conditions to access the
	external network. If the client is captive (i.e. (i.e., captive=true), it
	will still be allowed enough access for it to perform server
	authentication (<xref target="server-auth" format="default"/>).</li>
      </ul> format="default"/>).</dd>
      </dl>-->
      <t>The following keys can be optionally included in the top-level top level of the
      JSON structure returned by the API server:</t>
      <ul spacing="normal">
        <li>"user-portal-url" (string): provides

<table anchor="tab2">
  <thead>
    <tr>
      <th>Key</th>
      <th>Type</th>
      <th>Description</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>user-portal-url</td>
      <td>string</td>
      <td>Provides the URL of a web portal that MUST be accessed over TLS with
      which a user can interact.</li>
        <li>"venue-info-url" (string): provides interact.</td>
    </tr>
    <tr>
      <td>venue-info-url</td>
      <td>string</td>
      <td>Provides the URL of a webpage or site that SHOULD be accessed over
      TLS on which the operator of the network has information that it wishes
      to share with the user (e.g., store info, maps, flight status, or entertainment).</li>
        <li>"can-extend-session" (boolean): indicates entertainment).</td>
    </tr>
    <tr>
      <td>can-extend-session</td>
      <td>boolean</td>
      <td>Indicates that the URL specified
        as "user-portal-url" allows the user to extend a session once the
        client is no longer in a state of captivity. This provides a hint that
        a client system can suggest accessing the portal URL to the user when
        the session is near its limit in terms of time or bytes.</li>
        <li>"seconds-remaining" (number): an bytes.
      </td>
    </tr>
    <tr>
      <td>seconds-remaining</td>
      <td>number</td>
      <td>An integer that indicates the number
        of seconds remaining, after which the client will be placed into a
        captive state. The API server SHOULD <bcp14>SHOULD</bcp14> include this value
        if the client is not captive (i.e. (i.e., captive=false) and the client
        session is time-limited, time-limited and SHOULD <bcp14>SHOULD</bcp14> omit this value for
        captive clients (i.e. (i.e., captive=true) or when the session is not time-limited.</li>
        <li>"bytes-remaining" (number): an
        time-limited.
      </td>
    </tr>
    <tr>
      <td>bytes-remaining</td>
      <td>number</td>
      <td>An integer that indicates the number of bytes remaining, after
        which the client will be in placed into a captive state. The byte
        count represents the sum of the total number of IP packet (layer 3)
        bytes sent and received by the client, including IP headers. Captive portal
        Portal systems might not count traffic to whitelisted servers, such as
        the API server, but clients cannot rely on such behavior. The API
        server SHOULD <bcp14>SHOULD</bcp14> include this value if the client is not
        captive (i.e. (i.e., captive=false) and the client session is byte-limited, byte-limited
        and SHOULD <bcp14>SHOULD</bcp14> omit this value for captive clients (i.e.
        (i.e., captive=true) or when the session is not byte-limited.</li>
      </ul>
      <t>The valid JSON keys can be extended by adding entries to byte-limited.
      </td>
    </tr>
  </tbody>
</table>

<!--
      <dl newline="true" spacing="normal">
        <dt>"user-portal-url" (string)</dt>
	<dd>This provides the Captive Portal API Keys Registry (<xref target="iana-section" format="default"/>). If URL of a client receives web portal that <bcp14>MUST</bcp14> be
	accessed over TLS with which a key user can interact.</dd>
        <dt>"venue-info-url" (string)</dt>
	<dd>This provides the URL of a webpage or site
	that it does not recognize, it MUST ignore <bcp14>SHOULD</bcp14> be accessed over TLS on which the key and any associated values. All keys other than operator
	of the ones defined in this document as "required" will be considered optional.</t>
      <t>Captive Portal JSON content can contain per-client data network has information that is not appropriate it wishes to share with the user
	(e.g., store in an intermediary cache. Captive Portal API servers SHOULD set info, maps, flight status, or entertainment).</dd>
        <dt>"can-extend-session" (boolean)</dt>
	<dd>This indicates that the Cache-Control header field in any responses URL specified
	as "user-portal-url" allows the user to "private", or extend a more restrictive value such as "no-store" <xref target="RFC7234" format="default"/>.</t>
      <t>Client behavior for issuing requests for updated JSON content session once the
	client is implementation-specific, and no longer in a state of captivity. This provides a hint that
	a client system can be based on suggest accessing the portal URL to the user interaction when
	the session is near its limit in terms of time or bytes.</dd>
        <dt>"seconds-remaining" (number)</dt>
	<dd>This is an integer that indicates the indications number
	of seconds and bytes remaining in a given session. If at any point remaining, after which the client does not receive valid JSON content from the will be placed into a
	captive state. The API server, either due to an error or due to receiving no response, server <bcp14>SHOULD</bcp14> include this value
	if the client SHOULD continue to apply the most recent valid content it had received; or, if no content had been received previously, proceed to interact with is not captive (i.e., captive=false) and the client
	session is time-limited and <bcp14>SHOULD</bcp14> omit this value for
	captive network as if clients (i.e., captive=true) or when the API capabilities were session is not present.</t>
    </section>
    <section anchor="example" numbered="true" toc="default">
      <name>Example Interaction</name>
      <t>A
	time-limited.</dd>
        <dt>"bytes-remaining" (number)</dt>
	<dd>This is an integer that indicates the number of bytes remaining, after
	which the client connected to will be in placed into a captive network upon discovering state. The byte
	count represents the URI sum of the API server will query total number of IP packet (layer 3)
	bytes sent and received by the client, including IP headers. Captive
	Portal systems might not count traffic to whitelisted servers, such as
	the API server, but clients cannot rely on such behavior. The API
	server to retrieve information about its captive state and conditions to escape captivity. In <bcp14>SHOULD</bcp14> include this example, value if the client discovered the URI "https://example.org/captive-portal/api/X54PD39JV" using one of is not
	captive (i.e., captive=false) and the mechanisms defined in <xref target="I-D.ietf-capport-rfc7710bis" format="default"/>.</t>
      <t>To request client session is byte-limited
	and <bcp14>SHOULD</bcp14> omit this value for captive clients
	(i.e., captive=true) or when the session is not byte-limited.</dd>
      </dl>
-->
      <t>The valid JSON keys can be extended by adding entries to the Captive
      Portal JSON content, API Keys Registry (<xref target="iana-field-reg"
      format="default"/>). If a client sends an HTTP GET request:</t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
GET /captive-portal/api/X54PD39JV HTTP/1.1
Host: example.org
Accept: application/captive+json
]]></artwork>
      <t>The server then responds with receives a key that it does not
      recognize, it <bcp14>MUST</bcp14> ignore the key and any associated
      values. All keys other than the ones defined in this document as
      "required" will be considered optional.</t>
      <t>Captive Portal JSON content for can contain per-client data that client:</t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
HTTP/1.1 200 OK
Cache-Control: private
Date: Mon, 02 Mar 2020 05:07:35 GMT
Content-Type: application/captive+json

{
   "captive": true,
   "user-portal-url": "https://example.org/portal.html"
}
]]></artwork>
      <t>Upon receiving this information the client will use this information to direct the user is not
      appropriate to store in an intermediary cache. Captive Portal API
      servers <bcp14>SHOULD</bcp14> set the web portal (as specified by the user-portal-url value) to enable access Cache-Control header field in any
      responses to the external network. Once the "private" or a more restrictive value, such as "no-store"
      <xref target="RFC7234" format="default"/>.</t>
      <t>Client behavior for issuing requests for updated JSON content is
      implementation specific and can be based on user satisfies interaction or the requirements for external network access,
      indications of seconds and bytes remaining in a given session. If at any
      point the client SHOULD query does not receive valid JSON content from the API server again
      server, either due to verify that it is an error or due to receiving no longer captive.</t> response, the
      client <bcp14>SHOULD</bcp14> continue to apply the most recent valid
      content it had received or, if no content had been received previously,
      proceed to interact with the captive network as if the API capabilities
      were not present.</t>
    </section>
    <section anchor="example" numbered="true" toc="default">
      <name>Example Interaction</name>
      <t>Upon discovering the URI of the API server,
      a client connected to a captive network
      will query the API server to retrieve information about
      its captive state and conditions to escape captivity. In this example,
      the client discovered the URI
      "https://example.org/captive-portal/api/X54PD39JV" using one of the
      mechanisms defined in <xref target="RFC8910"
      format="default"/>.</t>
      <t>To request the Captive Portal JSON content, a client sends an HTTP
      GET request:</t>

<sourcecode type="http-message"><![CDATA[
GET /captive-portal/api/X54PD39JV HTTP/1.1
Host: example.org
Accept: application/captive+json
]]></sourcecode>
      <t>The server then responds with the JSON content for that client:</t>
<sourcecode type="http-message"><![CDATA[
HTTP/1.1 200 OK
Cache-Control: private
Date: Mon, 02 Mar 2020 05:07:35 GMT
Content-Type: application/captive+json

{
   "captive": true,
   "user-portal-url": "https://example.org/portal.html"
}
]]></sourcecode>
      <t>Upon receiving this information, the client will use it
      to direct the user to the web portal (as specified by the
      user-portal-url value) to enable access to the external network. Once
      the user satisfies the requirements for external network access, the
      client <bcp14>SHOULD</bcp14> query the API server again to verify that
      it is no longer captive.</t>
      <t>When the client requests the Captive Portal JSON content after
      gaining external network access, the server responds with updated JSON
      content:</t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
<sourcecode type="http-message"><![CDATA[
HTTP/1.1 200 OK
Cache-Control: private
Date: Mon, 02 Mar 2020 05:08:13 GMT
Content-Type: application/captive+json

{
   "captive": false,
   "user-portal-url": "https://example.org/portal.html",
   "venue-info-url": "https://flight.example.com/entertainment",
   "seconds-remaining": 326,
   "can-extend-session": true
}
]]></artwork>
]]></sourcecode>
    </section>
    <section anchor="security" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>One of the goals of this protocol is to improve the security of the
      communication between client hosts and Captive Portal systems. Client
      traffic is protected from passive listeners on the local network by
      requiring TLS-encrypted connections between the client and the Captive
      Portal API server, as described in <xref target="api-details"
      format="default"/>. All communication between the clients and the API
      server MUST <bcp14>MUST</bcp14> be encrypted.</t>
      <t>In addition to encrypting communications between clients and Captive
      Portal systems, this protocol requires a basic level of authentication
      from the API server, as described in <xref target="server-auth"
      format="default"/>. Specifically, the API server MUST <bcp14>MUST</bcp14>
      present a valid certificate on which the client can perform revocation
      checks. This allows the client to ensure that the API server has
      authority for the hostname that was provisioned by the network using
      <xref target="I-D.ietf-capport-rfc7710bis" target="RFC8910" format="default"/>. Note that
      this validation only confirms that the API server matches what the
      network's provisioning mechanism (such as DHCP or IPv6 Router
      Advertisements) provided, and provided; it is not validating the security of those
      provisioning mechanisms or the user's trust relationship to the
      network.</t>
      <section anchor="privacy" numbered="true" toc="default">
        <name>Privacy Considerations</name>
        <t>Information passed between a client and the user-facing web portal
	may include a user's personal information, such as a full name and credit card details. Therefore, it is important that both the user-facing web portal and the API server that points a client to the web portal are only accessed over encrypted connections.</t>
        <t>It is important to note that although communication to the user-facing web portal requires using TLS, the authentication only validates that the web portal server matches the name in the URI provided by the API server. Since this is not a name that a user typed in, the hostname of the web site that would be presented to the user may include "confusable characters" that can mislead the user. See Section 12.5 of <xref target="RFC8264" format="default"/> for a discussion of confusable characters.</t>
      </section>
    </section>
    <section anchor="iana-section" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>IANA is requested to create a registration for an "application/captive+json" media type (<xref target="iana-json" format="default"/>) and a registry for fields in that format (<xref target="iana-field-reg" format="default"/>).</t>
      <section anchor="iana-json" numbered="true" toc="default">
        <name>Captive Portal API JSON Media Type Registration</name>
        <t>This document registers the media type for Captive Portal API JSON text, "application/captive+json".</t>
        <t>Type name: application</t>
        <t>Subtype name: captive+json</t>
        <t>Required parameters: N/A</t>
        <t>Optional parameters: N/A</t>
        <t>Encoding considerations: Encoding considerations are identical to those specified for the "application/json" media type.</t>
        <t>Security considerations: See <xref target="security" format="default"/></t>
        <t>Interoperability considerations: This document specifies format of conforming messages and the interpretation thereof.</t>
        <t>Published specification: This document</t>
        <t>Applications that use this media type: This media type is intended to be used by servers presenting the Captive Portal API, and clients connecting to such captive networks.</t>
        <t>Fragment identifier considerations: N/A</t>
        <t>Additional information: N/A</t>
        <t>Person and email address to contact for further information: See Authors' Addresses section</t>
        <t>Intended usage: COMMON</t>
        <t>Restrictions on usage: N/A</t>
        <t>Author: CAPPORT IETF WG</t>
        <t>Change controller: IETF</t>
      </section>
      <section anchor="iana-field-reg" numbered="true" toc="default">
        <name>Captive Portal API Keys Registry</name>
        <t>IANA is asked to create and maintain a new registry called "Captive Portal API Keys", which will reserve JSON keys for use in Captive Portal API data structures. The initial contents of this registry are provided in <xref target="json-keys" format="default"/>.</t>
        <t>Each entry in the registry contains the following fields:</t>
        <dl newline="false" spacing="normal">
          <dt>Key:</dt>
          <dd>
  The JSON key being registered, in string format.</dd>
          <dt>Type:</dt>
          <dd>
  The type of the JSON value to be stored, as one of the value types defined in <xref target="RFC8259" format="default"/>.</dd>
          <dt>Description:</dt>
          <dd>
  A brief description explaining the meaning of the value, how it might be used, and/or how it should be interpreted by clients.</dd>
          <dt>Specification:</dt>
          <dd>
  A reference to a specification that defines the key and explains its usage.</dd>
        </dl>
        <t>New assignments for Captive Portal API Keys Registry will be administered by IANA using the Specification Required policy <xref target="RFC8126" format="default"/>.
The Designated Expert is expected to validate the existence of documentation describing new keys in a permanent
publicly available specification, such as an Internet Draft or RFC. The expert is expected to validate that new keys have a
clear meaning and do not create unnecessary confusion or overlap with existing keys. Keys that are specific to
non-generic use cases, particularly ones that are not specified as part of an IETF document, are encouraged to
use a domain-specific prefix.</t>
      </section>
    </section>
    <section anchor="thanksall" numbered="true" toc="default">
      <name>Acknowledgments</name>
      <t>This work in this document was started by Mark Donnelly and Margaret Cullen. Thanks to everyone in the CAPPORT Working Group who has given input.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <seriesInfo name="DOI" value="10.17487/RFC2119"/>
            <seriesInfo name="RFC" value="2119"/>
            <seriesInfo name="BCP" value="14"/>
            <author initials="S." surname="Bradner" fullname="S. Bradner">
              <organization/>
            </author>
            <date year="1997" month="March"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <seriesInfo name="DOI" value="10.17487/RFC8174"/>
            <seriesInfo name="RFC" value="8174"/>
            <seriesInfo name="BCP" value="14"/>
            <author initials="B." surname="Leiba" fullname="B. Leiba">
              <organization/>
            </author>
            <date year="2017" month="May"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC2818" target="https://www.rfc-editor.org/info/rfc2818">
          <front>
            <title>HTTP Over TLS</title>
            <seriesInfo name="DOI" value="10.17487/RFC2818"/>
            <seriesInfo name="RFC" value="2818"/>
            <author initials="E." surname="Rescorla" fullname="E. Rescorla">
              <organization/>
            </author>
            <date year="2000" month="May"/>
            <abstract>
              <t>This memo describes how to use Transport Layer Security (TLS) to secure Hypertext Transfer Protocol (HTTP) connections over the Internet.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC6125" target="https://www.rfc-editor.org/info/rfc6125">
          <front>
            <title>Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)</title>
            <seriesInfo name="DOI" value="10.17487/RFC6125"/>
            <seriesInfo name="RFC" value="6125"/>
            <author initials="P." surname="Saint-Andre" fullname="P. Saint-Andre">
              <organization/>
            </author>
            <author initials="J." surname="Hodges" fullname="J. Hodges">
              <organization/>
            </author>
            <date year="2011" month="March"/>
            <abstract>
              <t>Many application technologies enable secure communication between two entities by means of Internet Public Key Infrastructure Using X.509 (PKIX) certificates in the context of Transport Layer Security (TLS). This document specifies procedures for representing and verifying the identity of application services in such interactions.   [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC6960" target="https://www.rfc-editor.org/info/rfc6960">
          <front>
            <title>X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP</title>
            <seriesInfo name="DOI" value="10.17487/RFC6960"/>
            <seriesInfo name="RFC" value="6960"/>
            <author initials="S." surname="Santesson" fullname="S. Santesson">
              <organization/>
            </author>
            <author initials="M." surname="Myers" fullname="M. Myers">
              <organization/>
            </author>
            <author initials="R." surname="Ankney" fullname="R. Ankney">
              <organization/>
            </author>
            <author initials="A." surname="Malpani" fullname="A. Malpani">
              <organization/>
            </author>
            <author initials="S." surname="Galperin" fullname="S. Galperin">
              <organization/>
            </author>
            <author initials="C." surname="Adams" fullname="C. Adams">
              <organization/>
            </author>
            <date year="2013" month="June"/>
            <abstract>
              <t>This document specifies a protocol useful in determining the current status of a digital certificate without requiring Certificate Revocation Lists (CRLs). Additional mechanisms addressing PKIX operational requirements are specified in separate documents.  This document obsoletes RFCs 2560 and 6277.  It also updates RFC 5912.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC6066" target="https://www.rfc-editor.org/info/rfc6066">
          <front>
            <title>Transport Layer Security (TLS) Extensions: Extension Definitions</title>
            <seriesInfo name="DOI" value="10.17487/RFC6066"/>
            <seriesInfo name="RFC" value="6066"/>
            <author initials="D." surname="Eastlake 3rd" fullname="D. Eastlake 3rd">
              <organization/>
            </author>
            <date year="2011" month="January"/>
            <abstract>
              <t>This document provides specifications for existing TLS extensions.  It is a companion document for RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2".  The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC5905" target="https://www.rfc-editor.org/info/rfc5905">
          <front>
            <title>Network Time Protocol Version 4: Protocol and Algorithms Specification</title>
            <seriesInfo name="DOI" value="10.17487/RFC5905"/>
            <seriesInfo name="RFC" value="5905"/>
            <author initials="D." surname="Mills" fullname="D. Mills">
              <organization/>
            </author>
            <author initials="J." surname="Martin" fullname="J. Martin" role="editor">
              <organization/>
            </author>
            <author initials="J." surname="Burbank" fullname="J. Burbank">
              <organization/>
            </author>
            <author initials="W." surname="Kasch" fullname="W. Kasch">
              <organization/>
            </author>
            <date year="2010" month="June"/>
            <abstract>
              <t>The Network Time Protocol (NTP) is widely used to synchronize computer clocks in the Internet.  This document describes NTP version 4 (NTPv4), which is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305, as well as previous versions of the protocol. NTPv4 includes a modified protocol header to accommodate the Internet Protocol version 6 address family.  NTPv4 includes fundamental improvements in the mitigation and discipline algorithms that extend the potential accuracy to the tens of microseconds with modern workstations and fast LANs.  It includes a dynamic server discovery scheme, so that in many cases, specific server configuration is not required.  It corrects certain errors in the NTPv3 design and implementation and includes an optional extension mechanism.   [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC5280" target="https://www.rfc-editor.org/info/rfc5280">
          <front>
            <title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
            <seriesInfo name="DOI" value="10.17487/RFC5280"/>
            <seriesInfo name="RFC" value="5280"/>
            <author initials="D." surname="Cooper" fullname="D. Cooper">
              <organization/>
            </author>
            <author initials="S." surname="Santesson" fullname="S. Santesson">
              <organization/>
            </author>
            <author initials="S." surname="Farrell" fullname="S. Farrell">
              <organization/>
            </author>
            <author initials="S." surname="Boeyen" fullname="S. Boeyen">
              <organization/>
            </author>
            <author initials="R." surname="Housley" fullname="R. Housley">
              <organization/>
            </author>
            <author initials="W." surname="Polk" fullname="W. Polk">
              <organization/>
            </author>
            <date year="2008" month="May"/>
            <abstract>
              <t>This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet.  An overview of this approach and model is provided as an introduction.  The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms.  Standard certificate extensions are described and two Internet-specific extensions are defined.  A set of required certificate extensions is specified.  The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions.  An algorithm for X.509 certification path validation is described.  An ASN.1 module and examples are provided in the appendices.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8259" target="https://www.rfc-editor.org/info/rfc8259">
          <front>
            <title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
            <seriesInfo name="DOI" value="10.17487/RFC8259"/>
            <seriesInfo name="RFC" value="8259"/>
            <seriesInfo name="STD" value="90"/>
            <author initials="T." surname="Bray" fullname="T. Bray" role="editor">
              <organization/>
            </author>
            <date year="2017" month="December"/>
            <abstract>
              <t>JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format.  It was derived from the ECMAScript Programming Language Standard.  JSON defines a small set of formatting rules for the portable representation of structured data.</t>
              <t>This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC7234" target="https://www.rfc-editor.org/info/rfc7234">
          <front>
            <title>Hypertext Transfer Protocol (HTTP/1.1): Caching</title>
            <seriesInfo name="DOI" value="10.17487/RFC7234"/>
            <seriesInfo name="RFC" value="7234"/>
            <author initials="R." surname="Fielding" fullname="R. Fielding" role="editor">
              <organization/>
            </author>
            <author initials="M." surname="Nottingham" fullname="M. Nottingham" role="editor">
              <organization/>
            </author>
            <author initials="J." surname="Reschke" fullname="J. Reschke" role="editor">
              <organization/>
            </author>
            <date year="2014" month="June"/>
            <abstract>
              <t>The Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems.  This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8126">
          <front>
            <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
            <seriesInfo name="DOI" value="10.17487/RFC8126"/>
            <seriesInfo name="RFC" value="8126"/>
            <seriesInfo name="BCP" value="26"/>
            <author initials="M." surname="Cotton" fullname="M. Cotton">
              <organization/>
            </author>
            <author initials="B." surname="Leiba" fullname="B. Leiba">
              <organization/>
            </author>
            <author initials="T." surname="Narten" fullname="T. Narten">
              <organization/>
            </author>
            <date year="2017" month="June"/>
            <abstract>
              <t>Many protocols make use of points of extensibility that use constants to identify various protocol parameters.  To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper.  For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
              <t>To make assignments in as a given registry prudently, guidance describing full name and
	credit card details. Therefore, it is important that both the conditions under which new values should be assigned, as well as when
	user-facing web portal and how modifications the API server that points a client to existing values can be made, the
	web portal are only accessed over encrypted connections.</t>
        <t>It is needed.  This document defines a framework for important to note that although communication to the documentation
	user-facing web portal requires use of these guidelines by specification authors, in order to assure TLS, the authentication only
	validates that the web portal server matches the name in the URI
	provided guidance for by the IANA Considerations API server. Since this is clear and addresses the various issues not a name that are likely in the operation of a registry.</t>
              <t>This is user typed
	in, the third edition hostname of this document; it obsoletes RFC 5226.</t>
            </abstract>
          </front>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="I-D.ietf-capport-architecture" target="http://www.ietf.org/internet-drafts/draft-ietf-capport-architecture-08.txt">
          <front>
            <title>CAPPORT Architecture</title>
            <seriesInfo name="Internet-Draft" value="draft-ietf-capport-architecture-08"/>
            <author initials="K" surname="Larose" fullname="Kyle Larose">
              <organization/>
            </author>
            <author initials="D" surname="Dolson" fullname="David Dolson">
              <organization/>
            </author>
            <author initials="H" surname="Liu" fullname="Heng Liu">
              <organization/>
            </author>
            <date month="May" day="11" year="2020"/>
            <abstract>
              <t>This document describes a CAPPORT architecture.  DHCP or Router Advertisements, an optional signaling protocol, and an HTTP API are used the website that would be presented to provide the solution.  The role user
	may include "confusable characters", which can mislead the user. See
	<xref target="RFC8264" sectionFormat="of" section="12.5"/> for a
	discussion of Provisioning Domains (PvDs) is described.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="I-D.ietf-capport-rfc7710bis" target="http://www.ietf.org/internet-drafts/draft-ietf-capport-rfc7710bis-07.txt">
          <front>
            <title>Captive-Portal Identification in DHCP / RA</title>
            <seriesInfo name="Internet-Draft" value="draft-ietf-capport-rfc7710bis-07"/>
            <author initials="W" surname="Kumari" fullname="Warren Kumari">
              <organization/>
            </author>
            <author initials="E" surname="Kline" fullname="Erik Kline">
              <organization/>
            </author>
            <date month="May" day="23" year="2020"/>
            <abstract>
              <t>In many environments offering short-term or temporary Internet access (such as coffee shops), it is common to start new connections in confusable characters.</t>
      </section>
    </section>
    <section anchor="iana-section" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>IANA has registered the
      "application/captive+json" media type (<xref target="iana-json"
      format="default"/>) and created a captive portal mode.  This highly restricts what registry for fields in that format (<xref
      target="iana-field-reg" format="default"/>).</t>
      <section anchor="iana-json" numbered="true" toc="default">
        <name>Captive Portal API JSON Media Type Registration</name>
        <t>This document registers the customer can do until media type for Captive Portal API JSON
	text, "application/captive+json".</t>
	<dl newline="false" spacing="normal">
        <dt>Type name:</dt>
	<dd>application</dd>
        <dt>Subtype name:</dt>
	<dd>captive+json</dd>
        <dt>Required parameters:</dt>
	<dd>N/A</dd>
        <dt>Optional parameters:</dt>
	<dd>N/A</dd>
        <dt>Encoding considerations:</dt>
	<dd>Encoding considerations are identical to those specified for the customer has authenticated.  This
	"application/json" media type.</dd>
        <dt>Security considerations:</dt>
	<dd>See <xref target="security" format="default"/></dd>
        <dt>Interoperability considerations:</dt>
	<dd>This document describes a DHCPv4 and DHCPv6 option and a Router Advertisement (RA) option to inform clients that they are behind some sort specifies format of captive-portal enforcement device, conforming messages and that they will need to authenticate to get Internet access.  It is not a full solution to address all of the issues
	interpretation thereof.</dd>
        <dt>Published specification:</dt>
	<dd>RFC 8908</dd>
        <dt>Applications that clients may have with captive portals; it use this media type:</dt>
	<dd>This media type is designed intended to be one component of a standardized approach for hosts used by servers presenting the
	Captive Portal API, and clients connecting to interact with such portals.  While this document defines how the network operator may convey the captive portal API endpoint to hosts, the specific methods of authenticating to,
	networks.</dd>
        <dt>Fragment identifier considerations:</dt>
	<dd>N/A</dd>
        <dt>Additional Information:</dt>
	<dd>N/A</dd>
        <dt>Person and interacting with the captive portal are out of scope of this document.  This document replaces RFC 7710.  RFC 7710 used DHCP code point 160. Due email address to a conflict, this document specifies 114.  [ This document is being collaborated contact for further information:</dt>
	<dd>See Authors' Addresses section</dd>
        <dt>Intended usage:</dt>
	<dd>COMMON</dd>
        <dt>Restrictions on usage:</dt>
	<dd>N/A</dd>
        <dt>Author:</dt>
	<dd>CAPPORT IETF WG</dd>
        <dt>Change controller:</dt>
	<dd>IETF</dd>
	</dl>
      </section>
      <section anchor="iana-field-reg" numbered="true" toc="default">
        <name>Captive Portal API Keys Registry</name>
        <t>IANA has created a new registry called "Captive
	Portal API Keys", which reserves JSON keys for use in Github at: https://github.com/capport-wg/7710bis. Captive
	Portal API data structures. The most recent version initial contents of this registry are
	provided in <xref target="json-keys" format="default"/>.</t>
        <t>Each entry in the document, open issues, etc should all be available here.  The authors (gratefully) accept pull requests.  Text registry contains the following fields:</t>
        <dl newline="false" spacing="normal">
          <dt>Key:</dt>
          <dd>The JSON key being registered in square brackets will be removed before publication. ]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC7525" target="https://www.rfc-editor.org/info/rfc7525">
          <front>
            <title>Recommendations for Secure Use string format.</dd>
          <dt>Type:</dt>
          <dd>The type of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)</title>
            <seriesInfo name="DOI" value="10.17487/RFC7525"/>
            <seriesInfo name="RFC" value="7525"/>
            <seriesInfo name="BCP" value="195"/>
            <author initials="Y." surname="Sheffer" fullname="Y. Sheffer">
              <organization/>
            </author>
            <author initials="R." surname="Holz" fullname="R. Holz">
              <organization/>
            </author>
            <author initials="P." surname="Saint-Andre" fullname="P. Saint-Andre">
              <organization/>
            </author>
            <date year="2015" month="May"/>
            <abstract>
              <t>Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are widely used the JSON value to protect data exchanged over application protocols such be stored, as HTTP, SMTP, IMAP, POP, SIP, and XMPP.  Over the last few years, several serious attacks on TLS have emerged, including attacks on its most commonly used cipher suites and their modes one of operation.  This document provides recommendations for improving the security value
	  types defined in <xref target="RFC8259" format="default"/>.</dd>
          <dt>Description:</dt>
          <dd>A brief description explaining the meaning of deployed services the value, how it
	  might be used, and/or how it should be interpreted by clients.</dd>
          <dt>Refrence:</dt>
          <dd>A reference to a specification that use TLS defines the key and DTLS. explains
	  its usage.</dd>
        </dl>
        <t>New assignments for the "Captive Portal API Keys" registry will be
	administered by IANA using the Specification Required policy <xref
	target="RFC8126" format="default"/>. The recommendations are applicable designated expert is expected
	to validate the majority of use cases.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8264" target="https://www.rfc-editor.org/info/rfc8264">
          <front>
            <title>PRECIS Framework: Preparation, Enforcement, and Comparison existence of Internationalized Strings in Application Protocols</title>
            <seriesInfo name="DOI" value="10.17487/RFC8264"/>
            <seriesInfo name="RFC" value="8264"/>
            <author initials="P." surname="Saint-Andre" fullname="P. Saint-Andre">
              <organization/>
            </author>
            <author initials="M." surname="Blanchet" fullname="M. Blanchet">
              <organization/>
            </author>
            <date year="2017" month="October"/>
            <abstract>
              <t>Application protocols using Unicode code points documentation describing new keys in protocol strings need to properly handle a
	permanent, publicly available specification, such strings in order to enforce internationalization rules for strings placed in various protocol slots (such as addresses and identifiers) and to perform valid comparison operations (e.g., for purposes of authentication an Internet-Draft
	or authorization).  This document defines a framework enabling application protocols RFC. The expert is expected to perform the preparation, enforcement, and comparison of internationalized strings ("PRECIS") in a way validate that depends on the properties of Unicode code points new keys have a clear
	meaning and thus is more agile do not create unnecessary confusion or overlap with respect
	existing keys. Keys that are specific to versions nongeneric use cases,
	particularly ones that are not specified as part of Unicode.  As a result, this framework provides an IETF document,
	are encouraged to use a more sustainable approach domain-specific prefix.</t>
      </section>
    </section>
  </middle>
  <back>
<displayreference target="I-D.ietf-capport-architecture" to="CAPPORT-ARCH"/>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2818.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6125.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6960.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6066.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5905.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8259.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7234.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
      </references>
      <references>
        <name>Informative References</name>
<!--  draft-ietf-capport-architecture-08: Submitted to IESG for Publication -->
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-capport-architecture-08.xml"/>

<!-- [rfced] Note that we have updated the handling of internationalized strings than the previous framework, known as Stringprep (RFC 3454).  This document obsoletes reference for
draft-ietf-capport-rfc7710bis to refer to RFC-to-be 8910.  We expect to
initiate AUTH48 for RFC 7564.</t>
            </abstract> 8910 next week.
-->

<!-- draft-ietf-capport-rfc7710bis-07: Submitted to IESG for Publication -->
<reference anchor='RFC8910' target="https://www.rfc-editor.org/info/rfc8910">
<front>
<title>Captive-Portal Identification in DHCP / Router Advertisement (RA)</title>
<author initials='W' surname='Kumari' fullname='Warren Kumari'>
    <organization />
</author>
<author initials='E' surname='Kline' fullname='Erik Kline'>
    <organization />
</author>
<date month='September' year='2020' />
</front>
<seriesInfo name='RFC' value='8910' />
<seriesInfo name="DOI" value="10.17487/RFC8910"/>
</reference>

        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7525.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8264.xml"/>
      </references>
    </references>
    <section anchor="thanksall" numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>This work was started by <contact fullname="Mark
      Donnelly"/> and <contact fullname="Margaret Cullen"/>. Thanks to
      everyone in the CAPPORT Working Group who has given input.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAFIr7F4AA8Vca3PjRnb9zl/R4XywVCE5ksaaB7dSWYWSbXlnJEXSxEml
Uqkm0CRhgQCMBqRhVNrfvvfc2w00SEjjxyZx2WOSALpv38e5T8x4PB5USZWa
qZrpokrujbrKy0qn6uTqfKDn89Lc916K8yjTa3osLvWiGiemWowjXRR0x1gX
yfjg/SDWlZkOIvpzmZebqbJVPBgkRTlVVVnb6ujg4MPB0eDObB7yMp6q86wy
ZWaq8SlWHNCPd8syr4ud7flGHVVJng1spbP4v3WaZ0TKxthBkUzVf1Z5NFKW
7i7NwtKnzRof/msw0HW1ysvpQKkx/adUktmpup2oK12nG/5FDnWbr9eb4Ncy
B4dMnFR5yT/k5XKqTooiNURONOHfLG1nqqm6zIy7dKXLO/WTljWipCImzOrC
lFWS5SM6Vpos8jJLtPpwfHD4rdyV11kFbn3OksrE6qYi/lmVL9TJ2pRJpPku
s9ZJSnwsQOGfNTabRPm6e67Tibpd6bu8NMHJTnVp6cfOlf7TzfQ8NR/13HYO
9/74vZrlJIUZfb9Ts6SMUhOc72NeJ/Y+SVNDB7xU7w8Ojt799oPFk0ro+3ME
KlKigs83GI/Hir5UkP9gcLtKrCJNrNcmq1RsbFQmc1pUZ+qH29srKKqihSql
0zR/sCpKE7rRqionDokSqYekWim9rWN2YyuznqifcLXCNrTWqFkgoh3ixEb5
vSnVKn/AiktTqbyucKKIFyN+ECWxWpgqWhED6bxEO26pViYpd7Y01pJK24mc
cp3EMXF28Ar6XuZxLQr//JnVDxtSrVvzpVK3pc7sgki7KnOyhTxVe+DHPqsl
sRor4dqy1Gsxp4WOjNqjM+7/QYbdrgyzPTaLJCMxJ5mwr6F4pa2aG5OB9GSJ
W2jxNekWuKJK80udlGbNu/KzZgd9ymhFGhRVdWnU4+M/n49PJ134CW54epqo
m8JEyYKOnaabEa8IAosyv0+Ihimxm6kWAXWkt/ewMnR/SQahslwoFJbwMXQU
kcxAPy54/Nqn9U7U5+tzrKVVbU05JvYm2VI9mLkq5BTMZajR3OCW+DkNwmIE
WrQl5Eb3QaNMFpWbAt+iPMsMawbhXG2xye3HG0WwEl7C4vOcNVkOj0X6CYPC
3ZpyTQiV5suNenxFp1rbp23FSw2pvl6S4mHNKngCa5OtFgTJEKLXUFaFr4uL
H9cxYRERDok5TZJ9Fjn0EhQzVSQ7QrxtBZmxhKYsVCct5rbXYCsq3KdaxBo6
ZLUpRFvIh6zJZgOjKessw/a5qOZn4qE6I5Ut1u021rNepBruc2Eq+DWYCd1G
/+rU5qT0ZKul3K3loEMhfLhjP5O+E4PuG1OSROTUlj8r86XIWSWc2O3zVuno
lF1/BXnYUXbpI3EAIsixK3h2q4afPt/cDkfyf3VxyZ+vz/718/n12Sk+3/xw
8vFj80HuGNCXy88f3XV8ap+cXX76dHZxKg/Tr2rrp08n/0H/I00aDC+vbs8v
L04+7pKpNOEHDMOIZhSlYfvaUtl/mV0p8s2Pj/9w/d3s6PDwA+mofHl/+O5b
+kIYkfFmpBSkMvx1QEzaQHGMLrEIKRNMOiFhkZ3SFpacRqYIWswEFvcTKcWC
NFs49xLgeWuwbH9YlcOrRFxp0oZGdK7qATjrMRwU9oI2zOhwAn9wn8ADkcaM
QPTDKomA9M6GvL+zzkOoTJRZoNAhlnEwIgxJ6fiZaIzDQw9AojuTwdEkUN6Q
/D4KfqkNH7TqR2vsSDKkW+7dTWSEBNC63NBiBIlrseFnkHYyeDNRZ7gvYv8T
UIC1THuFhHCfRMb7J8+HeZpHdxZ8Yu8Jg6FIlhzPZNdrt5C2NtFKZ4ldW/ED
blFrCERiL97NRJ0zsmhraYlYRID7aE85lWNuDzI4NGgdrxMkLTPfhD6Nbih0
yVwJlYFERGvwzwGxcDF+pQBjvChNFhc5yRNEB6jT5wDKRfTu3eHBPLHkrWEN
WGbWeC91aioKCi25IiQWsXx7ElMJztfsyChDVi3umfblKI0DQvGQ5HVXVVVY
Vkpn2O8P3z89idY6tCFp8KGIeoqyK/cIKJ6o73Kgq14XCHOTr3GeWLDKLYNL
pYbuuQkF2cNRn21QpJzGOMCQt5y+fh088trZ2Vjs7DWxZCiscEJssdIpS6sr
vTbIgtRqSWtmjSo/UAAPExP1sJQ5dFhTGgI65wK9DmwQJBWB2uALx0dGw4QS
oiSp1M8kIhuaDUn8ZAtyb5zg34Dar4cMwkSK5ShGIhhwJ3TsyIyJrYN5kEbZ
xLZT7hEYmVMZO95UrUOlB6OcXGFU0flLUwDufSgh+31jfYDHAEVmuwioWyS0
CFu5M7xePOYQJFzRGd/5FQKjEjpt5czu/uaMJrPwEY3AIbjOY+zzAjZ0gkJ3
SMi5H/BIVOc76iObh/ja5DheBo1ofHyEWDpHYP2Q2A49SdVahAvQ425souK6
dMrVappTyzlrIyXXlKVQKhREMzUxLDYFQYQL3jhne0kAhL6LZEncjFuK2CoQ
r2cJuSJWDtZtnxKQjTP3vOf1GV2rRpBHcDcxtIMkz2RVwrca8qNjjd0CbnVQ
Zh1mALJ+JWi8/vfjb69O33z48d+GwP2k4gwXiwGCX3kYD3IP7PX4SqQ+RiHF
QXBRlxRmsi8WxPXeoMe+clEwBuObIENhlX/IKbyPp2qRlNbpQV+iA9HD9sVI
EDIsS+/+WWqsbToNsABbmy9wXUsSW5mvRfvY23HklDW+NPW49CdeUNzwCMjl
E8ZQGYP16VQ5oxNpB1SdYuUgb+ugiLMCaEDgOV3Urbscd4l4sGePnTvzEgpf
YL9EavfEG2IVylALIc7rJyhCmai1rhaqvGuoG/kGwcBv8PAjLMgkaHd6DiZP
L27G56fOG789PDqmyNqJJaSUGGR+qZE/CyiEhHrqSYFnLuYlcwEuYZ/S3PtQ
KVqZ6I7TXhg0AEwSvbXRme3qcfBUCHGcX7dk0UaEr7Rjy64gyFWXWUrcUbPg
HKh+1batz7hzf3h7QOfeu5zdXO3Dg1DiiWC85TmS+551rokphtDHfKlIN9hS
ZcGDt29pwRYf4XyIIFq/Wd6rmA4UzPFth2mSOgPeE9LyRCSYmYew2EB6nMua
zCaxNKzGrO0Rw0gZixINZ9zMWV91gmrEObsLW7MqdUkfBXmH10931gIViWq7
CMJPk6gKMmpkMrRZyM3rlriP5Eis2ptdf7S+JFYaSYUJlETOWxrg3FWPAgDk
13kpwVItsA0GBFvvcHpET5smFHo7OQb3OBn9cAwjI+m+O4aZUIyRNRUTCVFe
PDPngXSsF5jHaX8/B10FQ90inmvLixeoLorOHX84gPHK2ZnFogKIAMd2k0Uh
cFReVYJKI1lfXRJP0gYnOhiAAuks5DyHYOtEDJZTSMqQku2nRIg+cvXbdYCo
CzVEI8FZa3qIAKyUEts07YQbCgDf8wAeTqQwuHdyfrK/Y5PHR+8PWptEnO5L
gP1BYahILvzqnCvOfdWUr9XiimlrcaHbIubsKOT5VhmTo5idc0pccN4JrQmL
60y7yK2R1DYbX0BGdqu+JiTpAt0m9eWscd5zs9L3SS7BOFfogiJHJ2/oVqHC
+h8Dvd9gp5jdxybEREFKpgs9TyikQLTwQBDAmOSOxrn5mnIlcucSIFI8JCGt
d6yotTrVZlYH/tTt4r9SwJmUHN0Ajw0FKCjoP5h5oZfMaB0Ua5tsmZsp9GdZ
u7L4q59tno3vzMYnyj1KReLS6OvIM5IbdAT/o77XN8TegmB3/jMRpS7ySjR8
78ebywtv8e+Pjj8Ah5wXsq4SA8RBzOqZ0EOCz7GHQY3VB6v/iCMMFdsySrKU
THm37myHAv20jo3Ivb0PstNihET5yuhYUjrpunx/dsv2AkJHLsYTpGJNXKNl
17Oga9nkpDhZNb7Fr+3KzVld6bMtU6MI6usRjtzGpqq8GKOMnnpNB09bgaCW
VZdZn+Fwz2Lo+DRUe/M8J1XJ9qe0dOxR0bUuugaLWmRP7YwsccLpOSJEdrck
Cst6wM+T60gaFxAoMbCtzNqguUWoZkdvWHu0w8R/+yc6pNln+3elBmc5vnJm
srxervxW0KCkE5j4XLUbLO89Pob5ydN+nzysb7vkRdNj+HuLhnsrYqPjukxJ
RPQs7U8S6qQRn68/SpdouzPUX8NC9MeI5QujjCs4jge0CXa/N1ltxohXf/Xm
jC7EZZtULq9oY8ZdGvKwMJqTTHQFN99FMqhSp+zKaQ8EbleGFcmuADkNBPNh
9sxkOaHYp0K4hMdHZJIFWeoiTZarinUX2TzSZpy5IicNuN+fiElkY/a38dil
x89YR1AT+xiAHpG8K7sgBfM4LnvAlIyP5iKzpfhZTgklJZzlc0bnEr5GJlqt
Et9EaoJxVwGAjG29XCLI72bZTmtwDufBmUi0IVzSKRSCIu5GEH6mCSI76Lpx
YTmX54in8w0HWMRKyXztuERLHlUW4mRWr+emJEY6jVs22WzAWNIAvg3LukVU
swgh7qJi8rz6hB4arjPVEdshuzoPHq6YtlXx7XMDFIfUxjvVUBjVM0i0oGDX
7DdVr63iCuoSiFuZY6gFBVXQHEwMNuXUxe3h48se1AObe6WDBnOwF0uB5fHH
ZMBL/AYJkFp8VQhYUyY6UAaVMMj1Zeq1B4Iqh2K2hJxfqUJHd6ZSe6ne0G9v
9h1xlsNQDhoiQ1ttNSZGTsRQeVpE/C7lmbNOy8l3sygVAFCwxJlC14WBeTyg
bJwmXIt3bp+wpgaW2p3gdE5pbjDwgQV9+sCP+MD0/0kvwbr/K70M93I+VapI
7BdDpyrIKBJEUkoiow2lbfds2f0vWODaLEkw5QZePNGZJgTnGB9uHGFFA4lO
SQCYCK+8X4lzI8TS9XyZJf9j2vwiWWa5y4/wCM8YUIahrc2jhMcqmFWkUydk
BHwel7RSoipeDv26Z9vn8BsuCYuHjSUR9llCdjTafKyB3LV7fuZgJHElMxGf
kXkGpV6O1MPiOYXLZV6UnOTCkTpv6TFBEmBiZaSjlZk8n1E2obR18zczPDBG
mFtSWu8iXHKNaSzLb4K4njYeEg33RMSQHbKWIgfdQQKPeEfRQG9hwywfM61D
lzm8O3rzLTf9JLLv5nqU0ddSg3NpBX6si5jl1WEbAlvUuiELDjbGzqVHYhhO
N+eao5hMPGSYRroMxUEoB7qB9+KafhdFxadL08zZiihpxUySRmTYtQiU0zjG
JFun4ML0NgiZhPUwriX5y5Qpy5wHktxPsiDX4fJGOKNwbydibJNkbp0CvSsu
4iLdxxp0oysMe6YiG2gh+U+0J/c6s7y5Bde5pdzgNvkCkl9tMWn1v5ZvI+s9
k+5GOAxKWa/reVDOe+JP35nF2a141UWe7fSx+xulbNaYQdiO+UUMMnjQ0wlL
Ktv1ob5VEeRUxtIdJowNzx3GNM2hUJvaDr4n93e0faS0RcDmz/r7CvrwB7k3
0j6ED5V8FES2RmxLOvNBWk4p1F+bfwa48OJB+PnXh5PDwQ+ky1MVMGAgNYCp
eq68EG7EXq1p0Rif1cfBuFjXXHMXeMl5ulR7mtTRwYG6/Mugg6vIwxg2B6cY
kVafMO5ycKQ+UXh+dHB0oA6Opwfvpm+O1fefbgdhzeGFkwweMUDbFAV4yNqM
+LftjGbary2uprSq1ulw8NRhzWdYSYs0rJjd3K4bRkpdZ/umXEltq5NK4XOQ
/e5hOKrJx1wYuHUA8Sr70gnjAmS3hLlblbj06Rnv6osbEvJ1Rk65p7v1uFu9
D1N70UAv4b5REyVEWbQBSicndHIi4/nJx1xNeOPc3VdMycXxS+eQXqTaUdbV
6D5X+vfW4vfTwzd/SIs5DP7daiwPbtVDguekqDDxj0f5+nWnquAW2M2Fp+rN
0duRo3Wn5iDGt2VD6KlHNfcKZi4wdKEGuupyhRzXZYvHy5wOL1+kTiDNlkTm
sdcoHPjGslvYz77k63Wd+apYdxCQC/wvTQP6MmuTN7m9xYlykFJQ4IwHOZPK
uMvT00GH9YpxubHkce/cckNfYAM+63k2cB3tzGk+PobTYU8Syfczot3INjsF
9utrbw216Hx0W2zuEs7V2cL+hqnL0ZZYHQ4hraFAlfjeFCC3qpy9ceIuOzqV
0Oem4MMju/Cqd0KgU/HzkZXOnm8U+2mGXzO+sDWkqJue2s5cAj/yoO3XBxS+
GrWgl9HQkLSdQC7mUXDMoySojvWRSR4tWnGR3V1zm39ju4NJTUSl9nwOdPrD
7Arh+/nV/Vt1TfEhpmzie/DaihPab3rJkr0g9N3qU3YNHtM3/dtaFTSgiDh+
8QpVDNHWVVJ4n9lO4716pa4A7FEPThVy4QkG0Tp2wIFpx570thU/8woEWma+
RqI9haRQFolyGDm0JRqtFjVGNqALHESjXQZNLGPlTJ+rMaWhhyX/l9wQO/ra
ajP09gxdPZDAz3FS152T2ApeUM5m5emWzHthD6CyTR2POjil1CkGLZarLQwL
arw9pDcY0rwKIqa+hSBMo+/YBhoerLSl6Kwi4HrbD35x4uEmkYhLXiPgkoVq
Ldg1LtBbA1iNukbunBiIadsRD34otu0nh+XuUJeGMN3acmBIdoDskJRqqJpX
btaJTY1udZPIDUYtDo9k1kJmLN4fvcWQvwzJhuMbC9W7DSen5ycXJ7vG0ylq
kfRxU2J9vCcHIoXmBJF+5WpYO25EdP+qLmlTPsOFpyepIDbrCaZyQce9X6U5
kyE5Nw/yVYp1ltJAIzzoccMcNH7iXbkZeh3S687KFGzPvgsh8hqBCekGYc9t
hCb46IXzIwfFGvKOY3DbYHBTz6v2UjfYvHYlOwwC0mVQNVUXr08oCnP1ut0r
Z1mUx+L4Q/lO1TMXGBRkJjHyc2sA7DbJ8V6uc7yd5jedxIP+9s7QXvh7F0My
OhPF3JjjKsruI12ZeFqsVwWn3W50bo2XKJamDZaa92Wa7K80+YJIvKrnKdp7
sV9STrO132AQvIfo4KfJGNsju6cCFeGE0tWXZaTbz834cqZDh+dnIF1B0Jf1
HR7j9ly8zFaBCAb9XamX63aQmae4txnKunHSvLcWui938Yo9m7y/h7dc/VS2
G9mqUB5j46xLLvl1VoCIZdbIfkPhgh/ndmgiAme21JDUVOF1qMsLaLirxXJJ
M/OXhVp5GVrNTq6uLq9v1fnZ7Xfqp+8Hg5kMykaS56V4qwzXnoOCbvXe2X4L
Ii3SaXvXRTliBRIqLndrniNsYApxKt08fGa/4cjFo1xugNBJ/kE3gkvFlt3V
1ydfpIEjE42pz4TbxKuhCZbcOD2OsdspG5TBzjAMjm7HxrvJ9jhS1N9+i1GA
mJJuOtN0IC/v+UOQekv1W/AS0SCtKq18Z6cO9qbKPcpGEk4sSPldTIUL7zFn
CkHNz91BD24V/YLBnsHglFMLxkSQeaLmZWIWLuPgn/GyYepKEQLsWl6UDLYZ
8dg9xWTSoXPmyxb5Oi/9Rbvyrj58LQ/jlmK0QMIOuDBBzWSmlHk78CMIE750
5ZtAjmiZf2fboNUvSA+R4C6ztib0VbX3PR8dE2Q6gYFo1v12iLBDuWr9T05w
uGneKzx6C65Doqf8kjSXac6+4G8O4Alo+uQr2p25O/OFE/KIpevRVoeDcn5e
l42ErQ5jnhqv6g4KgHeE6PWe4Injmg4bgzA8a952Vvy3NSDNIMrFkMzXCNVV
S8NKE1f1gEfdGqWBaNzcr4OKOmvf5ZO4y7VtEGCnupCKFp/fj/lMRELN7K4/
CxEzyMhsl6hc0FfARKT5nRp+HyCqU11ym9cET/NQVDgn4t+UAy8AnJ7dI76d
hJDXeD8aZx9gC4oec4Bd05qCr1okX2SGL7rL8gcCvKWo3OMrNB7v8CKhD6Bk
WHC78Yhc2FaYEmRt+4TptVM4NUw1gY30y5IIqtSMEieT8V8JQQtzGo63tgAF
/j175wfwMiqY+D3+9g2C2Zyzcul1JVlRE+z8DdUDh+U3RAAA

-->
</rfc>