idnits 2.17.1 draft-hardjono-oauth-dynreg-03.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 (April 26, 2012) is 4376 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: 'RFC2617' is defined on line 753, 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. 'OAuth-Sig' ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Hardjono, Ed. 3 Internet-Draft MIT 4 Intended status: Standards Track M. Machulak 5 Expires: October 28, 2012 Newcastle University 6 E. Maler 7 XMLgrrl.com 8 C. Scholz 9 COM.lounge GmbH 10 April 26, 2012 12 OAuth Dynamic Client Registration Protocol 13 draft-hardjono-oauth-dynreg-03 15 Abstract 17 This specification proposes an OAuth Dynamic Client Registration 18 protocol. 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 October 28, 2012. 37 Copyright Notice 39 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3 56 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.1. The client needs to be uniquely identifiable by the 60 authorization server . . . . . . . . . . . . . . . . . . . 5 61 3.2. The authorization server must collect metadata about a 62 client for later user interaction . . . . . . . . . . . . 5 63 3.3. The authorization server must have the option of 64 strongly authenticating the client and its metadata . . . 5 65 3.4. Dynamic client registration must be possible from both 66 web-server applications and applications with other 67 capabilities and limitations, such as native 68 applications . . . . . . . . . . . . . . . . . . . . . . . 6 69 3.5. Transaction integrity must be ensured in large 70 deployments where data propagation can be an issue . . . . 6 71 3.6. Use of standardized discovery protocol . . . . . . . . . . 6 72 3.7. UMA design principles and requirements . . . . . . . . . . 7 73 4. Analysis of Registration Flow Options . . . . . . . . . . . . 7 74 5. Client Registration with Pushed Metadata . . . . . . . . . . . 8 75 5.1. Client Registration Request . . . . . . . . . . . . . . . 9 76 5.2. Client Registration Response . . . . . . . . . . . . . . . 10 77 5.3. Error Response . . . . . . . . . . . . . . . . . . . . . . 11 78 6. Client Registration with Pushed URL and Pulled Metadata . . . 12 79 6.1. Client Registration Request . . . . . . . . . . . . . . . 13 80 6.2. Client Discovery . . . . . . . . . . . . . . . . . . . . . 13 81 6.3. Client Registration Response . . . . . . . . . . . . . . . 13 82 6.4. Error Response . . . . . . . . . . . . . . . . . . . . . . 14 83 7. Native Application Client Registration . . . . . . . . . . . . 15 84 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 85 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 86 10. Document History . . . . . . . . . . . . . . . . . . . . . . . 17 87 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 88 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 89 11.2. Non-Normative References . . . . . . . . . . . . . . . . . 18 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 92 1. Introduction 94 This draft discusses a number of requirements for and approaches to 95 automatic registration of clients with an OAuth authorization server, 96 with special emphasis on the needs of the OAuth-based User-Managed 97 Access protocol [UMA-Core]. This draft also proposes a dynamic 98 registration protocol for an OAuth authorization server. 100 In some use-case scenarios it is desirable or necessary to allow 101 OAuth clients to obtain authorization from an OAuth authorization 102 server without the two parties having previously interacted. 103 Nevertheless, in order for the authorization server to accurately 104 represent to end-users which client is seeking authorization to 105 access the end-user's resources, a method for automatic and unique 106 registration of clients is needed. 108 The goal of this proposed registration protocol is for an 109 authorization server to provide a client with a client identifier and 110 optionally a client secret in a dynamic fashion. To accomplish this, 111 the authorization server must first be provided with information 112 about the client, with the client-name being the minimal information 113 provided. In practice, additional information will need to be 114 furnished to the authorization server, such as the client's homepage, 115 icon, description, and so on. 117 The dynamic registration protocol proposed here is envisioned to be 118 an additional task to be performed by the OAuth authorization server, 119 namely registration of a new client identifier and optional secret 120 and the issuance of this information to the client. This task would 121 occur prior to the point at which the client wields its identifier 122 and secret at the authorization server in order to obtain an access 123 token in normal OAuth fashion. 125 1.1. Notational Conventions 127 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 128 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this 129 document are to be interpreted as described in [RFC2119]. 131 Unless otherwise noted, all the protocol parameter names and values 132 are case sensitive. 134 1.2. Terminology 135 resource server 136 A server capable of accepting and responding to protected 137 resource requests. 139 resource owner 140 An entity capable of granting access to a protected resource. 142 client 143 An application obtaining authorization and making protected 144 resource requests. 146 authorization server 147 A server capable of issuing tokens after successfully 148 authenticating the resource owner and obtaining authorization. 149 The authorization server may be the same server as the resource 150 server, or a separate entity. 152 authorization manager 153 An UMA-defined variant of an authorization server that carries 154 out an authorizing user's policies governing access to a 155 protected resource. 157 end-user authorization endpoint 158 The authorization server's HTTP endpoint capable of 159 authenticating the end-user and obtaining authorization. 161 token endpoint 162 The authorization server's HTTP endpoint capable of issuing 163 tokens and refreshing expired tokens. 165 client identifier 166 An unique identifier issued to the client to identify itself to 167 the authorization server. Client identifiers may have a 168 matching secret. 170 client registration endpoint The authorization server's HTTP 171 endpoint capable of issuing client identifiers and optional 172 client secrets. 174 2. Use Cases 176 The UMA protocol involves two instances of OAuth flows. In the 177 first, an end-user introduces a host (essentially an enhanced OAuth 178 resource server) to an authorization manager (an enhanced OAuth 179 authorization server) as a client of it, possibly without that host 180 having obtained client identification information from that server 181 previously. In the second, a requester (an enhanced OAuth client) 182 approaches a host and authorization manager to get and use an access 183 token in approximately the normal OAuth fashion, again possibly 184 without that client having obtained client identification information 185 from that server previously. Both the host-as-client and the 186 requester-as-client thus may need dynamic client registration in 187 order for the UMA protocol flow to proceed. 189 The needs for inter-party trust vary in different UMA use cases. In 190 lightweight Web circumstances such as person-to-person calendar 191 sharing, dynamic registration is entirely appropriate. In cases 192 where high-sensitivity information is being protected or where a 193 regulatory environment puts constraints on the building of trust 194 relationships, such as sharing health records with medical 195 professionals or giving access to tax records to outsourced 196 bookkeeping staff, static means of provisioning client identifiers 197 may be imposed. 199 More information about UMA use cases is available at [UMA-UC]. 201 3. Requirements 203 Following are proposed requirements for dynamic client registration. 205 3.1. The client needs to be uniquely identifiable by the authorization 206 server 208 In order for an authorization server to do proper user-delegated 209 authorization and prevent unauthorized access it must be able to 210 identify clients uniquely. As is done today in OAuth, the client 211 identifier (and optional secret) should thus be issued by the 212 authorization server and not simply accepted as proposed by the 213 client. 215 3.2. The authorization server must collect metadata about a client for 216 later user interaction 218 In order for the authorization server to describe a client to an end- 219 user in an authorization step it needs information about the client. 220 This can be the client name at a minimum, but today servers usually 221 request at least a description, a homepage URL, and an icon when 222 doing manual registration. 224 3.3. The authorization server must have the option of strongly 225 authenticating the client and its metadata 227 In order to prevent spoofing of clients and enable dynamic building 228 of strong trust relationships, the authorization server should have 229 the option to verify the provided information. This might be solved 230 using message signature verification; relatively weaker 231 authentication might be achieved in a simpler way by pulling metadata 232 from a trusted client URL. 234 3.4. Dynamic client registration must be possible from both web-server 235 applications and applications with other capabilities and 236 limitations, such as native applications 238 In the UMA context, alternative types of applications might serve as 239 both hosts (for example, as a device-based personal data store) and 240 requesters (for example, to subscribe to a calendar or view a photo). 241 Such applications, particularly native applications, may have special 242 limitations, so new solutions to meeting the set of requirements 243 presented here may be needed. We anticipate that each instance of a 244 native application (that is, the specific instance running on each 245 device) that is installed and run by the same user may need the 246 option of getting a unique client identifier. In this case, there 247 are implications around gathering and displaying enough information 248 to ensure that the end-user is delegating authorization to the 249 intended application. 251 3.5. Transaction integrity must be ensured in large deployments where 252 data propagation can be an issue 254 When a client sends information to a server endpoint, it might take 255 time for this data to propagate through big server installations that 256 spread across various data centers. Care needs to be taken that 257 subsequent interactions with the user after the registration process, 258 such as an authorization request, show the correct data. 260 In the UMA context, dynamic registration of a host at an AM is almost 261 certain to take place in the middle of an introduction and 262 authorization process mediated by the end-user; even though the host 263 needs a client identifier from the AM no matter which end-user caused 264 the registration process to take place, the end-user may need to wait 265 for the registration sub-process to finish in order to continue with 266 the overall process. It may be necessary to ensure that the host 267 interacts with the same AM server throughout. 269 3.6. Use of standardized discovery protocol 271 Regardless of flow option, the client needs to discover the 272 authorization server's client registration endpoint. The client MUST 273 use the [RFC5785] and [hostmeta] discovery mechanisms to learn the 274 URI of the client registration endpoint at the authorization server. 275 The authorization server MUST provide a host-meta document that 276 clearly defines the registration end-point at the server. 278 3.7. UMA design principles and requirements 280 In addition to general requirements for dynamic client registration, 281 UMA seeks to optimize for the design principles and requirements 282 found in the UMA Requirements document [UMA-Reqs], most particularly: 284 o DP1: Simple to understand, implement in an interoperable fashion, 285 and deploy on an Internet-wide scale 287 o DP6: Able to be combined and extended to support a variety of use 288 cases and emerging application functionality 290 o DP8: Avoid adding crypto requirements beyond what existing web app 291 implementations do today 293 o DP10: Complexity should be borne by the authorization endpoint vs. 294 other endpoints 296 4. Analysis of Registration Flow Options 298 This section analyzes some options for exchanging client metadata for 299 a client identifier and optional secret. 301 It currently seems impossible to specify a single registration flow 302 that will satisfy all requirements, deployment needs, and client 303 types. This document, therefore, presents as small a variety of 304 options as possible. If it is possible to construct a single unified 305 flow in the ultimate design, all other things being equal this would 306 be preferred. 308 Client provides metadata on every request 309 In this approach, the client passes all necessary metadata such 310 as its name and icon on every request to the authorization 311 server, and the client doesn't wield a client identifier as 312 such. This option makes it more difficult (though not 313 impossible) to meet the first and second requirements since 314 different clients could theoretically represent themselves to 315 an authorization server with the same metadata and the same 316 client could represent itself on subsequent visits with 317 different metadata. Also, today's OAuth protocol requires the 318 use of a client identifier. Because of the UMA simplicity 319 principle we do not recommend this flow option and and have not 320 provided a candidate solution. 322 Client pushes metadata 323 In this approach, the client discovers the registration 324 endpoint of the authorization server and sends its metadata 325 directly to that endpoint in a standard format. The 326 authorization server answers with a client identifier and 327 optional secret in the response. This approach may be 328 necessary in cases where the client is behind a firewall, but 329 strong authentication of the client metadata may be more 330 difficult or costly with this approach than with a "pull" 331 approach, discussed just below. Further, this approach is 332 problematic in the case of applications that can't function as 333 POST-capable web servers. A proposal for "push" is presented 334 in this document. 336 Client pushes URL, server pulls metadata from it 337 In this approach, the client sends only a URL to the 338 authorization server, which then uses that URL to pull metadata 339 about the client in some standard format, returning 340 identification information in the response to the initial 341 request. This approach more easily allows for strong 342 authentication of clients because the metadata can be 343 statically signed. (The message containing the URL could be 344 signed as well.) However, caution should be exercised around 345 the propagation issue if the initial URL push is made to a 346 server different from the one the end-user is interacting with. 347 Further, this approach is problematic in the case of 348 applications that cannot themselves serve as "pull-able" 349 metadata repositories. A proposal for "pull" is presented in 350 this document. 352 Native-app client collaborates with home-base web app to provide 353 metadata 354 An instance of a native application (for example, on a mobile 355 device) may have difficulty directly conveying trustworthy 356 metadata but may also have difficulty providing a trustworthy 357 third-party source from which a server can pull metadata. This 358 document explores one option for meeting the requirements, but 359 does not present a full-fledged proposal. 361 5. Client Registration with Pushed Metadata 363 This registration flow works as follows: 365 1. The client sends its metadata in JSON form to the client 366 registration endpoint. The client MUST send its name, 367 description, and redirection URI and MAY send a URI for its icon. 368 The client MAY sign the metadata as a JSON Token issuer, using 369 the mechanisms defined in [OAuth-Sig]. 371 2. The authorization server checks the data, verifying the signature 372 as necessary, and returns a client identifier and an optional 373 client secret. 375 +--------+ +---------------+ 376 | Client |--(A)--- Registration Request --->| Authorization | 377 | | with Metadata | Server | 378 | | | | 379 | |<-(B)----Registration Response ---| | 380 | | with Client ID Info | | 381 +--------+ +---------------+ 383 Figure 1: Client Registration Flow with Pushed Metadata 385 5.1. Client Registration Request 387 The client sends a JSON formatted document to the client registration 388 endpoint. The client includes the following parameters in the 389 request: 391 type 392 REQUIRED. This parameter must be set to "push". 394 client_name 395 REQUIRED. This field contains a human-readable name of the 396 client. 398 client_url 399 REQUIRED. This field contains the URL of the homepage of the 400 client. 402 client_description 403 REQUIRED. This field contains a text description of the 404 client. 406 client_icon 407 OPTIONAL. This field contains a URL for an icon for the 408 client. 410 redirect_url 411 REQUIRED. This field contains the URL to which the 412 authorization server should send its response. 414 The client MAY include additional metadata in the request and the 415 authorization server MAY ignore this additional information. 417 For example, the client might send the following request: 419 POST /register HTTP/1.1 420 Host: server.example.com 421 Content-Type: application/json 423 { 424 type: "push", 425 client_name: "Online Photo Gallery", 426 client_url: "http://onlinephotogallery.com", 427 client_description: "Uploading and also editing capabilities!", 428 client_icon: "http://onlinephotogallery.com/icon.png", 429 redirect_url: "https://onlinephotogallery.com/client_reg" 430 } 432 The parameters are included in the entity body of the HTTP request 433 using the "application/json" media type as defined by [JSON]. The 434 parameters are serialized into a JSON structure by adding each 435 parameter at the highest structure level. Parameter names and string 436 values are included as JSON strings. 438 5.2. Client Registration Response 440 After receiving and verifying information received from the client, 441 the authorization server issues a client identifier and an optional 442 client secret, and constructs the response by adding the following 443 parameters to the entity body of the HTTP response with a 200 status 444 code (OK): 446 client_id 447 REQUIRED. 449 client_secret 450 OPTIONAL. 452 issued_at 453 OPTIONAL. Specifies the timestamp when the identifier was 454 issued. The timestamp value MUST be a positive integer. The 455 value is expressed in the number of seconds since January 1, 456 1970 00:00:00 GMT. 458 expires_in 459 OPTIONAL; if supplied, the "issued_at" parameter is REQUIRED. 460 Specifies the valid lifetime, in seconds, of the identifier. 461 The value is represented in base 10 ASCII. 463 The parameters are included in the entity body of the HTTP response 464 using the "application/json" media type as defined by [JSON]. The 465 parameters are serialized into a JSON structure by adding each 466 parameter at the highest structure level. Parameter names and string 467 values are included as JSON strings. 469 The authorization server MUST include the HTTP "Cache-Control" 470 response header field with a value of "no-store" in any response 471 containing "client_secret". 473 For example, the authorization server might return the following 474 response: 476 HTTP/1.1 200 OK 477 Content-Type: application/json 478 Cache-Control: no-store 480 { 481 client_id: "5UO9XcL4TQTa", 482 client_secret: "WdRKN3zeTc20" 483 } 485 5.3. Error Response 487 If the request for registration is invalid or unauthorized, the 488 authorization server constructs the response by adding the following 489 parameters to the entity body of the HTTP response with a 400 status 490 code (Bad Request) using the "application/json" media type: 492 o "error" (REQUIRED). 494 o "error_description" (OPTIONAL). Human-readable text providing 495 additional information, used to assist in the understanding and 496 resolution of the error occurred. 498 o "error_uri" (OPTIONAL). A URI identifying a human-readable web 499 page with information about the error, used to provide the end- 500 user with additional information about the error. 502 An example error response (with line breaks for readability): 504 HTTP/1.1 400 Bad Request 505 Content-Type: application/json 506 Cache-Control: no-store 508 { 509 "error": "unauthorized_client", 510 "description": "This client is not on the 511 white list of this Authorization Server." 512 } 514 6. Client Registration with Pushed URL and Pulled Metadata 516 This registration flow works as follows: 518 1. The client sends its metadata URI to the client registration 519 endpoint. The client MAY sign the metadata as a JSON Token 520 issuer, using the mechanisms defined in [OAuth-Sig]. 522 2. The authorization server verifies the signature as necessary, and 523 uses the [RFC5785] and [hostmeta] discovery mechanisms on this 524 URI to retrieve the host-meta document describing the client. 525 The host-meta document MUST contain the client name, description, 526 and redirection URI, and MAY contain a URI for the client icon. 528 +--------+ +---------------+ 529 | Client |--(A)--- Registration Request --->| Authorization | 530 | | with URL | Server | 531 | | | | 532 | |<-(B)--- Client Discovery --------| | 533 | | | | 534 | |--(C)---- Host-Meta Document ---->| | 535 | | | | 536 | |<-(D)--- Registration Response ---| | 537 | | with Client ID Info | | 538 +--------+ +---------------+ 540 Figure 2: Client Registration Flow with Pushed URL and Pulled 541 Metadata 543 6.1. Client Registration Request 545 The client sends a JSON formatted document to the client registration 546 endpoint. The client includes the following parameters in the 547 request: 549 type 550 REQUIRED. This parameter must be set to "pull". 552 client_url 553 REQUIRED. This field contains the URL of the homepage of the 554 client. 556 The client MUST NOT include other metadata parameters, such as those 557 defined in the pushed-metadata scenario. 559 For example, the client might send the following request: 561 POST /register HTTP/1.1 562 Host: server.example.com 563 Content-Type: application/json 565 { 566 type: "pull", 567 url: "http://onlinephotogallery.com" 568 } 570 The parameters are included in the entity body of the HTTP request 571 using the "application/json" media type as defined by [JSON]. The 572 parameters are serialized into a JSON structure by adding each 573 parameter at the highest structure level. Parameter names and string 574 values are included as JSON strings. 576 6.2. Client Discovery 578 The authorization server evaluates this request and MAY perform a 579 [RFC5785] and [hostmeta] discovery mechanism on the provided URL to 580 the host-meta document for the client. 582 6.3. Client Registration Response 584 After receiving and verifying information retrieved from the client, 585 the authorization server issues the client identifier and an optional 586 client secret, and constructs the response by adding the following 587 parameters to the entity body of the HTTP response with a 200 status 588 code (OK): 590 o "client_id" (REQUIRED) 592 o "client_secret" (OPTIONAL) 594 The parameters are included in the entity body of the HTTP response 595 using the "application/json" media type as defined by [JSON]. The 596 parameters are serialized into a JSON structure by adding each 597 parameter at the highest structure level. Parameter names and string 598 values are included as JSON strings. 600 The authorization server MUST include the HTTP "Cache-Control" 601 response header field with a value of "no-store" in any response 602 containing the "client_secret". 604 For example the authorization server might return the following 605 response: 607 HTTP/1.1 200 OK 608 Content-Type: application/json 609 Cache-Control: no-store 611 { 612 "client_id":"5UO9XcL4TQTa", 613 "client_secret":"WdRKN3zeTc20" 614 } 616 6.4. Error Response 618 If the request for registration is invalid or unauthorized, the 619 authorization server constructs the response by adding the following 620 parameters to the entity body of the HTTP response with a 400 status 621 code (Bad Request) using the "application/json" media type: 623 o "error" (REQUIRED). A single error code. 625 o "error_description" (OPTIONAL). Human-readable text providing 626 additional information, used to assist in the understanding and 627 resolution of the error occurred. 629 o "error_uri" (OPTIONAL). A URI identifying a human-readable web 630 page with information about the error, used to provide the end- 631 user with additional information about the error. 633 An example error response (with line breaks for readability): 635 HTTP/1.1 400 Bad Request 636 Content-Type: application/json 637 Cache-Control: no-store 639 { 640 "error": "unauthorized_client", 641 "description": "This client is not on the 642 white list of this Authorization Server." 643 } 645 If the host-meta discovery was not successful, the authorization 646 server MUST use the error code "hostmeta_error". 648 An example error response (with line breaks for readability): 650 HTTP/1.1 404 Not Found 651 Content-Type: application/json 652 Cache-Control: no-store 654 { 655 "error": "hostmeta_error", 656 "description": "The hostmeta document could 657 not be retrieved from the URL." 658 } 660 7. Native Application Client Registration 662 For a native application serving as an UMA host, we anticipate that 663 the need for dynamic client registration to introduce this app to an 664 UMA authorization manager may typically happen only once (or very 665 infrequently), likely to a single authorization manager, and 666 registration could usefully take place at the time the app is 667 provisioned onto a device. By contrast, for a native app serving as 668 an UMA requester, it may need to register at multiple authorization 669 managers over time when seeking access tokens, at moments much later 670 than the original provisioning of the app onto the device. 672 When a native application is provisioned on a device, such as through 673 an app store model, often it has an associated "home base" web server 674 application component with which it registers (outside of any UMA- 675 related or OAuth-related interactions). This pairwise relationship 676 can be exploited in a number of ways to allow trustable, unique 677 metadata to be conveyed to an OAuth server and for this instance of 678 the app to receive a client identifier and optional secret. We have 679 discussed "device-initiated" and "home base-initiated" pattern 680 options for OAuth dynamic client registration in these circumstances. 681 Device-initiated flows seem more generically applicable (for example, 682 for both UMA host and UMA requester needs). However, a home base- 683 initiated flow may be preferable in case it is necessary to pre- 684 determine a trust level towards an OAuth server. In this case, the 685 home base server could initiate the registration process if and only 686 if there exists a trust relationship between the two parties. 688 Following is one option for a device-initiated flow: 690 1. User provisions native app on device and registers with and 691 authenticates to app's home-base web application. 693 2. Home base provisions native app with home base-signed metadata. 695 3. Whenever user tries to use native app to access a protected 696 resource, native app provides home base-provided metadata to 697 server. 699 4. Server verifies home base signature by pulling public key from 700 home base URL and generates client identifier and secret for 701 native app. 703 5. Server returns client identifier and secret to native app. 705 8. Security Considerations 707 Following are some security considerations: 709 o No client authentication: The server should treat unsigned pushed 710 client metadata as self-asserted. 712 o Weak client authentication: The server should treat unsigned 713 pulled client metadata as self-asserted unless the the domain of 714 the client matches the client metadata URL and the URL is well- 715 known and trusted. 717 o Strong client authentication: The server should treat signed 718 client metadata (pushed or pulled) and a signed metadata URL as 719 self-asserted unless it can verify the signature as being from a 720 trusted source. 722 9. Acknowledgments 724 The authors thank the User-Managed Access Work Group participants, 725 particularly the following, for their input to this document: 727 o Domenico Catalano 729 o George Fletcher 731 o Nat Sakimura 733 10. Document History 735 [[ to be removed by RFC editor before publication as an RFC ]] 737 11. References 739 11.1. Normative References 741 [JSON] Crockford, D., "The application/json Media Type for 742 JavaScript Object Notation (JSON)", 2006, 743 . 745 [OAuth-Sig] 746 Balfanz, D., "OAuth Signature proposals", 2010, . 750 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 751 Requirement Levels", BCP 14, RFC 2119, March 1997. 753 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 754 Leach, P., Luotonen, A., and L. Stewart, "HTTP 755 Authentication: Basic and Digest Access Authentication", 756 RFC 2617, June 1999. 758 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 759 Uniform Resource Identifiers (URIs)", RFC 5785, 760 April 2010. 762 [hostmeta] 763 Hammer-Lahav, E., "Web Host Metadata", 2010, . 767 11.2. Non-Normative References 769 [UMA-Core] 770 Hardjono, T., "UMA Core Specification", 2012, . 773 [UMA-Reqs] 774 Maler, E., "UMA Requirements", 2010, . 778 [UMA-UC] Akram, H., "UMA Explained", 2010, . 782 Authors' Addresses 784 Thomas Hardjono (editor) 785 MIT 787 Phone: 788 Fax: 789 Email: hardjono@mit.edu 790 URI: 792 Maciej Machulak 793 Newcastle University 795 Email: m.p.machulak@ncl.ac.uk 796 URI: http://ncl.ac.uk/ 798 Eve Maler 799 XMLgrrl.com 801 Email: eve@xmlgrrl.com 802 URI: http://www.xmlgrrl.com 803 Christian Scholz 804 COM.lounge GmbH 806 Phone: 807 Fax: 808 Email: 809 URI: