Subject: [scim] Request for Input

From: Alexandre Santos <[email-masked]>
Date: Wed, 27 Mar 2013 16:01:01 -0700

For groups with many users (>10k) it becomes problematic to do POSTs or
PUTs. The only alternative would be PATCH. However PATCH is not mandatory.

For this reason we would like to request your input for the following
proposal: allow membership changes via PUT and DELETE.

For this the PUT and DELETE commands would be in the format:
PUT /Groups/<groupId>/user/<userId> - to add a user to a group
DELETE /Groups/<groupId>/user/<userId> - to remove the user from the group

Thank you,

*Alexandre Santos*  | Sr. Development Engineer
*Ping**Identity*  |   www.pingidentity.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
*O:* 604.697.7056
*Email:* [email-masked]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
*Connect with Ping*
Twitter: @pingidentity
LinkedIn Group: Ping's Identity Cloud
Facebook.com/pingidentitypage
*
*

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 27 Mar 2013 23:46:43 +0000

What do you mean by "membership changes" below ?

From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexandre Santos
Sent: Wednesday, March 27, 2013 4:01 PM
To: [email-masked]
Subject: [scim] Request for Input

For groups with many users (>10k) it becomes problematic to do POSTs or PUTs. The only alternative would be PATCH. However PATCH is not mandatory.

For this reason we would like to request your input for the following proposal: allow membership changes via PUT and DELETE.

Thank you,

Alexandre Santos  | Sr. Development Engineer
PingIdentity  |   www.pingidentity.com<http://www.pingidentity.com/>
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
O: 604.697.7056
Email: [email-masked]<mailto:[email-masked]>
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Connect with Ping
Twitter: @pingidentity
LinkedIn Group: Ping's Identity Cloud
Facebook.com/pingidentitypage

---

From: Alexandre Santos <[email-masked]>
Date: Wed, 27 Mar 2013 16:49:05 -0700

Adding and removing users to and from a group.

On Wed, Mar 27, 2013 at 4:46 PM, Anthony Nadalin <[email-masked]>wrote:

>  What do you mean by “membership changes” below ?****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Alexandre Santos
> *Sent:* Wednesday, March 27, 2013 4:01 PM
> *To:* [email-masked]
> *Subject:* [scim] Request for Input****
>
> ** **
>
> ****
> ** **
> proposal: allow membership changes via PUT and DELETE.****
>
> ** **
>
> For this the PUT and DELETE commands would be in the format:****
>
> PUT /Groups/<groupId>/user/<userId> - to add a user to a group****
>
> ****
> ** **
> Thank you,****
> ****
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - -****
>
> *Connect with Ping*
> Twitter: @pingidentity
> Facebook.com/pingidentitypage****
>
> * *
>
> ** **
>

---

From: Phil Hunt <[email-masked]>
Date: Wed, 27 Mar 2013 17:01:47 -0700

I think this may fit in with our discussion of adjusting PATCH to work better with multi-value and complex attributes (ticket 18).

So far, we've been avoiding extended paths that go within the Resource entity (e.g. to address specific attributes).

If you were to do the item below, I think you would have to add the attribute name to the path at the very least.

PUT /Groups/<groupid>/members/Users/<userid>

Still I think that may have problems if the member is actual a URL rather then a simple UUID.

Phil

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

On 2013-03-27, at 4:01 PM, Alexandre Santos wrote:

> PingIdentity  |   www.pingidentity.com
> Email: [email-masked]
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim

---

From: Kelly Grizzle <[email-masked]>
Date: Thu, 28 Mar 2013 13:10:00 +0000

PATCH was added specifically to address the "changing membership of a large group" use case.  The POST/DELETE to the members endpoint was considered when looking into PATCH, but unfortunately this does not work in the general case.  Specifically, this only works if the list elements have a unique identifier, so it fell apart when trying to apply this to adding/removing addresses (which do not have a unique identifier).

I'm not convinced that we need to add another mechanism to solve this use case, but I do agree that PATCH could be simplified.

--Kelly

