Subject: [scim] Proposal to close ticket #5 as "won't fix"

From: Kelly Grizzle <[email-masked]>
Date: Mon, 12 Nov 2012 14:34:45 +0000

Ticket #5 in the issue tracker suggests allowing an attribute other than the User id to be used for references in the members attribute of the Group schema.  The reasoning for this proposal was that it would allow clients to process group membership without having to map a server-generated id to the client's unique identifier.  However, the externalId is neither required to be present or guaranteed to be unique (see issue 79 in the google issue tracker - http://code.google.com/p/scim/issues/detail?id=79).  I am proposing to close this ticket as "won't fix" since there is not a reliable way to reference a user without using the id.

Please respond with any comments.

--Kelly

-----Original Message-----
From: scim issue tracker [mailto:[email-masked]] 
Sent: Thursday, November 08, 2012 5:03 PM
To: [email-masked]; [email-masked]; Kelly Grizzle
Cc: [email-masked]
Subject: Re: [scim] #5: Consider supporting attribute other than "id" for the "members" attribute in Group Schema

#5: Consider supporting attribute other than "id" for the "members" attribute in Group Schema

Comment (by kelly.grizzle@…):

 I seem to remember that most of the SCIM 1.x team was opposed to this  since the id is the only guaranteed unique identifier.  I'm -1 and would  suggest that we close this as wontfix.

-- 
-----------------------------+------------------------------------------
-----------------------------+--
 Reporter:  melinda.shore@…  |       Owner:  draft-ietf-scim-core-schema@…
     Type:  enhancement      |      Status:  new
 Priority:  major            |   Milestone:
Component:  core-schema      |     Version:
 Severity:  -                |  Resolution:
 Keywords:                   |
-----------------------------+------------------------------------------
-----------------------------+--

Ticket URL: <http://trac.tools.ietf.org/wg/scim/trac/ticket/5#comment:2>
scim <http://tools.ietf.org/scim/>

---

From: Hasini Gunasinghe <[email-masked]>
Date: Mon, 12 Nov 2012 21:51:09 +0530

In the implementation point of view,
If the consumer is not storing the user to server-side id mapping, whenever
a group is created or updated wrt its members, consumer has to first query
the user resource through filter operation using a unique attribute that
consumer maintains related to users, obtain the server-generated id, create
the request including that id and send the create/update request to group
end point.

If the group includes multiple users, multiple calls need to be made to
obtain the sever-generated ids of the relevant user resources.

On the other hand, it might not be practical to maintain resource to
server-generated id mapping at the consumer side since one consumer can be
provisioning to multiple providers.

What I suggest is: if the consumer specifies an attribute name (eg:
username) [not necessarily a unique attribute according to the schema] and
the value to reference the user who is a member of a group being
manipulated, the server should honor that. And the consumer must make sure
to use an attribute which it maintains as unique over all the user
resources.
If the uniqueness is not maintained on the attribute used by the consumer
to reference the user, then server can throw an error and reject the
request.

Thanks,
Hasini.

On Mon, Nov 12, 2012 at 8:04 PM, Kelly Grizzle
<[email-masked]>wrote:

