Subject: Re: [scim] scim Digest, Vol 8, Issue 24

From: Ganesh and Sashi Prasad <[email-masked]>
Date: Sat, 11 Aug 2012 13:45:57 +1000

> In your example you are conflating value with an attribute id.

I don't believe so.

I'm adopting a model where every attribute of the resource is a key-value
pair. The key is a name or ID.

For non-repeating attributes (both simple and composite), the key is the
attribute name itself.

Simple attribute:

Key: "dob"
Value: "01 Jan 1970"

For composite attributes, the key employs dot notation to specify the
fully-qualified attribute name, e.g., "address.postcode".

Composite attribute:

Key: "address.street-number"
Value: "10"

Key: "address.suburb"
Value: "East Camden"

For repeating (multi-valued) attributes, I'm suggesting that there be new
keys for each individual value, otherwise they are impossible to
distinguish, and a positional index is inadequate. So we convert the array
into a dictionary and this then becomes a composite attribute using dot
notation for the key.

Multi-valued attribute:

Key: "emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd902"
Value: "[email-masked]"

So this allows us to apply uniform treatment to any arbitrarily deep
resource structure. We can refer to every leaf value with a key that is the
fully-qualified name using dot notation.

The verbs are just unambiguous operations on these (now) explicitly
addressable attributes.

INCLUDE to a collection and specify only the value. The key is generated
and returned. The fully-qualified key is
<collection-name>.<newly-generated-ID> and the value is what was specified
in the INCLUDE.

REPLACE a fully-qualified key with a new value. If the key doesn't exist,
return a "404 Not Found".

PLACE a value at the logical location implied by the fully-qualified key.
If there is already a key with that name, return a "409 Conflict".

FORCE the fully-qualified key to hold the given value, regardless of
whether it existed before or not. Only errors possible are "400 Bad
Request" and "500 Internal Error".

RETIRE an attribute or a collection given its fully-qualified key. The
implementation will determine whether the attribute will disappear entirely
or will exist holding a null value (the blank string "" or the empty object
{} ).

I'll explain in a separate post why we need operation verbs like these that
are independent of the HTTP verbs.

Regards,
Ganesh

On 11 August 2012 10:38, <[email-masked]> wrote:

