Network Working Group T. Pauly
Internet-Draft Apple Inc.
Intended status: Standards Track S. Valdez
Expires: 11 June 2023 Google LLC
C. A. Wood
Cloudflare
8 December 2022
The Privacy Pass HTTP Authentication Scheme draft-ietf-privacypass-auth-scheme-07
プライバシーパスHTTP認証スキームドラフト-ITF-PRIVACYPASS-AUTH-SCHEME-07
Abstract
概要
This document defines an HTTP authentication scheme that can be used by clients to redeem Privacy Pass tokens with an origin. It can also be used by origins to challenge clients to present an acceptable Privacy Pass token.
このドキュメントでは、クライアントがプライバシーパストークンをオリジンで引き換えるために使用できるHTTP認証スキームを定義します。また、Originsがクライアントに挑戦して、許容可能なプライバシーパストークンを提示するように使用することもできます。
Status of This Memo
本文書の位置付け
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
このインターネットドラフトは、BCP 78およびBCP 79の規定に完全に適合して提出されています。
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
インターネットドラフトは、インターネットエンジニアリングタスクフォース（IETF）の作業文書です。他のグループは、作業文書をインターネットドラフトとして配布する場合もあることに注意してください。現在のインターネットドラフトのリストは、https：//datatracker.ietf.org/drafts/current/にあります。
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
インターネットドラフトは、最大6か月間有効なドラフトドキュメントであり、いつでも他のドキュメントで更新、交換、または廃止される場合があります。インターネットドラフトを参照資料として使用したり、「進行中の作業」以外に引用することは不適切です。
This Internet-Draft will expire on 11 June 2023.
このインターネットドラフトは、2023年6月11日に期限切れになります。
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. HTTP Authentication Scheme . . . . . . . . . . . . . . . . . 4
2.1. Token Challenge . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Redemption Context Construction . . . . . . . . . . . 7
2.1.2. Token Caching . . . . . . . . . . . . . . . . . . . . 8
2.2. Token Redemption . . . . . . . . . . . . . . . . . . . . 8
3. User Interaction . . . . . . . . . . . . . . . . . . . . . . 10
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
5.1. Authentication Scheme . . . . . . . . . . . . . . . . . . 13
5.2. Token Type Registry . . . . . . . . . . . . . . . . . . . 13
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.1. Normative References . . . . . . . . . . . . . . . . . . 15
6.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
Privacy Pass tokens are unlinkable authenticators that can be used to anonymously authorize a client (see [ARCHITECTURE]). Tokens are generated by token issuers, on the basis of authentication, attestation, or some previous action such as solving a CAPTCHA. A client possessing such a token is able to prove that it was able to get a token issued, without allowing the relying party redeeming the client's token (the origin) to link it with the issuance flow.
プライバシーパストークンは、クライアントを匿名で承認するために使用できるリンクできない認証者です（[アーキテクチャ]を参照）。トークンは、認証、証明、またはキャプチャの解決などの以前のアクションに基づいて、トークン発行者によって生成されます。そのようなトークンを所有しているクライアントは、クライアントのトークン（原点）を補償するために発行フローにリンクすることなく、頼る当事者がそれをリンクすることなく、トークンを発行することができたことを証明することができます。
Different types of authenticators, using different token issuance protocols, can be used as Privacy Pass tokens.
さまざまなトークン発行プロトコルを使用したさまざまなタイプの認証器を、プライバシーパストークンとして使用できます。
This document defines a common HTTP authentication scheme ([RFC9110], Section 11), PrivateToken, that allows clients to redeem various kinds of Privacy Pass tokens.
このドキュメントでは、クライアントがさまざまな種類のプライバシーパストークンを引き換えることができる一般的なHTTP認証スキーム（[RFC9110]、セクション11）、PrivateTokenを定義しています。
Clients and relying parties (origins) interact using this scheme to perform the token challenge and token redemption flow. In particular, origins challenge clients for a token with an HTTP Authentication challenge (using the WWW-Authenticate response header field). Clients then respond to that challenge with an HTTP authentiation response (using the Authorization request header field). Clients produce an authentication response based on the origin's token challenge by running the token issuance protocol [ISSUANCE]. The act of presenting a token in an Authorization request header is referred to as token redemption. This interaction between client and origin is shown below.
クライアントと依存関係者（Origins）は、このスキームを使用して対話して、トークンチャレンジとトークンの償還フローを実行します。特に、Originsは、HTTP認証チャレンジを備えたトークンのクライアントに挑戦します（www-authenticate応答ヘッダーフィールドを使用）。その後、クライアントはHTTP認証応答（承認要求ヘッダーフィールドを使用）でその課題に応答します。クライアントは、トークン発行プロトコル[発行]を実行することにより、Originのトークンチャレンジに基づいて認証応答を生成します。承認要求ヘッダーでトークンを提示する行為は、トークン償還と呼ばれます。クライアントと起源の間のこの相互作用を以下に示します。
Client Relying Party (Origin)
クライアントに依存するパーティー（起源）
<---------------------- WWW-Authenticate \ Challenge
(TokenChallenge) |
+----------------------------------\ |
| | |
| Issuance Protocol | |
| | |
+----------------------------------/ |
|
Authorization ---------------------------> / Response (redemption)
(Token)
Figure 1: Token Architectural Components
図1：トークンアーキテクチャコンポーネント
In addition to working with different token issuance protocols, this scheme optionally supports use of tokens that are associated with origin-chosen contexts and specific origin names. Relying parties that request and redeem tokens can choose a specific kind of token, as appropriate for its use case. These options allow for different deployment models to prevent double-spending, and allow for both interactive (online challenges) and non-interactive (pre-fetched) tokens.
さまざまなトークン発行プロトコルの操作に加えて、このスキームはオプションで、起源が選択したコンテキストと特定の原点名に関連付けられているトークンの使用をサポートします。トークンを要求して償還する当事者に頼ることは、そのユースケースに適した場合、特定の種類のトークンを選択できます。これらのオプションにより、さまざまな展開モデルが2倍の支出を防ぎ、インタラクティブ（オンラインチャレンジ）と非対話型（事前にフェッチした）トークンの両方を可能にします。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
Unless otherwise specified, this document encodes protocol messages in TLS notation from [TLS13], Section 3.
特に指定されていない限り、このドキュメントは[TLS13]、セクション3のTLS表記でプロトコルメッセージをエンコードします。
This document uses the terms "Client", "Origin", "Issuer", "Issuance Protocol", and "Token" as defined in [ARCHITECTURE]. It additionally uses the following terms in more specific ways:
このドキュメントでは、[アーキテクチャ]で定義されているように、「クライアント」、「オリジナル」、「発行者」、「発行プロトコル」、「トークン」という用語を使用します。さらに、より具体的な方法で次の用語を使用します。
* Issuer key: Keying material that can be used with an issuance protocol to create a signed token.
* 発行者キー：発行プロトコルで使用できるキーイング資料で署名されたトークンを作成します。
* Token challenge: A requirement for tokens sent from an origin to a client, using the "WWW-Authenticate" HTTP header field. This challenge is bound to a specific token issuer and issuance protocol, and may be additionally bound to a specific context or origin name.
* トークンチャレンジ：「www-authenticate」httpヘッダーフィールドを使用して、クライアントに起源から送信されるトークンの要件。この課題は、特定のトークン発行者および発行プロトコルに縛られており、特定のコンテキストまたは原点名にさらに拘束される場合があります。
* Token redemption: An action by which a client presents a token to an origin in an HTTP request, using the "Authorization" HTTP header field.
* トークン償還：「認証」HTTPヘッダーフィールドを使用して、クライアントがHTTP要求でトークンを起源に提示するアクション。
Token redemption is performed using HTTP Authentication ([RFC9110], Section 11), with the scheme "PrivateToken". Origins challenge clients to present a token from a specific issuer (Section 2.1). Once a client has received a token from that issuer, or already has a valid token available, it presents the token to the origin (Section 2.2).
トークン償還は、HTTP認証（[RFC9110]、セクション11）を使用して実行され、スキームは「privateToken」です。Originsは、特定の発行者からトークンを提示するようクライアントに挑戦します（セクション2.1）。クライアントがその発行者からトークンを受け取ったか、すでに有効なトークンを利用できるようになったら、トークンを起源に示します（セクション2.2）。
Unlike many authentication schemes in which a client will present the same credentials across multiple requests, tokens used with the "PrivateToken" scheme are single-use credentials, and are not reused. Spending the same token value more than once allows the origin to link multiple transactions to the same client. In deployment scenarios where origins send token challenges to request tokens, origins ought to expect at most one request containing a token from the client in reaction to a particular challenge.
クライアントが複数の要求にわたって同じ資格情報を提示する多くの認証スキームとは異なり、「privateToken」スキームで使用されるトークンは使い捨ての資格情報であり、再利用されません。同じトークン値を複数回使用することで、Originは複数のトランザクションを同じクライアントにリンクできます。Originsがトークンを要求するためにトークンの課題を送信する展開シナリオでは、Originsは、特定の課題に反応するクライアントからのトークンを含む最大1つの要求を期待する必要があります。
Origins send a token challenge to clients in an "WWW-Authenticate" header field with the "PrivateToken" scheme. This challenge includes a TokenChallenge message, along with information about what keys to use when requesting a token from the issuer.
Originsは、「privateToken」スキームを使用して「www-authenticate」ヘッダーフィールドでクライアントにトークンチャレンジを送信します。この課題には、TokenChallengeメッセージと、発行者からトークンを要求する際に使用する鍵に関する情報が含まれます。
Origins that support this authentication scheme need to handle the following tasks:
この認証スキームをサポートする起源は、次のタスクを処理する必要があります。
1. Select which issuer to use, and configure the issuer name and token-key to include in WWW-Authenticate challenges.
1. 使用する発行者を選択し、発行者名とtoken-Keyを構成して、www-authenticateの課題に含めます。
2. Determine a redemption context construction to include in the TokenChallenge, as discussed in Section 2.1.1.
2. セクション2.1.1で説明したように、TokenChallengeに含める償還コンテキスト構造を決定します。
3. Select the origin information to include in the TokenChallenge. This can be empty to allow fully cross-origin tokens, a single origin name that matches the origin itself, or a list of origin names containing the origin itself.
3. TokenChallengeに含めるオリジン情報を選択します。これは、完全にオリジントークン、原点自体に一致する単一の原点名、または起源自体を含む原点名のリストを許可するために空にすることができます。
The TokenChallenge message has the following structure:
TokenChallengeメッセージには次の構造があります。
struct {
uint16_t token_type;
opaque issuer_name<1..2^16-1>;
opaque redemption_context<0..32>;
opaque origin_info<0..2^16-1>;
} TokenChallenge;
The structure fields are defined as follows:
構造フィールドは次のように定義されています。
* "token_type" is a 2-octet integer, in network byte order. This type indicates the issuance protocol used to generate the token. Values are registered in an IANA registry, Section 5.2. Challenges with unsupported token_type values MUST be ignored.
* 「token_type」は、ネットワークバイトの順序で2-OCTET整数です。このタイプは、トークンの生成に使用される発行プロトコルを示しています。値は、IANAレジストリ、セクション5.2に登録されています。サポートされていないtoken_type値の課題は無視する必要があります。
* "issuer_name" is a string containing the name of the issuer. This is a hostname that is used to identify the issuer that is allowed to issue tokens that can be redeemed by this origin. The string is prefixed with a 2-octet integer indicating the length, in network byte order.
* 「Issuer_name」は、発行者の名前を含む文字列です。これは、この起源によって引き換えることができるトークンを発行することが許可されている発行者を識別するために使用されるホスト名です。文字列には、ネットワークバイトの順序で長さを示す2オクテットの整数が付いています。
* "redemption_context" is an optional field. If present, it allows the origin to require that clients fetch tokens bound to a specific context, as opposed to reusing tokens that were fetched for other contexts. See Section 2.1.1 for example contexts that might be useful in practice. When present, this value is a 32-byte context generated by the origin. Valid lengths for this field are either 0 or 32 bytes. The field is prefixed with a single octet indicating the length. Challenges with redemption_context values of invalid lengths MUST be ignored.
* 「Redemption_Context」はオプションのフィールドです。存在する場合、他のコンテキストのためにフェッチされたトークンを再利用するのではなく、クライアントが特定のコンテキストにバインドされたトークンを取得することを要求することができます。たとえば、実際に役立つ可能性のあるコンテキストなど、セクション2.1.1を参照してください。存在する場合、この値は、原点によって生成される32バイトのコンテキストです。このフィールドの有効な長さは、0または32バイトです。フィールドには、長さを示す単一のオクテットが付いています。無効な長さのredemption_context値の課題は無視する必要があります。
* "origin_info" is an optional string containing one or more origin names, which allows a token to be scoped to a specific set of origins. The string is prefixed with a 2-octet integer indicating the length, in network byte order. If empty, any non-origin-specific token can be redeemed. If the string contains multiple origin names, they are delimited with commas "," without any whitespace. If this field is not empty, the Origin MUST include its own name as one of the names in the list.
* 「Origin_info」は、1つ以上のOrigin名を含むオプションの文字列であり、トークンを特定のオリジンセットにスコープすることができます。文字列には、ネットワークバイトの順序で長さを示す2オクテットの整数が付いています。空の場合、非オリジン固有のトークンを引き換えることができます。文字列に複数のオリジン名が含まれている場合、それらはコンマで区切られています。このフィールドが空でない場合、原点にはリスト内の名前の1つとして独自の名前を含める必要があります。
When used in an authentication challenge, the "PrivateToken" scheme uses the following parameters:
認証チャレンジで使用される場合、「privateToken」スキームは次のパラメーターを使用します。
* "challenge", which contains a base64url-encoded [RFC4648] TokenChallenge value. Since the length of the challenge is not fixed, the base64url value MUST include padding. As an Authentication Parameter (auth-param from [RFC9110], Section 11.2), the value can be either a token or a quoted-string, and might be required to be a quoted-string if the base64url string includes "=" characters. This challenge value MUST be unique for every 401 HTTP response to prevent replay attacks. This parameter is required for all challenges.
* base64urlエンコード[RFC4648] TokenChallenge値を含む「Challenge」。チャレンジの長さは固定されていないため、base64url値にはパディングを含める必要があります。認証パラメーター（[RFC9110]のAuth-Param、セクション11.2）として、値はトークンまたは引用符で囲まれたストリングであり、base64url文字列に「=」文字が含まれている場合は引用されたストリングである必要があります。この課題の値は、リプレイ攻撃を防ぐために、401 HTTP応答ごとに一意でなければなりません。このパラメーターは、すべての課題に必要です。
* "token-key", which contains a base64url encoding of the public key for use with the issuance protocol indicated by the challenge. Since the length of the key is not fixed, the base64url value MUST include padding. As an Authentication Parameter (auth-param from [RFC9110], Section 11.2), the value can be either a token or a quoted-string, and might be required to be a quoted-string if the base64url string includes "=" characters. This parameter MAY be omitted in deployments where clients are able to retrieve the issuer key using an out-of-band mechanism.
* 「Token-Key」には、チャレンジで示された発行プロトコルで使用するための公開鍵のbase64urlエンコードが含まれています。キーの長さは固定されていないため、base64url値にはパディングを含める必要があります。認証パラメーター（[RFC9110]のAuth-Param、セクション11.2）として、値はトークンまたは引用符で囲まれたストリングであり、base64url文字列に「=」文字が含まれている場合は引用されたストリングである必要があります。このパラメーターは、クライアントがバンド外のメカニズムを使用して発行者キーを取得できる展開で省略される場合があります。
* "max-age", an optional parameter that consists of the number of seconds for which the challenge will be accepted by the origin.
* 「Max-age」は、課題が起源によって受け入れられる秒数で構成されるオプションのパラメーターです。
Clients can ignore the challenge if the token-key is invalid or otherwise untrusted.
クライアントは、トークンキーが無効であるか、信頼されていない場合、課題を無視できます。
The header field MAY also include the standard "realm" parameter, if desired. Issuance protocols MAY require other parameters. Clients SHOULD ignore unknown parameters in challenges, except if otherwise specified by issuance protocols.
ヘッダーフィールドには、必要に応じて標準の「レルム」パラメーターを含めることもできます。発行プロトコルには、他のパラメーターが必要になる場合があります。クライアントは、発行プロトコルによって特に指定されている場合を除き、課題の不明なパラメーターを無視する必要があります。
As an example, the WWW-Authenticate header field could look like this:
例として、www-authenticateヘッダーフィールドは次のようになります。
WWW-Authenticate: PrivateToken challenge="abc...", token-key="123..."
Upon receipt of this challenge, a client uses the message and keys in the issuance protocol indicated by the token_type. If the TokenChallenge has a token_type the client does not recognize or support, it MUST NOT parse or respond to the challenge. If the TokenChallenge contains a non-empty origin_info field, the client MUST validate that the name of the origin that issued the authentication challenge is included in the list of origin names; if validation fails, the client MUST NOT process or respond to the challenge. Clients MAY have further restrictions and requirements around validating when a challenge is considered acceptable or valid. For example, clients can choose to ignore challenges that list origin names for which current connection is not authoritative (according to the TLS certificate).
この課題を受け取ると、クライアントはtoken_typeで示される発行プロトコルでメッセージとキーを使用します。TokenChallengeにtoken_Typeがある場合、クライアントは認識またはサポートしていません。チャレンジに解析または応答してはなりません。TokenChallengeに空白のOrigin_Infoフィールドが含まれている場合、クライアントは、認証チャレンジを発行したオリジンの名前がOrigin名のリストに含まれていることを検証する必要があります。検証が失敗した場合、クライアントはチャレンジに処理または応答してはなりません。クライアントは、チャレンジが許容可能または有効であると見なされる場合の検証に関するさらなる制限と要件を持っている場合があります。たとえば、クライアントは、現在の接続が信頼できるものではない原点名をリストする課題を無視することを選択できます（TLS証明書によると）。
Caching and pre-fetching of tokens is discussed in Section 2.1.2.
トークンのキャッシュと事前フェッチについては、セクション2.1.2で説明します。
Note that it is possible for the WWW-Authenticate header field to include multiple challenges. This allows the origin to indicate support for different token types, issuers, or to include multiple redemption contexts. For example, the WWW-Authenticate header field could look like this:
www-authenticateヘッダーフィールドが複数の課題を含めることができることに注意してください。これにより、オリジンはさまざまなトークンタイプ、発行者のサポートを示したり、複数の償還コンテキストを含めることができます。たとえば、www-authenticateヘッダーフィールドは次のようになります。
WWW-Authenticate: PrivateToken challenge="abc...", token-key="123...",
PrivateToken challenge="def...", token-key="234..."
Origins should only include challenges for different types of issuance protocols with functionally equivalent properties. For instance, both issuance protocols in [ISSUANCE] have the same functional properties, albeit with different mechanisms for verifying the resulting tokens during redemption. Since clients are free to choose which challenge they want to consume when presented with options, mixing multiple challenges with different functional properties for one use case is nonsensical.
Originsには、機能的に同等のプロパティを備えたさまざまな種類の発行プロトコルの課題のみを含める必要があります。たとえば、[発行]の両方の発行プロトコルには、償還中に結果のトークンを検証するためのさまざまなメカニズムがありますが、同じ機能特性があります。クライアントはオプションを提示したときに消費する課題を自由に選択できるため、1つのユースケースの異なる機能特性と複数の課題を混合することは無意味です。
The TokenChallenge redemption context allows the origin to determine the context in which a given token can be redeemed. This value can be a unique per-request nonce, constructed from 32 freshly generated random bytes. It can also represent state or properties of the client session. Some example properties and methods for constructing the corresponding context are below. This list is not exhaustive.
TokenChallenge Redemptionコンテキストにより、原点は特定のトークンを引き換えることができるコンテキストを決定できます。この値は、32の新たに生成されたランダムバイトから構築された一意の要求ごとのノンセになります。また、クライアントセッションの状態またはプロパティを表すこともできます。対応するコンテキストを構築するためのいくつかの例のプロパティと方法は以下にあります。このリストは網羅的ではありません。
* Context bound to a given time window: Construct redemption context as SHA256(current time window).
* 特定の時間ウィンドウにバインドされたコンテキスト：SHA256（現在の時間ウィンドウ）として償還コンテキストを構築します。
* Context bound to a client location: Construct redemption context as SHA256(client IP address prefix).
* クライアントにバインドされたコンテキスト場所：SHA256（クライアントIPアドレスプレフィックス）としてredいコンテキストを構築します。
* Context bound to a given time window and location: Construct redemption context as SHA256(current time window, client IP address prefix).
* 特定の時間ウィンドウと場所にバインドされたコンテキスト：redemptionコンテキストをSHA256として構築します（現在の時間ウィンドウ、クライアントIPアドレスプレフィックス）。
An empty redemption context is not bound to any property of the client session. Preventing double spending on tokens requires the origin to keep state associated with the redemption context. The size of this state varies based on the size of the redemption context. For example, double spend state for unique, per-request redemption contexts does only needs to exist within the scope of the request connection or session. In contrast, double spend state for empty redemption contexts must be stored and shared across all requests until token-key expiration or rotation.
空の償還コンテキストは、クライアントセッションのどのプロパティにも拘束されません。トークンへの二重支出を防ぐには、redいのコンテキストに状態を維持するために起源が必要です。この状態のサイズは、償還のコンテキストのサイズに基づいて異なります。たとえば、一意の要求償還コンテキストの一意の支出状態は、リクエスト接続またはセッションの範囲内でのみ存在する必要があります。対照的に、空の償還のコンテキストのための二重支出状態は、トークンキーの有効期限またはローテーションまで、すべての要求で保存および共有する必要があります。
Origins that share redemption contexts, i.e., by using the same redemption context, choosing the same issuer, and providing the same origin_info field in the TokenChallenge, must necessarily share state required to enforce double spend prevention. Origins should consider the operational complexity of this shared state before choosing to share redemption contexts. Failure to successfully synchronize this state and use it for double spend prevention can allow Clients to redeem tokens to one Origin that were issued after an interaction with another Origin that shares the context.
redいのコンテキストを共有する起源、つまり、同じ償還コンテキストを使用し、同じ発行者を選択し、TokenChallengeで同じOrigin_Infoフィールドを提供することにより、二重支出防止を強制するために必要な状態を必然的に共有する必要があります。Originsは、償還のコンテキストを共有することを選択する前に、この共有状態の運用上の複雑さを考慮する必要があります。この状態を正常に同期し、それを使用して二重支出予防に使用することにより、クライアントは、コンテキストを共有する別の起源との相互作用の後に発行された1つの起源にトークンを引き換えることができます。
Clients can generate multiple tokens from a single TokenChallenge, and cache them for future use. This improves privacy by separating the time of token issuance from the time of token redemption, and also allows clients to avoid any overhead of receiving new tokens via the issuance protocol.
クライアントは、単一のTokenChallengeから複数のトークンを生成し、将来の使用のためにそれらをキャッシュできます。これにより、トークン発行の時間をトークン償還時に分離することによりプライバシーが向上し、クライアントは発行プロトコルを介して新しいトークンを受信するオーバーヘッドを回避することができます。
Cached tokens can only be redeemed when they match all of the fields in the TokenChallenge: token_type, issuer_name, redemption_context, and origin_info. Clients ought to store cached tokens based on all of these fields, to avoid trying to redeem a token that does not match. Note that each token has a unique client nonce, which is sent in token redemption (Section 2.2).
キャッシュされたトークンは、tokenchallengeのすべてのフィールドと一致する場合にのみ引き換えます：token_type、yussuer_name、redemption_context、およびovirion_info。クライアントは、これらすべてのフィールドに基づいてキャッシュされたトークンを保存する必要があります。これは、一致しないトークンを引き換えようとしないようにします。各トークンには、トークン償還で送信される一意のクライアントNONCEがあります（セクション2.2）。
If a client fetches a batch of multiple tokens for future use that are bound to a specific redemption context (the redemption_context in the TokenChallenge was not empty), clients SHOULD discard these tokens upon flushing state such as HTTP cookies [COOKIES], or changing networks. Using these tokens in a context that otherwise would not be linkable to the original context could allow the origin to recognize a client.
クライアントが特定のredいコンテキストに拘束される将来の使用のために複数のトークンのバッチを取得した場合（トークンチャレンジのredemption_contextは空ではありませんでした）、クライアントはHTTP Cookie [Cookie]やネットワークの変更などのフラッシュ状態でこれらのトークンを破棄する必要があります。。それ以外の場合は元のコンテキストにリンクできないコンテキストでこれらのトークンを使用すると、オリジンがクライアントを認識できるようになります。
The output of the issuance protocol is a token that corresponds to the origin's challenge (see Section 2.1). A token is a structure that begins with a two-octet field that indicates a token type, which MUST match the token_type in the TokenChallenge structure.
発行プロトコルの出力は、原点の課題に対応するトークンです（セクション2.1を参照）。トークンは、トークンタイプを示す2オクテットのフィールドで始まる構造であり、トークンチャレンジ構造のtoken_typeと一致する必要があります。
struct {
uint16_t token_type;
uint8_t nonce[32];
uint8_t challenge_digest[32];
uint8_t token_key_id[Nid];
uint8_t authenticator[Nk];
} Token;
The structure fields are defined as follows:
構造フィールドは次のように定義されています。
* "token_type" is a 2-octet integer, in network byte order. This value must match the value in the challenge (Section 2.1).
* 「token_type」は、ネットワークバイトの順序で2-OCTET整数です。この値は、チャレンジの値と一致する必要があります（セクション2.1）。
* "nonce" is a 32-octet message containing a client-generated random nonce.
* 「NonCe」は、クライアントで生成されたランダムなNonCEを含む32オクテットメッセージです。
* "challenge_digest" is a 32-octet message containing the hash of the original TokenChallenge, SHA256(TokenChallenge).
* 「Challenge_Digest」は、元のTokenChallengeのハッシュであるSHA256（TokenChallenge）を含む32オクテットメッセージです。
* "token_key_id" is an Nid-octet identifier for the the token authentication key. The value of this field is defined by the token_type and corresponding issuance protocol.
* 「token_key_id」は、トークン認証キーのnid-octet識別子です。このフィールドの値は、token_typeおよび対応する発行プロトコルによって定義されます。
* "authenticator" is a Nk-octet authenticator that covers the preceding fields in the token. The value of this field is defined by the token_type and corresponding issuance protocol.
* 「Authenticator」は、トークンの前のフィールドをカバーするNK-OCTET認証器です。このフィールドの値は、token_typeおよび対応する発行プロトコルによって定義されます。
The authenticator value in the Token structure is computed over the token_type, nonce, challenge_digest, and token_key_id fields.
トークン構造の認証因子値は、token_type、nonce、challenge_digest、およびtoken_key_idフィールドで計算されます。
When used for client authorization, the "PrivateToken" authentication scheme defines one parameter, "token", which contains the base64url-encoded Token struct. Since the length of the Token struct is not fixed, the base64url value MUST include padding. As an Authentication Parameter (auth-param from [RFC9110], Section 11.2), the value can be either a token or a quoted-string, and might be required to be a quoted-string if the base64url string includes "=" characters. All unknown or unsupported parameters to "PrivateToken" authentication credentials MUST be ignored.
クライアント認証に使用される場合、「privateToken」認証スキームは、base64urlエンコードされたトークン構造体を含む1つのパラメーター「トークン」を定義します。トークン構造体の長さは固定されていないため、base64url値にはパディングを含める必要があります。認証パラメーター（[RFC9110]のAuth-Param、セクション11.2）として、値はトークンまたは引用符で囲まれたストリングであり、base64url文字列に「=」文字が含まれている場合は引用されたストリングである必要があります。「privateToken」認証資格情報に対する未知のまたはサポートされていないすべてのパラメーターは無視する必要があります。
Clients present this Token structure to origins in a new HTTP request using the Authorization header field as follows:
クライアントは、このトークン構造を、承認ヘッダーフィールドを次のように使用して、新しいHTTPリクエストの起源に提示します。
Authorization: PrivateToken token="abc..."
承認：privateToken token = "ABC ..."
For token types that support public verifiability, origins verify the token authenticator using the public key of the issuer, and validate that the signed message matches the concatenation of the client nonce and the hash of a valid TokenChallenge. For context-bound tokens, origins store or reconstruct the contexts of previous TokenChallenge structures in order to validate the token. A TokenChallenge MAY be bound to a specific TLS session with a client, but origins can also accept tokens for valid challenges in new sessions. Origins SHOULD implement some form of double-spend prevention that prevents a token with the same nonce from being redeemed twice. This prevents clients from "replaying" tokens for previous challenges. For context-bound tokens, this double-spend prevention can require no state or minimal state, since the context can be used to verify token uniqueness.
パブリックの検証可能性をサポートするトークンタイプの場合、Originsは発行者の公開鍵を使用してトークン認証器を検証し、署名されたメッセージがクライアントNonceの連結と有効なTokenChallengeのハッシュと一致することを検証します。コンテキストに縛られたトークンの場合、トークンを検証するために、以前のtokenchallenge構造のコンテキストを起源または再構築します。TokenChallengeは、クライアントとの特定のTLSセッションにバインドされる場合がありますが、Originsは新しいセッションで有効な課題についてトークンを受け入れることもできます。Originsは、同じ非CEが2回償還されるのを防ぐトークンを防ぐ、何らかの形の二重の支出予防を実装する必要があります。これにより、クライアントは以前の課題のためにトークンを「リプレイ」することを防ぎます。コンテキストに縛られたトークンの場合、コンテキストを使用してトークンの一意性を検証することができるため、この二重の支出予防には状態または最小状態を必要としません。
If a client is unable to fetch a token, it MUST react to the challenge as if it could not produce a valid Authorization response.
クライアントがトークンを取得できない場合、有効な承認応答を作成できないかのように、チャレンジに反応する必要があります。
When used in contexts like websites, origins that challenge clients for tokens need to consider how to optimize their interaction model to ensure a good user experience.
Webサイトなどのコンテキストで使用する場合、トークンのクライアントに挑戦するOriginsは、ユーザーエクスペリエンスを確保するために相互作用モデルを最適化する方法を検討する必要があります。
Tokens challenges can be performed without explicit user involvement, depending on the issuance protocol. If tokens are scoped to a specific origin, there is no need for per-challenge user interaction. Note that the issuance protocol may separately involve user interaction if the client needs to be newly validated.
トークンの課題は、発行プロトコルに応じて、明示的なユーザーの関与なしに実行できます。トークンが特定の起源にスコープされている場合、チャレンジごとのユーザーインタラクションは必要ありません。クライアントを新たに検証する必要がある場合、発行プロトコルにはユーザーインタラクションが個別に含まれる場合があることに注意してください。
If a client cannot use cached tokens to respond to a challenge (either because it has run out of cached tokens or the associated context is unique), the token issuance process can add user-perceivable latency. Origins need not block useful work on token authentication. Instead, token authentication can be used in similar ways to CAPTCHA validation today, but without the need for user interaction. If issuance is taking a long time, a website could show an indicator that it is waiting, or fall back to another method of user validation.
クライアントがキャッシュされたトークンを使用してチャレンジに応答できない場合（キャッシュされたトークンが不足しているか、関連するコンテキストが一意であるため）、トークン発行プロセスはユーザーの知覚可能なレイテンシを追加できます。Originsは、トークン認証で有用な作業をブロックする必要はありません。代わりに、トークン認証は、今日のCaptCha検証と同様の方法で使用できますが、ユーザーインタラクションは必要ありません。発行に長い時間がかかっている場合、ウェブサイトは、待っていることを示す指標を示すか、ユーザー検証の別の方法に戻ることができます。
An origin MUST NOT use more than one redemption context value for a given token type and issuer per client request. If an origin issues a large number of challenges with unique contexts, such as more than once for each request, this can indicate that the origin is either not functioning correctly or is trying to attack or overload the client or issuance server. In such cases, a client MUST ignore redundant token challenges for the same request and SHOULD alert the user if possible.
オリジンは、特定のトークンタイプに複数の償還コンテキスト値とクライアント要求ごとに発行者を使用してはなりません。オリジンが各リクエストに対して1回以上のような一意のコンテキストで多数の課題を発行する場合、これはオリジンが正しく機能していないか、クライアントまたは発行サーバーを攻撃または過負荷にしようとしていることを示します。そのような場合、クライアントは同じ要求に対して冗長トークンの課題を無視する必要があり、可能であればユーザーに警告する必要があります。
Origins MAY include multiple challenges, where each challenge refers to a different issuer or a different token type, to allow clients to choose a preferred issuer or type.
Originsには、各チャレンジが異なる発行者または異なるトークンタイプを指し、クライアントが優先発行者またはタイプを選択できるようにする複数の課題が含まれる場合があります。
An origin MUST NOT assume that token challenges will always yield a valid token. Clients might experience issues running the issuance protocol, e.g., because the attester or issuer is unavailable, or clients might simply not support the requested token type. Origins SHOULD account for such operational or interoperability failures by offering clients an alternative type of challenge such as CAPTCHA for accessing a resource.
起源は、トークンの課題が常に有効なトークンを生成すると仮定してはなりません。クライアントは、Attesterまたは発行者が利用できない場合や、クライアントが単に要求されたトークンタイプをサポートしていない場合があるため、発行プロトコルの実行に問題が発生する場合があります。Originsは、リソースにアクセスするためのCaptchaなどの代替タイプの課題をクライアントに提供することにより、そのような運用性または相互運用性の障害を説明する必要があります。
For example, consider a scenario in which the client is a web browser, and the origin can accept either a token or a solution to a puzzle intended to determine if the client is a real human user. The origin would send clients a 401 HTTP response that contains a token challenge in a "WWW-Authenticate" header field along with content that contains the puzzle to display to the user. Clients that are able to respond with a token will be able to automatically return the token and not show the puzzle, while clients that either do not support tokens or are unable to fetch tokens at a particular time can present the user with the puzzle.
たとえば、クライアントがWebブラウザーであり、オリジンがトークンまたはクライアントが実際の人間のユーザーであるかどうかを判断するためのパズルのソリューションのいずれかを受け入れることができるシナリオを検討します。Originは、ユーザーに表示するパズルを含むコンテンツとともに、「www-authenticate」ヘッダーフィールドにトークンチャレンジを含む401 HTTP応答をクライアントに送信します。トークンで応答できるクライアントは、トークンを自動的に返すことができ、パズルを表示できませんが、トークンをサポートしていないか、特定の時間にトークンをフェッチできないクライアントは、ユーザーにパズルを提示できます。
To mitigate the risk of deployments becoming dependent on tokens, clients and servers SHOULD grease their behavior unless explicitly configured not to. In particular, clients SHOULD ignore token challenges with some non-zero probability. Likewise, origins SHOULD randomly choose to not challenge clients for tokens with some non-zero probability. Moreover, origins SHOULD include random token types, from the Reserved list of "greased" types (defined in Section 5.2), with some non-zero probability.
トークンに依存する展開のリスクを軽減するために、クライアントとサーバーは、明示的に構成されていない限り、動作をグリース化する必要があります。特に、クライアントはゼロ以外の確率でトークンの課題を無視する必要があります。同様に、Originsは、ゼロ以外の確率でトークンのクライアントに挑戦しないことをランダムに選択する必要があります。さらに、Originsには、「グリースされた」タイプの予約リスト（セクション5.2で定義）のランダムトークンタイプを含める必要があり、ゼロ以外の確率があります。
The security properties of token challenges vary depending on whether the challenge contains a redemption context or not, as well as whether the challenge is per-origin or not. For example, cross-origin tokens with empty contexts can be replayed from one party by another, as shown below.
トークンの課題のセキュリティプロパティは、課題に償還のコンテキストが含まれているかどうかによって異なります。たとえば、空のコンテキストを持つクロスオリジントークンは、以下に示すように、あるパーティーから別のパーティによって再生できます。
Client Attacker Origin
<----------- Challenge \
|
<--------- Challenge |
|
Redemption ----> |
|
Redemption ----------> /
Figure 2: Token Architectural Components
図2：トークンアーキテクチャコンポーネント
Token challenges that include non-empty origin_info bind tokens to one or more specific origins. As described in Section 2.1, clients only accept such challenges from origin names listed in the origin_info string. Even if multiple origins are listed, a token can only be redeemed for an origin if the challenge has an exact match for the origin_info. For example, if "a.example.com" issues a challenge with an origin_info string of "a.example.com,b.example.com", a client could redeem a token fetched for this challenge if and only if "b.example.com" also included an origin_info string of "a.example.com,b.example.com". On the other hand, if "b.example.com" had an origin_info string of "b.example.com" or "b.example.com,a.example.com" or "a.example.com,b.example.com,c.example.com", the string would not match and the client would need to use a different token.
非空白のOrigin_infoを含むトークンの課題は、トークンを1つ以上の特定の起源にバインドします。セクション2.1で説明されているように、クライアントはOrigin_Info文字列にリストされているOrigin名からそのような課題のみを受け入れます。複数の起源がリストされていても、課題がOrigin_Infoと正確に一致している場合にのみ、トークンを起源と引き換えることができます。たとえば、「a.example.com」が「a.example.com、b.example.com」のOrigin_info文字列でチャレンジを発行する場合、クライアントは「b。example.com「a.example.com、b.example.com」のOrigin_info文字列も含まれています。一方、「b.example.com」に「b.example.com」または「b.example.com、a.example.com」または「a.example.com、b.example」のOrigin_info文字列があった場合.com、c.example.com "、文字列は一致せず、クライアントは別のトークンを使用する必要があります。
Context-bound token challenges require clients to obtain matching tokens when challenged, rather than presenting a token that was obtained from a different context in the past. This can make it more likely that issuance and redemption events will occur at approximately the same time. For example, if a client is challenged for a token with a unique context at time T1 and then subsequently obtains a token at time T2, a colluding issuer and origin can link this to the same client if T2 is unique to the client. This linkability is less feasible as the number of issuance events at time T2 increases. Depending on the "max-age" token challenge parameter, clients MAY try to augment the time between getting challenged then redeeming a token so as to make this sort of linkability more difficult. For more discussion on correlation risks between token issuance and redemption, see [I-D.ietf-privacypass-architecture].
コンテキストに縛られたトークンの課題では、過去に別のコンテキストから取得したトークンを提示するのではなく、クライアントが挑戦したときに一致するトークンを取得する必要があります。これにより、発行と償還のイベントがほぼ同時に発生する可能性が高くなります。たとえば、クライアントが時間T1で一意のコンテキストを持つトークンに挑戦され、その後T2でトークンを取得する場合、T2がクライアントに固有の場合、発行者と原産地が同じクライアントにこれをリンクできます。このリンク可能性は、時間T2の発行イベントの数が増加するため、実現可能性が低くなります。「最大時代」のトークンチャレンジパラメーターに応じて、クライアントは、この種のリンク可能性をより困難にするために、挑戦を受けてからトークンを引き換えるまでの時間を増やそうとする場合があります。トークン発行と償還の相関リスクに関する詳細については、[i-d.ietf-privacypass-architecture]を参照してください。
As discussed in Section 2.1, clients SHOULD discard any context-bound tokens upon flushing cookies or changing networks, to prevent an origin using the redemption context state as a cookie to recognize clients.
セクション2.1で説明したように、クライアントはクッキーのフラッシュまたはネットワークの変更時にコンテキストに縛られたトークンを破棄し、クライアントを認識するためのCookieとしてredいコンテキスト状態を使用する起源を防ぐ必要があります。
Applications SHOULD constrain tokens to a single origin unless the use case can accommodate such replay attacks. Replays are also possible if the client redeems a token sent as part of 0-RTT data. If successful token redemption produces side effects, origins SHOULD implement an anti-replay mechanism to mitigate the harm of such replays. See [RFC8446], Section 8 and [RFC9001], Section 9.2 for details about anti-replay mechanisms, as well as [RFC8470], Section 3 for discussion about safety considerations for 0-RTT HTTP data.
アプリケーションは、ユースケースがそのようなリプレイ攻撃に対応できない限り、トークンを単一の起源に制限する必要があります。クライアントが0-RTTデータの一部として送信されたトークンを引き換えると、リプレイも可能です。トークン償還が成功した場合、Originsはそのようなリプレイの害を軽減するためのアンチレプレイメカニズムを実装する必要があります。[RFC8446]、セクション8および[RFC9001]、セクション9.2、アンチレプレイメカニズムの詳細については、[RFC8470]、セクション3、0-RTT HTTPデータの安全性に関する考慮事項についての議論を参照してください。
All random values in the challenge and token MUST be generated using a cryptographically secure source of randomness.
チャレンジとトークンのすべてのランダム値は、暗号化されたランダム性のソースを使用して生成する必要があります。
This document registers the "PrivateToken" authentication scheme in the "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" defined in [RFC9110], Section 16.4.
このドキュメントは、[RFC9110]、セクション16.4で定義されている「ハイパーテキスト転送プロトコル（HTTP）認証スキームレジストリ」の「privateToken」認証スキームを登録します。
Authentication Scheme Name: PrivateToken
認証スキーム名：privatetoken
Pointer to specification text: Section 2 of this document
仕様テキストへのポインタ：このドキュメントのセクション2
IANA is requested to create a new "Privacy Pass Token Type" registry in a new "Privacy Pass Parameters" page to list identifiers for issuance protocols defined for use with the Privacy Pass token authentication scheme. These identifiers are two-byte values, so the maximum possible value is 0xFFFF = 65535.
IANAは、プライバシーパストークン認証スキームで使用するために定義された発行プロトコルの識別子をリストするために、新しい「プライバシーパスパラメーター」ページに新しい「プライバシーパストークンタイプ」レジストリを作成するように要求されています。これらの識別子は2バイト値であるため、最大値は0xffff = 65535です。
Template:
テンプレート：
* Value: The two-byte identifier for the algorithm
* 値：アルゴリズムの2バイト識別子
* Name: Name of the issuance protocol
* 名前：発行プロトコルの名前
* Publicly Verifiable: A Y/N value indicating if the output tokens are publicly verifiable
* 公開可能：出力トークンが公開されているかどうかを示すy/n値
* Public Metadata: A Y/N value indicating if the output tokens can contain public metadata.
* パブリックメタデータ：出力トークンにパブリックメタデータを含めることができるかどうかを示すY/N値。
* Private Metadata: A Y/N value indicating if the output tokens can contain private metadata.
* プライベートメタデータ：出力トークンにプライベートメタデータを含めることができるかどうかを示すY/N値。
* Nk: The length in bytes of an output authenticator
* NK：出力認証器のバイトの長さ
* Nid: The length of the token key identifier
* NID：トークンキー識別子の長さ
* Reference: Where this algorithm is defined
* 参照：このアルゴリズムが定義されている場合
* Notes: Any notes associated with the entry New entries in this registry are subject to the Specification Required registration policy ([RFC8126], Section 4.6). Designated experts need to ensure that the token type is sufficiently clearly defined to be used for both token issuance and redemption, and meets the common security and privacy requirements for issuance protocols defined in Section 3.2 of [ARCHITECTURE].
* 注：このレジストリのエントリに関連する新しいエントリに関連するメモは、必要な登録ポリシー（[RFC8126]、セクション4.6）の仕様の対象となります。指定された専門家は、トークンタイプがトークンの発行と償還の両方に使用されるように十分に明確に定義され、[アーキテクチャ]のセクション3.2で定義されている発行プロトコルの共通のセキュリティおよびプライバシー要件を満たすことを保証する必要があります。
This registry also will also allow provisional registrations to allow for experimentation with protocols being developed. Designated experts review, approve, and revoke provisional registrations.
また、このレジストリでは、暫定的な登録がプロトコルが開発されている実験を可能にすることもできます。指定された専門家は、暫定登録をレビュー、承認、および取り消します。
Values 0xFF00-0xFFFF are reserved for private use, to enable proprietary uses and limited experimentation.
値0xff00-0xffffは、独自の用途と限られた実験を可能にするために、私的使用のために予約されています。
This document defines several Reserved values, which can be used by clients and servers to send "greased" values in token challenges and responses to ensure that implementations remain able to handle unknown token types gracefully (this technique is inspired by [RFC8701]). Implemenations SHOULD select reserved values at random when including them in greased messages. Servers can include these in TokenChallenge structures, either as the only challenge when no real token type is desired, or as one challenge in a list of challenges that include real values. Clients can include these in Token structures when they are not able to present a real token response. The contents of the Token structure SHOULD be filled with random bytes when using greased values.
このドキュメントでは、いくつかの予約された値を定義します。クライアントとサーバーは、トークンの課題と応答で「グリースした」値を送信して、実装が不明なトークンタイプを優雅に処理できるようにすることができます（この手法は[RFC8701]に触発されています）。インプレメントは、グリース化されたメッセージにそれらを含めるときに、予約値をランダムに選択する必要があります。サーバーは、これらをTokenChallenge構造に含めることができます。実際のトークンタイプが望まれない場合の唯一の課題として、または実際の値を含む課題のリストの1つの課題として。クライアントは、実際のトークン応答を提示できない場合、これらをトークン構造に含めることができます。トークン構造の内容は、グリースされた値を使用する場合、ランダムバイトで満たす必要があります。
The initial contents for this registry are defined in the table below.
このレジストリの初期内容は、以下の表に定義されています。
+=============+========+==========+========+========+==+===+=========+=====+
|Value |Name |Publicly |Public |Private |Nk|Nid|Reference|Notes|
| | |Verifiable|Metadata|Metadata| | | | |
+=============+========+==========+========+========+==+===+=========+=====+
|0x0000 |RESERVED|N/A |N/A |N/A |N/|N/A|This |None |
| | | | | |A | |document | |
+-------------+--------+----------+--------+--------+--+---+---------+-----+
|0x02AA |RESERVED|N/A |N/A |N/A |N/|N/A|This |None |
| | | | | |A | |document | |
+-------------+--------+----------+--------+--------+--+---+---------+-----+
|0x1132 |RESERVED|N/A |N/A |N/A |N/|N/A|This |None |
| | | | | |A | |document | |
+-------------+--------+----------+--------+--------+--+---+---------+-----+
|0x2E96 |RESERVED|N/A |N/A |N/A |N/|N/A|This |None |
| | | | | |A | |document | |
+-------------+--------+----------+--------+--------+--+---+---------+-----+
|0x3CD3 |RESERVED|N/A |N/A |N/A |N/|N/A|This |None |
| | | | | |A | |document | |
+-------------+--------+----------+--------+--------+--+---+---------+-----+
|0x4473 |RESERVED|N/A |N/A |N/A |N/|N/A|This |None |
| | | | | |A | |document | |
+-------------+--------+----------+--------+--------+--+---+---------+-----+
|0x5A63 |RESERVED|N/A |N/A |N/A |N/|N/A|This |None |
| | | | | |A | |document | |
+-------------+--------+----------+--------+--------+--+---+---------+-----+
|0x6D32 |RESERVED|N/A |N/A |N/A |N/|N/A|This |None |
| | | | | |A | |document | |
+-------------+--------+----------+--------+--------+--+---+---------+-----+
|0x7F3F |RESERVED|N/A |N/A |N/A |N/|N/A|This |None |
| | | | | |A | |document | |
+-------------+--------+----------+--------+--------+--+---+---------+-----+
|0x8D07 |RESERVED|N/A |N/A |N/A |N/|N/A|This |None |
| | | | | |A | |document | |
+-------------+--------+----------+--------+--------+--+---+---------+-----+
|0x916B |RESERVED|N/A |N/A |N/A |N/|N/A|This |None |
| | | | | |A | |document | |
+-------------+--------+----------+--------+--------+--+---+---------+-----+
|0xA6A4 |RESERVED|N/A |N/A |N/A |N/|N/A|This |None |
| | | | | |A | |document | |
+-------------+--------+----------+--------+--------+--+---+---------+-----+
|0xBEAB |RESERVED|N/A |N/A |N/A |N/|N/A|This |None |
| | | | | |A | |document | |
+-------------+--------+----------+--------+--------+--+---+---------+-----+
|0xC3F3 |RESERVED|N/A |N/A |N/A |N/|N/A|This |None |
| | | | | |A | |document | |
+-------------+--------+----------+--------+--------+--+---+---------+-----+
|0xDA42 |RESERVED|N/A |N/A |N/A |N/|N/A|This |None |
| | | | | |A | |document | |
+-------------+--------+----------+--------+--------+--+---+---------+-----+
|0xE944 |RESERVED|N/A |N/A |N/A |N/|N/A|This |None |
| | | | | |A | |document | |
+-------------+--------+----------+--------+--------+--+---+---------+-----+
|0xF057 |RESERVED|N/A |N/A |N/A |N/|N/A|This |None |
| | | | | |A | |document | |
+-------------+--------+----------+--------+--------+--+---+---------+-----+
|0xFF00-0xFFFF|Private |N/A |N/A |N/A |N/|N/A|This |None |
| |Use | | | |A | |document | |
+-------------+--------+----------+--------+--------+--+---+---------+-----+
Table 1: Token Types
表1：トークンタイプ
[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/rfc/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487/RFC2119、1997年3月、<https://www.rfc-editor.org/rfc/RFC2119>。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/rfc/rfc4648>.
[RFC4648] Josefsson、S。、「Base16、Base32、およびBase64 Data Encodings」、RFC 4648、DOI 10.17487/RFC4648、2006年10月、<https://www.rfc-editor.org/rfc/rfc4648>
[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/rfc/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/rfc/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/rfc/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487/RFC8174、2017年5月、<https：//www.rfc-editor.org/rfc/RFC8174>。
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/rfc/rfc9110>.
[RFC9110] Fielding、R.、Ed。、Ed。、Nottingham、M.、Ed。、およびJ. Reschke、ed。、 "HTTP Semantics"、Std 97、RFC 9110、DOI 10.17487/RFC9110、2022年6月、<https：//www.rfc-editor.org/rfc/rfc9110>。
[TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/rfc/rfc8446>.
[TLS13] Rescorla、E。、「輸送層セキュリティ（TLS）プロトコルバージョン1.3」、RFC 8446、DOI 10.17487/RFC8446、2018年8月、<https://www.rfc-editor.org/rfc/rfc846>
[ARCHITECTURE] Davidson, A., Iyengar, J., and C. A. Wood, "The Privacy Pass Architecture", Work in Progress, Internet-Draft, draft-ietf-privacypass-architecture-09, 8 December 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-privacypass-architecture-09>.
[アーキテクチャ] Davidson、A.、Iyengar、J。、およびC. A. Wood、「プライバシーパスアーキテクチャ」、進行中の作業、インターネットドラフト、Draft-Itef-Privacypass-Architecture-09、2022年12月8日、<https：//datatracker.ietf.org/doc/html/draft-iitf-privacypass-architecture -09>。
[COOKIES] Bingler, S., West, M., and J. Wilander, "Cookies: HTTP State Management Mechanism", Work in Progress, Internet-Draft, draft-ietf-httpbis-rfc6265bis-11, 7 November 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis-11>.
[Cookies] Bingler、S.、West、M。、およびJ. Wilander、「Cookies：HTTP State Managementメカニズム」、進行中の作業、インターネットドラフト、Draft-ITTPBIS-RFC6265BIS-11、2022年11月7日、<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis11>。
[I-D.ietf-privacypass-architecture] Davidson, A., Iyengar, J., and C. A. Wood, "The Privacy Pass Architecture", Work in Progress, Internet-Draft, draft-ietf-privacypass-architecture-09, 8 December 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-privacypass-architecture-09>.
[I-D.IETF-PRIVACYPASS-ARCHITECTURE] Davidson、A.、Iyengar、J。、およびC. A. Wood、「プライバシーパスアーキテクチャ」、Work in Progress、Internet-Draft、Draft-Itef-Privacypass-Architecture-09、1月8日12月8日2022、<https://datatracker.ietf.org/doc/html/draft-ietf-privacypass-architecture-09>。
[ISSUANCE] Celi, S., Davidson, A., Faz-Hernandez, A., Valdez, S., and C. A. Wood, "Privacy Pass Issuance Protocol", Work in Progress, Internet-Draft, draft-ietf-privacypass-protocol-06, 6 July 2022, <https://datatracker.ietf.org/doc/html/ draft-ietf-privacypass-protocol-06>.
[発行] Celi、S.、Davidson、A.、Faz-Hernandez、A.、Valdez、S.、およびC. A. Wood、「Privacy Pass Issuance Protocol」、Work in Progress、Internet-Draft、Draft-IT-Privacypass-Protocol-06、2022年7月6日、<https://datatracker.ietf.org/doc/html/ draft-ietf-privacypass-protocol-06>。
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/rfc/rfc8446>.
[RFC8446] Rescorla、E。、「輸送層セキュリティ（TLS）プロトコルバージョン1.3」、RFC 8446、DOI 10.17487/RFC8446、2018年8月、<https://www.rfc-editor.org/rfc/RFC846>
[RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September 2018, <https://www.rfc-editor.org/rfc/rfc8470>.
[RFC8470] Thomson、M.、Nottingham、M.、およびW. Tarreau、「HTTPで初期データを使用」、RFC 8470、DOI 10.17487/RFC8470、2018年9月、<https://www.rfc-edtion.org/g/RFC/RFC8470>。
[RFC8701] Benjamin, D., "Applying Generate Random Extensions And Sustain Extensibility (GREASE) to TLS Extensibility", RFC 8701, DOI 10.17487/RFC8701, January 2020, <https://www.rfc-editor.org/rfc/rfc8701>.
[RFC8701]ベンジャミン、D。、「ランダム拡張を生成し、TLS拡張性（グリース）をTLS拡張性に維持する」、RFC 8701、DOI 10.17487/RFC8701、2020年1月、<https：//www.rfc-editor.org/rfc/RFC8701>。
[RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, <https://www.rfc-editor.org/rfc/rfc9001>.
[RFC9001] Thomson、M.、ed。and S. Turner、ed。、「TLSを使用してQUICを確保する」、RFC 9001、DOI 10.17487/RFC9001、2021年5月、<https://www.rfc-editor.org/rfc/rfc9001>。
This section includes test vectors for the challenge and redemption functionalities described in Section 2.1 and Section 2.2. Each test vector lists the following values:
このセクションには、セクション2.1およびセクション2.2で説明されているチャレンジおよび償還機能のテストベクトルが含まれています。各テストベクトルには、次の値がリストされています。
* token_type: The type of token issuance protocol, a value from Section 5.2. For these test vectors, token_type is 0x0002, corresponding to the issuance protocol in [ISSUANCE].
* token_type：トークン発行プロトコルのタイプ、セクション5.2からの値。これらのテストベクトルの場合、token_typeは[発行]の発行プロトコルに対応する0x0002です。
* issuer_name: The name of the issuer in the TokenChallenge structure, represented as a hexadecimal string.
* Issuer_Name：TokenChallenge構造の発行者の名前は、16進文字列として表されます。
* redemption_context: The redemption context in the TokenChallenge structure, represented as a hexadecimal string.
* Redemption_Context：TokenChallenge構造のredいコンテキストは、16進列として表されます。
* origin_info: The origin info in the TokenChallenge structure, represented as a hexadecimal string.
* Origin_info：TokenChallenge構造のOrigin Infoは、16進列として表されます。
* nonce: The nonce in the Token structure, represented as a hexadecimal string.
* Nonce：トークン構造のノンセは、16進列文字列として表されます。
* token_key: The public token-key, encoded based on the corresponding token type, represented as a hexadecimal string.
* token_key：対応するトークンタイプに基づいてエンコードされたパブリックトークンキーは、16進数文字列として表されます。
* token_authenticator_input: The values in the Token structure used to compute the Token authenticator value, represented as a hexadecimal string.
* token_authenticator_input：トークンの認証因子値を計算するために使用されるトークン構造の値（16進文字列として表されます）。
* token_authenticator: The output Token authenticator which verifies under token_key, represented as a hexadecimal string.
* token_authenticator：token_keyで検証する出力トークン認証器は、16進数文字列として表されます。
Test vectors are provided for each of the following TokenChallenge configurations:
テストベクトルは、次のTokenChallenge構成のそれぞれに提供されます。
* TokenChallenge with a single origin and non-empty redemption context
* TokenChallenge単一の起源と空でない償還のコンテキストを備えています
* TokenChallenge with a single origin and empty redemption context
* 単一の起源と空のredいのコンテキストを備えたtokenchallenge
* TokenChallenge with an empty origin and redemption context
* 空の起源とredいのコンテキストを備えたtokenchallenge
* TokenChallenge with an empty origin and redemption context
* 空の起源とredいのコンテキストを備えたtokenchallenge
* TokenChallenge with an empty origin and non-empty redemption context
* 空の起源と空でないredいのコンテキストを備えたtokenchallenge
* TokenChallenge with a multiple origins and non-empty redemption context
* 複数の起源と空でないredいのコンテキストを備えたtokenchallenge
These test vectors are below.
これらのテストベクトルは以下にあります。
token_type: 2
issuer_name: 6973737565722e6578616d706c65
redemption_context:
40ff3cdc296a1e823f43b49355df1a2ee4c5f65e5d38ebb3e24ecf4d874997c6
origin_info: 6f726967696e2e6578616d706c65
nonce: 4437fb872eab95b5831a5d01005ee2995e417862ecfd2079ee4c246859a060ae
token_key: 30820252303d06092a864886f70d01010a3030a00d300b060960864801650
3040202a11a301806092a864886f70d010108300b0609608648016503040202a20302013
00382020f003082020a0282020100d730ce8b3ec7336b48a4f5897564d87c87627298f21
ba4bf34e7931142875c0e52c5aef3222d67e86124403e436d0136ebd806de37730427f81
4f7f0485eace93015471d14e56f3824e8bc5fbe44cf67e241c7642ac3a39452a283ff806
84ddbd66929a371d01e50feef1faee7f63f3ceb4b5ceacb939e06a558c2a6bccfd96fb74
16d3edce151bc7b0a6582f0ce99a7c0e7d5793b13d41292105e510e1aa00e082975a1386
6dfaf3a0a51c0dd1ecb64cc55cc607ca1813b5f91fd8e9cb9db18ffd81ac985a6cfdd5cc
2a0b8a5e4e9fa1ea5f149c1662155bb071c95218cae9ae4af613351baf470b1597bb984c
5ea8326f98aff64f72b60bcd035f6b970eb6edd2f9f2180d5aa8a17ed400056af3faa520
4b73c89b4eada6a057dd3dda9d8e18b3a6d2347c1027e2711f21eb7d96fef50cc3dacb2f
5ccc36e4c138ab75953974ade74982f85b91f419654d390378e2ea5aae33f1b4acf534d0
6de2f114acfdd88d6d708f4d2b646a8112b0fe181489916e2ba5c634cdf9b95762d1e120
169482dd27f959132705079fc4a00eee1f353a81c1e810ade20d070d839277169e09150c
08605afe7cea2aec41d2f85c2af7bef5d577343b4385e2c6c159926c1c8267d00433b88b
ad314a5ddcef58936126f1dd8da7b5728da192f54b304e60f4088e5b0620404f82a5939d
975e6714453a533c172c8a9b4b5da976ea60a5aa91fef0203010001
token_authenticator_input: 00024437fb872eab95b5831a5d01005ee2995e417862e
cfd2079ee4c246859a060ae055038620bd58190f057b86af2883352fd9ec612487979b00
74a489aece337e79f9293b4d62e4b4759af064df8fa5759c79ab51a00f692541b26d466d
ab48091
token_authenticator: 9c2fc25cb429a7cfe6e21193b6122ffe18c2c09c1df10dfea3d
155c297ce3f4132d273bf2ad490c41e592219bb253378c21215657905fe713aca31f6ab7
1206c1c872210c71d53a8d9b3ee635cf22c47d518454f9f5a898218ed7aae78414e9d85f
4a62244babdb63accc1257f1f1824493549465a3c63d69e9e307a328121402022a4f1aea
a7e6ff46edf4884b5ab47531b8c949a225a9f5a9c1b7608af0641c2070533402683e6f86
d547b6083d6cfa2a985f4673bf46ae09864d31613acd5a7d61dae7a29133e37093baabe1
20e59714d662162324406403c1fb44312b03c509202041a44dc351ea3659d446ea024e96
23b522171d9af0c8ac81f8a6a0018cb049bda21d12c9783ae6f7057144f8d26699d20f19
023269256ff607ca1ab37b0d95704aa0299e64b3b823c148ff8c46e835c7060dbb3c247e
6034892b3f6b7401fb67366e8afe8267182d6f36bf3618712371e6ae4654c0897f7475d3
9e9c186189162e29a9d8b3e37860457843a1c2fa3cacc133bdb8c7f77aae0ea3a5649300
35a7689f3a24ea726d4506d19f0b1aedb8739cb3fe7177cfaed08c8902162ed530ef19a0
266ca61a1a0b1bfc329fd2d1c1ad307a32f531f5be6faf75d96a49020acca8e37a4cb55f
f4072916711c397daf5bcbd229132b47d10b16f646d1d675cdf58c6f057333b1cbb94b2d
c44320cd2e9cba6f1c33a708ae1bb97f0739a
token_type: 2
issuer_name: 6973737565722e6578616d706c65
redemption_context:
origin_info: 6f726967696e2e6578616d706c65
nonce: 4437fb872eab95b5831a5d01005ee2995e417862ecfd2079ee4c246859a060ae
token_key: 30820252303d06092a864886f70d01010a3030a00d300b060960864801650
3040202a11a301806092a864886f70d010108300b0609608648016503040202a20302013
00382020f003082020a0282020100d730ce8b3ec7336b48a4f5897564d87c87627298f21
ba4bf34e7931142875c0e52c5aef3222d67e86124403e436d0136ebd806de37730427f81
4f7f0485eace93015471d14e56f3824e8bc5fbe44cf67e241c7642ac3a39452a283ff806
84ddbd66929a371d01e50feef1faee7f63f3ceb4b5ceacb939e06a558c2a6bccfd96fb74
16d3edce151bc7b0a6582f0ce99a7c0e7d5793b13d41292105e510e1aa00e082975a1386
6dfaf3a0a51c0dd1ecb64cc55cc607ca1813b5f91fd8e9cb9db18ffd81ac985a6cfdd5cc
2a0b8a5e4e9fa1ea5f149c1662155bb071c95218cae9ae4af613351baf470b1597bb984c
5ea8326f98aff64f72b60bcd035f6b970eb6edd2f9f2180d5aa8a17ed400056af3faa520
4b73c89b4eada6a057dd3dda9d8e18b3a6d2347c1027e2711f21eb7d96fef50cc3dacb2f
5ccc36e4c138ab75953974ade74982f85b91f419654d390378e2ea5aae33f1b4acf534d0
6de2f114acfdd88d6d708f4d2b646a8112b0fe181489916e2ba5c634cdf9b95762d1e120
169482dd27f959132705079fc4a00eee1f353a81c1e810ade20d070d839277169e09150c
08605afe7cea2aec41d2f85c2af7bef5d577343b4385e2c6c159926c1c8267d00433b88b
ad314a5ddcef58936126f1dd8da7b5728da192f54b304e60f4088e5b0620404f82a5939d
975e6714453a533c172c8a9b4b5da976ea60a5aa91fef0203010001
token_authenticator_input: 00024437fb872eab95b5831a5d01005ee2995e417862e
cfd2079ee4c246859a060ae11e15c91a7c2ad02abd66645802373db1d823bea80f08d452
541fb2b62b5898b9f9293b4d62e4b4759af064df8fa5759c79ab51a00f692541b26d466d
ab48091
token_authenticator: 4be4655a33566de7409e7cfdcdb764c251c04138602a046a7d7
1540aa9bcdb34e7df5dfabe17e16a3569f67c36460a79e9e7278b454c4f505580ae99750
b9308022b20aa8807ee054881126d9a4afd134331d0ebb3f9a4f2948731cd0ad2fe468b1
f8c6fcf2d5b9a2991a684b3fb0dec6a3e32fd3335e546f58c2217736683d378076355727
0493eb0f607c7936633a0532d1828dc860f0bf3954c82f0e1ab6089eae92d9d97e3237f2
58c5c82e711bef1682deb6edd19b24bb543f4418825e5d41e126de82f1a4b63321f07c12
3029a7499356fa8bdc11982451c69fa3d1940a4781b646c99e33e83b95810dc1e7a32a25
953ba0a0e37917c9f85bb4f0e7687c826e7138c9a2e71e87644b36c3891b4fec6af02519
aafaa36d559c71d090ea081ceed6cb738ffb730fa5dcbe889362591eb0a89f8ba4057f09
3ca35cc684f3b4cdc7c177f275a9d74a75e98eb395689842a5626d61af84072c9eb858ea
ed7e467b570c771e6530e02dda20b47f6860bb341ca4f849168dc7b6cb8c6743b8113c3e
f09ce9b9b2eaf172204cc26ea7c3de962cc1a851195cf143c9f27cb8f1df219df1209097
5ba657de1d021f2044829a689decf1072e5f79fbef0d3ae6085532f81b32b2a47968b073
2928193894dabb521c3f4c4a6858d43c8abd4695db4e49d3b5d46059032819d8485b0ccb
c3d24c5c72ac3e44d9ff94946cb8f8ca69fb1
token_type: 2
issuer_name: 6973737565722e6578616d706c65
redemption_context:
origin_info:
nonce: 4437fb872eab95b5831a5d01005ee2995e417862ecfd2079ee4c246859a060ae
token_key: 30820252303d06092a864886f70d01010a3030a00d300b060960864801650
3040202a11a301806092a864886f70d010108300b0609608648016503040202a20302013
00382020f003082020a0282020100d730ce8b3ec7336b48a4f5897564d87c87627298f21
ba4bf34e7931142875c0e52c5aef3222d67e86124403e436d0136ebd806de37730427f81
4f7f0485eace93015471d14e56f3824e8bc5fbe44cf67e241c7642ac3a39452a283ff806
84ddbd66929a371d01e50feef1faee7f63f3ceb4b5ceacb939e06a558c2a6bccfd96fb74
16d3edce151bc7b0a6582f0ce99a7c0e7d5793b13d41292105e510e1aa00e082975a1386
6dfaf3a0a51c0dd1ecb64cc55cc607ca1813b5f91fd8e9cb9db18ffd81ac985a6cfdd5cc
2a0b8a5e4e9fa1ea5f149c1662155bb071c95218cae9ae4af613351baf470b1597bb984c
5ea8326f98aff64f72b60bcd035f6b970eb6edd2f9f2180d5aa8a17ed400056af3faa520
4b73c89b4eada6a057dd3dda9d8e18b3a6d2347c1027e2711f21eb7d96fef50cc3dacb2f
5ccc36e4c138ab75953974ade74982f85b91f419654d390378e2ea5aae33f1b4acf534d0
6de2f114acfdd88d6d708f4d2b646a8112b0fe181489916e2ba5c634cdf9b95762d1e120
169482dd27f959132705079fc4a00eee1f353a81c1e810ade20d070d839277169e09150c
08605afe7cea2aec41d2f85c2af7bef5d577343b4385e2c6c159926c1c8267d00433b88b
ad314a5ddcef58936126f1dd8da7b5728da192f54b304e60f4088e5b0620404f82a5939d
975e6714453a533c172c8a9b4b5da976ea60a5aa91fef0203010001
token_authenticator_input: 00024437fb872eab95b5831a5d01005ee2995e417862e
cfd2079ee4c246859a060aeb741ec1b6fd05f1e95f8982906aec1612896d9ca97d53eef9
4ad3c9fe023f7a49f9293b4d62e4b4759af064df8fa5759c79ab51a00f692541b26d466d
ab48091
token_authenticator: 31c2ae70c45f171ed822a9397ba844d6ee20d09323491f4f9fb
3db54d7d3c7b403fd8ee1e2eedebd693d2493b3b1973142cd85f54257c009edda7cd5ad5
3cf8a07d8a3252c62da14d688d225727faa294b5ed57bd0913482c845b502fd967c27b92
d7c4ee7566894134fc71999e55073bf9d19f95b10f0d2044bef815dccfa7632903af7fd2
09af17c008c93fe76e6c4dffd90de933d711366ee72adc32d1289205a306de9b15bb6639
9b2e89c7cb129eadf062be9c4fd54b1ffea79840d0451544f30cc4eab6c36a06ad6dac87
741059803aa57006ce5aea4e71e053f4901f9901dd1f9fa489763f1c499fdf8ec1903a31
79259c79f7a496eefbe937f5b6d69f17f2b96b184cfab98dc0e46b2b0f5fb57764f894bf
2025d5f26505d70d3fa8766406d246bc037d588f035ea7230969323cb237da949a87db95
854f09ba24363a608d0a56427fac57907204aa8c57dc29633a36a83cff385f1eefcfffc9
730eda756d80109a20394c21b40ddc3e0121bd08e4a1eae48daa3a3c7a78f682ee208a78
686960c270e0ffd0042f38e9f786276ef01f7bda5ee323692c8de4f590014c4f4ea1f583
bf3db5cee7ba39d612c73535ef488c796ea33d2f9049a3b34cbc7db3d58208a11ceaf1b0
ab7853b817f53a3ff470bd3e353ca9d4365de09b6a70d94ee4e9118a0901013026360e99
64b2d6c51d47d4307328cedff3561d65a5583
token_type: 2
issuer_name: 6973737565722e6578616d706c65
redemption_context:
40ff3cdc296a1e823f43b49355df1a2ee4c5f65e5d38ebb3e24ecf4d874997c6
origin_info:
6f726967696e2e6578616d706c652c6f726967696e322e6578616d706c65
nonce: 4437fb872eab95b5831a5d01005ee2995e417862ecfd2079ee4c246859a060ae
token_key: 30820252303d06092a864886f70d01010a3030a00d300b060960864801650
3040202a11a301806092a864886f70d010108300b0609608648016503040202a20302013
00382020f003082020a0282020100d730ce8b3ec7336b48a4f5897564d87c87627298f21
ba4bf34e7931142875c0e52c5aef3222d67e86124403e436d0136ebd806de37730427f81
4f7f0485eace93015471d14e56f3824e8bc5fbe44cf67e241c7642ac3a39452a283ff806
84ddbd66929a371d01e50feef1faee7f63f3ceb4b5ceacb939e06a558c2a6bccfd96fb74
16d3edce151bc7b0a6582f0ce99a7c0e7d5793b13d41292105e510e1aa00e082975a1386
6dfaf3a0a51c0dd1ecb64cc55cc607ca1813b5f91fd8e9cb9db18ffd81ac985a6cfdd5cc
2a0b8a5e4e9fa1ea5f149c1662155bb071c95218cae9ae4af613351baf470b1597bb984c
5ea8326f98aff64f72b60bcd035f6b970eb6edd2f9f2180d5aa8a17ed400056af3faa520
4b73c89b4eada6a057dd3dda9d8e18b3a6d2347c1027e2711f21eb7d96fef50cc3dacb2f
5ccc36e4c138ab75953974ade74982f85b91f419654d390378e2ea5aae33f1b4acf534d0
6de2f114acfdd88d6d708f4d2b646a8112b0fe181489916e2ba5c634cdf9b95762d1e120
169482dd27f959132705079fc4a00eee1f353a81c1e810ade20d070d839277169e09150c
08605afe7cea2aec41d2f85c2af7bef5d577343b4385e2c6c159926c1c8267d00433b88b
ad314a5ddcef58936126f1dd8da7b5728da192f54b304e60f4088e5b0620404f82a5939d
975e6714453a533c172c8a9b4b5da976ea60a5aa91fef0203010001
token_authenticator_input: 00024437fb872eab95b5831a5d01005ee2995e417862e
cfd2079ee4c246859a060ae175a86e01410befaee0307ec86990b8a6e1b8192dfca7f0a9
692e06813ec9d199f9293b4d62e4b4759af064df8fa5759c79ab51a00f692541b26d466d
ab48091
token_authenticator: 6b25498e0c809b8c83ec22f6d46a98cd866354ad56b7aa78ef3
fc237ebe9b7fc5ea3346257ddf085166931653d94016e37896df38a767c438d4b2ca440c
47ae62f5e9074f9a72b06bdf103b4f205b20075d07465750a06e463106bb1ff0f9393f00
1ac5377b9ba7edc28b88aeab4e0d4ca9bd101af13967a4d681be02f8f3308224c0115ef8
7ed890e04441486db438538a3a8a82050377d5882001689216c82bb74513ecab47eebaa4
17f030ee887a83f0cc805becc5dd417a3c1c79f828d28068872b0102e8b2fd21743d4aea
4d4bbe8193b496d4167c312c1bea39c5c337701b33f07706daf2e07d8e0ad178878604b3
adcd766ea93e70a70a0b7d1447d20a6af222d8a785db417f462639e89aa57fd664c1c93d
b0b75dc2189345ab83aa823a7b1eb7c3f965fca97780e46d019044dc9583fc3a4e13705c
7c97594c4e983c975f2ac6e5a3a3fe46bc811e9bb46e8f1d2997152d19eff15e2e238f7b
541413f05141d31154e4a59c4b552192ef1d39b0399c5a9b935d4133f4d4e2b3737e7f45
8f92a90719cf5620b05884a74a16db6dbc48b7e819543290cef76d0e761dff156a6800a7
4430a79cba2cc46178ab72b169222fb082f9e05874ccaf0734e2b24315fb2c429c0b1b42
dc6513d76b891b7ce1c9c819303a050c9251aaa8ea2bb61a3bbbfc770ccad6a53dfd29d9
a65f81e91de499d752b29a43294f0cdaf361a
Authors' Addresses
著者のアドレス
Tommy Pauly Apple Inc. One Apple Park Way Cupertino, California 95014, United States of America Email: tpauly@apple.com
Tommy Pauly Apple Inc. One Apple Park Way Cupertino、カリフォルニア95014、アメリカ合衆国電子メール：tpauly@apple.com
Steven Valdez Google LLC Email: svaldez@chromium.org
Steven Valdez Google LLCメール：svaldez@chromium.org
Christopher A. Wood Cloudflare Email: caw@heapingbits.net
Christopher A. Wood Cloudflareメール：caw@heapingbits.net
Pauly, et al. Expires 11 June 2023 [Page 22]
ポーリー他2023年6月11日有効期限[22ページ]