Re: [scim] draft-shahzad-scim-device-model-00

Eliot Lear <> Thu, 27 October 2022 05:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BE712C1527A7 for <>; Wed, 26 Oct 2022 22:48:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.897
X-Spam-Status: No, score=-0.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HxWDV6Tost6c for <>; Wed, 26 Oct 2022 22:48:48 -0700 (PDT)
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id F113EC1522CA for <>; Wed, 26 Oct 2022 22:48:47 -0700 (PDT)
Received: from [IPV6:2001:420:c0f8:1001::1d6] ([IPv6:2001:420:c0f8:1001:0:0:0:1d6]) (authenticated bits=0) by (8.15.2/8.15.2/Debian-18) with ESMTPSA id 29R5mcZU542567 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 27 Oct 2022 07:48:39 +0200
Authentication-Results:; dmarc=none (p=none dis=none)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=upstairs; t=1666849720; bh=mAdCqFlMnQCXEMGUGmXEhoVeU+JQ8uKh8zs6GOBql1E=; h=Date:To:Cc:References:From:Subject:In-Reply-To:From; b=NDyh9Z+1zhJsMkqLRFo8Lae1CN/Ox05eItm0MqAi8IwYG03kxDmturvmWZ6vv7cfi mCtM5jmBZk6q0LcMcaxDq11TadleFQgROwe6kEPTh5vIDK7RuIg9/luINlo4ysfzkk INck8EFiUQsfzNYzVl5vuO4Wxg7ffhLLkE/p7WW4=
Message-ID: <>
Date: Thu, 27 Oct 2022 07:48:36 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.4.0
Content-Language: en-US
To: Phillip Hunt <>, Salvatore DAgostino <>,, Muhammed Shahzad <>
Cc: SCIM WG <>
References: <> <> <>
From: Eliot Lear <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [scim] draft-shahzad-scim-device-model-00
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: Thu, 27 Oct 2022 05:48:52 -0000

Hi Phil,

Thanks so much for your feedback.  We'll have more detailed answers in 
due course, but I want to call out one point now:

On 26.10.22 20:12, Phillip Hunt wrote:
> Note: I have written a JSON Schema definition for SCIM’s core and 
> protocol and it is available in github at: 
> To the group at large, now that “schema” in JSON is no longer a dirty 
> word, I would think it might be interesting using JSON Schema at some 
> point in the future. The only issue at this stage, is that SCIM’s 
> discovery mechanism doesn’t use JSON Schema and would be a major 
> change.  Maintaining both formats would be a pain for implementers.
I wasn't explicit in my last message, but the draft is.  We're not doing 
XML.  If that's a problem for people, we should talk about it.  If 
someone else wants to convert what we end up with into XML Schema, I 
wouldn't object, but to me at least, it's like being forced to mow 
someone else's lawn.

What I do think important is that we formalize the schema in a 
description language (props to XML schema people for really having 
gotten that ball rolling long ago), and that the description language be 
a canonical form of the schema that can be validated. The Python JSON 
schema validator is actually a pleasure to use for at least simple stuff.

To this end, I'm very pleased to see your progress on Github.

But there are some problems with JSON Schema that, quite frankly, annoy 
the crap out of me, and as this is a -00 draft, we can make lots of 
changes.  One change we could make would be to move to OpenAPI YAML.  I 
won't claim to be an expert on either JSON Schema OR OpenAPI, but at 
least the latter allows comments and multiline descriptions.

We have a rough non-normalized version of the same schema in OpenAPI 
that can be found at

I think this is food for thought.