idnits 2.17.1 draft-ietf-oauth-dyn-reg-27.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 25, 2015) is 3313 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) == Outdated reference: A later version (-14) exists of draft-hardjono-oauth-umacore-10 == Outdated reference: A later version (-11) exists of draft-ietf-uta-tls-bcp-09 Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OAuth Working Group J. Richer, Ed. 3 Internet-Draft 4 Intended status: Standards Track M. Jones 5 Expires: September 26, 2015 Microsoft 6 J. Bradley 7 Ping Identity 8 M. Machulak 9 Newcastle University 10 P. Hunt 11 Oracle Corporation 12 March 25, 2015 14 OAuth 2.0 Dynamic Client Registration Protocol 15 draft-ietf-oauth-dyn-reg-27 17 Abstract 19 This specification defines mechanisms for dynamically registering 20 OAuth 2.0 clients with authorization servers. Registration requests 21 send a set of desired client metadata values to the authorization 22 server. The resulting registration responses return a client 23 identifier to use at the authorization server and the client metadata 24 values registered for the client. The client can then use this 25 registration information to communicate with the authorization server 26 using the OAuth 2.0 protocol. This specification also defines a set 27 of common client metadata fields and values for clients to use during 28 registration. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on September 26, 2015. 47 Copyright Notice 49 Copyright (c) 2015 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4 66 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 67 1.3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 5 68 2. Client Metadata . . . . . . . . . . . . . . . . . . . . . . . 6 69 2.1. Relationship between Grant Types and Response Types . . . 10 70 2.2. Human-Readable Client Metadata . . . . . . . . . . . . . 11 71 2.3. Software Statement . . . . . . . . . . . . . . . . . . . 12 72 3. Client Registration Endpoint . . . . . . . . . . . . . . . . 13 73 3.1. Client Registration Request . . . . . . . . . . . . . . . 14 74 3.1.1. Client Registration Request Using a Software 75 Statement . . . . . . . . . . . . . . . . . . . . . . 16 76 3.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 17 77 3.2.1. Client Information Response . . . . . . . . . . . . . 17 78 3.2.2. Client Registration Error Response . . . . . . . . . 19 79 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 80 4.1. OAuth Dynamic Client Registration Metadata Registry . . . 21 81 4.1.1. Registration Template . . . . . . . . . . . . . . . . 21 82 4.1.2. Initial Registry Contents . . . . . . . . . . . . . . 22 83 4.2. OAuth Token Endpoint Authentication Methods Registry . . 24 84 4.2.1. Registration Template . . . . . . . . . . . . . . . . 25 85 4.2.2. Initial Registry Contents . . . . . . . . . . . . . . 25 86 5. Security Considerations . . . . . . . . . . . . . . . . . . . 25 87 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 28 88 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 89 7.1. Normative References . . . . . . . . . . . . . . . . . . 29 90 7.2. Informative References . . . . . . . . . . . . . . . . . 31 91 Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . 31 92 A.1. Open versus Protected Dynamic Client Registration . . . . 31 93 A.1.1. Open Dynamic Client Registration . . . . . . . . . . 31 94 A.1.2. Protected Dynamic Client Registration . . . . . . . . 31 96 A.2. Registration Without or With Software Statements . . . . 32 97 A.2.1. Registration Without a Software Statement . . . . . . 32 98 A.2.2. Registration With a Software Statement . . . . . . . 32 99 A.3. Registration by the Client or Developer . . . . . . . . . 32 100 A.3.1. Registration by the Client . . . . . . . . . . . . . 32 101 A.3.2. Registration by the Developer . . . . . . . . . . . . 32 102 A.4. Client ID per Client Instance or per Client Software . . 32 103 A.4.1. Client ID per Client Software Instance . . . . . . . 32 104 A.4.2. Client ID Shared Among All Instances of Client 105 Software . . . . . . . . . . . . . . . . . . . . . . 33 106 A.5. Stateful or Stateless Registration . . . . . . . . . . . 33 107 A.5.1. Stateful Client Registration . . . . . . . . . . . . 33 108 A.5.2. Stateless Client Registration . . . . . . . . . . . . 33 109 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 33 110 Appendix C. Document History . . . . . . . . . . . . . . . . . . 34 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 113 1. Introduction 115 In order for an OAuth 2.0 [RFC6749] client to utilize an OAuth 2.0 116 authorization server, the client needs specific information to 117 interact with the server, including an OAuth 2.0 client identifier to 118 use at that server. This specification describes how an OAuth 2.0 119 client can be dynamically registered with an authorization server to 120 obtain this information. 122 As part of the registration process, this specification also defines 123 a mechanism for the client to present the authorization server with a 124 set of metadata, such as a set of valid redirection URIs. This 125 metadata can either be communicated in a self-asserted fashion or as 126 a set of metadata called a software statement, which is digitally 127 signed or MACed; in the case of a software statement, the issuer is 128 vouching for the validity of the data about the client. 130 Traditionally, registration of a client with an authorization server 131 is performed manually. The mechanisms defined in this specification 132 can be used either for a client to dynamically register itself with 133 authorization servers or for a client developer to programmatically 134 register the client with authorization servers. Multiple 135 applications using OAuth 2.0 have previously developed mechanisms for 136 accomplishing such registrations. This specification generalizes the 137 registration mechanisms defined by the OpenID Connect Dynamic Client 138 Registration 1.0 [OpenID.Registration] specification and used by the 139 User Managed Access (UMA) Profile of OAuth 2.0 140 [I-D.hardjono-oauth-umacore] specification in a way that is 141 compatible with both, while being applicable to a wider set of OAuth 142 2.0 use cases. 144 1.1. Notational Conventions 146 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 147 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this 148 document are to be interpreted as described in [RFC2119]. 150 Unless otherwise noted, all the protocol parameter names and values 151 are case sensitive. 153 1.2. Terminology 155 This specification uses the terms "access token", "authorization 156 code", "authorization endpoint", "authorization grant", 157 "authorization server", "client", "client identifier", "client 158 secret", "grant type", "protected resource", "redirection URI", 159 "refresh token", "resource owner", "resource server", "response 160 type", and "token endpoint" defined by OAuth 2.0 [RFC6749] and uses 161 the term "Claim" defined by JSON Web Token (JWT) [JWT]. 163 This specification defines the following terms: 165 Client Software 166 Software implementing an OAuth 2.0 client. 167 Client Instance 168 A deployed instance of a piece of client software. 169 Client Developer 170 The person or organization that builds a client software package 171 and prepares it for distribution. At the time of building the 172 client, the developer is often not aware of who the deploying 173 service provider organizations will be. Client developers will 174 need to use dynamic registration when they are unable to predict 175 aspects of the software, such as the deployment URLs, at compile 176 time. For instance, this can occur when the software API 177 publisher and the deploying organization are not the same. 178 Client Registration Endpoint 179 OAuth 2.0 endpoint through which a client can be registered at an 180 authorization server. The means by which the URL for this 181 endpoint is obtained are out of scope for this specification. 182 Initial Access Token 183 OAuth 2.0 access token optionally issued by an authorization 184 server to a developer or client and used to authorize calls to the 185 client registration endpoint. The type and format of this token 186 are likely service-specific and are out of scope for this 187 specification. The means by which the authorization server issues 188 this token as well as the means by which the registration endpoint 189 validates this token are out of scope for this specification. Use 190 of an initial access token is required when the authorization 191 server limits the parties that can register a client. 193 Deployment Organization 194 An administrative security domain under which a software API 195 (service) is deployed and protected by an OAuth 2.0 framework. In 196 some OAuth scenarios, the deployment organization and the software 197 API publisher are the same. In these cases, the deploying 198 organization will often have a close relationship with client 199 software developers. In many other cases, the definer of the 200 service may be an independent third-party publisher or a standards 201 organization. When working to a published specification for an 202 API, the client software developer is unable to have a prior 203 relationship with the potentially many deployment organizations 204 deploying the software API (service). 205 Software API Deployment 206 A deployed instance of a software API that is protected by OAuth 207 2.0 (a protected resource) in a particular deployment organization 208 domain. For any particular software API, there may be one or more 209 deployments. A software API deployment typically has an 210 associated OAuth 2.0 authorization server as well as a client 211 registration endpoint. The means by which endpoints are obtained 212 are out of scope for this specification. 213 Software API Publisher 214 The organization that defines a particular web accessible API that 215 may be deployed in one or more deployment environments. A 216 publisher may be any standards body, commercial, public, private, 217 or open source organization that is responsible for publishing and 218 distributing software and API specifications that may be protected 219 via OAuth 2.0. In some cases, a software API publisher and a 220 client developer may be the same organization. At the time of 221 publication of a web accessible API, the software publisher often 222 does not have a prior relationship with the deploying 223 organizations. 224 Software Statement 225 Digitally signed or MACed JSON Web Token (JWT) [JWT] that asserts 226 metadata values about the client software. In some cases, a 227 software statement will be issued directly by the client 228 developer. In other cases, a software statement will be issued by 229 a third party organization for use by the client developer. In 230 both cases, the trust relationship the authorization server has 231 with the issuer of the software statement is intended to be used 232 as an input to the evaluation of whether the registration request 233 is accepted. A software statement can be presented to an 234 authorization server as part of a client registration request. 236 1.3. Protocol Flow 237 +--------(A)- Initial Access Token (OPTIONAL) 238 | 239 | +----(B)- Software Statement (OPTIONAL) 240 | | 241 v v 242 +-----------+ +---------------+ 243 | |--(C)- Client Registration Request -->| Client | 244 | Client or | | Registration | 245 | Developer |<-(D)- Client Information Response ---| Endpoint | 246 | | or Client Error Response +---------------+ 247 +-----------+ 249 Figure 1: Abstract Dynamic Client Registration Flow 251 The abstract OAuth 2.0 client dynamic registration flow illustrated 252 in Figure 1 describes the interaction between the client or developer 253 and the endpoint defined in this specification. This figure does not 254 demonstrate error conditions. This flow includes the following 255 steps: 257 (A) Optionally, the client or developer is issued an initial access 258 token giving access to the client registration endpoint. The 259 method by which the initial access token is issued to the client 260 or developer is out of scope for this specification. 261 (B) Optionally, the client or developer is issued a software 262 statement for use with the client registration endpoint. The 263 method by which the software statement is issued to the client or 264 developer is out of scope for this specification. 265 (C) The client or developer calls the client registration endpoint 266 with the client's desired registration metadata, optionally 267 including the initial access token from (A) if one is required by 268 the authorization server. 269 (D) The authorization server registers the client and returns: 271 * the client's registered metadata, 272 * a client identifier that is unique at the server, and 273 * a set of client credentials such as a client secret, if 274 applicable for this client. 276 Examples of different configurations and usages are included in 277 Appendix A. 279 2. Client Metadata 281 Registered clients have a set of metadata values associated with 282 their client identifier at an authorization server, such as the list 283 of valid redirection URIs or a display name. 285 These client metadata values are used in two ways: 287 o as input values to registration requests, and 288 o as output values in registration responses. 290 The following client metadata fields are defined by this 291 specification. The implementation and use of all client metadata 292 fields is OPTIONAL, unless stated otherwise. 294 redirect_uris 295 Array of redirection URI values for use in redirect-based flows 296 such as the authorization code and implicit flows. As required by 297 Section 2 of OAuth 2.0 [RFC6749], clients using flows with 298 redirection MUST register their redirection URI values. 299 Authorization servers that support dynamic registration for 300 redirect-based flows MUST implement support for this metadata 301 value. 302 token_endpoint_auth_method 303 The requested authentication method for the token endpoint. 304 Values defined by this specification are: 306 * "none": The client is a public client as defined in OAuth 2.0 307 and does not have a client secret. 308 * "client_secret_post": The client uses the HTTP POST parameters 309 defined in OAuth 2.0 section 2.3.1. 310 * "client_secret_basic": the client uses HTTP Basic defined in 311 OAuth 2.0 section 2.3.1 313 Additional values can be defined via the IANA OAuth Token Endpoint 314 Authentication Methods Registry established in Section 4.2. 315 Absolute URIs can also be used as values for this parameter 316 without being registered. If unspecified or omitted, the default 317 is "client_secret_basic", denoting HTTP Basic Authentication 318 Scheme as specified in Section 2.3.1 of OAuth 2.0. 319 grant_types 320 Array of OAuth 2.0 grant types that the client may use. These 321 grant types are defined as follows: 323 * "authorization_code": The Authorization Code Grant described in 324 OAuth 2.0 Section 4.1 325 * "implicit": The Implicit Grant described in OAuth 2.0 326 Section 4.2 327 * "password": The Resource Owner Password Credentials Grant 328 described in OAuth 2.0 Section 4.3 329 * "client_credentials": The Client Credentials Grant described in 330 OAuth 2.0 Section 4.4 331 * "refresh_token": The Refresh Token Grant described in OAuth 2.0 332 Section 6. 334 * "urn:ietf:params:oauth:grant-type:jwt-bearer": The JWT Bearer 335 Grant defined in OAuth JWT Bearer Token Profiles [OAuth.JWT]. 336 * "urn:ietf:params:oauth:grant-type:saml2-bearer": The SAML 2 337 Bearer Grant defined in OAuth SAML 2 Bearer Token Profiles 338 [OAuth.SAML2]. 340 If the token endpoint is used in the grant type, the value of this 341 parameter MUST be the same as the value of the "grant_type" 342 parameter passed to the token endpoint defined in the grant type 343 definition. Authorization servers MAY allow for other values as 344 defined in the grant type extension process described in OAuth 2.0 345 Section 2.5. If omitted, the default behavior is that the client 346 will use only the "authorization_code" Grant Type. 347 response_types 348 Array of the OAuth 2.0 response types that the client can use. 349 These response types are defined as follows: 351 * "code": The authorization code response described in OAuth 2.0 352 Section 4.1. 353 * "token": The implicit response described in OAuth 2.0 354 Section 4.2. 356 If the authorization endpoint is used by the grant type, the value 357 of this parameter MUST be the same as the value of the 358 "response_type" parameter passed to the authorization endpoint 359 defined in the grant type definition. Authorization servers MAY 360 allow for other values as defined in the grant type extension 361 process is described in OAuth 2.0 Section 2.5. If omitted, the 362 default is that the client will use only the "code" response type. 363 client_name 364 Human-readable name of the client to be presented to the end-user 365 during authorization. If omitted, the authorization server MAY 366 display the raw "client_id" value to the end-user instead. It is 367 RECOMMENDED that clients always send this field. The value of 368 this field MAY be internationalized, as described in Section 2.2. 369 client_uri 370 URL of a web page providing information about the client. If 371 present, the server SHOULD display this URL to the end-user in a 372 clickable fashion. It is RECOMMENDED that clients always send 373 this field. The value of this field MUST point to a valid web 374 page. The value of this field MAY be internationalized, as 375 described in Section 2.2. 376 logo_uri 377 URL that references a logo for the client. If present, the server 378 SHOULD display this image to the end-user during approval. The 379 value of this field MUST point to a valid image file. The value 380 of this field MAY be internationalized, as described in 381 Section 2.2. 383 scope 384 Space separated list of scope values (as described in Section 3.3 385 of OAuth 2.0 [RFC6749]) that the client can use when requesting 386 access tokens. The semantics of values in this list is service 387 specific. If omitted, an authorization server MAY register a 388 client with a default set of scopes. 389 contacts 390 Array of strings representing ways to contact people responsible 391 for this client, typically email addresses. The authorization 392 server MAY make these contact addresses available to end-users for 393 support requests for the client. See Section 6 for information on 394 Privacy Considerations. 395 tos_uri 396 URL that points to a human-readable terms of service document for 397 the client that describes a contractual relationship between the 398 end-user and the client that the end-user accepts when authorizing 399 the client. The authorization server SHOULD display this URL to 400 the end-user if it is provided. The value of this field MUST 401 point to a valid web page. The value of this field MAY be 402 internationalized, as described in Section 2.2. 403 policy_uri 404 URL that points to a human-readable privacy policy document that 405 describes how the deployment organization collects, uses, retains, 406 and discloses personal data. The authorization server SHOULD 407 display this URL to the end-user if it is provided. The value of 408 this field MUST point to a valid web page. The value of this 409 field MAY be internationalized, as described in Section 2.2. 410 jwks_uri 411 URL referencing the client's JSON Web Key Set [JWK] document, 412 which contains the client's public keys. The value of this field 413 MUST point to a valid JWK Set document. These keys can be used by 414 higher level protocols that use signing or encryption. For 415 instance, these keys might be used by some applications for 416 validating signed requests made to the token endpoint when using 417 JWTs for client authentication [OAuth.JWT]. Use of this parameter 418 is preferred over the "jwks" parameter, as it allows for easier 419 key rotation. The "jwks_uri" and "jwks" parameters MUST NOT both 420 be present in the same request or response. 421 jwks 422 Client's JSON Web Key Set [JWK] document value, which contains the 423 client's public keys. The value of this field MUST be a JSON 424 object containing a valid JWK Set. These keys can be used by 425 higher level protocols that use signing or encryption. This 426 parameter is intended to be used by clients that cannot use the 427 "jwks_uri" parameter, such as native clients that cannot host 428 public URLs. The "jwks_uri" and "jwks" parameters MUST NOT both 429 be present in the same request or response. 430 software_id 431 A unique identifier (e.g. a UUID) assigned by the client developer 432 or software publisher used by registration endpoints to identify 433 the client software to be dynamically registered. Unlike 434 "client_id", which is issued by the authorization server and 435 SHOULD vary between instances, the "software_id" SHOULD remain the 436 same for all instances of the client software. The "software_id" 437 SHOULD remain the same across multiple updates or versions of the 438 same piece of software. The value of this field is not intended 439 to be human-readable and is usually opaque to the client and 440 authorization server. 441 software_version 442 A version identifier for the client software identified by 443 "software_id". The value of the "software_version" SHOULD change 444 on any update to the client software identified by the same 445 "software_id". The value of this field is a string that is 446 intended to be compared using string equality matching. The value 447 of this field is not intended to be human readable and is usually 448 opaque to the client and authorization server. 450 Extensions and profiles of this specification MAY expand this list 451 with metadata names and descriptions registered in accordance with 452 the IANA Considerations in Section 4 of this document. The 453 authorization server MUST ignore any client metadata sent by the 454 client that it does not understand (for instance, by silently 455 removing unknown metadata from the client's registration record 456 during processing). 458 Client metadata values can either be communicated directly in the 459 body of a registration request, as described in Section 3.1, or 460 included as claims in a software statement, as described in 461 Section 2.3, or a mixture of both. If the same client metadata name 462 is present in both locations and the software statement is trusted by 463 the authorization server, the value of a claim in the software 464 statement MUST take precedence. 466 2.1. Relationship between Grant Types and Response Types 468 The "grant_types" and "response_types" values described above are 469 partially orthogonal, as they refer to arguments passed to different 470 endpoints in the OAuth protocol. However, they are related in that 471 the "grant_types" available to a client influence the 472 "response_types" that the client is allowed to use, and vice versa. 473 For instance, a "grant_types" value that includes 474 "authorization_code" implies a "response_types" value that includes 475 "code", as both values are defined as part of the OAuth 2.0 476 authorization code grant. As such, a server supporting these fields 477 SHOULD take steps to ensure that a client cannot register itself into 478 an inconsistent state, for example by returning an 479 "invalid_client_metadata" error response to an inconsistent 480 registration request. 482 The correlation between the two fields is listed in the table below. 484 +-----------------------------------------------+-------------------+ 485 | grant_types value includes: | response_types | 486 | | value includes: | 487 +-----------------------------------------------+-------------------+ 488 | authorization_code | code | 489 | implicit | token | 490 | password | (none) | 491 | client_credentials | (none) | 492 | refresh_token | (none) | 493 | urn:ietf:params:oauth:grant-type:jwt-bearer | (none) | 494 | urn:ietf:params:oauth:grant-type:saml2-bearer | (none) | 495 +-----------------------------------------------+-------------------+ 497 Extensions and profiles of this document that introduce new values to 498 either the "grant_types" or "response_types" parameter MUST document 499 all correspondences between these two parameter types. 501 2.2. Human-Readable Client Metadata 503 Human-readable client metadata values and client metadata values that 504 reference human-readable values MAY be represented in multiple 505 languages and scripts. For example, the values of fields such as 506 "client_name", "tos_uri", "policy_uri", "logo_uri", and "client_uri" 507 might have multiple locale-specific values in some client 508 registrations to facilitate use in different locations. 510 To specify the languages and scripts, BCP47 [RFC5646] language tags 511 are added to client metadata member names, delimited by a # 512 character. Since JSON [RFC7159] member names are case sensitive, it 513 is RECOMMENDED that language tag values used in Claim Names be 514 spelled using the character case with which they are registered in 515 the IANA Language Subtag Registry [IANA.Language]. In particular, 516 normally language names are spelled with lowercase characters, region 517 names are spelled with uppercase characters, and languages are 518 spelled with mixed case characters. However, since BCP47 language 519 tag values are case insensitive, implementations SHOULD interpret the 520 language tag values supplied in a case insensitive manner. Per the 521 recommendations in BCP47, language tag values used in metadata member 522 names should only be as specific as necessary. For instance, using 523 "fr" might be sufficient in many contexts, rather than "fr-CA" or 524 "fr-FR". 526 For example, a client could represent its name in English as 527 ""client_name#en": "My Client"" and its name in Japanese as 528 ""client_name#ja-Jpan-JP": 529 "\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D"" within the same 530 registration request. The authorization server MAY display any or 531 all of these names to the resource owner during the authorization 532 step, choosing which name to display based on system configuration, 533 user preferences or other factors. 535 If any human-readable field is sent without a language tag, parties 536 using it MUST NOT make any assumptions about the language, character 537 set, or script of the string value, and the string value MUST be used 538 as-is wherever it is presented in a user interface. To facilitate 539 interoperability, it is RECOMMENDED that clients and servers use a 540 human-readable field without any language tags in addition to any 541 language-specific fields, and it is RECOMMENDED that any human- 542 readable fields sent without language tags contain values suitable 543 for display on a wide variety of systems. 545 Implementer's Note: Many JSON libraries make it possible to reference 546 members of a JSON object as members of an object construct in the 547 native programming environment of the library. However, while the 548 "#" character is a valid character inside of a JSON object's member 549 names, it is not a valid character for use in an object member name 550 in many programming environments. Therefore, implementations will 551 need to use alternative access forms for these claims. For instance, 552 in JavaScript, if one parses the JSON as follows, "var j = 553 JSON.parse(json);", then as a workaround the member "client_name#en- 554 us" can be accessed using the JavaScript syntax "j["client_name#en- 555 us"]". 557 2.3. Software Statement 559 A software statement is a JSON Web Token (JWT) [JWT] that asserts 560 metadata values about the client software as a bundle. A set of 561 claims that can be used in a software statement are defined in 562 Section 2. When presented to the authorization server as part of a 563 client registration request, the software statement MUST be digitally 564 signed or MACed using JWS [JWS] and MUST contain an "iss" (issuer) 565 claim denoting the party attesting to the claims in the software 566 statement. It is RECOMMENDED that software statements be digitally 567 signed using the "RS256" signature algorithm, although particular 568 applications MAY specify the use of different algorithms. It is 569 RECOMMENDED that software statements contain the "software_id" claim 570 to allow authorization servers to correlate different instances of 571 software using the same software statement. 573 For example, a software statement could contain the following claims: 575 { 576 "software_id": "4NRB1-0XZABZI9E6-5SM3R", 577 "client_name": "Example Statement-based Client", 578 "client_uri": "https://client.example.net/" 579 } 581 The following non-normative example JWT includes these claims and has 582 been asymmetrically signed using RS256: 584 Line breaks are for display purposes only 586 eyJhbGciOiJSUzI1NiJ9. 587 eyJzb2Z0d2FyZV9pZCI6IjROUkIxLTBYWkFCWkk5RTYtNVNNM1IiLCJjbGll 588 bnRfbmFtZSI6IkV4YW1wbGUgU3RhdGVtZW50LWJhc2VkIENsaWVudCIsImNs 589 aWVudF91cmkiOiJodHRwczovL2NsaWVudC5leGFtcGxlLm5ldC8ifQ. 590 GHfL4QNIrQwL18BSRdE595T9jbzqa06R9BT8w409x9oIcKaZo_mt15riEXHa 591 zdISUvDIZhtiyNrSHQ8K4TvqWxH6uJgcmoodZdPwmWRIEYbQDLqPNxREtYn0 592 5X3AR7ia4FRjQ2ojZjk5fJqJdQ-JcfxyhK-P8BAWBd6I2LLA77IG32xtbhxY 593 fHX7VhuU5ProJO8uvu3Ayv4XRhLZJY4yKfmyjiiKiPNe-Ia4SMy_d_QSWxsk 594 U5XIQl5Sa2YRPMbDRXttm2TfnZM1xx70DoYi8g6czz-CPGRi4SW_S2RKHIJf 595 IjoI3zTJ0Y2oe0_EJAiXbL6OyF9S5tKxDXV8JIndSA 597 The means by which a client or developer obtains a software statement 598 are outside the scope of this specification. Some common methods 599 could include a client developer generating a client-specific JWT by 600 registering with a software API publisher to obtain a software 601 statement for a class of clients. The software statement is 602 typically distributed with all instances of a client application. 604 The criteria by which authorization servers determine whether to 605 trust and utilize the information in a software statement are beyond 606 the scope of this specification. 608 In some cases, authorization servers MAY choose to accept a software 609 statement value directly as a client identifier in an authorization 610 request, without a prior dynamic client registration having been 611 performed. The circumstances under which an authorization server 612 would do so, and the specific software statement characteristics 613 required in this case, are beyond the scope of this specification. 615 3. Client Registration Endpoint 617 The client registration endpoint is an OAuth 2.0 endpoint defined in 618 this document that is designed to allow a client to be registered 619 with the authorization server. The client registration endpoint MUST 620 accept HTTP POST messages with request parameters encoded in the 621 entity body using the "application/json" format. The client 622 registration endpoint MUST be protected by a transport-layer security 623 mechanism, as described in Section 5. 625 The client registration endpoint MAY be an OAuth 2.0 protected 626 resource and accept an initial access token in the form of an OAuth 627 2.0 [RFC6749] access token to limit registration to only previously 628 authorized parties. The method by which the initial access token is 629 obtained by the client or developer is generally out-of-band and is 630 out of scope for this specification. The method by which the initial 631 access token is verified and validated by the client registration 632 endpoint is out of scope for this specification. 634 To support open registration and facilitate wider interoperability, 635 the client registration endpoint SHOULD allow registration requests 636 with no authorization (which is to say, with no initial access token 637 in the request). These requests MAY be rate-limited or otherwise 638 limited to prevent a denial-of-service attack on the client 639 registration endpoint. 641 3.1. Client Registration Request 643 This operation registers a client with the authorization server. The 644 authorization server assigns this client a unique client identifier, 645 optionally assigns a client secret, and associates the metadata 646 provided in the request with the issued client identifier. The 647 request includes any client metadata parameters being specified for 648 the client during the registration. The authorization server MAY 649 provision default values for any items omitted in the client 650 metadata. 652 To register, the client or developer sends an HTTP POST to the client 653 registration endpoint with a content type of "application/json". The 654 HTTP Entity Payload is a JSON [RFC7159] document consisting of a JSON 655 object and all requested client metadata values as top-level members 656 of that JSON object. 658 For example, if the server supports open registration (with no 659 initial access token), the client could send the following 660 registration request to the client registration endpoint: 662 The following is a non-normative example request not using an initial 663 access token (with line wraps within values for display purposes 664 only): 666 POST /register HTTP/1.1 667 Content-Type: application/json 668 Accept: application/json 669 Host: server.example.com 671 { 672 "redirect_uris":[ 673 "https://client.example.org/callback", 674 "https://client.example.org/callback2"], 675 "client_name":"My Example Client", 676 "client_name#ja-Jpan-JP": 677 "\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D", 678 "token_endpoint_auth_method":"client_secret_basic", 679 "logo_uri":"https://client.example.org/logo.png", 680 "jwks_uri":"https://client.example.org/my_public_keys.jwks", 681 "example_extension_parameter": "example_value" 682 } 684 Alternatively, if the server supports authorized registration, the 685 developer or the client will be provisioned with an initial access 686 token. (The method by which the initial access token is obtained is 687 out of scope for this specification.) The developer or client sends 688 the following authorized registration request to the client 689 registration endpoint. Note that the initial access token sent in 690 this example as an OAuth 2.0 Bearer Token [RFC6750], but any OAuth 691 2.0 token type could be used by an authorization server. 693 The following is a non-normative example request using an initial 694 access token and registering a JWK set by value (with line wraps 695 within values for display purposes only): 697 POST /register HTTP/1.1 698 Content-Type: application/json 699 Accept: application/json 700 Authorization: Bearer ey23f2.adfj230.af32-developer321 701 Host: server.example.com 703 { 704 "redirect_uris":["https://client.example.org/callback", 705 "https://client.example.org/callback2"], 706 "client_name":"My Example Client", 707 "client_name#ja-Jpan-JP": 708 "\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D", 709 "token_endpoint_auth_method":"client_secret_basic", 710 "policy_uri":"https://client.example.org/policy.html", 711 "jwks":{"keys":[{ 712 "e": "AQAB", 713 "n": "nj3YJwsLUFl9BmpAbkOswCNVx17Eh9wMO-_AReZwBqfaWFcfG 714 HrZXsIV2VMCNVNU8Tpb4obUaSXcRcQ-VMsfQPJm9IzgtRdAY8NN8Xb7PEcYyk 715 lBjvTtuPbpzIaqyiUepzUXNDFuAOOkrIol3WmflPUUgMKULBN0EUd1fpOD70p 716 RM0rlp_gg_WNUKoW1V-3keYUJoXH9NztEDm_D2MQXj9eGOJJ8yPgGL8PAZMLe 717 2R7jb9TxOCPDED7tY_TU4nFPlxptw59A42mldEmViXsKQt60s1SLboazxFKve 718 qXC_jpLUt22OC6GUG63p-REw-ZOr3r845z50wMuzifQrMI9bQ", 719 "kty": "RSA" 720 }]}, 721 "example_extension_parameter": "example_value" 722 } 724 3.1.1. Client Registration Request Using a Software Statement 726 In addition to JSON elements, client metadata values MAY also be 727 provided in a software statement, as described in Section 2.3. The 728 authorization server MAY ignore the software statement if it does not 729 support this feature. If the server supports software statements, 730 client metadata values conveyed in the software statement MUST take 731 precedence over those conveyed using plain JSON elements. 733 Software statements are included in the requesting JSON object using 734 this OPTIONAL member: 736 software_statement 737 A software statement containing client metadata values about the 738 client software as claims. 740 In the following example, some registration parameters are conveyed 741 as claims in a software statement from the example in Section 2.3, 742 while some values specific to the client instance are conveyed as 743 regular parameters (with line wraps within values for display 744 purposes only): 746 POST /register HTTP/1.1 747 Content-Type: application/json 748 Accept: application/json 749 Host: server.example.com 751 { 752 "redirect_uris":[ 753 "https://client.example.org/callback", 754 "https://client.example.org/callback2" 755 ], 756 "software_statement":"eyJhbGciOiJSUzI1NiJ9. 757 eyJzb2Z0d2FyZV9pZCI6IjROUkIxLTBYWkFCWkk5RTYtNVNNM1IiLCJjbGll 758 bnRfbmFtZSI6IkV4YW1wbGUgU3RhdGVtZW50LWJhc2VkIENsaWVudCIsImNs 759 aWVudF91cmkiOiJodHRwczovL2NsaWVudC5leGFtcGxlLm5ldC8ifQ. 760 GHfL4QNIrQwL18BSRdE595T9jbzqa06R9BT8w409x9oIcKaZo_mt15riEXHa 761 zdISUvDIZhtiyNrSHQ8K4TvqWxH6uJgcmoodZdPwmWRIEYbQDLqPNxREtYn0 762 5X3AR7ia4FRjQ2ojZjk5fJqJdQ-JcfxyhK-P8BAWBd6I2LLA77IG32xtbhxY 763 fHX7VhuU5ProJO8uvu3Ayv4XRhLZJY4yKfmyjiiKiPNe-Ia4SMy_d_QSWxsk 764 U5XIQl5Sa2YRPMbDRXttm2TfnZM1xx70DoYi8g6czz-CPGRi4SW_S2RKHIJf 765 IjoI3zTJ0Y2oe0_EJAiXbL6OyF9S5tKxDXV8JIndSA", 766 "scope":"read write", 767 "example_extension_parameter":"example_value" 768 } 770 3.2. Responses 772 Upon a successful registration request, the authorization server 773 returns a client identifier for the client. The server responds with 774 an HTTP 201 Created code and a body of type "application/json" with 775 content as described in Section 3.2.1. 777 Upon an unsuccessful registration request, the authorization server 778 responds with an error, as described in Section 3.2.2. 780 3.2.1. Client Information Response 782 The response contains the client identifier as well as the client 783 secret, if the client is a confidential client. The response MAY 784 contain additional fields as specified by extensions to this 785 specification. 787 client_id 788 REQUIRED. OAuth 2.0 client identifier. It SHOULD NOT be 789 currently valid for any other registered client, though an 790 authorization server MAY issue the same client identifier to 791 multiple instances of a registered client at its discretion. 792 client_secret 793 OPTIONAL. OAuth 2.0 client secret. If issued, this MUST be 794 unique for each "client_id" and SHOULD be unique for multiple 795 instances of a client using the same "client_id". This value is 796 used by confidential clients to authenticate to the token endpoint 797 as described in OAuth 2.0 [RFC6749] Section 2.3.1. 798 client_id_issued_at 799 OPTIONAL. Time at which the client identifier was issued. The 800 time is represented as the number of seconds from 801 1970-01-01T0:0:0Z as measured in UTC until the date/time of 802 issuance. 803 client_secret_expires_at 804 REQUIRED if "client_secret" is issued. Time at which the client 805 secret will expire or 0 if it will not expire. The time is 806 represented as the number of seconds from 1970-01-01T0:0:0Z as 807 measured in UTC until the date/time of expiration. 809 Additionally, the authorization server MUST return all registered 810 metadata about this client, including any fields provisioned by the 811 authorization server itself. The authorization server MAY reject or 812 replace any of the client's requested metadata values submitted 813 during the registration and substitute them with suitable values. 815 The response is an "application/json" document with all parameters as 816 top-level members of a JSON object [RFC7159]. 818 If a software statement was used as part of the registration, its 819 value MUST be returned unmodified in the response along with other 820 metadata using the "software_statement" member name. Client metadata 821 elements used from the software statement MUST also be returned 822 directly as top-level client metadata values in the registration 823 response (possibly with different values, since the values requested 824 and the values used may differ). 826 Following is a non-normative example response: 828 HTTP/1.1 201 Created 829 Content-Type: application/json 830 Cache-Control: no-store 831 Pragma: no-cache 833 { 834 "client_id":"s6BhdRkqt3", 835 "client_secret": "cf136dc3c1fc93f31185e5885805d", 836 "client_id_issued_at":2893256800, 837 "client_secret_expires_at":2893276800, 838 "redirect_uris":[ 839 "https://client.example.org/callback", 840 "https://client.example.org/callback2"], 841 "grant_types": ["authorization_code", "refresh_token"], 842 "client_name":"My Example Client", 843 "client_name#ja-Jpan-JP": 844 "\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D", 845 "token_endpoint_auth_method":"client_secret_basic", 846 "logo_uri":"https://client.example.org/logo.png", 847 "jwks_uri":"https://client.example.org/my_public_keys.jwks", 848 "example_extension_parameter": "example_value" 849 } 851 3.2.2. Client Registration Error Response 853 When an OAuth 2.0 error condition occurs, such as the client 854 presenting an invalid initial access token, the authorization server 855 returns an error response appropriate to the OAuth 2.0 token type. 857 When a registration error condition occurs, the authorization server 858 returns an HTTP 400 status code (unless otherwise specified) with 859 content type "application/json" consisting of a JSON object [RFC7159] 860 describing the error in the response body. 862 Two members are defined for inclusion in the JSON object: 864 error 865 REQUIRED. Single ASCII error code string. 866 error_description 867 OPTIONAL. Human-readable ASCII text description of the error used 868 for debugging. 870 Other members MAY also be included, and if not understood, MUST be 871 ignored. 873 This specification defines the following error codes: 875 invalid_redirect_uri 876 The value of one or more redirection URIs is invalid. 877 invalid_client_metadata 878 The value of one of the client metadata fields is invalid and the 879 server has rejected this request. Note that an authorization 880 server MAY choose to substitute a valid value for any requested 881 parameter of a client's metadata. 882 invalid_software_statement 883 The software statement presented is invalid. 884 unapproved_software_statement 885 The software statement presented is not approved for use by this 886 authorization server. 888 Following is a non-normative example of an error response resulting 889 from a redirection URI that has been blacklisted by the authorization 890 server (with line wraps within values for display purposes only): 892 HTTP/1.1 400 Bad Request 893 Content-Type: application/json 894 Cache-Control: no-store 895 Pragma: no-cache 897 { 898 "error": "invalid_redirect_uri", 899 "error_description": "The redirection URI 900 http://sketchy.example.com is not allowed by this server." 901 } 903 Following is a non-normative example of an error response resulting 904 from an inconsistent combination of "response_types" and 905 "grant_types" values (with line wraps within values for display 906 purposes only): 908 HTTP/1.1 400 Bad Request 909 Content-Type: application/json 910 Cache-Control: no-store 911 Pragma: no-cache 913 { 914 "error": "invalid_client_metadata", 915 "error_description": "The grant type 'authorization_code' must be 916 registered along with the response type 'code' but found only 917 'implicit' instead." 918 } 920 4. IANA Considerations 922 4.1. OAuth Dynamic Client Registration Metadata Registry 924 This specification establishes the OAuth Dynamic Client Registration 925 Metadata registry. 927 OAuth registration client metadata names and descriptions are 928 registered with a Specification Required ([RFC5226]) after a two-week 929 review period on the oauth-ext-review@ietf.org mailing list, on the 930 advice of one or more Designated Experts. However, to allow for the 931 allocation of names prior to publication, the Designated Expert(s) 932 may approve registration once they are satisfied that such a 933 specification will be published. 935 Registration requests sent to the mailing list for review should use 936 an appropriate subject (e.g., "Request to register OAuth Dynamic 937 Client Registration Metadata name: example"). 939 Within the review period, the Designated Expert(s) will either 940 approve or deny the registration request, communicating this decision 941 to the review list and IANA. Denials should include an explanation 942 and, if applicable, suggestions as to how to make the request 943 successful. 945 IANA must only accept registry updates from the Designated Expert(s) 946 and should direct all requests for registration to the review mailing 947 list. 949 4.1.1. Registration Template 951 Client Metadata Name: 952 The name requested (e.g., "example"). This name is case 953 sensitive. Names that match other registered names in a case 954 insensitive manner SHOULD NOT be accepted. 956 Client Metadata Description: 957 Brief description of the metadata value (e.g., "Example 958 description"). 960 Change controller: 961 For Standards Track RFCs, state "IESG". For others, give the name 962 of the responsible party. Other details (e.g., postal address, 963 email address, home page URI) may also be included. 965 Specification document(s): 966 Reference to the document(s) that specify the token endpoint 967 authorization method, preferably including a URI that can be used 968 to retrieve a copy of the document(s). An indication of the 969 relevant sections may also be included but is not required. 971 4.1.2. Initial Registry Contents 973 The initial contents of the OAuth Dynamic Client Registration 974 Metadata registry are: 976 o Client Metadata Name: "redirect_uris" 977 o Client Metadata Description: Array of redirection URIs for use in 978 redirect-based flows 979 o Change controller: IESG 980 o Specification document(s): [[ this document ]] 982 o Client Metadata Name: "token_endpoint_auth_method" 983 o Client Metadata Description: Requested authentication method for 984 the token endpoint 985 o Change controller: IESG 986 o Specification document(s): [[ this document ]] 988 o Client Metadata Name: "grant_types" 989 o Client Metadata Description: Array of OAuth 2.0 grant types that 990 the client may use 991 o Change controller: IESG 992 o Specification document(s): [[ this document ]] 994 o Client Metadata Name: "response_types" 995 o Client Metadata Description: Array of the OAuth 2.0 response types 996 that the client may use 997 o Change controller: IESG 998 o Specification document(s): [[ this document ]] 1000 o Client Metadata Name: "client_name" 1001 o Client Metadata Description: Human-readable name of the client to 1002 be presented to the user 1003 o Change Controller: IESG 1004 o Specification Document(s): [[ this document ]] 1006 o Client Metadata Name: "client_uri" 1007 o Client Metadata Description: URL of a Web page providing 1008 information about the client 1009 o Change Controller: IESG 1010 o Specification Document(s): [[ this document ]] 1012 o Client Metadata Name: "logo_uri" 1013 o Client Metadata Description: URL that references a logo for the 1014 client 1015 o Change Controller: IESG 1016 o Specification Document(s): [[ this document ]] 1018 o Client Metadata Name: "scope" 1019 o Client Metadata Description: Space separated list of OAuth 2.0 1020 scope values 1021 o Change Controller: IESG 1022 o Specification Document(s): [[ this document ]] 1024 o Client Metadata Name: "contacts" 1025 o Client Metadata Description: Array of strings representing ways to 1026 contact people responsible for this client, typically email 1027 addresses 1028 o Change Controller: IESG 1029 o Specification document(s): [[ this document ]] 1031 o Client Metadata Name: "tos_uri" 1032 o Client Metadata Description: URL that points to a human-readable 1033 Terms of Service document for the client 1034 o Change Controller: IESG 1035 o Specification Document(s): [[ this document ]] 1037 o Client Metadata Name: "policy_uri" 1038 o Client Metadata Description: URL that points to a human-readable 1039 Policy document for the client 1040 o Change Controller: IESG 1041 o Specification Document(s): [[ this document ]] 1043 o Client Metadata Name: "jwks_uri" 1044 o Client Metadata Description: URL referencing the client's JSON Web 1045 Key Set [JWK] document representing the client's public keys 1046 o Change Controller: IESG 1047 o Specification Document(s): [[ this document ]] 1049 o Client Metadata Name: "jwks" 1050 o Client Metadata Description: Client's JSON Web Key Set [JWK] 1051 document representing the client's public keys 1052 o Change Controller: IESG 1053 o Specification Document(s): [[ this document ]] 1055 o Client Metadata Name: "software_id" 1056 o Client Metadata Description: Identifier for the software that 1057 comprises a client 1058 o Change Controller: IESG 1059 o Specification Document(s): [[ this document ]] 1061 o Client Metadata Name: "software_version" 1062 o Client Metadata Description: Version identifier for the software 1063 that comprises a client 1065 o Change Controller: IESG 1066 o Specification Document(s): [[ this document ]] 1068 o Client Metadata Name: "client_id" 1069 o Client Metadata Description: Client identifier 1070 o Change Controller: IESG 1071 o Specification Document(s): [[ this document ]] 1073 o Client Metadata Name: "client_secret" 1074 o Client Metadata Description: Client secret 1075 o Change Controller: IESG 1076 o Specification Document(s): [[ this document ]] 1078 o Client Metadata Name: "client_id_issued_at" 1079 o Client Metadata Description: Time at which the client identifier 1080 was issued 1081 o Change Controller: IESG 1082 o Specification Document(s): [[ this document ]] 1084 o Client Metadata Name: "client_secret_expires_at" 1085 o Client Metadata Description: Time at which the client secret will 1086 expire 1087 o Change Controller: IESG 1088 o Specification Document(s): [[ this document ]] 1090 4.2. OAuth Token Endpoint Authentication Methods Registry 1092 This specification establishes the OAuth Token Endpoint 1093 Authentication Methods registry. 1095 Additional values for use as "token_endpoint_auth_method" values are 1096 registered with a Specification Required ([RFC5226]) after a two-week 1097 review period on the oauth-ext-review@ietf.org mailing list, on the 1098 advice of one or more Designated Experts. However, to allow for the 1099 allocation of values prior to publication, the Designated Expert(s) 1100 may approve registration once they are satisfied that such a 1101 specification will be published. 1103 Registration requests must be sent to the oauth-ext-review@ietf.org 1104 mailing list for review and comment, with an appropriate subject 1105 (e.g., "Request to register token_endpoint_auth_method value: 1106 example"). 1108 Within the review period, the Designated Expert(s) will either 1109 approve or deny the registration request, communicating this decision 1110 to the review list and IANA. Denials should include an explanation 1111 and, if applicable, suggestions as to how to make the request 1112 successful. 1114 IANA must only accept registry updates from the Designated Expert(s) 1115 and should direct all requests for registration to the review mailing 1116 list. 1118 4.2.1. Registration Template 1120 Token Endpoint Authorization Method Name: 1121 The name requested (e.g., "example"). This name is case 1122 sensitive. Names that match other registered names in a case 1123 insensitive manner SHOULD NOT be accepted. 1125 Change controller: 1126 For Standards Track RFCs, state "IESG". For others, give the name 1127 of the responsible party. Other details (e.g., postal address, 1128 email address, home page URI) may also be included. 1130 Specification document(s): 1131 Reference to the document(s) that specify the token endpoint 1132 authorization method, preferably including a URI that can be used 1133 to retrieve a copy of the document(s). An indication of the 1134 relevant sections may also be included but is not required. 1136 4.2.2. Initial Registry Contents 1138 The initial contents of the OAuth Token Endpoint Authentication 1139 Methods registry are: 1141 o Token Endpoint Authorization Method Name: "none" 1142 o Change controller: IESG 1143 o Specification document(s): [[ this document ]] 1145 o Token Endpoint Authorization Method Name: "client_secret_post" 1146 o Change controller: IESG 1147 o Specification document(s): [[ this document ]] 1149 o Token Endpoint Authorization Method Name: "client_secret_basic" 1150 o Change controller: IESG 1151 o Specification document(s): [[ this document ]] 1153 5. Security Considerations 1155 Since requests to the client registration endpoint result in the 1156 transmission of clear-text credentials (in the HTTP request and 1157 response), the authorization server MUST require the use of a 1158 transport-layer security mechanism when sending requests to the 1159 registration endpoint. The server MUST support TLS 1.2 RFC 5246 1160 [RFC5246] and MAY support additional transport-layer mechanisms 1161 meeting its security requirements. When using TLS, the client MUST 1162 perform a TLS/SSL server certificate check, per RFC 6125 [RFC6125]. 1163 Implementation security considerations can be found in 1164 Recommendations for Secure Use of TLS and DTLS 1165 [I-D.ietf-uta-tls-bcp]. 1167 For clients that use redirect-based grant types such as 1168 "authorization_code" and "implicit", authorization servers MUST 1169 require clients to register their redirection URI values. This can 1170 help mitigate attacks where rogue actors inject and impersonate a 1171 validly registered client and intercept its authorization code or 1172 tokens through an invalid redirection URI or open redirector. 1173 Additionally, in order to prevent hijacking of the return values of 1174 the redirection, registered redirection URI values MUST be one of: 1176 o A remote web site protected by TLS (e.g., 1177 https://client.example.com/oauth_redirect) 1178 o A web site hosted on the local machine using an HTTP URI (e.g., 1179 http://localhost:8080/oauth_redirect) 1180 o A non-HTTP application-specific URL that is available only to the 1181 client application (e.g., exampleapp://oauth_redirect) 1183 Public clients MAY register with an authorization server using this 1184 protocol, if the authorization server's policy allows them. Public 1185 clients use a "none" value for the "token_endpoint_auth_method" 1186 metadata field and are generally used with the "implicit" grant type. 1187 Often these clients will be short-lived in-browser applications 1188 requesting access to a user's resources and access is tied to a 1189 user's active session at the authorization server. Since such 1190 clients often do not have long-term storage, it is possible that such 1191 clients would need to re-register every time the browser application 1192 is loaded. Additionally, such clients may not have ample opportunity 1193 to unregister themselves using the delete action before the browser 1194 closes. To avoid the resulting proliferation of dead client 1195 identifiers, an authorization server MAY decide to expire 1196 registrations for existing clients meeting certain criteria after a 1197 period of time has elapsed. 1199 Since different OAuth 2.0 grant types have different security and 1200 usage parameters, an authorization server MAY require separate 1201 registrations for a piece of software to support multiple grant 1202 types. For instance, an authorization server might require that all 1203 clients using the "authorization_code" grant type make use of a 1204 client secret for the "token_endpoint_auth_method", but any clients 1205 using the "implicit" grant type do not use any authentication at the 1206 token endpoint. In such a situation, a server MAY disallow clients 1207 from registering for both the "authorization_code" and "implicit" 1208 grant types simultaneously. Similarly, the "authorization_code" 1209 grant type is used to represent access on behalf of an end-user, but 1210 the "client_credentials" grant type represents access on behalf of 1211 the client itself. For security reasons, an authorization server 1212 could require that different scopes be used for these different use 1213 cases, and as a consequence it MAY disallow these two grant types 1214 from being registered together by the same client. In all of these 1215 cases, the authorization server would respond with an 1216 "invalid_client_metadata" error response. 1218 Unless used as a claim in a software statement, the authorization 1219 server MUST treat all client metadata as self-asserted. For 1220 instance, a rogue client might use the name and logo of a legitimate 1221 client that it is trying to impersonate. Additionally, a rogue 1222 client might try to use the software identifier or software version 1223 of a legitimate client to attempt to associate itself on the 1224 authorization server with instances of the legitimate client. To 1225 counteract this, an authorization server needs to take steps to 1226 mitigate this risk by looking at the entire registration request and 1227 client configuration. For instance, an authorization server could 1228 issue a warning if the domain/site of the logo doesn't match the 1229 domain/site of redirection URIs. An authorization server could also 1230 refuse registration requests from a known software identifier that is 1231 requesting different redirection URIs or a different client URI. An 1232 authorization server can also present warning messages to end-users 1233 about dynamically registered clients in all cases, especially if such 1234 clients have been recently registered or have not been trusted by any 1235 users at the authorization server before. 1237 In a situation where the authorization server is supporting open 1238 client registration, it must be extremely careful with any URL 1239 provided by the client that will be displayed to the user (e.g. 1240 "logo_uri", "tos_uri", "client_uri", and "policy_uri"). For 1241 instance, a rogue client could specify a registration request with a 1242 reference to a drive-by download in the "policy_uri". The 1243 authorization server SHOULD check to see if the "logo_uri", 1244 "tos_uri", "client_uri", and "policy_uri" have the same host and 1245 scheme as the those defined in the array of "redirect_uris" and that 1246 all of these URIs resolve to valid web pages. 1248 Clients MAY use both the direct JSON object and the JWT-encoded 1249 software statement to present client metadata to the authorization 1250 server as part of the registration request. A software statement is 1251 cryptographically protected and represents claims made by the issuer 1252 of the statement, while the JSON object represents the self-asserted 1253 claims made by the client or developer directly. If the software 1254 statement is valid and signed by an acceptable authority (such as the 1255 software API publisher), the values of client metadata within the 1256 software statement MUST take precedence over those metadata values 1257 presented in the plain JSON object, which could have been modified en 1258 route. 1260 The software statement is an item that is self-asserted by the 1261 client, even though its contents have been digitally signed or MACed 1262 by the issuer of the software statement. As such, presentation of 1263 the software statement is not sufficient in most cases to fully 1264 identity a piece of client software. An initial access token, in 1265 contrast, does not necessarily contain information about a particular 1266 piece of client software but instead represents authorization to use 1267 the registration endpoint. An authorization server MUST consider the 1268 full registration request, including the software statement, initial 1269 access token, and JSON client metadata values, when deciding whether 1270 to honor a given registration request. 1272 If an authorization server receives a registration request for a 1273 client that uses the same "software_id" and "software_version" values 1274 as another client, the server should treat the new registration as 1275 being suspect. It is possible that the new client is trying to 1276 impersonate the existing client. 1278 Since a client identifier is a public value that can be used to 1279 impersonate a client at the authorization endpoint, an authorization 1280 server that decides to issue the same client identifier to multiple 1281 instances of a registered client needs to be very particular about 1282 the circumstances under which this occurs. For instance, the 1283 authorization server can limit a given client identifier to clients 1284 using the same redirect-based flow and the same redirection URIs. An 1285 authorization server SHOULD NOT issue the same client secret to 1286 multiple instances of a registered client, even if they are issued 1287 the same client identifier, or else the client secret could be 1288 leaked, allowing malicious impostors to impersonate a confidential 1289 client. 1291 6. Privacy Considerations 1293 As the protocol described in this specification deals almost 1294 exclusively with information about software and not about people, 1295 there are very few privacy concerns for its use. The notable 1296 exception is the "contacts" field as defined in Client Metadata 1297 (Section 2), which contains contact information for the developers or 1298 other parties responsible for the client software. These values are 1299 intended to be displayed to end-users and will be available to the 1300 administrators of the authorization server. As such, the developer 1301 may wish to provide an email address or other contact information 1302 expressly dedicated to the purpose of supporting the client instead 1303 of using their personal or professional addresses. Alternatively, 1304 the developer may wish to provide a collective email address for the 1305 client to allow for continuing contact and support of the client 1306 software after the developer moves on and someone else takes over 1307 that responsibility. 1309 In general, the metadata for a client, such as the client name and 1310 software identifier, are common across all instances of a piece of 1311 client software and therefore pose no privacy issues for end-users. 1312 Client identifiers, on the other hand, are often unique to a specific 1313 instance of a client. For clients such as web sites that are used by 1314 many users, there may not be significant privacy concerns regarding 1315 the client identifier, but for clients such as native applications 1316 that are installed on a single end-user's device, the client 1317 identifier could be uniquely tracked during OAuth 2.0 transactions 1318 and its use tied to that single end-user. However, as the client 1319 software still needs to be authorized by a resource owner through an 1320 OAuth 2.0 authorization grant, this type of tracking can occur 1321 whether or not the client identifier is unique by correlating the 1322 authenticated resource owner with the requesting client identifier. 1324 Note that clients are forbidden by this specification from creating 1325 their own client identifier. If the client were able to do so, an 1326 individual client instance could be tracked across multiple colluding 1327 authorization servers, leading to privacy and security issues. 1328 Additionally, client identifiers are generally issued uniquely per 1329 registration request, even for the same instance of software. In 1330 this way, an application could marginally improve privacy by 1331 registering multiple times and appearing to be completely separate 1332 applications. However, this technique does incur significant 1333 usability cost in the form of requiring multiple authorizations per 1334 resource owner and is therefore unlikely to be used in practice. 1336 7. References 1338 7.1. Normative References 1340 [IANA.Language] 1341 Internet Assigned Numbers Authority (IANA), "Language 1342 Subtag Registry", 2005. 1344 [JWK] Jones, M., "JSON Web Key (JWK)", draft-ietf-jose-json-web- 1345 key (work in progress), January 2015. 1347 [JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 1348 Signature (JWS)", draft-ietf-jose-json-web-signature (work 1349 in progress), January 2015. 1351 [JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 1352 (JWT)", draft-ietf-oauth-json-web-token (work in 1353 progress), January 2015. 1355 [OAuth.JWT] 1356 Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token 1357 (JWT) Profile for OAuth 2.0 Client Authentication and 1358 Authorization Grants", draft-ietf-oauth-jwt-bearer (work 1359 in progress), November 2015. 1361 [OAuth.SAML2] 1362 Campbell, B., Mortimore, C., and M. Jones, "SAML 2.0 1363 Profile for OAuth 2.0 Client Authentication and 1364 Authorization Grants", draft-ietf-oauth-saml2-bearer (work 1365 in progress), November 2015. 1367 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1368 Requirement Levels", BCP 14, RFC 2119, March 1997. 1370 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1371 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1372 May 2008. 1374 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1375 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1377 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying 1378 Languages", BCP 47, RFC 5646, September 2009. 1380 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1381 Verification of Domain-Based Application Service Identity 1382 within Internet Public Key Infrastructure Using X.509 1383 (PKIX) Certificates in the Context of Transport Layer 1384 Security (TLS)", RFC 6125, March 2011. 1386 [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 1387 6749, October 2012. 1389 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 1390 Framework: Bearer Token Usage", RFC 6750, October 2012. 1392 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 1393 Interchange Format", RFC 7159, March 2014. 1395 7.2. Informative References 1397 [I-D.hardjono-oauth-umacore] 1398 Hardjono, T., "User-Managed Access (UMA) Profile of OAuth 1399 2.0", draft-hardjono-oauth-umacore-10 (work in progress), 1400 July 2014. 1402 [I-D.ietf-uta-tls-bcp] 1403 Sheffer, Y., Holz, R., and P. Saint-Andre, 1404 "Recommendations for Secure Use of TLS and DTLS", draft- 1405 ietf-uta-tls-bcp-09 (work in progress), February 2015. 1407 [OAuth.Registration.Management] 1408 Richer, J., Jones, M., Bradley, J., and M. Machulak, 1409 "OAuth 2.0 Dynamic Client Registration Management 1410 Protocol", draft-ietf-oauth-dyn-reg-management (work in 1411 progress), February 2015. 1413 [OpenID.Registration] 1414 Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect 1415 Dynamic Client Registration 1.0", November 2014. 1417 Appendix A. Use Cases 1419 This appendix describes different ways that this specification can be 1420 utilized, including describing some of the choices that may need to 1421 be made. Some of the choices are independent and can be used in 1422 combination, whereas some of the choices are interrelated. 1424 A.1. Open versus Protected Dynamic Client Registration 1426 A.1.1. Open Dynamic Client Registration 1428 Authorization servers that support open registration allow 1429 registrations to be made with no initial access token. This allows 1430 all client software to register with the authorization server. 1432 A.1.2. Protected Dynamic Client Registration 1434 Authorization servers that support protected registration require 1435 that an initial access token be used when making registration 1436 requests. While the method by which a client or developer receives 1437 this initial access token and the method by which the authorization 1438 server validates this initial access token are out of scope for this 1439 specification, a common approach is for the developer to use a manual 1440 pre-registration portal at the authorization server that issues an 1441 initial access token to the developer. 1443 A.2. Registration Without or With Software Statements 1445 A.2.1. Registration Without a Software Statement 1447 When a software statement is not used in the registration request, 1448 the authorization server must be willing to use client metadata 1449 values without them being digitally signed or MACed (and thereby 1450 attested to) by any authority. (Note that this choice is independent 1451 of the Open versus Protected choice, and that an initial access token 1452 is another possible form of attestation.) 1454 A.2.2. Registration With a Software Statement 1456 A software statement can be used in a registration request to provide 1457 attestation by an authority for a set of client metadata values. 1458 This can be useful when the authorization server wants to restrict 1459 registration to client software attested to by a set of authorities 1460 or when it wants to know that multiple registration requests refer to 1461 the same piece of client software. 1463 A.3. Registration by the Client or Developer 1465 A.3.1. Registration by the Client 1467 In some use cases, client software will dynamically register itself 1468 with an authorization server to obtain a client identifier and other 1469 information needed to interact with the authorization server. In 1470 this case, no client identifier for the authorization server is 1471 packaged with the client software. 1473 A.3.2. Registration by the Developer 1475 In some cases, the developer (or development software being used by 1476 the developer) will pre-register the client software with the 1477 authorization server or a set of authorization servers. In this 1478 case, the client identifier value(s) for the authorization server(s) 1479 can be packaged with the client software. 1481 A.4. Client ID per Client Instance or per Client Software 1483 A.4.1. Client ID per Client Software Instance 1485 In some cases, each deployed instance of a piece of client software 1486 will dynamically register and obtain distinct client identifier 1487 values. This can be advantageous, for instance, if the code flow is 1488 being used, as it also enables each client instance to have its own 1489 client secret. This can be useful for native clients, which cannot 1490 maintain the secrecy of a client secret value packaged with the 1491 software, but which may be able to maintain the secrecy of a per- 1492 instance client secret. 1494 A.4.2. Client ID Shared Among All Instances of Client Software 1496 In some cases, each deployed instance of a piece of client software 1497 will share a common client identifier value. For instance, this is 1498 often the case for in-browser clients using the implicit flow, when 1499 no client secret is involved. Particular authorization servers might 1500 choose, for instance, to maintain a mapping between software 1501 statement values and client identifier values, and return the same 1502 client identifier value for all registration requests for a 1503 particular piece of software. The circumstances under which an 1504 authorization server would do so, and the specific software statement 1505 characteristics required in this case, are beyond the scope of this 1506 specification. 1508 A.5. Stateful or Stateless Registration 1510 A.5.1. Stateful Client Registration 1512 In some cases, authorization servers will maintain state about 1513 registered clients, typically indexing this state using the client 1514 identifier value. This state would typically include the client 1515 metadata values associated with the client registration, and possibly 1516 other state specific to the authorization server's implementation. 1517 When stateful registration is used, operations to support retrieving 1518 and/or updating this state may be supported. One possible set of 1519 operations upon stateful registrations is described in the 1520 [OAuth.Registration.Management] specification. 1522 A.5.2. Stateless Client Registration 1524 In some cases, authorization servers will be implemented in a manner 1525 the enables them to not maintain any local state about registered 1526 clients. One means of doing this is to encode all the registration 1527 state in the returned client identifier value, and possibly 1528 encrypting the state to the authorization server to maintain the 1529 confidentiality and integrity of the state. 1531 Appendix B. Acknowledgments 1533 The authors thank the OAuth Working Group, the User-Managed Access 1534 Working Group, and the OpenID Connect Working Group participants for 1535 their input to this document. In particular, the following 1536 individuals have been instrumental in their review and contribution 1537 to various versions of this document: Amanda Anganes, Derek Atkins, 1538 Tim Bray, Domenico Catalano, Donald Coffin, Vladimir Dzhuvinov, 1539 George Fletcher, Thomas Hardjono, Phil Hunt, William Kim, Torsten 1540 Lodderstedt, Eve Maler, Josh Mandel, Nov Matake, Tony Nadalin, Nat 1541 Sakimura, Christian Scholz, and Hannes Tschofenig. 1543 Appendix C. Document History 1545 [[ to be removed by the RFC editor before publication as an RFC ]] 1547 -27 1549 1: Changed a registry name missed in -26. 1551 -26 1553 o Used consistent registry name. 1555 -25 1557 o Updated author information. 1558 o Clarified registry contents. 1559 o Added forward pointer to IANA from metadata section. 1560 o Clarified how to silently ignore errors. 1561 o Reformatted diagram text. 1563 -24 1565 o Clarified some party definitions. 1566 o Clarified the opaqueness of software_id and software_statement. 1567 o Created a forward pointer to the Security Considerations section 1568 for TLS requirements on the registration endpoint. 1569 o Added a forward pointer to the Privacy Considerations section for 1570 the contacts field. 1571 o Wrote privacy considerations about client_id tracking. 1573 -23 1575 o Updated author information. 1577 -22 1579 o Reorganized registration response sections. 1580 o Addressed shepherd comments. 1581 o Added concrete JWK set to example. 1583 -21 1585 o Applied minor editorial fixes. 1586 o Added software statement examples. 1588 o Moved software statement request details to sub-section. 1589 o Clarified that a server MAY ignore the software statement (just as 1590 it MAY ignore other metadata values). 1591 o Removed TLS 1.0. 1592 o Added privacy considerations around "contacts" field. 1593 o Marked software_id as RECOMMENDED inside of a software statement. 1595 -20 1597 o Applied minor editorial fixes from working group comments. 1599 -19 1601 o Added informative references to the OpenID Connect Dynamic Client 1602 Registration and UMA specifications in the introduction. 1603 o Clarified the "jwks" and "jwks_uri" descriptions and included an 1604 example situation in which they might be used. 1605 o Removed "application_type". 1606 o Added redirection URI usage restrictions to the Security 1607 Considerations section, based on the client type. 1608 o Expanded the "tos_uri" and "policy_uri" descriptions. 1610 -18 1612 o Corrected an example HTTP response status code to be 201 Created. 1613 o Said more about who issues and uses initial access tokens and 1614 software statements. 1615 o Stated that the use of an initial access token is required when 1616 the authorization server limits the parties that can register a 1617 client. 1618 o Stated that the implementation and use of all client metadata 1619 fields is OPTIONAL, other than "redirect_uris", which MUST be used 1620 for redirect-based flows and implemented to fulfill the 1621 requirement in Section 2 of OAuth 2.0. 1622 o Added the "application_type" metadata value, which had somehow 1623 been omitted. 1624 o Added missing default metadata values, which had somehow been 1625 omitted. 1626 o Clarified that the "software_id" is ultimately asserted by the 1627 client developer. 1628 o Clarified that the "error" member is required in error responses, 1629 "error_description" member is optional, and other members may be 1630 present. 1631 o Added security consideration about registrations with duplicate 1632 "software_id" and "software_version" values. 1634 -17 1635 o Merged draft-ietf-oauth-dyn-reg-metadata back into this document. 1636 o Removed "Core" from the document title. 1637 o Explicitly state that all metadata members are optional. 1638 o Clarified language around software statements for use in 1639 registration context. 1640 o Clarified that software statements need to be digitally signed or 1641 MACed. 1642 o Added a "jwks" metadata parameter to parallel the "jwks_uri" 1643 parameter. 1644 o Removed normative language from terminology. 1645 o Expanded abstract and introduction. 1646 o Addressed review comments from several working group members. 1648 -16 1650 o Replaced references to draft-jones-oauth-dyn-reg-metadata and 1651 draft-jones-oauth-dyn-reg-management with draft-ietf-oauth-dyn- 1652 reg-metadata and draft-ietf-oauth-dyn-reg-management. 1653 o Addressed review comments by Phil Hunt and Tony Nadalin. 1655 -15 1657 o Partitioned the Dynamic Client Registration specification into 1658 core, metadata, and management specifications. This built on work 1659 first published as draft-richer-oauth-dyn-reg-core-00 and draft- 1660 richer-oauth-dyn-reg-management-00. 1661 o Added the ability to use Software Statements. This built on work 1662 first published as draft-hunt-oauth-software-statement-00 and 1663 draft-hunt-oauth-client-association-00. 1664 o Created the IANA OAuth Registration Client Metadata registry for 1665 registering Client Metadata values. 1666 o Defined Client Instance term and stated that multiple instances 1667 can use the same client identifier value under certain 1668 circumstances. 1669 o Rewrote the introduction. 1670 o Rewrote the Use Cases appendix. 1672 -14 1674 o Added software_id and software_version metadata fields 1675 o Added direct references to RFC6750 errors in read/update/delete 1676 methods 1678 -13 1680 o Fixed broken example text in registration request and in delete 1681 request 1683 o Added security discussion of separating clients of different grant 1684 types 1685 o Fixed error reference to point to RFC6750 instead of RFC6749 1686 o Clarified that servers must respond to all requests to 1687 configuration endpoint, even if it's just an error code 1688 o Lowercased all Terms to conform to style used in RFC6750 1690 -12 1692 o Improved definition of Initial Access Token 1693 o Changed developer registration scenario to have the Initial Access 1694 Token gotten through a normal OAuth 2.0 flow 1695 o Moved non-normative client lifecycle examples to appendix 1696 o Marked differentiating between auth servers as out of scope 1697 o Added protocol flow diagram 1698 o Added credential rotation discussion 1699 o Called out Client Registration Endpoint as an OAuth 2.0 Protected 1700 Resource 1701 o Cleaned up several pieces of text 1703 -11 1705 o Added localized text to registration request and response 1706 examples. 1707 o Removed "client_secret_jwt" and "private_key_jwt". 1708 o Clarified "tos_uri" and "policy_uri" definitions. 1709 o Added the OAuth Token Endpoint Authentication Methods registry for 1710 registering "token_endpoint_auth_method" metadata values. 1711 o Removed uses of non-ASCII characters, per RFC formatting rules. 1712 o Changed "expires_at" to "client_secret_expires_at" and "issued_at" 1713 to "client_id_issued_at" for greater clarity. 1714 o Added explanatory text for different credentials (Initial Access 1715 Token, Registration Access Token, Client Credentials) and what 1716 they're used for. 1717 o Added Client Lifecycle discussion and examples. 1718 o Defined Initial Access Token in Terminology section. 1720 -10 1722 o Added language to point out that scope values are service-specific 1723 o Clarified normative language around client metadata 1724 o Added extensibility to token_endpoint_auth_method using absolute 1725 URIs 1726 o Added security consideration about registering redirect URIs 1727 o Changed erroneous 403 responses to 401's with notes about token 1728 handling 1729 o Added example for initial registration credential 1730 -09 1732 o Added method of internationalization for Client Metadata values 1733 o Fixed SAML reference 1735 -08 1737 o Collapsed jwk_uri, jwk_encryption_uri, x509_uri, and 1738 x509_encryption_uri into a single jwks_uri parameter 1739 o Renamed grant_type to grant_types since it's a plural value 1740 o Formalized name of "OAuth 2.0" throughout document 1741 o Added JWT Bearer Assertion and SAML 2 Bearer Assertion to example 1742 grant types 1743 o Added response_types parameter and explanatory text on its use 1744 with and relationship to grant_types 1746 -07 1748 o Changed registration_access_url to registration_client_uri 1749 o Fixed missing text in 5.1 1750 o Added Pragma: no-cache to examples 1751 o Changed "no such client" error to 403 1752 o Renamed Client Registration Access Endpoint to Client 1753 Configuration Endpoint 1754 o Changed all the parameter names containing "_url" to instead use 1755 "_uri" 1756 o Updated example text for forming Client Configuration Endpoint URL 1758 -06 1760 o Removed secret_rotation as a client-initiated action, including 1761 removing client secret rotation endpoint and parameters. 1762 o Changed _links structure to single value registration_access_url. 1763 o Collapsed create/update/read responses into client info response. 1764 o Changed return code of create action to 201. 1765 o Added section to describe suggested generation and composition of 1766 Client Registration Access URL. 1767 o Added clarifying text to PUT and POST requests to specify JSON in 1768 the body. 1769 o Added Editor's Note to DELETE operation about its inclusion. 1770 o Added Editor's Note to registration_access_url about alternate 1771 syntax proposals. 1773 -05 1775 o changed redirect_uri and contact to lists instead of space 1776 delimited strings 1777 o removed operation parameter 1778 o added _links structure 1779 o made client update management more RESTful 1780 o split endpoint into three parts 1781 o changed input to JSON from form-encoded 1782 o added READ and DELETE operations 1783 o removed Requirements section 1784 o changed token_endpoint_auth_type back to 1785 token_endpoint_auth_method to match OIDC who changed to match us 1787 -04 1789 o removed default_acr, too undefined in the general OAuth2 case 1790 o removed default_max_auth_age, since there's no mechanism for 1791 supplying a non-default max_auth_age in OAuth2 1792 o clarified signing and encryption URLs 1793 o changed token_endpoint_auth_method to token_endpoint_auth_type to 1794 match OIDC 1796 -03 1798 o added scope and grant_type claims 1799 o fixed various typos and changed wording for better clarity 1800 o endpoint now returns the full set of client information 1801 o operations on client_update allow for three actions on metadata: 1802 leave existing value, clear existing value, replace existing value 1803 with new value 1805 -02 1807 o Reorganized contributors and references 1808 o Moved OAuth references to RFC 1809 o Reorganized model/protocol sections for clarity 1810 o Changed terminology to "client register" instead of "client 1811 associate" 1812 o Specified that client_id must match across all subsequent requests 1813 o Fixed RFC2XML formatting, especially on lists 1815 -01 1817 o Merged UMA and OpenID Connect registrations into a single document 1818 o Changed to form-parameter inputs to endpoint 1819 o Removed pull-based registration 1821 -00 1823 o Imported original UMA draft specification 1825 Authors' Addresses 1827 Justin Richer (editor) 1829 Email: ietf@justin.richer.org 1831 Michael B. Jones 1832 Microsoft 1834 Email: mbj@microsoft.com 1835 URI: http://self-issued.info/ 1837 John Bradley 1838 Ping Identity 1840 Email: ve7jtb@ve7jtb.com 1842 Maciej Machulak 1843 Newcastle University 1845 Email: maciej.machulak@gmail.com 1847 Phil Hunt 1848 Oracle Corporation 1850 Email: phil.hunt@yahoo.com