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

Hi Elliot, Muhammed, Hassan,

Thanks for submitting this. Great to see!

Sorry for the long explanation that follows, I am hoping the wider SCIM audience will also find this useful in the SCIM”bis” discussions.

RFC7643 does in fact describe a more informal language that SCIM understands.  Its main objective was:  avoiding naming collisions, and to standardize common attributes and typing. Structure was kept to a minimum. eg. extensions to existing resoruces are placed in their own JSON attribute object (see Enterprise User example in 7643).

At the time schema for JSON was a controversial subject for those seeking shelter from XML. Ahh the joys of consensus process. Still I wish we had the option of JSON Schema back then!  :)

A couple of improvements that may be helpful:

1.  ResourceType definition.  This tells clients what the endpoints are for your resources and what the primary and allowable extension schemas are. For example take a look at RFC7643 Section 6 and an exampleJSON representation can be found in Section 8.6.  When clients query the ResourceTypes endpoint of the server, this is what tells them the device model schema is available.

2.  In 1, I think you are trying to extablish a new resource type.  “extension” typically means extending another schema.  For example the enterprise:User is an extension of the normal User. 

You may want to change your URN from urn:ietf:params:scim:schemas:extension:Endpoints:2.0:Device to urn:ietf:params:scim:schemas:Endpoints:2.0:Device. Note: the number 2 in the core schema was really meant to imply SCIM 2. You can keep that convention, but you don’t have to (as object schema can revise independently of protocol version).

In the case of the User resource type, calling
HTTP GET /ResourceTypes/Users
returns:
{
     "schemas": ["urn:ietf:params:scim:schemas:core:2.0:ResourceType"],
     "id": "User",
     "name": "User",
     "endpoint": "/Users",
     "description": "User Account",
     "schema": "urn:ietf:params:scim:schemas:core:2.0:User",
     "schemaExtensions": [
       {
         "schema":
           "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User",
         "required": true
       }
     ],
     "meta": {
       "location": "https://example.com/v2/ResourceTypes/User",
       "resourceType": "ResourceType"
     }
 }

This shows the primary schema is urn:ietf:params:scim:schemas:core:2.0:User for the endpoint “/Users" and in this server the extension schema "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User” is required (it could be false).  In practice most implementations ignore this.

3.  SCIM Schema declaration - Section 8.6 shows examples of SCIM Schema for the SCIM Resources. This schema declaration is worth doing as this is what the /Schemas endpoint returns when a client wants to discover what urn:ietf:params:scim:schemas:extension:Endpoints:2.0:Device is for example. For example 

GET /ResourceTypes/Devices
GET /Schemas/urn:ietf:params:scim:schemas:extension:Endpoints:2.0:Device

Note: I have written a JSON Schema definition for SCIM’s core and protocol and it is available in github at: https://github.com/i2-open/i2scim/tree/master/spec/schema

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.  

Phillip Hunt
@independentid
phil.hunt@independentid.com

> On Oct 26, 2022, at 5:59 AM, Salvatore DAgostino <sal@idmachines.com> wrote:
> 
> Thanks for this.
>  
> I work with certifying ISO/IEC 60835-11-5 devices which is for physical access control units and peripheral devices that often include QR and BLE readers. In many cases these use serial communications to communicate between the networked (IP) ACU and the PD to implement the settings, commands, and responses to the standard. Always interested in how we bridge SCIM to the physical access control world and does this provide a way forward.
>  
> There are companies that use SCIM for driving the attributes of the access group in these physical access use cases already, and I am very interested in how they might react to this .
>  
> Kind regards,
> Sal
>  
> From: scim <scim-bounces@ietf.org> On Behalf Of Eliot Lear
> Sent: Wednesday, October 26, 2022 1:49 AM
> To: scim@ietf.org
> Cc: hiqbal@ncsu.edu; Muhammed Shahzad <mshahza@ncsu.edu>
> Subject: [scim] draft-shahzad-scim-device-model-00
>  
> Hello SCIM folk,
> 
> On behalf of Muhammed Shahzad, Hassan Iqbar, and myself, I would like to bring to your attention the first try at a device schema for SCIM.[1]  A few things to point out:
> 
> There are actually several schema in this draft.  The first is a base device schema.  The others are extensions for additional functionality.
> The intent of this schema is to demonstrate how one can provision devices that make use of different L2 technologies, some even without IP capabilities, with different bootstrapping methods.
> We've made use of JSON schema to present the work.  This has posed us one particular challenge that we have yet to clean up: line length limitations in drafts.
> We'd ask the chairs for some time to present and discuss in London.  I expect we'll need to refactor here and there, but we'd like input on the core concept, as well as the objects themselves.  A Github repository is available at https://github.com/iot-onboarding/scim-devices <https://github.com/iot-onboarding/scim-devices>.
> 
> Thanks!
> 
> Eliot
> 
> [1] https://datatracker.ietf.org/doc/html/draft-shahzad-scim-device-model <https://datatracker.ietf.org/doc/html/draft-shahzad-scim-device-model>_______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim