draft-ietf-kitten-sasl-oauth-20.txt   draft-ietf-kitten-sasl-oauth-21.txt 
KITTEN W. Mills KITTEN W. Mills
Internet-Draft Microsoft Internet-Draft Microsoft
Intended status: Standards Track T. Showalter Intended status: Standards Track T. Showalter
Expires: October 18, 2015 Expires: October 19, 2015
H. Tschofenig H. Tschofenig
ARM Ltd. ARM Ltd.
April 16, 2015 April 17, 2015
A set of SASL Mechanisms for OAuth A set of SASL Mechanisms for OAuth
draft-ietf-kitten-sasl-oauth-20.txt draft-ietf-kitten-sasl-oauth-21.txt
Abstract Abstract
OAuth enables a third-party application to obtain limited access to a OAuth enables a third-party application to obtain limited access to a
protected resource, either on behalf of a resource owner by protected resource, either on behalf of a resource owner by
orchestrating an approval interaction, or by allowing the third-party orchestrating an approval interaction, or by allowing the third-party
application to obtain access on its own behalf. application to obtain access on its own behalf.
This document defines how an application client uses credentials This document defines how an application client uses credentials
obtained via OAuth over the Simple Authentication and Security Layer obtained via OAuth over the Simple Authentication and Security Layer
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 October 18, 2015. This Internet-Draft will expire on October 19, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 42 skipping to change at page 2, line 42
3.3. OAuth Access Token Types using Keyed Message Digests . . 10 3.3. OAuth Access Token Types using Keyed Message Digests . . 10
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Successful Bearer Token Exchange . . . . . . . . . . . . 12 4.1. Successful Bearer Token Exchange . . . . . . . . . . . . 12
4.2. Successful OAuth 1.0a Token Exchange . . . . . . . . . . 13 4.2. Successful OAuth 1.0a Token Exchange . . . . . . . . . . 13
4.3. Failed Exchange . . . . . . . . . . . . . . . . . . . . . 13 4.3. Failed Exchange . . . . . . . . . . . . . . . . . . . . . 13
4.4. SMTP Example of a Failed Negotiation . . . . . . . . . . 14 4.4. SMTP Example of a Failed Negotiation . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. Internationalization Considerations . . . . . . . . . . . . . 16 6. Internationalization Considerations . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7.1. SASL Registration . . . . . . . . . . . . . . . . . . . . 17 7.1. SASL Registration . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . 17 8.1. Normative References . . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . 18 8.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. Acknowlegements . . . . . . . . . . . . . . . . . . 19 Appendix A. Acknowlegements . . . . . . . . . . . . . . . . . . 19
Appendix B. Document History . . . . . . . . . . . . . . . . . . 19 Appendix B. Document History . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
OAuth 1.0a [RFC5849] and OAuth 2.0 [RFC6749] are protocol frameworks OAuth 1.0a [RFC5849] and OAuth 2.0 [RFC6749] are protocol frameworks
that enable a third-party application to obtain limited access to a that enable a third-party application to obtain limited access to a
protected resource, either on behalf of a resource owner by protected resource, either on behalf of a resource owner by
orchestrating an approval interaction, or by allowing the third-party orchestrating an approval interaction, or by allowing the third-party
application to obtain access on its own behalf. application to obtain access on its own behalf.
skipping to change at page 10, line 13 skipping to change at page 10, line 13
of parameters necessary for the OAuth protocol exchange to of parameters necessary for the OAuth protocol exchange to
function. Another comparable discovery or client registration function. Another comparable discovery or client registration
mechanism MAY be used if available. mechanism MAY be used if available.
The use of the 'offline_access' scope, as defined in The use of the 'offline_access' scope, as defined in
[OpenID.Core] is RECOMMENDED to give clients the capability to [OpenID.Core] is RECOMMENDED to give clients the capability to
explicitly request a refresh token. explicitly request a refresh token.
If the resource server provides a scope then the client MUST always If the resource server provides a scope then the client MUST always
request scoped tokens from the token endpoint. If the resource request scoped tokens from the token endpoint. If the resource
server does not return a scope the client SHOULD presume an empty server does not return a scope the client SHOULD presume an unscoped
scope (unscoped token) is required to access the resource. token is required to access the resource.
Since clients may interact with a number of application servers, such Since clients may interact with a number of application servers, such
as email servers and XMPP [RFC6120] servers, they need to have a way as email servers and XMPP [RFC6120] servers, they need to have a way
to determine whether dynamic client registration has been performed to determine whether dynamic client registration has been performed
already and whether an already available refresh token can be re-used already and whether an already available refresh token can be re-used
to obtain an access token for the desired resource server. This to obtain an access token for the desired resource server. This
specification RECOMMENDs that a client uses the information in the specification RECOMMENDs that a client uses the information in the
'iss' element defined in OpenID Connect Core [OpenID.Core] to make 'iss' element defined in OpenID Connect Core [OpenID.Core] to make
this determination. this determination.
skipping to change at page 17, line 17 skipping to change at page 17, line 17
At the time of writing the standardization of the various claims in At the time of writing the standardization of the various claims in
the access token (in JSON format) is still ongoing, see the access token (in JSON format) is still ongoing, see
[I-D.ietf-oauth-json-web-token]. Once completed it will provide a [I-D.ietf-oauth-json-web-token]. Once completed it will provide a
standardized format for exchanging identity information between the standardized format for exchanging identity information between the
authorization server and the resource server. authorization server and the resource server.
7. IANA Considerations 7. IANA Considerations
7.1. SASL Registration 7.1. SASL Registration
The IANA is requested to register the following SASL profile: The IANA is requested to register the following entry in the SASL
Mechanisms registry:
SASL mechanism profile: OAUTHBEARER SASL mechanism name: OAUTHBEARER
Security Considerations: See this document Security Considerations: See this document
Published Specification: See this document Published Specification: See this document
For further information: Contact the authors of this document. For further information: Contact the authors of this document.
Owner/Change controller: the IETF Intended usage: common
Owner/Change controller: the IESG
Note: None Note: None
The IANA is requested to register the following SASL profile: The IANA is requested to register the following entry in the SASL
Mechanisms registry:
SASL mechanism profile: OAUTH10A SASL mechanism name: OAUTH10A
Security Considerations: See this document Security Considerations: See this document
Published Specification: See this document Published Specification: See this document
For further information: Contact the authors of this document. For further information: Contact the authors of this document.
Owner/Change controller: the IETF Intended usage: common
Owner/Change controller: the IESG
Note: None Note: None
8. References 8. References
8.1. Normative References 8.1. Normative References
[OpenID.Core] [OpenID.Core]
Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
C. Mortimore, "OpenID Connect Core 1.0", February 2014. C. Mortimore, "OpenID Connect Core 1.0", February 2014.
 End of changes. 13 change blocks. 
16 lines changed or deleted 22 lines changed or added

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