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

[Benjamin Kaduk <[e-mail]>]

On Tue, 16 Sep 2014, Bill Mills wrote:

> 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

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.
> My comments on the suggested text:

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:
> -----------------------
> 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

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

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