You are viewing an old version of this page. View the current version.
Compare with Current
View Page History
« Previous
Version 14
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. Simple SCIM responses will be enough to meet the majority of real-world SCIM use cases.
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)
SCIM APIs are a strict subset of TIER APIs. Rather than relying solely on SCIM User and Group Resource Types, TIER defines and uses new Resource Types: TierGroup and TierUser using SCIM-defined procedures.
Pros:
- Full SCIM compliance: Can be accomplished in 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" in their names while other resource type names would not (or would they?)
- To support SCIM User and Group objects, TIER would need to provide bi-directional, automated mapping between the TierUser and TierGroup schema and the corresponding SCIM schema.