Subject: [OAUTH-WG] RFC 7592 - Client Update Request omitted fields

From: Filip Skokan <[email-masked]>
Date: Tue, 3 Mar 2020 14:42:45 +0100

Hello everyone,

Section 2.2 of RFC 7592 <https://tools.ietf.org/html/rfc7592#section-2.2>
(Dynamic Client Registration Management Protocol) has the following two
statements that oppose one another.

This request MUST include all client metadata fields as returned to the
> client from a previous registration, read, or update operation.

Omitted fields MUST be treated as null or empty values by the server,
> indicating the client's request to delete them from the client's
> registration.

What's the intention here? Should a server be accepting requests that are
missing client properties it has either on the record or "resolved" or not?

Personally I like to always make sure the client submits everything and to
remove properties it must pass null or empty string as the values. That way
the request is 100% intentional about the final state of the record it
wants to update to.

What do you think?

Best,
*Filip*

---

From: Justin Richer <[email-masked]>
Date: Wed, 4 Mar 2020 10:36:57 -0500

Your interpretation was our intent with that. It’s a full replace of the object. We had debating having PATCH style semantics, but ultimately decided that that was too complex for the most common update actions that a client would have.

 — Justin

> On Mar 3, 2020, at 8:42 AM, Filip Skokan <[email-masked]> wrote:
> 
> Hello everyone,
> 
> Section 2.2 of RFC 7592 <https://tools.ietf.org/html/rfc7592#section-2.2> (Dynamic Client Registration Management Protocol) has the following two statements that oppose one another.
> 
> This request MUST include all client metadata fields as returned to the client from a previous registration, read, or update operation.
> 
> Omitted fields MUST be treated as null or empty values by the server, indicating the client's request to delete them from the client's registration.
> 
> What's the intention here? Should a server be accepting requests that are missing client properties it has either on the record or "resolved" or not?
> 
> Personally I like to always make sure the client submits everything and to remove properties it must pass null or empty string as the values. That way the request is 100% intentional about the final state of the record it wants to update to.
> 
> What do you think?
> 
> Best,
> Filip
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Filip Skokan <[email-masked]>
Date: Wed, 4 Mar 2020 16:42:13 +0100

So the following

> indicating the client's request to delete them from the client's

Does not mean the server needs to accept requests where fields are omitted?
Is that a left over from previous drafts then?

S pozdravem,
*Filip Skokan*

On Wed, 4 Mar 2020 at 16:37, Justin Richer <[email-masked]> wrote:

> Your interpretation was our intent with that. It’s a full replace of the
> object. We had debating having PATCH style semantics, but ultimately
> decided that that was too complex for the most common update actions that a
> client would have.
>
>  — Justin
>

---

From: Justin Richer <[email-masked]>
Date: Wed, 4 Mar 2020 11:35:11 -0500

I’m not sure what you’re asking — the text is not left over from anything and is intentionally included. That text is saying that if I leave out the field then the server treats it just like as if I had sent in a null value. So the following are equivalent:

{
  “client_name”: “foo”,
  “tos_uri”: null
}

And 

{
  “client_name”: “foo”,
}

In both cases, it’s a signal that the client is removing the value from the “tos_uri” field. It does not mean that the AS leaves the “tos_uri” field with the value that it previously was (ie, a PATCH style request). 

The AS can reject the update request if it doesn’t want to allow the client to blank out that field, for whatever reason. 

 — Justin

> On Mar 4, 2020, at 10:42 AM, Filip Skokan <[email-masked]> wrote:
> 
> So the following
> 
> Does not mean the server needs to accept requests where fields are omitted? Is that a left over from previous drafts then?
> 
> S pozdravem,
> Filip Skokan
> 
> 
> On Wed, 4 Mar 2020 at 16:37, Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>> On Mar 3, 2020, at 8:42 AM, Filip Skokan <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hello everyone,
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>

---

From: Filip Skokan <[email-masked]>
Date: Wed, 4 Mar 2020 17:36:15 +0100

Got it, thanks!

Best,
Filip

On Wed, 4 Mar 2020 at 17:35, Justin Richer <[email-masked]> wrote:

> I’m not sure what you’re asking — the text is not left over from anything
> and is intentionally included. That text is saying that if I leave out the
> field then the server treats it just like as if I had sent in a null value.
> So the following are equivalent:
>
> {
>   “client_name”: “foo”,
>   “tos_uri”: null
> }
>
> And
>
> {
>   “client_name”: “foo”,
> }
>
>
> In both cases, it’s a signal that the client is removing the value from
> the “tos_uri” field. It does not mean that the AS leaves the “tos_uri”
> field with the value that it previously was (ie, a PATCH style request).
>
> The AS can reject the update request if it doesn’t want to allow the
> client to blank out that field, for whatever reason.
>
>  — Justin
>
>
> Does not mean the server needs to accept requests where fields are
> omitted? Is that a left over from previous drafts then?
>
> S pozdravem,
> *Filip Skokan*
>
>
>> Personally I like to always make sure the client submits everything and
>> to remove properties it must pass null or empty string as the values. That
>> way the request is 100% intentional about the final state of the record it
>> wants to update to.
>>
>> What do you think?
>>
>> Best,
>> *Filip*

---

From: Filip Skokan <[email-masked]>
Date: Wed, 4 Mar 2020 19:20:52 +0100

I guess what i meant to call out is that while you and the spec says how
omitted fields should be handled, but in the same section earlier it states
that all fields must be included.

S pozdravem,
*Filip Skokan*

---

From: Justin Richer <[email-masked]>
Date: Wed, 4 Mar 2020 16:41:38 -0500

I can see the confusion in interpreting these requirements together. However, this is giving a specific semantics to omitted fields such that they’re treated as included in a specific way — with a null value. The intent of “include everything” is that you don’t leave out values and expect them to not change. Instead we define explicitly what happens when you leave out values — they get deleted, effectively. 

 — Justin

> On Mar 4, 2020, at 1:20 PM, Filip Skokan <[email-masked]> wrote:
> 
> I guess what i meant to call out is that while you and the spec says how omitted fields should be handled, but in the same section earlier it states that all fields must be included.
> 
> S pozdravem,
> Filip Skokan
> 
> 
> On Wed, 4 Mar 2020 at 17:35, Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>> On Mar 4, 2020, at 10:42 AM, Filip Skokan <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> So the following
>>