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 <jman...@gmail.com<mailto:jman...@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-dra...@ietf.org<mailto:internet-dra...@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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
