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 <jric...@mit.edu> 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
>
>
> On Mar 4, 2020, at 10:42 AM, Filip Skokan <panva...@gmail.com> wrote:
>
> So the following
>
> 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.
>
>
> 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 <jric...@mit.edu> 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
>>
>> On Mar 3, 2020, at 8:42 AM, Filip Skokan <panva...@gmail.com> 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
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
