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

From: Justin Richer <[email-masked]>
Date: Mon, 1 Apr 2013 13:04:45 -0400

If the access token isn't valid, then the intent is that the server 
return whatever is a valid response from OAuth, which as I recall is 
practically any 400 class error. This behavior for DynReg is outlined in 
section 5.2 of draft -09.

In your case, since you're actually failing on the bad token, you're 
fine with returning a 401. In other words, by my intent of the text and 
my understanding of your implementation, you're actually compliant. The 
problem is that the text made you think otherwise. :)

Can you suggest how to make this clearer for developers in the text?

  -- Justin

On 03/29/2013 11:57 PM, nov matake wrote:
> oops sorry, not draft07, but draft06.
>
> On 2013/03/30, at 12:55, nov matake <[email-masked]> wrote:
>
>> Hi Justin,
>>
>> I read the latest draft and found endpoints described in the spec returns 403 in "no such clients" case.
>> I also read the draft07's editor note below, so I can understand the situation.
>>
>> [[ Editor's note: If the client doesn't exist,
>> then the Refresh Access Token shouldn't be valid, making this kind of
>> error a 403 at the auth layer instead.  How best to call this
>> inconsistency out? ]]
>>
>> However, in my current implementation, the server returns 401 if an access token is given but there are no valid access token in its DB.
>> In my case, validation for the given access token is done in middleware layer, so I don't want to change the error code per endpoint.
>> In such case, client registration/read/update/delete endpoints can return 401 error?
>>
>> Thanks
>>
>> --
>> nov
>>
>> On 2013/03/30, at 5:53, Justin Richer <[email-masked]> wrote:
>>
>>> New dynamic registration draft is published. Biggest changes here are the internationalization/localization capabilities that are now applicable to human-readable client metadata fields.
>>>
>>> -- Justin
>>>
>>> On 03/29/2013 04:38 PM, [email-masked] 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-09.txt
>>>> 	Pages           : 23
>>>> 	Date            : 2013-03-29
>>>>
>>>> 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-09
>>>>
>>>> A diff from the previous version is available at:
>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-09
>>>>
>>>>
>>>> Internet-Drafts are also available by anonymous FTP at:
>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> _______________________________________________
>>> OAuth mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/oauth

---

From: nov matake <[email-masked]>
Date: Tue, 2 Apr 2013 02:23:48 +0900

Thanks for your clarification.

After reading the editor's note in draft06, I felt 401 is more natural than 403.
(assuming you don't want to use 404 for security reason)

The editor's note is enough detail for the reason of using 401.

Using 403, it's like "the token is valid, but the ghost client has no permission"..?

On 2013/04/02, at 2:04, Justin Richer <[email-masked]> wrote:

> If the access token isn't valid, then the intent is that the server return whatever is a valid response from OAuth, which as I recall is practically any 400 class error. This behavior for DynReg is outlined in section 5.2 of draft -09.
> 
> In your case, since you're actually failing on the bad token, you're fine with returning a 401. In other words, by my intent of the text and my understanding of your implementation, you're actually compliant. The problem is that the text made you think otherwise. :)
>

---

From: nov matake <[email-masked]>
Date: Tue, 2 Apr 2013 02:35:38 +0900

[Current]
If the client does not exist on this server, the server MUST return an HTTP 403 Forbidden.

[Proposed]
If the client does not exist on this server, the server treat the given token as invalid and
MUST return HTTP 401 Unauthorized as described in RFC 6750 Section 3.1.

---

From: Justin Richer <[email-masked]>
Date: Mon, 1 Apr 2013 13:47:53 -0400

I think that text is a viable solution -- we didn't want the "ghost 
client" situation to be 404 for security reasons (to keep people from 
poking around the registration endpoint). I don't think it's going to 
happen in practice, but I think it's important to be clear on what to do 
in this situation.

Created an issue to track it here: 
https://github.com/jricher/oauth-spec/issues/62

  -- Justin