idnits 2.17.1 draft-ietf-oauth-use-cases-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 166: '...tion method that MAY be used for such ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2012) is 4203 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-ietf-oauth-v2-threatmodel-07 == Outdated reference: A later version (-18) exists of draft-ietf-oauth-assertions-05 == Outdated reference: A later version (-23) exists of draft-ietf-oauth-saml2-bearer-14 == Outdated reference: A later version (-12) exists of draft-ietf-oauth-jwt-bearer-02 Summary: 1 error (**), 0 flaws (~~), 6 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: April 25, 2013 Deutsche Telekom AG 6 Z. Zeltsan 7 Alcatel-Lucent 8 October 22, 2012 10 OAuth Use Cases 11 draft-ietf-oauth-use-cases-03 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 April 25, 2013. 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. OAuth use cases . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Web server . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.2. User-agent . . . . . . . . . . . . . . . . . . . . . . . . 5 57 2.3. Native Application . . . . . . . . . . . . . . . . . . . . 6 58 2.4. In-App-Payment (based on Native Application) . . . . . . . 8 59 2.5. Device with an input method . . . . . . . . . . . . . . . 10 60 2.6. Client password (shared secret) credentials . . . . . . . 12 61 2.7. Assertion . . . . . . . . . . . . . . . . . . . . . . . . 12 62 2.8. Access token exchange . . . . . . . . . . . . . . . . . . 13 63 2.9. Multiple access tokens . . . . . . . . . . . . . . . . . . 15 64 2.10. Gateway for browser-based VoIP applets . . . . . . . . . . 17 65 2.11. Signed Messages . . . . . . . . . . . . . . . . . . . . . 18 66 2.12. Signature with asymmetric secret . . . . . . . . . . . . . 20 67 3. Authors of the use cases . . . . . . . . . . . . . . . . . . . 21 68 4. Security considerations . . . . . . . . . . . . . . . . . . . 22 69 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 22 70 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 72 7.1. Normative References . . . . . . . . . . . . . . . . . . . 22 73 7.2. Informative References . . . . . . . . . . . . . . . . . . 23 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 76 1. Introduction 78 This document describes the use cases that have been discussed on the 79 oauth WG mailing list and introduced by the Internet Drafts submitted 80 to the group. The selected use cases illustrate the use of the OAuth 81 flows by the clients of the various profiles and types. The document 82 also includes those cases that are not directly supported by the 83 OAuth 2.0 [I-D.ietf-oauth-v2], but were considered during its 84 development. The document provides a list of the requirements 85 derived from the use cases. The use cases supported by OAuth 2.0 are 86 indicated. 88 The document's objective is to help with understanding of the OAuth 89 2.0 protocol design. 91 The following section provides the abbreviated descriptions of the 92 use cases. 94 2. OAuth use cases 96 This section describes the use cases that have been discussed by the 97 oauth WG. 99 2.1. Web server 101 Description: 103 Alice accesses an application running on a web server at 104 www.printphotos.example and instructs it to print her photographs 105 that are stored on a server www.storephotos.example. The application 106 at www.printphotos.example receives Alice's authorization for 107 accessing her photographs without learning her authentication 108 credentials with www.storephotos.example. 110 Pre-conditions: 112 o Alice has registered with www.storephotos.example to enable 113 authentication 115 o The application at www.printphotos.example has established 116 authentication credentials with the application at 117 www.storephotos.example 119 Post-conditions: 121 A successful procedure results in the application 122 www.printphotos.example receiving an authorization code from 123 www.storephotos.example. The code is bound to the application at 124 www.printphotos.example and to the callback URL supplied by the 125 application. The application at www.printphotos.example uses the 126 authorization code for obtaining an access token from 127 www.storephotos.example. The application at www.storephotos.example 128 issues an access token after authenticating the application at 129 www.printphotos.example and validating the authorization code that it 130 has submitted. The application at www.printphotos.example uses the 131 access token for getting access to Alice's photographs at 132 www.storephotos.example. 134 Note: When an access token expires, the service at 135 www.printphotos.example needs to repeat the OAuth procedure for 136 getting Alice's authorization to access her photographs at 137 www.storephotos.example. Alternatively, if Alice wants to grant the 138 application a long lasting access to her resources at 139 www.storephotos.example, the authorization server associated with 140 www.storephotos.example may issue the long-living tokens. Those 141 tokens can be exchanged for short-living access tokens required to 142 access www.storephotos.example. 144 Requirements: 146 o The server www.printphotos.example, which hosts an OAuth client, 147 must be capable of issuing the HTTP redirect requests to Alice's 148 user agent - a browser 150 o Application at www.storephotos.example must be able to 151 authenticate Alice. The authentication method is not in the OAuth 152 scope 154 o Application at www.storephotos.example must obtain Alice's 155 authorization of the access to her photos by 156 www.printphotos.example 158 o Application at www.storephotos.example may identify to Alice the 159 scope of access that www.printphotos.example has requested while 160 asking for Alice's authorization 162 o Application at www.storephotos.example must be able to 163 authenticate the application at www.printphotos.example and 164 validate the authorization code before issuing an access token. 165 The OAuth 2.0 protocol [I-D.ietf-oauth-v2] specifies one 166 authentication method that MAY be used for such authentication - 167 Client Password Authentication. 169 o Application at www.printphotos.example must provide a callback URL 170 to the application at www.storephotos.example (note: the URL can 171 be pre-registered with www.storephotos.example) 173 o Application at www.storephotos.example is required to maintain a 174 record that associates the authorization code with the application 175 at www.printphotos.example and the callback URL provided by the 176 application 178 o Access tokens are bearer's tokens (they are not associated with a 179 specific application, such as www.printphotos.example) and should 180 have a short lifespan 182 o Application at www.storephotos.example must invalidate the 183 authorization code after its first use 185 o Alice's manual involvement in the OAuth authorization procedure 186 (e.g., entering an URL or a password) should not be required. 187 (Alice's authentication to www.storephotos.example is not in the 188 OAuth scope. Her registration with www.storephotos.example is 189 required as a pre-condition) 191 Note: OAuth 2.0 supports this use case 193 2.2. User-agent 195 Description: 197 Alice has on her computer a gaming application. She keeps her scores 198 in a database of a social site at www.fun.example. In order to 199 upload Alice's scores, the application gets access to the database 200 with her authorization. 202 Pre-conditions: 204 o Alice uses a gaming application implemented in a scripting 205 language (e.g., JavaScript) that runs in her browser and uses 206 OAuth for accessing a social site at www.fun.example 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 application is registered with the social site at 213 www.fun.example and has an identifier 215 o Alice has registered with www.fun.example for identification and 216 authentication 218 o An auxiliary web server at www.help.example 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 as a 226 fragment of a redirection URL of an auxiliary web server 227 www.help.example. Alice's browser follows the redirection, but 228 retains the fragment. From the auxiliary web server at 229 www.help.example 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. 234 Requirements: 236 o Registration of the application running in the Alice's browser 237 with the application running on www.fun.example is required for 238 identification 240 o Alice's authentication with www.fun.example is required 242 o Application running at www.fun.example must be able to describe to 243 Alice the request made by the gaming application running on her 244 computer and obtain Alice's authorization for or denial of the 245 requested access 247 o After obtaining Alice's authorization the application running at 248 www.fun.example must respond with an access token and redirect 249 Alice's browser to a web server (e.g., www.help.example) that is 250 capable of retrieving an access token from an URL 252 Note: OAuth 2.0 supports this use case 254 2.3. Native Application 256 Description: 258 Alice wants to upload (or download) her photographs to (or from) 259 storephotos.example using her smartphone. She downloads and installs 260 a photo app on her smartphone. In order to enable the app to access 261 her photographs, Alice needs to authorize the app to access the web 262 site on her behalf. The authorization shall be valid for a prolonged 263 duration (e.g. several months), so that Alice does not need to 264 authenticate and authorize access on every execution of the app. It 265 shall be possible to withdraw the app's authorization both on the 266 smartphone as well as on the site storephotos.example. 268 Pre-conditions: 270 o Alice has installed a (native) photo app application on her 271 smartphone 273 o The installed application is registered with the social site at 274 storephotos.example and has an identifier 276 o Alice holds an account with storephotos.example 278 o Authentication and authorization shall be performed in an 279 interactive, browser-based process. The smartphone's browser is 280 used for authenticating Alice and for enabling her to authorize 281 the request by the Mobile App 283 Post-conditions: 285 A successful procedure results in Alice's app receiving the access 286 and refresh tokens. The app obtains the tokens by utilizing the 287 Authorization Code flow. The application uses the access token to 288 gain access to Alice's data at storephotos.example. The refresh 289 tokens are persistently stored on the device for use in subsequent 290 app executions. If a refresh token exists on app startup, the app 291 directly uses the refresh token to obtain a new access token. 293 Requirements: 295 o Alice's authentication with storephotos.example is required 297 o Registration of the application running on Alice's smartphone is 298 required for identification and registration and may be carried 299 out on a per installation base 301 o The application at storephotos.example provides a capability to 302 view and delete the apps' authorizations. This implies that the 303 different installations of the same app on the different devices 304 can be distinguished (e.g., by a device name or a telephone 305 number) 307 o The app must provide Alice an option to logout. The logout must 308 result in revocation of the refresh tokens on the authorization 309 server 311 Note: OAuth 2.0 supports this use case 313 2.4. In-App-Payment (based on Native Application) 315 Description: 317 Alice has installed on her computer a gaming application (e.g., 318 running as native code or as a widget). At some point she wants to 319 play the next level of the game and needs to purchase an access to 320 the advanced version of the game from her service provider at 321 www.sp.example. With Alice's authorization the application accesses 322 her account at www.sp.example and enables her to make the payment. 324 Pre-conditions: 326 o Alice has registered and has an account with her service provider 327 at www.sp.example 329 o The application is registered with the service provider at 330 www.sp.example. This enables the server provider to provide Alice 331 with all necessary information about the gaming application 332 (including the information about the purchasing price) 334 o Alice has a Web user-agent (e.g., a browser or a widget runtime) 335 installed on her computer 337 Post-conditions: 339 A successful procedure results in the gaming application invoking the 340 user browser and directing it to the authorization server of the 341 service provider. The HTTP message includes information about the 342 gaming application's request to access Alice's account. The 343 authorization server presents to Alice the authentication and 344 authorization interfaces. The authorization interface shows Alice 345 the information about the application's request including the 346 requested charge to her account. After Alice successfully 347 authenticates and authorizes the request, the authorization server 348 enables Alice to save the transaction details including the 349 authorization code issued for the gaming application. Then the 350 authorization server redirects Alice's browser to a custom scheme URI 351 (registered with the operating system). This redirection request 352 contains a one-time authorization code and invokes a special 353 application that is able to extract the authorization code and 354 present it to the gaming application. The gaming application 355 presents the authorization code to the authorization server and 356 exchanges it for a one-time access token. The gaming application 357 then uses the access token to get access to Alice's account and post 358 the charges at www.sp.example. 360 Requirements: 362 Note: The focus is on the requirements that are specific to this use 363 case. The requirements that are common to the native applications 364 are listed in the preceding use case. 366 o An authorization server associated with the server at 367 www.sp.example must be able to provide Alice with information 368 about the access request that the gaming application has made 369 (including the amount that is to be charged to her account with 370 the service provider and the purpose for the charge) over a secure 371 transport 373 o An authorization server associated with the server at 374 www.sp.example must be able to obtain Alice's authorization 375 decision on the request over a secure transport 377 o An authorization server associated with the server at 378 www.sp.example must be able to generate on demand a one-time 379 authorization code and a one-time access token according to the 380 scope authorized by Alice 382 o An authorization server associated with the server at 383 www.sp.example must be able to call back to the gaming application 384 with the authorization result over a secure transport 386 o An authorization server associated with the server at 387 www.sp.example must enable the gaming application to exchange an 388 authorization code for an access token over a secure transport 390 o An authorization server associated with the server at 391 www.sp.example must verify the authorization code and invalidate 392 it after its first use 394 o An authorization server associated with the server at 395 www.sp.example must enable Alice to save the details of the 396 requested transaction, including the authorization code 398 o An authorization server associated with the server at 399 www.sp.example must keep a record linking the requested 400 transaction with the authorization code and the respective access 401 token 403 o An authorization server associated with the server at 404 www.sp.example must enable the resource server www.sp.example to 405 obtain the transaction information that is linked to the issued 406 access token 408 o Resource server at www.sp.example must verify access token and 409 invalidate it after its first use 411 o A resource server at www.sp.example must enable the gaming 412 application to post charges to Alice's account according to the 413 access token presented over a secure transport 415 o The gaming application must provide a custom scheme URI to the 416 authorization server associated with www.sp.example (note: it can 417 be preregistered with the authorization server) 419 o Alice's manual involvement in the OAuth authorization procedure 420 (e.g., entering an URL or a password) should not be required. 421 (Alice's authentication to www.sp.example is not in the OAuth 422 scope) 424 Note: OAuth 2.0 does not directly support this use case 426 2.5. Device with an input method 428 Description: 430 Alice has a device, such as a gaming console, that does not support 431 an easy data-entry method. She also has access to a computer with a 432 browser. The application running on the Alice's device gets 433 authorized access to a protected resource (e.g., photographs) stored 434 on a server at www.storephotos.example 436 Pre-conditions: 438 o Alice uses a gaming console, which does not have an easy data- 439 entry method, for accessing her photographs at 440 www.storephotos.example 442 o Alice is able to connect to www.storephotos.example using a 443 computer that runs a browser 445 o Auhtorization server associated with www.storephotos.example is 446 able to generate an authorization code that is suitable for 447 reading and writing by a human (e.g., an alphanumeric string that 448 is not too long) 450 o The gaming device supports input of the characters that can be 451 found in an authorization code 453 o Alice has registered with the authorization server associated with 454 www.storephotos.example for identification and authentication 456 Post-conditions: 458 o Alice, interacting with an authorization server associated with 459 www.storephotos.example, authorizes access to her photographs by 460 her gaming console. She uses her browser-equipped computer for 461 OAuth authorization 463 o The authorization server associated with www.storephotos.example 464 responds to Alice's authorization by displaying an authorization 465 code in her browser's window 467 o Alice enters the displayed code into an input field on the gaming 468 console 470 o The gaming console exchanges with the authorization server the 471 authorization code for an access token 473 o Alice's gaming console uses the access token to access the 474 photographs on www.storephotos.example 476 Requirements: 478 o Alice's authentication with the authorization server is required 480 o Alice is required to perform authorization of her gaming console 481 by interacting with the authorization server associated with 482 www.storephotos.example. To that end she has to direct her 483 browser to the authorization server 485 o After authorizing the access and getting an authorization code 486 displayed in her browser, Alice has to enter the displayed code 487 into an input field on the gaming console 489 o The gaming console should be able to exchange the authorization 490 code for an access token through interaction with the 491 authorization server associated with www.storephotos.example 493 o The URL of the authorization server and the authorization code 494 must be suitable for manual entry 496 o The authorization code must be composed of the characters that are 497 appropriate for input to the gaming console 499 o Because the authorization code is relatively short and its 500 character set is limited, the code's lifetime should be configured 501 appropriately 503 Note: OAuth 2.0 supports this use case 505 2.6. Client password (shared secret) credentials 507 Description: 509 The company GoodPay prepares the employee payrolls for the company 510 GoodWork. In order to do that the application at www.GoodPay.example 511 gets authenticated access to the employees' attendance data stored at 512 www.GoodWork.example. 514 Pre-conditions: 516 o The application at www.GoodPay.example has established through a 517 registration an identifier and a shared secret with the 518 application running at www.GoodWork.example 520 o The scope of the access by the application at www.GoodPay.example 521 to the data stored at www.GoodWork.example has been defined 523 Post-conditions: 525 A successful procedure results in the application at 526 www.GoodPay.example receiving an access token after authenticating to 527 the application running at www.GoodWork.example. 529 Requirements: 531 o Authentication of the application at www.GoodPay.example to the 532 application at www.GoodWork.example is required 534 o The authentication method must be based on the identifier and 535 shared secret, which the application running at 536 www.GoodPay.example submits to the application at 537 www.GoodWork.example in the initial HTTP request 539 o Because in this use case GoodPay gets access to GoodWork's 540 sensitive data, GoodWork shall have a pre-established trust with 541 GoodPay on the security policy and the authorization method's 542 implementation 544 Note: OAuth 2.0 supports this use case 546 2.7. Assertion 548 Description: 550 Company GoodPay prepares the employee payrolls for the company 551 GoodWork. In order to do that the application at www.GoodPay.example 552 gets authenticated access to the employees' attendance data stored at 553 www.GoodWork.example. 554 This use case describes an alternative solution to the one described 555 by the use case Client password credentials. 557 Pre-conditions: 559 o The application at www.GoodPay.example has obtained an 560 authentication assertion from a party that is trusted by the 561 application at www.GoodWork.example 563 o The scope of the access by the application at www.GoodPay.example 564 to the data stored at www.GoodWork.example has been defined 566 o The application at www.GoodPay.example has established trust 567 relationship with the asserting party and is capable of validating 568 its assertions 570 Post-conditions: 572 A successful procedure results in the application at 573 www.GoodPay.example receiving an access token after authenticating to 574 the application running at www.GoodWork.example by presenting an 575 assertion (e.g., SAML assertion). 577 Requirements: 579 o Authentication of the application at www.GoodPay.example to the 580 application at www.GoodWork.example is required 582 o The application running at www.GoodWork.example must be capable of 583 validating assertion presented by the application running at 584 www.GoodPay.example 586 o Because in this use case GoodPay gets access to GoodWork's 587 sensitive data, GoodWork shall establish trust with GoodPay on the 588 security policy and the authorization method's implementation 590 Note: OAuth 2.0 supports this use case 592 2.8. Access token exchange 594 Description: 596 Alice uses an application running on www.printphotos.example for 597 printing her photographs that are stored on a server at 598 www.storephotos.example. The application running on 599 www.storephotos.example, while serving the request of the application 600 at www.printphotos.example, discovers that some of the requested 601 photographs have been moved to www.storephotos1.example. The 602 application at www.storephotos.example retrieves the missing 603 photographs from www.storephotos1.example and provides access to all 604 requested photographs to the application at www.printphotos.example. 605 The application at www.printphotos.example carries out Alice's 606 request. 608 Pre-conditions: 610 o The application running on www.printphotos.example is capable of 611 interacting with Alice's browser 613 o Alice has registered with and can be authenticated by 614 authorization server 616 o The applications at www.storephotos.example has registered with 617 authorization server 619 o The applications at www.storephotos1.example has registered with 620 authorization server 622 o The application at www.printphotos.example has registered with 623 authorization server 625 Post-conditions: 627 A successful procedure results in the application at 628 www.printphotos.example receiving an access token that allows access 629 to Alice's photographs. This access token is used for the following 630 purposes: 632 o By the application running at www.printphotos.example to get 633 access to the photographs at www.storephotos.example 635 o By the application running at www.storephotos.example to obtain 636 from authorization server another access token that allows it to 637 retrieve the additional photographs stored at 638 www.storephotos1.example 640 As the result, there are two access token issued for two different 641 applications. The tokens may have different properties (e.g., scope, 642 permissions, and expiration dates). 644 Requirements: 646 o The applications at www.printphotos.example and 647 www.storephotos.example require different access tokens 649 o The application at www.printphotos.example is required to provide 650 its callback URL to the application at www.storephotos.example 652 o Authentication of the application at www.printphotos.example to 653 the authorization server is required 655 o Alice's authentication by the authorization server is required 657 o The authorization server must be able to describe to Alice the 658 request of the application at www.printphotos.example and obtain 659 her authorization (or rejection) 661 o If Alice has authorized the request, the authorization server must 662 be able to issue an access token that enables the application at 663 www.printphotos.example to get access to Alice's photographs at 664 www.storephotos.example 666 o The authorization server must be able, based on the access token 667 presented by the application at www.printphotos.example, to 668 generate another access token that allows the application at 669 www.storephotos.example to get access to the photographs at 670 www.storephotos1.example. In this context the authorization 671 server must validate the authorization of the application at 672 www.storephotos.example to obtain the token. 674 o The application at www.storephotos.example must be able to 675 validate an access token presented by the application running at 676 www.printphotos.example 678 o The application at www.storephotos1.example must be able to 679 validate the access token presented by the application running at 680 www.storephotos.example 682 Note: This use case is indirectly supported by Assertion frmamework 683 for OAuth 2.0 [I-D.ietf-oauth-assertions] and its extensions SAML 2.0 684 Bearer Assertion Profiles for OAuth 2.0 [I-D.ietf-oauth-saml2-bearer] 685 and JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0 686 [I-D.ietf-oauth-jwt-bearer] 688 2.9. Multiple access tokens 690 Description: 692 Alice uses a communicator application running on a web server at 693 www.communicator.example to access her email service at 694 www.email.example and her voice over IP service at www.voip.example. 695 Email addresses and telephone numbers are obtained from Alice's 696 address book at www.contacts.example. Those web sites all rely on 697 the same authorization server, so the application at 698 www.communicator.example can receive a single authorization from 699 Alice for getting access to these three services on her behalf at 700 once. 701 The authorization server needs to issue different access tokens for 702 the involved services due to security and privacy policy. One 703 typical reason is the use of the symmetric secrets for signing self- 704 contained access tokens. In this use case, using a particular token 705 for more than a single service introduces a security risk. 707 Note: This use case is especially useful for native applications 708 since a web browser needs to be launched only once. 710 Pre-conditions: 712 o The same authorization server serves Alice and all involved 713 servers 715 o Alice has registered with the authorization server for 716 authentication and for authorization of the requests of the 717 communicator application running at www.communicator.example 719 o The email application at www.email.example has registered with the 720 authorization server for authentication 722 o The VoIP application at www.voip.example has registered with the 723 authorization server for authentication 725 o The address book at www.contacts.example has registered with the 726 authorization server for authentication 728 Post-conditions: 730 A successful procedure results in the application at 731 www.communicator.example receiving three different access tokens: one 732 for accessing the email service at www.email.example, one for 733 accessing the contacts at www.contacts.example, and one for accessing 734 the VoIP service at www.voip.example. 736 Requirements: 738 o The application running at www.communicator.example must be 739 authenticated by the authorization server 741 o Alice must be authenticated by the authorization server 743 o The application running at www.communicator.example must be able 744 to get a single Alice's authorization for access to the multiple 745 services (e.g., email and VoIP) 747 o The application running at www.communicator.example must be able 748 to recognize that all three applications rely on the same 749 authorization server 751 o A callback URL of the application running at 752 www.communicator.example must be known to the authorization server 754 o The authorization server must be able to issue the separate 755 service-specific tokens (with different, scope, permissions, and 756 expiration dates) for access to the requested services (such as 757 email and VoIP) 759 Note: OAuth 2.0 does not support this use case 761 2.10. Gateway for browser-based VoIP applets 763 Description: 765 Alice accesses a social site on a web server at www.social.example. 766 Her browser loads a VoIP applet that enables her to make a VoIP call 767 using her SIP server at www.sipservice.example. The application at 768 www.social.example gets Alice's authorization to use her account with 769 www.sipservice.example without learning her authentication 770 credentials with www.sipservice.example. 772 Pre-conditions: 774 o Alice has registered with www.sipservice.example for 775 authentication 777 o The application at www.social.example has established 778 authentication credentials with the application at 779 www.sipservice.example 781 Post-conditions: 783 A successful procedure results in the application at 784 www.social.example receiving access token from www.sipservice.example 785 with Alice's authorization. 787 Requirements: 789 o The server at www.social.example must be able to redirect Alice's 790 browser to www.sipservice.example 792 o The application running at www.sipservice.example must be capable 793 of authenticating Alice and obtaining her authorization of a 794 request from www.social.example 796 o The server at www.sipservice.example must be able to redirect 797 Alice's browser back to www.social.example 799 o The application at www.social.example must be able to translate 800 the messages of the Alice's VoIP applet into SIP and RTP messages 802 o The application at www.social.example must be able to add the 803 access token to the SIP requests that it sends to 804 www.sipservice.example 806 o Application at www.sipservice.example must be able to authenticate 807 the application at www.social.example and validate the access 808 token 810 o Alice's manual involvement in the OAuth authorization procedure 811 (e.g., entering an URL or a password) should not be required. 812 (Alice's authentication to www.sipservice.example is not in the 813 OAuth scope) 815 Note: OAuth 2.0 does not support this use case 817 2.11. Signed Messages 819 Description: 821 Alice manages all her personal health records in her personal health 822 data store at a server at www.myhealth.example, which manages 823 authorization of access to Alice's participating health systems. 824 Alice's Primary Care Physician (PCP), which has a Web site at 825 www.pcp.example, recommends her to see a sleep specialist 826 (www.sleepwell.example). Alice arrives at the sleep specialist's 827 office and authorizes it to access her basic health data at her PCP's 828 web site. The application at www.pcp.example verifies that Alice has 829 authorized www.sleepwell.example to access her health data as well as 830 enforces that www.sleepwell.example is the only application that can 831 retrieve that data with that specific authorization. 833 Pre-conditions: 835 o Alice has a personal health data store that allows for discovery 836 of her participating health systems (e.g. psychiatrist, sleep 837 specialist, PCP, orthodontist, ophthalmologist, etc) 839 o The application at www.myhealth.example manages authorization of 840 access to Alice's participating health systems 842 o The application at www.myhealth.example can issue authorization 843 tokens understood by Alice's participating health systems 845 o The application at www.pcp.example stores Alice's basic health and 846 prescription records 848 o The application at www.sleepwell.com stores results of Alice's 849 sleep tests 851 Post-conditions: 853 o A successful procedure results in just the information that Alice 854 authorized being transferred from the Primary Care Physician 855 (www.pcp.example) to the sleep specialist (www.sleepwell.example) 857 o The transfer of health data only occurs if the application at 858 www.pcp.example can verify that www.sleepwell.example is the party 859 requesting access and that the authorization token presented by 860 www.sleepwell.example is issued by the application at 861 www.myhealth.example with a restricted audience of 862 www.sleepwell.example 864 Requirements: 866 o The application at www.sleepwell.example interacting with 867 www.myhealth.example must be able to discover the location of the 868 PCP system (e.g., XRD discovery) 870 o The application at www.sleepwell.example must be capable of 871 requesting Alice's authorization of access to the application at 872 www.pcp.example for the purpose of retrieving basic health data 873 (e.g. date-of-birth, weight, height, etc). The mechanism Alice 874 uses to authorize this access is out of scope for this use case 876 o The application at www.myhealth.example must be capable of issuing 877 a token bound to www.sleepwell.example for access to the 878 application at www.pcp.example. Note that a signed token (JWT) 879 can be used to prove who issued the token 881 o The application at www.sleepwell.example must be capable of 882 issuing a request (which includes the token issued by 883 www.myhealth.example) to the application at www.pcp.example 885 o The application at www.sleepwell.example must sign the request 886 before sending it to www.pcp.example 888 o The application at www.pcp.example must be capable of receiving 889 the request and verifying the signature 891 o The application at www.pcp.example must be capable of parsing the 892 message and finding the authorization token 894 o The application at www.pcp.example must be capable of verifying 895 the signature of the authorization token 897 o The application at www.pcp.example must be capable of parsing the 898 authorization token and verifying that this token was issued to 899 the application at www.sleepwell.com 901 o The application at www.pcp.example must be capable of retrieving 902 the requested data and returning it to the application at 903 www.sleepwell.example 905 Note: OAuth 2.0 does not support this use case 907 2.12. Signature with asymmetric secret 909 Description: 911 Alice accesses an application running on a web server at 912 www.printphotos.example and instructs it to print her photographs 913 that are stored on a server www.storephotos.example. The application 914 at www.printphotos.example, which does not have a shared secret with 915 www.storephotos.example, receives Alice's authorization for accessing 916 her photographs without learning her authentication credentials with 917 www.storephotos.example. 919 Pre-conditions: 921 o Alice has registered with www.storephotos.example to enable 922 authentication 924 o The application at www.printphotos.example has a private and a 925 matching public keys 927 Post-conditions: 929 A successful procedure results in the application at 930 www.printphotos.example receiving an access token from 931 www.storephotos.example for accessing the Alice's photographs. 933 Requirements: 935 o The application at www.printphotos.example must be capable of 936 issuing the HTTP redirect requests to Alice's user agent - a 937 browser 939 o The application at www.storephotos.example must be able to 940 authenticate Alice 942 o The application running at www.storephotos.example must be able to 943 obtain the public key of the application at 944 www.printphotos.example 946 o The application running at www.printphotos.example is required to 947 sign using its private key the requests to the application at 948 www.storephotos.example 950 o The application at www.storephotos.example must obtain Alice's 951 authorization of the access to her photos by 952 www.printphotos.example 954 o The application at www.storephotos.example is required to identify 955 to Alice the scope of access that www.printphotos.example has 956 requested while asking for Alice's authorization 958 o The application at www.storephotos.example must be able to 959 authenticate the application at www.printphotos.example by 960 validating a signature of its request using the public key of 961 www.printphotos.example 963 o The application at www.printphotos.example must provide a callback 964 URL to the application at www.storephotos.example (note: the URL 965 can be pre-registered with www.storephotos.example) 967 o The application at www.storephotos.example must be capable of 968 issuing the HTTP redirect requests to Alice's browser 970 o Alice's manual involvement in the OAuth authorization procedure 971 (e.g., entering an URL or a password) should not be required. 972 (Alice's authentication to www.storephotos.example is not in the 973 OAuth scope) 975 Note: OAuth 2.0 does not support this use case 977 3. Authors of the use cases 979 The major contributors of the use cases are as follows: 981 W. Beck, Deutsche Telekom AG 982 G. Brail, Sonoa Systems 983 B. de hOra 984 B. Eaton, Google 985 S. Farrell, NewBay Software 986 G. Fletcher, AOL 987 Y. Goland, Microsoft 988 B. Goldman, Facebook 989 E. Hammer-Lahav, Yahoo! 990 D. Hardt 991 R. Krikorian, Twitter 992 T. Lodderstedt, Deutsche Telekom 993 E. Maler, PayPal 994 D. Recordon, Facebook 995 L. Shepard, Facebook 996 A. Tom, Yahoo! 997 B. Vrancken, Alcatel-Lucent 998 Z. Zeltsan, Alcatel-Lucent 1000 4. Security considerations 1002 The OAuth 2.0 specification [I-D.ietf-oauth-v2] provides the 1003 implementers with security guidelines for all OAuth 2.0 client 1004 profiles. In addition, a comprehensive OAuth security model and 1005 background for the protocol design are provided by 1006 [I-D.ietf-oauth-v2-threatmodel]. 1008 5. IANA considerations 1010 This Internet Draft includes no request to IANA. 1012 6. Acknowledgements 1014 The authors thank Igor Faynberg and Hui-Lan Lu for their invaluable 1015 help with preparing this document. Special thanks are to the draft 1016 reviewers Thomas Hardjono and Melinda Shore, whose suggestions have 1017 helped to improve the draft. 1019 7. References 1021 7.1. Normative References 1023 [I-D.ietf-oauth-v2] 1024 Hardt, D., "The OAuth 2.0 Authorization Framework", 1025 draft-ietf-oauth-v2-31 (work in progress), August 2012. 1027 7.2. Informative References 1029 [I-D.ietf-oauth-v2-threatmodel] 1030 Lodderstedt, T., McGloin, M., and P. Hunt, "OAuth 2.0 1031 Threat Model and Security Considerations", 1032 draft-ietf-oauth-v2-threatmodel-07 (work in progress), 1033 August 2012. 1035 [I-D.ietf-oauth-assertions] 1036 Campbell, B., Mortimore, C., Jones, M., and Y. Goland, 1037 "Assertion Framework for OAuth 2.0", 1038 draft-ietf-oauth-assertions-05 (work in progress), 1039 September 2012. 1041 [I-D.ietf-oauth-saml2-bearer] 1042 Campbell, B. and C. Mortimore, "SAML 2.0 Bearer Assertion 1043 Profiles for OAuth 2.0", draft-ietf-oauth-saml2-bearer-14 1044 (work in progress), September 2012. 1046 [I-D.ietf-oauth-jwt-bearer] 1047 Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token 1048 (JWT) Bearer Token Profiles for OAuth 2.0", 1049 draft-ietf-oauth-jwt-bearer-02 (work in progress), 1050 September 2012. 1052 Authors' Addresses 1054 George Fletcher 1055 AOL 1057 Email: gffletch@aol.com 1059 Torsten Lodderstedt 1060 Deutsche Telekom AG 1062 Email: torsten@lodderstedt.net 1063 Zachary Zeltsan 1064 Alcatel-Lucent 1065 600 Mountain Avenue 1066 Murray Hill, New Jersey 1067 USA 1069 Phone: +1 908 582 2359 1070 Email: Zachary.Zeltsan@alcatel-lucent.com