Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration

[Justin Richer <[e-mail]>]

I'm not sure why you don't think it's in scope, it's in the working 
group's charter:

   http://www.ietf.org/dyn/wg/charter/oauth-charter.html

So ... it's definitely in scope, and has been for over a year and a 
half. This is the tenth version of this document-- an IETF Working Group 
document at that-- that's been posted to the group with every revision 
and there has been significant conversation around it, especially over 
the last six months since I took over the editor role. There are also a 
handful of implementations of this, and while most of them are built to 
do OpenID Connect or UMA (which are directly built on OAuth), I know 
there are some that also do plain OAuth. (Not the least of which is one 
that I have personally implemented and deployed.)

SCIM doesn't solve client management particularly well, since it's made 
for users more than anything. The usage model of SCIM is also quite 
different -- it's really intended to be used between two servers to 
transfer information, as opposed to handling self-asserted claims. I 
understand that some implementations like UAA have done their static 
registration using a SCIM profile, but it's not dynamic registration, 
really. I think it's too much of a square-peg-round-hole problem, at 
least with SCIM as it is today; so let SCIM do what it's good at, and 
don't try to force it into something it's not.

Furthermore, be careful not to conflate SCIM with REST. Ultimately, 
Dynamic Registration was meant to be a fairly simple REST/JSON API that 
would be easy to implement, especially for clients. Just because SCIM is 
RESTful doesn't mean it's a good structure for other RESTful APIs. 
Namely, I don't think the extra structure and hooks with SCIM really buy 
you anything here, especially with the additions and changes you'd have 
to make to SCIM.

And finally, nobody to date has actually written a proposal that is even 
remotely SCIM based.

  -- Justin

On 05/22/2013 02:39 PM, Anthony Nadalin wrote:
>
> So, I really don’t understand why dynamic registration is in scope, I 
> understand this relative to OpenID Connect but not OAuth, if this is 
> indeed in scope then I would have expected that the endpoint be based 
> upon SCIM and not something else like what has been done here.
>
> *From:*Justin Richer [mailto:[e-mail]]
> *Sent:* Monday, May 20, 2013 11:10 AM
> *To:* Anthony Nadalin
> *Cc:* Phil Hunt; [e-mail]
> *Subject:* Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration
>
> Tony, can you be more specific? What needs to be changed in your 
> opinion? What text changes would you suggest?
>
>  -- Justin
>
> On 05/20/2013 02:09 PM, Anthony Nadalin wrote:
>
>     Agree
>
>     *From:*[e-mail] <mailto:[e-mail]>
>     [mailto:[e-mail]] *On Behalf Of *Phil Hunt
>     *Sent:* Monday, May 20, 2013 9:42 AM
>     *To:* Justin Richer
>     *Cc:* [e-mail] <mailto:[e-mail]>
>     *Subject:* Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic
>     Registration
>
>     This draft isn't ready for LC.
>
>     Phil
>
>
>     On 2013-05-20, at 8:49, Justin Richer <[e-mail]
>     <mailto:[e-mail]>> wrote:
>
>         But also keep in mind that this is last-call, and that we
>         don't really want to encourage avoidable drastic changes at
>         this stage.
>
>          -- Justin
>
>
>         On 05/20/2013 11:21 AM, Phil Hunt wrote:
>
>             Keep in mind there may be other changes coming.
>
>             The issue is that new developers can't figure out what
>             token is being referred to.
>
>
>             Phil
>
>
>             On 2013-05-20, at 8:09, Justin Richer <[e-mail]
>             <mailto:[e-mail]>> wrote:
>
>                 Phil Hunt's review of the Dynamic Registration
>                 specification has raised a couple of issues that I
>                 felt were getting buried by the larger discussion
>                 (which I still strongly encourage others to jump in
>                 to). Namely, Phil has suggested a couple of syntax
>                 changes to the names of several parameters.
>
>
>                 1) expires_at -> client_secret_expires_at
>                 2) issued_at -> client_id_issued_at
>                 3) token_endpoint_auth_method ->
>                 token_endpoint_client_auth_method
>
>
>                 I'd like to get a feeling, *especially from
>                 developers* who have deployed this draft spec, what we
>                 ought to do for each of these:
>
>                  A) Keep the parameter names as-is
>                  B) Adopt the new names as above
>                  C) Adopt a new name that I will specify
>
>                 In all cases, clarifying text will be added to the
>                 parameter *definitions* so that it's more clear to
>                 people reading the spec what each piece does. Speaking
>                 as the editor: "A" is the default as far as I'm
>                 concerned, since we shouldn't change syntax without
>                 very good reason to do so. That said, if it's going to
>                 be better for developers with the new parameter names,
>                 I am open to fixing them now.
>
>                 Naming things is hard.
>
>                  -- Justin
>
>                 _______________________________________________
>                 OAuth mailing list
>                 [e-mail] <mailto:[e-mail]>
>                 https://www.ietf.org/mailman/listinfo/oauth
>