draft-ietf-oauth-web-delegation-00.txt   draft-ietf-oauth-web-delegation-01.txt 
Network Working Group E. Hammer-Lahav, Ed. Network Working Group E. Hammer-Lahav, Ed.
Internet-Draft Yahoo! Internet-Draft Yahoo!
Intended status: Standards Track July 6, 2009 Intended status: Standards Track July 6, 2009
Expires: January 7, 2010 Expires: January 7, 2010
The OAuth Protocol: Web Delegation The OAuth Protocol: Web Delegation
draft-ietf-oauth-web-delegation-00 draft-ietf-oauth-web-delegation-01
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 15 skipping to change at page 2, line 15
authorize access to clients by substituting their credentials authorize access to clients by substituting their credentials
(typically, a username and password pair) with a different set of (typically, a username and password pair) with a different set of
delegation-specific credentials. delegation-specific credentials.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 4 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 4
3. Redirection-Based Authorization . . . . . . . . . . . . . . . 4 3. Redirection-Based Authorization . . . . . . . . . . . . . . . 4
3.1. Temporary Credentials . . . . . . . . . . . . . . . . . . 5 4. Temporary Credentials . . . . . . . . . . . . . . . . . . . . 5
3.2. Resource Owner Authorization . . . . . . . . . . . . . . . 6 5. Resource Owner Authorization . . . . . . . . . . . . . . . . . 6
3.3. Token Credentials . . . . . . . . . . . . . . . . . . . . 8 6. Token Credentials . . . . . . . . . . . . . . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5.1. Credentials Transmission . . . . . . . . . . . . . . . . . 9 8.1. Credentials Transmission . . . . . . . . . . . . . . . . . 9
5.2. Phishing Attacks . . . . . . . . . . . . . . . . . . . . . 9 8.2. Phishing Attacks . . . . . . . . . . . . . . . . . . . . . 9
5.3. Scoping of Access Requests . . . . . . . . . . . . . . . . 10 8.3. Scoping of Access Requests . . . . . . . . . . . . . . . . 10
5.4. Entropy of Secrets . . . . . . . . . . . . . . . . . . . . 10 8.4. Entropy of Secrets . . . . . . . . . . . . . . . . . . . . 10
5.5. Denial of Service / Resource Exhaustion Attacks . . . . . 10 8.5. Denial of Service / Resource Exhaustion Attacks . . . . . 10
5.6. Cross-Site Request Forgery (CSRF) . . . . . . . . . . . . 11 8.6. Cross-Site Request Forgery (CSRF) . . . . . . . . . . . . 11
5.7. User Interface Redress . . . . . . . . . . . . . . . . . . 11 8.7. User Interface Redress . . . . . . . . . . . . . . . . . . 11
5.8. Automatic Processing of Repeat Authorizations . . . . . . 12 8.8. Automatic Processing of Repeat Authorizations . . . . . . 12
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . 12 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . 12
Appendix A.1. Obtaining Temporary Credentials . . . . . . . . . 13 Appendix A.1. Obtaining Temporary Credentials . . . . . . . . . 13
Appendix A.2. Requesting Resource Owner Authorization . . . . . 14 Appendix A.2. Requesting Resource Owner Authorization . . . . . 14
Appendix A.3. Obtaining Token Credentials . . . . . . . . . . . 14 Appendix A.3. Obtaining Token Credentials . . . . . . . . . . . 14
Appendix A.4. Accessing protected resources . . . . . . . . . . 14 Appendix A.4. Accessing protected resources . . . . . . . . . . 14
Appendix A.4.1. Generating Signature Base String . . . . . . . . . 14 Appendix A.4.1. Generating Signature Base String . . . . . . . . . 14
Appendix A.4.2. Calculating Signature Value . . . . . . . . . . . 16 Appendix A.4.2. Calculating Signature Value . . . . . . . . . . . 16
Appendix A.4.3. Requesting protected resource . . . . . . . . . . 16 Appendix A.4.3. Requesting protected resource . . . . . . . . . . 16
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . 16 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . 16
Appendix C. Document History . . . . . . . . . . . . . . . . . 16 Appendix C. Document History . . . . . . . . . . . . . . . . . 16
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. Normative References . . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
6.2. Informative References . . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
The OAuth protocol provides a method for servers to allow third-party The OAuth protocol provides a method for servers to allow third-party
access to protected resources, without forcing their end users to access to protected resources, without forcing their end users to
share their credentials. This pattern is common among services that share their credentials. This pattern is common among services that
allow third-party developers to extend the service functionality, by allow third-party developers to extend the service functionality, by
building applications using an open API. building applications using an open API.
skipping to change at page 5, line 23 skipping to change at page 5, line 23
owners to revoke token credentials after they have been issued to owners to revoke token credentials after they have been issued to
clients. clients.
In order for the client to perform these steps, the server needs to In order for the client to perform these steps, the server needs to
advertise the URIs of these three endpoints, as well as the HTTP advertise the URIs of these three endpoints, as well as the HTTP
method (GET, POST, etc.) used to make each requests. To assist in method (GET, POST, etc.) used to make each requests. To assist in
communicating these endpoint, each is given a name: communicating these endpoint, each is given a name:
Temporary Credential Request Temporary Credential Request
The endpoint used by the client to obtain temporary credentials The endpoint used by the client to obtain temporary credentials
as described in Section 3.1. as described in Section 4.
Resource Owner Authorization Resource Owner Authorization
The endpoint to which the resource owner is redirected to grant The endpoint to which the resource owner is redirected to grant
authorization as described in Section 3.2. authorization as described in Section 5.
Token Request Token Request
The endpoint used by the client to request a set of token The endpoint used by the client to request a set of token
credentials using the temporary credentials as described in credentials using the temporary credentials as described in
Section 3.3. Section 6.
The three URIs MAY include a query component as defined by [RFC3986] The three URIs MAY include a query component as defined by [RFC3986]
section 3, but if present, the query MUST NOT contain any parameters section 3, but if present, the query MUST NOT contain any parameters
beginning with the "oauth_" prefix. beginning with the "oauth_" prefix.
The method in which the server advertises its three endpoint is The method in which the server advertises its three endpoint is
beyond the scope of this specification. beyond the scope of this specification.
3.1. Temporary Credentials 4. Temporary Credentials
The client obtains a set of temporary credentials from the server by The client obtains a set of temporary credentials from the server by
making an authenticated request per making an authenticated request per
[draft-ietf-oauth-authentication]. The client MUST use the HTTP [draft-ietf-oauth-authentication]. The client MUST use the HTTP
method advertised by the server. The HTTP POST method is method advertised by the server. The HTTP POST method is
RECOMMENDED. The client constructs a request URI by adding the RECOMMENDED. The client constructs a request URI by adding the
following parameter to the Temporary Credential Request endpoint URI: following parameter to the Temporary Credential Request endpoint URI:
oauth_callback: An absolute URL to which the server will redirect oauth_callback: An absolute URL to which the server will redirect
the resource owner back when the Resource Owner Authorization the resource owner back when the Resource Owner Authorization
step (Section 3.2) is completed. If the client is unable to step (Section 5) is completed. If the client is unable to
receive callbacks or a callback URI has been established via receive callbacks or a callback URI has been established via
other means, the parameter value MUST be set to "oob" (case other means, the parameter value MUST be set to "oob" (case
sensitive), to indicate an out-of-band configuration. sensitive), to indicate an out-of-band configuration.
Servers MAY specify additional parameters. Servers MAY specify additional parameters.
When making the request, the client authenticates using only the When making the request, the client authenticates using only the
client credentials. The client MUST omit the "oauth_token" protocol client credentials. The client MUST omit the "oauth_token" protocol
parameter from the request and use an empty string as the token parameter from the request and use an empty string as the token
secret value. secret value.
skipping to change at page 6, line 47 skipping to change at page 6, line 47
Note that even though the parameter names include the term 'token', Note that even though the parameter names include the term 'token',
these credentials are not token credentials, but are used in the next these credentials are not token credentials, but are used in the next
two steps in a similar manner to token credentials. two steps in a similar manner to token credentials.
For example (line breaks are for display purposes only): For example (line breaks are for display purposes only):
oauth_token=ab3cd9j4ks73hf7g&oauth_token_secret=xyz4992k83j47x0b& oauth_token=ab3cd9j4ks73hf7g&oauth_token_secret=xyz4992k83j47x0b&
oauth_callback_confirmed=true oauth_callback_confirmed=true
3.2. Resource Owner Authorization 5. Resource Owner Authorization
Before the client requests a set of token credentials from the Before the client requests a set of token credentials from the
server, it MUST send the user to the server to authorize the request. server, it MUST send the user to the server to authorize the request.
The client constructs a request URI by adding the following The client constructs a request URI by adding the following
parameters to the Resource Owner Authorization endpoint URI: parameters to the Resource Owner Authorization endpoint URI:
oauth_token oauth_token
REQUIRED. The temporary credentials identifier obtained in REQUIRED. The temporary credentials identifier obtained in
Section 3.1 in the "oauth_token" parameter. Servers MAY Section 4 in the "oauth_token" parameter. Servers MAY declare
declare this parameter as OPTIONAL, in which case they MUST this parameter as OPTIONAL, in which case they MUST provide a
provide a way for the resource owner to indicate the identifier way for the resource owner to indicate the identifier through
through other means. other means.
Servers MAY specify additional parameters. Servers MAY specify additional parameters.
The client redirects the resource owner to the constructed URI using The client redirects the resource owner to the constructed URI using
an HTTP redirection response, or by other means available to it via an HTTP redirection response, or by other means available to it via
the resource owner's user agent. The request MUST use the HTTP GET the resource owner's user agent. The request MUST use the HTTP GET
method. method.
The way in which the server handles the authorization request is The way in which the server handles the authorization request is
beyond the scope of this specification. However, the server MUST beyond the scope of this specification. However, the server MUST
skipping to change at page 8, line 16 skipping to change at page 8, line 16
http://client.example.net/cb?state=1&oauth_token=ab3cd9j4ks73hf7g& http://client.example.net/cb?state=1&oauth_token=ab3cd9j4ks73hf7g&
oauth_verifier=473829k9302sa oauth_verifier=473829k9302sa
If the client did not provide a callback URI, the server SHOULD If the client did not provide a callback URI, the server SHOULD
display the value of the verification code, and instruct the resource display the value of the verification code, and instruct the resource
owner to manually inform the client that authorization is completed. owner to manually inform the client that authorization is completed.
If the server knows a client to be running on a limited device it If the server knows a client to be running on a limited device it
SHOULD ensure that the verifier value is suitable for manual entry. SHOULD ensure that the verifier value is suitable for manual entry.
3.3. Token Credentials 6. Token Credentials
The client obtains a set of token credentials from the server by The client obtains a set of token credentials from the server by
making an authenticated request per making an authenticated request per
[draft-ietf-oauth-authentication]. The client MUST use the HTTP [draft-ietf-oauth-authentication]. The client MUST use the HTTP
method advertised by the server. The HTTP POST method is method advertised by the server. The HTTP POST method is
RECOMMENDED. The client constructs a request URI by adding the RECOMMENDED. The client constructs a request URI by adding the
following parameter to the Token Request endpoint URI: following parameter to the Token Request endpoint URI:
oauth_verifier: The verification code received from the server in oauth_verifier: The verification code received from the server in
the previous step. the previous step.
skipping to change at page 9, line 17 skipping to change at page 9, line 17
oauth_token=j49ddk933skd9dks&oauth_token_secret=ll399dj47dskfjdk oauth_token=j49ddk933skd9dks&oauth_token_secret=ll399dj47dskfjdk
The token credentials issued by the server MUST reflect the exact The token credentials issued by the server MUST reflect the exact
scope, duration, and other attributes approved by the resource owner. scope, duration, and other attributes approved by the resource owner.
Once the client receives the token credentials, it can proceed to Once the client receives the token credentials, it can proceed to
access protected resources on behalf of the resource owner by making access protected resources on behalf of the resource owner by making
an authenticated request per [draft-ietf-oauth-authentication] using an authenticated request per [draft-ietf-oauth-authentication] using
the client credentials and the token credentials received. the client credentials and the token credentials received.
4. IANA Considerations 7. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
5. Security Considerations 8. Security Considerations
As stated in [RFC2617], the greatest sources of risks are usually As stated in [RFC2617], the greatest sources of risks are usually
found not in the core protocol itself but in policies and procedures found not in the core protocol itself but in policies and procedures
surrounding its use. Implementers are strongly encouraged to assess surrounding its use. Implementers are strongly encouraged to assess
how this protocol addresses their security requirements. how this protocol addresses their security requirements.
5.1. Credentials Transmission 8.1. Credentials Transmission
The OAuth specification does not describe any mechanism for The OAuth specification does not describe any mechanism for
protecting tokens and shared-secrets from eavesdroppers when they are protecting tokens and shared-secrets from eavesdroppers when they are
transmitted from the server to the client during the authorization transmitted from the server to the client during the authorization
phase. Servers should ensure that these transmissions are protected phase. Servers should ensure that these transmissions are protected
using transport-layer mechanisms such as TLS or SSL. using transport-layer mechanisms such as TLS or SSL.
5.2. Phishing Attacks 8.2. Phishing Attacks
Wide deployment of OAuth and similar protocols may cause resource Wide deployment of OAuth and similar protocols may cause resource
owners to become inured to the practice of being redirected to owners to become inured to the practice of being redirected to
websites where they are asked to enter their passwords. If resource websites where they are asked to enter their passwords. If resource
owners are not careful to verify the authenticity of these websites owners are not careful to verify the authenticity of these websites
before entering their credentials, it will be possible for attackers before entering their credentials, it will be possible for attackers
to exploit this practice to steal resource owners' passwords. to exploit this practice to steal resource owners' passwords.
Servers should attempt to educate resource owners about the risks Servers should attempt to educate resource owners about the risks
phishing attacks pose, and should provide mechanisms that make it phishing attacks pose, and should provide mechanisms that make it
easy for resource owners to confirm the authenticity of their sites. easy for resource owners to confirm the authenticity of their sites.
5.3. Scoping of Access Requests 8.3. Scoping of Access Requests
By itself, OAuth does not provide any method for scoping the access By itself, OAuth does not provide any method for scoping the access
rights granted to a client. However, most applications do require rights granted to a client. However, most applications do require
greater granularity of access rights. For example, servers may wish greater granularity of access rights. For example, servers may wish
to make it possible to grant access to some protected resources but to make it possible to grant access to some protected resources but
not others, or to grant only limited access (such as read-only not others, or to grant only limited access (such as read-only
access) to those protected resources. access) to those protected resources.
When implementing OAuth, servers should consider the types of access When implementing OAuth, servers should consider the types of access
resource owners may wish to grant clients, and should provide resource owners may wish to grant clients, and should provide
mechanisms to do so. Servers should also take care to ensure that mechanisms to do so. Servers should also take care to ensure that
resource owners understand the access they are granting, as well as resource owners understand the access they are granting, as well as
any risks that may be involved. any risks that may be involved.
5.4. Entropy of Secrets 8.4. Entropy of Secrets
Unless a transport-layer security protocol is used, eavesdroppers Unless a transport-layer security protocol is used, eavesdroppers
will have full access to OAuth requests and signatures, and will thus will have full access to OAuth requests and signatures, and will thus
be able to mount offline brute-force attacks to recover the be able to mount offline brute-force attacks to recover the
credentials used. Servers should be careful to assign shared-secrets credentials used. Servers should be careful to assign shared-secrets
which are long enough, and random enough, to resist such attacks for which are long enough, and random enough, to resist such attacks for
at least the length of time that the shared-secrets are valid. at least the length of time that the shared-secrets are valid.
For example, if shared-secrets are valid for two weeks, servers For example, if shared-secrets are valid for two weeks, servers
should ensure that it is not possible to mount a brute force attack should ensure that it is not possible to mount a brute force attack
skipping to change at page 10, line 43 skipping to change at page 10, line 43
secrets reasonable. secrets reasonable.
It is equally important that the pseudo-random number generator It is equally important that the pseudo-random number generator
(PRNG) used to generate these secrets be of sufficiently high (PRNG) used to generate these secrets be of sufficiently high
quality. Many PRNG implementations generate number sequences that quality. Many PRNG implementations generate number sequences that
may appear to be random, but which nevertheless exhibit patterns or may appear to be random, but which nevertheless exhibit patterns or
other weaknesses which make cryptanalysis or brute force attacks other weaknesses which make cryptanalysis or brute force attacks
easier. Implementers should be careful to use cryptographically easier. Implementers should be careful to use cryptographically
secure PRNGs to avoid these problems. secure PRNGs to avoid these problems.
5.5. Denial of Service / Resource Exhaustion Attacks 8.5. Denial of Service / Resource Exhaustion Attacks
The OAuth protocol has a number of features which may make resource The OAuth protocol has a number of features which may make resource
exhaustion attacks against servers possible. For example, if a exhaustion attacks against servers possible. For example, if a
server includes a nontrivial amount of entropy in token shared- server includes a nontrivial amount of entropy in token shared-
secrets as recommended above, then an attacker may be able to exhaust secrets as recommended above, then an attacker may be able to exhaust
the server's entropy pool very quickly by repeatedly obtaining the server's entropy pool very quickly by repeatedly obtaining
temporary credentials from the server. temporary credentials from the server.
Similarly, OAuth requires servers to track used nonces. If an Similarly, OAuth requires servers to track used nonces. If an
attacker is able to use many nonces quickly, the resources required attacker is able to use many nonces quickly, the resources required
skipping to change at page 11, line 21 skipping to change at page 11, line 21
Resource Exhaustion attacks are by no means specific to OAuth. Resource Exhaustion attacks are by no means specific to OAuth.
However, OAuth implementers should be careful to consider the However, OAuth implementers should be careful to consider the
additional avenues of attack that OAuth exposes, and design their additional avenues of attack that OAuth exposes, and design their
implementations accordingly. For example, entropy starvation implementations accordingly. For example, entropy starvation
typically results in either a complete denial of service while the typically results in either a complete denial of service while the
system waits for new entropy or else in weak (easily guessable) system waits for new entropy or else in weak (easily guessable)
secrets. When implementing OAuth, servers should consider which of secrets. When implementing OAuth, servers should consider which of
these presents a more serious risk for their application and design these presents a more serious risk for their application and design
accordingly. accordingly.
5.6. Cross-Site Request Forgery (CSRF) 8.6. Cross-Site Request Forgery (CSRF)
Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP
requests are transmitted from a user that the website trusts or has requests are transmitted from a user that the website trusts or has
authenticated. CSRF attacks on OAuth approvals can allow an attacker authenticated. CSRF attacks on OAuth approvals can allow an attacker
to obtain authorization to protected resources without the consent of to obtain authorization to protected resources without the consent of
the User. Servers SHOULD strongly consider best practices in CSRF the User. Servers SHOULD strongly consider best practices in CSRF
prevention at all OAuth endpoints. prevention at all OAuth endpoints.
CSRF attacks on OAuth callback URIs hosted by client are also CSRF attacks on OAuth callback URIs hosted by client are also
possible. Clients should prevent CSRF attacks on OAuth callback URIs possible. Clients should prevent CSRF attacks on OAuth callback URIs
by verifying that the resource owner at the client site intended to by verifying that the resource owner at the client site intended to
complete the OAuth negotiation with the server. complete the OAuth negotiation with the server.
5.7. User Interface Redress 8.7. User Interface Redress
Servers should protect the authorization process against UI Redress Servers should protect the authorization process against UI Redress
attacks (also known as "clickjacking"). As of the time of this attacks (also known as "clickjacking"). As of the time of this
writing, no complete defenses against UI redress are available. writing, no complete defenses against UI redress are available.
Servers can mitigate the risk of UI redress attacks through the Servers can mitigate the risk of UI redress attacks through the
following techniques: following techniques:
o Javascript frame busting. o Javascript frame busting.
o Javascript frame busting, and requiring that browsers have o Javascript frame busting, and requiring that browsers have
javascript enabled on the authorization page. javascript enabled on the authorization page.
o Browser-specific anti-framing techniques. o Browser-specific anti-framing techniques.
o Requiring password reentry before issuing OAuth tokens. o Requiring password reentry before issuing OAuth tokens.
5.8. Automatic Processing of Repeat Authorizations 8.8. Automatic Processing of Repeat Authorizations
Servers may wish to automatically process authorization requests Servers may wish to automatically process authorization requests
(Section 3.2) from clients which have been previously authorized by (Section 5) from clients which have been previously authorized by the
the resource owner. When the resource owner is redirected to the resource owner. When the resource owner is redirected to the server
server to grant access, the server detects that the resource owner to grant access, the server detects that the resource owner has
has already granted access to that particular client. Instead of already granted access to that particular client. Instead of
prompting the resource owner for approval, the server automatically prompting the resource owner for approval, the server automatically
redirects the resource owner back to the client. redirects the resource owner back to the client.
If the client credentials are compromised, automatic processing If the client credentials are compromised, automatic processing
creates additional security risks. An attacker can use the stolen creates additional security risks. An attacker can use the stolen
client credentials to redirect the resource owner to the server with client credentials to redirect the resource owner to the server with
an authorization request. The server will then grant access to the an authorization request. The server will then grant access to the
resource owner's data without the resource owner's explicit approval, resource owner's data without the resource owner's explicit approval,
or even awareness of an attack. If no automatic approval is or even awareness of an attack. If no automatic approval is
implemented, an attacker must use social engineering to convince the implemented, an attacker must use social engineering to convince the
skipping to change at page 16, line 48 skipping to change at page 16, line 48
Mark Atwood, Dirk Balfanz, Darren Bounds, Richard M. Conlan, Blaine Mark Atwood, Dirk Balfanz, Darren Bounds, Richard M. Conlan, Blaine
Cook, Leah Culver, Breno de Medeiros, Brian Eaton, Kellan Elliott- Cook, Leah Culver, Breno de Medeiros, Brian Eaton, Kellan Elliott-
McCrea, Larry Halff, Eran Hammer-Lahav, Ben Laurie, Chris Messina, McCrea, Larry Halff, Eran Hammer-Lahav, Ben Laurie, Chris Messina,
John Panzer, Sam Quigley, David Recordon, Eran Sandler, Jonathan John Panzer, Sam Quigley, David Recordon, Eran Sandler, Jonathan
Sergent, Todd Sieling, Brian Slesinsky, and Andy Smith. Sergent, Todd Sieling, Brian Slesinsky, and Andy Smith.
Appendix C. Document History Appendix C. Document History
[[ To be removed by the RFC editor before publication as an RFC. ]] [[ To be removed by the RFC editor before publication as an RFC. ]]
-01
o Moved all subsection from section 3 to the document root.
-00 -00
o Transitioned from the individual submission draft-hammer-oauth-02 o Transitioned from the individual submission draft-hammer-oauth-02
to working group draft. to working group draft.
o Split draft-hammer-oauth-02 into two drafts, one dealing with web o Split draft-hammer-oauth-02 into two drafts, one dealing with web
delegation (this draft) and another dealing with authentication delegation (this draft) and another dealing with authentication
draft-ietf-oauth-web-authentication. draft-ietf-oauth-web-authentication.
o Updated draft with changes from OAuth Core 1.0 Revision A to fix a o Updated draft with changes from OAuth Core 1.0 Revision A to fix a
session fixation exploit. session fixation exploit.
skipping to change at page 17, line 14 skipping to change at page 17, line 18
o Transitioned from the individual submission draft-hammer-oauth-02 o Transitioned from the individual submission draft-hammer-oauth-02
to working group draft. to working group draft.
o Split draft-hammer-oauth-02 into two drafts, one dealing with web o Split draft-hammer-oauth-02 into two drafts, one dealing with web
delegation (this draft) and another dealing with authentication delegation (this draft) and another dealing with authentication
draft-ietf-oauth-web-authentication. draft-ietf-oauth-web-authentication.
o Updated draft with changes from OAuth Core 1.0 Revision A to fix a o Updated draft with changes from OAuth Core 1.0 Revision A to fix a
session fixation exploit. session fixation exploit.
6. References 9. References
6.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP Leach, P., Luotonen, A., and L. Stewart, "HTTP
skipping to change at page 17, line 44 skipping to change at page 18, line 5
[W3C.REC-html40-19980424] [W3C.REC-html40-19980424]
Hors, A., Jacobs, I., and D. Raggett, "HTML 4.0 Hors, A., Jacobs, I., and D. Raggett, "HTML 4.0
Specification", World Wide Web Consortium Specification", World Wide Web Consortium
Recommendation REC-html40-19980424, April 1998, Recommendation REC-html40-19980424, April 1998,
<http://www.w3.org/TR/1998/REC-html40-19980424>. <http://www.w3.org/TR/1998/REC-html40-19980424>.
[draft-ietf-oauth-authentication] [draft-ietf-oauth-authentication]
Hammer-Lahav, E., Ed., "The OAuth Protocol: Hammer-Lahav, E., Ed., "The OAuth Protocol:
Authentication". Authentication".
6.2. Informative References 9.2. Informative References
[OAuth Core 1.0 Revision A] [OAuth Core 1.0 Revision A]
OAuth, OCW., "OAuth Core 1.0". OAuth, OCW., "OAuth Core 1.0".
Author's Address Author's Address
Eran Hammer-Lahav (editor) Eran Hammer-Lahav (editor)
Yahoo! Yahoo!
Email: eran@hueniverse.com Email: eran@hueniverse.com
 End of changes. 27 change blocks. 
45 lines changed or deleted 49 lines changed or added

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