<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.17 (Ruby 3.0.2) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-sawant-capport-api-state-enhancement-00" category="info" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.21.0 -->
  <front>
    <title abbrev="CAPPORT API State Enhancement">Captive Portal API State Structure Enhancement</title>
    <seriesInfo name="Internet-Draft" value="draft-sawant-capport-api-state-enhancement-00"/>
    <author fullname="Paresh Sawant">
      <organization>Apple Inc.</organization>
      <address>
        <email>paresh_sawant@apple.com</email>
      </address>
    </author>
    <date year="2024" month="June" day="26"/>
    <keyword>capport api state</keyword>
    <keyword>token</keyword>
    <keyword>internet access</keyword>
    <keyword>notification</keyword>
    <abstract>
      <?line 23?>

<t>This document specifies a new key in Captive Portal API State data
structure. The purpose of the new key is to allow clients to
perform the client authentication without user interaction.</t>
    </abstract>
  </front>
  <middle>
    <?line 29?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>As described in <xref target="RFC8908"/>, the Captive Portal API data structure is
specified in JavaScript Object Notation (JSON) <xref target="RFC8259"/>. Requests
and responses for the Captive Portal API use the
"application/captive+json" media type. The original specification
specifies key "user-portal-url" to convey the web portal URL to the
client. Although in most cases client devices are capable of
presenting the web portal to the user, there are types of devices
that are not built to support the user interaction with the web
portal. This document specifies a new key that allows client to
perform the authentication without user interaction.</t>
    </section>
    <section anchor="conventions-and-definitions">
      <name>Conventions and Definitions</name>
      <t>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"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
      <?line -18?>

</section>
    <section anchor="api-state-structure-enhancement">
      <name>API State Structure Enhancement</name>
      <t><xref target="new-key"/> shows the new key that can be optionally included in the
top-level of the JSON structure returned by the API server.</t>
      <table anchor="new-key">
        <name>Table 1</name>
        <thead>
          <tr>
            <th align="left">Key</th>
            <th align="left">Type</th>
            <th align="left">Description</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">authentication-server-url</td>
            <td align="left">string</td>
            <td align="left">It provides the URL of the Authentication Server that <bcp14>MUST</bcp14> be accessed over TLS. Authentication Server authenticates clients using the HTTP authentication framework specified in <xref target="RFC9110"/>. The server <bcp14>MUST NOT</bcp14> require user interaction on the client device. The client <bcp14>MUST</bcp14> have a credential to perform the authentication without user nteraction.</td>
          </tr>
        </tbody>
      </table>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>This document recommends security considerations specified in
<xref section="7" sectionFormat="of" target="RFC8908"/>.</t>
    </section>
    <section anchor="privacy-considerations">
      <name>Privacy Considerations</name>
      <t>This document recommends privacy consideration specified in
<xref section="7.1" sectionFormat="of" target="RFC8908"/>.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>IANA is requested to add the new key specified in <xref target="new-key"/>.</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-normative-references">
      <name>Normative References</name>
      <reference anchor="RFC8908" target="https://www.rfc-editor.org/info/rfc8908" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8908.xml">
        <front>
          <title>Captive Portal API</title>
          <author fullname="T. Pauly" initials="T." role="editor" surname="Pauly"/>
          <author fullname="D. Thakore" initials="D." role="editor" surname="Thakore"/>
          <date month="September" year="2020"/>
          <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>
        <seriesInfo name="RFC" value="8908"/>
        <seriesInfo name="DOI" value="10.17487/RFC8908"/>
      </reference>
      <reference anchor="RFC8259" target="https://www.rfc-editor.org/info/rfc8259" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8259.xml">
        <front>
          <title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
          <author fullname="T. Bray" initials="T." role="editor" surname="Bray"/>
          <date month="December" year="2017"/>
          <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>
        <seriesInfo name="STD" value="90"/>
        <seriesInfo name="RFC" value="8259"/>
        <seriesInfo name="DOI" value="10.17487/RFC8259"/>
      </reference>
      <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
        <front>
          <title>Key words for use in RFCs to Indicate Requirement Levels</title>
          <author fullname="S. Bradner" initials="S." surname="Bradner"/>
          <date month="March" year="1997"/>
          <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>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="2119"/>
        <seriesInfo name="DOI" value="10.17487/RFC2119"/>
      </reference>
      <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
        <front>
          <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
          <author fullname="B. Leiba" initials="B." surname="Leiba"/>
          <date month="May" year="2017"/>
          <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>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="8174"/>
        <seriesInfo name="DOI" value="10.17487/RFC8174"/>
      </reference>
      <reference anchor="RFC9110" target="https://www.rfc-editor.org/info/rfc9110" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml">
        <front>
          <title>HTTP Semantics</title>
          <author fullname="R. Fielding" initials="R." role="editor" surname="Fielding"/>
          <author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham"/>
          <author fullname="J. Reschke" initials="J." role="editor" surname="Reschke"/>
          <date month="June" year="2022"/>
          <abstract>
            <t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes.</t>
            <t>This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t>
          </abstract>
        </front>
        <seriesInfo name="STD" value="97"/>
        <seriesInfo name="RFC" value="9110"/>
        <seriesInfo name="DOI" value="10.17487/RFC9110"/>
      </reference>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA5VW23LbNhB9x1ds5ZdeTFXyuBNbkyZlbWes1LZUS37IZDId
