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

Hi Bill,

reads like a good consensus.

kind regards,
Torsten.

Am 16.10.2014 21:12, schrieb Bill Mills:
> 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 are
> described in, for example, [RFC6750] for the OAuth Bearer Token
> instead) and are the main functionality specified within this
> document. Consequently, the message exchange shown in Figure 1 is the
> result of this specification. The client will generally need to
> determine the authentication endpoints (and perhaps the service
> endpoints) 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 OpenID
> Connect 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 endpoints
> MAY require client registration and generic clients SHOULD support
> the 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 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.
>
>
> (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 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.
>
>
>
> On Wednesday, October 15, 2014 11:47 AM, Bill Mills 
> <wmills_92105@yahoo.com> 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
>
> Kitten@ietf.org <mailto:Kitten@ietf.org>
>
> https://www.ietf.org/mailman/listinfo/kitten
>
>
>