Subject: [OAUTH-WG] Difference between client_update semantics in draft-ietf-oauth-dyn-reg and OpenID Connect Registration

From: Mike Jones <[email-masked]>
Date: Fri, 4 Jan 2013 23:55:19 +0000

The client_update operation in http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-03 does something different than the operation upon which it was based from http://openid.net/specs/openid-connect-registration-1_0-13.html.  Specifically, while the OpenID Connect operation replaces all field values, the OAuth operation allows only selective fields to be replaced, designating fields to remain unchanged by specifying their value as the empty string ("").

I'm personally not happy with the change to the semantics of client field inclusion.  Updating some but not all fields is a substantially more complicated operation than replacing all fields.  Is there some use case that motivates this?  I don't think it's a substantial burden on the registering party to remember all the field values from the initial registration and then selectively use them for update operations, when needed.  Then the work goes to the (I suspect rare) parties that need partial update - not to every server.  It complicates the simple case, rather than pushing the complexity to the rare case, violating the design principle "make simple things simple and make more complicated things possible".

Is anyone opposed to updating the OAuth Registration semantics to match the Connect registration semantics?  Is so, why?

                                                                Thanks,
                                                                -- Mike

---

From: John Bradley <[email-masked]>
Date: Fri, 4 Jan 2013 21:13:45 -0300

We did discuss this issue in the connect WG.

The decision was made to always completely replace.   That prevents unknown states if a update fails.   

I think the always replace everything rule is simpler, though admittedly more bandwidth is required.  However bandwidth is not a significant factor for this as far as I know.

John B.

On 2013-01-04, at 8:55 PM, Mike Jones <[email-masked]> wrote:

> The client_update operation in http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-03 does something different than the operation upon which it was based fromhttp://openid.net/specs/openid-connect-registration-1_0-13.html.  Specifically, while the OpenID Connect operation replaces all field values, the OAuth operation allows only selective fields to be replaced, designating fields to remain unchanged by specifying their value as the empty string (“”).
>  
> I'm personally not happy with the change to the semantics of client field inclusion.  Updating some but not all fields is a substantially more complicated operation than replacing all fields.  Is there some use case that motivates this?  I don't think it's a substantial burden on the registering party to remember all the field values from the initial registration and then selectively use them for update operations, when needed.  Then the work goes to the (I suspect rare) parties that need partial update - not to every server.  It complicates the simple case, rather than pushing the complexity to the rare case, violating the design principle “make simple things simple and make more complicated things possible”.
>  
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: "Richer, Justin P." <[email-masked]>
Date: Sat, 5 Jan 2013 19:36:31 +0000

Mike, John, thanks for the feedback. I hope and anticipate that this conversation will help improve both drafts.

I disagree with the assessment here that it makes things more complicated in the simple case. How? The way that DynReg is currently written, if the client simply POSTs back the entire set of information that it has about itself every time, which I anticipate the most simple clients will do, then it still behaves as expected. Doesn't it? There's nothing in the draft that REQUIRES an incomplete POST, it just ALLOWS it to happen and defines what to do when it does. Furthermore, it makes it *safer* if the client POSTs something that is incomplete from the *server's* perspective, since the semantics are now, explicitly, to leave alone any values that are left out. In other words, it's my view that this actually makes things far simpler for clients wanting to do simple things, and makes more complex things possible. This is especially in light of the requirement of the server to echo out the actual full state of the client during the transaction. Having implemented this myself, it's really not very complex from either side. The server is marginally more complex, but it leaves fewer cases undefined or "up to the server to decide".

Part of the motivation I had for changing this here was to cope with the cases where the server asserts things about the client that the client doesn't register about itself in the first place, and I wanted something that was simple and programmatic to implement from both sides. In other words, it's assuming that the *server* has the most complete picture of the client's state, not the *client*, which is the assumption made in OIDC and by Mike and John's comments below. Let's take this example as a concrete case (formatting and parameter names are notional and might be off, I'm typing from memory):

Client registers with params:

  client_name=Foo
  token_endpoint_auth_type=client_secret_basic

Server sends back to the client:
{
  client_name: Foo
  client_secret: super-secret-secret
  token_endpoint_auth_type: client_secret_basic
  scope: read open dennis
  registration_access_token: TOKEN
}

So the client never asked for scope restriction, but the server decided (however it wanted to, probably by a defaulting mechanism) to give the client three scopes. In the current OIDC spec, the client would never even know this happened because this information isn't ever echoed back (though this at least is changing). Even if it did know about this parameter, it didn't ask for anything in particular in that field, so it now has to keep around something that it doesn't really know what to do with. So with that in mind, the client decides to change its name and sends back all the parameters that it knows about:

  client_name=Bar
  token_endpoint_auth_type=client_secret_basic
  access_token=TOKEN

Now in the OIDC definition of the semantics, this tells the server to clear out the existing "scope" value, because it's not included in the request. But the server really shouldn't do that, should it? You could argue that because it's a server-defaulted parameter and that the server should know to treat it special. But then the server would have to track which fields are still in a "defaulted" state, or keep some kind of programming logic that says "a blank on an update actually means something else". Which fields does this apply to? Neither of those are "simple".

