<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" consensus="true" docName="draft-ietf-capport-api-08" indexInclude="true" ipr="trust200902" number="8908" prepTime="2020-09-21T20:35:31" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-capport-api-08" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc8908" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="Captive Portal API">Captive Portal API</title>
    <seriesInfo name="RFC" value="8908" stream="IETF"/>
    <author initials="T." surname="Pauly" fullname="Tommy Pauly" role="editor">
      <organization showOnFrontPage="true">Apple Inc.</organization>
      <address>
        <postal>
          <street>One Apple Park Way</street>
          <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 showOnFrontPage="true">CableLabs</organization>
      <address>
        <postal>
          <street>858 Coal Creek Circle</street>
          <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="09" year="2020"/>
    <workgroup>Captive Portal Interaction</workgroup>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">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>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc8908" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2020 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Simplified BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Simplified BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-workflow">Workflow</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-api-connection-details">API Connection Details</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-server-authentication">Server Authentication</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-api-state-structure">API State Structure</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-example-interaction">Example Interaction</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-privacy-considerations">Privacy Considerations</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2">
              <li pn="section-toc.1-1.8.2.1">
                <t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent="8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-captive-portal-api-json-med">Captive Portal API JSON Media Type Registration</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.2">
                <t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent="8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-captive-portal-api-keys-reg">Captive Portal API Keys Registry</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.9.2">
              <li pn="section-toc.1-1.9.2.1">
                <t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent="9.1" format="counter" sectionFormat="of" target="section-9.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.2">
                <t indent="0" pn="section-toc.1-1.9.2.2.1"><xref derivedContent="9.2" format="counter" sectionFormat="of" target="section-9.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">This document describes a HyperText Transfer Protocol (HTTP)
      Application 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" sectionFormat="of" derivedContent="CAPPORT-ARCH"/>. Specifically, the API provides:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1-2">
        <li pn="section-1-2.1">The state of captivity (whether or not the client has access to
	the Internet).</li>
        <li pn="section-1-2.2">A URI of a user-facing web portal that can be used to get out of
	captivity.</li>
        <li pn="section-1-2.3">Authenticated and encrypted connections, using TLS for connections
	to both the API and user-facing web portal.</li>
      </ul>
    </section>
    <section anchor="terms" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-terminology">Terminology</name>
      <t indent="0" pn="section-2-1">This document leverages the terminology and components described in
      <xref target="I-D.ietf-capport-architecture" format="default" sectionFormat="of" derivedContent="CAPPORT-ARCH"/> and
      additionally defines the following terms:</t>
      <dl newline="true" spacing="normal" indent="3" pn="section-2-2">
        <dt pn="section-2-2.1">Captive Portal Client</dt>
        <dd pn="section-2-2.2">The client that interacts with the Captive
	Portal API is typically some application running on the user equipment
	that is connected to the captive network. This is also referred to as
	the "client" in this document.</dd>
        <dt pn="section-2-2.3">Captive Portal API Server</dt>
        <dd pn="section-2-2.4">The server exposing the APIs defined in
	this document to the client. This is also referred to as the "API
	server" in this document.</dd>
      </dl>
      <t indent="0" pn="section-2-3">
    The key words "<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 "<bcp14>OPTIONAL</bcp14>" in this document are
    to be interpreted as 
    described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> 
    when, and only when, they appear in all capitals, as shown here.
      </t>
    </section>
    <section anchor="workflow" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-workflow">Workflow</name>
      <t indent="0" pn="section-3-1">The Captive Portal Architecture defines several categories of
      interaction between clients and Captive Portal systems:</t>
      <ol spacing="normal" indent="adaptive" start="1" type="1" pn="section-3-2">
        <li pn="section-3-2.1" derivedCounter="1.">Provisioning, in which a client discovers that a network has a
	captive portal and learns the URI of the API server.</li>
        <li pn="section-3-2.2" derivedCounter="2.">API Server interaction, in which a client queries the state of
	captivity and retrieves the necessary information to get out of
	captivity</li>
        <li pn="section-3-2.3" derivedCounter="3.">Enforcement, in which the enforcement device in the network blocks
	disallowed traffic.</li>
      </ol>
      <t indent="0" pn="section-3-3">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. A set of mechanisms
      for discovering the API server endpoint is defined in <xref target="RFC8910" format="default" sectionFormat="of" derivedContent="RFC8910"/>.</t>
    </section>
    <section anchor="api-details" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-api-connection-details">API Connection Details</name>
      <t indent="0" pn="section-4-1">The API server endpoint <bcp14>MUST</bcp14> be accessed over HTTP
      using an https URI <xref target="RFC2818" format="default" sectionFormat="of" derivedContent="RFC2818"/> and
      <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>
      <t indent="0" pn="section-4-2">The client <bcp14>SHOULD NOT</bcp14> assume that the URI of the API
      server for a given network will stay the same and <bcp14>SHOULD</bcp14>
      rely on the discovery or provisioning process each time it joins the
      network.</t>
      <t indent="0" pn="section-4-3">As described in <xref target="I-D.ietf-capport-architecture" sectionFormat="of" section="3" format="default" derivedLink="https://tools.ietf.org/html/draft-ietf-capport-architecture-08#section-3" derivedContent="CAPPORT-ARCH"/>, 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 indent="0" pn="section-4-4">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 <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 indent="0" pn="section-4-5">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="include" removeInRFC="false" pn="section-4.1">
        <name slugifiedName="name-server-authentication">Server Authentication</name>
        <t indent="0" pn="section-4.1-1">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; 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="RFC8910" format="default" sectionFormat="of" derivedContent="RFC8910"/>, by validating
	that a DNS-ID <xref target="RFC6125" format="default" sectionFormat="of" derivedContent="RFC6125"/> on the
	certificate is equal to the provisioned hostname.</t>
        <t indent="0" pn="section-4.1-2">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" sectionFormat="of" derivedContent="RFC6960"/> (OCSP) stapling, using the TLS Certificate Status
	Request extension <xref target="RFC6066" format="default" sectionFormat="of" derivedContent="RFC6066"/>,
	<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 <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
	<xref target="RFC7525" sectionFormat="of" section="6.5" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7525#section-6.5" derivedContent="RFC7525">BCP 195</xref>. In
	addition to connections to OCSP responders and CRLs, a captive network
	<bcp14>SHOULD</bcp14> also permit connections to Network Time Protocol
	(NTP) <xref target="RFC5905" format="default" sectionFormat="of" derivedContent="RFC5905"/> servers or other
	time-sync mechanisms to allow clients to accurately validate
	certificates.</t>
        <t indent="0" pn="section-4.1-3">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" sectionFormat="of" derivedContent="RFC5280"/> <bcp14>SHOULD NOT</bcp14> be used
	by the Captive Portal API server. If the certificates do require the
	use of AIA, the captive network <bcp14>MUST</bcp14> allow client
	access to the host specified in the URI.</t>
        <t indent="0" pn="section-4.1-4">If the client is unable to validate the certificate presented by
	the API server, it <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="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-api-state-structure">API State Structure</name>
      <t indent="0" pn="section-5-1">The Captive Portal API data structures are specified in JavaScript
      Object Notation (JSON) <xref target="RFC8259" format="default" sectionFormat="of" derivedContent="RFC8259"/>. Requests and responses for the Captive Portal API
      use the "application/captive+json" media type. Clients
      <bcp14>SHOULD</bcp14> include this media type as an Accept header in
      their GET requests, and servers <bcp14>MUST</bcp14> mark this media type
      as their Content-Type header in responses.</t>
      <t indent="0" pn="section-5-2">The following key <bcp14>MUST</bcp14> be included in the top level of
      the JSON structure returned by the API server:</t>
      <table anchor="tab1" align="center" pn="table-1">
        <thead>
          <tr>
            <th align="left" colspan="1" rowspan="1">Key</th>
            <th align="left" colspan="1" rowspan="1">Type</th>
            <th align="left" colspan="1" rowspan="1">Description</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">captive</td>
            <td align="left" colspan="1" rowspan="1">boolean</td>
            <td align="left" colspan="1" rowspan="1">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" sectionFormat="of" derivedContent="Section 4.1"/>).
      </td>
          </tr>
        </tbody>
      </table>
      <t indent="0" pn="section-5-4">The following keys can be optionally included in the top level of the
      JSON structure returned by the API server:</t>
      <table anchor="tab2" align="center" pn="table-2">
        <thead>
          <tr>
            <th align="left" colspan="1" rowspan="1">Key</th>
            <th align="left" colspan="1" rowspan="1">Type</th>
            <th align="left" colspan="1" rowspan="1">Description</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">user-portal-url</td>
            <td align="left" colspan="1" rowspan="1">string</td>
            <td align="left" colspan="1" rowspan="1">Provides the URL of a web portal that <bcp14>MUST</bcp14> be accessed over TLS with
      which a user can interact.</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">venue-info-url</td>
            <td align="left" colspan="1" rowspan="1">string</td>
            <td align="left" colspan="1" rowspan="1">Provides the URL of a webpage or site that <bcp14>SHOULD</bcp14> 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).</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">can-extend-session</td>
            <td align="left" colspan="1" rowspan="1">boolean</td>
            <td align="left" colspan="1" rowspan="1">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.
      </td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">seconds-remaining</td>
            <td align="left" colspan="1" rowspan="1">number</td>
            <td align="left" colspan="1" rowspan="1">An integer that indicates the number 
        of seconds remaining, after which the client will be placed into a 
        captive state. The API server <bcp14>SHOULD</bcp14> include this value
        if the client is not captive (i.e., captive=false) and the client
        session is time-limited and <bcp14>SHOULD</bcp14> omit this value for
        captive clients (i.e., captive=true) or when the session is not
        time-limited.
      </td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">bytes-remaining</td>
            <td align="left" colspan="1" rowspan="1">number</td>
            <td align="left" colspan="1" rowspan="1">An integer that indicates the number of bytes remaining, after
        which the client will be 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 systems might not count traffic to whitelisted servers, such as
        the API server, but clients cannot rely on such behavior. The API 
        server <bcp14>SHOULD</bcp14> include this value if the client is not
        captive (i.e., captive=false) and the 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.
      </td>
          </tr>
        </tbody>
      </table>
      <t indent="0" pn="section-5-6">The valid JSON keys can be extended by adding entries to the Captive
      Portal API Keys Registry (<xref target="iana-field-reg" format="default" sectionFormat="of" derivedContent="Section 8.2"/>). If a client 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 indent="0" pn="section-5-7">Captive Portal JSON content can contain per-client data that is not
      appropriate to store in an intermediary cache. Captive Portal API
      servers <bcp14>SHOULD</bcp14> set the Cache-Control header field in any
      responses to "private" or a more restrictive value, such as "no-store"
      <xref target="RFC7234" format="default" sectionFormat="of" derivedContent="RFC7234"/>.</t>
      <t indent="0" pn="section-5-8">Client behavior for issuing requests for updated JSON content is
      implementation specific and can be based on user interaction or the
      indications of seconds and bytes remaining in a given session. If at any
      point the client does not receive valid JSON content from the API
      server, either due to an error or due to receiving no 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="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-example-interaction">Example Interaction</name>
      <t indent="0" pn="section-6-1">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" sectionFormat="of" derivedContent="RFC8910"/>.</t>
      <t indent="0" pn="section-6-2">To request the Captive Portal JSON content, a client sends an HTTP
      GET request:</t>
      <sourcecode type="http-message" markers="false" pn="section-6-3">
