[要約] RFC 8908は、キャプティブポータルAPIに関する文書であり、ネットワークに接続されたデバイスがキャプティブポータルの存在を検出し、ユーザーが認証や利用規約の同意などを行うためのインターフェースを提供することを目的としています。このAPIは、公共のWi-Fiアクセスポイントなどで一般的に見られるキャプティブポータルの利用体験を改善するために使用されます。関連するRFCにはRFC 7710（キャプティブポータルのためのDHCPおよびRAオプション）などがあります。
Internet Engineering Task Force (IETF) T. Pauly, Ed.
Request for Comments: 8908 Apple Inc.
Category: Standards Track D. Thakore, Ed.
ISSN: 2070-1721 CableLabs
September 2020
Captive Portal API
キャプティブポータルAPI
Abstract
概要
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.
このドキュメントでは、クライアントがキャプティブポータルシステムと対話できるようにするHTTP APIについて説明します。このAPIを使用すると、クライアントは自分のキャプティブポータルセッションについて獲得権と状態を取得する方法を発見することができます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはインターネット規格のトラック文書です。
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.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。インターネット規格に関する詳細情報は、RFC 7841のセクション2で利用できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8908.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc8908で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（C）2020 IETFの信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) 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.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Terminology
3. Workflow
4. API Connection Details
4.1. Server Authentication
5. API State Structure
6. Example Interaction
7. Security Considerations
7.1. Privacy Considerations
8. IANA Considerations
8.1. Captive Portal API JSON Media Type Registration
8.2. Captive Portal API Keys Registry
9. References
9.1. Normative References
9.2. Informative References
Acknowledgments
Authors' Addresses
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 [CAPPORT-ARCH]. Specifically, the API provides:
このドキュメントでは、クライアントがキャプティブポータルシステムと対話できるようにするハイパーテキスト転送プロトコル（HTTP）アプリケーションプログラミングインターフェイス（API）について説明します。この文書で定義されているAPIは、キャプティブポータルアーキテクチャ[Capport-Arch]の要件を満たすように設計されています。具体的には、APIは次のとおりです。
* The state of captivity (whether or not the client has access to the Internet).
* 捕獲率の状態（クライアントがインターネットにアクセスできるかどうか）。
* A URI of a user-facing web portal that can be used to get out of captivity.
* 捕われ志向から抜け出すために使用することができるユーザーが直面するWebポータルのURI。
* Authenticated and encrypted connections, using TLS for connections to both the API and user-facing web portal.
* APIとユーザー向けWebポータルの両方への接続のためのTLSを使用して、認証された接続と暗号化された接続。
This document leverages the terminology and components described in [CAPPORT-ARCH] and additionally defines the following terms:
このドキュメントは[Capport-Arch]に記載されている用語とコンポーネントを利用し、さらに次の用語を定義します。
Captive Portal Client 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.
キャプティブポータルクライアントキャプティブポータルAPIと対話するクライアントは、通常、キャプティブネットワークに接続されているユーザー機器で実行されているアプリケーションです。この文書の「クライアント」とも呼ばれます。
Captive Portal API Server The server exposing the APIs defined in this document to the client. This is also referred to as the "API server" in this document.
キャプティブポータルAPIサーバーこのドキュメントで定義されているAPIをクライアントに公開するサーバー。この文書の「APIサーバー」とも呼ばれます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
The Captive Portal Architecture defines several categories of interaction between clients and Captive Portal systems:
キャプティブポータルアーキテクチャは、クライアントとキャプティブポータルシステム間の相互作用のいくつかのカテゴリを定義します。
1. Provisioning, in which a client discovers that a network has a captive portal and learns the URI of the API server.
1. クライアントがネットワークにキャプティブポータルを持ち、APIサーバーのURIを学習したプロビジョニング。
2. API Server interaction, in which a client queries the state of captivity and retrieves the necessary information to get out of captivity
2. APIサーバーの対話、クライアントが登録さの状態を問い合わせ、必要な情報を取得するために必要な情報を取得する
3. Enforcement, in which the enforcement device in the network blocks disallowed traffic.
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 [RFC8910].
この文書は、2番目のカテゴリで使用されているメカニズムを定義します。Provisioningの一部として、Captive Portal APIサーバーの場所がクライアントによって検出されたと想定されています。APIサーバーエンドポイントを検出するためのメカニズムのセットは[RFC8910]で定義されています。
The API server endpoint MUST be accessed over HTTP using an https URI [RFC2818] and SHOULD 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".
APIサーバーエンドポイントは、HTTPS URI [RFC2818]を使用してHTTPを介してアクセスする必要があり、デフォルトのHTTPSポートを使用する必要があります。たとえば、Captive Portal APIサーバーが "example.org"でホストされている場合、APIのURIは "https://example.org/captive-portal/api"にすることができます。
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.
クライアントは、特定のネットワーク用のAPIサーバーのURIが同じままで、ネットワークに参加するたびに検出プロセスまたはプロビジョニングプロセスに依存することを想定してください。
As described in Section 3 of [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.
[capport-arch]のセクション3で説明されているように、クライアントの身元は、サーバーがクライアントのポータル状態と正しく返信するために、Captive Portal APIサーバーに表示される必要があります。キャプティブポータルシステムによって使用される識別子がクライアントのIPアドレスのセットである場合、システムは同じIPアドレスがAPIサーバーと執行デバイスの両方に表示されるようにする必要があります。
If the API server needs information about the client identity that is not otherwise visible to it, the URI provided to the client during provisioning SHOULD 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.
APIサーバーがそれに見えないクライアントIDに関する情報を必要とする場合、プロビジョニング中にクライアントに提供されたURIはクライアントごとに異なるはずです。したがって、キャプティブポータルシステムの設定方法によっては、URIは各クライアントホストに対して固有のものと同じクライアントホストのセッション間になります。
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.
たとえば、クライアントごとのセッションURIを使用するキャプティブポータルシステムは、API URIとして「https://example.org/captive-portal/aptive-portal/api/x54pd39jv」を使用できます。
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 [RFC8910], by validating that a DNS-ID [RFC6125] on the certificate is equal to the provisioned hostname.
HTTPS接続を介してキャプティブポータルAPIにアクセスする目的は2倍です。まず、暗号化された接続はローカルネットワーク上の他の関係者からのAPI交換の整合性と機密性を保護します。次に、APIのクライアントにAPIをホストしているサーバーを認証する機会を提供します。この認証により、クライアントは、証明書のDNS-ID [RFC6125]が等しいことを検証することによって、[RFC8910]で定義されたメカニズムを使用して、[RFC8910]で定義されているメカニズムを使用して、ネットワークによってプロビジョニングされたホスト名の有効な証明書があることをクライアントに保証できます。プロビジョニングされたホスト名に。
Clients performing revocation checking will need some means of accessing revocation information for certificates presented by the API server. Online Certificate Status Protocol [RFC6960] (OCSP) stapling, using the TLS Certificate Status Request extension [RFC6066], SHOULD be used. OCSP stapling allows a client to perform revocation checks without initiating new connections. To allow for other forms of revocation checking, especially for clients that do not support OCSP stapling, a captive network SHOULD permit connections to OCSP responders or Certificate Revocation Lists (CRLs) that are referenced by certificates provided by the API server. For more discussion on certificate revocation checks, see Section 6.5 of BCP 195 [RFC7525]. In addition to connections to OCSP responders and CRLs, a captive network SHOULD also permit connections to Network Time Protocol (NTP) [RFC5905] servers or other time-sync mechanisms to allow clients to accurately validate certificates.
失効確認を実行するクライアントは、APIサーバーによって提示された証明書の失効情報にアクセスする手段が必要です。オンライン証明書ステータスプロトコル[RFC6960]（OCSP）Stapling、TLS証明書のステータス要求を使用して[RFC6066]を使用する必要があります。OCSP Staplingを使用すると、クライアントが新しい接続を開始せずに失効チェックを実行できます。特にOCSPステープルをサポートしていないクライアントの他の形式の失効検査を可能にするために、CPISサーバーによって提供された証明書によって参照されるOCSPレスポンダまたは証明書失効リスト（CRL）への接続を許可する必要があります。証明書失効チェックに関する詳細については、BCP 195 [RFC7525]のセクション6.5を参照してください。OCSPレスポンダおよびCRLへの接続に加えて、キャプティブネットワークは、クライアントが証明書を正確に検証できるように、ネットワークタイムプロトコル（NTP）[RFC5905]サーバーまたは他のタイムシンクメカニズムへの接続を許可する必要があります。
Certificates with missing intermediate certificates that rely on clients validating the certificate chain using the URI specified in the Authority Information Access (AIA) extension [RFC5280] SHOULD NOT be used by the Captive Portal API server. If the certificates do require the use of AIA, the captive network MUST allow client access to the host specified in the URI.
権限情報アクセス（AIA）拡張機能[RFC5280]で指定されたクライアントに依存しているクライアントに依存しているクライアントに依存している証明書[RFC5280]は、キャプティブポータルAPIサーバーで使用しないでください。証明書がAIAの使用を必要とする場合、キャプティブネットワークはURIで指定されたホストへのクライアントアクセスを許可する必要があります。
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 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.
クライアントがAPIサーバーによって提示された証明書を検証できない場合は、このドキュメントで説明されているAPIインタラクションの動作のいずれかを続行してはいけません。クライアントは、API機能が存在しなかったかのように、キャプティブネットワークと対話します。ネットワークがClearText WebページをWebポータルにリダイレクトした場合、ユーザーがネットワークにアクセスすることも可能です。
The Captive Portal API data structures are specified in JavaScript Object Notation (JSON) [RFC8259]. Requests and responses for the Captive Portal API use the "application/captive+json" media type. Clients SHOULD include this media type as an Accept header in their GET requests, and servers MUST mark this media type as their Content-Type header in responses.
キャプティブポータルAPIデータ構造は、JavaScriptオブジェクト表記（JSON）[RFC8259]で指定されています。キャプティブポータルAPIの要求と応答「アプリケーション/キャプティブJSON」メディアタイプを使用します。クライアントには、このメディアタイプをその承認要求に承認ヘッダーとして含める必要があり、サーバーはこのメディアタイプを応答のコンテンツ型ヘッダーとしてマークする必要があります。
The following key MUST be included in the top level of the JSON structure returned by the API server:
次のキーは、API Serverによって返されたJSON構造の最上位レベルに含まれている必要があります。
+=========+=========+============================================+
| Key | Type | Description |
+=========+=========+============================================+
| captive | boolean | 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 (Section 4.1). |
+---------+---------+--------------------------------------------+
Table 1
表1
The following keys can be optionally included in the top level of the JSON structure returned by the API server:
次のキーは、APIサーバーによって返されるJSON構造の最上位レベルにオプションで含まれています。
+====================+=========+==================================+
| Key | Type | Description |
+====================+=========+==================================+
| user-portal-url | string | Provides the URL of a web portal |
| | | that MUST be accessed over TLS |
| | | with which a user can interact. |
+--------------------+---------+----------------------------------+
| venue-info-url | string | Provides the URL of a webpage or |
| | | site that SHOULD be accessed |
| | | over TLS on which the operator |
| | | of the network has information |
| | | that it wishes to share with the |
| | | user (e.g., store info, maps, |
| | | flight status, or |
| | | entertainment). |
+--------------------+---------+----------------------------------+
| can-extend-session | boolean | 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. |
+--------------------+---------+----------------------------------+
| seconds-remaining | number | An integer that indicates the |
| | | number of seconds remaining, |
| | | after which the client will be |
| | | placed into a captive state. |
| | | The API server SHOULD include |
| | | this value if the client is not |
| | | captive (i.e., captive=false) |
| | | and the client session is time- |
| | | limited and SHOULD omit this |
| | | value for captive clients (i.e., |
| | | captive=true) or when the |
| | | session is not time-limited. |
+--------------------+---------+----------------------------------+
| bytes-remaining | number | 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 SHOULD include this value |
| | | if the client is not captive |
| | | (i.e., captive=false) and the |
| | | client session is byte-limited |
| | | and SHOULD omit this value for |
| | | captive clients (i.e., |
| | | captive=true) or when the |
| | | session is not byte-limited. |
+--------------------+---------+----------------------------------+
Table 2
表2.
The valid JSON keys can be extended by adding entries to the Captive Portal API Keys Registry (Section 8.2). If a client receives a key 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 "required" will be considered optional.
有効なJSONキーは、キャプティブポータルAPIキーレジストリにエントリを追加することによって拡張できます（セクション8.2）。クライアントが認識されないキーを受信した場合は、キーと関連する値を無視する必要があります。この文書で定義されているもの以外のすべてのキーは、「必須」と見なされます。
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].
キャプティブポータルJSONコンテンツには、中間キャッシュに格納するのに適していないクライアントごとのデータを含めることができます。Captive Portal APIサーバーは、「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.
更新されたJSONコンテンツの要求を発行するためのクライアントの動作は実装固有であり、ユーザーの操作または特定のセッションで残っている秒とバイトの指示に基づいています。任意の時点で、クライアントがエラーが発生した場合、または応答がないために、APIサーバーから有効なJSONコンテンツが受信されない場合、クライアントは受信した最新の有効なコンテンツを引き続き適用し、コンテンツがない場合は以前に受信された場合は、API機能が存在しないかのように、キャプティブネットワークと対話します。
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 [RFC8910].
APIサーバーのURIを検出すると、キャプティブネットワークに接続されているクライアントがAPIサーバーに照会して、キャプティブの状態と条件に関する情報を取得してキャプティブを脱出します。この例では、クライアントは[RFC8910]で定義されているメカニズムの1つを使用して、クライアントがURI "https://example.org/captive-portal/api/x54pd39jv"を検出しました。
To request the Captive Portal JSON content, a client sends an HTTP GET request:
キャプティブポータルJSONコンテンツを要求するには、クライアントはHTTP GETリクエストを送信します。
GET /captive-portal/api/X54PD39JV HTTP/1.1
Host: example.org
Accept: application/captive+json
The server then responds with the JSON content for that client:
その後、サーバーはそのクライアントのJSONコンテンツで応答します。
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"
}
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 SHOULD query the API server again to verify that it is no longer captive.
この情報を受信すると、クライアントはそれを使用して、外部ネットワークへのアクセスを有効にするために（user-portal-URL値で指定されているように）ユーザをWebポータルに指示するように使用します。ユーザーが外部ネットワークアクセスの要件を満たすと、クライアントはもう一度APIサーバーに問い合わせる必要があります。
When the client requests the Captive Portal JSON content after gaining external network access, the server responds with updated JSON content:
外部ネットワークアクセスを取得した後にクライアントがキャプティブポータルJSONコンテンツを要求すると、サーバーは更新されたJSONコンテンツで応答します。
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
}
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 Section 4. All communication between the clients and the API server MUST be encrypted.
このプロトコルの目標の1つは、クライアントホストとキャプティブポータルシステム間の通信のセキュリティを向上させることです。クライアントトラフィックは、セクション4で説明されているように、クライアントとキャプティブポータルAPIサーバー間のTLS暗号化接続を要求することによって、ローカルネットワーク上のパッシブリスナーから保護されています。クライアントとAPIサーバー間のすべての通信を暗号化する必要があります。
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 Section 4.1. Specifically, the API server MUST 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 [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.
クライアントとキャプティブポータルシステム間の通信を暗号化することに加えて、このプロトコルでは、セクション4.1で説明されているように、APIサーバーからの基本的な認証レベルが必要です。具体的には、APIサーバーは、クライアントが失効チェックを実行できる有効な証明書を提示する必要があります。これにより、クライアントは[RFC8910]を使用してネットワークによってプロビジョニングされたホスト名の権限があることを確認できます。この検証は、APIサーバーが提供されているネットワークのプロビジョニングメカニズム（DHCPまたはIPv6ルータの広告など）に一致することを確認します。これらのプロビジョニングメカニズムのセキュリティまたはネットワークへのユーザーの信頼関係のセキュリティを検証していません。
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.
クライアントとユーザ向きのWebポータルとの間で渡される情報は、フルネームおよびクレジットカードの詳細などのユーザーの個人情報を含み得る。したがって、クライアントを指しているユーザーが直面するWeb PortalとWebポータルに指すAPIサーバーの両方が暗号化された接続に対してのみアクセスされることが重要です。
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 Section 12.5 of [RFC8264] for a discussion of confusable characters.
ユーザ向けWebポータルへの通信はTLSの使用を必要とするが、認証は、Web Portal ServerがAPIサーバによって提供されたURI内の名前と一致することを検証することだけを検証することに注意することが重要です。これはユーザーが型付けされた名前ではないので、ユーザーに提示されるウェブサイトのホスト名は、ユーザーを誤解させることができる「混乱可能な文字」を含み得る。混乱可能な文字について議論するために、[RFC8264]の12.5項を参照してください。
IANA has registered the "application/captive+json" media type (Section 8.1) and created a registry for fields in that format (Section 8.2).
IANAは、「アプリケーション/キャプティブJSON」メディアタイプ（セクション8.1）を登録し、そのフォーマットのフィールドのレジストリを作成しました（セクション8.2）。
This document registers the media type for Captive Portal API JSON text, "application/captive+json".
このドキュメントは、キャプティブポータルAPI JSONテキスト、「アプリケーション/キャプティブJSON」のメディアタイプを登録します。
Type name: application
タイプ名：アプリケーション
Subtype name: captive+json
サブタイプ名：キャプティブJSON.
Required parameters: N/A
必要なパラメータ：N / A.
Optional parameters: N/A
オプションのパラメータ：n / A.
Encoding considerations: Encoding considerations are identical to those specified for the "application/json" media type.
エンコードに関する考慮事項：エンコードに関する考慮事項は、「アプリケーション/ JSON」メディアタイプに指定されたものと同じです。
Security considerations: See Section 7
セキュリティ上の考慮事項：セクション7を参照してください
Interoperability considerations: This document specifies format of conforming messages and the interpretation thereof.
相互運用性の考慮事項：このドキュメントは、適合メッセージの形式とその解釈を指定します。
Published specification: RFC 8908
公開仕様：RFC 8908
Applications that use this media type: This media type is intended to be used by servers presenting the Captive Portal API, and clients connecting to such captive networks.
このメディアタイプを使用するアプリケーション：このメディアタイプは、キャプティブポータルAPIを提示するサーバー、およびそのような責任ネットワークに接続するクライアントが使用することを目的としています。
Fragment identifier considerations: N/A
フラグメント識別子の考慮事項：N / A.
Additional Information: N/A
追加情報：N / A.
Person and email address to contact for further information: See Authors' Addresses section
詳細については連絡先の人とEメールアドレス：作者の住所のセクションを参照
Intended usage: COMMON
意図された使用法：一般的な
Restrictions on usage: N/A
使用制限：N / A.
Author: CAPPORT IETF WG
著者：キャップポートIETF WG
Change controller: IETF
変更コントローラ：IETF.
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 Section 5.
IANAは、「キャプティブポータルAPIキー」という新しいレジストリを作成しており、これはキャプティブポータルAPIデータ構造で使用するためのJSONキーを予約しています。このレジストリの初期内容はセクション5で提供されています。
Each entry in the registry contains the following fields:
レジストリ内の各エントリには、次のフィールドが含まれています。
Key: The JSON key being registered in string format.
キー：文字列形式で登録されているJSONキー。
Type: The type of the JSON value to be stored, as one of the value types defined in [RFC8259].
型：[RFC8259]で定義されている値の種類の1つとして、保存するJSON値の型。
Description: A brief description explaining the meaning of the value, how it might be used, and/or how it should be interpreted by clients.
説明：値の意味、使用方法、および/またはクライアントによってどのように解釈されるべきかの意味を説明する簡単な説明。
Reference: A reference to a specification that defines the key and explains its usage.
参照：キーを定義し、その使用方法を説明する仕様への参照。
New assignments for the "Captive Portal API Keys" registry will be administered by IANA using the Specification Required policy [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.
「キャプティブポータルAPIキー」の新しい割り当ては、指定されたポリシー[RFC8126]を使用してIANAによって管理されます。指定されたエキスパートは、インターネットドラフトやRFCなどの恒久的で公的に利用可能な仕様で新しいキーを記述する文書の存在を検証することが期待されています。エキスパートは、新しいキーが明確な意味を持ち、不要な混乱を生み出したり、既存のキーと重複したりしないことを検証することが期待されています。Nongenerのユースケースに固有のキー、特にIETF文書の一部として指定されていないものは、ドメイン固有のプレフィックスを使用することをお勧めします。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <https://www.rfc-editor.org/info/rfc2818>.
[RFC2818] RESCORLA、E.、「HTTP over TLS」、RFC 2818、DOI 10.17487 / RFC2818、2000年5月、<https：//www.rfc-editor.org/info/rfc2818>。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW.Polk、 "Internet X.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル「、RFC 5280、DOI 10.17487 / RFC5280、2008年5月、<https://www.rfc-editor.org/info/rfc5280>。
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, <https://www.rfc-editor.org/info/rfc5905>.
[RFC5905]ミルズ、D.、Martin、J.、Ed。、Burbank、J.、およびW. Kasch、「ネットワークタイムプロトコルバージョン4：プロトコルおよびアルゴリズム仕様」、RFC 5905、DOI 10.17487 / RFC5905、2010年6月<https://www.rfc-editor.org/info/rfc5905>。
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, <https://www.rfc-editor.org/info/rfc6066>.
[RFC6066]イーストレイク3RD、D.、「トランスポート層セキュリティ（TLS）拡張：拡張定義」、RFC 6066、DOI 10.17487 / RFC6066、2011年1月、<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>.
[RFC6125] Transport Layer Security（TLS）のコンテキストでのX.509（PKIX）証明書を使用したInternet Publicキーインフラストラクチャ内のインターネット公開鍵インフラストラクチャ内のドメインベースのアプリケーションサービスIDの表現と検証の表現と検証RFC 6125、DOI 10.17487 / RFC6125、2011年3月、<https://www.rfc-editor.org/info/rfc6125>。
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, DOI 10.17487/RFC6960, June 2013, <https://www.rfc-editor.org/info/rfc6960>.
[RFC6960] Santesson、S、Myers、M.、Ankney、R.、Malpani、A.、Galparin、S、およびC. ADAMS、「X.509インターネット公開鍵インフラストラクチャオンライン証明書ステータスプロトコル - OCSP」、RFC6960、DOI 10.17487 / RFC6960、2013年6月、<https：//www.rfc-editor.org/info/rfc6960>。
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10.17487/RFC7234, June 2014, <https://www.rfc-editor.org/info/rfc7234>.
[RFC7234] Field、R.、Ed。、Nottingham、M.、Ed。、J.Reschke、Ed。、「ハイパーテキスト転送プロトコル（HTTP / 1.1）：キャッシング」、RFC 7234、DOI 10.17487 / RFC7234、2014年6月<https://www.rfc-editor.org/info/rfc7234>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]綿、M.、Leiba、B.およびT.Narten、「RFCSのIANAに関する考察のためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<HTTPS：// WWW.rfc-editor.org / info / rfc8126>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.
[RFC8259] Bray、T.、ED。、「JavaScriptオブジェクト表記（JSON）データ交換フォーマット」、STD 90、RFC 8259、DOI 10.17487 / RFC8259、2017年12月、<https：//www.rfc-editor.org/ info / rfc8259>。
[CAPPORT-ARCH] Larose, K., Dolson, D., and H. Liu, "CAPPORT Architecture", Work in Progress, Internet-Draft, draft-ietf-capport-architecture-08, 11 May 2020, <https://tools.ietf.org/html/draft-ietf-capport-architecture-08>.
[Capport-Arch] Larse、K.、Dolson、D.、およびH. Liu、 "Capport Architecture"、進行中の作業、インターネットドラフト、ドラフト-Appport-Architecture-08,11 5月11日、<https：//tools.ietf.org/html/draft-ietf-capport-chapport-08>。
[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>.
[RFC7525] Sheffer、Y、Holz、R.およびP.Saint-Andre、「トランスポート層セキュリティ（TLS）およびデータグラムトランスポート層セキュリティ（DTLS）」、BCP 195、RFC 7525、DOI 10.17487/ RFC7525、2015年5月、<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>.
[RFC8264] Saint-Andre、P.およびM.Blanchet、「Precisフレームワーク：アプリケーションプロトコルの準備、執行、および執行、および国際化された文字列の比較」、RFC 8264、DOI 10.17487 / RFC8264、2017年10月、<https：// www。rfc-editor.org/info/rfc8264>。
[RFC8910] Kumari, W. and E. Kline, "Captive-Portal Identification in DHCP and Router Advertisement (RA)", RFC 8910, DOI 10.17487/RFC8910, September 2020, <https://www.rfc-editor.org/info/rfc8910>.
[RFC8910] Kumari、W.およびE. Kline、「DHCPおよびルーター広告（RA）」、RFC 8910、DOI 10.17487 / RFC8910、9月2020年9月、<https://ww.rfc-editor.org/ info / rfc8910>。
Acknowledgments
謝辞
This work was started by Mark Donnelly and Margaret Cullen. Thanks to everyone in the CAPPORT Working Group who has given input.
この作品は、Mark DonnellyとMargaret Cullenによって開始されました。入力を受けたキャップポートワーキンググループのみんなのおかげで。
Authors' Addresses
著者の住所
Tommy Pauly (editor) Apple Inc. One Apple Park Way Cupertino, CA 95014 United States of America
Tommy Pouly（編集）Apple Inc. Apple Inc.アップルパークウェイCupertino、CA 95014アメリカ
Email: tpauly@apple.com
Darshak Thakore (editor) CableLabs 858 Coal Creek Circle Louisville, CO 80027 United States of America
Darshak Thakore（編集）CableLabs 858 Coal Creek Circle Louisville、CO 80027アメリカ
Email: d.thakore@cablelabs.com