> Ticket #5 in the issue tracker suggests allowing an attribute other than
> the User id to be used for references in the members attribute of the Group
> schema.  The reasoning for this proposal was that it would allow clients to
> process group membership without having to map a server-generated id to the
> client's unique identifier.  However, the externalId is neither required to
> be present or guaranteed to be unique (see issue 79 in the google issue
> tracker - http://code.google.com/p/scim/issues/detail?id=79).  I am
> proposing to close this ticket as "won't fix" since there is not a reliable
> way to reference a user without using the id.
>
>  I seem to remember that most of the SCIM 1.x team was opposed to this
>  since the id is the only guaranteed unique identifier.  I'm -1 and would
>  suggest that we close this as wontfix.
>
> --
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim
>

---

From: Phil Hunt <[email-masked]>
Date: Mon, 12 Nov 2012 08:48:57 -0800

Kelly,

If I understand correctly, the problem is how/when to convert from client group representation to SP SCIM representation. 

I'd like to explore this a bit...

1.  [CURRENT DRAFT] Client converts to Id in advance:
  Pro: The client must convert their local identifier to the SP identifier (objectid).
  Con: The SP will undergo a lot more query traffic converting externalid, uid, mail, etc to object 'id'.  This is not an issue if client stores previously provisioned object Id values.
  Con: It takes an extra network operation per non-objectid member.

2. [PROPOSED] SP auto-converts unique object key attributes (externalId, uid, mail, etc):
  Pro: the client can present group updates using any unique key attribute using its own group representation.
  Pro: update is completed in a single network operation.
Neutral: Instead of incurring many lookups, the SP converts unique keys into object identifiers.
  Con: This could lead to a long-running operation for a large group in order to indicate success since chance of failure is increased.
  Con: The client could NOT compare the group values after reading the group back--> member values would be converted to object 'id' values.

3. [PROSPOSAL 2] SP allows for any unique id to be used as a member value with no conversion
I want to exclude this, I think this leads to much complexity and referential integrity issues and suggests membership may not be validated.
 Pro: SP represents group the same way client represents it making comparison possible
 Con: at some point, SP has to normalize the data.
 Con: when is group validated
 Con: unique key attributes are not as stable as object 'id' attributes

As an example many LDAP clients will have DN's as members. If the client previously provisioned Users and set externalId to their local LDAP DN, then updating groups could conceivably become easier.

I don't think there is a great answer here. For current implementers, any experience on this issue? Has option 1 been a problem?

From an error handling perspective, I like the current draft the best. It forces the client to ensure the group is valid before updating the SP.

Phil

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

On 2012-11-12, at 8:21 AM, Hasini Gunasinghe wrote:

> If the consumer is not storing the user to server-side id mapping, whenever a group is created or updated wrt its members, consumer has to first query the user resource through filter operation using a unique attribute that consumer maintains related to users, obtain the server-generated id, create the request including that id and send the create/update request to group end point.
> 
> If the group includes multiple users, multiple calls need to be made to obtain the sever-generated ids of the relevant user resources.
> 
> On the other hand, it might not be practical to maintain resource to server-generated id mapping at the consumer side since one consumer can be provisioning to multiple providers.
> 
> What I suggest is: if the consumer specifies an attribute name (eg: username) [not necessarily a unique attribute according to the schema] and the value to reference the user who is a member of a group being manipulated, the server should honor that. And the consumer must make sure to use an attribute which it maintains as unique over all the user resources.
> If the uniqueness is not maintained on the attribute used by the consumer to reference the user, then server can throw an error and reject the request.
> 
> Thanks,
> Hasini.
> 
> On Mon, Nov 12, 2012 at 8:04 PM, Kelly Grizzle <[email-masked]> wrote:

---

From: Erik Wahlström <[email-masked]>
Date: Tue, 13 Nov 2012 09:13:51 +0000

Hi,

I prefer the current draft version. The ID looses it's unique identifier status rather quickly if we start accepting other unique identifiers a part from the original unique identifier.

I also like the simplicity of always requiring the ID. There are no special cases that clients and servers must support. I prefer more server roundtrips over increased complexity and if server roundtrips is a problem for a client, the client can always persists the mapping.

So, all in all, +1 on "wont fix".

/ Erik

On Nov 12, 2012, at 5:48 PM, Phil Hunt wrote:

Kelly,

Phil

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

Thanks,
Hasini.

On Mon, Nov 12, 2012 at 8:04 PM, Kelly Grizzle <[email-masked]<mailto:[email-masked]>> wrote:
Ticket #5 in the issue tracker suggests allowing an attribute other than the User id to be used for references in the members attribute of the Group schema.  The reasoning for this proposal was that it would allow clients to process group membership without having to map a server-generated id to the client's unique identifier.  However, the externalId is neither required to be present or guaranteed to be unique (see issue 79 in the google issue tracker - http://code.google.com/p/scim/issues/detail?id=79).  I am proposing to close this ticket as "won't fix" since there is not a reliable way to reference a user without using the id.

--Kelly

-----Original Message-----
From: scim issue tracker [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, November 08, 2012 5:03 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Kelly Grizzle
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [scim] #5: Consider supporting attribute other than "id" for the "members" attribute in Group Schema

_______________________________________________
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

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

---

From: Hasini Gunasinghe <[email-masked]>
Date: Wed, 14 Nov 2012 13:13:12 +0530

On Tue, Nov 13, 2012 at 2:43 PM, Erik Wahlström <
[email-masked]> wrote:

>  Hi,
>
>  I prefer the current draft version. The ID looses it's unique identifier
> status rather quickly if we start accepting other unique identifiers a part
> from the original unique identifier.
>
>  I also like the simplicity of always requiring the ID. There are no
> special cases that clients and servers must support. I prefer more server
> roundtrips over increased complexity
>

Yes, if more server round trips are preferred over the complexity
in accommodating the requirement raised in ticket #5, we can stick to the
current draft with regard to this.
So +1 for resolving as 'won't fix'.

Thanks,
Hasini.

> and if server roundtrips is a problem for a client, the client can always
> persists the mapping.
>
>  If I understand correctly, the problem is how/when to convert from
> client group representation to SP SCIM representation.
>
>   Con: The SP will undergo a lot more query traffic converting externalid,
> uid, mail, etc to object 'id'.  This is not an issue if client stores
> previously provisioned object Id values.
>   Con: This could lead to a long-running operation for a large group in
> order to indicate success since chance of failure is increased.
>   Con: The client could NOT compare the group values after reading the
> group back--> member values would be converted to object 'id' values.
>
> I want to exclude this, I think this leads to much complexity and
> referential integrity issues and suggests membership may not be validated.
>  As an example many LDAP clients will have DN's as members. If the client
> previously provisioned Users and set externalId to their local LDAP DN,
> then updating groups could conceivably become easier.
>
>  I don't think there is a great answer here. For current implementers,
> any experience on this issue? Has option 1 been a problem?
>
>  From an error handling perspective, I like the current draft the best.
> It forces the client to ensure the group is valid before updating the SP.
>
>      Phil
>
>  @independentid
> www.independentid.com
>   [email-masked]
>
>
>
>
>
> If the consumer is not storing the user to server-side id mapping,
> whenever a group is created or updated wrt its members, consumer has to
> first query the user resource through filter operation using a unique
> attribute that consumer maintains related to users, obtain the
> server-generated id, create the request including that id and send the
> create/update request to group end point.
>

---

From: Kelly Grizzle <[email-masked]>
Date: Thu, 15 Nov 2012 14:01:40 +0000

Thanks, Hasini.  It feels like we have consensus on this one.  If anyone disagrees, please speak now.

--Kelly

From: Hasini Gunasinghe [mailto:[email-masked]]
Sent: Wednesday, November 14, 2012 1:43 AM
To: Erik Wahlström
Cc: Phil Hunt; [email-masked]; Kelly Grizzle
Subject: Re: [scim] Proposal to close ticket #5 as "won't fix"

On Tue, Nov 13, 2012 at 2:43 PM, Erik Wahlström <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

I also like the simplicity of always requiring the ID. There are no special cases that clients and servers must support. I prefer more server roundtrips over increased complexity

Yes, if more server round trips are preferred over the complexity in accommodating the requirement raised in ticket #5, we can stick to the current draft with regard to this.
So +1 for resolving as 'won't fix'.

Thanks,
Hasini.
and if server roundtrips is a problem for a client, the client can always persists the mapping.

/ Erik

Kelly,

Phil

@independentid

Thanks,
Hasini.

--Kelly

-----Original Message-----
From: scim issue tracker [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, November 08, 2012 5:03 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Kelly Grizzle
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [scim] #5: Consider supporting attribute other than "id" for the "members" attribute in Group Schema

Comment (by kelly.grizzle@...):

 Reporter:  melinda.shore@...  |       Owner:  draft-ietf-scim-core-schema@...

---

From: Leif Johansson <[email-masked]>
Date: Thu, 15 Nov 2012 20:48:52 +0100

> anyone disagrees, please speak now.
OK. Nobody speaks up. I'm calling this consensus.