RFC 7643, "System for Cross-domain Identity Management: Core Schema", September 2015

Note: This RFC has been updated by RFC 9865

Errata ID: 8279
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Matthias Winter
Date Reported: 2025-02-05
Held for Document Update by: Deb Cooley
Date Held: 2025-12-28

Section 7 says:

         server  The value SHOULD be unique within the context of the
            current SCIM endpoint (or tenancy) and MAY be globally
            unique (e.g., a "username", email address, or other
            server-generated key or counter).  No two resources on the
            same server SHOULD possess the same value.

It should say:

         server  The value for the attribute SHOULD be different from 
            all other values for the attribute in any resource on the 
            same server which use the same schema definition. Uniqueness 
            MAY be restricted to resources accessible to the same tenant.

Notes:

The definition is highly ambiguous. Assume a service provider offering the two endpoints /Users and /BusinessUsers. Assume that both resource types use the schema "urn:ietf:params:scim:schemas:core:2.0:User". Further, assume that the service provider serves two tenants, each having access to only a fraction of the resources.

Uniqueness within the context of the SCIM endpoint means that a User and a BusinessUser *can* have the same "userName", but two Users *cannot* exist on the server with the same "userName".
Uniqueness within the context of the tenancy means that a User and a BusinessUser *cannot* have the same "userName" if accessible to the same tenant, but two Users *can* exist on the server with the same "userName" if they are not accessible to the same tenant.
Finally, the uniqueness in the sense of the second sentence means that a User and a BusinessUser *cannot* have the same "userName" and two Users *cannot* exist on the server with the same "userName" irrespective of the tenancy.

Because the option is named "server" and not "endpoint", I assume it is not intended to be restricted endpoints, but rather applies to all resource types using the schema. I also assume a restriction to tenancy is intended. Without this restriction it would be possible for a tenant to determine values of not accessible resources by a brute-force attack.

Let me note that the usage of SHOULD instead of MUST does not make much sense here, because a service provider offering the schema to clients will always know for sure if it enforces uniqueness or not. On the other hand, changing SHOULD to MUST is beyond the scope of errata.

Report New Errata