Subject: [scim] userids, usernames, and group names

From: Dale Olds <[email-masked]>
Date: Fri, 31 Aug 2012 14:59:26 -0700

In our scim implementation we assign the following meanings to these 
user attributes:

* id: unique, immutable, required, not intended to be typed by humans. 
The only identifier safe to store in external systems.

* userName: unique, mutable, required, though rarely changed in 
practice, not localized -- more like a keyword. It's what humans can use 
when they need to type in a reference to a user.

* displayName: not unique, mutable, optional, used as input to some 
display context but might not be literally displayed.

Access control for the id and userName fields is identical -- they are 
both essentially treated as identifiers, displayName is different. These 
meanings work for us. All 3 attributes are used for specific purposes, 
and I believe our use does not violate the current spec. BTW, thanks for 
changing userName to be mutable in 1.1.

We are now implementing groups.

IIRC, the only choice the spec gives for human readable group names is 
displayName, but we have tools (e.g. CLIs) that need to accept a 
reference to a group typed in by a user. We could use displayName for 
that purpose, but then we lose the displayName capability that we have 
for users.

I've checked for this issue in the list archives but did not see any 
discussion. Has the group discussed a naming attribute for groups that 
would be more like userName than displayName?

A related issue is compound attributes such as Users.groups and 
Groups.members. If Groups had groupName attribute similar to userName 
for users, it would be most useful if these attributes could have 
sub-attributes like this:

User:
{
   id: 111111
   userName: 'joe'
   groups: [{display: 'Hiking Tour Guides', name: 'guides', value: 22222}]
}

Group:
{
   id: 22222
   groupName: 'guides'
   members: [{display: 'Joey', name: 'joe', value: 11111}]
}

I suppose we could add this capability as an extension, but would like 
to see if others would find this useful as well.

--Dale