draft-ietf-oauth-use-cases-01.txt   draft-ietf-oauth-use-cases-02.txt 
OAUTH WG G. Fletcher OAUTH WG G. Fletcher
Internet-Draft AOL Internet-Draft AOL
Intended status: Informational T. Lodderstedt Intended status: Informational T. Lodderstedt
Expires: January 17, 2013 Deutsche Telekom AG Expires: April 13, 2013 Deutsche Telekom AG
Z. Zeltsan Z. Zeltsan
Alcatel-Lucent Alcatel-Lucent
July 16, 2012 October 10, 2012
OAuth Use Cases OAuth Use Cases
draft-ietf-oauth-use-cases-01 draft-ietf-oauth-use-cases-02
Abstract Abstract
This document lists the OAuth use cases. The provided list is based This document lists the OAuth use cases. The provided list is based
on the Internet Drafts of the OAUTH working group and discussions on on the Internet Drafts of the OAUTH working group and discussions on
the group's mailing list. the group's mailing list.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 17, 2013. This Internet-Draft will expire on April 13, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 12 skipping to change at page 2, line 12
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. OAuth use cases . . . . . . . . . . . . . . . . . . . . . . . 3 2. OAuth use cases . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Web server . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Web server . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. User-agent . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. User-agent . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. In-App-Payment (based on Native Application) . . . . . . . 6 2.3. Native Application . . . . . . . . . . . . . . . . . . . . 6
2.4. Native Application . . . . . . . . . . . . . . . . . . . . 9 2.4. In-App-Payment (based on Native Application) . . . . . . . 8
2.5. Device . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.5. Device with an input method . . . . . . . . . . . . . . . 10
2.6. Client password (shared secret) credentials . . . . . . . 11 2.6. Client password (shared secret) credentials . . . . . . . 12
2.7. Assertion . . . . . . . . . . . . . . . . . . . . . . . . 12 2.7. Assertion . . . . . . . . . . . . . . . . . . . . . . . . 12
2.8. Content manager . . . . . . . . . . . . . . . . . . . . . 13 2.8. Access token exchange . . . . . . . . . . . . . . . . . . 13
2.9. Access token exchange . . . . . . . . . . . . . . . . . . 14 2.9. Multiple access tokens . . . . . . . . . . . . . . . . . . 15
2.10. Multiple access tokens . . . . . . . . . . . . . . . . . . 16 2.10. Gateway for browser-based VoIP applets . . . . . . . . . . 17
2.11. Gateway for browser-based VoIP applets . . . . . . . . . . 17 2.11. Signed Messages . . . . . . . . . . . . . . . . . . . . . 18
2.12. Signed Messages . . . . . . . . . . . . . . . . . . . . . 18 2.12. Signature with asymmetric secret . . . . . . . . . . . . . 20
2.13. Signature with asymmetric secret . . . . . . . . . . . . . 20
3. Authors of the use cases . . . . . . . . . . . . . . . . . . . 22 3. Authors of the use cases . . . . . . . . . . . . . . . . . . . 22
4. Security considerations . . . . . . . . . . . . . . . . . . . 22 4. Security considerations . . . . . . . . . . . . . . . . . . . 22
5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 22 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 22
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
7. Normative References . . . . . . . . . . . . . . . . . . . . . 23 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.1. Normative References . . . . . . . . . . . . . . . . . . . 23
7.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
This document describes the use cases that have been discussed on the This document describes the use cases that have been discussed on the
oauth WG mailing list and introduced by the Internet Drafts submitted oauth WG mailing list and introduced by the Internet Drafts submitted
to the group. The selected use cases illustrate the use of the OAuth to the group. The selected use cases illustrate the use of the OAuth
flows by the clients of the various profiles and types. The document flows by the clients of the various profiles and types. The document
also includes those cases that are not directly supported by the also includes those cases that are not directly supported by the
OAuth 2.0 protocol, but were considered during its development. The OAuth 2.0 [I-D.ietf-oauth-v2], but were considered during its
document provides a list of the requirements derived from the use development. The document provides a list of the requirements
cases. The use cases supported by OAuth 2.0 are indicated. derived from the use cases. The use cases supported by OAuth 2.0 are
indicated.
The document's objective is to help with understanding of the OAuth The document's objective is to help with understanding of the OAuth
2.0 protocol design. 2.0 protocol design.
Note: The use of the string ".example.com" in the URLs of the example
entities does not mean that the entities belong to the same
organization.
The following section provides the abbreviated descriptions of the The following section provides the abbreviated descriptions of the
use cases. use cases.
2. OAuth use cases 2. OAuth use cases
This section lists the use cases that have been discussed by the This section describes the use cases that have been discussed by the
oauth WG. oauth WG.
2.1. Web server 2.1. Web server
Description: Description:
Alice accesses an application running on a web server at Alice accesses an application running on a web server at
www.printphotos.example.com and instructs it to print her photographs www.printphotos.example.com and instructs it to print her photographs
that are stored on a server www.storephotos.example.com. The that are stored on a server www.storephotos.example.com. The
application at www.printphotos.example.com receives Alice's application at www.printphotos.example.com receives Alice's
skipping to change at page 4, line 49 skipping to change at page 4, line 46
authorization of the access to her photos by authorization of the access to her photos by
www.printphotos.example.com www.printphotos.example.com
o Application at www.storephotos.example.com may identify to Alice o Application at www.storephotos.example.com may identify to Alice
the scope of access that www.printphotos.example.com has requested the scope of access that www.printphotos.example.com has requested
while asking for Alice's authorization while asking for Alice's authorization
o Application at www.storephotos.example.com must be able to o Application at www.storephotos.example.com must be able to
authenticate the application at www.printphotos.example.com and authenticate the application at www.printphotos.example.com and
validate the authorization code before issuing an access token. validate the authorization code before issuing an access token.
The OAuth 2.0 protocol [I-D.draft-ietf-oauth-v2] specifies one The OAuth 2.0 protocol [I-D.ietf-oauth-v2] specifies one
authentication method that MAY be used for such authentication - authentication method that MAY be used for such authentication -
Client Password Authentication. Client Password Authentication.
o Application at www.printphotos.example.com must provide a callback o Application at www.printphotos.example.com must provide a callback
URL to the application at www.storephotos.example.com (note: the URL to the application at www.storephotos.example.com (note: the
URL can be pre-registered with www.storephotos.example.com) URL can be pre-registered with www.storephotos.example.com)
o Application at www.storephotos.example.com is required to maintain o Application at www.storephotos.example.com is required to maintain
a record that associates the authorization code with the a record that associates the authorization code with the
application at www.printphotos.example.com and the callback URL application at www.printphotos.example.com and the callback URL
skipping to change at page 5, line 27 skipping to change at page 5, line 24
o Application at www.storephotos.example.com must invalidate the o Application at www.storephotos.example.com must invalidate the
authorization code after its first use authorization code after its first use
o Alice's manual involvement in the OAuth authorization procedure o Alice's manual involvement in the OAuth authorization procedure
(e.g., entering an URL or a password) should not be required. (e.g., entering an URL or a password) should not be required.
(Alice's authentication to www.storephotos.example.com is not in (Alice's authentication to www.storephotos.example.com is not in
the OAuth scope. Her registration with the OAuth scope. Her registration with
www.storephotos.example.com is required as a pre-condition) www.storephotos.example.com is required as a pre-condition)
Note: OAuth 2.0 supports this use case
2.2. User-agent 2.2. User-agent
Description: Description:
Alice has installed on her computer a gaming application. She keeps Alice has on her computer a gaming application. She keeps her scores
her scores in a database of a social site at www.fun.example.com. In in a database of a social site at www.fun.example.com. In order to
order to upload Alice's scores, the application gets access to the upload Alice's scores, the application gets access to the database
database with her authorization. with her authorization.
Pre-conditions: Pre-conditions:
o Alice has installed a gaming application implemented in a o Alice uses a gaming application implemented in a scripting
scripting language (e.g., JavaScript) that runs in her browser and language (e.g., JavaScript) that runs in her browser and uses
uses OAuth for accessing a social site at www.fun.example.com OAuth for accessing a social site at www.fun.example.com
o There is no a web site supporting this application and capable of o There is no a web site supporting this application and capable of
handling the OAuth flow, so the gaming application needs to update handling the OAuth flow, so the gaming application needs to update
the database itself the database itself
o The installed application is registered with the social site at o The application is registered with the social site at
www.fun.example.com and has an identifier www.fun.example.com and has an identifier
o Alice has registered with www.fun.example.com for identification o Alice has registered with www.fun.example.com for identification
and authentication and authentication
o An auxiliary web server at www.help.example.com is reachable by o An auxiliary web server at www.help.example.com is reachable by
Alice's browser and capable of providing a script that extracts an Alice's browser and capable of providing a script that extracts an
access token from an URL's fragment access token from an URL's fragment
Post-conditions: Post-conditions:
skipping to change at page 6, line 39 skipping to change at page 6, line 39
o Application running at www.fun.example.com must be able to o Application running at www.fun.example.com must be able to
describe to Alice the request made by the gaming application describe to Alice the request made by the gaming application
running on her computer and obtain Alice's authorization for or running on her computer and obtain Alice's authorization for or
denial of the requested access denial of the requested access
o After obtaining Alice's authorization the application running at o After obtaining Alice's authorization the application running at
www.fun.example.com must respond with an access token and redirect www.fun.example.com must respond with an access token and redirect
Alice's browser to a web server (e.g., www.help.example.com) that Alice's browser to a web server (e.g., www.help.example.com) that
is capable of retrieving an access token from an URL is capable of retrieving an access token from an URL
2.3. In-App-Payment (based on Native Application) Note: OAuth 2.0 supports this use case
2.3. Native Application
Description:
Alice wants to upload (or download) her photographs to (or from)
storephotos.example.com using her smartphone. She downloads and
installs a photo app on her smartphone. In order to enable the app
to access her photographs, Alice needs to authorize the app to access
the web site on her behalf. The authorization shall be valid for a
prolonged duration (e.g. several months), so that Alice does not need
to authenticate and authorize access on every execution of the app.
It shall be possible to withdraw the app's authorization both on the
smartphone as well as on the site storephotos.example.com.
Pre-conditions:
o Alice has installed a (native) photo app application on her
smartphone
o The installed application is registered with the social site at
storephotos.example.com and has an identifier
o Alice holds an account with storephotos.example.com
o Authentication and authorization shall be performed in an
interactive, browser-based process. The smartphone's browser is
used for authenticating Alice and for enabling her to authorize
the request by the Mobile App
Post-conditions:
A successful procedure results in Alice's app receiving the access
and refresh tokens. The app obtains the tokens by utilizing the
Authorization Code flow. The application uses the access token to
gain access to Alice's data at storephotos.example.com. The refresh
tokens are persistently stored on the device for use in subsequent
app executions. If a refresh token exists on app startup, the app
directly uses the refresh token to obtain a new access token.
Requirements:
o Alice's authentication with storephotos.example.com is required
o Registration of the application running on Alice's smartphone is
required for identification and registration and may be carried
out on a per installation base
o The application at storephotos.example.com provides a capability
to view and delete the apps' authorizations. This implies that
the different installations of the same app on the different
devices can be distinguished (e.g., by a device name or a
telephone number)
o The app must provide Alice an option to logout. The logout must
result in revocation of the refresh tokens on the authorization
server
Note: OAuth 2.0 supports this use case
2.4. In-App-Payment (based on Native Application)
Description: Description:
Alice has installed on her computer a gaming application (e.g., Alice has installed on her computer a gaming application (e.g.,
running as native code or as a widget). At some point she wants to running as native code or as a widget). At some point she wants to
play the next level of the game and needs to purchase an access to play the next level of the game and needs to purchase an access to
the advanced version of the game from her service provider at the advanced version of the game from her service provider at
www.sp.example.com. With Alice's authorization the application www.sp.example.com. With Alice's authorization the application
accesses her account at www.sp.example.com and enables her to make accesses her account at www.sp.example.com and enables her to make
the payment. the payment.
skipping to change at page 7, line 41 skipping to change at page 9, line 7
contains a one-time authorization code and invokes a special contains a one-time authorization code and invokes a special
application that is able to extract the authorization code and application that is able to extract the authorization code and
present it to the gaming application. The gaming application present it to the gaming application. The gaming application
presents the authorization code to the authorization server and presents the authorization code to the authorization server and
exchanges it for a one-time access token. The gaming application exchanges it for a one-time access token. The gaming application
then uses the access token to get access to Alice's account and post then uses the access token to get access to Alice's account and post
the charges at www.sp.example.com. the charges at www.sp.example.com.
Requirements: Requirements:
o An authorization server associated with the server at Note: The focus is on the requirements that are specific to this use
www.sp.example.com must be able to authenticate Alice over a case. The requirements that are common to the native applications
secure transport are listed in the preceding use case.
o An authorization server associated with the server at o An authorization server associated with the server at
www.sp.example.com must be able to provide Alice with information www.sp.example.com must be able to provide Alice with information
about the access request that the gaming application has made about the access request that the gaming application has made
(including the amount that is to be charged to her account with (including the amount that is to be charged to her account with
the service provider, and the purpose for the charge) over a the service provider and the purpose for the charge) over a secure
secure transport transport
o An authorization server associated with the server at o An authorization server associated with the server at
www.sp.example.com must be able to obtain Alice's authorization www.sp.example.com must be able to obtain Alice's authorization
decision on the request over a secure transport decision on the request over a secure transport
o An authorization server associated with the server at o An authorization server associated with the server at
www.sp.example.com must be able to generate on demand a one-time www.sp.example.com must be able to generate on demand a one-time
authorization code and a one-time access token according to the authorization code and a one-time access token according to the
scope authorized by Alice scope authorized by Alice
o An authorization server associated with the server at o An authorization server associated with the server at
www.sp.example.com must be able to call back to the gaming www.sp.example.com must be able to call back to the gaming
application with the authorization result over a secure transport application with the authorization result over a secure transport
o An authorization server associated with the server at o An authorization server associated with the server at
www.sp.example.com must enable the gaming application to exchange www.sp.example.com must enable the gaming application to exchange
an authorization code for an access token over a secure transport an authorization code for an access token over a secure transport
o * An authorization server associated with the server at o An authorization server associated with the server at
www.sp.example.com must verify the authorization code and www.sp.example.com must verify the authorization code and
invalidate it after its first use invalidate it after its first use
o * An authorization server associated with the server at o An authorization server associated with the server at
www.sp.example.com must enable Alice to save the details of the www.sp.example.com must enable Alice to save the details of the
requested transaction, including the authorization code requested transaction, including the authorization code
o * An authorization server associated with the server at o An authorization server associated with the server at
www.sp.example.com must keep a record linking the requested www.sp.example.com must keep a record linking the requested
transaction with the authorization code and the respective access transaction with the authorization code and the respective access
token token
o * An authorization server associated with the server at o An authorization server associated with the server at
www.sp.example.com must enable the resource server www.sp.example.com must enable the resource server
www.sp.example.com to obtain the transaction information that is www.sp.example.com to obtain the transaction information that is
linked to the issued access token linked to the issued access token
o * Resource server at www.sp.example.com must verify access token o Resource server at www.sp.example.com must verify access token and
and invalidate it after its first use invalidate it after its first use
o * A resource server at www.sp.example.com must enable the gaming o A resource server at www.sp.example.com must enable the gaming
application to post charges to Alice's account according to the application to post charges to Alice's account according to the
access token presented over a secure transport access token presented over a secure transport
o The gaming application must provide a custom scheme URI to the o The gaming application must provide a custom scheme URI to the
authorization server associated with www.sp.example.com (note: it authorization server associated with www.sp.example.com (note: it
can be preregistered with the authorization server) can be preregistered with the authorization server)
o Alice's manual involvement in the OAuth authorization procedure o Alice's manual involvement in the OAuth authorization procedure
(e.g., entering an URL or a password) should not be required. (e.g., entering an URL or a password) should not be required.
(Alice's authentication to www.sp.example.com is not in the OAuth (Alice's authentication to www.sp.example.com is not in the OAuth
scope) scope)
* The requirements denoted by '*' are not common for the Native Note: OAuth 2.0 does not directly support this use case
Application use cases, but are specific to the In-App-Payment use
case
2.4. Native Application 2.5. Device with an input method
Description: Description:
Alice wants to upload (or download) her photographs to (or from) Alice has a device, such as a gaming console, that does not support
storephotos.example.com using her smartphone. She downloads and an easy data-entry method. She also has access to a computer with a
installs a photo app on her smartphone. In order to enable the app browser. The application running on the Alice's device gets
to access her photographs, Alice needs to authorize the app to access authorized access to a protected resource (e.g., photographs) stored
the web site on her behalf. The authorization shall be valid for a on a server at www.storephotos.example.com
prolonged duration (e.g. several months), so that Alice does not need
to authenticate and authorize access on every execution of the app.
It shall be possible to withdraw the app's authorization both on the
smartphone as well as on the site storephotos.example.com.
Pre-conditions: Pre-conditions:
o Alice has installed a (native) photo app application on her o Alice uses a gaming console, which does not have an easy data-
smartphone entry method, for accessing her photographs at
www.storephotos.example.com
o The installed application is registered with the social site at
storephotos.example.com and has an identifier
o Alice holds an account with storephotos.example.com
o Authentication and authorization shall be performed in an
interactive, browser-based process. The smartphone's browser is
used for authenticating Alice and for enabling her to authorize
the request by the Mobile App
Post-conditions:
A successful procedure results in Alice's app receiving an access and
a refresh token. The app may obtain the tokens by utilizing either
the web server or the user agent flow. The application uses the
access token to gain access to Alice's data at
storephotos.example.com. The refresh token is persistently stored on
the device for use in sub-sequent app executions. If a refresh token
exists on app startup, the app directly uses the refresh token to
obtain a new access token.
Requirements:
o Alice's authentication with storephotos.example.com is required
o Registration of the application running on Alice's smartphone is o Alice is able to connect to www.storephotos.example.com using a
required for identification and registration and may be carried computer that runs a browser
out on a per installation base
o The application at storephotos.example.com provides a capability o Auhtorization server associated with www.storephotos.example.com
to view and delete the apps' authorizations. This implies that is able to generate an authorization code that is suitable for
the different installations of the same app on the different reading and writing by a human (e.g., an alphanumeric string that
devices can be distinguished (e.g., by a device name or a is not too long)
telephone number)
o The app must provide Alice an option to logout. The logout must o The gaming device supports input of the characters that can be
result in the revocation of the refresh token on the authorization found in an authorization code
server
2.5. Device o Alice has registered with the authorization server associated with
www.storephotos.example.com for identification and authentication
Description: Post-conditions:
Alice has a device, such as a game console, that does not support an o Alice, interacting with an authorization server associated with
easy data-entry method. She also has an access to a computer with a www.storephotos.example, authorizes access to her photographs by
browser. The application running on the Alice's device gets her gaming console. She uses her browser-equipped computer for
authorized access to a protected resource (e.g., photographs) stored OAuth authorization
on a server at www.storephotos.example.com
Pre-conditions: o The authorization server associated with
www.storephotos.example.com responds to Alice's authorization by
displaying an authorization code in her browser's window
o Alice uses an Oauth-enabled game console, which does not have an o Alice enters the displayed code into an input field on the gaming
easy data-entry method, for accessing her photographs at console
www.storephotos.example.com. The device starts the OAuth
procedure by requesting a token
o Alice is able to connect to www.storephotos.example.com using a o The gaming console exchanges with the authorization server the
computer that provides an easy data-entry method, which is authorization code for an access token
equipped with a browser. This computer is used to authorize
access by the application running on the game console to Alice's
photographs
o Application running on Alice's game console has registered with o Alice's gaming console uses the access token to access the
www.storephotos.example.com (has been issued an identifier) photographs on www.storephotos.example.com
o Alice has registered with the application running at Requirements:
www.storephotos.example.com for identification and authentication
Post-conditions: Description: o Alice's authentication with the authorization server is required
A successful procedure results in the application running on Alice's o Alice is required to perform authorization of her gaming console
game console receiving an access token that enables access to the by interacting with the authorization server associated with
photographs on www.storephotos.example.com. www.storephotos.example.com. To that end she has to direct her
browser to the authorization server
Requirements: o After authorizing the access and getting an authorization code
displayed in her browser, Alice has to enter the displayed code
into an input field on the gaming console
o Registration of the application running on the game console with o The gaming console should be able to exchange the authorization
the application running on www.storephotos.example.com is required code for an access token through interaction with the
for identification authorization server associated with www.storephotos.example.com
o Application running on the game console must be able to poll o The URL of the authorization server and the authorization code
periodically the application running at must be suitable for manual entry
www.storephotos.example.com while waiting for Alice's
authorization of the requested access to her photographs. The
repeating requests include the application's identifier and the
verification code that has been issued by
www.storephotos.example.com
o Alice is required to use her browser for interacting with the web o The authorization code must be composed of the characters that are
application running on www.storephotos.example.com. To that end appropriate for input to the gaming console
she has to manually direct her browser to the verification URL
that is displayed on her game console
o Alice's authentication with www.storephotos.example.com is o Because the authorization code is relatively short and its
required character set is limited, the code's lifetime should be configured
appropriately
o After authentication with www.storephotos.example.com Alice, if Note: OAuth 2.0 supports this use case
she wishes to approve the request, which is described in her
browser's window, must enter the user code. (The user code is
also displayed on her game console along with the verification
URL)
2.6. Client password (shared secret) credentials 2.6. Client password (shared secret) credentials
Description: Description:
The company GoodPay prepares the employee payrolls for the company The company GoodPay prepares the employee payrolls for the company
GoodWork. In order to do that the application at GoodWork. In order to do that the application at
www.GoodPay.example.com gets authenticated access to the employees' www.GoodPay.example.com gets authenticated access to the employees'
attendance data stored at www.GoodWork.example.com. attendance data stored at www.GoodWork.example.com.
skipping to change at page 12, line 28 skipping to change at page 12, line 46
o The authentication method must be based on the identifier and o The authentication method must be based on the identifier and
shared secret, which the application running at shared secret, which the application running at
www.GoodPay.example.com submits to the application at www.GoodPay.example.com submits to the application at
www.GoodWork.example.com in the initial HTTP request www.GoodWork.example.com in the initial HTTP request
o Because in this use case GoodPay gets access to GoodWork's o Because in this use case GoodPay gets access to GoodWork's
sensitive data, GoodWork shall have a pre-established trust with sensitive data, GoodWork shall have a pre-established trust with
GoodPay on the security policy and the authorization method's GoodPay on the security policy and the authorization method's
implementation implementation
Note: OAuth 2.0 supports this use case
2.7. Assertion 2.7. Assertion
Description: Description:
Company GoodPay prepares the employee payrolls for the company Company GoodPay prepares the employee payrolls for the company
GoodWork. In order to do that the application at GoodWork. In order to do that the application at
www.GoodPay.example.com gets authenticated access to the employees' www.GoodPay.example.com gets authenticated access to the employees'
attendance data stored at www.GoodWork.example.com. attendance data stored at www.GoodWork.example.com.
This use case describes an alternative solution to the one described This use case describes an alternative solution to the one described
by the use case Client password credentials. by the use case Client password credentials.
skipping to change at page 13, line 25 skipping to change at page 13, line 44
the application at www.GoodWork.example.com is required the application at www.GoodWork.example.com is required
o The application running at www.GoodWork.example.com must be o The application running at www.GoodWork.example.com must be
capable of validating assertion presented by the application capable of validating assertion presented by the application
running at www.GoodPay.example.com running at www.GoodPay.example.com
o Because in this use case GoodPay gets access to GoodWork's o Because in this use case GoodPay gets access to GoodWork's
sensitive data, GoodWork shall establish trust with GoodPay on the sensitive data, GoodWork shall establish trust with GoodPay on the
security policy and the authorization method's implementation security policy and the authorization method's implementation
2.8. Content manager Note: OAuth 2.0 supports this use case
Description:
Alice and Bob are having a chat conversation using a content manager
application running on a web server at
www.contentmanager.example.com. Alice notifies Bob that she wants to
share some photographs at www.storephotos.example.com and instructs
the application at www.contentmanager.example.com to enable Bob's
access to the photographs. The application at
www.contentmanager.example.com, after Alice's authorization, obtains
an access token for Bob, who uses it to access Alice's photographs at
www.storephotos.example.com.
Pre-conditions:
Alice, Bob the content manager application at
www.contentmanager.example.com, and the application at
www.storephotos.example.com have registered with the same
authorization server for authentication
Post-conditions:
A successful procedure results in the application at
www.contentmanager.example.com receiving an access token that allows
access to Alice's photographs at www.storephotos.example.com. The
access token is issued by the authorization server after Alice has
authorized the content manager at www.contentmanager.example.com to
get an access token on Bob's behalf. The access token is passed to
Bob by the content manager. Bob uses the access token to view
Alice's photographs at www.storephotos.example.com.
Requirements:
o The server at www.contentmanager.example.com, must be capable of
issuing the HTTP redirect requests to Alice's and Bob's user
agents - the browsers
o The authorization server must be able to authenticate Alice, Bob,
and the application at www.contentmanager.example.com
o The authorization server is required to obtain Alice's
authorization for issuing an access token to
www.contentmanager.example.com on Bob's behalf
o Authorization server must be able to identify to Alice the scope
of access that www.contentmanager.example.com has requested on
Bob's behalf while asking for Alice's authorization
2.9. Access token exchange 2.8. Access token exchange
Description: Description:
Alice uses an application running on www.printphotos.example.com for Alice uses an application running on www.printphotos.example.com for
printing her photographs that are stored on a server at printing her photographs that are stored on a server at
www.storephotos.example.com. The application running on www.storephotos.example.com. The application running on
www.storephotos.example.com, while serving the request of the www.storephotos.example.com, while serving the request of the
application at www.printphotos.example.com, discovers that some of application at www.printphotos.example.com, discovers that some of
the requested photographs have been moved to the requested photographs have been moved to
www.storephotos1.example.com. The application at www.storephotos1.example.com. The application at
skipping to change at page 16, line 21 skipping to change at page 15, line 42
www.storephotos.example.com to obtain the token. www.storephotos.example.com to obtain the token.
o The application at www.storephotos.example.com must be able to o The application at www.storephotos.example.com must be able to
validate an access token presented by the application running at validate an access token presented by the application running at
www.printphotos.example.com www.printphotos.example.com
o The application at www.storephotos1.example.com must be able to o The application at www.storephotos1.example.com must be able to
validate the access token presented by the application running at validate the access token presented by the application running at
www.storephotos.example.com www.storephotos.example.com
2.10. Multiple access tokens Note: This use case is indirectly supported by Assertion frmamework
for OAuth 2.0 [I-D.ietf-oauth-assertions] and its extensions SAML 2.0
Bearer Assertion Profiles for OAuth 2.0 [I-D.ietf-oauth-saml2-bearer]
and JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0
[I-D.ietf-oauth-jwt-bearer]
2.9. Multiple access tokens
Description: Description:
Alice uses a communicator application running on a web server at Alice uses a communicator application running on a web server at
www.communicator.example.com to access her email service at www.communicator.example.com to access her email service at
www.email.example.com and her voice over IP service at www.email.example.com and her voice over IP service at
www.voip.example.com. Email addresses and telephone numbers are www.voip.example.com. Email addresses and telephone numbers are
obtained from Alice's address book at www.contacts.example.com. obtained from Alice's address book at www.contacts.example.com.
Those web sites all rely on the same authorization server, so the Those web sites all rely on the same authorization server, so the
application at www.communicator.example.com can receive a single application at www.communicator.example.com can receive a single
authorization from Alice for getting access to these three services authorization from Alice for getting access to these three services
on her behalf at once. on her behalf at once.
The authorization server needs to issue different access tokens for
the involved services due to security and privacy policy. One
typical reason is the use of the symmetric secrets for signing self-
contained access tokens. In this use case, using a particular token
for more than a single service introduces a security risk.
Note: This use case is especially useful for native applications Note: This use case is especially useful for native applications
since a web browser needs to be launched only once. since a web browser needs to be launched only once.
Pre-conditions: Pre-conditions:
o The same authorization server serves Alice and all involved o The same authorization server serves Alice and all involved
servers servers
o Alice has registered with the authorization server for o Alice has registered with the authorization server for
skipping to change at page 17, line 40 skipping to change at page 17, line 24
o A callback URL of the application running at o A callback URL of the application running at
www.communicator.example.com must be known to the authorization www.communicator.example.com must be known to the authorization
server server
o The authorization server must be able to issue the separate o The authorization server must be able to issue the separate
service-specific tokens (with different, scope, permissions, and service-specific tokens (with different, scope, permissions, and
expiration dates) for access to the requested services (such as expiration dates) for access to the requested services (such as
email and VoIP) email and VoIP)
2.11. Gateway for browser-based VoIP applets Note: OAuth 2.0 does not support this use case
2.10. Gateway for browser-based VoIP applets
Description: Description:
Alice accesses a social site on a web server at Alice accesses a social site on a web server at
www.social.example.com. Her browser loads a VoIP applet that enables www.social.example.com. Her browser loads a VoIP applet that enables
her to make a VoIP call using her SIP server at her to make a VoIP call using her SIP server at
www.sipservice.example.com. The application at www.sipservice.example.com. The application at
www.social.example.com gets Alice's authorization to use her account www.social.example.com gets Alice's authorization to use her account
with www.sipservice.example.com without learning her authentication with www.sipservice.example.com without learning her authentication
credentials with www.sipservice.example.com. credentials with www.sipservice.example.com.
skipping to change at page 18, line 47 skipping to change at page 18, line 34
o Application at www.sipservice.example.com must be able to o Application at www.sipservice.example.com must be able to
authenticate the application at www.social.example.com and authenticate the application at www.social.example.com and
validate the access token validate the access token
o Alice's manual involvement in the OAuth authorization procedure o Alice's manual involvement in the OAuth authorization procedure
(e.g., entering an URL or a password) should not be required. (e.g., entering an URL or a password) should not be required.
(Alice's authentication to www.sipservice.example.com is not in (Alice's authentication to www.sipservice.example.com is not in
the OAuth scope) the OAuth scope)
2.12. Signed Messages Note: OAuth 2.0 does not support this use case
2.11. Signed Messages
Description: Description:
Alice manages all her personal health records in her personal health Alice manages all her personal health records in her personal health
data store at a server at www.myhealth.example.com, which manages data store at a server at www.myhealth.example.com, which manages
authorization of access to Alice's participating health systems. authorization of access to Alice's participating health systems.
Alice's Primary Care Physician (PCP), which has a Web site at Alice's Primary Care Physician (PCP), which has a Web site at
www.pcp.example.com, recommends her to see a sleep specialist www.pcp.example.com, recommends her to see a sleep specialist
(www.sleepwell.example.com). Alice arrives at the sleep specialist's (www.sleepwell.example.com). Alice arrives at the sleep specialist's
office and authorizes it to access her basic health data at her PCP's office and authorizes it to access her basic health data at her PCP's
skipping to change at page 20, line 43 skipping to change at page 20, line 32
verifying the signature of the authorization token verifying the signature of the authorization token
o The application at www.pcp.example.com must be capable of parsing o The application at www.pcp.example.com must be capable of parsing
the authorization token and verifying that this token was issued the authorization token and verifying that this token was issued
to the application at www.sleepwell.com to the application at www.sleepwell.com
o The application at www.pcp.example.com must be capable of o The application at www.pcp.example.com must be capable of
retrieving the requested data and returning it to the application retrieving the requested data and returning it to the application
at www.sleepwell.example.com at www.sleepwell.example.com
2.13. Signature with asymmetric secret Note: OAuth 2.0 does not support this use case
2.12. Signature with asymmetric secret
Description: Description:
Alice accesses an application running on a web server at Alice accesses an application running on a web server at
www.printphotos.example.com and instructs it to print her photographs www.printphotos.example.com and instructs it to print her photographs
that are stored on a server www.storephotos.example.com. The that are stored on a server www.storephotos.example.com. The
application at www.printphotos.example.com, which does not have a application at www.printphotos.example.com, which does not have a
shared secret with www.storephotos.example.com, receives Alice's shared secret with www.storephotos.example.com, receives Alice's
authorization for accessing her photographs without learning her authorization for accessing her photographs without learning her
authentication credentials with www.storephotos.example.com. authentication credentials with www.storephotos.example.com.
skipping to change at page 22, line 18 skipping to change at page 22, line 10
www.storephotos.example.com) www.storephotos.example.com)
o The application at www.storephotos.example.com must be capable of o The application at www.storephotos.example.com must be capable of
issuing the HTTP redirect requests to Alice's browser issuing the HTTP redirect requests to Alice's browser
o Alice's manual involvement in the OAuth authorization procedure o Alice's manual involvement in the OAuth authorization procedure
(e.g., entering an URL or a password) should not be required. (e.g., entering an URL or a password) should not be required.
(Alice's authentication to www.storephotos.example.com is not in (Alice's authentication to www.storephotos.example.com is not in
the OAuth scope) the OAuth scope)
Note: OAuth 2.0 does not support this use case
3. Authors of the use cases 3. Authors of the use cases
The major contributors of the use cases are as follows: The major contributors of the use cases are as follows:
W. Beck, Deutsche Telekom AG W. Beck, Deutsche Telekom AG
G. Brail, Sonoa Systems G. Brail, Sonoa Systems
B. de hOra B. de hOra
B. Eaton, Google B. Eaton, Google
S. Farrell, NewBay Software S. Farrell, NewBay Software
G. Fletcher, AOL G. Fletcher, AOL
skipping to change at page 22, line 43 skipping to change at page 22, line 37
T. Lodderstedt, Deutsche Telekom T. Lodderstedt, Deutsche Telekom
E. Maler, PayPal E. Maler, PayPal
D. Recordon, Facebook D. Recordon, Facebook
L. Shepard, Facebook L. Shepard, Facebook
A. Tom, Yahoo! A. Tom, Yahoo!
B. Vrancken, Alcatel-Lucent B. Vrancken, Alcatel-Lucent
Z. Zeltsan, Alcatel-Lucent Z. Zeltsan, Alcatel-Lucent
4. Security considerations 4. Security considerations
TBD The OAuth 2.0 specification [I-D.ietf-oauth-v2] provides the
implementers with security guidelines for all OAuth 2.0 client
profiles. In addition, a comprehensive OAuth security model and
background for the protocol design are provided by
[I-D.ietf-oauth-v2-threatmodel].
5. IANA considerations 5. IANA considerations
This Internet Draft includes no request to IANA. This Internet Draft includes no request to IANA.
6. Acknowledgements 6. Acknowledgements
The authors thank Igor Faynberg and Hui-Lan Lu for their invaluable The authors thank Igor Faynberg and Hui-Lan Lu for their invaluable
help with preparing this document. Special thanks are to the draft help with preparing this document. Special thanks are to the draft
reviewers Thomas Hardjono and Melinda Shore, whose suggestions have reviewers Thomas Hardjono and Melinda Shore, whose suggestions have
helped to improve the draft. helped to improve the draft.
7. Normative References 7. References
[I-D.draft-ietf-oauth-v2] 7.1. Normative References
Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth
2.0 Authorization Protocol". [I-D.ietf-oauth-v2]
Hardt, D., "The OAuth 2.0 Authorization Framework",
draft-ietf-oauth-v2-31 (work in progress), August 2012.
7.2. Informative References
[I-D.ietf-oauth-v2-threatmodel]
Lodderstedt, T., McGloin, M., and P. Hunt, "OAuth 2.0
Threat Model and Security Considerations",
draft-ietf-oauth-v2-threatmodel-07 (work in progress),
August 2012.
[I-D.ietf-oauth-assertions]
Campbell, B., Mortimore, C., Jones, M., and Y. Goland,
"Assertion Framework for OAuth 2.0",
draft-ietf-oauth-assertions-05 (work in progress),
September 2012.
[I-D.ietf-oauth-saml2-bearer]
Campbell, B. and C. Mortimore, "SAML 2.0 Bearer Assertion
Profiles for OAuth 2.0", draft-ietf-oauth-saml2-bearer-14
(work in progress), September 2012.
[I-D.ietf-oauth-jwt-bearer]
Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token
(JWT) Bearer Token Profiles for OAuth 2.0",
draft-ietf-oauth-jwt-bearer-02 (work in progress),
September 2012.
Authors' Addresses Authors' Addresses
George Fletcher George Fletcher
AOL AOL
Email: gffletch@aol.com Email: gffletch@aol.com
Torsten Lodderstedt Torsten Lodderstedt
Deutsche Telekom AG Deutsche Telekom AG
 End of changes. 60 change blocks. 
202 lines changed or deleted 223 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/