From: [email-masked] [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Wednesday, March 27, 2013 7:02 PM
To: Alexandre Santos
Cc: [email-masked]
Subject: Re: [scim] Request for Input

Phil

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

Thank you,

Facebook.com/pingidentitypage<http://Facebook.com/pingidentitypage>

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

---

From: Erik Wahlström <[email-masked]>
Date: Thu, 28 Mar 2013 17:53:55 +0000

+1
Rather make patch mandatory before adding functionality to PUT and DELETE. Just for simplicity.
/ Erik

On Mar 28, 2013, at 2:10 PM, Kelly Grizzle wrote:

PATCH was added specifically to address the “changing membership of a large group” use case.  The POST/DELETE to the members endpoint was considered when looking into PATCH, but unfortunately this does not work in the general case.  Specifically, this only works if the list elements have a unique identifier, so it fell apart when trying to apply this to adding/removing addresses (which do not have a unique identifier).

I’m not convinced that we need to add another mechanism to solve this use case, but I do agree that PATCH could be simplified.

--Kelly

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Wednesday, March 27, 2013 7:02 PM
To: Alexandre Santos
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [scim] Request for Input

Phil

@independentid

Thank you,

---

From: Samuel Erdtman <[email-masked]>
Date: Sun, 31 Mar 2013 20:47:37 +0200

I would vote for the simplest solution that solves the problem, I think
Kelly raises a point that makes PUT and DELETE harder to get as clean as in
the examples I.e. there is no single unique id for most multivalued
attributes, the value attribute could be the same for several attributes
e.g. Same phone number could be used for both mobile and work then it is
the combination value and type that makes it unique. (With the current
discussion on not requiring global unique id's for the combined set group
and user will have the same problem if not required unique)

The solution might be to something like this:
PUT /Groups/<group-Id>/<attribute>/
e.g.
PUT /Groups/<group-Id>/members/

DELETE /Groups/<group-Id>/<attribute>/<type>/<value>
e.g.
DELETE /Groups/<group-Id>/members/User/<value>

We could also allow replace in one operation by doing put to a uniquely
identified attribute:
PUT /Groups/<group-Id>/<attribute>/<type>/<value>
e.g.
PUT /Groups/<group-Id>/members/User/<value>

In case we go for a solution like this I think that we also should simplify
or remove PATCH operation. We could do singe attribute delete, add and
update like this:
PUT /Groups/<group-Id>/<attribute> (add or update attribute)
PUT /Groups/<group-Id>/<attribute> (remove attribute)
This has the disadvantage towards patch that you can only handle one
attribute at the time or the full resource object.

Finally I would like to remind everyone that we have had the discussion of
adding an "unique" identifier to the attributes in a multivalued attribute
and the strongest argument against was that it is not possible when putting
SCIM on top of an existing data source.

Sent from my iPhone

On 28 mar 2013, at 18:54, "Erik Wahlström" <[email-masked]>
wrote:

 +1
Rather make patch mandatory before adding functionality to PUT and
DELETE. Just for simplicity.
/ Erik

  PATCH was added specifically to address the “changing membership of a
large group” use case.  The POST/DELETE to the members endpoint was
considered when looking into PATCH, but unfortunately this does not work in
the general case.  Specifically, this only works if the list elements have
a unique identifier, so it fell apart when trying to apply this to
adding/removing addresses (which do not have a unique identifier).

 I’m not convinced that we need to add another mechanism to solve this use
case, but I do agree that PATCH could be simplified.

 --Kelly

  *From:* [email-masked]
[mailto:[email-masked]<[email-masked]>
] *On Behalf Of *Phil Hunt
*Sent:* Wednesday, March 27, 2013 7:02 PM
*To:* Alexandre Santos
*Cc:* [email-masked]
*Subject:* Re: [scim] Request for Input

 I think this may fit in with our discussion of adjusting PATCH to work
better with multi-value and complex attributes (ticket 18).

  So far, we've been avoiding extended paths that go within the Resource
entity (e.g. to address specific attributes).

  If you were to do the item below, I think you would have to add the
attribute name to the path at the very least.

  Still I think that may have problems if the member is actual a URL rather
then a simple UUID.

     Phil

  @independentid
  www.independentid.com

[email-masked]

 Thank you,

   **

---

From: Phil Hunt <[email-masked]>
Date: Sun, 31 Mar 2013 12:31:36 -0700

The trade off here is that the simple request you propose becomes complex because multiple operations must be completed against a resource rather then completing all changes in a single albeit somewhat more complex patch.

The RESTful model now becomes more complex because now we have both a Resource level set of verbs and then we have attribute level verbs.

Finally, it seems doubtful you could get rid of the current PATCH operation - by adding simple value modification proposed below, the spec would now have two ways of modifying things through 2 different RESTful models (per above). 

Overall, the spec gets much longer and more complex because it has multiple choices and RESTful verb models.

Aside: We've talked at length about positional identifies before. The trouble with value identifiers is managing all those keys and requiring the client to look them up before deleting. In practice it seems simplest to just specify the value you want deleted and let the server sort it out on the server side (avoiding extra request/responses). The limitation of the server-side value key approach is you cannot have duplicate values. In general this seems reasonable.

Another option that was considered is the JSON Patch draft. http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-10
It works reasonably well when you know the entire contents of a JSON record/document. It's path construct doesn't really lend itself well to a Resource where the full document may not be available at the time of the PATCH.  In other words, the SCIM operation is to patch a remote object rather than a JSON document in hand.  In the end, it has the same limitation as the value identifiers. In particular for large groups, we want to avoid downloading the entire group just to allow the client to be able to patch it.  It's also worth noting that a SCIM client may not be allowed to know about the entire set of members in a SCIM Group.

A subtle tweak to the current PATCH that makes it more readable and less cryptic might be all we really need.

Phil

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

On 2013-03-31, at 11:47 AM, Samuel Erdtman wrote:

> I would vote for the simplest solution that solves the problem, I think Kelly raises a point that makes PUT and DELETE harder to get as clean as in the examples I.e. there is no single unique id for most multivalued attributes, the value attribute could be the same for several attributes e.g. Same phone number could be used for both mobile and work then it is the combination value and type that makes it unique. (With the current discussion on not requiring global unique id's for the combined set group and user will have the same problem if not required unique)
> 
> We could also allow replace in one operation by doing put to a uniquely identified attribute:
> In case we go for a solution like this I think that we also should simplify or remove PATCH operation. We could do singe attribute delete, add and update like this:
> This has the disadvantage towards patch that you can only handle one attribute at the time or the full resource object.
> 
> Finally I would like to remind everyone that we have had the discussion of adding an "unique" identifier to the attributes in a multivalued attribute and the strongest argument against was that it is not possible when putting SCIM on top of an existing data source.
> 
> 
> Sent from my iPhone
> 
> On 28 mar 2013, at 18:54, "Erik Wahlström" <[email-masked]> wrote:
> 
>> +1