draft-ietf-capport-api-07.txt   draft-ietf-capport-api-08.txt 
Captive Portal Interaction T. Pauly, Ed. Captive Portal Interaction T. Pauly, Ed.
Internet-Draft Apple Inc. Internet-Draft Apple Inc.
Intended status: Standards Track D. Thakore, Ed. Intended status: Standards Track D. Thakore, Ed.
Expires: 29 October 2020 CableLabs Expires: 20 December 2020 CableLabs
27 April 2020 18 June 2020
Captive Portal API Captive Portal API
draft-ietf-capport-api-07 draft-ietf-capport-api-08
Abstract Abstract
This document describes an HTTP API that allows clients to interact This document describes an HTTP API that allows clients to interact
with a Captive Portal system. With this API, clients can discover with a Captive Portal system. With this API, clients can discover
how to get out of captivity and fetch state about their Captive how to get out of captivity and fetch state about their Captive
Portal sessions. Portal sessions.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 29 October 2020. This Internet-Draft will expire on 20 December 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 14 skipping to change at page 2, line 14
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. API Connection Details . . . . . . . . . . . . . . . . . . . 3 4. API Connection Details . . . . . . . . . . . . . . . . . . . 3
4.1. Server Authentication . . . . . . . . . . . . . . . . . . 4 4.1. Server Authentication . . . . . . . . . . . . . . . . . . 4
5. API State Structure . . . . . . . . . . . . . . . . . . . . . 5 5. API State Structure . . . . . . . . . . . . . . . . . . . . . 5
6. Example Interaction . . . . . . . . . . . . . . . . . . . . . 6 6. Example Interaction . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7.1. Privacy Considerations . . . . . . . . . . . . . . . . . 8 7.1. Privacy Considerations . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8.1. Captive Portal API JSON Media Type Registration . . . . . 8 8.1. Captive Portal API JSON Media Type Registration . . . . . 9
8.2. Captive Portal API Keys Registry . . . . . . . . . . . . 9 8.2. Captive Portal API Keys Registry . . . . . . . . . . . . 9
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
This document describes a HyperText Transfer Protocol (HTTP) This document describes a HyperText Transfer Protocol (HTTP)
Application Program Interface (API) that allows clients to interact Application Program Interface (API) that allows clients to interact
with a Captive Portal system. The API defined in this document has with a Captive Portal system. The API defined in this document has
been designed to meet the requirements in the Captive Portal been designed to meet the requirements in the Captive Portal
Architecture [I-D.ietf-capport-architecture]. Specifically, the API Architecture [I-D.ietf-capport-architecture]. Specifically, the API
provides: provides:
* The state of captivity (whether or not the client has access to * The state of captivity (whether or not the client has access to
the Internet) the Internet)
* A URI that a client browser can present to a user to get out of * A URI of a user-facing web portal that can be used to get out of
captivity captivity
* An encrypted connection (using TLS for connections to both the API * Authenticated and encrypted connections, using TLS for connections
and user portal) to both the API and user-facing web portal
2. Terminology 2. Terminology
This document leverages the terminology and components described in This document leverages the terminology and components described in
[I-D.ietf-capport-architecture] and additionally defines the [I-D.ietf-capport-architecture] and additionally defines the
following terms: following terms:
* Captive Portal Client: The client that interacts with the Captive * Captive Portal Client: The client that interacts with the Captive
Portal API is typically some application running on the User Portal API is typically some application running on the User
Equipment that is connected to the Captive Network. This is also Equipment that is connected to the Captive Network. This is also
skipping to change at page 3, line 24 skipping to change at page 3, line 24
3. Workflow 3. Workflow
The Captive Portal Architecture defines several categories of The Captive Portal Architecture defines several categories of
interaction between clients and Captive Portal systems: interaction between clients and Captive Portal systems:
1. Provisioning, in which a client discovers that a network has a 1. Provisioning, in which a client discovers that a network has a
captive portal, and learns the URI of the API server. captive portal, and learns the URI of the API server.
2. API Server interaction, in which a client queries the state of 2. API Server interaction, in which a client queries the state of
the captive portal and retrieves the necessary information to get captivity and retrieves the necessary information to get out of
out of captivity. captivity.
3. Enforcement, in which the enforcement device in the network 3. Enforcement, in which the enforcement device in the network
blocks disallowed traffic. blocks disallowed traffic.
This document defines the mechanisms used in the second category. It This document defines the mechanisms used in the second category. It
is assumed that the location of the Captive Portal API server has is assumed that the location of the Captive Portal API server has
been discovered by the client as part of Provisioning. A set of been discovered by the client as part of Provisioning. A set of
mechanisms for discovering the API Server endpoint is defined in mechanisms for discovering the API Server endpoint is defined in
[I-D.ietf-capport-rfc7710bis]. [I-D.ietf-capport-rfc7710bis].
4. API Connection Details 4. API Connection Details
The API server endpoint MUST be accessed using HTTP over TLS (HTTPS) The API server endpoint MUST be accessed over HTTP using an https URI
and SHOULD be served on port 443 [RFC2818]. The client SHOULD NOT [RFC2818], and SHOULD use the default https port. For example, if
assume that the URI for a given network attachment will stay the the Captive Portal API server is hosted at "example.org", the URI of
same, and SHOULD rely on the discovery or provisioning process each the API could be "https://example.org/captive-portal/api"
time it joins the network.
The client SHOULD NOT assume that the URI of the API server for a
given network will stay the same, and SHOULD rely on the discovery or
provisioning process each time it joins the network.
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"
As described in Section 3 of [I-D.ietf-capport-architecture], the As described in Section 3 of [I-D.ietf-capport-architecture], the
identity of the client needs to be visible to the Captive Portal API 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 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 portal state. If the identifier used by the Captive Portal system is
the client's IP address, the system needs to ensure that the same IP the client's set of IP addresses, the system needs to ensure that the
address is visible to both the API server and the enforcement device. same IP addresses are visible to both the API server and the
enforcement device.
If the API server needs information about the client identity that is If the API server needs information about the client identity that is
not otherwise visible to it, the URI provided to the client during not otherwise visible to it, the URI provided to the client during
provisioning can be distinct per client. Thus, depending on how the provisioning SHOULD be distinct per client. Thus, depending on how
Captive Portal system is configured, the URI might be unique for each the Captive Portal system is configured, the URI will be unique for
client host and between sessions for the same client host. each client host and between sessions for the same client host.
For example, a Captive Portal system that uses per-client session For example, a Captive Portal system that uses per-client session
URIs could use "https://example.org/captive-portal/api/X54PD" as its URIs could use "https://example.org/captive-portal/api/X54PD39JV" as
API URI. its API URI.
4.1. Server Authentication 4.1. Server Authentication
The purpose of accessing the Captive Portal API over an HTTPS The purpose of accessing the Captive Portal API over an HTTPS
connection is twofold: first, the encrypted connection protects the connection is twofold: first, the encrypted connection protects the
integrity and confidentiality of the API exchange from other parties integrity and confidentiality of the API exchange from other parties
on the local network; and second, it provides the client of the API on the local network; and second, it provides the client of the API
an opportunity to authenticate the server that is hosting the API. an opportunity to authenticate the server that is hosting the API.
This authentication is aimed at allowing a user to be reasonably This authentication allows the client to ensure that the entity
confident that the entity providing the Captive Portal API has a providing the Captive Portal API has a valid certificate for the
valid certificate for the hostname in the URI ("example.org", in the hostname provisioned by the network using the mechanisms defined in
example above). The hostname of the API SHOULD be displayed to the [I-D.ietf-capport-rfc7710bis], by validating that a DNS-ID [RFC6125]
user in order to indicate the entity which is providing the API on the certificate is equal to the provisioned hostname.
service.
Clients performing revocation checking will need some means of Clients performing revocation checking will need some means of
accessing revocation information for certificates presented by the accessing revocation information for certificates presented by the
API server. Online Certificate Status Protocol [RFC6960] (OCSP) API server. Online Certificate Status Protocol [RFC6960] (OCSP)
stapling, using the TLS Certificate Status Request extension stapling, using the TLS Certificate Status Request extension
[RFC6066] SHOULD be used. OCSP stapling allows a client to perform [RFC6066] SHOULD be used. OCSP stapling allows a client to perform
revocation checks without initiating new connections. To allow for revocation checks without initiating new connections. To allow for
other forms of revocation checking, a captive network could permit other forms of revocation checking, especially for clients that do
not support OCSP stapling, a captive network SHOULD permit
connections to OCSP responders or Certificate Revocation Lists (CRLs) connections to OCSP responders or Certificate Revocation Lists (CRLs)
that are referenced by certificates provided by the API server. In that are referenced by certificates provided by the API server. For
addition to connections to OCSP responders and CRLs, a captive more discussion on certificate revocation checks, see Section 6.5 of
network SHOULD also permit connections to Network Time Protocol (NTP) BCP 195 [RFC7525]. In addition to connections to OCSP responders and
[RFC5905] servers or other time-sync mechnisms to allow clients to CRLs, a captive network SHOULD also permit connections to Network
accurately validate certificates. Time Protocol (NTP) [RFC5905] servers or other time-sync mechanisms
to allow clients to accurately validate certificates.
Certificates with missing intermediate certificates that rely on Certificates with missing intermediate certificates that rely on
clients validating the certificate chain using the URI specified in clients validating the certificate chain using the URI specified in
the Authority Information Access (AIA) extension [RFC5280] SHOULD NOT the Authority Information Access (AIA) extension [RFC5280] SHOULD NOT
be used by the Captive Portal API server. If the certificates do be used by the Captive Portal API server. If the certificates do
require the use of AIA, the captive network MUST allow client access require the use of AIA, the captive network MUST allow client access
to the host specified in the URI. to the host specified in the URI.
If the client is unable to validate the certificate presented by the If the client is unable to validate the certificate presented by the
API server, it MUST NOT proceed with any of the behavior for API API server, it MUST NOT proceed with any of the behavior for API
interaction described in this document. The client will proceed to interaction described in this document. The client will proceed to
interact with the captive network as if the API capabilities were not 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 present. It may still be possible for the user to access the network
by being redirected to a web portal. if the network redirects a cleartext webpage to a web portal.
5. API State Structure 5. API State Structure
The Captive Portal API data structures are specified in JavaScript The Captive Portal API data structures are specified in JavaScript
Object Notation (JSON) [RFC8259]. Requests and responses for the Object Notation (JSON) [RFC8259]. Requests and responses for the
Captive Portal API use the "application/captive+json" media type. Captive Portal API use the "application/captive+json" media type.
Clients SHOULD include this media type as an Accept header in their Clients SHOULD include this media type as an Accept header in their
GET requests, and servers MUST mark this media type as their Content- GET requests, and servers MUST mark this media type as their Content-
Type header in responses. Type header in responses.
The following key MUST be included in the top-level of the JSON The following key MUST be included in the top-level of the JSON
structure returned by the API server: structure returned by the API server:
* "captive" (boolean): indicates whether the client is in a state of * "captive" (boolean): indicates whether the client is in a state of
captivity, i.e it has not satisfied the conditions to access the captivity, i.e it has not satisfied the conditions to access the
external network. If the client is captive (i.e. captive=true), external network. If the client is captive (i.e. captive=true),
it can still be allowed enough access for it to perform server it will still be allowed enough access for it to perform server
authentication Section 4.1. authentication (Section 4.1).
The following keys can be optionally included in the top-level of the The following keys can be optionally included in the top-level of the
JSON structure returned by the API server: JSON structure returned by the API server:
* "user-portal-url" (string): provides the URL of a web portal with * "user-portal-url" (string): provides the URL of a web portal that
which a user can interact. MUST be accessed over TLS with which a user can interact.
* "venue-info-url" (string): provides the URL of a webpage or site * "venue-info-url" (string): provides the URL of a webpage or site
on which the operator of the network has information that it that SHOULD be accessed over TLS on which the operator of the
wishes to share with the user (e.g., store info, maps, flight network has information that it wishes to share with the user
status, or entertainment). (e.g., store info, maps, flight status, or entertainment).
* "can-extend-session" (boolean): indicates that the URL specified * "can-extend-session" (boolean): indicates that the URL specified
as "user-portal-url" allows the user to extend a session once the 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 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 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. user when the session is near its limit in terms of time or bytes.
* "seconds-remaining" (integer): indicates the number of seconds * "seconds-remaining" (number): an integer that indicates the number
remaining, after which the client will be placed into a captive of seconds remaining, after which the client will be placed into a
state. The API server SHOULD include this value if the client is captive state. The API server SHOULD include this value if the
not captive (i.e. captive=false) and the client session is time- client is not captive (i.e. captive=false) and the client session
limited, and SHOULD omit this value for captive clients (i.e. is time-limited, and SHOULD omit this value for captive clients
captive=true) or when the session is not time-limited. (i.e. captive=true) or when the session is not time-limited.
* "bytes-remaining" (integer): indicates the number of bytes * "bytes-remaining" (number): an integer that indicates the number
remaining, after which the client will be in placed into a captive of bytes remaining, after which the client will be in placed into
state. The byte count represents the sum of the total number of a captive state. The byte count represents the sum of the total
IP packet (layer 3) bytes sent and received by the client. number of IP packet (layer 3) bytes sent and received by the
Captive portal systems might not count traffic to whitelisted client, including IP headers. Captive portal systems might not
servers, such as the API server, but clients cannot rely on such count traffic to whitelisted servers, such as the API server, but
behavior. The API server SHOULD include this value if the client clients cannot rely on such behavior. The API server SHOULD
is not captive (i.e. captive=false) and the client session is include this value if the client is not captive (i.e.
byte-limited, and SHOULD omit this value for captive clients (i.e. captive=false) and the client session is byte-limited, and SHOULD
captive=true) or when the session is not byte-limited. omit this value for captive clients (i.e. captive=true) or when
the session is not byte-limited.
The valid JSON keys can be extended by adding entries to the Captive The valid JSON keys can be extended by adding entries to the Captive
Portal API Keys Registry Section 8. If a client receives a key that Portal API Keys Registry (Section 8). If a client receives a key
it does not recognize, it MUST ignore the key and any associated that it does not recognize, it MUST ignore the key and any associated
values. All keys other than the ones defined in this document as values. All keys other than the ones defined in this document as
"required" will be considered optional. "required" will be considered optional.
Captive Portal JSON content can contain per-client data that is not
appropriate to store in an intermediary cache. Captive Portal API
servers SHOULD set the Cache-Control header field in any responses to
"private", or a more restrictive value such as "no-store" [RFC7234].
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 SHOULD 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.
6. Example Interaction 6. Example Interaction
A client connected to a captive network upon discovering the URI of A client connected to a captive network upon discovering the URI of
the API server will query the API server to retrieve information the API server will query the API server to retrieve information
about its captive state and conditions to escape captivity. To about its captive state and conditions to escape captivity. In this
request the Captive Portal JSON content, a client sends an HTTP GET example, the client discovered the URI "https://example.org/captive-
request: portal/api/X54PD39JV" using one of the mechanisms defined in
[I-D.ietf-capport-rfc7710bis].
GET /captive-portal/api/X54PD To request the Captive Portal JSON content, a client sends an HTTP
GET request:
GET /captive-portal/api/X54PD39JV HTTP/1.1
Host: example.org Host: example.org
Accept: application/captive+json Accept: application/captive+json
The server then responds with the JSON content for that client: The server then responds with the JSON content for that client:
HTTP/1.1 200 OK HTTP/1.1 200 OK
Cache-Control: private Cache-Control: private
Date: Mon, 02 Mar 2020 05:07:35 GMT Date: Mon, 02 Mar 2020 05:07:35 GMT
Content-Type: application/captive+json Content-Type: application/captive+json
skipping to change at page 7, line 4 skipping to change at page 7, line 23
HTTP/1.1 200 OK HTTP/1.1 200 OK
Cache-Control: private Cache-Control: private
Date: Mon, 02 Mar 2020 05:07:35 GMT Date: Mon, 02 Mar 2020 05:07:35 GMT
Content-Type: application/captive+json Content-Type: application/captive+json
{ {
"captive": true, "captive": true,
"user-portal-url": "https://example.org/portal.html" "user-portal-url": "https://example.org/portal.html"
} }
Upon receiving this information the client will use this information Upon receiving this information the client will use this information
direct the user to the the web portal (as specified by the user- 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 portal-url value) to enable access to the external network. Once the
user satisfies the requirements for extenal network access, the user satisfies the requirements for external network access, the
client SHOULD query the API server again to verify that it is no client SHOULD query the API server again to verify that it is no
longer captive. longer captive.
When the client requests the Captive Portal JSON content after When the client requests the Captive Portal JSON content after
gaining external network access, the server responds with updated gaining external network access, the server responds with updated
JSON content: JSON content:
HTTP/1.1 200 OK HTTP/1.1 200 OK
Cache-Control: private Cache-Control: private
Date: Mon, 02 Mar 2020 05:08:13 GMT Date: Mon, 02 Mar 2020 05:08:13 GMT
Content-Type: application/captive+json Content-Type: application/captive+json
{ {
"captive": false, "captive": false,
"user-portal-url": "https://example.org/portal.html", "user-portal-url": "https://example.org/portal.html",
"venue-info-url": "https://flight.example.com/entertainment", "venue-info-url": "https://flight.example.com/entertainment",
"seconds-remaining": 326, "seconds-remaining": 326,
"can-extend-session": true "can-extend-session": true
} }
Captive Portal JSON content can contain per-client data that is not
appropriate to store in an intermediary cache. Captive Portal API
servers SHOULD set the Cache-Control header in any responses to
"private", or a more restrictive value [RFC7234].
7. Security Considerations 7. Security Considerations
One of the goals of this protocol is to improve the security of the One of the goals of this protocol is to improve the security of the
communication between client hosts and Captive Portal systems. communication between client hosts and Captive Portal systems.
Client traffic is protected from passive listeners on the local Client traffic is protected from passive listeners on the local
network by requiring TLS-encrypted connections between the client and network by requiring TLS-encrypted connections between the client and
the Captive Portal API server, as described in Section 4. All the Captive Portal API server, as described in Section 4. All
communication between the clients and the API server MUST be communication between the clients and the API server MUST be
encrypted. encrypted.
In addition to encrypting communications between clients and Captive In addition to encrypting communications between clients and Captive
Portal systems, this protocol requires a basic level of Portal systems, this protocol requires a basic level of
authentication from the API server, as described in Section 4.1. authentication from the API server, as described in Section 4.1.
Specifically, the API server MUST present a valid certificate on Specifically, the API server MUST present a valid certificate on
which the client can perform revocation checks. This allows the which the client can perform revocation checks. This allows the
client to ensure that the API server has authority for a hostname client to ensure that the API server has authority for the hostname
that can be presented to a user. that was provisioned by the network using
[I-D.ietf-capport-rfc7710bis]. Note that this validation only
It is important to note that while the server authentication checks confirms that the API server matches what the network's provisioning
can validate a specific hostname, it is certainly possible for the mechanism (such as DHCP or IPv6 Router Advertisements) provided, and
API server to present a valid certificate for a hostname that uses not validating the security of those provisioning mechanisms or the
non-standard characters or is otherwise designed to trick the user user's trust relationship to the network.
into believing that its hostname is some other, more trustworthy,
name. This is a danger of any scenario in which a hostname is not
typed in by a user.
7.1. Privacy Considerations 7.1. Privacy Considerations
Information passed between a client and a Captive Portal system may Information passed between a client and the user-facing web portal
include a user's personal information, such as a full name and credit may include a user's personal information, such as a full name and
card details. Therefore, it is important that Captive Portal API credit card details. Therefore, it is important that both the user-
Servers do not allow access to the Captive Portal API over facing web portal and the API server that points a client to the web
unencrypted sessions. portal are only accessed over encrypted connections.
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 [RFC8264] for a discussion of confusable
characters.
8. IANA Considerations 8. IANA Considerations
IANA is requested to create a registration for an "application/ IANA is requested to create a registration for an "application/
captive+json" media type (Section 8.1) and a registry for fields in captive+json" media type (Section 8.1) and a registry for fields in
that format (Section 8.2). that format (Section 8.2).
8.1. Captive Portal API JSON Media Type Registration 8.1. Captive Portal API JSON Media Type Registration
This document registers the media type for Captive Portal API JSON This document registers the media type for Captive Portal API JSON
skipping to change at page 9, line 38 skipping to change at page 10, line 16
Key: The JSON key being registered, in string format. Key: The JSON key being registered, in string format.
Type: The type of the JSON value to be stored, as one of the value Type: The type of the JSON value to be stored, as one of the value
types defined in [RFC8259]. types defined in [RFC8259].
Description: A brief description explaining the meaning of the Description: A brief description explaining the meaning of the
value, how it might be used, and/or how it should be interpreted value, how it might be used, and/or how it should be interpreted
by clients. by clients.
Specification: A reference to a specification that defines the key
and explains its usage.
New assignments for Captive Portal API Keys Registry will be New assignments for Captive Portal API Keys Registry will be
administered by IANA using the Specification Required policy administered by IANA using the Specification Required policy
[RFC8126]. The Designated Expert is expected to validate the [RFC8126]. The Designated Expert is expected to validate the
existence of documentation describing new keys in a permanent existence of documentation describing new keys in a permanent
publicly available specification. The expert is expected to validate publicly available specification, such as an Internet Draft or RFC.
that new keys have a clear meaning and do not create unnecessary The expert is expected to validate that new keys have a clear meaning
confusion or overlap with existing keys. Keys that are specific to and do not create unnecessary confusion or overlap with existing
non-generic use cases, particularly ones that are not specified as keys. Keys that are specific to non-generic use cases, particularly
part of an IETF document, are encouraged to use a domain-specific ones that are not specified as part of an IETF document, are
prefix. encouraged to use a domain-specific prefix.
9. Acknowledgments 9. Acknowledgments
This work in this document was started by Mark Donnelly and Margaret This work in this document was started by Mark Donnelly and Margaret
Cullen. Thanks to everyone in the CAPPORT Working Group who has Cullen. Thanks to everyone in the CAPPORT Working Group who has
given input. given input.
10. References 10. References
10.1. Normative References 10.1. Normative References
skipping to change at page 10, line 40 skipping to change at page 11, line 21
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>. <https://www.rfc-editor.org/info/rfc5905>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066, Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011, DOI 10.17487/RFC6066, January 2011,
<https://www.rfc-editor.org/info/rfc6066>. <https://www.rfc-editor.org/info/rfc6066>.
[RFC6125] Saint-Andre, P. and J. Hodges, "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)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
Galperin, S., and C. Adams, "X.509 Internet Public Key Galperin, S., and C. Adams, "X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol - OCSP", Infrastructure Online Certificate Status Protocol - OCSP",
RFC 6960, DOI 10.17487/RFC6960, June 2013, RFC 6960, DOI 10.17487/RFC6960, June 2013,
<https://www.rfc-editor.org/info/rfc6960>. <https://www.rfc-editor.org/info/rfc6960>.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
RFC 7234, DOI 10.17487/RFC7234, June 2014, RFC 7234, DOI 10.17487/RFC7234, June 2014,
<https://www.rfc-editor.org/info/rfc7234>. <https://www.rfc-editor.org/info/rfc7234>.
skipping to change at page 11, line 24 skipping to change at page 12, line 10
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259, Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017, DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>. <https://www.rfc-editor.org/info/rfc8259>.
10.2. Informative References 10.2. Informative References
[I-D.ietf-capport-architecture] [I-D.ietf-capport-architecture]
Larose, K., Dolson, D., and H. Liu, "CAPPORT Larose, K., Dolson, D., and H. Liu, "CAPPORT
Architecture", Work in Progress, Internet-Draft, draft- Architecture", Work in Progress, Internet-Draft, draft-
ietf-capport-architecture-07, 20 April 2020, ietf-capport-architecture-08, 11 May 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-capport- <http://www.ietf.org/internet-drafts/draft-ietf-capport-
architecture-07.txt>. architecture-08.txt>.
[I-D.ietf-capport-rfc7710bis] [I-D.ietf-capport-rfc7710bis]
Kumari, W. and E. Kline, "Captive-Portal Identification in Kumari, W. and E. Kline, "Captive-Portal Identification in
DHCP / RA", Work in Progress, Internet-Draft, draft-ietf- DHCP / RA", Work in Progress, Internet-Draft, draft-ietf-
capport-rfc7710bis-03, 30 March 2020, capport-rfc7710bis-07, 23 May 2020, <http://www.ietf.org/
<http://www.ietf.org/internet-drafts/draft-ietf-capport- internet-drafts/draft-ietf-capport-rfc7710bis-07.txt>.
rfc7710bis-03.txt>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC8264] Saint-Andre, P. and M. Blanchet, "PRECIS Framework:
Preparation, Enforcement, and Comparison of
Internationalized Strings in Application Protocols",
RFC 8264, DOI 10.17487/RFC8264, October 2017,
<https://www.rfc-editor.org/info/rfc8264>.
Authors' Addresses Authors' Addresses
Tommy Pauly (editor) Tommy Pauly (editor)
Apple Inc. Apple Inc.
One Apple Park Way One Apple Park Way
Cupertino, California 95014, Cupertino, California 95014,
United States of America United States of America
Email: tpauly@apple.com Email: tpauly@apple.com
 End of changes. 39 change blocks. 
103 lines changed or deleted 148 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/