Internet Engineering Task Force (IETF) M. Jones
Request for Comments: 8414 Microsoft
Category: Standards Track N. Sakimura
ISSN: 2070-1721 NRI
J. Bradley
Yubico
June 2018
Internet Engineering Task Force (IETF) M. Jones
Request for Comments: 8414 Microsoft
Category: Standards Track N. Sakimura
ISSN: 2070-1721 NRI
J. Bradley
Yubico
June 2018
OAuth 2.0 Authorization Server Metadata
OAuth 2.0授权服务器元数据
Abstract
摘要
This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities.
本规范定义了一种元数据格式，OAuth 2.0客户端可使用该格式获取与OAuth 2.0授权服务器交互所需的信息，包括其端点位置和授权服务器功能。
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/rfc8414.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8414.
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 ....................................................2
1.1. Requirements Notation and Conventions ......................3
1.2. Terminology ................................................3
2. Authorization Server Metadata ...................................4
2.1. Signed Authorization Server Metadata .......................8
3. Obtaining Authorization Server Metadata .........................8
3.1. Authorization Server Metadata Request ......................9
3.2. Authorization Server Metadata Response ....................10
3.3. Authorization Server Metadata Validation ..................11
4. String Operations ..............................................11
5. Compatibility Notes ............................................11
6. Security Considerations ........................................12
6.1. TLS Requirements ..........................................12
6.2. Impersonation Attacks .....................................12
6.3. Publishing Metadata in a Standard Format ..................13
6.4. Protected Resources .......................................13
7. IANA Considerations ............................................14
7.1. OAuth Authorization Server Metadata Registry ..............14
7.1.1. Registration Template ..............................15
7.1.2. Initial Registry Contents ..........................16
7.2. Updated Registration Instructions .........................19
7.3. Well-Known URI Registry ...................................19
7.3.1. Registry Contents ..................................19
8. References .....................................................20
8.1. Normative References ......................................20
8.2. Informative References ....................................22
Acknowledgements ..................................................23
Authors' Addresses ................................................23
1. Introduction ....................................................2
1.1. Requirements Notation and Conventions ......................3
1.2. Terminology ................................................3
2. Authorization Server Metadata ...................................4
2.1. Signed Authorization Server Metadata .......................8
3. Obtaining Authorization Server Metadata .........................8
3.1. Authorization Server Metadata Request ......................9
3.2. Authorization Server Metadata Response ....................10
3.3. Authorization Server Metadata Validation ..................11
4. String Operations ..............................................11
5. Compatibility Notes ............................................11
6. Security Considerations ........................................12
6.1. TLS Requirements ..........................................12
6.2. Impersonation Attacks .....................................12
6.3. Publishing Metadata in a Standard Format ..................13
6.4. Protected Resources .......................................13
7. IANA Considerations ............................................14
7.1. OAuth Authorization Server Metadata Registry ..............14
7.1.1. Registration Template ..............................15
7.1.2. Initial Registry Contents ..........................16
7.2. Updated Registration Instructions .........................19
7.3. Well-Known URI Registry ...................................19
7.3.1. Registry Contents ..................................19
8. References .....................................................20
8.1. Normative References ......................................20
8.2. Informative References ....................................22
Acknowledgements ..................................................23
Authors' Addresses ................................................23
This specification generalizes the metadata format defined by "OpenID Connect Discovery 1.0" [OpenID.Discovery] in a way that is compatible with OpenID Connect Discovery while being applicable to a wider set of OAuth 2.0 use cases. This is intentionally parallel to the way that "OAuth 2.0 Dynamic Client Registration Protocol" [RFC7591] generalized the dynamic client registration mechanisms defined by "OpenID Connect Dynamic Client Registration 1.0" [OpenID.Registration] in a way that is compatible with it.
本规范概括了“OpenID Connect Discovery 1.0”[OpenID.Discovery]定义的元数据格式，其方式与OpenID Connect Discovery兼容，同时适用于更广泛的OAuth 2.0用例集。这有意与“OAuth 2.0动态客户端注册协议”[RFC7591]以与之兼容的方式概括了“OpenID连接动态客户端注册1.0”[OpenID.Registration]定义的动态客户端注册机制的方式平行。
The metadata for an authorization server is retrieved from a well-known location as a JSON [RFC8259] document, which declares its endpoint locations and authorization server capabilities. This process is described in Section 3.
授权服务器的元数据作为JSON[RFC8259]文档从一个众所周知的位置检索，该文档声明其端点位置和授权服务器功能。第3节描述了该过程。
This metadata can be communicated either in a self-asserted fashion by the server origin via HTTPS or as a set of signed metadata values represented as claims in a JSON Web Token (JWT) [JWT]. In the JWT case, the issuer is vouching for the validity of the data about the authorization server. This is analogous to the role that the Software Statement plays in OAuth Dynamic Client Registration [RFC7591].
该元数据可以由服务器源通过HTTPS以自断言的方式进行通信，也可以作为JSON Web令牌（JWT）[JWT]中声明的一组签名元数据值进行通信。在JWT案例中，发卡机构正在为有关授权服务器的数据的有效性提供担保。这类似于软件语句在OAuth动态客户端注册[RFC7591]中所起的作用。
The means by which the client chooses an authorization server is out of scope. In some cases, its issuer identifier may be manually configured into the client. In other cases, it may be dynamically discovered, for instance, through the use of WebFinger [RFC7033], as described in Section 2 of "OpenID Connect Discovery 1.0" [OpenID.Discovery].
客户端选择授权服务器的方式超出范围。在某些情况下，其发行者标识符可以手动配置到客户机中。在其他情况下，如“OpenID连接发现1.0”[OpenID.Discovery]第2节所述，可以通过使用WebFinger[RFC7033]动态发现。
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]所述进行解释。
All uses of JSON Web Signature (JWS) [JWS] and JSON Web Encryption (JWE) [JWE] data structures in this specification utilize the JWS Compact Serialization or the JWE Compact Serialization; the JWS JSON Serialization and the JWE JSON Serialization are not used.
本规范中JSON Web签名（JWS）[JWS]和JSON Web加密（JWE）[JWE]数据结构的所有使用都使用JWS紧凑序列化或JWE紧凑序列化；不使用JWS JSON序列化和JWE JSON序列化。
This specification uses the terms "Access Token", "Authorization Code", "Authorization Endpoint", "Authorization Grant", "Authorization Server", "Client", "Client Authentication", "Client Identifier", "Client Secret", "Grant Type", "Protected Resource", "Redirection URI", "Refresh Token", "Resource Owner", "Resource Server", "Response Type", and "Token Endpoint" defined by OAuth 2.0 [RFC6749]; the terms "Claim Name", "Claim Value", and "JSON Web Token (JWT)" defined by JSON Web Token (JWT) [JWT]; and the term "Response Mode" defined by "OAuth 2.0 Multiple Response Type Encoding Practices" [OAuth.Responses].
本规范使用术语“访问令牌”、“授权代码”、“授权端点”、“授权授予”、“授权服务器”、“客户端”、“客户端身份验证”、“客户端标识符”、“客户端机密”、“授权类型”、“受保护资源”、“重定向URI”、“刷新令牌”、“资源所有者”、“资源服务器”、“响应类型”和OAuth 2.0[RFC6749]定义的“令牌端点”；JSON Web令牌（JWT）[JWT]定义的术语“声明名称”、“声明值”和“JSON Web令牌（JWT）”；以及“OAuth 2.0多响应类型编码实践”[OAuth.Responses]定义的术语“响应模式”。
Authorization servers can have metadata describing their configuration. The following authorization server metadata values are used by this specification and are registered in the IANA "OAuth Authorization Server Metadata" registry established in Section 7.1:
授权服务器可以具有描述其配置的元数据。以下授权服务器元数据值由本规范使用，并在第7.1节中建立的IANA“OAuth授权服务器元数据”注册表中注册：
issuer REQUIRED. The authorization server's issuer identifier, which is a URL that uses the "https" scheme and has no query or fragment components. Authorization server metadata is published at a location that is ".well-known" according to RFC 5785 [RFC5785] derived from this issuer identifier, as described in Section 3. The issuer identifier is used to prevent authorization server mix-up attacks, as described in "OAuth 2.0 Mix-Up Mitigation" [MIX-UP].
需要发行人。授权服务器的颁发者标识符，它是一个使用“https”方案的URL，没有查询或片段组件。授权服务器元数据发布在根据RFC 5785[RFC5785]从该颁发者标识符派生的“.well-known”位置，如第3节所述。发卡机构标识符用于防止授权服务器混淆攻击，如“OAuth 2.0混淆缓解”[mix-up]中所述。
authorization_endpoint URL of the authorization server's authorization endpoint [RFC6749]. This is REQUIRED unless no grant types are supported that use the authorization endpoint.
授权\授权服务器授权端点的授权端点URL[RFC6749]。这是必需的，除非不支持使用授权端点的授权类型。
token_endpoint URL of the authorization server's token endpoint [RFC6749]. This is REQUIRED unless only the implicit grant type is supported.
授权服务器的令牌终结点的令牌\终结点URL[RFC6749]。除非仅支持隐式授予类型，否则这是必需的。
jwks_uri OPTIONAL. URL of the authorization server's JWK Set [JWK] document. The referenced document contains the signing key(s) the client uses to validate signatures from the authorization server. This URL MUST use the "https" scheme. The JWK Set MAY also contain the server's encryption key or keys, which are used by clients to encrypt requests to the server. When both signing and encryption keys are made available, a "use" (public key use) parameter value is REQUIRED for all keys in the referenced JWK Set to indicate each key's intended usage.
jwks_uri是可选的。授权服务器的JWK集[JWK]文档的URL。引用的文档包含客户端用于验证来自授权服务器的签名的签名密钥。此URL必须使用“https”方案。JWK集还可能包含服务器的一个或多个加密密钥，客户端使用这些密钥加密对服务器的请求。当签名密钥和加密密钥都可用时，引用的JWK集中的所有密钥都需要“使用”（公钥使用）参数值，以指示每个密钥的预期用途。
registration_endpoint OPTIONAL. URL of the authorization server's OAuth 2.0 Dynamic Client Registration endpoint [RFC7591].
注册是可选的。授权服务器的OAuth 2.0动态客户端注册终结点的URL[RFC7591]。
scopes_supported RECOMMENDED. JSON array containing a list of the OAuth 2.0 [RFC6749] "scope" values that this authorization server supports. Servers MAY choose not to advertise some supported scope values even when this parameter is used.
建议使用受支持的作用域。包含此授权服务器支持的OAuth 2.0[RFC6749]“范围”值列表的JSON数组。即使使用此参数，服务器也可能选择不公布某些受支持的作用域值。
response_types_supported REQUIRED. JSON array containing a list of the OAuth 2.0 "response_type" values that this authorization server supports. The array values used are the same as those used with the "response_types" parameter defined by "OAuth 2.0 Dynamic Client Registration Protocol" [RFC7591].
需要支持的响应类型。包含此授权服务器支持的OAuth 2.0“response_type”值列表的JSON数组。使用的数组值与“OAuth 2.0动态客户端注册协议”[RFC7591]定义的“response_types”参数使用的数组值相同。
response_modes_supported OPTIONAL. JSON array containing a list of the OAuth 2.0 "response_mode" values that this authorization server supports, as specified in "OAuth 2.0 Multiple Response Type Encoding Practices" [OAuth.Responses]. If omitted, the default is "["query", "fragment"]". The response mode value "form_post" is also defined in "OAuth 2.0 Form Post Response Mode" [OAuth.Post].
响应\支持的模式\可选。JSON数组，包含此授权服务器支持的OAuth 2.0“response_mode”值列表，如“OAuth 2.0多响应类型编码实践”[OAuth.Responses]中所述。如果省略，默认值为“[”查询“，”片段“]”。响应模式值“form_post”也在“OAuth 2.0 form post响应模式”[OAuth.post]中定义。
grant_types_supported OPTIONAL. JSON array containing a list of the OAuth 2.0 grant type values that this authorization server supports. The array values used are the same as those used with the "grant_types" parameter defined by "OAuth 2.0 Dynamic Client Registration Protocol" [RFC7591]. If omitted, the default value is "["authorization_code", "implicit"]".
授予\u支持的类型\u可选。包含此授权服务器支持的OAuth 2.0授权类型值列表的JSON数组。使用的数组值与“OAuth 2.0动态客户端注册协议”[RFC7591]定义的“grant_types”参数使用的数组值相同。如果省略，默认值为“[”授权\代码“，”隐式“]。
token_endpoint_auth_methods_supported OPTIONAL. JSON array containing a list of client authentication methods supported by this token endpoint. Client authentication method values are used in the "token_endpoint_auth_method" parameter defined in Section 2 of [RFC7591]. If omitted, the default is "client_secret_basic" -- the HTTP Basic Authentication Scheme specified in Section 2.3.1 of OAuth 2.0 [RFC6749].
令牌\端点\身份验证\支持的方法\可选。包含此令牌端点支持的客户端身份验证方法列表的JSON数组。[RFC7591]第2节中定义的“token_endpoint_auth_method”参数中使用了客户端身份验证方法值。如果省略，默认值为“client_secret_basic”——OAuth 2.0[RFC6749]第2.3.1节中指定的HTTP基本身份验证方案。
token_endpoint_auth_signing_alg_values_supported OPTIONAL. JSON array containing a list of the JWS signing algorithms ("alg" values) supported by the token endpoint for the signature on the JWT [JWT] used to authenticate the client at the token endpoint for the "private_key_jwt" and "client_secret_jwt" authentication methods. This metadata entry MUST be present if either of these authentication methods are specified in the "token_endpoint_auth_methods_supported" entry. No default algorithms are implied if this entry is omitted. Servers SHOULD support "RS256". The value "none" MUST NOT be used.
令牌\u端点\u身份验证\u签名\u alg\u值\u支持可选。JSON数组，包含JWT[JWT]上签名的令牌端点支持的JWS签名算法（“alg”值）列表，JWT[JWT]用于在令牌端点对客户端进行“私钥”和“客户端机密”身份验证方法的身份验证。如果在“token\u endpoint\u auth\u methods\u supported”条目中指定了这些身份验证方法，则必须存在此元数据条目。如果省略此项，则不会暗示默认算法。服务器应支持“RS256”。不得使用“无”值。
service_documentation OPTIONAL. URL of a page containing human-readable information that developers might want or need to know when using the authorization server. In particular, if the authorization server
服务文档是可选的。包含开发人员在使用授权服务器时可能想要或需要知道的人类可读信息的页面的URL。特别是，如果授权服务器
does not support Dynamic Client Registration, then information on how to register clients needs to be provided in this documentation.
不支持动态客户端注册，则需要在本文档中提供有关如何注册客户端的信息。
ui_locales_supported OPTIONAL. Languages and scripts supported for the user interface, represented as a JSON array of language tag values from BCP 47 [RFC5646]. If omitted, the set of supported languages and scripts is unspecified.
ui\u语言环境\u支持可选。用户界面支持的语言和脚本，表示为来自BCP 47[RFC5646]的语言标记值的JSON数组。如果省略，则未指定支持的语言和脚本集。
op_policy_uri OPTIONAL. URL that the authorization server provides to the person registering the client to read about the authorization server's requirements on how the client can use the data provided by the authorization server. The registration process SHOULD display this URL to the person registering the client if it is given. As described in Section 5, despite the identifier "op_policy_uri" appearing to be OpenID-specific, its usage in this specification is actually referring to a general OAuth 2.0 feature that is not specific to OpenID Connect.
op_策略_uri可选。授权服务器向注册客户端的人员提供的URL，以了解授权服务器对客户端如何使用授权服务器提供的数据的要求。注册过程应向注册客户机的人员显示此URL（如果已提供）。如第5节所述，尽管标识符“op_policy_uri”看起来是特定于OpenID的，但它在本规范中的用法实际上是指非特定于OpenID Connect的通用OAuth 2.0特性。
op_tos_uri OPTIONAL. URL that the authorization server provides to the person registering the client to read about the authorization server's terms of service. The registration process SHOULD display this URL to the person registering the client if it is given. As described in Section 5, despite the identifier "op_tos_uri", appearing to be OpenID-specific, its usage in this specification is actually referring to a general OAuth 2.0 feature that is not specific to OpenID Connect.
op_tos_uri可选。授权服务器向注册客户端的人员提供的URL，用于阅读授权服务器的服务条款。注册过程应向注册客户机的人员显示此URL（如果已提供）。如第5节所述，尽管标识符“op_tos_uri”看起来是特定于OpenID的，但其在本规范中的用法实际上是指非特定于OpenID Connect的通用OAuth 2.0特性。
revocation_endpoint OPTIONAL. URL of the authorization server's OAuth 2.0 revocation endpoint [RFC7009].
撤销端点是可选的。授权服务器的OAuth 2.0吊销终结点的URL[RFC7009]。
revocation_endpoint_auth_methods_supported OPTIONAL. JSON array containing a list of client authentication methods supported by this revocation endpoint. The valid client authentication method values are those registered in the IANA "OAuth Token Endpoint Authentication Methods" registry [IANA.OAuth.Parameters]. If omitted, the default is "client_secret_basic" -- the HTTP Basic Authentication Scheme specified in Section 2.3.1 of OAuth 2.0 [RFC6749].
撤销\端点\身份验证\支持的方法\可选。包含此吊销端点支持的客户端身份验证方法列表的JSON数组。有效的客户端身份验证方法值是在IANA“OAuth令牌端点身份验证方法”注册表[IANA.OAuth.Parameters]中注册的值。如果省略，默认值为“client_secret_basic”——OAuth 2.0[RFC6749]第2.3.1节中指定的HTTP基本身份验证方案。
revocation_endpoint_auth_signing_alg_values_supported OPTIONAL. JSON array containing a list of the JWS signing algorithms ("alg" values) supported by the revocation endpoint for the signature on the JWT [JWT] used to authenticate the client at
撤销\端点\身份验证\签名\所有值\支持可选。JSON数组，其中包含JWT[JWT]上签名的撤销端点支持的JWS签名算法（“alg”值）列表，用于在
the revocation endpoint for the "private_key_jwt" and "client_secret_jwt" authentication methods. This metadata entry MUST be present if either of these authentication methods are specified in the "revocation_endpoint_auth_methods_supported" entry. No default algorithms are implied if this entry is omitted. The value "none" MUST NOT be used.
“私钥”和“客户端密钥”身份验证方法的吊销端点。如果在“revocation\u endpoint\u auth\u methods\u supported”条目中指定了其中一种身份验证方法，则必须存在此元数据条目。如果省略此项，则不会暗示默认算法。不得使用“无”值。
introspection_endpoint OPTIONAL. URL of the authorization server's OAuth 2.0 introspection endpoint [RFC7662].
自省\u端点可选。授权服务器的OAuth 2.0内省端点的URL[RFC7662]。
introspection_endpoint_auth_methods_supported OPTIONAL. JSON array containing a list of client authentication methods supported by this introspection endpoint. The valid client authentication method values are those registered in the IANA "OAuth Token Endpoint Authentication Methods" registry [IANA.OAuth.Parameters] or those registered in the IANA "OAuth Access Token Types" registry [IANA.OAuth.Parameters]. (These values are and will remain distinct, due to Section 7.2.) If omitted, the set of supported authentication methods MUST be determined by other means.
自省\端点\验证\方法\支持可选。包含此自省端点支持的客户端身份验证方法列表的JSON数组。有效的客户端身份验证方法值是在IANA“OAuth令牌端点身份验证方法”注册表[IANA.OAuth.Parameters]中注册的值，或在IANA“OAuth访问令牌类型”注册表[IANA.OAuth.Parameters]中注册的值。（由于第7.2节的规定，这些值是并将保持不同的。）如果省略，则必须通过其他方式确定支持的认证方法集。
introspection_endpoint_auth_signing_alg_values_supported OPTIONAL. JSON array containing a list of the JWS signing algorithms ("alg" values) supported by the introspection endpoint for the signature on the JWT [JWT] used to authenticate the client at the introspection endpoint for the "private_key_jwt" and "client_secret_jwt" authentication methods. This metadata entry MUST be present if either of these authentication methods are specified in the "introspection_endpoint_auth_methods_supported" entry. No default algorithms are implied if this entry is omitted. The value "none" MUST NOT be used.
自省\u端点\u身份验证\u签名\u alg\u值\u支持可选。JSON数组，包含JWT[JWT]上签名的内省端点支持的JWS签名算法（“alg”值）列表，用于在内省端点对客户端进行“私钥JWT”和“客户端机密JWT”身份验证方法的身份验证。如果在“内省\端点\身份验证\方法\支持的”条目中指定了这些身份验证方法，则必须存在此元数据条目。如果省略此项，则不会暗示默认算法。不得使用“无”值。
code_challenge_methods_supported OPTIONAL. JSON array containing a list of Proof Key for Code Exchange (PKCE) [RFC7636] code challenge methods supported by this authorization server. Code challenge method values are used in the "code_challenge_method" parameter defined in Section 4.3 of [RFC7636]. The valid code challenge method values are those registered in the IANA "PKCE Code Challenge Methods" registry [IANA.OAuth.Parameters]. If omitted, the authorization server does not support PKCE.
代码\挑战\支持的方法\可选。包含此授权服务器支持的代码交换（PKCE）[RFC7636]代码质询方法的验证密钥列表的JSON数组。代码质询方法值用于[RFC7636]第4.3节中定义的“代码质询方法”参数。有效的代码质询方法值是在IANA“PKCE代码质询方法”注册表[IANA.OAuth.Parameters]中注册的值。如果省略，则授权服务器不支持PKCE。
Additional authorization server metadata parameters MAY also be used. Some are defined by other specifications, such as OpenID Connect Discovery 1.0 [OpenID.Discovery].
还可以使用其他授权服务器元数据参数。有些是由其他规范定义的，如OpenID Connect Discovery 1.0[OpenID.Discovery]。
In addition to JSON elements, metadata values MAY also be provided as a "signed_metadata" value, which is a JSON Web Token (JWT) [JWT] that asserts metadata values about the authorization server as a bundle. A set of claims that can be used in signed metadata is defined in Section 2. The signed metadata MUST be digitally signed or MACed using JSON Web Signature (JWS) [JWS] and MUST contain an "iss" (issuer) claim denoting the party attesting to the claims in the signed metadata. Consumers of the metadata MAY ignore the signed metadata if they do not support this feature. If the consumer of the metadata supports signed metadata, metadata values conveyed in the signed metadata MUST take precedence over the corresponding values conveyed using plain JSON elements.
除了JSON元素外，元数据值还可以作为“签名的_元数据”值提供，该值是一个JSON Web令牌（JWT）[JWT]，它将授权服务器的元数据值作为捆绑包进行断言。第2节定义了一组可用于签名元数据的声明。签名的元数据必须使用JSON Web签名（JWS）[JWS]进行数字签名或标记，并且必须包含一个“iss”（颁发者）声明，表示在签名的元数据中证明声明的一方。元数据的使用者如果不支持此功能，可能会忽略已签名的元数据。如果元数据的使用者支持签名元数据，则签名元数据中传递的元数据值必须优先于使用普通JSON元素传递的相应值。
Signed metadata is included in the authorization server metadata JSON object using this OPTIONAL member:
已签名元数据包含在使用此可选成员的authorization server元数据JSON对象中：
signed_metadata A JWT containing metadata values about the authorization server as claims. This is a string value consisting of the entire signed JWT. A "signed_metadata" metadata value SHOULD NOT appear as a claim in the JWT.
signed_metadata包含授权服务器元数据值的JWT，如声明所述。这是一个由整个带符号JWT组成的字符串值。“签名的_元数据”元数据值不应作为声明出现在JWT中。
Authorization servers supporting metadata MUST make a JSON document containing metadata as specified in Section 2 available at a path formed by inserting a well-known URI string into the authorization server's issuer identifier between the host component and the path component, if any. By default, the well-known URI string used is "/.well-known/oauth-authorization-server". This path MUST use the "https" scheme. The syntax and semantics of ".well-known" are defined in RFC 5785 [RFC5785]. The well-known URI suffix used MUST be registered in the IANA "Well-Known URIs" registry [IANA.well-known].
支持元数据的授权服务器必须使包含第2节中指定元数据的JSON文档在一个路径上可用，该路径是通过在主机组件和路径组件（如果有）之间的授权服务器的颁发者标识符中插入一个众所周知的URI字符串形成的。默认情况下，使用的众所周知的URI字符串是“/.well-known/oauth authorization server”。此路径必须使用“https”方案。“.well-known”的语法和语义在RFC 5785[RFC5785]中有定义。所使用的众所周知的URI后缀必须在IANA“众所周知的URI”注册表[IANA.well-known]中注册。
Different applications utilizing OAuth authorization servers in application-specific ways may define and register different well-known URI suffixes used to publish authorization server metadata as used by those applications. For instance, if the example application uses an OAuth authorization server in an example-specific way, and there are example-specific metadata values that it needs to publish, then it might register and use the "example-configuration" URI suffix and publish the metadata document at the path formed by inserting "/.well-known/example-configuration" between the host and path components of the authorization server's issuer identifier. Alternatively, many such applications will use the default well-known
以特定于应用程序的方式使用OAuth授权服务器的不同应用程序可以定义和注册用于发布这些应用程序使用的授权服务器元数据的不同众所周知的URI后缀。例如，如果示例应用程序以特定于示例的方式使用OAuth授权服务器，并且有特定于示例的元数据值需要发布，那么它可能会注册并使用“示例配置”URI后缀，并在插入“/.well-known/example configuration”形成的路径上发布元数据文档在授权服务器的颁发者标识符的主机和路径组件之间。或者，许多这样的应用程序将使用默认的众所周知的
URI string "/.well-known/oauth-authorization-server", which is the right choice for general-purpose OAuth authorization servers, and not register an application-specific one.
URI字符串“/.well-known/oauth授权服务器”，这是通用oauth授权服务器的正确选择，并且不注册特定于应用程序的服务器。
An OAuth 2.0 application using this specification MUST specify what well-known URI suffix it will use for this purpose. The same authorization server MAY choose to publish its metadata at multiple well-known locations derived from its issuer identifier, for example, publishing metadata at both "/.well-known/example-configuration" and "/.well-known/oauth-authorization-server".
使用此规范的OAuth 2.0应用程序必须指定用于此目的的著名URI后缀。同一授权服务器可以选择在从其颁发者标识符派生的多个已知位置发布其元数据，例如，在“/.well-known/example configuration”和“/.well-known/oauth authorization server”上发布元数据。
Some OAuth applications will choose to use the well-known URI suffix "openid-configuration". As described in Section 5, despite the identifier "/.well-known/openid-configuration", appearing to be OpenID specific, its usage in this specification is actually referring to a general OAuth 2.0 feature that is not specific to OpenID Connect.
一些OAuth应用程序将选择使用众所周知的URI后缀“openid配置”。如第5节所述，尽管标识符“/.well-known/openid configuration”看起来是特定于openid的，但其在本规范中的用法实际上是指非特定于openid Connect的通用OAuth 2.0特性。
An authorization server metadata document MUST be queried using an HTTP "GET" request at the previously specified path.
必须使用HTTP“GET”请求在先前指定的路径上查询授权服务器元数据文档。
The client would make the following request when the issuer identifier is "https://example.com" and the well-known URI suffix is "oauth-authorization-server" to obtain the metadata, since the issuer identifier contains no path component:
当发卡机构标识符为“”时，客户端将发出以下请求https://example.com而众所周知的URI后缀是“oauth authorization server”，用于获取元数据，因为颁发者标识符不包含路径组件：
GET /.well-known/oauth-authorization-server HTTP/1.1
Host: example.com
GET /.well-known/oauth-authorization-server HTTP/1.1
Host: example.com
If the issuer identifier value contains a path component, any terminating "/" MUST be removed before inserting "/.well-known/" and the well-known URI suffix between the host component and the path component. The client would make the following request when the issuer identifier is "https://example.com/issuer1" and the well-known URI suffix is "oauth-authorization-server" to obtain the metadata, since the issuer identifier contains a path component:
如果颁发者标识符值包含路径组件，则在主机组件和路径组件之间插入“/.well-known/”和众所周知的URI后缀之前，必须删除任何终止“/”。当发卡机构标识符为“”时，客户端将发出以下请求https://example.com/issuer1而众所周知的URI后缀是“oauth authorization server”，用于获取元数据，因为颁发者标识符包含一个路径组件：
GET /.well-known/oauth-authorization-server/issuer1 HTTP/1.1
Host: example.com
GET /.well-known/oauth-authorization-server/issuer1 HTTP/1.1
Host: example.com
Using path components enables supporting multiple issuers per host. This is required in some multi-tenant hosting configurations. This use of ".well-known" is for supporting multiple issuers per host; unlike its use in RFC 5785 [RFC5785], it does not provide general information about the host.
使用路径组件可以支持每台主机的多个发卡机构。这在某些多租户托管配置中是必需的。“.well-known”用于支持每个主机的多个发行人；与RFC 5785[RFC5785]中的使用不同，它不提供有关主机的一般信息。
The response is a set of claims about the authorization server's configuration, including all necessary endpoints and public key location information. A successful response MUST use the 200 OK HTTP status code and return a JSON object using the "application/json" content type that contains a set of claims as its members that are a subset of the metadata values defined in Section 2. Other claims MAY also be returned.
响应是一组关于授权服务器配置的声明，包括所有必需的端点和公钥位置信息。成功的响应必须使用200 OK HTTP状态代码，并使用“application/JSON”内容类型返回JSON对象，该内容类型包含一组声明作为其成员，这些声明是第2节中定义的元数据值的子集。其他索赔也可能被退回。
Claims that return multiple values are represented as JSON arrays. Claims with zero elements MUST be omitted from the response.
返回多个值的声明表示为JSON数组。必须从响应中省略包含零元素的声明。
An error response uses the applicable HTTP status code value.
错误响应使用适用的HTTP状态代码值。
The following is a non-normative example response:
以下是非规范性示例响应：
HTTP/1.1 200 OK
Content-Type: application/json
HTTP/1.1 200 OK
Content-Type: application/json
{
"issuer":
"https://server.example.com",
"authorization_endpoint":
"https://server.example.com/authorize",
"token_endpoint":
"https://server.example.com/token",
"token_endpoint_auth_methods_supported":
["client_secret_basic", "private_key_jwt"],
"token_endpoint_auth_signing_alg_values_supported":
["RS256", "ES256"],
"userinfo_endpoint":
"https://server.example.com/userinfo",
"jwks_uri":
"https://server.example.com/jwks.json",
"registration_endpoint":
"https://server.example.com/register",
"scopes_supported":
["openid", "profile", "email", "address",
"phone", "offline_access"],
"response_types_supported":
["code", "code token"],
"service_documentation":
"http://server.example.com/service_documentation.html",
"ui_locales_supported":
["en-US", "en-GB", "en-CA", "fr-FR", "fr-CA"]
}
{
"issuer":
"https://server.example.com",
"authorization_endpoint":
"https://server.example.com/authorize",
"token_endpoint":
"https://server.example.com/token",
"token_endpoint_auth_methods_supported":
["client_secret_basic", "private_key_jwt"],
"token_endpoint_auth_signing_alg_values_supported":
["RS256", "ES256"],
"userinfo_endpoint":
"https://server.example.com/userinfo",
"jwks_uri":
"https://server.example.com/jwks.json",
"registration_endpoint":
"https://server.example.com/register",
"scopes_supported":
["openid", "profile", "email", "address",
"phone", "offline_access"],
"response_types_supported":
["code", "code token"],
"service_documentation":
"http://server.example.com/service_documentation.html",
"ui_locales_supported":
["en-US", "en-GB", "en-CA", "fr-FR", "fr-CA"]
}
The "issuer" value returned MUST be identical to the authorization server's issuer identifier value into which the well-known URI string was inserted to create the URL used to retrieve the metadata. If these values are not identical, the data contained in the response MUST NOT be used.
返回的“issuer”值必须与授权服务器的issuer标识符值相同，其中插入了众所周知的URI字符串，以创建用于检索元数据的URL。如果这些值不相同，则不得使用响应中包含的数据。
Processing some OAuth 2.0 messages requires comparing values in the messages to known values. For example, the member names in the metadata response might be compared to specific member names such as "issuer". Comparing Unicode [UNICODE] strings, however, has significant security implications.
处理某些OAuth 2.0消息需要将消息中的值与已知值进行比较。例如，可以将元数据响应中的成员名称与特定成员名称（如“issuer”）进行比较。但是，比较Unicode[Unicode]字符串具有重要的安全含义。
Therefore, comparisons between JSON strings and other Unicode strings MUST be performed as specified below:
因此，JSON字符串和其他Unicode字符串之间的比较必须按照以下规定执行：
1. Remove any JSON-applied escaping to produce an array of Unicode code points.
1. 删除用于生成Unicode代码点数组的任何JSON。
2. Unicode Normalization [USA15] MUST NOT be applied at any point to either the JSON string or the string it is to be compared against.
2. Unicode规范化[USA15]不得在任何时候应用于JSON字符串或要与之进行比较的字符串。
3. Comparisons between the two strings MUST be performed as a Unicode code-point-to-code-point equality comparison.
3. 两个字符串之间的比较必须作为Unicode代码点到代码点相等比较来执行。
Note that this is the same equality comparison procedure described in Section 8.3 of [RFC8259].
请注意，这与[RFC8259]第8.3节中描述的等式比较程序相同。
The identifiers "/.well-known/openid-configuration", "op_policy_uri", and "op_tos_uri" contain strings referring to the OpenID Connect [OpenID.Core] family of specifications that were originally defined by "OpenID Connect Discovery 1.0" [OpenID.Discovery]. Despite the reuse of these identifiers that appear to be OpenID specific, their usage in this specification is actually referring to general OAuth 2.0 features that are not specific to OpenID Connect.
标识符“/.well-known/openid配置”、“op_policy_uri”和“op_-tos_uri”包含引用最初由“openid-Connect-Discovery 1.0”[openid.Discovery]定义的openid-Connect[openid.Core]规范系列的字符串。尽管重用了这些看起来是特定于OpenID的标识符，但它们在本规范中的用法实际上是指非特定于OpenID Connect的通用OAuth 2.0特性。
The algorithm for transforming the issuer identifier to an authorization server metadata location defined in Section 3 is equivalent to the corresponding transformation defined in Section 4 of "OpenID Connect Discovery 1.0" [OpenID.Discovery], provided that the issuer identifier contains no path component. However, they are different when there is a path component, because OpenID Connect
将发卡机构标识符转换为第3节中定义的授权服务器元数据位置的算法与“OpenID Connect Discovery 1.0”[OpenID.Discovery]第4节中定义的相应转换等效，前提是发卡机构标识符不包含路径组件。但是，当存在路径组件时，它们是不同的，因为OpenID连接
Discovery 1.0 specifies that the well-known URI string is appended to the issuer identifier (e.g., "https://example.com/issuer1/.well-known/openid-configuration"), whereas this specification specifies that the well-known URI string is inserted before the path component of the issuer identifier (e.g., "https://example.com/.well-known/openid-configuration/issuer1").
Discovery 1.0指定将众所周知的URI字符串附加到颁发者标识符（例如“https://example.com/issuer1/.well-known/openid-configuration），而本规范规定在发卡机构标识符的路径组件之前插入众所周知的URI字符串（例如。，"https://example.com/.well-known/openid-configuration/issuer1").
Going forward, OAuth authorization server metadata locations should use the transformation defined in this specification. However, when deployed in legacy environments in which the OpenID Connect Discovery 1.0 transformation is already used, it may be necessary during a transition period to publish metadata for issuer identifiers containing a path component at both locations. During this transition period, applications should first apply the transformation defined in this specification and attempt to retrieve the authorization server metadata from the resulting location; only if the retrieval from that location fails should they fall back to attempting to retrieve it from the alternate location obtained using the transformation defined by OpenID Connect Discovery 1.0. This backwards-compatible behavior should only be necessary when the well-known URI suffix employed by the application is "openid-configuration".
接下来，OAuth授权服务器元数据位置应该使用本规范中定义的转换。但是，当部署在已使用OpenID Connect Discovery 1.0转换的旧式环境中时，可能需要在过渡期间为两个位置都包含路径组件的颁发者标识符发布元数据。在此过渡期间，应用程序应首先应用本规范中定义的转换，并尝试从结果位置检索授权服务器元数据；只有当从该位置检索失败时，他们才会退回到尝试从使用OpenID Connect Discovery 1.0定义的转换获得的备用位置检索它。只有当应用程序使用的众所周知的URI后缀为“openid配置”时，才需要这种向后兼容的行为。
Implementations MUST support TLS. Which version(s) ought to be implemented will vary over time and depend on the widespread deployment and known security vulnerabilities at the time of implementation. The authorization server MUST support TLS version 1.2 [RFC5246] and MAY support additional TLS mechanisms meeting its security requirements. When using TLS, the client MUST perform a TLS/SSL server certificate check, per RFC 6125 [RFC6125]. Implementation security considerations can be found in "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)" [BCP195].
实现必须支持TLS。应实施的版本将随着时间的推移而变化，并取决于广泛的部署和实施时已知的安全漏洞。授权服务器必须支持TLS版本1.2[RFC5246]，并且可以支持满足其安全要求的其他TLS机制。使用TLS时，客户机必须按照RFC 6125[RFC6125]执行TLS/SSL服务器证书检查。实现安全注意事项可在“传输层安全性（TLS）和数据报传输层安全性（DTLS）的安全使用建议”[BCP195]中找到。
To protect against information disclosure and tampering, confidentiality protection MUST be applied using TLS with a ciphersuite that provides confidentiality and integrity protection.
为了防止信息泄露和篡改，必须使用TLS和提供机密性和完整性保护的密码套件应用机密性保护。
TLS certificate checking MUST be performed by the client, as described in Section 6.1, when making an authorization server metadata request. Checking that the server certificate is valid for the issuer identifier URL prevents man-in-middle and DNS-based
如第6.1节所述，当发出授权服务器元数据请求时，必须由客户端执行TLS证书检查。检查服务器证书对于颁发者标识符URL是否有效，可以防止中间人和基于DNS的身份验证
attacks. These attacks could cause a client to be tricked into using an attacker's keys and endpoints, which would enable impersonation of the legitimate authorization server. If an attacker can accomplish this, they can access the resources that the affected client has access to using the authorization server that they are impersonating.
攻击。这些攻击可能会诱使客户端使用攻击者的密钥和端点，这将允许模拟合法的授权服务器。如果攻击者能够完成此操作，则他们可以使用模拟的授权服务器访问受影响客户端有权访问的资源。
An attacker may also attempt to impersonate an authorization server by publishing a metadata document that contains an "issuer" claim using the issuer identifier URL of the authorization server being impersonated, but with its own endpoints and signing keys. This would enable it to impersonate that authorization server, if accepted by the client. To prevent this, the client MUST ensure that the issuer identifier URL it is using as the prefix for the metadata request exactly matches the value of the "issuer" metadata value in the authorization server metadata document received by the client.
攻击者还可能试图通过发布包含“颁发者”声明的元数据文档来模拟授权服务器，该声明使用被模拟的授权服务器的颁发者标识符URL，但使用其自己的端点和签名密钥。如果客户端接受，这将使它能够模拟该授权服务器。为防止出现这种情况，客户端必须确保其用作元数据请求前缀的颁发者标识符URL与客户端接收的授权服务器元数据文档中的“颁发者”元数据值的值完全匹配。
Publishing information about the authorization server in a standard format makes it easier for both legitimate clients and attackers to use the authorization server. Whether an authorization server publishes its metadata in an ad hoc manner or in the standard format defined by this specification, the same defenses against attacks that might be mounted that use this information should be applied.
以标准格式发布有关授权服务器的信息可使合法客户端和攻击者更容易使用授权服务器。无论授权服务器是以特殊方式发布其元数据，还是以本规范定义的标准格式发布其元数据，都应采用与使用此信息的攻击相同的防御措施。
Secure determination of appropriate protected resources to use with an authorization server for all use cases is out of scope of this specification. This specification assumes that the client has a means of determining appropriate protected resources to use with an authorization server and that the client is using the correct metadata for each authorization server. Implementers need to be aware that if an inappropriate protected resource is used by the client, that an attacker may be able to act as a man-in-the-middle proxy to a valid protected resource without it being detected by the authorization server or the client.
对于所有用例，安全确定要与授权服务器一起使用的适当受保护资源超出了本规范的范围。本规范假定客户端有一种方法来确定要与授权服务器一起使用的适当受保护资源，并且客户端正在为每个授权服务器使用正确的元数据。实施者需要知道，如果客户端使用了不适当的受保护资源，攻击者可能会充当有效受保护资源的中间人代理，而不会被授权服务器或客户端检测到。
The ways to determine the appropriate protected resources to use with an authorization server are, in general, application dependent. For instance, some authorization servers are used with a fixed protected resource or set of protected resources, the locations of which may be well known or could be published as metadata values by the authorization server. In other cases, the set of resources that can be used with an authorization server can be dynamically changed by administrative actions. Many other means of determining appropriate associations between authorization servers and protected resources are also possible.
通常，确定与授权服务器一起使用的适当受保护资源的方法取决于应用程序。例如，某些授权服务器与固定的受保护资源或一组受保护资源一起使用，这些资源的位置可能是众所周知的，或者授权服务器可以将其发布为元数据值。在其他情况下，可以通过管理操作动态更改授权服务器使用的资源集。确定授权服务器和受保护资源之间的适当关联的许多其他方法也是可能的。
The following registration procedure is used for the registry established by this specification.
以下注册程序用于本规范建立的注册表。
Values are registered on a Specification Required [RFC8126] basis after a two-week review period on the oauth-ext-review@ietf.org mailing list, on the advice of one or more Designated Experts. However, to allow for the allocation of values prior to publication, the Designated Experts may approve registration once they are satisfied that such a specification will be published.
在oauth ext上经过两周的审查后，根据规范要求[RFC8126]注册值-review@ietf.org根据一名或多名指定专家的建议，提供邮件列表。但是，为了允许在发布之前分配值，指定专家在确信此类规范将发布后，可批准注册。
Registration requests sent to the mailing list for review should use an appropriate subject (e.g., "Request to register OAuth Authorization Server Metadata: example").
发送到邮件列表供审查的注册请求应使用适当的主题（例如，“注册OAuth授权服务器元数据的请求：示例”）。
Within the review period, the Designated Experts will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. Registration requests that are undetermined for a period longer than 21 days can be brought to the IESG's attention (using the iesg@ietf.org mailing list) for resolution.
在审查期内，指定专家将批准或拒绝注册请求，并将此决定告知审查名单和IANA。拒绝应包括解释，以及（如适用）关于如何使请求成功的建议。超过21天未确定的注册请求可提请IESG注意（使用iesg@ietf.org邮件列表）以供解决。
Criteria that should be applied by the Designated Experts include determining whether the proposed registration duplicates existing functionality, determining whether it is likely to be of general applicability or whether it is useful only for a single application, and whether the registration makes sense.
指定专家应适用的标准包括确定拟议的登记是否与现有功能重复，确定其是否可能具有普遍适用性，或是否仅对单一申请有用，以及登记是否有意义。
IANA must only accept registry updates from the Designated Experts and should direct all requests for registration to the review mailing list.
IANA必须只接受指定专家的注册更新，并将所有注册请求发送至审查邮件列表。
It is suggested that multiple Designated Experts be appointed who are able to represent the perspectives of different applications using this specification, in order to enable broadly-informed review of registration decisions. In cases where a registration decision could be perceived as creating a conflict of interest for a particular Designated Expert, that Designated Expert should defer to the judgment of the other Designated Experts.
建议任命多名指定专家，他们能够代表使用本规范的不同应用的观点，以便对注册决定进行广泛知情的审查。如果注册决定可能被视为对特定指定专家造成利益冲突，则该指定专家应服从其他指定专家的判断。
This specification establishes the IANA "OAuth Authorization Server Metadata" registry for OAuth 2.0 authorization server metadata names. The registry records the authorization server metadata member and a reference to the specification that defines it.
本规范为OAuth 2.0授权服务器元数据名称建立IANA“OAuth授权服务器元数据”注册表。注册表记录授权服务器元数据成员以及对定义该成员的规范的引用。
The Designated Experts must either:
指定专家必须：
(a) require that metadata names and values being registered use only
printable ASCII characters excluding double quote ('"') and backslash
('\') (the Unicode characters with code points U+0021, U+0023 through
U+005B, and U+005D through U+007E), or
(a) require that metadata names and values being registered use only
printable ASCII characters excluding double quote ('"') and backslash
('\') (the Unicode characters with code points U+0021, U+0023 through
U+005B, and U+005D through U+007E), or
(b) if new metadata members or values are defined that use other code points, require that their definitions specify the exact sequences of Unicode code points used to represent them. Furthermore, proposed registrations that use Unicode code points that can only be represented in JSON strings as escaped characters must not be accepted.
(b) 如果定义了使用其他代码点的新元数据成员或值，则要求其定义指定用于表示它们的Unicode代码点的精确序列。此外，不得接受使用Unicode代码点（只能在JSON字符串中表示为转义字符）的拟议注册。
Metadata Name: The name requested (e.g., "issuer"). This name is case-sensitive. Names may not match other registered names in a case-insensitive manner (one that would cause a match if the Unicode toLowerCase() operation were applied to both strings) unless the Designated Experts state that there is a compelling reason to allow an exception.
元数据名称：请求的名称（例如，“颁发者”）。此名称区分大小写。名称不能以不区分大小写的方式与其他注册名称匹配（如果Unicode toLowerCase（）操作应用于两个字符串，则会导致匹配），除非指定的专家声明有令人信服的理由允许出现异常。
Metadata Description: Brief description of the metadata (e.g., "Issuer identifier URL").
元数据描述：元数据的简要描述（例如，“颁发者标识符URL”）。
Change Controller: For Standards Track RFCs, list the "IESG". For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included.
更改控制器：对于标准跟踪RFC，请列出“IESG”。对于其他人，请提供责任方的名称。还可以包括其他详细信息（例如，邮政地址、电子邮件地址、主页URI）。
Specification Document(s): Reference to the document or documents that specify the parameter, preferably including URIs that can be used to retrieve copies of the documents. An indication of the relevant sections may also be included but is not required.
规范文档：指指定参数的一个或多个文档，最好包括可用于检索文档副本的URI。也可以包括相关章节的指示，但不需要。
o Metadata Name: issuer o Metadata Description: Authorization server's issuer identifier URL o Change Controller: IESG o Specification Document(s): Section 2 of RFC 8414
o 元数据名称：颁发者o元数据描述：授权服务器的颁发者标识符URL o更改控制器：IESG o规范文件：RFC 8414第2节
o Metadata Name: authorization_endpoint o Metadata Description: URL of the authorization server's authorization endpoint o Change Controller: IESG o Specification Document(s): Section 2 of RFC 8414
o 元数据名称：授权\端点o元数据描述：授权服务器的授权端点的URL o更改控制器：IESG o规范文档：RFC 8414第2节
o Metadata Name: token_endpoint o Metadata Description: URL of the authorization server's token endpoint o Change Controller: IESG o Specification Document(s): Section 2 of RFC 8414
o 元数据名称：令牌\端点o元数据描述：授权服务器令牌端点的URL o更改控制器：IESG o规范文档：RFC 8414第2节
o Metadata Name: jwks_uri o Metadata Description: URL of the authorization server's JWK Set document o Change Controller: IESG o Specification Document(s): Section 2 of RFC 8414
o 元数据名称：jwks_uri o元数据描述：授权服务器的JWK集合文档的URL o更改控制器：IESG o规范文档：RFC 8414第2节
o Metadata Name: registration_endpoint o Metadata Description: URL of the authorization server's OAuth 2.0 Dynamic Client Registration Endpoint o Change Controller: IESG o Specification Document(s): Section 2 of RFC 8414
o 元数据名称：注册\端点o元数据描述：授权服务器的OAuth 2.0动态客户端注册端点的URL o更改控制器：IESG o规范文档：RFC 8414第2节
o Metadata Name: scopes_supported o Metadata Description: JSON array containing a list of the OAuth 2.0 "scope" values that this authorization server supports o Change Controller: IESG o Specification Document(s): Section 2 of RFC 8414
o 元数据名称：scopes\u supported o元数据描述：JSON数组，包含此授权服务器支持的OAuth 2.0“scope”值列表o更改控制器：IESG o规范文档：RFC 8414第2节
o Metadata Name: response_types_supported o Metadata Description: JSON array containing a list of the OAuth 2.0 "response_type" values that this authorization server supports o Change Controller: IESG o Specification Document(s): Section 2 of RFC 8414
o 元数据名称：响应类型\u支持的o元数据描述：包含此授权服务器支持的OAuth 2.0“响应类型”值列表的JSON数组o更改控制器：IESG o规范文档：RFC 8414第2节
o Metadata Name: response_modes_supported o Metadata Description: JSON array containing a list of the OAuth 2.0 "response_mode" values that this authorization server supports o Change Controller: IESG o Specification Document(s): Section 2 of RFC 8414
o 元数据名称：响应\模式\支持的o元数据描述：包含此授权服务器支持的OAuth 2.0“响应\模式”值列表的JSON数组o更改控制器：IESG o规范文档：RFC 8414第2节
o Metadata Name: grant_types_supported o Metadata Description: JSON array containing a list of the OAuth 2.0 grant type values that this authorization server supports o Change Controller: IESG o Specification Document(s): Section 2 of RFC 8414
o 元数据名称：grant\u types\u supported o元数据描述：包含此授权服务器支持的OAuth 2.0授予类型值列表的JSON数组o更改控制器：IESG o规范文档：RFC 8414第2节
o Metadata Name: token_endpoint_auth_methods_supported o Metadata Description: JSON array containing a list of client authentication methods supported by this token endpoint o Change Controller: IESG o Specification Document(s): Section 2 of RFC 8414
o 元数据名称：令牌\端点\身份验证\方法\支持的元数据描述：包含此令牌端点支持的客户端身份验证方法列表的JSON数组o更改控制器：IESG o规范文档：RFC 8414第2节
o Metadata Name: token_endpoint_auth_signing_alg_values_supported o Metadata Description: JSON array containing a list of the JWS signing algorithms supported by the token endpoint for the signature on the JWT used to authenticate the client at the token endpoint o Change Controller: IESG o Specification Document(s): Section 2 of RFC 8414
o 元数据名称：token\u endpoint\u auth\u signing\u alg\u values\u supported o元数据描述：包含token端点支持的JWS签名算法列表的JSON数组，JWT上的签名用于在token端点对客户端进行身份验证o更改控制器：IESG o规范文档：RFC 8414第2节
o Metadata Name: service_documentation o Metadata Description: URL of a page containing human-readable information that developers might want or need to know when using the authorization server o Change Controller: IESG o Specification Document(s): Section 2 of RFC 8414
o 元数据名称：服务文档o元数据描述：包含开发人员在使用授权服务器时可能想要或需要知道的人类可读信息的页面URL o更改控制器：IESG o规范文档：RFC 8414第2节
o Metadata Name: ui_locales_supported o Metadata Description: Languages and scripts supported for the user interface, represented as a JSON array of language tag values from BCP 47 o Change Controller: IESG o Specification Document(s): Section 2 of RFC 8414
o 元数据名称：ui_locales_supported o元数据描述：用户界面支持的语言和脚本，表示为BCP 47中语言标记值的JSON数组o更改控制器：IESG o规范文档：RFC 8414第2节
o Metadata Name: op_policy_uri o Metadata Description: URL that the authorization server provides to the person registering the client to read about the authorization server's requirements on how the client can use the data provided by the authorization server o Change Controller: IESG o Specification Document(s): Section 2 of RFC 8414
o 元数据名称：op_policy_uri o元数据描述：授权服务器向注册客户端的人员提供的URL，以了解授权服务器对客户端如何使用授权服务器提供的数据的要求o更改控制器：IESG o规范文档：RFC 8414第2节
o Metadata Name: op_tos_uri o Metadata Description: URL that the authorization server provides to the person registering the client to read about the authorization server's terms of service o Change Controller: IESG o Specification Document(s): Section 2 of RFC 8414
o 元数据名称：op_tos_uri o元数据描述：授权服务器向注册客户端的人员提供的URL，用于阅读授权服务器的服务条款o更改控制器：IESG o规范文档：RFC 8414第2节
o Metadata Name: revocation_endpoint o Metadata Description: URL of the authorization server's OAuth 2.0 revocation endpoint o Change Controller: IESG o Specification Document(s): Section 2 of RFC 8414
o 元数据名称：吊销\端点o元数据描述：授权服务器的OAuth 2.0吊销端点o更改控制器的URL:IESG o规范文档：RFC 8414的第2节
o Metadata Name: revocation_endpoint_auth_methods_supported o Metadata Description: JSON array containing a list of client authentication methods supported by this revocation endpoint o Change Controller: IESG o Specification Document(s): Section 2 of RFC 8414
o 元数据名称：吊销\端点\认证\方法\支持的元数据描述：包含此吊销端点支持的客户端身份验证方法列表的JSON数组o更改控制器：IESG o规范文档：RFC 8414第2节
o Metadata Name: revocation_endpoint_auth_signing_alg_values_supported o Metadata Description: JSON array containing a list of the JWS signing algorithms supported by the revocation endpoint for the signature on the JWT used to authenticate the client at the revocation endpoint o Change Controller: IESG o Specification Document(s): Section 2 of RFC 8414
o 元数据名称：吊销\u端点\u身份验证\u签名\u alg\u值\u支持的o元数据描述：JSON数组，包含吊销端点支持的JWS签名算法列表，用于在JWT上签名，用于在吊销端点对客户端进行身份验证o更改控制器：IESG o规范文档：RFC 8414第2节
o Metadata Name: introspection_endpoint o Metadata Description: URL of the authorization server's OAuth 2.0 introspection endpoint o Change Controller: IESG o Specification Document(s): Section 2 of RFC 8414
o 元数据名称：内省\端点o元数据描述：授权服务器的OAuth 2.0内省端点的URL o更改控制器：IESG o规范文档：RFC 8414的第2节
o Metadata Name: introspection_endpoint_auth_methods_supported o Metadata Description: JSON array containing a list of client authentication methods supported by this introspection endpoint o Change Controller: IESG o Specification Document(s): Section 2 of RFC 8414
o 元数据名称：内省\端点\身份验证\方法\支持的元数据描述：包含此内省端点支持的客户端身份验证方法列表的JSON数组o更改控制器：IESG o规范文档：RFC 8414第2节
o Metadata Name: introspection_endpoint_auth_signing_alg_values_supported o Metadata Description: JSON array containing a list of the JWS signing algorithms supported by the introspection endpoint for the signature on the JWT used to authenticate the client at the introspection endpoint o Change Controller: IESG o Specification Document(s): Section 2 of RFC 8414
o 元数据名称：内省\u端点\u身份验证\u签名\u alg\u值\u支持的元数据描述：JSON数组，包含内省端点支持的JWS签名算法列表，用于在JWT上签名，用于在内省端点对客户端进行身份验证o更改控制器：IESG o规范文档：RFC 8414第2节
o Metadata Name: code_challenge_methods_supported o Metadata Description: PKCE code challenge methods supported by this authorization server o Change Controller: IESG o Specification Document(s): Section 2 of RFC 8414
o 元数据名称：代码\u质询\u方法\u支持的o元数据描述：此授权服务器支持的PKCE代码质询方法o更改控制器：IESG o规范文档：RFC 8414第2节
o Metadata Name: signed_metadata o Metadata Description: Signed JWT containing metadata values about the authorization server as claims o Change Controller: IESG o Specification Document(s): Section 2.1 of RFC 8414
o 元数据名称：signed_Metadata o元数据描述：signed JWT包含关于授权服务器的元数据值，如声明o更改控制器：IESG o规范文档：RFC 8414第2.1节
This specification adds to the instructions for the Designated Experts of the following IANA registries, both of which are in the "OAuth Parameters" registry [IANA.OAuth.Parameters]:
本规范增加了以下IANA注册中心指定专家的说明，这两个注册中心均位于“OAuth参数”注册中心[IANA.OAuth.Parameters]：
o OAuth Access Token Types o OAuth Token Endpoint Authentication Methods
o OAuth访问令牌类型o OAuth令牌端点身份验证方法
IANA has added a link to this specification in the Reference sections of these registries.
IANA在这些注册中心的参考章节中添加了到本规范的链接。
For these registries, the Designated Experts must reject registration requests in one registry for values already occurring in the other registry. This is necessary because the "introspection_endpoint_auth_methods_supported" parameter allows for the use of values from either registry. That way, because the values in the two registries will continue to be mutually exclusive, no ambiguities will arise.
对于这些登记册，指定专家必须拒绝一个登记册中已在另一个登记册中出现的价值的登记请求。这是必要的，因为“introspection\u endpoint\u auth\u methods\u supported”参数允许使用来自任一注册表的值。这样，由于两个登记册中的值将继续相互排斥，因此不会出现歧义。
This specification registers the well-known URI defined in Section 3 in the IANA "Well-Known URIs" registry [IANA.well-known] established by RFC 5785 [RFC5785].
本规范在RFC 5785[RFC5785]建立的IANA“已知URI”注册表[IANA.well-known]中注册第3节中定义的已知URI。
o URI suffix: oauth-authorization-server o Change controller: IESG o Specification document: Section 3 of RFC 8414 o Related information: (none)
o URI后缀：oauth授权服务器o变更控制器：IESG o规范文档：RFC 8414 o第3节相关信息：（无）
[BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, May 2015, <http://www.rfc-editor.org/info/bcp195>.
[BCP195]Sheffer，Y.，Holz，R.，和P.Saint Andre，“安全使用传输层安全性（TLS）和数据报传输层安全性（DTLS）的建议”，BCP 195，RFC 75252015年5月<http://www.rfc-editor.org/info/bcp195>.
[IANA.OAuth.Parameters] IANA, "OAuth Parameters", <https://www.iana.org/assignments/oauth-parameters>.
[IANA.OAuth.Parameters]IANA，“OAuth参数”<https://www.iana.org/assignments/oauth-parameters>.
[JWE] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015, <https://www.rfc-editor.org/info/rfc7516>.
[JWE]Jones，M.和J.Hildebrand，“JSON Web加密（JWE）”，RFC 7516，DOI 10.17487/RFC7516，2015年5月<https://www.rfc-editor.org/info/rfc7516>.
[JWK] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, <https://www.rfc-editor.org/info/rfc7517>.
[JWK]Jones，M.，“JSON Web密钥（JWK）”，RFC 7517，DOI 10.17487/RFC75172015年5月<https://www.rfc-editor.org/info/rfc7517>.
[JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://www.rfc-editor.org/info/rfc7515>.
[JWS]Jones，M.，Bradley，J.，和N.Sakimura，“JSON网络签名（JWS）”，RFC 7515，DOI 10.17487/RFC7515，2015年5月<https://www.rfc-editor.org/info/rfc7515>.
[JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <https://www.rfc-editor.org/info/rfc7519>.
[JWT]Jones，M.，Bradley，J.，和N.Sakimura，“JSON网络令牌（JWT）”，RFC 7519，DOI 10.17487/RFC7519，2015年5月<https://www.rfc-editor.org/info/rfc7519>.
[OAuth.Post] Jones, M. and B. Campbell, "OAuth 2.0 Form Post Response Mode", April 2015, <http://openid.net/specs/ oauth-v2-form-post-response-mode-1_0.html>.
[OAuth.Post]Jones，M.和B.Campbell，“OAuth 2.0表单Post响应模式”，2015年4月<http://openid.net/specs/ oauth-v2-form-post-response-mode-1_0.html>。
[OAuth.Responses] de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M. Jones, "OAuth 2.0 Multiple Response Type Encoding Practices", February 2014, <http://openid.net/specs/ oauth-v2-multiple-response-types-1_0.html>.
[OAuth.Responses]de Medeiros，B.，Ed.，Scurtescu，M.，Tarjan，P.，和M.Jones，“OAuth 2.0多响应类型编码实践”，2014年2月<http://openid.net/specs/ oauth-v2-multiple-response-types-1_0.html>。
[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>.
[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>.
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, <https://www.rfc-editor.org/info/rfc5646>.
[RFC5646]Phillips，A.，Ed.和M.Davis，Ed.，“识别语言的标签”，BCP 47，RFC 5646，DOI 10.17487/RFC5646，2009年9月<https://www.rfc-editor.org/info/rfc5646>.
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, DOI 10.17487/RFC5785, April 2010, <https://www.rfc-editor.org/info/rfc5785>.
[RFC5785]诺丁汉，M.和E.Hammer Lahav，“定义众所周知的统一资源标识符（URI）”，RFC 5785，DOI 10.17487/RFC5785，2010年4月<https://www.rfc-editor.org/info/rfc5785>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC6125]Saint Andre，P.和J.Hodges，“在传输层安全（TLS）环境下使用X.509（PKIX）证书在互联网公钥基础设施内表示和验证基于域的应用程序服务身份”，RFC 6125，DOI 10.17487/RFC6125，2011年3月<https://www.rfc-editor.org/info/rfc6125>.
[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>.
[RFC7009] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth 2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009, August 2013, <https://www.rfc-editor.org/info/rfc7009>.
[RFC7009]Lodderstdt，T.，Ed.，Dronia，S.，和M.Scurtescu，“OAuth 2.0代币撤销”，RFC 7009，DOI 10.17487/RFC70092013年8月<https://www.rfc-editor.org/info/rfc7009>.
[RFC7033] Jones, P., Salgueiro, G., Jones, M., and J. Smarr, "WebFinger", RFC 7033, DOI 10.17487/RFC7033, September 2013, <https://www.rfc-editor.org/info/rfc7033>.
[RFC7033]Jones，P.，Salgueiro，G.，Jones，M.，和J.Smarr，“网络手指”，RFC 7033，DOI 10.17487/RFC70332013年9月<https://www.rfc-editor.org/info/rfc7033>.
[RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", RFC 7591, DOI 10.17487/RFC7591, July 2015, <https://www.rfc-editor.org/info/rfc7591>.
[RFC7591]Richer，J.，Ed.，Jones，M.，Bradley，J.，Machulak，M.，和P.Hunt，“OAuth 2.0动态客户端注册协议”，RFC 7591，DOI 10.17487/RFC7591，2015年7月<https://www.rfc-editor.org/info/rfc7591>.
[RFC7636] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key for Code Exchange by OAuth Public Clients", RFC 7636, DOI 10.17487/RFC7636, September 2015, <https://www.rfc-editor.org/info/rfc7636>.
[RFC7636]Sakimura，N.，Ed.，Bradley，J.，和N.Agarwal，“OAuth公共客户代码交换的证明密钥”，RFC 7636，DOI 10.17487/RFC76362015年9月<https://www.rfc-editor.org/info/rfc7636>.
[RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, October 2015, <https://www.rfc-editor.org/info/rfc7662>.
[RFC7662]Richer，J.，Ed.“OAuth 2.0令牌内省”，RFC 7662，DOI 10.17487/RFC7662，2015年10月<https://www.rfc-editor.org/info/rfc7662>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]Cotton，M.，Leiba，B.，和T.Narten，“在RFC中编写IANA考虑事项部分的指南”，BCP 26，RFC 8126，DOI 10.17487/RFC8126，2017年6月<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.
[RFC8259]Bray，T.，Ed.“JavaScript对象表示法（JSON）数据交换格式”，STD 90，RFC 8259，DOI 10.17487/RFC8259，2017年12月<https://www.rfc-editor.org/info/rfc8259>.
[UNICODE] The Unicode Consortium, "The Unicode Standard", <http://www.unicode.org/versions/latest/>.
[UNICODE]UNICODE联盟，“UNICODE标准”<http://www.unicode.org/versions/latest/>.
[USA15] Davis, M., Ed. and K. Whistler, Ed., "Unicode Normalization Forms", Unicode Standard Annex #15, May 2018, <http://www.unicode.org/reports/tr15/>.
[USA15]Davis，M.，Ed.和K.Whistler，Ed.，“Unicode规范化格式”，Unicode标准附件#15，2018年5月<http://www.unicode.org/reports/tr15/>.
[IANA.well-known] IANA, "Well-Known URIs", <https://www.iana.org/assignments/well-known-uris>.
[IANA.知名]IANA，“知名URI”<https://www.iana.org/assignments/well-known-uris>.
[MIX-UP] Jones, M., Bradley, J., and N. Sakimura, "OAuth 2.0 Mix-Up Mitigation", Work in Progress, draft-ietf-oauth-mix-up-mitigation-01, July 2016.
[MIX-UP]Jones，M.，Bradley，J.，和N.Sakimura，“OAuth 2.0 MIX-UP缓解”，正在进行的工作，草稿-ietf-OAuth-MIX-UP-缓解-01，2016年7月。
[OpenID.Core] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, "OpenID Connect Core 1.0", November 2014, <http://openid.net/specs/openid-connect-core-1_0.html>.
[OpenID.Core]北樱村、J.布拉德利、M.琼斯、B.德梅德罗斯和C.莫蒂莫尔，“OpenID连接核心1.0”，2014年11月<http://openid.net/specs/openid-connect-core-1_0.html>.
[OpenID.Discovery] Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID Connect Discovery 1.0", November 2014, <http://openid.net/specs/ openid-connect-discovery-1_0.html>.
[OpenID.Discovery]北樱村、J.布拉德利、M.琼斯和E.杰伊，“OpenID连接发现1.0”，2014年11月<http://openid.net/specs/ openid-connect-discovery-1_0.html>。
[OpenID.Registration] Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect Dynamic Client Registration 1.0", November 2014, <http://openid.net/specs/ openid-connect-registration-1_0.html>.
[OpenID.注册]Sakimura，N.，Bradley，J.，和M.Jones，“OpenID Connect动态客户端注册1.0”，2014年11月<http://openid.net/specs/ openid-connect-registration-1_0.html>。
Acknowledgements
致谢
This specification is based on the OpenID Connect Discovery 1.0 specification, which was produced by the OpenID Connect working group of the OpenID Foundation. This specification standardizes the de facto usage of the metadata format defined by OpenID Connect Discovery to publish OAuth authorization server metadata.
此规范基于OpenID连接发现1规范，该规范由OpenID基金会的OpenID连接工作组生成。此规范标准化了OpenID Connect Discovery定义的元数据格式的实际使用，以发布OAuth授权服务器元数据。
The authors would like to thank the following people for their reviews of this specification: Shwetha Bhandari, Ben Campbell, Brian Campbell, Brian Carpenter, William Denniss, Vladimir Dzhuvinov, Donald Eastlake, Samuel Erdtman, George Fletcher, Dick Hardt, Phil Hunt, Alexey Melnikov, Tony Nadalin, Mark Nottingham, Eric Rescorla, Justin Richer, Adam Roach, Hannes Tschofenig, and Hans Zandbelt.
作者感谢以下人士对本规范的评论：Shwetha Bhandari、Ben Campbell、Brian Campbell、Brian Carpenter、William Denniss、Vladimir Dzhuvinov、Donald Eastlake、Samuel Erdtman、George Fletcher、Dick Hardt、Phil Hunt、Alexey Melnikov、Tony Nadalin、Mark Nottingham、Eric Rescorla、Justin Richer、，亚当·罗奇、汉内斯·茨霍芬尼和汉斯·赞德贝尔特。
Authors' Addresses
作者地址
Michael B. Jones Microsoft
迈克尔·琼斯微软公司
Email: mbj@microsoft.com
URI: http://self-issued.info/
Email: mbj@microsoft.com
URI: http://self-issued.info/
Nat Sakimura Nomura Research Institute, Ltd.
新樱村野村研究所有限公司。
Email: n-sakimura@nri.co.jp
URI: http://nat.sakimura.org/
Email: n-sakimura@nri.co.jp
URI: http://nat.sakimura.org/
John Bradley Yubico
约翰·布拉德利·尤比科
Email: RFC8414@ve7jtb.com
URI: http://www.thread-safe.com/
Email: RFC8414@ve7jtb.com
URI: http://www.thread-safe.com/