Re: [scim] Where are arbitrary fields allowed in a SCIM resource?

Phillip Hunt <> Thu, 02 April 2020 19:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A38553A10E3 for <>; Thu, 2 Apr 2020 12:01:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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 elvPOy_eKGVq for <>; Thu, 2 Apr 2020 12:01:24 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::102e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9CEB13A1179 for <>; Thu, 2 Apr 2020 12:01:03 -0700 (PDT)
Received: by with SMTP id q16so111231pje.1 for <>; Thu, 02 Apr 2020 12:01:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=EGbEMi8M07tUpWuYlXVSoI+XcKR9IvwJ5GoQLNu4Pdc=; b=K5xFQXvMjUIHOwuaWzZbgxD1JKQmiieFneDMzgB2m6+cUvO6V5Fr+UrsBUXl4l99TJ 20pOcCsINLvYImP8UfbDN8nE9pLsLV2NImw03HPtAxGAnkL8MfJHBrZkgVuT91RhWCj7 PhRA9NXjymIl7kYXHwUTnQ1h/805YA73lDODPGdPKrPR71q4AzVS1AIVbqneAkvA0r7M TTvWo+t+8ou3oXFYx7QUwDh13B1HWLK6x91BzMI4tenZP2uyk8ZHAonIk15nAIYlqY1z TtfupyYdWeQgeiQmQjeWuM6aqsZ0ZcQeNdic2zgupbn4QYOaoGA7O/M1D7WYljoEwbCL 60Mg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=EGbEMi8M07tUpWuYlXVSoI+XcKR9IvwJ5GoQLNu4Pdc=; b=GTfuwr8RDNNjleC8a+oGaGvANOPd/JwF2aUQ/EHtdiX+V5vpHizHQgDti6ulhNPQtw StXERJIZMX5TW16DmG7VQ/W/fBvInEecibC/RuppI0rfJcTUv+r/338tqB59wQs4/+oW ZZ98GXoC531RpxwoZU/5sOLiQpBX7fLQMEOWbr8UAOFdfclgHr1cZR0o92n6MSWCyQ1r inQRgALXn+/cYTGkp2gh40u7cxQWXV+a0+1qrHztliE8nVUC1ksLsfnFFsL5VxDY8ZXf ZFCbJfCxvGC5U3GlzSUrI3jrxOmaJXuwhlGBlLebTbclPs+vtAR9YvLxctIPOwc53KS0 975Q==
X-Gm-Message-State: AGi0PuYGVYFfO0C0v7n0GpHSdXPKuGrrpQWYWaNcq0tIyxbYcIQ7aT30 vTFISB1IuArbbduXAQCoembZAY8I7Uw=
X-Google-Smtp-Source: APiQypJ9xeHHtTK668ryOvxbgI24lLkvLm9uZ4MxIgddXJ/qphGGrnvbWIx+/mh7M0loUKOheMYf+g==
X-Received: by 2002:a17:90a:23cc:: with SMTP id g70mr5449386pje.122.1585854062497; Thu, 02 Apr 2020 12:01:02 -0700 (PDT)
Received: from ( [2001:569:7a71:1d00:35a8:9797:5fd:6d7c]) by with ESMTPSA id f129sm4258821pfb.190.2020. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Apr 2020 12:01:01 -0700 (PDT)
From: Phillip Hunt <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_051DFE04-7A0B-495D-8215-43224705A34E"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Thu, 2 Apr 2020 12:01:00 -0700
In-Reply-To: <>
Cc: "" <>
To: "Moyer, Steven William" <>
References: <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [scim] Where are arbitrary fields allowed in a SCIM resource?
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, 02 Apr 2020 19:01:33 -0000


It is unfortunate, but extending sub-attributes of CMVAs is still on the grouops *wish* list and has not been addressed - its been challenging to get a new SCIM charter moving forward at the IETF.  Especially hard now with the current situation.

In practice, I suspect many just go ahead and modify the standardized objects and publish it to the schemas endpoint. In a “robust” design, you must expect that many clients or SPs may choose to ignore attributes and sub-attributes they do not care about. This kind of behaviour is throughout the spec such as with how attribute mutability is handled during a PUT operation.

With that said, there are many within IETF who are starting to argue against “robust" design.  We in the world of IDM often have to deal with schema impedance mis-matches all the time. If you ever worked on X.500 of LDAP, you know what I mean. Also, I find RESTful style’s lack of formalization opens up a number of edge cases for which SCIM has only scratched the surface. ROBUSTness (take what you understand and ignore the rest) seems to be the only pragmatic response to the informality of RESTful design. 

Hope this helps.


Phil Hunt

> On Apr 2, 2020, at 6:48 AM, Moyer, Steven William <> wrote:
> When SCIM resources are represented as JSON objects, the specification is pretty clear that arbitrary fields are allowed in the top-level JSON object but a question has come up related to arbitrary fields within complex objects.  We need additional information in the SCIM Address type and would rather embed the attributes than reference extension data.
> Thanks,  Steve
> _______________________________________________
> scim mailing list
> <>
> <>