[kitten] proposed softer revision to 3.2.2 Re: I-D Action: draft-ietf-kitten-sasl-oauth-16.txt

[Bill Mills <[e-mail]>]

Based on the discussion here I've put together softer language that gives the right guidance but doesn't make major normative changes in the draft.

Section 1 Introduction -- second to last paragraph:
Again, steps (E) and (F) are not defined in [RFC6749] (but aredescribed in, for example, [RFC6750] for the OAuth Bearer Tokeninstead) and are the main functionality specified within thisdocument. Consequently, the message exchange shown in Figure 1 is theresult of this specification. The client will generally need todetermine the authentication endpoints (and perhaps the serviceendpoints) before the OAuth 2.0 protocol exchange messages in steps(A)-(D) are executed. The discovery of the resource owner, authorization server endpoints, and client registration are outside the scope of this specification. The client must discover the authorization endpoints using a discovery mechanism such as OpenIDConnect Discovery [OpenID.Discovery] or Webfinger using host-meta[RFC7033].  Once credentials are obtained the client proceeds to steps(E) and (F) defined in this specification.  Authorization endpointsMAY require client registration and generic clients SHOULD supportthe Dynamic Client Registration protocol [I-D.ietf-oauth-dyn-reg].
(Note: I struck "In band discovery is not tenable if clients support the OAuth 2.0 password grant.)


Section 3.2.2 In the "oauth-configuration (OPTIONAL):" bullet add:
(appended to/after the first paragraph)
The returned discovery document SHOULD have all dataelements required by the OpenID Connect Discovery specificationpopulated.  In addition, the discovery document SHOULD containthe 'registration_endpoint' element to learn about the endpointto be used with the Dynamic Client Registration protocol[I-D.ietf-oauth-dyn-reg] to obtain the minimum number ofparameters necessary for the OAuth protocol exchange tofunction.  Another comparable discovery or client registrationmechanism MAY be used if available. 
The use of the 'offline_access' scope, as defined in[OpenID.Core] is RECOMMENDED to give clients the capability toexplicitly request a refresh token.

(At the end of this bullet)
Since clients may interact with a number of application servers,such as email servers and XMPP servers, they need to have a wayto determine whether dynamic client registration has been performedalready and whether an already available refresh token can bere-used to obtain an access token for the desired resource server.This specification RECOMMENDs that a client uses the information inthe 'issue' element to make this determination.
 

     On Wednesday, October 15, 2014 11:47 AM, Bill Mills <[e-mail]> wrote:
   

 I think that wants to be a draft that's more generalto OpenID and OAuth.  Agreed it's a good thing.
_______________________________________________
Kitten mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/kitten