Re: [scim] PATCH Multi-Valued Attribute Value Type

Shelley <randomshelley@gmail.com> Thu, 01 October 2020 13:29 UTC

Return-Path: <randomshelley@gmail.com>
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 292873A1052 for <scim@ietfa.amsl.com>; Thu, 1 Oct 2020 06:29:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, URIBL_BLOCKED=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 oeRklWdlUEMU for <scim@ietfa.amsl.com>; Thu, 1 Oct 2020 06:29:49 -0700 (PDT)
Received: from mail-vs1-xe42.google.com (mail-vs1-xe42.google.com [IPv6:2607:f8b0:4864:20::e42]) (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 2F2BF3A0967 for <scim@ietf.org>; Thu, 1 Oct 2020 06:29:49 -0700 (PDT)
Received: by mail-vs1-xe42.google.com with SMTP id 7so2563608vsp.6 for <scim@ietf.org>; Thu, 01 Oct 2020 06:29:49 -0700 (PDT)
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; bh=xHMw5RvjcgtNBixP01G1A0QeekE1y2aebls9L16JWwY=; b=n72m6SNRWMmVZC9Vhc64Mzsp8LNrlMWiiXY02uwAc1p4oQxQiKWwLHVRkv8/svEkU1 QQcxuhPO93UpjVzHVVwBIqesRwl2SnSDgDlSIBIR5xaKSJEmmmLMNQx7w6zSrzDxCF54 5Km8TMB02C9CU1KIaS8sARSE7AYqt1Uql0fcTKJPoXzzzXMFA2jHKtw6aa6767tzB1UR ihCPi3fSbBBgMHO/KiQF+I2qeQ8k8RPkuO3RiZ9YeZ4MzY2mVhEJ2UXTs8L5hZhLBJDH T72reXIQzE576F1rPgaahmBCHlBgVNpsKUJpFBgZJvZBV2SQOLWF4FBkomATBgJn7S5U t0MQ==
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; bh=xHMw5RvjcgtNBixP01G1A0QeekE1y2aebls9L16JWwY=; b=V9NJeko8RbCIRCzW3BRYraxaUn7kthAzvGtZnI8BP5WXdtATxRXeGVnptU7KC3XDwN 7tmzV3sjkhO6sNkmAOnmfw7JQ7oHdd4lcRkyEQ/a0DCpjUHB/8hcWZ0Zm67P8HgFbSse UD9fZ/J/T14tsxDZZLHfdK/y/oKD+Hb9Fb4I7GiYBm5tJVr6DkSuuH99mQiZYrA3Fyup gKPtb5egjd5dpAOuKTCFB0LvCcPFNWrNgp50mCSdtgABJzpOrnnBnefU9mVEHOWc+7YF qsXBPHbNtkUtI8/iZVmUZl9JwxMIsqb6Dxx/oz6WLMIWmj2NEFL/GRbzZU11DQsRHeYh bdQw==
X-Gm-Message-State: AOAM533RrOiK5x2i8Yi3GE6VyuyMb1Td1T0qdlcosdb4+3f9+5X0vdA6 3WoNCwOQ5El8iUjU6E+EeKh/PxmkE2ZpWELVnRBUwohC7LL+Mw==
X-Google-Smtp-Source: ABdhPJzEuDQzgS20xFS4MmbqqfxAuZbOQnNUQtF2ZY9iW8s4bbXS/8MEu6QGEc8QWafYYSWEgHdAKGhz9b257lc30nI=
X-Received: by 2002:a67:e981:: with SMTP id b1mr4998620vso.43.1601558988247; Thu, 01 Oct 2020 06:29:48 -0700 (PDT)
MIME-Version: 1.0
References: <89C877BA-9DF9-44A1-A1A9-5719D3665B76@amazon.com> <EA91DB7E-985F-47F2-BD44-A71FF911775A@independentid.com>
In-Reply-To: <EA91DB7E-985F-47F2-BD44-A71FF911775A@independentid.com>
From: Shelley <randomshelley@gmail.com>
Date: Thu, 01 Oct 2020 08:29:36 -0500
Message-ID: <CAGUsYPyQQWNyC330Ek=5=Qrb_7F5GZakg1Dw0O88+0ZkAZ2WCA@mail.gmail.com>
To: Phillip Hunt <phil.hunt@independentid.com>, "McAdams, Darin" <darinm=40amazon.com@dmarc.ietf.org>, "scim@ietf.org" <scim@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000094d9ce05b09c02c0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/scim/Hqz_MfQiAkjnbvRy-M-e8hgmy6Q>
Subject: Re: [scim] PATCH Multi-Valued Attribute Value Type
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Simple Cloud Identity Management BOF <scim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/scim>, <mailto:scim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/scim/>
List-Post: <mailto:scim@ietf.org>
List-Help: <mailto:scim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/scim>, <mailto:scim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Oct 2020 13:29:51 -0000

Thanks for the clarification.

Should the "add" descriptions [1] be corrected to account for arrays and
other literals being provided? Current text:

>    The value MAY be a quoted value, or it may be a JSON object containing the sub-attributes of the complex attribute specified in the operation's "path".
>
> Should it instead be something more like the following?

>    The value MUST contain a value with the data type of the attribute specified in the operation's "path".
>
> (And, similar clarifications for "replace" would be useful, too, with the
additional clarification that CMVA value paths must replace with only a
single element value, and may not provide an array.)

[1] https://tools.ietf.org/html/rfc7644#section-3.5.2.1


On Wed, Sep 30, 2020 at 8:25 PM Phillip Hunt <phil.hunt@independentid.com>
wrote:

> If the path is a simple attribute than the patch value is the actual
> simple assignment.
>
> If the path is a complex attribute than Patch value is the set of
> attributes that constitute a value.
>
> CMVA then follows that value is an array unless a [value path filter] was
> specified.
>
> The idea is that path can be either fine-grained or point to a whole
> object much like in the json patch spec. The big difference is scim uses a
> filter for multivalue arrays over indexing.  Thus value of “value” depends
> on what path points to.
>
> Phil
>
> On Sep 30, 2020, at 3:39 PM, McAdams, Darin <darinm=
> 40amazon.com@dmarc.ietf.org> wrote:
>
> 
>
> I’m curious as well. We are proposing a SCIM interop profile in FastFed
> and now I’m hoping we got it right!
>
> https://openid.net/specs/fastfed-scim-1_0-02.html#rfc.section.4.3.7
>
>
>
> *From: *scim <scim-bounces@ietf.org> on behalf of Shelley <
> randomshelley@gmail.com>
> *Date: *Wednesday, September 30, 2020 at 2:23 PM
> *To: *"scim@ietf.org" <scim@ietf.org>
> *Subject: *[EXTERNAL] [scim] PATCH Multi-Valued Attribute Value Type
>
>
>
> For "add" and "replace" PATCH operations that specify multi-valued
> attributes, is the content of the "*value*" attribute supposed to be an *array
> *containing the new/replaced element(s) or a single *JSON object *
> containing the new/replaced element? The RFC seems to contain examples for
> both, and I would like to better understand the difference.
>
>
>
> *Add Operation "Value" Type for Multi-Valued Attributes*
>
> There is an "*add*" example on page 37 which specifies an *array *for a
> multi-valued attribute:
>
> {
>   "op": "add",
>   "path": "members",
>   "value": *[*{
>     "display": "Babs Jensen",
>     "$ref": "https://example.com/v2/Users/2819c223...413861904646",
>     "value": "2819c223-7f76-453a-919d-413861904646"
>   }*]*
> }
>
>
>
> The description of "add", however, indicates that it contains "*a "value"
> member whose content specifies the value to be added.*" In the case of
> "add", the value being added is the individual element, not an array.
>
>
>
> Also, the "add" description indicates that the "*value MAY be a quoted
> value, or it may be a JSON object containing the sub-attributes*" but
> does *not *seem to allow arrays (nor JSON literals, such as booleans or
> numbers, which is a separate question...).
>
>
>
> *Is the description or the example incorrect? Should the operation "value"
> here be a JSON object or an array?*
>
>
>
> *Replace Operation "Value" Type for Multi-Valued Attributes *
>
> For "*replace*", there is an example on page 44 that specifies an *array *for
> the "value" of a multi-valued attribute:
>
> {
>   "op": "replace",
>   "path": "members",
>   "value": *[*{
>       "display": "Babs Jensen",
>       "$ref": "https://example.com/v2/Users/2819c223...413861904646",
>       "value": "2819c223...413861904646"
>     },
>     {
>       "display": "James Smith",
>       "$ref": "https://example.com/v2/Users/08e1d05d...473d93df9210",
>       "value": "08e1d05d...473d93df9210"
>     }
>   *]*
> }
>
> However, there is also a "*replace*" example on page 45 that specifies an *object
> *(not an array) for the "value" of a multi-valued attribute:
>
> {
>   "op": "replace",
>   "path": "addresses[type eq \"work\"]",
>   "value": *{*
>     "type": "work",
>     "streetAddress": "911 Universal City Plaza",
>     "locality": "Hollywood",
>     "region": "CA",
>     "postalCode": "91608",
>     "country": "US",
>     "formatted": "911 Universal City Plaza\nHollywood, CA 91608 US",
>     "primary": true
>   *}*
> }
>
>
> The use of the array for "replace" on "members" seems appropriate since it
> is replacing the entire attribute with one or more values. For the
> "addresses" value path, it's a little less clear to me. The use of an
> object seems to imply that even if multiple addresses are matched by the
> filter, only one new element may be specified to take it's/their place. Can
> someone provide clarification on when to use *array vs. object *here?
>
>
>
> Thank you!
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim
>
>