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

From: Justin Richer <[email-masked]>
Date: Mon, 20 May 2013 11:09:14 -0400

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

---

From: Phil Hunt <[email-masked]>
Date: Mon, 20 May 2013 08:21:10 -0700

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

---

From: Justin Richer <[email-masked]>
Date: Mon, 20 May 2013 11:49:27 -0400

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:
> On 2013-05-20, at 8:09, Justin Richer <[email-masked] 
> <mailto:[email-masked]>> 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.
>>
>>
>> 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
>> [email-masked] <mailto:[email-masked]>

---

From: "Donald F Coffin" <[email-masked]>
Date: Mon, 20 May 2013 08:58:23 -0700

Justin,

We are still working on the requirement document for integrating OAuth 2.0
into the NAESB ESPI standard.  To date, no one who has implemented the
current "Download My Data" or "Connect My Data" features of the ESPI
standard would be affected, since they have not implemented OAuth 2.0.  I
would vote for "B" as I believe it clarifies intention of the field, but am
also satisfied if "A" is the final result.

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA  92688-3836

Phone:      (949) 636-8571

Email:       [email-masked]

From: Justin Richer [mailto:[email-masked]] 
Sent: Monday, May 20, 2013 8:09 AM
To: [email-masked]
Subject: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration

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. 

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:

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

---

From: Phil Hunt <[email-masked]>
Date: Mon, 20 May 2013 09:41:52 -0700

This draft isn't ready for LC. 

Phil

On 2013-05-20, at 8:49, Justin Richer <[email-masked]> 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
> 
>

---

From: Justin Richer <[email-masked]>
Date: Mon, 20 May 2013 12:42:09 -0400

I, of course, disagree. But that's what we're trying to figure out as a 
working group, after all.

  -- Justin

On 05/20/2013 12:41 PM, Phil Hunt wrote:
> On 2013-05-20, at 8:49, Justin Richer <[email-masked] 
>> 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
>>
>>
>>>> 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.
>>>>
>>>>
>>>> *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

---

From: Mike Jones <[email-masked]>
Date: Mon, 20 May 2013 16:48:59 +0000

The deployment evidence doesn’t support your position, Phil.  There are over a dozen interoperable implementations already deployed.  Those deployments demonstrate that the spec, as written, is already doing one thing well – enabling clients (as defined by RFC 6749) to register with Authorization Servers, obtaining client_id and optionally client_secret values that enable those clients to use those Authorization Servers.  Doing one thing well is exactly what we should be striving for, and the evidence says that we’ve achieved that.

It’s time to ship it!

                                                                -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Justin Richer
Sent: Monday, May 20, 2013 9:42 AM
To: Phil Hunt
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration

I, of course, disagree. But that's what we're trying to figure out as a working group, after all.

 -- Justin

Phil

On 2013-05-20, at 8:49, Justin Richer <[email-masked]<mailto:[email-masked]>> 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

Phil

On 2013-05-20, at 8:09, Justin Richer <[email-masked]<mailto:[email-masked]>> 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.

Naming things is hard.

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

---

From: Mike Jones <[email-masked]>
Date: Mon, 20 May 2013 16:52:47 +0000

I believe that no syntax changes are necessary.

Of the three possible changes described below, I particularly believe that (3) is completely unnecessary, as there is nothing that authenticates to the Token Endpoint other than the client.  Thus, adding “client_” to the name adds no useful semantic content.  This proposed change is especially superfluous.

                                                            -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Monday, May 20, 2013 8:21 AM
To: Justin Richer
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration

Phil

Naming things is hard.

 -- Justin

---

From: Justin Richer <[email-masked]>
Date: Mon, 20 May 2013 12:57:42 -0400

For what it's worth, I also agree that (3) is overkill. The other two, I 
believe, have more potential value in clarity, and I haven't yet heard 
evidence that making this particular syntax change would be either easy 
or difficult from other developers. It's possible (though completely 
conjectural on my part) that nobody's actually using these informational 
fields yet, so changing them now would be relatively painless on the 
ground and would make things clearer going forward.

  -- Justin

