You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 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: 

  1. Maximum freedom in defining TIER-specific APIs and schema
  2. SCIM compliance for simple API calls can be achieved by proper configuration of the parties.
  3. Minimal development effort is required to provide simple SCIM responses

Cons:

  1. Less SCIM compliance overall than other proposals on the table
  2. 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:

  1. Absolute maximum SCIM compatibility
  2. The base set of API standards and schema for TIER is fully defined by the SCIM RFCs 7642, 7643 and 7644.
  3. Since TIER-specific resources will have their own identifiers and schema, there is no need to prefix attribute names with 'tier' or anything else. 

Cons:

  1. 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.
  2. 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:

  1. Can be accomplished in full conformance with SCIM using SCIM-defined procedures for defining new Resource Types and their core schema.
  2. Freedom to define our own schema without having to prefix attribute names
  3. Avoids use of the choppy SCIM schema extension mechanism for Users and Groups (SCIM mandates all core attributes together followed by SCIM extensions followed by TIER extensions).

Cons:

  1. TIER User and Group Resource Types would have "Tier" at the front while other resource type names would not (or would they?)
  • No labels