In the current definition of the DynReg spec, the client not only knows the fields and can do something about them if it wants to, it can also *safely* ignore them in responses. If the client sends back the same set above, dealing only in the parameters that it knows and cares about, the server now has an unambiguous message when the client omits the "scope" field.

With this behavior, though, we do need the equivalent of "set to null" in order to explicitly empty out the value of an existing field. I took the approach of using a blank value -- expressed in HTTP forms as an empty string. I'm open to other suggestions if there's a better/cleaner approach to this part of it, but this was the best I could come up with.

Finally, it's not a bandwidth issue at all, so let's just ignore that particular red herring. :)

 -- Justin

________________________________
From: [email-masked] [[email-masked]] on behalf of John Bradley [[email-masked]]
Sent: Friday, January 04, 2013 7:13 PM
To: Mike Jones
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Difference between client_update semantics in draft-ietf-oauth-dyn-reg and OpenID Connect Registration

John B.

On 2013-01-04, at 8:55 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:

                                                                Thanks,
                                                                -- Mike

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

---

From: "Richer, Justin P." <[email-masked]>
Date: Wed, 9 Jan 2013 20:05:28 +0000

It's been a few days now and I haven't seen any traffic from the group about this at all, so I'll just come out and ask for opinions. The two proposals are:

OIDC-style:
 - inclusion of field replaces that field value on the server with the new value
 - omission of field deletes that field value on the server

DynReg style:
 - inclusion of field replaces that field value on the server with the new value
 - omission of field tells the server to leave its current value alone
 - inclusion of field with an empty string value deletes/clears that field value from the server

Should the OAuth2 Dyn Reg spec adopt the OIDC semantics, or keep its current semantics? Why? Is there another option that's even better?

 -- Justin

On Jan 5, 2013, at 2:36 PM, "Richer, Justin P." <[email-masked]<mailto:[email-masked]>> wrote:

  client_name=Foo

  client_name=Bar

 -- Justin

________________________________
From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] on behalf of John Bradley [[email-masked]<mailto:[email-masked]>]
Sent: Friday, January 04, 2013 7:13 PM
To: Mike Jones
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Difference between client_update semantics in draft-ietf-oauth-dyn-reg and OpenID Connect Registration

John B.

                                                                Thanks,
                                                                -- Mike

---

From: Mike Jones <[email-masked]>
Date: Wed, 9 Jan 2013 20:07:58 +0000

Complete replacement is simpler to implement, and has fewer potential error cases to handle than partial update.  Keep it simple.

                                                                -- Mike

From: Richer, Justin P. [mailto:[email-masked]]
Sent: Wednesday, January 09, 2013 12:05 PM
To: John Bradley; Mike Jones
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Difference between client_update semantics in draft-ietf-oauth-dyn-reg and OpenID Connect Registration

OIDC-style:

DynReg style:

 -- Justin

  client_name=Foo

  client_name=Bar

 -- Justin

John B.

The client_update operation in http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-03 does something different than the operation upon which it was based fromhttp://openid.net/specs/openid-connect-registration-1_0-13.html.  Specifically, while the OpenID Connect operation replaces all field values, the OAuth operation allows only selective fields to be replaced, designating fields to remain unchanged by specifying their value as the empty string ("").

                                                                Thanks,
                                                                -- Mike

---

From: "Richer, Justin P." <[email-masked]>
Date: Wed, 9 Jan 2013 20:11:02 +0000

I prefer the DynReg style, as it keeps things simple for clients (still supports the replace-all mechanics) while making it safer for them. It's also explicit about how to handle server-asserted values that a dumb client might ignore. The partial-update is a small added bonus.

 -- Justin

On Jan 9, 2013, at 3:05 PM, Justin Richer <[email-masked]<mailto:[email-masked]>>
 wrote:

OIDC-style:

DynReg style:

 -- Justin

  client_name=Foo

  client_name=Bar

 -- Justin

John B.

                                                                Thanks,
                                                                -- Mike

---

From: "Richer, Justin P." <[email-masked]>
Date: Wed, 9 Jan 2013 20:12:02 +0000

This not true in my own personal implementation experience, which is where I came up with the DynReg style.

 -- Justin

On Jan 9, 2013, at 3:07 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:

                                                                -- Mike

From: Richer, Justin P. [mailto:[email-masked]<http://mitre.org>]

OIDC-style:

DynReg style:

 -- Justin

  client_name=Foo

  client_name=Bar

 -- Justin

John B.

                                                                Thanks,
                                                                -- Mike

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 10 Jan 2013 19:17:50 +0100

Hi all,

based on a conversion with one of our developers I would prefer the DynReg style.

regards,
Torsten.

Am 09.01.2013 um 21:05 schrieb "Richer, Justin P." <[email-masked]>:

> On Jan 5, 2013, at 2:36 PM, "Richer, Justin P." <[email-masked]> wrote:
>