Subject: [OAUTH-WG] A couple of questions re dynamic client registration

From: Todd W Lainhart <[email-masked]>
Date: Fri, 25 Oct 2013 16:47:53 -0400

I'm working off this document for our client registration: 
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-14 

Section 4 - Client Configuration Endpoint says this:

The client MUST use its registration access token in
   all calls to this endpoint as an OAuth 2.0 Bearer Token [RFC6750].

I'm trying to understand if I should provide a separate administrative 
endpoint for client configurations (i.e. accessible via an entity with 
admin credentials/privileges).  I think this language is telling me "yes". 
 What are the client options for read/update/delete should this access 
token be lost?  I read "none".

Section 4.1 - Section 4.1 says this:

The authorization server MUST provide the client with the fully
   qualified URL in the "registration_client_uri" element of the Client
   Information Response (Section 5.1).

I'm curious as to why this isn't returned in the Location header?

Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250
1-978-899-4705
2-276-4705 (T/L)
[email-masked]

---

From: "Richer, Justin P." <[email-masked]>
Date: Sat, 26 Oct 2013 16:20:32 +0000

On Oct 25, 2013, at 1:47 PM, Todd W Lainhart <[email-masked]<mailto:[email-masked]>>
 wrote:

I'm working off this document for our client registration: http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-14

The client MUST use its registration access token in
  all calls to this endpoint as an OAuth 2.0 Bearer Token [RFC6750<http://tools.ietf.org/html/rfc6750>].

I'm trying to understand if I should provide a separate administrative endpoint for client configurations (i.e. accessible via an entity with admin credentials/privileges).  I think this language is telling me "yes".  What are the client options for read/update/delete should this access token be lost?  I read "none".

I would suggest it, or provide alternative mechanisms to access the endpoint. Our own implementation (MITREid) does the former. In our case, we also wanted a mechanism whereby our admins can edit the client id and client secret directly as needed, as well as support manual registration, neither of which are supported by the dynamic registration protocol (and that's on purpose).

The authorization server MUST provide the client with the fully
  qualified URL in the "registration_client_uri" element of the Client
  Information Response (Section 5.1<http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-14#section-5.1>).

Simply because we wanted it to be self-contained in the returned JSON object. We could, I suppose, also return it in the location header, which would follow REST principles a little better.

 -- Justin

Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250
1-978-899-4705
2-276-4705 (T/L)
[email-masked]<mailto:[email-masked]>

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth