Re: [scim] Filtering against Null Attribute Values

Shelley <> Tue, 22 September 2020 21:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E44B13A0B6F for <>; Tue, 22 Sep 2020 14:40:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 0aJRcfjhKb1k for <>; Tue, 22 Sep 2020 14:40:24 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::e2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 11E933A09B7 for <>; Tue, 22 Sep 2020 14:40:24 -0700 (PDT)
Received: by with SMTP id p24so6247586vsf.8 for <>; Tue, 22 Sep 2020 14:40:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RTJgzp8JOcM+nNFfaoV7gP/D9WG0lyolrQzvvQx9kw0=; b=BXSfP5oVRDZFIXMgIpZjSZkHkpOjcO1t3WA7TjnRpyxXUCRK/N9RTB4Hjk6PgVpWkg abXO1TGvvaMLLGony9FoSi1xF/yHRBneU/Q476ZLrOgVlS798V0eJjEPZnWGxXqDBEEh cL4QqtUNr9X7U+U+o4Zkog6BnFshbRQR2Tjedkpjsakxm7fEV5mgKX9K22EUnieyytIL 0jv6Sj15O402iOAvSRy/kT+/ioS9VrdLLoXdcMvdcRjQXE5/dgguBe3YHB19KXgghqct QHE52W9qZISbUnooUSKmXjJ//Mz1FnCy8tIj12q4UsKSkhV0j6GllvPuT0U0MxG6XOB7 AUDg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RTJgzp8JOcM+nNFfaoV7gP/D9WG0lyolrQzvvQx9kw0=; b=bSeM0RimtmUhhGdkAUQNOGU4GK0dIGV6syjbvwRAVpqrrY0riQ8/I4fcNQbXbwIET5 ZSfUKw3C3vtORuMIJ9IRfRov6Xxn+AsDnpeLb9FMvGJ7ihj6/5JmBecj5H2a+XKNqZoP TKwzcbeIaekp99FcWtQUBqoN54rRFNMfEy6ck1NQwmIkP2Cz7onipfoe5ImyaII6IgxX WFSY87LL34U6G+NfNn7+HSVxqWX9ZB/fKDZhB2ErCPVs9hbaF5OIbMVBqwnnpSXn0AVn GmzT/2HWoQDOi+ScCMREMf+6+lfOWsNv5Izf/wbkW2VbItIaNRgOkulSs6kyldskP2LW cosA==
X-Gm-Message-State: AOAM532P1nW5VRzcx9ZFIWtOuF2EMJwMxbsrinoRNtixRKqkolc5N7jJ BtQFyDsRmrlR8klTmeyuzGHcxxuyjCR+OmbNgOb7FwLygzAiJg==
X-Google-Smtp-Source: ABdhPJzxMtPap7RzS1+6EjgMi0daV8z7oBLR5AF67ohjbeCkzMpvUN3VX0suXTVi4MZ7mPuoQz3PqfHCKmXH193ChGE=
X-Received: by 2002:a67:69c7:: with SMTP id e190mr5210586vsc.15.1600810823071; Tue, 22 Sep 2020 14:40:23 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Shelley <>
Date: Tue, 22 Sep 2020 16:40:12 -0500
Message-ID: <>
To: Phil Hunt <>
Content-Type: multipart/alternative; boundary="000000000000763d5a05afedd0e8"
Archived-At: <>
Subject: Re: [scim] Filtering against Null Attribute Values
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: Tue, 22 Sep 2020 21:40:26 -0000

Thanks. I agree that the more qualified filter you provided is clearer; I'm
trying to determine how to properly handle various filters as a service

I can understand the less than/greater than comparison operators (lt, gt,
ge, le) evaluating to false for unspecified attributes since there is no
defined order, but would assume that other direct equality and negation can
still evaluate to true? For example:

1. Given that the aforementioned filters would both evaluate to false, for
users with an unspecified age, would all of the following then evaluate to

   - filter=not (age lt 18)
   - filter=not (age gt 18)
   - filter=age ne 18
   - filter=age eq null
   - filter=not (age pr)

2. Using another example, I assume that users without an "active" attribute
value specified would match the following filters?

   - active ne true
   - active ne false
   - not (active eq true)
   - not (active eq false)

3. Also, if there is no lexicographical ordering for undefined attributes,
would they be ordered first or last when sorting by that attribute?

Thanks again for the clarifications.

On Tue, Sep 22, 2020 at 3:12 PM Phil Hunt <>

> Shelley
> It is indirectly specified in the last paragraph of
>    For filtered attributes that are not part of a particular resource
>    type, the service provider SHALL treat the attribute as if there is
>    no attribute value.  For example, a presence or equality filter for
>    an undefined attribute evaluates to false.
> In your example below, both conditions would evaluate false as the value
> is undefined (and neither statement can not be said to lexicographically
> true) —> leading to a confusing situation where a resource is neither lt 18
> or ge 18. A more qualified filter might be:
> filter=age pr and age lt 18
> filter=age pr and age gt 18
> Phil Hunt
> @independentid
> On Sep 22, 2020, at 11:10 AM, Shelley <> wrote:
> Do the SCIM specifications prescribe any special behavior for filtering
> and sorting by attributes that are null/unspecified?
> For instance, given an optional user extension attribute for "age" and the
> following filters:
>    - filter=age lt 18
>    - filter=age gt 18
> Would either of these filters return a user resource with no specified
> age, such that nulls have a prescribed ordering? Or, would both of these
> filters exclude all users without specified ages? (And, if it's the latter,
> what effect is negation intended to have on the filter?)
> This question applies to filters, matching resources during PATCH,
> sorting, and other attribute operators as well (e.g. would not
> (displayName co "test") match users without display names?).
> Thanks in advance for any clarifications!
> _______________________________________________
> scim mailing list