...
- Less SCIM compliance overall than other proposals on the table
- Ongoing challenge to explain to developers and others where and how TIER diverges from SCIM
Proposal 2)
...
Pros:
- Absolute maximum SCIM compatibility
- The base set of API standards and schema for TIER is fully defined by the SCIM RFCs 7642, 7643 and 7644.
- Since TIER-specific Resource Types will have their own identifiers and schema, there is no need to prefix attribute names with 'tier' or anything else.
Cons:
- The SCIM extension mechanism means all attributes defined in an extension are collected into a complex schema element below all the SCIM-defined base schema attributes. If there are two extensions, there will be two collections of additional attributes. See lines 131 to 142 in the example of a SCIM User resource supplemented with a SCIM Enterprise User.
- Precludes modification of any attribute defined in a given SCIM 2,0 Resource Type. SCIM Resource Type identifiers (Users, Groups, etc.) are reserved names in TIER, and all attributes defined in a given SCIM Resource Type must share the same syntax and semantics when used in TIER.
...
TIER APIs and Schema are a superset of SCIM APIs and Schema. Don't rely on SCIM User and Group Resource Types, but define and use new SCIM-compliant Resource Types, TierGroup and TierUser.
Pros:
- Full SCIM compliance: Can be accomplished in full conformance with SCIM RFCs using SCIM-defined procedures for defining new Resource Types and their core schema.
- Freedom to define our own resource types and schema without having to prefix each attribute name with 'tier'
- Avoids use of the choppy SCIM schema extension mechanism for Users and Groups (SCIM mandates all core attributes together followed by sections of SCIM extensions and TIER extensions).
Cons:
- TIER User and Group Resource Types would have "Tier" at the front in their names while other resource type names would not (or would they?)