On 05/20/2013 12:52 PM, Mike Jones wrote:
> Of the three possible changes described below, I particularly believe 
> that (3) is completely unnecessary, as there is nothing that 
> authenticates to the Token Endpoint other than the client.  Thus, 
> adding “client_” to the name adds no useful semantic content.  This 
> proposed change is especially superfluous.
>
> -- Mike
>
> *From:[email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Phil Hunt
> *Sent:* Monday, May 20, 2013 8:21 AM
> *To:* Justin Richer
> *Cc:* [email-masked]
> *Subject:* Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration
>
>     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
>

---

From: Phil Hunt <[email-masked]>
Date: Mon, 20 May 2013 10:51:02 -0700

-1

The draft has features that are unclear and will double the operational cost. The fact that it works doesn't mean it is ready from the wg perspective. 

For the production use, has anyone outside of oidc implemented and placed in production?

As a non-oidc implementer, I can't make the same assumptions (like discovery) that oidc umplementers have. 

Phil

---

From: Justin Richer <[email-masked]>
Date: Mon, 20 May 2013 14:00:01 -0400

Phil, I think what you're bringing up is a red herring. Everyone that 
does OAuth today does "discovery" in some manner or another, even if 
it's not specified to be dynamic like it is in OIDC. Most of the time 
this happens manually, out of band. For instance, a number of our 
clients here have historically done "discovery" of the server's 
capabilities by the client developers just pasting in all the URLs and 
parameters to their application's configuration. They get these values 
from the server documentation. Just because a piece of information needs 
to be known doesn't mean that it needs to be automatically discovered at 
runtime.

And yes, we are using it in a plain-OAuth context here, in addition to 
an OIDC context. This is using the same server code, for what its worth.

I also take issue with your contention that it will "double the 
operational cost" -- how so? If you don't want to enforce the 
token_endpoint_auth_method, just don't have your clients send it and 
don't have the server return it. It's optional for a reason -- if you 
don't like it or have no use for it, don't use it.

  -- Justin

On 05/20/2013 01:51 PM, Phil Hunt wrote:
> -1
>
> The draft has features that are unclear and will double the 
> operational cost. The fact that it works doesn't mean it is ready from 
> the wg perspective.
>
> On 2013-05-20, at 9:48, Mike Jones <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> The deployment evidence doesn’t support your position, Phil.  There 
>> are over a dozen interoperable implementations already deployed.  
>> Those deployments demonstrate that the spec, as written, is already 
>> doing one thing well – enabling clients (as defined by RFC 6749) to 
>> register with Authorization Servers, obtaining client_id and 
>> optionally client_secret values that enable those clients to use 
>> those Authorization Servers.  Doing one thing well is exactly what we 
>> should be striving for, and the evidence says that we’ve achieved that.
>>
>> It’s time to ship it!
>>
>> -- Mike
>>
>> *From:[email-masked] <mailto:[email-masked]> 
>> [mailto:[email-masked]] *On Behalf Of *Justin Richer
>> *Sent:* Monday, May 20, 2013 9:42 AM
>> *To:* Phil Hunt
>> *Cc:* [email-masked] <mailto:[email-masked]>
>>         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
>>
>>                 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.
>>
>>
>>                 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:
>>
>>                 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
>>

---

From: Justin Richer <[email-masked]>
Date: Mon, 20 May 2013 14:10:29 -0400

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
>             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.
>
>
>             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:
>
>             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

---

From: Anthony Nadalin <[email-masked]>
Date: Mon, 20 May 2013 18:09:38 +0000

Agree

Phil

 -- Justin

Phil

Naming things is hard.

 -- Justin

---

From: Phil Hunt <[email-masked]>
Date: Mon, 20 May 2013 11:27:07 -0700

Further to my last…

Justin has already committed to breaking changes.  This may have been lost or buried in the long review thread.

Specifically - The client authentication types specified are undocumented (client_secret_jwt and private_key_jwt) as they were all Holder-of-Key authentication methods.  The OAuth drafts currently only have bearer drafts and dyn reg does not support these profiles.  Justin has acknowledged this.

It seems to me, that since the token_endpoint_auth_method is broken, the current implementations are actually implementing the draft correctly or servers are just ignoring it the parameter.

There are concerns with this draft.  I plan to make specific suggestions (some breaking) later this week.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Justin Richer <[email-masked]>
Date: Mon, 20 May 2013 14:39:09 -0400

Phil, that's not a fair comparison. What I've done is a fundamentally 
different kind of breaking change than the one you're asking for, though.

To explain more concretely: The change I agreed to make here was to 
remove two underspecified values (of five listed) to a parameter that is 
intended to be extensible. The extensions to DynReg that are using these 
values (like OIDC registration) can then define them fully (like they 
already are). That is a good change, and prompted by the good discussion 
and feedback you've given here. That doesn't mean that the parameter 
itself is "broken", and I think it's entirely another thing to remove 
the parameter wholesale when it has proven utility. Getting rid of it 
entirely would make it an OIDC-only parameter, when people are using it 
in non-OIDC contexts.

I acknowledge the concerns that you have with the draft, and I thank you 
for your feedback so far. However, I don't agree with your conclusions 
regarding those concerns. I do look forward to any concrete proposals 
you'll have later this week that will help further this discussion.

  -- Justin

On 05/20/2013 02:27 PM, Phil Hunt wrote:
> Further to my last...
>
> Justin has already committed to breaking changes.  This may have been 
> lost or buried in the long review thread.
>
> Specifically - The client authentication types specified are 
> undocumented (client_secret_jwt and private_key_jwt) as they were all 
> Holder-of-Key authentication methods.  The OAuth drafts currently only 
> have bearer drafts and dyn reg does not support these profiles. 
>  Justin has acknowledged this.
>
> It seems to me, that since the token_endpoint_auth_method is broken, 
> the current implementations are actually implementing the draft 
> correctly or servers are just ignoring it the parameter.
>
> There are concerns with this draft.  I plan to make specific 
> suggestions (some breaking) later this week.
>
> Phil
>
> @independentid
> www.independentid.com <http://www.independentid.com>
> [email-masked] <mailto:[email-masked]>
>
>
>
>
>
>> operational cost. The fact that it works doesn't mean it is ready 
>> from the wg perspective.
>>
>>> The deployment evidence doesn't support your position, Phil.  There 
>>> doing one thing well -- enabling clients (as defined by RFC 6749) to 
>>> those Authorization Servers.  Doing one thing well is exactly what 
>>> we should be striving for, and the evidence says that we've achieved 
>>> that.
>>>
>>> It's time to ship it!
>>>
>>> -- Mike
>>>
>>>                 without very good reason to do so. That said, if
>>>                 it's going to be better for developers with the new

---

From: Nat Sakimura <[email-masked]>
Date: Mon, 20 May 2013 20:42:09 +0200

No change please.

=nat via iPhone

On May 20, 2013, at 17:10, Justin Richer <[email-masked]> wrote:

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:

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

---

From: Edmund Jay <[email-masked]>
Date: Mon, 20 May 2013 13:23:53 -0700 (PDT)

+1 for keeping names as is.

________________________________
From: Justin Richer <[email-masked]>
To: "[email-masked]" <[email-masked]>
Sent: Mon, May 20, 2013 8:10:13 AM
Subject: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration

Naming things is hard.

 -- Justin

---

From: nov matake <[email-masked]>
Date: Tue, 21 May 2013 07:21:07 +0900

+1

---

From: John Bradley <[email-masked]>
Date: Mon, 20 May 2013 23:03:50 -0400

Phil the token_endpoint_auth_method is not broken.  We have agreed that the methods defined in Connect and not in the base spec will be registered separately in the registry rather than being in the base spec.  I don't think that is broken.

They are documented in Connect, that works for connect but less so for people who don't use that spec, so they go in the registry.

They are NOT related to HoK in any way they are just the JWT assertion profile with keying specified for symmetric and asymmetric.  The bearer profile as it is needs both sides to agree on keying otherwise it tends not to work.  

Some similar generic profile will need to be defined for JWT and SAML assertions to get interoperability outside of connect.

So this is not a breaking change, just a slight shuffling of where things are.

John B.

---

From: Roland Hedberg <[email-masked]>
Date: Tue, 21 May 2013 05:52:56 +0200

+1

Sent from my iPhone

On 21 maj 2013, at 00:21, "nov matake" <[email-masked]<mailto:[email-masked]>> wrote:

+1

On 2013/05/21, at 5:23, Edmund Jay <[email-masked]<mailto:[email-masked]>> wrote:

________________________________
From: Justin Richer <[email-masked]<mailto:[email-masked]>>
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Sent: Mon, May 20, 2013 8:10:13 AM
Subject: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration

Naming things is hard.

 -- Justin

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 22 May 2013 18:39:02 +0000

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:[email-masked]]
Sent: Monday, May 20, 2013 11:10 AM
To: Anthony Nadalin
Cc: Phil Hunt; [email-masked]
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

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Monday, May 20, 2013 9:42 AM
To: Justin Richer
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration

