[要約] RFC 9246は、CDN間のコンテンツ配信におけるURI署名をサポートするためのJWTプロファイルを提案しており、署名されたJWTによってUAを認可する情報をURIに含める方法を規定しています。このメカニズムは、CDNIおよび単一CDNのシナリオの両方で使用できます。
Internet Engineering Task Force (IETF) R. van Brandenburg
Request for Comments: 9246 Tiledmedia
Category: Standards Track K. Leung
ISSN: 2070-1721
P. Sorber
Apple, Inc.
June 2022
URI Signing for Content Delivery Network Interconnection (CDNI)
コンテンツ配信ネットワークの相互接続のためのURI署名（CDNI）
Abstract
概要
This document describes how the concept of URI Signing supports the content access control requirements of Content Delivery Network Interconnection (CDNI) and proposes a URI Signing method as a JSON Web Token (JWT) profile.
このドキュメントでは、URIの署名の概念がコンテンツ配信ネットワーク相互接続（CDNI）のコンテンツアクセス制御要件をどのようにサポートし、JSON Webトークン（JWT）プロファイルとしてURI署名方法を提案しています。
The proposed URI Signing method specifies the information needed to be included in the URI to transmit the signed JWT, as well as the claims needed by the signed JWT to authorize a User Agent (UA). The mechanism described can be used both in CDNI and single Content Delivery Network (CDN) scenarios.
提案されたURI署名方法は、署名されたJWTを送信するためにURIに含まれる必要がある情報と、署名されたJWTがユーザーエージェント（UA）を承認するために必要な請求を指定します。説明されているメカニズムは、CDNIおよび単一コンテンツ配信ネットワーク（CDN）シナリオの両方で使用できます。
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/rfc9246.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9246で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されているように保証なしで提供される修正されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction
1.1. Terminology
1.2. Background and Overview on URI Signing
1.3. CDNI URI Signing Overview
1.4. URI Signing in a Non-CDNI Context
2. JWT Format and Processing Requirements
2.1. JWT Claims
2.1.1. Issuer (iss) Claim
2.1.2. Subject (sub) Claim
2.1.3. Audience (aud) Claim
2.1.4. Expiry Time (exp) Claim
2.1.5. Not Before (nbf) Claim
2.1.6. Issued At (iat) Claim
2.1.7. JWT ID (jti) Claim
2.1.8. CDNI Claim Set Version (cdniv) Claim
2.1.9. CDNI Critical Claims Set (cdnicrit) Claim
2.1.10. Client IP Address (cdniip) Claim
2.1.11. CDNI URI Container (cdniuc) Claim
2.1.12. CDNI Expiration Time Setting (cdniets) Claim
2.1.13. CDNI Signed Token Transport (cdnistt) Claim
2.1.14. CDNI Signed Token Depth (cdnistd) Claim
2.1.15. URI Container Forms
2.1.15.1. URI Hash Container (hash:)
2.1.15.2. URI Regular Expression Container (regex:)
2.2. JWT Header
3. URI Signing Token Renewal
3.1. Overview
3.2. Signed Token Renewal Mechanism
3.2.1. Required Claims
3.3. Communicating a Signed JWT in Signed Token Renewal
3.3.1. Support for Cross-Domain Redirection
4. Relationship with CDNI Interfaces
4.1. CDNI Control Interface
4.2. CDNI Footprint & Capabilities Advertisement Interface
4.3. CDNI Request Routing Redirection Interface
4.4. CDNI Metadata Interface
4.5. CDNI Logging Interface
5. URI Signing Message Flow
5.1. HTTP Redirection
5.2. DNS Redirection
6. IANA Considerations
6.1. CDNI Payload Type
6.1.1. CDNI UriSigning Payload Type
6.2. CDNI Logging Record Type
6.2.1. CDNI Logging Record Version 2 for HTTP
6.3. CDNI Logging Field Names
6.4. CDNI URI Signing Verification Code
6.5. CDNI URI Signing Signed Token Transport
6.6. JSON Web Token Claims Registration
6.6.1. Registry Contents
6.7. Expert Review Guidance
7. Security Considerations
8. Privacy
9. References
9.1. Normative References
9.2. Informative References
Appendix A. Signed URI Package Example
A.1. Simple Example
A.2. Complex Example
A.3. Signed Token Renewal Example
Acknowledgements
Contributors
Authors' Addresses
This document describes the concept of URI Signing and how it can be used to provide access authorization in the case of redirection between cooperating CDNs and between a Content Service Provider (CSP) and a CDN. The primary goal of URI Signing is to make sure that only authorized UAs are able to access the content, with a CSP being able to authorize every individual request. It should be noted that URI Signing is not a content protection scheme; if a CSP wants to protect the content itself, other mechanisms, such as Digital Rights Management (DRM), are more appropriate. In addition to access control, URI Signing also has benefits in reducing the impact of denial-of-service attacks.
このドキュメントでは、URIの署名の概念と、協力CDNとコンテンツサービスプロバイダー（CSP）とCDNの間のリダイレクトの場合にアクセス許可を提供するために使用する方法について説明します。URI署名の主な目標は、CSPがすべての個々のリクエストを許可できるように、認定されたUASのみがコンテンツにアクセスできることを確認することです。URIの署名はコンテンツ保護スキームではないことに注意する必要があります。CSPがコンテンツ自体を保護したい場合、Digital Rights Management（DRM）などの他のメカニズムがより適切です。Access Controlに加えて、URIの署名には、サービス拒否攻撃の影響を減らすことにも利点があります。
The overall problem space for CDN Interconnection (CDNI) is described in the CDNI Problem Statement [RFC6707] specification. This document, along with the Content Distribution Network Interconnection (CDNI) Requirements [RFC7337] document and the Framework for Content Distribution Network Interconnection (CDNI) [RFC7336], describes the need for interconnected CDNs to be able to implement an access control mechanism that enforces a CSP's distribution policies.
CDN相互接続（CDNI）の全体的な問題スペースは、CDNI問題ステートメント[RFC6707]仕様で説明されています。このドキュメントは、コンテンツ配信ネットワークの相互接続（CDNI）要件[RFC7337]ドキュメントとコンテンツ配信ネットワーク相互接続（CDNI）[RFC7336]のフレームワークとともに、相互接続されたCDNが強制されるアクセス制御メカニズムを実装できる必要性を説明しています。CSPの配布ポリシー。
Specifically, the CDNI Framework [RFC7336] states:
具体的には、CDNIフレームワーク[RFC7336]は次のとおりです。
The CSP may also trust the CDN operator to perform actions such as delegating traffic to additional downstream CDNs, and to enforce per-request authorization performed by the CSP using techniques such as URI Signing.
また、CSPは、CDNオペレーターが追加のダウンストリームCDNにトラフィックを委任するなどのアクションを実行し、URI署名などの手法を使用してCSPが実行するリケストごとの許可を実施することを信頼する場合があります。
In particular, the following requirement is listed in the CDNI Requirements [RFC7337]:
特に、次の要件はCDNI要件[RFC7337]にリストされています。
| MI-16 {HIGH} The CDNI Metadata interface shall allow signaling
| of authorization checks and validation that are to be
| performed by the Surrogate before delivery. For example,
| this could potentially include the need to validate
| information (e.g., Expiry time, Client IP address) required
| for access authorization.
This document defines a method of signing URIs that allows Surrogates in interconnected CDNs to enforce a per-request authorization initiated by the CSP. Splitting the role of initiating per-request authorization by the CSP and the role of verifying this authorization by the CDN allows any arbitrary distribution policy to be enforced across CDNs without the need of CDNs to have any awareness of the specific CSP distribution policies.
このドキュメントでは、相互接続されたCDNのサロゲートがCSPによって開始されたレクエストごとの認可を実施できるようにするURIに署名する方法を定義しています。CSPによる要求ごとの許可を開始する役割とCDNによるこの認可を検証する役割を分割することで、CDNSを必要とせずに特定のCSP分布ポリシーを認識する必要なく、任意の分布ポリシーをCDNを介して実施することができます。
The method is implemented using signed JSON Web Tokens (JWTs) [RFC7519].
このメソッドは、署名されたJSON Webトークン（JWTS）[RFC7519]を使用して実装されます。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
This document uses the terminology defined in the CDNI Problem Statement [RFC6707].
この文書は、CDNI問題ステートメント[RFC6707]で定義されている用語を使用しています。
This document also uses the terminology of the JSON Web Token (JWT) [RFC7519].
このドキュメントでは、JSON Webトークン（JWT）[RFC7519]の用語も使用しています。
In addition, the following terms are used throughout this document:
さらに、このドキュメント全体で次の用語が使用されます。
FCI: Footprint & Capabilities Advertisement interface
FCI：フットプリントと機能広告インターフェイス
Signed URI: A URI for which a signed JWT is provided.
署名されたURI：署名されたJWTが提供されるURI。
Target CDN URI: A URI created by the CSP to direct a UA towards the upstream CDN (uCDN). The Target CDN URI can be signed by the CSP and verified by the uCDN and possibly further downstream CDNs (dCDNs).
ターゲットCDN URI：CSPによって作成されたURIは、UAを上流のCDN（UCDN）に向けるために指示します。ターゲットCDN URIは、CSPによって署名され、UCDNおよびおそらくさらに下流CDN（DCDN）によって検証されます。
Redirection URI: A URI created by the uCDN to redirect a UA towards the dCDN. The Redirection URI can be signed by the uCDN and verified by the dCDN. In a cascaded CDNI scenario, there can be more than one Redirection URI.
リダイレクトURI：UCDNによって作成されたURIは、DCDNにUAをリダイレクトします。リダイレクトURIはUCDNによって署名され、DCDNによって検証されます。カスケードされたCDNIシナリオでは、複数のリダイレクトURIがある可能性があります。
Signed Token Renewal: A series of signed JWTs that are used for subsequent access to a set of related resources in a CDN, such as a set of HTTP Adaptive Streaming files. Every time a signed JWT is used to access a particular resource, a new signed JWT is sent along with the resource that can be used to request the next resource in the set. When generating a new signed JWT in Signed Token Renewal, parameters are carried over from one signed JWT to the next.
署名されたトークン更新：HTTPアダプティブストリーミングファイルのセットなど、CDN内の関連リソースのセットへのその後のアクセスに使用される一連の署名されたJWTS。署名されたJWTが特定のリソースへのアクセスに使用されるたびに、新しい署名されたJWTがセット内の次のリソースを要求するために使用できるリソースとともに送信されます。署名済みのトークン更新で新しい署名されたJWTを生成すると、パラメーターは署名されたJWTから次のJWTに引き継がれます。
A CSP and CDN are assumed to have a trust relationship that enables the CSP to authorize access to a content item, which is realized in practice by including a set of claims in a signed JWT in the URI before redirecting a UA to the CDN. Using these attributes, it is possible for a CDN to check an incoming content request to see whether it was authorized by the CSP (e.g., based on a time window or pattern matching the URI). To prevent the UA from altering the claims, the JWT MUST be signed.
CSPとCDNは、CSPがCDNにリダイレクトする前にURIの署名されたJWTに署名されたJWTに一連のクレームを含めることで実際に実現できるコンテンツアイテムへのアクセスを承認できるようにする信頼関係を持つと想定されています。これらの属性を使用して、CDNが着信コンテンツリクエストをチェックして、CSPによって承認されたかどうかを確認することができます（たとえば、URIと一致するタイムウィンドウまたはパターンに基づいて）。UAがクレームを変更するのを防ぐために、JWTに署名する必要があります。
Figure 1 presents an overview of the URI Signing mechanism in the case of a CSP with a single CDN. When the UA browses for content on CSP's website (1), it receives HTML web pages with embedded content URIs. Upon requesting these URIs, the CSP redirects to a CDN, creating a Target CDN URI (2) (alternatively, the Target CDN URI itself is embedded in the HTML). The Target CDN URI is the Signed URI, which may include the IP address of the UA and/or a time window. The Signed URI always contains a signed JWT generated by the CSP using a shared secret or private key. Once the UA receives the response with the Signed URI, it sends a new HTTP request using the Signed URI to the CDN (3). Upon receiving the request, the CDN authenticates the Signed URI by verifying the signed JWT. If applicable, the CDN checks whether the time window is still valid in the Signed URI and the pattern matches the URI of the request. After these claims are verified, the CDN delivers the content (4).
図1は、CSPの場合のURI署名メカニズムの概要を、単一のCDNを備えた概要を示しています。UAがCSPのWebサイト（1）でコンテンツを参照すると、埋め込まれたコンテンツURIを備えたHTML Webページを受信します。これらのURIを要求すると、CSPはCDNにリダイレクトし、ターゲットCDN URI（2）を作成します（あるいは、ターゲットCDN URI自体がHTMLに埋め込まれています）。ターゲットCDN URIは署名されたURIで、UAのIPアドレスおよび/または時間ウィンドウが含まれる場合があります。署名されたURIには、共有秘密または秘密鍵を使用してCSPによって生成された署名されたJWTが常に含まれています。UAが署名されたURIで応答を受信すると、署名されたURIをCDN（3）に使用して新しいHTTP要求を送信します。リクエストを受信すると、CDNは署名されたJWTを確認することにより、署名されたURIを認証します。該当する場合、CDNは、署名されたURIで時間ウィンドウがまだ有効であるかどうかをチェックし、パターンはリクエストのURIと一致します。これらのクレームが検証された後、CDNはコンテンツを配信します（4）。
Note: While using a symmetric shared key is supported, it is NOT RECOMMENDED. See the Security Considerations (Section 7) about the limitations of shared keys.
注：対称共有キーを使用することがサポートされていますが、推奨されません。共有キーの制限に関するセキュリティに関する考慮事項（セクション7）を参照してください。
--------
/ \
| CSP |< * * * * * * * * * * *
\ / Trust *
-------- relationship *
^ | *
| | *
1. Browse | | 2. Signed *
for | | URI *
content | | *
| v v
+------+ 3. Signed URI --------
| User |----------------->/ \
| Agent| | CDN |
| |<-----------------\ /
+------+ 4. Content --------
Delivery
Figure 1: URI Signing in a CDN Environment
図1：CDN環境でのURI署名
In a CDNI environment, as shown in Figure 2 below, URI Signing operates the same way in the initial steps 1 and 2, but the later steps involve multiple CDNs delivering the content. The main difference from the single CDN case is a redirection step between the uCDN and the dCDN. In step 3, the UA may send an HTTP request or a DNS request, depending on whether HTTP-based or DNS-based request routing is used. The uCDN responds by directing the UA towards the dCDN using either a Redirection URI (i.e., a Signed URI generated by the uCDN) or a DNS reply, respectively (4). Once the UA receives the response, it sends the Redirection URI/Target CDN URI to the dCDN (5). The received URI is verified by the dCDN before delivering the content (6).
以下の図2に示すように、CDNI環境では、URIの署名は最初の手順1と2で同じように動作しますが、後の手順では、コンテンツを配信する複数のCDNが含まれます。単一のCDNケースとの主な違いは、UCDNとDCDNの間のリダイレクトステップです。ステップ3では、UAは、HTTPベースまたはDNSベースのリクエストルーティングが使用されるかどうかに応じて、HTTP要求またはDNSリクエストを送信する場合があります。UCDNは、リダイレクトURI（つまり、UCDNによって生成された署名URI）またはDNS応答のいずれかを使用してDCDNにUAを指示することにより応答します（4）。UAが応答を受信すると、リダイレクトURI/ターゲットCDN URIをDCDNに送信します（5）。受信したURIは、コンテンツを配信する前にDCDNによって検証されます（6）。
Note: The CDNI call flows are covered in URI Signing Message Flow (Section 5).
注：CDNIコールフローは、URIの署名メッセージフロー（セクション5）でカバーされています。
+-------------------------+
|Request Redirection Modes|
+-------------------------+
| a) HTTP |
| b) DNS |
+-------------------------+
--------
/ \< * * * * * * * * * * * * * *
| CSP |< * * * * * * * * * * * *
\ / Trust * *
-------- relationship * *
^ | * *
| | 2. Signed * *
1. Browse | | URI in * *
for | | HTML * *
content | | * *
| v 3.a)Signed URI v *
+------+ b)DNS request -------- * Trust
| User |----------------->/ \ * relationship
| Agent| | uCDN | * (optional)
| |<-----------------\ / *
+------+ 4.a)Redirection URI------- *
^ | b)DNS Reply ^ *
| | * *
| | Trust relationship * *
| | * *
6. Content | | 5.a)Redirection URI * *
delivery | | b)Signed URI(after v v
| | DNS exchange) --------
| +---------------------->/ \ [May be
| | dCDN | cascaded
+--------------------------\ / CDNs]
--------
Figure 2: URI Signing in a CDNI Environment
図2：CDNI環境でのURI署名
The trust relationships between CSP, uCDN, and dCDN have direct implications for URI Signing. In the case shown in Figure 2, the CSP has a trust relationship with the uCDN. The delivery of the content may be delegated to a dCDN, which has a relationship with the uCDN but may have no relationship with the CSP.
CSP、UCDN、およびDCDNの信頼関係は、URIの署名に直接的な意味を持っています。図2に示す場合、CSPはUCDNとの信頼関係を持っています。コンテンツの配信は、UCDNと関係があるが、CSPと関係がないDCDNに委任される場合があります。
In CDNI, there are two methods for request routing: DNS-based and HTTP-based. For DNS-based request routing, the Signed URI (i.e., the Target CDN URI) provided by the CSP reaches the CDN directly. In the case where the dCDN does not have a trust relationship with the CSP, this means that either an asymmetric public/private key method needs to be used for computing the signed JWT (because the CSP and dCDN are not able to exchange symmetric shared secret keys). Shared keys MUST NOT be redistributed.
CDNIには、リクエストルーティングにはDNSベースとHTTPベースの2つの方法があります。DNSベースのリクエストルーティングの場合、CSPによって提供される署名されたURI（つまり、ターゲットCDN URI）がCDNに直接到達します。DCDNがCSPと信頼関係を持っていない場合、これは、署名されたJWTの計算に非対称パブリック/秘密キー方式を使用する必要があることを意味します（CSPとDCDNは対称共有シークレットを交換できないためキー）。共有キーを再配布してはなりません。
For HTTP-based request routing, the Signed URI (i.e., the Target CDN URI) provided by the CSP reaches the uCDN. After this URI has been verified by the uCDN, the uCDN creates and signs a new Redirection URI, redirecting the UA to the dCDN. Since this new URI can have a new signed JWT, the relationship between the dCDN and CSP is not relevant. Because a relationship between uCDN and dCDN always exists, either asymmetric public/private keys or symmetric shared secret keys can be used for URI Signing with HTTP-based request routing. Note that the signed Redirection URI MUST maintain HTTPS as the scheme if it was present in the original, and it MAY be upgraded from "http:" to "https:".
HTTPベースのリクエストルーティングの場合、CSPによって提供される署名されたURI（つまり、ターゲットCDN URI）がUCDNに到達します。このURIがUCDNによって検証された後、UCDNは新しいリダイレクトURIを作成および署名し、UAをDCDNにリダイレクトします。この新しいURIには新しい署名されたJWTがある可能性があるため、DCDNとCSPの関係は関連していません。UCDNとDCDNの関係は常に存在するため、非対称のパブリック/プライベートキーまたは対称共有シークレットキーのいずれかを、HTTPベースのリクエストルーティングでURIの署名に使用できます。署名されたリダイレクトURIは、オリジナルに存在する場合、スキームとしてHTTPSを維持する必要があり、「http：」から「https：」にアップグレードされる可能性があることに注意してください。
Two types of keys can be used for URI Signing: asymmetric keys and symmetric shared keys. Asymmetric keys are based on a public/private key pair mechanism and always contain a private key known only to the entity signing the URI (either CSP or uCDN) and a public key for the verification of the Signed URI. With symmetric keys, the same key is used by both the signing entity for signing the URI and the verifying entity for verifying the Signed URI. Regardless of the type of keys used, the verifying entity has to obtain the key in a manner that allows trust to be placed in the assertions made using that key (either the public or the symmetric key). There are very different requirements (outside the scope of this document) for distributing asymmetric keys and symmetric keys. Key distribution for symmetric keys requires confidentiality to prevent third parties from getting access to the key, since they could then generate valid Signed URIs for unauthorized requests. Key distribution for asymmetric keys does not require confidentiality since public keys can typically be distributed openly (because they cannot be used to sign URIs) and the corresponding private keys are kept secret by the URI signer.
URIの署名には、非対称キーと対称共有キーの2種類のキーを使用できます。非対称キーは、パブリック/プライベートキーペアのメカニズムに基づいており、URI（CSPまたはUCDNのいずれか）に署名するエンティティと署名されたURIの検証のための公開鍵のみに知られている秘密鍵を常に含んでいます。対称キーを使用すると、同じキーが、署名されたURIに署名するための署名エンティティと、署名されたURIを検証するための検証エンティティの両方で使用されます。使用するキーの種類に関係なく、検証エンティティは、そのキー（パブリックまたは対称キー）を使用して行われたアサーションに信頼を置くことを可能にする方法でキーを取得する必要があります。非対称キーと対称キーを配布するための非常に異なる要件（このドキュメントの範囲外）があります。対称キーのキーディストリビューションには、第三者がキーにアクセスするのを防ぐために機密性が必要です。なぜなら、不正なリクエストのために有効な署名されたURIを生成できるからです。非対称キーのキーディストリビューションは、通常（URIに署名するために使用できないため）公開されているため（URISに署名することができないため）、パブリックキーを公然と配布できるため、機密性を必要としません。
Note: While using a symmetric shared key is supported, it is NOT RECOMMENDED. See the Security Considerations (Section 7) about the limitations of shared keys.
注：対称共有キーを使用することがサポートされていますが、推奨されません。共有キーの制限に関するセキュリティに関する考慮事項（セクション7）を参照してください。
While the URI Signing method defined in this document was primarily created for the purpose of allowing URI Signing in CDNI scenarios, i.e., between a uCDN and a dCDN, there is nothing in the defined URI Signing method that precludes it from being used in a non-CDNI context. As such, the described mechanism could be used in a single-CDN scenario such as shown in Figure 1 in Section 1.2 for example to allow a CSP that uses different CDNs to only have to implement a single URI Signing mechanism.
このドキュメントで定義されているURI署名方法は、主にURIがCDNIシナリオに署名することを許可する目的で作成されましたが、つまり、UCDNとDCDNの間で、定義されたURI署名方法には、それを非で使用することを妨げるものは何もありません。-CDNIコンテキスト。そのため、説明されたメカニズムは、たとえば、セクション1.2の図1に示すような単一CDNシナリオで使用できます。たとえば、異なるCDNを使用するCSPを単一のURI署名メカニズムのみを実装する必要があります。
The concept behind URI Signing is based on embedding a signed JSON Web Token (JWT) [RFC7519] in an HTTP or HTTPS URI [RFC7230] (see Section 2.7 of [RFC7230]). The signed JWT contains a number of claims that can be verified to ensure the UA has legitimate access to the content.
URIの署名の背後にある概念は、HTTPまたはHTTPS URI [RFC7230]に署名されたJSON Webトークン（JWT）[RFC7519]を埋め込むことに基づいています（[RFC7230]のセクション2.7を参照）。署名されたJWTには、UAがコンテンツに合法的にアクセスできるように確認できる多くのクレームが含まれています。
This document specifies the following attribute for embedding a signed JWT in a Target CDN URI or Redirection URI:
このドキュメントは、標的CDN URIまたはリダイレクトURIに署名されたJWTを埋め込むための次の属性を指定します。
URI Signing Package (URISigningPackage): The URI attribute that encapsulates all the URI Signing claims in a signed JWT encoded format. This attribute is exposed in the Signed URI as a path-style parameter or a form-style parameter.
URI署名パッケージ（urisingingpackage）：署名されたJWTエンコード形式のすべてのURI署名請求をカプセル化するURI属性。この属性は、パススタイルのパラメーターまたはフォームスタイルのパラメーターとして署名されたURIに公開されます。
The parameter name of the URI Signing Package Attribute is defined in the CDNI Metadata (Section 4.4). If the CDNI Metadata interface is not used, or does not include a parameter name for the URI Signing Package Attribute, the parameter name can be set by configuration (out of scope of this document).
URI署名パッケージ属性のパラメーター名は、CDNIメタデータ（セクション4.4）で定義されています。CDNIメタデータインターフェイスが使用されていない場合、またはURI署名パッケージ属性のパラメーター名が含まれていない場合、パラメーター名は構成によって設定できます（このドキュメントの範囲外）。
The URI Signing Package will be found by parsing any path-style parameters and form-style parameters looking for a key name matching the URI Signing Package Attribute. Both parameter styles MUST be supported to allow flexibility of operation. The first matching parameter SHOULD be taken to provide the signed JWT, though providing more than one matching key is undefined behavior. Path-style parameters generated in the form indicated by Section 3.2.7 of [RFC6570] and Form-style parameters generated in the form indicated by Sections 3.2.8 and 3.2.9 of [RFC6570] MUST be supported.
URIの署名パッケージは、PATHスタイルのパラメーターとフォームスタイルのパラメーターを解析して、URI Signing Package属性に一致するキー名を探しています。動作の柔軟性を可能にするために、両方のパラメータースタイルをサポートする必要があります。署名されたJWTを提供するために最初のマッチングパラメーターを使用する必要がありますが、複数のマッチングキーを提供することは未定義の動作です。[RFC6570]のセクション3.2.7で示される形式で生成されたパススタイルのパラメーターと[RFC6570]のセクション3.2.8および3.2.9で示される形式で生成されたフォームスタイルのパラメーターをサポートする必要があります。
The following is an example where the URI Signing Package Attribute name is "token" and the signed JWT is "SIGNEDJWT":
以下は、URIの署名パッケージ属性名が「トークン」であり、署名されたJWTが「SignedJWT」である例です。
http://example.com/media/path?come=data&token=SIGNEDJWT&other=data
This section identifies the set of claims that can be used to enforce the CSP distribution policy. New claims can be introduced in the future to extend the distribution policy capabilities.
このセクションでは、CSPディストリビューションポリシーを実施するために使用できる一連のクレームを特定します。将来、新しい請求を導入して、配布ポリシー機能を拡張することができます。
In order to provide distribution policy flexibility, the exact subset of claims used in a given signed JWT is a runtime decision. Claim requirements are defined in the CDNI Metadata (Section 4.4). If the CDNI Metadata interface is not used, or does not include claim requirements, the claim requirements can be set by configuration (out of scope of this document).
配布ポリシーの柔軟性を提供するために、特定の署名されたJWTで使用されるクレームの正確なサブセットは、ランタイム決定です。クレーム要件は、CDNIメタデータ（セクション4.4）で定義されています。CDNIメタデータインターフェイスが使用されていない場合、または請求要件が含まれていない場合、クレーム要件は構成によって設定できます（このドキュメントの範囲外）。
The following claims (where the "JSON Web Token Claims" registry claim name is specified in parentheses below) are used to enforce the distribution policies. All of the listed claims are mandatory to implement in a URI Signing implementation but are not necessarily mandatory to use in a given signed JWT. (The "optional" and "mandatory" identifiers in square brackets refer to whether or not a given claim MUST be present in a URI Signing JWT.)
以下のクレーム（「JSON Webトークンクレーム」レジストリクレーム名は、以下の括弧で指定されています）を使用して、配布ポリシーを実施します。リストされているすべてのクレームは、URIの署名実装で実装するために必須ですが、特定の署名されたJWTで使用することは必ずしも必須ではありません。（四角い括弧内の「オプション」および「必須」識別子は、特定のクレームがjwtに署名することに存在する必要があるかどうかを指します。）
Note: The time on the entities that generate and verify the Signed URI MUST be in sync. In the CDNI case, this means that CSP, uCDN, and dCDN servers need to be time synchronized. It is RECOMMENDED to use NTP [RFC5905] for time synchronization.
注：署名されたURIを生成および検証するエンティティの時間は同期する必要があります。CDNIの場合、これはCSP、UCDN、およびDCDNサーバーを時間同期する必要があることを意味します。時間同期にNTP [RFC5905]を使用することをお勧めします。
Note: See the Security Considerations (Section 7) on the limitations of using an expiration time and Client IP address for distribution policy enforcement.
注：配布ポリシーの実施に有効期限時間とクライアントIPアドレスを使用することの制限に関するセキュリティに関する考慮事項（セクション7）を参照してください。
Issuer (iss) [optional] - The semantics in Section 4.1.1 of [RFC7519] MUST be followed. If this claim is used, it MUST be used to identify the Issuer (signer) of the JWT. In particular, the recipient will have already received, in trusted configuration, a mapping of Issuer name to one or more keys used to sign JWTs and must verify that the JWT was signed by one of those keys. If this claim is used and the CDN verifying the signed JWT does not support Issuer verification, or if the Issuer in the signed JWT does not match the list of known acceptable Issuers, or if the Issuer claim does not match the key used to sign the JWT, the CDN MUST reject the request. If the received signed JWT contains an Issuer claim, then any JWT subsequently generated for CDNI redirection MUST also contain an Issuer claim, and the Issuer value MUST be updated to identify the redirecting CDN. If the received signed JWT does not contain an Issuer claim, an Issuer claim MAY be added to a signed JWT generated for CDNI redirection.
発行者（ISS）[オプション] - [RFC7519]のセクション4.1.1のセマンティクスに従う必要があります。このクレームが使用されている場合、JWTの発行者（署名者）を識別するために使用する必要があります。特に、受信者は、JWTSに署名するために使用される1つ以上のキーへの発行者名のマッピングを信頼できる構成で既に受信しており、JWTがそれらのキーの1つによって署名されたことを確認する必要があります。この請求が使用され、署名されたJWTを検証するCDNが発行者の検証をサポートしない場合、または署名されたJWTの発行者が既知の許容可能な発行者のリストと一致しない場合、または発行者の請求が署名に使用されるキーと一致しない場合JWT、CDNはリクエストを拒否する必要があります。受信した署名JWTに発行者の請求が含まれている場合、その後CDNIリダイレクト用に生成されたJWTには発行者の請求も含まれている必要があり、リダイレクトCDNを特定するために発行者の値を更新する必要があります。受信された署名されたJWTに発行者の請求が含まれていない場合、発行者の請求は、CDNIリダイレクトのために生成された署名されたJWTに追加される場合があります。
Subject (sub) [optional] - The semantics in Section 4.1.2 of [RFC7519] MUST be followed. If this claim is used, it MUST be a JSON Web Encryption (JWE [RFC7516]) Object in compact serialization form, because it contains personally identifiable information. This claim contains information about the Subject (for example, a user or an agent) that MAY be used to verify the signed JWT. If the received signed JWT contains a Subject claim, then any JWT subsequently generated for CDNI redirection MUST also contain a Subject claim, and the Subject value MUST be the same as in the received signed JWT. A signed JWT generated for CDNI redirection MUST NOT add a Subject claim if no Subject claim existed in the received signed JWT.
件名（sub）[オプション] - [RFC7519]のセクション4.1.2のセマンティクスに従う必要があります。このクレームが使用される場合、個人識別可能な情報が含まれているため、コンパクトなシリアル化形式のJSON Web暗号化（JWE [RFC7516]）オブジェクトでなければなりません。このクレームには、署名されたJWTを検証するために使用できる被験者（ユーザーまたはエージェントなど）に関する情報が含まれています。受信した署名されたJWTにサブジェクトクレームが含まれている場合、その後CDNIリダイレクト用に生成されたJWTには被験者のクレームも含まれている必要があり、被験者値は受信した署名済みJWTと同じでなければなりません。CDNIリダイレクト用に生成された署名されたJWTは、受信した署名されたJWTに被験者の申し立てが存在しなかった場合、被験者の申し立てを追加してはなりません。
Audience (aud) [optional] - The semantics in Section 4.1.3 of [RFC7519] MUST be followed. This claim is used to ensure that the CDN verifying the JWT is an intended recipient of the request. The claim MUST contain an identity belonging to the chain of entities involved in processing the request (e.g., identifying the CSP or any CDN in the chain) that the recipient is configured to use for the processing of this request. A CDN MAY modify the claim as long it can generate a valid signature.
聴衆（aud）[オプション] - [RFC7519]のセクション4.1.3のセマンティクスに従う必要があります。このクレームは、JWTを検証するCDNがリクエストの意図された受信者であることを確認するために使用されます。請求には、受信者がこのリクエストの処理に使用するように構成されているリクエストの処理に関与するエンティティのチェーン（たとえば、チェーン内のCSPまたはCDNの識別）に属するIDが含まれている必要があります。CDNは、有効な署名を生成できる限り、クレームを変更する場合があります。
Expiry Time (exp) [optional] - The semantics in Section 4.1.4 of [RFC7519] MUST be followed, though URI Signing implementations MUST NOT allow for any time-synchronization "leeway". If this claim is used and the CDN verifying the signed JWT does not support Expiry Time verification, or if the Expiry Time in the signed JWT corresponds to a time equal to or earlier than the time of the content request, the CDN MUST reject the request. If the received signed JWT contains an Expiry Time claim, then any JWT subsequently generated for CDNI redirection MUST also contain an Expiry Time claim, and the Expiry Time value MUST be the same as in the received signed JWT. A signed JWT generated for CDNI redirection MUST NOT add an Expiry Time claim if no Expiry Time claim existed in the received signed JWT.
有効期限（EXP）[オプション] - [RFC7519]のセクション4.1.4のセマンティクスに従う必要がありますが、URI署名の実装は、時刻同期を許可してはなりません。このクレームが使用され、署名されたJWTを検証するCDNが有効期限の確認をサポートしない場合、または署名されたJWTの有効期限がコンテンツ要求の時間よりも等しい時間以前に対応する場合、CDNはリクエストを拒否する必要があります。受信した署名済みJWTに有効期限の請求が含まれている場合、その後CDNIリダイレクト用に生成されたJWTには有効期限の請求も含まれている必要があり、有効期限の値は受信した署名JWTと同じでなければなりません。CDNIリダイレクト用に生成された署名されたJWTは、受信した署名されたJWTに有効期限の請求が存在しなかった場合、有効期限の請求を追加してはなりません。
Not Before (nbf) [optional] - The semantics in Section 4.1.5 of [RFC7519] MUST be followed, though URI Signing implementations MUST NOT allow for any time-synchronization "leeway". If this claim is used and the CDN verifying the signed JWT does not support Not Before time verification, or if the Not Before time in the signed JWT corresponds to a time later than the time of the content request, the CDN MUST reject the request. If the received signed JWT contains a Not Before time claim, then any JWT subsequently generated for CDNI redirection MUST also contain a Not Before time claim, and the Not Before time value MUST be the same as in the received signed JWT. A signed JWT generated for CDNI redirection MUST NOT add a Not Before time claim if no Not Before time claim existed in the received signed JWT.
以前（NBF）[オプション] - [RFC7519]のセクション4.1.5のセマンティクスに従う必要がありますが、URI署名の実装は、時刻同期を許可してはなりません。このクレームが使用され、署名されたJWTを検証するCDNが時間の検証前にサポートされない場合、または署名されたJWTの時間前の時間がコンテンツリクエストの時間よりも遅れている場合、CDNはリクエストを拒否する必要があります。受信された署名されたJWTに時間の前に請求が含まれている場合、その後CDNIリダイレクト用に生成されたJWTには、時間前の請求も含まれていなければならず、時間前には符号付きJWTと同じでなければなりません。CDNIリダイレクト用に生成された署名されたJWTは、受信された署名されたJWTに時間の請求が存在しなかった場合、時間の前に請求前に請求しないことを追加してはなりません。
Issued At (iat) [optional] - The semantics in Section 4.1.6 of [RFC7519] MUST be followed. If the received signed JWT contains an Issued At claim, then any JWT subsequently generated for CDNI redirection MUST also contain an Issued At claim, and the Issued At value MUST be updated to identify the time the new JWT was generated. If the received signed JWT does not contain an Issued At claim, an Issued At claim MAY be added to a signed JWT generated for CDNI redirection.
（IAT）で発行された[オプション] - [RFC7519]のセクション4.1.6のセマンティクスに従う必要があります。受信した署名JWTに発行された請求が含まれている場合、その後CDNIリダイレクト用に生成されたJWTには発行された請求も含まれている必要があり、新しいJWTが生成された時間を特定するために発行された値を更新する必要があります。受信した署名されたJWTに発行された請求が含まれていない場合、発行された請求は、CDNIリダイレクトのために生成された署名されたJWTに追加される場合があります。
JWT ID (jti) [optional] - The semantics in Section 4.1.7 of [RFC7519] MUST be followed. A JWT ID can be used to prevent replay attacks if the CDN stores a list of all previously used values and verifies that the value in the current JWT has never been used before. If the signed JWT contains a JWT ID claim and the CDN verifying the signed JWT either does not support JWT ID storage or has previously seen the value used in a request for the same content, then the CDN MUST reject the request. If the received signed JWT contains a JWT ID claim, then any JWT subsequently generated for CDNI redirection MUST also contain a JWT ID claim, and the value MUST be the same as in the received signed JWT. If the received signed JWT does not contain a JWT ID claim, a JWT ID claim MUST NOT be added to a signed JWT generated for CDNI redirection. Sizing of the JWT ID is application dependent given the desired security constraints.
JWT ID（JTI）[オプション] - [RFC7519]のセクション4.1.7のセマンティクスに従う必要があります。JWT IDを使用して、CDNが以前に使用されたすべての値のリストを保存し、現在のJWTの値がこれまで使用されていないことを確認する場合、リプレイ攻撃を防ぐことができます。署名されたJWTにJWT IDクレームが含まれており、CDNに署名されたJWTがJWT IDストレージをサポートしていないか、以前に同じコンテンツのリクエストで使用されている値を見たことがある場合、CDNはリクエストを拒否する必要があります。受信した署名済みのJWTにJWT IDクレームが含まれている場合、その後CDNIリダイレクト用に生成されたJWTにはJWT IDクレームも含まれている必要があり、値は受信された署名JWTと同じでなければなりません。受信された署名されたJWTにJWT IDクレームが含まれていない場合、JWT IDクレームをCDNIリダイレクト用に生成した署名済みJWTに追加してはなりません。JWT IDのサイジングは、目的のセキュリティ制約を考慮して、アプリケーションに依存します。
CDNI Claim Set Version (cdniv) [optional] - The CDNI Claim Set Version (cdniv) claim provides a means within a signed JWT to tie the claim set to a specific version of this specification. The cdniv claim is intended to allow changes in and facilitate upgrades across specifications. The type is a JSON integer and the value MUST be set to "1" for this version of the specification. In the absence of this claim, the value is assumed to be "1". For future versions, this claim will be mandatory. Implementations MUST reject signed JWTs with unsupported CDNI Claim Set versions.
CDNIクレームセットバージョン（CDNIV）[オプション] - CDNIクレームセットバージョン（CDNIV）クレームは、署名されたJWT内の手段を提供し、この仕様の特定のバージョンにクレームセットを結びます。CDNIVクレームは、仕様全体のアップグレードを変更し、促進することを目的としています。タイプはJSON整数であり、このバージョンの仕様の値は「1」に設定する必要があります。この主張がない場合、値は「1」であると想定されます。将来のバージョンの場合、この主張は必須です。実装は、サポートされていないCDNIクレームセットバージョンで署名されたJWTを拒否する必要があります。
CDNI Critical Claims Set (cdnicrit) [optional] - The CDNI Critical Claims Set (cdnicrit) claim indicates that extensions to this specification are being used that MUST be understood and processed. Its value is a comma-separated listing of claims in the Signed JWT that use those extensions. If any of the listed extension claims are not understood and supported by the recipient, then the Signed JWT MUST be rejected. Producers MUST NOT include claim names defined by this specification, duplicate names, or names that do not occur as claim names within the Signed JWT in the cdnicrit list. Producers MUST NOT use the empty list "" as the cdnicrit value. Recipients MAY consider the Signed JWT to be invalid if the cdnicrit list contains any claim names defined by this specification or if any other constraints on its use are violated. This claim MUST be understood and processed by all implementations.
CDNIクリティカルクレームセット（CDNICRIT）[オプション] - CDNIクリティカルクレームセット（CDNICRIT）クレームは、この仕様の拡張が使用され、理解して処理されなければならないことを示しています。その価値は、それらの拡張機能を使用する署名されたJWTの請求のコンマ分離されたリストです。リストされている拡張請求のいずれかが受信者によって理解され、サポートされていない場合、署名されたJWTは拒否されなければなりません。プロデューサーは、この仕様、重複した名前、またはcdnicritリストの署名されたJWT内のクレーム名として発生しない名前で定義された請求名を含めてはなりません。プロデューサーは、空のリスト ""をcdnicrit値として使用してはなりません。受信者は、CDNICRITリストにこの仕様によって定義されたクレーム名、またはその使用に関する他の制約が違反されている場合、署名されたJWTが無効であると考えることができます。このクレームは、すべての実装によって理解および処理されなければなりません。
Client IP Address (cdniip) [optional] - The Client IP Address (cdniip) claim holds an IP address or IP prefix for which the Signed URI is valid. This is represented in CIDR notation with dotted decimal format for IPv4 addresses [RFC0791] or canonical text representation for IPv6 addresses [RFC5952]. The request MUST be rejected if sourced from a client outside the specified IP range. Since the Client IP is considered personally identifiable information, this field MUST be a JSON Web Encryption (JWE [RFC7516]) Object in compact serialization form. If the CDN verifying the signed JWT does not support Client IP verification, or if the Client IP in the signed JWT does not match the source IP address in the content request, the CDN MUST reject the request. The type of this claim is a JSON string that contains the JWE. If the received signed JWT contains a Client IP claim, then any JWT subsequently generated for CDNI redirection MUST also contain a Client IP claim, and the Client IP value MUST be the same as in the received signed JWT. A signed JWT generated for CDNI redirection MUST NOT add a Client IP claim if no Client IP claim existed in the received signed JWT.
クライアントIPアドレス（CDNIIP）[オプション] - クライアントIPアドレス（CDNIIP）クレームには、署名されたURIが有効なIPアドレスまたはIPプレフィックスが保持されます。これは、IPv4アドレス[RFC0791]またはIPv6アドレス[RFC5952]の標準的なテキスト表現の点線の小数形式でCIDR表記で表されます。指定されたIP範囲外のクライアントから調達した場合、リクエストは拒否する必要があります。クライアントIPは個人識別可能な情報と見なされるため、このフィールドはコンパクトなシリアル化形式のJSON Web暗号化（JWE [RFC7516]）オブジェクトでなければなりません。署名されたJWTを検証するCDNがクライアントIP検証をサポートしていない場合、または署名されたJWTのクライアントIPがコンテンツリクエストのソースIPアドレスと一致しない場合、CDNはリクエストを拒否する必要があります。この主張のタイプは、JWEを含むJSON文字列です。受信した署名済みJWTにクライアントIPクレームが含まれている場合、その後CDNIリダイレクト用に生成されたJWTにはクライアントIP請求も含まれている必要があり、クライアントIP値は受信した署名されたJWTと同じでなければなりません。 CDNIリダイレクト用に生成された署名されたJWTは、受信した署名されたJWTにクライアントIPクレームが存在しなかった場合、クライアントIPクレームを追加してはなりません。
It should be noted that use of this claim can cause issues, for example, in situations with dual-stack IPv4 and IPv6 networks, MPTCP, QUIC, and mobile clients switching from Wi-Fi to Cellular networks where the client's source address can change, even between address families. This claim exists mainly for legacy feature parity reasons; therefore, use of this claim should be done judiciously. An example of a reasonable use case would be making a signed JWT for an internal preview of an asset where the end consumer understands that they must be originated from the same IP for the entirety of the session. Using this claim at large is NOT RECOMMENDED.
このクレームの使用は、たとえば、デュアルスタックIPv4およびIPv6ネットワーク、MPTCP、QUIC、およびクライアントのソースアドレスが変更できるセルラーネットワークに切り替えるモバイルクライアントの状況で問題を引き起こす可能性があることに注意する必要があります。住所家族の間でさえ。この主張は、主にレガシー機能のパリティの理由で存在します。したがって、この請求の使用は慎重に行う必要があります。合理的なユースケースの例は、最終消費者がセッション全体で同じIPから発信する必要があることを理解している資産の内部プレビューのために署名されたJWTを作成することです。この主張を一般的に使用することは推奨されません。
URI Container (cdniuc) [mandatory] - The URI Container (cdniuc) holds the URI representation before a URI Signing Package is added. This representation can take one of several forms detailed in Section 2.1.15. If the URI Container used in the signed JWT does not match the URI of the content request, the CDN verifying the signed JWT MUST reject the request. When comparing the URI, the percent encoded form as defined in Section 2.1 of [RFC3986] MUST be used. When redirecting a URI, the CDN generating the new signed JWT MAY change the URI Container to comport with the URI being used in the redirection.
URIコンテナ（CDNIUC）[必須] - URI署名パッケージが追加される前に、URIコンテナ（CDNIUC）がURI表現を保持します。この表現は、セクション2.1.15で詳述されているいくつかのフォームの1つを取得できます。署名されたJWTで使用されているURIコンテナがコンテンツリクエストのURIと一致しない場合、署名されたJWTを検証するCDNはリクエストを拒否する必要があります。URIを比較する場合、[RFC3986]のセクション2.1で定義されているエンコードフォームの割合を使用する必要があります。URIをリダイレクトすると、新しい署名されたJWTを生成するCDNは、URIコンテナを変更して、リダイレクトで使用されるURIとコンパートする可能性があります。
CDNI Expiration Time Setting (cdniets) [optional] - The CDNI Expiration Time Setting (cdniets) claim provides a means for setting the value of the Expiry Time (exp) claim when generating a subsequent signed JWT in Signed Token Renewal. Its type is a JSON numeric value. It denotes the number of seconds to be added to the time at which the JWT is verified that gives the value of the Expiry Time (exp) claim of the next signed JWT. The CDNI Expiration Time Setting (cdniets) SHOULD NOT be used when not using Signed Token Renewal and MUST be present when using Signed Token Renewal.
CDNI有効期限設定（CDNIETS）[オプション] - CDNI有効期限設定（CDNIETS）クレームは、署名されたトークン更新でその後の署名JWTを生成するときに有効期限（EXP）クレームの値を設定する手段を提供します。そのタイプはJSON数値です。これは、次の署名されたJWTの有効期限（EXP）クレームの値を与えるJWTが検証された時間に追加される秒数を示します。署名済みのトークン更新を使用していない場合は、CDNIの有効期限設定（CDNIETS）を使用しないでください。署名されたトークン更新を使用する場合は存在する必要があります。
CDNI Signed Token Transport (cdnistt) [optional] - The CDNI Signed Token Transport (cdnistt) claim provides a means of signaling the method through which a new signed JWT is transported from the CDN to the UA and vice versa for the purpose of Signed Token Renewal. Its type is a JSON integer. Values for this claim are defined in Section 6.5. If using this claim, you MUST also specify a CDNI Expiration Time Setting (cdniets) as noted above.
CDNI署名トークントランスポート（CDNISTT）[オプション] - CDNI署名されたトークントランスポート（CDNISTT）クレームは、署名されたトークンの目的でCDNからUAへ、またはその逆の新しい署名JWTがCDNに運ばれる方法を通知する手段を提供します。リニューアル。そのタイプはJSON整数です。このクレームの値は、セクション6.5で定義されています。このクレームを使用する場合は、上記のようにCDNI有効期限設定（CDNIETS）も指定する必要があります。
CDNI Signed Token Depth (cdnistd) [optional] - The CDNI Signed Token Depth (cdnistd) claim is used to associate a subsequent signed JWT, generated as the result of a CDNI Signed Token Transport claim, with a specific URI subset. Its type is a JSON integer. Signed JWTs MUST NOT use a negative value for the CDNI Signed Token Depth claim.
CDNI署名トークン深さ（cdnistD）[オプション] - CDNI署名されたトークン深度（CDNISTD）クレームは、特定のURIサブセットを使用して、CDNI署名されたトークン輸送クレームの結果として生成された後続の署名JWTを関連付けるために使用されます。そのタイプはJSON整数です。署名されたJWTSは、CDNI署名されたトークン深度請求に負の値を使用してはなりません。
If the transport used for Signed Token Transport allows the CDN to associate the path component of a URI with tokens (e.g., an HTTP Cookie Path as described in Section 4.1.2.4 of [RFC6265]), the CDNI Signed Token Depth value is the number of path segments that should be considered significant for this association. A CDNI Signed Token Depth of zero means that the client SHOULD be directed to return the token with requests for any path. If the CDNI Signed Token Depth is greater than zero, then the CDN SHOULD send the client a token to return for future requests wherein the first CDNI Signed Token Depth segments of the path match the first CDNI Signed Token Depth segments of the Signed URI path. This matching MUST use the URI with the token removed, as specified in Section 2.1.15.
署名されたトークントランスポートに使用されるトランスポートにより、CDNがURIのパスコンポーネントをトークンに関連付けることができる場合（たとえば、[RFC6265]のセクション4.1.2.4で説明されているHTTP Cookieパス）、CDNI署名されたトークン深度値は数値ですこの関連性にとって重要と見なされるべきパスセグメントの。cdniに署名されたトークンの深さゼロは、クライアントがパスのリクエストでトークンを返すように指示する必要があることを意味します。CDNI署名されたトークンの深さがゼロより大きい場合、CDNはクライアントにトークンを送信して将来の要求に戻ります。最初のCDNIがパスの署名されたトークン深度セグメントは、署名されたURIパスの最初のCDNI署名されたトークン深度セグメントと一致します。このマッチングは、セクション2.1.15で指定されているように、トークンを削除した状態でURIを使用する必要があります。
If the URI path to match contains fewer segments than the CDNI Signed Token Depth claim, a signed JWT MUST NOT be generated for the purposes of Signed Token Renewal. If the CDNI Signed Token Depth claim is omitted, it means the same thing as if its value were zero. If the received signed JWT contains a CDNI Signed Token Depth claim, then any JWT subsequently generated for CDNI redirection or Signed Token Transport MUST also contain a CDNI Signed Token Depth claim, and the value MUST be the same as in the received signed JWT.
一致するURIパスにCDNI署名されたトークン深度クレームよりも少ないセグメントが含まれている場合、署名されたJWTを署名されたトークン更新の目的のために生成してはなりません。CDNIに署名されたトークン深度クレームが省略されている場合、それはその値がゼロであると同じことを意味します。受信した署名JWTにCDNI署名されたトークン深度クレームが含まれている場合、その後CDNIリダイレクトまたは署名されたトークントランスポートのために生成されたJWTには、CDNI署名されたトークン深度クレームも含まれている必要があり、値は受信された署名されたJWTと同じでなければなりません。
The URI Container (cdniuc) claim takes one of the following forms: 'hash:' or 'regex:'. More forms may be added in the future to extend the capabilities.
URIコンテナ（CDNIUC）のクレームには、次の形式のいずれかが掲載されています。将来、より多くのフォームが追加されて、機能を拡張することができます。
Before comparing a URI with contents of this container, the following steps MUST be performed:
URIをこのコンテナの内容と比較する前に、次の手順を実行する必要があります。
* Prior to verification, remove the signed JWT from the URI. This removal is only for the purpose of determining if the URI matches; all other purposes will use the original URI. If the signed JWT is terminated by anything other than a sub-delimiter (as defined in Section 2.2 of [RFC3986]), everything from the reserved character (as defined in Section 2.2 of [RFC3986]) that precedes the URI Signing Package Attribute to the last character of the signed JWT will be removed, inclusive. Otherwise, everything from the first character of the URI Signing Package Attribute to the sub-delimiter that terminates the signed JWT will be removed, inclusive.
* 確認の前に、署名されたJWTをURIから削除します。この削除は、URIが一致するかどうかを判断する目的のみです。他のすべての目的は、元のURIを使用します。署名されたJWTがサブディリミッター以外のもの（[RFC3986]のセクション2.2で定義されている）以外のものによって終了した場合、予約された文字（[RFC3986]のセクション2.2で定義されている）からのすべてが、URIの署名パッケージに先行するものです。署名されたJWTの最後のキャラクターは、包括的に削除されます。それ以外の場合、URI Signing Package属性の最初の文字から、署名されたJWTを終了するサブデリミッターまですべてが削除されます。
* Normalize the URI according to Section 2.7.3 of [RFC7230] and Sections 6.2.2 and 6.2.3 of [RFC3986]. This applies to both generation and verification of the signed JWT.
* [RFC7230]のセクション2.7.3および[RFC3986]のセクション6.2.2および6.2.3に従ってURIを正規化します。これは、署名されたJWTの生成と検証の両方に適用されます。
Prefixed with 'hash:', this string is a URL Segment form (Section 5 of [RFC6920]) of the URI.
'hash：'が付いた接頭辞、この文字列は、URIのURLセグメントフォーム（[RFC6920]のセクション5）です。
Prefixed with 'regex:', this string is any regular expression compatible with POSIX (Section 9 of [POSIX.1]) Extended Regular Expression used to match against the requested URI. These regular expressions MUST be evaluated in the POSIX locale (Section 7.2 of [POSIX.1]).
「Regex：」が付いた接頭辞、この文字列は、要求されたURIと一致するために使用されるPOSIX（[POSIX.1]のセクション9）の正規表現と互換性のある正規表現です。これらの正規表現は、POSIXロケール（[POSIX.1]のセクション7.2）で評価する必要があります。
Note: Because '\' has special meaning in JSON [RFC8259] as the escape character within JSON strings, the regular expression character '\' MUST be escaped as '\\'.
注：「\」はJSON [RFC8259]で特別な意味を持っているため、JSON文字列内の脱出キャラクターとして、正規表現文字「\」は「\\」として逃げる必要があります。
An example of a 'regex:' is the following:
「Regex：」の例は次のとおりです。
[^:]*\\://[^/]*/dir/content/quality_[^/]*/segment.{3}\\.mp4(\\?.*)?
Note: Due to computational complexity of executing arbitrary regular expressions, it is RECOMMENDED to only execute after verifying the JWT to ensure its authenticity.
注：任意の正規表現を実行することの計算の複雑さにより、JWTを検証してその信頼性を確保する後にのみ実行することをお勧めします。
The header of the JWT MAY be passed via the CDNI Metadata interface instead of being included in the URISigningPackage. The header value MUST be transmitted in the serialized encoded form and prepended to the JWT payload and signature passed in the URISigningPackage prior to verification. This reduces the size of the signed JWT token.
JWTのヘッダーは、urisingingPackageに含まれる代わりに、CDNIメタデータインターフェイスを介して渡される場合があります。ヘッダー値は、シリアル化されたエンコードされたフォームに送信され、検証前にurisIngingpackageで渡されたJWTペイロードと署名に加えられる必要があります。これにより、署名されたJWTトークンのサイズが削減されます。
For content that is delivered via HTTP in a segmented fashion, such as MPEG-DASH [MPEG-DASH] or HTTP Live Streaming (HLS) [RFC8216], special provisions need to be made in order to ensure URI Signing can be applied. In general, segmented protocols work by breaking large objects (e.g., videos) into a sequence of small independent segments. Such segments are then referenced by a separate manifest file, which either includes a list of URLs to the segments or specifies an algorithm through which a User Agent can construct the URLs to the segments. Requests for segments therefore originate from the manifest file and, unless the URLs in the manifest file point to the CSP, are not subjected to redirection and URI Signing. This opens up a vulnerability to malicious User Agents sharing the manifest file and deep linking to the segments.
MPEG-DASH [MPEG-DASH]やHTTPライブストリーミング（HLS）[RFC8216]などのセグメント化された方法でHTTPを介して配信されるコンテンツについては、URIの署名を確実に適用できるようにするために特別な規定を作成する必要があります。一般に、セグメント化されたプロトコルは、大きなオブジェクト（ビデオ）を小さな独立したセグメントのシーケンスに分割することにより機能します。そのようなセグメントは、セグメントへのURLのリストを含むか、ユーザーエージェントがURLをセグメントに作成できるアルゴリズムを指定する別のマニフェストファイルによって参照されます。したがって、セグメントのリクエストはマニフェストファイルに由来し、マニフェストファイルのURLがCSPを指している場合を除き、リダイレクトとURIの署名を受けない限り。これにより、マニフェストファイルを共有し、セグメントに深くリンクする悪意のあるユーザーエージェントに対する脆弱性が開きます。
One method for dealing with this vulnerability would be to include, in the manifest itself, Signed URIs that point to the individual segments. There exist a number of issues with that approach. First, it requires the CDN delivering the manifest to rewrite the manifest file for each User Agent, which would require the CDN to be aware of the exact segmentation protocol used. Secondly, it could also require the expiration time of the Signed URIs to be valid for an extended duration if the content described by the manifest is meant to be consumed in real time. For instance, if the manifest file were to contain a segmented video stream of more than 30 minutes in length, Signed URIs would require to be valid for at least 30 minutes, thereby reducing their effectiveness and that of the URI Signing mechanism in general. For a more detailed analysis of how segmented protocols such as HTTP Adaptive Streaming protocols affect CDNI, see Models for HTTP-Adaptive-Streaming-Aware Content Distribution Network Interconnection (CDNI) [RFC6983].
この脆弱性に対処するための1つの方法は、マニフェスト自体に、個々のセグメントを指すウリと署名することです。そのアプローチには多くの問題があります。まず、マニフェストを配信するCDNが各ユーザーエージェントのマニフェストファイルを書き換える必要があります。これにより、CDNは使用される正確なセグメンテーションプロトコルを認識する必要があります。第二に、マニフェストによって説明されているコンテンツがリアルタイムで消費されることを意図している場合、署名されたURIの有効期限が長期間有効であることも必要になる可能性があります。たとえば、マニフェストファイルに長さが30分以上のセグメント化されたビデオストリームが含まれている場合、署名されたURISは少なくとも30分間有効である必要があり、それにより、それらの効果とURI署名メカニズムの有効性を低下させます。 HTTP適応ストリーミングプロトコルなどのセグメント化されたプロトコルがCDNIにどのように影響するかをより詳細に分析するには、HTTP適応性ストリーミングアウェアコンテンツ配信ネットワーク相互接続（CDNI）[RFC6983]のモデルを参照してください。
The method described in this section allows CDNs to use URI Signing for segmented content without having to include the Signed URIs in the manifest files themselves.
このセクションで説明する方法により、CDNは、マニフェストファイル自体に署名されたURIを含めることなく、セグメント化されたコンテンツのURI署名を使用できます。
In order to allow for effective access control of segmented content, the URI Signing mechanism defined in this section is based on a method through which subsequent segment requests can be linked together. As part of the JWT verification procedure, the CDN can generate a new signed JWT that the UA can use to do a subsequent request. More specifically, whenever a UA successfully retrieves a segment, it receives, in the HTTP 2xx Successful message, a signed JWT that it can use whenever it requests the next segment. As long as each successive signed JWT is correctly verified before a new one is generated, the model is not broken, and the User Agent can successfully retrieve additional segments. Given the fact that with segmented protocols it is usually not possible to determine a priori which segment will be requested next (i.e., to allow for seeking within the content and for switching to a different representation), the Signed Token Renewal uses the URI Regular Expression Container scoping mechanisms in the URI Container (cdniuc) claim to allow a signed JWT to be valid for more than one URL.
セグメント化されたコンテンツの効果的なアクセス制御を可能にするために、このセクションで定義されているURI署名メカニズムは、後続のセグメント要求をリンクできる方法に基づいています。 JWT検証手順の一部として、CDNは、UAが後続の要求を行うために使用できる新しい署名されたJWTを生成できます。より具体的には、UAがセグメントを正常に取得するたびに、HTTP 2XX成功したメッセージで、次のセグメントを要求するたびに使用できる署名されたJWTを受信します。連続した署名された各JWTが新しいものを生成する前に正しく検証されている限り、モデルは破損しておらず、ユーザーエージェントは追加のセグメントを正常に取得できます。セグメント化されたプロトコルでは、通常、どのセグメントが次に要求されるか（つまり、コンテンツ内を探すことができ、別の表現に切り替えることができる）を決定することは通常不可能であるという事実を考えると、署名されたトークンの更新はURI正規表現を使用しますURIコンテナ（CDNIUC）のコンテナスコーピングメカニズムは、署名されたJWTが複数のURLに対して有効であると主張しています。
In order for this renewal of signed JWTs to work, it is necessary for a UA to extract the signed JWT from the HTTP 2xx Successful message of an earlier request and use it to retrieve the next segment. The exact mechanism by which the client does this is outside the scope of this document. However, in order to also support legacy UAs that do not include any specific provisions for the handling of signed JWTs, Section 3.3 defines a mechanism using HTTP Cookies [RFC6265] that allows such UAs to support the concept of renewing signed JWTs without requiring any additional UA support.
署名されたJWTSのこの更新が機能するためには、UAが以前のリクエストのHTTP 2XX成功したメッセージから署名されたJWTを抽出し、それを使用して次のセグメントを取得する必要があります。クライアントがこれを行う正確なメカニズムは、このドキュメントの範囲外です。ただし、署名されたJWTSの処理に関する特定の規定を含めないレガシーUASもサポートするために、セクション3.3は、追加のUASが追加の追加を必要とせずに署名されたJWTSを更新する概念をサポートできるHTTP Cookie [RFC6265]を使用してメカニズムを定義します。UAサポート。
The cdnistt claim (Section 2.1.13) and cdniets claim (Section 2.1.12) MUST both be present for Signed Token Renewal. cdnistt MAY be set to a value of '0' to mean no Signed Token Renewal, but there still MUST be a corresponding cdniets that verifies as a JSON number. However, if use of Signed Token Renewal is not desired, it is RECOMMENDED to simply omit both.
cdnisttクレーム（セクション2.1.13）およびcdnietsクレーム（セクション2.1.12）は、両方とも署名されたトークン更新のために存在する必要があります。cdnisttは、署名されたトークンの更新がないことを意味するように「0」の値に設定される場合がありますが、JSON番号として検証する対応するcdnietsが必要です。ただし、署名されたトークン更新の使用が望まれない場合は、単に両方を省略することをお勧めします。
This section assumes the value of the CDNI Signed Token Transport (cdnistt) claim has been set to 1.
このセクションでは、CDNI署名されたトークントランスポート（CDNISTT）の請求の値が1に設定されていると想定しています。
When using the Signed Token Renewal mechanism, the signed JWT is transported to the UA via a 'URISigningPackage' cookie added to the HTTP 2xx Successful message along with the content being returned to the UA, or to the HTTP 3xx Redirection message in case the UA is redirected to a different server.
署名済みのトークン更新機構を使用すると、署名されたJWTは、HTTP 2xx成功したメッセージに追加された「urisigningingpackage」Cookieを介してUAに輸送されます。別のサーバーにリダイレクトされます。
For security purposes, the use of cross-domain cookies is not supported in some application environments. As a result, the Cookie-based method for transport of the Signed Token described in Section 3.3 might break if used in combination with an HTTP 3xx Redirection response where the target URL is in a different domain. In such scenarios, Signed Token Renewal of a signed JWT SHOULD be communicated via the query string instead, in a similar fashion to how regular signed JWTs (outside of Signed Token Renewal) are communicated. Note the value of the CDNI Signed Token Transport (cdnistt) claim MUST be set to 2.
セキュリティの目的では、クロスドメインCookieの使用は、一部のアプリケーション環境ではサポートされていません。その結果、セクション3.3で説明されている署名されたトークンの輸送のためのCookieベースの方法は、ターゲットURLが別のドメインにあるHTTP 3XXリダイレクト応答と組み合わせて使用すると壊れる可能性があります。このようなシナリオでは、署名されたJWTの署名されたトークン更新は、代わりにクエリ文字列を介して通信する必要があります。注CDNI署名されたトークントランスポート（CDNISTT）クレームの値は2に設定する必要があります。
Note that the process described herein only works in cases where both the manifest file and segments constituting the segmented content are delivered from the same domain. In other words, any redirection between different domains needs to be carried out while retrieving the manifest file.
ここで説明するプロセスは、セグメント化されたコンテンツを構成するマニフェストファイルとセグメントの両方が同じドメインから配信される場合にのみ機能することに注意してください。言い換えれば、マニフェストファイルを取得する際に、異なるドメイン間のリダイレクトを実行する必要があります。
Some of the CDNI Interfaces need enhancements to support URI Signing. A dCDN that supports URI Signing needs to be able to advertise this capability to the uCDN. The uCDN needs to select a dCDN based on such capability when the CSP requires access control to enforce its distribution policy via URI Signing. Also, the uCDN needs to be able to distribute via the CDNI Metadata interface the information necessary to allow the dCDN to verify a Signed URI. Events that pertain to URI Signing (e.g., request denial or delivery after an access authorization decision has been made) need to be included in the logs communicated through the CDNI Logging interface.
一部のCDNIインターフェイスには、URIの署名をサポートするために強化が必要です。URIの署名をサポートするDCDNは、この機能をUCDNに宣伝できる必要があります。URIの署名を介して配布ポリシーを実施するためにCSPがアクセス制御を必要とする場合、UCDNはそのような機能に基づいてDCDNを選択する必要があります。また、UCDNは、DCDNが署名されたURIを検証できるようにするために必要な情報をCDNIメタデータインターフェースを介して配布できる必要があります。URIの署名に関連するイベント（たとえば、アクセス許可決定が行われた後の要求の拒否または配信が行われた）は、CDNIロギングインターフェイスを介して伝えられたログに含める必要があります。
URI Signing has no impact on this interface.
URIの署名は、このインターフェイスに影響を与えません。
The CDNI Request Routing: Footprint and Capabilities Semantics document [RFC8008] defines support for advertising CDNI Metadata capabilities via CDNI Payload Type. The CDNI Payload Type registered in Section 6.1 can be used for capability advertisement.
CDNIリクエストルーティング：フットプリントおよび機能セマンティクスドキュメント[RFC8008]は、CDNIペイロードタイプを介してCDNIメタデータ機能の広告のサポートを定義します。セクション6.1に登録されているCDNIペイロードタイプは、機能広告に使用できます。
The CDNI Request Routing Redirection Interface [RFC7975] describes the recursive request redirection method. For URI Signing, the uCDN signs the URI provided by the dCDN. URI Signing therefore has no impact on this interface.
CDNIリクエストルーティングリダイレクトインターフェイス[RFC7975]は、再帰要求リダイレクト法を説明しています。URI署名の場合、UCDNはDCDNによって提供されたURIに署名します。したがって、URIの署名はこのインターフェイスに影響を与えません。
The CDNI Metadata Interface [RFC8006] describes the CDNI Metadata distribution needed to enable content acquisition and delivery. For URI Signing, a new CDNI Metadata object is specified.
CDNIメタデータインターフェイス[RFC8006]は、コンテンツの獲得と配信を有効にするために必要なCDNIメタデータ分布を説明しています。URI署名の場合、新しいCDNIメタデータオブジェクトが指定されています。
The UriSigning Metadata object contains information to enable URI Signing and verification by a dCDN. The UriSigning properties are defined below.
UrisIngingメタデータオブジェクトには、DCDNによるURIの署名と検証を可能にする情報が含まれています。urisigningプロパティは以下に定義されています。
Property: enforce
プロパティ：実施
Description: URI Signing enforcement flag. Specifically, this flag indicates if the access to content is subject to URI Signing. URI Signing requires the dCDN to ensure that the URI is signed and verified before delivering content. Otherwise, the dCDN does not perform verification, regardless of whether or not the URI is signed.
説明：URI署名執行フラグ。具体的には、このフラグは、コンテンツへのアクセスがURIの署名の対象かどうかを示します。URIの署名では、コンテンツを配信する前にURIが署名および検証されていることを確認するためにDCDNが必要です。それ以外の場合、URIが署名されているかどうかに関係なく、DCDNは検証を実行しません。
Type: Boolean
タイプ：Boolean
Mandatory-to-Specify: No. The default is true.
必須の仕様：いいえ。デフォルトはtrueです。
Property: issuers
プロパティ：発行者
Description: A list of valid Issuers against which the Issuer claim in the signed JWT may be cross-referenced.
説明：署名されたJWTで発行者が請求する有効な発行者のリストは相互参照される可能性があります。
Type: Array of Strings
タイプ：文字列の配列
Mandatory-to-Specify: No. The default is an empty list. An empty list means that any Issuer in the trusted key store of Issuers is acceptable.
必須の仕様：いいえ。デフォルトは空のリストです。空のリストとは、発行者の信頼できるキーストアの発行者が受け入れられることを意味します。
Property: package-attribute
プロパティ：Package-Attribute
Description: The attribute name to use for the URI Signing Package.
説明：URI署名パッケージに使用する属性名。
Type: String
タイプ：文字列
Mandatory-to-Specify: No. The default is "URISigningPackage".
必須の仕様：いいえ。デフォルトは「urisIngingPackage」です。
Property: jwt-header
プロパティ：JWT-Header
Description: The header part of JWT that is used for verifying a signed JWT when the JWT token in the URI Signing Package does not contain a header part.
説明：URI署名パッケージのJWTトークンにヘッダーパーツが含まれていないときに署名されたJWTを検証するために使用されるJWTのヘッダー部分。
Type: String
タイプ：文字列
Mandatory-to-Specify: No. By default, the header is assumed to be included in the JWT token.
必須の仕様：いいえ。デフォルトでは、ヘッダーはJWTトークンに含まれていると想定されています。
The following is an example of a URI Signing metadata payload with all default values:
以下は、すべてのデフォルト値を持つURI署名メタデータペイロードの例です。
{
"generic-metadata-type": "MI.UriSigning"
"generic-metadata-value": {}
}
The following is an example of a URI Signing metadata payload with explicit values:
以下は、明示的な値を持つURI署名メタデータペイロードの例です。
{
"generic-metadata-type": "MI.UriSigning"
"generic-metadata-value":
{
"enforce": true,
"issuers": ["csp", "ucdn1", "ucdn2"],
"package-attribute": "usp",
"jwt-header":
{
"alg": "ES256",
"kid": "P5UpOv0eMq1wcxLf7WxIg09JdSYGYFDOWkldueaImf0"
}
}
}
For URI Signing, the dCDN reports that enforcement of the access control was applied to the request for content delivery. When the request is denied due to enforcement of URI Signing, the reason is logged.
URIの署名については、DCDNは、アクセス制御の施行がコンテンツ配信の要求に適用されたと報告しています。URIの署名の施行により要求が拒否された場合、その理由は記録されます。
The following CDNI Logging field for URI Signing SHOULD be supported in the HTTP Request Logging Record as specified in "Content Distribution Network Interconnection (CDNI) Logging Interface" [RFC7937] using the new "cdni_http_request_v2" record-type registered in Section 6.2.1.
URIの署名用の次のCDNIロギングフィールドは、「コンテンツ配信ネットワークインターコネクション（CDNI）ロギングインターフェイス」で指定されているHTTPリクエストロギングレコードでサポートする必要があります。
* s-uri-signing (mandatory):
* s-uri-singime（必須）：
Format: 3DIGIT
フォーマット：3digit
Field value: this characterizes the URI Signing verification performed by the Surrogate on the request. The allowed values are registered in Section 6.4.
フィールド値：これは、リクエストでサロゲートによって実行されるURI署名検証を特徴付けます。許可された値は、セクション6.4に登録されています。
Occurrence: there MUST be zero or exactly one instance of this field.
発生：このフィールドのインスタンスはゼロまたは正確に1つある必要があります。
* s-uri-signing-deny-reason (optional):
* s-uri-singe-deny-reason（オプション）：
Format: QSTRING
フォーマット：QString
Field value: a string for providing further information in case the signed JWT was rejected, e.g., for debugging purposes.
フィールド値：署名されたJWTが拒否された場合に備えて、詳細情報を提供するための文字列、たとえば、デバッグ目的で。
Occurrence: there MUST be zero or exactly one instance of this field.
発生：このフィールドのインスタンスはゼロまたは正確に1つある必要があります。
URI Signing supports both HTTP-based and DNS-based request routing. JSON Web Token (JWT) [RFC7519] defines a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a Signed JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC).
URI署名は、HTTPベースとDNSベースのリクエストルーティングの両方をサポートしています。JSON Web Token（JWT）[RFC7519]は、2つの当事者間で転送されるクレームを表すコンパクトでURL安全な手段を定義します。署名されたJWTのクレームは、JSON Web Signature（JWS）構造のペイロードとして使用されるJSONオブジェクトとしてエンコードされ、メッセージ認証コード（MAC）でデジタル署名または整合性の保護されたクレームを可能にします。
For HTTP-based request routing, a set of information that is unique to a given end user content request is included in a Signed JWT, using key information that is specific to a pair of adjacent CDNI hops (e.g., between the CSP and the uCDN or between the uCDN and a dCDN). This allows a CDNI hop to ascertain the authenticity of a given request received from a previous CDNI hop.
HTTPベースのリクエストルーティングの場合、特定のエンドユーザーコンテンツリクエストに固有の情報セットは、隣接するCDNIホップのペアに固有のキー情報を使用して、署名済みのJWTに含まれています（例：CSPとUCDNの間でまたはUCDNとDCDNの間）。これにより、CDNIホップは、以前のCDNIホップから受け取った特定のリクエストの信頼性を確認できます。
The URI Signing method (assuming HTTP redirection, iterative request routing, and a CDN path with two CDNs) includes the following steps:
URI署名方法（HTTPリダイレクト、反復リクエストルーティング、2つのCDNを備えたCDNパスを仮定）には、次の手順が含まれています。
End-User dCDN uCDN CSP
| | | |
| 1.CDNI FCI used to | |
| advertise URI Signing capability | |
| |------------------->| |
| | | |
| 2.Provides information to verify Signed JWT |
| | |<-------------------|
| | | |
| 3.CDNI Metadata interface used to| |
| provide URI Signing attributes| |
| |<-------------------| |
: : : :
: (Later in time) : : :
|4.Authorization request | |
|------------------------------------------------------------->|
| | | [Apply distribution
| | | policy] |
| | | |
| | (ALT: Authorization decision)
|5.Request is denied | | <Negative> |
|<-------------------------------------------------------------|
| | | |
|6.CSP provides Signed URI | <Positive> |
|<-------------------------------------------------------------|
| | | |
|7.Content request | | |
|---------------------------------------->| [Verify URI |
| | | signature] |
| | | |
| | (ALT: Verification result) |
|8.Request is denied | <Negative>| |
|<----------------------------------------| |
| | | |
|9.Re-sign URI and redirect to <Positive>| |
| dCDN (newly Signed URI) | |
|<----------------------------------------| |
| | | |
|10.Content request | | |
|------------------->| [Verify URI | |
| | signature] | |
| | | |
| (ALT: Verification result) | |
|11.Request is denied| <Negative> | |
|<-------------------| | |
| | | |
|12.Content delivery | <Positive> | |
|<-------------------| | |
: : : :
: (Later in time) : : :
|13.CDNI Logging interface to include URI Signing information |
| |------------------->| |
Figure 3: HTTP-Based Request Routing with URI Signing
図3：URI署名によるHTTPベースの要求ルーティング
1. Using the CDNI Footprint & Capabilities Advertisement interface, the dCDN advertises its capabilities including URI Signing support to the uCDN.
1. DCDNは、CDNIフットプリント＆機能広告インターフェイスを使用して、URIのサポートをURIにサポートするなどの機能を宣伝しています。
2. CSP provides to the uCDN the information needed to verify Signed URIs from that CSP. For example, this information will include one or more keys used for validation.
2. CSPは、そのCSPから署名されたURIを確認するために必要な情報をUCDNに提供します。たとえば、この情報には、検証に使用される1つ以上のキーが含まれます。
3. Using the CDNI Metadata interface, the uCDN communicates to a dCDN the information needed to verify Signed URIs from the uCDN for the given CSP. For example, this information may include the URI query string parameter name for the URI Signing Package Attribute in addition to keys used for validation.
3. CDNIメタデータインターフェイスを使用して、UCDNは、指定されたCSPのUCDNから署名されたURIを検証するために必要な情報をDCDNに通信します。たとえば、この情報には、検証に使用されるキーに加えて、URI signingパッケージ属性のURIクエリ文字列パラメーター名が含まれている場合があります。
4. When a UA requests a piece of protected content from the CSP, the CSP makes a specific authorization decision for this unique request based on its local distribution policy.
4. UAがCSPから保護されたコンテンツを要求する場合、CSPは、ローカル配布ポリシーに基づいて、この一意の要求に対して特定の承認決定を下します。
5. If the authorization decision is negative, the CSP rejects the request and sends an error code (e.g., 403 Forbidden) in the HTTP response.
5. 承認の決定が否定的な場合、CSPはリクエストを拒否し、HTTP応答でエラーコード（403禁止）を送信します。
6. If the authorization decision is positive, the CSP computes a Signed JWT that is based on unique parameters of that request and conveys it to the end user as the URI to use to request the content.
6. 承認の決定が肯定的である場合、CSPはその要求の一意のパラメーターに基づいて署名されたJWTを計算し、コンテンツを要求するために使用するURIとしてエンドユーザーにそれを伝えます。
7. On receipt of the corresponding content request, the uCDN verifies the Signed JWT in the URI using the information provided by the CSP.
7. 対応するコンテンツリクエストを受信すると、UCDNはCSPが提供する情報を使用してURIで署名されたJWTを検証します。
8. If the verification result is negative, the uCDN rejects the request and sends an error code 403 Forbidden in the HTTP response.
8. 検証結果が負の場合、UCDNは要求を拒否し、HTTP応答で禁止されているエラーコード403を送信します。
9. If the verification result is positive, the uCDN computes a Signed JWT that is based on unique parameters of that request and provides it to the end user as the URI to use to further request the content from the dCDN.
9. 検証結果が正の場合、UCDNはその要求の一意のパラメーターに基づいて署名されたJWTを計算し、DCDNからコンテンツをさらにリクエストするために使用するURIとしてエンドユーザーにそれを提供します。
10. On receipt of the corresponding content request, the dCDN verifies the Signed JWT in the Signed URI using the information provided by the uCDN in the CDNI Metadata.
10. 対応するコンテンツリクエストを受信すると、DCDNは、CDNIメタデータでUCDNが提供する情報を使用して、署名されたURIで署名されたJWTを検証します。
11. If the verification result is negative, the dCDN rejects the request and sends an error code 403 Forbidden in the HTTP response.
11. 検証結果が負の場合、DCDNは要求を拒否し、HTTP応答で禁止されているエラーコード403を送信します。
12. If the verification result is positive, the dCDN serves the request and delivers the content.
12. 検証結果が正の場合、DCDNはリクエストを提供し、コンテンツを配信します。
13. At a later time, the dCDN reports logging events that include URI Signing information.
13. 後で、DCDNは、URIの署名情報を含むロギングイベントを報告します。
With HTTP-based request routing, URI Signing matches well the general chain of trust model of CDNI both with symmetric and asymmetric keys because the key information only needs to be specific to a pair of adjacent CDNI hops.
HTTPベースのリクエストルーティングでは、URIの署名は、キー情報が隣接するCDNIホップのペアに固有のだけである必要があるため、対称キーと両方のCDNIの一般的な信頼チェーンモデルとよく一致します。
Note: While using a symmetric shared key is supported, it is NOT RECOMMENDED. See the Security Considerations (Section 7) about the limitations of shared keys.
注：対称共有キーを使用することがサポートされていますが、推奨されません。共有キーの制限に関するセキュリティに関する考慮事項（セクション7）を参照してください。
For DNS-based request routing, the CSP and uCDN must agree on a trust model appropriate to the security requirements of the CSP's particular content. Use of asymmetric public/private keys allows for unlimited distribution of the public key to dCDNs. However, if a shared secret key is required, then the distribution SHOULD be performed by the CSP directly.
DNSベースのリクエストルーティングの場合、CSPとUCDNは、CSPの特定のコンテンツのセキュリティ要件に適した信頼モデルに同意する必要があります。非対称のパブリック/プライベートキーを使用すると、公開キーをDCDNSに無制限に配布できます。ただし、共有秘密のキーが必要な場合は、CSPによって直接分布を実行する必要があります。
Note: While using a symmetric shared key is supported, it is NOT RECOMMENDED. See the Security Considerations (Section 7) about the limitations of shared keys.
注：対称共有キーを使用することがサポートされていますが、推奨されません。共有キーの制限に関するセキュリティに関する考慮事項（セクション7）を参照してください。
The URI Signing method (assuming iterative DNS request routing and a CDN path with two CDNs) includes the following steps.
URI署名方法（反復DNSリクエストルーティングと2つのCDNを備えたCDNパスを仮定）には、次の手順が含まれています。
End-User dCDN uCDN CSP
| | | |
| 1.CDNI FCI used to | |
| advertise URI Signing capability | |
| |------------------->| |
| | | |
| 2.Provides information to verify Signed JWT |
| | |<-------------------|
| 3.CDNI Metadata interface used to| |
| provide URI Signing attributes| |
| |<-------------------| |
: : : :
: (Later in time) : : :
|4.Authorization request | |
|------------------------------------------------------------->|
| | | [Apply distribution
| | | policy] |
| | | |
| | (ALT: Authorization decision)
|5.Request is denied | | <Negative> |
|<-------------------------------------------------------------|
| | | |
|6.Provides Signed URI | <Positive> |
|<-------------------------------------------------------------|
| | | |
|7.DNS request | | |
|---------------------------------------->| |
| | | |
|8.Redirect DNS to dCDN | |
|<----------------------------------------| |
| | | |
|9.DNS request | | |
|------------------->| | |
| | | |
|10.IP address of Surrogate | |
|<-------------------| | |
| | | |
|11.Content request | | |
|------------------->| [Verify URI | |
| | signature] | |
| | | |
| (ALT: Verification result) | |
|12.Request is denied| <Negative> | |
|<-------------------| | |
| | | |
|13.Content delivery | <Positive> | |
|<-------------------| | |
: : : :
: (Later in time) : : :
|14.CDNI Logging interface to report URI Signing information |
| |------------------->| |
Figure 4: DNS-based Request Routing with URI Signing
図4：URI署名によるDNSベースの要求ルーティング
1. Using the CDNI Footprint & Capabilities Advertisement interface, the dCDN advertises its capabilities including URI Signing support to the uCDN.
1. DCDNは、CDNIフットプリント＆機能広告インターフェイスを使用して、URIのサポートをURIにサポートするなどの機能を宣伝しています。
2. CSP provides to the uCDN the information needed to verify Signed JWTs from that CSP. For example, this information will include one or more keys used for validation.
2. CSPは、そのCSPから署名されたJWTを確認するために必要な情報をUCDNに提供します。たとえば、この情報には、検証に使用される1つ以上のキーが含まれます。
3. Using the CDNI Metadata interface, the uCDN communicates to a dCDN the information needed to verify Signed JWTs from the CSP (e.g., the URI query string parameter name for the URI Signing Package Attribute). In the case of symmetric shared key, the uCDN MUST NOT share the key with a dCDN.
3. CDNIメタデータインターフェイスを使用して、UCDNはDCDNにCSPから署名されたJWTを検証するために必要な情報を通信します（たとえば、URI Signing Package属性のURIクエリ文字列パラメーター名）。対称共有キーの場合、UCDNはキーをDCDNと共有してはなりません。
4. When a UA requests a piece of protected content from the CSP, the CSP makes a specific authorization decision for this unique request based on its local distribution policy.
4. UAがCSPから保護されたコンテンツを要求する場合、CSPは、ローカル配布ポリシーに基づいて、この一意の要求に対して特定の承認決定を下します。
5. If the authorization decision is negative, the CSP rejects the request and sends an error code (e.g., 403 Forbidden) in the HTTP response.
5. 承認の決定が否定的な場合、CSPはリクエストを拒否し、HTTP応答でエラーコード（403禁止）を送信します。
6. If the authorization decision is positive, the CSP computes a Signed JWT that is based on unique parameters of that request and includes it in the URI provided to the end user to request the content.
6. 承認決定が肯定的である場合、CSPは、その要求の一意のパラメーターに基づいて署名されたJWTを計算し、エンドユーザーに提供されたURIにコンテンツをリクエストするように含みます。
7. The end user sends a DNS request to the uCDN.
7. エンドユーザーは、DNSリクエストをUCDNに送信します。
8. On receipt of the DNS request, the uCDN redirects the request to the dCDN.
8. DNSリクエストを受信すると、UCDNはリクエストをDCDNにリダイレクトします。
9. The end user sends a DNS request to the dCDN.
9. エンドユーザーは、DCDNにDNSリクエストを送信します。
10. On receipt of the DNS request, the dCDN responds with IP address of one of its Surrogates.
10. DNSリクエストを受信すると、DCDNはその代理の1つのIPアドレスで応答します。
11. On receipt of the corresponding content request, the dCDN verifies the Signed JWT in the URI using the information provided by the uCDN in the CDNI Metadata.
11. 対応するコンテンツリクエストを受信すると、DCDNは、CDNIメタデータのUCDNが提供する情報を使用して、URIで署名されたJWTを検証します。
12. If the verification result is negative, the dCDN rejects the request and sends an error code 403 Forbidden in the HTTP response.
12. 検証結果が負の場合、DCDNは要求を拒否し、HTTP応答で禁止されているエラーコード403を送信します。
13. If the verification result is positive, the dCDN serves the request and delivers the content.
13. 検証結果が正の場合、DCDNはリクエストを提供し、コンテンツを配信します。
14. At a later time, dCDN reports logging events that includes URI Signing information.
14. 後で、DCDNは、URIの署名情報を含むロギングイベントを報告します。
With DNS-based request routing, URI Signing matches well the general chain of trust model of CDNI when used with asymmetric keys because the only key information that needs to be distributed across multiple, possibly untrusted, CDNI hops is the public key, which is generally not confidential.
DNSベースのリクエストルーティングを使用すると、URIの署名は、非対称キーで使用する場合のCDNIの一般的なチェーンモデルと一致します。これは、複数の、おそらく信頼できない場合、CDNIホップが公開キーであるため、複数の、おそらく信頼できないものに分布する必要があるため、一般的には機密ではありません。
With DNS-based request routing, URI Signing does not match well with the general chain of trust model of CDNI when used with symmetric keys because the symmetric key information needs to be distributed across multiple CDNI hops to CDNs with which the CSP may not have a trust relationship. This raises a security concern for applicability of URI Signing with symmetric keys in case of DNS-based inter-CDN request routing. Due to these flaws, this architecture MUST NOT be implemented.
DNSベースのリクエストルーティングでは、対称キー情報を複数のCDNIホップに配布する必要があるため、対称キーで使用する場合、URIの署名はCDNIの一般的な信頼チェーンモデルとよく一致しません。信頼関係。これにより、DNSベースのInter-CDN要求ルーティングの場合、対称キーを使用したURIの適用性に関するセキュリティ上の懸念が生じます。これらの欠陥のため、このアーキテクチャを実装してはなりません。
Note: While using a symmetric shared key is supported, it is NOT RECOMMENDED. See the Security Considerations (Section 7) about the limitations of shared keys.
注：対称共有キーを使用することがサポートされていますが、推奨されません。共有キーの制限に関するセキュリティに関する考慮事項（セクション7）を参照してください。
IANA has registered the following CDNI Payload Type under the IANA "CDNI Payload Types" registry:
IANAは、IANAの「CDNIペイロードタイプ」レジストリの下に次のCDNIペイロードタイプを登録しています。
+===============+===============+
| Payload Type | Specification |
+===============+===============+
| MI.UriSigning | RFC 9246 |
+---------------+---------------+
Table 1
表1
Purpose: The purpose of this payload type is to distinguish UriSigning Metadata interface (MI) objects (and any associated capability advertisement).
目的：このペイロードタイプの目的は、メタデータインターフェイス（MI）オブジェクト（および関連する機能広告）をurisingすることです。
Interface: MI/FCI
インターフェイス：MI/FCI
Encoding: see Section 4.4
エンコーディング：セクション4.4を参照してください
IANA has registered the following CDNI Logging record-type under the IANA "CDNI Logging record-types" registry:
IANAは、IANAの「CDNIロギングレコードタイプ」レジストリの下で、次のCDNIロギングレコードタイプを登録しています。
+======================+===========+===========================+
| record-types | Reference | Description |
+======================+===========+===========================+
| cdni_http_request_v2 | RFC 9246 | Extension to CDNI Logging |
| | | Record version 1 for |
| | | content delivery using |
| | | HTTP, to include URI |
| | | Signing Logging fields |
+----------------------+-----------+---------------------------+
Table 2
表2
The "cdni_http_request_v2" record-type supports all of the fields supported by the "cdni_http_request_v1" record-type [RFC7937] plus the two additional fields "s-uri-signing" and "s-uri-signing-deny-reason", registered by this document in Section 6.3. The name, format, field value, and occurrence information for the two new fields can be found in Section 4.5 of this document.
「cdni_http_request_v2」レコードタイプは、「cdni_http_request_vv1」レコードタイプ[rfc7937]と2つの追加フィールド「S-uri-signing "および" s-uri-signing-signy-rises "、「s-uri-signis-rise」でサポートされているすべてのフィールドをサポートします。セクション6.3のこのドキュメントにより。2つの新しいフィールドの名前、形式、フィールド値、および発生情報は、このドキュメントのセクション4.5に記載されています。
IANA has registered the following CDNI Logging fields under the IANA "CDNI Logging Field Names" registry:
IANAは、IANA「CDNIロギングフィールド名」レジストリの下に、次のCDNIロギングフィールドを登録しています。
+===========================+===========+
| Field Name | Reference |
+===========================+===========+
| s-uri-signing | RFC 9246 |
+---------------------------+-----------+
| s-uri-signing-deny-reason | RFC 9246 |
+---------------------------+-----------+
Table 3
表3
IANA has created a new "CDNI URI Signing Verification Code" subregistry in the "Content Delivery Networks Interconnection (CDNI) Parameters" registry. The "CDNI URI Signing Verification Code" namespace defines the valid values associated with the s-uri-signing CDNI Logging field. The CDNI URI Signing Verification Code is a 3DIGIT value as defined in Section 4.5. Additions to the CDNI URI Signing Verification Code namespace will conform to the "Specification Required" policy as defined in [RFC8126]. Updates to this subregistry are expected to be infrequent.
IANAは、「コンテンツ配信ネットワーク相互接続（CDNI）パラメーター」レジストリで新しい「CDNI URI署名検証コード」を作成しました。「CDNI URI署名検証コード」名前空間は、S-URI署名CDNIロギングフィールドに関連付けられた有効な値を定義します。CDNI URI署名検証コードは、セクション4.5で定義されている3DIGIT値です。CDNI URI署名検証コード名空間への追加は、[RFC8126]で定義されている「必要な仕様」ポリシーに準拠します。このサブレジストリの更新はまれであると予想されます。
+=======+===========+=====================================+
| Value | Reference | Description |
+=======+===========+=====================================+
| 000 | RFC 9246 | No signed JWT verification |
| | | performed |
+-------+-----------+-------------------------------------+
| 200 | RFC 9246 | Signed JWT verification performed |
| | | and verified |
+-------+-----------+-------------------------------------+
| 400 | RFC 9246 | Signed JWT verification performed |
| | | and rejected because of incorrect |
| | | signature |
+-------+-----------+-------------------------------------+
| 401 | RFC 9246 | Signed JWT verification performed |
| | | and rejected because of Issuer |
| | | enforcement |
+-------+-----------+-------------------------------------+
| 402 | RFC 9246 | Signed JWT verification performed |
| | | and rejected because of Subject |
| | | enforcement |
+-------+-----------+-------------------------------------+
| 403 | RFC 9246 | Signed JWT verification performed |
| | | and rejected because of Audience |
| | | enforcement |
+-------+-----------+-------------------------------------+
| 404 | RFC 9246 | Signed JWT verification performed |
| | | and rejected because of Expiration |
| | | Time enforcement |
+-------+-----------+-------------------------------------+
| 405 | RFC 9246 | Signed JWT verification performed |
| | | and rejected because of Not Before |
| | | enforcement |
+-------+-----------+-------------------------------------+
| 406 | RFC 9246 | Signed JWT verification performed |
| | | and rejected because only one of |
| | | CDNI Signed Token Transport or CDNI |
| | | Expiration Time Setting present |
+-------+-----------+-------------------------------------+
| 407 | RFC 9246 | Signed JWT verification performed |
| | | and rejected because of JWT ID |
| | | enforcement |
+-------+-----------+-------------------------------------+
| 408 | RFC 9246 | Signed JWT verification performed |
| | | and rejected because of Version |
| | | enforcement |
+-------+-----------+-------------------------------------+
| 409 | RFC 9246 | Signed JWT verification performed |
| | | and rejected because of Critical |
| | | Extension enforcement |
+-------+-----------+-------------------------------------+
| 410 | RFC 9246 | Signed JWT verification performed |
| | | and rejected because of Client IP |
| | | enforcement |
+-------+-----------+-------------------------------------+
| 411 | RFC 9246 | Signed JWT verification performed |
| | | and rejected because of URI |
| | | Container enforcement |
+-------+-----------+-------------------------------------+
| 500 | RFC 9246 | Unable to perform signed JWT |
| | | verification because of malformed |
| | | URI |
+-------+-----------+-------------------------------------+
Table 4
表4
IANA has created a new "CDNI URI Signing Signed Token Transport" subregistry in the "Content Delivery Networks Interconnection (CDNI) Parameters" registry. The "CDNI URI Signing Signed Token Transport" namespace defines the valid values that may be in the Signed Token Transport (cdnistt) JWT claim. Additions to the Signed Token Transport namespace conform to the "Specification Required" policy as defined in [RFC8126]. Updates to this subregistry are expected to be infrequent.
IANAは、「コンテンツ配信ネットワークの相互接続（CDNI）パラメーター」レジストリに新しい「CDNI URI署名トークントークントランスポート」サブレジストリを作成しました。「CDNI URI署名署名されたトークントランスポート」名前空間は、署名されたトークントランスポート（CDNISTT）JWTクレームにある有効な値を定義します。[RFC8126]で定義されているように、署名されたトークントランスポートネームスペースへの追加。このサブレジストリの更新はまれであると予想されます。
The following table defines the initial Enforcement Information Elements:
次の表は、初期の執行情報要素を定義しています。
+=======+=============================================+==========+
| Value | Description | RFC |
+=======+=============================================+==========+
| 0 | Designates token transport is not enabled | RFC 9246 |
+-------+---------------------------------------------+----------+
| 1 | Designates token transport via cookie | RFC 9246 |
+-------+---------------------------------------------+----------+
| 2 | Designates token transport via query string | RFC 9246 |
+-------+---------------------------------------------+----------+
Table 5
表5
This specification registers the following claims in the IANA "JSON Web Token Claims" registry [IANA.JWT.Claims] established by [RFC7519].
この仕様は、[RFC7519]によって確立されたIANA「JSON Webトークンクレーム」レジストリ[IANA.jwt.Claims]で次の主張を登録します。
Claim Name: cdniv Claim Description: CDNI Claim Set Version Change Controller: IESG Specification Document(s): Section 2.1.8 of RFC 9246
クレーム名：CDNIVクレーム説明：CDNIクレームセットバージョン変更コントローラー：IESG仕様文書：RFC 9246のセクション2.1.8
Claim Name: cdnicrit Claim Description: CDNI Critical Claims Set Change Controller: IESG Specification Document(s): Section 2.1.9 of RFC 9246
クレーム名：CDNICRITクレーム説明：CDNIクリティカルクレームセットチェンジコントローラー：IESG仕様文書：RFC 9246のセクション2.1.9
Claim Name: cdniip Claim Description: CDNI IP Address Change Controller: IESG Specification Document(s): Section 2.1.10 of RFC 9246
クレーム名：CDNIIPクレーム説明：CDNI IPアドレス変更コントローラー：IESG仕様文書：RFC 9246のセクション2.1.10
Claim Name: cdniuc Claim Description: CDNI URI Container Change Controller: IESG Specification Document(s): Section 2.1.11 of RFC 9246
クレーム名：CDNIUCクレーム説明：CDNI URIコンテナ変更コントローラー：IESG仕様文書：RFC 9246のセクション2.1.11
Claim Name: cdniets Claim Description: CDNI Expiration Time Setting for Signed Token Renewal Change Controller: IESG Specification Document(s): Section 2.1.12 of RFC 9246
クレーム名：cdnietsクレーム説明：署名されたトークン更新変化コントローラーのCDNI有効期限設定：IESG仕様文書：RFC 9246のセクション2.1.12
Claim Name: cdnistt Claim Description: CDNI Signed Token Transport Method for Signed Token Renewal Change Controller: IESG Specification Document(s): Section 2.1.13 of RFC 9246
クレーム名：cdnisttクレーム説明：cdni署名されたトークン輸送方法署名されたトークン更新変化コントローラー：IESG仕様文書：RFC 9246のセクション2.1.13
Claim Name: cdnistd Claim Description: CDNI Signed Token Depth Change Controller: IESG Specification Document(s): Section 2.1.14 of RFC 9246
クレーム名：CDNISTDクレーム説明：CDNI署名されたトークン深度変更コントローラー：IESG仕様文書：RFC 9246のセクション2.1.14
Generally speaking, we should determine the registration has a rational justification and does not duplicate a previous registration. Early assignment should be permissible as long as there is a reasonable expectation that the specification will become formalized. Expert Reviewers should be empowered to make determinations, but generally speaking they should allow new claims that do not otherwise introduce conflicts with implementation or things that may lead to confusion. They should also follow the guidelines of Section 5 of [RFC8126] when sensible.
一般的に言えば、登録には合理的な正当性があり、以前の登録を複製しないと判断する必要があります。仕様が正式になるようになるという合理的な期待がある限り、早期の割り当ては許可されるべきです。専門家のレビュアーは、決定を行う権限を与える必要がありますが、一般的に言えば、そうでなければ、実装や混乱につながる可能性のあるものとの競合を導入しない新しい主張を許可する必要があります。また、賢明な場合は、[RFC8126]のセクション5のガイドラインに従う必要があります。
This document describes the concept of URI Signing and how it can be used to provide access authorization in the case of CDNI. The primary goal of URI Signing is to make sure that only authorized UAs are able to access the content, with a CSP being able to authorize every individual request. It should be noted that URI Signing is not a content protection scheme; if a CSP wants to protect the content itself, other mechanisms, such as DRM, are more appropriate.
このドキュメントでは、URIの署名の概念と、CDNIの場合にアクセス許可を提供するために使用する方法について説明します。URI署名の主な目標は、CSPがすべての個々のリクエストを許可できるように、認定されたUASのみがコンテンツにアクセスできることを確認することです。URIの署名はコンテンツ保護スキームではないことに注意する必要があります。CSPがコンテンツ自体を保護したい場合、DRMなどの他のメカニズムがより適切です。
CDNI URI Signing Signed Tokens leverage JSON Web Tokens and thus, guidelines in [RFC8725] are applicable for all JWT interactions.
CDNI URI署名署名されたトークンはJSON Webトークンを活用しているため、[RFC8725]のガイドラインはすべてのJWT相互作用に適用できます。
In general, it holds that the level of protection against illegitimate access can be increased by including more claims in the signed JWT. The current version of this document includes claims for enforcing Issuer, Client IP Address, Not Before time, and Expiration Time; however, this list can be extended with other more complex attributes that are able to provide some form of protection against some of the vulnerabilities highlighted below.
一般に、署名されたJWTにより多くの請求を含めることにより、非合法アクセスに対する保護レベルを増やすことができると考えられています。このドキュメントの現在のバージョンには、発行者、クライアントIPアドレスを実施するための請求、時間前ではなく、有効期限が含まれています。ただし、このリストは、以下に強調されている脆弱性の一部に対して何らかの形の保護を提供できる他のより複雑な属性で拡張できます。
That said, there are a number of aspects that limit the level of security offered by URI Signing and that anybody implementing URI Signing should be aware of.
とはいえ、URIの署名によって提供されるセキュリティのレベルを制限する多くの側面があり、URI署名を実装する人は誰でも知っておくべきです。
Replay attacks: A (valid) Signed URI may be used to perform replay attacks. The vulnerability to replay attacks can be reduced by picking a relatively short window between the Not Before time and Expiration Time attributes, although this is limited by the fact that any HTTP-based request needs a window of at least a couple of seconds to prevent sudden network issues from denying legitimate UAs access to the content. One may also reduce exposure to replay attacks by including a unique one-time access ID via the JWT ID attribute (jti claim). Whenever the dCDN receives a request with a given unique ID, it adds that ID to the list of 'used' IDs. In the case an illegitimate UA tries to use the same URI through a replay attack, the dCDN can deny the request based on the already used access ID. This list should be kept bounded. A reasonable approach would be to expire the entries based on the exp claim value. If no exp claim is present, then a simple Least Recently Used (LRU) cache could be used; however, this would allow values to eventually be reused.
リプレイ攻撃：（有効な）署名されたURIを使用して、リプレイ攻撃を実行できます。リプレイ攻撃に対する脆弱性は、時間前の属性と有効期限の属性の間の比較的短いウィンドウを選択することで減らすことができますが、これは、HTTPベースの要求が突然を防ぐために少なくとも数秒のウィンドウが必要であるという事実によって制限されています。コンテンツへの合法的なUASアクセスを拒否したことによるネットワークの問題。また、JWT ID属性（JTIクレーム）を介して一意の1回限りのアクセスIDを含めることにより、リプレイ攻撃への露出を減らすこともできます。 DCDNが特定の一意のIDを使用してリクエストを受信するたびに、そのIDが「使用されている」IDのリストに追加されます。違法なUAがリプレイ攻撃を介して同じURIを使用しようとする場合、DCDNは既に使用されているアクセスIDに基づいて要求を拒否できます。このリストは境界を維持する必要があります。合理的なアプローチは、EXP請求値に基づいてエントリを期限切れにすることです。 EXP請求が存在しない場合、単純な最近使用されていない（LRU）キャッシュを使用できます。ただし、これにより、値を最終的に再利用できます。
Illegitimate clients behind a NAT: In cases where there are multiple users behind the same NAT, all users will have the same IP address from the point of view of the dCDN. This results in the dCDN not being able to distinguish between different users based on Client IP Address, which can lead to illegitimate users being able to access the content. One way to reduce exposure to this kind of attack is to not only check for Client IP but also for other attributes, e.g., attributes that can be found in HTTP headers. However, this may be easily circumvented by a sophisticated attacker.
NATの背後にある非合法クライアント：同じNATの背後に複数のユーザーがいる場合、すべてのユーザーはDCDNの観点から同じIPアドレスを持っています。これにより、DCDNはクライアントIPアドレスに基づいて異なるユーザーを区別できず、非合法ユーザーがコンテンツにアクセスできるようになります。この種の攻撃への露出を減らす1つの方法は、クライアントIPをチェックするだけでなく、HTTPヘッダーにある属性など、他の属性をチェックすることです。ただし、これは洗練された攻撃者によって簡単に回避される場合があります。
A shared key distributed between CSP and uCDN is more likely to be compromised. Since this key can be used to legitimately sign a URL for content access authorization, it is important to know the implications of a compromised shared key. While using a shared key scheme can be convenient, this architecture is NOT RECOMMENDED due to the risks associated. It is included for legacy feature parity and is highly discouraged in new implementations.
CSPとUCDNの間に分布する共有キーは、妥協される可能性が高くなります。このキーを使用して、コンテンツアクセス許可のためにURLに合法的に署名できるため、侵害された共有キーの意味を知ることが重要です。共有キースキームの使用は便利ですが、関連するリスクのためにこのアーキテクチャは推奨されません。これは、レガシー機能のパリティに含まれており、新しい実装では非常に落胆しています。
If a shared key usable for signing is compromised, an attacker can use it to perform a denial-of-service attack by forcing the CDN to evaluate prohibitively expensive regular expressions embedded in a URI Container (cdniuc) claim. As a result, compromised keys should be timely revoked in order to prevent exploitation.
署名のために使用可能な共有キーが侵害された場合、攻撃者はそれを使用して、CDNに強制的にURIコンテナ（CDNIUC）クレームに埋め込まれた法外な高価な正規表現を評価することにより、サービス拒否攻撃を実行できます。その結果、搾取を防ぐために、妥協したキーをタイムリーに取り消す必要があります。
The URI Container (cdniuc) claim can be given a wildcard value. This, combined with the fact that it is the only mandatory claim, means you can effectively make a skeleton key. Doing this does not sufficiently limit the scope of the JWT and is NOT RECOMMENDED. The only way to prevent such a key from being used after it is distributed is to revoke the signing key so it no longer validates.
URIコンテナ（CDNIUC）のクレームには、ワイルドカード値を付与できます。これは、それが唯一の必須クレームであるという事実と相まって、スケルトンキーを効果的に作成できることを意味します。これを行うことは、JWTの範囲を十分に制限することはなく、推奨されません。このようなキーが分散された後に使用されないようにする唯一の方法は、署名キーを取り消して検証しなくなることです。
The privacy protection concerns described in "Content Distribution Network Interconnection (CDNI) Logging Interface" [RFC7937] apply when the client's IP address (cdniip) or Subject (sub) is embedded in the Signed URI. For this reason, the mechanism described in Section 2 encrypts the Client IP or Subject before including it in the URI Signing Package (and thus the URL itself).
「コンテンツ配信ネットワークの相互接続（CDNI）ロギングインターフェイス」[RFC7937]に記載されているプライバシー保護の懸念は、クライアントのIPアドレス（CDNIIP）またはサブジェクト（sub）が署名されたURIに埋め込まれている場合に適用されます。このため、セクション2で説明されているメカニズムは、URI署名パッケージ（したがってURL自体）に含める前に、クライアントIPまたはサブジェクトを暗号化します。
[POSIX.1] The Open Group, "IEEE Standard for Information Technology -- Portable Operating System Interface (POSIX(TM)) Base Specifications, Issue 7", (Revision of IEEE Std 1003.1-2008), IEEE Std 1003.1-2017, January 2018, <https://pubs.opengroup.org/onlinepubs/9699919799/>.
[POSIX.1]オープングループ、「情報技術のIEEE標準 - ポータブルオペレーティングシステムインターフェイス（POSIX（TM））ベース仕様、問題7」、（IEEE STD 1003.1-2008の改訂）、IEEE STD 1003.1-2017、2018年1月、<https://pubs.opengroup.org/onlinepubs/9699919799/>。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <https://www.rfc-editor.org/info/rfc791>.
[RFC0791] POSTEL、J。、「インターネットプロトコル」、STD 5、RFC 791、DOI 10.17487/RFC0791、1981年9月、<https://www.rfc-editor.org/info/rfc791>。
[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。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487/RFC2119、1997年3月、<https://www.rfc-editor.org/info/RFC2119>。
[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, <https://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月、<https：//www.rfc-editor.org/info/rfc3986>。
[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] Mills、D.、Martin、J.、Ed。、Burbank、J.、およびW. Kasch、「ネットワークタイムプロトコルバージョン4：プロトコルとアルゴリズムの仕様」、RFC 5905、DOI 10.17487/RFC5905、2010年6月、<https://www.rfc-editor.org/info/rfc5905>。
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010, <https://www.rfc-editor.org/info/rfc5952>.
[RFC5952] Kawamura、S。およびM. Kawashima、「IPv6アドレステキスト表現の推奨」、RFC 5952、DOI 10.17487/RFC5952、2010年8月、<https://www.rfc-editor.org/info/rfc5952>。
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, DOI 10.17487/RFC6265, April 2011, <https://www.rfc-editor.org/info/rfc6265>.
[RFC6265] Barth、A。、「HTTP状態管理メカニズム」、RFC 6265、DOI 10.17487/RFC6265、2011年4月、<https://www.rfc-editor.org/info/rfc6265>。
[RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, "URI Template", RFC 6570, DOI 10.17487/RFC6570, March 2012, <https://www.rfc-editor.org/info/rfc6570>.
[RFC6570]グレゴリオ、J。、フィールディング、R。、ハドリー、M。、ノッティンガム、M。、およびD.オーチャード、「URIテンプレート」、RFC 6570、DOI 10.17487/RFC6570、2012年3月、<https：// wwwwwwwwwwwwww.rfc-editor.org/info/rfc6570>。
[RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content Distribution Network Interconnection (CDNI) Problem Statement", RFC 6707, DOI 10.17487/RFC6707, September 2012, <https://www.rfc-editor.org/info/rfc6707>.
[RFC6707] Niven-Jenkins、B.、Le Faucheur、F.、およびN. Bitar、「コンテンツ配信ネットワーク相互接続（CDNI）問題ステートメント」、RFC 6707、DOI 10.17487/RFC6707、2012年9月、<https：// wwwwwwwwwwwwwwwwwwww.rfc-editor.org/info/rfc6707>。
[RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., Keranen, A., and P. Hallam-Baker, "Naming Things with Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, <https://www.rfc-editor.org/info/rfc6920>.
[RFC6920] Farrell、S.、Kutscher、D.、Dannewitz、C.、Ohlman、B.、Keranen、A。、およびP. Hallam-Baker、「Hashesで物を命名」、RFC 6920、DOI 10.17487/RFC6920、2013年4月、<https://www.rfc-editor.org/info/rfc6920>。
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.
[RFC7230] Fielding、R.、ed。and J. Reschke、ed。、「HyperText Transfer Protocol（HTTP/1.1）：メッセージの構文とルーティング」、RFC 7230、DOI 10.17487/RFC7230、2014年6月、<https://www.rfc-editor.org/info/RFC7230>。
[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015, <https://www.rfc-editor.org/info/rfc7516>.
[RFC7516]ジョーンズ、M。およびJ.ヒルデブランド、「JSON Web暗号化（JWE）」、RFC 7516、DOI 10.17487/RFC7516、2015年5月<https://www.rfc-editor.org/info/rfc7516>
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <https://www.rfc-editor.org/info/rfc7519>.
[RFC7519] Jones、M.、Bradley、J。、およびN. Sakimura、「JSON Web Token（JWT）」、RFC 7519、DOI 10.17487/RFC7519、2015年5月、<https：//www.rfc-editor.org/info/rfc7519>。
[RFC7937] Le Faucheur, F., Ed., Bertrand, G., Ed., Oprescu, I., Ed., and R. Peterkofsky, "Content Distribution Network Interconnection (CDNI) Logging Interface", RFC 7937, DOI 10.17487/RFC7937, August 2016, <https://www.rfc-editor.org/info/rfc7937>.
[RFC7937] Le Faucheur、F.、ed。、Bertrand、G.、Ed。、Oprescu、I.、Ed。、およびR. Peterkofsky、「コンテンツ配信ネットワーク相互接続（CDNI）ロギングインターフェイス」、RFC 7937、DOI 10.17487/RFC7937、2016年8月、<https://www.rfc-editor.org/info/rfc7937>。
[RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, "Content Delivery Network Interconnection (CDNI) Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016, <https://www.rfc-editor.org/info/rfc8006>.
[RFC8006] Niven-Jenkins、B.、Murray、R.、Caulfield、M。、およびK. Ma、「コンテンツ配信ネットワーク相互接続（CDNI）メタデータ」、RFC 8006、DOI 10.17487/RFC8006、2016年12月、<https：//www.rfc-editor.org/info/rfc8006>。
[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] Cotton、M.、Leiba、B。、およびT. Narten、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487/RFC8126、2017年6月、<https：// wwwwwwwwwwwwwwwwwwww.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>。
[IANA.JWT.Claims] IANA, "JSON Web Token (JWT)", <https://www.iana.org/assignments/jwt>.
[iana.jwt.claims] iana、 "json web token（jwt）"、<https://www.iana.org/assignments/jwt>。
[MPEG-DASH] ISO, "Information technology -- Dynamic adaptive streaming over HTTP (DASH) -- Part 1: Media presentation description and segment formats", ISO/IEC 23009-1:2019, Edition 4, December 2019, <https://www.iso.org/standard/79329.html>.
[MPEG-DASH] ISO、「情報技術 - HTTP上の動的適応ストリーミング（DASH） - パート1：メディアプレゼンテーションの説明とセグメント形式」、ISO/IEC 23009-1：2019、Edition 2019年12月、<HTTPS：//www.iso.org/standard/79329.html>。
[RFC6983] van Brandenburg, R., van Deventer, O., Le Faucheur, F., and K. Leung, "Models for HTTP-Adaptive-Streaming-Aware Content Distribution Network Interconnection (CDNI)", RFC 6983, DOI 10.17487/RFC6983, July 2013, <https://www.rfc-editor.org/info/rfc6983>.
[RFC6983] van Brandenburg、R.、van Deventer、O.、Le Faucheur、F.、およびK. Leung、「HTTP適応 - 調整対応コンテンツ配電ネットワークのモデル（CDNI）」、RFC 6983、DOI 10.174877/RFC6983、2013年7月、<https://www.rfc-editor.org/info/rfc6983>。
[RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., "Framework for Content Distribution Network Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, August 2014, <https://www.rfc-editor.org/info/rfc7336>.
[RFC7336] Peterson、L.、Davie、B。、およびR. Van Brandenburg、ed。、「コンテンツ配信ネットワーク相互接続のフレームワーク（CDNI）」、RFC 7336、DOI 10.17487/RFC7336、2014年8月、<https：///www.rfc-editor.org/info/rfc7336>。
[RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution Network Interconnection (CDNI) Requirements", RFC 7337, DOI 10.17487/RFC7337, August 2014, <https://www.rfc-editor.org/info/rfc7337>.
[RFC7337] Leung、K.、ed。and Y. Lee、ed。、「コンテンツ配信ネットワーク相互接続（CDNI）要件」、RFC 7337、DOI 10.17487/RFC7337、2014年8月、<https://www.rfc-editor.org/info/rfc737>。
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, <https://www.rfc-editor.org/info/rfc7517>.
[RFC7517]ジョーンズ、M。、「JSON Webキー（JWK）」、RFC 7517、DOI 10.17487/RFC7517、2015年5月、<https://www.rfc-editor.org/info/rfc7517>。
[RFC7975] Niven-Jenkins, B., Ed. and R. van Brandenburg, Ed., "Request Routing Redirection Interface for Content Delivery Network (CDN) Interconnection", RFC 7975, DOI 10.17487/RFC7975, October 2016, <https://www.rfc-editor.org/info/rfc7975>.
[RFC7975] Niven-Jenkins、B.、ed。and R. Van Brandenburg、ed。、「コンテンツ配信ネットワーク（CDN）相互接続のルーティングリダイレクトインターフェイスをリクエスト」、RFC 7975、DOI 10.17487/RFC7975、2016年10月、<https://www.rfc-editor.org/info/RFC7975>。
[RFC8008] Seedorf, J., Peterson, J., Previdi, S., van Brandenburg, R., and K. Ma, "Content Delivery Network Interconnection (CDNI) Request Routing: Footprint and Capabilities Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016, <https://www.rfc-editor.org/info/rfc8008>.
[RFC8008] Seedorf、J.、Peterson、J.、Previdi、S.、Van Brandenburg、R.、およびK. Ma、「コンテンツ配信ネットワークの相互接続（CDNI）リクエストルーティング：フットプリントと機能セマンティクス」、RFC 8008、doi10.17487/rfc8008、2016年12月、<https://www.rfc-editor.org/info/rfc8008>。
[RFC8216] Pantos, R., Ed. and W. May, "HTTP Live Streaming", RFC 8216, DOI 10.17487/RFC8216, August 2017, <https://www.rfc-editor.org/info/rfc8216>.
[RFC8216] Pantos、R.、ed。およびW. May、「HTTP Live Streaming」、RFC 8216、DOI 10.17487/RFC8216、2017年8月、<https://www.rfc-editor.org/info/rfc8216>。
[RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best Current Practices", BCP 225, RFC 8725, DOI 10.17487/RFC8725, February 2020, <https://www.rfc-editor.org/info/rfc8725>.
[RFC8725] Sheffer、Y.、Hardt、D。、およびM. Jones、「JSON Webトークンベスト現在のプラクティス」、BCP 225、RFC 8725、DOI 10.17487/RFC8725、2020年2月、<https：//www.rfc-editor.org/info/rfc8725>。
This section contains three examples of token usage: a simple example with only the required claim present, a complex example that demonstrates the full JWT claims set, including an encrypted Client IP Address (cdniip), and one that uses a Signed Token Renewal.
このセクションには、トークン使用の3つの例が含まれています。必要なクレームのみを備えた単純な例、暗号化されたクライアントIPアドレス（CDNIIP）を含む完全なJWTクレームセットを実証する複雑な例、および署名されたトークン更新を使用するもの。
Note: All of the examples have empty space added to improve formatting and readability, but are not present in the generated content.
注：すべての例には、フォーマットと読みやすさを改善するために空のスペースが追加されていますが、生成されたコンテンツには存在しません。
All examples use the following JWK Set [RFC7517]:
すべての例は、次のJWKセット[RFC7517]を使用しています。
{ "keys": [
{
"kty": "EC",
"kid": "P5UpOv0eMq1wcxLf7WxIg09JdSYGYFDOWkldueaImf0",
"use": "sig",
"alg": "ES256",
"crv": "P-256",
"x": "be807S4O7dzB6I4hTiCUvmxCI6FuxWba1xYBlLSSsZ8",
"y": "rOGC4vI69g-WF9AGEVI37sNNwbjIzBxSjLvIL7f3RBA"
},
{
"kty": "EC",
"kid": "P5UpOv0eMq1wcxLf7WxIg09JdSYGYFDOWkldueaImf0",
"use": "sig",
"alg": "ES256",
"crv": "P-256",
"x": "be807S4O7dzB6I4hTiCUvmxCI6FuxWba1xYBlLSSsZ8",
"y": "rOGC4vI69g-WF9AGEVI37sNNwbjIzBxSjLvIL7f3RBA",
"d": "yaowezrCLTU6yIwUL5RQw67cHgvZeMTLVZXjUGb1A1M"
},
{
"kty": "oct",
"kid": "f-WbjxBC3dPuI3d24kP2hfvos7Qz688UTi6aB0hN998",
"use": "enc",
"alg": "A128GCM",
"k": "4uFxxV7fhNmrtiah2d1fFg"
}
]}
Note: They are the public signing key, the private signing key, and the shared secret encryption key, respectively. The public and private signing keys have the same fingerprint and only vary by the 'd' parameter that is missing from the public signing key.
注：それらは、それぞれ公開署名キー、プライベート署名キー、共有秘密の暗号化キーです。パブリックおよびプライベートの署名キーは同じ指紋を持ち、公開署名キーから欠落している「D」パラメーターによってのみ異なります。
This example is a simple common usage example containing a minimal subset of claims that the authors find most useful.
この例は、著者が最も便利だと思うクレームの最小限のサブセットを含む単純な一般的な使用例です。
The JWT Claim Set before signing:
署名前に設定されたJWTクレーム：
Note: "sha-256;2tderfWPa86Ku7YnzW51YUp7dGUjBS_3SW3ELx4hmWY" is the URL Segment form (Section 5 of [RFC6920]) of "http://cdni.example/foo/bar".
注： "Sha-256; 2tderfwpa86ku7ynzw51yup7dgujbs_3sw3lx4hmwy"は、「http：//cdni.example/foo/bar/bar」のURLセグメントフォーム（[rfc6920]のセクション5）です。
{
"exp": 1646867369,
"iss": "uCDN Inc",
"cdniuc":
"hash:sha-256;2tderfWPa86Ku7YnzW51YUp7dGUjBS_3SW3ELx4hmWY"
}
The signed JWT:
署名されたJWT：
eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU dZRkRPV2tsZHVlYUltZjAifQ.eyJleHAiOjE2NDY4NjczNjksImlzcyI6InVDRE4gS W5jIiwiY2RuaXVjIjoiaGFzaDpzaGEtMjU2OzJ0ZGVyZldQYTg2S3U3WW56VzUxWVV wN2RHVWpCU18zU1czRUx4NGhtV1kifQ.TaNlJM3D96i_9J9XvlICO6FUIDFTqt3E2Y JkEUOLfcH0b89wYRKTbJ9Yj6h_GRgSoZoQO0cps3yUPcWGK3smCw
eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU dZRkRPV2tsZHVlYUltZjAifQ.eyJleHAiOjE2NDY4NjczNjksImlzcyI6InVDRE4gS W5jIiwiY2RuaXVjIjoiaGFzaDpzaGEtMjU2OzJ0ZGVyZldQYTg2S3U3WW56VzUxWVV wN2RHVWpCU18zU1czRUx4NGhtV1kifQ.TaNlJM3D96i_9J9XvlICO6FUIDFTqt3E2Y JkEUOLfcH0b89wYRKTbJ9Yj6h_GRgSoZoQO0cps3yUPcWGK3smCw
This example uses all fields except for those dealing with Signed Token Renewal, including Client IP Address (cdniip) and Subject (sub), which are encrypted. This significantly increases the size of the signed JWT token.
この例では、暗号化されたクライアントIPアドレス（CDNIIP）や件名（Sub）を含む署名されたトークン更新を扱うものを除くすべてのフィールドを使用します。これにより、署名されたJWTトークンのサイズが大幅に増加します。
JWE for Client IP Address (cdniip) of [2001:db8::1/32]:
[2001：DB8 :: 1/32]のクライアントIPアドレス（CDNIIP）のJWE：
eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiZGlyIiwia2lkIjoiZi1XYmp4QkMzZFB1ST NkMjRrUDJoZnZvczdRejY4OFVUaTZhQjBoTjk5OCJ9..aUDDFEQBIc3nWjOb.bGXWT HPkntmPCKn0pPPNEQ.iyTttnFybO2YBLqwl_YSjA
eyjlbmmioijbmti4r0nniiiwiywxnijoizglyiiwiaiwiaiwiaizi1xymp4qkmzzfb1st nkmjrrudjoznzvczdrejy4ofvuatzhqjbotjk5oc5ocj99..udfcbcbcbcbcmpcbcmpcmpcbcmpcmpcmpcbcmpmpmpmpmpmpmpmpmtcbcbcmy4cbcbcbcbcbcbcbcbydrejy4fvuatzhqjbotjk5oczdrejy
JWE for Subject (sub) of "UserToken":
「usertoken」の主題（sub）のJWE：
eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiZGlyIiwia2lkIjoiZi1XYmp4QkMzZFB1ST NkMjRrUDJoZnZvczdRejY4OFVUaTZhQjBoTjk5OCJ9..CLAu80xclc8Bp-Ui.6P1A3 F6ip2Dv.CohdtLLpgBnTvRJQCFuz-g
eyjlbmmioijbmti4r0nniiiwiywxnijoizglyiiwiawiawiawiaizi1xymp4qkmzzfb1st nkmjrrudjoznzvczdrejy4ofvuatzhqjbotjk5ocj9..clau80cxccxcxfdfdfdfdfdfdfdfdfdfdfdfdfdfddrejy4ofvuatzhqjbotjk5ocj9..
The JWT Claim Set before signing:
署名前に設定されたJWTクレーム：
{
"aud": "dCDN LLC",
"sub": "eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiZGlyIiwia2lkIjoiZi1XYmp4
QkMzZFB1STNkMjRrUDJoZnZvczdRejY4OFVUaTZhQjBoTjk5OCJ9..CLAu80xclc8B
p-Ui.6P1A3F6ip2Dv.CohdtLLpgBnTvRJQCFuz-g",
"cdniip": "eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiZGlyIiwia2lkIjoiZi1XY
mp4QkMzZFB1STNkMjRrUDJoZnZvczdRejY4OFVUaTZhQjBoTjk5OCJ9..aUDDFEQBI
c3nWjOb.bGXWTHPkntmPCKn0pPPNEQ.iyTttnFybO2YBLqwl_YSjA",
"cdniv": 1,
"exp": 1646867369,
"iat": 1646694569,
"iss": "uCDN Inc",
"jti": "5DAafLhZAfhsbe",
"nbf": 1646780969,
"cdniuc": "regex:http://cdni\\.example/foo/bar/[0-9]{3}\\.png"
}
The signed JWT:
署名されたJWT：
eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU
dZRkRPV2tsZHVlYUltZjAifQ.eyJhdWQiOiJkQ0ROIExMQyIsInN1YiI6ImV5Smxib
U1pT2lKQk1USTRSME5OSWl3aVlXeG5Jam9pWkdseUlpd2lhMmxrSWpvaVppMVhZbXA
0UWtNelpGQjFTVE5rTWpSclVESm9ablp2Y3pkUmVqWTRPRlZVYVRaaFFqQm9Uams1T
0NKOS4uQ0xBdTgweGNsYzhCcC1VaS42UDFBM0Y2aXAyRHYuQ29oZHRMTHBnQm5UdlJ
KUUNGdXotZyIsImNkbmlpcCI6ImV5SmxibU1pT2lKQk1USTRSME5OSWl3aVlXeG5Ja
m9pWkdseUlpd2lhMmxrSWpvaVppMVhZbXA0UWtNelpGQjFTVE5rTWpSclVESm9ablp
2Y3pkUmVqWTRPRlZVYVRaaFFqQm9Uams1T0NKOS4uYVVEREZFUUJJYzNuV2pPYi5iR
1hXVEhQa250bVBDS24wcFBQTkVRLml5VHR0bkZ5Yk8yWUJMcXdsX1lTakEiLCJjZG5
pdiI6MSwiZXhwIjoxNjQ2ODY3MzY5LCJpYXQiOjE2NDY2OTQ1NjksImlzcyI6InVDR
E4gSW5jIiwianRpIjoiNURBYWZMaFpBZmhzYmUiLCJuYmYiOjE2NDY3ODA5NjksImN
kbml1YyI6InJlZ2V4Omh0dHA6Ly9jZG5pXFwuZXhhbXBsZS9mb28vYmFyL1swLTlde
zN9XFwucG5nIn0.IjmVX0uD5MYqArc-M08uEsEeoDQn8kuYXZ9HGHDmDDxsHikT0c8
jcX8xYD0z3LzQclMG65i1kT2sRbZ7isUw8w
This example uses fields for Signed Token Renewal.
この例では、署名されたトークン更新にフィールドを使用しています。
The JWT Claim Set before signing:
署名前に設定されたJWTクレーム：
{
"cdniets": 30,
"cdnistt": 1,
"cdnistd": 2,
"exp": 1646867369,
"cdniuc": "regex:http://cdni\\.example/foo/bar/[0-9]{3}\\.ts"
}
The signed JWT:
署名されたJWT：
eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU dZRkRPV2tsZHVlYUltZjAifQ.eyJjZG5pZXRzIjozMCwiY2RuaXN0dCI6MSwiY2Rua XN0ZCI6MiwiZXhwIjoxNjQ2ODY3MzY5LCJjZG5pdWMiOiJyZWdleDpodHRwOi8vY2R uaVxcLmV4YW1wbGUvZm9vL2Jhci9bMC05XXszfVxcLnRzIn0.tlPvoKw3BCClw4Lx9 PQu7MK6b2IN55ZoCPSaxovGK0zS53Wpb1MbJBow7G8LiGR39h6-2Iq7PWUSr3MdTIz HYw
eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU dZRkRPV2tsZHVlYUltZjAifQ.eyJjZG5pZXRzIjozMCwiY2RuaXN0dCI6MSwiY2Rua XN0ZCI6MiwiZXhwIjoxNjQ2ODY3MzY5LCJjZG5pdWMiOiJyZWdleDpodHRwOi8vY2R uaVxcLmV4YW1wbGUvZm9vL2Jhci9bMC05XXszfVxcLnRzIn0.tlPvoKw3BCClw4Lx9 PQu7MK6b2IN55ZoCPSaxovGK0zS53Wpb1MbJBow7G8LiGR39h6-2Iq7PWUSr3MdTIz HYw
Once the server verifies the signed JWT it will return a new signed JWT with an updated Expiry Time (exp) as shown below. Note the Expiry Time is increased by the expiration time setting (cdniets) value.
サーバーが署名されたJWTを検証すると、以下に示すように、更新された有効期限（EXP）で新しい署名されたJWTを返します。注期限は、有効期限の設定（cdniets）値によって増加します。
The JWT Claim Set before signing:
署名前に設定されたJWTクレーム：
{
"cdniets": 30,
"cdnistt": 1,
"cdnistd": 2,
"exp": 1646867399,
"cdniuc": "regex:http://cdni\\.example/foo/bar/[0-9]{3}\\.ts"
}
The signed JWT:
署名されたJWT：
eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU dZRkRPV2tsZHVlYUltZjAifQ.eyJjZG5pZXRzIjozMCwiY2RuaXN0dCI6MSwiY2Rua XN0ZCI6MiwiZXhwIjoxNjQ2ODY3Mzk5LCJjZG5pdWMiOiJyZWdleDpodHRwOi8vY2R uaVxcLmV4YW1wbGUvZm9vL2Jhci9bMC05XXszfVxcLnRzIn0.ivY5d_fKGd-OHTpUs 8uJUrnHvt-rduzu5H4zM7167pUUAghub53FqDQ5G16jRYX2sY73mA_uLpYDdb-CPts 8FA
eyJhbGciOiJFUzI1NiIsImtpZCI6IlA1VXBPdjBlTXExd2N4TGY3V3hJZzA5SmRTWU dZRkRPV2tsZHVlYUltZjAifQ.eyJjZG5pZXRzIjozMCwiY2RuaXN0dCI6MSwiY2Rua XN0ZCI6MiwiZXhwIjoxNjQ2ODY3Mzk5LCJjZG5pdWMiOiJyZWdleDpodHRwOi8vY2R uaVxcLmV4YW1wbGUvZm9vL2Jhci9bMC05XXszfVxcLnRzIn0.ivY5d_fKGd-OHTpUs 8uJUrnHvt-rduzu5H4zM7167pUUAghub53FqDQ5G16jRYX2sY73mA_uLpYDdb-CPts 8FA
Acknowledgements
謝辞
The authors would like to thank the following people for their contributions in reviewing this document and providing feedback: Scott Leibrand, Kevin Ma, Ben Niven-Jenkins, Thierry Magnien, Dan York, Bhaskar Bhupalam, Matt Caulfield, Samuel Rajakumar, Iuniana Oprescu, Leif Hedstrom, Gancho Tenev, Brian Campbell, and Chris Lemmons.
著者は、この文書のレビューとフィードバックの提供における貢献について、以下の人々に感謝したいと思います：Scott Leibrand、Kevin MA、Ben Niven-Jenkins、Thierry Magnien、Dan York、Bhaskar Bupalam、Matt Caulfield、Samuel Rajakumar、iuniana oprescu、LeifHedstrom、Gancho Tenev、Brian Campbell、Chris Lemmons。
Contributors
貢献者
In addition, the authors would also like to make special mentions for certain people who contributed significant sections to this document.
さらに、著者はまた、この文書に重要なセクションを提供した特定の人々のために特別な言及をしたいと考えています。
* Matt Caulfield provided content for Section 4.4, "CDNI Metadata Interface".
* Matt Caulfieldは、セクション4.4「CDNIメタデータインターフェイス」のコンテンツを提供しました。
* Emmanuel Thomas provided content for HTTP Adaptive Streaming.
* エマニュエル・トーマスは、HTTP適応ストリーミングのコンテンツを提供しました。
* Matt Miller provided consultation on JWT usage as well as code to generate working JWT examples.
* Matt Millerは、JWTの使用法と、動作するJWTの例を生成するコードに関する相談を提供しました。
Authors' Addresses
著者のアドレス
Ray van Brandenburg Tiledmedia Anna van Buerenplein 1 2595DA Den Haag Netherlands Phone: +31 88 866 7000 Email: ray@tiledmedia.com
Ray Van Brandenburg Tilededia Anna Van Buerenplein 1 2595Da Den Haag Otherlands電話：31 88 866 7000メール：ray@tiledmedia.com
Kent Leung Email: mail4kentl@gmail.com
Kent Leung Email：mail4kentl@gmail.com
Phil Sorber Apple, Inc. Suite 410 1800 Wazee Street Denver, CO 80202 United States Email: sorber@apple.com
Phil Sorber Apple、Inc。Suite 410 1800 Wazee Street Denver、Co 80202米国メール：sorber@apple.com