Internet Engineering Task Force (IETF) J. Richer, Ed.
Request for Comments: 7592
Category: Experimental M. Jones
ISSN: 2070-1721 Microsoft
J. Bradley
Ping Identity
M. Machulak
Newcastle University
July 2015
Internet Engineering Task Force (IETF) J. Richer, Ed.
Request for Comments: 7592
Category: Experimental M. Jones
ISSN: 2070-1721 Microsoft
J. Bradley
Ping Identity
M. Machulak
Newcastle University
July 2015
OAuth 2.0 Dynamic Client Registration Management Protocol
OAuth 2.0动态客户端注册管理协议
Abstract
摘要
This specification defines methods for management of OAuth 2.0 dynamic client registrations for use cases in which the properties of a registered client may need to be changed during the lifetime of the client. Not all authorization servers supporting dynamic client registration will support these management methods.
本规范定义了用于管理OAuth 2.0动态客户端注册的方法，用于在客户端生命周期内可能需要更改已注册客户端的属性的用例。并非所有支持动态客户端注册的授权服务器都支持这些管理方法。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. 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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7592.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7592.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 4
2. Client Configuration Endpoint . . . . . . . . . . . . . . . . 5
2.1. Client Read Request . . . . . . . . . . . . . . . . . . . 6
2.2. Client Update Request . . . . . . . . . . . . . . . . . . 7
2.3. Client Delete Request . . . . . . . . . . . . . . . . . . 9
3. Client Information Response . . . . . . . . . . . . . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13
7. Normative References . . . . . . . . . . . . . . . . . . . . 13
Appendix A. Registration Tokens and Client Credentials . . . . . 15
A.1. Credential Rotation . . . . . . . . . . . . . . . . . . . 16
Appendix B. Forming the Client Configuration Endpoint URL . . . 16
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 4
2. Client Configuration Endpoint . . . . . . . . . . . . . . . . 5
2.1. Client Read Request . . . . . . . . . . . . . . . . . . . 6
2.2. Client Update Request . . . . . . . . . . . . . . . . . . 7
2.3. Client Delete Request . . . . . . . . . . . . . . . . . . 9
3. Client Information Response . . . . . . . . . . . . . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13
7. Normative References . . . . . . . . . . . . . . . . . . . . 13
Appendix A. Registration Tokens and Client Credentials . . . . . 15
A.1. Credential Rotation . . . . . . . . . . . . . . . . . . . 16
Appendix B. Forming the Client Configuration Endpoint URL . . . 16
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
In order for an OAuth 2.0 client to utilize an OAuth 2.0 authorization server, the client needs specific information to interact with the server, including an OAuth 2.0 client identifier to use with that server. "OAuth 2.0 Dynamic Client Registration Protocol" [RFC7591] describes how an OAuth 2.0 client can be dynamically registered with an authorization server to obtain this information and how metadata about the client can be registered with the server.
为了使OAuth 2.0客户机利用OAuth 2.0授权服务器，客户机需要与服务器交互的特定信息，包括与该服务器一起使用的OAuth 2.0客户机标识符。“OAuth 2.0动态客户端注册协议”[RFC7591]描述了如何在授权服务器上动态注册OAuth 2.0客户端以获取此信息，以及如何在服务器上注册有关客户端的元数据。
This specification extends the core registration specification by defining a set of methods for management of dynamic OAuth 2.0 client registrations beyond those defined in the core registration specification. In some situations, the registered metadata of a client can change over time, either by modification at the authorization server or by a change in the client software itself. This specification provides methods for the current registration state of a client to be queried at the authorization server, methods for the registration of a client to be updated at the authorization server, and methods for the client to be unregistered from the authorization server.
本规范通过定义一组用于管理动态OAuth 2.0客户端注册的方法扩展了核心注册规范，这些方法超出了核心注册规范中定义的方法。在某些情况下，客户机的已注册元数据可能会随着时间的推移而改变，可以通过在授权服务器上进行修改，也可以通过客户机软件本身的改变来改变。本规范提供了在授权服务器上查询客户端当前注册状态的方法、在授权服务器上更新客户端注册的方法以及从授权服务器上注销客户端的方法。
This Experimental RFC is intended to encourage development and deployment of interoperable solutions with the intent that feedback from this experience will inform a future standard.
此实验性RFC旨在鼓励开发和部署可互操作的解决方案，目的是从这一经验中获得的反馈将通知未来的标准。
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
Unless otherwise noted, all the protocol parameter names and values are case sensitive.
除非另有说明，否则所有协议参数名称和值都区分大小写。
This specification uses the terms "access token", "authorization code", "authorization endpoint", "authorization grant", "authorization server", "client", "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] and the terms defined by "OAuth 2.0 Client Dynamic Registration Protocol" [RFC7591].
本规范使用术语“访问令牌”、“授权代码”、“授权端点”、“授权授予”、“授权服务器”、“客户端”、“客户端标识符”、“客户端机密”、“授权类型”、“受保护资源”、“重定向URI”、“刷新令牌”、“资源所有者”、“资源服务器”、“响应类型”和“令牌端点”由OAuth 2.0[RFC6749]和“OAuth 2.0客户端动态注册协议”[RFC7591]定义的术语定义。
This specification defines the following terms:
本规范定义了以下术语：
Client Configuration Endpoint OAuth 2.0 endpoint through which registration information for a registered client can be managed. This URL for this endpoint is returned by the authorization server in the client information response.
客户端配置端点OAuth 2.0端点，通过该端点可以管理已注册客户端的注册信息。此端点的URL由授权服务器在客户端信息响应中返回。
Registration Access Token OAuth 2.0 Bearer Token issued by the authorization server through the client registration endpoint that is used to authenticate the caller when accessing the client's registration information at the client configuration endpoint. This access token is associated with a particular registered client.
注册访问令牌OAuth 2.0由授权服务器通过客户端注册端点发出的承载令牌，用于在客户端配置端点访问客户端的注册信息时对调用方进行身份验证。此访问令牌与特定的已注册客户端相关联。
This extends the flow in "OAuth 2.0 Dynamic Client Registration Protocol" [RFC7591] as follows:
这扩展了“OAuth 2.0动态客户端注册协议”[RFC7591]中的流程，如下所示：
+--------(A)- Initial Access Token (OPTIONAL)
|
| +----(B)- Software Statement (OPTIONAL)
| |
v v
+-----------+ +---------------+
| |--(C)- Client Registration Request -->| Client |
| | | Registration |
| |<-(D)- Client Information Response ---| Endpoint |
| | +---------------+
| |
| | +---------------+
| Client or |--(E)- Read or Update Request ------->| |
| Developer | | |
| |<-(F)- Client Information Response ---| Client |
| | | Configuration |
| | | Endpoint |
| | | |
| |--(G)- Delete Request --------------->| |
| | | |
| |<-(H)- Delete Confirmation -----------| |
+-----------+ +---------------+
+--------(A)- Initial Access Token (OPTIONAL)
|
| +----(B)- Software Statement (OPTIONAL)
| |
v v
+-----------+ +---------------+
| |--(C)- Client Registration Request -->| Client |
| | | Registration |
| |<-(D)- Client Information Response ---| Endpoint |
| | +---------------+
| |
| | +---------------+
| Client or |--(E)- Read or Update Request ------->| |
| Developer | | |
| |<-(F)- Client Information Response ---| Client |
| | | Configuration |
| | | Endpoint |
| | | |
| |--(G)- Delete Request --------------->| |
| | | |
| |<-(H)- Delete Confirmation -----------| |
+-----------+ +---------------+
Figure 1: Abstract Extended Dynamic Client Registration Flow
图1：抽象扩展动态客户端注册流
The abstract OAuth 2.0 client dynamic registration flow illustrated in Figure 1 describes the interaction between the client or developer and the endpoints defined in this specification and its parent. This figure does not demonstrate error conditions. This flow includes the following steps:
图1所示的抽象OAuth 2.0客户端动态注册流描述了客户端或开发人员与本规范中定义的端点及其父节点之间的交互。此图未显示错误情况。此流程包括以下步骤：
(A) Optionally, the client or developer is issued an initial access token for use with the client registration endpoint. The method by which the initial access token is issued to the client or developer is out of scope for this specification.
（A） 可选地，向客户机或开发人员发出初始访问令牌，以便与客户机注册端点一起使用。向客户机或开发人员发出初始访问令牌的方法超出了本规范的范围。
(B) Optionally, the client or developer is issued a software statement for use with the client registration endpoint. The method by which the software statement is issued to the client or developer is out of scope for this specification.
（B） 或者，向客户机或开发人员发出软件语句，以用于客户机注册端点。向客户或开发人员发布软件语句的方法超出本规范的范围。
(C) The client or developer calls the client registration endpoint with its desired registration metadata, optionally including the initial access token from (A) if one is required by the authorization server.
（C） 客户机或开发人员使用其所需的注册元数据调用客户机注册端点，如果授权服务器需要初始访问令牌，还可以选择包括来自（A）的初始访问令牌。
(D) The authorization server registers the client and returns:
（D） 授权服务器注册客户端并返回：
* the client's registered metadata,
* 客户端的注册元数据，
* a client identifier that is unique to the server,
* 服务器唯一的客户端标识符，
* a set of client credentials such as a client secret, if applicable for this client,
* 一组客户端凭据，如客户端机密（如果适用于此客户端），
* a URI pointing to the client configuration endpoint, and
* 指向客户端配置终结点的URI，以及
* a registration access token to be used when calling the client configuration endpoint.
* 调用客户端配置终结点时要使用的注册访问令牌。
(E) The client or developer optionally calls the client configuration endpoint with a read or update request using the registration access token issued in (D). An update request contains all of the client's registered metadata.
（E） 客户机或开发人员可以选择使用（D）中发出的注册访问令牌，通过读取或更新请求调用客户机配置端点。更新请求包含客户端注册的所有元数据。
(F) The authorization server responds with the client's current configuration, potentially including a new registration access token and a new set of client credentials such as a client secret if applicable for this client. If a new registration access token is issued, it replaces the token issued in (D) for all subsequent calls to the client configuration endpoint.
（F） 授权服务器使用客户端的当前配置进行响应，可能包括一个新的注册访问令牌和一组新的客户端凭据，如适用于此客户端的客户端机密。如果发出了新的注册访问令牌，它将替换（D）中发出的令牌，用于对客户端配置端点的所有后续调用。
(G) The client or developer optionally calls the client configuration endpoint with a delete request using the registration access token issued in (D) or (F).
（G） 客户机或开发人员可以选择使用（D）或（F）中发出的注册访问令牌通过删除请求调用客户机配置端点。
(H) The authorization server deprovisions the client and responds with a confirmation that the deletion has taken place.
（H） 授权服务器取消对客户端的提供，并以已执行删除的确认来响应。
The client configuration endpoint is an OAuth 2.0 protected resource that is provisioned by the server to facilitate viewing, updating, and deleting a client's registered information. The location of this
客户端配置端点是由服务器提供的受OAuth 2.0保护的资源，用于方便查看、更新和删除客户端的注册信息。这个地方
endpoint is communicated to the client through the "registration_client_uri" member of the client information response, as specified in Section 3. The client MUST use its registration access token in all calls to this endpoint as an OAuth 2.0 Bearer Token [RFC6750].
端点通过客户端信息响应的“registration\u client\u uri”成员传递给客户端，如第3节所述。客户端必须在对此端点的所有调用中使用其注册访问令牌作为OAuth 2.0承载令牌[RFC6750]。
The client configuration endpoint MUST be protected by a transport-layer security mechanism, as described in Section 5.
客户端配置端点必须由传输层安全机制保护，如第5节所述。
Operations on this endpoint are switched through the use of different HTTP methods [RFC7231]. If an authorization server does not support a particular method on the client configuration endpoint, it MUST respond with the appropriate error code.
此端点上的操作通过使用不同的HTTP方法进行切换[RFC7231]。如果授权服务器不支持客户端配置端点上的特定方法，则它必须使用适当的错误代码进行响应。
To read the current configuration of the client on the authorization server, the client makes an HTTP GET request to the client configuration endpoint, authenticating with its registration access token.
要在授权服务器上读取客户端的当前配置，客户端向客户端配置端点发出HTTP GET请求，并使用其注册访问令牌进行身份验证。
The following is a non-normative example request:
以下是一个非规范性示例请求：
GET /register/s6BhdRkqt3 HTTP/1.1
Accept: application/json
Host: server.example.com
Authorization: Bearer reg-23410913-abewfq.123483
GET /register/s6BhdRkqt3 HTTP/1.1
Accept: application/json
Host: server.example.com
Authorization: Bearer reg-23410913-abewfq.123483
Upon successful read of the information for a currently active client, the authorization server responds with an HTTP 200 OK with content type of "application/json" and a payload as described in Section 3. Some values in the response, including the "client_secret" and "registration_access_token", MAY be different from those in the initial registration response. If the authorization server includes a new client secret and/or registration access token in its response, the client MUST immediately discard its previous client secret and/or registration access token. The value of the "client_id" MUST NOT change from the initial registration response.
成功读取当前活动客户机的信息后，授权服务器将以内容类型为“application/json”的HTTP 200 OK和第3节所述的有效负载进行响应。响应中的某些值，包括“客户端密码”和“注册访问令牌”，可能与初始注册响应中的值不同。如果授权服务器在其响应中包含新的客户端密码和/或注册访问令牌，则客户端必须立即放弃其以前的客户端密码和/或注册访问令牌。“client_id”的值不能从初始注册响应更改。
If the registration access token used to make this request is not valid, the server MUST respond with an error as described in the OAuth Bearer Token Usage specification [RFC6750].
如果用于发出此请求的注册访问令牌无效，服务器必须按照OAuth承载令牌使用规范[RFC6750]中所述的错误进行响应。
If the client does not exist on this server, the server MUST respond with HTTP 401 Unauthorized and the registration access token used to make this request SHOULD be immediately revoked.
如果此服务器上不存在客户端，则服务器必须使用HTTP 401 Unauthorized进行响应，并且用于发出此请求的注册访问令牌应立即撤销。
If the client does not have permission to read its record, the server MUST return an HTTP 403 Forbidden.
如果客户端没有读取其记录的权限，则服务器必须返回HTTP 403。
To update a previously registered client's registration with an authorization server, the client makes an HTTP PUT request to the client configuration endpoint with a content type of "application/ json". The HTTP entity payload is a JSON [RFC7159] document consisting of a JSON object and all parameters as top-level members of that JSON object. This request is authenticated by the registration access token issued to the client.
要更新以前注册的客户端在授权服务器上的注册，客户端向客户端配置端点发出内容类型为“application/json”的HTTP PUT请求。HTTP实体负载是一个JSON[RFC7159]文档，由一个JSON对象和作为该JSON对象顶级成员的所有参数组成。此请求由颁发给客户端的注册访问令牌进行身份验证。
This request MUST include all client metadata fields as returned to the client from a previous registration, read, or update operation. The updated client metadata fields request MUST NOT include the "registration_access_token", "registration_client_uri", "client_secret_expires_at", or "client_id_issued_at" fields described in Section 3.
此请求必须包括从以前的注册、读取或更新操作返回给客户端的所有客户端元数据字段。更新后的客户端元数据字段请求不得包括第3节中所述的“注册访问令牌”、“注册客户端uri”、“客户端机密过期时间”或“客户端id发布时间”字段。
Valid values of client metadata fields in this request MUST replace, not augment, the values previously associated with this client. Omitted fields MUST be treated as null or empty values by the server, indicating the client's request to delete them from the client's registration. The authorization server MAY ignore any null or empty value in the request just as any other value.
此请求中客户端元数据字段的有效值必须替换而不是增加以前与此客户端关联的值。服务器必须将省略的字段视为空值或空值，表示客户端请求从客户端注册中删除这些字段。授权服务器可以像忽略任何其他值一样忽略请求中的任何null或空值。
The client MUST include its "client_id" field in the request, and it MUST be the same as its currently issued client identifier. If the client includes the "client_secret" field in the request, the value of this field MUST match the currently issued client secret for that client. The client MUST NOT be allowed to overwrite its existing client secret with its own chosen value.
客户端必须在请求中包含其“client_id”字段，并且该字段必须与其当前发布的客户端标识符相同。如果客户端在请求中包含“client_secret”字段，则该字段的值必须与该客户端当前发布的客户端密码匹配。不得允许客户端使用其自己选择的值覆盖其现有客户端机密。
For all metadata fields, the authorization server MAY replace any invalid values with suitable default values, and it MUST return any such fields to the client in the response.
对于所有元数据字段，授权服务器可以用合适的默认值替换任何无效值，并且必须在响应中将任何此类字段返回给客户端。
For example, a client could send the following request to the client registration endpoint to update the client registration in the above example with new information.
例如，客户机可以向客户机注册端点发送以下请求，以使用新信息更新上述示例中的客户机注册。
The following is a non-normative example request:
以下是一个非规范性示例请求：
PUT /register/s6BhdRkqt3 HTTP/1.1
Accept: application/json
Host: server.example.com
Authorization: Bearer reg-23410913-abewfq.123483
PUT /register/s6BhdRkqt3 HTTP/1.1
Accept: application/json
Host: server.example.com
Authorization: Bearer reg-23410913-abewfq.123483
{
"client_id": "s6BhdRkqt3",
"client_secret": "cf136dc3c1fc93f31185e5885805d",
"redirect_uris": [
"https://client.example.org/callback",
"https://client.example.org/alt"],
"grant_types": ["authorization_code", "refresh_token"],
"token_endpoint_auth_method": "client_secret_basic",
"jwks_uri": "https://client.example.org/my_public_keys.jwks",
"client_name": "My New Example",
"client_name#fr": "Mon Nouvel Exemple",
"logo_uri": "https://client.example.org/newlogo.png",
"logo_uri#fr": "https://client.example.org/fr/newlogo.png"
}
{
"client_id": "s6BhdRkqt3",
"client_secret": "cf136dc3c1fc93f31185e5885805d",
"redirect_uris": [
"https://client.example.org/callback",
"https://client.example.org/alt"],
"grant_types": ["authorization_code", "refresh_token"],
"token_endpoint_auth_method": "client_secret_basic",
"jwks_uri": "https://client.example.org/my_public_keys.jwks",
"client_name": "My New Example",
"client_name#fr": "Mon Nouvel Exemple",
"logo_uri": "https://client.example.org/newlogo.png",
"logo_uri#fr": "https://client.example.org/fr/newlogo.png"
}
This example uses client metadata values defined in [RFC7591].
此示例使用[RFC7591]中定义的客户端元数据值。
Upon successful update, the authorization server responds with an HTTP 200 OK message with content type "application/json" and a payload as described in Section 3. Some values in the response, including the "client_secret" and "registration_access_token", MAY be different from those in the initial registration response. If the authorization server includes a new client secret and/or registration access token in its response, the client MUST immediately discard its previous client secret and/or registration access token. The value of the "client_id" MUST NOT change from the initial registration response.
成功更新后，授权服务器将以内容类型为“application/json”的HTTP 200 OK消息和第3节所述的有效负载进行响应。响应中的某些值，包括“客户端密码”和“注册访问令牌”，可能与初始注册响应中的值不同。如果授权服务器在其响应中包含新的客户端密码和/或注册访问令牌，则客户端必须立即放弃其以前的客户端密码和/或注册访问令牌。“client_id”的值不能从初始注册响应更改。
If the registration access token used to make this request is not valid, the server MUST respond with an error as described in the OAuth Bearer Token Usage specification [RFC6750].
如果用于发出此请求的注册访问令牌无效，服务器必须按照OAuth承载令牌使用规范[RFC6750]中所述的错误进行响应。
If the client does not exist on this server, the server MUST respond with HTTP 401 Unauthorized, and the registration access token used to make this request SHOULD be immediately revoked.
如果此服务器上不存在客户端，则服务器必须使用HTTP 401 Unauthorized进行响应，并且用于发出此请求的注册访问令牌应立即撤销。
If the client is not allowed to update its records, the server MUST respond with HTTP 403 Forbidden.
如果不允许客户端更新其记录，则服务器必须以HTTP 403 Forbidden进行响应。
If the client attempts to set an invalid metadata field and the authorization server does not set a default value, the authorization server responds with an error as described in [RFC7591].
如果客户端试图设置无效的元数据字段，而授权服务器未设置默认值，则授权服务器将响应[RFC7591]中所述的错误。
To deprovision itself on the authorization server, the client makes an HTTP DELETE request to the client configuration endpoint. This request is authenticated by the registration access token issued to the client.
为了在授权服务器上解除自身的配置，客户机向客户机配置端点发出HTTP DELETE请求。此请求由颁发给客户端的注册访问令牌进行身份验证。
The following is a non-normative example request:
以下是一个非规范性示例请求：
DELETE /register/s6BhdRkqt3 HTTP/1.1
Host: server.example.com
Authorization: Bearer reg-23410913-abewfq.123483
DELETE /register/s6BhdRkqt3 HTTP/1.1
Host: server.example.com
Authorization: Bearer reg-23410913-abewfq.123483
A successful delete action will invalidate the "client_id", "client_secret", and "registration_access_token" for this client, thereby preventing the "client_id" from being used at either the authorization endpoint or token endpoint of the authorization server. If possible, the authorization server SHOULD immediately invalidate all existing authorization grants and currently active access tokens, all refresh tokens, and all other tokens associated with this client.
成功的删除操作将使此客户端的“客户端\u id”、“客户端\u机密”和“注册\u访问\u令牌”无效，从而防止在授权服务器的授权端点或令牌端点使用“客户端\u id”。如果可能，授权服务器应立即使所有现有授权授权和当前活动的访问令牌、所有刷新令牌以及与此客户端关联的所有其他令牌失效。
If a client has been successfully deprovisioned, the authorization server MUST respond with an HTTP 204 No Content message.
如果客户端已成功取消配置，则授权服务器必须以HTTP 204无内容消息响应。
If the server does not support the delete method, the server MUST respond with HTTP 405 Not Supported.
如果服务器不支持delete方法，则服务器必须使用HTTP 405 not SUPPORED进行响应。
If the registration access token used to make this request is not valid, the server MUST respond with an error as described in the OAuth Bearer Token Usage specification [RFC6750].
如果用于发出此请求的注册访问令牌无效，服务器必须按照OAuth承载令牌使用规范[RFC6750]中所述的错误进行响应。
If the client does not exist on this server, the server MUST respond with HTTP 401 Unauthorized and the registration access token used to make this request SHOULD be immediately revoked, if possible.
如果此服务器上不存在客户端，则服务器必须使用HTTP 401 Unauthorized进行响应，并且如果可能，应立即撤销用于发出此请求的注册访问令牌。
If the client is not allowed to delete itself, the server MUST respond with HTTP 403 Forbidden.
如果不允许客户端删除自身，则服务器必须以HTTP 403 Forbidden进行响应。
The following is a non-normative example response:
以下是非规范性示例响应：
HTTP/1.1 204 No Content Cache-Control: no-store Pragma: no-cache
HTTP/1.1 204无内容缓存控制：无存储杂注：无缓存
This specification extends the client information response defined in "OAuth 2.0 Client Dynamic Registration" [RFC7591], which states that the response contains the client identifier (as well as the client secret if the client is a confidential client). When used with this specification, the client information response also contains the fully qualified URL of the client configuration endpoint (Section 2) for this specific client that the client or developer may use to manage the client's registration configuration, as well as a registration access token that is to be used by the client or developer to perform subsequent operations at the client configuration endpoint.
本规范扩展了“OAuth 2.0客户端动态注册”[RFC7591]中定义的客户端信息响应，该响应声明该响应包含客户端标识符（以及客户端机密（如果客户端是机密客户端）。当与本规范一起使用时，客户机信息响应还包含该特定客户机的客户机配置端点的完全限定URL（第2节），客户机或开发人员可使用该URL管理客户机的注册配置，以及注册访问令牌，客户端或开发人员将使用该令牌在客户端配置端点执行后续操作。
registration_client_uri REQUIRED. String containing the fully qualified URL of the client configuration endpoint for this client.
需要注册\客户端\ uri。包含此客户端的客户端配置终结点的完全限定URL的字符串。
registration_access_token REQUIRED. String containing the access token to be used at the client configuration endpoint to perform subsequent operations upon the client registration.
需要注册\访问\令牌。包含访问令牌的字符串，该令牌将在客户端配置端点处使用，以便在客户端注册时执行后续操作。
Additionally, the authorization server MUST return all registered metadata about this client, including any fields provisioned by the authorization server itself. The authorization server MAY reject or replace any of the client's requested metadata values submitted during the registration or update requests and substitute them with suitable values.
此外，授权服务器必须返回有关此客户端的所有已注册元数据，包括授权服务器本身设置的任何字段。授权服务器可以拒绝或替换在注册或更新请求期间提交的任何客户端请求的元数据值，并用合适的值替换它们。
The response is an "application/json" document with all parameters as top-level members of a JSON object [RFC7159].
响应是一个“application/json”文档，所有参数都是json对象[RFC7159]的顶级成员。
The following is a non-normative example response:
以下是非规范性示例响应：
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
"registration_access_token": "reg-23410913-abewfq.123483",
"registration_client_uri":
"https://server.example.com/register/s6BhdRkqt3",
"client_id": "s6BhdRkqt3",
"client_secret": "cf136dc3c1fc93f31185e5885805d",
"client_id_issued_at": 2893256800,
"client_secret_expires_at": 2893276800,
"client_name": "My Example Client",
"client_name#ja-Jpan-JP":
"\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D",
"redirect_uris": [
"https://client.example.org/callback",
"https://client.example.org/callback2"],
"grant_types": ["authorization_code", "refresh_token"],
"token_endpoint_auth_method": "client_secret_basic",
"logo_uri": "https://client.example.org/logo.png",
"jwks_uri": "https://client.example.org/my_public_keys.jwks"
}
{
"registration_access_token": "reg-23410913-abewfq.123483",
"registration_client_uri":
"https://server.example.com/register/s6BhdRkqt3",
"client_id": "s6BhdRkqt3",
"client_secret": "cf136dc3c1fc93f31185e5885805d",
"client_id_issued_at": 2893256800,
"client_secret_expires_at": 2893276800,
"client_name": "My Example Client",
"client_name#ja-Jpan-JP":
"\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D",
"redirect_uris": [
"https://client.example.org/callback",
"https://client.example.org/callback2"],
"grant_types": ["authorization_code", "refresh_token"],
"token_endpoint_auth_method": "client_secret_basic",
"logo_uri": "https://client.example.org/logo.png",
"jwks_uri": "https://client.example.org/my_public_keys.jwks"
}
This specification registers the following client metadata names and descriptions in the "OAuth Dynamic Client Registration Metadata" registry established by [RFC7591]:
本规范在[RFC7591]建立的“OAuth动态客户端注册元数据”注册表中注册以下客户端元数据名称和描述：
o Client Metadata Name: "registration_access_token"
o 客户端元数据名称：“注册\访问\令牌”
o Client Metadata Description: OAuth 2.0 Bearer Token used to access the client configuration endpoint
o 客户端元数据描述：用于访问客户端配置端点的OAuth 2.0承载令牌
o Change Controller: IESG
o 更改控制器：IESG
o Specification Document(s): RFC 7592
o 规范文件：RFC 7592
o Client Metadata Name: "registration_client_uri"
o 客户端元数据名称：“注册\客户端\ uri”
o Client Metadata Description: Fully qualified URI of the client registration endpoint
o 客户端元数据描述：客户端注册终结点的完全限定URI
o Change Controller: IESG
o 更改控制器：IESG
o Specification Document(s): RFC 7592
o 规范文件：RFC 7592
While the client secret can expire, the registration access token SHOULD NOT expire while a client is still actively registered. If this token were to expire, a developer or client could be left in a situation where they have no means of retrieving, updating, or deleting the client's registration information. Were that the case, a new registration would be required, thereby generating a new client identifier. However, to limit the exposure surface of the registration access token, the registration access token MAY be rotated when the developer or client does a read or update operation on the client's client configuration endpoint. As the registration access tokens are relatively long-term credentials, and since the registration access token is a Bearer Token and acts as the sole authentication for use at the client configuration endpoint, it MUST be protected by the developer or client as described in the OAuth 2.0 Bearer Token Usage specification [RFC6750].
虽然客户端密码可能会过期，但注册访问令牌不应在客户端仍处于活动注册状态时过期。如果该令牌到期，开发人员或客户机可能会处于无法检索、更新或删除客户机注册信息的状态。如果是这种情况，则需要进行新的注册，从而生成新的客户端标识符。然而，为了限制注册访问令牌的公开面，当开发人员或客户端在客户端的客户端配置端点上执行读取或更新操作时，可以旋转注册访问令牌。由于注册访问令牌是相对长期的凭证，并且由于注册访问令牌是承载令牌，并且作为客户端配置端点使用的唯一身份验证，因此必须由开发人员或客户端按照OAuth 2.0承载令牌使用规范[RFC6750]中的描述对其进行保护。
Since requests to the client configuration endpoint result in the transmission of clear-text credentials (in the HTTP request and response), the authorization server MUST require the use of a transport-layer security mechanism when sending requests to the endpoint. The server MUST support TLS 1.2 [RFC5246] and MAY support additional transport-layer security 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 TLS and DTLS [BCP195].
由于对客户端配置端点的请求会导致明文凭证的传输（在HTTP请求和响应中），因此授权服务器在向端点发送请求时必须使用传输层安全机制。服务器必须支持TLS 1.2[RFC5246]，并且可以支持满足其安全要求的其他传输层安全机制。使用TLS时，客户机必须按照RFC 6125[RFC6125]执行TLS/SSL服务器证书检查。实施安全注意事项可在TLS和DTL安全使用建议[BCP195]中找到。
Since possession of the registration access token authorizes the holder to potentially read, modify, or delete a client's registration (including its credentials such as a client_secret), the registration access token MUST contain sufficient entropy to prevent a random guessing attack of this token, such as described in Section 5.2 of [RFC6750] and Section 5.1.4.2.2 of [RFC6819].
由于拥有注册访问令牌授权持有人潜在地读取、修改或删除客户的注册（包括其凭证，如客户_机密），注册访问令牌必须包含足够的熵，以防止该令牌的随机猜测攻击，如[RFC6750]第5.2节所述以及[RFC6819]第5.1.4.2.2节。
If a client is deprovisioned from a server, any outstanding registration access token for that client MUST be invalidated at the same time. Otherwise, this can lead to an inconsistent state wherein a client could make requests to the client configuration endpoint where the authentication would succeed but the action would fail because the client is no longer valid. The authorization server MUST treat all such requests as if the registration access token was invalid by returning an HTTP 401 Unauthorized error, as described.
如果从服务器取消提供客户端，则该客户端的任何未完成注册访问令牌必须同时失效。否则，这可能会导致不一致的状态，其中客户端可能向客户端配置端点发出请求，在该端点处，身份验证将成功，但操作将失败，因为客户端不再有效。授权服务器必须通过返回HTTP 401 Unauthorized错误，将所有此类请求视为注册访问令牌无效，如下所述。
This specification poses no additional privacy considerations beyond those described in the core "OAuth 2.0 Dynamic Client Registration Protocol" [RFC7591].
除了核心“OAuth 2.0动态客户机注册协议”[RFC7591]中所述的内容外，本规范没有提出其他隐私注意事项。
[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>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<http://www.rfc-editor.org/info/rfc5246>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, <http://www.rfc-editor.org/info/rfc6125>.
[RFC6125]Saint Andre，P.和J.Hodges，“在传输层安全（TLS）环境下使用X.509（PKIX）证书在互联网公钥基础设施内表示和验证基于域的应用程序服务身份”，RFC 6125，DOI 10.17487/RFC6125，2011年3月<http://www.rfc-editor.org/info/rfc6125>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <http://www.rfc-editor.org/info/rfc6749>.
[RFC6749]Hardt，D.，Ed.“OAuth 2.0授权框架”，RFC 6749，DOI 10.17487/RFC6749，2012年10月<http://www.rfc-editor.org/info/rfc6749>.
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, October 2012, <http://www.rfc-editor.org/info/rfc6750>.
[RFC6750]Jones，M.和D.Hardt，“OAuth 2.0授权框架：承载令牌使用”，RFC 6750，DOI 10.17487/RFC6750，2012年10月<http://www.rfc-editor.org/info/rfc6750>.
[RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 Threat Model and Security Considerations", RFC 6819, DOI 10.17487/RFC6819, January 2013, <http://www.rfc-editor.org/info/rfc6819>.
[RFC6819]Lodderstet，T.，Ed.，McGloin，M.，和P.Hunt，“OAuth 2.0威胁模型和安全考虑”，RFC 6819，DOI 10.17487/RFC6819，2013年1月<http://www.rfc-editor.org/info/rfc6819>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, <http://www.rfc-editor.org/info/rfc7159>.
[RFC7159]Bray，T.，Ed.“JavaScript对象表示法（JSON）数据交换格式”，RFC 7159，DOI 10.17487/RFC7159，2014年3月<http://www.rfc-editor.org/info/rfc7159>.
[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, <http://www.rfc-editor.org/info/rfc7231>.
[RFC7231]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：语义和内容”，RFC 7231，DOI 10.17487/RFC72312014年6月<http://www.rfc-editor.org/info/rfc7231>.
[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, <http://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月<http://www.rfc-editor.org/info/rfc7591>.
Throughout the course of the dynamic registration protocol, there are three different classes of credentials in play, each with different properties and targets.
在动态注册协议的整个过程中，有三种不同类别的凭证在起作用，每种凭证具有不同的属性和目标。
o The initial access token is optionally used by the client or developer at the registration endpoint. This is an OAuth 2.0 token that is used to authorize the initial client registration request. The content, structure, generation, and validation of this token are out of scope for this specification. The authorization server can use this token to verify that the presenter is allowed to dynamically register new clients. This token may be shared among multiple instances of a client to allow them to each register separately, thereby letting the authorization server use this token to tie multiple instances of registered clients (each with their own distinct client identifier) back to the party to whom the initial access token was issued, usually an application developer. This token is usually intended to be used only at the client registration endpoint.
o 初始访问令牌可由客户端或开发人员在注册端点处选择性地使用。这是用于授权初始客户端注册请求的OAuth 2.0令牌。此令牌的内容、结构、生成和验证超出了本规范的范围。授权服务器可以使用此令牌验证是否允许演示者动态注册新客户端。该令牌可在客户端的多个实例之间共享，以允许它们各自单独注册，从而允许授权服务器使用该令牌将已注册客户端的多个实例（每个实例具有其自己的不同客户端标识符）绑定回初始访问令牌被颁发给的一方，通常是应用程序开发人员。此令牌通常仅用于客户端注册端点。
o The registration access token is used by the client or developer at the client configuration endpoint and represents the holder's authorization to manage the registration of a client. This is an OAuth 2.0 Bearer Token that is issued from the client registration endpoint in response to a client registration request and is returned in a client information response. The registration access token is uniquely bound to the client identifier and is required to be presented with all calls to the client configuration endpoint. The registration access token should be protected as described in [RFC6750] and should not be shared between instances of a client. If a registration access token is shared between client instances, one instance could change or delete registration values for all other instances of the client. The registration access token can be rotated through the use of the client read or update method on the client configuration endpoint. The registration access token is intended to be used only at the client configuration endpoint.
o 注册访问令牌由客户机或开发人员在客户机配置端点处使用，表示持有人管理客户机注册的授权。这是一个OAuth 2.0承载令牌，由客户端注册端点发出，以响应客户端注册请求，并在客户端信息响应中返回。注册访问令牌唯一地绑定到客户端标识符，并且需要与对客户端配置端点的所有调用一起显示。注册访问令牌应按照[RFC6750]中所述进行保护，并且不应在客户端实例之间共享。如果在客户端实例之间共享注册访问令牌，则一个实例可以更改或删除客户端所有其他实例的注册值。可以通过在客户端配置端点上使用客户端读取或更新方法来旋转注册访问令牌。注册访问令牌仅用于客户端配置端点。
o The client credentials (such as "client_secret") are optional depending on the type of client and are used to retrieve OAuth tokens. Client credentials are most often bound to particular instances of a client and should not be shared between instances. Note that since not all types of clients have client credentials, they cannot be used to manage client registrations at the client configuration endpoint. The client credentials can be rotated through the use of the client read or update method on the client configuration endpoint. The client credentials are intended to be used only at the token endpoint.
o 客户端凭据（例如“client_secret”）是可选的，具体取决于客户端的类型，用于检索OAuth令牌。客户端凭据通常绑定到客户端的特定实例，不应在实例之间共享。请注意，由于并非所有类型的客户端都具有客户端凭据，因此它们不能用于管理客户端配置端点处的客户端注册。可以通过在客户端配置端点上使用客户端读取或更新方法来旋转客户端凭据。客户端凭据仅用于令牌端点。
The authorization server may be configured to issue new registration access tokens and/or client credentials (such as a "client_secret") throughout the lifetime of the client. This may help minimize the impact of exposed credentials. The authorization server conveys new registration access tokens and client credentials (if applicable) to the client in the client information response of either a read or update request to the client configuration endpoint. The client's current registration access token and client credentials (if applicable) MUST be included in the client information response.
授权服务器可被配置为在客户端的整个生存期内颁发新的注册访问令牌和/或客户端凭据（例如“客户端密钥”）。这可能有助于将公开凭据的影响降至最低。授权服务器在对客户端配置端点的读取或更新请求的客户端信息响应中向客户端传送新的注册访问令牌和客户端凭据（如果适用）。客户端信息响应中必须包括客户端的当前注册访问令牌和客户端凭据（如果适用）。
The registration access token SHOULD be rotated only in response to a read or update request to the client configuration endpoint. At this point, the new registration access token is returned to the client, the old registration access token MUST be discarded by the client, and it SHOULD be discarded by the server, if possible. If, instead, the registration access token were to expire or be invalidated outside of such requests, the client or developer might be locked out of managing the client's configuration.
注册访问令牌应仅在响应对客户端配置端点的读取或更新请求时旋转。此时，新的注册访问令牌返回给客户端，旧的注册访问令牌必须由客户端丢弃，如果可能的话，它应该由服务器丢弃。相反，如果注册访问令牌在此类请求之外过期或失效，则客户端或开发人员可能无法管理客户端的配置。
Note that the authorization server decides the frequency of the credential rotation and not the client. Methods by which the client can request credential rotation are outside the scope of this document.
请注意，授权服务器决定凭证轮换的频率，而不是客户端。客户端可以请求凭据轮换的方法不在本文档的范围内。
The authorization server MUST provide the client with the fully qualified URL in the "registration_client_uri" element of the Client Information Response, as specified in Section 3. The authorization server MUST NOT expect the client to construct or discover this URL on its own. The client MUST use the URL as given by the server and MUST NOT construct this URL from component pieces.
授权服务器必须在客户端信息响应的“registration\u client\u uri”元素中为客户端提供完全限定的URL，如第3节所述。授权服务器不能期望客户端自行构造或发现此URL。客户端必须使用服务器给定的URL，并且不能从组件块构造此URL。
Depending on deployment characteristics, the client configuration endpoint URL may take any number of forms. It is RECOMMENDED that this endpoint URL be formed through the use of a server-constructed URL string that combines the client registration endpoint's URL and the issued "client_id" for this client, with the latter as either a path parameter or a query parameter. For example, a client with the client identifier "s6BhdRkqt3" could be given a client configuration endpoint URL of "https://server.example.com/register/s6BhdRkqt3" (path parameter) or of "https://server.example.com/ register?client_id=s6BhdRkqt3" (query parameter). In both of these cases, the client simply uses the URL as given by the authorization server.
根据部署特征，客户端配置端点URL可以采用任意数量的形式。建议通过使用服务器构造的URL字符串来形成此端点URL，该字符串组合了客户端注册端点的URL和为此客户端颁发的“client_id”，后者作为路径参数或查询参数。例如，客户机标识符为“s6BhdRkqt3”的客户机可以被指定一个客户机配置端点URLhttps://server.example.com/register/s6BhdRkqt3“（路径参数）或”https://server.example.com/ 注册？客户机id=s6BhdRkqt3”（查询参数）。在这两种情况下，客户机只是使用授权服务器提供的URL。
These common patterns can help the server to more easily determine the client to which the request pertains, which MUST be matched against the client to which the registration access token was issued. If desired, the server MAY simply return the client registration endpoint URL as the client configuration endpoint URL and change behavior based on the authentication context provided by the registration access token.
这些通用模式可以帮助服务器更容易地确定请求所属的客户机，该客户机必须与发出注册访问令牌的客户机相匹配。如果需要，服务器可以简单地返回客户机注册端点URL作为客户机配置端点URL，并基于注册访问令牌提供的认证上下文更改行为。
Acknowledgments
致谢
The authors thank the OAuth Working Group, the User-Managed Access Working Group, and the OpenID Connect Working Group participants for their input to this document. In particular, the following individuals have been instrumental in their review and contribution to various draft versions of this document: Amanda Anganes, Derek Atkins, Tim Bray, Domenico Catalano, Donald Coffin, Vladimir Dzhuvinov, George Fletcher, Thomas Hardjono, Phil Hunt, William Kim, Torsten Lodderstedt, Eve Maler, Josh Mandel, Nov Matake, Tony Nadalin, Nat Sakimura, Christian Scholz, and Hannes Tschofenig.
作者感谢OAuth工作组、用户管理访问工作组和OpenID Connect工作组参与者对本文档的输入。特别是，以下个人对本文件的各种草案版本进行了审查和贡献：阿曼达·安加内斯、德里克·阿特金斯、蒂姆·布雷、多梅尼科·卡塔拉诺、唐纳德·科芬、弗拉基米尔·朱维诺夫、乔治·弗莱彻、托马斯·哈德乔诺、菲尔·亨特、威廉·金、托尔斯滕·洛德斯特德、伊夫·马勒、乔什·曼德尔、诺夫·马塔克、，Tony Nadalin、Nat Sakimura、Christian Scholz和Hannes Tschofenig。
Authors' Addresses
作者地址
Justin Richer (editor)
贾斯汀·里希（编辑）
Email: ietf@justin.richer.org
Email: ietf@justin.richer.org
Michael B. Jones Microsoft
迈克尔·琼斯微软公司
Email: mbj@microsoft.com
URI: http://self-issued.info/
Email: mbj@microsoft.com
URI: http://self-issued.info/
John Bradley Ping Identity
约翰·布拉德利·平身份
Email: ve7jtb@ve7jtb.com
Email: ve7jtb@ve7jtb.com
Maciej Machulak Newcastle University
纽卡斯尔大学
Email: maciej.machulak@gmail.com
Email: maciej.machulak@gmail.com