Alternative Proposals on the Relationship Between TIER and SCIM APIs and Schema

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. Simple SCIM responses will be enough to meet the majority of real-world SCIM use cases.

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. Don't rely solely on SCIM User and Group Resource Types, but define and use new SCIM-compliant Resource Types, TierGroup and TierUser. 

Pros:

1. Full SCIM compliance: Can be accomplished in conformance with SCIM RFCs using SCIM-defined procedures for defining new Resource Types and their core schema.
2. Freedom to define our own resource types and schema without having to prefix each attribute name with 'tier'
3. 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:

1. TIER User and Group Resource Types would have "Tier" in their names while other resource type names would not (or would they?)
2. To support SCIM User and Group objects, TIER would need to provide an automated mapping between the TierUser and TierGroup schema and the corresponding SCIM schema.