idnits 2.17.1 draft-ietf-oauth-dyn-reg-24.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 (February 20, 2015) is 3350 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: August 24, 2015 Microsoft 6 J. Bradley 7 Ping Identity 8 M. Machulak 9 Newcastle University 10 P. Hunt 11 Oracle Corporation 12 February 20, 2015 14 OAuth 2.0 Dynamic Client Registration Protocol 15 draft-ietf-oauth-dyn-reg-24 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 August 24, 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 Registration Client 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 . . . . . . . . . . . . . . . . . . . . . . . 39 113 1. Introduction 115 In order for an OAuth 2.0 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 the 270 client's registered metadata, a client identifier that is unique 271 at the server, a set of client credentials such as a client secret 272 if applicable for this client, and possibly other values. 274 Examples of different configurations and usages are included in 275 Appendix A. 277 2. Client Metadata 279 Registered clients have a set of metadata values associated with 280 their client identifier at an authorization server, such as the list 281 of valid redirection URIs or a display name. 283 These client metadata values are used in two ways: 285 o as input values to registration requests, and 286 o as output values in registration responses. 288 The following client metadata fields are defined by this 289 specification. The implementation and use of all client metadata 290 fields is OPTIONAL, unless stated otherwise. 292 redirect_uris 293 Array of redirection URI values for use in redirect-based flows 294 such as the authorization code and implicit flows. As required by 295 Section 2 of OAuth 2.0 [RFC6749], clients using flows with 296 redirection MUST register their redirection URI values. 297 Authorization servers that support dynamic registration for 298 redirect-based flows MUST implement support for this metadata 299 value. 300 token_endpoint_auth_method 301 The requested authentication method for the token endpoint. 302 Values defined by this specification are: 304 * "none": The client is a public client as defined in OAuth 2.0 305 and does not have a client secret. 306 * "client_secret_post": The client uses the HTTP POST parameters 307 defined in OAuth 2.0 section 2.3.1. 308 * "client_secret_basic": the client uses HTTP Basic defined in 309 OAuth 2.0 section 2.3.1 311 Additional values can be defined via the IANA OAuth Token Endpoint 312 Authentication Methods Registry established in Section 4.2. 313 Absolute URIs can also be used as values for this parameter 314 without being registered. If unspecified or omitted, the default 315 is "client_secret_basic", denoting HTTP Basic Authentication 316 Scheme as specified in Section 2.3.1 of OAuth 2.0. 317 grant_types 318 Array of OAuth 2.0 grant types that the client may use. These 319 grant types are defined as follows: 321 * "authorization_code": The Authorization Code Grant described in 322 OAuth 2.0 Section 4.1 323 * "implicit": The Implicit Grant described in OAuth 2.0 324 Section 4.2 325 * "password": The Resource Owner Password Credentials Grant 326 described in OAuth 2.0 Section 4.3 327 * "client_credentials": The Client Credentials Grant described in 328 OAuth 2.0 Section 4.4 329 * "refresh_token": The Refresh Token Grant described in OAuth 2.0 330 Section 6. 331 * "urn:ietf:params:oauth:grant-type:jwt-bearer": The JWT Bearer 332 Grant defined in OAuth JWT Bearer Token Profiles [OAuth.JWT]. 334 * "urn:ietf:params:oauth:grant-type:saml2-bearer": The SAML 2 335 Bearer Grant defined in OAuth SAML 2 Bearer Token Profiles 336 [OAuth.SAML2]. 338 If the token endpoint is used in the grant type, the value of this 339 parameter MUST be the same as the value of the "grant_type" 340 parameter passed to the token endpoint defined in the grant type 341 definition. Authorization servers MAY allow for other values as 342 defined in the grant type extension process described in OAuth 2.0 343 Section 2.5. If omitted, the default behavior is that the client 344 will use only the "authorization_code" Grant Type. 345 response_types 346 Array of the OAuth 2.0 response types that the client can use. 347 These response types are defined as follows: 349 * "code": The authorization code response described in OAuth 2.0 350 Section 4.1. 351 * "token": The implicit response described in OAuth 2.0 352 Section 4.2. 354 If the authorization endpoint is used by the grant type, the value 355 of this parameter MUST be the same as the value of the 356 "response_type" parameter passed to the authorization endpoint 357 defined in the grant type definition. Authorization servers MAY 358 allow for other values as defined in the grant type extension 359 process is described in OAuth 2.0 Section 2.5. If omitted, the 360 default is that the client will use only the "code" response type. 361 client_name 362 Human-readable name of the client to be presented to the end-user 363 during authorization. If omitted, the authorization server MAY 364 display the raw "client_id" value to the end-user instead. It is 365 RECOMMENDED that clients always send this field. The value of 366 this field MAY be internationalized, as described in Section 2.2. 367 client_uri 368 URL of a web page providing information about the client. If 369 present, the server SHOULD display this URL to the end-user in a 370 clickable fashion. It is RECOMMENDED that clients always send 371 this field. The value of this field MUST point to a valid web 372 page. The value of this field MAY be internationalized, as 373 described in Section 2.2. 374 logo_uri 375 URL that references a logo for the client. If present, the server 376 SHOULD display this image to the end-user during approval. The 377 value of this field MUST point to a valid image file. The value 378 of this field MAY be internationalized, as described in 379 Section 2.2. 380 scope 381 Space separated list of scope values (as described in Section 3.3 382 of OAuth 2.0 [RFC6749]) that the client can use when requesting 383 access tokens. The semantics of values in this list is service 384 specific. If omitted, an authorization server MAY register a 385 client with a default set of scopes. 386 contacts 387 Array of strings representing ways to contact people responsible 388 for this client, typically email addresses. The authorization 389 server MAY make these contact addresses available to end-users for 390 support requests for the client. See Section 6 for information on 391 Privacy Considerations. 392 tos_uri 393 URL that points to a human-readable terms of service document for 394 the client that describes a contractual relationship between the 395 end-user and the client that the end-user accepts when authorizing 396 the client. The authorization server SHOULD display this URL to 397 the end-user if it is provided. The value of this field MUST 398 point to a valid web page. The value of this field MAY be 399 internationalized, as described in Section 2.2. 400 policy_uri 401 URL that points to a human-readable privacy policy document that 402 describes how the deployment organization collects, uses, retains, 403 and discloses personal data. The authorization server SHOULD 404 display this URL to the end-user if it is provided. The value of 405 this field MUST point to a valid web page. The value of this 406 field MAY be internationalized, as described in Section 2.2. 407 jwks_uri 408 URL referencing the client's JSON Web Key Set [JWK] document, 409 which contains the client's public keys. The value of this field 410 MUST point to a valid JWK Set document. These keys can be used by 411 higher level protocols that use signing or encryption. For 412 instance, these keys might be used by some applications for 413 validating signed requests made to the token endpoint when using 414 JWTs for client authentication [OAuth.JWT]. Use of this parameter 415 is preferred over the "jwks" parameter, as it allows for easier 416 key rotation. The "jwks_uri" and "jwks" parameters MUST NOT both 417 be present in the same request or response. 418 jwks 419 Client's JSON Web Key Set [JWK] document value, which contains the 420 client's public keys. The value of this field MUST be a JSON 421 object containing a valid JWK Set. These keys can be used by 422 higher level protocols that use signing or encryption. This 423 parameter is intended to be used by clients that cannot use the 424 "jwks_uri" parameter, such as native clients that cannot host 425 public URLs. The "jwks_uri" and "jwks" parameters MUST NOT both 426 be present in the same request or response. 427 software_id 428 A unique identifier (e.g. a UUID) assigned by the client developer 429 or software publisher used by registration endpoints to identify 430 the client software to be dynamically registered. Unlike 431 "client_id", which is issued by the authorization server and 432 SHOULD vary between instances, the "software_id" SHOULD remain the 433 same for all instances of the client software. The "software_id" 434 SHOULD remain the same across multiple updates or versions of the 435 same piece of software. The value of this field is not intended 436 to be human-readable and is usually opaque to the client and 437 authorization server. 438 software_version 439 A version identifier for the client software identified by 440 "software_id". The value of the "software_version" SHOULD change 441 on any update to the client software identified by the same 442 "software_id". The value of this field is a string that is 443 intended to be compared using string equality matching. The value 444 of this field is not intended to be human readable and is usually 445 opaque to the client and authorization server. 447 Extensions and profiles of this specification MAY expand this list. 448 The authorization server MUST ignore any client metadata values sent 449 by the client that it does not understand. 451 Client metadata values can either be communicated directly in the 452 body of a registration request, as described in Section 3.1, or 453 included as claims in a software statement, as described in 454 Section 2.3, or a mixture of both. If the same client metadata name 455 is present in both locations and the software statement is trusted by 456 the authorization server, the value of a claim in the software 457 statement MUST take precedence. 459 2.1. Relationship between Grant Types and Response Types 461 The "grant_types" and "response_types" values described above are 462 partially orthogonal, as they refer to arguments passed to different 463 endpoints in the OAuth protocol. However, they are related in that 464 the "grant_types" available to a client influence the 465 "response_types" that the client is allowed to use, and vice versa. 466 For instance, a "grant_types" value that includes 467 "authorization_code" implies a "response_types" value that includes 468 "code", as both values are defined as part of the OAuth 2.0 469 authorization code grant. As such, a server supporting these fields 470 SHOULD take steps to ensure that a client cannot register itself into 471 an inconsistent state, for example by returning an 472 "invalid_client_metadata" error response to an inconsistent 473 registration request. 475 The correlation between the two fields is listed in the table below. 477 +-----------------------------------------------+-------------------+ 478 | grant_types value includes: | response_types | 479 | | value includes: | 480 +-----------------------------------------------+-------------------+ 481 | authorization_code | code | 482 | implicit | token | 483 | password | (none) | 484 | client_credentials | (none) | 485 | refresh_token | (none) | 486 | urn:ietf:params:oauth:grant-type:jwt-bearer | (none) | 487 | urn:ietf:params:oauth:grant-type:saml2-bearer | (none) | 488 +-----------------------------------------------+-------------------+ 490 Extensions and profiles of this document that introduce new values to 491 either the "grant_types" or "response_types" parameter MUST document 492 all correspondences between these two parameter types. 494 2.2. Human-Readable Client Metadata 496 Human-readable client metadata values and client metadata values that 497 reference human-readable values MAY be represented in multiple 498 languages and scripts. For example, the values of fields such as 499 "client_name", "tos_uri", "policy_uri", "logo_uri", and "client_uri" 500 might have multiple locale-specific values in some client 501 registrations to facilitate use in different locations. 503 To specify the languages and scripts, BCP47 [RFC5646] language tags 504 are added to client metadata member names, delimited by a # 505 character. Since JSON [RFC7159] member names are case sensitive, it 506 is RECOMMENDED that language tag values used in Claim Names be 507 spelled using the character case with which they are registered in 508 the IANA Language Subtag Registry [IANA.Language]. In particular, 509 normally language names are spelled with lowercase characters, region 510 names are spelled with uppercase characters, and languages are 511 spelled with mixed case characters. However, since BCP47 language 512 tag values are case insensitive, implementations SHOULD interpret the 513 language tag values supplied in a case insensitive manner. Per the 514 recommendations in BCP47, language tag values used in metadata member 515 names should only be as specific as necessary. For instance, using 516 "fr" might be sufficient in many contexts, rather than "fr-CA" or 517 "fr-FR". 519 For example, a client could represent its name in English as 520 ""client_name#en": "My Client"" and its name in Japanese as 521 ""client_name#ja-Jpan-JP": 522 "\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D"" within the same 523 registration request. The authorization server MAY display any or 524 all of these names to the resource owner during the authorization 525 step, choosing which name to display based on system configuration, 526 user preferences or other factors. 528 If any human-readable field is sent without a language tag, parties 529 using it MUST NOT make any assumptions about the language, character 530 set, or script of the string value, and the string value MUST be used 531 as-is wherever it is presented in a user interface. To facilitate 532 interoperability, it is RECOMMENDED that clients and servers use a 533 human-readable field without any language tags in addition to any 534 language-specific fields, and it is RECOMMENDED that any human- 535 readable fields sent without language tags contain values suitable 536 for display on a wide variety of systems. 538 Implementer's Note: Many JSON libraries make it possible to reference 539 members of a JSON object as members of an object construct in the 540 native programming environment of the library. However, while the 541 "#" character is a valid character inside of a JSON object's member 542 names, it is not a valid character for use in an object member name 543 in many programming environments. Therefore, implementations will 544 need to use alternative access forms for these claims. For instance, 545 in JavaScript, if one parses the JSON as follows, "var j = 546 JSON.parse(json);", then as a workaround the member "client_name#en- 547 us" can be accessed using the JavaScript syntax "j["client_name#en- 548 us"]". 550 2.3. Software Statement 552 A software statement is a JSON Web Token (JWT) [JWT] that asserts 553 metadata values about the client software as a bundle. A set of 554 claims that can be used in a software statement are defined in 555 Section 2. When presented to the authorization server as part of a 556 client registration request, the software statement MUST be digitally 557 signed or MACed using JWS [JWS] and MUST contain an "iss" (issuer) 558 claim denoting the party attesting to the claims in the software 559 statement. It is RECOMMENDED that software statements be digitally 560 signed using the "RS256" signature algorithm, although particular 561 applications MAY specify the use of different algorithms. It is 562 RECOMMENDED that software statements contain the "software_id" claim 563 to allow authorization servers to correlate different instances of 564 software using the same software statement. 566 For example, a software statement could contain the following claims: 568 { 569 "software_id": "4NRB1-0XZABZI9E6-5SM3R", 570 "client_name": "Example Statement-based Client", 571 "client_uri": "https://client.example.net/" 572 } 573 The following non-normative example JWT includes these claims and has 574 been asymmetrically signed using RS256: 576 Line breaks are for display purposes only 578 eyJhbGciOiJSUzI1NiJ9. 579 eyJzb2Z0d2FyZV9pZCI6IjROUkIxLTBYWkFCWkk5RTYtNVNNM1IiLCJjbGll 580 bnRfbmFtZSI6IkV4YW1wbGUgU3RhdGVtZW50LWJhc2VkIENsaWVudCIsImNs 581 aWVudF91cmkiOiJodHRwczovL2NsaWVudC5leGFtcGxlLm5ldC8ifQ. 582 GHfL4QNIrQwL18BSRdE595T9jbzqa06R9BT8w409x9oIcKaZo_mt15riEXHa 583 zdISUvDIZhtiyNrSHQ8K4TvqWxH6uJgcmoodZdPwmWRIEYbQDLqPNxREtYn0 584 5X3AR7ia4FRjQ2ojZjk5fJqJdQ-JcfxyhK-P8BAWBd6I2LLA77IG32xtbhxY 585 fHX7VhuU5ProJO8uvu3Ayv4XRhLZJY4yKfmyjiiKiPNe-Ia4SMy_d_QSWxsk 586 U5XIQl5Sa2YRPMbDRXttm2TfnZM1xx70DoYi8g6czz-CPGRi4SW_S2RKHIJf 587 IjoI3zTJ0Y2oe0_EJAiXbL6OyF9S5tKxDXV8JIndSA 589 The means by which a client or developer obtains a software statement 590 are outside the scope of this specification. Some common methods 591 could include a client developer generating a client-specific JWT 592 registering with a software API publisher to obtain a software 593 statement for a class of clients. The software statement is 594 typically distributed with all instances of a client application. 596 The criteria by which authorization servers determine whether to 597 trust and utilize the information in a software statement are beyond 598 the scope of this specification. 600 In some cases, authorization servers MAY choose to accept a software 601 statement value directly as a client identifier in an authorization 602 request, without a prior dynamic client registration having been 603 performed. The circumstances under which an authorization server 604 would do so, and the specific software statement characteristics 605 required in this case, are beyond the scope of this specification. 607 3. Client Registration Endpoint 609 The client registration endpoint is an OAuth 2.0 endpoint defined in 610 this document that is designed to allow a client to be registered 611 with the authorization server. The client registration endpoint MUST 612 accept HTTP POST messages with request parameters encoded in the 613 entity body using the "application/json" format. The client 614 registration endpoint MUST be protected by a transport-layer security 615 mechanism, as described in Section 5. 617 The client registration endpoint MAY be an OAuth 2.0 protected 618 resource and accept an initial access token in the form of an OAuth 619 2.0 [RFC6749] access token to limit registration to only previously 620 authorized parties. The method by which the initial access token is 621 obtained by the client or developer is generally out-of-band and is 622 out of scope for this specification. The method by which the initial 623 access token is verified and validated by the client registration 624 endpoint is out of scope for this specification. 626 To support open registration and facilitate wider interoperability, 627 the client registration endpoint SHOULD allow registration requests 628 with no authorization (which is to say, with no initial access token 629 in the request). These requests MAY be rate-limited or otherwise 630 limited to prevent a denial-of-service attack on the client 631 registration endpoint. 633 3.1. Client Registration Request 635 This operation registers a client with the authorization server. The 636 authorization server assigns this client a unique client identifier, 637 optionally assigns a client secret, and associates the metadata 638 provided in the request with the issued client identifier. The 639 request includes any client metadata parameters being specified for 640 the client during the registration. The authorization server MAY 641 provision default values for any items omitted in the client 642 metadata. 644 To register, the client or developer sends an HTTP POST to the client 645 registration endpoint with a content type of "application/json". The 646 HTTP Entity Payload is a JSON [RFC7159] document consisting of a JSON 647 object and all requested client metadata values as top-level members 648 of that JSON object. 650 For example, if the server supports open registration (with no 651 initial access token), the client could send the following 652 registration request to the client registration endpoint: 654 The following is a non-normative example request not using an initial 655 access token (with line wraps within values for display purposes 656 only): 658 POST /register HTTP/1.1 659 Content-Type: application/json 660 Accept: application/json 661 Host: server.example.com 663 { 664 "redirect_uris":[ 665 "https://client.example.org/callback", 666 "https://client.example.org/callback2"], 667 "client_name":"My Example Client", 668 "client_name#ja-Jpan-JP": 669 "\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D", 670 "token_endpoint_auth_method":"client_secret_basic", 671 "logo_uri":"https://client.example.org/logo.png", 672 "jwks_uri":"https://client.example.org/my_public_keys.jwks", 673 "example_extension_parameter": "example_value" 674 } 676 Alternatively, if the server supports authorized registration, the 677 developer or the client will be provisioned with an initial access 678 token. (The method by which the initial access token is obtained is 679 out of scope for this specification.) The developer or client sends 680 the following authorized registration request to the client 681 registration endpoint. Note that the initial access token sent in 682 this example as an OAuth 2.0 Bearer Token [RFC6750], but any OAuth 683 2.0 token type could be used by an authorization server. 685 The following is a non-normative example request using an initial 686 access token and registering a JWK set by value (with line wraps 687 within values for display purposes only): 689 POST /register HTTP/1.1 690 Content-Type: application/json 691 Accept: application/json 692 Authorization: Bearer ey23f2.adfj230.af32-developer321 693 Host: server.example.com 695 { 696 "redirect_uris":["https://client.example.org/callback", 697 "https://client.example.org/callback2"], 698 "client_name":"My Example Client", 699 "client_name#ja-Jpan-JP": 700 "\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D", 701 "token_endpoint_auth_method":"client_secret_basic", 702 "policy_uri":"https://client.example.org/policy.html", 703 "jwks":{"keys":[{ 704 "e": "AQAB", 705 "n": "nj3YJwsLUFl9BmpAbkOswCNVx17Eh9wMO-_AReZwBqfaWFcfG 706 HrZXsIV2VMCNVNU8Tpb4obUaSXcRcQ-VMsfQPJm9IzgtRdAY8NN8Xb7PEcYyk 707 lBjvTtuPbpzIaqyiUepzUXNDFuAOOkrIol3WmflPUUgMKULBN0EUd1fpOD70p 708 RM0rlp_gg_WNUKoW1V-3keYUJoXH9NztEDm_D2MQXj9eGOJJ8yPgGL8PAZMLe 709 2R7jb9TxOCPDED7tY_TU4nFPlxptw59A42mldEmViXsKQt60s1SLboazxFKve 710 qXC_jpLUt22OC6GUG63p-REw-ZOr3r845z50wMuzifQrMI9bQ", 711 "kty": "RSA" 712 }]}, 713 "example_extension_parameter": "example_value" 714 } 716 3.1.1. Client Registration Request Using a Software Statement 718 In addition to JSON elements, client metadata values MAY also be 719 provided in a software statement, as described in Section 2.3. The 720 authorization server MAY ignore the software statement if it does not 721 support this feature. If the server supports software statements, 722 client metadata values conveyed in the software statement MUST take 723 precedence over those conveyed using plain JSON elements. 725 Software statements are included in the requesting JSON object using 726 this OPTIONAL member: 728 software_statement 729 A software statement containing client metadata values about the 730 client software as claims. 732 In the following example, some registration parameters are conveyed 733 as claims in a software statement from the example in Section 2.3, 734 while some values specific to the client instance are conveyed as 735 regular parameters (with line wraps within values for display 736 purposes only): 738 POST /register HTTP/1.1 739 Content-Type: application/json 740 Accept: application/json 741 Host: server.example.com 743 { 744 "redirect_uris":[ 745 "https://client.example.org/callback", 746 "https://client.example.org/callback2" 747 ], 748 "software_statement":"eyJhbGciOiJSUzI1NiJ9. 749 eyJzb2Z0d2FyZV9pZCI6IjROUkIxLTBYWkFCWkk5RTYtNVNNM1IiLCJjbGll 750 bnRfbmFtZSI6IkV4YW1wbGUgU3RhdGVtZW50LWJhc2VkIENsaWVudCIsImNs 751 aWVudF91cmkiOiJodHRwczovL2NsaWVudC5leGFtcGxlLm5ldC8ifQ. 752 GHfL4QNIrQwL18BSRdE595T9jbzqa06R9BT8w409x9oIcKaZo_mt15riEXHa 753 zdISUvDIZhtiyNrSHQ8K4TvqWxH6uJgcmoodZdPwmWRIEYbQDLqPNxREtYn0 754 5X3AR7ia4FRjQ2ojZjk5fJqJdQ-JcfxyhK-P8BAWBd6I2LLA77IG32xtbhxY 755 fHX7VhuU5ProJO8uvu3Ayv4XRhLZJY4yKfmyjiiKiPNe-Ia4SMy_d_QSWxsk 756 U5XIQl5Sa2YRPMbDRXttm2TfnZM1xx70DoYi8g6czz-CPGRi4SW_S2RKHIJf 757 IjoI3zTJ0Y2oe0_EJAiXbL6OyF9S5tKxDXV8JIndSA", 758 "scope":"read write", 759 "example_extension_parameter":"example_value" 760 } 762 3.2. Responses 764 Upon a successful registration request, the authorization server 765 returns a client identifier for the client. The server responds with 766 an HTTP 201 Created code and a body of type "application/json" with 767 content as described in Section 3.2.1. 769 Upon an unsuccessful registration request, the authorization server 770 responds with an error, as described in Section 3.2.2. 772 3.2.1. Client Information Response 774 The response contains the client identifier as well as the client 775 secret, if the client is a confidential client. The response MAY 776 contain additional fields as specified by extensions to this 777 specification. 779 client_id 780 REQUIRED. OAuth 2.0 client identifier. It SHOULD NOT be 781 currently valid for any other registered client, though an 782 authorization server MAY issue the same client identifier to 783 multiple instances of a registered client at its discretion. 784 client_secret 785 OPTIONAL. OAuth 2.0 client secret. If issued, this MUST be 786 unique for each "client_id" and SHOULD be unique for multiple 787 instances of a client using the same "client_id". This value is 788 used by confidential clients to authenticate to the token endpoint 789 as described in OAuth 2.0 [RFC6749] Section 2.3.1. 790 client_id_issued_at 791 OPTIONAL. Time at which the client identifier was issued. The 792 time is represented as the number of seconds from 793 1970-01-01T0:0:0Z as measured in UTC until the date/time of 794 issuance. 795 client_secret_expires_at 796 REQUIRED if "client_secret" is issued. Time at which the client 797 secret will expire or 0 if it will not expire. The time is 798 represented as the number of seconds from 1970-01-01T0:0:0Z as 799 measured in UTC until the date/time of expiration. 801 Additionally, the authorization server MUST return all registered 802 metadata about this client, including any fields provisioned by the 803 authorization server itself. The authorization server MAY reject or 804 replace any of the client's requested metadata values submitted 805 during the registration and substitute them with suitable values. 807 The response is an "application/json" document with all parameters as 808 top-level members of a JSON object [RFC7159]. 810 If a software statement was used as part of the registration, its 811 value MUST be returned unmodified in the response along with other 812 metadata using the "software_statement" member name. Client metadata 813 elements used from the software statement MUST also be returned 814 directly as top-level client metadata values in the registration 815 response (possibly with different values, since the values requested 816 and the values used may differ). 818 Following is a non-normative example response: 820 HTTP/1.1 201 Created 821 Content-Type: application/json 822 Cache-Control: no-store 823 Pragma: no-cache 825 { 826 "client_id":"s6BhdRkqt3", 827 "client_secret": "cf136dc3c1fc93f31185e5885805d", 828 "client_id_issued_at":2893256800, 829 "client_secret_expires_at":2893276800, 830 "redirect_uris":[ 831 "https://client.example.org/callback", 832 "https://client.example.org/callback2"], 833 "grant_types": ["authorization_code", "refresh_token"], 834 "client_name":"My Example Client", 835 "client_name#ja-Jpan-JP": 836 "\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D", 837 "token_endpoint_auth_method":"client_secret_basic", 838 "logo_uri":"https://client.example.org/logo.png", 839 "jwks_uri":"https://client.example.org/my_public_keys.jwks", 840 "example_extension_parameter": "example_value" 841 } 843 3.2.2. Client Registration Error Response 845 When an OAuth 2.0 error condition occurs, such as the client 846 presenting an invalid initial access token, the authorization server 847 returns an error response appropriate to the OAuth 2.0 token type. 849 When a registration error condition occurs, the authorization server 850 returns an HTTP 400 status code (unless otherwise specified) with 851 content type "application/json" consisting of a JSON object [RFC7159] 852 describing the error in the response body. 854 Two members are defined for inclusion in the JSON object: 856 error 857 REQUIRED. Single ASCII error code string. 858 error_description 859 OPTIONAL. Human-readable ASCII text description of the error used 860 for debugging. 862 Other members MAY also be included, and if not understood, MUST be 863 ignored. 865 This specification defines the following error codes: 867 invalid_redirect_uri 868 The value of one or more redirection URIs is invalid. 869 invalid_client_metadata 870 The value of one of the client metadata fields is invalid and the 871 server has rejected this request. Note that an authorization 872 server MAY choose to substitute a valid value for any requested 873 parameter of a client's metadata. 874 invalid_software_statement 875 The software statement presented is invalid. 876 unapproved_software_statement 877 The software statement presented is not approved for use by this 878 authorization server. 880 Following is a non-normative example of an error response resulting 881 from a redirection URI that has been blacklisted by the authorization 882 server (with line wraps within values for display purposes only): 884 HTTP/1.1 400 Bad Request 885 Content-Type: application/json 886 Cache-Control: no-store 887 Pragma: no-cache 889 { 890 "error": "invalid_redirect_uri", 891 "error_description": "The redirection URI 892 http://sketchy.example.com is not allowed by this server." 893 } 895 Following is a non-normative example of an error response resulting 896 from an inconsistent combination of "response_types" and 897 "grant_types" values (with line wraps within values for display 898 purposes only): 900 HTTP/1.1 400 Bad Request 901 Content-Type: application/json 902 Cache-Control: no-store 903 Pragma: no-cache 905 { 906 "error": "invalid_client_metadata", 907 "error_description": "The grant type 'authorization_code' must be 908 registered along with the response type 'code' but found only 909 'implicit' instead." 910 } 912 4. IANA Considerations 914 4.1. OAuth Dynamic Registration Client Metadata Registry 916 This specification establishes the OAuth Dynamic Registration Client 917 Metadata registry. 919 OAuth registration client metadata values are registered with a 920 Specification Required ([RFC5226]) after a two-week review period on 921 the oauth-ext-review@ietf.org mailing list, on the advice of one or 922 more Designated Experts. However, to allow for the allocation of 923 values prior to publication, the Designated Expert(s) may approve 924 registration once they are satisfied that such a specification will 925 be published. 927 Registration requests must be sent to the oauth-ext-review@ietf.org 928 mailing list for review and comment, with an appropriate subject 929 (e.g., "Request to register OAuth Dynamic Registration Client 930 Metadata name: example"). 932 Within the review period, the Designated Expert(s) will either 933 approve or deny the registration request, communicating this decision 934 to the review list and IANA. Denials should include an explanation 935 and, if applicable, suggestions as to how to make the request 936 successful. 938 IANA must only accept registry updates from the Designated Expert(s) 939 and should direct all requests for registration to the review mailing 940 list. 942 4.1.1. Registration Template 944 Client Metadata Name: 945 The name requested (e.g., "example"). This name is case 946 sensitive. Names that match other registered names in a case 947 insensitive manner SHOULD NOT be accepted. 949 Client Metadata Description: 950 Brief description of the metadata value (e.g., "Example 951 description"). 953 Change controller: 954 For Standards Track RFCs, state "IESG". For others, give the name 955 of the responsible party. Other details (e.g., postal address, 956 email address, home page URI) may also be included. 958 Specification document(s): 960 Reference to the document(s) that specify the token endpoint 961 authorization method, preferably including a URI that can be used 962 to retrieve a copy of the document(s). An indication of the 963 relevant sections may also be included but is not required. 965 4.1.2. Initial Registry Contents 967 The initial contents of the OAuth Dynamic Registration Client 968 Metadata registry are: 970 o Client Metadata Name: "redirect_uris" 971 o Client Metadata Description: Array of redirection URIs for use in 972 redirect-based flows 973 o Change controller: IESG 974 o Specification document(s): [[ this document ]] 976 o Client Metadata Name: "token_endpoint_auth_method" 977 o Client Metadata Description: Requested authentication method for 978 the token endpoint 979 o Change controller: IESG 980 o Specification document(s): [[ this document ]] 982 o Client Metadata Name: "grant_types" 983 o Client Metadata Description: Array of OAuth 2.0 grant types that 984 the client may use 985 o Change controller: IESG 986 o Specification document(s): [[ this document ]] 988 o Client Metadata Name: "response_types" 989 o Client Metadata Description: Array of the OAuth 2.0 response types 990 that the client may use 991 o Change controller: IESG 992 o Specification document(s): [[ this document ]] 994 o Client Metadata Name: "client_name" 995 o Client Metadata Description: Human-readable name of the client to 996 be presented to the user 997 o Change Controller: IESG 998 o Specification Document(s): [[ this document ]] 1000 o Client Metadata Name: "client_uri" 1001 o Client Metadata Description: URL of a Web page providing 1002 information about the client 1003 o Change Controller: IESG 1004 o Specification Document(s): [[ this document ]] 1006 o Client Metadata Name: "logo_uri" 1007 o Client Metadata Description: URL that references a logo for the 1008 client 1009 o Change Controller: IESG 1010 o Specification Document(s): [[ this document ]] 1012 o Client Metadata Name: "scope" 1013 o Client Metadata Description: Space separated list of scope values 1014 o Change Controller: IESG 1015 o Specification Document(s): [[ this document ]] 1017 o Client Metadata Name: "contacts" 1018 o Client Metadata Description: Array of strings representing ways to 1019 contact people responsible for this client, typically email 1020 addresses 1021 o Change Controller: IESG 1022 o Specification document(s): [[ this document ]] 1024 o Client Metadata Name: "tos_uri" 1025 o Client Metadata Description: URL that points to a human-readable 1026 Terms of Service document for the client 1027 o Change Controller: IESG 1028 o Specification Document(s): [[ this document ]] 1030 o Client Metadata Name: "policy_uri" 1031 o Client Metadata Description: URL that points to a human-readable 1032 Policy document for the client 1033 o Change Controller: IESG 1034 o Specification Document(s): [[ this document ]] 1036 o Client Metadata Name: "jwks_uri" 1037 o Client Metadata Description: URL referencing the client's JSON Web 1038 Key Set [JWK] document representing the client's public keys 1039 o Change Controller: IESG 1040 o Specification Document(s): [[ this document ]] 1042 o Client Metadata Name: "jwks" 1043 o Client Metadata Description: Client's JSON Web Key Set [JWK] 1044 document representing the client's public keys 1045 o Change Controller: IESG 1046 o Specification Document(s): [[ this document ]] 1048 o Client Metadata Name: "software_id" 1049 o Client Metadata Description: Identifier for the software that 1050 comprises a client 1051 o Change Controller: IESG 1052 o Specification Document(s): [[ this document ]] 1054 o Client Metadata Name: "software_version" 1055 o Client Metadata Description: Version identifier for the software 1056 that comprises a client 1057 o Change Controller: IESG 1058 o Specification Document(s): [[ this document ]] 1060 o Client Metadata Name: "client_id" 1061 o Client Metadata Description: Client identifier 1062 o Change Controller: IESG 1063 o Specification Document(s): [[ this document ]] 1065 o Client Metadata Name: "client_secret" 1066 o Client Metadata Description: Client secret 1067 o Change Controller: IESG 1068 o Specification Document(s): [[ this document ]] 1070 o Client Metadata Name: "client_id_issued_at" 1071 o Client Metadata Description: Time at which the client identifier 1072 was issued 1073 o Change Controller: IESG 1074 o Specification Document(s): [[ this document ]] 1076 o Client Metadata Name: "client_secret_expires_at" 1077 o Client Metadata Description: Time at which the client secret will 1078 expire 1079 o Change Controller: IESG 1080 o Specification Document(s): [[ this document ]] 1082 4.2. OAuth Token Endpoint Authentication Methods Registry 1084 This specification establishes the OAuth Token Endpoint 1085 Authentication Methods registry. 1087 Additional values for use as "token_endpoint_auth_method" metadata 1088 values are registered with a Specification Required ([RFC5226]) after 1089 a two-week review period on the oauth-ext-review@ietf.org mailing 1090 list, on the advice of one or more Designated Experts. However, to 1091 allow for the allocation of values prior to publication, the 1092 Designated Expert(s) may approve registration once they are satisfied 1093 that such a specification will be published. 1095 Registration requests must be sent to the oauth-ext-review@ietf.org 1096 mailing list for review and comment, with an appropriate subject 1097 (e.g., "Request to register token_endpoint_auth_method value: 1098 example"). 1100 Within the review period, the Designated Expert(s) will either 1101 approve or deny the registration request, communicating this decision 1102 to the review list and IANA. Denials should include an explanation 1103 and, if applicable, suggestions as to how to make the request 1104 successful. 1106 IANA must only accept registry updates from the Designated Expert(s) 1107 and should direct all requests for registration to the review mailing 1108 list. 1110 4.2.1. Registration Template 1112 Token Endpoint Authorization Method Name: 1113 The name requested (e.g., "example"). This name is case 1114 sensitive. Names that match other registered names in a case 1115 insensitive manner SHOULD NOT be accepted. 1117 Change controller: 1118 For Standards Track RFCs, state "IESG". For others, give the name 1119 of the responsible party. Other details (e.g., postal address, 1120 email address, home page URI) may also be included. 1122 Specification document(s): 1123 Reference to the document(s) that specify the token endpoint 1124 authorization method, preferably including a URI that can be used 1125 to retrieve a copy of the document(s). An indication of the 1126 relevant sections may also be included but is not required. 1128 4.2.2. Initial Registry Contents 1130 The initial contents of the OAuth Token Endpoint Authentication 1131 Methods registry are: 1133 o Token Endpoint Authorization Method Name: "none" 1134 o Change controller: IESG 1135 o Specification document(s): [[ this document ]] 1137 o Token Endpoint Authorization Method Name: "client_secret_post" 1138 o Change controller: IESG 1139 o Specification document(s): [[ this document ]] 1141 o Token Endpoint Authorization Method Name: "client_secret_basic" 1142 o Change controller: IESG 1143 o Specification document(s): [[ this document ]] 1145 5. Security Considerations 1147 Since requests to the client registration endpoint result in the 1148 transmission of clear-text credentials (in the HTTP request and 1149 response), the authorization server MUST require the use of a 1150 transport-layer security mechanism when sending requests to the 1151 registration endpoint. The server MUST support TLS 1.2 RFC 5246 1152 [RFC5246] and MAY support additional transport-layer mechanisms 1153 meeting its security requirements. When using TLS, the client MUST 1154 perform a TLS/SSL server certificate check, per RFC 6125 [RFC6125]. 1155 Implementation security considerations can be found in 1156 Recommendations for Secure Use of TLS and DTLS 1157 [I-D.ietf-uta-tls-bcp]. 1159 For clients that use redirect-based grant types such as 1160 "authorization_code" and "implicit", authorization servers MUST 1161 require clients to register their redirection URI values. This can 1162 help mitigate attacks where rogue actors inject and impersonate a 1163 validly registered client and intercept its authorization code or 1164 tokens through an invalid redirection URI or open redirector. 1165 Additionally, in order to prevent hijacking of the return values of 1166 the redirection, registered redirection URI values MUST be one of: 1168 o A remote web site protected by TLS (e.g., 1169 https://client.example.com/oauth_redirect) 1170 o A web site hosted on the local machine using an HTTP URI (e.g., 1171 http://localhost:8080/oauth_redirect) 1172 o A non-HTTP application-specific URL that is available only to the 1173 client application (e.g., exampleapp://oauth_redirect) 1175 Public clients MAY register with an authorization server using this 1176 protocol, if the authorization server's policy allows them. Public 1177 clients use a "none" value for the "token_endpoint_auth_method" 1178 metadata field and are generally used with the "implicit" grant type. 1179 Often these clients will be short-lived in-browser applications 1180 requesting access to a user's resources and access is tied to a 1181 user's active session at the authorization server. Since such 1182 clients often do not have long-term storage, it's possible that such 1183 clients would need to re-register every time the browser application 1184 is loaded. Additionally, such clients may not have ample opportunity 1185 to unregister themselves using the delete action before the browser 1186 closes. To avoid the resulting proliferation of dead client 1187 identifiers, an authorization server MAY decide to expire 1188 registrations for existing clients meeting certain criteria after a 1189 period of time has elapsed. 1191 Since different OAuth 2.0 grant types have different security and 1192 usage parameters, an authorization server MAY require separate 1193 registrations for a piece of software to support multiple grant 1194 types. For instance, an authorization server might require that all 1195 clients using the "authorization_code" grant type make use of a 1196 client secret for the "token_endpoint_auth_method", but any clients 1197 using the "implicit" grant type do not use any authentication at the 1198 token endpoint. In such a situation, a server MAY disallow clients 1199 from registering for both the "authorization_code" and "implicit" 1200 grant types simultaneously. Similarly, the "authorization_code" 1201 grant type is used to represent access on behalf of an end-user, but 1202 the "client_credentials" grant type represents access on behalf of 1203 the client itself. For security reasons, an authorization server 1204 could require that different scopes be used for these different use 1205 cases, and as a consequence it MAY disallow these two grant types 1206 from being registered together by the same client. In all of these 1207 cases, the authorization server would respond with an 1208 "invalid_client_metadata" error response. 1210 Unless used as a claim in a software statement, the authorization 1211 server MUST treat all client metadata as self-asserted. For 1212 instance, a rogue client might use the name and logo of a legitimate 1213 client that it is trying to impersonate. Additionally, a rogue 1214 client might try to use the software identifier or software version 1215 of a legitimate client to attempt to associate itself on the 1216 authorization server with instances of the legitimate client. To 1217 counteract this, an authorization server needs to take steps to 1218 mitigate this risk by looking at the entire registration request and 1219 client configuration. For instance, an authorization server could 1220 issue a warning if the domain/site of the logo doesn't match the 1221 domain/site of redirection URIs. An authorization server could also 1222 refuse registration requests from a known software identifier that is 1223 requesting different redirection URIs or a different client URI. An 1224 authorization server can also present warning messages to end-users 1225 about dynamically registered clients in all cases, especially if such 1226 clients have been recently registered or have not been trusted by any 1227 users at the authorization server before. 1229 In a situation where the authorization server is supporting open 1230 client registration, it must be extremely careful with any URL 1231 provided by the client that will be displayed to the user (e.g. 1232 "logo_uri", "tos_uri", "client_uri", and "policy_uri"). For 1233 instance, a rogue client could specify a registration request with a 1234 reference to a drive-by download in the "policy_uri". The 1235 authorization server SHOULD check to see if the "logo_uri", 1236 "tos_uri", "client_uri", and "policy_uri" have the same host and 1237 scheme as the those defined in the array of "redirect_uris" and that 1238 all of these URIs resolve to valid web pages. 1240 Clients MAY use both the direct JSON object and the JWT-encoded 1241 software statement to present client metadata to the authorization 1242 server as part of the registration request. A software statement is 1243 cryptographically protected and represents claims made by the issuer 1244 of the statement, while the JSON object represents the self-asserted 1245 claims made by the client or developer directly. If the software 1246 statement is valid and signed by an acceptable authority (such as the 1247 software API publisher), the values of client metadata within the 1248 software statement MUST take precedence over those metadata values 1249 presented in the plain JSON object, which could have been modified en 1250 route. 1252 The software statement is an item that is self-asserted by the 1253 client, even though its contents have been digitally signed or MACed 1254 by the issuer of the software statement. As such, presentation of 1255 the software statement is not sufficient in most cases to fully 1256 identity a piece of client software. An initial access token, in 1257 contrast, does not necessarily contain information about a particular 1258 piece of client software but instead represents authorization to use 1259 the registration endpoint. An authorization server MUST consider the 1260 full registration request, including the software statement, initial 1261 access token, and JSON client metadata values, when deciding whether 1262 to honor a given registration request. 1264 If an authorization server receives a registration request for a 1265 client that uses the same "software_id" and "software_version" values 1266 as another client, the server should treat the new registration as 1267 being suspect. It is possible that the new client is trying to 1268 impersonate the existing client. 1270 Since a client identifier is a public value that can be used to 1271 impersonate a client at the authorization endpoint, an authorization 1272 server that decides to issue the same client identifier to multiple 1273 instances of a registered client needs to be very particular about 1274 the circumstances under which this occurs. For instance, the 1275 authorization server can limit a given client identifier to clients 1276 using the same redirect-based flow and the same redirection URIs. An 1277 authorization server SHOULD NOT issue the same client secret to 1278 multiple instances of a registered client, even if they are issued 1279 the same client identifier, or else the client secret could be 1280 leaked, allowing malicious impostors to impersonate a confidential 1281 client. 1283 6. Privacy Considerations 1285 As the protocol described in this specification deals almost 1286 exclusively with information about software and not about people, 1287 there are very few privacy concerns for its use. The notable 1288 exception is the "contacts" field as defined in Client Metadata 1289 (Section 2), which contains contact information for the developers or 1290 other parties responsible for the client software. These values are 1291 intended to be displayed to end-users and will be available to the 1292 administrators of the authorization server. As such, the developer 1293 may wish to provide an email address or other contact information 1294 expressly dedicated to the purpose of supporting the client instead 1295 of using their personal or professional addresses. Alternatively, 1296 the developer may wish to provide a collective email address for the 1297 client to allow for continuing contact and support of the client 1298 software after the developer moves on and someone else takes over 1299 that responsibility. 1301 In general, the metadata for a client, such as the client name and 1302 software identifier, are common across all instances of a piece of 1303 client software and therefore pose no privacy issues for end-users. 1304 Client identifiers, on the other hand, are often unique to a specific 1305 instance of a client. For clients such as web sites that are used by 1306 many users, there may not be significant privacy concerns regarding 1307 the client identifier, but for clients such as native applications 1308 that are installed on a single end-user's device, the client 1309 identifier could be uniquely tracked during OAuth 2.0 transactions 1310 and its use tied to that single end-user. However, as the client 1311 software still needs to be authorized by a resource owner through an 1312 OAuth 2.0 authorization grant, this type of tracking can occur 1313 whether or not the client identifier is unique by correlating the 1314 authenticated resource owner with the requesting client identifier. 1316 Note that clients are forbidden by this specification from creating 1317 their own client identifier. If the client were able to do so, an 1318 individual client instance could be tracked across multiple colluding 1319 authorization servers, leading to privacy and security issues. 1320 Additionally, client identifiers are generally issued uniquely per 1321 registration request, even for the same instance of software. In 1322 this way, an application could marginally improve privacy by 1323 registering multiple times and appearing to be completely separate 1324 applications. However, this technique does incur significant 1325 usability cost in the form of requiring multiple authorizations per 1326 resource owner and is therefore unlikely to be used in practice. 1328 7. References 1330 7.1. Normative References 1332 [IANA.Language] 1333 Internet Assigned Numbers Authority (IANA), "Language 1334 Subtag Registry", 2005. 1336 [JWK] Jones, M., "JSON Web Key (JWK)", draft-ietf-jose-json-web- 1337 key (work in progress), January 2015. 1339 [JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 1340 Signature (JWS)", draft-ietf-jose-json-web-signature (work 1341 in progress), January 2015. 1343 [JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 1344 (JWT)", draft-ietf-oauth-json-web-token (work in 1345 progress), January 2015. 1347 [OAuth.JWT] 1348 Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token 1349 (JWT) Profile for OAuth 2.0 Client Authentication and 1350 Authorization Grants", draft-ietf-oauth-jwt-bearer (work 1351 in progress), November 2015. 1353 [OAuth.SAML2] 1354 Campbell, B., Mortimore, C., and M. Jones, "SAML 2.0 1355 Profile for OAuth 2.0 Client Authentication and 1356 Authorization Grants", draft-ietf-oauth-saml2-bearer (work 1357 in progress), November 2015. 1359 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1360 Requirement Levels", BCP 14, RFC 2119, March 1997. 1362 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1363 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1364 May 2008. 1366 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1367 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1369 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying 1370 Languages", BCP 47, RFC 5646, September 2009. 1372 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1373 Verification of Domain-Based Application Service Identity 1374 within Internet Public Key Infrastructure Using X.509 1375 (PKIX) Certificates in the Context of Transport Layer 1376 Security (TLS)", RFC 6125, March 2011. 1378 [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 1379 6749, October 2012. 1381 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 1382 Framework: Bearer Token Usage", RFC 6750, October 2012. 1384 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 1385 Interchange Format", RFC 7159, March 2014. 1387 7.2. Informative References 1389 [I-D.hardjono-oauth-umacore] 1390 Hardjono, T., "User-Managed Access (UMA) Profile of OAuth 1391 2.0", draft-hardjono-oauth-umacore-10 (work in progress), 1392 July 2014. 1394 [I-D.ietf-uta-tls-bcp] 1395 Sheffer, Y., Holz, R., and P. Saint-Andre, 1396 "Recommendations for Secure Use of TLS and DTLS", draft- 1397 ietf-uta-tls-bcp-09 (work in progress), February 2015. 1399 [OAuth.Registration.Management] 1400 Richer, J., Jones, M., Bradley, J., and M. Machulak, 1401 "OAuth 2.0 Dynamic Client Registration Management 1402 Protocol", draft-ietf-oauth-dyn-reg-management (work in 1403 progress), February 2015. 1405 [OpenID.Registration] 1406 Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect 1407 Dynamic Client Registration 1.0", November 2014. 1409 Appendix A. Use Cases 1411 This appendix describes different ways that this specification can be 1412 utilized, including describing some of the choices that may need to 1413 be made. Some of the choices are independent and can be used in 1414 combination, whereas some of the choices are interrelated. 1416 A.1. Open versus Protected Dynamic Client Registration 1418 A.1.1. Open Dynamic Client Registration 1420 Authorization servers that support open registration allow 1421 registrations to be made with no initial access token. This allows 1422 all client software to register with the authorization server. 1424 A.1.2. Protected Dynamic Client Registration 1426 Authorization servers that support protected registration require 1427 that an initial access token be used when making registration 1428 requests. While the method by which a client or developer receives 1429 this initial access token and the method by which the authorization 1430 server validates this initial access token are out of scope for this 1431 specification, a common approach is for the developer to use a manual 1432 pre-registration portal at the authorization server that issues an 1433 initial access token to the developer. 1435 A.2. Registration Without or With Software Statements 1437 A.2.1. Registration Without a Software Statement 1439 When a software statement is not used in the registration request, 1440 the authorization server must be willing to use client metadata 1441 values without them being digitally signed or MACed (and thereby 1442 attested to) by any authority. (Note that this choice is independent 1443 of the Open versus Protected choice, and that an initial access token 1444 is another possible form of attestation.) 1446 A.2.2. Registration With a Software Statement 1448 A software statement can be used in a registration request to provide 1449 attestation by an authority for a set of client metadata values. 1450 This can be useful when the authorization server wants to restrict 1451 registration to client software attested to by a set of authorities 1452 or when it wants to know that multiple registration requests refer to 1453 the same piece of client software. 1455 A.3. Registration by the Client or Developer 1457 A.3.1. Registration by the Client 1459 In some use cases, client software will dynamically register itself 1460 with an authorization server to obtain a client identifier and other 1461 information needed to interact with the authorization server. In 1462 this case, no client identifier for the authorization server is 1463 packaged with the client software. 1465 A.3.2. Registration by the Developer 1467 In some cases, the developer (or development software being used by 1468 the developer) will pre-register the client software with the 1469 authorization server or a set of authorization servers. In this 1470 case, the client identifier value(s) for the authorization server(s) 1471 can be packaged with the client software. 1473 A.4. Client ID per Client Instance or per Client Software 1475 A.4.1. Client ID per Client Software Instance 1477 In some cases, each deployed instance of a piece of client software 1478 will dynamically register and obtain distinct client identifier 1479 values. This can be advantageous, for instance, if the code flow is 1480 being used, as it also enables each client instance to have its own 1481 client secret. This can be useful for native clients, which cannot 1482 maintain the secrecy of a client secret value packaged with the 1483 software, but which may be able to maintain the secrecy of a per- 1484 instance client secret. 1486 A.4.2. Client ID Shared Among All Instances of Client Software 1488 In some cases, each deployed instance of a piece of client software 1489 will share a common client identifier value. For instance, this is 1490 often the case for in-browser clients using the implicit flow, when 1491 no client secret is involved. Particular authorization servers might 1492 choose, for instance, to maintain a mapping between software 1493 statement values and client identifier values, and return the same 1494 client identifier value for all registration requests for a 1495 particular piece of software. The circumstances under which an 1496 authorization server would do so, and the specific software statement 1497 characteristics required in this case, are beyond the scope of this 1498 specification. 1500 A.5. Stateful or Stateless Registration 1502 A.5.1. Stateful Client Registration 1504 In some cases, authorization servers will maintain state about 1505 registered clients, typically indexing this state using the client 1506 identifier value. This state would typically include the client 1507 metadata values associated with the client registration, and possibly 1508 other state specific to the authorization server's implementation. 1509 When stateful registration is used, operations to support retrieving 1510 and/or updating this state may be supported. One possible set of 1511 operations upon stateful registrations is described in the 1512 [OAuth.Registration.Management] specification. 1514 A.5.2. Stateless Client Registration 1516 In some cases, authorization servers will be implemented in a manner 1517 the enables them to not maintain any local state about registered 1518 clients. One means of doing this is to encode all the registration 1519 state in the returned client identifier value, and possibly 1520 encrypting the state to the authorization server to maintain the 1521 confidentiality and integrity of the state. 1523 Appendix B. Acknowledgments 1525 The authors thank the OAuth Working Group, the User-Managed Access 1526 Working Group, and the OpenID Connect Working Group participants for 1527 their input to this document. In particular, the following 1528 individuals have been instrumental in their review and contribution 1529 to various versions of this document: Amanda Anganes, Derek Atkins, 1530 Tim Bray, Domenico Catalano, Donald Coffin, Vladimir Dzhuvinov, 1531 George Fletcher, Thomas Hardjono, Phil Hunt, William Kim, Torsten 1532 Lodderstedt, Eve Maler, Josh Mandel, Nov Matake, Tony Nadalin, Nat 1533 Sakimura, Christian Scholz, and Hannes Tschofenig. 1535 Appendix C. Document History 1537 [[ to be removed by the RFC editor before publication as an RFC ]] 1539 -24 1541 o Clarified some party definitions. 1542 o Clarified the opaqueness of software_id and software_statement. 1543 o Created a forward pointer to the Security Considerations section 1544 for TLS requirements on the registration endpoint. 1545 o Added a forward pointer to the Privacy Considerations section for 1546 the contacts field. 1547 o Wrote privacy considerations about client_id tracking. 1549 -23 1551 o Updated author information. 1553 -22 1555 o Reorganized registration response sections. 1556 o Addressed shepherd comments. 1557 o Added concrete JWK set to example. 1559 -21 1561 o Applied minor editorial fixes. 1562 o Added software statement examples. 1563 o Moved software statement request details to sub-section. 1564 o Clarified that a server MAY ignore the software statement (just as 1565 it MAY ignore other metadata values). 1566 o Removed TLS 1.0. 1567 o Added privacy considerations around "contacts" field. 1568 o Marked software_id as RECOMMENDED inside of a software statement. 1570 -20 1572 o Applied minor editorial fixes from working group comments. 1574 -19 1576 o Added informative references to the OpenID Connect Dynamic Client 1577 Registration and UMA specifications in the introduction. 1579 o Clarified the "jwks" and "jwks_uri" descriptions and included an 1580 example situation in which they might be used. 1581 o Removed "application_type". 1582 o Added redirection URI usage restrictions to the Security 1583 Considerations section, based on the client type. 1584 o Expanded the "tos_uri" and "policy_uri" descriptions. 1586 -18 1588 o Corrected an example HTTP response status code to be 201 Created. 1589 o Said more about who issues and uses initial access tokens and 1590 software statements. 1591 o Stated that the use of an initial access token is required when 1592 the authorization server limits the parties that can register a 1593 client. 1594 o Stated that the implementation and use of all client metadata 1595 fields is OPTIONAL, other than "redirect_uris", which MUST be used 1596 for redirect-based flows and implemented to fulfill the 1597 requirement in Section 2 of OAuth 2.0. 1598 o Added the "application_type" metadata value, which had somehow 1599 been omitted. 1600 o Added missing default metadata values, which had somehow been 1601 omitted. 1602 o Clarified that the "software_id" is ultimately asserted by the 1603 client developer. 1604 o Clarified that the "error" member is required in error responses, 1605 "error_description" member is optional, and other members may be 1606 present. 1607 o Added security consideration about registrations with duplicate 1608 "software_id" and "software_version" values. 1610 -17 1612 o Merged draft-ietf-oauth-dyn-reg-metadata back into this document. 1613 o Removed "Core" from the document title. 1614 o Explicitly state that all metadata members are optional. 1615 o Clarified language around software statements for use in 1616 registration context. 1617 o Clarified that software statements need to be digitally signed or 1618 MACed. 1619 o Added a "jwks" metadata parameter to parallel the "jwks_uri" 1620 parameter. 1621 o Removed normative language from terminology. 1622 o Expanded abstract and introduction. 1623 o Addressed review comments from several working group members. 1625 -16 1626 o Replaced references to draft-jones-oauth-dyn-reg-metadata and 1627 draft-jones-oauth-dyn-reg-management with draft-ietf-oauth-dyn- 1628 reg-metadata and draft-ietf-oauth-dyn-reg-management. 1629 o Addressed review comments by Phil Hunt and Tony Nadalin. 1631 -15 1633 o Partitioned the Dynamic Client Registration specification into 1634 core, metadata, and management specifications. This built on work 1635 first published as draft-richer-oauth-dyn-reg-core-00 and draft- 1636 richer-oauth-dyn-reg-management-00. 1637 o Added the ability to use Software Statements. This built on work 1638 first published as draft-hunt-oauth-software-statement-00 and 1639 draft-hunt-oauth-client-association-00. 1640 o Created the IANA OAuth Registration Client Metadata registry for 1641 registering Client Metadata values. 1642 o Defined Client Instance term and stated that multiple instances 1643 can use the same client identifier value under certain 1644 circumstances. 1645 o Rewrote the introduction. 1646 o Rewrote the Use Cases appendix. 1648 -14 1650 o Added software_id and software_version metadata fields 1651 o Added direct references to RFC6750 errors in read/update/delete 1652 methods 1654 -13 1656 o Fixed broken example text in registration request and in delete 1657 request 1658 o Added security discussion of separating clients of different grant 1659 types 1660 o Fixed error reference to point to RFC6750 instead of RFC6749 1661 o Clarified that servers must respond to all requests to 1662 configuration endpoint, even if it's just an error code 1663 o Lowercased all Terms to conform to style used in RFC6750 1665 -12 1667 o Improved definition of Initial Access Token 1668 o Changed developer registration scenario to have the Initial Access 1669 Token gotten through a normal OAuth 2.0 flow 1670 o Moved non-normative client lifecycle examples to appendix 1671 o Marked differentiating between auth servers as out of scope 1672 o Added protocol flow diagram 1673 o Added credential rotation discussion 1674 o Called out Client Registration Endpoint as an OAuth 2.0 Protected 1675 Resource 1676 o Cleaned up several pieces of text 1678 -11 1680 o Added localized text to registration request and response 1681 examples. 1682 o Removed "client_secret_jwt" and "private_key_jwt". 1683 o Clarified "tos_uri" and "policy_uri" definitions. 1684 o Added the OAuth Token Endpoint Authentication Methods registry for 1685 registering "token_endpoint_auth_method" metadata values. 1686 o Removed uses of non-ASCII characters, per RFC formatting rules. 1687 o Changed "expires_at" to "client_secret_expires_at" and "issued_at" 1688 to "client_id_issued_at" for greater clarity. 1689 o Added explanatory text for different credentials (Initial Access 1690 Token, Registration Access Token, Client Credentials) and what 1691 they're used for. 1692 o Added Client Lifecycle discussion and examples. 1693 o Defined Initial Access Token in Terminology section. 1695 -10 1697 o Added language to point out that scope values are service-specific 1698 o Clarified normative language around client metadata 1699 o Added extensibility to token_endpoint_auth_method using absolute 1700 URIs 1701 o Added security consideration about registering redirect URIs 1702 o Changed erroneous 403 responses to 401's with notes about token 1703 handling 1704 o Added example for initial registration credential 1706 -09 1708 o Added method of internationalization for Client Metadata values 1709 o Fixed SAML reference 1711 -08 1713 o Collapsed jwk_uri, jwk_encryption_uri, x509_uri, and 1714 x509_encryption_uri into a single jwks_uri parameter 1715 o Renamed grant_type to grant_types since it's a plural value 1716 o Formalized name of "OAuth 2.0" throughout document 1717 o Added JWT Bearer Assertion and SAML 2 Bearer Assertion to example 1718 grant types 1719 o Added response_types parameter and explanatory text on its use 1720 with and relationship to grant_types 1722 -07 1724 o Changed registration_access_url to registration_client_uri 1725 o Fixed missing text in 5.1 1726 o Added Pragma: no-cache to examples 1727 o Changed "no such client" error to 403 1728 o Renamed Client Registration Access Endpoint to Client 1729 Configuration Endpoint 1730 o Changed all the parameter names containing "_url" to instead use 1731 "_uri" 1732 o Updated example text for forming Client Configuration Endpoint URL 1734 -06 1736 o Removed secret_rotation as a client-initiated action, including 1737 removing client secret rotation endpoint and parameters. 1738 o Changed _links structure to single value registration_access_url. 1739 o Collapsed create/update/read responses into client info response. 1740 o Changed return code of create action to 201. 1741 o Added section to describe suggested generation and composition of 1742 Client Registration Access URL. 1743 o Added clarifying text to PUT and POST requests to specify JSON in 1744 the body. 1745 o Added Editor's Note to DELETE operation about its inclusion. 1746 o Added Editor's Note to registration_access_url about alternate 1747 syntax proposals. 1749 -05 1751 o changed redirect_uri and contact to lists instead of space 1752 delimited strings 1753 o removed operation parameter 1754 o added _links structure 1755 o made client update management more RESTful 1756 o split endpoint into three parts 1757 o changed input to JSON from form-encoded 1758 o added READ and DELETE operations 1759 o removed Requirements section 1760 o changed token_endpoint_auth_type back to 1761 token_endpoint_auth_method to match OIDC who changed to match us 1763 -04 1765 o removed default_acr, too undefined in the general OAuth2 case 1766 o removed default_max_auth_age, since there's no mechanism for 1767 supplying a non-default max_auth_age in OAuth2 1768 o clarified signing and encryption URLs 1769 o changed token_endpoint_auth_method to token_endpoint_auth_type to 1770 match OIDC 1772 -03 1774 o added scope and grant_type claims 1775 o fixed various typos and changed wording for better clarity 1776 o endpoint now returns the full set of client information 1777 o operations on client_update allow for three actions on metadata: 1778 leave existing value, clear existing value, replace existing value 1779 with new value 1781 -02 1783 o Reorganized contributors and references 1784 o Moved OAuth references to RFC 1785 o Reorganized model/protocol sections for clarity 1786 o Changed terminology to "client register" instead of "client 1787 associate" 1788 o Specified that client_id must match across all subsequent requests 1789 o Fixed RFC2XML formatting, especially on lists 1791 -01 1793 o Merged UMA and OpenID Connect registrations into a single document 1794 o Changed to form-parameter inputs to endpoint 1795 o Removed pull-based registration 1797 -00 1799 o Imported original UMA draft specification 1801 Authors' Addresses 1803 Justin Richer (editor) 1805 Email: ietf@justin.richer.org 1807 Michael B. Jones 1808 Microsoft 1810 Email: mbj@microsoft.com 1811 URI: http://self-issued.info/ 1812 John Bradley 1813 Ping Identity 1815 Email: ve7jtb@ve7jtb.com 1817 Maciej Machulak 1818 Newcastle University 1820 Email: m.p.machulak@ncl.ac.uk 1821 URI: http://ncl.ac.uk/ 1823 Phil Hunt 1824 Oracle Corporation 1826 Email: phil.hunt@yahoo.com