Phil

 -- Justin

Phil

Naming things is hard.

 -- Justin

---

From: Phil Hunt <[email-masked]>
Date: Wed, 22 May 2013 11:46:58 -0700

Let's make a new thread for this.  It is worth some discussion.

We have some strong cases for this, and I do think dyn reg involves some credential management issues that SCIM doesn't yet handle.

I think Justin is planning to make these aspects more clear in the draft.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Justin Richer <[email-masked]>
Date: Wed, 22 May 2013 16:34:44 -0400

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:[email-masked]]
> *Sent:* Monday, May 20, 2013 11:10 AM
> *To:* Anthony Nadalin
> *Cc:* Phil Hunt; [email-masked]
>     [mailto:[email-masked]] *On Behalf Of *Phil Hunt
>                 developers* who have deployed this draft spec, what we
>                 ought to do for each of these:
>
>                 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
>

---

From: Justin Richer <[email-masked]>
Date: Wed, 22 May 2013 16:38:02 -0400

I answered some of this in my reply to Tony already, but from my 
perspective it boils down to SCIM not really being that great of a fit 
for this kind of use. It makes very different assumptions about who's 
undertaking all of the actions, and those assumptions (which are 
completely valid assumptions, mind you) are baked into what the spec 
does and how it works. From what I understand of how SCIM works, you'd 
have to jump through some interesting hoops to get to the self-managed 
registration using SCIM as it's defined today, or even as it could be 
defined. There are profiles of using SCIM to transfer information about 
registered clients between AS's in different security domains (or 
different instances), but that's not dynamic registration. Someone can 
feel free to correct me if I'm completely off the rails here. (Won't be 
the first time. :) )