EIQsxBTAAKA0qqx/6bf0y7oLULLoyyTlgwQsuLezZxdMkoR55QvZgxNeejWX
MDTW8wLSYR9GnnuJv7YSvrISzvSUayFnUnvGs8zKOaqlw+Hgerzz/u5bAgW3
xi57oPTEsNwIzWfoLLd84hPHF1z7RPCyRKcJL1XiyEQiH0wknQ5zVTZTzimj
/bJE7f7Z+B1jqrQ9wNicP+h0jjsH7E4uF8bmPQYJ1DYBbUKwSUJv7qSmhdJe
Wi3xWAjpHIm08WqiMF70wlipevDRG7EPDq1YOXG4Ws5o8YkxXvmpseSHAT6T
qihiWkNupZvCKOQVzoy95Vr9Hcz2IC3LQkJfi3Y4lDOuih6UQeuviMZvnN5p
CzNjLEkS4JnzlgvP2HiqHCCCFcECrpQCA5YOOGi5AEwe03q5ijn3nLlNKdsw
nkooK1saJ8FMwON2a8YhUsCLwixAFAq9kYCV0k6MnYVXoxgICPyvYYOFQlwq
D5WTNmKMgeNBO6YyU3leSMb2EAFvTV6FQ1jtqZ3tmrEU05ROWJXJnHJarb67
fndydNw5Wq/3g/tnsqT8YJsf5sA2CAUb7/mcj9Bk6WGQfZbCw5XxMerv348G
Vz9svBz8crxet+Fafqmk845xnQOWpzTaIdYIwEsBYNJ0xFpUwBqRn0V876fP
zugWzGSuOBCHI/7GqlulUb8OtWbfQ2mpGi1CMymDo6SyRYuKI4ye4xmFspAZ
xFO4ub6gQ4oiFqgNaUEluZ0SBjPjPDYG5VHXL5dzJYhCiBiGyrOCyMBKTJjK
qm8fe4jWQ4FDJVCPdCklRzSqDTI/5T6cYFtBVqnCk6qrYlNuTOxyJJBn445F
d4TS1zgfPRFXt1k94uq3k3QPTghXTVv0gZU/lROlVdhTA8rgkoaMg9blzWjc
2o//cDUI6+uzP2/612entB6dpxcX2wWr3xidD24uTh9WD5ong8vLs6vTqIxS
aIhY6zL9gCcUVWswHPcHV+lFi8rqGxiFchjIZMwNS+mxA7hjjZb6/WT47z/d
w5r0B90ukn7TAd1Xh7hZIGbRm9HFst4ikEuG/JacoCPYiTYKS4XzkTtwU7PQ
QLRANH/8SMh86sHrTJTdwze1gBJuCDeYNYQBs6eSJ8oRxGdEz7jZotmQP0K6
GW/6obHf4L4jfP22UFpC0j16+4YRhb52cbLVCrmbIJEQZQLMNYZv4LPgmipo
SmIeokyjXRRVHotH/e1NmRRyLovN8KYhtjP/sOwV3nA5ZHFKUFRI+Lm0WJl7
+AM97T73MMYWftidBrIE9/DkuWf3veTR05Q8PW++jBE0uzKJsdF8Q++YBs2e
e+h7KK2ZK+RuyIIGXJ1v2uzqUdCP6AWWIXzxckcMDB2NL0btF7R2YtnORocD
YjMAz8fj4eMxMrF44+MkuIPGPRN76Ljb7dAtQhMjZgYb6mNlvlTKPjMAjd69
WuMkjSZqUTAx5XjtcBBW5hRNnMnfOu52ph1WcdWDvZqKED4Cf22NwxXQba0Z
IJVHUlRW+SWNRYdFsHw7CXdHjpX4tYIrHIpuoyEaGg2MsAHQcAjuFVXz4XIP
I3ho1ZyL/+GzrBUaLl/02O4+47OfXqVPHAYh+rTxUwAt0VdRnjfa9VHxt51d
f/JkXNyx/wCiXbscZQsAAA==

-->

</rfc>
