Subject: [scim] Group Schema and use cases

From: Matt Randall <[email-masked]>
Date: Mon, 30 Sep 2013 11:04:04 -0500

I’ve observed that there aren’t many use cases documented around the use of
groups [1] within the SCIM specification.  Is this something the working
group needs contributions to from large cloud service providers?  My team
has found it difficult in practice to make use of this portion of the
schema without extension, which we’re concerned may increase the difficulty
for ECS’ to integrate with our service.  Specifically, displayName per its
name and documentation indicates that it must be a human-readable name for
a group, and is not required to be unique.  Without additional extension,
consumers are forced either populate groups whose display names are used as
a keying mechanism, or manually associate them via separate administrative
tooling.  For large numbers of groups, this can impart a significant
administrative burden.  A fictitious example of such a group:  “Application-A
Region-1 Business-Administrators”.  The usage of displayName as a key will
potentially complicate integration with multilingual cloud subscribers as
well.

We’d be delighted to have a dialogue on this topic with any interested
parties.

[1] http://tools.ietf.org/html/draft-ietf-scim-use-cases-00

Matt Randall

---

From: Phil Hunt <[email-masked]>
Date: Tue, 1 Oct 2013 10:10:42 -0700

Not sure what the issue here is. DisplayName is informational only since it is member that must be unique within the group. 

displayName is there to save look ups when displaying a group member in a UI-this is why it is supposed to be human readable. 

If you need another attribute like uid, that would be an extension. 

Phil

> On Sep 30, 2013, at 9:04, Matt Randall <[email-masked]> wrote:
> 
> I’ve observed that there aren’t many use cases documented around the use of groups [1] within the SCIM specification.  Is this something the working group needs contributions to from large cloud service providers?  My team has found it difficult in practice to make use of this portion of the schema without extension, which we’re concerned may increase the difficulty for ECS’ to integrate with our service.  Specifically, displayName per its name and documentation indicates that it must be a human-readable name for a group, and is not required to be unique.  Without additional extension, consumers are forced either populate groups whose display names are used as a keying mechanism, or manually associate them via separate administrative tooling.  For large numbers of groups, this can impart a significant administrative burden.  A fictitious example of such a group:  “Application-A Region-1 Business-Administrators”.  The usage of displayName as a key will potentially complicate integration with multilingual cloud subscribers as well.
> 
>  
> 
> We’d be delighted to have a dialogue on this topic with any interested parties.
> 
>  
> 
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim

---

From: Matt Randall <[email-masked]>
Date: Tue, 1 Oct 2013 18:52:36 -0500

As you've noted, to make use of groups in the majority of our use cases
we've had to use an extension.  I'm trying to understand the use cases
where the current specification provides direct value without extension, as
no documentation exists for them.   Is it envisioned that groups can be
used for making authorization decisions when supplemented with secondary
out-of-band administrative user interfaces for performing mapping?  Would a
scenario exist where a cloud service provider would pre-populate a
subscriber's scim repository with pre-defined groups that represent access
control lists?

The current specification has no mechanism that allows a cloud service
provider to derive meaning from a group without either extension or one of
the following:

- A separate out-of-band mechanism
- Deriving meaning from the displayName property
- Pre-populating a subscriber's repository with predefined groups

How are service providers here approaching the usage of groups?

On Tue, Oct 1, 2013 at 12:10 PM, Phil Hunt <[email-masked]> wrote:

> Not sure what the issue here is. DisplayName is informational only since
> it is member that must be unique within the group.
>
> displayName is there to save look ups when displaying a group member in a
> UI-this is why it is supposed to be human readable.
>
> I’ve observed that there aren’t many use cases documented around the use
> of groups [1] within the SCIM specification.  Is this something the
> working group needs contributions to from large cloud service providers?  My
> team has found it difficult in practice to make use of this portion of the
> for ECS’ to integrate with our service.  Specifically, displayName per
> its name and documentation indicates that it must be a human-readable name
> for a group, and is not required to be unique.  Without additional
> extension, consumers are forced either populate groups whose display names
> are used as a keying mechanism, or manually associate them via separate
> administrative tooling.  For large numbers of groups, this can impart a
> significant administrative burden.  A fictitious example of such a group:
> “Application-A Region-1 Business-Administrators”.  The usage of
> displayName as a key will potentially complicate integration with
> multilingual cloud subscribers as well.
>
>
>