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

Compare with Current View Page History

« Previous Version 6 Next »

 

Proposal 1) 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 2) Don't reuse User and Group SCIM Resource Types, but define and use new Resource Types TierGroup and TierUser. Stick with "TIER is a superset of SCIM"

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 clunky SCIM schema extension mechanism for Users and Grouips

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