idnits 2.17.1 draft-ietf-oauth-dyn-reg-01.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 is 1 instance of too long lines in the document, the longest one being 52 characters in excess of 72. 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 (November 5, 2012) is 4190 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: 'JSON' is defined on line 743, but no explicit reference was found in the text == Unused Reference: 'JWE' is defined on line 749, but no explicit reference was found in the text == Unused Reference: 'JWT' is defined on line 757, but no explicit reference was found in the text == Unused Reference: 'OAuth-Sig' is defined on line 760, but no explicit reference was found in the text == Unused Reference: 'RFC2617' is defined on line 788, but no explicit reference was found in the text == Unused Reference: 'RFC5785' is defined on line 799, but no explicit reference was found in the text == Unused Reference: 'USA15' is defined on line 809, but no explicit reference was found in the text == Unused Reference: 'UMA-Core' is defined on line 819, but no explicit reference was found in the text == Unused Reference: 'UMA-Reqs' is defined on line 823, but no explicit reference was found in the text == Unused Reference: 'UMA-UC' is defined on line 828, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4627 (ref. 'JSON') (Obsoleted by RFC 7158, RFC 7159) -- Possible downref: Non-RFC (?) normative reference: ref. 'JWA' -- Possible downref: Non-RFC (?) normative reference: ref. 'JWE' -- Possible downref: Non-RFC (?) normative reference: ref. 'JWK' -- Possible downref: Non-RFC (?) normative reference: ref. 'JWS' -- Possible downref: Non-RFC (?) normative reference: ref. 'JWT' -- Possible downref: Non-RFC (?) normative reference: ref. 'OAuth-Sig' ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) -- Possible downref: Non-RFC (?) normative reference: ref. 'USA15' Summary: 7 errors (**), 0 flaws (~~), 12 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Richer, Ed. 3 Internet-Draft The MITRE Corporation 4 Intended status: Standards Track T. Hardjono 5 Expires: May 9, 2013 MIT 6 M. Machulak 7 Newcastle University 8 E. Maler 9 XMLgrrl.com 10 C. Scholz 11 COM.lounge GmbH 12 N. Sakimura 13 NRI 14 J. Bradley 15 Ping Identity 16 M. Jones 17 Microsoft 18 November 5, 2012 20 OAuth Dynamic Client Registration Protocol 21 draft-ietf-oauth-dyn-reg-01 23 Abstract 25 This specification proposes an OAuth Dynamic Client Registration 26 protocol. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on May 9, 2013. 45 Copyright Notice 47 Copyright (c) 2012 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3 64 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 66 1.3.1. The client needs to be uniquely identifiable by 67 the authorization server . . . . . . . . . . . . . . . 4 68 1.3.2. The authorization server must collect metadata 69 about a client for later user interaction . . . . . . 4 70 1.3.3. The authorization server should have the option of 71 strongly authenticating the client and its metadata . 4 72 1.3.4. Dynamic client registration must be possible from 73 both web-server applications and applications with 74 other capabilities and limitations, such as native 75 applications . . . . . . . . . . . . . . . . . . . . . 4 76 1.3.5. Transaction integrity must be ensured . . . . . . . . 5 77 2. Client Registration Endpoint . . . . . . . . . . . . . . . . . 5 78 2.1. Client Association Request . . . . . . . . . . . . . . . . 6 79 2.2. Client Association Response . . . . . . . . . . . . . . . 8 80 2.3. Client Update Request . . . . . . . . . . . . . . . . . . 9 81 2.4. Client Update Response . . . . . . . . . . . . . . . . . . 10 82 2.5. Rotate Secret Request . . . . . . . . . . . . . . . . . . 11 83 2.6. Rotate Secret Response . . . . . . . . . . . . . . . . . . 11 84 2.7. Client Registration Error Response . . . . . . . . . . . . 12 85 3. Client Metadata . . . . . . . . . . . . . . . . . . . . . . . 13 86 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 87 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 88 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 89 7. Document History . . . . . . . . . . . . . . . . . . . . . . . 16 90 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 91 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 92 8.2. Non-Normative References . . . . . . . . . . . . . . . . . 18 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 95 1. Introduction 97 In some use-case scenarios, it is desirable or necessary to allow 98 OAuth clients to obtain authorization from an OAuth authorization 99 server without the two parties having previously interacted. 100 Nevertheless, in order for the authorization server to accurately 101 represent to end-users which client is seeking authorization to 102 access the end-user's resources, a method for automatic and unique 103 registration of clients is needed. The OAuth2 authorization 104 framework does not define how the relationship between the Client and 105 the Authorization Server is initialized, or how a given client is 106 assigned a unique Client Identifier. Historically, this has happened 107 out-of-band from the OAuth protocol. This draft provides a mechanism 108 for a client to register itself with the Authorization Server, which 109 can be used to dynamically provision a Client Identifier, and 110 optionally a Client Secret. 112 As part of the registration process, this specification also defines 113 a mechanism for the client to present the Authorization Server with a 114 set of meta information, such as a display name and icon to be 115 presented to the user during the authorization step. This draft 116 provides a method for the client to register and update this 117 information over time. 119 1.1. Notational Conventions 121 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 122 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this 123 document are to be interpreted as described in [RFC2119]. 125 Unless otherwise noted, all the protocol parameter names and values 126 are case sensitive. 128 1.2. Terminology 130 This specification uses the terms "Access Token", "Refresh Token", 131 "Authorization Code", "Authorization Grant", "Authorization Server", 132 "Authorization Endpoint", "Client", "Client Identifier", "Client 133 Secret", "Protected Resource", "Resource Owner", "Resource Server", 134 and "Token Endpoint" defined by OAuth 2.0 [OAuth2.0]. 136 This specification defines the following additional terms: 138 o Client Registration Endpoint: The OAuth 2.0 Endpoint through which 139 a Client can request new registration and manage the metadata 140 associated with it. 142 o Registration Access Token: An OAuth 2.0 Bearer Token issued by the 143 Authorization Server through the Client Registration Endpoint 144 which is used by the Client to authenticate itself during update 145 and secret rotation operations. 147 1.3. Requirements 149 [[ Following are proposed requirements for dynamic client 150 registration. This section is intended for discussion and will 151 likely be removed in the final draft. ]] 153 1.3.1. The client needs to be uniquely identifiable by the 154 authorization server 156 In order for an authorization server to do proper user-delegated 157 authorization and prevent unauthorized access it must be able to 158 identify clients uniquely. As is done today in OAuth, the client 159 identifier (and optional secret) should thus be issued by the 160 authorization server and not simply accepted as proposed by the 161 client. 163 1.3.2. The authorization server must collect metadata about a client 164 for later user interaction 166 In order for the authorization server to describe a client to an end- 167 user in an authorization step it needs information about the client. 168 This can be the client name at a minimum, but today servers usually 169 request at least a description, a homepage URL, and an icon when 170 doing manual registration. 172 1.3.3. The authorization server should have the option of strongly 173 authenticating the client and its metadata 175 In order to prevent spoofing of clients and enable dynamic building 176 of strong trust relationships, the authorization server should have 177 the option to verify the provided information. This might be solved 178 using message signature verification. 180 1.3.4. Dynamic client registration must be possible from both web- 181 server applications and applications with other capabilities and 182 limitations, such as native applications 184 Each instance of a native application (that is, the specific instance 185 running on each device) that is installed and run by the same user 186 may need the option of getting a unique client identifier. In this 187 case, there are implications around gathering and displaying enough 188 information to ensure that the end-user is delegating authorization 189 to the intended application. The registration protocol should be 190 simple and flexible enough to allow for multiple types of 191 applications. 193 1.3.5. Transaction integrity must be ensured 195 When a client sends information to a server endpoint, it might take 196 time for this data to propagate through big server installations that 197 spread across various data centers. Care needs to be taken that 198 subsequent interactions with the user after the registration process, 199 such as an authorization request, show the correct data. 201 2. Client Registration Endpoint 203 The Client Registration Endpoint is an OAuth 2.0 Endpoint defined in 204 this document that is designed to allow a Client to register itself 205 with the Authorization Server. The Client Registration Endpoint MUST 206 accept HTTP POST messages with request parameters encoded in the 207 entity body using the "application/x-www-form-urlencoded" format. 208 The Client Registration Endpoint MUST be protected by a transport- 209 layer security mechanism when sending requests to the Registration 210 Endpoint. The server MUST support TLS 1.2 RFC 5246 [RFC5246] and/or 211 TLS 1.0 [RFC2246] and MAY support additional transport-layer 212 mechanisms meeting its security requirements. When using TLS, the 213 Client MUST perform a TLS/SSL server certificate check, per RFC 6125 214 [RFC6125]. 216 The Endpoint defines three operations that a client can take on it, 217 switched by the "operation" parameter: 219 o client_associate: generate a new Client Identifier (and optionally 220 a Client Secret) and associate it with the set of presented 221 metadata (Section 3) 223 o client_update: update the metadata (Section 3) associated with a 224 Client Identifier 226 o rotate_secret: issue a new Registration Access Token and, if 227 applicable, a Client Secret for a Client 229 In order to facilitate registered clients updating their information, 230 the Client Registration Endpoint issues a request_access_token for 231 clients to securely identify themselves in future connections. As 232 such, the Endpoint MUST accept requests with OAuth 2.0 Bearer Tokens 233 [OAuth.Bearer] for these operations. 235 In order to support open registration and facilitate wider 236 interoperability, the Client Registration Endpoint SHOULD allow 237 client_associate requests with no further authentication. These 238 requests MAY be rate-limited to prevent a denial-of-service attack on 239 the Client Registration Endpoint. 241 In addition, the Client Registration Endpoint MAY accept an initial 242 authorization credential in the form of an OAuth 2.0 [OAuth2.0] 243 access token in order to limit registration to only previously 244 authorized parties. The method by which this access token is 245 obtained by the registrant is generally out-of-band and is out of 246 scope of this specification. 248 These two aspects, operation selection and client authentication, are 249 represented by two parameters common to all operations: 251 operation REQUIRED. Values are "client_associate" (for new 252 registrations), "rotate_secret" to request rotation of the 253 "client_secret", and "client_update" (for updating parameters of 254 an existing "client_id"). 256 access_token OPTIONAL. An OAuth2 Bearer token used to access the 257 Client Registration Endpoint, as defined in OAuth2 Bearer. This 258 parameter MUST NOT be sent if the Access Token is sent in the HTTP 259 Authorization header as described in Section 7.1 of OAuth 2.0 260 [OAuth2.0]. Access Tokens sent in the authorization header must 261 be OAuth 2.0 Bearer Tokens [OAuth.Bearer]. 263 Each operation takes a different parameter set, and all operations 264 are described below. 266 The Client Registration Endpoint MUST ignore all parameters it does 267 not understand. 269 2.1. Client Association Request 271 This operation registers a new client to the Authorization Server. 272 The Authorization Server assigns this client a unique Client 273 Identifier, optionally assigns a Client Secret, and associates the 274 metadata given in the request with the issued Client Identifier. The 275 request includes the two parameters described above as well as any 276 parameters described in Client Metadata (Section 3). 278 operation REQUIRED, MUST have the value "client_associate" 280 access_token OPTIONAL, used to restrict new client registration 281 redirect_uris 282 REQUIRED 284 client_name RECOMMENDED 286 client_url 287 RECOMMENDED 289 logo_url OPTIONAL 291 contacts OPTIONAL 293 tos_url OPTIONAL 295 token_endpoint_auth_method OPTIONAL 297 policy_url OPTIONAL 299 jwk_url OPTIONAL 301 jwk_encryption_url OPTIONAL 303 x509_url OPTIONAL 305 x509_encryption_url OPTIONAL 307 require_signed_request_object OPTIONAL 309 default_max_age OPTIONAL 311 default_acr OPTIONAL 313 For example, a client could send the following registration request 314 to the Client Registration Endpoint: 316 Following is a non-normative example request (with line wraps for 317 display purposes only): 318 POST /register HTTP/1.1 319 Accept: application/x-www-form-urlencoded 320 Host: server.example.com 321 Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJ ... fQ.8Gj_-sj ... _X 323 operation=client_associate 324 &redirect_uris=https://client.example.org/callback 325 %20https://client.example.org/callback2 326 &client_name=My%20Example%20 327 &logo_url=https://client.example.org/logo.png 328 &token_endpoint_auth_type=client_secret_basic 329 &jwk_url=https://client.example.org/my_rsa_public_key.jwk 331 2.2. Client Association Response 333 Upon successful association, the Client Registration Endpoint returns 334 the newly-created Client Identifier and, optionally, a Client Secret. 335 The response also contains a Registration Access Token that is to be 336 used by the client to perform subsequent operations at this endpoint. 337 These items are returned as a JSON document with the following fields 338 as top-level members of the root JSON object. 340 client_id REQUIRED. The unique Client identifier, MUST NOT be 341 currently valid for any other registered Client. 343 client_secret OPTIONAL. The Client secret. This MUST be unique for 344 each "client_id". This value us used by confidential clients. It 345 is not required for clients selecting a token_endpoint_auth_type 346 of "private_key_jwt" 348 registration_access_token REQUIRED The Access token to be used by 349 the client to perform "client_update" and "rotate_secret" 350 requests. 352 issued_at 353 OPTIONAL. Specifies the timestamp when the identifier was issued. 354 The timestamp value MUST be a positive integer. The value is 355 expressed in the number of seconds since January 1, 1970 00:00:00 356 GMT. 358 expires_at OPTIONAL. The number of seconds from 1970-01-01T0:0:0Z 359 as measured in UTC that the "client_secret" will expire or "0" if 360 they do not expire. See RFC 3339 [RFC3339] for details regarding 361 date/times in general and UTC in particular. 363 Following is a non-normative example response: 364 HTTP/1.1 200 OK 365 Content-Type: application/json 366 Cache-Control: no-store 368 { 369 "client_id":"s6BhdRkqt3", 370 "client_secret": 371 "cf136dc3c1fd9153029bb9c6cc9ecead918bad9887fce6c93f31185e5885805d", 372 "registration_access_token": "this.is.a.access.token.value.ffx83", 373 "expires_at":2893276800 374 } 376 2.3. Client Update Request 378 This operation updates a previously-registered client with new 379 metadata at the Authorization Server. This request MUST be protected 380 by the Registration Authorization Token associated with the Client 381 Identifier. This request MAY include any fields described in Client 382 Metadata (Section 3). The values of Client Metadata fields in this 383 request MUST replace (not augment) the values previously associated 384 with this client_identifier. Empty values in Client Metadata SHOULD 385 be taken as a request to clear any existing value of that field. 387 operation REQUIRED, MUST have the value "client_update" 389 access_token REQUIRED, unless presented in the Authorization Header 390 as in OAuth2 Bearer [OAuth.Bearer]. The Registration Access Token 391 that was issued during the client_associate step, or previous 392 client_update or rotate_secret calls. 394 redirect_uris 395 REQUIRED 397 client_name RECOMMENDED 399 client_url 400 RECOMMENDED 402 logo_url OPTIONAL 404 contacts OPTIONAL 406 tos_url OPTIONAL 407 token_endpoint_auth_method OPTIONAL 409 policy_url OPTIONAL 411 jwk_url OPTIONAL 413 jwk_encryption_url OPTIONAL 415 x509_url OPTIONAL 417 x509_encryption_url OPTIONAL 419 require_signed_request_object OPTIONAL 421 default_max_age OPTIONAL 423 default_acr OPTIONAL 425 For example, a client could send the following registration request 426 to the Client Registration Endpoint: 428 Following is a non-normative example request (with line wraps for 429 display purposes only): 430 POST /register HTTP/1.1 431 Accept: application/x-www-form-urlencoded 432 Host: server.example.com 433 Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJ ... fQ.8Gj_-sj ... _X 435 operation=client_update 436 &redirect_uris=https://client.example.org/callback 437 %20https://client.example.org/callback2 438 &client_name=My%20Example%20 439 &logo_url=https://client.example.org/logo.png 440 &token_endpoint_auth_type=client_secret_basic 441 &jwk_url=https://client.example.org/my_rsa_public_key.jwk 443 2.4. Client Update Response 445 Upon successful update, the Client Registration Endpoint returns a 446 JSON document with the following fields as top-level members of the 447 root JSON object. 449 client_id REQUIRED. The unique Client identifier, MUST NOT be 450 currently valid for any other registered Client. 452 Following is a non-normative example response: 453 HTTP/1.1 200 OK 454 Content-Type: application/json 455 Cache-Control: no-store 457 { 458 "client_id":"s6BhdRkqt3", 459 } 461 [[ Editor's note: should this return the entire client data object, 462 for confirmation and review, including any fields that may have been 463 asserted by the AS? ]] 465 2.5. Rotate Secret Request 467 This operation allows the client to rotate its current Client Secret, 468 if it has one. If the client has not been issued a Client Secret, 469 this operation is an error. [[ Editor's note: could this request be 470 used to rotate the Registration Access Token, even when there's not a 471 client_secret? Should something else be used to rotate the token 472 independently? This is an open issue. ]] 474 operation REQUIRED. MUST have the value rotate_secret 476 access_token REQUIRED. The Registration Access Token that was 477 issued during the client_associate step, or previous client_update 478 or rotate_secret calls. 480 Following is a non-normative example request (with line wraps for 481 display purposes only): 482 POST /register HTTP/1.1 483 Accept: application/x-www-form-urlencoded 484 Host: server.example.com 485 Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJ ... fQ.8Gj_-sj ... _X 487 operation=rotate_secret 489 2.6. Rotate Secret Response 491 Upon successful rotation of the client secret, the Client 492 Registration Endpoint returns a JSON document with the following 493 fields as top-level members of the root JSON object. 495 client_id REQUIRED. The unique Client identifier, MUST NOT be 496 currently valid for any other registered Client. 498 client_secret REQUIRED. The Client secret. This MUST be unique for 499 each "client_id". 501 registration_access_token REQUIRED The Access token to be used by 502 the client to perform subsequent "client_update" and 503 "rotate_secret" requests. 505 issued_at 506 OPTIONAL. Specifies the timestamp when the identifier was issued. 507 The timestamp value MUST be a positive integer. The value is 508 expressed in the number of seconds since January 1, 1970 00:00:00 509 GMT. 511 expires_at OPTIONAL. The number of seconds from 1970-01-01T0:0:0Z 512 as measured in UTC that the "client_secret" will expire or "0" if 513 they do not expire. See RFC 3339 [RFC3339] for details regarding 514 date/times in general and UTC in particular. 516 Following is a non-normative example response: 517 HTTP/1.1 200 OK 518 Content-Type: application/json 519 Cache-Control: no-store 521 { 522 "client_id":"s6BhdRkqt3", 523 "client_secret": 524 "cf136dc3c1fd9153029bb9c6cc9ecead918bad9887fce6c93f31185e5885805d", 525 "registration_access_token": "this.is.a.access.token.value.ffx83", 526 "expires_at":2893276800 527 } 529 2.7. Client Registration Error Response 531 When an OAuth error condition occurs, the Client Registration 532 Endpoint returns an Error Response as defined in Section 5.2 of the 533 OAuth 2.0 specification. 535 When a registration error condition occurs, the Client Registration 536 Endpoint returns a HTTP 400 status code including a JSON object 537 describing the error in the response body. 539 The JSON object contains two members: 541 error The error code, a single ASCII string. 543 error_description The additional text description of the error for 544 debugging. 546 This specification defines the following error codes: 548 invalid_operation The value of "operation" is invalid or not 549 supported. 551 invalid_redirect_uri The value of one or more "redirect_uris" is 552 invalid. 554 invalid_client_metadata The value of one of the client metadata 555 (Section 3) fields is invalid. 557 Following is a non-normative example of an error response: 558 HTTP/1.1 400 Bad Request 559 Content-Type: application/json 560 Cache-Control: no-store 562 { 563 "error":"invalid_operation", 564 "error_description":"The value of the operation parameter must be one of client_associate, rotate_secret or client_update." 565 } 567 3. Client Metadata 569 Clients generally have an array of metadata associated with their 570 unique Client Identifier at the Authorization Server. These can 571 range from human-facing display strings, such as a client name, to 572 items that impact the security of the protocol, 574 Extensions and profiles of this specification MAY expand this list, 575 but MUST at least accept all parameters on this list. The 576 Authorization Server MUST ignore any additional parameters sent by 577 the Client that it does not understand. 579 redirect_uris 580 REQUIRED A space-delimited list of redirect URIs. 582 client_name RECOMMENDED. Human-readable name of the Client to be 583 presented to the user. 585 client_url 586 RECOMMENDED. This field contains the URL of the homepage of the 587 client. 589 logo_url OPTIONAL. A URL that references a logo for the Client 590 application. If present, the server SHOULD display this image to 591 the end user during approval. 593 contacts OPTIONAL. Space delimited list of email addresses for 594 people allowed to administer the information for this Client. 595 This is used by some providers to enable a web UI to modify the 596 Client information. 598 tos_url OPTIONAL. URL that points to a human-readable Terms of 599 Service for the Client. The Authorization Server SHOULD display 600 this URL to the End-User if it is given. 602 token_endpoint_auth_method OPTIONAL. The requested authentication 603 type for the Token Endpoint. The options are 604 "client_secret_post", "client_secret_basic", "client_secret_jwt", 605 and "private_key_jwt". Other Authentication methods may be 606 defined by extension. If unspecified or omitted, the default is 607 "client_secret_basic" HTTP Basic Authentication Scheme as 608 specified in Section 2.3.1 of OAuth 2.0 [OAuth2.0]. [[ this list 609 of terms needs to be expanded and fully defined, especially in 610 reference to signed-jwt client authentication ]] 612 policy_url OPTIONAL. A URL location that the Client provides to the 613 End-User to read about the how the profile data will be used. The 614 Authorization Server SHOULD display this URL to the End-User if it 615 is given. 617 jwk_url OPTIONAL. URL for the Client's JSON Web Key [JWK] document 618 that is used for signing Token Endpoint Requests. If 619 jwk_encryption_url is not provided, the key at jwk_url is also 620 used as the key to encrypt responses to the Client. If the Client 621 registers both "x509_url" and "jwk_url", the keys contained in 622 both formats MUST be the same. 624 jwk_encryption_url OPTIONAL. URL for the Client's JSON Web Key 625 [JWK] that is used to encrypt any responses to the Client. If the 626 Client registers both "jwk_encryption_url" and 627 "x509_encryption_url", the keys contained in both formats MUST be 628 the same. 630 x509_url OPTIONAL. URL for the Client's PEM encoded X.509 631 Certificate or Certificate chain that is used for signing Token 632 Endpoint Requests. If "x509_encryption_url" is not provided, 633 "x509_url" it is also used to encrypt responses to the Client. If 634 the Client registers both "x509_url" and "jwk_url", the keys 635 contained in both formats MUST be the same. 637 x509_encryption_url OPTIONAL. URL for the Client's PEM encoded 638 X.509 Certificate or Certificate chain that is used to encrypt the 639 ID Token and User Info Endpoint Responses to the Client. If the 640 Client registers both "jwk_encryption_url" and 641 "x509_encryption_url", the keys contained in both formats SHOULD 642 be the same. 644 require_signed_request_object OPTIONAL. The JWS [JWS] "alg" 645 algorithm [JWA] that MUST be required by the Authorization Server. 646 The valid values are listed in Section 3.1 of JWA [JWA]. Servers 647 SHOULD support "RS256". 649 default_max_age OPTIONAL. (default max authentication age): Type: 650 Integer - Specifies that the End-User must be actively 651 authenticated if any present authentication is older than the 652 specified number of seconds. (The "max_age" request parameter 653 corresponds to the OpenID 2.0 PAPE "max_auth_age" request 654 parameter.) The "max_age" claim in the request object overrides 655 this default value. 657 default_acr OPTIONAL. (default authentication context class 658 reference): Type: String - Specifies the default value that the 659 Authorization server must use for processing requests from this 660 client. The "acrs_supported" element of discovery contains a list 661 of the supported "acr" values for this server. The "acr" claim in 662 the request object overrides this default value. 664 4. IANA Considerations 666 This document makes no requests of IANA. 668 5. Security Considerations 670 [[ Editor's note: Following are some security considerations taken 671 whole from the UMA and OpenID Connect source drafts. ]] 673 o No client authentication: The server should treat unsigned pushed 674 client metadata as self-asserted. 676 o Weak client authentication: The server should treat unsigned 677 pulled client metadata as self-asserted unless the domain of the 678 client matches the client metadata URL and the URL is well-known 679 and trusted. 681 o Strong client authentication: The server should treat signed 682 client metadata (pushed or pulled) and a signed metadata URL as 683 self-asserted unless it can verify the signature as being from a 684 trusted source. 686 Since requests to the Client Registration Endpoint result in the 687 transmission of clear-text credentials (in the HTTP request and 688 response), the server MUST require the use of a transport-layer 689 security mechanism when sending requests to the Registration 690 Endpoint. The server MUST support TLS 1.2 RFC 5246 [RFC5246] and/or 691 TLS 1.0 [RFC2246] and MAY support additional transport-layer 692 mechanisms meeting its security requirements. When using TLS, the 693 Client MUST perform a TLS/SSL server certificate check, per RFC 6125 694 [RFC6125]. 696 Requests to the Registration Endpoint for "client_update" MUST have 697 some rate limiting on failures to prevent the Client secret from 698 being disclosed though repeated access attempts. 700 A rogue RP might use the logo for the legitimate RP, which it is 701 trying to impersonate. An IdP needs to take steps to mitigate this 702 phishing risk, since the logo could confuse users into thinking 703 they're logging in to the legitimate RP. An IdP could also warn if 704 the domain/site of the logo doesn't match the domain/site of redirect 705 URIs. An IdP can also make warnings against untrusted RPs in all 706 cases, especially if they're dynamically registered, have not been 707 trusted by any users at the IdP before, and want to use the logo 708 feature. 710 In a situation where the Authorization Server is supporting open 711 Client registration, it must be extremely careful with any URL 712 provided by the Client that will be displayed to the user (e.g. 713 "logo_url" and "policy_url"). A rogue Client could specify a 714 registration request with a reference to a drive-by download in the 715 "policy_url". The Authorization Server should check to see if the 716 "logo_url" and "policy_url" have the same host as the hosts defined 717 in the array of "redirect_uris". 719 6. Acknowledgments 721 The authors thank the User-Managed Access Work Group and the OpenID 722 Connect Working Group participants for their input to this document. 724 7. Document History 726 [[ to be removed by RFC editor before publication as an RFC ]] 728 - 01 729 o Merged UMA and OpenID Connect registrations into a single document 731 o Changed to form-paramter inputs to endpoint 733 o Removed pull-based registration 735 - 00 737 o Imported original UMA draft specification 739 8. References 741 8.1. Normative References 743 [JSON] Crockford, D., "The application/json Media Type for 744 JavaScript Object Notation (JSON)", 2006, 745 . 747 [JWA] Jones, M., "JSON Web Algorithms", May 2012. 749 [JWE] Jones, M., Rescorla, E., and J. Hildebrand, "JSON Web 750 Encryption (JWE)", May 2012. 752 [JWK] Jones, M., "JSON Web Key (JWK)", May 2012. 754 [JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 755 Signature", May 2012. 757 [JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token", 758 May 2012. 760 [OAuth-Sig] 761 Balfanz, D., "OAuth Signature proposals", 2010, . 765 [OAuth.Bearer] 766 Jones, M. and D. Hardt, "OAuth 2.0 Protocol: Bearer 767 Tokens", Aug 2012. 769 [OAuth2.0] 770 Hardt, D., "OAuth 2.0 Authorization Protocol", July 2012. 772 [OpenID.Messages] 773 Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., 774 Mortimore, C., and E. Jay, "OpenID Connect Messages 1.0", 775 May 2012. 777 [OpenID.Session] 778 Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and 779 N. Agarwal, "OpenID Connect Session Management 1.0", 780 August 2012. 782 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 783 Requirement Levels", BCP 14, RFC 2119, March 1997. 785 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 786 RFC 2246, January 1999. 788 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 789 Leach, P., Luotonen, A., and L. Stewart, "HTTP 790 Authentication: Basic and Digest Access Authentication", 791 RFC 2617, June 1999. 793 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 794 Internet: Timestamps", RFC 3339, July 2002. 796 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 797 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 799 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 800 Uniform Resource Identifiers (URIs)", RFC 5785, 801 April 2010. 803 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 804 Verification of Domain-Based Application Service Identity 805 within Internet Public Key Infrastructure Using X.509 806 (PKIX) Certificates in the Context of Transport Layer 807 Security (TLS)", RFC 6125, March 2011. 809 [USA15] Davis, M., Whistler, K., and M. Duerst, "Unicode 810 Normalization Forms", Unicode Standard Annex 15, 09 2009. 812 [hostmeta] 813 Hammer-Lahav, E., "Web Host Metadata", 2010, . 817 8.2. Non-Normative References 819 [UMA-Core] 820 Scholz, C., "UMA Requirements", 2010, . 823 [UMA-Reqs] 824 Maler, E., "UMA Requirements", 2010, . 828 [UMA-UC] Akram, H., "UMA Explained", 2010, . 832 Authors' Addresses 834 Justin Richer (editor) 835 The MITRE Corporation 837 Phone: 838 Fax: 839 Email: jricher@mitre.org 840 URI: 842 Thomas Hardjono 843 MIT 845 Phone: 846 Fax: 847 Email: hardjono@mit.edu 848 URI: 850 Maciej Machulak 851 Newcastle University 853 Email: m.p.machulak@ncl.ac.uk 854 URI: http://ncl.ac.uk/ 856 Eve Maler 857 XMLgrrl.com 859 Email: eve@xmlgrrl.com 860 URI: http://www.xmlgrrl.com 861 Christian Scholz 862 COM.lounge GmbH 864 Phone: 865 Fax: 866 Email: 867 URI: 869 Nat Sakimura 870 Nomura Research Institute, Ltd. 872 Email: n-sakimura@nri.co.jp 874 John Bradley 875 Ping Identity 877 Email: ve7jtb@ve7jtb.com 879 Michael B. Jones 880 Microsoft 882 Email: mbj@microsoft.com