--- 1/draft-ietf-kitten-sasl-oauth-18.txt 2015-01-20 15:14:57.909466038 -0800 +++ 2/draft-ietf-kitten-sasl-oauth-19.txt 2015-01-20 15:14:57.953467086 -0800 @@ -1,21 +1,21 @@ KITTEN W. Mills Internet-Draft Microsoft Intended status: Standards Track T. Showalter -Expires: May 29, 2015 +Expires: July 24, 2015 H. Tschofenig ARM Ltd. - November 25, 2014 + January 20, 2015 A set of SASL Mechanisms for OAuth - draft-ietf-kitten-sasl-oauth-18.txt + draft-ietf-kitten-sasl-oauth-19.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,64 +38,64 @@ 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 May 29, 2015. + This Internet-Draft will expire on July 24, 2015. Copyright Notice - Copyright (c) 2014 IETF Trust and the persons identified as the + 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. OAuth SASL Mechanism Specifications . . . . . . . . . . . . . 6 3.1. Initial Client Response . . . . . . . . . . . . . . . . . 7 3.1.1. Reserved Key/Values . . . . . . . . . . . . . . . . . 8 3.2. Server's Response . . . . . . . . . . . . . . . . . . . . 8 - 3.2.1. OAuth Identifiers in the SASL Context . . . . . . . . 8 + 3.2.1. OAuth Identifiers in the SASL Context . . . . . . . . 9 3.2.2. Server Response to Failed Authentication . . . . . . 9 3.2.3. Completing an Error Message Sequence . . . . . . . . 10 3.3. OAuth Access Token Types using Keyed Message Digests . . 10 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 4.1. Successful Bearer Token Exchange . . . . . . . . . . . . 11 - 4.2. Successful OAuth 1.0a Token Exchange . . . . . . . . . . 12 + 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 + 4.4. SMTP Example of a Failed Negotiation . . . . . . . . . . 15 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 - 6. Internationalization Considerations . . . . . . . . . . . . . 16 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 - 7.1. SASL Registration . . . . . . . . . . . . . . . . . . . . 16 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 - 8.2. Informative References . . . . . . . . . . . . . . . . . 18 + 6. Internationalization Considerations . . . . . . . . . . . . . 17 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 + 7.1. SASL Registration . . . . . . . . . . . . . . . . . . . . 17 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 18 + 8.2. Informative References . . . . . . . . . . . . . . . . . 19 Appendix A. Acknowlegements . . . . . . . . . . . . . . . . . . 19 - Appendix B. Document History . . . . . . . . . . . . . . . . . . 19 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 + 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. The core OAuth 2.0 specification [RFC6749] specifies the interaction @@ -246,25 +246,25 @@ further definition. These mechanisms are client initiated and lock-step, the server always replying to a client message. In the case where the client has and correctly uses a valid token the flow is: 1. Client sends a valid and correct initial client response. 2. Server responds with a successful authentication. - In the case where authorization fails the server sends an error + In the case where authentication fails the server sends an error result, then client MUST then send an additional message to the server in order to allow the server to finish the exchange. Some protocols and common SASL implementations do not support both sending - a SASL message and finalizing a SASL negotiation, the additional + a SASL message and finalizing a SASL negotiation. The additional client message in the error case deals with this problem. This exchange is: 1. Client sends an invalid initial client response. 2. Server responds with an error message. 3. Client sends a dummy client response. 4. Server fails the authentication. @@ -274,31 +274,37 @@ Client responses are a GS2 [RFC5801] header followed by zero or more key/value pairs, or may be empty. The gs2-header is defined here for compatibility with GS2 if a GS2 mechanism is formally defined, but this document does not define one. These key/value pairs take the place of the corresponding HTTP headers and values to convey the information necessary to complete an OAuth style HTTP authorization. Unknown key/value pairs MUST be ignored by the server. The ABNF [RFC5234] syntax is: kvsep = %x01 - key = 1*(ALPHA / ",") + key = 1*(ALPHA) value = *(VCHAR / SP / HTAB / CR / LF ) kvpair = key "=" value kvsep ;;gs2-header = See RFC 5801 client_resp = (gs2-header kvsep 0*kvpair kvsep) / kvsep The GS2 header MAY include the user name associated with the resource being accessed, the "authzid". It is worth noting that application protocols are allowed to require an authzid, as are specific server implementations. + The client response consisting of only a single kvsep is used only + when authentication fails, and is only valid in that context. If + sent as the first message from the client the server MAY simply fail + the authentication without returning discovery information since + there is no user or server name indication. + The following keys and corresponding values are defined in the client response: auth (REQUIRED): The payload that would be in the HTTP Authorization header if this OAuth exchange was being carried out over HTTP. host: Contains the host name to which the client connected. In an HTTP context this is the value of the HTTP Host header. @@ -311,24 +317,24 @@ server MUST fail an authorization request requiring keyed message digests that are not accompanied by host and port values. In OAuth 1.0a for example, the so-called "signature base string calculation" includes the reconstructed HTTP URL. 3.1.1. Reserved Key/Values In these mechanisms values for path, query string and post body are assigned default values. OAuth authorization schemes MAY define usage of these in the SASL context and extend this specification. - For OAuth Access Token Types that use request keyed message digest - the default values MUST be used unless explicit values are provided - in the client response. The following key values are reserved for - future use: + For OAuth Access Token Types that include a keyed message digest of + the request the default values MUST be used unless explicit values + are provided in the client response. The following key values are + reserved for future use: mthd (RESERVED): HTTP method, the default value is "POST". path (RESERVED): HTTP path data, the default value is "/". post (RESERVED): HTTP post data, the default value is "". qs (RESERVED): The HTTP query string, the default value is "". 3.2. Server's Response @@ -338,22 +344,22 @@ utilizes a keyed message digest of the request parameters then the client must provide a client response that satisfies the data requirements for the scheme in use. The server responds to a successfully verified client message by completing the SASL negotiation. The authenticated identity reported by the SASL mechanism is the identity securely established for the client with the OAuth credential. The application, not the SASL mechanism, based on local access policy determines whether the identity reported by the mechanism is allowed access to the requested - resource. Note that the semantics of the authz-id is specified by - the SASL framework [RFC4422]. + resource. Note that the semantics of the authorization identity is + specified by the SASL framework [RFC4422]. 3.2.1. OAuth Identifiers in the SASL Context In the OAuth framework the client may be authenticated by the authorization server and the resource owner is authenticated to the authorization server. OAuth access tokens may contain information about the authentication of the resource owner and about the client and may therefore make this information accessible to the resource server. @@ -370,37 +376,38 @@ status (REQUIRED): The authorization error code. Valid error codes are defined in the IANA "OAuth Extensions Error Registry" specified in the OAuth 2 core specification. scope (OPTIONAL): An OAuth scope which is valid to access the service. This may be empty which implies that unscoped tokens are required, or a scope value. If a scope is specified then a single scope is preferred, use of a space separated list of scopes is NOT RECOMMENDED. - oauth-configuration (OPTIONAL): The URL for for a document - following the OpenID Provider Configuration Information schema - as described in OpenID Connect Discovery [OpenID.Discovery] - section 3 that is appropriate for the user. This document MUST - have all OAuth related data elements populated. The server MAY - return different URLs for users in different domains and the - client SHOULD NOT cache a single returned value and assume it - applies for all users/domains that the server suports. The - returned discovery document SHOULD have all data elements - required by the OpenID Connect Discovery specification - populated. In addition, the discovery document SHOULD contain - the 'registration_endpoint' element to learn about the endpoint - to be used with the Dynamic Client Registration protocol - [I-D.ietf-oauth-dyn-reg] to obtain the minimum number of - parameters necessary for the OAuth protocol exchange to - function. Another comparable discovery or client registration - mechanism MAY be used if available. + openid-configuration (OPTIONAL): The URL for a document following + the OpenID Provider Configuration Information schema as + described in OpenID Connect Discovery (OIDCD) + [OpenID.Discovery] section 3 that is appropriate for the user. + As specified in OIDCD this will have the "https" URL scheme. + This document MUST have all OAuth related data elements + populated. The server MAY return different URLs for users in + different domains and the client SHOULD NOT cache a single + returned value and assume it applies for all users/domains that + the server suports. The returned discovery document SHOULD + have all data elements required by the OpenID Connect Discovery + specification populated. In addition, the discovery document + SHOULD contain the 'registration_endpoint' element to learn + about the endpoint to be used with the Dynamic Client + Registration protocol [I-D.ietf-oauth-dyn-reg] to obtain the + minimum number 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 provides no scope to the client then the client SHOULD presume an empty scope (unscoped token) is required to access the resource. @@ -408,26 +415,28 @@ as email servers and XMPP 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. 3.2.3. Completing an Error Message Sequence - Section 3.6 of [RFC4422] explicitly prohibits additional information - in an unsuccessful authentication outcome. Therefore, the error - message is sent in a normal message. The client MUST then send an - additional client response consisting of a single %x01 (control A) - character to the server in order to allow the server to finish the - exchange. + Section 3.6 of SASL [RFC4422] explicitly prohibits additional + information in an unsuccessful authentication outcome. Therefore, + the error message is sent in a normal message. The client MUST then + send either an additional client response consisting of a single %x01 + (control A) character to the server in order to allow the server to + finish the exchange or send a SASL cancellation token as generally + defined in section 3.5 of SASL [RFC4422]. A specific example of a + cancellation token can be found in IMAP [RFC3501] section 6.2.2. 3.3. OAuth Access Token Types using Keyed Message Digests OAuth Access Token Types may use keyed message digests and the client and the resource server may need to perform a cryptographic computation for integrity protection and data origin authentication. OAuth is designed for access to resources identified by URIs. SASL is designed for user authentication, and has no facility for more fine-grained access control. In this specification we require or @@ -470,80 +479,89 @@ In this example the signature base string with line breaks added for readability would be: POST&http%3A%2F%2Fexample.com:143%2F&oauth_consumer_key%3D9djdj82h4 8djs9d2%26oauth_nonce%3D7d8f3e4a%26oauth_signature_method%3DHMAC-SH A1%26oauth_timestamp%3D137131201%26oauth_token%3Dkkk9d7dh3k39sjv7 4. Examples These examples illustrate exchanges between IMAP and SMTP clients and - servers. + servers. All IMAP examples use SASL-IR [RFC4959] and send payload in + the initial client response. The Bearer Token examples assume + encrypted transport, if the underlying connection is not already TLS + then STARTTLS MUST be used as TLS is required in the Bearer Token + specification. Note to implementers: The SASL OAuth method names are case insensitive. One example uses "Bearer" but that could as easily be "bearer", "BEARER", or "BeArEr". 4.1. Successful Bearer Token Exchange This example shows a successful OAuth 2.0 bearer token exchange in - IMAP. Note that line breaks are inserted for readability and the - underlying TLS establishment is not shown either. + IMAP. Note that line breaks are inserted for readability. The + underlying TLS establishment is not shown but is required for using + Bearer Tokens per that specification. S: * OK IMAP4rev1 Server Ready C: t0 CAPABILITY S: * CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER SASL-IR S: t0 OK Completed - C: t1 AUTHENTICATE OAUTHBEARER bixhPXVzZXJAZXhhbXBsZS5jb20sAWhvc3Q9c2 + C: t1 AUTH OAUTHBEARER bixhPXVzZXJAZXhhbXBsZS5jb20sAWhvc3Q9c2 VydmVyLmV4YW1wbGUuY29tAXBvcnQ9MTQzAWF1dGg9QmVhcmVyIHZGOWRmdDRxb VRjMk52YjNSbGNrQmhiSFJoZG1semRHRXVZMjl0Q2c9PQEB S: t1 OK SASL authentication succeeded As required by IMAP [RFC3501], the payloads are base64-encoded. The decoded initial client response (with %x01 represented as ^A and long lines wrapped for readability) is: n,a=user@example.com,^Ahost=server.example.com^Aport=143^A auth=Bearer vF9dft4qmTc2Nvb3RlckBhbHRhdmlzdGEuY29tCg==^A^A The same credential used in an SMTP exchange is shown below. Note that line breaks are inserted for readability, and that the SMTP protocol terminates lines with CR and LF characters (ASCII values 0x0D and 0x0A), these are not displayed explicitly in the example. + Again this example assumes that TLS is already established per the + Bearer Token specification requirements. [connection begins] S: 220 mx.example.com ESMTP 12sm2095603fks.9 C: EHLO sender.example.com S: 250-mx.example.com at your service,[172.31.135.47] S: 250-SIZE 35651584 S: 250-8BITMIME S: 250-AUTH LOGIN PLAIN OAUTHBEARER S: 250-ENHANCEDSTATUSCODES + S: 250-STARTTLS S: 250 PIPELINING - C: t1 AUTHENTICATE OAUTHBEARER bixhPXVzZXJAZXhhbXBsZS5jb20sAWhvc3Q9c + [Negotiate TLS...] + C: t1 AUTH OAUTHBEARER bixhPXVzZXJAZXhhbXBsZS5jb20sAWhvc3Q9c 2VydmVyLmV4YW1wbGUuY29tAXBvcnQ9MTQzAWF1dGg9QmVhcmVyIHZGOWRmdDR xbVRjMk52YjNSbGNrQmhiSFJoZG1semRHRXVZMjl0Q2c9PQEB S: 235 Authentication successful. [connection continues...] 4.2. Successful OAuth 1.0a Token Exchange This IMAP example shows a successful OAuth 1.0a token exchange. Note - that line breaks are inserted for readability and the underlying TLS - establishment is not shown. Signature computation is discussed in - Section 3.3. + that line breaks are inserted for readability. This example assumes + that TLS is already established. Signature computation is discussed + in Section 3.3. S: * OK IMAP4rev1 Server Ready C: t0 CAPABILITY S: * CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER OAUTH10A SASL-IR S: t0 OK Completed - C: t1 AUTHENTICATE OAUTH10A bixhPXVzZXJAZXhhbXBsZS5jb20sAWhvc3Q9ZXhhb + C: t1 AUTH OAUTH10A bixhPXVzZXJAZXhhbXBsZS5jb20sAWhvc3Q9ZXhhb XBsZS5jb20BcG9ydD0xNDMBYXV0aD1PQXV0aCByZWFsbT0iRXhhbXBsZSIsb2F1 dGhfY29uc3VtZXJfa2V5PSI5ZGpkajgyaDQ4ZGpzOWQyIixvYXV0aF90b2tlbj0 ia2trOWQ3ZGgzazM5c2p2NyIsb2F1dGhfc2lnbmF0dXJlX21ldGhvZD0iSE1BQy 1TSEExIixvYXV0aF90aW1lc3RhbXA9IjEzNzEzMTIwMSIsb2F1dGhfbm9uY2U9I jdkOGYzZTRhIixvYXV0aF9zaWduYXR1cmU9IlRtOTBJR0VnY21WaGJDQnphV2R1 WVhSMWNtVSUzRCIBAQ== S: t1 OK SASL authentication succeeded As required by IMAP [RFC3501], the payloads are base64-encoded. The decoded initial client response (with %x01 represented as ^A and @@ -561,31 +579,31 @@ oauth_signature="SSdtIGEgbGl0dGxlIHRlYSBwb3Qu"^A^A 4.3. Failed Exchange This IMAP example shows a failed exchange because of the empty Authorization header, which is how a client can query for the needed scope. Note that line breaks are inserted for readability. S: * OK IMAP4rev1 Server Ready C: t0 CAPABILITY - S: * CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER SASL-IR IMAP4rev1 Server - Ready + S: * CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER SASL-IR S: t0 OK Completed - C: t1 AUTHENTICATE OAUTHBEARER bixhPXVzZXJAZXhhbXBsZS5jb20sAW + C: t1 AUTH OAUTHBEARER bixhPXVzZXJAZXhhbXBsZS5jb20sAW hvc3Q9c2VydmVyLmV4YW1wbGUuY29tAXBvcnQ9MTQzAWF1dGg9AQE= S: + eyJzdGF0dXMiOiJpbnZhbGlkX3Rva2VuIiwic2NvcGUiOiJleGFtcGxl X3Njb3BlIiwib3BlbmlkLWNvbmZpZ3VyYXRpb24iOiJodHRwczovL2V4 YW1wbGUuY29tLy53ZWxsLWtub3duL29wZW5pZC1jb25maWd1cmF0aW9u In0= - C: + AQ== + C: AQ== S: t1 NO SASL authentication failed + The decoded initial client response is: n,a=user@example.com,^Ahost=server.example.com^A port=143^Aauth=^A^A The decoded server error response is: { "status":"invalid_token", "scope":"example_scope", @@ -586,28 +604,45 @@ The decoded server error response is: { "status":"invalid_token", "scope":"example_scope", "openid-configuration":"https://example.com/.well-known/openid-configuration" } The client responds with the required dummy response, "AQ==" is the - base64 encoding of the ASCII value 0x01. + base64 encoding of the ASCII value 0x01. The same exchange using the + IMAP specific method of cancelling an AUTHENTICATE command sends "*" + and is shown below. + + S: * OK IMAP4rev1 Server Ready + C: t0 CAPABILITY + S: * CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER SASL-IR IMAP4rev1 + S: t0 OK Completed + C: t1 AUTH OAUTHBEARER bixhPXVzZXJAZXhhbXBsZS5jb20sAW + hvc3Q9c2VydmVyLmV4YW1wbGUuY29tAXBvcnQ9MTQzAWF1dGg9AQE= + S: + eyJzdGF0dXMiOiJpbnZhbGlkX3Rva2VuIiwic2NvcGUiOiJleGFtcGxl + X3Njb3BlIiwib3BlbmlkLWNvbmZpZ3VyYXRpb24iOiJodHRwczovL2V4 + YW1wbGUuY29tLy53ZWxsLWtub3duL29wZW5pZC1jb25maWd1cmF0aW9u + In0= + C: * + S: t1 NO SASL authentication failed 4.4. SMTP Example of a Failed Negotiation This example shows an authorization failure in an SMTP exchange. Note that line breaks are inserted for readability, and that the SMTP protocol terminates lines with CR and LF characters (ASCII values 0x0D and 0x0A), these are not displayed explicitly in the example. + TLS negotiation is not shown but as noted above it is required for + the use of Bearer Tokens. [connection begins] S: 220 mx.example.com ESMTP 12sm2095603fks.9 C: EHLO sender.example.com S: 250-mx.example.com at your service,[172.31.135.47] S: 250-SIZE 35651584 S: 250-8BITMIME S: 250-AUTH LOGIN PLAIN OAUTHBEARER S: 250-ENHANCEDSTATUSCODES S: 250 PIPELINING @@ -743,20 +778,23 @@ Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, "OpenID Connect Core 1.0", February 2014. [OpenID.Discovery] Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID Connect Discovery 1.0", July 2011. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. + [RFC2244] Newman, C. and J. Myers, "ACAP -- Application + Configuration Access Protocol", RFC 2244, November 1997. + [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001. [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006. [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax @@ -780,35 +818,39 @@ Framework: Bearer Token Usage", RFC 6750, October 2012. [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, March 2014. 8.2. Informative References [I-D.ietf-oauth-dyn-reg] Richer, J., Jones, M., Bradley, J., Machulak, M., and P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", - draft-ietf-oauth-dyn-reg-20 (work in progress), August - 2014. + draft-ietf-oauth-dyn-reg-22 (work in progress), January + 2015. [I-D.ietf-oauth-json-web-token] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token - (JWT)", draft-ietf-oauth-json-web-token-31 (work in - progress), November 2014. + (JWT)", draft-ietf-oauth-json-web-token-32 (work in + progress), December 2014. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003. + [RFC4959] Siemborski, R. and A. Gulbrandsen, "IMAP Extension for + Simple Authentication and Security Layer (SASL) Initial + Client Response", RFC 4959, September 2007. + [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008. [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011. [RFC6819] Lodderstedt, T., McGloin, M., and P. Hunt, "OAuth 2.0 Threat Model and Security Considerations", RFC 6819, January 2013. @@ -823,20 +865,28 @@ Williams, Matt Miller, and Benjamin Kaduk. This document was produced under the chairmanship of Alexey Melnikov, Tom Yu, Shawn Emery, Josh Howlett, Sam Hartman. The supervising area director was Stephen Farrell. Appendix B. Document History [[ to be removed by RFC editor before publication as an RFC ]] + -19 + + o Last call feedback agaiun. + + o Clarified usage of TLS in examples and fixed them some more. + Adding reference to RFC4422 and cancellation token and an example + for that. + -18 o Last call feedback round #5. Fixed -17 change log. o Corrected "issue" to "iss", other minor changes. -17 o Last call feedback again (WGLC #4). eradicated comma splicing. Removed extra server message in example 4.3.