Re: [scim] What if created and lastModified are not populated in the app?

Phillip Hunt <> Wed, 22 June 2022 20:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 54623C15AADA for <>; Wed, 22 Jun 2022 13:21:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 wGPIwGJu7o8f for <>; Wed, 22 Jun 2022 13:21:36 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::52a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 64DEBC15AAC4 for <>; Wed, 22 Jun 2022 13:21:36 -0700 (PDT)
Received: by with SMTP id 184so17094510pga.12 for <>; Wed, 22 Jun 2022 13:21:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=+mGLKdCQAoPfD3rug3b08rcSNA1A++RDijsKyFI31uo=; b=0IlXM+7GkNw6SgBxNt0xFAEY/Mby5yhLKrofac5dIUhITNQhn0CyMb9JIosXQZXBAh iu8ssArMXrPBhoO+9FPbVAfhRK8aXFLvbl0cnQOMX6Al/hGDUJZXl0m7SETGUEaD6mXo UyOyC9cecRwKJBZTxJjTiUD5r3RkSDI2XIpmTodzRLcT6rHxcDD5AffjUFFMooPnkmmf yAxEDqPpAJW8VcWUljLtIKAp2u3AY8wzfuevRg1PMuEa09JsytKHutIDyAMgY98rCfF4 c1iapRzgBAWAol2H3+isYM3YHlqz/rANKhSiP/F9kjE8Z2vnBa0Kp0+2ySoW9lS9I9pJ 06hw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=+mGLKdCQAoPfD3rug3b08rcSNA1A++RDijsKyFI31uo=; b=DNZMZyy8pKZUq9cclHFGv2atKD46spFuQ9osu0+mKODZ9+EuKtVfNivE+u5ogtZ2BI gjV/+BRBk6MucJtBz9ObIn6qT0fM852WbELsJ5OpgzieaLiahcJUiFAF1qGXmwhjsTGW 4PSzLJ68YzRCZqMRIB3SrH6TylypJJW5o69cOAcWID55oE5VwDcvmPRP2KYcQdCypAc9 cBkrKQ4d4k5vQbkggzDFiJqhXwPGEF1HaqoBxaVsl2jar1969Z1erlYK+UFydrW1BQh3 nsYKZEDL+LOdCVdwi8u9xkVE8FFHAc52Ps2o2emOcY8A3e3NUkYaDob922O1dR/zET7I 3G5A==
X-Gm-Message-State: AJIora8xr0WxOSytpRQURE8nLbBR/MWv/BQX20Yq3nRrPDLQ7jyQUVNH Qp74pQ6ug5dpx7dYwhG4Hqiyb0GAlLsLnQ==
X-Google-Smtp-Source: AGRyM1sebRmwp2B0znH/TUr07826bka60cvZUmbJnLMjDijBjNUknv8X6pavND8ZDFrp2CseFAj99w==
X-Received: by 2002:a63:8c0b:0:b0:40c:f5d5:343d with SMTP id m11-20020a638c0b000000b0040cf5d5343dmr4334383pgd.373.1655929295171; Wed, 22 Jun 2022 13:21:35 -0700 (PDT)
Received: from ( [2001:569:7316:ae00:30ae:5d23:372a:1370]) by with ESMTPSA id z8-20020a1709027e8800b0015e8d4eb1easm10369284pla.52.2022. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Jun 2022 13:21:34 -0700 (PDT)
From: Phillip Hunt <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_8B3A6DAD-1174-42C3-9D61-C772A25108E6"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
Date: Wed, 22 Jun 2022 13:21:32 -0700
In-Reply-To: <>
To: Pierre Ozoux <>
References: <> <> <>
X-Mailer: Apple Mail (2.3696.100.31)
Archived-At: <>
Subject: Re: [scim] What if created and lastModified are not populated in the app?
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Simple Cloud Identity Management BOF <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 22 Jun 2022 20:21:37 -0000


Technically RFC7643 is silent on whether meta attributes are required. It only stipulates format if provided.

Also, RFC7232 (HTTP Conditional Requests) Sec 3.3, 3.4 describes Pre-conditions which count on validators which SCIM (as profile of HTTP) supports but does not require (see etag in RFC7644).

If you simply don’t implement, you are kind of outside the typical implementation approach and some unanticipated effects may result. For example, I would be careful about how search filters or conditional requests are handled involving meta.created/meta.lastmodified.  You may end up returning too many or too few responses to some clients. 

As I mentioned, these fields are used by most clients for change detection.

If you intend your implementation to be generally inter-operable, I would find a way to map a date value that makes sense. E.g. it could be a mapped value based on the last time the underlying database tables were updated (e.g. a batch update).  IOW — every resource you return would have the same “batch” date.

That said, I would expect a lot of implementations to have unexpected results if no meta created or lastmodified dates are returned.  

Hope this helps.

Phillip Hunt

> On Jun 22, 2022, at 8:23 AM, Pierre Ozoux <> wrote:
> Hi, thanks for your answer!
> Actually are these fields required?
>  - created
>  - lastModified
> Reading rfc7643 it says that:
>       created  The "DateTime" that the resource was added to the service
>          provider.  This attribute MUST be a DateTime.
>       lastModified  The most recent DateTime that the details of this
>          resource were updated at the service provider.  If this
>          resource has never been modified since its initial creation,
>          the value MUST be the same as the value of "created".
> Thanks for your help and have a nice day!
> _______________________________________________
> scim mailing list