I say let's just keep letting SCIM be good at what it's good at and not 
try to squish it into something it's not.

  -- Justin

On 05/22/2013 02:46 PM, Phil Hunt wrote:
> We have some strong cases for this, and I do think dyn reg involves 
> some credential management issues that SCIM doesn't yet handle.
>
>> *Sent:*Monday, May 20, 2013 11:10 AM
>> *To:*Anthony Nadalin
>> *Cc:*Phil Hunt; [email-masked] <mailto:[email-masked]>
>> *Subject:*Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration
>>
>>     *From:[email-masked]
>>     <mailto:[email-masked]>[mailto:[email-masked]]*On
>>     Behalf Of*Phil Hunt
>>     *Sent:*Monday, May 20, 2013 9:42 AM
>>     *To:*Justin Richer
>>     *Cc:[email-masked] <mailto:[email-masked]>
>>     *Subject:*Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic
>>     Registration
>>                 I'd like to get a feeling,*especially from
>>                 developers*who have deployed this draft spec, what we

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 22 May 2013 21:22:23 +0000

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:[email-masked]]
Sent: Wednesday, May 22, 2013 1:35 PM
To: Anthony Nadalin
Cc: Phil Hunt; [email-masked]
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:

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

From: Justin Richer [mailto:[email-masked]]
Sent: Monday, May 20, 2013 11:10 AM
To: Anthony Nadalin
Cc: Phil Hunt; [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration

 -- Justin

Phil

 -- Justin

Phil

Naming things is hard.

 -- Justin

---

From: Phil Hunt <[email-masked]>
Date: Wed, 22 May 2013 15:16:07 -0700

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

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 22 May 2013 22:48:01 +0000

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:[email-masked]]
Sent: Wednesday, May 22, 2013 3:16 PM
To: Anthony Nadalin
Cc: Justin Richer; [email-masked]
Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration

Phil

On 2013-05-22, at 14:22, Anthony Nadalin <[email-masked]<mailto:[email-masked]>> 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.

 -- Justin

 -- Justin

Phil

 -- Justin

Phil

Naming things is hard.

 -- Justin

---

From: Justin Richer <[email-masked]>
Date: Wed, 22 May 2013 18:52:02 -0400

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:[email-masked]]
> *Sent:* Wednesday, May 22, 2013 3:16 PM
> *To:* Anthony Nadalin
> *Cc:* Justin Richer; [email-masked]
> 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
>
>
>     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.
>
>     *Sent:* Wednesday, May 22, 2013 1:35 PM
>     *To:* Anthony Nadalin
>     *Cc:* Phil Hunt; [email-masked] <mailto:[email-masked]>
>     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.
>
>         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.
>
>         *Cc:* Phil Hunt; [email-masked] <mailto:[email-masked]>
>         Tony, can you be more specific? What needs to be changed in
>         your opinion? What text changes would you suggest?
>
>          -- Justin
>
>             <mailto:[email-masked]>
>                 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 2013-05-20, at 8:09, Justin Richer
>                     <[email-masked] <mailto:[email-masked]>> wrote:
>
>                         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
>                         developers* who have deployed this draft spec,
>                         what we ought to do for each of these:
>
>                         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

---

From: "Donald F Coffin" <[email-masked]>
Date: Thu, 23 May 2013 13:20:28 -0700

The issue I have with not providing Dynamic Registration capability within OAuth (as the current document proposes) is that to provide a Dynamic Registration capability will then require the implementation of an additional standard to provide such support.  

At the present time, I am responsible for integrating OAuth 2.0 into the current NAESB REQ.21 -- Energy Service Provider Interface (ESPI) standard, which will require the existing standard to be revised.  The last thing the OpenESPI working group needs is to also require the implementation of another standard, such as OpenID, in order to implement a feature (i.e. Application Registration) that is already in the current specification.  The impetus for the current OAuth 2.0 integration is to revise the ESPI standard requirement to utilize OAuth 1.0, which was deprecated with the release of RFC6749 (The OAuth 2.0 Authorization Framework).

From: Anthony Nadalin [mailto:[email-masked]] 
Sent: Wednesday, May 22, 2013 3:48 PM
To: Phil Hunt
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Proposed Syntax Changes in Dynamic Registration

 

 

Phil

 

 -- Justin

 -- Justin

Agree

Phil

 -- Justin

Phil

Naming things is hard.

 -- Justin