> If you have received this digest without all the individual message
> attachments you will need to update your digest options in your list
> subscription.  To do so, go to
>
> https://www.ietf.org/mailman/listinfo/scim
>
> Click the 'Unsubscribe or edit options' button, log in, and set "Get
> MIME or Plain Text Digests?" to MIME.  You can set this option
> globally for all the list digests you receive at this point.
>
>
>
> Send scim mailing list submissions to
>         [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.ietf.org/mailman/listinfo/scim
> or, via email, send a message with subject or body 'help' to
>         [email-masked]
>
> You can reach the person managing the list at
>         [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of scim digest..."
>
> Today's Topics:
>
>    1. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hunt)
>
>
> ---------- Forwarded message ----------
> From: Phil Hunt <[email-masked]>
> To: Ganesh and Sashi Prasad <[email-masked]>
> Cc: "Diodati, Mark" <[email-masked]>, Emmanuel Dreux <
> [email-masked]>, Trey Drake <[email-masked]>, Kelly
> Grizzle <[email-masked]>, "[email-masked]" <[email-masked]>
> Date: Fri, 10 Aug 2012 17:36:54 -0700
> Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement
> Ganesh,
>
> In your example you are conflating value with an attribute id. I find that
> confusing.
>
> I agree though that operations in patch could be a lot more explicit.
>
> Eg explicitly deleting a value by saying delete or retire.
>
> Phil
>
> On 2012-08-10, at 16:19, Ganesh and Sashi Prasad <[email-masked]>
> wrote:
>
>  >  I am concerned about your second suggestion:
>
> Let's discuss that now.
>
> The trade-offs are very clear here.
>
> Pros:
>
> Pro 1. The API to manipulate resources becomes so much cleaner, consistent
> and intuitive when every individual attribute value gets its own ID.
>
> Here's how to delete a single member from a Group, as per the current spec:
>
>    PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce
>    Host: example.com
>    Accept: application/json
>    Authorization: Bearer h480djs93hd8
>    ETag: W/"a330bc54f0671c9"
>
>    {
>      "schemas": ["urn:scim:schemas:core:1.0"],
>      "members": [
>        {
>          "display": "Babs Jensen",
>          "value": "2819c223-7f76-453a-919d-413861904646"
>          "operation": "delete"
>        }
>      ]
>    }
>
>
> Here's how to delete ALL members from a group according to the current
> spec:
>
>    PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce
>    Host: example.com
>    Accept: application/json
>    Authorization: Bearer h480djs93hd8
>    ETag: W/"a330bc54f0671c9"
>
>    {
>      "schemas": ["urn:scim:schemas:core:1.0"],
>      "meta": {
>        "attributes": [
>          "members"
>        ]
>      }
>    }
>
>
> The two operations differ significantly, and it's not very intuitive.
> With my suggestion, here's how to delete a single member from a group:
>
> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.comAccept: application/json Authorization: Bearer h480djs93hd8 ETag:
> W/"a330bc54f0671c9" {
> "operations" : [
> {
>  "RETIRE" : {
> "key" : "members.2819c223-7f76-453a-919d-413861904646"
>  }
> }
> ] }
> Here's how I suggest deleting ALL members from a group:
>
> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.comAccept: application/json Authorization: Bearer h480djs93hd8 ETag:
> W/"a330bc54f0671c9" {
> "operations" : [
> {
>  "RETIRE" : {
> "key" : "members"
>  }
> }
> ] }
>
> I'm sure you'll agree that this is simpler, more consistent and more
> intuitive to a reader.
>
> Pro 2: We can apply this mechanism consistently to three areas:
> (a) Manipulating multi-valued attributes of a resource
> (b) Manipulating members of a group
> (c) Performing bulk operations, where we simply use HTTP verbs instead of
> the specialised (and semantically less ambiguous) verbs I suggested for
> attributes, the "key" becomes the URI, and the "value" becomes the
> corresponding JSON object.
>
> All of them return "207 Multi-Status" with the "results" array holding
> individual status codes.
>
> In the current spec, (a) and (b) are done similarly but (c) is very
> different.
>
> Pro 3: Adoption of the standard by clients is likely to be higher because
> it's simpler for them.
>
> Pro 4: New (not incumbent) cloud providers will probably find this easier
> to implement because they have no legacy. They will probably use some form
> of NoSQL database and won't be constrained by the limitations of LDAP
> directories.
>
> Cons:
>
> Con 1: Incumbent cloud providers with existing data stores in a directory
> format (where multi-valued attributes are stored as comma-separated values
> under a single attribute node) will find it difficult to migrate to this
> model and store each attribute value as a sub-node with its own key. This
> will "hinder adoption of the spec", which is what you fear.
>
> Have I summed up the Pros and Cons correctly? I'm biased of course, so I
> could have missed a Con or hyped a Pro :-).
>
> In other words, we're debating interface complexity (current spec) versus
> implementation complexity (my suggestion). Both can hinder adoption of the
> spec by different parties.
>
> Here's what we need to discuss - Do the Pros make the suggestion worth
> adopting in spite of the Cons, or are the Cons so great that it's best to
> leave the spec as it is?
>
> Keep in mind that a complex spec that only favours incumbent cloud
> providers can cut both ways. It opens the door to a simpler interface
> offered by a new generation of nimbler SPs that don't have the same legacy
> issues, and there could be an exodus of clients to these new SPs. SCIM
> could end up being obsoleted very soon, because the API interface is very
> complex and clumsy, as any new reader can attest. I was taken aback by the
> complexity when I saw it, which is why I was prompted to suggest something
> simpler.
>
> This is an issue where we need the opinions of many people, and they need
> to state their affiliations. If most people weighing in belong to incumbent
> SPs and they vote in favour of interface complexity to avoid implementation
> complexity, then it means the spec is not doing a good job of balancing the
> interests of various groups. I think we should also poll client
> organisations to see what they would want.
>
> (Gartner is trusted by enterprise clients to evaluate the capabilities of
> vendors (SPs). I believe Gartner should take the lead in representing
> client interests in this working group rather than those of incumbent
> vendors, which is what it seems like to me. Correct me if I'm being unfair.)
>
> Regards,
> Ganesh
>
>
>
> On 11 August 2012 01:35, Diodati,Mark <[email-masked]> wrote:
>
>>  Hi Ganesh,
>>
>>
>>
>> I am concerned about your second suggestion:
>>
>> “2. When dealing with multi-valued attributes of a resource (expressed as
>> arrays in JSON), they must be converted from an array into a dictionary
>> with unique keys (UUIDs generated by the cloud provider when the attribute
>> is created). Without unique keys for every attribute value of a resource,
>> manipulating it will be clumsy and inelegant.”
>>
>>
>>
>> One of the primary reasons that SPML failed was lack of adoption by
>> service providers due to its complexity. Very few target applications
>> implemented SPML. Most of the commercial provisioning systems had an SPML
>> interface (either v1 or v2), but not one of them was conformant to the SPML
>> standard because of complexity. If you are interested, I will forward you
>> the research documents that discuss these problems in detail. For SCIM to
>> be successful, it must be adopted by commercial target applications (i.e.,
>> service providers). I am confident that a requirement for unique
>> identifiers with multi-valued attributes will preclude its adoption,
>> because it requires major changes to the service provider’s existing
>> identity storage mechanisms.
>>
>> Mark
>>
>>
>>
>>
>>
>>
>>
>> *From:* Trey Drake [mailto:[email-masked]]
>> *Sent:* Friday, August 10, 2012 9:51 AM
>>
>> *To:* Ganesh and Sashi Prasad
>> *Cc:* [email-masked]; Emmanuel Dreux; Kelly Grizzle; Phil Hunt
>>
>> *Subject:* Re: [scim] SCIM Protocol - 3 suggestions for improvement
>>
>>
>>
>> Ganesh,
>>
>>
>>
>> I'll base my comments on your latest reply (below).
>>
>>
>>
>> The externalID is not part of the protocol.  It is an *optional*
>> attribute within the *schema* specification.  As for #2, the protocol spec
>> works as you describe if "arbitrary URI parameters" equate to resource
>> attributes (Allow generic search using 'GET /Users' and arbitrary URI
>> parameters).  Please clarify your suggestion.
>>
>>
>>
>> I'm not tracking your coupling concern.  The client can search and hence
>> retrieve resources on any attribute it chooses, externalId or otherwise.
>>  Nothing mandates use of externalId.
>>
>>
>>
>>
>>
>> What do you mean by "candidate key"?  Given
>>
>>
>>
>> On Fri, Aug 10, 2012 at 5:49 AM, Ganesh and Sashi Prasad <
>> [email-masked]> wrote:
>>
>> >  I think scim gets its current simplicity from its single owner hub
>> spoke model implementing tight coupling. [...] IMHO loose coupling is a
>> much more complex solution.
>>
>>
>>
>> Phil,
>>
>>
>>
>> I'm a bit surprised that you're implying "tight coupling == simple" and
>> "loose coupling == complex". That's contrary to my experience.
>>
>>
>>
>> When I say "loose coupling", I mean "no unnecessary dependencies".
>> Invariably, a reduction in dependencies leads to greater simplicity.
>>
>>
>>
>> Let's not confuse reduction of dependencies in the data model with a
>> hub-and-spokes architecture. They're entirely orthogonal aspects of the
>> solution.
>>
>>
>>
>> All that my suggestion involves is,
>>
>>
>>
>> 1. Take 'external ID' out of the protocol.
>>
>> 2. Allow generic search using 'GET /Users' and arbitrary URI parameters
>>
>>
>>
>> No planned functionality is lost by this.
>>
>>
>>
>> 1. The client enterprise can still send its internal ID as part of the
>> resource body, inside some attribute defined by them (but not defined by
>> the protocol). Let's say they call it 'myID'.
>>
>> 2. The client enterprise can search for resource URIs using any
>> attribute, including this internal ID
>>
>> 'GET /Users?myID=bjensen'
>>
>> Since myID is a candidate key, the server will return exactly one URI,
>> which is the canonical URI for the resource
>>
>> https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646
>>
>> 3. The client can use this URI to perform all other operations as usual.
>>
>>
>>
>> So taking 'externalID' out of the protocol spec only does this:
>>
>> 1. It avoids enshrining tight coupling in the protocol (If clients want to tightly couple themselves to the cloud provider by sending their internal IDs, they can do so. Suicide is OK, but the protocol should not be guilty of assisted suicide. ;-)
>>
>> 2. It encourages loose coupling by nudging clients towards maintaining their own internal-to-external identifier mappings.
>>
>>
>>
>> That's what I'd like to see. I don't believe this complicates the protocol. It simplifies it and it also lends itself to a loosely-coupled approach.
>>
>>
>>
>> I'll address the multi-valued attribute suggestion separately.
>>
>>
>>
>> Regards,
>>
>> Ganesh
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On 10 August 2012 07:53, Phil Hunt <[email-masked]> wrote:
>>
>>
>>
>> Phil
>>
>>
>> On 2012-08-09, at 14:14, Ganesh and Sashi Prasad <[email-masked]>
>> wrote:
>>
>>  >  storing this information in a mapping table outside of the SCIM spec
>> is a great way to enable this solution.  Part of the key here is that SCIM
>> is just a piece of the architecture for this solution, and is only
>> responsible for the transport layer between domains.
>>
>> I wasn't suggesting that the mapping table be part of the SCIM spec. I
>> provided that example to illustrate that splitting and merging identities
>> is a common requirement, and that decoupling local identifiers within a
>> domain from shared identifiers between domains was the best way to
>> facilitate it.
>>
>>
>>
>> I'm suggesting that the spec do less, not more.
>>
>>
>>
>> What the SCIM spec needs to do there is just refrain from introducing
>> tight coupling. I would like to see a single identifier exposed through the
>> API, with the implication (and perhaps the recommendation) that it be the
>> shared one. Allowing one domain to expose its internal identifier to the
>> other creates tight coupling and ensures that both domains need
>> simultaneously split or merge identities, which is not desirable. So I
>> recommend _taking out_ the "external id" field from the API. The spec
>> shouldn't encourage tight coupling. If clients want to pass in their
>> internal ids as part of the resource body, no one can stop them, and they
>> can always do a search on that attribute to retrieve the URI exactly as you
>> visualise they will with the "external id", but let's not elevate an
>> anti-pattern to a recommendation by enshrining the "external id" as an
>> acceptable attribute.
>>
>>
>>
>> Am I making sense?
>>
>>
>>
>> I see what you are saying. I think scim gets its current simplicity from
>> its single owner hub spoke model implementing tight coupling.
>>
>>
>>
>> IMHO loose coupling is a much more complex solution. The reality is that
>> each end-point has value to contribute and thus the single-owner model will
>> eventually need to become multi-owner or multi-hub.
>>
>>
>>
>> That said i think the current model provides a practical starting point.
>>
>>
>>
>> >  Regarding unique identifiers for multi-valued attributes there is a
>> trade-off involved.  On one hand this makes PATCH semantics easier.  On the
>> other hand it puts extra burden on service providers.
>>
>>
>> Precisely. The spec has to strike the right balance. It would be
>> interesting to hear from the other members of the spec mailing list. You
>> know where I stand on this. It would be good to hear the spectrum of
>> opinions.
>>
>>
>>
>> Regards,
>>
>> Ganesh
>>
>> On 10 August 2012 00:28, Kelly Grizzle <[email-masked]>
>> wrote:
>>
>> Thanks Emmanuel.  I had started writing up a similar response.  As you
>> suggest, storing this information in a mapping table outside of the SCIM
>> spec is a great way to enable this solution.  Part of the key here is that
>> SCIM is just a piece of the architecture for this solution, and is only
>> responsible for the transport layer between domains.
>>
>>
>>
>> You could also model these ID mappings in the SCIM user as an extension
>> but would probably not want to expose these externally.  Here is an example
>> of how to model the end state of the false positive scenario (splitting a
>> user):
>>
>>
>>
>> | Internal Entity ID | External Domain ID | External Entity ID | Primary
>> flag |
>>
>> | 9caf78aac3d6       | D2                 | ff487230b3a0       |
>> true         |
>>
>> | a99a5feba839       | D2                 | 7a87f27c1dd8       |
>> true         |
>>
>>
>>
>> This could be represented as two SCIM users that contain information
>> about the entities on other domains.
>>
>>
>>
>> {
>>
>>   "schemas": ["urn:scim:schemas:core:1.0",
>> "urn:scim:schemas:extension:federation:1.0"],
>>
>>   "id": "9caf78aac3d6",
>>
>>   "userName": "John Smith",
>>
>>   "urn:scim:schemas:extension:federation:1.0": {
>>
>>     "linkedUsers": [
>>
>>       {
>>
>>         "domain": "D2",
>>
>>         "externalEntityId": "ff487230b3a0"
>>
>>       }
>>
>>     ]
>>
>>   }
>>
>> }
>>
>>
>>
>> {
>>
>>   "schemas": ["urn:scim:schemas:core:1.0",
>> "urn:scim:schemas:extension:federation:1.0"],
>>
>>   "id": "a99a5feba839",
>>
>>   "userName": "John Smith",
>>
>>   "urn:scim:schemas:extension:federation:1.0": {
>>
>>     "linkedUsers": [
>>
>>       {
>>
>>         "domain": "D2",
>>
>>         "externalEntityId": "7a87f27c1dd8"
>>
>>       }
>>
>>     ]
>>
>>   }
>>
>> }
>>
>>
>>
>> In the second user, the linkedUsers attribute would be empty until the
>> split user was synced to domain 2.
>>
>>
>>
>>
>>
>> Similarly, the false negative use case (merging two users) looked like
>> this at the end:
>>
>>
>>
>> | Internal Entity ID | External Domain ID | External Entity ID | Primary
>> flag |
>>
>> | 9caf78aac3d6       | D2                 | ff487230b3a0       |
>> true         |
>>
>> | 9caf78aac3d6       | D2                 | 41206cc97c8b       |
>> false        |
>>
>>
>>
>> This could be represented with the following SCIM user:
>>
>>
>>
>> {
>>
>>   "schemas": ["urn:scim:schemas:core:1.0",
>> "urn:scim:schemas:extension:federation:1.0"],
>>
>>   "id": "9caf78aac3d6",
>>
>>   "userName": "John Smith",
>>
>>   "urn:scim:schemas:extension:federation:1.0": {
>>
>>     "linkedUsers": [
>>
>>       {
>>
>>         "domain": "D2",
>>
>>         "externalEntityId": "ff487230b3a0"
>>
>>       },
>>
>>       {
>>
>>         "domain": "D2",
>>
>>         "externalEntityId": "41206cc97c8b",
>>
>>         "deletionRequired": true
>>
>>       }
>>
>>     ]
>>
>>   }
>>
>> }
>>
>>
>>
>>
>>
>> Regarding unique identifiers for multi-valued attributes there is a
>> trade-off involved.  On one hand this makes PATCH semantics easier.  On the
>> other hand it puts extra burden on service providers.  Since the inception
>> of SCIM, a key goal has been to foster adoption by service providers by
>> making things fit easily onto existing systems.  IMO the value gained by
>> unique identifiers for multi-valued attributes is not worth the demands put
>> on a service provider.  I also think that vendors that have a
>> non-SCIM-compliant API will choose to keep things that way if the spec is
>> too hard for them to implement.  In a green field environment we do have
>> the luxury of mandating a model to make certain operations more elegant.
>> However, we can’t ignore legacy systems.
>>
>>
>>
>> --Kelly
>>
>>
>>
>> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
>> Of *Emmanuel Dreux
>> *Sent:* Thursday, August 09, 2012 3:18 AM
>> *To:* Ganesh and Sashi Prasad; Kelly Grizzle
>> *Cc:* [email-masked]
>> *Subject:* Re: [scim] SCIM Protocol - 3 suggestions for improvement
>>
>>
>>
>> Hi Ganesh,
>>
>>
>>
>> Nothing prevents you in your SCIM implementation (client or server) to
>> generate a unique identifier for each synchronized object and maintain an
>> internal mapping table ( you would have to map group membership as well).
>>
>>
>>
>> This is what we are doing with Active Directory sources or targets:
>>
>> As we didn’t find an immutable uniqueID in AD systems (DN,samAccountName,
>> UPN) are subject to change (even objectGuid can change if an AD domain is
>> migrated), we decided to generate and maintain an internal table of ids.
>> This fits your requirements as it hides internal ids.
>>
>>
>>
>> This was written in dotnet and we have started a project to rewrite our
>> SCIM stack in PHP and will give it to the Open Source community. This
>> implementation will have a parameter : AllocateIds versus UseExistingIDs.
>>
>> This will give the choice of “hiding” internalIDs or use them as unique
>> ID.
>>
>>
>>
>> You can also implement such feature without violating the SCIM specs, or
>> without asking to include it in the specs.
>>
>>
>>
>> --
>>
>> Regards,
>>
>> Emmanuel Dreux
>>
>> http://www.cloudiway.com
>>
>> Tel: +33 4 26 78 17 58
>>
>> Mobile: +33 6 47 81 26 70
>>
>> skype: Emmanuel.Dreux
>>
>>
>>
>> *De :* Ganesh and Sashi Prasad [mailto:[email-masked]<[email-masked]>]
>>
>> *Envoyé :* jeudi 9 août 2012 03:35
>> *À :* Kelly Grizzle
>> *Cc :* [email-masked]
>> *Objet :* Re: [scim] SCIM Protocol - 3 suggestions for improvement
>>
>>
>>
>> Hi Kelly,
>>
>> Thanks for your response. Let me first respond in brief to the two main
>> points you have made, and then elaborate on the first.
>>
>> 1.      Why should domains not expose their internal identifiers to
>> other domains?
>>
>> a.
>>
>> We are designing a protocol for a federated system of domains, where all
>> domains are co-equal peers. (In physics too, N-body problems are much
>> harder than 2-body problems. :-) Therefore, assuming that there are only
>> two players in the interaction makes this tightly coupled in a number of
>> ways. We should rely on messaging and notification, with encapsulation of
>> domain-specific data.
>>
>> b.
>>
>> In any non-trivial data store, there will always be the ongoing need to
>> merge and split identities as and when “false negatives” and “false
>> positives” are discovered. A domain should be able to handle this internal
>> housekeeping freely, only notifying other domains when convenient. Mapping
>> of internal identifiers to external ones and maintaining this mapping
>> internally allows this loosely-coupled housekeeping to take place. Sharing
>> internal identifiers (or otherwise outsourcing the mapping of internal to
>> external identifiers) forces housekeeping activities to be done in
>> lock-step across domains.
>>
>> c.
>>
>> Asynchronous interaction is not just a matter of a suitable wire protocol
>> which can be designed later. The data model plays a crucial role in
>> enabling or constraining such interaction. A tightly-coupled data model
>> will force the use of synchronous interactions, and the exposure of
>> internal identifiers is a key part of this tight coupling.
>>
>> 2. The difficulty of assigning unique identifiers to the individual
>> values of multi-valued attributes:
>>
>> a.
>>
>> I'm not belittling the effort involved in migrating legacy data stores to
>> such a model. However, in the larger historical context of cross-domain
>> identity management, we are really at the very early stages. If a
>> relatively new discipline and a brand new spec are held captive to legacy
>> considerations, we are losing an opportunity to provide a clean and elegant
>> model to subsequent users of the spec, and this will have repercussions
>> over many years or even decades.
>>
>> b.
>>
>> If incumbent cloud providers find it hard to immediately adopt the
>> dictionary model for existing multi-valued attributes, they can transition
>> to this model by offering both “SCIM-compliant” and “non-SCIM-compliant”
>> APIs to their customers and encouraging new customers to adopt the
>> “SCIM-compliant” API. Legacy customers can be supported using a
>> “non-SCIM-compliant” API for an arbitrarily long period and gradually
>> migrated to the SCIM-compliant API. The logistics are not insurmountable,
>> and shouldn't prevent the adoption of a dictionary model for multi-valued
>> attributes.
>>
>> Elaboration of Point 1:
>>
>> When we consider federated identity across more than one domain, we have
>> to assume that domains are not necessarily master-slave in their
>> interaction. The most generic interaction model is peer-to-peer, where
>> entity lifecycle events within a domain are notified to other domains (when
>> necessary) in an asynchronous manner (i.e., through messaging) and the
>> other domains are free to respond to these events in an appropriate manner
>> and at a time of their convenience.
>>
>> A key set of lifecycle events for an entity is the merging and splitting
>> of identity that is often required.
>>
>> The question “Is this one entity?” can be answered either yes (positive)
>> or no (negative). But sometimes, we can discover false positives and false
>> negatives in our data stores.
>>
>> Consider a case where customers sign up online, and two customers who are
>> privacy-conscious enter fake IDs such as “John Smith”, and also use the
>> same date of birth (say, 1 Jan 1970) or similar attributes. The front-end
>> application may make an intelligent (but incorrect) guess that these two
>> persons are the same, and re-assign the same identifier to the second
>> person. This is a false positive. They appear to be the same entity, but
>> they're actually different. When the error is discovered, the identities
>> will need to be split, with a new identifier generated for one of them.
>>
>> Consider the opposite case where a customer signs up through two
>> different portals or in two different sessions, using the names “JSmith”
>> and “JohnS”. It is very likely that they will be treated as two different
>> customers and assigned two unique identifiers. This is a false negative.
>> They appear to be two entities, but are actually the same. At a later
>> stage, when the error is discovered, the identities will have to be merged,
>> and one of the identifiers will have to be dropped.
>>
>> These are not theoretical use cases. They form a significant proportion
>> of the user base in most large Web-facing applications. Let's see how these
>> can be managed in a federated way by mapping internal identifiers to
>> external ones and only exposing external identifiers to other domains.
>>
>> a. False positives:
>>
>> Domain 1 has the following information about a customer in its data store:
>>
>> Internal ID: 9caf78aac3d6
>>
>> Attributes: {name: “John Smith”, dob: “01-Jan-1970”}
>>
>> When requesting the provisioning of this entity in Domain 2, the
>> following ID is returned by Domain 2: ff487230b3a0.
>>
>> Domain 1 then maintains the following in a mapping table and uses it for
>> translation when talking to Domain 2, taking care never to expose its
>> internal identifier:
>>
>> | Internal Entity ID | External Domain ID | External Entity ID | Primary
>> flag |
>>
>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true |
>>
>> When the false positive is discovered and the entity is split, Domain 1
>> creates a new internal identifier and now has the following entity
>> information.
>>
>> Internal ID: 9caf78aac3d6
>>
>> Attributes: {name: “John Smith”, dob: “01-Jan-1970”}
>>
>> Internal ID: a99a5feba839
>>
>> Attributes: {name: “John Smith”, dob: “01-Jan-1970”}
>>
>> This second entity with its own internal identifier is invisible to
>> Domain 2, and this is by design. Communication about the original entity
>> takes place as before by mapping “9caf78aac3d6” to “ff487230b3a0” and
>> vice-versa. At some convenient time (importantly, this doesn't have to be
>> at the time the split happens), Domain 2 can be requested to provision a
>> second entity, and when it responds with an identifier of “7a87f27c1dd8”,
>> this can go into the mapping table as a new record associated with the
>> second entity's internal identifier.
>>
>> The mapping table now contains the following entries:
>>
>> | Internal Entity ID | External Domain ID | External Entity ID | Primary
>> flag |
>>
>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true |
>>
>> | a99a5feba839 | D2 | 7a87f27c1dd8 | true |
>>
>> Domain 2 is not even aware that a split has happened, and the
>> provisioning that it does is not in lockstep with the split in identity
>> that occurred in Domain 1.
>>
>> (What is the “Primary flag” used for? We'll see when we cover the
>> treatment of false negatives.)
>>
>> b. False negatives:
>>
>> Domain 1 has the following information about what it thinks are two
>> distinct customers in its data store:
>>
>> Internal ID: 9caf78aac3d6
>>
>> Attributes: {name: “JSmith”, dob: “01-Jan-1970”}
>>
>> Internal ID: 273d36e30d09
>>
>> Attributes: {name: “JohnS”, dob: “01-Jan-1970”}
>>
>> When requesting the provisioning of these entities in Domain 2, the
>> following IDs are returned by Domain 2: ff487230b3a0 and 41206cc97c8b.
>>
>> Domain 1 then maintains the following in a mapping table and uses it for
>> translation when talking to Domain 2, taking care never to expose its
>> internal identifiers:
>>
>> | Internal Entity ID | External Domain ID | External Entity ID | Primary
>> flag |
>>
>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true |
>>
>> | 273d36e30d09 | D2 | 41206cc97c8b | true |
>>
>> When the false negative is discovered and the two entities are merged,
>> Domain 1 drops one of the internal identifiers and rationalises the name of
>> the customer (say, to “John Smith”). Let's say it retains the first ID
>> “9caf78aac3d6” and drops the second “273d36e30d09”.
>>
>> The mapping table now looks like this:
>>
>> | Internal Entity ID | External Domain ID | External Entity ID | Primary
>> flag |
>>
>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true |
>>
>> | 9caf78aac3d6 | D2 | 41206cc97c8b | false |
>>
>> Now two external identifiers map to the same internal one, so inbound
>> communication from Domain 2 can be unambiguously translated to the same
>> entity internally. However, when going outwards, Domain 1 will have to look
>> up the translation table to determine the “primary” external ID for this
>> entity in Domain 2, which was decided to be “ff487230b3a0”. That's where
>> the “Primary flag” comes in. The second external ID “41206cc97c8b” is never
>> used thereafter in outbound communication.
>>
>> At some stage (importantly, not in lockstep with the identity merge),
>> Domain 2 can be requested to delete the customer record identified by
>> “41206cc97c8b”, and the second entry in the mapping table can be removed
>> once this is acknowledged.
>>
>> This scheme will scale up to multiple domains, because the “External
>> Domain ID” column helps to keep track of which external ID is shared with
>> which Domain. (Why don't we use just one external ID for an entity and
>> share it with all external domains? Tight coupling again. Just as OAuth
>> allows an access token given to a third party to be invalidated without
>> affecting the access of other third parties, the use of separate external
>> identifiers for different domains allows fine-grained control of identity
>> federation.)
>>
>> The scheme also allows the splitting of an entity into more than two
>> entities, and the merging of more than two entities into a single one. (Any
>> organisation with a web-facing application will tell you how many John
>> Smiths there are who were born on 1 Jan 1970!)
>>
>> This is a fairly long-winded explanation, but this is why we need to hide
>> internal identifiers from other domains, and why mappings need to be
>> managed internally in each domain. Such a data model also allows us to
>> choose asynchronous protocols for propagation of identity events, since
>> there is no consistency requirement to update multiple domains concurrently.
>>
>> Regards,
>>
>> Ganesh Prasad
>>
>>
>>
>> On 9 August 2012 04:55, Kelly Grizzle <[email-masked]>
>> wrote:
>>
>> Thanks for the feedback, Ganesh.  I read through this and your InfoQ
>> article (http://www.infoq.com/articles/scim-data-model-limitations) and
>> have some thoughts.
>>
>>
>>
>> > The rest of the protocol does not meaningfully use the enterprise
>> client’s identifier, the "external ID"
>>
>> > at all, even though it was ostensibly introduced to make things
>> friendlier for the client.
>>
>>
>>
>> The usage pattern for an external ID would be to search for a user by
>> externalId and use the ID of the returned user in any desired operation.
>> For example:
>>
>>
>>
>> GET /Users?filter=externalId eq “bjensen”&attributes=id
>>
>>
>>
>> {
>>
>>   “totalResults”: 1,
>>
>>   “Resources”: [
>>
>>     {
>>
>>       “id”: “2819c223-7f76-453a-919d-413861904646”
>>
>>     }
>>
>>   ]
>>
>> }
>>
>>
>>
>> Retrieve the ID from the response and use it.
>>
>>
>>
>> DELETE /Users/2819c223-7f76-453a-919d-413861904646
>>
>>
>>
>> This does introduce an additional HTTP request if the client chooses not
>> to store the server’s id.  An issue was created to consider allowing
>> operations to use the externalId (
>> http://code.google.com/p/scim/issues/detail?id=35), but I believe the
>> general consensus has been to not include this in the spec.  One main point
>> of contention is that much of the rest of the spec (eg – group membership
>> references, manager references, etc…) require knowledge of the server’s
>> identifier.  Continuing this discussion on the IETF list would be a good
>> thing, though.
>>
>>
>>
>>
>>
>> > the cloud provider's ID and the enterprise client's ID are both
>> "Internal IDs" with respect to their domains
>>
>>
>>
>> I think this comes down to a nomenclature problem.  The server’s ID does
>> not necessarily have to be the unique identifier that the underlying
>> identity store uses, it just has to be stable and unique.  In many cases,
>> the underlying identity store will provide identifiers with these
>> properties already (eg – a uuid) and it can be used by the SCIM interface.
>> The “externalId” is referring to the fact that the id is maintained
>> external to the SCIM server.  As long as the server’s identifiers are
>> stable and unique (which is mandated by the spec), I don’t see a problem.
>>
>>
>>
>>
>>
>> > The secret is that *every value needs a key*, and multi-valued
>> attributes lack that. So our solution is quite
>>
>> > simple - turn every list or array (of values) into a dictionary (of
>> key-value pairs) by providing each value
>>
>> > with a unique and meaning-free identifier.
>>
>>
>>
>> I agree that this would be useful, especially in the PATCH operation.
>> One reason that this wasn’t included in the spec originally is that it can
>> put undue burden on the service provider.  Many service providers are
>> putting SCIM interfaces in front of their existing identity stores (eg –
>> directory servers, SaaS application databases, etc…).  Many of these do not
>> have a unique identifier for multi-valued attributes.  By requiring this, a
>> majority of the server providers would have to start maintaining a unique
>> key for each multi-valued attribute.  I believe this would be a roadblock
>> for many implementers.
>>
>>
>>
>>
>>
>> > When the SCIM protocol uses PATCH, there are areas where it seems a
>> bit clumsy.
>>
>>
>>
>> I like the thoughts here.  Your example reminds me of unified diffs (
>> http://en.wikipedia.org/wiki/Diff#Unified_format), which are commonly
>> used with a patch program (pretty much the equivalent of the PATCH verb).
>>  However, the three proposals seem to largely hinge on being able to
>> uniquely address each element within an object.  Without these it is not so
>> easy to address each patch sub-operation (REPLACE, INCLUDE, etc…) or
>> provide a multi-status.
>>
>>
>> The 207 response would be interesting to consider for the bulk endpoint (
>> http://www.simplecloud.info/specs/draft-scim-api-00.html#bulk-resources),
>> however.
>>
>>
>>
>>
>>
>> > There are other, non-data aspects of SCIM which may require review,
>> such as its synchronous request-response
>>
>> > interaction model, which is a form of tight coupling and could prove to
>> be a source of brittleness.
>>
>>
>>
>> I agree that we should explore optional asynchronous requests in 2.0.
>>
>>
>>
>> Thanks again for your thoughts.  I hope you stay involved in the
>> discussion as work on SCIM 2.0 goes forward.
>>
>>
>>
>> --Kelly
>>
>>
>>
>> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
>> Of *Ganesh and Sashi Prasad
>> *Sent:* Wednesday, August 01, 2012 4:24 PM
>> *To:* [email-masked]
>> *Subject:* [scim] SCIM Protocol - 3 suggestions for improvement
>>
>>
>>
>> (I posted this on the SCIM Google Group, and I was advised to subscribe
>> to the mailing list and post it here instead, so here goes.)
>>
>>
>>
>> Hi,
>>
>>
>>
>> My name is Ganesh Prasad, and my experience in Identity and Access
>> Management is mainly through a 3-year project at an Australian insurance
>> company, an experience I have written about as a eBook on InfoQ (
>> http://www.infoq.com/minibooks/Identity-Management-Shoestring).
>>
>>
>>
>> I have been following the SCIM spec off and on, and based on my
>> experience with a loosely-coupled architecture that I found to be
>> successful, I have the following 3 suggestions to make.
>>
>>
>>
>> 1. The enterprise client and the cloud provider should maintain their own
>> internal IDs for a resource, which they should not reveal to each other.
>> Both of them should map their internal IDs to a shared External ID, and
>> this is the only ID that should be exposed through the API. The current
>> specification's provision of an id (which is the external ID and the only
>> one to be transferred through the API) and an "external ID" (which is the
>> client's internal ID and should be hidden) is diametrically opposite to
>> this.
>>
>>
>>
>> 2. When dealing with multi-valued attributes of a resource (expressed as
>> arrays in JSON), they must be converted from an array into a dictionary
>> with unique keys (UUIDs generated by the cloud provider when the attribute
>> is created). Without unique keys for every attribute value of a resource,
>> manipulating it will be clumsy and inelegant.
>>
>>
>>
>> 3. The PATCH command can be improved in 3 significant ways:
>>
>> 3a. Leverage the fact (from 2 above) that every value has a key, to
>> greatly simplify the API
>>
>> 3b. Use special verbs as nested operations of the PATCH command to add,
>> modify and delete attributes at any level
>>
>> 3c. Use the WebDAV status code of "207 Multi-Status" instead of "200 OK"
>> as the response to a PATCH (or BULK) command.
>>
>>
>>
>> To elaborate,
>>
>>
>>
>> 1. Revealing private IDs externally is a form of tight coupling. A major
>> requirement with Identity Management is to split (or merge) identities when
>> false positives (or false negatives) are detected, i.e., when a resource is
>> discovered to be more than one, or when multiple resources are detected to
>> be the same. If internal identifiers are revealed to external domains, such
>> clean-ups become difficult, hence every domain that wants to expose
>> references to a resource must map its internal ID to and external one
>> created for this explicit purpose, and only reveal this.
>>
>>
>>
>> In the SCIM case, when an enterprise client POSTs a resource creation
>> request, the cloud provider must generate its own internal UUID as well as
>> an external UUID, map them together, and only return the external UUID in
>> the "Location:" header. The enterprise client should map this external UUID
>> to a newly-generated internal ID of its own. In case the resource already
>> has an identifier within the enterprise client's domain, then this is the
>> internal ID that must be mapped to the external UUID returned through the
>> POST response.
>>
>>
>>
>> 2. If a resource is to be created, and one of its attributes is
>> multi-valued, e.g.,
>>
>>
>>
>>     "email-addrs" :
>>
>>     [
>>
>>         "[email-masked]",
>>
>>         "[email-masked]",
>>
>>         "[email-masked]"
>>
>> <
>>
>> _______________________________________________
>> scim mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/scim
>>
>>
>>
>>
>> _______________________________________________
>> scim mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/scim
>>
>>
>>
>> ------------------------------
>>
>> This e-mail message, including any attachments, is for the sole use of
>> the person to whom it has been sent, and may contain information that is
>> confidential or legally protected. If you are not the intended recipient or
>> have received this message in error, you are not authorized to copy,
>> distribute, or otherwise use this message or its attachments. Please notify
>> the sender immediately by return e-mail and permanently delete this message
>> and any attachments. Gartner makes no warranty that this e-mail is error or
>> virus free.
>>
>
>
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim
>
>

---

From: Phil Hunt <[email-masked]>
Date: Fri, 10 Aug 2012 21:59:29 -0600

For the multi-value example you gave you used the value as the attribute name key. 

That means a lot more complex indexing structure. Better to just say delete a specific value. 

The spec already allows multiple values to have tags like home, work, etc.

Phil

On 2012-08-10, at 21:45, Ganesh and Sashi Prasad <[email-masked]> wrote:

> I'm adopting a model where every attribute of the resource is a key-value pair. The key is a name or ID.
> 
> For non-repeating attributes (both simple and composite), the key is the attribute name itself. 
> 
> Simple attribute:
> 
> Key: "dob"
> Value: "01 Jan 1970"
> 
> For composite attributes, the key employs dot notation to specify the fully-qualified attribute name, e.g., "address.postcode".
> 
> Composite attribute:
> 
> For repeating (multi-valued) attributes, I'm suggesting that there be new keys for each individual value, otherwise they are impossible to distinguish, and a positional index is inadequate. So we convert the array into a dictionary and this then becomes a composite attribute using dot notation for the key.
> 
> Multi-valued attribute:
> 
> So this allows us to apply uniform treatment to any arbitrarily deep resource structure. We can refer to every leaf value with a key that is the fully-qualified name using dot notation.
> 
> The verbs are just unambiguous operations on these (now) explicitly addressable attributes.
> 
> INCLUDE to a collection and specify only the value. The key is generated and returned. The fully-qualified key is <collection-name>.<newly-generated-ID> and the value is what was specified in the INCLUDE.
> 
> REPLACE a fully-qualified key with a new value. If the key doesn't exist, return a "404 Not Found".
> 
> PLACE a value at the logical location implied by the fully-qualified key. If there is already a key with that name, return a "409 Conflict".
> 
> FORCE the fully-qualified key to hold the given value, regardless of whether it existed before or not. Only errors possible are "400 Bad Request" and "500 Internal Error".
> 
> RETIRE an attribute or a collection given its fully-qualified key. The implementation will determine whether the attribute will disappear entirely or will exist holding a null value (the blank string "" or the empty object {} ).
> 
> I'll explain in a separate post why we need operation verbs like these that are independent of the HTTP verbs.
> 
> Regards,
> Ganesh
> 
> Cc: "Diodati, Mark" <[email-masked]>, Emmanuel Dreux <[email-masked]>, Trey Drake <[email-masked]>, Kelly Grizzle <[email-masked]>, "[email-masked]" <[email-masked]>
> In your example you are conflating value with an attribute id. I find that confusing. 
> 
> On 2012-08-10, at 16:19, Ganesh and Sashi Prasad <[email-masked]> wrote:
> 
>> Pro 1. The API to manipulate resources becomes so much cleaner, consistent and intuitive when every individual attribute value gets its own ID.
>> 
>> Here's how to delete ALL members from a group according to the current spec:
>> 
>> I'm sure you'll agree that this is simpler, more consistent and more intuitive to a reader.
>> 
>> (c) Performing bulk operations, where we simply use HTTP verbs instead of the specialised (and semantically less ambiguous) verbs I suggested for attributes, the "key" becomes the URI, and the "value" becomes the corresponding JSON object.
>> 
>> All of them return "207 Multi-Status" with the "results" array holding individual status codes.
>> 
>> In the current spec, (a) and (b) are done similarly but (c) is very different.
>> 
>> Pro 3: Adoption of the standard by clients is likely to be higher because it's simpler for them.
>> 
>> Pro 4: New (not incumbent) cloud providers will probably find this easier to implement because they have no legacy. They will probably use some form of NoSQL database and won't be constrained by the limitations of LDAP directories.
>> 
>> Cons:
>> 
>> Con 1: Incumbent cloud providers with existing data stores in a directory format (where multi-valued attributes are stored as comma-separated values under a single attribute node) will find it difficult to migrate to this model and store each attribute value as a sub-node with its own key. This will "hinder adoption of the spec", which is what you fear.
>> 
>> Have I summed up the Pros and Cons correctly? I'm biased of course, so I could have missed a Con or hyped a Pro :-).
>> 
>> In other words, we're debating interface complexity (current spec) versus implementation complexity (my suggestion). Both can hinder adoption of the spec by different parties.
>> 
>> Here's what we need to discuss - Do the Pros make the suggestion worth adopting in spite of the Cons, or are the Cons so great that it's best to leave the spec as it is?
>> 
>> Keep in mind that a complex spec that only favours incumbent cloud providers can cut both ways. It opens the door to a simpler interface offered by a new generation of nimbler SPs that don't have the same legacy issues, and there could be an exodus of clients to these new SPs. SCIM could end up being obsoleted very soon, because the API interface is very complex and clumsy, as any new reader can attest. I was taken aback by the complexity when I saw it, which is why I was prompted to suggest something simpler.
>> 
>> This is an issue where we need the opinions of many people, and they need to state their affiliations. If most people weighing in belong to incumbent SPs and they vote in favour of interface complexity to avoid implementation complexity, then it means the spec is not doing a good job of balancing the interests of various groups. I think we should also poll client organisations to see what they would want.
>> 
>> (Gartner is trusted by enterprise clients to evaluate the capabilities of vendors (SPs). I believe Gartner should take the lead in representing client interests in this working group rather than those of incumbent vendors, which is what it seems like to me. Correct me if I'm being unfair.)
>> 
>> Regards,
>> Ganesh
>> 
>> 
>> 
>> “2. When dealing with multi-valued attributes of a resource (expressed as arrays in JSON), they must be converted from an array into a dictionary with unique keys (UUIDs generated by the cloud provider when the attribute is created). Without unique keys for every attribute value of a resource, manipulating it will be clumsy and inelegant.”
>> 
>>  
>> 
>> One of the primary reasons that SPML failed was lack of adoption by service providers due to its complexity. Very few target applications implemented SPML. Most of the commercial provisioning systems had an SPML interface (either v1 or v2), but not one of them was conformant to the SPML standard because of complexity. If you are interested, I will forward you the research documents that discuss these problems in detail. For SCIM to be successful, it must be adopted by commercial target applications (i.e., service providers). I am confident that a requirement for unique identifiers with multi-valued attributes will preclude its adoption, because it requires major changes to the service provider’s existing identity storage mechanisms.
>> 
>> Mark
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>> From: Trey Drake [mailto:[email-masked]] 
>> Sent: Friday, August 10, 2012 9:51 AM
>> 
>> 
>> To: Ganesh and Sashi Prasad
>> Cc: [email-masked]; Emmanuel Dreux; Kelly Grizzle; Phil Hunt
>> 
>> The externalID is not part of the protocol.  It is an *optional* attribute within the *schema* specification.  As for #2, the protocol spec works as you describe if "arbitrary URI parameters" equate to resource attributes (Allow generic search using 'GET /Users' and arbitrary URI parameters).  Please clarify your suggestion.
>> 
>>  
>> 
>> I'm not tracking your coupling concern.  The client can search and hence retrieve resources on any attribute it chooses, externalId or otherwise.  Nothing mandates use of externalId.   
>> 
>>  
>> 
>>  
>> 
>> On Fri, Aug 10, 2012 at 5:49 AM, Ganesh and Sashi Prasad <[email-masked]> wrote:
>> 
>> >  I think scim gets its current simplicity from its single owner hub spoke model implementing tight coupling. [...] IMHO loose coupling is a much more complex solution.
>> 
>>  
>> 
>> Phil,
>> 
>>  
>> 
>> I'm a bit surprised that you're implying "tight coupling == simple" and "loose coupling == complex". That's contrary to my experience.
>> 
>>  
>> 
>> When I say "loose coupling", I mean "no unnecessary dependencies". Invariably, a reduction in dependencies leads to greater simplicity.
>> 
>>  
>> 
>> Let's not confuse reduction of dependencies in the data model with a hub-and-spokes architecture. They're entirely orthogonal aspects of the solution.
>> 
>>  
>> 
>> 1. The client enterprise can still send its internal ID as part of the resource body, inside some attribute defined by them (but not defined by the protocol). Let's say they call it 'myID'.
>> 
>> 2. The client enterprise can search for resource URIs using any attribute, including this internal ID
>> 
>> Since myID is a candidate key, the server will return exactly one URI, which is the canonical URI for the resource
>> 
>> On 2012-08-09, at 14:14, Ganesh and Sashi Prasad <[email-masked]> wrote:
>> 
>> >  storing this information in a mapping table outside of the SCIM spec is a great way to enable this solution.  Part of the key here is that SCIM is just a piece of the architecture for this solution, and is only responsible for the transport layer between domains. 
>> 
>> I wasn't suggesting that the mapping table be part of the SCIM spec. I provided that example to illustrate that splitting and merging identities is a common requirement, and that decoupling local identifiers within a domain from shared identifiers between domains was the best way to facilitate it.
>> 
>>  
>> 
>> What the SCIM spec needs to do there is just refrain from introducing tight coupling. I would like to see a single identifier exposed through the API, with the implication (and perhaps the recommendation) that it be the shared one. Allowing one domain to expose its internal identifier to the other creates tight coupling and ensures that both domains need simultaneously split or merge identities, which is not desirable. So I recommend _taking out_ the "external id" field from the API. The spec shouldn't encourage tight coupling. If clients want to pass in their internal ids as part of the resource body, no one can stop them, and they can always do a search on that attribute to retrieve the URI exactly as you visualise they will with the "external id", but let's not elevate an anti-pattern to a recommendation by enshrining the "external id" as an acceptable attribute.
>> 
>>  
>> 
>> Am I making sense?
>> 
>>  
>> 
>> I see what you are saying. I think scim gets its current simplicity from its single owner hub spoke model implementing tight coupling. 
>> 
>>  
>> 
>> IMHO loose coupling is a much more complex solution. The reality is that each end-point has value to contribute and thus the single-owner model will eventually need to become multi-owner or multi-hub. 
>> 
>>  
>> 
>> >  Regarding unique identifiers for multi-valued attributes there is a trade-off involved.  On one hand this makes PATCH semantics easier.  On the other hand it puts extra burden on service providers. 
>> 
>> 
>> Precisely. The spec has to strike the right balance. It would be interesting to hear from the other members of the spec mailing list. You know where I stand on this. It would be good to hear the spectrum of opinions.
>> 
>>  
>> 
>> Regards,
>> 
>> Ganesh
>> 
>> On 10 August 2012 00:28, Kelly Grizzle <[email-masked]> wrote:
>> 
>> Thanks Emmanuel.  I had started writing up a similar response.  As you suggest, storing this information in a mapping table outside of the SCIM spec is a great way to enable this solution.  Part of the key here is that SCIM is just a piece of the architecture for this solution, and is only responsible for the transport layer between domains.
>> 
>>  
>> 
>> You could also model these ID mappings in the SCIM user as an extension but would probably not want to expose these externally.  Here is an example of how to model the end state of the false positive scenario (splitting a user):
>> 
>>  
>> 
>> | Internal Entity ID | External Domain ID | External Entity ID | Primary flag |
>> 
>> This could be represented as two SCIM users that contain information about the entities on other domains.
>> 
>>  
>> 
>> {
>> 
>>   "schemas": ["urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:federation:1.0"],
>> 
>>   "id": "9caf78aac3d6",
>> 
>>   "schemas": ["urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:federation:1.0"],
>> 
>>   "id": "a99a5feba839",
>> 
>> In the second user, the linkedUsers attribute would be empty until the split user was synced to domain 2.
>> 
>>  
>> 
>>  
>> 
>> Similarly, the false negative use case (merging two users) looked like this at the end:
>> 
>>  
>> 
>> | Internal Entity ID | External Domain ID | External Entity ID | Primary flag |
>> 
>>   "schemas": ["urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:federation:1.0"],
>> 
>>   "id": "9caf78aac3d6",
>> 
>> Regarding unique identifiers for multi-valued attributes there is a trade-off involved.  On one hand this makes PATCH semantics easier.  On the other hand it puts extra burden on service providers.  Since the inception of SCIM, a key goal has been to foster adoption by service providers by making things fit easily onto existing systems.  IMO the value gained by unique identifiers for multi-valued attributes is not worth the demands put on a service provider.  I also think that vendors that have a non-SCIM-compliant API will choose to keep things that way if the spec is too hard for them to implement.  In a green field environment we do have the luxury of mandating a model to make certain operations more elegant.  However, we can’t ignore legacy systems.
>> 
>>  
>> 
>> --Kelly
>> 
>>  
>> 
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of Emmanuel Dreux
>> Sent: Thursday, August 09, 2012 3:18 AM
>> To: Ganesh and Sashi Prasad; Kelly Grizzle
>> Cc: [email-masked]
>> Nothing prevents you in your SCIM implementation (client or server) to generate a unique identifier for each synchronized object and maintain an internal mapping table ( you would have to map group membership as well).
>> 
>>  
>> 
>> As we didn’t find an immutable uniqueID in AD systems (DN,samAccountName, UPN) are subject to change (even objectGuid can change if an AD domain is migrated), we decided to generate and maintain an internal table of ids. This fits your requirements as it hides internal ids.
>> 
>>  
>> 
>> This was written in dotnet and we have started a project to rewrite our SCIM stack in PHP and will give it to the Open Source community. This implementation will have a parameter : AllocateIds versus UseExistingIDs.
>> 
>> This will give the choice of “hiding” internalIDs or use them as unique ID.
>> 
>>  
>> 
>> You can also implement such feature without violating the SCIM specs, or without asking to include it in the specs.
>> 
>>  
>> 
>> --
>> 
>> Regards,
>> 
>> Emmanuel Dreux
>> 
>> http://www.cloudiway.com
>> 
>> Tel: +33 4 26 78 17 58
>> 
>> De : Ganesh and Sashi Prasad [mailto:[email-masked]] 
>> Envoyé : jeudi 9 août 2012 03:35
>> À : Kelly Grizzle
>> Cc : [email-masked]
>> Objet : Re: [scim] SCIM Protocol - 3 suggestions for improvement
>> 
>>  
>> 
>> Hi Kelly,
>> Thanks for your response. Let me first respond in brief to the two main points you have made, and then elaborate on the first.
>> 1.      Why should domains not expose their internal identifiers to other domains?
>> a.
>> We are designing a protocol for a federated system of domains, where all domains are co-equal peers. (In physics too, N-body problems are much harder than 2-body problems. :-) Therefore, assuming that there are only two players in the interaction makes this tightly coupled in a number of ways. We should rely on messaging and notification, with encapsulation of domain-specific data.
>> b.
>> In any non-trivial data store, there will always be the ongoing need to merge and split identities as and when “false negatives” and “false positives” are discovered. A domain should be able to handle this internal housekeeping freely, only notifying other domains when convenient. Mapping of internal identifiers to external ones and maintaining this mapping internally allows this loosely-coupled housekeeping to take place. Sharing internal identifiers (or otherwise outsourcing the mapping of internal to external identifiers) forces housekeeping activities to be done in lock-step across domains.
>> c.
>> Asynchronous interaction is not just a matter of a suitable wire protocol which can be designed later. The data model plays a crucial role in enabling or constraining such interaction. A tightly-coupled data model will force the use of synchronous interactions, and the exposure of internal identifiers is a key part of this tight coupling.
>> 2. The difficulty of assigning unique identifiers to the individual values of multi-valued attributes:
>> a.
>> I'm not belittling the effort involved in migrating legacy data stores to such a model. However, in the larger historical context of cross-domain identity management, we are really at the very early stages. If a relatively new discipline and a brand new spec are held captive to legacy considerations, we are losing an opportunity to provide a clean and elegant model to subsequent users of the spec, and this will have repercussions over many years or even decades.
>> b.
>> If incumbent cloud providers find it hard to immediately adopt the dictionary model for existing multi-valued attributes, they can transition to this model by offering both “SCIM-compliant” and “non-SCIM-compliant” APIs to their customers and encouraging new customers to adopt the “SCIM-compliant” API. Legacy customers can be supported using a “non-SCIM-compliant” API for an arbitrarily long period and gradually migrated to the SCIM-compliant API. The logistics are not insurmountable, and shouldn't prevent the adoption of a dictionary model for multi-valued attributes.
>> Elaboration of Point 1:
>> When we consider federated identity across more than one domain, we have to assume that domains are not necessarily master-slave in their interaction. The most generic interaction model is peer-to-peer, where entity lifecycle events within a domain are notified to other domains (when necessary) in an asynchronous manner (i.e., through messaging) and the other domains are free to respond to these events in an appropriate manner and at a time of their convenience.
>> A key set of lifecycle events for an entity is the merging and splitting of identity that is often required.
>> The question “Is this one entity?” can be answered either yes (positive) or no (negative). But sometimes, we can discover false positives and false negatives in our data stores.
>> Consider a case where customers sign up online, and two customers who are privacy-conscious enter fake IDs such as “John Smith”, and also use the same date of birth (say, 1 Jan 1970) or similar attributes. The front-end application may make an intelligent (but incorrect) guess that these two persons are the same, and re-assign the same identifier to the second person. This is a false positive. They appear to be the same entity, but they're actually different. When the error is discovered, the identities will need to be split, with a new identifier generated for one of them.
>> Consider the opposite case where a customer signs up through two different portals or in two different sessions, using the names “JSmith” and “JohnS”. It is very likely that they will be treated as two different customers and assigned two unique identifiers. This is a false negative. They appear to be two entities, but are actually the same. At a later stage, when the error is discovered, the identities will have to be merged, and one of the identifiers will have to be dropped.
>> These are not theoretical use cases. They form a significant proportion of the user base in most large Web-facing applications. Let's see how these can be managed in a federated way by mapping internal identifiers to external ones and only exposing external identifiers to other domains.
>> a. False positives:
>> When requesting the provisioning of this entity in Domain 2, the following ID is returned by Domain 2: ff487230b3a0.
>> Domain 1 then maintains the following in a mapping table and uses it for translation when talking to Domain 2, taking care never to expose its internal identifier:
>> | Internal Entity ID | External Domain ID | External Entity ID | Primary flag |
>> When the false positive is discovered and the entity is split, Domain 1 creates a new internal identifier and now has the following entity information.
>> This second entity with its own internal identifier is invisible to Domain 2, and this is by design. Communication about the original entity takes place as before by mapping “9caf78aac3d6” to “ff487230b3a0” and vice-versa. At some convenient time (importantly, this doesn't have to be at the time the split happens), Domain 2 can be requested to provision a second entity, and when it responds with an identifier of “7a87f27c1dd8”, this can go into the mapping table as a new record associated with the second entity's internal identifier.
>> | Internal Entity ID | External Domain ID | External Entity ID | Primary flag |
>> Domain 2 is not even aware that a split has happened, and the provisioning that it does is not in lockstep with the split in identity that occurred in Domain 1.
>> (What is the “Primary flag” used for? We'll see when we cover the treatment of false negatives.)
>> b. False negatives:
>> Domain 1 has the following information about what it thinks are two distinct customers in its data store:
>> When requesting the provisioning of these entities in Domain 2, the following IDs are returned by Domain 2: ff487230b3a0 and 41206cc97c8b.
>> Domain 1 then maintains the following in a mapping table and uses it for translation when talking to Domain 2, taking care never to expose its internal identifiers:
>> | Internal Entity ID | External Domain ID | External Entity ID | Primary flag |
>> When the false negative is discovered and the two entities are merged, Domain 1 drops one of the internal identifiers and rationalises the name of the customer (say, to “John Smith”). Let's say it retains the first ID “9caf78aac3d6” and drops the second “273d36e30d09”.
>> | Internal Entity ID | External Domain ID | External Entity ID | Primary flag |
>> Now two external identifiers map to the same internal one, so inbound communication from Domain 2 can be unambi
>

---

From: Ganesh and Sashi Prasad <[email-masked]>
Date: Sat, 11 Aug 2012 18:30:29 +1000

>  For the multi-value example you gave you used the value as the attribute
name key.

Now I'm confused :-). I don't believe any of my examples ever used a value
as the key.

Could you please show me which example you mean, and which parts of it you
believe to be the value?

Regards,
Ganesh

On 11 August 2012 13:59, Phil Hunt <[email-masked]> wrote:

>> Pro 1. The API to manipulate resources becomes so much cleaner,
>> consistent and intuitive when every individual attribute value gets its own
>> ID.
>>
>>> “2. When dealing with multi-valued attributes of a resource (expressed
>>> as arrays in JSON), they must be converted from an array into a dictionary
>>>  >  storing this information in a mapping table outside of the SCIM
>>> As we didn’t find an immutable uniqueID in AD systems
>>> (DN,samAccountName, UPN) are subject to change (even objectGuid can change
>>> if an AD domain is migrated), we decided to generate and maintain an
>>> internal table of ids. This fits your requirements as it hides internal ids.
>>>
>>>
>>>
>>> Asynchronous interaction is not just a matter of a suitable wire
>>> protocol which can be designed later. The data model plays a crucial role
>>> in enabling or constraining such interaction. A tightly-coupled data model
>>> I'm not belittling the effort involved in migrating legacy data stores
>>> to such a model. However, in the larger historical context of cross-domain
>>> Consider a case where customers sign up online, and two customers who
>>> are privacy-conscious enter fake IDs such as “John Smith”, and also use the
>>> communication from Domain 2 can be unambi
>>>

---

From: Phil Hunt <[email-masked]>
Date: Sat, 11 Aug 2012 09:12:35 -0600

Ganesh,

Here's the sample that concerned me...
>            "key" : "members.2819c223-7f76-453a-919d-413861904646"

You gave other examples of an attribute with an identifier that matched that value or of identifiers that were additional unique keys.

Given that multi-values must be each unique, I don't see the point of the extra indexing to support this. Just use the value as the item you wish to delete.

I agree, the delete value operation could be more explicit and clear in general.

Phil

@independentid
www.independentid.com
[email-masked]

On 2012-08-11, at 2:30 AM, Ganesh and Sashi Prasad wrote:

> Now I'm confused :-). I don't believe any of my examples ever used a value as the key.
> 
> Could you please show me which example you mean, and which parts of it you believe to be the value?
> 
> Regards,
> Ganesh 
>

---

From: Ganesh and Sashi Prasad <[email-masked]>
Date: Sun, 12 Aug 2012 01:50:19 +1000

Phil,

The reason we cannot use the value itself to identify an element is that
this method will only work for simple elements, not for nested structures.
i.e., if we had an array of dictionaries (e.g., we had to record an array
of addresses for each customer, with each address element having
sub-elements like street number, street name, suburb, etc.), then it would
be clumsy to supply the entire value of the array element because it's
itself a dictionary. Creating a unique key for each element scales better.

Regards,
Ganesh

On 12 August 2012 01:12, Phil Hunt <[email-masked]> wrote:

> You gave other examples of an attribute with an identifier that matched
> that value or of identifiers that were additional unique keys.
>
> Given that multi-values must be each unique, I don't see the point of the
> extra indexing to support this. Just use the value as the item you wish to
> delete.
>
>>> (c) Performing bulk operations, where we simply use HTTP verbs instead
>>> of the specialised (and semantically less ambiguous) verbs I suggested for
>>> Pro 4: New (not incumbent) cloud providers will probably find this
>>> easier to implement because they have no legacy. They will probably use
>>> some form of NoSQL database and won't be constrained by the limitations of
>>> LDAP directories.
>>>
>>> Cons:
>>>
>>> Con 1: Incumbent cloud providers with existing data stores in a
>>> directory format (where multi-valued attributes are stored as
>>> comma-separated values under a single attribute node) will find it
>>> difficult to migrate to this model and store each attribute value as a
>>> sub-node with its own key. This will "hinder adoption of the spec", which
>>> is what you fear.
>>>
>>> In other words, we're debating interface complexity (current spec)
>>> versus implementation complexity (my suggestion). Both can hinder adoption
>>> of the spec by different parties.
>>>
>>> This is an issue where we need the opinions of many people, and they
>>> need to state their affiliations. If most people weighing in belong to
>>> incumbent SPs and they vote in favour of interface complexity to avoid
>>> implementation complexity, then it means the spec is not doing a good job
>>> of balancing the interests of various groups. I think we should also poll
>>> client organisations to see what they would want.
>>>
>>> (Gartner is trusted by enterprise clients to evaluate the capabilities
>>> of vendors (SPs). I believe Gartner should take the lead in representing
>>>> I'm not tracking your coupling concern.  The client can search and
>>>> hence retrieve resources on any attribute it chooses, externalId or
>>>> otherwise.  Nothing mandates use of externalId.
>>>>
>>>>
>>>>
>>>> I see what you are saying. I think scim gets its current simplicity
>>>> from its single owner hub spoke model implementing tight coupling.
>>>>
>>>>
>>>> IMHO loose coupling is a much more complex solution. The reality is
>>>> that each end-point has value to contribute and thus the single-owner model
>>>> will eventually need to become multi-owner or multi-hub.
>>>>
>>>>
>>>> *From:* [email-masked] [mailto:[email-masked]] *On
>>>> Behalf Of *Emmanuel Dreux
>>>> You can also implement such feature without violating the SCIM specs,
>>>> or without asking to include it in the specs.
>>>>
>>>>
>>>> --
>>>>
>>>> Regards,
>>>>
>>>> Emmanuel Dreux
>>>>
>>>> http://www.cloudiway.com
>>>>
>>>> Tel: +33 4 26 78 17 58
>>>>
>>>> We are designing a protocol for a federated system of domains, where
>>>> all domains are co-equal peers. (In physics too, N-body problems are much
>>>> When we consider federated identity across more than one domain, we
>>>> have to assume that domains are not necessarily master-slave in their
>>>> A key set of lifecycle events for an entity is the merging and
>>>> splitting of identity that is often required.
>>>>
>>>> The question “Is this one entity?” can be answered either yes
>>>> (positive) or no (negative). But sometimes, we can discover false positives
>>>> and false negatives in our data stores.
>>>>
>>>> Domain 1 then maintains the following in a mapping table and uses it
>>>> for translation when talking to Domain 2, taking care never to expose its
>>>> internal identifier:
>>>>
>>>> Domain 1 then maintains the following in a mapping table and uses it
>>>> for translation when talking to Domain 2, taking care never to expose its
>>>> internal identifiers:
>>>>

---

From: Phil Hunt <[email-masked]>
Date: Sat, 11 Aug 2012 10:04:51 -0600

That's a huge imposition on the client. 

Not sure about your arg on server side. It depends on the store implemetation i suppose. 

Phil

On 2012-08-11, at 9:50, Ganesh and Sashi Prasad <[email-masked]> wrote:

> Phil,
> 
> The reason we cannot use the value itself to identify an element is that this method will only work for simple elements, not for nested structures. i.e., if we had an array of dictionaries (e.g., we had to record an array of addresses for each customer, with each address element having sub-elements like street number, street name, suburb, etc.), then it would be clumsy to supply the entire value of the array element because it's itself a dictionary. Creating a unique key for each element scales better.
> 
> Regards,
> Ganesh
>

---

From: Ganesh and Sashi Prasad <[email-masked]>
Date: Sun, 12 Aug 2012 02:28:01 +1000

>  That's a huge imposition on the client.

Why? Any GET will return the resource representation with all keys, so the
client can always discover the key to an attribute value at any time. The
client doesn't have to store the keys if it doesn't want to. I'm not
denying that there is some effort to be expended in return for the
simplification in the API, but I wouldn't call it "huge".

And if the interface is truly RESTful and follows the HatEoAS principle, it
will return hyperlinks for every sub-resource that may be manipulated as
the next step after the GET, so it could even be a set of readymade links
to traverse to perform standard operations.

I believe the XML equivalents look like these: <link rel="REPLACE"
href="".../>, <link rel="RETIRE" href="" .../>, etc.

Regards,
Ganesh

On 12 August 2012 02:04, Phil Hunt <[email-masked]> wrote:

>>> For repeating (multi-valued) attributes, I'm suggesting that there be
>>> new keys for each individual value, otherwise they are impossible to
>>> PLACE a value at the logical location implied by the fully-qualified
>>> key. If there is already a key with that name, return a "409 Conflict".
>>>
>>>> Have I summed up the Pros and Cons correctly? I'm biased of course, so
>>>> I could have missed a Con or hyped a Pro :-).
>>>>
>>>>> I'm a bit surprised that you're implying "tight coupling == simple"
>>>>> and "loose coupling == complex". That's contrary to my experience.
>>>>>
>>>>>
>>>>> >  Regarding unique identifiers for multi-valued attributes there is
>>>>> a trade-off involved.  On one hand this makes PATCH semantics easier.  On
>>>>> the other hand it puts extra burden on service providers.
>>>>>
>>>>>
>>>>> You could also model these ID mappings in the SCIM user as an
>>>>> extension but would probably not want to expose these externally.  Here is
>>>>> an example of how to model the end state of the false positive scenario
>>>>> (splitting a user):
>>>>>
>>>>>
>>>>> This was written in dotnet and we have started a project to rewrite
>>>>> our SCIM stack in PHP and will give it to the Open Source community. This
>>>>> Thanks for your response. Let me first respond in brief to the two
>>>>> main points you have made, and then elaborate on the first.
>>>>>
>>>>> In any non-trivial data store, there will always be the ongoing need
>>>>> to merge and split identities as and when “false negatives” and “false
>>>>> These are not theoretical use cases. They form a significant
>>>>> proportion of the user base in most large Web-facing applications. Let's
>>>>> see how these can be managed in a federated way by mapping internal
>>>>> identifiers to external ones and only exposing external identifiers to
>>>>> other domains.
>>>>>
>>>>> a. False positives:
>>>>>
>>>>> When the false positive is discovered and the entity is split, Domain
>>>>> 1 creates a new internal identifier and now has the following entity
>>>>> information.
>>>>>

---

From: Kelly Grizzle <[email-masked]>
Date: Sun, 12 Aug 2012 01:53:51 +0000

Ganesh,

This is exactly how PATCH works in SCIM 1.0.  Multi-valued attributes that have a value sub-attribute can be removed by specifying only the value since it is unique.  Multi-valued attributes that don't have a value sub-attribute (eg - address) have to specified completely for uniqueness.  As I have said before, I am very opposed to adding a unique identifier to each element in a multi-valued collection due to the burden it will put on SPs.  Is it elegant?  No.  Is it functional?  Yes.  Will this non-elegance affect adoption?  My opinion is that adding unique keys to each element will have a much more detrimental effect on adoption.

I do believe that in general PATCH can be made more intuitive without adding uids to each element.  The verbs that you propose make sense.  There is also a JSON Patch informational draft in the IETF that is interesting - http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-02.  It relies on a JSON Pointer draft which uses index-based addressing for multi-valued attributes.  I think that this is something that should be looked at within the WG and I would be willing to lead this effort.

I'm curious if anyone else in the WG is in favor of unique identifiers for every multi-valued element.

--Kelly

________________________________
From: [email-masked] [[email-masked]] on behalf of Ganesh and Sashi Prasad [[email-masked]]
Sent: Saturday, August 11, 2012 10:50 AM
To: Phil Hunt
Cc: [email-masked]
Subject: Re: [scim] scim Digest, Vol 8, Issue 24

Phil,

Regards,
Ganesh

On 12 August 2012 01:12, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:
Ganesh,

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com<http://example.com/> Accept: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" {
"operations" : [
{
"RETIRE" : {
"key" : "members.2819c223-7f76-453a-919d-413861904646"
}
}
] }

Phil

@independentid
www.independentid.com<http://www.independentid.com>
[email-masked]<mailto:[email-masked]>

Regards,
Ganesh

On 11 August 2012 13:59, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:

Phil

I don't believe so.

Simple attribute:

Key: "dob"
Value: "01 Jan 1970"

Composite attribute:

Key: "address.suburb"
Value: "East Camden"

Multi-valued attribute:

Key: "emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd902"
Value: "[email-masked]<mailto:[email-masked]>"

Regards,
Ganesh

On 11 August 2012 10:38, <[email-masked]<mailto:[email-masked]>> wrote:
If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to

Send scim mailing list submissions to
        [email-masked]<mailto:[email-masked]>

To subscribe or unsubscribe via the World Wide Web, visit
        https://www.ietf.org/mailman/listinfo/scim
or, via email, send a message with subject or body 'help' to
        [email-masked]<mailto:[email-masked]>

You can reach the person managing the list at
        [email-masked]<mailto:[email-masked]>

Today's Topics:

---------- Forwarded message ----------
From: Phil Hunt <[email-masked]<mailto:[email-masked]>>
To: Ganesh and Sashi Prasad <[email-masked]<mailto:[email-masked]>>
Cc: "Diodati, Mark" <[email-masked]<mailto:[email-masked]>>, Emmanuel Dreux <[email-masked]<mailto:[email-masked]>>, Trey Drake <[email-masked]<mailto:[email-masked]>>, Kelly Grizzle <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Fri, 10 Aug 2012 17:36:54 -0700
Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement
Ganesh,

Phil

Let's discuss that now.

Pros:

   PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce
   Host: example.com<http://example.com/>
   Accept: application/json
   Authorization: Bearer h480djs93hd8
   ETag: W/"a330bc54f0671c9"

   {

   PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce
   Host: example.com<http://example.com/>
   Accept: application/json
   Authorization: Bearer h480djs93hd8
   ETag: W/"a330bc54f0671c9"

   {

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com<http://example.com/> Accept: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" {
"operations" : [
{
"RETIRE" : {
"key" : "members.2819c223-7f76-453a-919d-413861904646"
}
}
] }
Here's how I suggest deleting ALL members from a group:

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com<http://example.com/> Accept: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" {
"operations" : [
{
"RETIRE" : {
"key" : "members"
}
}
] }

Cons:

Regards,
Ganesh

On 11 August 2012 01:35, Diodati,Mark <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ganesh,

From: Trey Drake [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, August 10, 2012 9:51 AM

To: Ganesh and Sashi Prasad
Cc: [email-masked]<mailto:[email-masked]>; Emmanuel Dreux; Kelly Grizzle; Phil Hunt

Ganesh,

Phil,

Regards,

Ganesh

On 10 August 2012 07:53, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:

Phil

Am I making sense?

Regards,
Ganesh
On 10 August 2012 00:28, Kelly Grizzle <[email-masked]<mailto:[email-masked]>> wrote:
Thanks Emmanuel.  I had started writing up a similar response.  As you suggest, storing this information in a mapping table outside of the SCIM spec is a great way to enable this solution.  Part of the key here is that SCIM is just a piece of the architecture for this solution, and is only responsible for the transport layer between domains.

{

{

{

--Kelly

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Emmanuel Dreux
Sent: Thursday, August 09, 2012 3:18 AM
To: Ganesh and Sashi Prasad; Kelly Grizzle
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement

Hi Ganesh,

--
Regards,
Emmanuel Dreux
http://www.cloudiway.com<http://www.cloudiway.com/>
Tel: +33 4 26 78 17 58<tel:%2B33%204%2026%2078%2017%2058>
Mobile: +33 6 47 81 26 70<tel:%2B33%206%2047%2081%2026%2070>
skype: Emmanuel.Dreux

De : Ganesh and Sashi Prasad [mailto:[email-masked]]
Envoyé : jeudi 9 août 2012 03:35
À : Kelly Grizzle
Cc : [email-masked]<mailto:[email-masked]>
Objet : Re: [scim] SCIM Protocol - 3 suggestions for improvement

Hi Kelly,

a.

b.

c.

a.

b.

Elaboration of Point 1:

a. False positives:

b. False negatives:

scim mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/scim

_______________________________________________
scim mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/scim

---

From: Ganesh and Sashi Prasad <[email-masked]>
Date: Sun, 12 Aug 2012 12:53:08 +1000

>  Multi-valued attributes that don't have a value sub-attribute (eg -
address) have to specified completely for uniqueness.

That's exactly the point. How do we "specify completely for uniqueness"?

In the example below, how are you proposing that the following element be
updated if we can't use positional indexes?

addresses[1].street-number = "243"

User object:

{
  ...
  addresses: [
    {
      "type" : "home",
      "street-number" : "35",
      "street-name" : "High Road",
      "suburb" : "East Camden",
      "postcode" : "5346",
      "state" : "SA",
      "country" : "Australia"
    },
    {
      "type" : "office",
      "street-number" : "213",
      "street-name" : "Main Street",
      "suburb" : "Adelaide",
      "postcode" : "5000",
      "state" : "SA",
      "country" : "Australia"
    }
  ]
}

It's impractical to use the value because it's the whole dictionary element:

{
  "type" : "office",
  "street-number" : "213",
  "street-name" : "Main Street",
  "suburb" : "Adelaide",
  "postcode" : "5000",
  "state" : "SA",
  "country" : "Australia"
}

With my proposal, the "addresses" array gets converted to a dictionary, and
then we have a stable way of referencing this element:

addresses.3cbaaff8e84e.street-number = "243"

{
  ...
  addresses: {
    "d6ea365462f5" :
    {
      "type" : "home",
      "street-number" : "35",
      "street-name" : "High Road",
      "suburb" : "East Camden",
      "postcode" : "5346",
      "state" : "SA",
      "country" : "Australia"
    },
    "3cbaaff8e84e" :
    {
      "type" : "office",
      "street-number" : "213",
      "street-name" : "Main Street",
      "suburb" : "Adelaide",
      "postcode" : "5000",
      "state" : "SA",
      "country" : "Australia"
    }
  }
}

If you're proposing one mechanism for composite attributes and another
mechanism for simple attributes, I would suggest that's actually more
complex than adopting a single mechanism that works the same way for _all_
attributes. Remember that a lot of the administration is probably going to
be scripted rather than done by hand, and having two mechanisms (depending
on whether the attribute is simple or composite) will complicate every
script that has to be written.

There's a lot of talk about the "burden" on the SPs, but I believe this is
overblown. Is there any SP representative in this WG who can tell us what
this proposal will actually entail for them?

Regards,
Ganesh

On 12 August 2012 11:53, Kelly Grizzle <[email-masked]> wrote:

>  Ganesh,
>
>  This is exactly how PATCH works in SCIM 1.0.  Multi-valued attributes
> that have a value sub-attribute can be removed by specifying only the value
> since it is unique.  Multi-valued attributes that don't have a value
> sub-attribute (eg - address) have to specified completely for uniqueness.
>  As I have said before, I am very opposed to adding a unique identifier to
> each element in a multi-valued collection due to the burden it will put on
> SPs.  Is it elegant?  No.  Is it functional?  Yes.  Will this non-elegance
> affect adoption?  My opinion is that adding unique keys to each element
> will have a much more detrimental effect on adoption.
>
>  I do believe that in general PATCH can be made more intuitive without
> adding uids to each element.  The verbs that you propose make sense.  There
> is also a JSON Patch informational draft in the IETF that is interesting -
> http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-02.  It relies
> on a JSON Pointer draft which uses index-based addressing for multi-valued
> attributes.  I think that this is something that should be looked at within
> the WG and I would be willing to lead this effort.
>
> *From:* [email-masked] [[email-masked]] on behalf of Ganesh
> and Sashi Prasad [[email-masked]]
> *Sent:* Saturday, August 11, 2012 10:50 AM
> *To:* Phil Hunt
> *Cc:* [email-masked]
> *Subject:* Re: [scim] scim Digest, Vol 8, Issue 24
>
>  Phil,
>
>>  Given that multi-values must be each unique, I don't see the point of
>> the extra indexing to support this. Just use the value as the item you wish
>> to delete.
>>
>>>  INCLUDE to a collection and specify only the value. The key is
>>> generated and returned. The fully-qualified key is
>>>>  Have I summed up the Pros and Cons correctly? I'm biased of course,
>>>> so I could have missed a Con or hyped a Pro :-).
>>>>
>>>>  Here's what we need to discuss - Do the Pros make the suggestion
>>>> worth adopting in spite of the Cons, or are the Cons so great that it's
>>>> best to leave the spec as it is?
>>>>
>>>>  (Gartner is trusted by enterprise clients to evaluate the
>>>> capabilities of vendors (SPs). I believe Gartner should take the lead in
>>>> representing client interests in this working group rather than those of
>>>> incumbent vendors, which is what it seems like to me. Correct me if I'm
>>>> being unfair.)
>>>>
>>>>  Regards,
>>>> Ganesh
>>>>
>>>>
>>>>

---

From: Kelly Grizzle <[email-masked]>
Date: Sun, 12 Aug 2012 03:25:27 +0000

> how are you proposing that the following element be updated if we can't use positional indexes?

My proposal is what is currently in the spec - http://tools.ietf.org/html/draft-scim-api-00#section-3.3.2.

      Attributes that do not have a value Sub-Attribute or that have a

      non-unique value Sub-Attribute are matched by comparing all

      Sub-Attribute values from the PATCH request body to the Sub-Attribute

      values of the Resource.

Another way to say this is "the whole dictionary element", which I don't believe is impractical.  I understand your proposal and the implications of using uid for each element vs. not.  It just comes down to a difference of opinion.

--Kelly

________________________________
From: Ganesh and Sashi Prasad [[email-masked]]
Sent: Saturday, August 11, 2012 9:53 PM
To: Kelly Grizzle
Cc: Phil Hunt; [email-masked]
Subject: Re: [scim] scim Digest, Vol 8, Issue 24

>  Multi-valued attributes that don't have a value sub-attribute (eg - address) have to specified completely for uniqueness.

In the example below, how are you proposing that the following element be updated if we can't use positional indexes?

User object:

{
  ...
  addresses: [
    {
      "type" : "home",
      "street-number" : "35",

{
  "type" : "office",
  "street-number" : "213",

With my proposal, the "addresses" array gets converted to a dictionary, and then we have a stable way of referencing this element:

{
  ...
  addresses: {
    "d6ea365462f5" :
    {
      "type" : "home",
      "street-number" : "35",

If you're proposing one mechanism for composite attributes and another mechanism for simple attributes, I would suggest that's actually more complex than adopting a single mechanism that works the same way for _all_ attributes. Remember that a lot of the administration is probably going to be scripted rather than done by hand, and having two mechanisms (depending on whether the attribute is simple or composite) will complicate every script that has to be written.

There's a lot of talk about the "burden" on the SPs, but I believe this is overblown. Is there any SP representative in this WG who can tell us what this proposal will actually entail for them?

Regards,
Ganesh

On 12 August 2012 11:53, Kelly Grizzle <[email-masked]<mailto:[email-masked]>> wrote:
Ganesh,

--Kelly

From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] on behalf of Ganesh and Sashi Prasad [[email-masked]<mailto:[email-masked]>]

Phil,

Regards,
Ganesh

Phil

@independentid

Regards,
Ganesh

Phil

I don't believe so.

Simple attribute:

Key: "dob"
Value: "01 Jan 1970"

Composite attribute:

Key: "address.suburb"
Value: "East Camden"

Multi-valued attribute:

Regards,
Ganesh

Today's Topics:

---------- Forwarded message ----------
From: Phil Hunt <[email-masked]<mailto:[email-masked]>>
To: Ganesh and Sashi Prasad <[email-masked]<mailto:[email-masked]>>
Cc: "Diodati, Mark" <[email-masked]<mailto:[email-masked]>>, Emmanuel Dreux <[email-masked]<mailto:[email-masked]>>, Trey Drake <[email-masked]<mailto:[email-masked]>>, Kelly Grizzle <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Fri, 10 Aug 2012 17:36:54 -0700
Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement
Ganesh,

Phil

Let's discuss that now.

Pros:

   {

   {

Cons:

Regards,
Ganesh

Ganesh,

Phil,

Regards,

Ganesh

Phil

Am I making sense?

Regards,
Ganesh

{

{

{

--Kelly

Hi Ganesh,

Hi Kelly,

a.

b.

c.

a.

b.

Elaboration of Point 1:

a. False positives:

b. False negatives:

scim mailing list

---

From: Ganesh and Sashi Prasad <[email-masked]>
Date: Sun, 12 Aug 2012 14:28:39 +1000

>  It just comes down to a difference of opinion.

Yes, but do consider that the unique key approach allows uniformity of
treatment regardless of level in the hierarchy for _all_ operations - add,
modify and delete, with "modify" having three sub-elements of its own (add
attribute, modify attribute, delete attribute).

INCLUDE and RETIRE (add a new dictionary element to this collection, or
remove the entire collection):
key = "addresses"

REPLACE, FORCE and RETIRE (update or remove one complete dictionary element
in the collection):
key = "addresses.3cbaaff8e84e"

PLACE and FORCE (introduce a new dictionary element with a pre-assigned
unique key - not the client's internal key, of course):
key = "addresses.7956063c59a1"

REPLACE, FORCE and RETIRE (update of the dictionary element, updating or
removing an _existing_ sub-element):
key = "addresses.3cbaaff8e84e.street-number"
key = "addresses.3cbaaff8e84e.street-name"
...
key = "addresses.3cbaaff8e84e.country"

PLACE and FORCE (update of the dictionary element, introducing a _new_
sub-element):
key = "addresses.3cbaaff8e84e.city"

INCLUDE (update of the dictionary element, introducing one or more _new_
values for a multi-valued sub-element):
key = "addresses.3cbaaff8e84e.available-services"
value = ["cable", "ADSL"]
(This in turn returns keys for the two new dictionary elements that it
creates.)

There's just one standard syntax for all of these operations. There's a bit
of an initial conceptual hurdle for a reader of the spec to grok this
approach and also a one-time implementation hurdle for the SPs, but
thereafter it's simple and elegant.

Once again I'd like to ask, is there any SP representative on this working
group who can tell us exactly what it would entail for them to implement a
unique-key-per-value scheme? I want to understand how much of a burden this
really is, because I reckon this would knock a few pages off the spec
document (which is another index of simplicity).

Regards,
Ganesh

On 12 August 2012 13:25, Kelly Grizzle <[email-masked]> wrote:

>  My proposal is what is currently in the spec -
> http://tools.ietf.org/html/draft-scim-api-00#section-3.3.2.
>
>  Another way to say this is "the whole dictionary element", which I don't
> believe is impractical.  I understand your proposal and the implications of
> using uid for each element vs. not.  It just comes down to a difference of
> opinion.
>
>  --Kelly
>
> *From:* Ganesh and Sashi Prasad [[email-masked]]
> *Sent:* Saturday, August 11, 2012 9:53 PM
> *To:* Kelly Grizzle
> *Cc:* Phil Hunt; [email-masked]
>
>  In the example below, how are you proposing that the following element
> be updated if we can't use positional indexes?
>
>  With my proposal, the "addresses" array gets converted to a dictionary,
> and then we have a stable way of referencing this element:
>
>  There's a lot of talk about the "burden" on the SPs, but I believe this
> is overblown. Is there any SP representative in this WG who can tell us
> what this proposal will actually entail for them?
>
>  Regards,
> Ganesh
>
> On 12 August 2012 11:53, Kelly Grizzle <[email-masked]>wrote:
>
>>  Ganesh,
>>
>> *From:* [email-masked] [[email-masked]] on behalf of
>> Ganesh and Sashi Prasad [[email-masked]]
>>  The reason we cannot use the value itself to identify an element is
>> that this method will only work for simple elements, not for nested
>> structures. i.e., if we had an array of dictionaries (e.g., we had to
>> record an array of addresses for each customer, with each address element
>> having sub-elements like street number, street name, suburb, etc.), then it
>> would be clumsy to supply the entire value of the array element because
>> it's itself a dictionary. Creating a unique key for each element scales
>> better.
>>
>>  Regards,
>> Ganesh
>>
>>>  You gave other examples of an attribute with an identifier that
>>> matched that value or of identifiers that were additional unique keys.
>>>
>>>>  RETIRE an attribute or a collection given its fully-qualified key.
>>>> The implementation will determine whether the attribute will disappear
>>>> entirely or will exist holding a null value (the blank string "" or the
>>>> empty object {} ).
>>>>
>>>>  I'll explain in a separate post why we need operation verbs like
>>>> these that are independent of the HTTP verbs.
>>>>
>>>>  Regards,
>>>> Ganesh
>>>>
>>>>> On 11 August 2012 01:35, Diodati,Mark <[email-masked]>wrote:
>>>>>
>>>>>>  Hi Ganesh,
>>>>>>
>>>>>>
>>>>>> “2. When dealing with multi-valued attributes of a resource
>>>>>> (expressed as arrays in JSON), they must be converted from an array into a
>>>>>> dictionary with unique keys (UUIDs generated by the cloud provider when the
>>>>>> attribute is created). Without unique keys for every attribute value of a
>>>>>> resource, manipulating it will be clumsy and inelegant.”
>>>>>>
>>>>>>
>>>>>> 1. The client enterprise can still send its internal ID as part of
>>>>>> the resource body, inside some attribute defined by them (but not defined
>>>>>> by the protocol). Let's say they call it 'myID'.
>>>>>>
>>>>>> Since myID is a candidate key, the server will return exactly one
>>>>>> URI, which is the canonical URI for the resource
>>>>>>
>>>>>> I wasn't suggesting that the mapping table be part of the SCIM spec.
>>>>>> I provided that example to illustrate that splitting and merging identities
>>>>>> Thanks Emmanuel.  I had started writing up a similar response.  As
>>>>>> you suggest, storing this information in a mapping table outside of the
>>>>>> SCIM spec is a great way to enable this solution.  Part of the key here is
>>>>>> that SCIM is just a piece of the architecture for this solution, and is
>>>>>> only responsible for the transport layer between domains.
>>>>>>
>>>>>>
>>>>>> Nothing prevents you in your SCIM implementation (client or server)
>>>>>> to generate a unique identifier for each synchronized object and maintain
>>>>>> an internal mapping table ( you would have to map group membership as well).
>>>>>>
>>>>>>
>>>>>> I'm not belittling the effort involved in migrating legacy data
>>>>>> stores to such a model. However, in the larger historical context of
>>>>>> cross-domain identity management, we are really at the very early stages.
>>>>>> If a relatively new discipline and a brand new spec are held captive to
>>>>>> legacy considerations, we are losing an opportunity to provide a clean and
>>>>>> elegant model to subsequent users of the spec, and this will have
>>>>>> repercussions over many years or even decades.
>>>>>>
>>>>>> b.
>>>>>>
>>>>>> When the false negative is discovered and the two entities are
>>>>>> merged, Domain 1 drops one of the internal identifiers and rationalises the
>>>>>> name of the customer (say, to “John Smith”). Let's say it retains the first
>>>>>> ID “9caf78aac3d6” and drops the second “273d36e30d09”.
>>>>>>

---

From: Ganesh and Sashi Prasad <[email-masked]>
Date: Sun, 12 Aug 2012 15:01:09 +1000

(I'm aware that I'm pushing very hard on this, and apologies if this is
putting anyone off. I think it's in the best interests of the spec to have
a robust (but respectful) discussion.)

Nested arrays are a great example of where the simplistic approach breaks
down. How can we specify that the first address now also has "Wi-fi" and
doesn't have the "cable" service anymore? With the current spec, we'd
struggle.

These are not esoteric examples. I work for a telco and this is
stock-standard information that we need to maintain about our customers.

{
  ...
  addresses: [
    {
      "type" : "home",
      "street-number" : "35",
      "street-name" : "High Road",
      ...
      "country" : "Australia",
      "available_services" : ["cable", "ADSL"]
    },
    {
      "type" : "office",
      "street-number" : "213",
      "street-name" : "Main Street",
      ...
      "country" : "Australia",
      "available_services: ["ADSL2+", "Wi-fi"]
    }
  ]
}

Here's how I believe it should be done:

PATCH /Users

{
  "operations" : [
    {
      "INCLUDE" : {
        "key" : "addresses.d6ea365462f5.available_services",
        "value" : "Wi-fi"
      },
      "RETIRE" : {
        "key" : "addresses.d6ea365462f5.available_services.9be6378dc303"
      }
    }
  ]
}

because the resource structure would be like this:

{
  ...
  addresses: {
    "d6ea365462f5" :
    {
      "type" : "home",
      "street-number" : "35",
      "street-name" : "High Road",
      ...
      "country" : "Australia",
      "available_services" : {
        "9be6378dc303" : "cable",
        "6aa1429eba34" : "ADSL"
      }
    },
    "3cbaaff8e84e" :
    {
      "type" : "office",
      "street-number" : "213",
      "street-name" : "Main Street",
      ...
      "country" : "Australia",
      "available_services: {
        "2beca1fdf3e5" : "ADSL2+",
        "8c3dcc204a33" : "Wi-fi"
      }
    }
  }
}

I think nested arrays are the clincher in favour of the
unique-key-per-value approach. The difference of opinion is then just
whether you think nested arrays are a common occurrence or not. I've just
provided an example from my current industry where it is.

Regards,
Ganesh

On 12 August 2012 14:28, Ganesh and Sashi Prasad <[email-masked]>wrote:

> REPLACE, FORCE and RETIRE (update or remove one complete dictionary
> element in the collection):
> There's just one standard syntax for all of these operations. There's a
> bit of an initial conceptual hurdle for a reader of the spec to grok this
> On 12 August 2012 13:25, Kelly Grizzle <[email-masked]>wrote:
>
>>  Another way to say this is "the whole dictionary element", which I
>> don't believe is impractical.  I understand your proposal and the
>> implications of using uid for each element vs. not.  It just comes down to
>> a difference of opinion.
>>
>>  --Kelly
>>
>>>>>  For composite attributes, the key employs dot notation to specify
>>>>> the fully-qualified attribute name, e.g., "address.postcode".
>>>>>
>>>>>  Composite attribute:
>>>>>
>>>>>  For repeating (multi-valued) attributes, I'm suggesting that there
>>>>> be new keys for each individual value, otherwise they are impossible to
>>>>>> Grizzle <[email-masked]>, "[email-masked]" <[email-masked]
>>>>>> >
>>>>>> (c) Performing bulk operations, where we simply use HTTP verbs
>>>>>> instead of the specialised (and semantically less ambiguous) verbs I
>>>>>> suggested for attributes, the "key" becomes the URI, and the "value"
>>>>>> becomes the corresponding JSON object.
>>>>>>
>>>>>>  This is an issue where we need the opinions of many people, and
>>>>>> they need to state their affiliations. If most people weighing in belong to
>>>>>>> >  I think scim gets its current simplicity from its single owner
>>>>>>> hub spoke model implementing tight coupling. [...] IMHO loose coupling is a
>>>>>>> What the SCIM spec needs to do there is just refrain from
>>>>>>> introducing tight coupling. I would like to see a single identifier exposed
>>>>>>> through the API, with the implication (and perhaps the recommendation) that
>>>>>>> it be the shared one. Allowing one domain to expose its internal identifier
>>>>>>> to the other creates tight coupling and ensures that both domains need
>>>>>>> >  Regarding unique identifiers for multi-valued attributes there
>>>>>>> is a trade-off involved.  On one hand this makes PATCH semantics easier.
>>>>>>> On the other hand it puts extra burden on service providers.
>>>>>>>
>>>>>>>
>>>>>>> You can also implement such feature without violating the SCIM
>>>>>>> specs, or without asking to include it in the specs.
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Emmanuel Dreux
>>>>>>>
>>>>>>> http://www.cloudiway.com
>>>>>>>
>>>>>>> Tel: +33 4 26 78 17 58
>>>>>>>
>>>>>>> Consider a case where customers sign up online, and two customers
>>>>>>> who are privacy-conscious enter fake IDs such as “John Smith”, and also use
>>>>>>> the same date of birth (say, 1 Jan 1970) or similar attributes. The
>>>>>>> front-end application may make an intelligent (but incorrect) guess that
>>>>>>> these two persons are the same, and re-assign the same identifier to the
>>>>>>> second person. This is a false positive. They appear to be the same entity,
>>>>>>> but they're actually different. When the error is discovered, the
>>>>>>> identities will need to be split, with a new identifier generated for one
>>>>>>> of them.
>>>>>>>
>>>>>>> When the false positive is discovered and the entity is split,
>>>>>>> Domain 1 creates a new internal identifier and now has the following entity
>>>>>>> information.
>>>>>>>
>>>>>>> Now two external identifiers map to the same internal one, so
>>>>>>> inbound communication from Domain 2 can be unambi
>>>>>>>

---

From: Ganesh and Sashi Prasad <[email-masked]>
Date: Sun, 12 Aug 2012 15:43:27 +1000

>  Multi-valued attributes that have a value sub-attribute can be removed
by specifying only the value since it is unique.

I don't know how I let this one pass!

A JSON array is a List, not a Set. There is _no uniqueness constraint_ on
its values, so your assumption is not justified.

If I wanted to model the medal winners of the men's 100 metre race at the
London Olympics (won by Usain Bolt and his compatriots), I might want to
say:

"medallists" : [ "Jamaica", "Jamaica", "Jamaica" ]

Are you saying this will not be allowed by SCIM because the values are not
unique? Why not? When JSON allows it, why should SCIM object?

Until now, I assumed that the spec was only _clumsy_. If it's based on the
assumption that array values are unique, then it is _wrong_.

Regards,
Ganesh

On 12 August 2012 15:01, Ganesh and Sashi Prasad <[email-masked]>wrote:

>> Once again I'd like to ask, is there any SP representative on this
>> working group who can tell us exactly what it would entail for them to
>> implement a unique-key-per-value scheme? I want to understand how much of a
>> burden this really is, because I reckon this would knock a few pages off
>> the spec document (which is another index of simplicity).
>>
>> Regards,
>> Ganesh
>>
>>>  With my proposal, the "addresses" array gets converted to a
>>> dictionary, and then we have a stable way of referencing this element:
>>>
>>>  There's a lot of talk about the "burden" on the SPs, but I believe
>>> this is overblown. Is there any SP representative in this WG who can tell
>>> us what this proposal will actually entail for them?
>>>
>>>  Regards,
>>> Ganesh
>>>
>>>> http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-02.  It
>>>> relies on a JSON Pointer draft which uses index-based addressing for
>>>> multi-valued attributes.  I think that this is something that should be
>>>> looked at within the WG and I would be willing to lead this effort.
>>>>
>>>>  I'm curious if anyone else in the WG is in favor of unique
>>>> identifiers for every multi-valued element.
>>>>
>>>>  --Kelly
>>>>
>>>>>  Given that multi-values must be each unique, I don't see the point
>>>>> of the extra indexing to support this. Just use the value as the item you
>>>>> wish to delete.
>>>>>
>>>>>>  So this allows us to apply uniform treatment to any arbitrarily
>>>>>> deep resource structure. We can refer to every leaf value with a key that
>>>>>> is the fully-qualified name using dot notation.
>>>>>>
>>>>>>  PLACE a value at the logical location implied by the
>>>>>> fully-qualified key. If there is already a key with that name, return a
>>>>>> "409 Conflict".
>>>>>>
>>>>>>  FORCE the fully-qualified key to hold the given value, regardless
>>>>>> of whether it existed before or not. Only errors possible are "400 Bad
>>>>>>>  PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host:
>>>>>>> example.com Accept: application/json Authorization: Bearer
>>>>>>> h480djs93hd8 ETag: W/"a330bc54f0671c9" {
>>>>>>> "operations" : [
>>>>>>> {
>>>>>>> "RETIRE" : {
>>>>>>>  PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host:
>>>>>>> example.com Accept: application/json Authorization: Bearer
>>>>>>> h480djs93hd8 ETag: W/"a330bc54f0671c9" {
>>>>>>> "operations" : [
>>>>>>> {
>>>>>>> "RETIRE" : {
>>>>>>> "key" : "members"
>>>>>>> }
>>>>>>> }
>>>>>>> ] }
>>>>>>>
>>>>>>>  Have I summed up the Pros and Cons correctly? I'm biased of
>>>>>>> course, so I could have missed a Con or hyped a Pro :-).
>>>>>>>
>>>>>>>> Let's not confuse reduction of dependencies in the data model with
>>>>>>>> a hub-and-spokes architecture. They're entirely orthogonal aspects of the
>>>>>>>> solution.
>>>>>>>>
>>>>>>>>
>>>>>>>>  >  storing this information in a mapping table outside of the
>>>>>>>> I wasn't suggesting that the mapping table be part of the SCIM
>>>>>>>> spec. I provided that example to illustrate that splitting and merging
>>>>>>>> identities is a common requirement, and that decoupling local identifiers
>>>>>>>> within a domain from shared identifiers between domains was the best way to
>>>>>>>> facilitate it.
>>>>>>>>
>>>>>>>>
>>>>>>>> This could be represented as two SCIM users that contain
>>>>>>>> information about the entities on other domains.
>>>>>>>>
>>>>>>>>
>>>>>>>> {
>>>>>>>>
>>>>>>>> We are designing a protocol for a federated system of domains,
>>>>>>>> where all domains are co-equal peers. (In physics too, N-body problems are
>>>>>>>> much harder than 2-body problems. :-) Therefore, assuming that there are
>>>>>>>> only two players in the interaction makes this tightly coupled in a number
>>>>>>>> of ways. We should rely on messaging and notification, with encapsulation
>>>>>>>> of domain-specific data.
>>>>>>>>
>>>>>>>> b.
>>>>>>>>
>>>>>>>> In any non-trivial data store, there will always be the ongoing
>>>>>>>> need to merge and split identities as and when “false negatives” and “false
>>>>>>>> Domain 1 then maintains the following in a mapping table and uses
>>>>>>>> it for translation when talking to Domain 2, taking care never to expose
>>>>>>>> its internal identifier:
>>>>>>>>
>>>>>>>> Domain 1 then maintains the following in a mapping table and uses
>>>>>>>> it for translation when talking to Domain 2, taking care never to expose
>>>>>>>> its internal identifiers:
>>>>>>>>

---

From: Ganesh and Sashi Prasad <[email-masked]>
Date: Sun, 12 Aug 2012 16:41:40 +1000

>  >  Multi-valued attributes that have a value sub-attribute can be
removed by specifying only the value since it is unique.

Ignore my last comment. I think I understand what you're trying to say.

You're describing a dictionary masquerading as an array, with the keys
embedded within the values! And what you're referring to as the "value"
sub-attribute is actually the "key". This is what has confused the heck out
of me :-).

i.e., you're talking about arrays like this:

x = [ { "key" : "9e076b1f6f21", "a" : "1", "b" : "2"}, { "key" :
"f02abe1a7f8e", "a" : "5", "b" : "6"} ]

You're asking "why should we generate a new key for each element when we
already have a key inside?"

The answer is, we don't have to! We can turn this into a proper dictionary
using the existing key, like this:

x = { "9e076b1f6f21" : {"a" : "1", "b" : "2"}, "f02abe1a7f8e" : {"a" : "5",
"b" : "6"} }

And now we can refer to the elements using dot notation. We don't have to
search inside the arrays for the attribute containing the key.

If we're already planning to ask the SPs to support the above array
notation, then there's no extra _implementation_ effort to support the
proper dictionary notation because it's just a change of _representation_
to simplify the API.

Is this more acceptable?

Regards,
Ganesh

On 12 August 2012 15:43, Ganesh and Sashi Prasad <[email-masked]>wrote:

>>>>  >  Multi-valued attributes that don't have a value sub-attribute (eg
>>>> - address) have to specified completely for uniqueness.
>>>>
>>>>  In the example below, how are you proposing that the following
>>>> element be updated if we can't use positional indexes?
>>>>
>>>>  If you're proposing one mechanism for composite attributes and
>>>> another mechanism for simple attributes, I would suggest that's actually
>>>> more complex than adopting a single mechanism that works the same way for
>>>> _all_ attributes. Remember that a lot of the administration is probably
>>>> going to be scripted rather than done by hand, and having two mechanisms
>>>> (depending on whether the attribute is simple or composite) will complicate
>>>> every script that has to be written.
>>>>
>>>>>  This is exactly how PATCH works in SCIM 1.0.  Multi-valued
>>>>> attributes that have a value sub-attribute can be removed by specifying
>>>>> only the value since it is unique.  Multi-valued attributes that don't have
>>>>> a value sub-attribute (eg - address) have to specified completely for
>>>>> uniqueness.  As I have said before, I am very opposed to adding a unique
>>>>> identifier to each element in a multi-valued collection due to the burden
>>>>> it will put on SPs.  Is it elegant?  No.  Is it functional?  Yes.  Will
>>>>> this non-elegance affect adoption?  My opinion is that adding unique keys
>>>>> to each element will have a much more detrimental effect on adoption.
>>>>>
>>>>>  I do believe that in general PATCH can be made more intuitive
>>>>> without adding uids to each element.  The verbs that you propose make
>>>>> sense.  There is also a JSON Patch informational draft in the IETF that is
>>>>> interesting -
>>>>>>>> [email-masked]>, Trey Drake <[email-masked]>,
>>>>>>>> Kelly Grizzle <[email-masked]>, "[email-masked]" <
>>>>>>>> [email-masked]>
>>>>>>>>  Pro 4: New (not incumbent) cloud providers will probably find
>>>>>>>> this easier to implement because they have no legacy. They will probably
>>>>>>>> use some form of NoSQL database and won't be constrained by the limitations
>>>>>>>> of LDAP directories.
>>>>>>>>
>>>>>>>>  Cons:
>>>>>>>>
>>>>>>>>  Keep in mind that a complex spec that only favours incumbent
>>>>>>>> cloud providers can cut both ways. It opens the door to a simpler interface
>>>>>>>>> One of the primary reasons that SPML failed was lack of adoption
>>>>>>>>> by service providers due to its complexity. Very few target applications
>>>>>>>>> I'm a bit surprised that you're implying "tight coupling ==
>>>>>>>>> simple" and "loose coupling == complex". That's contrary to my experience.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I see what you are saying. I think scim gets its current
>>>>>>>>> simplicity from its single owner hub spoke model implementing tight
>>>>>>>>> coupling.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> IMHO loose coupling is a much more complex solution. The reality
>>>>>>>>> is that each end-point has value to contribute and thus the single-owner
>>>>>>>>> model will eventually need to become multi-owner or multi-hub.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> the other hand it puts extra burden on service providers.  Since the
>>>>>>>>> inception of SCIM, a key goal has been to foster adoption by service
>>>>>>>>> providers by making things fit easily onto existing systems.  IMO the value
>>>>>>>>> gained by unique identifiers for multi-valued attributes is not worth the
>>>>>>>>> demands put on a service provider.  I also think that vendors that have a
>>>>>>>>> Nothing prevents you in your SCIM implementation (client or
>>>>>>>>> server) to generate a unique identifier for each synchronized object and
>>>>>>>>> maintain an internal mapping table ( you would have to map group membership
>>>>>>>>> as well).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This was written in dotnet and we have started a project to
>>>>>>>>> rewrite our SCIM stack in PHP and will give it to the Open Source
>>>>>>>>> community. This implementation will have a parameter : AllocateIds versus
>>>>>>>>> UseExistingIDs.
>>>>>>>>>
>>>>>>>>> 2. The difficulty of assigning unique identifiers to the
>>>>>>>>> individual values of multi-valued attributes:
>>>>>>>>>
>>>>>>>>> a.
>>>>>>>>>
>>>>>>>>> When we consider federated identity across more than one domain,
>>>>>>>>> we have to assume that domains are not necessarily master-slave in their
>>>>>>>>> This second entity with its own internal identifier is invisible
>>>>>>>>> to Domain 2, and this is by design. Communication about the original entity
>>>>>>>>> Domain 1 has the following information about what it thinks are
>>>>>>>>> two distinct customers in its data store:
>>>>>>>>>
>>>>>>>>> When requesting the provisioning of these entities in Domain 2,
>>>>>>>>> the following IDs are returned by Domain 2: ff487230b3a0 and 41206cc97c8b.
>>>>>>>>>

---

From: Emmanuel Dreux <[email-masked]>
Date: Sun, 12 Aug 2012 18:29:18 +0000

ð  addresses.3cbaaff8e84e.street-number = "243"

Where would 3cbaaff8e84e come from? Would it have to be stored on the account database of the service provider?

If so, I believe that this is impracticable in the core schema. Indeed it implies that a service provider must extend the schema of his account repository (LDAP partition, SQL db, ...) and "prepare it" for SCIM integration.
This would be a show stopper. SCIM must be transparent, and must be able to be put on top of an existing system to provide provisioning apis.

Said differently, SCIM must not be intrusive for existing systems and must not require modifications to allow its integration.
Correct me if I misunderstood your suggestion.

De : Ganesh and Sashi Prasad [mailto:[email-masked]]
Envoyé : dimanche 12 août 2012 04:53
À : Kelly Grizzle
Cc : [email-masked]; Phil Hunt
Objet : Re: [scim] scim Digest, Vol 8, Issue 24

User object:

{
  ...
  addresses: [
    {
      "type" : "home",
      "street-number" : "35",

{
  "type" : "office",
  "street-number" : "213",

{
  ...
  addresses: {
    "d6ea365462f5" :
    {
      "type" : "home",
      "street-number" : "35",

Regards,
Ganesh

--Kelly

Regards,
Ganesh

Phil

@independentid

Regards,
Ganesh

Phil

I don't believe so.

Simple attribute:

Key: "dob"
Value: "01 Jan 1970"

Composite attribute:

Key: "address.suburb"
Value: "East Camden"

Multi-valued attribute:

Regards,
Ganesh

Today's Topics:

---------- Forwarded message ----------
From: Phil Hunt <[email-masked]<mailto:[email-masked]>>
To: Ganesh and Sashi Prasad <[email-masked]<mailto:[email-masked]>>
Cc: "Diodati, Mark" <[email-masked]<mailto:[email-masked]>>, Emmanuel Dreux <[email-masked]<mailto:[email-masked]>>, Trey Drake <[email-masked]<mailto:[email-masked]>>, Kelly Grizzle <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Fri, 10 Aug 2012 17:36:54 -0700
Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement
Ganesh,

Phil

Let's discuss that now.

Pros:

   Accept: application/json

   {

     "members": [

       {

         "operation": "delete"

       }

     ]

   }

   Accept: application/json

   {

     "meta": {

       "attributes": [

         "members"

       ]

     }

   }

Cons:

Regards,
Ganesh

I am concerned about your second suggestion:
"2. When dealing with multi-valued attributes of a resource (expressed as arrays in JSON), they must be converted from an array into a dictionary with unique keys (UUIDs generated by the cloud provider when the attribute is created). Without unique keys for every attribute value of a resource, manipulating it will be clumsy and inelegant."

One of the primary reasons that SPML failed was lack of adoption by service providers due to its complexity. Very few target applications implemented SPML. Most of the commercial provisioning systems had an SPML interface (either v1 or v2), but not one of them was conformant to the SPML standard because of complexity. If you are interested, I will forward you the research documents that discuss these problems in detail. For SCIM to be successful, it must be adopted by commercial target applications (i.e., service providers). I am confident that a requirement for unique identifiers with multi-valued attributes will preclude its adoption, because it requires major changes to the service provider's existing identity storage mechanisms.
Mark

Ganesh,

Phil,

Regards,

Ganesh

Phil

Am I making sense?

Regards,
Ganesh

{

{

{

Regarding unique identifiers for multi-valued attributes there is a trade-off involved.  On one hand this makes PATCH semantics easier.  On the other hand it puts extra burden on service providers.  Since the inception of SCIM, a key goal has been to foster adoption by service providers by making things fit easily onto existing systems.  IMO the value gained by unique identifiers for multi-valued attributes is not worth the demands put on a service provider.  I also think that vendors that have a non-SCIM-compliant API will choose to keep things that way if the spec is too hard for them to implement.  In a green field environment we do have the luxury of mandating a model to make certain operations more elegant.  However, we can't ignore legacy systems.

--Kelly

Hi Ganesh,

This is what we are doing with Active Directory sources or targets:
As we didn't find an immutable uniqueID in AD systems (DN,samAccountName, UPN) are subject to change (even objectGuid can change if an AD domain is migrated), we decided to generate and maintain an internal table of ids. This fits your requirements as it hides internal ids.

This was written in dotnet and we have started a project to rewrite our SCIM stack in PHP and will give it to the Open Source community. This implementation will have a parameter : AllocateIds versus UseExistingIDs.
This will give the choice of "hiding" internalIDs or use them as unique ID.

Hi Kelly,

a.

b.

In any non-trivial data store, there will always be the ongoing need to merge and split identities as and when "false negatives" and "false positives" are discovered. A domain should be able to handle this internal housekeeping freely, only notifying other domains when convenient. Mapping of internal identifiers to external ones and maintaining this mapping internally allows this loosely-coupled housekeeping to take place. Sharing internal identifiers (or otherwise outsourcing the mapping of internal to external identifiers) forces housekeeping activities to be done in lock-step across domains.

c.

a.

b.

If incumbent cloud providers find it hard to immediately adopt the dictionary model for existing multi-valued attributes, they can transition to this model by offering both "SCIM-compliant" and "non-SCIM-compliant" APIs to their customers and encouraging new customers to adopt the "SCIM-compliant" API. Legacy customers can be supported using a "non-SCIM-compliant" API for an arbitrarily long period and gradually migrated to the SCIM-compliant API. The logistics are not insurmountable, and shouldn't prevent the adoption of a dictionary model for multi-valued attributes.

Elaboration of Point 1:

The question "Is this one entity?" can be answered either yes (positive) or no (negative). But sometimes, we can discover false positives and false negatives in our data stores.

Consider a case where customers sign up online, and two customers who are privacy-conscious enter fake IDs such as "John Smith", and also use the same date of birth (say, 1 Jan 1970) or similar attributes. The front-end application may make an intelligent (but incorrect) guess that these two persons are the same, and re-assign the same identifier to the second person. This is a false positive. They appear to be the same entity, but they're actually different. When the error is discovered, the identities will need to be split, with a new identifier generated for one of them.

Consider the opposite case where a customer signs up through two different portals or in two different sessions, using the names "JSmith" and "JohnS". It is very likely that they will be treated as two different customers and assigned two unique identifiers. This is a false negative. They appear to be two entities, but are actually the same. At a later stage, when the error is discovered, the identities will have to be merged, and one of the identifiers will have to be dropped.

a. False positives:

Attributes: {name: "John Smith", dob: "01-Jan-1970"}

Attributes: {name: "John Smith", dob: "01-Jan-1970"}

Attributes: {name: "John Smith", dob: "01-Jan-1970"}

This second entity with its own internal identifier is invisible to Domain 2, and this is by design. Communication about the original entity takes place as before by mapping "9caf78aac3d6" to "ff487230b3a0" and vice-versa. At some convenient time (importantly, this doesn't have to be at the time the split happens), Domain 2 can be requested to provision a second entity, and when it responds with an identifier of "7a87f27c1dd8", this can go into the mapping table as a new record associated with the second entity's internal identifier.

(What is the "Primary flag" used for? We'll see when we cover the treatment of false negatives.)

b. False negatives:

Attributes: {name: "JSmith", dob: "01-Jan-1970"}

Attributes: {name: "JohnS", dob: "01-Jan-1970"}

When the false negative is discovered and the two entities are merged, Domain 1 drops one of the internal identifiers and rationalises the name of the customer (say, to "John Smith"). Let's say it retains the first ID "9caf78aac3d6" and drops the second "273d36e30d09".

scim mailing list

---

From: Ganesh and Sashi Prasad <[email-masked]>
Date: Mon, 13 Aug 2012 07:29:32 +1000

> Would it have to be stored on the account database of the service
provider?****

** **

Yes.

> If so, I believe that this is impracticable in the core schema. Indeed it
implies that a service provider must extend the schema of his account
repository (LDAP partition, SQL db, …) and “prepare it” for SCIM
integration.

Why? That doesn't necessarily follow. Implementation is independent of
representation. We're talking about a change in representation to make the
API cleaner.

As a simple example, if an LDAP node is being used to hold a list of
comma-separated email addresses, it can just as easily store
comma-separated name-value pairs.

mail: [email-masked], [email-masked], [email-masked]

can be changed to

mail: aa66-daf9ea3bd902=[email-masked],9cda-8646c3085bbf=
[email-masked], 7a6d1de664e1=[email-masked]

That's why I asked if there was an SP representative on this working group
who could explain what such a change could mean for them. As of now, it
looks like other people are presuming that SPs will not be able to
implement these changes easily and are rejecting them for that reason.

Regards,
Ganesh

On 13 August 2012 04:29, Emmanuel Dreux <[email-masked]> wrote:

>  **ð  **addresses.3cbaaff8e84e.street-number = "243"****
>
> ** **
>
> Where would 3cbaaff8e84e come from? Would it have to be stored on the
> account database of the service provider?****
>
> ** **
>
> If so, I believe that this is impracticable in the core schema. Indeed it
> implies that a service provider must extend the schema of his account
> repository (LDAP partition, SQL db, …) and “prepare it” for SCIM
> integration.****
>
> This would be a show stopper. SCIM must be transparent, and must be able
> to be put on top of an existing system to provide provisioning apis.****
>
> ** **
>
> Said differently, SCIM must not be intrusive for existing systems and must
> not require modifications to allow its integration.****
>
> Correct me if I misunderstood your suggestion.****
>
> ** **
>
> --****
>
> Regards,****
>
> Emmanuel Dreux****
>
> http://www.cloudiway.com****
>
> Tel: +33 4 26 78 17 58****
>
> Mobile: +33 6 47 81 26 70****
>
> skype: Emmanuel.Dreux****
>
> ** **
>
> *De :* Ganesh and Sashi Prasad [mailto:[email-masked]]
> *Envoyé :* dimanche 12 août 2012 04:53
> *À :* Kelly Grizzle
> *Cc :* [email-masked]; Phil Hunt
> *Objet :* Re: [scim] scim Digest, Vol 8, Issue 24****
>
> ** **
>
> address) have to specified completely for uniqueness.  ****
>
> ** **
>
> That's exactly the point. How do we "specify completely for uniqueness"?**
> **
>
> ** **
>
> updated if we can't use positional indexes?****
>
> ** **
>
> addresses[1].street-number = "243"****
>
> ** **
>
> User object:****
>
> ** **
>
> {****
>
>   ...****
>
>   addresses: [****
>
>     {****
>
>       "type" : "home",****
>
>       "street-number" : "35",****
>
>       "street-name" : "High Road",****
>
>       "suburb" : "East Camden",****
>
>       "postcode" : "5346",****
>
>       "state" : "SA",****
>
>       "country" : "Australia"****
>
>     },****
>
>     {****
>
>       "type" : "office",****
>
>       "street-number" : "213",****
>
>       "street-name" : "Main Street",****
>
>       "suburb" : "Adelaide",****
>
>       "postcode" : "5000",****
>
>       "state" : "SA",****
>
>       "country" : "Australia"****
>
>     }****
>
>   ]****
>
> }****
>
> ** **
>
> It's impractical to use the value because it's the whole dictionary
> element:****
>
> ** **
>
> {****
>
>   "type" : "office",****
>
>   "street-number" : "213",****
>
>   "street-name" : "Main Street",****
>
>   "suburb" : "Adelaide",****
>
>   "postcode" : "5000",****
>
>   "state" : "SA",****
>
>   "country" : "Australia"****
>
> }****
>
> ** **
>
> and then we have a stable way of referencing this element:****
>
> ** **
>
> addresses.3cbaaff8e84e.street-number = "243"****
>
> ** **
>
> {****
>
>   ...****
>
>   addresses: {****
>
>     "d6ea365462f5" :****
>
>     {****
>
>       "type" : "home",****
>
>       "street-number" : "35",****
>
>       "street-name" : "High Road",****
>
>       "suburb" : "East Camden",****
>
>       "postcode" : "5346",****
>
>       "state" : "SA",****
>
>       "country" : "Australia"****
>
>     },****
>
>     "3cbaaff8e84e" :****
>
>     {****
>
>       "type" : "office",****
>
>       "street-number" : "213",****
>
>       "street-name" : "Main Street",****
>
>       "suburb" : "Adelaide",****
>
>       "postcode" : "5000",****
>
>       "state" : "SA",****
>
>       "country" : "Australia"****
>
>     }****
>
>   }****
>
> }****
>
> ** **
>
> script that has to be written.****
>
> ** **
>
> this proposal will actually entail for them?****
>
> ** **
>
> Regards,****
>
> Ganesh****
>
> ** **
>
> On 12 August 2012 11:53, Kelly Grizzle <[email-masked]>
> wrote:****
>
> Ganesh,****
>
> ** **
>
> This is exactly how PATCH works in SCIM 1.0.  Multi-valued attributes that
> have a value sub-attribute can be removed by specifying only the value
> will have a much more detrimental effect on adoption.****
>
> ** **
>
> the WG and I would be willing to lead this effort.****
>
> ** **
>
> I'm curious if anyone else in the WG is in favor of unique identifiers for
> every multi-valued element.****
>
> ** **
>
> --Kelly****
>
> ** **
> *Subject:* Re: [scim] scim Digest, Vol 8, Issue 24****
>
> Phil, ****
>
> ** **
>
> ****
> ** **
> Regards,****
> Ganesh****
> On 12 August 2012 01:12, Phil Hunt <[email-masked]> wrote:****
>
> Ganesh, ****
>
> ** **
>
> Here's the sample that concerned me...****
>
>  The two operations differ significantly, and it's not very intuitive. ***
> *
>
> With my suggestion, here's how to delete a single member from a group:****
>
> ** **
>
> W/"a330bc54f0671c9" {****
>
> "operations" : [****
>
> {****
>
> "RETIRE" : {****
>
> "key" : "members.2819c223-7f76-453a-919d-413861904646"****
>
> }****
>
> }****
>
> ] } ****
>
>  ** **
>
> ** **
>
> that value or of identifiers that were additional unique keys.****
>
> ** **
>
> delete.****
> ** **
> I agree, the delete value operation could be more explicit and clear in
> general.****
>
> ** **
>
> Phil****
>
> ** **
>
> @independentid****
>
> www.independentid.com****
>
> [email-masked]****
>
> ** **
>
> ** **
>
> ** **
>
> On 2012-08-11, at 2:30 AM, Ganesh and Sashi Prasad wrote:****
>
>
>
> ****
>
> >  For the multi-value example you gave you used the value as the
> attribute name key.  ****
>
> ** **
>
> as the key.****
> ** **
> believe to be the value?****
>
> ** **
>
> Regards,****
>
> Ganesh ****
>
> On 11 August 2012 13:59, Phil Hunt <[email-masked]> wrote:****
>
>
> For the multi-value example you gave you used the value as the attribute
> name key. ****
>
> ** **
>
> That means a lot more complex indexing structure. Better to just say
> delete a specific value. ****
>
> ** **
>
> ****
> ** **
> Phil****
> On 2012-08-10, at 21:45, Ganesh and Sashi Prasad <[email-masked]>
> wrote:****
>
> I don't believe so. ****
> ** **
> pair. The key is a name or ID.****
>
> ** **
>
> attribute name itself. ****
>
> ** **
>
> Simple attribute:****
>
> ** **
>
> Key: "dob"****
>
> Value: "01 Jan 1970"****
>
> ** **
>
> fully-qualified attribute name, e.g., "address.postcode".****
>
> ** **
>
> Composite attribute:****
>
> ** **
>
> Key: "address.street-number"****
>
> Value: "10"****
>
> ** **
>
> Key: "address.suburb"****
>
> Value: "East Camden"****
>
> ** **
>
> notation for the key.****
>
> ** **
>
> Multi-valued attribute:****
>
> ** **
>
> Key: "emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd902"****
>
> Value: "[email-masked]"****
>
> ** **
>
> fully-qualified name using dot notation.****
>
> ** **
>
> addressable attributes.****
>
> ** **
>
> in the INCLUDE.****
> ** **
> return a "404 Not Found".****
>
> ** **
>
> If there is already a key with that name, return a "409 Conflict".****
>
> ** **
>
> Request" and "500 Internal Error".****
>
> ** **
>
> {} ).****
> ** **
> I'll explain in a separate post why we need operation verbs like these
> that are independent of the HTTP verbs.****
>
> ** **
>
> Regards,****
>
> Ganesh****
>
> ** **
>
> On 11 August 2012 10:38, <[email-masked]> wrote:****
>
> Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement****
>
> Ganesh,****
>
> ** **
>
> confusing. ****
> ** **
> I agree though that operations in patch could be a lot more explicit. ****
>
> ** **
>
> Eg explicitly deleting a value by saying delete or retire. ****
>
>
> Phil****
>
>
> wrote:****
>   >  I am concerned about your second suggestion:  ****
>
> ** **
>
> Let's discuss that now.****
>
> ** **
>
> The trade-offs are very clear here.****
>
> ** **
>
> Pros:****
>
> ** **
>
> and intuitive when every individual attribute value gets its own ID.****
>
> ** **
>
> ****
> ** **
>    PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce****
>
>    Host: example.com****
>
>    Accept: application/json****
>
>    Authorization: Bearer h480djs93hd8****
>
>    ETag: W/"a330bc54f0671c9"****
>
> ** **
>
>    {****
>
>      "schemas": ["urn:scim:schemas:core:1.0"],****
>
>      "members": [****
>
>        {****
>
>          "display": "Babs Jensen",****
>
>          "value": "2819c223-7f76-453a-919d-413861904646"****
>
>          "operation": "delete"****
>
>        }****
>
>      ]****
>
>    }****
>
>
> spec:****
> ** **
>    PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce****
>
>    Host: example.com****
>
>    Accept: application/json****
>
>    Authorization: Bearer h480djs93hd8****
>
>    ETag: W/"a330bc54f0671c9"****
>
> ** **
>
>    {****
>
>      "schemas": ["urn:scim:schemas:core:1.0"],****
>
>      "meta": {****
>
>        "attributes": [****
>
>          "members"****
>
>        ]****
>
>      }****
>
>    }****
>
>
> The two operations differ significantly, and it's not very intuitive. ****
>
> With my suggestion, here's how to delete a single member from a group:****
>
> ** **
>
> W/"a330bc54f0671c9" {****
>
> "operations" : [****
>
> {****
>
> "RETIRE" : {****
>
> "key" : "members.2819c223-7f76-453a-919d-413861904646"****
>
> }****
>
> }****
>
> ] }
> Here's how I suggest deleting ALL members from a group:****
>
> ** **
>
> W/"a330bc54f0671c9" {****
>
> "operations" : [****
>
> {****
>
> "RETIRE" : {****
>
> "key" : "members"****
>
> }****
>
> }****
>
> ] } ****
>
>
> intuitive to a reader.****
>
> ** **
>
> Pro 2: We can apply this mechanism consistently to three areas:****
>
> (a) Manipulating multi-valued attributes of a resource****
>
> (b) Manipulating members of a group****
>
> corresponding JSON object.****
>
> ** **
>
> individual status codes.****
>
> ** **
>
> different.****
> ** **
> it's simpler for them.****
>
> ** **
>
> directories.****
> ** **
> Cons:****
> ** **
> will "hinder adoption of the spec", which is what you fear.****
>
> ** **
>
> could have missed a Con or hyped a Pro :-).****
>
> ** **
>
> spec by different parties.****
>
> ** **
>
> leave the spec as it is?****
>
> ** **
>
> simpler.****
> ** **
> organisations to see what they would want.****
>
> ** **
>
> ****
> ** **
> Regards,****
> Ganesh****
> ** **
> ** **
> On 11 August 2012 01:35, Diodati,Mark <[email-masked]> wrote:***
> *
>
> Hi Ganesh,****
>
>  ****
>
> I am concerned about your second suggestion: ****
>
> manipulating it will be clumsy and inelegant.”****
>
>  ****
>
> identity storage mechanisms. ****
>
> Mark****
>
>  ****
>
>  ****
>
>  ****
>
> *Sent:* Friday, August 10, 2012 9:51 AM****
>
>
> *To:* Ganesh and Sashi Prasad****
>
> *Cc:* [email-masked]; Emmanuel Dreux; Kelly Grizzle; Phil Hunt ****
>
>
> *Subject:* Re: [scim] SCIM Protocol - 3 suggestions for improvement****
>
> ** **
>
>  ****
>
> Ganesh,****
>
>  ****
>
> I'll base my comments on your latest reply (below).  ****
>
>  ****
>
> The externalID is not part of the protocol.  It is an *optional* attribute
> within the *schema* specification.  As for #2, the protocol spec works as
> you describe if "arbitrary URI parameters" equate to resource attributes
> (Allow generic search using 'GET /Users' and arbitrary URI parameters).
>  Please clarify your suggestion.****
>
>  ****
>
>  Nothing mandates use of externalId.   ****
>
>  ****
>
>  ****
>
> What do you mean by "candidate key"?  Given ****
>
>  ****
>
> [email-masked]> wrote:****
>
> much more complex solution.****
>
>  ****
>
> Phil,****
>
>  ****
>
> "loose coupling == complex". That's contrary to my experience.****
>
>  ****
>
> Invariably, a reduction in dependencies leads to greater simplicity.****
>
>  ****
>
> solution.****
>  ****
> All that my suggestion involves is,****
>
>  ****
>
> 1. Take 'external ID' out of the protocol.****
>
> 2. Allow generic search using 'GET /Users' and arbitrary URI parameters***
> *
>
>  ****
>
> No planned functionality is lost by this.****
>
>  ****
>
> the protocol). Let's say they call it 'myID'.****
>
> 2. The client enterprise can search for resource URIs using any attribute,
> including this internal ID****
>
> 'GET /Users?myID=bjensen'****
>
> which is the canonical URI for the resource****
>
> https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646****
>
> 3. The client can use this URI to perform all other operations as usual.****
>
>  ****
>
> So taking 'externalID' out of the protocol spec only does this:****
>
> 1. It avoids enshrining tight coupling in the protocol (If clients want to tightly couple themselves to the cloud provider by sending their internal IDs, they can do so. Suicide is OK, but the protocol should not be guilty of assisted suicide. ;-)****
>
> 2. It encourages loose coupling by nudging clients towards maintaining their own internal-to-external identifier mappings.****
>
>  ****
>
> That's what I'd like to see. I don't believe this complicates the protocol. It simplifies it and it also lends itself to a loosely-coupled approach.****
>
>  ****
>
> I'll address the multi-valued attribute suggestion separately.****
>
>  ****
>
> Regards,****
>
> Ganesh****
>
>   ****
>
>  ****
>
>  ****
>
>   ****
>
> On 10 August 2012 07:53, Phil Hunt <[email-masked]> wrote:****
>
>
>
> Phil****
>
>
> wrote:****
> facilitate it.****
>  ****
> I'm suggesting that the spec do less, not more.****
>
>  ****
>
> acceptable attribute.****
>
>  ****
>
> Am I making sense?****
>
>   ****
>
> its single owner hub spoke model implementing tight coupling. ****
>
>  ****
>
> eventually need to become multi-owner or multi-hub. ****
>
>  ****
>
> That said i think the current model provides a practical starting point. *
> ***
>
>  ****
>
> other hand it puts extra burden on service providers. ****
>
>
> opinions.****
>  ****
> Regards,****
> Ganesh****
> wrote:****
> responsible for the transport layer between domains.****
>
>  ****
>
> user):****
>  ****
> flag |****
> true         |****
> true         |****
>  ****
> This could be represented as two SCIM users that contain information about
> the entities on other domains.****
>
>  ****
>
> {****
>
> "urn:scim:schemas:extension:federation:1.0"],****
>
>   "id": "9caf78aac3d6",****
>
>   "userName": "John Smith",****
>
>   "urn:scim:schemas:extension:federation:1.0": {****
>
>     "linkedUsers": [****
>
>       {****
>
>         "domain": "D2",****
>
>         "externalEntityId": "ff487230b3a0"****
>
>       }****
>
>     ]****
>
>   }****
>
> }****
>
>  ****
>
> {****
>
> "urn:scim:schemas:extension:federation:1.0"],****
>
>   "id": "a99a5feba839",****
>
>   "userName": "John Smith",****
>
>   "urn:scim:schemas:extension:federation:1.0": {****
>
>     "linkedUsers": [****
>
>       {****
>
>         "domain": "D2",****
>
>         "externalEntityId": "7a87f27c1dd8"****
>
>       }****
>
>     ]****
>
>   }****
>
> }****
>
>  ****
>
> split user was synced to domain 2.****
>
>  ****
>
>  ****
>
> this at the end:****
>  ****
> flag |****
> true         |****
> false        |****
>  ****
> This could be represented with the following SCIM user:****
>
>  ****
>
> {****
>
> "urn:scim:schemas:extension:federation:1.0"],****
>
>   "id": "9caf78aac3d6",****
>
>   "userName": "John Smith",****
>
>   "urn:scim:schemas:extension:federation:1.0": {****
>
>     "linkedUsers": [****
>
>       {****
>
>         "domain": "D2",****
>
>         "externalEntityId": "ff487230b3a0"****
>
>       },****
>
>       {****
>
>         "domain": "D2",****
>
>         "externalEntityId": "41206cc97c8b",****
>
>         "deletionRequired": true****
>
>       }****
>
>     ]****
>
>   }****
>
> }****
>
>  ****
>
>  ****
>
> However, we can’t ignore legacy systems. ****
>
>  ****
>
> --Kelly****
>
>  ****
>
> *Subject:* Re: [scim] SCIM Protocol - 3 suggestions for improvement****
>
>  ****
>
> Hi Ganesh,****
>
>  ****
>
> internal mapping table ( you would have to map group membership as well).*
> ***
>
>  ****
>
> This is what we are doing with Active Directory sources or targets:****
>
> This fits your requirements as it hides internal ids.****
>
>  ****
>
> implementation will have a parameter : AllocateIds versus UseExistingIDs.*
> ***
>
> ****
>  ****
> without asking to include it in the specs.****
>
>  ****
>
> --****
>
> Regards,****
>
> Emmanuel Dreux****
>
> http://www.cloudiway.com****
>
> Tel: +33 4 26 78 17 58****
>
> Mobile: +33 6 47 81 26 70****
>
> skype: Emmanuel.Dreux****
>
>  ****
>
> *Objet :* Re: [scim] SCIM Protocol - 3 suggestions for improvement****
>
>  ****
>
> Hi Kelly,****
>
> points you have made, and then elaborate on the first.****
>
> 1.      Why should domains not expose their internal identifiers to other
> domains?****
>
> a.****
>
> domain-specific data.****
>
> b. ****
>
> lock-step across domains.****
>
> c.****
>
> internal identifiers is a key part of this tight coupling.****
>
> 2. The difficulty of assigning unique identifiers to the individual values
> of multi-valued attributes:****
>
> a. ****
>
> over many years or even decades.****
>
> b. ****
>
> attributes.****
> Elaboration of Point 1:****
>
> and at a time of their convenience.****
>
> of identity that is often required.****
>
> negatives in our data stores.****
>
> will need to be split, with a new identifier generated for one of them.***
> *
>
> Consider the opposite case where a customer signs up through two different
> portals or in two different sessions, using the names “JSmith” and “JohnS”.
> It is very likely that they will be treated as two different customers and
> assigned two unique identifiers. This is a false negative. They appear to
> be two entities, but are actually the same. At a later stage, when the
> error is discovered, the identities will have to be merged, and one of the
> identifiers will have to be dropped.****
>
> These are not theoretical use cases. They form a significant proportion of
> the user base in most large Web-facing applications. Let's see how these
> external ones and only exposing external identifiers to other domains.****
>
> a. False positives:****
>
> ****
> Internal ID: 9caf78aac3d6****
>
> Attributes: {name: “John Smith”, dob: “01-Jan-1970”}****
>
> When requesting the provisioning of this entity in Domain 2, the following
> ID is returned by Domain 2: ff487230b3a0.****
>
> internal identifier:****
> flag |****
> | 9caf78aac3d6 | D2 | ff487230b3a0 | true |****
>
> information.****
> Internal ID: 9caf78aac3d6****
>
> Attributes: {name: “John Smith”, dob: “01-Jan-1970”}****
>
> Internal ID: a99a5feba839****
>
> Attributes: {name: “John Smith”, dob: “01-Jan-1970”}****
>
> This second entity with its own internal identifier is invisible to Domain
> 2, and this is by design. Communication about the original entity takes
> place as before by mapping “9caf78aac3d6” to “ff487230b3a0” and vice-versa.
> At some convenient time (importantly, this doesn't have to be at the time
> the split happens), Domain 2 can be requested to provision a second entity,
> and when it responds with an identifier of “7a87f27c1dd8”, this can go into
> the mapping table as a new record associated with the second entity's
> internal identifier.****
>
> The mapping table now contains the following entries:****
>
> flag |****
> | 9caf78aac3d6 | D2 | ff487230b3a0 | true |****
>
> | a99a5feba839 | D2 | 7a87f27c1dd8 | true |****
>
> Domain 2 is not even aware that a split has happened, and the provisioning
> that it does is not in lockstep with the split in identity that occurred in
> Domain 1.****
>
> treatment of false negatives.)****
>
> b. False negatives:****
>
> distinct customers in its data store:****
>
> Internal ID: 9caf78aac3d6****
>
> Attributes: {name: “JSmith”, dob: “01-Jan-1970”}****
>
> Internal ID: 273d36e30d09****
>
> Attributes: {name: “JohnS”, dob: “01-Jan-1970”}****
>
> following IDs are returned by Domain 2: ff487230b3a0 and 41206cc97c8b.****
>
> internal identifiers:****
>
> flag |****
> | 9caf78aac3d6 | D2 | ff487230b3a0 | true |****
>
> | 273d36e30d09 | D2 | 41206cc97c8b | true |****
>
> “9caf78aac3d6” and drops the second “273d36e30d09”.****
>
> The mapping table now looks like this:****
>
> flag |****
> | 9caf78aac3d6 | D2 | ff487230b3a0 | true |****
>
> | 9caf78aac3d6 | D2 | 41206cc97c8b | false |****
>
> communication from Domain 2 can be unambi****
>
>     _______________________________________________ ****
>
>
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim****
>
>  ** **
>
> https://www.ietf.org/mailman/listinfo/scim****
>
> ** **
>
> ** **
>
> ** **
>

---

From: Phil Hunt <[email-masked]>
Date: Sun, 12 Aug 2012 18:13:27 -0600

I strongly object to anything that leads to a read before modify requirement. Too complex and too chatty. 

Phil

On 2012-08-12, at 15:29, Ganesh and Sashi Prasad <[email-masked]> wrote:

> > Would it have to be stored on the account database of the service provider?
> 
>  
> 
> Yes.
> 
> 
> 
> > If so, I believe that this is impracticable in the core schema. Indeed it implies that a service provider must extend the schema of his account repository (LDAP partition, SQL db, …) and “prepare it” for SCIM integration.
> 
> 
> Why? That doesn't necessarily follow. Implementation is independent of representation. We're talking about a change in representation to make the API cleaner.
> 
> As a simple example, if an LDAP node is being used to hold a list of comma-separated email addresses, it can just as easily store comma-separated name-value pairs.
> 
> mail: aa66-daf9ea3bd902=[email-masked],9cda-8646c3085bbf=[email-masked], 7a6d1de664e1=[email-masked]
> 
> That's why I asked if there was an SP representative on this working group who could explain what such a change could mean for them. As of now, it looks like other people are presuming that SPs will not be able to implement these changes easily and are rejecting them for that reason.
> 
> Regards,
> Ganesh
> 
> If so, I believe that this is impracticable in the core schema. Indeed it implies that a service provider must extend the schema of his account repository (LDAP partition, SQL db, …) and “prepare it” for SCIM integration.
> 
> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" {
> 
> "operations" : [
> 
> {
> 
> "RETIRE" : {
> 
> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" {
> 
> "operations" : [
> 
> {
> 
> "RETIRE" : {
> 
> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" {
> 
> "operations" : [
> 
> {
> 
> "RETIRE" : {
> 
> "key" : "members"
> 
> }
> 
> }
> 
> ] }
> 
> 
> Here's what we need to discuss - Do the Pros make the suggestio

---

From: Melinda Shore <[email-masked]>
Date: Sun, 12 Aug 2012 16:53:19 -0800

> requirement. Too complex and too chatty.

This strikes me as rather an important point.  It might be more
productive to think about error messaging in this context.

Melinda

---

From: William Mills <[email-masked]>
Date: Sun, 12 Aug 2012 19:28:31 -0700 (PDT)

Test and set perhaps, but read before write implies locking...  which you don't wanna go there.

> From: Melinda Shore <[email-masked]>
>To: [email-masked] 
>Sent: Sunday, August 12, 2012 5:53 PM

---

From: Ganesh and Sashi Prasad <[email-masked]>
Date: Mon, 13 Aug 2012 13:54:55 +1000

> I strongly object to anything that leads to a read before modify
requirement. Too complex and too chatty.

Sorry Phil, but you're contradicting yourself here. There seems to be an
awful lot of matching (i.e., reading) going on in the spec as it stands,
with if-then clauses to do one thing or another if the match either
succeeds or fails. This is a complex, chatty protocol right now!

   Multi-valued attributes:  An attribute value in the PATCH request
      body is added to the value collection if the value does not exist
      and merged if a matching value is present.  Values are matched by
      comparing the value Sub-Attribute from the PATCH request body to
      the value Sub-Attribute of the Resource.  Attributes that do not
      have a value Sub-Attribute; e.g., addresses, or do not have unique
      value Sub-Attributes cannot be matched and must instead be deleted
      then added.  Specific values can be removed from a Resource by
      adding an "operation" Sub-Attribute with the value "delete" to the
      attribute in the PATCH request body.  As with adding/updating
      attribute value collections, the value to delete is determined by
      comparing the value Sub-Attribute from the PATCH request body to
      the value Sub-Attribute of the Resource.  Attributes that do not
      have a value Sub-Attribute or that have a non-unique value Sub-
      Attribute are matched by comparing all Sub-Attribute values from
      the PATCH request body to the Sub-Attribute values of the
      Resource.  A delete operation is ignored if the attribute's name
      is in the meta.attributes list.  If the requested value to delete
      does not match a unique value on the Resource the server MAY
      return a HTTP 400 error.

For a spec that is supposed to be about simplicity, the above description
is anything but simple. I know you guys have worked hard on this and I
don't mean to disparage those efforts, but think about how the above
passage would appear to a new reader (i.e., a novice to the spec, not a
technology novice).

There is something fundamentally broken, and it is this: multi-valued
attributes without a unique identifier per value. If you don't fix that,
you won't get simplicity.

We know LDAP trees are broken for multi-valued attributes. As Mark
Wahl famously
commented <http://www.ldap.com/1/commentary/wahl/20050617_01.shtml> back in
2005,

"Unfortunately, some of the emerging protocols which also intend to
represent and transfer personal identity information have perhaps taken a
step backwards by not even considering these issues, perhaps sweeping them
under the rug in the guise of simplicity, XMLification, or "fix in the next
version", which only postpone finding interoperable solutions to allowing
applications to express the identity entries they want to express."

SCIM is exactly one of these "emerging protocols" Wahl talks about, and
what I see now strikes me as "sweeping these issues under the rug in the
guise of simplicity". Apologies for the bluntness.

My take is that SPs are _already_ struggling to manage multi-valued
attributes, and existing mechanisms are
clumsy<http://ff1959.wordpress.com/2011/07/28/replace-a-value-of-a-multi-valued-attribute/>.
They would be grateful for a specification that made operations easier at
the cost of a re-engineered schema. That calls for some thought leadership
from this working group.

Regards,
Ganesh

On 13 August 2012 10:13, Phil Hunt <[email-masked]> wrote:

> > If so, I believe that this is impracticable in the core schema. Indeed
> it implies that a service provider must extend the schema of his account
>> Said differently, SCIM must not be intrusive for existing systems and
>> must not require modifications to allow its integration.****
>>
>> That's exactly the point. How do we "specify completely for uniqueness"?*
>> ***
>>
>> ** **
>>
>> what this proposal will actually entail for them?****
>>
>> ** **
>>
>> Regards,****
>>
>> Ganesh****
>>
>> ** **
>>
>> I'm curious if anyone else in the WG is in favor of unique identifiers
>> for every multi-valued element.****
>>
>> ** **
>>
>> --Kelly****
>>
>> ** **
>> Now I'm confused :-). I don't believe any of my examples ever used a
>> value as the key.****
>>
>> ** **
>>
>> Could you please show me which example you mean, and which parts of it
>> you believe to be the value?****
>>
>> ** **
>>
>> Regards,****
>>
>> Ganesh ****
>>
>> In your example you are conflating value with an attribute id. I find
>> that confusing. ****
>>
>> ** **
>>
>> ID.****
>> Here's how to delete a single member from a Group, as per the current
>> spec:****
>>
>> ** **
>>

---

From: Melinda Shore <[email-masked]>
Date: Sun, 12 Aug 2012 20:06:00 -0800

> succeeds or fails. This is a complex, chatty protocol right now!

??  Not really.  Try putting together a state machine diagram for
the current spec and a state machine diagram for what you're proposing.

The issue being raised here isn't endpoint logic, but
network traffic, and I'm pretty sure it's not very helpful to
respond to the observation that your model requires more
messages with a complaint about what you seem to think is a
complex algorithm for attribute processing.

Melinda

---

From: Ganesh and Sashi Prasad <[email-masked]>
Date: Mon, 13 Aug 2012 16:35:19 +1000

Responding to extract of Melinda Shore's mail from digest:

It depends on how it's implemented. I'm confident we can have the best of
both - simple API with low-overhead implementation. Can we brainstorm HOW
this proposal can be implemented rather than WHY it can't be implemented
(which is mostly what I've been hearing so far)? After all, no one has
challenged the claim that this proposal drastically simplifies the API for
the client, so it would appear to be worth doing. I'm sure there's more
than enough intellectual horsepower in this working group to pull this off
if we put our minds to it.

Regards,
Ganesh

On 13 August 2012 13:54, Ganesh and Sashi Prasad <[email-masked]>wrote:

> We know LDAP trees are broken for multi-valued attributes. As Mark Wahl famously
> commented <http://www.ldap.com/1/commentary/wahl/20050617_01.shtml> back
> in 2005,
>
> attributes, and existing mechanisms are clumsy<http://ff1959.wordpress.com/2011/07/28/replace-a-value-of-a-multi-valued-attribute/>.
>> That's why I asked if there was an SP representative on this working
>> group who could explain what such a change could mean for them. As of now,
>> it looks like other people are presuming that SPs will not be able to
>>> be updated if we can't use positional indexes?****
>>>
>>> ** **
>>>
>>> to delete.****
>>> The spec already allows multiple values to have tags like home, work,
>>> etc.****
>>>
>>> ** **
>>>
>>> Phil****
>>>
>>>
>>> I'm adopting a model where every attribute of the resource is a
>>> key-value pair. The key is a name or ID.****
>>>
>>> ** **
>>>
>>> REPLACE a fully-qualified key with a new value. If the key doesn't
>>> exist, return a "404 Not Found".****
>>>
>>> ** **
>>>
>>> key. If there is already a key with that name, return a "409 Conflict".*
>>> ***
>>>
>>> ** **
>>>
>>> Pro 3: Adoption of the standard by clients is likely to be higher
>>> because it's simpler for them.****
>>>
>>> ** **
>>>
>>> LDAP directories.****
>>> is what you fear.****
>>> of the spec by different parties.****
>>>
>>> ** **
>>>

---

From: Kelly Grizzle <[email-masked]>
Date: Mon, 13 Aug 2012 14:27:25 +0000

> After all, no one has challenged the claim that this proposal drastically simplifies the API for the client

I agree that your proposal makes PATCH semantics simpler and more elegant.

> ... so it would appear to be worth doing.

I strongly disagree here.  This statements assumes that simplicity of the client API is the only factor that should be considered with the spec.

Emmanuel's example is from a real-world service provider that would not be able to implement the spec easily with a uid per element.  He is working on a SCIM interface that will help facilitate data exchange between multiple Active Directory servers.  Your solution was to change the data model from this:

mail: [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>

to this:

mail: aa66-daf9ea3bd902=[email-masked]<mailto:[email-masked]>,9cda-8646c3085bbf=[email-masked]<mailto:[email-masked]>, 7a6d1de664e1=[email-masked]<mailto:[email-masked]>

I do not know of a single organization that would change their Active Directory data model to fit this.  For one thing, it would be a huge data migration effort (likely across other domain controllers, etc...) to assign these unique identifiers.  This also assumes that SCIM is the only reader/writer of this data, which will almost never be the case.  If the data model requires uids for every element, then every piece of non-SCIM code that writes data into the directory will have to follow this.  Additionally, there are *many* tools and applications  (eg - address books) that rely on a certain data model in Active Directory, and this would cause them to break.  IMO this same argument holds true for most service providers.

PATCH is an optional part of the spec.  It was primarily introduced to make modifying resources with large multi-valued lists more efficient.  It does not need to solve every problem (eg - modifying sub-elements in nested arrays).  Adding uids to every multi-valued element does not strike the right balance between the needs of the client and the needs of the service provider.

--Kelly

From: Ganesh and Sashi Prasad [mailto:[email-masked]]
Sent: Monday, August 13, 2012 1:35 AM
To: Phil Hunt; Melinda Shore
Cc: Emmanuel Dreux; Kelly Grizzle; [email-masked]
Subject: Re: [scim] scim Digest, Vol 8, Issue 24

It depends on how it's implemented. I'm confident we can have the best of both - simple API with low-overhead implementation. Can we brainstorm HOW this proposal can be implemented rather than WHY it can't be implemented (which is mostly what I've been hearing so far)? After all, no one has challenged the claim that this proposal drastically simplifies the API for the client, so it would appear to be worth doing. I'm sure there's more than enough intellectual horsepower in this working group to pull this off if we put our minds to it.

Regards,
Ganesh

> I strongly object to anything that leads to a read before modify requirement. Too complex and too chatty.
Sorry Phil, but you're contradicting yourself here. There seems to be an awful lot of matching (i.e., reading) going on in the spec as it stands, with if-then clauses to do one thing or another if the match either succeeds or fails. This is a complex, chatty protocol right now!

      return a HTTP 400 error.

For a spec that is supposed to be about simplicity, the above description is anything but simple. I know you guys have worked hard on this and I don't mean to disparage those efforts, but think about how the above passage would appear to a new reader (i.e., a novice to the spec, not a technology novice).

There is something fundamentally broken, and it is this: multi-valued attributes without a unique identifier per value. If you don't fix that, you won't get simplicity.

We know LDAP trees are broken for multi-valued attributes. As Mark Wahl famously commented<http://www.ldap.com/1/commentary/wahl/20050617_01.shtml> back in 2005,

"Unfortunately, some of the emerging protocols which also intend to represent and transfer personal identity information have perhaps taken a step backwards by not even considering these issues, perhaps sweeping them under the rug in the guise of simplicity, XMLification, or "fix in the next version", which only postpone finding interoperable solutions to allowing applications to express the identity entries they want to express."

SCIM is exactly one of these "emerging protocols" Wahl talks about, and what I see now strikes me as "sweeping these issues under the rug in the guise of simplicity". Apologies for the bluntness.

My take is that SPs are _already_ struggling to manage multi-valued attributes, and existing mechanisms are clumsy<http://ff1959.wordpress.com/2011/07/28/replace-a-value-of-a-multi-valued-attribute/>. They would be grateful for a specification that made operations easier at the cost of a re-engineered schema. That calls for some thought leadership from this working group.

Regards,
Ganesh

On 13 August 2012 10:13, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:
I strongly object to anything that leads to a read before modify requirement. Too complex and too chatty.

Phil

Yes.

mail: [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>
can be changed to

mail: aa66-daf9ea3bd902=[email-masked]<mailto:[email-masked]>,9cda-8646c3085bbf=[email-masked]<mailto:[email-masked]>, 7a6d1de664e1=[email-masked]<mailto:[email-masked]>

Regards,
Ganesh

On 13 August 2012 04:29, Emmanuel Dreux <[email-masked]<mailto:[email-masked]>> wrote:

=>  addresses.3cbaaff8e84e.street-number = "243"

De : Ganesh and Sashi Prasad [mailto:[email-masked]<mailto:[email-masked]>]
Envoyé : dimanche 12 août 2012 04:53
À : Kelly Grizzle
Cc : [email-masked]<mailto:[email-masked]>; Phil Hunt
Objet : Re: [scim] scim Digest, Vol 8, Issue 24

User object:

{
  ...
  addresses: [
    {
      "type" : "home",
      "street-number" : "35",

{
  "type" : "office",
  "street-number" : "213",

{
  ...
  addresses: {
    "d6ea365462f5" :
    {
      "type" : "home",
      "street-number" : "35",

Regards,
Ganesh

--Kelly

Regards,
Ganesh

Phil

@independentid

Regards,
Ganesh

Phil

I don't believe so.

Simple attribute:

Key: "dob"
Value: "01 Jan 1970"

Composite attribute:

Key: "address.suburb"
Value: "East Camden"

Multi-valued attribute:

Regards,
Ganesh

Today's Topics:

---------- Forwarded message ----------
From: Phil Hunt <[email-masked]<mailto:[email-masked]>>
To: Ganesh and Sashi Prasad <[email-masked]<mailto:[email-masked]>>
Cc: "Diodati, Mark" <[email-masked]<mailto:[email-masked]>>, Emmanuel Dreux <[email-masked]<mailto:[email-masked]>>, Trey Drake <[email-masked]<mailto:[email-masked]>>, Kelly Grizzle <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Fri, 10 Aug 2012 17:36:54 -0700
Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement
Ganesh,

Phil

Let's discuss that now.

Pros:

   Accept: application/json

   {

     "members": [

       {

         "operation": "delete"

       }

     ]

   }

   Accept: application/json

   {

     "meta": {

       "attributes": [

         "members"

       ]

     }

   }

Cons:

---

From: Ganesh and Sashi Prasad <[email-masked]>
Date: Tue, 14 Aug 2012 00:56:26 +1000

That was one suggestion. Another way could be container nodes with their
own "dn"s. If one suggestion won't work, tell me another way to make it
work. I'm waiting to hear a constructive suggestion that can square an
elegant API with the implementation constraints that come from having to
store multi-valued attributes in LDAP directories.

I've heard enough of WHY this won't work. For a change, tell me HOW it can
be made to work. Everyone now knows what the proposal means in terms of the
API, and implementors understand the constraints of legacy data stores, so
put the two together to propose a solution. C'mon, we have the "smartest
guys in the room" here, surely we should be able to crack this.

Regards,
Ganesh

P.S. I'm rapidly reaching my own conclusions about what is to be done:
http://wisdomofganesh.blogspot.com.au/2012/08/after-nosql-its-time-for-noldap.html

On 14 August 2012 00:27, Kelly Grizzle <[email-masked]> wrote:

>  > After all, no one has challenged the claim that this proposal
> drastically simplifies the API for the client****
>
> ** **
>
> > … so it would appear to be worth doing. ****
>
> ** **
>
> I strongly disagree here.  This statements assumes that simplicity of the
> client API is the only factor that should be considered with the spec.****
>
> ** **
>
> Emmanuel’s example is from a real-world service provider that would not be
> able to implement the spec easily with a uid per element.  He is working on
> a SCIM interface that will help facilitate data exchange between multiple
> Active Directory servers.  Your solution was to change the data model from
> this:****
>
> ** **
>
> mail: [email-masked], [email-masked], [email-masked]****
>
> ** **
>
> to this:****
>
> ** **
>
> [email-masked], 7a6d1de664e1=[email-masked]****
>
> ** **
>
> I do not know of a single organization that would change their Active
> Directory data model to fit this.  For one thing, it would be a huge data
> migration effort (likely across other domain controllers, etc…) to assign
> these unique identifiers.  This also assumes that SCIM is the only
> reader/writer of this data, which will almost never be the case.  If the
> data model requires uids for every element, then every piece of non-SCIM
> code that writes data into the directory will have to follow this.
> Additionally, there are **many** tools and applications  (eg – address
> books) that rely on a certain data model in Active Directory, and this
> would cause them to break.  IMO this same argument holds true for most
> service providers.****
>
> ** **
>
> ** **
>
> PATCH is an optional part of the spec.  It was primarily introduced to
> make modifying resources with large multi-valued lists more efficient.  It
> does not need to solve every problem (eg – modifying sub-elements in nested
> arrays).  Adding uids to every multi-valued element does not strike the
> right balance between the needs of the client and the needs of the service
> provider.****
>
> ** **
>
> --Kelly****
>
> ** **
>
> *From:* Ganesh and Sashi Prasad [mailto:[email-masked]]
> *Sent:* Monday, August 13, 2012 1:35 AM
> *To:* Phil Hunt; Melinda Shore
> *Cc:* Emmanuel Dreux; Kelly Grizzle; [email-masked]
>
> Responding to extract of Melinda Shore's mail from digest:****
>
> ** **
>
> The issue being raised here isn't endpoint logic, but****
>
> network traffic, and I'm pretty sure it's not very helpful to****
>
> respond to the observation that your model requires more****
>
> messages with a complaint about what you seem to think is a****
>
> complex algorithm for attribute processing.****
>
>  ** **
>
> if we put our minds to it.****
>
> ** **
>
> Regards,****
>
> Ganesh****
>
> ** **
>
> On 13 August 2012 13:54, Ganesh and Sashi Prasad <[email-masked]>
> wrote:****
>
> > I strongly object to anything that leads to a read before modify
> requirement. Too complex and too chatty.****
>
> succeeds or fails. This is a complex, chatty protocol right now!****
>
> ** **
>
>    Multi-valued attributes:  An attribute value in the PATCH request****
>
>       body is added to the value collection if the value does not exist****
>
>       and merged if a matching value is present.  Values are matched by****
>
>       comparing the value Sub-Attribute from the PATCH request body to****
>
>       the value Sub-Attribute of the Resource.  Attributes that do not****
>
>       have a value Sub-Attribute; e.g., addresses, or do not have unique****
>
>       value Sub-Attributes cannot be matched and must instead be deleted****
>
>       then added.  Specific values can be removed from a Resource by****
>
>       adding an "operation" Sub-Attribute with the value "delete" to the****
>
>       attribute in the PATCH request body.  As with adding/updating****
>
>       attribute value collections, the value to delete is determined by****
>
>       comparing the value Sub-Attribute from the PATCH request body to****
>
>       the value Sub-Attribute of the Resource.  Attributes that do not****
>
>       have a value Sub-Attribute or that have a non-unique value Sub-****
>
>       Attribute are matched by comparing all Sub-Attribute values from****
>
>       the PATCH request body to the Sub-Attribute values of the****
>
>       Resource.  A delete operation is ignored if the attribute's name****
>
>       is in the meta.attributes list.  If the requested value to delete****
>
>       does not match a unique value on the Resource the server MAY****
>
>       return a HTTP 400 error.****
>
>  ** **
>
> technology novice).****
> you won't get simplicity.****
>
> ** **
>
> in 2005,****
> applications to express the identity entries they want to express."****
>
> ** **
>
> guise of simplicity". Apologies for the bluntness.****
>
> ** **
>
> from this working group.****
>
> ** **
>
> Regards,****
>
> Ganesh****
>
> ** **
>
> On 13 August 2012 10:13, Phil Hunt <[email-masked]> wrote:****
>
> On 2012-08-12, at 15:29, Ganesh and Sashi Prasad <[email-masked]>
> wrote:****
>
> Yes.****
> API cleaner.****
> comma-separated name-value pairs.****
>
> ** **
>
> mail: [email-masked], [email-masked], [email-masked]****
>
> can be changed to****
>
> ** **
>
> [email-masked], 7a6d1de664e1=[email-masked]****
>
> ** **
>
> implement these changes easily and are rejecting them for that reason.****
>
> ** **
>
> Regards,****
>
> Ganesh****
>
> ** **
>
> On 13 August 2012 04:29, Emmanuel Dreux <[email-masked]> wrote:****
>
> ð  addresses.3cbaaff8e84e.street-number = "243"****
>
>  ****
>
> Here's what we need to discuss - Do the Pros make the suggestio****
>
>                   ** **
>
> ** **
>

---

From: Kelly Grizzle <[email-masked]>
Date: Mon, 13 Aug 2012 15:54:39 +0000

There are really two implementation options for a uid per element - either store the uids in the native underlying data store or have some secondary data store that maps elements to their uids.  The third option is to hope that a service provider has a NoLDAP data store or its equivalent.  None of these are practical for rapid and wide-spread adoption.

> put the two together to propose a solution.

As I said before, I am completely on board with cleaning up the PATCH semantics (eg - the inconsistency between meta.attributes and operation=delete, etc...).  Your suggestion of using different verbs is a good option to consider.  This cannot be based on a uid per element, though.  It seems as though you have admitted this in your conclusion - "As for LDAP and SCIM, I guess the best TLA is RIP."

--Kelly

From: Ganesh and Sashi Prasad [mailto:[email-masked]]
Sent: Monday, August 13, 2012 9:56 AM
To: Kelly Grizzle
Cc: Phil Hunt; Melinda Shore; Emmanuel Dreux; [email-masked]
Subject: Re: [scim] scim Digest, Vol 8, Issue 24

That was one suggestion. Another way could be container nodes with their own "dn"s. If one suggestion won't work, tell me another way to make it work. I'm waiting to hear a constructive suggestion that can square an elegant API with the implementation constraints that come from having to store multi-valued attributes in LDAP directories.

I've heard enough of WHY this won't work. For a change, tell me HOW it can be made to work. Everyone now knows what the proposal means in terms of the API, and implementors understand the constraints of legacy data stores, so put the two together to propose a solution. C'mon, we have the "smartest guys in the room" here, surely we should be able to crack this.

Regards,
Ganesh

to this:

--Kelly

From: Ganesh and Sashi Prasad [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, August 13, 2012 1:35 AM
To: Phil Hunt; Melinda Shore
Cc: Emmanuel Dreux; Kelly Grizzle; [email-masked]<mailto:[email-masked]>

Regards,
Ganesh

      return a HTTP 400 error.

Regards,
Ganesh

Phil

Yes.

Regards,
Ganesh

User object:

{
  ...
  addresses: [
    {
      "type" : "home",
      "street-number" : "35",

{
  "type" : "office",
  "street-number" : "213",

{
  ...
  addresses: {
    "d6ea365462f5" :
    {
      "type" : "home",
      "street-number" : "35",

Regards,
Ganesh

--Kelly

Regards,
Ganesh

Phil

@independentid

Regards,
Ganesh

Phil

I don't believe so.

Simple attribute:

Key: "dob"
Value: "01 Jan 1970"

Composite attribute:

Key: "address.suburb"
Value: "East Camden"

Multi-valued attribute:

Regards,
Ganesh

Today's Topics:

---------- Forwarded message ----------
From: Phil Hunt <[email-masked]<mailto:[email-masked]>>
To: Ganesh and Sashi Prasad <[email-masked]<mailto:[email-masked]>>
Cc: "Diodati, Mark" <[email-masked]<mailto:[email-masked]>>, Emmanuel Dreux <[email-masked]<mailto:[email-masked]>>, Trey Drake <[email-masked]<mailto:[email-masked]>>, Kelly Grizzle <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Fri, 10 Aug 2012 17:36:54 -0700
Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement
Ganesh,

Phil

Let's discuss that now.

Pros:

   Accept: application/json

   {

     "members": [

       {

         "operation": "delete"

       }

     ]

   }

   Accept: application/json

   {

     "meta": {

       "attributes": [

         "members"

       ]

     }

   }

Cons:

---

From: Charliemortimore <[email-masked]>
Date: Mon, 13 Aug 2012 12:25:53 -0400

Speaking as a large adopting service provider, we wouldn't be able to absorb a uniqueid per attribute scheme.   That said, in practice our patch support works fine without this

On Aug 13, 2012, at 11:54 AM, Kelly Grizzle <[email-masked]> wrote:

> There are really two implementation options for a uid per element – either store the uids in the native underlying data store or have some secondary data store that maps elements to their uids.  The third option is to hope that a service provider has a NoLDAP data store or its equivalent.  None of these are practical for rapid and wide-spread adoption.
>  
> As I said before, I am completely on board with cleaning up the PATCH semantics (eg – the inconsistency between meta.attributes and operation=delete, etc…).  Your suggestion of using different verbs is a good option to consider.  This cannot be based on a uid per element, though.  It seems as though you have admitted this in your conclusion – “As for LDAP and SCIM, I guess the best TLA is RIP.”
>  
> --Kelly
>  
> > … so it would appear to be worth doing. 
>  
> Emmanuel’s example is from a real-world service provider that would not be able to implement the spec easily with a uid per element.  He is working on a SCIM interface that will help facilitate data exchange between multiple Active Directory servers.  Your solution was to change the data model from this:
>  
> I do not know of a single organization that would change their Active Directory data model to fit this.  For one thing, it would be a huge data migration effort (likely across other domain controllers, etc…) to assign these unique identifiers.  This also assumes that SCIM is the only reader/writer of this data, which will almost never be the case.  If the data model requires uids for every element, then every piece of non-SCIM code that writes data into the directory will have to follow this.  Additionally, there are *many* tools and applications  (eg – address books) that rely on a certain data model in Active Directory, and this would cause them to break.  IMO this same argument holds true for most service providers.
>  
>  
> PATCH is an optional part of the spec.  It was primarily introduced to make modifying resources with large multi-valued lists more efficient.  It does not need to solve every problem (eg – modifying sub-elements in nested arrays).  Adding uids to every multi-valued element does not strike the right balance between the needs of the client and the needs of the service provider.
>  
> --Kelly
>  
> On 13 August 2012 13:54, Ganesh and Sashi Prasad <[email-masked]> wrote:
> We know LDAP trees are broken for multi-valued attributes. As Mark Wahl famously commented back in 2005,
>  
> My take is that SPs are _already_ struggling to manage multi-valued attributes, and existing mechanisms are clumsy. They would be grateful for a specification that made operations easier at the cost of a re-engineered schema. That calls for some thought leadership from this working group.
>  
> Regards,
> Ganesh
>  
>

---

From: Chris Phillips <[email-masked]>
Date: Mon, 13 Aug 2012 13:45:02 -0400

Kelly G's comments best match my opinion as well  --I too disagree with the proposed changes by Ganesh as they add unnecessary complexity.

The example below breaks practically any LDAP directory backing a mailstore and would force an implementor of SCIM to ghost their data somehow to support the changes Ganesh proposes. Something that certainly would make people avoid using SCIM at all.

Given that you have a number of thoughts about what could be changed in SCIM,Leif's recommendation to  craft them in an Internet Draft may be a better way to convey your thoughts.

Chris.

From: Kelly Grizzle <[email-masked]<mailto:[email-masked]>>
Date: Monday, 13 August, 2012 10:27 AM
To: Ganesh and Sashi Prasad <[email-masked]<mailto:[email-masked]>>, Phil Hunt <[email-masked]<mailto:[email-masked]>>, Melinda Shore <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Emmanuel Dreux <[email-masked]<mailto:[email-masked]>>
Subject: Re: [scim] scim Digest, Vol 8, Issue 24

to this:

--Kelly

Regards,
Ganesh

      return a HTTP 400 error.

Regards,
Ganesh

Phil

Yes.

Regards,
Ganesh

User object:

{
  ...
  addresses: [
    {
      "type" : "home",
      "street-number" : "35",

{
  "type" : "office",
  "street-number" : "213",

{
  ...
  addresses: {
    "d6ea365462f5" :
    {
      "type" : "home",
      "street-number" : "35",

Regards,
Ganesh

--Kelly

From:[email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] on behalf of Ganesh and Sashi Prasad [[email-masked]<mailto:[email-masked]>]

Regards,
Ganesh

Phil

@independentid

Regards,
Ganesh

Phil

I don't believe so.

Simple attribute:

Key: "dob"
Value: "01 Jan 1970"

Composite attribute:

Key: "address.suburb"
Value: "East Camden"

Multi-valued attribute:

Regards,
Ganesh

Today's Topics:

---------- Forwarded message ----------
From: Phil Hunt <[email-masked]<mailto:[email-masked]>>
To: Ganesh and Sashi Prasad <[email-masked]<mailto:[email-masked]>>
Cc: "Diodati, Mark" <[email-masked]<mailto:[email-masked]>>, Emmanuel Dreux <[email-masked]<mailto:[email-masked]>>, Trey Drake <[email-masked]<mailto:[email-masked]>>, Kelly Grizzle <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Fri, 10 Aug 2012 17:36:54 -0700
Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement
Ganesh,

Phil

Let's discuss that now.

Pros:

   Accept: application/json

   {

     "members": [

       {

         "operation": "delete"

       }

     ]

   }

   Accept: application/json

   {

     "meta": {

       "attributes": [

         "members"

       ]

     }

   }

Cons:

---

From: Ganesh and Sashi Prasad <[email-masked]>
Date: Tue, 14 Aug 2012 07:07:08 +1000

Thanks, Kelly. You've been most patient in hearing me out, I must say. I
couldn't ask for more.

Replying to Chris Philips's mail:
> Given that you have a number of thoughts about what could be changed in
SCIM,Leif's recommendation to  craft them in an Internet Draft may be a
better way to convey your thoughts.

I'm coming around to the same conclusion. Do you think such an Internet
Draft should be about changing SCIM, or should it propose a complementary
spec for SPs who use a "NoLDAP" data store? I think the underlying problem
is with LDAP, and unless we change that, these proposals won't fly.

Regards,
Ganesh

On 14 August 2012 01:54, Kelly Grizzle <[email-masked]> wrote:

>  There are really two implementation options for a uid per element –
> either store the uids in the native underlying data store or have some
> secondary data store that maps elements to their uids.  The third option is
> to hope that a service provider has a NoLDAP data store or its equivalent.
> None of these are practical for rapid and wide-spread adoption.****
>
> ** **
>
> > put the two together to propose a solution.****
>
> ** **
>
> As I said before, I am completely on board with cleaning up the PATCH
> semantics (eg – the inconsistency between meta.attributes and
> operation=delete, etc…).  Your suggestion of using different verbs is a
> good option to consider.  This cannot be based on a uid per element,
> though.  It seems as though you have admitted this in your conclusion – “As
> for LDAP and SCIM, I guess the best TLA is RIP.”****
>
> ** **
>
> --Kelly****
>
> ** **
>
> *Sent:* Monday, August 13, 2012 9:56 AM
> *To:* Kelly Grizzle
> *Cc:* Phil Hunt; Melinda Shore; Emmanuel Dreux; [email-masked]
>
> store multi-valued attributes in LDAP directories.****
>
> ** **
>
> guys in the room" here, surely we should be able to crack this.****
>
> ** **
>
> Regards,****
>
> Ganesh****
>
> ** **
>
> P.S. I'm rapidly reaching my own conclusions about what is to be done:****
>
>
> On 14 August 2012 00:27, Kelly Grizzle <[email-masked]>
> wrote:****
>
> *Cc:* Emmanuel Dreux; Kelly Grizzle; [email-masked]****
>
>

---

From: Leif Johansson <[email-masked]>
Date: Mon, 13 Aug 2012 23:38:35 +0200

On 08/13/2012 11:07 PM, Ganesh and Sashi Prasad wrote:
> Thanks, Kelly. You've been most patient in hearing me out, I must
> say. I couldn't ask for more.
> 
>> Given that you have a number of thoughts about what could be
>> changed
> in SCIM,Leif's recommendation to  craft them in an Internet Draft
> may be a better way to convey your thoughts.
> 
> I'm coming around to the same conclusion. Do you think such an
> Internet Draft should be about changing SCIM, or should it propose
> a complementary spec for SPs who use a "NoLDAP" data store? I think
> the underlying problem is with LDAP, and unless we change that,
> these proposals won't fly.

I don't think it matters at this point. My advise is to write up a
coherent proposal and think of it as input to the discussion.

	Leif

---

From: Trey Drake <[email-masked]>
Date: Mon, 13 Aug 2012 16:47:12 -0500

I don't believe LDAP is the culprit.  You'd find the same issue in most *existing* data models to include relational.  The issue is whether you're forcing the hand of the SP to overhaul their data model to accommodate SCIM.  I don't believe we would get very far if we took that tack.

Thanks,
Trey

On Aug 13, 2012, at 4:07 PM, Ganesh and Sashi Prasad <[email-masked]> wrote:

> Thanks, Kelly. You've been most patient in hearing me out, I must say. I couldn't ask for more.
> 
> I'm coming around to the same conclusion. Do you think such an Internet Draft should be about changing SCIM, or should it propose a complementary spec for SPs who use a "NoLDAP" data store? I think the underlying problem is with LDAP, and unless we change that, these proposals won't fly.
> 
> Regards,
> Ganesh
>

---

From: Ganesh and Sashi Prasad <[email-masked]>
Date: Tue, 14 Aug 2012 10:11:04 +1000

Hi Trey,

You have a point, but there are two levels to the difficulty. Relational
schemas are not cast in stone the way LDAP schemas are. Many of the object
classes in LDAP are not containers that can have their own DNs, so even if
an SP is willing to change their data model, they won't get far if they're
using LDAP.

Regards,
Ganesh

On 14 August 2012 07:47, Trey Drake <[email-masked]> wrote:

> I don't believe LDAP is the culprit.  You'd find the same issue in most
> *existing* data models to include relational.  The issue is whether you're
> forcing the hand of the SP to overhaul their data model to accommodate
> SCIM.  I don't believe we would get very far if we took that tack.
>
> Thanks,
> Trey
>
> On 14 August 2012 01:54, Kelly Grizzle <[email-masked]>wrote:
>
>> I've heard enough of WHY this won't work. For a change, tell me HOW it
>> can be made to work. Everyone now knows what the proposal means in terms of
>> the API, and implementors understand the constraints of legacy data stores,
>> so put the two together to propose a solution. C'mon, we have the "smartest
>> Emmanuel’s example is from a real-world service provider that would not
>> be able to implement the spec easily with a uid per element.  He is working
>> on a SCIM interface that will help facilitate data exchange between
>> multiple Active Directory servers.  Your solution was to change the data
>> model from this:****
>>
>>  ****
>>

---

From: Trey Drake <[email-masked]>
Date: Mon, 13 Aug 2012 23:39:29 -0500

IMO, one of the reasons why SCIM adoption is growing is that it does not force implementors to rework their schema.  I realize that you may think relational schemas may be more pliant, but most implementors are not deploying a greenfields SCIM backend.  Rather, SCIM is a front-end atop existing infrastructure.  A service provider backed with a "user" table defined with columns mapped to SCIM user attributes will be just as handicapped as a SP backed with LDAP/person.  Specifically, there's no hook for meta-data (guid) on a relational database column.  

I'm not sure what you mean by object classes not having a DN.  Object classes don't have DNs - entries do.

Thanks,
Trey

On Aug 13, 2012, at 7:11 PM, Ganesh and Sashi Prasad <[email-masked]> wrote:

> Hi Trey,
> 
> You have a point, but there are two levels to the difficulty. Relational schemas are not cast in stone the way LDAP schemas are. Many of the object classes in LDAP are not containers that can have their own DNs, so even if an SP is willing to change their data model, they won't get far if they're using LDAP.
> 
> Regards,
> Ganesh
>

---

From: Leif Johansson <[email-masked]>
Date: Tue, 14 Aug 2012 09:45:31 +0200

On 08/14/2012 06:39 AM, Trey Drake wrote:
> IMO, one of the reasons why SCIM adoption is growing is that it
> does not force implementors to rework their schema.  I realize that
> you may think relational schemas may be more pliant, but most
> implementors are not deploying a greenfields SCIM backend.  Rather,
> SCIM is a front-end atop existing infrastructure.  A service
> provider backed with a "user" table defined with columns mapped to
> SCIM user attributes will be just as handicapped as a SP backed
> with LDAP/person.  Specifically, there's no hook for meta-data
> (guid) on a relational database column.

As an individual I also strongly object to the notion that RDBMS schema
are more pliable than LDAP dito - in practice, once you nail down your
RDBMS model you're pretty much stuck with it.

But we digress (severely).

	Cheers Leif

---

From: Melinda Shore <[email-masked]>
Date: Tue, 14 Aug 2012 08:25:26 -0800

> RDBMS model you're pretty much stuck with it.

In my previous gig we were provisioning LDAP directory entries out of
SQL databases (SQL->SQL->LDAP) and I don't think I agree with that,
actually, or at least not in terms of attributes.  However, just
because it's pretty straightforward to add new tables and fields
doesn't mean that there's not a pile of dependent software that also
needs to be changed, or that it's easy to remove tables or fields.
LDAP is far less flexible in that regard.  But still, we're
probably constrained by the least flexible piece of the puzzle
(wow, what a stupid mixed metaphor), which is LDAP.

I've seen one SPML implementation and it was not spec-conforming.

Melinda

---

From: Anthony Nadalin <[email-masked]>
Date: Tue, 14 Aug 2012 19:54:37 +0000

We should not be constrained by LDAP restrictions, this would not be productive.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ganesh and Sashi Prasad
Sent: Monday, August 13, 2012 2:07 PM
To: Kelly Grizzle
Cc: Emmanuel Dreux; Melinda Shore; [email-masked]; Phil Hunt
Subject: Re: [scim] scim Digest, Vol 8, Issue 24

Regards,
Ganesh
On 14 August 2012 01:54, Kelly Grizzle <[email-masked]<mailto:[email-masked]>> wrote:
There are really two implementation options for a uid per element - either store the uids in the native underlying data store or have some secondary data store that maps elements to their uids.  The third option is to hope that a service provider has a NoLDAP data store or its equivalent.  None of these are practical for rapid and wide-spread adoption.

--Kelly

From: Ganesh and Sashi Prasad [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, August 13, 2012 9:56 AM
To: Kelly Grizzle
Cc: Phil Hunt; Melinda Shore; Emmanuel Dreux; [email-masked]<mailto:[email-masked]>

Regards,
Ganesh

to this:

--Kelly

Regards,
Ganesh

      return a HTTP 400 error.

Regards,
Ganesh

Phil

Yes.

Regards,
Ganesh

User object:

{
  ...
  addresses: [
    {
      "type" : "home",
      "street-number" : "35",

{
  "type" : "office",
  "street-number" : "213",

{
  ...
  addresses: {
    "d6ea365462f5" :
    {
      "type" : "home",
      "street-number" : "35",

Regards,
Ganesh

--Kelly

Regards,
Ganesh

Phil

@independentid

Regards,
Ganesh

Phil

I don't believe so.

Simple attribute:

Key: "dob"
Value: "01 Jan 1970"

Composite attribute:

Key: "address.suburb"
Value: "East Camden"

Multi-valued attribute:

Regards,
Ganesh

Today's Topics:

---------- Forwarded message ----------
From: Phil Hunt <[email-masked]<mailto:[email-masked]>>
To: Ganesh and Sashi Prasad <[email-masked]<mailto:[email-masked]>>
Cc: "Diodati, Mark" <[email-masked]<mailto:[email-masked]>>, Emmanuel Dreux <[email-masked]<mailto:[email-masked]>>, Trey Drake <[email-masked]<mailto:[email-masked]>>, Kelly Grizzle <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Fri, 10 Aug 2012 17:36:54 -0700
Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement
Ganesh,

Phil

Let's discuss that now.

Pros:

   Accept: application/json

   {

     "members": [

       {

         "operation": "delete"

       }

     ]

   }

   Accept: application/json

   {

     "meta": {

       "attributes": [

         "members"

       ]

     }

   }

Cons:

---

From: Ganesh and Sashi Prasad <[email-masked]>
Date: Thu, 16 Aug 2012 20:37:33 +1000

Hi all,

Would this hybrid architecture be a workable compromise? See diagram
towards the end: http://bit.ly/Rjc39Y

Regards,
Ganesh

On 15 August 2012 05:54, Anthony Nadalin <[email-masked]> wrote:

>  We should not be constrained by LDAP restrictions, this would not be
> productive.****
>
> ** **
>
> *Sent:* Monday, August 13, 2012 2:07 PM
> *To:* Kelly Grizzle
> *Cc:* Emmanuel Dreux; Melinda Shore; [email-masked]; Phil Hunt
>
> couldn't ask for more.****
>
> ** **
>
> Replying to Chris Philips's mail:****
>
> is with LDAP, and unless we change that, these proposals won't fly.****
>
> ** **
>
> Regards,****
>
> Ganesh****
>
> On 14 August 2012 01:54, Kelly Grizzle <[email-masked]>
> wrote:****
>
> There are really two implementation options for a uid per element – either
> store the uids in the native underlying data store or have some secondary
> data store that maps elements to their uids.  The third option is to hope
> that a service provider has a NoLDAP data store or its equivalent.  None of
> these are practical for rapid and wide-spread adoption.****
>
>  ****
>
> *Cc:* Phil Hunt; Melinda Shore; Emmanuel Dreux; [email-masked]****
>
>

---

From: Antonio Jara <[email-masked]>
Date: Thu, 16 Aug 2012 13:19:06 +0200

Hi,

I think that this is too complex, the idea of splitting the  
architecture into two directories, one for user provisioning with your  
idea of nested dictionaries instead of arrays to avoid the complexity  
during provisioning, and the second one the usual LDAP for  
Authentication/Authorization attributes to be compliant with the  
current deployments.

Assuming that the requirement is coming for the provisioning phase,  
Why not to define your design issues about the use of nested  
dictionaries to support attributes with multiple values in the entries  
from LDAP which needs to be used for the provisioning, and it is all.  
People interested in using them, will reach a simple solution to  
manage attributes with multiple values, other ones will require  
"fight" with a more complex process.

Regards

Quoting Ganesh and Sashi Prasad <[email-masked]>:

>> There are really two implementation options for a uid per element ? either
>> semantics (eg ? the inconsistency between meta.attributes and
>> operation=delete, etc?).  Your suggestion of using different verbs is a
>> though.  It seems as though you have admitted this in your conclusion ? ?As
>> for LDAP and SCIM, I guess the best TLA is RIP.?****
>>
>>  ****
>>
>> --Kelly****
>>
>>  ****
>>
>> > ? so it would appear to be worth doing. ****
>>
>>  ****
>>
>> Emmanuel?s example is from a real-world service provider that would not be
>> migration effort (likely across other domain controllers, etc?) to assign
>> Additionally, there are **many** tools and applications  (eg ? address
>> does not need to solve every problem (eg ? modifying sub-elements in nested
>> repository (LDAP partition, SQL db, ?) and ?prepare it? for SCIM
>> integration.****
>>
>>  ****
>>
>> repository (LDAP partition, SQL db, ?) and ?prepare it? for SCIM
>> integration.****
>>
>> example.comAccept: application/json Authorization: Bearer  
>> h480djs93hd8 ETag:
>> example.comAccept: application/json Authorization: Bearer  
>> h480djs93hd8 ETag:
>> example.comAccept: application/json Authorization: Bearer  
>> h480djs93hd8 ETag:

---

From: Kelly Grizzle <[email-masked]>
Date: Thu, 16 Aug 2012 15:59:34 +0000

Hi Ganesh ... your write-up concedes that this will be difficult to implement for an existing service provider.  I'm not sure that I understand the compromise.  Are you still suggesting that SCIM move to the unique-key-per-element strategy?

If so, the cost/benefit of this seems way off to me.  You are gaining a more elegant API by introducing an additional datastore and requiring replication.  I don't know of any service provider that would make this trade-off.  As you said, this is something that future service providers can keep in mind, but it is not going to help existing providers.

--Kelly

From: Ganesh and Sashi Prasad [mailto:[email-masked]]
Sent: Thursday, August 16, 2012 5:38 AM
To: Anthony Nadalin
Cc: Kelly Grizzle; Emmanuel Dreux; Melinda Shore; [email-masked]; Phil Hunt
Subject: Re: [scim] scim Digest, Vol 8, Issue 24

Hi all,

Would this hybrid architecture be a workable compromise? See diagram towards the end: http://bit.ly/Rjc39Y

Regards,
Ganesh
On 15 August 2012 05:54, Anthony Nadalin <[email-masked]<mailto:[email-masked]>> wrote:
We should not be constrained by LDAP restrictions, this would not be productive.

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Ganesh and Sashi Prasad
Sent: Monday, August 13, 2012 2:07 PM
To: Kelly Grizzle
Cc: Emmanuel Dreux; Melinda Shore; [email-masked]<mailto:[email-masked]>; Phil Hunt

Regards,
Ganesh

--Kelly

Regards,
Ganesh

to this:

--Kelly

Regards,
Ganesh

      return a HTTP 400 error.

Regards,
Ganesh

Phil

Yes.

Regards,
Ganesh

User object:

{
  ...
  addresses: [
    {
      "type" : "home",
      "street-number" : "35",

{
  "type" : "office",
  "street-number" : "213",

{
  ...
  addresses: {
    "d6ea365462f5" :
    {
      "type" : "home",
      "street-number" : "35",

Regards,
Ganesh

--Kelly

Regards,
Ganesh

Phil

@independentid

Regards,
Ganesh

Phil

I don't believe so.

Simple attribute:

Key: "dob"
Value: "01 Jan 1970"

Composite attribute:

Key: "address.suburb"
Value: "East Camden"

Multi-valued attribute:

Regards,
Ganesh

Today's Topics:

---------- Forwarded message ----------
From: Phil Hunt <[email-masked]<mailto:[email-masked]>>
To: Ganesh and Sashi Prasad <[email-masked]<mailto:[email-masked]>>
Cc: "Diodati, Mark" <[email-masked]<mailto:[email-masked]>>, Emmanuel Dreux <[email-masked]<mailto:[email-masked]>>, Trey Drake <[email-masked]<mailto:[email-masked]>>, Kelly Grizzle <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Fri, 10 Aug 2012 17:36:54 -0700
Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement
Ganesh,

Phil

Let's discuss that now.

Pros:

   Accept: application/json

   {

     "members": [

       {

         "operation": "delete"

       }

     ]

   }

   Accept: application/json

   {

     "meta": {

       "attributes": [

         "members"

       ]

     }

   }

Cons:

---

From: Phil Hunt <[email-masked]>
Date: Thu, 16 Aug 2012 10:42:12 -0700

I do think we need to arrive at some consensus on this now because Ganesh's proposal is a major "fork-in-the-road" decision. If we table it, it will be hard to come back to. This is why I have engaged on the subject with Ganesh so thoroughly.  Never-the-less, I would like to arrive at some conclusions here.

My apologies, but I thought it was worth re-stating the problem for those late to the discussion would be useful.

Background:
At present, the current spec does not allow you to change a specific sub-attribute in a multi-valued complex attribute structure (e.g. changing street name in a specific address value instance such as "home").  The proposal is that each sub attribute in a multi-valued structure gets its own unique identifier.  Then you can directly reference the specific complex attribute component in a complex value.

The current draft proposal requires that complex-value (e.g. an address value which is made up of number, street, city, etc) be changed if you want to change any of the sub-attributes. The current approach seems a reasonable compromise since it is likely the collection of attributes in a complex "value" are often manipulated together. IOW. You tend to set them all at once.  Ganesh's proposal allows specific sub-attributes to be directly addressable by giving each value instance a unique identifier.   

Another example of this is the group "member" attribute.  In the current draft, a member can have a value and a display name. In this case you would usually change the value (object identifier) and the name as well.  Ganesh's proposal would allow "Display Name" to be changed or value to be changed.  Something, IMV, that doesn't occur nearly as often.  IOW members change group membership, but members rarely change names.

My conclusion:
If the client must first query (or have synchronized the value identifiers), then the client has to do even more work than the current proposal of replacing the enter complex value.  Given such a choice I'm really skeptical that the pattern proposed by Ganesh would be widely used.  While Ganesh's proposal may be "specific", the practical simplicity of it is very much debatable.

The benefit of specific sub-attribute identifiers needs to be substantial.  We're not only talking about changing how infrastructure is done, but also how applications are written. This leaves out the entire current adopters and all enterprise users.  A big concern we have obviously is we have to consider existing infrastructure and data stores and be realistic. I don't think the benefit is worth the cost.

I agree with the others that the current draft could be changed to make patch operations more clear to the developer (simpler to read). While this may not improve logic, it will improve understanding and simplicity. The fact that certain operations may require an entire complex attribute value to be replaced is a reasonable compromise and should not be changed. 

Phil

@independentid
www.independentid.com
[email-masked]

On 2012-08-16, at 8:59 AM, Kelly Grizzle wrote:

> Hi Ganesh … your write-up concedes that this will be difficult to implement for an existing service provider.  I’m not sure that I understand the compromise.  Are you still suggesting that SCIM move to the unique-key-per-element strategy?
>  
> If so, the cost/benefit of this seems way off to me.  You are gaining a more elegant API by introducing an additional datastore and requiring replication.  I don’t know of any service provider that would make this trade-off.  As you said, this is something that future service providers can keep in mind, but it is not going to help existing providers.
>  
> --Kelly
>  
> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.comAccept: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" {
> "operations" : [
> {
> "RETIRE" : {
> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.comAccept: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" {
> "operations" : [
> {
> "RETIRE" : {
> "key" : "members"
> }
> }
> ] }
>

---

From: Erik Wahlström <[email-masked]>
Date: Thu, 16 Aug 2012 17:50:56 +0000

+1

My conclusion:

Phil

@independentid
www.independentid.com<http://www.independentid.com/>
[email-masked]<mailto:[email-masked]>

---

From: Melinda Shore <[email-masked]>
Date: Thu, 16 Aug 2012 09:55:00 -0800

On 8/16/12 9:42 AM, Phil Hunt wrote:
> The current draft proposal requires that complex-value (e.g. an address
> value which is made up of number, street, city, etc) be changed if you
> want to change any of the sub-attributes. The current approach seems a
> reasonable compromise since it is likely the collection of attributes in
> a complex "value" are often manipulated together. IOW. You tend to set
> them all at once.

I can imagine scenarios in which you might want to set a "sub-attribute"
(not sure I love this terminology) without knowing the sibling sub-
attributes, but they strike me as contrived and rather uncommon.  I
don't think the complexity introduced by Ganesh's proposal is counter-
weighted by any benefit that might come from it.  I don't support the
proposal.

Melinda

---

From: Chris Phillips <[email-masked]>
Date: Thu, 16 Aug 2012 15:23:29 -0400

+1 to Phil's comments.

As well, adding a ghost directory to [de|en]code things is just too much overhead to build into the protocol.  If someone wants to build that on TOP of SCIM, that's up to them.

While I appreciate the thought and time Ganesh has put into the concepts, I am not convinced the approach would be net better and less complex and so do not support it and welcome moving on to other topics.

C.

From: Phil Hunt <[email-masked]<mailto:[email-masked]>>
Date: Thursday, 16 August, 2012 1:42 PM
To: Kelly Grizzle <[email-masked]<mailto:[email-masked]>>
Cc: Emmanuel Dreux <[email-masked]<mailto:[email-masked]>>, Anthony Nadalin <[email-masked]<mailto:[email-masked]>>, Ganesh and Sashi Prasad <[email-masked]<mailto:[email-masked]>>, Melinda Shore <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [scim] scim Digest, Vol 8, Issue 24

Background:

My conclusion:

Phil

@independentid

--Kelly

From: Ganesh and Sashi Prasad [mailto:[email-masked]]
Sent: Thursday, August 16, 2012 5:38 AM
To: Anthony Nadalin
Cc: Kelly Grizzle; Emmanuel Dreux; Melinda Shore; [email-masked]<mailto:[email-masked]>; Phil Hunt
Subject: Re: [scim] scim Digest, Vol 8, Issue 24

Hi all,

Regards,
Ganesh

Regards,
Ganesh

--Kelly

Regards,
Ganesh

to this:

--Kelly

Regards,
Ganesh

      return a HTTP 400 error.

Regards,
Ganesh

Phil

Yes.

can be changed to

Regards,
Ganesh

User object:

{
  ...
  addresses: [
    {
      "type" : "home",
      "street-number" : "35",

{
  "type" : "office",
  "street-number" : "213",

{
  ...
  addresses: {
    "d6ea365462f5" :
    {
      "type" : "home",
      "street-number" : "35",

Regards,
Ganesh

--Kelly

Regards,
Ganesh

Phil

@independentid

Regards,
Ganesh

Phil

I don't believe so.

Simple attribute:

Key: "dob"
Value: "01 Jan 1970"

Composite attribute:

Key: "address.suburb"
Value: "East Camden"

Multi-valued attribute:

Regards,
Ganesh

Today's Topics:

---------- Forwarded message ----------
From: Phil Hunt <[email-masked]<mailto:[email-masked]>>
To: Ganesh and Sashi Prasad <[email-masked]<mailto:[email-masked]>>
Cc: "Diodati, Mark" <[email-masked]<mailto:[email-masked]>>, Emmanuel Dreux <[email-masked]<mailto:[email-masked]>>, Trey Drake <[email-masked]<mailto:[email-masked]>>, Kelly Grizzle <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Fri, 10 Aug 2012 17:36:54 -0700
Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement
Ganesh,

Phil

Let's discuss that now.

Pros:

   Accept: application/json

   {

     "members": [

       {

         "operation": "delete"

       }

     ]

   }

   Accept: application/json

   {

     "meta": {

       "attributes": [

         "members"

       ]

     }

   }

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com<http://example.com/>Accept: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" {
"operations" : [
{
"RETIRE" : {
"key" : "members.2819c223-7f76-453a-919d-413861904646"
}
}
] }
Here's how I suggest deleting ALL members from a group:

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com<http://example.com/>Accept: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" {
"operations" : [
{
"RETIRE" : {
"key" : "members"
}
}
] }

Cons:

---

From: Emmanuel Dreux <[email-masked]>
Date: Fri, 17 Aug 2012 10:41:35 +0000

Also agree to not follow Ganesh’s proposition.
As an IAM editor and technology provider for SAAS providers, I would be unable to push solutions that would require to change the provider’s data model. (90% would not accept such intrusion).

For information, we are doing 2 SCIM  integrations this month, for 2 SAAS providers who have 2 large customer’s Active Directories to synchronize (10 000 and 15 000 users). Deadline September 15.

That said, the problem of multi values is real and remains an issue for me.
Imagine that I catch Active Directory changes (for example a change in a street field: it might come from an administrator whno fixes this field, or a user that changes a value through a self service portal).
If our IAM product sends the change through a proprietary API (ex Google, Salesforce, Office365 api), then there is no problem.
If it send the change through SCIM, I will have to know and maintain somewhere that additional fields are linked together and I will have to get the values of all these fields in order to build the full SCIM object to patch it.

If you agree that this is an issue, would it be fair to try to improve this area in the specs?
--
Regards,
Emmanuel Dreux
http://www.cloudiway.com
Tel: +33 4 26 78 17 58
Mobile: +33 6 47 81 26 70
skype: Emmanuel.Dreux

De : Chris Phillips [mailto:[email-masked]]
Envoyé : jeudi 16 août 2012 21:23
À : [email-masked]
Objet : Re: [scim] scim Digest, Vol 8, Issue 24

+1 to Phil's comments.

C.

Background:

My conclusion:

Phil

@independentid

--Kelly

Hi all,

Regards,
Ganesh

Regards,
Ganesh

--Kelly

Regards,
Ganesh

to this:

--Kelly

Regards,
Ganesh

      return a HTTP 400 error.

Regards,
Ganesh

Phil

Yes.

Regards,
Ganesh

User object:

{
  ...
  addresses: [
    {
      "type" : "home",
      "street-number" : "35",

{
  "type" : "office",
  "street-number" : "213",

{
  ...
  addresses: {
    "d6ea365462f5" :
    {
      "type" : "home",
      "street-number" : "35",

Regards,
Ganesh

--Kelly

Regards,
Ganesh

Phil

@independentid

Regards,
Ganesh

Phil

I don't believe so.

Simple attribute:

Key: "dob"
Value: "01 Jan 1970"

Composite attribute:

Key: "address.suburb"
Value: "East Camden"

Multi-valued attribute:

Regards,
Ganesh

Today's Topics:

---------- Forwarded message ----------
From: Phil Hunt <[email-masked]<mailto:[email-masked]>>
To: Ganesh and Sashi Prasad <[email-masked]<mailto:[email-masked]>>
Cc: "Diodati, Mark" <[email-masked]<mailto:[email-masked]>>, Emmanuel Dreux <[email-masked]<mailto:[email-masked]>>, Trey Drake <[email-masked]<mailto:[email-masked]>>, Kelly Grizzle <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Fri, 10 Aug 2012 17:36:54 -0700
Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement
Ganesh,

Phil

Let's discuss that now.

Pros:

   Accept: application/json

   {

     "members": [

       {

         "operation": "delete"

       }

     ]

   }

   Accept: application/json

   {

     "meta": {

       "attributes": [

         "members"

       ]

     }

   }

Cons:

---

From: Charliemortimore <[email-masked]>
Date: Fri, 17 Aug 2012 18:04:50 -0700

+1 to Chris and Phil

- cmort

On Aug 16, 2012, at 12:23 PM, Chris Phillips <[email-masked]> wrote:

> To: Kelly Grizzle <[email-masked]>
> Cc: Emmanuel Dreux <[email-masked]>, Anthony Nadalin <[email-masked]>, Ganesh and Sashi Prasad <[email-masked]>, Melinda Shore <[email-masked]>, "[email-masked]" <[email-masked]>