Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-16.txt

From: [email-masked]
Date: Tue, 16 Sep 2014 16:45:19 -0700

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/

---

From: Bill Mills <[email-masked]>
Date: Tue, 16 Sep 2014 17:04:09 -0700

-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, "[email-masked]" <[email-masked]> wrote:

Abstract:

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

---

From: Bill Mills <[email-masked]>
Date: Tue, 16 Sep 2014 17:16:33 -0700

Resending with a more useful subject line.  

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

New text for 3.2.2:
-----------------------

-bill

Abstract:

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 17 Sep 2014 19:07:56 -0400 (EDT)

On Tue, 16 Sep 2014, Bill Mills wrote:

> -16 is submitted, and there is one suggested change (which I was

Thanks.

The new text for the "host" key/value has a comma splice.

In 4.3, there is an added message from the server.  Is that intended to
replace the previous value?

> supposed to have added in already and blew it), which is to replace
> section 3.2.2 with the text (farther) below.

I think I am confused or missed an email or something; I don't remember
why you were supposed to add this 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.

Even in the new text it is OPTIONAL, which would seem consistent with the
lack of requirement.

> #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.

The text in -16 seems more consistent with that goal than the text below.

> #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.

I don't have any position on the use or inclusion of scopes; I am only
concerned that if someone concludes they need to use a scope, they have
some sense of how to do so/what to choose.  It seems that this is a matter
for generic OAuth specifications, not this document, most likely.

> New text for 3.2.2:

It seems slightly redundant to say that it MUST have all the required
features of the thing that it complies to, but maybe the extra emphasis is
needed.

-Ben

---

From: Bill Mills <[email-masked]>
Date: Thu, 18 Sep 2014 00:46:25 +0000 (UTC)

for the nascent -17 draft: killed the comma splice, and removed the cruft server message that had the wrong status (401) in the base64 encoded stuff. 
The suggested text is from an off list conversation, bringing it to the list.
-bill

     On Wednesday, September 17, 2014 4:08 PM, Benjamin Kaduk <[email-masked]> wrote:

Thanks.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 17 Sep 2014 23:13:03 -0400 (EDT)

> The suggested text is from an off list conversation, bringing it to the list.

I would strongly suggest that the other party in the off-list conversation
send their comments to the list.

I think that in this point in the document's progression, we should have
some on-list justification and general consensus for any changes that are
being made.

-Ben

---

From: Bill Mills <[email-masked]>
Date: Mon, 22 Sep 2014 21:52:50 +0000 (UTC)

The  new language is proposed by Hannes and Torsten.  Hoping one of them will have time to follow up on list soon.
-bill 

     On Wednesday, September 17, 2014 8:13 PM, Benjamin Kaduk <[email-masked]> wrote:

-Ben