Subject: [scim] Comments on draft-ietf-scim-core-schema-00

From: Prateek Mishra <[email-masked]>
Date: Thu, 17 Jan 2013 11:08:26 -0500

Section 5.1 - Common Schema Attributes

A)

[quote]

id
    Unique identifier for the SCIM Resource as defined by the Service
    Provider. Each representation of the Resource MUST include a
    non-empty id value. This identifier MUST be unique across the
    Service Provider's entire set of Resources. It MUST be a stable,
    non-reassignable identifier that does not change when the same
    Resource is returned in subsequent requests. The value of the id
    attribute is always issued by the Service Provider and MUST never be
    specified by the Service Consumer. bulkId: is a reserved keyword and
    MUST NOT be used in the unique identifier. REQUIRED and READ-ONLY. 
[\quote]

This is an odd way to state a requirement that the service provider 
choose an identifier that is unique over all service providers and 
time.The reference to bulkId is confusing and should be removed.

Many protocols have a similar uniqueness requirement, for example, in 
SAML 2.0 there is the language -

[saml2.0]
The mechanism by which a SAML system entity ensures that the identifier 
is unique is left to the
implementation. In the case that a random or pseudorandom technique is 
employed, the probability of two
randomly chosen identifiers being identical MUST be less than or equal 
to 2-128 and SHOULD be less than
or equal to 2-160. This requirement MAY be met by encoding a randomly 
chosen value between 128 and
160 bits in length. A pseudorandom
generator MUST be seeded with unique material in order to ensure the 
desired uniqueness properties
between different systems.
[\saml2.0]

or in the JWT draft specification (v05)

[JWT-05]
The jti (JWT ID) claim provides a unique identifier for the JWT. The 
identifier value MUST be
assigned in a manner that ensures that there is a negligible probability 
that the same value
will be accidentally assigned to a different data object. The jti claim 
can be used to prevent
the JWT from being replayed.
[\JWT-05]

B)

[quote]

externalId
    Unique identifier for the Resource as defined by the Service
    Consumer. The externalId may simplify identification of the Resource
    between Service Consumer and Service provider by allowing the
    Consumer to refer to the Resource with its own identifier, obviating
    the need to store a local mapping between the local identifier of
    the Resource and the identifier used by the Service Provider. Each
    Resource MAY include a non-empty externalId value. The value of the
    externalId attribute is always issued be the Service Consumer and
    can never be specified by the Service Provider. This identifier MUST
    be unique across the Service Consumer's entire set of Resources. It
    MUST be a stable, non-reassignable identifier that does not change
    when the same Resource is returned in subsequent requests. The
    Service Provider MUST always interpret the externalId as scoped to
    the Service Consumer's tenant. 

[\quote]

I found this very confusing. I understand that the Service Consumer is 
allowed to set an identifier for a resource - though its optional, so 
thats well and good. Further, this identifier MUST always be returned 
with the resource.

But how are these other requirements regarding tenancy and uniqueness 
"across the Service Consumer's entire set of Resources" going to be 
enforced?
Will the service provider  be required to search through its entire 
repository to ensure these constraints are met?