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

["Richer, Justin P." <[e-mail]>]

So if that's the case -- you've got a client that can't keep a secret that has a secret -- you do one of the normal auth methods (like client_secret_basic) and call it a day. I don't think it makes any sense, and the language below is really less about client secrets and more about assertions and other methods of authentication that otherwise "public" clients could use. DynReg makes it so that the client_secret is now a runtime secret, so we're already outside the core definitions of public/confidential clients anyway.

 -- Justin

On May 9, 2013, at 8:41 AM, Josh Mandel <[e-mail]<mailto:[e-mail]>>
 wrote:


> A true public client doesn't have a client_secret or its equivalent, so it would have

If this is the case,  then my premise #2 is wrong -- and in that case my  concern about dynamic registration disappears.  But if so: what is the quoted bit of 2.3 *supposed* to indicate? (If not that a public client might,  in some scenarios, be given a client_secret with the explicit expectation that it won't be kept secret and the stipulation that it mustn't be relied upon for authentication... )

Thanks!

  - Josh

> On May 7, 2013, at 10:09 AM, Josh Mandel <[e-mail]<mailto:[e-mail]>>
>  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, <[e-mail]<mailto:[e-mail]>> 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
>>> [e-mail]<mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]<mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/oauth
>
>