[kitten] Suggested changes for -16 Re: I-D Action: draft-ietf-kitten-sasl-oauth-16.txt

[Bill Mills <[e-mail]>]

Resending with a more useful subject line.  



On Tuesday, September 16, 2014 5:04 PM, Bill Mills <[e-mail]> wrote:


-16 is submitted, and there is one suggested change (which I was supposed to have added in already and blew it), which is to replace section 3.2.2 with the text (farther) below.

My comments on the suggested text:

#1)  I don't think the dynamic registration stuff is baked enough to want to pull that in to the "oauth-configuration" definition.  I don't want to pull it in because I don't think dynamic registration is required for SASL/OAUTH (as evidenced by the Google and Outlook.com implementations.

#2)  I didn't really want to make all of the OpenID elements required but I don't have a strong opinion here, my initial intent was to use the OpenID Discovery format as an existing format to be re-used here but leave it flexible.

#3)  I am against recommending scope names at all in any way.  I would not include the last sentence of paragraph 5 below and strike the scope names.


New text for 3.2.2:
-----------------------
3.2.2.  Server Response to Failed Authentication  


For a failed authentication the server returns a JSON [RFC4627] 
formatted error result, and fails the authentication.  The error 
result consists of the following values:      


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 a document following 
the OpenID Provider Configuration Information schema, as 
described in Section 3 of the OpenID Connect Discovery 
[OpenID.Discovery], that is appropriate for the user.  The 
server MAY return different URLs for users from different 
domains and a client MUST NOT cache a single returned value and 
assume it applies for all users/domains that the server 
suports.  The returned discovery document MUST have all data 
elements required by the OpenID Connect Discovery specification 
populated.  In addition, the discovery document MUST 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.  Authorization servers MUST implement the 
authorization code grant and other grant types MAY be 
supported.  Furthermore, authorization servers MUST implement 
the ability to issue refresh tokens for use with native 
applications to benefit from an abbreviated protocol exchange. 
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 (as part of the element of 
the configuration payload) then the client MUST always request 
scoped tokens from the token endpoint.  This specification 
RECOMMMENDs the use of the following scopes:  

imap:  The 'imap' scope value is used to interact with IMAP mail 
servers.  

pop3:  The 'pop3' scope value is used to interact with POP3 mail 
servers.  

xmpp:  The 'xmpp' scope value is used to interact with XMPP servers.  



If the resource server provides no scope to the client then the 
client SHOULD presume an empty scope (unscoped token) is needed.  


Since clients may interact with a number of application servers, 
such 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 'issue' element to make this determination. 
-----------------------


I think we're getting very close :)

-bill



Draft -16 notification follows:
----------------------------------------------------




On Tuesday, September 16, 2014 4:45 PM, "[e-mail]" <[e-mail]> wrote:




A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF.

        Title           : A set of SASL Mechanisms for OAuth
        Authors         : William Mills
                          Tim Showalter
                          Hannes Tschofenig
    Filename        : draft-ietf-kitten-sasl-oauth-16.txt
    Pages           : 22
    Date            : 2014-09-16

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
   (SASL) to access a protected resource at a resource serve.  Thereby,
   it enables schemes defined within the OAuth framework for non-HTTP-
   based application protocols.

   Clients typically store the user's long-term credential.  This does,
   however, lead to significant security vulnerabilities, for example,
   when such a credential leaks.  A significant benefit of OAuth for
   usage in those clients is that the password is replaced by a shared
   secret with higher entropy, i.e., the token.  Tokens typically
   provide limited access rights and can be managed and revoked
   separately from the user's long-term password.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-oauth/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-16

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-sasl-oauth-16


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
Kitten mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/kitten




_______________________________________________
Kitten mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/kitten