--- 1/draft-ietf-kitten-sasl-oauth-20.txt 2015-04-17 11:15:03.037315722 -0700 +++ 2/draft-ietf-kitten-sasl-oauth-21.txt 2015-04-17 11:15:03.085316886 -0700 @@ -1,21 +1,21 @@ KITTEN W. Mills Internet-Draft Microsoft Intended status: Standards Track T. Showalter -Expires: October 18, 2015 +Expires: October 19, 2015 H. Tschofenig ARM Ltd. - April 16, 2015 + April 17, 2015 A set of SASL Mechanisms for OAuth - draft-ietf-kitten-sasl-oauth-20.txt + draft-ietf-kitten-sasl-oauth-21.txt Abstract OAuth enables a third-party application to obtain limited access to a protected resource, either on behalf of a resource owner by orchestrating an approval interaction, or by allowing the third-party application to obtain access on its own behalf. This document defines how an application client uses credentials obtained via OAuth over the Simple Authentication and Security Layer @@ -38,21 +38,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -76,25 +76,25 @@ 3.3. OAuth Access Token Types using Keyed Message Digests . . 10 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Successful Bearer Token Exchange . . . . . . . . . . . . 12 4.2. Successful OAuth 1.0a Token Exchange . . . . . . . . . . 13 4.3. Failed Exchange . . . . . . . . . . . . . . . . . . . . . 13 4.4. SMTP Example of a Failed Negotiation . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6. Internationalization Considerations . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 7.1. SASL Registration . . . . . . . . . . . . . . . . . . . . 17 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 - 8.2. Informative References . . . . . . . . . . . . . . . . . 18 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 18 + 8.2. Informative References . . . . . . . . . . . . . . . . . 19 Appendix A. Acknowlegements . . . . . . . . . . . . . . . . . . 19 - Appendix B. Document History . . . . . . . . . . . . . . . . . . 19 + Appendix B. Document History . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction OAuth 1.0a [RFC5849] and OAuth 2.0 [RFC6749] are protocol frameworks that enable a third-party application to obtain limited access to a protected resource, either on behalf of a resource owner by orchestrating an approval interaction, or by allowing the third-party application to obtain access on its own behalf. @@ -402,22 +402,22 @@ of parameters necessary for the OAuth protocol exchange to function. Another comparable discovery or client registration mechanism MAY be used if available. The use of the 'offline_access' scope, as defined in [OpenID.Core] is RECOMMENDED to give clients the capability to explicitly request a refresh token. If the resource server provides a scope then the client MUST always request scoped tokens from the token endpoint. If the resource - server does not return a scope the client SHOULD presume an empty - scope (unscoped token) is required to access the resource. + server does not return a scope the client SHOULD presume an unscoped + token is required to access the resource. Since clients may interact with a number of application servers, such as email servers and XMPP [RFC6120] servers, they need to have a way to determine whether dynamic client registration has been performed already and whether an already available refresh token can be re-used to obtain an access token for the desired resource server. This specification RECOMMENDs that a client uses the information in the 'iss' element defined in OpenID Connect Core [OpenID.Core] to make this determination. @@ -736,45 +736,51 @@ At the time of writing the standardization of the various claims in the access token (in JSON format) is still ongoing, see [I-D.ietf-oauth-json-web-token]. Once completed it will provide a standardized format for exchanging identity information between the authorization server and the resource server. 7. IANA Considerations 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 Published Specification: See 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 - 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 Published Specification: See 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 8. References 8.1. Normative References [OpenID.Core] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, "OpenID Connect Core 1.0", February 2014.