Re: [scim] how to describe SCIM extensions in the modern world

[Phillip Hunt <[e-mail]>]

Sorry if this is a bit rambly. I am having my morning coffee. This would definitely be a good conversation over beers. 

I would say scim is more like a database system where resources are served through a common api. The types of resources and their attributes discoverable at service provider endpoints (schemas and resource types). 

While many implement scim with fixed classes for each endpoint, some providers implement like a database (eg i2scim.io) and can serve any resource object through the common api simply by updating schema configuration and taking advantage of nosql and json friendly databases. H

One other thing scim does the others do not is inform clients about mutability. Is an attribute readonly, write only,  immutable, updatable etc. 

JsonSchema and openapi introduce tightly bound structures and even rules for one time use. The goal here is to generate code quickly over the cost of flexibility.  I have to admit this is not really a problem any more given continuous integration and iterative development. 

One issue with JsonSchema seems to be that the spec forked. I found this frustrating trying to describe scim in it as both had needed pieces. 🙄

Phil

On Jan 25, 2023, at 7:24 AM, Brian Demers <[e-mail]> wrote:



IMHO, I think there should be an _official_ set of reference schema (as defined in rfc7643) and an OpenAPI definition.

There is some overlap here, but I think they serve slightly different purposes.

The schema allows for a developer reference and for things that are not defined (or easily defined) in an OpenAPI definition (case sensitivity, uniqueness, returned, etc)

The OpenAPI spec may facilitate generating a basic client, a stub server, basic tests, or debugging (using an OpenAPI UI or something like Postman)

On the implementation side of things, I'm guessing all of the OpenAPI models could be translated from the schema (though extensions and canonical types might get a little tricky)

On Wed, Jan 25, 2023 at 9:36 AM Eliot Lear <[e-mail]> wrote:

Hi everyone,

Last year I said that we were looking for the best way to describe SCIM extensions.  Realistically the world is going in one of three directions:

• JSON Schema;
  
• OpenAPI; and
• AsyncAPI

JSON Schema presents some challenges for Internet-Drafts in that it doesn't fold well.  Not that this should be the key design decision, but it is annoying.

OpenAPI and AsyncAPI each borrow from JSON Schema.  OpenAPI directly maps to a RESTful interface while AsyncAPI can map to Other Things like MQTT.  But it too seems to be able to map to RESTful.

Do people have thoughts about this?

Eliot

_______________________________________________
scim mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/scim" rel="noreferrer nofollow" target="_blank">https://www.ietf.org/mailman/listinfo/scim

_______________________________________________
scim mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/scim