You are viewing an old version of this page. View the current version.
Compare with Current
View Page History
« Previous
Version 8
Next »
Proposal 1) TIER APIs and Schema have some overlap with SCIM APIs and Schema. The development of TIER-defined API and Schema is not bound by SCIM specifications
Pros:
- Maximum freedom in defining TIER-specific APIs and schema
- SCIM compliance for simple API calls can be achieved by proper configuration of the parties.
- Minimal development effort is required to provide simple SCIM responses
Cons:
- 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) TIER APIs and Schema are a superset of SCIM APIs and Schema. All SCIM APIs and Schema are valid TIER APIs and Schema, but not all TIER APIs and Schema are SCIM APIs and Schema
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.
Proposal 3) 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:
- 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 while other resource type names would not (or would they?)