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

Brian Demers <> Thu, 27 October 2022 06:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BBE52C1527A0 for <>; Wed, 26 Oct 2022 23:09:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Status: No, score=-2.105 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_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 Wggrdf1QkCcw for <>; Wed, 26 Oct 2022 23:09:44 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::535]) (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 E8408C1527A8 for <>; Wed, 26 Oct 2022 23:09:43 -0700 (PDT)
Received: by with SMTP id a5so971114edb.11 for <>; Wed, 26 Oct 2022 23:09:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=hs23fBGnvwmUHryfvdn/XvzTtt2fUQ8FOPF+nFn8GJo=; b=Sn4EVUzXHqVyTosz1Wbul9Ivb68AI1RY5OyhlTtVYyYNG6RWo8Y58DjJjp/aP+0Ggn Zo3kRvmYZM6PruLqHiXCSF4Vkfi+XzHsWJIh9mCUyfYe8Y4B5hKKY84uTcs1bnsQxo0S UzDsUHGP/XXpJ0WW154fIPZgr/jWhL1rMWCd2g3577RYv0XKYsN6IE4Jt2kdeI582E71 I+PL0b0hSwv13JdHmN4JdDbI/yln3Cb1FzleZUuODpT6mIU1xjk+PEGajmFD0hhLsU++ FLor7DatmGiuTuVJKztz3tM2SUfhOoFWCD5V/qqJNDWDMKtCewZHwYkGKHR606XzmIdp N4jg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=hs23fBGnvwmUHryfvdn/XvzTtt2fUQ8FOPF+nFn8GJo=; b=DyZIuaAvcP6HK+NyvooxmGiCA7akvxfJmG0P7h6eqI+dud6t8hWdj29ksNXA7bqVQX ggAOPaOWch/2qKhFDJ0s99s3sz1bB+ao5fn5dFebt8m6sN5lnUpPQ7K8M4SxmJsECX8/ Tam3EZmQpeYWnB5ZDgi8EB1ZKOV+WtkHOLJVxUA/ve24u6yDzIS5X8dwh2dBr1wjSQLv J96meagXB8+6K5od6LIGMBH9r2X+dOuptxY8xOUtUwdnvgHk44Ehp3sdU5HvzAuB3MQv G+fpuniMzcvqJw6IDyShU2re4GJm2hQrNn6/UF2xY1YtX1eTa0ROdY7qeucYdfqnfVB9 hsbg==
X-Gm-Message-State: ACrzQf3xRSs89T/PfFxYfQ8Xq2lnyOcOMtdFBWQFu7FmCmIL94xtBsDU ADumxvz4ewDI/ErtSjeiLYq3W/7Ong3i0qj/pew=
X-Google-Smtp-Source: AMsMyM6PMrJFclpJJWSqJpb4Y6CHdEeMuWB1vN/fXpiqoNfW2XY1DIwtXejKb4NnP/gPscrkeuDxuEhijKyWNjhLHFY=
X-Received: by 2002:a05:6402:11cc:b0:462:76cd:1215 with SMTP id j12-20020a05640211cc00b0046276cd1215mr4446305edw.318.1666850982095; Wed, 26 Oct 2022 23:09:42 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Brian Demers <>
Date: Thu, 27 Oct 2022 08:09:30 +0200
Message-ID: <>
To: Eliot Lear <>
Cc: Phillip Hunt <>, Salvatore DAgostino <>,, Muhammed Shahzad <>, SCIM WG <>
Content-Type: multipart/alternative; boundary="000000000000ae6e0a05ebfdfc75"
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 06:09:47 -0000

Great stuff Eliot!

I know nothing of the Device space, please forgive my ignorance if my
suggestions conflict with other established patterns/models in this space.

>From a developer usability perspective, I think the schema could be tweaked
slightly to reduce its nesting and verbosity a bit, particularly in
SCIM_endpoint_extension_schema.json (though much of this is personal
opinion, so take it with a grain of salt)

The JSON path to a few of these properties could be reduced, for example,
the properties:

Contain extra levels of nesting that may require additional documentation
and more code for the developer. In some languages, you would need to do
extra null checks to traverse the object graph.

Sometimes this can be avoided by flattening out the objects, where the
above look something like:

The `deviceControlApps` is an array which means some level of nesting is
required, but the names could still be tweaked to reduce the verbosity; the
nested structure should already provide enough context for each level,
maybe something like:

So the pseudo code in a verbose language like Java could be reduced from
something like:

var deviceControl = device.getDeviceControl();
// check if deviceControl is null, throw error

List<DeviceControlApp> apps = deviceControl.getDeviceControlApps();

//iterate over apps, and get the URLs

To something like:

List<DeviceControlApp> apps = device.getControlApps();

//iterate over apps, and get the URLs

As far as the actual schema format, similar to what Phillip mentioned, they
probably should be defined in the SCIM schema format (not to be confused
with XML schema).

(unofficial copies of various schema)

On Thu, Oct 27, 2022 at 7:49 AM Eliot Lear <> wrote:

> 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.
> Eliot
> _______________________________________________
> scim mailing list