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

From: [email-masked]
Date: Fri, 29 Mar 2013 13:38:08 -0700

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/

---

From: Justin Richer <[email-masked]>
Date: Fri, 29 Mar 2013 16:53:23 -0400

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:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: nov matake <[email-masked]>
Date: Sat, 30 Mar 2013 12:55:59 +0900

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
>

---

From: nov matake <[email-masked]>
Date: Sat, 30 Mar 2013 12:57:25 +0900

oops sorry, not draft07, but draft06.