Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-10.txt

A true public client doesn't have a client_secret or its equivalent, so it would have token_endpoint_auth_method = none. A confidential client can't use the implicit flow (since you can't send a client_secret to the auth endpoint), so there's a bit of overlap there.

Would it be useful to have an explanatory paragraph or table to this effect in the draft? I'm currently thinking that'd be a bit overkill, but I'd definitely rather it be clear and unambiguous.

 -- Justin

On May 7, 2013, at 10:09 AM, Josh Mandel <jmandel@gmail.com<mailto:jmandel@gmail.com>>
 wrote:

As I understand it (corrections welcome!) rfc6749 says that public clients:

1.  are defined functionally, as clients "incapable of maintaining the confidentiality of their credentials" [section 2.1]
2.  "MAY establish a client authentication method" if the server allows. e.g. client password auth [section 2.3]

Given 1 and 2, it's technical possible for a public client to be assigned a (not-so-)secret that it uses not for authentication per se, but merely to go through the motions of client password auth.

(How) Does dyn-reg support the registration of a public client that (for whatever reason -- code re-use?) seeks to use a client authentication method? It seems to me that, given the current draft, a registration server couldn't tell such a client from a confidential client  (token_endpoint_auth_method, grant_types, and response_types would be indistinguishable).

Is this use case out of scope?  If so, the spec might benefit from a note to that effect.  If not, an explicit flag at registration time (conveying the app's explicitly asserted "public" vs. "confidential" status) might help servers make better decisions.

  -Josh

On Sun, May 5, 2013 at 12:45 PM, <internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Web Authorization Protocol Working Group of the IETF.

        Title           : OAuth 2.0 Dynamic Client Registration Protocol
        Author(s)       : Justin Richer
                          John Bradley
                          Michael B. Jones
                          Maciej Machulak
        Filename        : draft-ietf-oauth-dyn-reg-10.txt
        Pages           : 25
        Date            : 2013-05-05

Abstract:
   This specification defines an endpoint and protocol for dynamic
   registration of OAuth 2.0 Clients at an Authorization Server and
   methods for the dynamically registered client to manage its
   registration.

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

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-10

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-10

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

_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth