draft-ietf-oauth-use-cases-02.txt   draft-ietf-oauth-use-cases-03.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: April 13, 2013 Deutsche Telekom AG Expires: April 25, 2013 Deutsche Telekom AG
Z. Zeltsan Z. Zeltsan
Alcatel-Lucent Alcatel-Lucent
October 10, 2012 October 22, 2012
OAuth Use Cases OAuth Use Cases
draft-ietf-oauth-use-cases-02 draft-ietf-oauth-use-cases-03
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 April 13, 2013. This Internet-Draft will expire on April 25, 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 22 skipping to change at page 2, line 22
2.3. Native Application . . . . . . . . . . . . . . . . . . . . 6 2.3. Native Application . . . . . . . . . . . . . . . . . . . . 6
2.4. In-App-Payment (based on Native Application) . . . . . . . 8 2.4. In-App-Payment (based on Native Application) . . . . . . . 8
2.5. Device with an input method . . . . . . . . . . . . . . . 10 2.5. Device with an input method . . . . . . . . . . . . . . . 10
2.6. Client password (shared secret) credentials . . . . . . . 12 2.6. Client password (shared secret) credentials . . . . . . . 12
2.7. Assertion . . . . . . . . . . . . . . . . . . . . . . . . 12 2.7. Assertion . . . . . . . . . . . . . . . . . . . . . . . . 12
2.8. Access token exchange . . . . . . . . . . . . . . . . . . 13 2.8. Access token exchange . . . . . . . . . . . . . . . . . . 13
2.9. Multiple access tokens . . . . . . . . . . . . . . . . . . 15 2.9. Multiple access tokens . . . . . . . . . . . . . . . . . . 15
2.10. Gateway for browser-based VoIP applets . . . . . . . . . . 17 2.10. Gateway for browser-based VoIP applets . . . . . . . . . . 17
2.11. Signed Messages . . . . . . . . . . . . . . . . . . . . . 18 2.11. Signed Messages . . . . . . . . . . . . . . . . . . . . . 18
2.12. Signature with asymmetric secret . . . . . . . . . . . . . 20 2.12. Signature with asymmetric secret . . . . . . . . . . . . . 20
3. Authors of the use cases . . . . . . . . . . . . . . . . . . . 22 3. Authors of the use cases . . . . . . . . . . . . . . . . . . . 21
4. Security considerations . . . . . . . . . . . . . . . . . . . 22 4. Security considerations . . . . . . . . . . . . . . . . . . . 22
5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 22 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 22
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.1. Normative References . . . . . . . . . . . . . . . . . . . 23 7.1. Normative References . . . . . . . . . . . . . . . . . . . 22
7.2. Informative 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
skipping to change at page 3, line 33 skipping to change at page 3, line 33
2. OAuth use cases 2. OAuth use cases
This section describes 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 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. The application
application at www.printphotos.example.com receives Alice's at www.printphotos.example receives Alice's authorization for
authorization for accessing her photographs without learning her accessing her photographs without learning her authentication
authentication credentials with www.storephotos.example.com. credentials with www.storephotos.example.
Pre-conditions: Pre-conditions:
o Alice has registered with www.storephotos.example.com to enable o Alice has registered with www.storephotos.example to enable
authentication authentication
o The application at www.printphotos.example.com has established o The application at www.printphotos.example has established
authentication credentials with the application at authentication credentials with the application at
www.storephotos.example.com www.storephotos.example
Post-conditions: Post-conditions:
A successful procedure results in the application A successful procedure results in the application
www.printphotos.example.com receiving an authorization code from www.printphotos.example receiving an authorization code from
www.storephotos.example.com. The code is bound to the application at www.storephotos.example. The code is bound to the application at
www.printphotos.example.com and to the callback URL supplied by the www.printphotos.example and to the callback URL supplied by the
application. The application at www.printphotos.example.com uses the application. The application at www.printphotos.example uses the
authorization code for obtaining an access token from authorization code for obtaining an access token from
www.storephotos.example.com. The application at www.storephotos.example. The application at www.storephotos.example
www.storephotos.example.com issues an access token after issues an access token after authenticating the application at
authenticating the application at www.printphotos.example.com and www.printphotos.example and validating the authorization code that it
validating the authorization code that it has submitted. The has submitted. The application at www.printphotos.example uses the
application at www.printphotos.example.com uses the access token for access token for getting access to Alice's photographs at
getting access to Alice's photographs at www.storephotos.example.com. www.storephotos.example.
Note: When an access token expires, the service at Note: When an access token expires, the service at
www.printphotos.example.com needs to repeat the OAuth procedure for www.printphotos.example needs to repeat the OAuth procedure for
getting Alice's authorization to access her photographs at getting Alice's authorization to access her photographs at
www.storephotos.example.com. Alternatively, if Alice wants to grant www.storephotos.example. Alternatively, if Alice wants to grant the
the application a long lasting access to her resources at application a long lasting access to her resources at
www.storephotos.example.com, the authorization server associated with www.storephotos.example, the authorization server associated with
www.storephotos.example.com may issue the long-living tokens. Those www.storephotos.example may issue the long-living tokens. Those
tokens can be exchanged for short-living access tokens required to tokens can be exchanged for short-living access tokens required to
access www.storephotos.example.com. access www.storephotos.example.
Requirements: Requirements:
o The server www.printphotos.example.com, which hosts an OAuth o The server www.printphotos.example, which hosts an OAuth client,
client, must be capable of issuing the HTTP redirect requests to must be capable of issuing the HTTP redirect requests to Alice's
Alice's user agent - a browser user agent - a browser
o Application at www.storephotos.example.com must be able to o Application at www.storephotos.example must be able to
authenticate Alice. The authentication method is not in the OAuth authenticate Alice. The authentication method is not in the OAuth
scope scope
o Application at www.storephotos.example.com must obtain Alice's o Application at www.storephotos.example must obtain Alice's
authorization of the access to her photos by authorization of the access to her photos by
www.printphotos.example.com www.printphotos.example
o Application at www.storephotos.example.com may identify to Alice o Application at www.storephotos.example may identify to Alice the
the scope of access that www.printphotos.example.com has requested scope of access that www.printphotos.example has requested while
while asking for Alice's authorization asking for Alice's authorization
o Application at www.storephotos.example.com must be able to o Application at www.storephotos.example must be able to
authenticate the application at www.printphotos.example.com and authenticate the application at www.printphotos.example 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.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 must provide a callback URL
URL to the application at www.storephotos.example.com (note: the to the application at www.storephotos.example (note: the URL can
URL can be pre-registered with www.storephotos.example.com) be pre-registered with www.storephotos.example)
o Application at www.storephotos.example.com is required to maintain o Application at www.storephotos.example is required to maintain a
a record that associates the authorization code with the record that associates the authorization code with the application
application at www.printphotos.example.com and the callback URL at www.printphotos.example and the callback URL provided by the
provided by the application application
o Access tokens are bearer's tokens (they are not associated with a o Access tokens are bearer's tokens (they are not associated with a
specific application, such as www.printphotos.example.com) and specific application, such as www.printphotos.example) and should
should have a short lifespan have a short lifespan
o Application at www.storephotos.example.com must invalidate the o Application at www.storephotos.example 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 is not in the
the OAuth scope. Her registration with OAuth scope. Her registration with www.storephotos.example is
www.storephotos.example.com is required as a pre-condition) required as a pre-condition)
Note: OAuth 2.0 supports this use case Note: OAuth 2.0 supports this use case
2.2. User-agent 2.2. User-agent
Description: Description:
Alice has on her computer a gaming application. She keeps her scores Alice has on her computer a gaming application. She keeps her scores
in a database of a social site at www.fun.example.com. In order to in a database of a social site at www.fun.example. In order to
upload Alice's scores, the application gets access to the database upload Alice's scores, the application gets access to the database
with her authorization. with her authorization.
Pre-conditions: Pre-conditions:
o Alice uses a gaming application implemented in a scripting o Alice uses a gaming application implemented in a scripting
language (e.g., JavaScript) that runs in her browser and uses language (e.g., JavaScript) that runs in her browser and uses
OAuth for accessing a social site at www.fun.example.com OAuth for accessing a social site at www.fun.example
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 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 and has an identifier
o Alice has registered with www.fun.example.com for identification o Alice has registered with www.fun.example for identification and
and authentication authentication
o An auxiliary web server at www.help.example.com is reachable by o An auxiliary web server at www.help.example 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:
A successful procedure results in Alice's browser receiving an access A successful procedure results in Alice's browser receiving an access
token. The access token is received from www.fun.example.com as a token. The access token is received from www.fun.example as a
fragment of a redirection URL of an auxiliary web server fragment of a redirection URL of an auxiliary web server
www.help.example.com. Alice's browser follows the redirection, but www.help.example. Alice's browser follows the redirection, but
retains the fragment. From the auxiliary web server at retains the fragment. From the auxiliary web server at
www.help.example.com Alice's browser downloads a script that extracts www.help.example Alice's browser downloads a script that extracts
access token from the fragment and makes it available to the gaming access token from the fragment and makes it available to the gaming
application. The application uses the access token to gain access to application. The application uses the access token to gain access to
Alice's data at www.fun.example.com. Alice's data at www.fun.example.
Requirements: Requirements:
o Registration of the application running in the Alice's browser o Registration of the application running in the Alice's browser
with the application running on www.fun.example.com is required with the application running on www.fun.example is required for
for identification identification
o Alice's authentication with www.fun.example.com is required o Alice's authentication with www.fun.example is required
o Application running at www.fun.example.com must be able to o Application running at www.fun.example must be able to describe to
describe to Alice the request made by the gaming application Alice the request made by the gaming application running on her
running on her computer and obtain Alice's authorization for or computer and obtain Alice's authorization for or denial of the
denial of the requested access 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 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) that is
is capable of retrieving an access token from an URL capable of retrieving an access token from an URL
Note: OAuth 2.0 supports this use case Note: OAuth 2.0 supports this use case
2.3. Native Application 2.3. Native Application
Description: Description:
Alice wants to upload (or download) her photographs to (or from) Alice wants to upload (or download) her photographs to (or from)
storephotos.example.com using her smartphone. She downloads and storephotos.example using her smartphone. She downloads and installs
installs a photo app on her smartphone. In order to enable the app a photo app on her smartphone. In order to enable the app to access
to access her photographs, Alice needs to authorize the app to access her photographs, Alice needs to authorize the app to access the web
the web site on her behalf. The authorization shall be valid for a site on her behalf. The authorization shall be valid for a prolonged
prolonged duration (e.g. several months), so that Alice does not need duration (e.g. several months), so that Alice does not need to
to authenticate and authorize access on every execution of the app. authenticate and authorize access on every execution of the app. It
It shall be possible to withdraw the app's authorization both on the shall be possible to withdraw the app's authorization both on the
smartphone as well as on the site storephotos.example.com. smartphone as well as on the site storephotos.example.
Pre-conditions: Pre-conditions:
o Alice has installed a (native) photo app application on her o Alice has installed a (native) photo app application on her
smartphone smartphone
o The installed application is registered with the social site at o The installed application is registered with the social site at
storephotos.example.com and has an identifier storephotos.example and has an identifier
o Alice holds an account with storephotos.example.com o Alice holds an account with storephotos.example
o Authentication and authorization shall be performed in an o Authentication and authorization shall be performed in an
interactive, browser-based process. The smartphone's browser is interactive, browser-based process. The smartphone's browser is
used for authenticating Alice and for enabling her to authorize used for authenticating Alice and for enabling her to authorize
the request by the Mobile App the request by the Mobile App
Post-conditions: Post-conditions:
A successful procedure results in Alice's app receiving the access A successful procedure results in Alice's app receiving the access
and refresh tokens. The app obtains the tokens by utilizing the and refresh tokens. The app obtains the tokens by utilizing the
Authorization Code flow. The application uses the access token to Authorization Code flow. The application uses the access token to
gain access to Alice's data at storephotos.example.com. The refresh gain access to Alice's data at storephotos.example. The refresh
tokens are persistently stored on the device for use in subsequent tokens are persistently stored on the device for use in subsequent
app executions. If a refresh token exists on app startup, the app app executions. If a refresh token exists on app startup, the app
directly uses the refresh token to obtain a new access token. directly uses the refresh token to obtain a new access token.
Requirements: Requirements:
o Alice's authentication with storephotos.example.com is required o Alice's authentication with storephotos.example is required
o Registration of the application running on Alice's smartphone is o Registration of the application running on Alice's smartphone is
required for identification and registration and may be carried required for identification and registration and may be carried
out on a per installation base out on a per installation base
o The application at storephotos.example.com provides a capability o The application at storephotos.example provides a capability to
to view and delete the apps' authorizations. This implies that view and delete the apps' authorizations. This implies that the
the different installations of the same app on the different different installations of the same app on the different devices
devices can be distinguished (e.g., by a device name or a can be distinguished (e.g., by a device name or a telephone
telephone number) number)
o The app must provide Alice an option to logout. The logout must o The app must provide Alice an option to logout. The logout must
result in revocation of the refresh tokens on the authorization result in revocation of the refresh tokens on the authorization
server server
Note: OAuth 2.0 supports this use case Note: OAuth 2.0 supports this use case
2.4. In-App-Payment (based on Native Application) 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. With Alice's authorization the application accesses
accesses her account at www.sp.example.com and enables her to make her account at www.sp.example and enables her to make the payment.
the payment.
Pre-conditions: Pre-conditions:
o Alice has registered and has an account with her service provider o Alice has registered and has an account with her service provider
at www.sp.example.com at www.sp.example
o The application is registered with the service provider at o The application is registered with the service provider at
www.sp.example.com. This enables the server provider to provide www.sp.example. This enables the server provider to provide Alice
Alice with all necessary information about the gaming application with all necessary information about the gaming application
(including the information about the purchasing price) (including the information about the purchasing price)
o Alice has a Web user-agent (e.g., a browser or a widget runtime) o Alice has a Web user-agent (e.g., a browser or a widget runtime)
installed on her computer installed on her computer
Post-conditions: Post-conditions:
A successful procedure results in the gaming application invoking the A successful procedure results in the gaming application invoking the
user browser and directing it to the authorization server of the user browser and directing it to the authorization server of the
service provider. The HTTP message includes information about the service provider. The HTTP message includes information about the
skipping to change at page 8, line 51 skipping to change at page 8, line 50
enables Alice to save the transaction details including the enables Alice to save the transaction details including the
authorization code issued for the gaming application. Then the authorization code issued for the gaming application. Then the
authorization server redirects Alice's browser to a custom scheme URI authorization server redirects Alice's browser to a custom scheme URI
(registered with the operating system). This redirection request (registered with the operating system). This redirection request
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.
Requirements: Requirements:
Note: The focus is on the requirements that are specific to this use Note: The focus is on the requirements that are specific to this use
case. The requirements that are common to the native applications case. The requirements that are common to the native applications
are listed in the preceding use case. 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 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 secure the service provider and the purpose for the charge) over a 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 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 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 must be able to call back to the gaming application
application with the authorization result over a secure transport 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 must enable the gaming application to exchange an
an authorization code for an access token over a secure transport 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 must verify the authorization code and invalidate
invalidate it after its first use 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 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 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 must enable the resource server www.sp.example to
www.sp.example.com to obtain the transaction information that is obtain the transaction information that is linked to the issued
linked to the issued access token access token
o Resource server at www.sp.example.com must verify access token and o Resource server at www.sp.example must verify access token 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 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 (note: it can
can be preregistered with the authorization server) 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 is not in the OAuth
scope) scope)
Note: OAuth 2.0 does not directly support this use case Note: OAuth 2.0 does not directly support this use case
2.5. Device with an input method 2.5. Device with an input method
Description: Description:
Alice has a device, such as a gaming console, that does not support Alice has a device, such as a gaming console, that does not support
an easy data-entry method. She also has access to a computer with a an easy data-entry method. She also has access to a computer with a
browser. The application running on the Alice's device gets browser. The application running on the Alice's device gets
authorized access to a protected resource (e.g., photographs) stored authorized access to a protected resource (e.g., photographs) stored
on a server at www.storephotos.example.com on a server at www.storephotos.example
Pre-conditions: Pre-conditions:
o Alice uses a gaming console, which does not have an easy data- o Alice uses a gaming console, which does not have an easy data-
entry method, for accessing her photographs at entry method, for accessing her photographs at
www.storephotos.example.com www.storephotos.example
o Alice is able to connect to www.storephotos.example.com using a o Alice is able to connect to www.storephotos.example using a
computer that runs a browser computer that runs a browser
o Auhtorization server associated with www.storephotos.example.com o Auhtorization server associated with www.storephotos.example is
is able to generate an authorization code that is suitable for able to generate an authorization code that is suitable for
reading and writing by a human (e.g., an alphanumeric string that reading and writing by a human (e.g., an alphanumeric string that
is not too long) is not too long)
o The gaming device supports input of the characters that can be o The gaming device supports input of the characters that can be
found in an authorization code found in an authorization code
o Alice has registered with the authorization server associated with o Alice has registered with the authorization server associated with
www.storephotos.example.com for identification and authentication www.storephotos.example for identification and authentication
Post-conditions: Post-conditions:
o Alice, interacting with an authorization server associated with o Alice, interacting with an authorization server associated with
www.storephotos.example, authorizes access to her photographs by www.storephotos.example, authorizes access to her photographs by
her gaming console. She uses her browser-equipped computer for her gaming console. She uses her browser-equipped computer for
OAuth authorization OAuth authorization
o The authorization server associated with o The authorization server associated with www.storephotos.example
www.storephotos.example.com responds to Alice's authorization by responds to Alice's authorization by displaying an authorization
displaying an authorization code in her browser's window code in her browser's window
o Alice enters the displayed code into an input field on the gaming o Alice enters the displayed code into an input field on the gaming
console console
o The gaming console exchanges with the authorization server the o The gaming console exchanges with the authorization server the
authorization code for an access token authorization code for an access token
o Alice's gaming console uses the access token to access the o Alice's gaming console uses the access token to access the
photographs on www.storephotos.example.com photographs on www.storephotos.example
Requirements: Requirements:
o Alice's authentication with the authorization server is required o Alice's authentication with the authorization server is required
o Alice is required to perform authorization of her gaming console o Alice is required to perform authorization of her gaming console
by interacting with the authorization server associated with by interacting with the authorization server associated with
www.storephotos.example.com. To that end she has to direct her www.storephotos.example. To that end she has to direct her
browser to the authorization server browser to the authorization server
o After authorizing the access and getting an authorization code o After authorizing the access and getting an authorization code
displayed in her browser, Alice has to enter the displayed code displayed in her browser, Alice has to enter the displayed code
into an input field on the gaming console into an input field on the gaming console
o The gaming console should be able to exchange the authorization o The gaming console should be able to exchange the authorization
code for an access token through interaction with the code for an access token through interaction with the
authorization server associated with www.storephotos.example.com authorization server associated with www.storephotos.example
o The URL of the authorization server and the authorization code o The URL of the authorization server and the authorization code
must be suitable for manual entry must be suitable for manual entry
o The authorization code must be composed of the characters that are o The authorization code must be composed of the characters that are
appropriate for input to the gaming console appropriate for input to the gaming console
o Because the authorization code is relatively short and its o Because the authorization code is relatively short and its
character set is limited, the code's lifetime should be configured character set is limited, the code's lifetime should be configured
appropriately appropriately
Note: OAuth 2.0 supports this use case Note: OAuth 2.0 supports this use case
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
www.GoodPay.example.com gets authenticated access to the employees' gets authenticated access to the employees' attendance data stored at
attendance data stored at www.GoodWork.example.com. www.GoodWork.example.
Pre-conditions: Pre-conditions:
o The application at www.GoodPay.example.com has established through o The application at www.GoodPay.example has established through a
a registration an identifier and a shared secret with the registration an identifier and a shared secret with the
application running at www.GoodWork.example.com application running at www.GoodWork.example
o The scope of the access by the application at o The scope of the access by the application at www.GoodPay.example
www.GoodPay.example.com to the data stored at to the data stored at www.GoodWork.example has been defined
www.GoodWork.example.com has been defined
Post-conditions: Post-conditions:
A successful procedure results in the application at A successful procedure results in the application at
www.GoodPay.example.com receiving an access token after www.GoodPay.example receiving an access token after authenticating to
authenticating to the application running at the application running at www.GoodWork.example.
www.GoodWork.example.com.
Requirements: Requirements:
o Authentication of the application at www.GoodPay.example.com to o Authentication of the application at www.GoodPay.example to the
the application at www.GoodWork.example.com is required application at www.GoodWork.example is required
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 submits to the application at
www.GoodWork.example.com in the initial HTTP request www.GoodWork.example 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 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
www.GoodPay.example.com gets authenticated access to the employees' gets authenticated access to the employees' attendance data stored at
attendance data stored at www.GoodWork.example.com. www.GoodWork.example.
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.
Pre-conditions: Pre-conditions:
o The application at www.GoodPay.example.com has obtained an o The application at www.GoodPay.example has obtained an
authentication assertion from a party that is trusted by the authentication assertion from a party that is trusted by the
application at www.GoodWork.example.com application at www.GoodWork.example
o The scope of the access by the application at o The scope of the access by the application at www.GoodPay.example
www.GoodPay.example.com to the data stored at to the data stored at www.GoodWork.example has been defined
www.GoodWork.example.com has been defined
o The application at www.GoodPay.example.com has established trust o The application at www.GoodPay.example has established trust
relationship with the asserting party and is capable of validating relationship with the asserting party and is capable of validating
its assertions its assertions
Post-conditions: Post-conditions:
A successful procedure results in the application at A successful procedure results in the application at
www.GoodPay.example.com receiving an access token after www.GoodPay.example receiving an access token after authenticating to
authenticating to the application running at www.GoodWork.example.com the application running at www.GoodWork.example by presenting an
by presenting an assertion (e.g., SAML assertion). assertion (e.g., SAML assertion).
Requirements: Requirements:
o Authentication of the application at www.GoodPay.example.com to o Authentication of the application at www.GoodPay.example to the
the application at www.GoodWork.example.com is required application at www.GoodWork.example is required
o The application running at www.GoodWork.example.com must be o The application running at www.GoodWork.example must be capable of
capable of validating assertion presented by the application validating assertion presented by the application running at
running at www.GoodPay.example.com www.GoodPay.example
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
Note: OAuth 2.0 supports this use case Note: OAuth 2.0 supports this use case
2.8. 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 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. The application running on
www.storephotos.example.com, while serving the request of the www.storephotos.example, while serving the request of the application
application at www.printphotos.example.com, discovers that some of at www.printphotos.example, discovers that some of the requested
the requested photographs have been moved to photographs have been moved to www.storephotos1.example. The
www.storephotos1.example.com. The application at application at www.storephotos.example retrieves the missing
www.storephotos.example.com retrieves the missing photographs from photographs from www.storephotos1.example and provides access to all
www.storephotos1.example.com and provides access to all requested requested photographs to the application at www.printphotos.example.
photographs to the application at www.printphotos.example.com. The The application at www.printphotos.example carries out Alice's
application at www.printphotos.example.com carries out Alice's
request. request.
Pre-conditions: Pre-conditions:
o The application running on www.printphotos.example.com is capable o The application running on www.printphotos.example is capable of
of interacting with Alice's browser interacting with Alice's browser
o Alice has registered with and can be authenticated by o Alice has registered with and can be authenticated by
authorization server authorization server
o The applications at www.storephotos.example.com has registered o The applications at www.storephotos.example has registered with
with authorization server authorization server
o The applications at www.storephotos1.example.com has registered o The applications at www.storephotos1.example has registered with
with authorization server authorization server
o The application at www.printphotos.example.com has registered with o The application at www.printphotos.example has registered with
authorization server authorization server
Post-conditions: Post-conditions:
A successful procedure results in the application at A successful procedure results in the application at
www.printphotos.example.com receiving an access token that allows www.printphotos.example receiving an access token that allows access
access to Alice's photographs. This access token is used for the to Alice's photographs. This access token is used for the following
following purposes: purposes:
o By the application running at www.printphotos.example.com to get o By the application running at www.printphotos.example to get
access to the photographs at www.storephotos.example.com access to the photographs at www.storephotos.example
o By the application running at www.storephotos.example.com to o By the application running at www.storephotos.example to obtain
obtain from authorization server another access token that allows from authorization server another access token that allows it to
it to retrieve the additional photographs stored at retrieve the additional photographs stored at
www.storephotos1.example.com www.storephotos1.example
As the result, there are two access token issued for two different As the result, there are two access token issued for two different
applications. The tokens may have different properties (e.g., scope, applications. The tokens may have different properties (e.g., scope,
permissions, and expiration dates). permissions, and expiration dates).
Requirements: Requirements:
o The applications at www.printphotos.example.com and o The applications at www.printphotos.example and
www.storephotos.example.com require different access tokens www.storephotos.example require different access tokens
o The application at www.printphotos.example.com is required to o The application at www.printphotos.example is required to provide
provide its callback URL to the application at its callback URL to the application at www.storephotos.example
www.storephotos.example.com
o Authentication of the application at www.printphotos.example.com o Authentication of the application at www.printphotos.example to
to the authorization server is required the authorization server is required
o Alice's authentication by the authorization server is required o Alice's authentication by the authorization server is required
o The authorization server must be able to describe to Alice the o The authorization server must be able to describe to Alice the
request of the application at www.printphotos.example.com and request of the application at www.printphotos.example and obtain
obtain her authorization (or rejection) her authorization (or rejection)
o If Alice has authorized the request, the authorization server must o If Alice has authorized the request, the authorization server must
be able to issue an access token that enables the application at be able to issue an access token that enables the application at
www.printphotos.example.com to get access to Alice's photographs www.printphotos.example to get access to Alice's photographs at
at www.storephotos.example.com www.storephotos.example
o The authorization server must be able, based on the access token o The authorization server must be able, based on the access token
presented by the application at www.printphotos.example.com, to presented by the application at www.printphotos.example, to
generate another access token that allows the application at generate another access token that allows the application at
www.storephotos.example.com to get access to the photographs at www.storephotos.example to get access to the photographs at
www.storephotos1.example.com. In this context the authorization www.storephotos1.example. In this context the authorization
server must validate the authorization of the application at server must validate the authorization of the application at
www.storephotos.example.com to obtain the token. www.storephotos.example to obtain the token.
o The application at www.storephotos.example.com must be able to o The application at www.storephotos.example 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
o The application at www.storephotos1.example.com must be able to o The application at www.storephotos1.example 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
Note: This use case is indirectly supported by Assertion frmamework 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 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] 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 and JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0
[I-D.ietf-oauth-jwt-bearer] [I-D.ietf-oauth-jwt-bearer]
2.9. Multiple access tokens 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 to access her email service at
www.email.example.com and her voice over IP service at www.email.example and her voice over IP service at www.voip.example.
www.voip.example.com. Email addresses and telephone numbers are Email addresses and telephone numbers are obtained from Alice's
obtained from Alice's address book at www.contacts.example.com. address book at www.contacts.example. Those web sites all rely on
Those web sites all rely on the same authorization server, so the the same authorization server, so the application at
application at www.communicator.example.com can receive a single www.communicator.example can receive a single authorization from
authorization from Alice for getting access to these three services Alice for getting access to these three services on her behalf at
on her behalf at once. once.
The authorization server needs to issue different access tokens for The authorization server needs to issue different access tokens for
the involved services due to security and privacy policy. One the involved services due to security and privacy policy. One
typical reason is the use of the symmetric secrets for signing self- typical reason is the use of the symmetric secrets for signing self-
contained access tokens. In this use case, using a particular token contained access tokens. In this use case, using a particular token
for more than a single service introduces a security risk. 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
authentication and for authorization of the requests of the authentication and for authorization of the requests of the
communicator application running at www.communicator.example.com communicator application running at www.communicator.example
o The email application at www.email.example.com has registered with o The email application at www.email.example has registered with the
the authorization server for authentication authorization server for authentication
o The VoIP application at www.voip.example.com has registered with o The VoIP application at www.voip.example has registered with the
the authorization server for authentication authorization server for authentication
o The address book at www.contacts.example.com has registered with o The address book at www.contacts.example has registered with the
the authorization server for authentication authorization server for authentication
Post-conditions: Post-conditions:
A successful procedure results in the application at A successful procedure results in the application at
www.communicator.example.com receiving three different access tokens: www.communicator.example receiving three different access tokens: one
one for accessing the email service at www.email.example.com, one for for accessing the email service at www.email.example, one for
accessing the contacts at www.contacts.example.com, and one for accessing the contacts at www.contacts.example, and one for accessing
accessing the VoIP service at www.voip.example.com. the VoIP service at www.voip.example.
Requirements: Requirements:
o The application running at www.communicator.example.com must be o The application running at www.communicator.example must be
authenticated by the authorization server authenticated by the authorization server
o Alice must be authenticated by the authorization server o Alice must be authenticated by the authorization server
o The application running at www.communicator.example.com must be o The application running at www.communicator.example must be able
able to get a single Alice's authorization for access to the to get a single Alice's authorization for access to the multiple
multiple services (e.g., email and VoIP) services (e.g., email and VoIP)
o The application running at www.communicator.example.com must be o The application running at www.communicator.example must be able
able to recognize that all three applications rely on the same to recognize that all three applications rely on the same
authorization server authorization server
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 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)
Note: OAuth 2.0 does not support this use case Note: OAuth 2.0 does not support this use case
2.10. Gateway for browser-based VoIP applets 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.
www.social.example.com. Her browser loads a VoIP applet that enables Her browser loads a VoIP applet that enables her to make a VoIP call
her to make a VoIP call using her SIP server at using her SIP server at www.sipservice.example. The application at
www.sipservice.example.com. The application at www.social.example gets Alice's authorization to use her account with
www.social.example.com gets Alice's authorization to use her account www.sipservice.example without learning her authentication
with www.sipservice.example.com without learning her authentication credentials with www.sipservice.example.
credentials with www.sipservice.example.com.
Pre-conditions: Pre-conditions:
o Alice has registered with www.sipservice.example.com for o Alice has registered with www.sipservice.example for
authentication authentication
o The application at www.social.example.com has established o The application at www.social.example has established
authentication credentials with the application at authentication credentials with the application at
www.sipservice.example.com www.sipservice.example
Post-conditions: Post-conditions:
A successful procedure results in the application at A successful procedure results in the application at
www.social.example.com receiving access token from www.social.example receiving access token from www.sipservice.example
www.sipservice.example.com with Alice's authorization. with Alice's authorization.
Requirements: Requirements:
o The server at www.social.example.com must be able to redirect o The server at www.social.example must be able to redirect Alice's
Alice's browser to www.sipservice.example.com browser to www.sipservice.example
o The application running at www.sipservice.example.com must be o The application running at www.sipservice.example must be capable
capable of authenticating Alice and obtaining her authorization of of authenticating Alice and obtaining her authorization of a
a request from www.social.example.com request from www.social.example
o The server at www.sipservice.example.com must be able to redirect o The server at www.sipservice.example must be able to redirect
Alice's browser back to www.social.example.com Alice's browser back to www.social.example
o The application at www.social.example.com must be able to o The application at www.social.example must be able to translate
translate the messages of the Alice's VoIP applet into SIP and RTP the messages of the Alice's VoIP applet into SIP and RTP messages
messages
o The application at www.social.example.com must be able to add the o The application at www.social.example must be able to add the
access token to the SIP requests that it sends to access token to the SIP requests that it sends to
www.sipservice.example.com www.sipservice.example
o Application at www.sipservice.example.com must be able to o Application at www.sipservice.example must be able to authenticate
authenticate the application at www.social.example.com and the application at www.social.example and validate the access
validate the access token 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 is not in the
the OAuth scope) OAuth scope)
Note: OAuth 2.0 does not support this use case Note: OAuth 2.0 does not support this use case
2.11. Signed Messages 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, 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, recommends her to see a sleep specialist
(www.sleepwell.example.com). Alice arrives at the sleep specialist's (www.sleepwell.example). 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
web site. The application at www.pcp.example.com verifies that Alice web site. The application at www.pcp.example verifies that Alice has
has authorized www.sleepwell.example.com to access her health data as authorized www.sleepwell.example to access her health data as well as
well as enforces that www.sleepwell.example.com is the only enforces that www.sleepwell.example is the only application that can
application that can retrieve that data with that specific retrieve that data with that specific authorization.
authorization.
Pre-conditions: Pre-conditions:
o Alice has a personal health data store that allows for discovery o Alice has a personal health data store that allows for discovery
of her participating health systems (e.g. psychiatrist, sleep of her participating health systems (e.g. psychiatrist, sleep
specialist, PCP, orthodontist, ophthalmologist, etc) specialist, PCP, orthodontist, ophthalmologist, etc)
o The application at www.myhealth.example.com manages authorization o The application at www.myhealth.example manages authorization of
of access to Alice's participating health systems access to Alice's participating health systems
o The application at www.myhealth.example.com can issue o The application at www.myhealth.example can issue authorization
authorization tokens understood by Alice's participating health tokens understood by Alice's participating health systems
systems
o The application at www.pcp.example.com stores Alice's basic health o The application at www.pcp.example stores Alice's basic health and
and prescription records prescription records
o The application at www.sleepwell.com stores results of Alice's o The application at www.sleepwell.com stores results of Alice's
sleep tests sleep tests
Post-conditions: Post-conditions:
o A successful procedure results in just the information that Alice o A successful procedure results in just the information that Alice
authorized being transferred from the Primary Care Physician authorized being transferred from the Primary Care Physician
(www.pcp.example.com) to the sleep specialist (www.pcp.example) to the sleep specialist (www.sleepwell.example)
(www.sleepwell.example.com)
o The transfer of health data only occurs if the application at o The transfer of health data only occurs if the application at
www.pcp.example.com can verify that www.sleepwell.example.com is www.pcp.example can verify that www.sleepwell.example is the party
the party requesting access and that the authorization token requesting access and that the authorization token presented by
presented by www.sleepwell.example.com is issued by the www.sleepwell.example is issued by the application at
application at www.myhealth.example.com with a restricted audience www.myhealth.example with a restricted audience of
of www.sleepwell.example.com www.sleepwell.example
Requirements: Requirements:
o The application at www.sleepwell.example.com interacting with o The application at www.sleepwell.example interacting with
www.myhealth.example.com must be able to discover the location of www.myhealth.example must be able to discover the location of the
the PCP system (e.g., XRD discovery) PCP system (e.g., XRD discovery)
o The application at www.sleepwell.example.com must be capable of o The application at www.sleepwell.example must be capable of
requesting Alice's authorization of access to the application at requesting Alice's authorization of access to the application at
www.pcp.example.com for the purpose of retrieving basic health www.pcp.example for the purpose of retrieving basic health data
data (e.g. date-of-birth, weight, height, etc). The mechanism (e.g. date-of-birth, weight, height, etc). The mechanism Alice
Alice uses to authorize this access is out of scope for this use uses to authorize this access is out of scope for this use case
case
o The application at www.myhealth.example.com must be capable of o The application at www.myhealth.example must be capable of issuing
issuing a token bound to www.sleepwell.example.com for access to a token bound to www.sleepwell.example for access to the
the application at www.pcp.example.com. Note that a signed token application at www.pcp.example. Note that a signed token (JWT)
(JWT) can be used to prove who issued the token can be used to prove who issued the token
o The application at www.sleepwell.example.com must be capable of o The application at www.sleepwell.example must be capable of
issuing a request (which includes the token issued by issuing a request (which includes the token issued by
www.myhealth.example.com) to the application at www.myhealth.example) to the application at www.pcp.example
www.pcp.example.com
o The application at www.sleepwell.example.com must sign the request o The application at www.sleepwell.example must sign the request
before sending it to www.pcp.example.com before sending it to www.pcp.example
o The application at www.pcp.example.com must be capable of o The application at www.pcp.example must be capable of receiving
receiving the request and verifying the signature the request and verifying the signature
o The application at www.pcp.example.com must be capable of parsing o The application at www.pcp.example must be capable of parsing the
the message and finding the authorization token message and finding the authorization token
o The application at www.pcp.example.com must be capable of o The application at www.pcp.example must be capable of verifying
verifying the signature of the authorization token 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 must be capable of parsing the
the authorization token and verifying that this token was issued authorization token and verifying that this token was issued to
to the application at www.sleepwell.com 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 must be capable of retrieving
retrieving the requested data and returning it to the application the requested data and returning it to the application at
at www.sleepwell.example.com www.sleepwell.example
Note: OAuth 2.0 does not support this use case Note: OAuth 2.0 does not support this use case
2.12. Signature with asymmetric secret 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 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. The application
application at www.printphotos.example.com, which does not have a at www.printphotos.example, which does not have a shared secret with
shared secret with www.storephotos.example.com, receives Alice's www.storephotos.example, receives Alice's authorization for accessing
authorization for accessing her photographs without learning her her photographs without learning her authentication credentials with
authentication credentials with www.storephotos.example.com. www.storephotos.example.
Pre-conditions: Pre-conditions:
o Alice has registered with www.storephotos.example.com to enable o Alice has registered with www.storephotos.example to enable
authentication authentication
o The application at www.printphotos.example.com has a private and a o The application at www.printphotos.example has a private and a
matching public keys matching public keys
Post-conditions: Post-conditions:
A successful procedure results in the application at A successful procedure results in the application at
www.printphotos.example.com receiving an access token from www.printphotos.example receiving an access token from
www.storephotos.example.com for accessing the Alice's photographs. www.storephotos.example for accessing the Alice's photographs.
Requirements: Requirements:
o The application at www.printphotos.example.com must be capable of o The application at www.printphotos.example must be capable of
issuing the HTTP redirect requests to Alice's user agent - a issuing the HTTP redirect requests to Alice's user agent - a
browser browser
o The application at www.storephotos.example.com must be able to o The application at www.storephotos.example must be able to
authenticate Alice authenticate Alice
o The application running at www.storephotos.example.com must be o The application running at www.storephotos.example must be able to
able to obtain the public key of the application at obtain the public key of the application at
www.printphotos.example.com www.printphotos.example
o The application running at www.printphotos.example.com is required o The application running at www.printphotos.example is required to
to sign using its private key the requests to the application at sign using its private key the requests to the application at
www.storephotos.example.com www.storephotos.example
o The application at www.storephotos.example.com must obtain Alice's o The application at www.storephotos.example must obtain Alice's
authorization of the access to her photos by authorization of the access to her photos by
www.printphotos.example.com www.printphotos.example
o The application at www.storephotos.example.com is required to o The application at www.storephotos.example is required to identify
identify to Alice the scope of access that to Alice the scope of access that www.printphotos.example has
www.printphotos.example.com has requested while asking for Alice's requested while asking for Alice's authorization
authorization
o The application at www.storephotos.example.com must be able to o The application at www.storephotos.example must be able to
authenticate the application at www.printphotos.example.com by authenticate the application at www.printphotos.example by
validating a signature of its request using the public key of validating a signature of its request using the public key of
www.printphotos.example.com www.printphotos.example
o The application at www.printphotos.example.com must provide a o The application at www.printphotos.example must provide a callback
callback URL to the application at www.storephotos.example.com URL to the application at www.storephotos.example (note: the URL
(note: the URL can be pre-registered with can be pre-registered with www.storephotos.example)
www.storephotos.example.com)
o The application at www.storephotos.example.com must be capable of o The application at www.storephotos.example 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 is not in the
the OAuth scope) OAuth scope)
Note: OAuth 2.0 does not support this use case 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
 End of changes. 165 change blocks. 
350 lines changed or deleted 334 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/