Re: [scim] PATCH "Add" Operation with Value Paths

Phillip Hunt <> Thu, 01 October 2020 18:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6F2753A0AAB for <>; Thu, 1 Oct 2020 11:29:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id v9UMq8-CtoY5 for <>; Thu, 1 Oct 2020 11:29:22 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B4C523A0AA4 for <>; Thu, 1 Oct 2020 11:29:22 -0700 (PDT)
Received: by with SMTP id 7so4669211pgm.11 for <>; Thu, 01 Oct 2020 11:29:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=j80WjPB2soDAZ0j6OTW4AqVZ/m3QiEfSifIcMLHAnI8=; b=JtBOgzipTv9q74nWklBD6Pvwx6GxRcEByMtmD+/bvqpYv9FX2kfzvNAY9eDgn2b6xD 5XFzPS9OOsONr+c6zW8IahApYJPddiXiw7vmjqdhWuKnTkHrLcgZcibu/1r0I/J2NmoJ BT58aG67zhQbpTLHDXyhzAA9z+pKph2y9fxipLut4iCeMmOeX/4/0O9S8A/SgWmyCUca t4KLUP62UmJkdo5vo59GOXVbg9t+g8WCDxwqzquhnEGQ+zBFmeGJ1vF3cZ+NRp1xtjJp P6qb6KcwR6xiPAtCkPRzEr7SZo+g90igWQ9TW1Um6KzZPLgP+iW369bXayhycmppXxlV hkTQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=j80WjPB2soDAZ0j6OTW4AqVZ/m3QiEfSifIcMLHAnI8=; b=B2mhfICWhQh342lJLPPvKDt8RWtKZ2m8daEcRud1/ApNpIb9W8HcJPn7jNPSs/mvFz 9gYh3fxxBzeaQf6i2OEOErw1/T+kiTZtLE8FQjh+xsHLgibgBRjXOvsH1SgisHQp6eKC kn5YvmYbOGWxYqbGSgR2pErkywIV6Dr5RGowoccUWEKvDSyi7QZriL7nsvvHuGIxgUI2 jvdRqBML5xP8jiTxIJjovC1zQVh5+aAj1lT6ElFORl1z3E1qeYOVeI8UtoLvOjNW8TTw w3Vb9ishRHZpLScGIiy0RgPqzrhzfB+eJBmURF10uV0rGdE69IiIu8fgIzitOZsNp6Wz 8GnQ==
X-Gm-Message-State: AOAM532OzjQddmCAnxR/YWgbTxCOXlMSr42xgDZx75yxQgZ/7J+MAffs yg3UELJqywBT6nKS5+iG6KTflqKV5xoXUwzt
X-Google-Smtp-Source: ABdhPJxLZwCxpIIimEYdRf3aCh/kVWIIhVTTA9iQrFNnDOqmj7fF4c8D2ryckM3SeDUghgBUAiGGBQ==
X-Received: by 2002:a62:7bc7:0:b029:138:9430:544e with SMTP id w190-20020a627bc70000b02901389430544emr8743700pfc.1.1601576961811; Thu, 01 Oct 2020 11:29:21 -0700 (PDT)
Received: from ?IPv6:2001:569:79bc:100:7ddc:cecb:f0cf:48fd? ( [2001:569:79bc:100:7ddc:cecb:f0cf:48fd]) by with ESMTPSA id o1sm193173pgi.41.2020. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Oct 2020 11:29:21 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-7C02EC71-C85A-44AD-BE20-A5C6910B8738"
Content-Transfer-Encoding: 7bit
From: Phillip Hunt <>
Mime-Version: 1.0 (1.0)
Date: Thu, 01 Oct 2020 11:29:20 -0700
Message-Id: <>
References: <>
In-Reply-To: <>
To: Shelley <>
X-Mailer: iPhone Mail (17H35)
Archived-At: <>
Subject: Re: [scim] PATCH "Add" Operation with Value Paths
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Simple Cloud Identity Management BOF <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 01 Oct 2020 18:29:24 -0000

Using add instead of replace would not be expected.  So an add with a valuepath filter to a mv attribute would not make sense.  An add of a sub-attribute using a valuepath filter would.  For many implementations you could expect a bad request response. 

As past editor I find it hard to agree it is necessary to document every unexpected behavior (There are 1000s). I caution the members of this list that scim receives significant criticism for *over* specification.  

Still for implementers, I always suggest using “robust” coding approach which means that if you feel you can clearly understand the request you are free to accept it.  Still, likewise clients should be prepared to accept bad request. 


> On Oct 1, 2020, at 10:51 AM, Shelley <> wrote:
> What is the expected behavior when an "add" operation provides a "path" containing a multi-valued attribute with a value filter?
> In this example, I suppose that any emails that meet the criteria should set/replace their "type" sub-attribute? (Although, I'm not sure why a consumer would choose "add" vs. "replace".)
> {
>     "op": "add",
>     "path": "emails[primary eq false].type",
>     "value": "other"
> }
> In this example, however, I'm not at all sure of the semantic meaning of the filter? Should this be unsupported (resulting in a failure), should the filter itself effectively be ignored (where the enclosed email element is just appended to the emails array as if the filter was not provided), or should this have some other behavior (e.g. some type of attribute merging for elements that match the filter)?
> {
>     "op": "add",
>     "path": "emails[primary eq false]",
>     "value": ...
> }
> _______________________________________________
> scim mailing list