idnits 2.17.1 draft-ietf-oauth-use-cases-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 2 instances 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 date (May 23, 2012) is 4356 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OAUTH WG G. Fletcher 3 Internet-Draft AOL 4 Intended status: Informational T. Lodderstedt 5 Expires: November 24, 2012 Deutsche Telekom AG 6 Z. Zeltsan 7 Alcatel-Lucent 8 May 23, 2012 10 OAuth Use Cases 11 draft-ietf-oauth-use-cases-00 13 Abstract 15 This document lists the OAuth use cases. The provided list is based 16 on the Internet-Drafts of the OAUTH working group and discussions on 17 the group's mailing list. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on November 24, 2012. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 55 3. OAuth use cases . . . . . . . . . . . . . . . . . . . . . . . 3 56 3.1. Web server . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3.2. User-agent . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3.3. In-App-Payment (based on Native Application) . . . . . . . 6 59 3.4. Native Application . . . . . . . . . . . . . . . . . . . . 9 60 3.5. Device . . . . . . . . . . . . . . . . . . . . . . . . . . 10 61 3.6. Client password (shared secret) credentials . . . . . . . 11 62 3.7. Assertion . . . . . . . . . . . . . . . . . . . . . . . . 12 63 3.8. Content manager . . . . . . . . . . . . . . . . . . . . . 13 64 3.9. Access token exchange . . . . . . . . . . . . . . . . . . 14 65 3.10. Multiple access tokens . . . . . . . . . . . . . . . . . . 16 66 3.11. Gateway for browser-based VoIP applets . . . . . . . . . . 17 67 3.12. Signed Messages . . . . . . . . . . . . . . . . . . . . . 18 68 3.13. Signature with asymmetric secret . . . . . . . . . . . . . 20 69 4. Authors of the use cases . . . . . . . . . . . . . . . . . . . 22 70 5. Security considerations . . . . . . . . . . . . . . . . . . . 22 71 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 22 72 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 73 8. Normative References . . . . . . . . . . . . . . . . . . . . . 23 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 76 1. Introduction 78 The need for documenting the OAuth use cases was discussed at the 79 oauth WG virtual meetings, on the group's mailing list, and at the 80 IETF 77 and IETF 78. This Internet-Draft describes such use cases. 81 The objective of the draft is to document the discussed OAuth use 82 cases and identify the use cases supported by the OAuth 83 specifications. The following section provides the abbreviated 84 descriptions of the use cases. 86 Note: The use of the string ".example.com" in the URLs of the example 87 entities does not mean that the entities belong to the same 88 organization. 90 2. Notational Conventions 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 3. OAuth use cases 98 This section lists the use cases that have been discussed by the 99 oauth WG. 101 3.1. Web server 103 Description: 105 Alice accesses an application running on a web server at 106 www.printphotos.example.com and instructs it to print her photographs 107 that are stored on a server www.storephotos.example.com. The 108 application at www.printphotos.example.com receives Alice's 109 authorization for accessing her photographs without learning her 110 authentication credentials with www.storephotos.example.com. 112 Pre-conditions: 114 o Alice has registered with www.storephotos.example.com to enable 115 authentication 117 o The application at www.printphotos.example.com has established 118 authentication credentials with the application at 119 www.storephotos.example.com 121 Post-conditions: 123 A successful procedure results in the application 124 www.printphotos.example.com receiving an authorization code from 125 www.storephotos.example.com. The code is bound to the application at 126 www.printphotos.example.com and to the callback URL supplied by the 127 application. The application at www.printphotos.example.com uses the 128 authorization code for obtaining an access token from 129 www.storephotos.example.com. The application at 130 www.storephotos.example.com issues an access token after 131 authenticating the application at www.printphotos.example.com and 132 validating the authorization code that it has submitted. The 133 application at www.printphotos.example.com uses the access token for 134 getting access to Alice's photographs at www.storephotos.example.com. 136 Note: When an access token expires, the service at 137 www.printphotos.example.com needs to repeat the OAuth procedure for 138 getting Alice's authorization to access her photographs at 139 www.storephotos.example.com. Alternatively, if Alice wants to grant 140 the application a long lasting access to her resources at 141 www.storephotos.example.com, the authorization server associated with 142 www.storephotos.example.com may issue the long-living tokens. Those 143 tokens can be exchanged for short-living access tokens required to 144 access www.storephotos.example.com. 146 Requirements: 148 o The server www.printphotos.example.com, which hosts an OAuth 149 client, must be capable of issuing the HTTP redirect requests to 150 Alice's user agent - a browser 152 o Application at www.storephotos.example.com must be able to 153 authenticate Alice. The authentication method is not in the OAuth 154 scope 156 o Application at www.storephotos.example.com must obtain Alice's 157 authorization of the access to her photos by 158 www.printphotos.example.com 160 o Application at www.storephotos.example.com may identify to Alice 161 the scope of access that www.printphotos.example.com has requested 162 while asking for Alice's authorization 164 o Application at www.storephotos.example.com must be able to 165 authenticate the application at www.printphotos.example.com and 166 validate the authorization code before issuing an access token. 167 The OAuth 2.0 protocol [I-D.draft-ietf-oauth-v2] specifies one 168 authentication method that MAY be used for such authentication - 169 Client Password Authentication. 171 o Application at www.printphotos.example.com must provide a callback 172 URL to the application at www.storephotos.example.com (note: the 173 URL can be pre-registered with www.storephotos.example.com) 175 o Application at www.storephotos.example.com is required to maintain 176 a record that associates the authorization code with the 177 application at www.printphotos.example.com and the callback URL 178 provided by the application 180 o Access tokens are bearer's tokens (they are not associated with a 181 specific application, such as www.printphotos.example.com) and 182 should have a short lifespan 184 o Application at www.storephotos.example.com must invalidate the 185 authorization code after its first use 187 o Alice's manual involvement in the OAuth authorization procedure 188 (e.g., entering an URL or a password) should not be required. 189 (Alice's authentication to www.storephotos.example.com is not in 190 the OAuth scope. Her registration with 191 www.storephotos.example.com is required as a pre-condition) 193 3.2. User-agent 195 Description: 197 Alice has installed on her computer a gaming application. She keeps 198 her scores in a database of a social site at www.fun.example.com. In 199 order to upload Alice's scores, the application gets access to the 200 database with her authorization. 202 Pre-conditions: 204 o Alice has installed a gaming application implemented in a 205 scripting language (e.g., JavaScript) that runs in her browser and 206 uses OAuth for accessing a social site at www.fun.example.com 208 o There is no a web site supporting this application and capable of 209 handling the OAuth flow, so the gaming application needs to update 210 the database itself 212 o The installed application is registered with the social site at 213 www.fun.example.com and has an identifier 215 o Alice has registered with www.fun.example.com for identification 216 and authentication 218 o An auxiliary web server at www.help.example.com is reachable by 219 Alice's browser and capable of providing a script that extracts an 220 access token from an URL's fragment 222 Post-conditions: 224 A successful procedure results in Alice's browser receiving an access 225 token. The access token is received from www.fun.example.com as a 226 fragment of a redirection URL of an auxiliary web server 227 www.help.example.com. Alice's browser follows the redirection, but 228 retains the fragment. From the auxiliary web server at 229 www.help.example.com Alice's browser downloads a script that extracts 230 access token from the fragment and makes it available to the gaming 231 application. The application uses the access token to gain access to 232 Alice's data at www.fun.example.com. 234 Requirements: 236 o Registration of the application running in the Alice's browser 237 with the application running on www.fun.example.com is required 238 for identification 240 o Alice's authentication with www.fun.example.com is required 242 o Application running at www.fun.example.com must be able to 243 describe to Alice the request made by the gaming application 244 running on her computer and obtain Alice's authorization for or 245 denial of the requested access 247 o After obtaining Alice's authorization the application running at 248 www.fun.example.com must respond with an access token and redirect 249 Alice's browser to a web server (e.g., www.help.example.com) that 250 is capable of retrieving an access token from an URL 252 3.3. In-App-Payment (based on Native Application) 254 Description: 256 Alice has installed on her computer a gaming application (e.g., 257 running as native code or as a widget). At some point she wants to 258 play the next level of the game and needs to purchase an access to 259 the advanced version of the game from her service provider at 260 www.sp.example.com. With Alice's authorization the application 261 accesses her account at www.sp.example.com and enables her to make 262 the payment. 264 Pre-conditions: 266 o Alice has registered and has an account with her service provider 267 at www.sp.example.com 269 o The application is registered with the service provider at 270 www.sp.example.com. This enables the server provider to provide 271 Alice with all necessary information about the gaming application 272 (including the information about the purchasing price) 274 o Alice has a Web user-agent (e.g., a browser or a widget runtime) 275 installed on her computer 277 Post-conditions: 279 A successful procedure results in the gaming application invoking the 280 user browser and directing it to the authorization server of the 281 service provider. The HTTP message includes information about the 282 gaming application's request to access Alice's account. The 283 authorization server presents to Alice the authentication and 284 authorization interfaces. The authorization interface shows Alice 285 the information about the application's request including the 286 requested charge to her account. After Alice successfully 287 authenticates and authorizes the request, the authorization server 288 enables Alice to save the transaction details including the 289 authorization code issued for the gaming application. Then the 290 authorization server redirects Alice's browser to a custom scheme URI 291 (registered with the operating system). This redirection request 292 contains a one-time authorization code and invokes a special 293 application that is able to extract the authorization code and 294 present it to the gaming application. The gaming application 295 presents the authorization code to the authorization server and 296 exchanges it for a one-time access token. The gaming application 297 then uses the access token to get access to Alice's account and post 298 the charges at www.sp.example.com. 300 Requirements: 302 o An authorization server associated with the server at 303 www.sp.example.com must be able to authenticate Alice over a 304 secure transport 306 o An authorization server associated with the server at 307 www.sp.example.com must be able to provide Alice with information 308 about the access request that the gaming application has made 309 (including the amount that is to be charged to her account with 310 the service provider, and the purpose for the charge) over a 311 secure transport 313 o An authorization server associated with the server at 314 www.sp.example.com must be able to obtain Alice's authorization 315 decision on the request over a secure transport 317 o An authorization server associated with the server at 318 www.sp.example.com must be able to generate on demand a one-time 319 authorization code and a one-time access token according to the 320 scope authorized by Alice 322 o An authorization server associated with the server at 323 www.sp.example.com must be able to call back to the gaming 324 application with the authorization result over a secure transport 326 o An authorization server associated with the server at 327 www.sp.example.com must enable the gaming application to exchange 328 an authorization code for an access token over a secure transport 330 o * An authorization server associated with the server at 331 www.sp.example.com must verify the authorization code and 332 invalidate it after its first use 334 o * An authorization server associated with the server at 335 www.sp.example.com must enable Alice to save the details of the 336 requested transaction, including the authorization code 338 o * An authorization server associated with the server at 339 www.sp.example.com must keep a record linking the requested 340 transaction with the authorization code and the respective access 341 token 343 o * An authorization server associated with the server at 344 www.sp.example.com must enable the resource server 345 www.sp.example.com to obtain the transaction information that is 346 linked to the issued access token 348 o * Resource server at www.sp.example.com must verify access token 349 and invalidate it after its first use 351 o * A resource server at www.sp.example.com must enable the gaming 352 application to post charges to Alice's account according to the 353 access token presented over a secure transport 355 o The gaming application must provide a custom scheme URI to the 356 authorization server associated with www.sp.example.com (note: it 357 can be preregistered with the authorization server) 359 o Alice's manual involvement in the OAuth authorization procedure 360 (e.g., entering an URL or a password) should not be required. 362 (Alice's authentication to www.sp.example.com is not in the OAuth 363 scope) 365 * The requirements denoted by '*' are not common for the Native 366 Application use cases, but are specific to the In-App-Payment use 367 case 369 3.4. Native Application 371 Description: 373 Alice wants to upload (or download) her photographs to (or from) 374 storephotos.example.com using her smartphone. She downloads and 375 installs a photo app on her smartphone. In order to enable the app 376 to access her photographs, Alice needs to authorize the app to access 377 the web site on her behalf. The authorization shall be valid for a 378 prolonged duration (e.g. several months), so that Alice does not need 379 to authenticate and authorize access on every execution of the app. 380 It shall be possible to withdraw the app's authorization both on the 381 smartphone as well as on the site storephotos.example.com. 383 Pre-conditions: 385 o Alice has installed a (native) photo app application on her 386 smartphone 388 o The installed application is registered with the social site at 389 storephotos.example.com and has an identifier 391 o Alice holds an account with storephotos.example.com 393 o Authentication and authorization shall be performed in an 394 interactive, browser-based process. The smartphone's browser is 395 used for authenticating Alice and for enabling her to authorize 396 the request by the Mobile App 398 Post-conditions: 400 A successful procedure results in Alice's app receiving an access and 401 a refresh token. The app may obtain the tokens by utilizing either 402 the web server or the user agent flow. The application uses the 403 access token to gain access to Alice's data at 404 storephotos.example.com. The refresh token is persistently stored on 405 the device for use in sub-sequent app executions. If a refresh token 406 exists on app startup, the app directly uses the refresh token to 407 obtain a new access token. 409 Requirements: 411 o Alice's authentication with storephotos.example.com is required 413 o Registration of the application running on Alice's smartphone is 414 required for identification and registration and may be carried 415 out on a per installation base 417 o The application at storephotos.example.com provides a capability 418 to view and delete the apps' authorizations. This implies that 419 the different installations of the same app on the different 420 devices can be distinguished (e.g., by a device name or a 421 telephone number) 423 o The app must provide Alice an option to logout. The logout must 424 result in the revocation of the refresh token on the authorization 425 server 427 3.5. Device 429 Description: 431 Alice has a device, such as a game console, that does not support an 432 easy data-entry method. She also has an access to a computer with a 433 browser. The application running on the Alice's device gets 434 authorized access to a protected resource (e.g., photographs) stored 435 on a server at www.storephotos.example.com 437 Pre-conditions: 439 o Alice uses an Oauth-enabled game console, which does not have an 440 easy data-entry method, for accessing her photographs at 441 www.storephotos.example.com. The device starts the OAuth 442 procedure by requesting a token 444 o Alice is able to connect to www.storephotos.example.com using a 445 computer that provides an easy data-entry method, which is 446 equipped with a browser. This computer is used to authorize 447 access by the application running on the game console to Alice's 448 photographs 450 o Application running on Alice's game console has registered with 451 www.storephotos.example.com (has been issued an identifier) 453 o Alice has registered with the application running at 454 www.storephotos.example.com for identification and authentication 456 Post-conditions: Description: 458 A successful procedure results in the application running on Alice's 459 game console receiving an access token that enables access to the 460 photographs on www.storephotos.example.com. 462 Requirements: 464 o Registration of the application running on the game console with 465 the application running on www.storephotos.example.com is required 466 for identification 468 o Application running on the game console must be able to poll 469 periodically the application running at 470 www.storephotos.example.com while waiting for Alice's 471 authorization of the requested access to her photographs. The 472 repeating requests include the application's identifier and the 473 verification code that has been issued by 474 www.storephotos.example.com 476 o Alice is required to use her browser for interacting with the web 477 application running on www.storephotos.example.com. To that end 478 she has to manually direct her browser to the verification URL 479 that is displayed on her game console 481 o Alice's authentication with www.storephotos.example.com is 482 required 484 o After authentication with www.storephotos.example.com Alice, if 485 she wishes to approve the request, which is described in her 486 browser's window, must enter the user code. (The user code is 487 also displayed on her game console along with the verification 488 URL) 490 3.6. Client password (shared secret) credentials 492 Description: 494 The company GoodPay prepares the employee payrolls for the company 495 GoodWork. In order to do that the application at 496 www.GoodPay.example.com gets authenticated access to the employees' 497 attendance data stored at www.GoodWork.example.com. 499 Pre-conditions: 501 o The application at www.GoodPay.example.com has established through 502 a registration an identifier and a shared secret with the 503 application running at www.GoodWork.example.com 505 o The scope of the access by the application at 506 www.GoodPay.example.com to the data stored at 507 www.GoodWork.example.com has been defined 509 Post-conditions: 511 A successful procedure results in the application at 512 www.GoodPay.example.com receiving an access token after 513 authenticating to the application running at 514 www.GoodWork.example.com. 516 Requirements: 518 o Authentication of the application at www.GoodPay.example.com to 519 the application at www.GoodWork.example.com is required 521 o The authentication method must be based on the identifier and 522 shared secret, which the application running at 523 www.GoodPay.example.com submits to the application at 524 www.GoodWork.example.com in the initial HTTP request 526 o Because in this use case GoodPay gets access to GoodWork's 527 sensitive data, GoodWork shall have a pre-established trust with 528 GoodPay on the security policy and the authorization method's 529 implementation 531 3.7. Assertion 533 Description: 535 Company GoodPay prepares the employee payrolls for the company 536 GoodWork. In order to do that the application at 537 www.GoodPay.example.com gets authenticated access to the employees' 538 attendance data stored at www.GoodWork.example.com. 539 This use case describes an alternative solution to the one described 540 by the use case Client password credentials. 542 Pre-conditions: 544 o The application at www.GoodPay.example.com has obtained an 545 authentication assertion from a party that is trusted by the 546 application at www.GoodWork.example.com 548 o The scope of the access by the application at 549 www.GoodPay.example.com to the data stored at 550 www.GoodWork.example.com has been defined 552 o The application at www.GoodPay.example.com has established trust 553 relationship with the asserting party and is capable of validating 554 its assertions 556 Post-conditions: 558 A successful procedure results in the application at 559 www.GoodPay.example.com receiving an access token after 560 authenticating to the application running at www.GoodWork.example.com 561 by presenting an assertion (e.g., SAML assertion). 563 Requirements: 565 o Authentication of the application at www.GoodPay.example.com to 566 the application at www.GoodWork.example.com is required 568 o The application running at www.GoodWork.example.com must be 569 capable of validating assertion presented by the application 570 running at www.GoodPay.example.com 572 o Because in this use case GoodPay gets access to GoodWork's 573 sensitive data, GoodWork shall establish trust with GoodPay on the 574 security policy and the authorization method's implementation 576 3.8. Content manager 578 Description: 580 Alice and Bob are having a chat conversation using a content manager 581 application running on a web server at 582 www.contentmanager.example.com. Alice notifies Bob that she wants to 583 share some photographs at www.storephotos.example.com and instructs 584 the application at www.contentmanager.example.com to enable Bob's 585 access to the photographs. The application at 586 www.contentmanager.example.com, after Alice's authorization, obtains 587 an access token for Bob, who uses it to access Alice's photographs at 588 www.storephotos.example.com. 590 Pre-conditions: 592 Alice, Bob the content manager application at 593 www.contentmanager.example.com, and the application at 594 www.storephotos.example.com have registered with the same 595 authorization server for authentication 597 Post-conditions: 599 A successful procedure results in the application at 600 www.contentmanager.example.com receiving an access token that allows 601 access to Alice's photographs at www.storephotos.example.com. The 602 access token is issued by the authorization server after Alice has 603 authorized the content manager at www.contentmanager.example.com to 604 get an access token on Bob's behalf. The access token is passed to 605 Bob by the content manager. Bob uses the access token to view 606 Alice's photographs at www.storephotos.example.com. 608 Requirements: 610 o The server at www.contentmanager.example.com, must be capable of 611 issuing the HTTP redirect requests to Alice's and Bob's user 612 agents - the browsers 614 o The authorization server must be able to authenticate Alice, Bob, 615 and the application at www.contentmanager.example.com 617 o The authorization server is required to obtain Alice's 618 authorization for issuing an access token to 619 www.contentmanager.example.com on Bob's behalf 621 o Authorization server must be able to identify to Alice the scope 622 of access that www.contentmanager.example.com has requested on 623 Bob's behalf while asking for Alice's authorization 625 3.9. Access token exchange 627 Description: 629 Alice uses an application running on www.printphotos.example.com for 630 printing her photographs that are stored on a server at 631 www.storephotos.example.com. The application running on 632 www.storephotos.example.com, while serving the request of the 633 application at www.printphotos.example.com, discovers that some of 634 the requested photographs have been moved to 635 www.storephotos1.example.com. The application at 636 www.storephotos.example.com retrieves the missing photographs from 637 www.storephotos1.example.com and provides access to all requested 638 photographs to the application at www.printphotos.example.com. The 639 application at www.printphotos.example.com carries out Alice's 640 request. 642 Pre-conditions: 644 o The application running on www.printphotos.example.com is capable 645 of interacting with Alice's browser 647 o Alice has registered with and can be authenticated by 648 authorization server 650 o The applications at www.storephotos.example.com has registered 651 with authorization server 653 o The applications at www.storephotos1.example.com has registered 654 with authorization server 656 o The application at www.printphotos.example.com has registered with 657 authorization server 659 Post-conditions: 661 A successful procedure results in the application at 662 www.printphotos.example.com receiving an access token that allows 663 access to Alice's photographs. This access token is used for the 664 following purposes: 666 o By the application running at www.printphotos.example.com to get 667 access to the photographs at www.storephotos.example.com 669 o By the application running at www.storephotos.example.com to 670 obtain from authorization server another access token that allows 671 it to retrieve the additional photographs stored at 672 www.storephotos1.example.com 674 As the result, there are two access token issued for two different 675 applications. The tokens may have different properties (e.g., scope, 676 permissions, and expiration dates). 678 Requirements: 680 o The applications at www.printphotos.example.com and 681 www.storephotos.example.com require different access tokens 683 o The application at www.printphotos.example.com is required to 684 provide its callback URL to the application at 685 www.storephotos.example.com 687 o Authentication of the application at www.printphotos.example.com 688 to the authorization server is required 690 o Alice's authentication by the authorization server is required 692 o The authorization server must be able to describe to Alice the 693 request of the application at www.printphotos.example.com and 694 obtain her authorization (or rejection) 696 o If Alice has authorized the request, the authorization server must 697 be able to issue an access token that enables the application at 698 www.printphotos.example.com to get access to Alice's photographs 699 at www.storephotos.example.com 701 o The authorization server must be able, based on the access token 702 presented by the application at www.printphotos.example.com, to 703 generate another access token that allows the application at 704 www.storephotos.example.com to get access to the photographs at 705 www.storephotos1.example.com. In this context the authorization 706 server must validate the authorization of the application at 707 www.storephotos.example.com to obtain the token. 709 o The application at www.storephotos.example.com must be able to 710 validate an access token presented by the application running at 711 www.printphotos.example.com 713 o The application at www.storephotos1.example.com must be able to 714 validate the access token presented by the application running at 715 www.storephotos.example.com 717 3.10. Multiple access tokens 719 Description: 721 Alice uses a communicator application running on a web server at 722 www.communicator.example.com to access her email service at 723 www.email.example.com and her voice over IP service at 724 www.voip.example.com. Email addresses and telephone numbers are 725 obtained from Alice's address book at www.contacts.example.com. 726 Those web sites all rely on the same authorization server, so the 727 application at www.communicator.example.com can receive a single 728 authorization from Alice for getting access to these three services 729 on her behalf at once. 731 Note: This use case is especially useful for native applications 732 since a web browser needs to be launched only once. 734 Pre-conditions: 736 o The same authorization server serves Alice and all involved 737 servers 739 o Alice has registered with the authorization server for 740 authentication and for authorization of the requests of the 741 communicator application running at www.communicator.example.com 743 o The email application at www.email.example.com has registered with 744 the authorization server for authentication 746 o The VoIP application at www.voip.example.com has registered with 747 the authorization server for authentication 749 o The address book at www.contacts.example.com has registered with 750 the authorization server for authentication 752 Post-conditions: 754 A successful procedure results in the application at 755 www.communicator.example.com receiving three different access tokens: 756 one for accessing the email service at www.email.example.com, one for 757 accessing the contacts at www.contacts.example.com, and one for 758 accessing the VoIP service at www.voip.example.com. 760 Requirements: 762 o The application running at www.communicator.example.com must be 763 authenticated by the authorization server 765 o Alice must be authenticated by the authorization server 767 o The application running at www.communicator.example.com must be 768 able to get a single Alice's authorization for access to the 769 multiple services (e.g., email and VoIP) 771 o The application running at www.communicator.example.com must be 772 able to recognize that all three applications rely on the same 773 authorization server 775 o A callback URL of the application running at 776 www.communicator.example.com must be known to the authorization 777 server 779 o The authorization server must be able to issue the separate 780 service-specific tokens (with different, scope, permissions, and 781 expiration dates) for access to the requested services (such as 782 email and VoIP) 784 3.11. Gateway for browser-based VoIP applets 786 Description: 788 Alice accesses a social site on a web server at 789 www.social.example.com. Her browser loads a VoIP applet that enables 790 her to make a VoIP call using her SIP server at 791 www.sipservice.example.com. The application at 792 www.social.example.com gets Alice's authorization to use her account 793 with www.sipservice.example.com without learning her authentication 794 credentials with www.sipservice.example.com. 796 Pre-conditions: 798 o Alice has registered with www.sipservice.example.com for 799 authentication 801 o The application at www.social.example.com has established 802 authentication credentials with the application at 803 www.sipservice.example.com 805 Post-conditions: 807 A successful procedure results in the application at 808 www.social.example.com receiving access token from 809 www.sipservice.example.com with Alice's authorization. 811 Requirements: 813 o The server at www.social.example.com must be able to redirect 814 Alice's browser to www.sipservice.example.com 816 o The application running at www.sipservice.example.com must be 817 capable of authenticating Alice and obtaining her authorization of 818 a request from www.social.example.com 820 o The server at www.sipservice.example.com must be able to redirect 821 Alice's browser back to www.social.example.com 823 o The application at www.social.example.com must be able to 824 translate the messages of the Alice's VoIP applet into SIP and RTP 825 messages 827 o The application at www.social.example.com must be able to add the 828 access token to the SIP requests that it sends to 829 www.sipservice.example.com 831 o Application at www.sipservice.example.com must be able to 832 authenticate the application at www.social.example.com and 833 validate the access token 835 o Alice's manual involvement in the OAuth authorization procedure 836 (e.g., entering an URL or a password) should not be required. 837 (Alice's authentication to www.sipservice.example.com is not in 838 the OAuth scope) 840 3.12. Signed Messages 842 Description: 844 Alice manages all her personal health records in her personal health 845 data store at a server at www.myhealth.example.com, which manages 846 authorization of access to Alice's participating health systems. 847 Alice's Primary Care Physician (PCP), which has a Web site at 848 www.pcp.example.com, recommends her to see a sleep specialist 849 (www.sleepwell.example.com). Alice arrives at the sleep specialist's 850 office and authorizes it to access her basic health data at her PCP's 851 web site. The application at www.pcp.example.com verifies that Alice 852 has authorized www.sleepwell.example.com to access her health data as 853 well as enforces that www.sleepwell.example.com is the only 854 application that can retrieve that data with that specific 855 authorization. 857 Pre-conditions: 859 o Alice has a personal health data store that allows for discovery 860 of her participating health systems (e.g. psychiatrist, sleep 861 specialist, PCP, orthodontist, ophthalmologist, etc) 863 o The application at www.myhealth.example.com manages authorization 864 of access to Alice's participating health systems 866 o The application at www.myhealth.example.com can issue 867 authorization tokens understood by Alice's participating health 868 systems 870 o The application at www.pcp.example.com stores Alice's basic health 871 and prescription records 873 o The application at www.sleepwell.com stores results of Alice's 874 sleep tests 876 Post-conditions: 878 o A successful procedure results in just the information that Alice 879 authorized being transferred from the Primary Care Physician 880 (www.pcp.example.com) to the sleep specialist 881 (www.sleepwell.example.com) 883 o The transfer of health data only occurs if the application at 884 www.pcp.example.com can verify that www.sleepwell.example.com is 885 the party requesting access and that the authorization token 886 presented by www.sleepwell.example.com is issued by the 887 application at www.myhealth.example.com with a restricted audience 888 of www.sleepwell.example.com 890 Requirements: 892 o The application at www.sleepwell.example.com interacting with 893 www.myhealth.example.com must be able to discover the location of 894 the PCP system (e.g., XRD discovery) 896 o The application at www.sleepwell.example.com must be capable of 897 requesting Alice's authorization of access to the application at 898 www.pcp.example.com for the purpose of retrieving basic health 899 data (e.g. date-of-birth, weight, height, etc). The mechanism 900 Alice uses to authorize this access is out of scope for this use 901 case 903 o The application at www.myhealth.example.com must be capable of 904 issuing a token bound to www.sleepwell.example.com for access to 905 the application at www.pcp.example.com. Note that a signed token 906 (JWT) can be used to prove who issued the token 908 o The application at www.sleepwell.example.com must be capable of 909 issuing a request (which includes the token issued by 910 www.myhealth.example.com) to the application at 911 www.pcp.example.com 913 o The application at www.sleepwell.example.com must sign the request 914 before sending it to www.pcp.example.com 916 o The application at www.pcp.example.com must be capable of 917 receiving the request and verifying the signature 919 o The application at www.pcp.example.com must be capable of parsing 920 the message and finding the authorization token 922 o The application at www.pcp.example.com must be capable of 923 verifying the signature of the authorization token 925 o The application at www.pcp.example.com must be capable of parsing 926 the authorization token and verifying that this token was issued 927 to the application at www.sleepwell.com 929 o The application at www.pcp.example.com must be capable of 930 retrieving the requested data and returning it to the application 931 at www.sleepwell.example.com 933 3.13. Signature with asymmetric secret 935 Description: 937 Alice accesses an application running on a web server at 938 www.printphotos.example.com and instructs it to print her photographs 939 that are stored on a server www.storephotos.example.com. The 940 application at www.printphotos.example.com, which does not have a 941 shared secret with www.storephotos.example.com, receives Alice's 942 authorization for accessing her photographs without learning her 943 authentication credentials with www.storephotos.example.com. 945 Pre-conditions: 947 o Alice has registered with www.storephotos.example.com to enable 948 authentication 950 o The application at www.printphotos.example.com has a private and a 951 matching public keys 953 Post-conditions: 955 A successful procedure results in the application at 956 www.printphotos.example.com receiving an access token from 957 www.storephotos.example.com for accessing the Alice's photographs. 959 Requirements: 961 o The application at www.printphotos.example.com must be capable of 962 issuing the HTTP redirect requests to Alice's user agent - a 963 browser 965 o The application at www.storephotos.example.com must be able to 966 authenticate Alice 968 o The application running at www.storephotos.example.com must be 969 able to obtain the public key of the application at 970 www.printphotos.example.com 972 o The application running at www.printphotos.example.com is required 973 to sign using its private key the requests to the application at 974 www.storephotos.example.com 976 o The application at www.storephotos.example.com must obtain Alice's 977 authorization of the access to her photos by 978 www.printphotos.example.com 980 o The application at www.storephotos.example.com is required to 981 identify to Alice the scope of access that 982 www.printphotos.example.com has requested while asking for Alice's 983 authorization 985 o The application at www.storephotos.example.com must be able to 986 authenticate the application at www.printphotos.example.com by 987 validating a signature of its request using the public key of 988 www.printphotos.example.com 990 o The application at www.printphotos.example.com must provide a 991 callback URL to the application at www.storephotos.example.com 992 (note: the URL can be pre-registered with 993 www.storephotos.example.com) 995 o The application at www.storephotos.example.com must be capable of 996 issuing the HTTP redirect requests to Alice's browser 998 o Alice's manual involvement in the OAuth authorization procedure 999 (e.g., entering an URL or a password) should not be required. 1000 (Alice's authentication to www.storephotos.example.com is not in 1001 the OAuth scope) 1003 4. Authors of the use cases 1005 The major contributors of the use cases are as follows: 1007 W. Beck, Deutsche Telekom AG 1008 G. Brail, Sonoa Systems 1009 B. de hOra 1010 B. Eaton, Google 1011 S. Farrell, NewBay Software 1012 G. Fletcher, AOL 1013 Y. Goland, Microsoft 1014 B. Goldman, Facebook 1015 E. Hammer-Lahav, Yahoo! 1016 D. Hardt 1017 R. Krikorian, Twitter 1018 T. Lodderstedt, Deutsche Telekom 1019 E. Maler, PayPal 1020 D. Recordon, Facebook 1021 L. Shepard, Facebook 1022 A. Tom, Yahoo! 1023 B. Vrancken, Alcatel-Lucent 1024 Z. Zeltsan, Alcatel-Lucent 1026 5. Security considerations 1028 TBD 1030 6. IANA considerations 1032 This Internet Draft includes no request to IANA. 1034 7. Acknowledgements 1036 The authors thank Igor Faynberg and Hui-Lan Lu for their invaluable 1037 help with preparing this document. Special thanks are to the draft 1038 reviewers Thomas Hardjono and Melinda Shore, whose suggestions have 1039 helped to improve the draft. 1041 8. Normative References 1043 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1044 Requirement Levels", RFC 2119, March 1997. 1046 [I-D.draft-ietf-oauth-v2] 1047 Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth 1048 2.0 Authorization Protocol". 1050 Authors' Addresses 1052 George Fletcher 1053 AOL 1055 Email: gffletch@aol.com 1057 Torsten Lodderstedt 1058 Deutsche Telekom AG 1060 Email: torsten@lodderstedt.net 1062 Zachary Zeltsan 1063 Alcatel-Lucent 1064 600 Mountain Avenue 1065 Murray Hill, New Jersey 1066 USA 1068 Phone: +1 908 582 2359 1069 Email: Zachary.Zeltsan@alcatel-lucent.com