[要約] RFC 7800は、JSON Web Tokens（JWTs）のための所有証明キーセマンティクスに関する仕様であり、JWTのセキュリティを向上させることを目的としています。
Internet Engineering Task Force (IETF) M. Jones
Request for Comments: 7800 Microsoft
Category: Standards Track J. Bradley
ISSN: 2070-1721 Ping Identity
H. Tschofenig
ARM Limited
April 2016
Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)
JSON Web Token（JWT）の所有証明キーの意味論
Abstract
概要
This specification describes how to declare in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular proof-of-possession key and how the recipient can cryptographically confirm proof of possession of the key by the presenter. Being able to prove possession of a key is also sometimes described as the presenter being a holder-of-key.
この仕様では、JWTのプレゼンターが特定の所有証明キーを所有していることをJSON Web Token（JWT）で宣言する方法と、受信者がプレゼンターによるキーの所有証明を暗号で確認する方法について説明します。キーの所持を証明できることは、プレゼンターがキーの所有者であると説明されることもあります。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7800.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7800で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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トラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Representations for Proof-of-Possession Keys . . . . . . . . 5
3.1. Confirmation Claim . . . . . . . . . . . . . . . . . . . 6
3.2. Representation of an Asymmetric Proof-of-Possession Key . 7
3.3. Representation of an Encrypted Symmetric Proof-of-
Possession Key . . . . . . . . . . . . . . . . . . . . . 7
3.4. Representation of a Key ID for a Proof-of-Possession Key 8
3.5. Representation of a URL for a Proof-of-Possession Key . . 9
3.6. Specifics Intentionally Not Specified . . . . . . . . . . 10
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6.1. JSON Web Token Claims Registration . . . . . . . . . . . 12
6.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 12
6.2. JWT Confirmation Methods Registry . . . . . . . . . . . . 12
6.2.1. Registration Template . . . . . . . . . . . . . . . . 12
6.2.2. Initial Registry Contents . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . 14
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
This specification describes how a JSON Web Token [JWT] can declare that the presenter of the JWT possesses a particular proof-of-possession (PoP) key and how the recipient can cryptographically confirm proof of possession of the key by the presenter. Proof of possession of a key is also sometimes described as the presenter being a holder-of-key. The [OAUTH-POP-ARCH] specification describes key confirmation, among other confirmation mechanisms. This specification defines how to communicate confirmation key information in JWTs.
この仕様は、JSON Webトークン[JWT]がJWTのプレゼンターが特定の所有証明（PoP）キーを所有していることを宣言する方法と、受信者がプレゼンターによるキーの所有証明を暗号で確認する方法について説明しています。キーの所持証明は、プレゼンターがキーの所有者であると説明されることもあります。 [OAUTH-POP-ARCH]仕様では、他の確認メカニズムの中でも特に、キー確認について説明しています。この仕様は、JWTで確認キー情報を通信する方法を定義します。
Envision the following two use cases. The first use case employs a symmetric proof-of-possession key and the second use case employs an asymmetric proof-of-possession key.
次の2つの使用例を想定してください。最初のユースケースは対称的な所有証明キーを使用し、2番目のユースケースは非対称的な所有証明キーを使用します。
+--------------+
| | +--------------+
| |--(3) Presentation of -->| |
| | JWT w/ Encrypted | |
| Presenter | PoP Key | |
| | | |
| |<-(4) Communication ---->| |
| | Authenticated by | |
+--------------+ PoP Key | |
^ ^ | |
| | | |
(1) Sym. (2) JWT w/ | Recipient |
| PoP | Encrypted | |
| Key | PoP Key | |
v | | |
+--------------+ | |
| | | |
| | | |
| |<-(0) Key Exchange for ->| |
| Issuer | Key Encryption Key | |
| | | |
| | | |
| | +--------------+
+--------------+
Figure 1: Proof of Possession with a Symmetric Key
図1：対称鍵を持つ所有の証明
In the case illustrated in Figure 1, (1) either the presenter generates a symmetric key and privately sends it to the issuer or the issuer generates a symmetric key and privately sends it to the presenter. The issuer generates a JWT with an encrypted copy of this symmetric key in the confirmation claim. This symmetric key is encrypted with a key known only to the issuer and the recipient, which was previously established in step (0). The entire JWT is integrity protected by the issuer. The JWT is then (2) sent to the presenter. Now, the presenter is in possession of the symmetric key as well as the JWT (which includes the confirmation claim). When the presenter (3) presents the JWT to the recipient, it also needs to demonstrate possession of the symmetric key; the presenter, for example, (4) uses the symmetric key in a challenge/response protocol with the recipient. The recipient is then able to verify that it is interacting with the genuine presenter by decrypting the key in the confirmation claim of the JWT. By doing this, the recipient obtains the symmetric key, which it then uses to verify cryptographically protected messages exchanged with the presenter (4). This symmetric key mechanism described above is conceptually similar to the use of Kerberos tickets.
図1に示すケースでは、（1）プレゼンターが対称キーを生成して非公開で発行者に送信するか、発行者が対称キーを生成して非公開でプレゼンターに送信します。発行者は、確認クレームにこの対称鍵の暗号化されたコピーを含むJWTを生成します。この対称鍵は、以前にステップ（0）で確立された、発行者と受信者だけが知っている鍵で暗号化されます。 JWT全体は、発行者によって完全性が保護されています。次に、JWTが（2）プレゼンターに送信されます。現在、プレゼンターは対称鍵とJWT（確認要求を含む）を所有しています。プレゼンター（3）がJWTを受信者に提示するとき、対称鍵の所有を示す必要もあります。たとえば、プレゼンターは、（4）受信者とのチャレンジ/レスポンスプロトコルで対称キーを使用します。受信者は、JWTの確認要求でキーを復号化することにより、本物のプレゼンターと対話していることを確認できます。これを行うことにより、受信者は対称鍵を取得し、それを使用して、プレゼンターと交換される暗号で保護されたメッセージを検証します（4）。上記のこの対称鍵メカニズムは、Kerberosチケットの使用と概念的に似ています。
Note that for simplicity, the diagram above and associated text describe the direct use of symmetric keys without the use of derived keys. A more secure practice is to derive the symmetric keys actually used from secrets exchanged, such as the key exchanged in step (0), using a Key Derivation Function (KDF) and use the derived keys, rather than directly using the secrets exchanged.
簡単にするために、上の図と関連テキストでは、派生キーを使用せずに対称キーを直接使用することを説明しています。より安全な方法は、交換された秘密を直接使用するのではなく、鍵導出関数（KDF）を使用して、ステップ（0）で交換された鍵などの交換された秘密から実際に使用される対称鍵を導出し、派生鍵を使用することです。
+--------------+
| | +--------------+
| |--(3) Presentation of -->| |
| | JWT w/ Public | |
| Presenter | PoP Key | |
| | | |
| |<-(4) Communication ---->| |
| | Authenticated by | |
+--------------+ PoP Key | |
| ^ | |
| | | |
(1) Public (2) JWT w/ | Recipient |
| PoP | Public | |
| Key | PoP Key | |
v | | |
+--------------+ | |
| | | |
| | | |
| | | |
| Issuer | | |
| | | |
| | | |
| | +--------------+
+--------------+
Figure 2: Proof of Possession with an Asymmetric Key
図2：非対称キーを持つ所有の証明
In the case illustrated in Figure 2, the presenter generates a public/private key pair and (1) sends the public key to the issuer, which creates a JWT that contains the public key (or an identifier for it) in the confirmation claim. The entire JWT is integrity protected using a digital signature to protect it against modifications. The JWT is then (2) sent to the presenter. When the presenter (3) presents the JWT to the recipient, it also needs to demonstrate possession of the private key. The presenter, for example, (4) uses the private key in a Transport Layer Security (TLS) exchange with the recipient or (4) signs a nonce with the private key. The recipient is able to verify that it is interacting with the genuine presenter by extracting the public key from the confirmation claim of the JWT (after verifying the digital signature of the JWT) and utilizing it with the private key in the TLS exchange or by checking the nonce signature.
図2に示す例では、プレゼンターが公開/秘密キーのペアを生成し、（1）公開キーを発行者に送信します。発行者は確認クレームに公開キー（またはその識別子）を含むJWTを作成します。 JWT全体は、変更から保護するためにデジタル署名を使用して整合性が保護されています。次に、JWTが（2）プレゼンターに送信されます。プレゼンター（3）がJWTを受信者に提示するとき、秘密鍵の所有を示す必要もあります。たとえば、プレゼンターは、（4）受信者とのトランスポート層セキュリティ（TLS）交換で秘密鍵を使用するか、（4）秘密鍵でナンスに署名します。受信者は、JWTの確認要求から公開鍵を抽出し（JWTのデジタル署名を検証した後）、TLS交換で秘密鍵と一緒に利用するか、または確認することにより、本物のプレゼンターと対話していることを確認できます。ノンス署名。
In both cases, the JWT may contain other claims that are needed by the application.
どちらの場合も、JWTにはアプリケーションが必要とする他のクレームが含まれる場合があります。
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 RFC 2119 [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの "は、RFC 2119 [RFC2119]で説明されているように解釈されます。
Unless otherwise noted, all the protocol parameter names and values are case sensitive.
特に明記しない限り、すべてのプロトコルパラメータの名前と値は大文字と小文字が区別されます。
This specification uses terms defined in the JSON Web Token [JWT], JSON Web Key [JWK], and JSON Web Encryption [JWE] specifications.
この仕様では、JSON Web Token [JWT]、JSON Web Key [JWK]、JSON Web Encryption [JWE]仕様で定義されている用語を使用しています。
These terms are defined by this specification:
これらの用語は、この仕様で定義されています。
Issuer Party that creates the JWT and binds the proof-of-possession key to it.
JWTを作成し、所有証明キーをそれにバインドする発行者パーティー。
Presenter Party that proves possession of a private key (for asymmetric key cryptography) or secret key (for symmetric key cryptography) to a recipient.
受信者に秘密鍵（非対称鍵暗号の場合）または秘密鍵（対称鍵暗号の場合）の所有を証明する発表者側。
Recipient Party that receives the JWT containing the proof-of-possession key information from the presenter.
プレゼンターから所有証明のキー情報を含むJWTを受信する受信者。
By including a "cnf" (confirmation) claim in a JWT, the issuer of the JWT declares that the presenter possesses a particular key and that the recipient can cryptographically confirm that the presenter has possession of that key. The value of the "cnf" claim is a JSON object and the members of that object identify the proof-of-possession key.
JWTに「cnf」（確認）クレームを含めることにより、JWTの発行者は、プレゼンターが特定のキーを所有し、受信者がプレゼンターがそのキーを所有していることを暗号で確認できることを宣言します。 「cnf」クレームの値はJSONオブジェクトであり、そのオブジェクトのメンバーは所有証明キーを識別します。
The presenter can be identified in one of several ways by the JWT depending upon the application requirements. If the JWT contains a "sub" (subject) claim [JWT], the presenter is normally the subject
プレゼンターは、アプリケーションの要件に応じて、JWTによっていくつかの方法の1つで識別できます。 JWTに「サブ」（サブジェクト）クレーム[JWT]が含まれている場合、プレゼンターは通常サブジェクトです
identified by the JWT. (In some applications, the subject identifier will be relative to the issuer identified by the "iss" (issuer) claim [JWT].) If the JWT contains no "sub" claim, the presenter is normally the issuer identified by the JWT using the "iss" claim. The case in which the presenter is the subject of the JWT is analogous to Security Assertion Markup Language (SAML) 2.0 [OASIS.saml-core-2.0-os] SubjectConfirmation usage. At least one of the "sub" and "iss" claims MUST be present in the JWT. Some use cases may require that both be present.
JWTによって識別されます。 （一部のアプリケーションでは、サブジェクトIDは「iss」（発行者）クレーム[JWT]によって識別される発行者に関連します。）JWTに「サブ」クレームが含まれていない場合、プレゼンターは通常、以下を使用してJWTによって識別される発行者です。 「iss」クレーム。プレゼンターがJWTのサブジェクトであるケースは、セキュリティアサーションマークアップ言語（SAML）2.0 [OASIS.saml-core-2.0-os] SubjectConfirmationの使用法に類似しています。 「sub」および「iss」クレームの少なくとも1つがJWTに存在する必要があります。一部のユースケースでは、両方が存在する必要がある場合があります。
Another means used by some applications to identify the presenter is an explicit claim, such as the "azp" (authorized party) claim defined by OpenID Connect [OpenID.Core]. Ultimately, the means of identifying the presenter is application specific, as is the means of confirming possession of the key that is communicated.
一部のアプリケーションがプレゼンターを識別するために使用するもう1つの方法は、OpenID Connect [OpenID.Core]によって定義された「azp」（承認済みパーティ）クレームなどの明示的なクレームです。最終的に、プレゼンターを識別する手段はアプリケーション固有であり、伝達されるキーの所有を確認する手段も同様です。
The "cnf" claim is used in the JWT to contain members used to identify the proof-of-possession key. Other members of the "cnf" object may be defined because a proof-of-possession key may not be the only means of confirming the authenticity of the token. This is analogous to the SAML 2.0 [OASIS.saml-core-2.0-os] SubjectConfirmation element in which a number of different subject confirmation methods can be included (including proof-of-possession key information).
「cnf」クレームはJWTで使用され、所有証明の鍵を識別するために使用されるメンバーを含みます。 「cnf」オブジェクトの他のメンバーを定義できます。これは、所有証明の鍵がトークンの信頼性を確認する唯一の手段ではない可能性があるためです。これは、SAML 2.0 [OASIS.saml-core-2.0-os] SubjectConfirmation要素に似ています。この要素には、多数の異なるサブジェクト確認メソッドを含めることができます（所有証明キー情報を含む）。
The set of confirmation members that a JWT must contain to be considered valid is context dependent and is outside the scope of this specification. Specific applications of JWTs will require implementations to understand and process some confirmation members in particular ways. However, in the absence of such requirements, all confirmation members that are not understood by implementations MUST be ignored.
JWTが有効と見なされるために含まなければならない確認メンバーのセットは、コンテキストに依存し、この仕様の範囲外です。 JWTの特定のアプリケーションでは、いくつかの確認メンバーを特定の方法で理解および処理するための実装が必要になります。ただし、そのような要件がない場合は、実装で理解されないすべての確認メンバーを無視する必要があります。
This specification establishes the IANA "JWT Confirmation Methods" registry for these members in Section 6.2 and registers the members defined by this specification. Other specifications can register other members used for confirmation, including other members for conveying proof-of-possession keys using different key representations.
この仕様は、セクション6.2でこれらのメンバーのIANA「JWT確認メソッド」レジストリを確立し、この仕様で定義されたメンバーを登録します。他の仕様では、さまざまなキー表現を使用して所有証明キーを伝達するための他のメンバーを含め、確認に使用される他のメンバーを登録できます。
The "cnf" claim value MUST represent only a single proof-of-possession key; thus, at most one of the "jwk", "jwe", and "jku" (JWK Set URL) confirmation values defined below may be present. Note that if an application needs to represent multiple proof-of-possession keys in the same JWT, one way for it to achieve this is to use other claim names, in addition to "cnf", to hold the additional proof-of- possession key information. These claims could use the same syntax and semantics as the "cnf" claim. Those claims would be defined by applications or other specifications and could be registered in the IANA "JSON Web Token Claims" registry [IANA.JWT.Claims].
「cnf」クレーム値は、単一の所有証明キーのみを表す必要があります。したがって、以下に定義されている「jwk」、「jwe」、および「jku」（JWK Set URL）確認値の最大1つが存在する可能性があります。アプリケーションが同じJWTで複数の所有証明キーを表す必要がある場合、これを実現する1つの方法は、「cnf」に加えて他のクレーム名を使用して、追加の所有証明を保持することです。重要な情報。これらのクレームでは、「cnf」クレームと同じ構文とセマンティクスを使用できます。これらのクレームは、アプリケーションまたは他の仕様によって定義され、IANAの「JSON Web Token Claims」レジストリ[IANA.JWT.Claims]に登録できます。
When the key held by the presenter is an asymmetric private key, the "jwk" member is a JSON Web Key [JWK] representing the corresponding asymmetric public key. The following example demonstrates such a declaration in the JWT Claims Set of a JWT:
プレゼンターが保持するキーが非対称秘密キーである場合、「jwk」メンバーは、対応する非対称公開キーを表すJSON Webキー[JWK]です。次の例は、JWTのJWTクレームセットでのそのような宣言を示しています。
{
"iss": "https://server.example.com",
"aud": "https://client.example.org",
"exp": 1361398824,
"cnf":{
"jwk":{
"kty": "EC",
"use": "sig",
"crv": "P-256",
"x": "18wHLeIgW9wVN6VD1Txgpqy2LszYkMf6J8njVAibvhM",
"y": "-V4dS4UaLMgP_4fY4j8ir7cl1TXlFdAgcx55o7TkcSA"
}
}
}
The JWK MUST contain the required key members for a JWK of that key type and MAY contain other JWK members, including the "kid" (Key ID) member.
JWKには、そのキータイプのJWKに必要なキーメンバーを含める必要があり、「子供」（キーID）メンバーを含む他のJWKメンバーを含めることができます（MAY）。
The "jwk" member MAY also be used for a JWK representing a symmetric key, provided that the JWT is encrypted so that the key is not revealed to unintended parties. The means of encrypting a JWT is explained in [JWT]. If the JWT is not encrypted, the symmetric key MUST be encrypted as described below.
「jwk」メンバーは、対称鍵を表すJWKにも使用できます（ただし、JWTが暗号化されており、意図しない相手に鍵が公開されない場合）。 JWTを暗号化する方法は、[JWT]で説明されています。 JWTが暗号化されていない場合は、対称鍵を以下のように暗号化する必要があります。
When the key held by the presenter is a symmetric key, the "jwe" member is an encrypted JSON Web Key [JWK] encrypted to a key known to the recipient using the JWE Compact Serialization containing the symmetric key. The rules for encrypting a JWK are found in Section 7 of the JSON Web Key [JWK] specification.
プレゼンターが保持するキーが対称キーである場合、「jwe」メンバーは、対称キーを含むJWE Compact Serializationを使用して、受信者が知っているキーに対して暗号化された暗号化されたJSON Webキー[JWK]です。 JWKの暗号化のルールは、JSON Web Key [JWK]仕様のセクション7に記載されています。
The following example illustrates a symmetric key that could subsequently be encrypted for use in the "jwe" member:
次の例は、「jwe」メンバーで使用するために後で暗号化できる対称鍵を示しています。
{
"kty": "oct",
"alg": "HS256",
"k": "ZoRSOrFzN_FzUA5XKMYoVHyzff5oRJxl-IXRtztJ6uE"
}
The UTF-8 [RFC3629] encoding of this JWK is used as the JWE Plaintext when encrypting the key.
このJWKのUTF-8 [RFC3629]エンコーディングは、キーを暗号化するときにJWE平文として使用されます。
The following example is a JWE Header that could be used when encrypting this key:
次の例は、この鍵を暗号化するときに使用できるJWEヘッダーです。
{
"alg": "RSA-OAEP",
"enc": "A128CBC-HS256"
}
The following example JWT Claims Set of a JWT illustrates the use of an encrypted symmetric key as the "jwe" member value:
次の例のJWTのJWTクレームセットは、暗号化された対称鍵を「jwe」メンバー値として使用する方法を示しています。
{
"iss": "https://server.example.com",
"sub": "24400320",
"aud": "s6BhdRkqt3",
"nonce": "n-0S6_WzA2Mj",
"exp": 1311281970,
"iat": 1311280970,
"cnf":{
"jwe":
"eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkExMjhDQkMtSFMyNTYifQ.
(remainder of JWE omitted for brevity)"
}
}
The proof-of-possession key can also be identified by the use of a Key ID instead of communicating the actual key, provided the recipient is able to obtain the identified key using the Key ID. In this case, the issuer of a JWT declares that the presenter possesses a particular key and that the recipient can cryptographically confirm proof of possession of the key by the presenter by including a "cnf" claim in the JWT whose value is a JSON object with the JSON object containing a "kid" member identifying the key.
所有者が鍵IDを使用して識別された鍵を取得できる場合は、実際の鍵を伝達する代わりに、鍵IDを使用して所有証明の鍵を識別することもできます。この場合、JWTの発行者は、プレゼンターが特定のキーを所有し、受信者がJWTに「cnf」クレームを含めることにより、プレゼンターによるキーの所有の証明を暗号で確認できることを宣言します。キーを識別する「子供」メンバーを含むJSONオブジェクト
The following example demonstrates such a declaration in the JWT Claims Set of a JWT:
次の例は、JWTのJWTクレームセットでのそのような宣言を示しています。
{
"iss": "https://server.example.com",
"aud": "https://client.example.org",
"exp": 1361398824,
"cnf":{
"kid": "dfd1aa97-6d8d-4575-a0fe-34b96de2bfad"
}
}
The content of the "kid" value is application specific. For instance, some applications may choose to use a JWK Thumbprint [JWK.Thumbprint] value as the "kid" value.
「kid」値の内容はアプリケーション固有です。たとえば、一部のアプリケーションは、JWKサムプリント[JWK.Thumbprint]値を「キッド」値として使用することを選択する場合があります。
The proof-of-possession key can be passed by reference instead of being passed by value. This is done using the "jku" member. Its value is a URI [RFC3986] that refers to a resource for a set of JSON-encoded public keys represented as a JWK Set [JWK], one of which is the proof-of-possession key. If there are multiple keys in the referenced JWK Set document, a "kid" member MUST also be included with the referenced key's JWK also containing the same "kid" value.
所有証明キーは、値ではなく参照で渡すことができます。これは、「jku」メンバーを使用して行われます。その値は、JWKセット[JWK]として表されるJSONエンコードされた公開キーのセットのリソースを参照するURI [RFC3986]であり、その1つは所有証明キーです。参照されるJWKセットドキュメントに複数のキーがある場合、「子供」メンバーも、同じ「子供」値を含む参照されるキーのJWKに含める必要があります。
The protocol used to acquire the resource MUST provide integrity protection. An HTTP GET request to retrieve the JWK Set MUST use TLS [RFC5246] and the identity of the server MUST be validated, as per Section 6 of RFC 6125 [RFC6125].
リソースの取得に使用されるプロトコルは、整合性保護を提供する必要があります。 RFC 6125 [RFC6125]のセクション6に従って、JWKセットを取得するためのHTTP GETリクエストはTLS [RFC5246]を使用する必要があり、サーバーのIDを検証する必要があります。
The following example demonstrates such a declaration in the JWT Claims Set of a JWT:
次の例は、JWTのJWTクレームセットでのそのような宣言を示しています。
{
"iss": "https://server.example.com",
"sub": "17760704",
"aud": "https://client.example.org",
"exp": 1440804813,
"cnf":{
"jku": "https://keys.example.net/pop-keys.json",
"kid": "2015-08-28"
}
}
Proof of possession is typically demonstrated by having the presenter sign a value determined by the recipient using the key possessed by the presenter. This value is sometimes called a "nonce" or a "challenge".
所持証明は、通常、プレゼンターが所有するキーを使用して受信者が決定した値にプレゼンターが署名することによって示されます。この値は、「ノンス」または「チャレンジ」と呼ばれることもあります。
The means of communicating the nonce and the nature of its contents are intentionally not described in this specification, as different protocols will communicate this information in different ways. Likewise, the means of communicating the signed nonce is also not specified, as this is also protocol specific.
異なるプロトコルが異なる方法でこの情報を通信するため、ノンスとその内容の性質を通信する手段は意図的にこの仕様では説明されていません。同様に、署名されたナンスを通信する手段もプロトコル固有であるため、指定されていません。
Note that another means of proving possession of the key when it is a symmetric key is to encrypt the key to the recipient. The means of obtaining a key for the recipient is likewise protocol specific.
対称鍵である場合に鍵の所有を証明する別の方法は、受信者に対して鍵を暗号化することです。受信者のキーを取得する手段も同様にプロトコル固有です。
For examples using the mechanisms defined in this specification, see [OAUTH-POP-ARCH].
この仕様で定義されているメカニズムの使用例については、[OAUTH-POP-ARCH]を参照してください。
All of the security considerations that are discussed in [JWT] also apply here. In addition, proof of possession introduces its own unique security issues. Possessing a key is only valuable if it is kept secret. Appropriate means must be used to ensure that unintended parties do not learn private key or symmetric key values.
[JWT]で説明されているセキュリティの考慮事項のすべてがここでも適用されます。さらに、所持証明は独自のセキュリティ問題を引き起こします。キーを所持することは、それが秘密にされている場合にのみ価値があります。意図しない当事者が秘密鍵または対称鍵の値を学習しないようにするために、適切な手段を使用する必要があります。
Applications utilizing proof of possession should also utilize audience restriction, as described in Section 4.1.3 of [JWT], as it provides different protections. Proof of possession can be used by recipients to reject messages from unauthorized senders. Audience restriction can be used by recipients to reject messages intended for different recipients.
所有証明を利用するアプリケーションは、[JWT]のセクション4.1.3で説明されているように、異なる保護を提供するため、オーディエンス制限も利用する必要があります。所持証明は、受信者が不正な送信者からのメッセージを拒否するために使用できます。受信者は、オーディエンス制限を使用して、さまざまな受信者宛のメッセージを拒否できます。
A recipient might not understand the "cnf" claim. Applications that require the proof-of-possession keys communicated with it to be understood and processed must ensure that the parts of this specification that they use are implemented.
受信者は「cnf」クレームを理解していない可能性があります。アプリケーションと通信して所持証明キーを理解および処理する必要がある場合、アプリケーションが使用するこの仕様の部分が実装されていることを確認する必要があります。
Proof of possession via encrypted symmetric secrets is subject to replay attacks. This attack can, for example, be avoided when a signed nonce or challenge is used since the recipient can use a distinct nonce or challenge for each interaction. Replay can also be avoided if a sub-key is derived from a shared secret that is specific to the instance of the PoP demonstration.
暗号化された対称秘密を介した所持証明は、リプレイ攻撃の対象となります。たとえば、受信者は対話ごとに個別のナンスまたはチャレンジを使用できるため、署名されたナンスまたはチャレンジが使用されている場合、この攻撃を回避できます。 PoPデモのインスタンスに固有の共有シークレットからサブキーが派生している場合も、リプレイを回避できます。
As is the case with other information included in a JWT, it is necessary to apply data origin authentication and integrity protection (via a keyed message digest or a digital signature). Data origin authentication ensures that the recipient of the JWT learns about the entity that created the JWT since this will be important for any policy decisions. Integrity protection prevents an adversary from changing any elements conveyed within the JWT payload. Special care has to be applied when carrying symmetric keys inside the JWT since those not only require integrity protection but also confidentiality protection.
JWTに含まれる他の情報と同様に、（鍵付きメッセージダイジェストまたはデジタル署名による）データ送信元認証と整合性保護を適用する必要があります。データ発信元認証により、JWTの受信者は、JWTを作成したエンティティについて確実に知ることができます。これは、ポリシーの決定にとって重要であるためです。完全性保護は、JWTペイロード内で伝達される要素を敵が変更することを防ぎます。 JWT内で対称鍵を運ぶときは、整合性保護だけでなく機密保護も必要になるため、特別な注意が必要です。
A proof-of-possession key can be used as a correlation handle if the same key is used with multiple parties. Thus, for privacy reasons, it is recommended that different proof-of-possession keys be used when interacting with different parties.
同じ鍵が複数のパーティで使用されている場合、所有証明鍵を相関ハンドルとして使用できます。したがって、プライバシー上の理由から、さまざまな当事者と対話する場合は、さまざまな所有証明キーを使用することをお勧めします。
The following registration procedure is used for all the registries established by this specification.
次の登録手順は、この仕様で確立されたすべてのレジストリに使用されます。
Values are registered on a Specification Required [RFC5226] basis after a three-week review period on the jwt-reg-review@ietf.org mailing list, on the advice of one or more Designated Experts. However, to allow for the allocation of values prior to publication, the Designated Experts may approve registration once they are satisfied that such a specification will be published.
値は、1名以上のDesignated Expertsの助言により、jwt-reg-review @ ietf.orgメーリングリストで3週間のレビュー期間の後に、Specification Required [RFC5226]ベースで登録されます。ただし、公開前に値を割り当てることを可能にするために、指定された専門家は、そのような仕様が公開されることを納得したら、登録を承認することができます。
Registration requests sent to the mailing list for review should use an appropriate subject (e.g., "Request to Register JWT Confirmation Method: example"). Registration requests that are undetermined for a period longer than 21 days can be brought to the IESG's attention (using the iesg@ietf.org mailing list) for resolution.
確認のためにメーリングリストに送信される登録リクエストでは、適切な件名を使用する必要があります（「JWT確認メソッドの登録リクエスト：例」など）。 21日よりも長い期間未確定の登録要求は、解決のために（iesg@ietf.orgメーリングリストを使用して）IESGに通知することができます。
Criteria that should be applied by the Designated Experts include determining whether the proposed registration duplicates existing functionality, determining whether it is likely to be of general applicability or whether it is useful only for a single application, and evaluating the security properties of the item being registered and whether the registration makes sense.
Designated Expertsが適用する必要のある基準には、提案された登録が既存の機能と重複しているかどうかの判断、一般的な適用性があるかどうか、または単一のアプリケーションにのみ役立つかどうかの判断、および登録されているアイテムのセキュリティプロパティの評価が含まれます。登録が意味があるかどうか。
It is suggested that multiple Designated Experts be appointed who are able to represent the perspectives of different applications using this specification in order to enable broadly informed review of registration decisions. In cases where a registration decision could be perceived as creating a conflict of interest for a particular Expert, that Expert should defer to the judgment of the other Experts.
広範囲にわたる情報に基づいた登録決定のレビューを可能にするために、この仕様を使用してさまざまなアプリケーションの見通しを表すことができる複数の指定専門家を任命することが推奨されます。登録の決定が特定のエキスパートの利益相反を生み出すものとして認識される可能性がある場合、そのエキスパートは他のエキスパートの判断を延期する必要があります。
This specification registers the "cnf" claim in the IANA "JSON Web Token Claims" registry [IANA.JWT.Claims] established by [JWT].
この仕様は、[JWT]によって確立されたIANA "JSON Web Token Claims"レジストリ[IANA.JWT.Claims]に「cnf」クレームを登録します。
o Claim Name: "cnf" o Claim Description: Confirmation o Change Controller: IESG o Specification Document(s): Section 3.1 of [RFC7800]
o クレーム名：「cnf」oクレームの説明：確認o変更管理者：IESG o仕様書：[RFC7800]のセクション3.1
This specification establishes the IANA "JWT Confirmation Methods" registry for JWT "cnf" member values. The registry records the confirmation method member and a reference to the specification that defines it.
この仕様は、JWT「cnf」メンバー値のIANA「JWT確認メソッド」レジストリを確立します。レジストリは、確認メソッドのメンバーとそれを定義する仕様への参照を記録します。
Confirmation Method Value: The name requested (e.g., "kid"). Because a core goal of this specification is for the resulting representations to be compact, it is RECOMMENDED that the name be short -- not to exceed eight characters without a compelling reason to do so. This name is case sensitive. Names may not match other registered names in a case-insensitive manner unless the Designated Experts state that there is a compelling reason to allow an exception.
確認方法の値：要求された名前（「kid」など）。この仕様の中心的な目標は、結果の表現をコンパクトにすることです。そのため、やむを得ない理由がない限り、名前は8文字を超えないように短くすることをお勧めします。この名前は大文字と小文字が区別されます。指定された専門家が例外を許可するやむを得ない理由があると述べない限り、名前は大文字と小文字を区別しない方法で他の登録名と一致しない場合があります。
Confirmation Method Description: Brief description of the confirmation method (e.g., "Key Identifier").
確認方法の説明：確認方法の簡単な説明（「キー識別子」など）。
Change Controller: For Standards Track RFCs, list the "IESG". For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included.
変更管理者：Standards Track RFCsについては、「IESG」をリストします。その他の場合は、責任者の名前を入力してください。その他の詳細（たとえば、住所、電子メールアドレス、ホームページURI）も含まれる場合があります。
Specification Document(s): Reference to the document or documents that specify the parameter, preferably including URIs that can be used to retrieve copies of the documents. An indication of the relevant sections may also be included but is not required.
仕様ドキュメント：パラメータを指定する1つまたは複数のドキュメントへの参照。できれば、ドキュメントのコピーを取得するために使用できるURIを含む。関連セクションの表示も含まれる場合がありますが、必須ではありません。
o Confirmation Method Value: "jwk" o Confirmation Method Description: JSON Web Key Representing Public Key o Change Controller: IESG o Specification Document(s): Section 3.2 of [RFC7800] o Confirmation Method Value: "jwe" o Confirmation Method Description: Encrypted JSON Web Key o Change Controller: IESG o Specification Document(s): Section 3.3 of [RFC7800]
o 確認方法の値：「jwk」o確認方法の説明：公開鍵を表すJSON Webキーo変更管理者：IESG o仕様書：[RFC7800]のセクション3.2 o確認方法の値：「jwe」o確認方法の説明：暗号化JSON Web Key o Change Controller：IESG o Specification Document（s）：Section 3.3 of [RFC7800]
o Confirmation Method Value: "kid" o Confirmation Method Description: Key Identifier o Change Controller: IESG o Specification Document(s): Section 3.4 of [RFC7800]
o 確認方法の値：「子供」o確認方法の説明：キー識別子o変更管理者：IESG o仕様書：[RFC7800]のセクション3.4
o Confirmation Method Value: "jku" o Confirmation Method Description: JWK Set URL o Change Controller: IESG o Specification Document(s): Section 3.5 of [RFC7800]
o 確認方法の値：「jku」o確認方法の説明：JWKセットURL oコントローラーの変更：IESG o仕様書：[RFC7800]のセクション3.5
[IANA.JWT.Claims] IANA, "JSON Web Token Claims", <http://www.iana.org/assignments/jwt>.
[IANA.JWT.Claims] IANA、「JSON Web Token Claims」、<http://www.iana.org/assignments/jwt>。
[JWE] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7156, May 2015, <http://www.rfc-editor.org/info/rfc7516>.
[JWE]ジョーンズ、M。およびJ.ヒルデブランド、「JSON Web Encryption（JWE）」、RFC 7516、DOI 10.17487 / RFC7156、2015年5月、<http://www.rfc-editor.org/info/rfc7516>。
[JWK] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7157, May 2015, <http://www.rfc-editor.org/info/rfc7517>.
[JWK]ジョーンズ、M。、「JSON Web Key（JWK）」、RFC 7517、DOI 10.17487 / RFC7157、2015年5月、<http://www.rfc-editor.org/info/rfc7517>。
[JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7159, May 2015, <http://www.rfc-editor.org/info/rfc7519>.
[JWT]ジョーンズ、M。、ブラッドリー、J.、N。崎村、「JSON Web Token（JWT）」、RFC 7519、DOI 10.17487 / RFC7159、2015年5月、<http://www.rfc-editor.org / info / rfc7519>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、DOI 10.17487 / RFC3629、2003年11月、<http://www.rfc-editor.org/info/ rfc3629>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<http：/ /www.rfc-editor.org/info/rfc3986>。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、DOI 10.17487 / RFC5226、2008年5月、<http://www.rfc-editor.org / info / rfc5226>。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<http://www.rfc-editor.org/info / rfc5246>。
[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, <http://www.rfc-editor.org/info/rfc6125>.
[RFC6125] Saint-Andre、P。およびJ. Hodges、「トランスポート層セキュリティ（TLS）のコンテキストでX.509（PKIX）証明書を使用したインターネット公開鍵インフラストラクチャ内のドメインベースのアプリケーションサービスIDの表現と検証」、 RFC 6125、DOI 10.17487 / RFC6125、2011年3月、<http://www.rfc-editor.org/info/rfc6125>。
[JWK.Thumbprint] Jones, M. and N. Sakimura, "JSON Web Key (JWK) Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 2015, <http://www.rfc-editor.org/info/rfc7638>.
[JWK.Thumbprint]ジョーンズ、M.、N。崎村、「JSON Web Key（JWK）Thumbprint」、RFC 7638、DOI 10.17487 / RFC7638、2015年9月、<http://www.rfc-editor.org/info/ rfc7638>。
[OASIS.saml-core-2.0-os] Cantor, S., Kemp, J., Philpott, R., and E. Maler, "Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0", OASIS Standard saml-core-2.0-os, March 2005, <http://docs.oasis-open.org/security/saml/v2.0/>.
[OASIS.saml-core-2.0-os] Cantor、S.、Kemp、J.、Philpott、R.、and E. Maler、 "Assertions and Protocol for the OASIS Security Assertion Markup Language（SAML）V2.0"、 OASIS標準saml-core-2.0-os、2005年3月、<http://docs.oasis-open.org/security/saml/v2.0/>。
[OAUTH-POP-ARCH] Hunt, P., Ed, Richer, J., Mills, W., Mishra, P., and H. Tschofenig, "OAuth 2.0 Proof-of-Possession (PoP) Security Architecture", Work in Progress, draft-ietf-oauth-pop-architecture-07, December 2015.
[OAUTH-POP-ARCH] Hunt、P.、Ed、Richer、J.、Mills、W.、Mishra、P。、およびH. Tschofenig、「OAuth 2.0 Proof-of-Possession（PoP）Security Architecture」、Work進行中、draft-ietf-oauth-pop-architecture-07、2015年12月。
[OpenID.Core] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, "OpenID Connect Core 1.0", November 2014, <http://openid.net/specs/openid-connect-core-1_0.html>.
[OpenID.Core] Sakimura N.、Bradley、J.、Jones、M.、de Medeiros、B。、およびC. Mortimore、「OpenID Connect Core 1.0」、2014年11月、<http://openid.net/ specs / openid-connect-core-1_0.html>。
Acknowledgements
謝辞
The authors wish to thank Brian Campbell, Stephen Farrell, Barry Leiba, Kepeng Li, Chris Lonvick, James Manger, Kathleen Moriarty, Justin Richer, and Nat Sakimura for their reviews of the specification.
仕様のレビューをしてくれたBrian Campbell、Stephen Farrell、Barry Leiba、Kepeng Li、Chris Lonvick、James Manger、Kathleen Moriarty、Justin Richer、Nat Sakimuraに感謝します。
Authors' Addresses
著者のアドレス
Michael B. Jones Microsoft
マイケルB.ジョーンズマイクロソフト
Email: mbj@microsoft.com
URI: http://self-issued.info/
John Bradley Ping Identity
ジョンブラッドリーピンアイデンティティ
Email: ve7jtb@ve7jtb.com
URI: http://www.thread-safe.com/
Hannes Tschofenig ARM Limited Austria
Hannes Tschofenig ARM Limitedオーストリア
Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at