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

[Justin Richer <[e-mail]>]

In fact, one of the driving factors in this draft was so that OIDC and 
UMA wouldn't have to invent their own protocols and that we could 
abstract the knowledge in both of these for a well-considered basic use 
case. We as a working group long ago agreed that we needed to do dynamic 
registration in OAuth, and instead of trying to invent from whole cloth, 
we combined these two known protocols. This was the deliberate process 
and you can see that reflected in the document's history.

So there's no forcing involved.
  -- Justin

On 05/22/2013 06:48 PM, Anthony Nadalin wrote:
>
> My mistake, was to say, We already have OpenID Connect doing dynamic 
> registration, I don’t think there is a need to force it into OAuth.
>
> *From:*Phil Hunt [mailto:[e-mail]]
> *Sent:* Wednesday, May 22, 2013 3:16 PM
> *To:* Anthony Nadalin
> *Cc:* Justin Richer; [e-mail]
> *Subject:* Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration
>
> I'm having trouble understanding
>
>     We already have OAuth doing dynamic registration, I don’t think
>     there is a need to force it into OAuth.
>
> I would be open to a scim dyn reg version. Particularly to discuss 
> instance metadata mgt which scim is good at and the credential 
> managemenr/bootstrap process as it pertains to oauth.  Never-the-less 
> the overwhelming priority has been apparently to simply standardize 
> oidc and uma implementations as is. This I am not comfortable with but 
> i can live with if there is give and take.
>
> I feel the subject is well in charter and is an important issue due to 
> the life-cycle management issues behind clients and the need to make 
> public clients the security equiv. of confidential clients.
>
> Phil
>
>
> On 2013-05-22, at 14:22, Anthony Nadalin <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     I totally disagree with your characterization of SCIM, while it
>     can be used from server to server (provision one system to
>     another) it can also be client to endpoint (initial provisioning
>     and JIT provisioning). SCIM is fairly simple (but can be complex),
>     I also have concerns about SCIM not being 100% restful but that
>     does not stop us from using it. I also agree that we should let
>     OAuth do what it’s good at and don’t try to force it into
>     something that it’s not. We already have OAuth doing dynamic
>     registration, I don’t think there is a need to force it into OAuth.
>
>     *From:*Justin Richer [mailto:[e-mail]]
>     *Sent:* Wednesday, May 22, 2013 1:35 PM
>     *To:* Anthony Nadalin
>     *Cc:* Phil Hunt; [e-mail] <mailto:[e-mail]>
>     *Subject:* Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic
>     Registration
>
>     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] <mailto:[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
>