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

Filip Skokan <panva.ip@gmail.com> Wed, 04 March 2020 18:21 UTC

Return-Path: <panva.ip@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 384573A141C for <oauth@ietfa.amsl.com>; Wed, 4 Mar 2020 10:21:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUP-BdhszAjS for <oauth@ietfa.amsl.com>; Wed, 4 Mar 2020 10:21:30 -0800 (PST)
Received: from mail-yw1-xc2d.google.com (mail-yw1-xc2d.google.com [IPv6:2607:f8b0:4864:20::c2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 175773A1418 for <oauth@ietf.org>; Wed, 4 Mar 2020 10:21:30 -0800 (PST)
Received: by mail-yw1-xc2d.google.com with SMTP id 10so2927611ywv.5 for <oauth@ietf.org>; Wed, 04 Mar 2020 10:21:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3O8x3PsxDV0ybkkKJMZeJE5xZSOiouW43QlfDESq684=; b=IkDYVQaXV8bWL7vsPTzoFHFUp3y8MrJf10OOiDFOe5wHe7mfSQ8xG4M70o+eRv9JZu XugGQkHepFXzrnwkBKePjdVLTvJFIa7JLm+rnVUZUGe+8LrMzosP1uA4R2mVADtlgyqO iyiPMf93oy3J1D6AaHR+mC/2l3lONHhwEm6azrfG9MtyR8M0iKhGU2IXvIGIs0R2Z2zG qgFxnb4wx3KVjlhpEeKJTZsfhSc3HGpdU977Fk+0yI96hBYXK6gn8gdKEjJvKBlcHHhW qUbRa81D73uFjDYZvApeFHP3NIRVDdl6QxGIiZ4h4TshR9hIuTFVZwSzdZJst8RaI8dA d5fw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3O8x3PsxDV0ybkkKJMZeJE5xZSOiouW43QlfDESq684=; b=GF74mzSRGI6AVBMD4SCPW/s2uqTMuP0cUWbJGKH2pdIW9WcYqO28MJoMLH6Vdg02Vq oir3iBKqfR8q43jqHtpN/TIc5kAREdZPFUY9G1wKvajmF2NUADdyCJbJwRLxvSNr0+3j LSDWMF6um+DekkPkjG+25FkboCnboPiD6KQr9rHkIbrF4sJ/c/qvHMtmodLKSl08P73u 3WSrcsWYw3GY1jO+oUQ1vGGxomcbNSzd6ISRyrEe1gCV0MAuu/k0RZpSa0y/4eU432RD P1iMkjX7yE0l0jxLVPbNBE7odeJ9OxfUXx19VU93Y4MoUhIKWJmatdMNTMyb642ceJqw r+0g==
X-Gm-Message-State: ANhLgQ0xdqkVEvipMXpm5UOP9/z2H4CHFaAcR3aP5KTBVYQ0dysCugv+ WjztN2qpGYknKWj6s8wgXmGW6yP7dbF1vQDbLA==
X-Google-Smtp-Source: ADFU+vvKVT9aOuISE5DPlP1KylDc1LfBbkfF54VH/g0+Q0RCBFtf1NQ4EIfR7QRykaGFVFwyL4DnMrULK4n+v0nPhu0=
X-Received: by 2002:a5b:f48:: with SMTP id y8mr3468022ybr.427.1583346088779; Wed, 04 Mar 2020 10:21:28 -0800 (PST)
MIME-Version: 1.0
References: <CALAqi_8r8h7+t+c2uDdaVzqCNxh33DS65Edo9ea3vQgm+dVEFA@mail.gmail.com> <84FE0330-B7E3-459A-A8A0-32058FAC4B98@mit.edu> <CALAqi_91Xv4QrZsQrU_YY=AKW8H_jX2Kax8gZ0QCxzDGX4DBzg@mail.gmail.com> <E03B5E8E-9EFA-46E2-9A57-BF5C6F3C4AE4@mit.edu>
In-Reply-To: <E03B5E8E-9EFA-46E2-9A57-BF5C6F3C4AE4@mit.edu>
From: Filip Skokan <panva.ip@gmail.com>
Date: Wed, 04 Mar 2020 19:20:52 +0100
Message-ID: <CALAqi_8yQyvSM0dmLHx7fhGMHVE2-29e=8VaCudbK0OMoR3ruw@mail.gmail.com>
To: Justin Richer <jricher@mit.edu>
Cc: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002da9a305a00b7da3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/D9mvix-MzrN-3Y_JikQAWfcwpEA>
Subject: Re: [OAUTH-WG] RFC 7592 - Client Update Request omitted fields
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Mar 2020 18:21:37 -0000

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 <jricher@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.ip@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 <jricher@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.ip@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
>>
>>
>>
>