Internet Engineering Task Force (IETF) A. Popov
Request for Comments: 8473 M. Nystroem
Category: Standards Track Microsoft Corp.
ISSN: 2070-1721 D. Balfanz, Ed.
N. Harper
Google Inc.
J. Hodges
Kings Mountain Systems
October 2018
Internet Engineering Task Force (IETF) A. Popov
Request for Comments: 8473 M. Nystroem
Category: Standards Track Microsoft Corp.
ISSN: 2070-1721 D. Balfanz, Ed.
N. Harper
Google Inc.
J. Hodges
Kings Mountain Systems
October 2018
Token Binding over HTTP
HTTP上的令牌绑定
Abstract
摘要
This document describes a collection of mechanisms that allow HTTP servers to cryptographically bind security tokens (such as cookies and OAuth tokens) to TLS connections.
本文档描述了一组机制，这些机制允许HTTP服务器以加密方式将安全令牌（如Cookie和OAuth令牌）绑定到TLS连接。
We describe both first-party and federated scenarios. In a first-party scenario, an HTTP server is able to cryptographically bind the security tokens that it issues to a client -- and that the client subsequently returns to the server -- to the TLS connection between the client and the server. Such bound security tokens are protected from misuse, since the server can generally detect if they are replayed inappropriately, e.g., over other TLS connections.
我们描述了第一方和联合场景。在第一方场景中，HTTP服务器能够以加密方式将它向客户端发出的安全令牌（客户端随后返回到服务器）绑定到客户端和服务器之间的TLS连接。由于服务器通常可以检测到这些绑定的安全令牌是否被不适当地重放（例如，通过其他TLS连接重放），因此可以防止误用。
Federated Token Bindings, on the other hand, allow servers to cryptographically bind security tokens to a TLS connection that the client has with a different server than the one issuing the token.
另一方面，联邦令牌绑定允许服务器以加密方式将安全令牌绑定到客户机与发出令牌的服务器不同的TLS连接。
This document is a companion document to "The Token Binding Protocol Version 1.0" (RFC 8471).
本文档是“令牌绑定协议版本1.0”（RFC 8471）的配套文档。
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/rfc8473.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8473.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. The Sec-Token-Binding HTTP Request Header Field . . . . . . . 4
2.1. HTTPS Token Binding Key-Pair Scoping . . . . . . . . . . 5
3. TLS Renegotiation . . . . . . . . . . . . . . . . . . . . . . 6
4. First-Party Use Cases . . . . . . . . . . . . . . . . . . . . 7
5. Federation Use Cases . . . . . . . . . . . . . . . . . . . . 7
5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 8
5.3. HTTP Redirects . . . . . . . . . . . . . . . . . . . . . 10
5.4. Negotiated Key Parameters . . . . . . . . . . . . . . . . 12
5.5. Federation Example . . . . . . . . . . . . . . . . . . . 13
6. Implementation Considerations . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7.1. Security Token Replay . . . . . . . . . . . . . . . . . . 16
7.2. Sensitivity of the Sec-Token-Binding Header . . . . . . . 16
7.3. Securing Federated Sign-On Protocols . . . . . . . . . . 17
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20
8.1. Scoping of Token Binding Key Pairs . . . . . . . . . . . 20
8.2. Lifetime of Token Binding Key Pairs . . . . . . . . . . . 20
8.3. Correlation . . . . . . . . . . . . . . . . . . . . . . . 21
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . 23
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. The Sec-Token-Binding HTTP Request Header Field . . . . . . . 4
2.1. HTTPS Token Binding Key-Pair Scoping . . . . . . . . . . 5
3. TLS Renegotiation . . . . . . . . . . . . . . . . . . . . . . 6
4. First-Party Use Cases . . . . . . . . . . . . . . . . . . . . 7
5. Federation Use Cases . . . . . . . . . . . . . . . . . . . . 7
5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 8
5.3. HTTP Redirects . . . . . . . . . . . . . . . . . . . . . 10
5.4. Negotiated Key Parameters . . . . . . . . . . . . . . . . 12
5.5. Federation Example . . . . . . . . . . . . . . . . . . . 13
6. Implementation Considerations . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7.1. Security Token Replay . . . . . . . . . . . . . . . . . . 16
7.2. Sensitivity of the Sec-Token-Binding Header . . . . . . . 16
7.3. Securing Federated Sign-On Protocols . . . . . . . . . . 17
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20
8.1. Scoping of Token Binding Key Pairs . . . . . . . . . . . 20
8.2. Lifetime of Token Binding Key Pairs . . . . . . . . . . . 20
8.3. Correlation . . . . . . . . . . . . . . . . . . . . . . . 21
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . 23
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
The Token Binding protocol [RFC8471] defines a Token Binding ID for a TLS connection between a client and a server. The Token Binding ID of a TLS connection is constructed using the public key of a private-public key pair. The client proves possession of the corresponding private key. This Token Binding key pair is long-lived. That is, subsequent TLS connections between the same client and server have the same Token Binding ID, unless specifically reset, e.g., by the user. When issuing a security token (e.g., an HTTP cookie or an OAuth token [RFC6749]) to a client, the server can include the Token Binding ID in the token, thus cryptographically binding the token to TLS connections between that particular client and server, and inoculating the token against abuse (reuse, attempted impersonation, etc.) by attackers.
令牌绑定协议[RFC8471]为客户机和服务器之间的TLS连接定义令牌绑定ID。TLS连接的令牌绑定ID是使用私有公钥对的公钥构造的。客户端证明拥有相应的私钥。此令牌绑定密钥对是长寿命的。也就是说，同一客户端和服务器之间的后续TLS连接具有相同的令牌绑定ID，除非例如由用户专门重置。当向客户机发出安全令牌（例如HTTP cookie或OAuth令牌[RFC6749]）时，服务器可以在令牌中包含令牌绑定ID，从而以加密方式将令牌绑定到该特定客户机和服务器之间的TLS连接，并接种令牌以防攻击者滥用（重用、尝试模拟等）。
While the Token Binding protocol [RFC8471] defines a message format for establishing a Token Binding ID, it does not specify how this message is embedded in higher-level protocols. The purpose of this specification is to define how TokenBindingMessages are embedded in HTTP (both versions 1.1 [RFC7230] and 2 [RFC7540]). Note that TokenBindingMessages are only defined if the underlying transport uses TLS. This means that Token Binding over HTTP is only defined when HTTP is layered on top of TLS (commonly referred to as HTTPS [RFC2818]).
虽然令牌绑定协议[RFC8471]定义了用于建立令牌绑定ID的消息格式，但它没有指定如何将此消息嵌入到更高级别的协议中。本规范的目的是定义如何将TokenBindingMessages嵌入HTTP（版本1.1[RFC7230]和版本2[RFC7540]）。请注意，只有在底层传输使用TLS时才定义TokenBindingMessages。这意味着HTTP上的令牌绑定仅在HTTP分层在TLS（通常称为HTTPS[RFC2818]）之上时定义。
HTTP clients establish a Token Binding ID with a server by including a special HTTP header field in HTTP requests. The HTTP header field value is a base64url-encoded TokenBindingMessage.
HTTP客户端通过在HTTP请求中包含一个特殊的HTTP头字段，与服务器建立令牌绑定ID。HTTP标头字段值是base64url编码的TokenBindingMessage。
A TokenBindingMessage allows a client to establish multiple Token Binding IDs with the server by including multiple TokenBinding structures. By default, a client will establish a Provided Token Binding ID with the server, indicating a Token Binding ID that the client will persistently use with the server. Under certain conditions, the client can also include a Referred Token Binding ID in the TokenBindingMessage, indicating a Token Binding ID that the client is using with a different server than the one that the TokenBindingMessage is sent to. This is useful in federation scenarios.
TokenBindingMessage允许客户端通过包含多个TokenBinding结构与服务器建立多个TokenBinding ID。默认情况下，客户端将与服务器建立提供的令牌绑定ID，指示客户端将与服务器持续使用的令牌绑定ID。在某些情况下，客户机还可以在TokenBindingMessage中包含引用的令牌绑定ID，指示客户机正在与TokenBindingMessage发送到的服务器不同的服务器上使用的令牌绑定ID。这在联合场景中很有用。
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.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
Once a client and server have negotiated the Token Binding protocol with HTTP/1.1 or HTTP/2 (see [RFC8471] and [RFC8472]), clients MUST include a Sec-Token-Binding header field in their HTTP requests and MUST include only one such header field per HTTP request. Also, the Sec-Token-Binding header field MUST NOT be included in HTTP responses. The ABNF of the Sec-Token-Binding header field is (per the style of [RFC7230]; see also Section 8.3 of [RFC7231]):
一旦客户机和服务器通过HTTP/1.1或HTTP/2协商令牌绑定协议（请参见[RFC8471]和[RFC8472]），客户机必须在其HTTP请求中包含Sec令牌绑定头字段，并且每个HTTP请求只能包含一个此类头字段。此外，HTTP响应中不得包含Sec令牌绑定头字段。Sec令牌绑定头字段的ABNF为（按照[RFC7230]的样式；另请参见[RFC7231]的第8.3节）：
Sec-Token-Binding = EncodedTokenBindingMessage
Sec-Token-Binding = EncodedTokenBindingMessage
The header field name is Sec-Token-Binding, and its single value, EncodedTokenBindingMessage, is a base64url encoding of a single TokenBindingMessage, as defined in [RFC8471]. The base64url encoding uses the URL and filename safe character set described in Section 5 of [RFC4648], with all trailing padding characters (i.e., "=") omitted and without the inclusion of any line breaks, whitespace, or other additional characters.
标头字段名为Sec Token Binding，其单个值EncodedTokenBindingMessage是单个TokenBindingMessage的base64url编码，如[RFC8471]中所定义。base64url编码使用[RFC4648]第5节中描述的URL和文件名安全字符集，省略所有尾随填充字符（即“=”），不包含任何换行符、空格或其他附加字符。
For example:
例如：
Sec-Token-Binding: AIkAAgBBQFzK4_bhAqLDwRQxqJWte33d7hZ0hZWHwk-miKPg4E\ 9fcgs7gBPoz-9RfuDfN9WCw6keHEw1ZPQMGs9CxpuHm-YAQM_j\ aOwwej6a-cQBGU7CJpUHOvXG4VvjNq8jDsvta9Y8_bPEPj25Gg\ mKiPjhJEtZA6mJ_9SNifLvVBTi7fR9wSAAAA
证券交易委员会代币绑定：AIkAAgBBQFzK4_bhAqLDwRQxqJWte33d7hZ0hZWHwk-miKPg4E\9fcgs7gBPoz-9RfuDfN9WCw6keHEw1ZPQMGs9CxpuHm-YAQM_j\aOwwej6a-CQBGU7CJPUHOVG4VJNQ8JDSVTA9Y8_BPJ25GG\MKIPJHJETZ6;\9SNIFL7FR9WSAAAA
(Note that the backslashes and line breaks are provided to ease readability; they are not part of the actual encoded message.)
（请注意，提供反斜杠和换行符是为了简化可读性；它们不是实际编码消息的一部分。）
If the server receives more than one Sec-Token-Binding header field in an HTTP request, then the server MUST reject the message with a 400 (Bad Request) HTTP status code. Additionally, the Sec-Token-Binding header field:
如果服务器在HTTP请求中接收到多个Sec Token Binding头字段，则服务器必须拒绝包含400（错误请求）HTTP状态代码的消息。此外，Sec令牌绑定头字段：
o SHOULD NOT be stored by origin servers on PUT requests,
o 不应在PUT请求时由源服务器存储，
o MAY be listed by a server in a Vary response header field, and
o 可能由服务器在“更改响应头”字段中列出，以及
o MUST NOT be used in HTTP trailers.
o 不得在HTTP拖车中使用。
The TokenBindingMessage MUST contain exactly one TokenBinding structure with a TokenBindingType value of provided_token_binding, which MUST be signed with the Token Binding private key used by the client for connections between itself and the server that the HTTP request is sent to (clients use different Token Binding key pairs for different servers; see Section 2.1 below). The Token Binding ID
TokenBindingMessage必须正好包含一个TokenBindingType值为提供的\u token\u binding的TokenBindingType结构，该结构必须使用客户端用于连接自身和HTTP请求发送到的服务器的令牌绑定私钥进行签名（客户端对不同的服务器使用不同的令牌绑定密钥对；请参阅下面的第2.1节）
established by this TokenBinding is called a "Provided Token Binding ID".
由该令牌绑定建立的称为“提供的令牌绑定ID”。
The TokenBindingMessage MAY also contain exactly one TokenBinding structure with a TokenBindingType value of referred_token_binding, as specified in Section 5.3. In addition to the latter, or rather than the latter, the TokenBindingMessage MAY contain other TokenBinding structures. This is specific to the use case in question; such use cases are outside the scope of this specification.
TokenBindingMessage还可能包含一个TokenBinding结构，其TokenBindingType值为refered_token_binding，如第5.3节所述。除了后者，或者不是后者，TokenBindingMessage可能包含其他TokenBinding结构。这是特定于所讨论的用例的；此类用例不在本规范的范围内。
A TokenBindingMessage is validated by the server as described in Section 4.2 ("Server Processing Rules") of [RFC8471]. If validation fails and a Token Binding is rejected, any associated bound tokens MUST also be rejected by the server. HTTP requests containing invalid tokens MUST be rejected. In this case, the server application MAY return HTTP status code 400 (Bad Request) or proceed with an application-specific "invalid token" response (e.g., directing the client to re-authenticate and present a different token), or terminate the connection.
TokenBindingMessage由服务器验证，如[RFC8471]第4.2节（“服务器处理规则”）所述。如果验证失败且令牌绑定被拒绝，则服务器还必须拒绝任何关联的绑定令牌。必须拒绝包含无效令牌的HTTP请求。在这种情况下，服务器应用程序可返回HTTP状态代码400（错误请求），或继续进行特定于应用程序的“无效令牌”响应（例如，指示客户端重新认证并呈现不同令牌），或终止连接。
In HTTP/2, the client SHOULD use header compression [RFC7541] to avoid the overhead of repeating the same header field in subsequent HTTP requests.
在HTTP/2中，客户端应该使用头压缩[RFC7541]，以避免在后续HTTP请求中重复相同头字段的开销。
HTTPS is used in conjunction with various application protocols and application contexts, in various ways. For example, general-purpose web browsing is one such HTTP-based application context. Within that context, HTTP cookies [RFC6265] are typically utilized for state management, including client authentication. A related, though distinct, example of other HTTP-based application contexts is where OAuth tokens [RFC6749] are utilized to manage authorization for third-party application access to resources. The token-scoping rules of these two examples can differ: the scoping rules for cookies are concisely specified in [RFC6265], whereas OAuth is a framework and defines various token types with various scopings, some of which are determined by the encompassing application.
HTTPS以各种方式与各种应用程序协议和应用程序上下文结合使用。例如，通用web浏览就是这样一种基于HTTP的应用程序上下文。在该上下文中，HTTP Cookie[RFC6265]通常用于状态管理，包括客户端身份验证。其他基于HTTP的应用程序上下文的一个相关但不同的示例是，OAuth令牌[RFC6749]用于管理第三方应用程序访问资源的授权。这两个示例的令牌作用域规则可能有所不同：Cookie的作用域规则在[RFC6265]中有简明的规定，而OAuth是一个框架，用各种作用域定义各种令牌类型，其中一些由包含的应用程序确定。
The scoping of Token Binding key pairs generated by web browsers for the purpose of binding HTTP cookies MUST be no wider than the granularity of a "registered domain" (also known as "effective top-level domain + 1", or "eTLD+1"). An origin's "registered domain" is the origin's host's public suffix plus the label to its left (where the term "public suffix" is defined in the "NOTE:" paragraph in Section 5.3 of [RFC6265] as "a domain that is controlled by a public registry"). For example, for "https://www.example.com", the public suffix (eTLD) is "com", and the registered domain (eTLD+1) is
web浏览器为绑定HTTP Cookie而生成的令牌绑定密钥对的范围不得超过“注册域”（也称为“有效顶级域+1”或“eTLD+1”）的粒度。源站的“注册域”是源站主机的公共后缀加上其左边的标签（其中术语“公共后缀”在[RFC6265]第5.3节的“注释：”中定义为“受公共注册表控制的域”）。例如，例如“https://www.example.com，公共后缀（eTLD）为“com”，注册域（eTLD+1）为
"example.com". User Agents SHOULD use an up-to-date public suffix list, such as the one maintained by Mozilla [PSL].
“example.com”。用户代理应该使用最新的公共后缀列表，如Mozilla[PSL]维护的列表。
This means that in practice the scope of a Token Binding key pair is no larger than the scope of a cookie allowed by a web browser. If a web browser restricts cookies to a narrower scope than registered domains, the scope of Token Binding key pairs MAY also be narrower. This applies to the use of Token Binding key pairs in first-party use cases, as well as in federation use cases defined in this specification (Section 5).
这意味着实际上令牌绑定密钥对的范围不大于web浏览器允许的cookie范围。如果web浏览器将Cookie限制在比注册域更窄的范围内，则令牌绑定密钥对的范围也可能更窄。这适用于第一方用例以及本规范（第5节）中定义的联合用例中令牌绑定密钥对的使用。
Key pairs used to bind other application tokens, such as OAuth tokens or "OpenID Connect" ID Tokens [OpenID.Core], SHOULD adhere to the above eTLD+1 scoping requirement for those tokens being employed in first-party or federation scenarios. Applications other than web browsers MAY use different key-pair scoping rules. See also Section 8.1 below.
用于绑定其他应用程序令牌（如OAuth令牌或“OpenID Connect”ID令牌[OpenID.Core]）的密钥对应遵守上述eTLD+1范围要求，以满足第一方或联合场景中使用的这些令牌的范围要求。web浏览器以外的应用程序可能使用不同的密钥对作用域规则。另见下文第8.1节。
Scoping rules for other HTTP-based application contexts are outside the scope of this specification.
其他基于HTTP的应用程序上下文的范围规则不在本规范的范围内。
Token Binding over HTTP/1.1 [RFC7230] can be performed in combination with TLS renegotiation. In this case, renegotiation MUST only occur between a client's HTTP request and the server's response, the client MUST NOT send any pipelined requests, and the client MUST NOT initiate renegotiation. (That is, the client may only send a renegotiation ClientHello in response to the server's HelloRequest.) These conditions ensure that both the client and the server can clearly identify which TLS Exported Keying Material value [RFC5705] to use when generating or verifying the TokenBindingMessage. This also prevents a TokenBindingMessage from being split across TLS renegotiation boundaries due to TLS message fragmentation; see Section 6.2.1 of [RFC5246].
HTTP/1.1[RFC7230]上的令牌绑定可以与TLS重新协商结合执行。在这种情况下，重新协商只能在客户端的HTTP请求和服务器的响应之间进行，客户端不得发送任何流水线请求，客户端不得发起重新协商。（也就是说，客户端只能发送重新协商ClientHello以响应服务器的HelloreRequest。）这些条件确保客户端和服务器都可以清楚地识别在生成或验证TokenBindingMessage时要使用的TLS导出的键控材料值[RFC5705]。这还可以防止TokenBindingMessage由于TLS消息碎片而跨TLS重新协商边界拆分；见[RFC5246]第6.2.1节。
(Note: This document deals with TLS 1.2 and therefore refers to RFC 5246 (which has been obsoleted by RFC 8446); [TOKENBIND-TLS13] addresses Token Binding in TLS 1.3.)
（注：本文件涉及TLS 1.2，因此参考RFC 5246（已被RFC 8446淘汰）；[TOKENBIND-TLS13]解决了TLS 1.3中的令牌绑定。）
In a first-party use case (also known as a "same-site" use case), an HTTP server issues a security token such as a cookie (or similar) to a client and expects the client to return the security token at a later time, e.g., in order to authenticate. Binding the security token to the TLS connection between the client and the server protects the security token from misuse, since the server can detect if the security token is replayed inappropriately, e.g., over other TLS connections.
在第一方用例（也称为“同一站点”用例）中，HTTP服务器向客户端发出安全令牌，例如cookie（或类似的），并期望客户端稍后返回安全令牌，例如，为了进行身份验证。将安全令牌绑定到客户端和服务器之间的TLS连接可以防止安全令牌被滥用，因为服务器可以检测安全令牌是否被不适当地重放，例如通过其他TLS连接重放。
See Section 5 of [RFC8471] for general guidance regarding the binding of security tokens and their subsequent validation.
有关安全令牌绑定及其后续验证的一般指南，请参见[RFC8471]第5节。
For privacy reasons, clients use different Token Binding key pairs to establish Provided Token Binding IDs with different servers. As a result, a server cannot bind a security token (such as an OAuth token or an OpenID Connect ID Token [OpenID.Core]) to a TLS connection that the client has with a different server. This is, however, a common requirement in federation scenarios: for example, an Identity Provider may wish to issue an identity token to a client and cryptographically bind that token to the TLS connection between the client and a Relying Party.
出于隐私原因，客户端使用不同的令牌绑定密钥对与不同的服务器建立提供的令牌绑定ID。因此，服务器无法将安全令牌（例如OAuth令牌或OpenID连接ID令牌[OpenID.Core]）绑定到客户端与其他服务器的TLS连接。然而，这是联合场景中的一个常见要求：例如，身份提供者可能希望向客户端发出身份令牌，并以加密方式将该令牌绑定到客户端和依赖方之间的TLS连接。
In this section, we describe mechanisms to achieve this. The common idea among these mechanisms is that a server (called the "Token Consumer" in this document) signals to the client that it should reveal the Provided Token Binding ID that is used between the client and itself to another server (called the "Token Provider" in this document). Also common across the mechanisms is how the Token Binding ID is revealed to the Token Provider: the client uses the Token Binding protocol [RFC8471] and includes a TokenBinding structure in the Sec-Token-Binding HTTP header field defined above. What differs between the various mechanisms is how the Token Consumer signals to the client that it should reveal the Token Binding ID to the Token Provider. Below, we specify one such mechanism, which is suitable for redirect-based interactions between Token Consumers and Token Providers.
在本节中，我们将介绍实现这一点的机制。这些机制的共同思想是，服务器（在本文档中称为“令牌消费者”）向客户端发出信号，表示它应该向另一台服务器（在本文档中称为“令牌提供者”）显示在客户端和自身之间使用的提供的令牌绑定ID。在这些机制中，令牌绑定ID如何显示给令牌提供者也是很常见的：客户端使用令牌绑定协议[RFC8471]，并在上面定义的Sec令牌绑定HTTP头字段中包含令牌绑定结构。不同机制之间的不同之处在于令牌使用者如何向客户端发出信号，表明它应该向令牌提供者显示令牌绑定ID。下面，我们指定一种这样的机制，它适用于令牌使用者和令牌提供者之间基于重定向的交互。
Client Token Consumer Token Provider
+--------+ +----+ +-----+
| Client | | TC | | TP |
+--------+ +----+ +-----+
| | |
| | |
| | |
| Client interacts w/TC | |
| using TokenBindingID TBID1: | |
| TBMSG[[provided_token_binding,| |
| TBID1, signature]] | |
|------------------------------>| |
| | |
| Client interacts w/TP |
| using TokenBindingID TBID2: |
| TBMSG[[provided_token_binding, |
| TBID2, signature]] |
|----------------------------------------------------->|
| |
| | |
| TC signals permission to | |
| reveal TBID1 to TP | |
|<------------------------------| |
| | |
| |
| Client interacts w/TP |
| using TokenBindingID TBID1 and TBID2: |
| TBMSG[[provided_token_binding, |
| TBID2, signature], |
| [referred_token_binding, |
| TBID1, signature]] |
|----------------------------------------------------->|
| |
| | |
| | |
Client Token Consumer Token Provider
+--------+ +----+ +-----+
| Client | | TC | | TP |
+--------+ +----+ +-----+
| | |
| | |
| | |
| Client interacts w/TC | |
| using TokenBindingID TBID1: | |
| TBMSG[[provided_token_binding,| |
| TBID1, signature]] | |
|------------------------------>| |
| | |
| Client interacts w/TP |
| using TokenBindingID TBID2: |
| TBMSG[[provided_token_binding, |
| TBID2, signature]] |
|----------------------------------------------------->|
| |
| | |
| TC signals permission to | |
| reveal TBID1 to TP | |
|<------------------------------| |
| | |
| |
| Client interacts w/TP |
| using TokenBindingID TBID1 and TBID2: |
| TBMSG[[provided_token_binding, |
| TBID2, signature], |
| [referred_token_binding, |
| TBID1, signature]] |
|----------------------------------------------------->|
| |
| | |
| | |
In a federated sign-on protocol, an Identity Provider issues an identity token to a client, which sends the identity token to a Relying Party to authenticate itself. Examples of this include OpenID Connect (in which the identity token is called an "ID Token") and the Security Assertion Markup Language (SAML) [OASIS.saml-core-2.0-os] (in which the identity token is a SAML assertion).
在联邦登录协议中，身份提供者向客户机发出身份令牌，客户机将身份令牌发送给依赖方以进行自身身份验证。这方面的示例包括OpenID Connect（其中标识令牌称为“ID令牌”）和安全断言标记语言（SAML）[OASIS.SAML-core-2.0-os]（其中标识令牌是SAML断言）。
To better protect the security of the identity token, the Identity Provider may wish to bind the identity token to the TLS connection between the client and the Relying Party, thus ensuring that only said client can use the identity token. The Relying Party will compare the Token Binding ID (or a cryptographic hash of it) in the identity token with the Token Binding ID (or a hash thereof) of the TLS connection between this Relying Party and the client.
为了更好地保护身份令牌的安全，身份提供者可能希望将身份令牌绑定到客户端和依赖方之间的TLS连接，从而确保只有所述客户端可以使用身份令牌。依赖方将把身份令牌中的令牌绑定ID（或其加密散列）与该依赖方和客户端之间的TLS连接的令牌绑定ID（或其散列）进行比较。
This is an example of a federation scenario, which more generally can be described as follows:
这是联合场景的一个示例，通常可以如下描述：
o A Token Consumer causes the client to issue a token request to the Token Provider. The goal is for the client to obtain a token and then use it with the Token Consumer.
o 令牌使用者使客户端向令牌提供者发出令牌请求。客户机的目标是获取令牌，然后将其与令牌消费者一起使用。
o The client delivers the token request to the Token Provider.
o 客户端将令牌请求传递给令牌提供者。
o The Token Provider issues the token. The token is issued for the specific Token Consumer who requested it (thus preventing malicious Token Consumers from using tokens with other Token Consumers). The token is, however, typically a bearer token, meaning that any client can use it with the Token Consumer -- not just the client to which it was issued.
o 令牌提供程序发出令牌。令牌是为请求它的特定令牌使用者颁发的（从而防止恶意令牌使用者与其他令牌使用者一起使用令牌）。然而，令牌通常是承载令牌，这意味着任何客户端都可以将其与令牌使用者一起使用，而不仅仅是向其发出令牌的客户端。
o Therefore, in the previous step, the Token Provider may want to include in the token the Token Binding ID (or a cryptographic hash of it) that the client uses when communicating with the Token Consumer, thus binding the token to the client's Token Binding key pair. The client proves possession of the private key when communicating with the Token Consumer through the Token Binding protocol [RFC8471] and uses the corresponding public key of this key pair as a component of the Token Binding ID. Comparing the Token Binding ID from the token to the Token Binding ID established with the client allows the Token Consumer to verify that the token was sent to it by the legitimate client.
o 因此，在前一步骤中，令牌提供者可能希望在令牌中包括客户端在与令牌消费者通信时使用的令牌绑定ID（或其加密散列），从而将令牌绑定到客户端的令牌绑定密钥对。通过令牌绑定协议[RFC8471]与令牌使用者通信时，客户端证明拥有私钥并使用此密钥对的相应公钥作为令牌绑定ID的一个组件。将令牌中的令牌绑定ID与客户端建立的令牌绑定ID进行比较，可使令牌使用者验证令牌是否由合法客户端发送给它。
o To allow the Token Provider to include the Token Binding ID in the token, the Token Binding ID between the client and the Token Consumer must therefore be communicated to the Token Provider along with the token request. Communicating a Token Binding ID involves proving possession of a private key and is described in the Token Binding protocol [RFC8471].
o 为了允许令牌提供者在令牌中包括令牌绑定ID，因此客户端和令牌消费者之间的令牌绑定ID必须与令牌请求一起传送给令牌提供者。传递令牌绑定ID涉及证明拥有私钥，在令牌绑定协议[RFC8471]中进行了描述。
The client will perform this last operation only if the Token Consumer requests the client to do so.
只有当令牌使用者请求客户端执行最后一个操作时，客户端才会执行最后一个操作。
Below, we specify how Token Consumers can signal this request in redirect-based federation protocols. Note that this assumes that the federated sign-on flow starts at the Token Consumer or, at the very least, includes a redirect from the Token Consumer to the Token Provider. It is outside the scope of this document to specify similar mechanisms for flows that do not include such redirects.
下面，我们指定令牌消费者如何在基于重定向的联合协议中发出此请求的信号。注意，这假设联邦登录流从令牌使用者开始，或者至少包括从令牌使用者到令牌提供者的重定向。为不包含此类重定向的流指定类似机制超出了本文档的范围。
When a Token Consumer redirects the client to a Token Provider as a means to deliver the token request, it SHOULD include an Include-Referred-Token-Binding-ID HTTP response header field in its HTTP response. The ABNF of the Include-Referred-Token-Binding-ID header is (per the style of [RFC7230]; see also Section 8.3 of [RFC7231]):
当令牌使用者将客户端重定向到令牌提供者作为传递令牌请求的手段时，它应该在其HTTP响应中包含包含引用的令牌绑定ID HTTP响应头字段。包含引用的令牌绑定ID头的ABNF为（按照[RFC7230]的样式；另请参见[RFC7231]的第8.3节）：
Include-Referred-Token-Binding-ID = "true"
Include-Referred-Token-Binding-ID = "true"
Where the header field name is "Include-Referred-Token-Binding-ID" and the field value of "true" is case insensitive. For example:
其中，标头字段名为“包含引用的令牌绑定ID”，字段值“true”不区分大小写。例如：
Include-Referred-Token-Binding-ID: true
包含引用的令牌绑定ID:true
Including this response header field signals to the client that it should reveal, to the Token Provider, the Token Binding ID used between itself and the Token Consumer. In the absence of this response header field, the client will not disclose any information about the Token Binding used between the client and the Token Consumer to the Token Provider.
包含此响应头字段会向客户端发出信号，表明客户端应向令牌提供者显示其自身和令牌使用者之间使用的令牌绑定ID。在没有此响应头字段的情况下，客户机将不会向令牌提供者披露有关客户机和令牌使用者之间使用的令牌绑定的任何信息。
As illustrated in Section 5.5, when a client receives this header field, it should take the TokenBindingID [RFC8471] of the provided TokenBinding from the referrer and create a referred TokenBinding with it to include in the TokenBindingMessage in the redirect request. In other words, the Token Binding message in the redirect request to the Token Provider now includes one provided binding and one referred binding, the latter constructed from the binding between the client and the Token Consumer.
如第5.5节所示，当客户端收到此标头字段时，它应该从引用方获取提供的TokenBinding的TokenBindingID[RFC8471]，并使用它创建引用的TokenBinding，以包含在重定向请求中的TokenBindingMessage中。换句话说，到令牌提供者的重定向请求中的令牌绑定消息现在包括一个提供的绑定和一个引用的绑定，后者由客户端和令牌使用者之间的绑定构造而成。
When a client receives the Include-Referred-Token-Binding-ID header, it includes the referred Token Binding even if both the Token Provider and the Token Consumer fall under the same eTLD+1 and the provided and Referred Token Binding IDs are the same.
当客户端接收到包含引用的令牌绑定ID报头时，它将包含引用的令牌绑定，即使令牌提供者和令牌使用者都属于相同的eTLD+1，并且提供的和引用的令牌绑定ID相同。
The referred Token Binding is sent only in the initial request resulting from the HTTP response that included the Include-Referred-Token-Binding-ID header. Should the response to that initial request be a further redirect, the original referred
引用的令牌绑定仅在由包含包含引用的令牌绑定ID头的HTTP响应产生的初始请求中发送。如果对该初始请求的响应是进一步重定向，则原始请求将被引用
Token Binding is no longer included in subsequent requests. (A new referred Token Binding may be included if the redirecting endpoint itself responded with an Include-Referred-Token-Binding-ID response header.)
令牌绑定不再包含在后续请求中。（如果重定向端点本身使用包含引用令牌绑定ID响应头进行响应，则可以包含新的引用令牌绑定。）
If the Include-Referred-Token-Binding-ID header field is received in response to a request that did not include the Sec-Token-Binding header field, the client MUST ignore the Include-Referred-Token-Binding-ID header field.
如果接收到包含引用的令牌绑定ID头字段以响应不包含Sec令牌绑定头字段的请求，则客户端必须忽略包含引用的令牌绑定ID头字段。
This header field only has meaning if the HTTP status code is a redirection code (300-399) and MUST be ignored by the client for any other status codes. As described in Section 2, if the client supports the Token Binding protocol and has negotiated the Token Binding protocol with both the Token Consumer and the Token Provider, it sends the Sec-Token-Binding header field to the Token Provider with each HTTP request.
仅当HTTP状态代码是重定向代码（300-399）且客户端必须忽略任何其他状态代码时，此标头字段才有意义。如第2节所述，如果客户端支持令牌绑定协议，并且已与令牌使用者和令牌提供者协商令牌绑定协议，则它会在每个HTTP请求中向令牌提供者发送Sec令牌绑定头字段。
The TokenBindingMessage included in the redirect request to the Token Provider SHOULD contain a TokenBinding with a TokenBindingType value of referred_token_binding. If included, this TokenBinding MUST be signed with the Token Binding private key used by the client for connections between itself and the Token Consumer (more specifically, the server that issued the Include-Referred-Token-Binding-ID response header field). The Token Binding ID established by this TokenBinding is called a "Referred Token Binding ID".
到令牌提供程序的重定向请求中包含的TokenBindingMessage应包含一个TokenBinding，其TokenBindingType值为refered\u Token\u binding。如果包含此令牌绑定，则必须使用客户端用于连接自身和令牌使用者（更具体地说，是发出包含引用的令牌绑定ID响应头字段的服务器）的令牌绑定私钥对该令牌绑定进行签名。此令牌绑定建立的令牌绑定ID称为“引用的令牌绑定ID”。
As described above, the TokenBindingMessage MUST additionally contain a Provided Token Binding ID, i.e., a TokenBinding structure with a TokenBindingType value of provided_token_binding, which MUST be signed with the Token Binding private key used by the client for connections between itself and the Token Provider (more specifically, the server that the token request is being sent to).
如上所述，TokenBindingMessage还必须包含提供的令牌绑定ID，即TokenBindingType值为提供的\u Token\u Binding的令牌绑定结构，必须使用客户端用于连接自身和令牌提供程序的令牌绑定私钥对其进行签名（更具体地说，是将令牌请求发送到的服务器）。
If, for some deployment-specific reason, the initial Token Provider ("TP1") needs to redirect the client to another Token Provider ("TP2") rather than directly back to the Token Consumer, it can be accommodated using the header fields defined in this specification in the following fashion ("the redirect-chain approach"):
如果出于某些部署特定的原因，初始令牌提供程序（“TP1”）需要将客户端重定向到另一个令牌提供程序（“TP2”）而不是直接返回到令牌消费者，则可以使用本规范中定义的头字段，以以下方式（“重定向链方法”）对其进行调整：
Initially, the client is redirected to TP1 by the Token Consumer ("TC"), as described above. Upon receiving a client's request that contains a TokenBindingMessage that in turn contains both provided and referred TokenBindings (for TP1 and TC, respectively), TP1 responds to the client with a redirect response that (1) contains the Include-Referred-Token-Binding-ID header field and (2) directs the client to send a request to TP2. This causes the client to follow the same pattern and send a request
最初，令牌消费者（“TC”）将客户端重定向到TP1，如上所述。收到包含TokenBindingMessage的客户端请求后，该消息又包含提供的和引用的TokenBindings（分别针对TP1和TC），TP1使用重定向响应响应客户端，该重定向响应（1）包含包含包含引用的TokenBinding ID头字段，（2）指示客户端向TP2发送请求。这会导致客户端遵循相同的模式并发送请求
containing a TokenBindingMessage that contains both provided and referred TokenBindings (for TP2 and TP1, respectively) to TP2. Note that this pattern can continue to additional Token Providers. In this case, TP2 issues a security token, bound to the client's TokenBinding with TP1, and sends a redirect response to the client pointing to TP1. TP1 in turn constructs a security token for the Token Consumer, bound to the TC's referred TokenBinding that had been conveyed earlier, and sends a redirect response pointing to the TC, containing the bound security token, to the client.
包含一条TokenBindingMessage，该消息包含TP2提供的和引用的标记绑定（分别针对TP2和TP1）。请注意，此模式可以继续应用于其他令牌提供程序。在这种情况下，TP2发出一个安全令牌，该令牌与TP1绑定到客户端的令牌，并向指向TP1的客户端发送重定向响应。TP1反过来为令牌消费者构造一个安全令牌，绑定到先前传输的TC的引用令牌绑定，并向客户端发送指向TC的重定向响应（包含绑定的安全令牌）。
The above is intended as only a non-normative example. Details are specific to deployment contexts. Other approaches are possible but are outside the scope of this specification.
以上仅作为非规范性示例。详细信息特定于部署上下文。其他方法也可以，但不在本规范的范围内。
The TLS extension for Token Binding protocol negotiation [RFC8472] allows the server and client to negotiate the parameters (signature algorithm, length) of the Token Binding key pair. It is possible that the Token Binding ID used between the client and the Token Consumer, and the Token Binding ID used between the client and the Token Provider, use different key parameters. The client MUST use the key parameters negotiated with the Token Consumer in the referred_token_binding TokenBinding of the TokenBindingMessage, even if those key parameters are different from the ones negotiated with the server that the header field is sent to.
令牌绑定协议协商的TLS扩展[RFC8472]允许服务器和客户端协商令牌绑定密钥对的参数（签名算法、长度）。客户端和令牌使用者之间使用的令牌绑定ID以及客户端和令牌提供者之间使用的令牌绑定ID可能使用不同的密钥参数。客户机必须在TokenBindingMessage的引用的\u Token\u binding TokenBinding中使用与令牌使用者协商的密钥参数，即使这些密钥参数不同于与头字段发送到的服务器协商的密钥参数。
Token Providers SHOULD support all the Token Binding key parameters specified in [RFC8471]. If a Token Provider does not support the key parameters specified in the referred_token_binding TokenBinding in the TokenBindingMessage, it MUST NOT issue a bound token.
令牌提供程序应支持[RFC8471]中指定的所有令牌绑定密钥参数。如果令牌提供程序不支持在TokenBindingMessage中引用的\u Token\u binding TokenBinding中指定的密钥参数，则它不得发出绑定令牌。
The diagram below shows a typical HTTP redirect-based web browser single sign-on (SSO) profile (Section 4.1 of [OASIS.saml-prof-2.0-os]) (no artifact, no callbacks), featuring the binding of, for example, a TLS Token Binding ID into an OpenID Connect ID Token.
下图显示了一个典型的基于HTTP重定向的web浏览器单点登录（SSO）配置文件（OASIS.saml-prof-2.0-os）第4.1节）（无工件，无回调），其特点是将TLS令牌绑定ID绑定到OpenID Connect ID令牌中。
Legend:
图例：
+------------+------------------------------------------------------+
| EKM: | TLS Exported Keying Material [RFC5705] |
| | |
| {EKMn}Ksm: | EKM for server "n", signed by the private key of |
| | TBID "m", where "n" must represent the server |
| | receiving the ETBMSG. If a conveyed TB's type is |
| | provided_token_binding, then m = n, else if TB's |
| | type is referred_token_binding, then m != n. For |
| | example, see step 1b in the diagram below. |
| | |
| ETBMSG: | "Sec-Token-Binding" HTTP header field conveying an |
| | EncodedTokenBindingMessage, in turn conveying |
| | TokenBinding (TB)struct(s), e.g., ETBMSG[[TB]] or |
| | ETBMSG[[TB1],[TB2]] |
| | |
| ID Token: | the ID Token in OpenID Connect. It is the semantic |
| | equivalent of a SAML "authentication assertion". |
| | "ID Token w/TBIDn" denotes a "token bound" ID Token |
| | containing TBIDn. |
| | |
| Ks and Kp: | private (aka secret) key and public key, |
| | respectively, of the client-side Token Binding key |
| | pair |
| | |
| OIDC: | OpenID Connect |
| | |
| TB: | TokenBinding struct containing a signed EKM, TBID, |
| | and TB type, e.g., |
| | [{EKM1}Ks1,TBID1,provided_token_binding] |
| | |
| TBIDn: | Token Binding ID for client and server n's token- |
| | bound TLS association. TBIDn contains Kpn. |
+------------+------------------------------------------------------+
+------------+------------------------------------------------------+
| EKM: | TLS Exported Keying Material [RFC5705] |
| | |
| {EKMn}Ksm: | EKM for server "n", signed by the private key of |
| | TBID "m", where "n" must represent the server |
| | receiving the ETBMSG. If a conveyed TB's type is |
| | provided_token_binding, then m = n, else if TB's |
| | type is referred_token_binding, then m != n. For |
| | example, see step 1b in the diagram below. |
| | |
| ETBMSG: | "Sec-Token-Binding" HTTP header field conveying an |
| | EncodedTokenBindingMessage, in turn conveying |
| | TokenBinding (TB)struct(s), e.g., ETBMSG[[TB]] or |
| | ETBMSG[[TB1],[TB2]] |
| | |
| ID Token: | the ID Token in OpenID Connect. It is the semantic |
| | equivalent of a SAML "authentication assertion". |
| | "ID Token w/TBIDn" denotes a "token bound" ID Token |
| | containing TBIDn. |
| | |
| Ks and Kp: | private (aka secret) key and public key, |
| | respectively, of the client-side Token Binding key |
| | pair |
| | |
| OIDC: | OpenID Connect |
| | |
| TB: | TokenBinding struct containing a signed EKM, TBID, |
| | and TB type, e.g., |
| | [{EKM1}Ks1,TBID1,provided_token_binding] |
| | |
| TBIDn: | Token Binding ID for client and server n's token- |
| | bound TLS association. TBIDn contains Kpn. |
+------------+------------------------------------------------------+
Client, aka Token Consumer, aka Token Provider, aka
User Agent OpenID Client, OpenID Provider,
OIDC Relying Party, OIDC Provider,
SAML Relying Party SAML Identity Provider
[ server "1" ] [ server "2" ]
+--------+ +----+ +-----+
| Client | | TC | | TP |
+--------+ +----+ +-----+
| | |
| | |
| | |
| 0. Client interacts w/TC | |
| over HTTPS, establishes Ks1 and Kp1, TBID1 |
| ETBMSG[[{EKM1}Ks1,TBID1,provided_token_binding]] |
|------------------------------>| |
| | |
| | |
| | |
| 1a. OIDC ID Token request, aka| |
| "Authentication Request", conveyed with |
| an HTTP response header field of |
| Include-Referred-Token-Binding-ID:true. |
| Any security-relevant cookies | |
| should contain TBID1. | |
+<- - - - - - - - - - - - - - - - | |
. | (redirect to TP via 301, 302, | |
. | 303, 307, or 308) | |
. | | |
+------------------------------------------------------->|
| 1b. opens HTTPS w/TP, |
| establishes Ks2, Kp2, TBID2; |
| sends a GET or POST with |
| ETBMSG[[{EKM2}Ks2,TBID2,provided_token_binding], |
| [{EKM2}Ks1,TBID1,referred_token_binding]] |
| as well as the ID Token request |
| | |
| | |
| | |
| 2. user authentication (if applicable; |
| methods vary; particulars are out of scope) |
|<====================================================>|
| (TP generates ID Token for TC containing TBID1; may |
| also set cookie(s) containing TBID2 and/or TBID1; |
| details vary; particulars are out of scope) |
| | |
| | |
Client, aka Token Consumer, aka Token Provider, aka
User Agent OpenID Client, OpenID Provider,
OIDC Relying Party, OIDC Provider,
SAML Relying Party SAML Identity Provider
[ server "1" ] [ server "2" ]
+--------+ +----+ +-----+
| Client | | TC | | TP |
+--------+ +----+ +-----+
| | |
| | |
| | |
| 0. Client interacts w/TC | |
| over HTTPS, establishes Ks1 and Kp1, TBID1 |
| ETBMSG[[{EKM1}Ks1,TBID1,provided_token_binding]] |
|------------------------------>| |
| | |
| | |
| | |
| 1a. OIDC ID Token request, aka| |
| "Authentication Request", conveyed with |
| an HTTP response header field of |
| Include-Referred-Token-Binding-ID:true. |
| Any security-relevant cookies | |
| should contain TBID1. | |
+<- - - - - - - - - - - - - - - - | |
. | (redirect to TP via 301, 302, | |
. | 303, 307, or 308) | |
. | | |
+------------------------------------------------------->|
| 1b. opens HTTPS w/TP, |
| establishes Ks2, Kp2, TBID2; |
| sends a GET or POST with |
| ETBMSG[[{EKM2}Ks2,TBID2,provided_token_binding], |
| [{EKM2}Ks1,TBID1,referred_token_binding]] |
| as well as the ID Token request |
| | |
| | |
| | |
| 2. user authentication (if applicable; |
| methods vary; particulars are out of scope) |
|<====================================================>|
| (TP generates ID Token for TC containing TBID1; may |
| also set cookie(s) containing TBID2 and/or TBID1; |
| details vary; particulars are out of scope) |
| | |
| | |
| | |
| 3a. ID Token containing Kp1, issued for TC, |
| conveyed via OIDC "Authentication Response" |
+<- - - - - - - - - - - - - - - - - - - - - - - - - - - -|
. | (redirect to TC) | |
. | | |
. | | |
+-------------------------------->| |
| 3b. HTTPS GET or POST with |
| ETBMSG[[{EKM1}Ks1,TBID1,provided_token_binding]] |
| conveying an Authentication Response containing |
| an ID Token w/TBID1, issued for TC |
| | |
| | |
| | |
| 4. user is signed on; any security-relevant cookie(s)|
| that is set SHOULD contain TBID1 |
|<------------------------------| |
| | |
| | |
| | |
| 3a. ID Token containing Kp1, issued for TC, |
| conveyed via OIDC "Authentication Response" |
+<- - - - - - - - - - - - - - - - - - - - - - - - - - - -|
. | (redirect to TC) | |
. | | |
. | | |
+-------------------------------->| |
| 3b. HTTPS GET or POST with |
| ETBMSG[[{EKM1}Ks1,TBID1,provided_token_binding]] |
| conveying an Authentication Response containing |
| an ID Token w/TBID1, issued for TC |
| | |
| | |
| | |
| 4. user is signed on; any security-relevant cookie(s)|
| that is set SHOULD contain TBID1 |
|<------------------------------| |
| | |
| | |
HTTPS-based applications may have multi-party use cases other than, or in addition to, the HTTP redirect-based signaling and conveyance of referred Token Bindings, as presented above in Section 5.3.
如上文第5.3节所述，基于HTTPS的应用程序可能具有多方用例，而非基于HTTP重定向的信令和所述令牌绑定的传输，或者除此之外。
Thus, Token Binding implementations should provide APIs for such applications to generate Token Binding messages containing Token Binding IDs of various application-specified Token Binding types, to be conveyed by the Sec-Token-Binding header field.
因此，令牌绑定实现应为此类应用程序提供API，以生成包含各种应用程序指定的令牌绑定类型的令牌绑定ID的令牌绑定消息，这些令牌绑定ID将由Sec令牌绑定头字段传递。
However, Token Binding implementations MUST only convey Token Binding IDs to servers if signaled to do so by an application. Signaling mechanisms other than the Include-Referred-Token-Binding-ID HTTP response header field are possible, but these mechanisms are outside the scope of this specification.
但是，令牌绑定实现必须仅在应用程序发出向服务器传递令牌绑定ID的信号时才将其传递给服务器。除了Include referered Token Binding ID HTTP response header字段之外，还可以使用其他信令机制，但这些机制不在本规范的范围内。
NOTE: See Section 8 ("Privacy Considerations") for privacy guidance regarding the use of this functionality.
注：有关使用此功能的隐私指南，请参见第8节（“隐私注意事项”）。
The goal of the federated Token Binding mechanisms is to prevent attackers from exporting and replaying tokens used in protocols between the client and the Token Consumer, thereby impersonating legitimate users and gaining access to protected resources. Although bound tokens can still be replayed by any malware present in clients (which may be undetectable to a server), in order to export bound tokens to other machines and successfully replay them, attackers also need to export the corresponding Token Binding private keys. Token Binding private keys are therefore high-value assets and SHOULD be strongly protected, ideally by generating them in a hardware security module that prevents key export.
联合令牌绑定机制的目标是防止攻击者导出和重放客户端和令牌使用者之间协议中使用的令牌，从而模拟合法用户并获得对受保护资源的访问。尽管绑定令牌仍然可以被客户端中存在的任何恶意软件重放（服务器可能无法检测到），但为了将绑定令牌导出到其他机器并成功重放，攻击者还需要导出相应的令牌绑定私钥。因此，令牌绑定私钥是高价值资产，应该得到强有力的保护，最好是在防止密钥导出的硬件安全模块中生成它们。
This consideration is a special case of the scenario described in Section 7.1 ("Security Token Replay") of [RFC8471].
这是[RFC8471]第7.1节（“安全令牌重播”）中描述的场景的特殊情况。
The purpose of the Token Binding protocol is to convince the server that the client that initiated the TLS connection controls a certain key pair. For the server to correctly draw this conclusion after processing the Sec-Token-Binding header field, certain secrecy and integrity requirements must be met.
令牌绑定协议的目的是使服务器确信发起TLS连接的客户端控制某个密钥对。为了让服务器在处理Sec令牌绑定头字段后正确得出此结论，必须满足某些保密性和完整性要求。
For example, the client must keep its Token Binding private key secret. If the private key is not secret, then another actor in the system could create a valid Token Binding header field and thereby impersonate the client. This can render the main purpose of the protocol -- to bind bearer tokens to certain clients -- moot. Consider, for example, an attacker who obtained (perhaps through a network intrusion) an authentication cookie that a client uses with a certain server. Consider further that the server bound that cookie to the client's Token Binding ID precisely to thwart misuse of the cookie. If the attacker were to come into possession of the client's private key, they could then establish a TLS connection with the server and craft a Sec-Token-Binding header field that matches the binding present in the cookie, thus successfully authenticating as the client and gaining access to the client's data at the server. The Token Binding protocol, in this case, did not successfully bind the cookie to the client.
例如，客户端必须对其令牌绑定私钥保密。如果私钥不是机密的，那么系统中的另一个参与者可以创建有效的令牌绑定头字段，从而模拟客户端。这可能使协议的主要目的——将承载令牌绑定到某些客户端——变得毫无意义。例如，考虑攻击者获得（可能通过网络入侵）客户端与某个服务器使用的认证cookie。进一步考虑，服务器将cookie绑定到客户端的令牌绑定ID，以精确地阻止cookie的滥用。如果攻击者拥有客户端的私钥，那么他们可以与服务器建立TLS连接，并创建与cookie中存在的绑定相匹配的Sec令牌绑定头字段，从而成功地验证为客户端并在服务器上访问客户端的数据。在本例中，令牌绑定协议没有成功地将cookie绑定到客户端。
Likewise, we need integrity protection of the Sec-Token-Binding header field. A client should not be tricked into sending to a server a Sec-Token-Binding header field that contains Token Bindings signed with any Token Binding keys that the client does not control.
同样，我们需要Sec令牌绑定头字段的完整性保护。不应诱使客户端向服务器发送Sec令牌绑定头字段，该字段包含使用客户端不控制的任何令牌绑定密钥签名的令牌绑定。
Consider an attacker A that somehow has knowledge of the Exported Keying Material (EKM) for a TLS connection between a client C and a server S. (While that is somewhat unlikely, it is also not entirely out of the question, since the client might not treat the EKM as a secret -- after all, a pre-image-resistant hash function has been applied to the TLS master secret, making it impossible for someone knowing the EKM to recover the TLS master secret. Such considerations might lead some clients to not treat the EKM as a secret.) Such an attacker A could craft a Sec-Token-Binding header field with A's key pair over C's EKM. If the attacker could now trick C into sending such a header field to S, it would appear to S as if C controls a certain key pair, when in fact it does not (the attacker A controls the key pair).
考虑攻击者A在某种程度上知道导出的密钥材料（EKM）用于客户端C和服务器S之间的TLS连接。（虽然这有点不太可能，但也不是完全不可能，因为客户端可能不会将EKM视为机密——毕竟，TLS主机密已应用了抗映像前哈希函数，使得了解EKM的人无法恢复TLS主机密。这些考虑可能会导致某些客户端ts不将EKM视为机密。）这样的攻击者a可以利用a的密钥对在C的EKM上创建一个Sec令牌绑定头字段。如果攻击者现在可以诱使C向s发送这样的头字段，s会觉得C控制了某个密钥对，而实际上它没有（攻击者a控制了密钥对）。
If A has a pre-existing relationship with S (e.g., perhaps has an account on S), it now appears to the server S as if A is connecting to it, even though it is really C. (If the server S does not simply use Token Binding IDs to identify clients but also uses bound authentication cookies, then A would also have to trick C into sending one of A's cookies to S, which it can do through a variety of means -- inserting cookies through JavaScript APIs, setting cookies through related-domain attacks, etc.) In other words, in this scenario, A can trick C into logging into A's account on S. This could lead to a loss of privacy for C, since A presumably has some other way to also access the account and can thus indirectly observe C's behavior (for example, if S has a feature that lets account holders see their activity history on S).
如果A与S有预先存在的关系（例如，可能在S上有一个帐户），那么现在服务器S会觉得A正在连接它，即使它实际上是C。（如果服务器S不仅使用令牌绑定ID来标识客户端，而且还使用绑定的身份验证cookies，那么A还必须欺骗C向S发送A的一个cookies，这可以通过多种方式实现——通过JavaScript API插入cookies，通过相关域攻击设置cookies，等等。）换句话说，在这种情况下，A可以诱骗C登录A在s上的帐户。这可能会导致C失去隐私，因为A可能还有其他方式访问该帐户，因此可以间接观察C的行为（例如，如果s具有允许帐户持有人在s上查看其活动历史的功能）。
Therefore, we need to protect the integrity of the Sec-Token-Binding header field. One eTLD+1 should not be able to set the Sec-Token-Binding header field (through a Document Object Model (DOM) API [W3C.REC-DOM-Level-3-Core-20040407] or otherwise) that the User Agent uses with another eTLD+1. Employing the "Sec-" header field prefix helps to meet this requirement by denoting the header field name as a "forbidden header name"; see [fetch-spec].
因此，我们需要保护Sec令牌绑定头字段的完整性。一个eTLD+1不能设置用户代理与另一个eTLD+1一起使用的Sec令牌绑定头字段（通过文档对象模型（DOM）API[W3C.REC-DOM-Level-3-Core-20040407]或其他方式）。使用“Sec-”头字段前缀有助于满足这一要求，将头字段名称表示为“禁止的头名称”；请参阅[获取规范]。
As explained above, in a federated sign-on scenario, a client will prove possession of two different Token Binding private keys to a Token Provider: one private key corresponds to the "provided" Token Binding ID (which the client normally uses with the Token Provider), and the other is the Token Binding private key corresponding to the "referred" Token Binding ID (which the client normally uses with the Token Consumer). The Token Provider is expected to issue a token that is bound to the Referred Token Binding ID.
如上所述，在联合登录场景中，客户端将向令牌提供者证明拥有两个不同的令牌绑定私钥：一个私钥对应于“提供的”令牌绑定ID（客户端通常与令牌提供者一起使用），另一个是对应于“引用的”令牌绑定私钥令牌绑定ID（客户端通常与令牌使用者一起使用）。令牌提供程序应发出绑定到引用的令牌绑定ID的令牌。
Both proofs (that of the provided Token Binding private key and that of the referred Token Binding private key) are necessary. To show this, consider the following scenario:
这两种证明（提供的令牌绑定私钥的证明和引用的令牌绑定私钥的证明）都是必要的。为了说明这一点，考虑下面的场景：
o The client has an authentication token with the Token Provider that is bound to the client's Token Binding ID used with that Token Provider.
o 客户端与令牌提供程序有一个身份验证令牌，该令牌与该令牌提供程序使用的客户端令牌绑定ID绑定。
o The client wants to establish a secure (i.e., free of men-in-the-middle) authenticated session with the Token Consumer but has not yet done so (in other words, we are about to run the federated sign-on protocol).
o 客户端希望与令牌消费者建立一个安全的（即中间没有人）身份验证会话，但尚未这样做（换句话说，我们将运行联邦登录协议）。
o A man-in-the-middle is allowed to intercept the connection between the client and the Token Consumer or between the client and the Token Provider (or both).
o 中间人可以拦截客户端和令牌消费者之间或客户端和令牌提供者（或两者）之间的连接。
The goal is to detect the presence of the man-in-the-middle in these scenarios.
目标是在这些场景中检测中间人的存在。
First, consider a man-in-the-middle between the client and the Token Provider. Recall that we assume that the client possesses a bound authentication token (e.g., cookie) for the Token Provider. The man-in-the-middle can intercept and modify any message sent by the client to the Token Provider and any message sent by the Token Provider to the client. (This means, among other things, that the man-in-the-middle controls the JavaScript running at the client in the origin of the Token Provider.) It is not, however, in possession of the client's Token Binding private key. Therefore, it can choose to either (1) replace the Token Binding ID in requests from the client to the Token Provider and create a Sec-Token-Binding header field that matches the TLS connection between the man-in-the-middle and the Token Provider or (2) leave the Sec-Token-Binding header field unchanged. If it chooses the latter, the signature in the Token Binding message (created by the original client on the EKM for the connection between the client and the man-in-the-middle) will not match a signature on the EKM between the man-in-the-middle and the Token Provider. If it chooses the former (and creates its own signature, using its own Token Binding private key, over the EKM for the connection between itself, the man-in-the-middle, and the Token Provider), then the Token Binding message will match the connection between the man-in-the-middle and the Token Provider, but the Token Binding ID in the message will not match the Token Binding ID that the client's authentication token is bound to. Either way, the man-in-the-middle is detected by the Token Provider, but only if the proof of possession of the provided Token Binding private key is required in the protocol (as is done above).
首先，考虑介于客户端和令牌提供者之间的中间人。回想一下，我们假设客户端拥有令牌提供者的绑定身份验证令牌（例如cookie）。中间的人可以截获和修改客户端发送给令牌提供者的任何消息以及令牌提供者发送给客户端的任何消息。（这意味着，除其他事项外，中间人控制在令牌提供者的原始客户端上运行的JavaScript。）但是，它并不拥有客户端的令牌绑定私钥。因此，它可以选择（1）在从客户端到令牌提供程序的请求中替换令牌绑定ID，并创建与中间人和令牌提供程序之间的TLS连接相匹配的Sec令牌绑定头字段，或者（2）保持Sec令牌绑定头字段不变。如果选择后者，令牌绑定消息中的签名（由EKM上的原始客户端为客户端和中间人之间的连接创建）将与中间人和令牌提供者之间EKM上的签名不匹配。如果它选择前者（并使用自己的令牌绑定私钥通过EKM为自身、中间人和令牌提供者之间的连接创建自己的签名），则令牌绑定消息将匹配中间人和令牌提供者之间的连接，但是消息中的令牌绑定ID与客户端的身份验证令牌绑定到的令牌绑定ID不匹配。无论哪种方式，令牌提供者都会检测到中间的人，但前提是协议中要求提供令牌绑定私钥的占有证明（如上所述）。
Next, consider the presence of a man-in-the-middle between the client and the Token Consumer. That man-in-the-middle can intercept and modify any message sent by the client to the Token Consumer and any message sent by the Token Consumer to the client. The Token Consumer is the party that redirects the client to the Token Provider. In this case, the man-in-the-middle controls the redirect URL and can tamper with any redirect URL issued by the Token Consumer (as well as with any JavaScript running in the origin of the Token Consumer). The goal of the man-in-the-middle is to trick the Token Provider into issuing a token bound to its Token Binding ID and not to the Token Binding ID of the legitimate client. To thwart this goal of the man-in-the-middle, the client's Referred Token Binding ID must be communicated to the Token Provider in a manner that cannot be affected by the man-in-the-middle (who, as mentioned above, can modify redirect URLs and JavaScript at the client). Including the referred TokenBinding structure in the Sec-Token-Binding header field (as opposed to, say, including the Referred Token Binding ID in an application-level message as part of the redirect URL) is one way to assure that the man-in-the-middle between the client and the Token Consumer cannot affect the communication of the Referred Token Binding ID to the Token Provider.
接下来，考虑在客户端和令牌消费者之间存在一个中间人。中间的那个人可以截获和修改客户端发送给令牌消费者的任何消息以及令牌消费者发送给客户端的任何消息。令牌使用者是将客户端重定向到令牌提供程序的一方。在这种情况下，中间人控制重定向URL，并可以篡改令牌消费者发布的任何重定向URL（以及令牌消费者源代码中运行的任何JavaScript）。中间人的目标是欺骗令牌提供者发布绑定到其令牌绑定ID而不是合法客户端的令牌绑定ID的令牌。为了阻止中间人的这一目标，必须以中间人（如上所述，中间人可以在客户端修改重定向URL和JavaScript）不会影响的方式将客户端引用的令牌绑定ID传递给令牌提供者。在Sec-Token-Binding头字段中包含引用的TokenBinding结构（与将引用的令牌绑定ID作为重定向URL的一部分包含在应用程序级消息中相反）是一种确保客户端和令牌使用者之间的中间人不会影响引用的令牌绑定ID与令牌提供者的通信的方法。
Therefore, the Sec-Token-Binding header field in the federated sign-on use case contains both a proof of possession of the provided Token Binding key and a proof of possession of the referred Token Binding key.
因此，联邦登录用例中的Sec-Token-Binding头字段既包含提供的令牌绑定密钥的占有证明，也包含引用的令牌绑定密钥的占有证明。
Note that the presence of Token Binding does not relieve the Token Provider and Token Consumer from performing various checks to ensure the security of clients during the use of federated sign-on protocols. These include the following:
请注意，令牌绑定的存在并不能免除令牌提供者和令牌使用者在使用联合登录协议期间执行各种检查以确保客户端的安全性。这些措施包括：
o The Token Provider should not issue tokens to Token Consumers that have been shown to act maliciously. To aid in this, the federation protocol should identify the Token Consumer to the Token Provider (e.g., through OAuth client IDs or similar mechanisms), and the Token Provider should ensure that tokens are indeed issued to the Token Consumer identified in the token request (e.g., by verifying that the redirect URI is associated with the OAuth client ID).
o 令牌提供者不应向已显示恶意行为的令牌使用者颁发令牌。为了帮助实现这一点，联邦协议应该向令牌提供者标识令牌消费者（例如，通过OAuth客户机ID或类似机制），令牌提供者应该确保令牌确实发放给令牌请求中标识的令牌消费者（例如，通过验证重定向URI是否与OAuth客户端ID关联）。
o The Token Consumer should verify that the tokens were issued for it and not for some other Token Consumer. To aid in this, the federation protocol should include an audience parameter in the token response or apply equivalent mechanisms (the implicit OAuth flow requires Token Consumers to identify themselves when they exchange OAuth authorization codes for OAuth refresh tokens, leaving it up to the Token Provider to verify that the OAuth authorization was delivered to the correct Token Consumer).
o 令牌使用者应验证令牌是为其而不是为其他令牌使用者颁发的。为了帮助实现这一点，联合协议应该在令牌响应中包含一个访问群体参数或应用等效机制（隐式OAuth流要求令牌使用者在为OAuth刷新令牌交换OAuth授权代码时标识自己，由令牌提供者验证OAuth授权是否已传递给正确的令牌使用者）。
Clients use different Token Binding key pairs for different servers, so as to not allow Token Binding to become a tracking tool across different servers. However, the scoping of the Token Binding key pairs to servers varies according to the scoping rules of the application protocol (Section 4.1 of [RFC8471]).
客户端对不同的服务器使用不同的令牌绑定密钥对，这样就不允许令牌绑定成为跨不同服务器的跟踪工具。但是，令牌绑定密钥对到服务器的范围根据应用程序协议的范围规则（RFC8471第4.1节）而有所不同。
In the case of HTTP cookies, servers may use Token Binding to secure their cookies. These cookies can be attached to any subdomain of effective top-level domains (eTLDs), and clients therefore should use the same Token Binding key pair across such subdomains. This will ensure that any server capable of receiving the cookie will see the same Token Binding ID from the client and thus be able to verify the Token Binding of the cookie. See Section 2.1 above.
对于HTTP Cookie，服务器可以使用令牌绑定来保护其Cookie。这些cookie可以附加到有效顶级域（ETLD）的任何子域，因此客户端应该在这些子域之间使用相同的令牌绑定密钥对。这将确保任何能够接收cookie的服务器都能从客户端看到相同的令牌绑定ID，从而能够验证cookie的令牌绑定。见上文第2.1节。
If the client application is not a web browser, it may have additional knowledge about the relationship between different servers. For example, the client application might be aware of the fact that two servers play the roles of Relying Party and Identity Provider, respectively, in a federated sign-on protocol and that they therefore share the identity of the user. In such cases, it is permissible to use different Token Binding key-pair scoping rules, such as using the same Token Binding key pair for both the Relying Party and the Identity Provider. Absent such special knowledge, conservative key-pair scoping rules should be used, assuring that clients use different Token Binding key pairs with different servers.
如果客户端应用程序不是web浏览器，则它可能对不同服务器之间的关系有更多的了解。例如，客户机应用程序可能知道这样一个事实：在联邦登录协议中，两台服务器分别扮演依赖方和身份提供者的角色，因此它们共享用户的身份。在这种情况下，允许使用不同的令牌绑定密钥对范围规则，例如对依赖方和身份提供者使用相同的令牌绑定密钥对。如果没有此类专门知识，则应使用保守的密钥对范围规则，以确保客户端在不同的服务器上使用不同的令牌绑定密钥对。
Token Binding key pairs do not have an expiration time. This means that they can potentially be used by a server to track a user for an extended period of time (similar to a long-lived cookie). HTTPS clients such as web User Agents SHOULD therefore provide a user interface for discarding Token Binding key pairs (similar to the controls provided for deleting cookies).
令牌绑定密钥对没有过期时间。这意味着它们可能被服务器用来在较长时间内跟踪用户（类似于长寿命cookie）。因此，诸如web用户代理之类的HTTPS客户端应提供用于丢弃令牌绑定密钥对的用户界面（类似于为删除cookie提供的控件）。
If a User Agent provides modes such as private browsing mode in which the user is promised that browsing state such as cookies are discarded after the session is over, the User Agent MUST also discard Token Binding key pairs from such modes after the session is over. Generally speaking, users should be given the same level of control over the lifetime of Token Binding key pairs as they have over cookies or other potential tracking mechanisms.
如果用户代理提供诸如私有浏览模式之类的模式，其中向用户承诺在会话结束后丢弃诸如cookies之类的浏览状态，则用户代理还必须在会话结束后丢弃此类模式中的令牌绑定密钥对。一般来说，应该给予用户对令牌绑定密钥对生命周期的控制级别，就像他们对cookie或其他潜在跟踪机制的控制级别一样。
An application's various communicating endpoints that receive Token Binding IDs for TLS connections other than their own obtain information about the application's other TLS connections. (In this context, "an application" is a combination of client-side and server-side components, communicating over HTTPS, where the client side may be web-browser-based, native-application-based, or both.) These other Token Binding IDs can serve as correlation handles for the endpoints of the other connections. If the receiving endpoints are otherwise aware of these other connections, then no additional information is being exposed. For instance, if in a redirect-based federation protocol the Identity Provider and Relying Party already possess URLs for one another, then also having Token Binding IDs for these connections does not provide additional correlation information. If not, by providing the other Token Binding IDs, additional information is then exposed that can be used to correlate the other endpoints. In such cases, a privacy analysis of enabled correlations and their potential privacy impacts should be performed as part of the application design decisions of how, and whether, to utilize Token Binding.
接收TLS连接的令牌绑定ID的应用程序的各个通信端点（不是它们自己的端点）可以获取有关应用程序的其他TLS连接的信息。（在此上下文中，“应用程序”是客户端和服务器端组件的组合，通过HTTPS进行通信，其中客户端可以是基于web浏览器、基于本机应用程序或两者兼有。）这些其他令牌绑定ID可以用作其他连接的端点的关联句柄。如果接收端点以其他方式知道这些其他连接，则不会公开其他信息。例如，如果在基于重定向的联合协议中，身份提供者和依赖方已经拥有彼此的URL，那么同样拥有这些连接的令牌绑定ID不会提供额外的相关信息。如果没有，则通过提供其他令牌绑定ID，将公开可用于关联其他端点的其他信息。在这种情况下，对启用的相关性及其潜在隐私影响的隐私分析应该作为应用程序设计决策的一部分来执行，以决定如何以及是否使用令牌绑定。
Also, Token Binding implementations must take care to only reveal Token Binding IDs to other endpoints if signaled to do so by the application associated with a Token Binding ID; see Section 6 ("Implementation Considerations").
此外，令牌绑定实现必须注意，如果与令牌绑定ID相关联的应用程序发出向其他端点显示令牌绑定ID的信号，则仅向其他端点显示令牌绑定ID；见第6节（“实施注意事项”）。
Finally, care should be taken to ensure that unrelated applications do not obtain information about each other's Token Bindings. For instance, a Token Binding implementation shared between multiple applications on a given system should prevent unrelated applications from obtaining each other's Token Binding information. This may be accomplished by using techniques such as application isolation and key segregation, depending upon system capabilities.
最后，应注意确保不相关的应用程序不会获取关于彼此令牌绑定的信息。例如，给定系统上多个应用程序之间共享的令牌绑定实现应该防止不相关的应用程序获取彼此的令牌绑定信息。这可以通过使用应用程序隔离和密钥隔离等技术来实现，具体取决于系统功能。
Below is the Internet Assigned Numbers Authority (IANA) "Permanent Message Header Field Names" registration information per [RFC3864].
以下是互联网分配号码管理局（IANA）根据[RFC3864]提供的“永久消息头字段名称”注册信息。
Header Field name: Sec-Token-Binding Protocol: HTTP Status: standard Reference: This document
标题字段名称：Sec令牌绑定协议：HTTP状态：标准参考：此文档
Header Field name: Include-Referred-Token-Binding-ID Protocol: HTTP Status: standard Reference: This document
标题字段名称：包含引用的令牌绑定ID协议：HTTP状态：标准引用：此文档
[PSL] Mozilla, "Public Suffix List", <https://publicsuffix.org/>.
[PSL]Mozilla，“公共后缀列表”<https://publicsuffix.org/>.
[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>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <https://www.rfc-editor.org/info/rfc2818>.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC 2818，DOI 10.17487/RFC2818，2000年5月<https://www.rfc-editor.org/info/rfc2818>.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, DOI 10.17487/RFC3864, September 2004, <https://www.rfc-editor.org/info/rfc3864>.
[RFC3864]Klyne，G.，Nottingham，M.和J.Mogul，“消息头字段的注册程序”，BCP 90，RFC 3864，DOI 10.17487/RFC3864，2004年9月<https://www.rfc-editor.org/info/rfc3864>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/info/rfc4648>.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC 4648，DOI 10.17487/RFC4648，2006年10月<https://www.rfc-editor.org/info/rfc4648>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<https://www.rfc-editor.org/info/rfc5246>.
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, March 2010, <https://www.rfc-editor.org/info/rfc5705>.
[RFC5705]Rescorla，E.“传输层安全（TLS）关键材料导出器”，RFC 5705，DOI 10.17487/RFC5705，2010年3月<https://www.rfc-editor.org/info/rfc5705>.
[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>.
[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.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，DOI 10.17487/RFC7230，2014年6月<https://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <https://www.rfc-editor.org/info/rfc7231>.
[RFC7231]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：语义和内容”，RFC 7231，DOI 10.17487/RFC72312014年6月<https://www.rfc-editor.org/info/rfc7231>.
[RFC7541] Peon, R. and H. Ruellan, "HPACK: Header Compression for HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, <https://www.rfc-editor.org/info/rfc7541>.
[RFC7541]Paun，R.和H.Ruellan，“HPACK：HTTP/2的报头压缩”，RFC 7541，DOI 10.17487/RFC7541，2015年5月<https://www.rfc-editor.org/info/rfc7541>.
[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>.
[RFC8471] Popov, A., Ed., Nystroem, M., Balfanz, D., and J. Hodges, "The Token Binding Protocol Version 1.0", RFC 8471, DOI 10.17487/RFC8471, October 2018, <https://www.rfc-editor.org/info/rfc8471>.
[RFC8471]Popov，A.，Ed.，Nystroem，M.，Balfanz，D.，和J.Hodges，“令牌绑定协议版本1.0”，RFC 8471，DOI 10.17487/RFC8471，2018年10月<https://www.rfc-editor.org/info/rfc8471>.
[RFC8472] Popov, A., Ed., Nystroem, M., and D. Balfanz, "Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation", RFC 8472, DOI 10.17487/RFC8472, October 2018, <https://www.rfc-editor.org/info/rfc8472>.
[RFC8472]Popov，A.，Ed.，Nystroem，M.，和D.Balfanz，“令牌绑定协议协商的传输层安全（TLS）扩展”，RFC 8472，DOI 10.17487/RFC8472，2018年10月<https://www.rfc-editor.org/info/rfc8472>.
[fetch-spec] WhatWG, "Fetch", Living Standard, <https://fetch.spec.whatwg.org/>.
[fetch spec]WhatWG，“fetch”，生活水平<https://fetch.spec.whatwg.org/>.
[OASIS.saml-core-2.0-os] Cantor, S., Kemp, J., Philpott, R., and E. Maler, "Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0", OASIS Standard saml-core-2.0-os, March 2005, <http://docs.oasis-open.org/ security/saml/v2.0/saml-core-2.0-os.pdf>.
[OASIS.saml-core-2.0-os]Cantor，S.，Kemp，J.，Philpott，R.，和E.Maler，“OASIS安全断言标记语言（saml）V2.0的断言和协议”，OASIS标准saml-core-2.0-os，2005年3月<http://docs.oasis-open.org/ security/saml/v2.0/saml-core-2.0-os.pdf>。
[OASIS.saml-prof-2.0-os] Hughes, J., Ed., Cantor, S., Ed., Hodges, J., Ed., Hirsch, F., Ed., Mishra, P., Ed., Philpott, R., Ed., and E. Maler, Ed., "Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0", OASIS Standard OASIS.saml-profiles-2.0-os, March 2005, <http://docs.oasis-open.org/security/ saml/v2.0/saml-profiles-2.0-os.pdf>.
[OASIS.saml-prof-2.0-os]休斯，J.，Ed.，坎托，S.，Ed.，霍奇斯，J.，Ed.，赫希，F.，Ed.，米什拉，P.，Ed.，Philpott，R.，Ed.，和E.Maler，Ed.，“OASIS安全断言标记语言（saml）V2.0的配置文件”，OASIS标准OASIS.saml-Profiles-2.0-os，2005年3月， <http://docs.oasis-open.org/security/ saml/v2.0/saml-profiles-2.0-os.pdf>。
[OpenID.Core] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, "OpenID Connect Core 1.0 incorporating errata set 1", November 2014, <http://openid.net/specs/openid-connect-core-1_0.html>.
[OpenID.Core]北樱村、J.布拉德利、M.琼斯、B.德梅德罗斯和C.莫蒂莫尔，“OpenID连接核心1.0合并勘误表集1”，2014年11月<http://openid.net/specs/openid-connect-core-1_0.html>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <https://www.rfc-editor.org/info/rfc6749>.
[RFC6749]Hardt，D.，Ed.“OAuth 2.0授权框架”，RFC 6749，DOI 10.17487/RFC6749，2012年10月<https://www.rfc-editor.org/info/rfc6749>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, <https://www.rfc-editor.org/info/rfc7540>.
[RFC7540]Belshe，M.，Paon，R.，和M.Thomson，编辑，“超文本传输协议版本2（HTTP/2）”，RFC 7540，DOI 10.17487/RFC7540，2015年5月<https://www.rfc-editor.org/info/rfc7540>.
[TOKENBIND-TLS13] Harper, N., "Token Binding for Transport Layer Security (TLS) Version 1.3 Connections", Work in Progress, draft-ietf-tokbind-tls13-01, May 2018.
[TOKENBIND-TLS13]哈珀，N.，“传输层安全（TLS）连接的令牌绑定版本1.3”，正在进行中，草稿-ietf-tokbind-TLS13-01，2018年5月。
[W3C.REC-DOM-Level-3-Core-20040407] Le Hors, A., Ed., Le Hegaret, P., Ed., Wood, L., Ed., Nicol, G., Ed., Robie, J., Ed., Champion, M., Ed., and S. Byrne, Ed., "Document Object Model (DOM) Level 3 Core Specification", World Wide Web Consortium Recommendation REC-DOM-Level-3-Core-20040407, April 2004, <https://www.w3.org/TR/2004/ REC-DOM-Level-3-Core-20040407>.
[W3C.REC-DOM-Level-3-Core-20040407]Le Hors，A.，Ed.，Le Hegaret，P.，Ed.，Wood，L.，Ed.，Nicol，G.，Ed.，Robie，J.，Ed.，Champion，M.，Ed.，和S.Byrne，Ed.，“文档对象模型（DOM）3级核心规范”，万维网联盟建议REC-DOM-Level-3-Core-20040407，2004年4月， <https://www.w3.org/TR/2004/ REC-DOM-Level-3-Core-20040407>。
Acknowledgements
致谢
This document incorporates comments and suggestions offered by Eric Rescorla, Gabriel Montenegro, Martin Thomson, Vinod Anupam, Anthony Nadalin, Michael B. Jones, Bill Cox, Brian Campbell, and others.
本文件包含Eric Rescorla、Gabriel Montegon、Martin Thomson、Vinod Anupam、Anthony Nadalin、Michael B.Jones、Bill Cox、Brian Campbell和其他人提出的意见和建议。
This document was produced under the chairmanship of John Bradley and Leif Johansson. The area directors included Eric Rescorla, Kathleen Moriarty, and Stephen Farrell.
本文件由约翰·布拉德利和莱夫·约翰逊主持编写。区域主管包括Eric Rescorla、Kathleen Moriarty和Stephen Farrell。
Authors' Addresses
作者地址
Andrei Popov Microsoft Corp. United States of America
Andrei Popov微软公司美利坚合众国
Email: andreipo@microsoft.com
Email: andreipo@microsoft.com
Magnus Nystroem Microsoft Corp. United States of America
Magnus Nystroem微软公司美利坚合众国
Email: mnystrom@microsoft.com
Email: mnystrom@microsoft.com
Dirk Balfanz (editor) Google Inc. United States of America
Dirk Balfanz（编辑）美国谷歌公司
Email: balfanz@google.com
Email: balfanz@google.com
Nick Harper Google Inc. United States of America
美国尼克·哈珀谷歌公司
Email: nharper@google.com
Email: nharper@google.com
Jeff Hodges Kings Mountain Systems United States of America
Jeff Hodges Kings Mountain Systems美利坚合众国
Email: Jeff.Hodges@KingsMountain.com
Email: Jeff.Hodges@KingsMountain.com