idnits 2.17.1 draft-zeltsan-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 : ---------------------------------------------------------------------------- No issues found here. 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 (October 5, 2010) is 4951 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 T. Lodderstedt 3 Internet-Draft Deutsche Telekom AG 4 Intended status: Informational Z. Zeltsan 5 Expires: April 8, 2011 Alcatel-Lucent 6 October 5, 2010 8 OAuth Use Cases 9 draft-zeltsan-oauth-use-cases-00 11 Abstract 13 This document lists the OAuth use cases. The document's objective is 14 to identify the use cases that will be a base for deriving the OAuth 15 requirements. The provided list is based on the Internet-Drafts of 16 the OAUTH working group and discussions on the group's mailing list. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 8, 2011. 35 Copyright Notice 37 Copyright (c) 2010 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 54 3. OAuth use cases . . . . . . . . . . . . . . . . . . . . . . . 3 55 3.1. Web server . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3.2. User-agent . . . . . . . . . . . . . . . . . . . . . . . . 5 57 3.3. Mobile App . . . . . . . . . . . . . . . . . . . . . . . . 6 58 3.4. Device . . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 3.5. Client password credentials . . . . . . . . . . . . . . . 9 60 3.6. Assertion . . . . . . . . . . . . . . . . . . . . . . . . 9 61 3.7. Content manager . . . . . . . . . . . . . . . . . . . . . 10 62 3.8. Access token exchange . . . . . . . . . . . . . . . . . . 11 63 3.9. Multiple access tokens . . . . . . . . . . . . . . . . . . 13 64 3.10. Gateway for browser-based VoIP applets . . . . . . . . . . 15 65 3.11. Signature with asymmetric secret . . . . . . . . . . . . . 16 66 4. Authors of the use cases . . . . . . . . . . . . . . . . . . . 17 67 5. Security considerations . . . . . . . . . . . . . . . . . . . 18 68 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18 69 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 70 8. Normative References . . . . . . . . . . . . . . . . . . . . . 18 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 73 1. Introduction 75 The need for documenting the OAuth use cases was discussed at the 76 oauth WG virtual meetings, on the group's mailing list, and at the 77 IETF 77 and IETF 78. This Internet-Draft describes such use cases. 78 The objective of the draft is to initiate discussion that will lead 79 to defining a set of the use cases that the OAuth specifications 80 should support. The following section provides the abbreviated 81 descriptions of the use cases. 83 2. Notational Conventions 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in [RFC2119]. 89 3. OAuth use cases 91 This section lists the use cases that have been discussed by the 92 oauth WG. 94 3.1. Web server 96 Description: 98 Alice accesses an application running on a web server at 99 www.printphotos.example.com and instructs it to print her photographs 100 that are stored on a server www.storephotos.example.com. The 101 application at www.printphotos.example.com receives Alice's 102 authorization for accessing her photographs without learning her 103 authentication credentials with www.storephotos.example.com. 105 Pre-conditions: 107 o Alice has registered with www.storephotos.example.com to enable 108 authentication 110 o The application at www.printphotos.example.com has established 111 authentication credentials with the application at 112 www.storephotos.example.com 114 Post-conditions: 116 A successful procedure results in the application 117 www.printphotos.example.com receiving an authorization code from 118 www.storephotos.example.com. The code is bound to the application at 119 www.printphotos.example.com and to the callback URL supplied by the 120 application. The application at www.printphotos.example.com uses the 121 authorization code for obtaining an access token from 122 www.storephotos.example.com. The application at 123 www.storephotos.example.com issues an access token after 124 authenticating the application at www.printphotos.example.com and 125 validating the authorization code that it has submitted. The 126 application at www.printphotos.example.com uses the access token for 127 getting access to Alice's photographs at www.storephotos.example.com. 129 Note: When an access token expires, the service at 130 www.printphotos.example.com needs to repeat the OAuth procedure for 131 getting Alice's authorization to access her photographs at 132 www.storephotos.example.com. Alternatively, if Alice wants to grant 133 the application a long lasting access to her resources at 134 www.storephotos.example.com, the authorization server associated with 135 www.storephotos.example.com may issue the long-living tokens. Those 136 tokens can be exchanged for short-living access tokens required to 137 access www.storephotos.example.com. 139 Requirements: 141 o The server www.printphotos.example.com, which hosts an OAuth 142 client, must be capable of issuing the HTTP redirect requests to 143 Alice's user agent - a browser 145 o Application at www.storephotos.example.com must be able to 146 authenticate Alice. The authentication method is not in the OAuth 147 scope 149 o Application at www.storephotos.example.com must obtain Alice's 150 authorization of the access to her photos by 151 www.printphotos.example.com 153 o Application at www.storephotos.example.com may identify to Alice 154 the scope of access that www.printphotos.example.com has requested 155 while asking for Alice's authorization 157 o Application at www.storephotos.example.com must be able to 158 authenticate the application at www.printphotos.example.com and 159 validate the authorization code before issuing an access token 161 o Application at www.printphotos.example.com must provide a callback 162 URL to the application at www.storephotos.example.com (note: the 163 URL can be pre-registered with www.storephotos.example.com) 165 o Application at www.storephotos.example.com is required to maintain 166 a record that associates the authorization code with the 167 application at www.printphotos.example.com and the callback URL 168 provided by the application 170 o Access tokens are bearer's tokens (they are not associated with a 171 specific application, such as www.printphotos.example.com) and 172 should have a short lifespan 174 o Application at www.storephotos.example.com must invalidate the 175 authorization code after its first use 177 o Alice's manual involvement in the OAuth authorization procedure 178 (e.g., entering an URL or a password) should not be required. 179 (Alice's authentication to www.storephotos.example.com is not in 180 the OAuth scope) 182 3.2. User-agent 184 Description: 186 Alice has installed on her computer a gaming application. She keeps 187 her scores in a database of a social site at www.fun.example.com. In 188 order to upload Alice's scores, the application gets access to the 189 database with her authorization. 191 Pre-conditions: 193 o Alice has installed a gaming application implemented in a 194 scripting language (e.g., JavaScript) that runs in her browser and 195 uses OAuth for accessing a social site at www.fun.example.com 197 o There is no a web site supporting this application and capable of 198 handling the OAuth flow 200 o The installed application is registered with the social site at 201 www.fun.example.com and has an identifier 203 o Alice has registered with www.fun.example.com for identification 204 and authentication 206 o An auxiliary web server at www.help.example.com is reachable by 207 Alice's browser and capable of providing a script that extracts an 208 access token from an URL's fragment 210 Post-conditions: 212 A successful procedure results in Alice's browser receiving an access 213 token. The access token is received from www.fun.example.com as a 214 fragment of a redirection URL of an auxiliary web server 215 www.help.example.com. Alice's browser follows the redirection, but 216 retains the fragment. From the auxiliary web server at 217 www.help.example.com Alice's browser downloads a script that extracts 218 access token from the fragment and makes it available to the gaming 219 application. The application uses the access token to gain access to 220 Alice's data at www.fun.example.com. 222 Requirements: 224 o Registration of the application running in the Alice's browser 225 with the application running on www.fun.example.com is required 226 for identification 228 o Alice's authentication with www.fun.example.com is required 230 o Application running at www.fun.example.com must be able to 231 describe to Alice the request made by the gaming application 232 running on her computer and obtain Alice's authorization for or 233 denial of the requested access 235 o After obtaining Alice's authorization the application running at 236 www.fun.example.com must respond with an access token and redirect 237 Alice's browser to a web server (e.g., www.help.example.com) that 238 is capable of retrieving an access token from an URL 240 3.3. Mobile App 242 Description: 244 Alice wants to upload (or download) her photographs to (or from) 245 storephotos.example.com using her smartphone. She downloads and 246 installs a photo app on her smartphone. In order to enable the app 247 to access her photographs, Alice needs to authorize the app to access 248 the web site on her behalf. The authorization shall be valid for a 249 prolonged duration (e.g. several months), so that Alice does not need 250 to authenticate and authorize access on every execution of the app. 251 It shall be possible to withdraw the app's authorization both on the 252 smartphone as well as on the site storephotos.example.com. 254 Pre-conditions: 256 o Alice has installed a (native) photo app application on her 257 smartphone 259 o The installed application is registered with the social site at 260 storephotos.example.com and has an identifier 262 o Alice holds an account with storephotos.example.com 264 o Authentication and authorization shall be performed in a 265 interactive, browser-based process 267 Post-conditions: 269 A successful procedure results in Alice's app receiving an access and 270 a refresh token. The app may obtain the tokens by utilizing either 271 the web server or the user agent flow. The application uses the 272 access token to gain access to Alice's data at 273 storephotos.example.com. The refresh token is persistently stored on 274 the device for use in sub-sequent app executions. If a refresh token 275 exists on app startup, the app directly uses the refresh token to 276 obtain a new access token. 278 Requirements: 280 o Alice's authentication with www.fun.example.com is required 282 o Registration of the application running on Alice's smartphone is 283 required for identification and registration and may be carried 284 out on a per installation base 286 o The application at storephotos.example.com provides a capability 287 to view and delete the apps' authorizations. This implies that 288 the different installations of the same app on the different 289 devices can be distinguished (e.g., by a device name or a 290 telephone number) 292 o The app must provide Alice an option to logout. The logout must 293 result in the revocation of the refresh token on the authorization 294 server 296 o 298 3.4. Device 300 Description: 302 Alice has a device, such as a game console, that does not support an 303 easy data-entry method. She also has an access to a computer with a 304 browser. The application running on the Alice's device gets 305 authorized access to a protected resource (e.g., photographs) stored 306 on a server at www.storephotos.example.com. 308 Pre-conditions: 310 o Alice uses an Oauth-enabled game console, which does not have an 311 easy data-entry method, for accessing her photographs at 312 www.storephotos.example.com. The token issuance process is 313 initiated at the device. 315 o Alice is able to connect to www.storephotos.example.com using a 316 separate device providing an easy data-entry method (e.g., 317 computer), which is equipped with a browser. This device is used 318 to authorize access by the application running on the game console 319 to Alice's photographs. 321 o Application running on Alice's game console has registered with 322 www.storephotos.example.com (has been issued an identifier) 324 o Alice has registered with the application running at 325 www.storephotos.example.com for identification and authentication 327 Post-conditions: Description: 329 A successful procedure results in the application running on Alice's 330 game console receiving an access token that enables access to the 331 photographs on www.storephotos.example.com. 333 Requirements: 335 o Registration of the application running on the game console with 336 the application running on www.storephotos.example.com is required 337 for identification 339 o Application running on the game console must be able to poll 340 periodically the application running at 341 www.storephotos.example.com while waiting for Alice's 342 authorization of the requested access to her photographs. The 343 repeating requests include the application's identifier and the 344 verification code that has been issued by 345 www.storephotos.example.com 347 o Alice is required to use her browser for interacting with the web 348 application running on www.storephotos.example.com. To that end 349 she has to manually direct her browser to the verification URL 350 that is displayed on her game console 352 o Alice's authentication with www.storephotos.example.com is 353 required 355 o After authentication with www.storephotos.example.com Alice, if 356 she wishes to approve the request, which is described in her 357 browser's window, must enter the user code. (The user code is 358 also displayed on her game console along with the verification 359 URL) 361 3.5. Client password credentials 363 Description: 365 The company GoodPay prepares the employee payrolls for the company 366 GoodWork. In order to do that the application at 367 www.GoodPay.example.com gets authenticated access to the employees' 368 attendance data stored at www.GoodWork.example.com. 370 Pre-conditions: 372 o The application at www.GoodPay.example.com has established through 373 a registration an identifier and a shared secret with the 374 application running at www.GoodWork.example.com 376 o The scope of the access by the application at 377 www.GoodPay.example.com to the data stored at 378 www.GoodWork.example.com has been defined 380 Post-conditions: 382 A successful procedure results in the application at 383 www.GoodPay.example.com receiving an access token after 384 authenticating to the application running at 385 www.GoodWork.example.com. 387 Requirements: 389 o Authentication of the application at www.GoodPay.example.com to 390 the application at www.GoodWork.example.com is required 392 o The authentication method must be based on the identifier and 393 shared secret, which the application running at 394 www.GoodPay.example.com submits to the application at 395 www.GoodWork.example.com in the initial HTTP request 397 o Because in this use case GoodPay gets access to GoodWork's 398 sensitive data, GoodWork shall establish trust with GoodPay on the 399 security policy and the authorization method's implementation 401 3.6. Assertion 403 Description: 405 Company GoodPay prepares the employee payrolls for the company 406 GoodWork. In order to do that the application at 407 www.GoodPay.example.com gets authenticated access to the employees' 408 attendance data stored at www.GoodWork.example.com. 409 This use case describes an alternative solution to the one described 410 by the use case Client password credentials. 412 Pre-conditions: 414 o The application at www.GoodPay.example.com has obtained an 415 authentication assertion from a party that is trusted by the 416 application at www.GoodWork.example.com 418 o The scope of the access by the application at 419 www.GoodPay.example.com to the data stored at 420 www.GoodWork.example.com has been defined 422 o The application at www.GoodPay.example.com has established trust 423 relationship with the asserting party and is capable of validating 424 its assertions 426 Post-conditions: 428 A successful procedure results in the application at 429 www.GoodPay.example.com receiving an access token after 430 authenticating to the application running at www.GoodWork.example.com 431 by presenting an assertion (e.g., SAML assertion). 433 Requirements: 435 o Authentication of the application at www.GoodPay.example.com to 436 the application at www.GoodWork.example.com is required 438 o The application running at www.GoodWork.example.com must be 439 capable of validating assertion presented by the application 440 running at www.GoodPay.example.com 442 o Because in this use case GoodPay gets access to GoodWork's 443 sensitive data, GoodWork shall establish trust with GoodPay on the 444 security policy and the authorization method's implementation 446 3.7. Content manager 448 Description: 450 Alice and Bob are having a chat conversation using a content manager 451 application running on a web server at 452 www.contentmanager.example.com. Alice notifies Bob that she wants to 453 share some photographs at www.storephotos.example.com and instructs 454 the application at www.contentmanager.example.com to enable Bob's 455 access to the photographs. The application at 456 www.contentmanager.example.com, after Alice's authorization, obtains 457 an access token for Bob, who uses it to access Alice's photographs at 458 www.storephotos.example.com. 460 Pre-conditions: 462 Alice, Bob the content manager application at 463 www.contentmanager.example.com, and the application at 464 www.storephotos.example.com have registered with the same 465 authorization server for authentication 467 Post-conditions: 469 A successful procedure results in the application at 470 www.contentmanager.example.com receiving an access token that allows 471 access to Alice's photographs at www.storephotos.example.com. The 472 access token is issued by the authorization server after Alice has 473 authorized the content manager at www.contentmanager.example.com to 474 get an access token on Bob's behalf. The access token is passed to 475 Bob by the content manager. Bob uses the access token to view 476 Alice's photographs at www.storephotos.example.com. 478 Requirements: 480 o The server at www.contentmanager.example.com, must be capable of 481 issuing the HTTP redirect requests to Alice's and Bob's user 482 agents - the browsers 484 o The authorization server must be able to authenticate Alice, Bob, 485 and the application at www.contentmanager.example.com 487 o The authorization server is required to obtain Alice's 488 authorization for issuing an access token to 489 www.contentmanager.example.com on Bob's behalf 491 o Authorization server must be able to identify to Alice the scope 492 of access that www.contentmanager.example.com has requested on 493 Bob's behalf while asking for Alice's authorization 495 3.8. Access token exchange 497 Description: 499 Alice uses an application running on www.printphotos.example.com for 500 printing her photographs that are stored on a server at 501 www.storephotos.example.com. The application running on 502 www.storephotos.example.com, while serving the request of the 503 application at www.printphotos.example.com, discovers that some of 504 the requested photographs have been moved to 505 www.storephotos1.example.com. The application at 506 www.storephotos.example.com retrieves the missing photographs from 507 www.storephotos1.example.com and provides access to all requested 508 photographs to the application at www.printphotos.example.com. The 509 application at www.printphotos.example.com carries out Alice's 510 request. 512 Pre-conditions: 514 o The application running on www.printphotos.example.com is capable 515 of interacting with Alice's browser 517 o Alice has registered with and can be authenticated by 518 authorization server 520 o The applications at www.storephotos.example.com has registered 521 with authorization server 523 o The applications at www.storephotos1.example.com has registered 524 with authorization server 526 o The application at www.printphotos.example.com has registered with 527 authorization server 529 Post-conditions: 531 A successful procedure results in the application at 532 www.printphotos.example.com receiving an access token that allows 533 access to Alice's photographs. This access token is used for the 534 following purposes: 536 o By the application running at www.printphotos.example.com to get 537 access to the photographs at www.storephotos.example.com 539 o By the application running at www.storephotos.example.com to 540 obtain from authorization server another access token that allows 541 it to retrieve the additional photographs stored at 542 www.storephotos1.example.com 544 As the result, there are two access token issued for two different 545 applications. The tokens may have different properties (e.g., scope, 546 permissions, and expiration dates). 548 Requirements: 550 o The applications at www.printphotos.example.com and 551 www.storephotos.example.com require different access tokens 553 o The application at www.printphotos.example.com is required to 554 provide its callback URL to the application at 555 www.storephotos.example.com 557 o Authentication of the application at www.printphotos.example.com 558 to the authorization server is required 560 o Alice's authentication by the authorization server is required 562 o The authorization server must be able to describe to Alice the 563 request of the application at www.printphotos.example.com and 564 obtain her authorization (or rejection) 566 o If Alice has authorized the request, the authorization server must 567 be able to issue an access token that enables the application at 568 www.printphotos.example.com to get access to Alice's photographs 569 at www.storephotos.example.com 571 o The authorization server must be able, based on the access token 572 presented by the application at www.printphotos.example.com, to 573 generate another access token that allows the application at 574 www.storephotos.example.com to get access to the photographs at 575 www.storephotos1.example.com. In this context the authorization 576 server must validate the authorization of the application at 577 www.storephotos.example.com to obtain the token. 579 o The application at www.storephotos.example.com must be able to 580 validate an access token presented by the application running at 581 www.printphotos.example.com 583 o The application at www.storephotos1.example.com must be able to 584 validate the access token presented by the application running at 585 www.storephotos.example.com 587 3.9. Multiple access tokens 589 Description: 591 Alice uses a communicator application running on a web server at 592 www.communicator.example.com to access her email service at 593 www.email.example.com and her voice over IP service at 594 www.voip.example.com. Email addresses and telephone numbers are 595 obtained from Alice's address book at www.contacts.example.com. 596 Those web sites all rely on the same authorization server, so the 597 application at www.communicator.example.com can receive a single 598 authorization from Alice for getting access to these three services 599 on her behalf at once. 601 Note: This use case is especially useful for native applications 602 since a web browser needs to be launched only once. 604 Pre-conditions: 606 o The same authorization server serves Alice and all involved 607 servers 609 o Alice has registered with the authorization server for 610 authentication and for authorization of the requests of the 611 communicator application running at www.communicator.example.com 613 o The email application at www.email.example.com has registered with 614 the authorization server for authentication 616 o The VoIP application at www.voip.example.com has registered with 617 the authorization server for authentication 619 o The address book at www.contacts.example.com has registered with 620 the authorization server for authentication 622 Post-conditions: 624 A successful procedure results in the application at 625 www.communicator.example.com receiving three different access tokens: 626 one for accessing the email service at www.email.example.com, one for 627 accessing the contacts at www.contacts.example.com, and one for 628 accessing the VoIP service at www.voip.example.com. 630 Requirements: 632 o The application running at www.communicator.example.com must be 633 authenticated by the authorization server 635 o Alice must be authenticated by the authorization server 637 o The application running at www.communicator.example.com must be 638 able to get a single Alice's authorization for access to the 639 multiple services (e.g., email and VoIP) 641 o The application running at www.communicator.example.com must be 642 able to recognize that all three applications rely on the same 643 authorization server 645 o A callback URL of the application running at 646 www.communicator.example.com must be known to the authorization 647 server 649 o The authorization server must be able to issue the separate 650 service-specific tokens (with different, scope, permissions, and 651 expiration dates) for access to the requested services (such as 652 email and VoIP) 654 3.10. Gateway for browser-based VoIP applets 656 Description: 658 Alice accesses a social site on a web server at 659 www.social.example.com. Her browser loads a VoIP applet that enables 660 her to make a VoIP call using her SIP server at 661 www.sipservice.example.com. The application at 662 www.social.example.com gets Alice's authorization to use her account 663 with www.sipservice.example.com without learning her authentication 664 credentials with www.sipservice.example.com. 666 Pre-conditions: 668 o Alice has registered with www.sipservice.example.com for 669 authentication 671 o The application at www.social.example.com has established 672 authentication credentials with the application at 673 www.sipservice.example.com 675 Post-conditions: 677 A successful procedure results in the application at 678 www.social.example.com receiving access token from 679 www.sipservice.example.com with Alice's authorization. 681 Requirements: 683 o The server at www.social.example.com must be able to redirect 684 Alice's browser to www.sipservice.example.com 686 o The application running at www.sipservice.example.com must be 687 capable of authenticating Alice and obtaining her authorization of 688 a request from www.social.example.com 690 o The server at www.sipservice.example.com must be able to redirect 691 Alice's browser back to www.social.example.com 693 o The application at www.social.example.com must be able to 694 translate the messages of the Alice's VoIP applet into SIP and RTP 695 messages 697 o The application at www.social.example.com must be able to add the 698 access token to the SIP requests that it sends to 699 www.sipservice.example.com 701 o Application at www.sipservice.example.com must be able to 702 authenticate the application at www.social.example.com and 703 validate the access token 705 o Alice's manual involvement in the OAuth authorization procedure 706 (e.g., entering an URL or a password) should not be required. 707 (Alice's authentication to www.sipservice.example.com is not in 708 the OAuth scope) 710 3.11. Signature with asymmetric secret 712 Description: 714 Alice accesses an application running on a web server at 715 www.printphotos.example.com and instructs it to print her photographs 716 that are stored on a server www.storephotos.example.com. The 717 application at www.printphotos.example.com, which does not have a 718 shared secret with www.storephotos.example.com, receives Alice's 719 authorization for accessing her photographs without learning her 720 authentication credentials with www.storephotos.example.com. 722 Pre-conditions: 724 o Alice has registered with www.storephotos.example.com to enable 725 authentication 727 o The application at www.printphotos.example.com has a private and a 728 matching public keys 730 Post-conditions: 732 A successful procedure results in the application at 733 www.printphotos.example.com receiving an access token for accessing 734 the Alice's photographs at www.storephotos.example.com. 736 Requirements: 738 o The application at www.printphotos.example.com must be capable of 739 issuing the HTTP redirect requests to Alice's user agent - a 740 browser 742 o The application at www.storephotos.example.com must be able to 743 authenticate Alice 745 o The application running at www.storephotos.example.com must be 746 able to obtain the public key of the application at 747 www.printphotos.example.com 749 o The application running at www.printphotos.example.com is required 750 to sign using its private key the requests to the application at 751 www.storephotos.example.com 753 o The application at www.storephotos.example.com must obtain Alice's 754 authorization of the access to her photos by 755 www.printphotos.example.com 757 o The application at www.storephotos.example.com is required to 758 identify to Alice the scope of access that 759 www.printphotos.example.com has requested while asking for Alice's 760 authorization 762 o The application at www.storephotos.example.com must be able to 763 authenticate the application at www.printphotos.example.com by 764 validating a signature of its request with the public key of 765 www.printphotos.example.com 767 o The application at www.printphotos.example.com must provide a 768 callback URL to the application at www.storephotos.example.com 769 (note: the URL can be pre-registered with 770 www.storephotos.example.com) 772 o The application at www.storephotos.example.com must be capable of 773 issuing the HTTP redirect requests to Alice's browser 775 o Alice's manual involvement in the OAuth authorization procedure 776 (e.g., entering an URL or a password) should not be required. 777 (Alice's authentication to www.storephotos.example.com is not in 778 the OAuth scope) 780 4. Authors of the use cases 782 The major contributors of the use cases are as follows: 784 W. Beck, Deutsche Telekom AG 785 G. Brail, Sonoa Systems 786 B. de hOra 787 B. Eaton, Google 788 S. Farrell, NewBay Software 789 Y. Goland, Microsoft 790 B. Goldman, Facebook 791 E. Hammer-Lahav, Yahoo! 792 D. Hardt 793 R. Krikorian, Twitter 794 T. Lodderstedt, Deutsche Telekom 795 E. Maler, PayPal 796 D. Recordon, Facebook 797 L. Shepard, Facebook 798 A. Tom, Yahoo! 799 B. Vrancken, Alcatel-Lucent 800 Z. Zeltsan, Alcatel-Lucent 802 5. Security considerations 804 TBD 806 6. IANA considerations 808 This Internet Draft includes no request to IANA. 810 7. Acknowledgements 812 The authors thank Igor Faynberg and Hui-Lan Lu for their invaluable 813 help with preparing this document. 815 8. Normative References 817 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 818 Requirement Levels", RFC 2119, March 1997. 820 Authors' Addresses 822 Dr.-Ing. Torsten Lodderstedt 823 Deutsche Telekom AG 825 Email: torsten@lodderstedt.net 826 Zachary Zeltsan 827 Alcatel-Lucent 828 600 Mountain Avenue 829 Murray Hill, New Jersey 830 USA 832 Phone: +1 908 582 2359 833 Email: Zachary.Zeltsan@alcatel-lucent.com