idnits 2.17.1 draft-hunt-oauth-client-association-00.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 exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Clients that are unable to retain a client credential for the life of the client instance MAY NOT register and should continue to be treated as Public clients as defined by OAuth 2.0. -- The document date (September 27, 2013) is 3863 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) == Unused Reference: 'I-D.ietf-jose-json-web-key' is defined on line 659, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-oauth-assertions' is defined on line 663, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-oauth-saml2-bearer' is defined on line 675, but no explicit reference was found in the text == Unused Reference: 'RFC2246' is defined on line 688, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 694, but no explicit reference was found in the text == Unused Reference: 'RFC5246' is defined on line 698, but no explicit reference was found in the text == Unused Reference: 'RFC5646' is defined on line 701, but no explicit reference was found in the text == Unused Reference: 'RFC6125' is defined on line 704, but no explicit reference was found in the text == Outdated reference: A later version (-41) exists of draft-ietf-jose-json-web-key-14 == Outdated reference: A later version (-18) exists of draft-ietf-oauth-assertions-12 == Outdated reference: A later version (-12) exists of draft-ietf-oauth-jwt-bearer-06 == Outdated reference: A later version (-23) exists of draft-ietf-oauth-saml2-bearer-17 ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) ** 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) Summary: 5 errors (**), 0 flaws (~~), 16 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OAuth P. Hunt, Ed. 3 Internet-Draft Oracle Corporation 4 Intended status: Standards Track T. Nadalin 5 Expires: March 31, 2014 Microsoft 6 September 27, 2013 8 OAuth Client Association 9 draft-hunt-oauth-client-association-00 11 Abstract 13 This specification defines methods that OAuth clients may use to 14 associate (register) with service providers for the purposes of 15 accessing OAuth protected resources. The document describes 16 different classifications of OAuth clients and the process to 17 directly access or associate for access with a particular OAuth 18 Framework protected service provider. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on March 31, 2014. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 56 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Client Association Lifecycle . . . . . . . . . . . . . . . . 4 58 3. Client Association . . . . . . . . . . . . . . . . . . . . . 6 59 3.1. Static Association Clients . . . . . . . . . . . . . . . 6 60 3.2. Dynamic Association Clients . . . . . . . . . . . . . . . 7 61 3.2.1. Registration Request . . . . . . . . . . . . . . . . 7 62 3.2.2. Association Processing . . . . . . . . . . . . . . . 9 63 3.2.3. Successful Association Response . . . . . . . . . . . 9 64 3.2.4. Error Responses . . . . . . . . . . . . . . . . . . . 11 65 3.3. Transient Association . . . . . . . . . . . . . . . . . . 12 66 3.4. Client Disassociation . . . . . . . . . . . . . . . . . . 13 67 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 69 6. Normative References . . . . . . . . . . . . . . . . . . . . 14 70 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 16 71 Appendix B. Document History . . . . . . . . . . . . . . . . . . 16 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 74 1. Introduction 76 The OAuth 2.0 Authorization Framework [RFC6749] is a framework by 77 which client applications use access tokens issued by authorization 78 servers to access to a service provider's software API endpoints. As 79 a framework, OAuth 2.0 enables many different flows by which a client 80 application may obtain an access token including delegated 81 authorization from a user. 83 The OAuth Authorization Framework defines only two types of clients: 84 public and confidential. Public clients have client_id's issued once 85 where each instance shares the same client_id and are usually native 86 applications. Confidential clients typically have a unique client_id 87 per instance and typically deployed in secure environments on web 88 application platforms. In both cases, OAuth has limited support for 89 building applications that are intended to work with multiple 90 deployments that are not known at compilation or software packaging 91 time. 93 This specification defines a taxonomy of clients, and the methods by 94 which a client instance may either register with, or directly request 95 tokens from, an OAuth endpoint. The generic term for how client 96 instances work with a new OAuth endpoint is "association". This 97 specification defines 3 types of association: 99 Static Are clients that are built to work with one or more 100 endpoint(s) that are known at the time the client 101 applicaiton is built. A "client_id" and any associated 102 credentials are typically issued to the developer. 103 Multiple instances of the same client share the same 104 client_id. The determination for "public" vs. 105 "confidential" client is as per Section 2.1 [RFC6749]. 107 Dynamic Are clients that associate with one or more endpoints 108 triggered by application based workflows, configuration or 109 installation events. Associations may be temporary or be 110 extended over a long period of time. A "client_id" is 111 issued at association time along with a token based client 112 credential and an optional client referesh token that 113 enables registration updates and client token rotation. 114 Clients that associate dynamically and are issued 115 individual "client_id" are considered "confidential" as 116 defined in Section 2.1 [RFC6749]. 118 Transient Are clients that associate with one or more endpoints 119 triggered by application based events or workflows. These 120 clients typically use the OAuth "Implicit" grant per 121 Section 4.2 of [RFC6749] and as such do not require an 122 instance specific "client_id" or a client credential. 123 These associations typically exist for the life of an 124 access token and may only last for seconds or minutes. 125 These clients use a client asserted client_id and are 126 considered public as defined in Section 2.1 [RFC6749]. 128 This draft defines how software statements 129 [I-D.draft-hunt-oauth-software-statement] can be used to associate 130 dynamic and transient clients with OAuth protected service providers. 132 1.1. Notational Conventions 134 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 135 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this 136 document are to be interpreted as described in [RFC2119]. 138 Unless otherwise noted, all the protocol parameter names and values 139 are case sensitive. 141 1.2. Terminology 143 This specification uses the terms "Access Token", "Refresh Token", 144 "Authorization Code", "Authorization Grant", "Authorization Server", 145 "Authorization Endpoint", "Client", "Public Client", "Confidential 146 Client", "Client Identifier", "Client Secret", "Protected Resource", 147 "Resource Owner", "Resource Server", and "Token Endpoint" defined by 148 OAuth 2.0 [RFC6749]. 150 This specification uses the terms "Deployment Organization", 151 "Software API Deployment", "Software API Publisher", "Client 152 Developer", and "Software Statement" as defined in 153 [I-D.draft-hunt-oauth-software-statement]. 155 This specification defines the following additional terms: 157 Client Resource Endpoint An optional OAuth 2.0 protected resource 158 endpoint through which registration information for a registered 159 client can be accessed and optionally managed. The API 160 definition is out of scope of this specification. 162 Initial Access Token An OAuth 2.0 access token is typically issued 163 by a software API deployment's security domain and used by a 164 dynamic client a to associate a client for use with a particular 165 software API deployment. The token is usually issued by the same 166 security domain as the Service API the client is registering for. 167 The content, structure, generation, and validation of this token 168 are out of scope for this specification. 170 Client Refresh Credential A client refresh token is an optional 171 credential token a client may use for the purpose of supporting 172 server or client initiated rotation of client credentials. If 173 client credentials are revoked or expired, the registered client 174 may use the client refresh token to refresh its registration and 175 obtain new client credentials. 177 2. Client Association Lifecycle 179 This specification defines an association lifecycle that registers a 180 client for one target resource API per "association". Clients that 181 need to register for more than one resource API should typically make 182 a separate registration request for each API being registered. 184 The abstract association flow illustrated in Figure 1 describes the 185 relationship and interaction between a software API publisher, a 186 client developer, a deployed client software instance and the 187 software API deployment registration services in this specification. 188 This figure does not demonstrate error conditions. 190 Client App 191 Developer 192 O (A) Obtain Software Statement **************** 193 \|/ <-------------------------------------- * Software API * 194 | * Publisher * 195 / \ **************** 196 | 197 | | 198 | | 199 |D S | A 200 |i o | p 201 |s f | p 202 |t t | r (B) 203 A |r w | o 204 p |i a | v 205 p |b r | a 206 |u e | l 207 |t | 208 |i | 209 |o | 210 |n *************|******** 211 v * v * 212 +------------+ * +---------------+ * 213 | Client App | (C) Client Association & Authz * | OAuth 2.0 | * 214 | Instance | --------------------------------->| Authorization | * 215 +------------+ * | Server | * 216 * +---------------+ * 217 * OAuth 2.0 aware * 218 * Service Provider * 219 ********************** 220 Legend: 221 O 222 \|/ - Developer 223 | 224 / \ 226 +----+ 227 | | - Piece of software 228 | | 229 +----+ 231 ****** 232 * * - Organization 233 * * 234 ****** 236 Figure 1: Client Lifecycle 238 (A) The client developer packages the client software with the signed 239 software statement and distributes the client application. Local 240 distributions may also be produced that include an initial 241 registration token designed for use within a specific deployment 242 domain. The method for doing this is out-of-scope of this 243 specification. 245 (B) Upon receiving, or becoming aware of, a client application 246 software distribution, an administrator configures administrative 247 policy to accept or reject a particular client software statement 248 within a deploying organization. Additionally an administrator 249 may configure broader policy that accepts software by name, 250 author, or signing organization. An administrator might also 251 pre-approve client software by automatically accepting software 252 statements from a particular signer or other category that can be 253 derived from a software statement. As part of the approval, an 254 initial registration token may be generated for use with a local 255 distribution of the client software (step A). 257 (C) To associate with a new OAuth provider, dynamic clients present a 258 software statement, deployment specific parameters, and an 259 optional initial registration token with a "grant_type" of 260 "urn:ietf:params:oauth:grant-type:client-assoc". The 261 authorization server MAY provide a client resource endpoint URL 262 that Clients MAY use to access or update their registration. 263 Clients wishing to rotate client credentials follow the same 264 process except they use the client refresh token as their 265 registration token. 267 Transient clients MAY perform implicit authorization requests 268 (per section 4.2 of [RFC6749]) by submitting their software 269 statement as the client identifier ("client_id"). Upon receiving 270 an access token, transient client MAY then make normal resource 271 requests. 273 3. Client Association 275 This section defines 3 types of client association and the process by 276 which each client type associates with a software API deployment. 278 3.1. Static Association Clients 280 Clients that are written for a specific set of endpoints and do not 281 require installation or runtime association are known as 'static 282 clients'. These clients typically have a "client_id"(s) and client 283 credential(s) acceptable to the deployment endpoint(s) that are 284 integrated with the application at compilation or packaging time. 285 The process for how this is performed is out of scope of this 286 specification. These clients SHOULD work using the normal OAuth2 287 Framework calls [RFC6749]. 289 3.2. Dynamic Association Clients 291 Dynamic association defines 3 types of transactions to support the 292 life-cycle of clients that associate on-the-fly with deployment 293 endpoints. 295 o The first time a client associates, it presents its software 296 statement, and any optional registration parameters, to the token 297 endpoint and receives a client credential token, an optional 298 client refresh token, and an optional client association resource 299 endpoint URL. Clients MAY also present an initial access token in 300 the authoirzation header as an indication of prior authorization 301 with the authorization server. 303 o A client MAY update its association after a configuration change, 304 software update, or expiration or revocation of its client 305 credential, MAY present its client refresh token as its 306 authorization plus the client's software statement and optional 307 configuration parameters to receive a new client credentaial token 308 and an optional client refresh token. 310 Dynamic clients association clients use the OAuth token endpoint with 311 "grant_type" of "urn:ietf:params:oauth:grant-type:client-assoc" to 312 submit a software statement and any per instance registration 313 parameters. In response the registration endpoint confirms the 314 registration by issuing a client token and an optional client refresh 315 token. Additionally, the registration endpoint MAY provide a client 316 resource endpoint which can be used to retrieve additional 317 information about the client. The use and function of the client 318 resource endpoint is out of scope of this specification. 320 3.2.1. Registration Request 322 The value of "grant_type" MUST be "urn:ietf:params:oauth:grant-type 323 :client-assoc". 325 The value of the "assertion" parameter MUST contain a software 326 statement [I-D.draft-hunt-oauth-software-statement]. 328 The authorization header MAY be ONE OF three values: 330 o Omitted to indicate a new association. 332 o An initial access token to indicate a new assocation that has been 333 pre-authorized. 335 o A client refresh token to update an existing association and to 336 rotate the client access token and optional client refresh token. 338 A non-normative, JSON encoded example of a new association request is 339 as follows: 341 POST /token.oauth2 HTTP/1.1 342 Content-Type: application/json 343 Accept: application/json 344 Host: as.example.com 346 { 347 "grant_type"= 348 "urn:ietf:params:oauth:grant-type:client-assoc" 349 "redirect_uris":[ 350 "https://client.example.org/callback", 351 "https://client.example.org/callback2" 352 ], 353 "software_statement":"eyJhbGciOiJFUzI1NiJ9. 354 eyJpc3Mi[...omitted for brevity...]. 355 J9l-ZhwP[...omitted for brevity...]", 356 "extension_parameter":"foo" 357 } 359 The update association is similar to a new association. In the 360 update, the main difference is the client supplies the client refresh 361 token in the "Authorization" header. In a software update (e.g. a 362 new verson of the client software), the client MAY provide an updated 363 or revised software statement (not shown). A non-normative, JSON 364 encoded example of an association update request is as follows: 366 POST /token.oauth2 HTTP/1.1 367 Content-Type: application/json 368 Accept: application/json 369 Authorization: Bearer ey23f2.adfj230.af32-developer321 370 Host: as.example.com 372 { 373 "grant_type"= 374 "urn:ietf:params:oauth:grant-type:client-assoc" 375 "redirect_uris":[ 376 "https://client.example.org/callback", 377 "https://client.example.org/callback2" 378 ], 379 "software_statement":"eyJhbGciOiJFUzI1NiJ9. 380 eyJpc3Mi[...omitted for brevity...]. 381 J9l-ZhwP[...omitted for brevity...]", 383 "extension_parameter":"foo" 384 } 386 The client MAY include additional instance specific parameters 387 defined in Section 2.2 [I-D.draft-hunt-oauth-software-statement]. If 388 a "software_statement" is enclosed, the token server MUST ignore any 389 attribute in the JSON request that is specified in the statement. 391 3.2.2. Association Processing 393 If an initial access token or client referesh token is presented as 394 an authentication credential, the server MUST process the token as 395 per section 3.2.1 of [RFC6749]. 397 The received software statement MUST have be validated per 398 Section 2.3 of [I-D.draft-hunt-oauth-software-statement] 400 If the software statement includes values for "redirect_url" and the 401 request includes a "redirect_url" value, the request MUST be 402 rejected. [[should this be a SHOULD?]] 404 Unless otherwise stated, the server SHOULD ignore any request 405 parameter that duplicates values provided in the software statement. 407 For each new association, the server SHOULD generate a new 408 "client_id" and client token. In dynamic associations, a single 409 "software_id" will have one or more "client_id" values associated 410 with it. 412 The server SHOULD NOT change the value of "client_id" if the client 413 updates the association by presenting a client refresh token. In 414 such a case, the "software_id" value contained in the software 415 statement SHOULD NOT change. When an association is updated, the 416 server MAY invalidate outstanding OAuth authorizations and access 417 tokens issued to the client. [[OR, should the server maintain 418 authorizations and access tokens?]] 420 3.2.3. Successful Association Response 422 After successfully processing the association request, the token 423 server SHALL respond with the following: 425 client_id REQUIRED. A unique client identifier assigned to the 426 client software instance. 428 token_type REQUIRED. The type of token issued by the authorization 429 server in parameter client_token for the purpose of client 430 authentication as described in Section 7.1 [RFC6749]. 432 client_token REQUIRED. The client credential token issued by the 433 authorization server. The type and usage is indicated by the 434 parameter token_type. 436 expires_in RECOMMENDED. The lifetime in seconds of the access 437 token. For example, the value "3600" denotes that the access 438 token will expire in one hour from the time the response was 439 generated. If omitted, the authorization server SHOULD 440 provide the expiration time via other means or document the 441 default value. 443 refresh_token OPTIONAL. A client refresh token of type "bearer" 444 which can be used to refresh a client association. The token 445 MAY be used to update association via the token grant request 446 and MAY be used to access the client association resource 447 endpoint indicated in "location". 449 location OPTIONAL. A URI specifying the location of a resource 450 endpoint representing the clients association with the 451 endpoint. The type of endpoint and usage is out of scope of 452 this specification. [[should there be a location type? e.g. 453 SCIM Dynamic Management?] 455 A non-normative JSON formated response (some values clipped for 456 readability): 458 HTTP/1.1 200 OK 459 Content-Type: application/json 460 Cache-Control: no-store 461 Pragma: no-cache 463 { 464 "client_id":"s6BhdRkqt3", 465 "token_type":"bearer", 466 "client_token":"eyJhbGciOiJFUzI1NiJ9. 467 eyJpc3Mi[...omitted for brevity...]. 468 J9l-ZhwP[...omitted for brevity...]", 469 "client_id_issued_at":2893256800, 470 "expires_at":2893276800, 471 "refresh_token":"mF_9.B5f-4.1JqM", 472 "location":"https://scim.example.com/Clients/s6BhdRkqt3", 473 "extension_parameter": "foo" 474 } 476 An non-normative HoK token example (some values clipped for 477 readability): 479 HTTP/1.1 200 OK 480 Content-Type: application/json 481 Cache-Control: no-store 482 Pragma: no-cache 484 { 485 "client_id":"s6BhdRkqt3", 486 "token_type":"hok", 487 "client_token":"eyJhbGciOiJFUzI1NiJ9. 488 eyJpc3Mi[...omitted for brevity...]. 489 J9l-ZhwP[...omitted for brevity...]", 490 "secret"="somesymetrickey", 491 "client_id_issued_at":2893256800, 492 "expires_at":2893276800, 493 "refresh_token":"mF_9.B5f-4.1JqM", 494 "location":"https://scim.example.com/Clients/s6BhdRkqt3" 495 } 497 3.2.4. Error Responses 499 When an OAuth 2.0 error condition occurs, such as the client 500 presenting an invalid initial access token or client refresh token, 501 the authorization server returns an error response appropriate to the 502 OAuth 2.0 token type. This error response is defined in 503 Section 3.2.1 of [RFC6750]. 505 When a registration error condition occurs, the authorization server 506 returns an HTTP 400 status code (unless otherwise specified) with 507 content type "application/json" consisting of a JSON object [RFC4627] 508 describing the error in the response body. 510 The JSON object contains two members: 512 error 513 The error code, a single ASCII string. 515 error_description 516 A human-readable text description of the error for debugging. 518 This specification defines the following error codes: 520 invalid_statement The software statement presented is not a valid 521 assertion according to [I-D.draft-hunt-oauth-software-statement]. 523 unapproved_software The software statement presented IS NOT approved 524 or IS NOT registered for use with the current endpoint. 526 invalid_redirect_uri 527 The value of one or more "redirect_uris" is invalid. 529 invalid_client_metadata 530 The value of one of the request parameters is invalid or is in 531 conflict with a value in the software statement. 533 Following is a non-normative example of an error response (with line 534 wraps for display purposes only): 536 HTTP/1.1 400 Bad Request 537 Content-Type: application/json 538 Cache-Control: no-store 539 Pragma: no-cache 541 { 542 "error":"invalid_redirect_uri", 543 "error_description":"The redirect URI of http://sketchy.example.com 544 is not allowed for this server." 545 } 547 3.3. Transient Association 549 Transient association clients access service providers for a limited 550 relationship usually defined by the life of any access token issued. 551 These clients are characterized by having no deployment organization 552 issued client tokens or identifiers. Transient clients MAY use their 553 "software_id" as the "client_id" and use their software statement as 554 their client token according to according to section 2.2 of 555 [I-D.ietf-oauth-jwt-bearer]. 557 Per section 4.2 of [RFC6749], implicit flow clients SHALL provide 558 their "software_id" as the "client_id" when making implicit 559 authorization requests. 561 Per section 2.1.2 of [I-D.draft-hunt-oauth-software-statement], it is 562 expected that the software_id SHOULD be known to the service provider 563 as part of its software approval process and is out of scope of this 564 specification. If the software_id is not known, the server SHOULD 565 respond with error code "unapproved_software" per Section 3.2.4. 567 Transient clients SHOULD be considered as 'public clients' as defined 568 in [RFC6749]. 570 3.4. Client Disassociation 572 [[TBD - should this be supported?]] 574 4. IANA Considerations 576 The following is a parameter registration request, as defined 577 Section 11.2, the OAuth parameters registry, of OAuth 2.0 [RFC6749]. 578 [[NEED TO REGISTER: software_statement, redirect_uri, etc ]] 580 5. Security Considerations 582 [[TO BE REVISED]] 584 For clients that use redirect-based grant types such as Authorization 585 Code and Implicit, authorization servers SHOULD require clients to 586 register their "redirect_uris"if not specified in their software 587 statement. Requiring clients to do so can help mitigate attacks 588 where rogue actors inject and impersonate a validly registered client 589 and intercept its authorization code or tokens through an invalid 590 redirect URI. 592 Clients with software statements containing "redirect_uris" MUST NOT 593 specify a new redirect_uri during registration. 595 The authorization server MUST treat all client metadata, including 596 software statements, as self-asserted. A rogue client might use the 597 name and logo for the legitimate client, which it is trying to 598 impersonate. For instance, an authorization server could warn if the 599 domain/site of the logo doesn't match the domain/site of redirect 600 URIs. An authorization server can also present warning messages to 601 end users about untrusted clients in all cases, especially if such 602 clients have not been associated by the authorization server before. 604 Authorization servers MAY assume that registered client software 605 sharing the same software assertion, software_id, and other metadata 606 SHOULD have similar operational behaviour metrics. Similarly, 607 Authorization server administrators MAY use software_id and 608 software_version to facilitate normal change control and approval 609 management of client software including: 611 o Approval of specific clients software for use with specific 612 protected resources. 614 o Lifecycle management and support of specific software versions as 615 indicated by software_version. 617 o Revocation of groups of client credentials and associated access 618 tokens when support issues or security risks identified with a 619 particular client software as identified by software_id and 620 software_version. 622 In a situation where the authorization server is supporting open 623 client registration, it must be extremely careful with any URL 624 provided by the client that will be displayed to the user (e.g. 625 "logo_uri", "tos_uri", "client_uri", and "policy_uri"). For 626 instance, a rogue client could specify a registration request with a 627 reference to a drive-by download in the "policy_uri". The 628 authorization server SHOULD check to see if the "logo_uri", 629 "tos_uri", "client_uri", and "policy_uri" have the same host and 630 scheme as the those defined in the array of "redirect_uris" and that 631 all of these resolve to valid Web pages. 633 Access tokens issued to clients to facilitate update or retrieval of 634 client registrations SHOULD be short lived. 636 Clients SHOULD rotate their client credentials before they expire by 637 obtaining an access token from the authorization server using the 638 registration scope. If a client has not successfully rotated its 639 credential prior to expiry, the client MUST register as a new client. 641 If a client is deprovisioned from a server (due to expiry or de- 642 registration), any outstanding Registration Access Token for that 643 client MUST be invalidated at the same time. Otherwise, this can 644 lead to an inconsistent state wherein a client could make requests to 645 the client configuration endpoint where the authentication would 646 succeed but the action would fail because the client is no longer 647 valid. 649 Clients that are unable to retain a client credential for the life of 650 the client instance MAY NOT register and should continue to be 651 treated as Public clients as defined by OAuth 2.0. 653 6. Normative References 655 [I-D.draft-hunt-oauth-software-statement] 656 Hunt, P., Ed. and T. Nadalin, "OAuth Software Statement", 657 . 659 [I-D.ietf-jose-json-web-key] 660 Jones, M., "JSON Web Key (JWK)", draft-ietf-jose-json-web- 661 key-14 (work in progress), July 2013. 663 [I-D.ietf-oauth-assertions] 664 Campbell, B., Mortimore, C., Jones, M., and Y. Goland, 665 "Assertion Framework for OAuth 2.0 Client Authentication 666 and Authorization Grants", draft-ietf-oauth-assertions-12 667 (work in progress), July 2013. 669 [I-D.ietf-oauth-jwt-bearer] 670 Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token 671 (JWT) Profile for OAuth 2.0 Client Authentication and 672 Authorization Grants", draft-ietf-oauth-jwt-bearer-06 673 (work in progress), July 2013. 675 [I-D.ietf-oauth-saml2-bearer] 676 Campbell, B., Mortimore, C., and M. Jones, "SAML 2.0 677 Profile for OAuth 2.0 Client Authentication and 678 Authorization Grants", draft-ietf-oauth-saml2-bearer-17 679 (work in progress), July 2013. 681 [IANA.Language] 682 Internet Assigned Numbers Authority (IANA), "Language 683 Subtag Registry", 2005. 685 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 686 Requirement Levels", BCP 14, RFC 2119, March 1997. 688 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 689 RFC 2246, January 1999. 691 [RFC4627] Crockford, D., "The application/json Media Type for 692 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 694 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 695 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 696 May 2008. 698 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 699 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 701 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying 702 Languages", BCP 47, RFC 5646, September 2009. 704 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 705 Verification of Domain-Based Application Service Identity 706 within Internet Public Key Infrastructure Using X.509 707 (PKIX) Certificates in the Context of Transport Layer 708 Security (TLS)", RFC 6125, March 2011. 710 [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 711 6749, October 2012. 713 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 714 Framework: Bearer Token Usage", RFC 6750, October 2012. 716 Appendix A. Acknowledgments 718 This draft was based upon in large part upon the work in draft-ietf- 719 oauth-dyn-reg-14, draft-richer-oauth-dyn-reg-core-00 and draft- 720 richer-oauth-dyn-reg-12 and WG discussions. The authors would like 721 to thank Justin Richer and the members of the OAuth Working Group. 723 Appendix B. Document History 725 [[ to be removed by the RFC editor before publication as an RFC ]] 727 -00 729 o First draft. 731 Authors' Addresses 733 Phil Hunt (editor) 734 Oracle Corporation 736 Email: phil.hunt@yahoo.com 738 Tony Nadalin 739 Microsoft 741 Email: tonynad@microsoft.com