GET /captive-portal/api/X54PD39JV HTTP/1.1
Host: example.org
Accept: application/captive+json
</sourcecode>
      <t indent="0" pn="section-6-4">The server then responds with the JSON content for that client:</t>
      <sourcecode type="http-message" markers="false" pn="section-6-5">
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 indent="0" pn="section-6-6">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 indent="0" pn="section-6-7">When the client requests the Captive Portal JSON content after
      gaining external network access, the server responds with updated JSON
      content:</t>
      <sourcecode type="http-message" markers="false" pn="section-6-8">
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
}
</sourcecode>
    </section>
    <section anchor="security" numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-7-1">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" sectionFormat="of" derivedContent="Section 4"/>. All communication between the clients and the API
      server <bcp14>MUST</bcp14> be encrypted.</t>
      <t indent="0" pn="section-7-2">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" sectionFormat="of" derivedContent="Section 4.1"/>. Specifically, the API server <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="RFC8910" format="default" sectionFormat="of" derivedContent="RFC8910"/>. 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; 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="include" removeInRFC="false" pn="section-7.1">
        <name slugifiedName="name-privacy-considerations">Privacy Considerations</name>
        <t indent="0" pn="section-7.1-1">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 indent="0" pn="section-7.1-2">It is important to note that although communication to the
	user-facing web portal requires use of 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 website that would be presented to the user
	may include "confusable characters", which can mislead the user. See
	<xref target="RFC8264" sectionFormat="of" section="12.5" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8264#section-12.5" derivedContent="RFC8264"/> for a
	discussion of confusable characters.</t>
      </section>
    </section>
    <section anchor="iana-section" numbered="true" toc="include" removeInRFC="false" pn="section-8">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-8-1">IANA has registered the
      "application/captive+json" media type (<xref target="iana-json" format="default" sectionFormat="of" derivedContent="Section 8.1"/>) and created a registry for fields in that format (<xref target="iana-field-reg" format="default" sectionFormat="of" derivedContent="Section 8.2"/>).</t>
      <section anchor="iana-json" numbered="true" toc="include" removeInRFC="false" pn="section-8.1">
        <name slugifiedName="name-captive-portal-api-json-med">Captive Portal API JSON Media Type Registration</name>
        <t indent="0" pn="section-8.1-1">This document registers the media type for Captive Portal API JSON
	text, "application/captive+json".</t>
        <dl newline="false" spacing="normal" indent="3" pn="section-8.1-2">
          <dt pn="section-8.1-2.1">Type name:</dt>
          <dd pn="section-8.1-2.2">application</dd>
          <dt pn="section-8.1-2.3">Subtype name:</dt>
          <dd pn="section-8.1-2.4">captive+json</dd>
          <dt pn="section-8.1-2.5">Required parameters:</dt>
          <dd pn="section-8.1-2.6">N/A</dd>
          <dt pn="section-8.1-2.7">Optional parameters:</dt>
          <dd pn="section-8.1-2.8">N/A</dd>
          <dt pn="section-8.1-2.9">Encoding considerations:</dt>
          <dd pn="section-8.1-2.10">Encoding considerations are identical to those specified for the
	"application/json" media type.</dd>
          <dt pn="section-8.1-2.11">Security considerations:</dt>
          <dd pn="section-8.1-2.12">See <xref target="security" format="default" sectionFormat="of" derivedContent="Section 7"/></dd>
          <dt pn="section-8.1-2.13">Interoperability considerations:</dt>
          <dd pn="section-8.1-2.14">This document specifies format of conforming messages and the
	interpretation thereof.</dd>
          <dt pn="section-8.1-2.15">Published specification:</dt>
          <dd pn="section-8.1-2.16">RFC 8908</dd>
          <dt pn="section-8.1-2.17">Applications that use this media type:</dt>
          <dd pn="section-8.1-2.18">This media type is intended to be used by servers presenting the
	Captive Portal API, and clients connecting to such captive
	networks.</dd>
          <dt pn="section-8.1-2.19">Fragment identifier considerations:</dt>
          <dd pn="section-8.1-2.20">N/A</dd>
          <dt pn="section-8.1-2.21">Additional Information:</dt>
          <dd pn="section-8.1-2.22">N/A</dd>
          <dt pn="section-8.1-2.23">Person and email address to contact for further information:</dt>
          <dd pn="section-8.1-2.24">
            <br/>See Authors' Addresses section</dd>
          <dt pn="section-8.1-2.25">Intended usage:</dt>
          <dd pn="section-8.1-2.26">COMMON</dd>
          <dt pn="section-8.1-2.27">Restrictions on usage:</dt>
          <dd pn="section-8.1-2.28">N/A</dd>
          <dt pn="section-8.1-2.29">Author:</dt>
          <dd pn="section-8.1-2.30">CAPPORT IETF WG</dd>
          <dt pn="section-8.1-2.31">Change controller:</dt>
          <dd pn="section-8.1-2.32">IETF</dd>
        </dl>
      </section>
      <section anchor="iana-field-reg" numbered="true" toc="include" removeInRFC="false" pn="section-8.2">
        <name slugifiedName="name-captive-portal-api-keys-reg">Captive Portal API Keys Registry</name>
        <t indent="0" pn="section-8.2-1">IANA has created a new registry called "Captive
	Portal API Keys", which reserves 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" sectionFormat="of" derivedContent="Section 5"/>.</t>
        <t indent="0" pn="section-8.2-2">Each entry in the registry contains the following fields:</t>
        <dl newline="false" spacing="normal" indent="3" pn="section-8.2-3">
          <dt pn="section-8.2-3.1">Key:</dt>
          <dd pn="section-8.2-3.2">The JSON key being registered in string format.</dd>
          <dt pn="section-8.2-3.3">Type:</dt>
          <dd pn="section-8.2-3.4">The type of the JSON value to be stored, as one of the value
	  types defined in <xref target="RFC8259" format="default" sectionFormat="of" derivedContent="RFC8259"/>.</dd>
          <dt pn="section-8.2-3.5">Description:</dt>
          <dd pn="section-8.2-3.6">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 pn="section-8.2-3.7">Reference:</dt>
          <dd pn="section-8.2-3.8">A reference to a specification that defines the key and explains
	  its usage.</dd>
        </dl>
        <t indent="0" pn="section-8.2-4">New assignments for the "Captive Portal API Keys" registry will be
	administered by IANA using the Specification Required policy <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>. 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 nongeneric 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>
  </middle>
  <back>
    <displayreference target="I-D.ietf-capport-architecture" to="CAPPORT-ARCH"/>
    <references pn="section-9">
      <name slugifiedName="name-references">References</name>
      <references pn="section-9.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author initials="S." surname="Bradner" fullname="S. Bradner">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1997" month="March"/>
            <abstract>
              <t indent="0">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>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC2818" target="https://www.rfc-editor.org/info/rfc2818" quoteTitle="true" derivedAnchor="RFC2818">
          <front>
            <title>HTTP Over TLS</title>
            <author initials="E." surname="Rescorla" fullname="E. Rescorla">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2000" month="May"/>
            <abstract>
              <t indent="0">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>
          <seriesInfo name="RFC" value="2818"/>
          <seriesInfo name="DOI" value="10.17487/RFC2818"/>
        </reference>
        <reference anchor="RFC5280" target="https://www.rfc-editor.org/info/rfc5280" quoteTitle="true" derivedAnchor="RFC5280">
          <front>
            <title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
            <author initials="D." surname="Cooper" fullname="D. Cooper">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Santesson" fullname="S. Santesson">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Farrell" fullname="S. Farrell">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Boeyen" fullname="S. Boeyen">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Housley" fullname="R. Housley">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="W." surname="Polk" fullname="W. Polk">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2008" month="May"/>
            <abstract>
              <t indent="0">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>
          <seriesInfo name="RFC" value="5280"/>
          <seriesInfo name="DOI" value="10.17487/RFC5280"/>
        </reference>
        <reference anchor="RFC5905" target="https://www.rfc-editor.org/info/rfc5905" quoteTitle="true" derivedAnchor="RFC5905">
          <front>
            <title>Network Time Protocol Version 4: Protocol and Algorithms Specification</title>
            <author initials="D." surname="Mills" fullname="D. Mills">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Martin" fullname="J. Martin" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Burbank" fullname="J. Burbank">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="W." surname="Kasch" fullname="W. Kasch">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2010" month="June"/>
            <abstract>
              <t indent="0">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>
          <seriesInfo name="RFC" value="5905"/>
          <seriesInfo name="DOI" value="10.17487/RFC5905"/>
        </reference>
        <reference anchor="RFC6066" target="https://www.rfc-editor.org/info/rfc6066" quoteTitle="true" derivedAnchor="RFC6066">
          <front>
            <title>Transport Layer Security (TLS) Extensions: Extension Definitions</title>
            <author initials="D." surname="Eastlake 3rd" fullname="D. Eastlake 3rd">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2011" month="January"/>
            <abstract>
              <t indent="0">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>
          <seriesInfo name="RFC" value="6066"/>
          <seriesInfo name="DOI" value="10.17487/RFC6066"/>
        </reference>
        <reference anchor="RFC6125" target="https://www.rfc-editor.org/info/rfc6125" quoteTitle="true" derivedAnchor="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>
            <author initials="P." surname="Saint-Andre" fullname="P. Saint-Andre">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Hodges" fullname="J. Hodges">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2011" month="March"/>
            <abstract>
              <t indent="0">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>
          <seriesInfo name="RFC" value="6125"/>
          <seriesInfo name="DOI" value="10.17487/RFC6125"/>
        </reference>
        <reference anchor="RFC6960" target="https://www.rfc-editor.org/info/rfc6960" quoteTitle="true" derivedAnchor="RFC6960">
          <front>
            <title>X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP</title>
            <author initials="S." surname="Santesson" fullname="S. Santesson">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Myers" fullname="M. Myers">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Ankney" fullname="R. Ankney">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Malpani" fullname="A. Malpani">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Galperin" fullname="S. Galperin">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Adams" fullname="C. Adams">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2013" month="June"/>
            <abstract>
              <t indent="0">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>
          <seriesInfo name="RFC" value="6960"/>
          <seriesInfo name="DOI" value="10.17487/RFC6960"/>
        </reference>
        <reference anchor="RFC7234" target="https://www.rfc-editor.org/info/rfc7234" quoteTitle="true" derivedAnchor="RFC7234">
          <front>
            <title>Hypertext Transfer Protocol (HTTP/1.1): Caching</title>
            <author initials="R." surname="Fielding" fullname="R. Fielding" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Nottingham" fullname="M. Nottingham" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Reschke" fullname="J. Reschke" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2014" month="June"/>
            <abstract>
              <t indent="0">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>
          <seriesInfo name="RFC" value="7234"/>
          <seriesInfo name="DOI" value="10.17487/RFC7234"/>
        </reference>
        <reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8126" quoteTitle="true" derivedAnchor="RFC8126">
          <front>
            <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
            <author initials="M." surname="Cotton" fullname="M. Cotton">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B." surname="Leiba" fullname="B. Leiba">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Narten" fullname="T. Narten">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="June"/>
            <abstract>
              <t indent="0">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 indent="0">To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed.  This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t>
              <t indent="0">This is the third edition of this document; it obsoletes RFC 5226.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="26"/>
          <seriesInfo name="RFC" value="8126"/>
          <seriesInfo name="DOI" value="10.17487/RFC8126"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author initials="B." surname="Leiba" fullname="B. Leiba">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="May"/>
            <abstract>
              <t indent="0">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>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8259" target="https://www.rfc-editor.org/info/rfc8259" quoteTitle="true" derivedAnchor="RFC8259">
          <front>
            <title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
            <author initials="T." surname="Bray" fullname="T. Bray" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="December"/>
            <abstract>
              <t indent="0">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 indent="0">This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="90"/>
          <seriesInfo name="RFC" value="8259"/>
          <seriesInfo name="DOI" value="10.17487/RFC8259"/>
        </reference>
      </references>
      <references pn="section-9.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="I-D.ietf-capport-architecture" quoteTitle="true" target="https://tools.ietf.org/html/draft-ietf-capport-architecture-08" derivedAnchor="CAPPORT-ARCH">
          <front>
            <title>CAPPORT Architecture</title>
            <author initials="K" surname="Larose" fullname="Kyle Larose">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D" surname="Dolson" fullname="David Dolson">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="H" surname="Liu" fullname="Heng Liu">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="May" day="11" year="2020"/>
            <abstract>
              <t indent="0">This document describes a CAPPORT architecture.  DHCP or Router Advertisements, an optional signaling protocol, and an HTTP API are used to provide the solution.  The role of Provisioning Domains (PvDs) is described.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-capport-architecture-08"/>
          <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-capport-architecture-08.txt"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="RFC7525" target="https://www.rfc-editor.org/info/rfc7525" quoteTitle="true" derivedAnchor="RFC7525">
          <front>
            <title>Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)</title>
            <author initials="Y." surname="Sheffer" fullname="Y. Sheffer">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Holz" fullname="R. Holz">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="P." surname="Saint-Andre" fullname="P. Saint-Andre">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2015" month="May"/>
            <abstract>
              <t indent="0">Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are widely used to protect data exchanged over application protocols such 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 of operation.  This document provides recommendations for improving the security of deployed services that use TLS and DTLS. The recommendations are applicable to the majority of use cases.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="195"/>
          <seriesInfo name="RFC" value="7525"/>
          <seriesInfo name="DOI" value="10.17487/RFC7525"/>
        </reference>
        <reference anchor="RFC8264" target="https://www.rfc-editor.org/info/rfc8264" quoteTitle="true" derivedAnchor="RFC8264">
          <front>
            <title>PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols</title>
            <author initials="P." surname="Saint-Andre" fullname="P. Saint-Andre">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Blanchet" fullname="M. Blanchet">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="October"/>
            <abstract>
              <t indent="0">Application protocols using Unicode code points in protocol strings need to properly handle 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 or authorization).  This document defines a framework enabling application protocols to perform the preparation, enforcement, and comparison of internationalized strings ("PRECIS") in a way that depends on the properties of Unicode code points and thus is more agile with respect to versions of Unicode.  As a result, this framework provides a more sustainable approach to the handling of internationalized strings than the previous framework, known as Stringprep (RFC 3454).  This document obsoletes RFC 7564.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8264"/>
          <seriesInfo name="DOI" value="10.17487/RFC8264"/>
        </reference>
        <reference anchor="RFC8910" target="https://www.rfc-editor.org/info/rfc8910" quoteTitle="true" derivedAnchor="RFC8910">
          <front>
            <title>Captive-Portal Identification in DHCP and Router Advertisement (RA)</title>
            <author initials="W" surname="Kumari" fullname="Warren Kumari">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E" surname="Kline" fullname="Erik Kline">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="September" year="2020"/>
          </front>
          <seriesInfo name="RFC" value="8910"/>
          <seriesInfo name="DOI" value="10.17487/RFC8910"/>
        </reference>
      </references>
    </references>
    <section anchor="thanksall" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgments">Acknowledgments</name>
      <t indent="0" pn="section-appendix.a-1">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>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="T." surname="Pauly" fullname="Tommy Pauly" role="editor">
        <organization showOnFrontPage="true">Apple Inc.</organization>
        <address>
          <postal>
            <street>One Apple Park Way</street>
            <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 showOnFrontPage="true">CableLabs</organization>
        <address>
          <postal>
            <street>858 Coal Creek Circle</street>
            <city>Louisville</city>
            <region>CO</region>
            <code>80027</code>
            <country>United States of America</country>
          </postal>
          <email>d.thakore@cablelabs.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>