idnits 2.17.1 draft-zeltsan-oauth-use-cases-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 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 4, 2011) is 4820 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 3 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: August 8, 2011 Deutsche Telekom AG 6 Z. Zeltsan 7 Alcatel-Lucent 8 February 4, 2011 10 OAuth Use Cases 11 draft-zeltsan-oauth-use-cases-01 13 Abstract 15 This document lists the OAuth use cases. The document's objective is 16 to identify the use cases that will be a base for deriving the OAuth 17 requirements. The provided list is based on the Internet-Drafts of 18 the OAUTH working group and discussions on the group's mailing list. 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 August 8, 2011. 37 Copyright Notice 39 Copyright (c) 2011 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 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 56 3. OAuth use cases . . . . . . . . . . . . . . . . . . . . . . . 3 57 3.1. Web server . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3.2. User-agent . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.3. In-App-Payment (based on Native Application) . . . . . . . 6 60 3.4. Mobile App . . . . . . . . . . . . . . . . . . . . . . . . 8 61 3.5. Device . . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 3.6. Client password credentials . . . . . . . . . . . . . . . 11 63 3.7. Assertion . . . . . . . . . . . . . . . . . . . . . . . . 11 64 3.8. Content manager . . . . . . . . . . . . . . . . . . . . . 12 65 3.9. Access token exchange . . . . . . . . . . . . . . . . . . 13 66 3.10. Multiple access tokens . . . . . . . . . . . . . . . . . . 15 67 3.11. Gateway for browser-based VoIP applets . . . . . . . . . . 17 68 3.12. Signed Messages . . . . . . . . . . . . . . . . . . . . . 18 69 3.13. Signature with asymmetric secret . . . . . . . . . . . . . 20 70 4. Authors of the use cases . . . . . . . . . . . . . . . . . . . 21 71 5. Security considerations . . . . . . . . . . . . . . . . . . . 22 72 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 22 73 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 74 8. Normative References . . . . . . . . . . . . . . . . . . . . . 22 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 77 1. Introduction 79 The need for documenting the OAuth use cases was discussed at the 80 oauth WG virtual meetings, on the group's mailing list, and at the 81 IETF 77 and IETF 78. This Internet-Draft describes such use cases. 82 The objective of the draft is to initiate discussion that will lead 83 to defining a set of the use cases that the OAuth specifications 84 should support. The following section provides the abbreviated 85 descriptions of the use cases. 87 2. Notational Conventions 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [RFC2119]. 93 3. OAuth use cases 95 This section lists the use cases that have been discussed by the 96 oauth WG. 98 3.1. Web server 100 Description: 102 Alice accesses an application running on a web server at 103 www.printphotos.example.com and instructs it to print her photographs 104 that are stored on a server www.storephotos.example.com. The 105 application at www.printphotos.example.com receives Alice's 106 authorization for accessing her photographs without learning her 107 authentication credentials with www.storephotos.example.com. 109 Pre-conditions: 111 o Alice has registered with www.storephotos.example.com to enable 112 authentication 114 o The application at www.printphotos.example.com has established 115 authentication credentials with the application at 116 www.storephotos.example.com 118 Post-conditions: 120 A successful procedure results in the application 121 www.printphotos.example.com receiving an authorization code from 122 www.storephotos.example.com. The code is bound to the application at 123 www.printphotos.example.com and to the callback URL supplied by the 124 application. The application at www.printphotos.example.com uses the 125 authorization code for obtaining an access token from 126 www.storephotos.example.com. The application at 127 www.storephotos.example.com issues an access token after 128 authenticating the application at www.printphotos.example.com and 129 validating the authorization code that it has submitted. The 130 application at www.printphotos.example.com uses the access token for 131 getting access to Alice's photographs at www.storephotos.example.com. 133 Note: When an access token expires, the service at 134 www.printphotos.example.com needs to repeat the OAuth procedure for 135 getting Alice's authorization to access her photographs at 136 www.storephotos.example.com. Alternatively, if Alice wants to grant 137 the application a long lasting access to her resources at 138 www.storephotos.example.com, the authorization server associated with 139 www.storephotos.example.com may issue the long-living tokens. Those 140 tokens can be exchanged for short-living access tokens required to 141 access www.storephotos.example.com. 143 Requirements: 145 o The server www.printphotos.example.com, which hosts an OAuth 146 client, must be capable of issuing the HTTP redirect requests to 147 Alice's user agent - a browser 149 o Application at www.storephotos.example.com must be able to 150 authenticate Alice. The authentication method is not in the OAuth 151 scope 153 o Application at www.storephotos.example.com must obtain Alice's 154 authorization of the access to her photos by 155 www.printphotos.example.com 157 o Application at www.storephotos.example.com may identify to Alice 158 the scope of access that www.printphotos.example.com has requested 159 while asking for Alice's authorization 161 o Application at www.storephotos.example.com must be able to 162 authenticate the application at www.printphotos.example.com and 163 validate the authorization code before issuing an access token 165 o Application at www.printphotos.example.com must provide a callback 166 URL to the application at www.storephotos.example.com (note: the 167 URL can be pre-registered with www.storephotos.example.com) 169 o Application at www.storephotos.example.com is required to maintain 170 a record that associates the authorization code with the 171 application at www.printphotos.example.com and the callback URL 172 provided by the application 174 o Access tokens are bearer's tokens (they are not associated with a 175 specific application, such as www.printphotos.example.com) and 176 should have a short lifespan 178 o Application at www.storephotos.example.com must invalidate the 179 authorization code after its first use 181 o Alice's manual involvement in the OAuth authorization procedure 182 (e.g., entering an URL or a password) should not be required. 183 (Alice's authentication to www.storephotos.example.com is not in 184 the OAuth scope) 186 3.2. User-agent 188 Description: 190 Alice has installed on her computer a gaming application. She keeps 191 her scores in a database of a social site at www.fun.example.com. In 192 order to upload Alice's scores, the application gets access to the 193 database with her authorization. 195 Pre-conditions: 197 o Alice has installed a gaming application implemented in a 198 scripting language (e.g., JavaScript) that runs in her browser and 199 uses OAuth for accessing a social site at www.fun.example.com 201 o There is no a web site supporting this application and capable of 202 handling the OAuth flow 204 o The installed application is registered with the social site at 205 www.fun.example.com and has an identifier 207 o Alice has registered with www.fun.example.com for identification 208 and authentication 210 o An auxiliary web server at www.help.example.com is reachable by 211 Alice's browser and capable of providing a script that extracts an 212 access token from an URL's fragment 214 Post-conditions: 216 A successful procedure results in Alice's browser receiving an access 217 token. The access token is received from www.fun.example.com as a 218 fragment of a redirection URL of an auxiliary web server 219 www.help.example.com. Alice's browser follows the redirection, but 220 retains the fragment. From the auxiliary web server at 221 www.help.example.com Alice's browser downloads a script that extracts 222 access token from the fragment and makes it available to the gaming 223 application. The application uses the access token to gain access to 224 Alice's data at www.fun.example.com. 226 Requirements: 228 o Registration of the application running in the Alice's browser 229 with the application running on www.fun.example.com is required 230 for identification 232 o Alice's authentication with www.fun.example.com is required 234 o Application running at www.fun.example.com must be able to 235 describe to Alice the request made by the gaming application 236 running on her computer and obtain Alice's authorization for or 237 denial of the requested access 239 o After obtaining Alice's authorization the application running at 240 www.fun.example.com must respond with an access token and redirect 241 Alice's browser to a web server (e.g., www.help.example.com) that 242 is capable of retrieving an access token from an URL 244 3.3. In-App-Payment (based on Native Application) 246 Description: 248 Alice has installed on her computer a gaming application (e.g., 249 running as native code or as a widget). At some point she wants to 250 play the next level of the game and needs to purchase an access to 251 the advanced version of the game from her service provider at 252 www.sp.example.com. With Alice's authorization the application 253 accesses her account at www.sp.example.com and enables her to make 254 the payment. 256 Pre-conditions: 258 o Alice has registered and has an account with her service provider 259 at www.sp.example.com 261 o The application is registered with the service provider at 262 www.sp.example.com. This enables the server provider to provide 263 Alice with all necessary information about the gaming application 264 (including the information about the purchasing price) 266 o Alice has a Web user-agent (e.g., a browser or a widget runtime) 267 installed on her computer 269 Post-conditions: 271 A successful procedure results in the gaming application invoking the 272 user browser and directing it to the authorization server of the 273 service provider. The HTTP message includes information about the 274 gaming application's request to access Alice's account. The 275 authorization server presents to Alice the authentication and 276 authorization interfaces. The authorization interface shows Alice 277 the information about the application's request including the 278 requested charge to her account. After Alice successfully 279 authenticates and authorizes the the request, the authorization 280 server enables Alice to save the transaction details incluing the 281 authorization code issued for the gaming application. Then the 282 authorization server redirects Alice's browser to a custom scheme URI 283 (registered with the operating system). This redirection request 284 contains the authorization code and invokes a special application 285 that is able to extract the authorization code and present it to the 286 gaming application. The gaming application presents the 287 authorization code to the authorization server and exchanges it for 288 an access token. The gaming application then uses the access token 289 to get access to Alice's account and make the charges. 291 Requirements: 293 o An authorization server associated with the server at 294 www.sp.example.com must be able to authenticate Alice 296 o An authorization server associated with the server at 297 www.sp.example.com must be able to provide Alice with the 298 information about the access request that the gaming application 299 has made (this includes the amount that is to be charged to her 300 account with the server provider) 302 o An authorization server associated with the server at 303 www.sp.example.com must be able to obtain Alice's authorization 304 (or denial) of the requested access 306 o * An authorization server associated with the server at 307 www.sp.example.com must enable Alice to save the details of the 308 requested transaction, including the authorization code 310 o An authorization server associated with the server at 311 www.sp.example.com must invalidate the authorization code after 312 its first use 314 o * An authorization server associated with the server at 315 www.sp.example.com must keep a record linking the requested 316 transaction with the authorization code and the respective access 317 token 319 o * An authorization server associated with the server at 320 www.sp.example.com must enable the resource server 321 www.sp.example.com to obtain the transaction information that is 322 linked to the issued access token 324 o * Resource server at www.sp.example.com must invalidate access 325 token after it was used the first time 327 o The gaming application must provide a custom scheme URI to the 328 authorization server associated with www.sp.example.com (note: it 329 can be preregistered with the authorization server) 331 o Alice's manual involvement in the OAuth authorization procedure 332 (e.g., entering an URL or a password) should not be required. 333 (Alice's authentication to www.sp.example.com is not in the OAuth 334 scope) 336 * The requirements denoted by '*' are not common for the Native 337 Application use cases, but are specific to the In-App-Payment use 338 case 340 3.4. Mobile App 342 Description: 344 Alice wants to upload (or download) her photographs to (or from) 345 storephotos.example.com using her smartphone. She downloads and 346 installs a photo app on her smartphone. In order to enable the app 347 to access her photographs, Alice needs to authorize the app to access 348 the web site on her behalf. The authorization shall be valid for a 349 prolonged duration (e.g. several months), so that Alice does not need 350 to authenticate and authorize access on every execution of the app. 351 It shall be possible to withdraw the app's authorization both on the 352 smartphone as well as on the site storephotos.example.com. 354 Pre-conditions: 356 o Alice has installed a (native) photo app application on her 357 smartphone 359 o The installed application is registered with the social site at 360 storephotos.example.com and has an identifier 362 o Alice holds an account with storephotos.example.com 364 o Authentication and authorization shall be performed in a 365 interactive, browser-based process 367 Post-conditions: 369 A successful procedure results in Alice's app receiving an access and 370 a refresh token. The app may obtain the tokens by utilizing either 371 the web server or the user agent flow. The application uses the 372 access token to gain access to Alice's data at 373 storephotos.example.com. The refresh token is persistently stored on 374 the device for use in sub-sequent app executions. If a refresh token 375 exists on app startup, the app directly uses the refresh token to 376 obtain a new access token. 378 Requirements: 380 o Alice's authentication with storephotos.example.com is required 382 o Registration of the application running on Alice's smartphone is 383 required for identification and registration and may be carried 384 out on a per installation base 386 o The application at storephotos.example.com provides a capability 387 to view and delete the apps' authorizations. This implies that 388 the different installations of the same app on the different 389 devices can be distinguished (e.g., by a device name or a 390 telephone number) 392 o The app must provide Alice an option to logout. The logout must 393 result in the revocation of the refresh token on the authorization 394 server 396 o 398 3.5. Device 400 Description: 402 Alice has a device, such as a game console, that does not support an 403 easy data-entry method. She also has an access to a computer with a 404 browser. The application running on the Alice's device gets 405 authorized access to a protected resource (e.g., photographs) stored 406 on a server at www.storephotos.example.com. 408 Pre-conditions: 410 o Alice uses an Oauth-enabled game console, which does not have an 411 easy data-entry method, for accessing her photographs at 412 www.storephotos.example.com. The token issuance process is 413 initiated at the device. 415 o Alice is able to connect to www.storephotos.example.com using a 416 separate device providing an easy data-entry method (e.g., 417 computer), which is equipped with a browser. This device is used 418 to authorize access by the application running on the game console 419 to Alice's photographs. 421 o Application running on Alice's game console has registered with 422 www.storephotos.example.com (has been issued an identifier) 424 o Alice has registered with the application running at 425 www.storephotos.example.com for identification and authentication 427 Post-conditions: Description: 429 A successful procedure results in the application running on Alice's 430 game console receiving an access token that enables access to the 431 photographs on www.storephotos.example.com. 433 Requirements: 435 o Registration of the application running on the game console with 436 the application running on www.storephotos.example.com is required 437 for identification 439 o Application running on the game console must be able to poll 440 periodically the application running at 441 www.storephotos.example.com while waiting for Alice's 442 authorization of the requested access to her photographs. The 443 repeating requests include the application's identifier and the 444 verification code that has been issued by 445 www.storephotos.example.com 447 o Alice is required to use her browser for interacting with the web 448 application running on www.storephotos.example.com. To that end 449 she has to manually direct her browser to the verification URL 450 that is displayed on her game console 452 o Alice's authentication with www.storephotos.example.com is 453 required 455 o After authentication with www.storephotos.example.com Alice, if 456 she wishes to approve the request, which is described in her 457 browser's window, must enter the user code. (The user code is 458 also displayed on her game console along with the verification 459 URL) 461 3.6. Client password credentials 463 Description: 465 The company GoodPay prepares the employee payrolls for the company 466 GoodWork. In order to do that the application at 467 www.GoodPay.example.com gets authenticated access to the employees' 468 attendance data stored at www.GoodWork.example.com. 470 Pre-conditions: 472 o The application at www.GoodPay.example.com has established through 473 a registration an identifier and a shared secret with the 474 application running at www.GoodWork.example.com 476 o The scope of the access by the application at 477 www.GoodPay.example.com to the data stored at 478 www.GoodWork.example.com has been defined 480 Post-conditions: 482 A successful procedure results in the application at 483 www.GoodPay.example.com receiving an access token after 484 authenticating to the application running at 485 www.GoodWork.example.com. 487 Requirements: 489 o Authentication of the application at www.GoodPay.example.com to 490 the application at www.GoodWork.example.com is required 492 o The authentication method must be based on the identifier and 493 shared secret, which the application running at 494 www.GoodPay.example.com submits to the application at 495 www.GoodWork.example.com in the initial HTTP request 497 o Because in this use case GoodPay gets access to GoodWork's 498 sensitive data, GoodWork shall establish trust with GoodPay on the 499 security policy and the authorization method's implementation 501 3.7. Assertion 503 Description: 505 Company GoodPay prepares the employee payrolls for the company 506 GoodWork. In order to do that the application at 507 www.GoodPay.example.com gets authenticated access to the employees' 508 attendance data stored at www.GoodWork.example.com. 509 This use case describes an alternative solution to the one described 510 by the use case Client password credentials. 512 Pre-conditions: 514 o The application at www.GoodPay.example.com has obtained an 515 authentication assertion from a party that is trusted by the 516 application at www.GoodWork.example.com 518 o The scope of the access by the application at 519 www.GoodPay.example.com to the data stored at 520 www.GoodWork.example.com has been defined 522 o The application at www.GoodPay.example.com has established trust 523 relationship with the asserting party and is capable of validating 524 its assertions 526 Post-conditions: 528 A successful procedure results in the application at 529 www.GoodPay.example.com receiving an access token after 530 authenticating to the application running at www.GoodWork.example.com 531 by presenting an assertion (e.g., SAML assertion). 533 Requirements: 535 o Authentication of the application at www.GoodPay.example.com to 536 the application at www.GoodWork.example.com is required 538 o The application running at www.GoodWork.example.com must be 539 capable of validating assertion presented by the application 540 running at www.GoodPay.example.com 542 o Because in this use case GoodPay gets access to GoodWork's 543 sensitive data, GoodWork shall establish trust with GoodPay on the 544 security policy and the authorization method's implementation 546 3.8. Content manager 548 Description: 550 Alice and Bob are having a chat conversation using a content manager 551 application running on a web server at 552 www.contentmanager.example.com. Alice notifies Bob that she wants to 553 share some photographs at www.storephotos.example.com and instructs 554 the application at www.contentmanager.example.com to enable Bob's 555 access to the photographs. The application at 556 www.contentmanager.example.com, after Alice's authorization, obtains 557 an access token for Bob, who uses it to access Alice's photographs at 558 www.storephotos.example.com. 560 Pre-conditions: 562 Alice, Bob the content manager application at 563 www.contentmanager.example.com, and the application at 564 www.storephotos.example.com have registered with the same 565 authorization server for authentication 567 Post-conditions: 569 A successful procedure results in the application at 570 www.contentmanager.example.com receiving an access token that allows 571 access to Alice's photographs at www.storephotos.example.com. The 572 access token is issued by the authorization server after Alice has 573 authorized the content manager at www.contentmanager.example.com to 574 get an access token on Bob's behalf. The access token is passed to 575 Bob by the content manager. Bob uses the access token to view 576 Alice's photographs at www.storephotos.example.com. 578 Requirements: 580 o The server at www.contentmanager.example.com, must be capable of 581 issuing the HTTP redirect requests to Alice's and Bob's user 582 agents - the browsers 584 o The authorization server must be able to authenticate Alice, Bob, 585 and the application at www.contentmanager.example.com 587 o The authorization server is required to obtain Alice's 588 authorization for issuing an access token to 589 www.contentmanager.example.com on Bob's behalf 591 o Authorization server must be able to identify to Alice the scope 592 of access that www.contentmanager.example.com has requested on 593 Bob's behalf while asking for Alice's authorization 595 3.9. Access token exchange 597 Description: 599 Alice uses an application running on www.printphotos.example.com for 600 printing her photographs that are stored on a server at 601 www.storephotos.example.com. The application running on 602 www.storephotos.example.com, while serving the request of the 603 application at www.printphotos.example.com, discovers that some of 604 the requested photographs have been moved to 605 www.storephotos1.example.com. The application at 606 www.storephotos.example.com retrieves the missing photographs from 607 www.storephotos1.example.com and provides access to all requested 608 photographs to the application at www.printphotos.example.com. The 609 application at www.printphotos.example.com carries out Alice's 610 request. 612 Pre-conditions: 614 o The application running on www.printphotos.example.com is capable 615 of interacting with Alice's browser 617 o Alice has registered with and can be authenticated by 618 authorization server 620 o The applications at www.storephotos.example.com has registered 621 with authorization server 623 o The applications at www.storephotos1.example.com has registered 624 with authorization server 626 o The application at www.printphotos.example.com has registered with 627 authorization server 629 Post-conditions: 631 A successful procedure results in the application at 632 www.printphotos.example.com receiving an access token that allows 633 access to Alice's photographs. This access token is used for the 634 following purposes: 636 o By the application running at www.printphotos.example.com to get 637 access to the photographs at www.storephotos.example.com 639 o By the application running at www.storephotos.example.com to 640 obtain from authorization server another access token that allows 641 it to retrieve the additional photographs stored at 642 www.storephotos1.example.com 644 As the result, there are two access token issued for two different 645 applications. The tokens may have different properties (e.g., scope, 646 permissions, and expiration dates). 648 Requirements: 650 o The applications at www.printphotos.example.com and 651 www.storephotos.example.com require different access tokens 653 o The application at www.printphotos.example.com is required to 654 provide its callback URL to the application at 655 www.storephotos.example.com 657 o Authentication of the application at www.printphotos.example.com 658 to the authorization server is required 660 o Alice's authentication by the authorization server is required 662 o The authorization server must be able to describe to Alice the 663 request of the application at www.printphotos.example.com and 664 obtain her authorization (or rejection) 666 o If Alice has authorized the request, the authorization server must 667 be able to issue an access token that enables the application at 668 www.printphotos.example.com to get access to Alice's photographs 669 at www.storephotos.example.com 671 o The authorization server must be able, based on the access token 672 presented by the application at www.printphotos.example.com, to 673 generate another access token that allows the application at 674 www.storephotos.example.com to get access to the photographs at 675 www.storephotos1.example.com. In this context the authorization 676 server must validate the authorization of the application at 677 www.storephotos.example.com to obtain the token. 679 o The application at www.storephotos.example.com must be able to 680 validate an access token presented by the application running at 681 www.printphotos.example.com 683 o The application at www.storephotos1.example.com must be able to 684 validate the access token presented by the application running at 685 www.storephotos.example.com 687 3.10. Multiple access tokens 689 Description: 691 Alice uses a communicator application running on a web server at 692 www.communicator.example.com to access her email service at 693 www.email.example.com and her voice over IP service at 694 www.voip.example.com. Email addresses and telephone numbers are 695 obtained from Alice's address book at www.contacts.example.com. 696 Those web sites all rely on the same authorization server, so the 697 application at www.communicator.example.com can receive a single 698 authorization from Alice for getting access to these three services 699 on her behalf at once. 701 Note: This use case is especially useful for native applications 702 since a web browser needs to be launched only once. 704 Pre-conditions: 706 o The same authorization server serves Alice and all involved 707 servers 709 o Alice has registered with the authorization server for 710 authentication and for authorization of the requests of the 711 communicator application running at www.communicator.example.com 713 o The email application at www.email.example.com has registered with 714 the authorization server for authentication 716 o The VoIP application at www.voip.example.com has registered with 717 the authorization server for authentication 719 o The address book at www.contacts.example.com has registered with 720 the authorization server for authentication 722 Post-conditions: 724 A successful procedure results in the application at 725 www.communicator.example.com receiving three different access tokens: 726 one for accessing the email service at www.email.example.com, one for 727 accessing the contacts at www.contacts.example.com, and one for 728 accessing the VoIP service at www.voip.example.com. 730 Requirements: 732 o The application running at www.communicator.example.com must be 733 authenticated by the authorization server 735 o Alice must be authenticated by the authorization server 737 o The application running at www.communicator.example.com must be 738 able to get a single Alice's authorization for access to the 739 multiple services (e.g., email and VoIP) 741 o The application running at www.communicator.example.com must be 742 able to recognize that all three applications rely on the same 743 authorization server 745 o A callback URL of the application running at 746 www.communicator.example.com must be known to the authorization 747 server 749 o The authorization server must be able to issue the separate 750 service-specific tokens (with different, scope, permissions, and 751 expiration dates) for access to the requested services (such as 752 email and VoIP) 754 3.11. Gateway for browser-based VoIP applets 756 Description: 758 Alice accesses a social site on a web server at 759 www.social.example.com. Her browser loads a VoIP applet that enables 760 her to make a VoIP call using her SIP server at 761 www.sipservice.example.com. The application at 762 www.social.example.com gets Alice's authorization to use her account 763 with www.sipservice.example.com without learning her authentication 764 credentials with www.sipservice.example.com. 766 Pre-conditions: 768 o Alice has registered with www.sipservice.example.com for 769 authentication 771 o The application at www.social.example.com has established 772 authentication credentials with the application at 773 www.sipservice.example.com 775 Post-conditions: 777 A successful procedure results in the application at 778 www.social.example.com receiving access token from 779 www.sipservice.example.com with Alice's authorization. 781 Requirements: 783 o The server at www.social.example.com must be able to redirect 784 Alice's browser to www.sipservice.example.com 786 o The application running at www.sipservice.example.com must be 787 capable of authenticating Alice and obtaining her authorization of 788 a request from www.social.example.com 790 o The server at www.sipservice.example.com must be able to redirect 791 Alice's browser back to www.social.example.com 793 o The application at www.social.example.com must be able to 794 translate the messages of the Alice's VoIP applet into SIP and RTP 795 messages 797 o The application at www.social.example.com must be able to add the 798 access token to the SIP requests that it sends to 799 www.sipservice.example.com 801 o Application at www.sipservice.example.com must be able to 802 authenticate the application at www.social.example.com and 803 validate the access token 805 o Alice's manual involvement in the OAuth authorization procedure 806 (e.g., entering an URL or a password) should not be required. 807 (Alice's authentication to www.sipservice.example.com is not in 808 the OAuth scope) 810 3.12. Signed Messages 812 Description: 814 Alice manages all her personal health records in her personal health 815 data store at www.myhealth.example.com. Alice's Primary Care 816 Physician (PCP), which has a Web site at www.pcp.example.com 817 recommends her to see a sleep specialist (www.sleepwell.example.com). 818 Alice arrives at the sleep specialist's office and authorizes it to 819 access her basic health data at her PCP's web site. The application 820 at www.pcp.example.com verifies that Alice has authorized 821 www.sleepwell.example.com to access her health data as well as 822 enforces that www.sleepwell.example.com is the only application that 823 can retrieve that data with that specific authorization. 825 Pre-conditions: 827 o Alice has a personal health data store that allows for discovery 828 of her participating health systems (e.g. psychiatrist, sleep 829 specialist, PCP, orthodontist, ophthalmologist, etc) 831 o The application at www.myhealth.example.com manages authorization 832 of access to Alice's participating health systems 834 o The application at www.myhealth.example.com can issue 835 authorization tokens understood by Alice's participating health 836 systems 838 o The application at www.pcp.example.com stores Alice's basic health 839 and prescription records 841 o The application at www.sleepwell.com stores results of Alice's 842 sleep tests 844 Post-conditions: 846 o A successful procedure results in just the information that Alice 847 authorized being transferred from the Primary Care Physician 848 (www.pcp.example.com) to the sleep specialist 849 (www.sleepwell.example.com) 851 o The transfer of health data only occurs if the application at 852 www.pcp.example.com can verify that www.sleepwell.example.com is 853 the party requesting access and that the authorization token 854 presented by www.sleepwell.example.com is issued by the 855 application at www.myhealth.example.com with a restricted audience 856 of www.sleepwell.example.com 858 Requirements: 860 o The application at www.sleepwell.example.com interacting with 861 www.myhealth.example.com must be able to discover the location of 862 the PCP system (e.g., XRD discovery) 864 o The application at www.sleepwell.example.com must be capable of 865 requesting Alice's authorization of access to the application at 866 www.pcp.example.com for the purpose of retrieving basic health 867 data (e.g. date-of-birth, weight, height, etc). The mechanism 868 Alice uses to authorize this access is out of scope for this use 869 case 871 o The application at www.myhealth.example.com must be capable of 872 issuing a token bound to www.sleepwell.example.com for access to 873 the application at www.pcp.example.com. Note that a signed token 874 (JWT) can be used to prove who issued the token 876 o The application at www.sleepwell.example.com must be capable of 877 issuing a request (which includes the token issued by 878 www.myhealth.example.com) to the application at 879 www.pcp.example.com 881 o The application at www.sleepwell.example.com must sign the request 882 before sending it to www.pcp.example.com 884 o The application at www.pcp.example.com must be capable of 885 receiving the request and verifying the signature 887 o The application at www.pcp.example.com must be capable of parsing 888 the message and finding the authorization token 890 o The application at www.pcp.example.com must be capable of 891 verifying the signature of the authorization token 893 o The application at www.pcp.example.com must be capable of parsing 894 the authorization token and verifying that this token was issued 895 to the application at www.sleepwell.com 897 o The application at www.pcp.example.com must be capable of 898 retrieving the requested data and returning it to the application 899 at www.sleepwell.example.com 901 3.13. Signature with asymmetric secret 903 Description: 905 Alice accesses an application running on a web server at 906 www.printphotos.example.com and instructs it to print her photographs 907 that are stored on a server www.storephotos.example.com. The 908 application at www.printphotos.example.com, which does not have a 909 shared secret with www.storephotos.example.com, receives Alice's 910 authorization for accessing her photographs without learning her 911 authentication credentials with www.storephotos.example.com. 913 Pre-conditions: 915 o Alice has registered with www.storephotos.example.com to enable 916 authentication 918 o The application at www.printphotos.example.com has a private and a 919 matching public keys 921 Post-conditions: 923 A successful procedure results in the application at 924 www.printphotos.example.com receiving an access token for accessing 925 the Alice's photographs at www.storephotos.example.com. 927 Requirements: 929 o The application at www.printphotos.example.com must be capable of 930 issuing the HTTP redirect requests to Alice's user agent - a 931 browser 933 o The application at www.storephotos.example.com must be able to 934 authenticate Alice 936 o The application running at www.storephotos.example.com must be 937 able to obtain the public key of the application at 938 www.printphotos.example.com 940 o The application running at www.printphotos.example.com is required 941 to sign using its private key the requests to the application at 942 www.storephotos.example.com 944 o The application at www.storephotos.example.com must obtain Alice's 945 authorization of the access to her photos by 946 www.printphotos.example.com 948 o The application at www.storephotos.example.com is required to 949 identify to Alice the scope of access that 950 www.printphotos.example.com has requested while asking for Alice's 951 authorization 953 o The application at www.storephotos.example.com must be able to 954 authenticate the application at www.printphotos.example.com by 955 validating a signature of its request with the public key of 956 www.printphotos.example.com 958 o The application at www.printphotos.example.com must provide a 959 callback URL to the application at www.storephotos.example.com 960 (note: the URL can be pre-registered with 961 www.storephotos.example.com) 963 o The application at www.storephotos.example.com must be capable of 964 issuing the HTTP redirect requests to Alice's browser 966 o Alice's manual involvement in the OAuth authorization procedure 967 (e.g., entering an URL or a password) should not be required. 968 (Alice's authentication to www.storephotos.example.com is not in 969 the OAuth scope) 971 4. Authors of the use cases 973 The major contributors of the use cases are as follows: 975 W. Beck, Deutsche Telekom AG 976 G. Brail, Sonoa Systems 977 B. de hOra 978 B. Eaton, Google 979 S. Farrell, NewBay Software 980 G. Fletcher, AOL 981 Y. Goland, Microsoft 982 B. Goldman, Facebook 983 E. Hammer-Lahav, Yahoo! 984 D. Hardt 985 R. Krikorian, Twitter 986 T. Lodderstedt, Deutsche Telekom 987 E. Maler, PayPal 988 D. Recordon, Facebook 989 L. Shepard, Facebook 990 A. Tom, Yahoo! 991 B. Vrancken, Alcatel-Lucent 992 Z. Zeltsan, Alcatel-Lucent 994 5. Security considerations 996 TBD 998 6. IANA considerations 1000 This Internet Draft includes no request to IANA. 1002 7. Acknowledgements 1004 The authors thank Igor Faynberg and Hui-Lan Lu for their invaluable 1005 help with preparing this document. 1007 8. Normative References 1009 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1010 Requirement Levels", RFC 2119, March 1997. 1012 Authors' Addresses 1014 George Fletcher 1015 AOL 1017 Email: gffletch@aol.com 1019 Dr.-Ing. Torsten Lodderstedt 1020 Deutsche Telekom AG 1022 Email: torsten@lodderstedt.net 1023 Zachary Zeltsan 1024 Alcatel-Lucent 1025 600 Mountain Avenue 1026 Murray Hill, New Jersey 1027 USA 1029 Phone: +1 908 582 2359 1030 Email: Zachary.Zeltsan@alcatel-lucent.com