Subject: [scim] SCIM Issues

From: Radovan Semancik <[email-masked]>
Date: Mon, 16 Apr 2012 15:08:56 +0200

Hello,

After reading the SCIM core specification I have compiled a list of 
issues, some of which I see as quite severe. I was encouraged by Travis 
Spencer to share the list here. So here it goes:

There is externalId attribute for user. It may seems as a single 
attribute but it is not. In fact "The Service Provider MUST always 
interpret the externalId as scoped to the Service Consumer's tenant". 
Which means that the provider needs to store one value for every client. 
This is an extra state that has nothing to do with the provider itself. 
It is transfer of client's responsibility to server. Wrong application 
of separation of concerns principle. This is not even made optional. 
Therefore it will complicate all the server deployments, regardless if 
it is necessary or not.

It looks like change of user's userName is not supported. This seems 
quite limiting to have two persistent identifiers for users (id and 
userName). Also, username changes are very common. If username is based 
on familyName it changes after most wedding for approximately half of 
the population.

The familyName and givenName attributes have culture-neutral names. This 
is a nice take from FOAF. But the middleName is not that good. It 
enforces "american" point of view to the schema. Maybe "additionalName" 
would be more appropriate.

User has displayName and also name/formatted attributes. It seems like 
these two are used for the same purpose? Or maybe it is displayName and 
userName? It looks like SCIM is following LDAP and SAP anti-patterns 
where users have just too many names to choose from. It is perhaps good 
for the entity that displays them, but terrible for the one that needs 
to manage that. The protocol should be more balanced in this aspect.

User has nickName as a top-level attribute. But isn't a "name" complex 
attribute a better place for nickName? Especially considering the fact 
that nickname is frequently formatted as a part of full name.

Does profileUrl represent application profile maintained by the 
application that is being provisioned? Or some other external profile? 
Should be "profileUrl" multivalued? The specification is not clear about 
that.

User has title and userType in the core schema. But these seem to better 
fit into the "enterprise" extension.

User has phoneNumbers, but no canonical phone number format is 
specified. This is limiting the usability of the specification 
especially in telco environment.

The type meta-attribute in the multi-valued attributes is a plain 
string. This is prone to conflicts, especially in ims and similar "open" 
attributes. URL instead of plain string may be a better choice.

And probably the most important one: Both groups and roles can be 
considered entitlements. The groups attribute is read-only, but it can 
be manipulated through Group Resource. Should such group also appear in 
entitlements user attribute? If it cannot than the correct name of that 
attribute should rather be "otherEntitlements" and the specification 
should make that clear. If it can then we have a redundancy: a group can 
be manipulated both through Group Resource and "entitlements" attribute. 
Similarly for roles. The specification does not specify if a role should 
only appear in "roles" and not in "entitlements" or can appear in both. 
The "SCIM Group Schema" also defines that roles may be represented as 
groups, which adds to the confusion. The ignorance of complexity of 
entitlement management was one of the time bombs in SPML. Not it is time 
bomb silently ticking in SCIM.

The members attribute in group does not scale. Groups with thousands of 
members are very difficult to manage in this way. And it is typical that 
a group such as "Generic Employee" have more members than that, not even 
speaking about telcos. This is one of the common problems in LDAP and 
also in SCIM. There is also a corollary: creating a user as a member of 
a group requires two operations: add user, modify group. This 
complicates the implementation in case that the second operation fails. 
Should a provisioning system report that as a failure or success? User 
is created but not assigned to a group. Good provisioning system should 
handle that, but how many good provisioning systems are out there?

Minor issue: Canonical types for members are capitalizes while other 
types start with lowercase letter.

Should not authenticationSchema be outside of the SCIM core schema? 
Schema defines no transport protocol and the authentication types 
clearly depend on transport protocols. Maybe a binding specificiation is 
a better place for authenticationSchema definition?

Resource schema has name attribute that obviously points to the object 
type. But it seems to be plain string. Namespace is not obvious here. If 
any SCIM extension adds a new object types (which seems likely) this may 
be very confusing. URL may be a better choice here.

User has userName, displayName and name/formatted. Group has 
displayName. Resource has name as string. It is confusing. It is also 
quite inconsistent and makes if difficult to support uniform 
representation of "objects" in the underlying SCIM implementation.

Resource Schema has description, but user and groups does not? 
Description may come handy in any object.

Can endpoint in the Resource Schema be only relative? Or may it be 
absolute? Base URL is not a good concept, especially when it comes to 
different representations of the schema (e.g. see 
http://www.w3.org/2001/tag/doc/alternatives-discovery.html).

The attributes/type definition in Resource Schema does not specify 
whether the value is URL or QName or plain string. If a plain string 
(which seems to be the case by looking at the examples) how to map that 
string to XSD QNames? Are only XSD data types possible? The 
specification says "SHOULD not" not "MUST NOT", therefore an extension 
mechanism should be specified here.

The multiValuedAttributeChildName attribute and associated way how to 
represent data in XML seems to add to the redundancy of the data format. 
Strictly speaking, this one is also quite specific to XML and should not 
be in the generic core schema.

When defining an attribute in a resource schema, how is attribute schema 
used? Is it a namespace that applies to attribute type? Or to the 
attribute name? Attribute has schema and sub-attribute does not? Why? 
Does it inherit it from parent? The specification should make that clear.

Sub-attributes cannot have sub-attributes?

If the type is mandatory for every multi-valued attribute (is 
"hardcoded" in the core schema specification), is there any point to 
define it explicitly in all the resource schemas?

I have noticed meta attribute in the examples, but it looks like it is 
not defined in the specification.

Is ordering of multi-value attribute values significant?

Critical problems in JSON-like representations: as there are no 
namespaces in JSON, naming conflicts can happen. If two schemas define a 
"employeeNumber" attribute while one of them defines it as string and 
the other as number, such schemas cannot be used together. Is this a 
known limitation of SCIM?

( The original post is here: 
http://storm.alert.sk/blog/2012/04/13/SCIMming-the-Surface )

-- 

                                            Radovan Semancik
                                           Software Architect
                                              evolveum.com

---

From: Chris Phillips <[email-masked]>
Date: Mon, 16 Apr 2012 12:00:02 -0400

Hi Radovan (and others),

I've been lurking on the list and it's been great to see the depth that
people are going to on SCIM.

As the contributor for the core schema attributes entitlements and roles
it's not about redundancy and 'can I fit one into the other' it is about
'can I preserve what is intended by roles, groups and entitlements?'.  To
do so needs all these fields.

The original use cases about the differences expressed between groups,
roles, and entitlements are here[1].

Summarized:
	Groups are things you belong to
	Roles are things you are (and implies the assignment of a collection of
entitlements)
	Entitlements are things you have

Implementing SCIM with the schema capable of representing these means not
having to serialize one into the other and then trying to figure out on
the other end what to de-serialize. SCIM is agnostic and preserves the
fidelity of the information regardless of what you are doing with groups,
roles, or entitlements.

The spec does not constrain or exclude anything from any of those 3 fields
because it shouldn't.  Following a certain access control paradigm or
consuming the attributes in a particular fashion once the values are
delivered are up to the implementer to decide what to do next.

Hope this helps...

Chris.
___________________________________________________________________________
________________
Chris Phillips 
Technical Architect, Canadian Access Federation | CANARIE|
[email-masked]

[1]http://groups.google.com/group/cloud-directory/msg/41d160f6d0edddb6?

---

From: Radovan Semancik <[email-masked]>
Date: Mon, 16 Apr 2012 19:03:48 +0200

Chris,

As far as I understand the theory behind specifications, the 
specifications are always about constraining something. I understand 
that everything cannot be constrained, but the specification should go 
to the reasonable details. I was thinking how I would implement this 
particular piece of SCIM when I realized it can be implement in many 
different ways. And that somehow does not align with my understanding of 
"standard specification". The more ways is there to implement the same 
thing the lower is the probability that implementations will be 
interoperable. If the core schema cannot specify this part in sufficient 
detail then maybe it should be moved into an (experimental) extension?

Regarding the explanation: there is a very fuzzy boundary between "what 
I am" and "what I have". E.g. the same thing can be expressed as both: 
"I am system administrator" and "I have the right to do system 
administration". It also can be expressed as group "I am a member of the 
'admin' group". Therefore these concepts may significantly overlap. 
Which is not a bad thing per se and I guess that every system will 
figure a way how to represent them in SCIM. But because these concepts 
overlap, there should be a clear specification how they should be 
represented in SCIM. E.g. explicitly state whether "entitlements", 
"roles" and "groups" MAY or MUST NOT contain representation of the same 
entity (are overlapping or disjoint sets) at the very minimum. Otherwise 
this will not lead to interoperable implementations and the whole point 
of standardizing these aspects is pointless.

And there yet another level of complexity here: extensions. Groups have 
its own object now. Why roles and entitlements do not have that? Is it 
expected to come in the future? Or be defined as per-deployment 
extension? If that is the case, can an extension define a sub-class of 
entitlements, e.g. "Privileges". How will the logic work in that case? 
E.g. a "privilege" should then also appear in entitlements, but roles 
and groups should not?

This is a very tricky part. I guess that the best approach here would be 
to base the specification on a sound formal model.

-- 

                                            Radovan Semancik
                                           Software Architect
                                              evolveum.com

---

From: Michael Hammer <[email-masked]>
Date: Mon, 16 Apr 2012 17:47:29 +0000

Hmmm...
It sounds like roles are a collection of entitlements, while a group is a
collection of individuals.  (Not sure what a "you" is.)
It would then seem that roles/entitlements could be assigned to either
individuals or groups.
Can we then infer that a binding of individual to a group also leads to
indirect binding to roles assigned to group, and further to entitlements
assigned to roles?
Seems like a lot can get inherited with recursive checks of bindings.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Radovan Semancik
Sent: Monday, April 16, 2012 1:04 PM
To: [email-masked]
Subject: Re: [scim] About roles, entitlements, and groups, was ->Re: SCIM
Issues

Chris,

As far as I understand the theory behind specifications, the specifications
are always about constraining something. I understand that everything cannot
be constrained, but the specification should go to the reasonable details. I
was thinking how I would implement this particular piece of SCIM when I
realized it can be implement in many different ways. And that somehow does
not align with my understanding of "standard specification". The more ways
is there to implement the same thing the lower is the probability that
implementations will be interoperable. If the core schema cannot specify
this part in sufficient detail then maybe it should be moved into an
(experimental) extension?

Regarding the explanation: there is a very fuzzy boundary between "what I
am" and "what I have". E.g. the same thing can be expressed as both: 
"I am system administrator" and "I have the right to do system
administration". It also can be expressed as group "I am a member of the
'admin' group". Therefore these concepts may significantly overlap. 
Which is not a bad thing per se and I guess that every system will figure a
way how to represent them in SCIM. But because these concepts overlap, there
should be a clear specification how they should be represented in SCIM. E.g.
explicitly state whether "entitlements", "roles" and "groups" MAY or MUST
NOT contain representation of the same entity (are overlapping or disjoint
sets) at the very minimum. Otherwise this will not lead to interoperable
implementations and the whole point of standardizing these aspects is
pointless.

And there yet another level of complexity here: extensions. Groups have its
own object now. Why roles and entitlements do not have that? Is it expected
to come in the future? Or be defined as per-deployment extension? If that is
the case, can an extension define a sub-class of entitlements, e.g.
"Privileges". How will the logic work in that case? 
E.g. a "privilege" should then also appear in entitlements, but roles and
groups should not?

This is a very tricky part. I guess that the best approach here would be to
base the specification on a sound formal model.

-- 

                                            Radovan Semancik
                                           Software Architect
                                              evolveum.com

On 04/16/2012 06:00 PM, Chris Phillips wrote:
> Hi Radovan (and others),
>
> I've been lurking on the list and it's been great to see the depth 
> that people are going to on SCIM.
>
> As the contributor for the core schema attributes entitlements and 
> roles it's not about redundancy and 'can I fit one into the other' it 
> is about 'can I preserve what is intended by roles, groups and 
> entitlements?'.  To do so needs all these fields.
>
> 	Roles are things you are (and implies the assignment of a collection

> of
> Implementing SCIM with the schema capable of representing these means 
> not having to serialize one into the other and then trying to figure 
> out on the other end what to de-serialize. SCIM is agnostic and 
> preserves the fidelity of the information regardless of what you are 
> doing with groups, roles, or entitlements.
>
> The spec does not constrain or exclude anything from any of those 3 
> fields because it shouldn't.  Following a certain access control 
> paradigm or consuming the attributes in a particular fashion once the 
> values are delivered are up to the implementer to decide what to do next.
>
> Hope this helps...

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

---

From: Samuel Erdtman <[email-masked]>
Date: Tue, 17 Apr 2012 07:09:46 +0200

Thanx for lots of good comments, I have inlined some thoughts,
answers, and questions. The questions I have not touched is mainly
because I have no good answer.

Cheers
//Samuel

On Mon, Apr 16, 2012 at 3:08 PM, Radovan Semancik
<[email-masked]> wrote:
> Hello,
>
> After reading the SCIM core specification I have compiled a list of issues,
> some of which I see as quite severe. I was encouraged by Travis Spencer to
> share the list here. So here it goes:
>
> There is externalId attribute for user. It may seems as a single attribute
> but it is not. In fact "The Service Provider MUST always interpret the
> externalId as scoped to the Service Consumer's tenant". Which means that the
> provider needs to store one value for every client. This is an extra state
> that has nothing to do with the provider itself. It is transfer of client's
> responsibility to server. Wrong application of separation of concerns
> principle. This is not even made optional. Therefore it will complicate all
> the server deployments, regardless if it is necessary or not.

externalId is not mandatory as far as I know. Are there aspects that I
miss here?

>
> It looks like change of user's userName is not supported. This seems quite
> limiting to have two persistent identifiers for users (id and userName).
> Also, username changes are very common. If username is based on familyName
> it changes after most wedding for approximately half of the population.

Does really userName change, sure you do change name and userName is
often coupled to that but to me it seems like the username is not
changed anyway. I have one colleague that change both family name and
given name but the account did not change userName, but he got a new
account. Further, in the case of an email provider a username could be
[email-masked] but I do not think that it would change if my name
changed (same for my Facebook login).
The difference between userName and id is that username is assigned by
the service consumer (client) and the id is assigned by the service
provider (in this case externalId might be more redundant in relation
to userName).

>
> The familyName and givenName attributes have culture-neutral names. This is
> a nice take from FOAF. But the middleName is not that good. It enforces
> "american" point of view to the schema. Maybe "additionalName" would be more
> appropriate.

I do not thing that middleName/additionalName is a big deal but good
point. to be fully compliant with the global view might we also the
need to make it multiValued for situations where more then one is
common?

>
> User has displayName and also name/formatted attributes. It seems like these
> two are used for the same purpose? Or maybe it is displayName and userName?
> It looks like SCIM is following LDAP and SAP anti-patterns where users have
> just too many names to choose from. It is perhaps good for the entity that
> displays them, but terrible for the one that needs to manage that. The
> protocol should be more balanced in this aspect.

Interesting

> attribute a better place for nickName? Especially considering the fact that
> nickname is frequently formatted as a part of full name.

Good point

>
> Does profileUrl represent application profile maintained by the application
> that is being provisioned? Or some other external profile? Should be
> "profileUrl" multivalued? The specification is not clear about that.

Specification puts profileUrl under singular attributes, i.e. not
multiValued. The kind url seems complex to specify, by not specifying
we giving the client the option to select.

>
> User has title and userType in the core schema. But these seem to better fit
> into the "enterprise" extension.
>
> User has phoneNumbers, but no canonical phone number format is specified.
> This is limiting the usability of the specification especially in telco
> environment.

Really good point, any suggestions on global phone number formats?
Would E.164 be a good choice?

>
> The type meta-attribute in the multi-valued attributes is a plain string.
> This is prone to conflicts, especially in ims and similar "open" attributes.
> URL instead of plain string may be a better choice.
>
> And probably the most important one: Both groups and roles can be considered
> entitlements. The groups attribute is read-only, but it can be manipulated
> through Group Resource. Should such group also appear in entitlements user
> attribute? If it cannot than the correct name of that attribute should
> rather be "otherEntitlements" and the specification should make that clear.
> If it can then we have a redundancy: a group can be manipulated both through
> Group Resource and "entitlements" attribute. Similarly for roles. The
> specification does not specify if a role should only appear in "roles" and
> not in "entitlements" or can appear in both. The "SCIM Group Schema" also
> defines that roles may be represented as groups, which adds to the
> confusion. The ignorance of complexity of entitlement management was one of
> the time bombs in SPML. Not it is time bomb silently ticking in SCIM.
>
> members are very difficult to manage in this way. And it is typical that a
> group such as "Generic Employee" have more members than that, not even
> speaking about telcos. This is one of the common problems in LDAP and also
> in SCIM. There is also a corollary: creating a user as a member of a group
> requires two operations: add user, modify group. This complicates the
> implementation in case that the second operation fails. Should a
> provisioning system report that as a failure or success? User is created but
> not assigned to a group. Good provisioning system should handle that, but
> how many good provisioning systems are out there?

To create a user that is member of a group is a problem and it comes
down to groups being read-only. The reason for groups being read-only
is because the groups attribute may contain memberships that are
inherited and dynamic which would make it problematic to remove a
membership from a user this way. However this problem has been
discussed and e.g. Salesforce needs a group on a user when it is
created. A solution might be to remove read-only from groups and add
some language on how to handle inherited and dynamic groups.
Could you elaborate on the issue with very large groups? You can add
and remove single users with PATCH?

>
> Minor issue: Canonical types for members are capitalizes while other types
> start with lowercase letter.

Good catch, it might be a legacy from the time when the endpoints
where called User and Group and not Users and Groups.

>
> Should not authenticationSchema be outside of the SCIM core schema? Schema
> defines no transport protocol and the authentication types clearly depend on
> transport protocols. Maybe a binding specificiation is a better place for
> authenticationSchema definition?
>
> Resource schema has name attribute that obviously points to the object type.
> But it seems to be plain string. Namespace is not obvious here. If any SCIM
> extension adds a new object types (which seems likely) this may be very
> confusing. URL may be a better choice here.
>
> User has userName, displayName and name/formatted. Group has displayName.
> Resource has name as string. It is confusing. It is also quite inconsistent
> and makes if difficult to support uniform representation of "objects" in the
> underlying SCIM implementation.
>
> Resource Schema has description, but user and groups does not? Description
> may come handy in any object.
>
> Can endpoint in the Resource Schema be only relative? Or may it be absolute?
> Base URL is not a good concept, especially when it comes to different
> representations of the schema (e.g. see
> The attributes/type definition in Resource Schema does not specify whether
> the value is URL or QName or plain string. If a plain string (which seems to
> be the case by looking at the examples) how to map that string to XSD
> QNames? Are only XSD data types possible? The specification says "SHOULD
> not" not "MUST NOT", therefore an extension mechanism should be specified
> here.
>
> Strictly speaking, this one is also quite specific to XML and should not be
> in the generic core schema.
>
> used? Is it a namespace that applies to attribute type? Or to the attribute
> name? Attribute has schema and sub-attribute does not? Why? Does it inherit
> it from parent? The specification should make that clear.
>

Yes, this was a chosen limitation, is it bad? One reason for the
choice might have been that mapping to flat structures gets harder for
every layer, e.g. there is work done on both LDAP and SAML mappings.

>
> If the type is mandatory for every multi-valued attribute (is "hardcoded" in
> the core schema specification), is there any point to define it explicitly
> in all the resource schemas?

Could you be more specific around hardcoded?

>
> I have noticed meta attribute in the examples, but it looks like it is not
> defined in the specification.

Meta attribute is defined here
http://www.simplecloud.info/specs/draft-scim-core-schema-00.html#anchor2

> Is ordering of multi-value attribute values significant?

No, multivalued attributes are unordered. This has made mapping to
e.g. SAML harder.

>
> Critical problems in JSON-like representations: as there are no namespaces
> in JSON, naming conflicts can happen. If two schemas define a
> "employeeNumber" attribute while one of them defines it as string and the
> other as number, such schemas cannot be used together. Is this a known
> limitation of SCIM?

This is only a problem if both extensions has the same urn, see example below:
{
  "schemas":["urn:scim:schemas:core:1.0", ext1, ext2],
  "userName": "kalle",
  "ext1": {
    employeeNumber: "abc123"
  },
  "ext2": {
    employeeNumber: "123abc"
  }
}

> http://storm.alert.sk/blog/2012/04/13/SCIMming-the-Surface )

On Mon, Apr 16, 2012 at 3:08 PM, Radovan Semancik
<[email-masked]> wrote:
> Hello,
>
> After reading the SCIM core specification I have compiled a list of issues,
> some of which I see as quite severe. I was encouraged by Travis Spencer to
> share the list here. So here it goes:
>
> There is externalId attribute for user. It may seems as a single attribute
> but it is not. In fact "The Service Provider MUST always interpret the
> externalId as scoped to the Service Consumer's tenant". Which means that the
> provider needs to store one value for every client. This is an extra state
> that has nothing to do with the provider itself. It is transfer of client's
> responsibility to server. Wrong application of separation of concerns
> principle. This is not even made optional. Therefore it will complicate all
> the server deployments, regardless if it is necessary or not.
>
> It looks like change of user's userName is not supported. This seems quite
> limiting to have two persistent identifiers for users (id and userName).
> Also, username changes are very common. If username is based on familyName
> it changes after most wedding for approximately half of the population.
>
> The familyName and givenName attributes have culture-neutral names. This is
> a nice take from FOAF. But the middleName is not that good. It enforces
> "american" point of view to the schema. Maybe "additionalName" would be more
> appropriate.
>
> User has displayName and also name/formatted attributes. It seems like these
> two are used for the same purpose? Or maybe it is displayName and userName?
> It looks like SCIM is following LDAP and SAP anti-patterns where users have
> just too many names to choose from. It is perhaps good for the entity that
> displays them, but terrible for the one that needs to manage that. The
> protocol should be more balanced in this aspect.
>
> attribute a better place for nickName? Especially considering the fact that
> nickname is frequently formatted as a part of full name.
>
> Does profileUrl represent application profile maintained by the application
> that is being provisioned? Or some other external profile? Should be
> "profileUrl" multivalued? The specification is not clear about that.
>
> User has title and userType in the core schema. But these seem to better fit
> into the "enterprise" extension.
>
> User has phoneNumbers, but no canonical phone number format is specified.
> This is limiting the usability of the specification especially in telco
> environment.
>
> The type meta-attribute in the multi-valued attributes is a plain string.
> This is prone to conflicts, especially in ims and similar "open" attributes.
> URL instead of plain string may be a better choice.
>
> And probably the most important one: Both groups and roles can be considered
> entitlements. The groups attribute is read-only, but it can be manipulated
> through Group Resource. Should such group also appear in entitlements user
> attribute? If it cannot than the correct name of that attribute should
> rather be "otherEntitlements" and the specification should make that clear.
> If it can then we have a redundancy: a group can be manipulated both through
> Group Resource and "entitlements" attribute. Similarly for roles. The
> specification does not specify if a role should only appear in "roles" and
> not in "entitlements" or can appear in both. The "SCIM Group Schema" also
> defines that roles may be represented as groups, which adds to the
> confusion. The ignorance of complexity of entitlement management was one of
> the time bombs in SPML. Not it is time bomb silently ticking in SCIM.
>
> members are very difficult to manage in this way. And it is typical that a
> group such as "Generic Employee" have more members than that, not even
> speaking about telcos. This is one of the common problems in LDAP and also
> in SCIM. There is also a corollary: creating a user as a member of a group
> requires two operations: add user, modify group. This complicates the
> implementation in case that the second operation fails. Should a
> provisioning system report that as a failure or success? User is created but
> not assigned to a group. Good provisioning system should handle that, but
> how many good provisioning systems are out there?
>
> Minor issue: Canonical types for members are capitalizes while other types
> start with lowercase letter.
>
> Should not authenticationSchema be outside of the SCIM core schema? Schema
> defines no transport protocol and the authentication types clearly depend on
> transport protocols. Maybe a binding specificiation is a better place for
> authenticationSchema definition?
>
> Resource schema has name attribute that obviously points to the object type.
> But it seems to be plain string. Namespace is not obvious here. If any SCIM
> extension adds a new object types (which seems likely) this may be very
> confusing. URL may be a better choice here.
>
> User has userName, displayName and name/formatted. Group has displayName.
> Resource has name as string. It is confusing. It is also quite inconsistent
> and makes if difficult to support uniform representation of "objects" in the
> underlying SCIM implementation.
>
> Resource Schema has description, but user and groups does not? Description
> may come handy in any object.
>
> Can endpoint in the Resource Schema be only relative? Or may it be absolute?
> Base URL is not a good concept, especially when it comes to different
> representations of the schema (e.g. see
> The attributes/type definition in Resource Schema does not specify whether
> the value is URL or QName or plain string. If a plain string (which seems to
> be the case by looking at the examples) how to map that string to XSD
> QNames? Are only XSD data types possible? The specification says "SHOULD
> not" not "MUST NOT", therefore an extension mechanism should be specified
> here.
>
> Strictly speaking, this one is also quite specific to XML and should not be
> in the generic core schema.
>
> used? Is it a namespace that applies to attribute type? Or to the attribute
> name? Attribute has schema and sub-attribute does not? Why? Does it inherit
> it from parent? The specification should make that clear.
>
> If the type is mandatory for every multi-valued attribute (is "hardcoded" in
> the core schema specification), is there any point to define it explicitly
> in all the resource schemas?
>
> I have noticed meta attribute in the examples, but it looks like it is not
> defined in the specification.
>
> Critical problems in JSON-like representations: as there are no namespaces
> in JSON, naming conflicts can happen. If two schemas define a
> "employeeNumber" attribute while one of them defines it as string and the
> other as number, such schemas cannot be used together. Is this a known
> limitation of SCIM?
>

---

From: Radovan Semancik <[email-masked]>
Date: Tue, 17 Apr 2012 16:58:26 +0200

Hi,

> externalId is not mandatory as far as I know. Are there aspects that I

I have understood that it is mandatory. The specification says "These 
attributes MUST be included in all Resources, ...". I have noticed that 
optional attributes are explicitly marked, but the "externalId" is not 
marked in any way. Maybe this is just an unclear wording?

> account.

This usualy means that the account history and audit trails are lost. 
New account also means new persistent identifier and therefore it is 
almost impossible to track it back to the original account. I would not 
assume that "immutable usernames" is the case for all the applications. 
We have done a lot of IDM deployments in last 10 years and requirement 
to change usernames was there in a vast majority of them.

> need to make it multiValued for situations where more then one is

Multivalued name attributes are quite tricky. We have been experimenting 
with that in midPoint (IDM solution that we develop) but there are 
problems formatting multivalue attributes. Especially if they are 
unordered (which is our case, but also an LDAP case). LDAP has 
multi-valued naming attributes but I haven't seen anyone using that 
feature as it complicates things a lot (except the case of multiple uid 
values, but that is kind of special case). I don't have a definitive 
answer to that, but I would be inclined towards a single-valued 
additionalName field now.

> Would E.164 be a good choice?

Telcos that I worked for all use E.164. But I don't know how much 
"europe-centric" is that.

> and remove single users with PATCH?

The problem with a very large groups is that the list of returned 
members is huge. This is not efficient to retrieve every time. Therefore 
the only efficient way is probably to read the "groups" pseudo-attribute 
of user. However, all changes have to be made to the "members" attribute 
of the group, which is a bit confusing. It can also be a critical 
problem for applications that require at least one group to create a 
user. Such applications just cannot be provisioned with SCIM currently. 
Making "groups" (in user) read-write may really help here.

We have been solving similar problem in midPoint. Our solution (not well 
tested yet) is to allow "additional operations" to go with a create 
operation. Adding a group membership to a user can be passed together 
with "create user" operation. This "batch" can be used by server to 
"recompose" the operation to a create operation that includes a group 
membership if that is needed. And it does not affect the protocol too 
much. However, this approach is somehow incompatible with REST.

Also, if the group has many members then changes to such group will be 
frequent. Operations like PUT may not be feasible, even with optimistic 
locking (ETag). I see that the presence of PATCH operation can make this 
efficient. But does SCIM rely on the fact that every protocol will have 
this efficient way of attribute modification?

Most provisioning systems are (unfortunately) based on read-modify-write 
cycle and it may be difficult for them to implement interface that 
relies on PATCH. E.g. imagine a provisioning system that "writes" user 
with a new set of groups [A, B, C]. The SCIM connector would need to 
read current user's group (e.g. by reading "groups" from user), compare 
with the [A, B, C] and then use PATCH to align the difference by adding 
values of "members" attribute (up to) three groups and removing the 
values from the groups that user should no longer have (efficiently 
doing a "diff" operation). Don't get me wrong: I like this "delta logic" 
and I consider it the only reasonable way to go. I also don't see 
anything bad in punishing broken IDM systems by requiring additional 
logic on their side. I'm just pointing out that there may be additional 
adoption barrier when it comes to most older (and also some newer) user 
provisioning products. Maybe it is worth to think if there is a way that 
will still allows the "delta logic" as a primary mechanism but will not 
be that confusing and difficult to implement for legacy systems. E.g. 
reflecting group membership to a read-write user attribute can make 
"PUT" feasible as the conflicts on large groups will be avoided and a 
(concurrency) conflict on a single user is unlikely (and hence the 
optimistic locking may be efficient).

And most importantly: I think there should be a clear and uniform way 
how to deal with assignment of the things that user belongs to. I call 
them "entitlements" but I see that SCIM has a slightly different 
terminology and does not have a common concept that unifies SCIM groups, 
roles and other entitlements. And I think this is the missing piece that 
is one of the causes of this confusion.

> every layer, e.g. there is work done on both LDAP and SAML mappings.

I don't know if it is bad or not. I just have a feeling that the 
structure should either have 1 level or arbitrary number of levels. 
Multiplicities other than 0, 1 and "many" are usually a source of 
unexpected problems in data models (even if this is meta-model rather 
than model).

Anyway, if that limitation is done with a purpose it should be 
documented in the specification.

> Could you be more specific around hardcoded?

The "type" attribute is explicitly defined for any multi-valued 
attributes in the specification (section 3.2). Therefore it is a part of 
the meta-schema rather than schema. May there be a multi-valued 
attribute that does not have "type"? If yes then the "type" should be 
marked as optional in the specification. If not then there is no point 
of specifying "type" in every run-time schema because it just must 
always be there.

Or maybe my understanding of the distinction between the fixed 
(specification) part of the protocol and the flexible (extenstion, 
runtime) part is wrong? If that is the case then maybe the specification 
should explain that in more detail.

> http://www.simplecloud.info/specs/draft-scim-core-schema-00.html#anchor2

Oh yes. My bad. Thanks for pointing that out.

> No, multivalued attributes are unordered. This has made mapping to

That is a crucial point that should be documented in the schema. I was 
explicitly looking for that and haven't found it.

>    "schemas":["urn:scim:schemas:core:1.0", ext1, ext2],

Oh. This "encapsulating" of extensions into a specific parts of the JSON 
structure somehow eluded me. Anyway, there is still a problem with 
future schema extensions. E.g. if a future version of SCIM defines new 
user attribute "ext1" it can break valid existing "documents" and 
therefore is a risk for compatibility. Maybe it would be a good idea to 
adopt the XML "best practice" of quarantining extensibility points into 
dedicated elements? E.g. it can look like this in JSON:

{
   "extension": {
     "ext1": {
        employeeNumber: "abc123"
      },
     "ext2": {
       employeeNumber: "123abc"
     }
   }
}

-- 

                                            Radovan Semancik
                                           Software Architect
                                              evolveum.com

---

From: Michael Hammer <[email-masked]>
Date: Tue, 17 Apr 2012 15:15:40 +0000

E.164 is global.  
E.g. +1 = North American region
All global country codes are defined by it.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Radovan Semancik
Sent: Tuesday, April 17, 2012 10:58 AM
To: [email-masked]
Subject: Re: [scim] SCIM Issues

Hi,

This usualy means that the account history and audit trails are lost. 
New account also means new persistent identifier and therefore it is almost
impossible to track it back to the original account. I would not assume that
"immutable usernames" is the case for all the applications. 
We have done a lot of IDM deployments in last 10 years and requirement to
change usernames was there in a vast majority of them.

Multivalued name attributes are quite tricky. We have been experimenting
with that in midPoint (IDM solution that we develop) but there are problems
formatting multivalue attributes. Especially if they are unordered (which is
our case, but also an LDAP case). LDAP has multi-valued naming attributes
but I haven't seen anyone using that feature as it complicates things a lot
(except the case of multiple uid values, but that is kind of special case).
I don't have a definitive answer to that, but I would be inclined towards a
single-valued additionalName field now.

> and remove single users with PATCH?

The problem with a very large groups is that the list of returned members is
huge. This is not efficient to retrieve every time. Therefore the only
efficient way is probably to read the "groups" pseudo-attribute of user.
However, all changes have to be made to the "members" attribute of the
group, which is a bit confusing. It can also be a critical problem for
applications that require at least one group to create a user. Such
applications just cannot be provisioned with SCIM currently. 
Making "groups" (in user) read-write may really help here.

We have been solving similar problem in midPoint. Our solution (not well
tested yet) is to allow "additional operations" to go with a create
operation. Adding a group membership to a user can be passed together with
"create user" operation. This "batch" can be used by server to "recompose"
the operation to a create operation that includes a group membership if that
is needed. And it does not affect the protocol too much. However, this
approach is somehow incompatible with REST.

Also, if the group has many members then changes to such group will be
frequent. Operations like PUT may not be feasible, even with optimistic
locking (ETag). I see that the presence of PATCH operation can make this
efficient. But does SCIM rely on the fact that every protocol will have this
efficient way of attribute modification?

Most provisioning systems are (unfortunately) based on read-modify-write
cycle and it may be difficult for them to implement interface that relies on
PATCH. E.g. imagine a provisioning system that "writes" user with a new set
of groups [A, B, C]. The SCIM connector would need to read current user's
group (e.g. by reading "groups" from user), compare with the [A, B, C] and
then use PATCH to align the difference by adding values of "members"
attribute (up to) three groups and removing the values from the groups that
user should no longer have (efficiently doing a "diff" operation). Don't get
me wrong: I like this "delta logic" 
and I consider it the only reasonable way to go. I also don't see anything
bad in punishing broken IDM systems by requiring additional logic on their
side. I'm just pointing out that there may be additional adoption barrier
when it comes to most older (and also some newer) user provisioning
products. Maybe it is worth to think if there is a way that will still
allows the "delta logic" as a primary mechanism but will not be that
confusing and difficult to implement for legacy systems. E.g. 
reflecting group membership to a read-write user attribute can make "PUT"
feasible as the conflicts on large groups will be avoided and a
(concurrency) conflict on a single user is unlikely (and hence the
optimistic locking may be efficient).

And most importantly: I think there should be a clear and uniform way how to
deal with assignment of the things that user belongs to. I call them
"entitlements" but I see that SCIM has a slightly different terminology and
does not have a common concept that unifies SCIM groups, roles and other
entitlements. And I think this is the missing piece that is one of the
causes of this confusion.

> every layer, e.g. there is work done on both LDAP and SAML mappings.

I don't know if it is bad or not. I just have a feeling that the structure
should either have 1 level or arbitrary number of levels. 
Multiplicities other than 0, 1 and "many" are usually a source of unexpected
problems in data models (even if this is meta-model rather than model).

Anyway, if that limitation is done with a purpose it should be documented in
the specification.

> Could you be more specific around hardcoded?

The "type" attribute is explicitly defined for any multi-valued attributes
in the specification (section 3.2). Therefore it is a part of the
meta-schema rather than schema. May there be a multi-valued attribute that
does not have "type"? If yes then the "type" should be marked as optional in
the specification. If not then there is no point of specifying "type" in
every run-time schema because it just must always be there.

>> namespaces in JSON, naming conflicts can happen. If two schemas 
>> define a "employeeNumber" attribute while one of them defines it as 
>> string and the other as number, such schemas cannot be used together. 
>> Is this a known limitation of SCIM?

Oh. This "encapsulating" of extensions into a specific parts of the JSON
structure somehow eluded me. Anyway, there is still a problem with future
schema extensions. E.g. if a future version of SCIM defines new user
attribute "ext1" it can break valid existing "documents" and therefore is a
risk for compatibility. Maybe it would be a good idea to adopt the XML "best
practice" of quarantining extensibility points into dedicated elements? E.g.
it can look like this in JSON:

{

-- 

                                            Radovan Semancik
                                           Software Architect
                                              evolveum.com

---

From: Kelly Grizzle <[email-masked]>
Date: Tue, 17 Apr 2012 18:11:42 +0000

Radovan,

Thanks for all of the excellent feedback.  You have brought up some great
points!

> I have noticed that optional attributes are explicitly marked, but the
> "externalId" is not  marked in any way. Maybe this is just an unclear wording?

This is supposed to be optional.  I agree that the spec should be explicit about
this.  Regarding externalId-per-consumer, this topic came up at IIW in October.
One thought was to allow this be multi-valued and have the type specify some
sort of URN for the consumer.  The discussion ended there, though.

> change usernames was there in a vast majority of them.

I agree.  In Active Directory, it seems like samAccountName (which is mutable)
would be modeled as the SCIM userName.  I don't see any problem in dropping the
immutability requirement from the spec.

> huge. This is not efficient to retrieve every time.

This is issue 43 in the issue tracker.  Hopefully this can get fixed in SCIM
2.0.  http://code.google.com/p/scim/issues/detail?id=43

> applications just cannot be provisioned with SCIM currently.  Making
> "groups" (in user) read-write may really help here.

I believe that when we first bumped into this at IIW in October, we proposed an
extension to the User schema that allows specifying the default group upon
creation.  If this is a common case (requiring a group upon creation), it should
be considered in the core spec rather than just as a workaround.

> Adding a group membership to a user can be passed together with

SCIM has a /Bulk endpoint that can be used for batching, but the spec says that
ordering is not guaranteed.  Perhaps this could be used if the service provider
is smart enough, but it could be difficult to implement efficiently.

> I see that the presence of PATCH operation can make this

PATCH support is not required by the spec, but I would imagine that any service
provider that has large data (eg - a directory server) would strive to implement
it for their own good.  I'm not sure how this would be done in different
protocols, though.  This needs more thought for non-REST protocols.

> Maybe it is worth to think if there is a way that will still allows the "delta
> logic" as a primary mechanism but will not be that confusing and difficult to
> implement for legacy systems. E.g.  reflecting group membership to a
> read-write user attribute can make "PUT" feasible as the conflicts on large
> groups will be avoided and a (concurrency) conflict on a single user is
> unlikely (and hence the optimistic locking may be efficient).

A read-write groups attribute on the User has been discussed quite a bit.  I
agree that it is much easier to manipulate group membership via the user than
the other way around.  As Samuel pointed out, the groups attribute contains
groups that are not only directly assigned, inherited, or dynamically
calculated.  As such, it is difficult to allow modification of this attribute
since some groups (eg - dynamic) cannot be removed or added.  Various ideas were
considered to allow this (splitting dynamic and nested groups into a separate
attribute, etc...), but they all had their own complications.  Because of this
we decided to stick with the "edit membership via the group" philosophy.

> causes of this confusion.

You are right that a group can be considered an entitlement and there is some
confusion here.  Concrete examples may help.  This is how I think about the
three:

 - Entitlements: These are individual low-level access grants that are assigned
   directly to a user.  An example granting a user the "Write" right on a
   resource called DevWiki.  This might be modeled as "write:DevWiki" or
   something.

 - Roles: These describe what roles or job functions the user holds within the
   organization (eg - Developer, Sales Executive, Student, etc...).  In some
   systems, having a role might cause a user to be granted individual
   entitlements or group memberships.  These relationships are not specified in
   SCIM since roles are opaque.

 - Groups: These are groupings of users that may support nesting.  In some cases
   they are used for access control (security groups) and in other cases they
   are used for other purposes (eg - distribution groups).  Security groups may
   be able to grant entitlements to a user.

I think that there is merit in keeping these concepts separated.  I can conceive
of future extensions to expose /Entitlements and /Roles endpoints that allow
reading and updating an entitlement catalog and role model.  There has been some
confusion around these three attributes, so it is probably worth trying to clean
this up in the spec.

> Good catch, it might be a legacy from the time when the endpoints where called
> User and Group and not Users and Groups.

It is probably legacy.  There are actually currently some discussions around
this wrt allowing the group members to be dereferenced.  "User" and "Group"
match the name in the resource schema
(http://www.simplecloud.info/specs/draft-scim-core-schema-00.html#resource-schema)
and it may be worth keeping these to allow dereferencing.

> clearly depend on transport protocols. Maybe a binding specificiation 
> is a better place for authenticationSchema definition?

This is defined in the ServiceProviderConfig, which regardless of the transport
protocol should be available.  You're right that this assumes the REST
protocol.  Perhaps authenticationSchemas should have a sub-attribute that
specifies the applicable protocol?

> Resource has name as string. It is confusing. It is also quite 
> inconsistent and makes if difficult to support uniform representation 
> of "objects" in the underlying SCIM implementation.

Maybe Group could use name instead of displayName?  I kind of like displayName
because this might be different from a raw name (eg - Super Users vs. cn=Super
Users,dc=foo,...).  This doesn't seem like much of an issue to me.  Looking at
the confusion between userName, displayName, formattedName is worthwhile,
though.

> Description may come handy in any object.

I could see this for groups but haven't ever really seen this for users.

> (which seems to be the case by looking at the examples) how to map 
> that string to XSD QNames? Are only XSD data types possible? The 

Yes these are based on XSD data types and are not currently extensible.  Are
there any data types that are not currently covered by the spec?

>>> If the type is mandatory for every multi-valued attribute (is "hardcoded"
>>> in the core schema specification), is there any point to define it
>>> explicitly in all the resource schemas?

I believe that the type sub-attribute is optional.  I believe that generally in
the schema spec if an attribute doesn't say REQUIRED than it is implied to be
optional.  This should be made more explicit.

>>> Is ordering of multi-value attribute values significant?  No, multivalued
>>attributes are unordered. This has made mapping to e.g. SAML harder.
> 

I agree.

> practice" of quarantining extensibility points into dedicated elements?
> E.g. it can look like this in JSON:
> 
> {
>    } }

Extensions are actually defined with URNs (eg - urn:scim:schemas:extension:enterprise:1.0),
so it is pretty unlikely that there will be conflicts.  See an example in the
JSON representation of an enterprise user here:
http://www.simplecloud.info/specs/draft-scim-core-schema-00.html#anchor9.

> I hope that the authors of SCIM will try to correct the obvious problems of
> the specification and focus on proving that it works before going any
> further. The only reasonable way to go is: working software first, standards
> second.

Implementations have been developed in parallel with the spec, and there were 9
of them that worked (at least to some extent) together just a few weeks ago
(http://code.google.com/p/scim/wiki/FirstInteropEvent).  The authors (myself
included) have always had an eye toward making something that is practical,
useful, and actually works.  As you have found, there are definitely some holes
and warts that need to be addressed.

I really appreciate your feedback and will make sure that some of these issues
make it into the issue tracker.

--Kelly

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 Apr 2012 19:34:56 +0100

Just a question on one snippet:

> need to make it multiValued for situations where more then one is

Does this mean that scim intend to re-develop the equivalent of
inetOrgPerson?

That seems like an odd idea. Why is it necessary?

Note - I'm not saying "use ldif" here, but wondering why this
putative WG would need to go re-do all that data modelling work,
as would be implied by the quoted text above.

S

---

From: Michael Hammer <[email-masked]>
Date: Tue, 17 Apr 2012 18:50:37 +0000

Kelly,

I am not sure I like the definitions you have for role.
Another international spec I looked over recently defines role as a set of
entitlements.
That makes more sense to me.

Group=set of Users
Role=set of Entitlements

The name of the role would give one an idea what entitlements to assign that
role.
Powers get inherited down the line:

Entitlement -> Role -> Group -> User

Pointers can be set in the opposite direction of the arrows.
And of course, leaving a role or group or both out of the chain is
permitted.

Mike Sense?

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Kelly Grizzle
Sent: Tuesday, April 17, 2012 2:12 PM
To: Radovan Semancik; [email-masked]
Subject: Re: [scim] SCIM Issues

Radovan,

> "externalId" is not  marked in any way. Maybe this is just an unclear
wording?

This is supposed to be optional.  I agree that the spec should be explicit
about this.  Regarding externalId-per-consumer, this topic came up at IIW in
October.
One thought was to allow this be multi-valued and have the type specify some
sort of URN for the consumer.  The discussion ended there, though.

> to change usernames was there in a vast majority of them.

I agree.  In Active Directory, it seems like samAccountName (which is
mutable) would be modeled as the SCIM userName.  I don't see any problem in
dropping the immutability requirement from the spec.

> members is huge. This is not efficient to retrieve every time.

> "groups" (in user) read-write may really help here.

I believe that when we first bumped into this at IIW in October, we proposed
an extension to the User schema that allows specifying the default group
upon creation.  If this is a common case (requiring a group upon creation),
it should be considered in the core spec rather than just as a workaround.

> the operation to a create operation that includes a group membership 
> if that is needed. And it does not affect the protocol too much. 
> However, this approach is somehow incompatible with REST.

SCIM has a /Bulk endpoint that can be used for batching, but the spec says
that ordering is not guaranteed.  Perhaps this could be used if the service
provider is smart enough, but it could be difficult to implement
efficiently.

> I see that the presence of PATCH operation can make this efficient. 
> But does SCIM rely on the fact that every protocol will have this 

PATCH support is not required by the spec, but I would imagine that any
service provider that has large data (eg - a directory server) would strive
to implement it for their own good.  I'm not sure how this would be done in
different protocols, though.  This needs more thought for non-REST
protocols.

> Maybe it is worth to think if there is a way that will still allows 
> the "delta logic" as a primary mechanism but will not be that 

A read-write groups attribute on the User has been discussed quite a bit.  I
agree that it is much easier to manipulate group membership via the user
than the other way around.  As Samuel pointed out, the groups attribute
contains groups that are not only directly assigned, inherited, or
dynamically calculated.  As such, it is difficult to allow modification of
this attribute since some groups (eg - dynamic) cannot be removed or added.
Various ideas were considered to allow this (splitting dynamic and nested
groups into a separate attribute, etc...), but they all had their own
complications.  Because of this we decided to stick with the "edit
membership via the group" philosophy.

> terminology and does not have a common concept that unifies SCIM 
> groups, roles and other entitlements. And I think this is the missing 
> piece that is one of the causes of this confusion.

You are right that a group can be considered an entitlement and there is
some confusion here.  Concrete examples may help.  This is how I think about
the
three:

 - Entitlements: These are individual low-level access grants that are
assigned
   directly to a user.  An example granting a user the "Write" right on a
   resource called DevWiki.  This might be modeled as "write:DevWiki" or
   something.

 - Roles: These describe what roles or job functions the user holds within
the
   organization (eg - Developer, Sales Executive, Student, etc...).  In some
   systems, having a role might cause a user to be granted individual
   entitlements or group memberships.  These relationships are not specified
in
   SCIM since roles are opaque.

 - Groups: These are groupings of users that may support nesting.  In some
cases
   they are used for access control (security groups) and in other cases
they
   are used for other purposes (eg - distribution groups).  Security groups
may
   be able to grant entitlements to a user.

I think that there is merit in keeping these concepts separated.  I can
conceive of future extensions to expose /Entitlements and /Roles endpoints
that allow reading and updating an entitlement catalog and role model.
There has been some confusion around these three attributes, so it is
probably worth trying to clean this up in the spec.

(http://www.simplecloud.info/specs/draft-scim-core-schema-00.html#resource-s
chema)

> is a better place for authenticationSchema definition?

This is defined in the ServiceProviderConfig, which regardless of the
transport protocol should be available.  You're right that this assumes the
REST protocol.  Perhaps authenticationSchemas should have a sub-attribute
that specifies the applicable protocol?

> of "objects" in the underlying SCIM implementation.

Maybe Group could use name instead of displayName?  I kind of like
displayName because this might be different from a raw name (eg - Super
Users vs. cn=Super Users,dc=foo,...).  This doesn't seem like much of an
issue to me.  Looking at the confusion between userName, displayName,
formattedName is worthwhile, though.

>>> If the type is mandatory for every multi-valued attribute (is
"hardcoded"
> attributes in the specification (section 3.2). Therefore it is a part 
> of the meta-schema rather than schema. May there be a multi-valued 
> of specifying "type" in every run-time schema because it just must always
be there.

I believe that the type sub-attribute is optional.  I believe that generally
in the schema spec if an attribute doesn't say REQUIRED than it is implied
to be optional.  This should be made more explicit.

I agree.

> Oh. This "encapsulating" of extensions into a specific parts of the 
> JSON structure somehow eluded me. Anyway, there is still a problem 
> with future schema extensions. E.g. if a future version of SCIM 
> defines new user attribute "ext1" it can break valid existing 
> "documents" and therefore is a risk for compatibility. Maybe it would 
> be a good idea to adopt the XML "best practice" of quarantining
extensibility points into dedicated elements?
>    "schemas":["urn:scim:schemas:core:1.0", ext1, ext2],

Extensions are actually defined with URNs (eg -
urn:scim:schemas:extension:enterprise:1.0),
so it is pretty unlikely that there will be conflicts.  See an example in
the JSON representation of an enterprise user here:
http://www.simplecloud.info/specs/draft-scim-core-schema-00.html#anchor9.

> I hope that the authors of SCIM will try to correct the obvious 
> problems of the specification and focus on proving that it works 
> before going any further. The only reasonable way to go is: working 
> software first, standards second.

Implementations have been developed in parallel with the spec, and there
were 9 of them that worked (at least to some extent) together just a few
weeks ago (http://code.google.com/p/scim/wiki/FirstInteropEvent).  The
authors (myself
included) have always had an eye toward making something that is practical,
useful, and actually works.  As you have found, there are definitely some
holes and warts that need to be addressed.

I really appreciate your feedback and will make sure that some of these
issues make it into the issue tracker.

--Kelly

---

From: Kelly Grizzle <[email-masked]>
Date: Tue, 17 Apr 2012 21:03:04 +0000

This makes sense to me.  However, I have seen roles be used for more than this.  A common example is using roles to define separation of duty policies, such as disallowing a person from being a "Vendor Creator" and "Payment Approver".  Often these role have entitlements under them, but not always.

I have also seen roles be split into different types - business roles and IT roles.  A business role is simply something that describes who a person is within their organization.  This can be assigned directly to the user or can be dynamically assigned by some sort of a matching rule (eg - "if your title is 'Sales Level III' you get 'Sales Engineer' role).  An IT role is more like what you are describing, a group of entitlements.  These different types of roles can be related to each other through various relationships.  For example, a "Developer" business role might give default access to (or require) the "Developer Version Control" IT role and permit access to (but not require) the "Developer Data Modeling" IT role.

Also, if a role is nothing more than a set of entitlements, how is this different from a group?  Security groups are generally granted some set of entitlements and then users are added as group members to be granted those entitlements.

All of this to say that while roles are often a set of entitlements, I don't think that this is always the case.

--Kelly

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]] 
Sent: Tuesday, April 17, 2012 1:51 PM
To: Kelly Grizzle; [email-masked]; [email-masked]
Subject: RE: [scim] SCIM Issues

Kelly,

Group=set of Users
Role=set of Entitlements

Mike Sense?

Mike

-----Original Message-----

Radovan,

"hardcoded"
be there.

I agree.

--Kelly

---

From: Michael Hammer <[email-masked]>
Date: Tue, 17 Apr 2012 21:59:42 +0000

I agree with you that loosely defined usage and habit can lead to very muddy
waters.

The way I rationalized this for myself was to dig deeper.  Is someone says
that a user or group is assigned a role, what does that mean?
If my role is IT wizard, it usually means I have powers (tokens?) that allow
me to do X, Y, and Z, which are atomic or binary permissions.
I either get to do it or not.  Having both entitlements and roles allows an
M:N mapping.  
A role is a collection of powers versus having to repeat a laundry least
each time.

This allow later the subsequent ability to assign a set of permissions to a
User or Group.  (M:X, M:Y, N:X, N:Y mappings)

I saw role and group as distinct in that those sets parallel the What versus
Who of the more atomic Entitlement and User.  
Again the User and Group allow X:Y mapping so one person can belong to
different groups.
Similarly, the actions of ascertaining Identity is conducted first (who),
followed by application of access rules (what you can then do).

The alternative IMHO is that if there is no distinction, and if role,
entitlement, and group are synonyms, 
you could then eliminate one or more redundant terms without loss and have
only Users and Entitlements 
(or whichever term you select to keep).  (N:Y mappings only)

So, I guess this boils down to whether there is need to have zero, one, or
two types of sets.
If one, is that a set of entitlements (aka role) that gets assigned one by
one to each User?
      Or, is that a set of Users that gets assigned one by one to each
Entitlement?
(Note, I think you use role and group as synonymous.)

My thinking was that having more levels of indirection/aggregation would
provide more flexibility.
Wonder what others are thinking?

Mike

-----Original Message-----
From: Kelly Grizzle [mailto:[email-masked]] 
Sent: Tuesday, April 17, 2012 5:03 PM
To: Michael Hammer; [email-masked]; [email-masked]
Subject: RE: [scim] SCIM Issues

This makes sense to me.  However, I have seen roles be used for more than
this.  A common example is using roles to define separation of duty
policies, such as disallowing a person from being a "Vendor Creator" and
"Payment Approver".  Often these role have entitlements under them, but not
always.

I have also seen roles be split into different types - business roles and IT
roles.  A business role is simply something that describes who a person is
within their organization.  This can be assigned directly to the user or can
be dynamically assigned by some sort of a matching rule (eg - "if your title
is 'Sales Level III' you get 'Sales Engineer' role).  An IT role is more
like what you are describing, a group of entitlements.  These different
types of roles can be related to each other through various relationships.
For example, a "Developer" business role might give default access to (or
require) the "Developer Version Control" IT role and permit access to (but
not require) the "Developer Data Modeling" IT role.

Also, if a role is nothing more than a set of entitlements, how is this
different from a group?  Security groups are generally granted some set of
entitlements and then users are added as group members to be granted those
entitlements.

All of this to say that while roles are often a set of entitlements, I don't
think that this is always the case.

--Kelly

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Tuesday, April 17, 2012 1:51 PM
To: Kelly Grizzle; [email-masked]; [email-masked]
Subject: RE: [scim] SCIM Issues

Kelly,

Group=set of Users
Role=set of Entitlements

Mike Sense?

Mike

-----Original Message-----

Radovan,

"hardcoded"
> always
be there.

I agree.

--Kelly

---

From: Phil Hunt <[email-masked]>
Date: Tue, 17 Apr 2012 15:06:39 -0700

More flexibility in this case leads to interpretation, mapping and interop issues.

Better to define and have clear meaning so outliers can at least map to the model. 

Phil

---

From: Radovan Semancik <[email-masked]>
Date: Wed, 18 Apr 2012 11:16:05 +0200

Hi,

> and warts that need to be addressed.

The problem is that some holes cannot be uncovered by just looking at 
the spec. I have tried my best but I'm quite sure that I have missed 
some. Interop event is also not a definitive answer. I really appreciate 
that such events happen, but these are still more-or-less laboratory 
environment. And interoperability is not the only issue here. Interop 
events cannot tell if the protocol is sufficiently complete to be 
practical. If the protocol is not complete, implementers will create 
their own extensions to cover the missing parts. And such extensions are 
very likely to be incompatible. This is what happened to X.509 and also 
to HTML in the early days.

I guess that SCIM is now validated considerably better than SPML. But 
that is till not enough. The protocol should be tried in several real 
deployments before it is standardized. Reality always has a bunch of 
unexpected surprises for engineers.

-- 

                                            Radovan Semancik
                                           Software Architect
                                              evolveum.com

---

From: Radovan Semancik <[email-masked]>
Date: Wed, 18 Apr 2012 11:44:19 +0200

I have few remarks to the "roles" discussion:

If a role is a collection of entitlements, what about hierarchical roles 
(roles that container roles)? Do we need to broaden the definition to 
"collection of entitlements and roles"? Or do we just assume that a role 
is an entitlement?

But there is a more important question: are we going into too much 
detail here?

A target system ("resource" in IDM speak) may work with really rich and 
complex roles represented by intricate structure of the 
subject-action-object triples, sub-roles of various types, bound to the 
organizational structure and all that spiced up with temporal 
constraints and other decorations. But the IDM systems usually know 
nothing about this. They don't need to. They only see such role as yet 
another entitlement and assign it to the user (and actually most IDM 
systems just see it as yet another (string) value of some account 
attribute). The roles in the IDM system are much higher abstraction than 
the roles in the resource. These are actually quite a different kinds of 
animal. What I see here is a attempt to encompass both concepts into a 
single framework/definition. I don't think that is feasible right now.

Is the scope of SCIM management of 
roles/groups/whateverEntitilementThereMayBe? Or is the scope only 
assigning such things to users? If it is the latter case than maybe we 
do not need to see the difference between group, role, entitlement, 
organizational unit, team, project, privilege, etc. Just define a class 
of "assignable" entities and provide a way how to assign them to users. 
That should be enough.

-- 

                                            Radovan Semancik
                                           Software Architect
                                              evolveum.com

---

From: Trey Drake <[email-masked]>
Date: Wed, 18 Apr 2012 12:04:48 +0200

Radovan,

I'm not sure what you're looking for - SCIM, in its current form, has been presented to the IETF as a standards track specification.  The intent of doing so is to widen the audience so as to improve the specification,  formalize governance, and all the usual goodness  SDOs provide.  If the SCIM WG is approved the effort has just begun.  In the meantime, we're rev'ing the spec, holding interops and gaining operational experience.  Yes, IDM vendors and SaaS providers alike are rolling out SCIM implementations as SCIM is addressing a pain point today.   Like it or not this is common practice.  I don't see this as a negative, rather its a positive - implementors are at least attempting to build off a spec that has a chance of interop vs rolling their own.  

Thanks,
Trey

On Apr 18, 2012, at 11:16 AM, Radovan Semancik wrote:

> The problem is that some holes cannot be uncovered by just looking at the spec. I have tried my best but I'm quite sure that I have missed some. Interop event is also not a definitive answer. I really appreciate that such events happen, but these are still more-or-less laboratory environment. And interoperability is not the only issue here. Interop events cannot tell if the protocol is sufficiently complete to be practical. If the protocol is not complete, implementers will create their own extensions to cover the missing parts. And such extensions are very likely to be incompatible. This is what happened to X.509 and also to HTML in the early days.
> 
> I guess that SCIM is now validated considerably better than SPML. But that is till not enough. The protocol should be tried in several real deployments before it is standardized. Reality always has a bunch of unexpected surprises for engineers.
> 
> -- 
> 
>                                           Radovan Semancik
>                                          Software Architect
>                                             evolveum.com
>

---

From: Michael Hammer <[email-masked]>
Date: Wed, 18 Apr 2012 14:15:26 +0000

Good point.  That is the trade-off.

Mike

-----Original Message-----
From: Phil Hunt [mailto:[email-masked]] 
Sent: Tuesday, April 17, 2012 6:07 PM
To: Michael Hammer
Cc: [email-masked]; [email-masked];
[email-masked]

More flexibility in this case leads to interpretation, mapping and interop
issues.

Better to define and have clear meaning so outliers can at least map to the
model. 

Phil

On 2012-04-17, at 14:59, Michael Hammer <[email-masked]>
wrote:

> I agree with you that loosely defined usage and habit can lead to very 
> muddy waters.
> 
> The way I rationalized this for myself was to dig deeper.  Is someone 
> says that a user or group is assigned a role, what does that mean?
> If my role is IT wizard, it usually means I have powers (tokens?) that 
> allow me to do X, Y, and Z, which are atomic or binary permissions.
> I either get to do it or not.  Having both entitlements and roles 
> allows an M:N mapping.
> A role is a collection of powers versus having to repeat a laundry 
> least each time.
> 
> This allow later the subsequent ability to assign a set of permissions 
> to a User or Group.  (M:X, M:Y, N:X, N:Y mappings)
> 
> I saw role and group as distinct in that those sets parallel the What 
> versus Who of the more atomic Entitlement and User.
> Similarly, the actions of ascertaining Identity is conducted first 
> (who), followed by application of access rules (what you can then do).
> 
> entitlement, and group are synonyms, you could then eliminate one or 
> more redundant terms without loss and have only Users and Entitlements 
> So, I guess this boils down to whether there is need to have zero, 
> one, or two types of sets.
> If one, is that a set of entitlements (aka role) that gets assigned 
> one by one to each User?
> My thinking was that having more levels of indirection/aggregation 
> would provide more flexibility.
> This makes sense to me.  However, I have seen roles be used for more 
> than this.  A common example is using roles to define separation of 
> duty policies, such as disallowing a person from being a "Vendor 
> Creator" and "Payment Approver".  Often these role have entitlements 
> under them, but not always.
> 
> I have also seen roles be split into different types - business roles 
> and IT roles.  A business role is simply something that describes who 
> a person is within their organization.  This can be assigned directly 
> to the user or can be dynamically assigned by some sort of a matching 
> rule (eg - "if your title is 'Sales Level III' you get 'Sales 
> Engineer' role).  An IT role is more like what you are describing, a 
> group of entitlements.  These different types of roles can be related to
each other through various relationships.
> require) the "Developer Version Control" IT role and permit access to 
> (but not require) the "Developer Data Modeling" IT role.
> 
> Also, if a role is nothing more than a set of entitlements, how is 
> this different from a group?  Security groups are generally granted 
> some set of entitlements and then users are added as group members to 
> be granted those entitlements.
> 
> All of this to say that while roles are often a set of entitlements, I 
> don't think that this is always the case.
> 
> --Kelly
> 
> 
> Another international spec I looked over recently defines role as a 
> set of entitlements.
> The name of the role would give one an idea what entitlements to 
> assign that role.
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Kelly Grizzle
> Thanks for all of the excellent feedback.  You have brought up some 
> great points!
> 
> 
>> I have noticed that optional attributes are explicitly marked, but 
>> the "externalId" is not  marked in any way. Maybe this is just an 
>> unclear
> wording?
> 
> This is supposed to be optional.  I agree that the spec should be 
> explicit about this.  Regarding externalId-per-consumer, this topic 
> came up at IIW in October.
> One thought was to allow this be multi-valued and have the type 
> specify some sort of URN for the consumer.  The discussion ended there,
though.
> 
> 
>> We have done a lot of IDM deployments in last 10 years and 
>> requirement to change usernames was there in a vast majority of them.
> 
> mutable) would be modeled as the SCIM userName.  I don't see any 
> problem in dropping the immutability requirement from the spec.
> 
> 
> This is issue 43 in the issue tracker.  Hopefully this can get fixed 
> in SCIM 2.0.  http://code.google.com/p/scim/issues/detail?id=43
> 
> 
>> However, all changes have to be made to the "members" attribute of 
>> the group, which is a bit confusing. It can also be a critical 
>> user. Such applications just cannot be provisioned with SCIM 
>> currently.  Making "groups" (in user) read-write may really help here.
> 
> I believe that when we first bumped into this at IIW in October, we 
> proposed an extension to the User schema that allows specifying the 
> default group upon creation.  If this is a common case (requiring a 
> group upon creation), it should be considered in the core spec rather than
just as a workaround.
> SCIM has a /Bulk endpoint that can be used for batching, but the spec 
> says that ordering is not guaranteed.  Perhaps this could be used if 
> the service provider is smart enough, but it could be difficult to 
> implement efficiently.
> 
> 
> PATCH support is not required by the spec, but I would imagine that 
> any service provider that has large data (eg - a directory server) 
> would strive to implement it for their own good.  I'm not sure how 
> this would be done in different protocols, though.  This needs more 
> thought for non-REST protocols.
> 
> 
> A read-write groups attribute on the User has been discussed quite a 
> bit.  I agree that it is much easier to manipulate group membership 
> via the user than the other way around.  As Samuel pointed out, the 
> groups attribute contains groups that are not only directly assigned, 
> inherited, or dynamically calculated.  As such, it is difficult to 
> allow modification of this attribute since some groups (eg - dynamic)
cannot be removed or added.
> Various ideas were considered to allow this (splitting dynamic and 
> nested groups into a separate attribute, etc...), but they all had 
> their own complications.  Because of this we decided to stick with the 
> "edit membership via the group" philosophy.
> 
> 
>> how to deal with assignment of the things that user belongs to. I 
>> call them "entitlements" but I see that SCIM has a slightly different 
> You are right that a group can be considered an entitlement and there 
> is some confusion here.  Concrete examples may help.  This is how I 
> think about the
> three:
> 
> I think that there is merit in keeping these concepts separated.  I 
> can conceive of future extensions to expose /Entitlements and /Roles 
> endpoints that allow reading and updating an entitlement catalog and role
model.
> It is probably legacy.  There are actually currently some discussions 
> around this wrt allowing the group members to be dereferenced.  "User" and
"Group"
> transport protocol should be available.  You're right that this 
> assumes the REST protocol.  Perhaps authenticationSchemas should have 
> a sub-attribute that specifies the applicable protocol?
> 
> 
> displayName because this might be different from a raw name (eg - 
> Super Users vs. cn=Super Users,dc=foo,...).  This doesn't seem like 
> much of an issue to me.  Looking at the confusion between userName, 
> displayName, formattedName is worthwhile, though.
> 
> 
>> specification says "SHOULD not" not "MUST NOT", therefore an 
>> extension mechanism should be specified here.
> 
> Yes these are based on XSD data types and are not currently 
> extensible.  Are there any data types that are not currently covered by
the spec?
>> marked as optional in the specification. If not then there is no 
>> point of specifying "type" in every run-time schema because it just 
>> must always
> be there.
> 
> I believe that the type sub-attribute is optional.  I believe that 
> generally in the schema spec if an attribute doesn't say REQUIRED than 
> it is implied to be optional.  This should be made more explicit.
> 
> 
>> That is a crucial point that should be documented in the schema. I 
>> was explicitly looking for that and haven't found it.
> 
> I agree.
> 
> 
> so it is pretty unlikely that there will be conflicts.  See an example 
> in the JSON representation of an enterprise user here:
> Implementations have been developed in parallel with the spec, and 
> there were 9 of them that worked (at least to some extent) together 
> just a few weeks ago 
> included) have always had an eye toward making something that is 
> practical, useful, and actually works.  As you have found, there are 
> definitely some holes and warts that need to be addressed.
> 
> I really appreciate your feedback and will make sure that some of 
> these issues make it into the issue tracker.
> 
> --Kelly
>

---

From: Michael Hammer <[email-masked]>
Date: Wed, 18 Apr 2012 14:36:55 +0000

Radovan,

Probably.

I think you can simplify it, but need to keep a distinction between the
subject and the adjectives here.
So, you could lump the roles/entitlements (privileges to be assigned) in one
bin, leaving the atomic/aggregate question aside.
And the User/Group (what privileges are assigned to) in another bin, also
leaving that atomic/aggregate question aside.
Pick the key terms (e.g. User and Role) to label the bins, and let the
explanation hand-wave over the complications.
:)

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Radovan Semancik
Sent: Wednesday, April 18, 2012 5:44 AM
Cc: [email-masked]
Subject: Re: [scim] SCIM Issues

If a role is a collection of entitlements, what about hierarchical roles
(roles that container roles)? Do we need to broaden the definition to
"collection of entitlements and roles"? Or do we just assume that a role is
an entitlement?

But there is a more important question: are we going into too much detail
here?

A target system ("resource" in IDM speak) may work with really rich and
complex roles represented by intricate structure of the
subject-action-object triples, sub-roles of various types, bound to the
organizational structure and all that spiced up with temporal constraints
and other decorations. But the IDM systems usually know nothing about this.
They don't need to. They only see such role as yet another entitlement and
assign it to the user (and actually most IDM systems just see it as yet
another (string) value of some account attribute). The roles in the IDM
system are much higher abstraction than the roles in the resource. These are
actually quite a different kinds of animal. What I see here is a attempt to
encompass both concepts into a single framework/definition. I don't think
that is feasible right now.

Is the scope of SCIM management of
roles/groups/whateverEntitilementThereMayBe? Or is the scope only assigning
such things to users? If it is the latter case than maybe we do not need to
see the difference between group, role, entitlement, organizational unit,
team, project, privilege, etc. Just define a class of "assignable" entities
and provide a way how to assign them to users. 
That should be enough.

-- 

                                            Radovan Semancik
                                           Software Architect
                                              evolveum.com

>
> I have also seen roles be split into different types - business roles and
IT roles.  A business role is simply something that describes who a person
is within their organization.  This can be assigned directly to the user or
can be dynamically assigned by some sort of a matching rule (eg - "if your
title is 'Sales Level III' you get 'Sales Engineer' role).  An IT role is
more like what you are describing, a group of entitlements.  These different
types of roles can be related to each other through various relationships.
For example, a "Developer" business role might give default access to (or
require) the "Developer Version Control" IT role and permit access to (but
not require) the "Developer Data Modeling" IT role.

---

From: Igor Faynberg <[email-masked]>
Date: Wed, 18 Apr 2012 12:29:13 -0400

And this is also how many successful technologies that were eventually 
standardised by the IETF had been developed!  In fact, the real sign of 
a good technology is that people embrace it and contribute toward 
developing it without waiting for Godot (or for any formal SDO action).

To this end, running code is the best possible proof of technology, and 
it is also the kernel around which consensus is building.

Yet I do hope that soon we will have a group, and the structure Trey 
mentions will be in place.  Still, even then I expect people to keep 
implementing from Internet Drafts (this happened with SIP, MPLS, and 
OAuth, just to give a few examples.

Igor

---

From: Chris Phillips <[email-masked]>
Date: Wed, 18 Apr 2012 14:23:14 -0400

Some comments about SCIM spec scope:

>From my perspective, SCIM is reasonably agnostic to any privilege and
access management model and is a reliable and consistent transport for
information about a persona and related control infrastructure elements
for CRUD/batch activity.

SCIM's core 1.0 schema has taken a stab at how to contain the persona
information with care toward maintaining untainted/untransformed
attributes to minimize data massaging at the end points.

To this end, there are no conditions to use a certain privilege or access
management model to use SCIM. The most popular models (group based, RBAC,
x.509, and entitlement based) are capable of being contained in SCIM 1.0
schema and are free to co-habitate, even conflict or duplicate each other
in various ways, or be absent. The strength of being able to contain most
any model outweighs enforcing certain behaviours which would sideline
people or services who don't subscribe to the philosophy, whatever it may
be.  

This Lego like building block approach keeps SCIM 'simple' but not
simplistic.

I think the more rigidity that is folded into SCIM needs to be done with
care and an eye to how much utility that a system based on 'just enough'
has.  This does not eliminate the need for capturing best practices around
unique id management or  other key areas of identity provisioning and how
it lives in the larger ecosystem though.

That said, schema should have a way to be kept current and somehow reflect
the spirit in which SCIM has evolved so far.  I am interested in the IETF
community's thoughts around governance strategies that would be available
in this area and how it would be shepherded forward in the IETF as a
starter topic. 

Chris.

---

From: Kelly Grizzle <[email-masked]>
Date: Wed, 18 Apr 2012 21:15:28 +0000

I agree with Chris that the agnostic privilege management nature of SCIM is a good thing.  Entitlements, roles, groups, and their relationships with each other can get complex quickly.  As Radovan pointed out, trying to model exactly what these mean is different than just being able to assign and deassign them on a user.  I could eventually see /Roles and /Entitlements endpoints as extensions.  Minimally they could just contain descriptions and allow listing all of the possible values.  On the other end of spectrum, they could have a full model that describes in detail what they mean and how they relate to each other.  I don't think we should go there without a lot of thought.

Having had this discussion, it seems like we should review the language in the schema spec to make sure that the descriptions of these attributes make sense or if we should tighten them up a bit.  Radovan's initial comment that "group membership is also an entitlement" is valid, and should probably be clarified in the spec.  Phil also makes a good point that "flexibility leads to interpretation, mapping, and interop issues".  The descriptions of these attributes should be clear enough in the spec that service providers and clients have a clear understanding of how these concepts map into their worlds.

--Kelly

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Chris Phillips
Sent: Wednesday, April 18, 2012 1:23 PM
To: [email-masked]
Subject: Re: [scim] SCIM Issues

Some comments about SCIM spec scope:

>From my perspective, SCIM is reasonably agnostic to any privilege and access management model and is a reliable and consistent transport for information about a persona and related control infrastructure elements for CRUD/batch activity.

SCIM's core 1.0 schema has taken a stab at how to contain the persona information with care toward maintaining untainted/untransformed attributes to minimize data massaging at the end points.

To this end, there are no conditions to use a certain privilege or access management model to use SCIM. The most popular models (group based, RBAC, x.509, and entitlement based) are capable of being contained in SCIM 1.0 schema and are free to co-habitate, even conflict or duplicate each other in various ways, or be absent. The strength of being able to contain most any model outweighs enforcing certain behaviours which would sideline people or services who don't subscribe to the philosophy, whatever it may be.  

This Lego like building block approach keeps SCIM 'simple' but not simplistic.

I think the more rigidity that is folded into SCIM needs to be done with care and an eye to how much utility that a system based on 'just enough'
has.  This does not eliminate the need for capturing best practices around unique id management or  other key areas of identity provisioning and how it lives in the larger ecosystem though.

That said, schema should have a way to be kept current and somehow reflect the spirit in which SCIM has evolved so far.  I am interested in the IETF community's thoughts around governance strategies that would be available in this area and how it would be shepherded forward in the IETF as a starter topic. 

Chris.

---

From: Michael Hammer <[email-masked]>
Date: Thu, 19 Apr 2012 00:05:17 +0000

Hmmm....

A corporation is a group.  Can you assign entitlements to that?
A user is a group with membership of one.
For example rights to vote in SDOs, independent of what individual?
Put another way, can an entitlement be an attribute to another entitlement,
with zero subjects to attach it to?
Seems like all adjectives and no nouns here.
That is my last comment.
Enjoy.  :)

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Kelly Grizzle
Sent: Wednesday, April 18, 2012 5:15 PM
To: Chris Phillips; [email-masked]
Subject: Re: [scim] SCIM Issues

I agree with Chris that the agnostic privilege management nature of SCIM is
a good thing.  Entitlements, roles, groups, and their relationships with
each other can get complex quickly.  As Radovan pointed out, trying to model
exactly what these mean is different than just being able to assign and
deassign them on a user.  I could eventually see /Roles and /Entitlements
endpoints as extensions.  Minimally they could just contain descriptions and
allow listing all of the possible values.  On the other end of spectrum,
they could have a full model that describes in detail what they mean and how
they relate to each other.  I don't think we should go there without a lot
of thought.

Having had this discussion, it seems like we should review the language in
the schema spec to make sure that the descriptions of these attributes make
sense or if we should tighten them up a bit.  Radovan's initial comment that
"group membership is also an entitlement" is valid, and should probably be
clarified in the spec.  Phil also makes a good point that "flexibility leads
to interpretation, mapping, and interop issues".  The descriptions of these
attributes should be clear enough in the spec that service providers and
clients have a clear understanding of how these concepts map into their
worlds.

--Kelly

-----Original Message-----

Some comments about SCIM spec scope:

>From my perspective, SCIM is reasonably agnostic to any privilege and access
management model and is a reliable and consistent transport for information
about a persona and related control infrastructure elements for CRUD/batch
activity.

SCIM's core 1.0 schema has taken a stab at how to contain the persona
information with care toward maintaining untainted/untransformed attributes
to minimize data massaging at the end points.

To this end, there are no conditions to use a certain privilege or access
management model to use SCIM. The most popular models (group based, RBAC,
x.509, and entitlement based) are capable of being contained in SCIM 1.0
schema and are free to co-habitate, even conflict or duplicate each other in
various ways, or be absent. The strength of being able to contain most any
model outweighs enforcing certain behaviours which would sideline people or
services who don't subscribe to the philosophy, whatever it may be.  

I think the more rigidity that is folded into SCIM needs to be done with
care and an eye to how much utility that a system based on 'just enough'
has.  This does not eliminate the need for capturing best practices around
unique id management or  other key areas of identity provisioning and how it
lives in the larger ecosystem though.

That said, schema should have a way to be kept current and somehow reflect
the spirit in which SCIM has evolved so far.  I am interested in the IETF
community's thoughts around governance strategies that would be available in
this area and how it would be shepherded forward in the IETF as a starter
topic. 

Chris.

---

From: Melinda Shore <[email-masked]>
Date: Wed, 18 Apr 2012 20:28:01 -0800

> Seems like all adjectives and no nouns here.

I see your point but I don't think it's necessary for it
to be the case.  Corporations and individuals are both entities.

Melinda

---

From: Michael Hammer <[email-masked]>
Date: Thu, 19 Apr 2012 13:13:11 +0000

In any case, let us move on and see how it goes.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Melinda Shore
Sent: Thursday, April 19, 2012 12:28 AM
To: [email-masked]
Subject: Re: [scim] SCIM Issues

> Seems like all adjectives and no nouns here.

I see your point but I don't think it's necessary for it to be the case.
Corporations and individuals are both entities.

Melinda

---

From: Samuel Erdtman <[email-masked]>
Date: Tue, 24 Apr 2012 12:38:08 +0200

When reading through this conversation one more time I see that the
following things has not yet been addressed. If I missed something
that has not been addressed please complement.

> Resource schema has name attribute that obviously points to the object type. But it seems to be plain string. Namespace is not obvious here. If any SCIM extension adds a new object types (which seems likely) this may be very confusing. URL may be a better choice here

Could you give some more details and may be an example?

> The multiValuedAttributeChildName attribute and associated way how to represent data in XML seems to add to the redundancy of the data format. Strictly speaking, this one is also quite specific to XML and should not be in the generic core schema.

I might not be perfect but it works, and I cannot se what other
document to put it into? any suggestions?

> When defining an attribute in a resource schema, how is attribute schema used? Is it a namespace that applies to attribute type? Or to the attribute name? Attribute has schema and sub-attribute does not? Why? Does it inherit it from parent? The specification should make that clear.

Could you give some more details and may be an example?

> Does this mean that scim intend to re-develop the equivalent of inetOrgPerson?

I´m not sure. Some one with more insight into the directory area might
be able to answer this question, e.g. Kelly, Trey or Morteza.

Cheers
//Samuel

---

From: Radovan Semancik <[email-masked]>
Date: Tue, 24 Apr 2012 14:41:41 +0200

> Could you give some more details and may be an example?

Resource schema has "name" attribute defined as:
'The Resource name. When applicable Service Providers MUST specify the 
name specified in the core schema specification; e.g., "User" or "Group".'

I guess that this is supposed to also contain user-defined types, not 
just the standard "User" and "Group" of SCIM core schema. So let's 
assume that I define a resource with name "Role" and create a custom 
resource schema for that. My concern was that this "Role" may be in 
conflict with future SCIM versions that could also define its own role. 
But now as I see that maybe the "schema" attribute was meant to define 
the namespace for the resource. I haven't realized that before and if 
that is really the case it should be clearly stated in the specification 
(and it also partially answers the other question regarding "schema" 
attribute below).

Anyway, there is still one issue. If I define my own "Role" in 
http://midpoint.evolveum.com/xml/ns/.... namespace and SCIM 1.1 defines 
"Role" in urn:scim:schemas:core:1.1 namespace, how could they be used 
together? Adding new standard object type is supposed to be a compatible 
change as far as I understand the principles. But only one of the Role 
types can have the "Role" name in the resource schema, is that correct? 
Even though the namespaces are different, only one of them can be used. 
This may prohibit existing deployments to use the new standard role 
mechanism while also keeping its own mechanism (maybe just for a 
migration period).

Also there is one more thing to consider: Should be SCIM 1.1 
backwards-compatible with SCIM 1.0? If that is the case, then maybe it 
is not a good idea to change the "urn:scim:schemas:core:1.0" to 
"urn:scim:schemas:core:1.1" for SCIM 1.1, as that would surely break 
existing implementations. If that is the case, then maybe 
"urn:scim:schemas:core:1" is sufficient as a namespace URI? It would 
also be less confusing if SCIM 1.1 uses the "urn:scim:schemas:core:1" 
namespace instead of "urn:scim:schemas:core:1.0".

> document to put it into? any suggestions?

We have used similar mechanism in midPoint. Instead of using this:

<User>
   ...
<userName>....</userName>
   ...
<emails>
<email>.....</email>
<email>.....</email>
</emails>
   ..
</User>

we use this:

<User>
   ...
<userName>....</userName>
   ...
<email>...</email>
<email>...</email>
   ...
</User>

Less elements means less overhead, we do not need to bother with the 
<emails> vs <email> problem and there is less redundancy in the data 
format. And both formats can be conveniently expressed in XSD and both 
are well supported by JAXB and similar technologies. It is also much 
cleaner in the XSD schema as both single and mutli attributes are 
represented in the same way differentiated only by maxOccurs XSD attribute.

> Could you give some more details and may be an example?

If the schema is represented like this:

{
   "id":"urn:scim:schemas:core:1.0:User",
   "name":"User",
   "description":"Core User",
   "schema":"urn:scim:schemas:core:1.0",
   "endpoint":"/Users",
   "attributes":[
     {
       "name":"id",
       "type":"string",
       "multiValued":false,
       "description":"Unique identifier for the SCIM resource as defined by the Service Provider. Each representation of the resource MUST include a non-empty id value. This identifier MUST be unique across the Service Provider's entire set of resources. It MUST be a stable, non-reassignable identifier that does not change when the same resource is returned in subsequent requests. The value of the id attribute is always issued by the Service Provider and MUST never be specified by the Service Consumer. REQUIRED.",
       "schema":"urn:scim:schemas:core:1.0",
       "readOnly":true,
       "required":true,
       "caseExact":false
     },
     ....

Does it mean that the name "id" should be considered as part of the 
"urn:scim:schemas:core:1.0" schema/namespace? Or is it the type "string" 
to be considered as part of "urn:scim:schemas:core:1.0" 
schema/namespace? Or both of them?

And further below in the schema definition:

     ....
     {
       "name":"name",
       "type":"complex",
       "multiValued":false,
       "description":"The components of the user's real name. Providers MAY return just the full name as a single string in the formatted sub-attribute, or they MAY return just the individual component attributes using the other sub-attributes, or they MAY return both. If both variants are returned, they SHOULD be describing the same name, with the formatted name indicating how the component attributes should be combined.",
       "schema":"urn:scim:schemas:core:1.0",
       "readOnly":false,
       "required":false,
       "caseExact":false,
       "subAttributes":[
         {
           "name":"formatted",
           "type":"string",
           "multiValued":false,
           "description":"The full name, including all middle names, titles, and suffixes as appropriate, formatted for display (e.g. Ms. Barbara J Jensen, III.)." ,
           "readOnly":false,
           "required":false,
           "caseExact":false
         },
     ....

The attribute "name" has a "schema" URI. But the sub-attribute 
"formatted" does not. Is it assumed that the sub-attribute inherits the 
schema specification from the attribute? I would guess so. But I haven't 
seen that mentioned in the specification.

But, wouldn't it be better if attribute and sub-attribute use the same 
structure to define them? E.g. if they both have "schema" specification, 
maybe as an optional part. In that way they can be represented by the 
same data structures during implemenations and processed by the same 
code. It may also allow specification of sub-attributes of 
sub-attributes which can easily resolve the (unnecessary) limitation of 
the current model.

> be able to answer this question, e.g. Kelly, Trey or Morteza.

I would guess that the answer is both yes and no. SCIM schema defines 
something that is "almost, but not quite, entirely unlike 
inetOrgPerson". It is a schema that is supposed to be used to represent 
users/accounts in which it is similar to inetOrgPerson. But (at least 
from my point of view) it resolves some of the problems of inetOrgPerson 
such as multi-valued attributes ("uid", "cn", ...) that are almost never 
used as multivalued but their multivalueness complicates all 
implementations that take the specification seriously. It may also 
resolve the issues with LDAP groups and entitlements (e.g. groupOfNames 
vs groupOfUniqueNames vs dynamic groups vs (proprietary) roles). While 
inetOrgPerson is closely related to the storage of data in directories, 
SCIM should focus on external representation of that data. SCIM is also 
on a good way to provide Internet-compatible extensibility based on URIs 
rather than OIDs (which only a small part of engineers that ever used 
LDAP knows that it exists and even fewer applications really use it).

I guess that SCIM schema might be something like inetOrgPerson NG - but 
only if the serious issues of the SCIM schema are resolved.

-- 

                                            Radovan Semancik
                                           Software Architect
                                              evolveum.com

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 24 Apr 2012 16:12:30 +0100

>>> Does this mean that scim intend to re-develop the equivalent of

That was my question I think, thanks for the answer.

>> be able to answer this question, e.g. Kelly, Trey or Morteza.

So the other part of my question was: why do we *need*
to do that re-definition? What would not work if we just
used inetOrgPerson (or some other existing equivalent).
Doing the work for fun doesn't see appealing.

> inetOrgPerson". 

Not quite a compelling answer to "why" so far - but I'm sure
it wasn't mean to be:-)

> It is a schema that is supposed to be used to represent

You'd have to wonder though if it also introduces new equally
problematic things. I don't know that it does, but I'd bet a
beer that it will.

> implementations that take the specification seriously. 

One could profile that, e.g. say that when uid is used for SCIM
it MUST NOT have >1 value (or whatever).

> It may also
> vs groupOfUniqueNames vs dynamic groups vs (proprietary) roles). 

I don't know that issue. Can you elaborate a bit?

> While
> SCIM should focus on external representation of that data. 

Hmmm. LDIF exists too. But regardless of the concrete encoding,
inetOrgPerson could be mapped to JSON or whatever is flavour of
the month right now.

> SCIM is also

What'd be wrong with RFC 3061 there? (For "standard" types that is.)
The IETF can and do allocate OIDs for various things and making those
look like a URI is easy.

> only if the serious issues of the SCIM schema are resolved.

Right. That's the main concern - if the SCIM schema is currently
not-baked then maybe an existing one with known problems is better,
and maybe quicker as well and much more likely to map to directories
without problems.

Cheers,
S.

PS: Note, I'm not actually saying SCIM should use inetOrgPerson
or other LDAP classes, I'm trying to understand if or why it cannot.

---

From: Michael Hammer <[email-masked]>
Date: Tue, 24 Apr 2012 16:55:30 +0000

"name":"formatted",
           "type":"string",
           "multiValued":false,
           "description":"The full name, including all middle names, titles,
and suffixes as appropriate, formatted for display (e.g. Ms. Barbara J
Jensen, III.)." ,

This looks more like a definition of a "display name"

ISTM that name is a composite of an ordered series of atomic attributes. 
Each atomic attribute could contain a sub-attribute binary flag that says
whether to display or not.
One could also include a sub-attribute that indicates the order preference
for display as well.

I am not sure why a given datum needs to be included twice.
Is there a reason for being more complicated than that?

Some of the discussion regarding mutability seems to be around the notion of
what is the true key to storing and retrieval of records.
Is this then some effort to achieve 3rd normal form or something similar?

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Radovan Semancik
Sent: Tuesday, April 24, 2012 5:42 AM
To: [email-masked]
Subject: Re: [scim] SCIM Issues

> type. But it seems to be plain string. Namespace is not obvious here. If
any SCIM extension adds a new object types (which seems likely) this may be
very confusing. URL may be a better choice here Could you give some more
details and may be an example?

Resource schema has "name" attribute defined as:
'The Resource name. When applicable Service Providers MUST specify the name
specified in the core schema specification; e.g., "User" or "Group".'

I guess that this is supposed to also contain user-defined types, not just
the standard "User" and "Group" of SCIM core schema. So let's assume that I
define a resource with name "Role" and create a custom resource schema for
that. My concern was that this "Role" may be in conflict with future SCIM
versions that could also define its own role. 
But now as I see that maybe the "schema" attribute was meant to define the
namespace for the resource. I haven't realized that before and if that is
really the case it should be clearly stated in the specification (and it
also partially answers the other question regarding "schema" 
attribute below).

Anyway, there is still one issue. If I define my own "Role" in
http://midpoint.evolveum.com/xml/ns/.... namespace and SCIM 1.1 defines
"Role" in urn:scim:schemas:core:1.1 namespace, how could they be used
together? Adding new standard object type is supposed to be a compatible
change as far as I understand the principles. But only one of the Role types
can have the "Role" name in the resource schema, is that correct? 
Even though the namespaces are different, only one of them can be used. 
This may prohibit existing deployments to use the new standard role
mechanism while also keeping its own mechanism (maybe just for a migration
period).

Also there is one more thing to consider: Should be SCIM 1.1
backwards-compatible with SCIM 1.0? If that is the case, then maybe it is
not a good idea to change the "urn:scim:schemas:core:1.0" to
"urn:scim:schemas:core:1.1" for SCIM 1.1, as that would surely break
existing implementations. If that is the case, then maybe
"urn:scim:schemas:core:1" is sufficient as a namespace URI? It would also be
less confusing if SCIM 1.1 uses the "urn:scim:schemas:core:1" 
namespace instead of "urn:scim:schemas:core:1.0".

<User>
   ...

we use this:

<User>
   ...

Less elements means less overhead, we do not need to bother with the
<emails> vs <email> problem and there is less redundancy in the data format.
And both formats can be conveniently expressed in XSD and both are well
supported by JAXB and similar technologies. It is also much cleaner in the
XSD schema as both single and mutli attributes are represented in the same
way differentiated only by maxOccurs XSD attribute.

{
   "id":"urn:scim:schemas:core:1.0:User",
   "name":"User",
   "description":"Core User",
   "schema":"urn:scim:schemas:core:1.0",
   "endpoint":"/Users",
   "attributes":[
     {
       "name":"id",
       "type":"string",
       "multiValued":false,
       "description":"Unique identifier for the SCIM resource as defined by
the Service Provider. Each representation of the resource MUST include a
non-empty id value. This identifier MUST be unique across the Service
Provider's entire set of resources. It MUST be a stable, non-reassignable
identifier that does not change when the same resource is returned in
subsequent requests. The value of the id attribute is always issued by the
Service Provider and MUST never be specified by the Service Consumer.
REQUIRED.",
       "schema":"urn:scim:schemas:core:1.0",
       "readOnly":true,
       "required":true,
       "caseExact":false
     },
     ....

     ....
     {
       "name":"name",
       "type":"complex",
       "multiValued":false,
       "description":"The components of the user's real name. Providers MAY
return just the full name as a single string in the formatted sub-attribute,
or they MAY return just the individual component attributes using the other
sub-attributes, or they MAY return both. If both variants are returned, they
SHOULD be describing the same name, with the formatted name indicating how
the component attributes should be combined.",
       "schema":"urn:scim:schemas:core:1.0",
       "readOnly":false,
       "required":false,
       "caseExact":false,
       "subAttributes":[
         {
           "name":"formatted",
           "type":"string",
           "multiValued":false,
           "description":"The full name, including all middle names, titles,
and suffixes as appropriate, formatted for display (e.g. Ms. Barbara J
Jensen, III.)." ,
           "readOnly":false,
           "required":false,
           "caseExact":false
         },
     ....

The attribute "name" has a "schema" URI. But the sub-attribute "formatted"
does not. Is it assumed that the sub-attribute inherits the schema
specification from the attribute? I would guess so. But I haven't seen that
mentioned in the specification.

But, wouldn't it be better if attribute and sub-attribute use the same
structure to define them? E.g. if they both have "schema" specification,
maybe as an optional part. In that way they can be represented by the same
data structures during implemenations and processed by the same code. It may
also allow specification of sub-attributes of sub-attributes which can
easily resolve the (unnecessary) limitation of the current model.

inetOrgPerson?

I would guess that the answer is both yes and no. SCIM schema defines
something that is "almost, but not quite, entirely unlike inetOrgPerson". It
is a schema that is supposed to be used to represent users/accounts in which
it is similar to inetOrgPerson. But (at least from my point of view) it
resolves some of the problems of inetOrgPerson such as multi-valued
attributes ("uid", "cn", ...) that are almost never used as multivalued but
their multivalueness complicates all implementations that take the
specification seriously. It may also resolve the issues with LDAP groups and
entitlements (e.g. groupOfNames vs groupOfUniqueNames vs dynamic groups vs
(proprietary) roles). While inetOrgPerson is closely related to the storage
of data in directories, SCIM should focus on external representation of that
data. SCIM is also on a good way to provide Internet-compatible
extensibility based on URIs rather than OIDs (which only a small part of
engineers that ever used LDAP knows that it exists and even fewer
applications really use it).

I guess that SCIM schema might be something like inetOrgPerson NG - but only
if the serious issues of the SCIM schema are resolved.

-- 

                                            Radovan Semancik
                                           Software Architect
                                              evolveum.com

---

From: Radovan Semancik <[email-masked]>
Date: Tue, 24 Apr 2012 21:15:31 +0200

> Doing the work for fun doesn't see appealing.

I'm not sure why authors of SCIM chosen not to use inetOrgPerson. Maybe 
the motivation was similar to that of FOAF. Yet, as you have pointed 
out, new specifications bring new problems (including FOAF), especially 
if they are not tested in practice before they are standardized. Which 
is still the point that I consider to be the most serious issue with 
respect to SCIM standardization. But let's put that aside for now. Here 
is my personal list why not inetOrgPerson:

uid, cn and others are multivalued. This is complicating the 
implementations. Yes, it can be "profiled" to singlevalued, but that 
will actually not be inetOrgPerson any more. The "formal" compatibility 
will be gone. SCIM implementation will still needs to deal with the 
eventuality that these attributes will be multivalued on the LDAP side. 
So there will be actually quite little benefit. And after all it is not 
difficult to implement attribute name mapping. The difficult thing is 
attribute value mapping, which cannot be avoided here. Also, did you 
know that "cn" an "commonName" is actually the same attribute? I guess 
that it is something from the X.500 legacy and is not really the best 
part of LDAP schema specs. We can profile that as well, ruling out 
"commonName" and similar long attribute names. But real good 
SCIM-to-LDAP implementation must be aware of that anyway. So the mapping 
will not be considerably simpler.

There is cn and displayName. The displayName is there for the purpose 
that cn is multivalued and it is difficult to display. We do not want a 
separate attribute just to fix ages old problem. We can again profile 
this. But ... well, see above.

Address is scattered across street, l, postOfficeBox, postalCode, and 
other attributes. Yes, there is a postalAddress attribute, but it 
actually duplicates the information. Even that can be profiled ... but ...

There is telephoneNumber, mobile (a.k.a mobileTelephoneNumber) and 
homePhone (all of them multi-valued). No way to specify work phone or 
mark which of the phone numbers is "primary" (except for copying that 
value to telephoneNumber). For email there is just one attribute (also 
multi-valued) and also no way how to mark primary address.

There are at least two frequently used an incompatible grouping 
mechanisms in LDAP: groupOfNames and groupOfUniqueNames. Some 
applications works with the former, some with the later. Which one to 
choose? We don't want both of them. But whatever we choose, the 
SCIM-to-LDAP code will most likely still need to support both. Both 
groupOfNames and groupOfUniqueNames contain a list of members as DNs. We 
don't want to use DNs in SCIM, so this needs to be mapped to other 
identifiers anyway (more mapping code). As listing the members of large 
groups is inefficient and cumbersome to manage, most vendors of good 
directory servers provide their own grouping mechanisms (dynamic groups, 
roles). Which means even more mapping code in the usual case.

OIDs: People that use LDAP daily and have never needed to create their 
own schema usually don't know what OIDs are good for, some of them 
probably don't know that OIDs even exist. Vast majority of LDAP code 
does not work with OIDs but with attribute and object class names. If 
SCIM would chose inetOrgPerson and still wants to maintain good 
extensibility, it MUST NOT use attribute names. It should use OIDs. 
Attribute names may collide. It is not a problem in LDAP, as LDAP is 
usually deployed in closed environment and not exposed to the Internet. 
Collisions are easy to handle in closed environments. The inetOrgPerson 
schema is also not really evolving, so the probability of collision with 
future version of inetOrgPerson is close to zero. But SCIM schema must 
be able to evolve. So OIDs are probably the only 
inetOrgPerson-compatible choice here. And I can't believe that something 
like the following example would ever be widely adopted (although I can 
see a lot of benefits going this way, we don't want SCIM to end up as 
SPML and DSML, do we?):

{
   "urn:oid:0.9.2342.19200300.100.1.1": "jack",
   "urn:oid:2.5.4.3": "cpt. Jack Sparrow",
   ....
}

If this would be what we want then the best choice would probably be to 
stay with ASN.1. It has a solid schema language and it is one the most 
efficient data representation languages that we know. Formats based on 
ASN.1 are also well extensible. And that means that we do not really 
need another provisioning language at all! We can reuse LDAP. But ASN.1 
is quite difficult to work with. The scripting folk would hate it. 
Dealing with all the problems of JSON and XML is probably the lesser 
evil here. But what would that mean is actually re-creating ASN.1/LDAP 
in JSON and XML. I don't think we want that. DSML was something like 
that and it was not a huge success. And actually, it is probably not 
correct to fix protocol to just one URI scheme. Therefore SCIM should 
allow also other URIs for attribute names. In which case the 
SCIM-to-LDAP code will have really hard time to translate generic URIs 
to OIDs.

I guess there are much more issues that I have missed. It looks like 
taking a schema designed for one technology and trying to reuse it "as 
is" for another technology may not be the best idea. I don't try to 
suggest that LDAP is bad. I quite believe the contrary. Some things 
shows its age and the marks of evolution, but overall it is not bad. But 
it is quite incompatible with the principles of the Web. I like LDAP a 
lot and I appreciate the engineering behind it (and ASN.1 and other 
related technologies). But I don't think that the Web is ready for that 
approach yet.

I'm not here to judge, but it looks to me that reusing inetOrgPerson in 
SCIM brings at last as many problems as would be created by introducing 
a new SCIM schema.

-- 

                                            Radovan Semancik
                                           Software Architect
                                              evolveum.com

---

From: Michael Hammer <[email-masked]>
Date: Tue, 24 Apr 2012 20:30:59 +0000

The term "overkill" comes most readily to mind.  :)

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Radovan Semancik
Sent: Tuesday, April 24, 2012 12:16 PM
To: [email-masked]
Subject: Re: [scim] SCIM Issues

On 04/24/2012 05:12 PM, Stephen Farrell wrote:
> So the other part of my question was: why do we *need* to do that 
> re-definition? What would not work if we just used inetOrgPerson (or 
> some other existing equivalent).

I'm not sure why authors of SCIM chosen not to use inetOrgPerson. Maybe the
motivation was similar to that of FOAF. Yet, as you have pointed out, new
specifications bring new problems (including FOAF), especially if they are
not tested in practice before they are standardized. Which is still the
point that I consider to be the most serious issue with respect to SCIM
standardization. But let's put that aside for now. Here is my personal list
why not inetOrgPerson:

uid, cn and others are multivalued. This is complicating the
implementations. Yes, it can be "profiled" to singlevalued, but that will
actually not be inetOrgPerson any more. The "formal" compatibility will be
gone. SCIM implementation will still needs to deal with the eventuality that
these attributes will be multivalued on the LDAP side. 
So there will be actually quite little benefit. And after all it is not
difficult to implement attribute name mapping. The difficult thing is
attribute value mapping, which cannot be avoided here. Also, did you know
that "cn" an "commonName" is actually the same attribute? I guess that it is
something from the X.500 legacy and is not really the best part of LDAP
schema specs. We can profile that as well, ruling out "commonName" and
similar long attribute names. But real good SCIM-to-LDAP implementation must
be aware of that anyway. So the mapping will not be considerably simpler.

There is cn and displayName. The displayName is there for the purpose that
cn is multivalued and it is difficult to display. We do not want a separate
attribute just to fix ages old problem. We can again profile this. But ...
well, see above.

Address is scattered across street, l, postOfficeBox, postalCode, and other
attributes. Yes, there is a postalAddress attribute, but it actually
duplicates the information. Even that can be profiled ... but ...

There is telephoneNumber, mobile (a.k.a mobileTelephoneNumber) and homePhone
(all of them multi-valued). No way to specify work phone or mark which of
the phone numbers is "primary" (except for copying that value to
telephoneNumber). For email there is just one attribute (also
multi-valued) and also no way how to mark primary address.

There are at least two frequently used an incompatible grouping mechanisms
in LDAP: groupOfNames and groupOfUniqueNames. Some applications works with
the former, some with the later. Which one to choose? We don't want both of
them. But whatever we choose, the SCIM-to-LDAP code will most likely still
need to support both. Both groupOfNames and groupOfUniqueNames contain a
list of members as DNs. We don't want to use DNs in SCIM, so this needs to
be mapped to other identifiers anyway (more mapping code). As listing the
members of large groups is inefficient and cumbersome to manage, most
vendors of good directory servers provide their own grouping mechanisms
(dynamic groups, roles). Which means even more mapping code in the usual
case.

OIDs: People that use LDAP daily and have never needed to create their own
schema usually don't know what OIDs are good for, some of them probably
don't know that OIDs even exist. Vast majority of LDAP code does not work
with OIDs but with attribute and object class names. If SCIM would chose
inetOrgPerson and still wants to maintain good extensibility, it MUST NOT
use attribute names. It should use OIDs. 
Attribute names may collide. It is not a problem in LDAP, as LDAP is usually
deployed in closed environment and not exposed to the Internet. 
Collisions are easy to handle in closed environments. The inetOrgPerson
schema is also not really evolving, so the probability of collision with
future version of inetOrgPerson is close to zero. But SCIM schema must be
able to evolve. So OIDs are probably the only inetOrgPerson-compatible
choice here. And I can't believe that something like the following example
would ever be widely adopted (although I can see a lot of benefits going
this way, we don't want SCIM to end up as SPML and DSML, do we?):

{

If this would be what we want then the best choice would probably be to stay
with ASN.1. It has a solid schema language and it is one the most efficient
data representation languages that we know. Formats based on
ASN.1 are also well extensible. And that means that we do not really need
another provisioning language at all! We can reuse LDAP. But ASN.1 is quite
difficult to work with. The scripting folk would hate it. 
Dealing with all the problems of JSON and XML is probably the lesser evil
here. But what would that mean is actually re-creating ASN.1/LDAP in JSON
and XML. I don't think we want that. DSML was something like that and it was
not a huge success. And actually, it is probably not correct to fix protocol
to just one URI scheme. Therefore SCIM should allow also other URIs for
attribute names. In which case the SCIM-to-LDAP code will have really hard
time to translate generic URIs to OIDs.

I guess there are much more issues that I have missed. It looks like taking
a schema designed for one technology and trying to reuse it "as is" for
another technology may not be the best idea. I don't try to suggest that
LDAP is bad. I quite believe the contrary. Some things shows its age and the
marks of evolution, but overall it is not bad. But it is quite incompatible
with the principles of the Web. I like LDAP a lot and I appreciate the
engineering behind it (and ASN.1 and other related technologies). But I
don't think that the Web is ready for that approach yet.

I'm not here to judge, but it looks to me that reusing inetOrgPerson in SCIM
brings at last as many problems as would be created by introducing a new
SCIM schema.

-- 

                                            Radovan Semancik
                                           Software Architect
                                              evolveum.com

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 24 Apr 2012 22:21:46 +0100

So plenty of reasons to cringe if thinking of using
inetOrgPerson, and I think you're probably right in
your text below about those.

But still no reason why it could not work.

FWIW, on the basis that I would expect as many
cringeworthy things in a new schema, some of which
wouldn't be discovered for a few years, I guess
I'm not personally convinced a new one is a necessity.

Having said that, if no-one else is concerned about
this, then maybe a new schema is fine. (And no-one
else has expressed this particular concern on the
list so far that I recall.)

S

---

From: William Mills <[email-masked]>
Date: Tue, 24 Apr 2012 14:28:10 -0700 (PDT)

As an observer, developing a new schema is a big thing.  It would really be surprising to me if there isn't something out there that already does most of what's needed.  Extending something like that seems a better solution than defining a completely new one from the ground up.

-bill

>________________________________
> From: Stephen Farrell <[email-masked]>
>To: Radovan Semancik <[email-masked]> 
>Cc: "[email-masked]" <[email-masked]> 
>Sent: Tuesday, April 24, 2012 2:21 PM

---

From: Emmanuel Dreux <[email-masked]>
Date: Tue, 24 Apr 2012 22:48:16 +0000

I would even prefer not having a schema at all:
1. We already maintain attribute mapping tables between sources and targets(name/familyName/SN/LastName, mail/email/proxyadress,LoginID)
2. Most of the time we have to exchange attributes not defined in the existing SCIM schema (social attributes, job title, job description, assistant, manager, SIP, +lots of other attributes). We have also to synchronize organizational units with some providers, and other notions of roles and entities.

Having SCIM standardize the name of standard attributes (loginID, firstname, lastname, email, nickname, etc...) and leave the flexibility to exchange whatever we want is just what we're asking for doing our business, with data formatted on the wire in a convenient way (JSON format exchanged using REST apis).

--
Regards,
Emmanuel Dreux
http://www.cloudiway.com
Tel: +33 1 46 15 07 22
Mobile: +33 6 47 81 26 70
skype: Emmanuel.Dreux

-----Message d'origine-----
De : Radovan Semancik [mailto:[email-masked]] 
Envoyé : mardi 24 avril 2012 21:16
À : [email-masked]
Objet : Re: [scim] SCIM Issues

> Doing the work for fun doesn't see appealing.

I'm not sure why authors of SCIM chosen not to use inetOrgPerson. Maybe the motivation was similar to that of FOAF. Yet, as you have pointed out, new specifications bring new problems (including FOAF), especially if they are not tested in practice before they are standardized. Which is still the point that I consider to be the most serious issue with respect to SCIM standardization. But let's put that aside for now. Here is my personal list why not inetOrgPerson:

uid, cn and others are multivalued. This is complicating the implementations. Yes, it can be "profiled" to singlevalued, but that will actually not be inetOrgPerson any more. The "formal" compatibility will be gone. SCIM implementation will still needs to deal with the eventuality that these attributes will be multivalued on the LDAP side. 
So there will be actually quite little benefit. And after all it is not difficult to implement attribute name mapping. The difficult thing is attribute value mapping, which cannot be avoided here. Also, did you know that "cn" an "commonName" is actually the same attribute? I guess that it is something from the X.500 legacy and is not really the best part of LDAP schema specs. We can profile that as well, ruling out "commonName" and similar long attribute names. But real good SCIM-to-LDAP implementation must be aware of that anyway. So the mapping will not be considerably simpler.

There is cn and displayName. The displayName is there for the purpose that cn is multivalued and it is difficult to display. We do not want a separate attribute just to fix ages old problem. We can again profile this. But ... well, see above.

Address is scattered across street, l, postOfficeBox, postalCode, and other attributes. Yes, there is a postalAddress attribute, but it actually duplicates the information. Even that can be profiled ... but ...

There is telephoneNumber, mobile (a.k.a mobileTelephoneNumber) and homePhone (all of them multi-valued). No way to specify work phone or mark which of the phone numbers is "primary" (except for copying that value to telephoneNumber). For email there is just one attribute (also
multi-valued) and also no way how to mark primary address.

There are at least two frequently used an incompatible grouping mechanisms in LDAP: groupOfNames and groupOfUniqueNames. Some applications works with the former, some with the later. Which one to choose? We don't want both of them. But whatever we choose, the SCIM-to-LDAP code will most likely still need to support both. Both groupOfNames and groupOfUniqueNames contain a list of members as DNs. We don't want to use DNs in SCIM, so this needs to be mapped to other identifiers anyway (more mapping code). As listing the members of large groups is inefficient and cumbersome to manage, most vendors of good directory servers provide their own grouping mechanisms (dynamic groups, roles). Which means even more mapping code in the usual case.

OIDs: People that use LDAP daily and have never needed to create their own schema usually don't know what OIDs are good for, some of them probably don't know that OIDs even exist. Vast majority of LDAP code does not work with OIDs but with attribute and object class names. If SCIM would chose inetOrgPerson and still wants to maintain good extensibility, it MUST NOT use attribute names. It should use OIDs. 
Attribute names may collide. It is not a problem in LDAP, as LDAP is usually deployed in closed environment and not exposed to the Internet. 
Collisions are easy to handle in closed environments. The inetOrgPerson schema is also not really evolving, so the probability of collision with future version of inetOrgPerson is close to zero. But SCIM schema must be able to evolve. So OIDs are probably the only inetOrgPerson-compatible choice here. And I can't believe that something like the following example would ever be widely adopted (although I can see a lot of benefits going this way, we don't want SCIM to end up as SPML and DSML, do we?):

{

If this would be what we want then the best choice would probably be to stay with ASN.1. It has a solid schema language and it is one the most efficient data representation languages that we know. Formats based on
ASN.1 are also well extensible. And that means that we do not really need another provisioning language at all! We can reuse LDAP. But ASN.1 is quite difficult to work with. The scripting folk would hate it. 
Dealing with all the problems of JSON and XML is probably the lesser evil here. But what would that mean is actually re-creating ASN.1/LDAP in JSON and XML. I don't think we want that. DSML was something like that and it was not a huge success. And actually, it is probably not correct to fix protocol to just one URI scheme. Therefore SCIM should allow also other URIs for attribute names. In which case the SCIM-to-LDAP code will have really hard time to translate generic URIs to OIDs.

I guess there are much more issues that I have missed. It looks like taking a schema designed for one technology and trying to reuse it "as is" for another technology may not be the best idea. I don't try to suggest that LDAP is bad. I quite believe the contrary. Some things shows its age and the marks of evolution, but overall it is not bad. But it is quite incompatible with the principles of the Web. I like LDAP a lot and I appreciate the engineering behind it (and ASN.1 and other related technologies). But I don't think that the Web is ready for that approach yet.

I'm not here to judge, but it looks to me that reusing inetOrgPerson in SCIM brings at last as many problems as would be created by introducing a new SCIM schema.

-- 

                                            Radovan Semancik
                                           Software Architect
                                              evolveum.com

---

From: Chris Phillips <[email-masked]>
Date: Wed, 25 Apr 2012 00:21:59 -0400

Regarding schema:

I appreciate the scrutiny that schema is getting as it is a complex area.  I would like to call out the backward compatibility element in the proposed charter[1] though:

"..These drafts are based on existing specifications, which together are commonly known as SCIM 1.0. As such, some consideration should be given for backward compatibility as the group evolves the work. This group will consider, the operational experience gathered from the existing work, as well as experiences with work done by other bodies, including the OASIS Provisioning TC"

I would find it very difficult to preserve back compatibility with significant alterations to the schema, extensions excepted of course.

Emmanuel, to your comment on not using any schema at all, it sounds like most of your needs would be served in using schema extension and capturing you items there.

William, there are many schemas out there, just not agreement around them. Rather than not have a schema at all, SCIM chose one and enhanced it with schema extensions allowing for flexibility for data elements yet to be thought of to keep it evergreen. The real challenge is maintaining the fidelity between what SCIM can maintain in the core and what the target in question can receive (e.g. SCIM-> LDAP ).  There are always going to be concessions made between schemas that are not the same so some fidelity may be lost in the process translating from SCIM to a target.

Stephen, count me and the federation communities observing this spec activity as concerned regarding schema change.

Chris.

[1] http://www.ietf.org/mail-archive/web/scim/current/msg00185.html

From: William Mills <[email-masked]<mailto:[email-masked]>>
Reply-To: William Mills <[email-masked]<mailto:[email-masked]>>
Date: Tue, 24 Apr 2012 17:28:10 -0400
To: Stephen Farrell <[email-masked]<mailto:[email-masked]>>, Radovan Semancik <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [scim] SCIM Issues

-bill

________________________________
From: Stephen Farrell <[email-masked]<mailto:[email-masked]>>
To: Radovan Semancik <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, April 24, 2012 2:21 PM
Subject: Re: [scim] SCIM Issues

S

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

---

From: Melinda Shore <[email-masked]>
Date: Tue, 24 Apr 2012 20:52:20 -0800

On 4/24/12 8:21 PM, Chris Phillips wrote:
> I would find it very difficult to preserve back compatibility with
> significant alterations to the schema, extensions excepted of
> course.

To be honest I find the notion of maintaining backward
compatibility with a schema that didn't maintain backward
compatibility (with inetOrgPerson, which is pretty much
everywhere) far less compelling than arguments about the
technical difficulties.  I think we could probably punt
on the embedded OIDs (although I'm not certain that we
could) but the multi-valued stuff seems like a problem.

Also, and with all due respect to, like, everybody, I always
find discussions about messages and message contents a lot
more productive than discussions about data representation,
and I've never fully understood why it's inevitably the
first place working groups want to go when undertaking a
new standardization effort.  Seems to me that it ought to be
the least interesting aspect, or at least close to the
least interesting.  I don't think that anything that's been
tossed out, up to and including ASN.1, is insufficiently
rich to be able to represent what's under discussion.

Melinda

---

From: Radovan Semancik <[email-masked]>
Date: Wed, 25 Apr 2012 10:47:59 +0200

I don't think this discussion is about data representation. Even though 
some representation mechanisms were mentioned, the core of the argument 
is data model (or meta-model if you like), extensibility mechanisms and 
compatibility.

This is very important to me and I would guess that also to the overall 
usability of SCIM.

If SCIM does not have a schema then it is almost useless. It is as 
simple as that. Anyone that ever build any provisioning 
connector/adapter will know that implementing the "protocol" is the 
simplest part. I mean implementing REST, web service, XML, JSON or 
similar layers. There are libraries for that and this part of code can 
actually work in few hours. The problem lies within the data: What 
attributes account has? What are the identifiers? Which attributes are 
mandatory to create an account? What is the type of individual 
attributes? How are times and dates represented? (and in what timezone) 
Are the values single or multivalued? How are national characters 
represented? May identifiers contain national characters? May 
identifiers change? How do we do renames? How is the account enabled and 
disabled? How are accounts assigned to groups? How are other 
entitlements assigned? Implementing and especially testing this takes 
most of the time. If SCIM cannot help to resolve this then it has very 
little real value. It would be approximately the same effort to write a 
custom adapter/connector as to customize and configure real-world SCIM 
connection. Maybe the custom way may be even more attractive as it will 
not be limited by SCIM specifications.

If SCIM is not backwards compatible, it probably won't be worth 
implementing at all. At least in the early stages. I think that 
everybody is aware that it is unlikely that a perfect schema will be 
created in early versions of SCIM. Then what is the point of 
implementing such early versions if we know that the schema is bad and 
we also know that we will need to throw out significant part of the code 
and configuration when a new SCIM version comes? And even worse: we 
would need to maintain several SCIM versions working at the same time to 
allow clients to migrate. Most people will actually wait for next 
versions of SCIM and do not implement the early versions (I assume 
reasonable thinking here, not a hype). If that is true, then there is a 
serious adoption problem.

I strongly believe that small, solid, extensible and backwards 
compatible schema is a critical part of SCIM specification. I would say 
it is much more important than the "protocol" part. I can't see how 
could SCIM be successful without that.

But in fact Melinda is right: talking about this should not be a 
(significant) part of standardization effort. However, this is protocol 
(and schema) development, not standardization. And that's the problem.

-- 

                                            Radovan Semancik
                                           Software Architect
                                              evolveum.com

---

From: William Mills <[email-masked]>
Date: Wed, 25 Apr 2012 07:49:18 -0700 (PDT)

> From: Chris Phillips <[email-masked]>
>To: "[email-masked]" <[email-masked]> 
>Sent: Tuesday, April 24, 2012 9:21 PM
>Subject: [scim] About SCIM Schema,  was ->Re:  SCIM Issues
> 
>
>Regarding schema:
>
>

That's sure not what the discussion sounds like, there's been a lot of discussion around defining names etc. That really appears to be around defining an entirely new schema for people.  Rather than that I'd suggest figuring out the rest of the structure like groups, atom identity, ownership and such and then include an object that has it's own schema like an LDAP person or something form Dublin Core.

>From:  William Mills <[email-masked]>
>Reply-To:  William Mills <[email-masked]>
>To:  Stephen Farrell <[email-masked]>, Radovan Semancik <[email-masked]>
>>> like the
following example would ever be widely adopted (although I can

---

From: Kelly Grizzle <[email-masked]>
Date: Wed, 25 Apr 2012 21:33:20 +0000

I agree with the importance of a small core schema that is extensible - SCIM would be DOA without one.  In fact, the current schema was designed trying to address many of the questions that you raised, and if it falls short in some of these areas it needs to be addressed.

For a bit of history, the SCIM schema has its origins in Portable Contacts (http://portablecontacts.net/).  Other starting points were considered (including inetOrgPerson), but ultimately PoCo was chosen because of its ability to model multi-valued complex attributes and similarity of data model.  SCIM steered away from inetOrgPerson because of its flat data model (eg - in inetOrgPerson it is very hard to model a work email address and home email address, and denote one as the primary email address), among some of the other issues that you pointed out.

> what is the point of implementing such early versions if we know that
> the schema is bad and we also know that we will need to throw out
> significant part of the code and configuration when a new SCIM version
> comes? ... If that is true, then there is a serious adoption problem.

I disagree here.  Adoption has always been a primary goal, and there are many vendors (Salesforce, Google, Cisco, Ping, UnboundID, SailPoint, etc...) that have already committed to adopting SCIM - many of whom already have working code.  You are absolutely right that some non-backwards compatible changes will need to be made.  The charter calls out that these should be kept to a minimum, and most early adopters seem happy enough with this.

The alternative is that SaaS providers continue to write their own proprietary APIs that will have the same versioning problems as SCIM.  In this world, every consumer would have to write a custom connector to every SaaS app, each with a custom protocol and language around the data that they model.

The question you raise is whether a near-perfect solution should be developed in isolation before it is unleashed to the world.  The initial philosophy of the SCIM community was that it is better to start the ball rolling with a wider community engaged (SaaS vendors, SaaS consumers, standards experts) and work out issues by writing code and finding problems along the way.  Working outside of a standards body makes it nearly impossible to engage such a large community.

--Kelly

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Radovan Semancik
Sent: Wednesday, April 25, 2012 3:48 AM
To: [email-masked]
Subject: Re: [scim] About SCIM Schema, was ->Re: SCIM Issues

I don't think this discussion is about data representation. Even though some representation mechanisms were mentioned, the core of the argument is data model (or meta-model if you like), extensibility mechanisms and compatibility.

This is very important to me and I would guess that also to the overall usability of SCIM.

If SCIM does not have a schema then it is almost useless. It is as simple as that. Anyone that ever build any provisioning connector/adapter will know that implementing the "protocol" is the simplest part. I mean implementing REST, web service, XML, JSON or similar layers. There are libraries for that and this part of code can actually work in few hours. The problem lies within the data: What attributes account has? What are the identifiers? Which attributes are mandatory to create an account? What is the type of individual attributes? How are times and dates represented? (and in what timezone) Are the values single or multivalued? How are national characters represented? May identifiers contain national characters? May identifiers change? How do we do renames? How is the account enabled and disabled? How are accounts assigned to groups? How are other entitlements assigned? Implementing and especially testing this takes most of the time. If SCIM cannot help to resolve this then it has very little real value. It would be approximately the same effort to write a custom adapter/connector as to customize and configure real-world SCIM connection. Maybe the custom way may be even more attractive as it will not be limited by SCIM specifications.

If SCIM is not backwards compatible, it probably won't be worth implementing at all. At least in the early stages. I think that everybody is aware that it is unlikely that a perfect schema will be created in early versions of SCIM. Then what is the point of implementing such early versions if we know that the schema is bad and we also know that we will need to throw out significant part of the code and configuration when a new SCIM version comes? And even worse: we would need to maintain several SCIM versions working at the same time to allow clients to migrate. Most people will actually wait for next versions of SCIM and do not implement the early versions (I assume reasonable thinking here, not a hype). If that is true, then there is a serious adoption problem.

I strongly believe that small, solid, extensible and backwards compatible schema is a critical part of SCIM specification. I would say it is much more important than the "protocol" part. I can't see how could SCIM be successful without that.

But in fact Melinda is right: talking about this should not be a
(significant) part of standardization effort. However, this is protocol (and schema) development, not standardization. And that's the problem.

-- 

                                            Radovan Semancik
                                           Software Architect
                                              evolveum.com

On 04/25/2012 06:52 AM, Melinda Shore wrote:
>> significant alterations to the schema, extensions excepted of course.
>
> To be honest I find the notion of maintaining backward compatibility 
> with a schema that didn't maintain backward compatibility (with 
> inetOrgPerson, which is pretty much
> everywhere) far less compelling than arguments about the technical 
> difficulties.  I think we could probably punt on the embedded OIDs 
> (although I'm not certain that we
> Also, and with all due respect to, like, everybody, I always find 
> discussions about messages and message contents a lot more productive 
> than discussions about data representation, and I've never fully 
> understood why it's inevitably the first place working groups want to 
> go when undertaking a new standardization effort.  Seems to me that it 
> ought to be the least interesting aspect, or at least close to the 
> least interesting.  I don't think that anything that's been tossed 
> out, up to and including ASN.1, is insufficiently rich to be able to 
> represent what's under discussion.
>
> Melinda

---

From: Radovan Semancik <[email-masked]>
Date: Thu, 26 Apr 2012 09:44:37 +0200

> I disagree here.  Adoption has always been a primary goal, and there are many vendors (Salesforce, Google, Cisco, Ping, UnboundID, SailPoint, etc...) that have already committed to adopting SCIM -…

With all respect to the early adopters, I see mostly provisioning 
vendors in the interoperability tests. If SCIM should be a "cloud" 
protocols I would expect mostly cloud providers in that group as it a 
provider side of the protocol that should specify most of the 
requirements. Is there any real production-quality deployment of SCIM 
among the early adopters? What is the feedback from the early SCIM 
tests? That it works as designed? Pardon me, but that's pretty useless 
feedback in this situation.

> The alternative is that SaaS providers continue to write their own proprietary APIs that will have the same versioning problems as SCIM.  In this world, every consumer would have to write a custom…

My argument is that if SCIM brings the same problems as proprietary APIs 
(little compatibility, weak schema, need to "profile" every deployment) 
then SCIM does not bring enough value to justify its existence. I.e. it 
would be approximately the same effort to configure SCIM connector as to 
write a new connector for proprietary API from scratch. And 
approximately the same effort to maintain them. Maybe it is even higher 
effort to maintain SCIM connector as a change in SCIM may affect many 
systems and there may be unexpected side effects.

If SCIM brings the same problems as existing APIs and improves the 
situation just a tiny bit, is it worth all the hassle?

> The question you raise is whether a near-perfect solution should be developed in isolation before it is unleashed to the world.  The initial philosophy of the SCIM community was that it is better t…

I don't argue for developing a solution in isolation. Quite the 
contrary. Open development (e.g. in a form of an open source project) is 
necessary for something like SCIM. But it has to be open development not 
yet the standardization. Standardization means fixing the interface. 
Fixing the interface inevitably limits further development. And fixing 
the interface that is inappropriate for real use does not make much 
sense to me. And engineering experience shows now and again that if 
something has not been tested in real situations it is inappropriate for 
real use (with an overwhelming probability).

Therefore if you consider SCIM 1.0 to be a very early development 
version that is barely usable and then work on SCIM 2.0 which may in 
fact bring some value I'm OK with that. But it should be clearly 
indicated that SCIM 1.0 is just a development version and it is not 
suitable for real deployments.

-- 

                                            Radovan Semancik
                                           Software Architect
                                              evolveum.com

---

From: "Brenner, Michael Ralf (Michael)" <[email-masked]>
Date: Thu, 26 Apr 2012 07:40:15 -0500

Is it really useful to get hung up on labels? ("early development", "not suitable", etc) and on the value of standards?If a handful of companies found and agreed that SCIM 1.0 to be good to implement it, in my book it beats the API that each company may have implemented a separate API in isolation. It's a good start and SCIM 2.0 should improve on it. I don't care much whether some may call it a standard or not (although I have to assume that we will call it a standard if developed in IETF, and we would ca it something else if developed as Open Source or similar), but I do care if more companies find that they can adopt it than the number of companies that adopted SCIM 1.0.
If there are good reasons to break backward compatibility to SCIM 1.0, so be it, and I expect the adopters of SCIM 1.0 can be convinced by technical arguments. The value of a standard is eventual less work globally (hence at least small savings for most) and broader adoption (at some version-point in the future, if not immediate) because of issues being found/resolved over time while re-using the core functionality. It's always more acceptable to a developer to re-develop ONCE every time the backward compatibility is broken (not that this is a good thing), than to develop n times using a different proprietary mechanism ... and who can ever guarantee that proprietary APIs do not break backward compatibility?

Having said that, I agree with Radovan that making sure the providers' requirements are understood and addressed is VERY important, much more important than either starting from SCIM 1.0, or breaking backward compatibility to it. Without clear requirements, anybody can argue either side for a long time. Assuming SCIM 1.0 was implemented against a set of clear requirements, and those are still the ones to pursue, then SCIM 1.0 is a good start, and we should not impose any hard conditions on backward compatibility (no SHALL for sure, but a rather a SHOULD if possible, or leave it open for now). If the assumption is incorrect, then we should be back at the drawing board - draft/agree new requirements if applicable, and design from scratch against those.

Michael

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Radovan Semancik
Sent: Thursday, April 26, 2012 3:45 AM
To: [email-masked]
Subject: Re: [scim] About SCIM Schema, was ->Re: SCIM Issues

-- 

                                            Radovan Semancik
                                           Software Architect
                                              evolveum.com

---

From: Kelly Grizzle <[email-masked]>
Date: Thu, 26 Apr 2012 14:53:06 +0000

I hear what you're saying and agree with you.  If SCIM does not solve real problems or provide real interoperability then it is a complete waste of time.  Where we differ is whether SCIM 1.0 is stable enough to use.  While it is not currently in production anywhere, multiple SaaS providers and vendors have committed to supporting it by the end of the year, so the "development version" label is not accurate.  Will it change in 2.0 in non-backwards-compatible ways?  Almost certainly ... but that is alright.

The primary goal of the interop events are to make sure that real use cases actually work and see where the spec doesn't hold up.  So far testing has found both weaknesses in the spec and bugs in the implementations.  Some of the spec problems are being addressed in 1.0 and some in 2.0.  See simplecloud.info for interop results and discussion.

> [Michael] I agree with Radovan that making sure the providers' requirements are
> understood and addressed is VERY important, much more important than either
> starting from SCIM 1.0, or breaking backward compatibility to it.

I totally agree.  There are some documented use cases on simplecloud.info, but they are very high level and somewhat out of date.  Lower level use cases have been used for the interop events, but these are not exhaustive and are light on detail.  The charter calls for a use cases document, which should definitely be done early in the process.

--Kelly

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Radovan Semancik
Sent: Thursday, April 26, 2012 2:45 AM
To: [email-masked]
Subject: Re: [scim] About SCIM Schema, was ->Re: SCIM Issues

On 04/25/2012 11:33 PM, Kelly Grizzle wrote:
>> significant part of the code and configuration when a new SCIM 
>> version comes? ... If that is true, then there is a serious adoption problem.

With all respect to the early adopters, I see mostly provisioning vendors in the interoperability tests. If SCIM should be a "cloud" 
protocols I would expect mostly cloud providers in that group as it a provider side of the protocol that should specify most of the requirements. Is there any real production-quality deployment of SCIM among the early adopters? What is the feedback from the early SCIM tests? That it works as designed? Pardon me, but that's pretty useless feedback in this situation.

> The alternative is that SaaS providers continue to write their own proprietary APIs that will have the same versioning problems as SCIM.  In this world, every consumer would have to write a custom…

My argument is that if SCIM brings the same problems as proprietary APIs (little compatibility, weak schema, need to "profile" every deployment) then SCIM does not bring enough value to justify its existence. I.e. it would be approximately the same effort to configure SCIM connector as to write a new connector for proprietary API from scratch. And approximately the same effort to maintain them. Maybe it is even higher effort to maintain SCIM connector as a change in SCIM may affect many systems and there may be unexpected side effects.

If SCIM brings the same problems as existing APIs and improves the situation just a tiny bit, is it worth all the hassle?

> The question you raise is whether a near-perfect solution should be developed in isolation before it is unleashed to the world.  The initial philosophy of the SCIM community was that it is better t…

I don't argue for developing a solution in isolation. Quite the contrary. Open development (e.g. in a form of an open source project) is necessary for something like SCIM. But it has to be open development not yet the standardization. Standardization means fixing the interface. 
Fixing the interface inevitably limits further development. And fixing the interface that is inappropriate for real use does not make much sense to me. And engineering experience shows now and again that if something has not been tested in real situations it is inappropriate for real use (with an overwhelming probability).

Therefore if you consider SCIM 1.0 to be a very early development version that is barely usable and then work on SCIM 2.0 which may in fact bring some value I'm OK with that. But it should be clearly indicated that SCIM 1.0 is just a development version and it is not suitable for real deployments.

-- 

                                            Radovan Semancik
                                           Software Architect
                                              evolveum.com

---

From: "Brenner, Michael Ralf (Michael)" <[email-masked]>
Date: Thu, 26 Apr 2012 10:29:00 -0500

That is what I was hoping to hear from one of the early adopters. I don't think we differ on whether SCIM 1.0 is stable enough or not. What I said earlier was that if SCIM 1.0 is considered stable enough by several companies that are implementing it (which you now confirm), then this is good enough for me. And better than a particular API implementation for the same purpose by a single company (no matter which one that was).

Michael

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kelly Grizzle
Sent: Thursday, April 26, 2012 10:53 AM
To: Radovan Semancik; [email-masked]
Subject: Re: [scim] About SCIM Schema, was ->Re: SCIM Issues

--Kelly

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Radovan Semancik
Sent: Thursday, April 26, 2012 2:45 AM
To: [email-masked]
Subject: Re: [scim] About SCIM Schema, was ->Re: SCIM Issues

-- 

                                            Radovan Semancik
                                           Software Architect
                                              evolveum.com

---

From: Melinda Shore <[email-masked]>
Date: Thu, 26 Apr 2012 08:06:34 -0800

> systems and there may be unexpected side effects.

There's often an adoption challenge around interoperability -
interoperability by definition undermines vendor lock-in.
There's an interest in *not* making it easy to provision to
other vendors' gear.  The three general responses to that are
1) to be able to make an argument that this technology is
better; 2) demand from customers, and; 3) if the vendor
software is open-source, go ahead and implement (er, "prototype")
on it.  If vendors believe they've got a proprietary advantage
with what they've got, or that the cost of implementing the new
stuff isn't going to generate (or save) enough revenue to cover
that cost, they're going to be reluctant to move.

Melinda

---

From: Phil Hunt <[email-masked]>
Date: Thu, 26 Apr 2012 11:29:18 -0700

If there are no production deployments of SCIM in operation and issues with the consortium specs have been found, why is backwards compatibility in the charter? 

Phil

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

---

From: Kelly Grizzle <[email-masked]>
Date: Thu, 26 Apr 2012 20:31:29 +0000

Primarily because there will soon be production deployments of 1.0 (plus some small fixes).  The charter says:

  some consideration should be given for backward
  compatibility as the group evolves the work.

To me this just says backwards compatibility should be one of the factors in deciding what goes into 2.0.  I don't think that 2.0 will end up having drop-in backwards compatibility with 1.0, but keeping these to a minimum will ease upgrade 2-3 years down the line when SCIM 2.0 is finalized.  That said, if the working group decides that major changes would be very beneficial to (for example) the schema, the desire for backwards compatibility may lose out.

--Kelly

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Thursday, April 26, 2012 1:29 PM
To: [email-masked]
Subject: [scim] Backwards Compatibility -> Was Re: About SCIM Schema

Phil

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

On 2012-04-26, at 7:53 AM, Kelly Grizzle wrote:

>> [Michael] I agree with Radovan that making sure the providers' 
>> requirements are understood and addressed is VERY important, much 
>> more important than either starting from SCIM 1.0, or breaking backward compatibility to it.
> 
> Of Radovan Semancik
>>> what is the point of implementing such early versions if we know 
>>> that the schema is bad and we also know that we will need to throw 
>>> out significant part of the code and configuration when a new SCIM

---

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Fri, 27 Apr 2012 01:57:21 -0500

Stephen,

Kelly answered this question much better than I could:
http://www.ietf.org/mail-archive/web/scim/current/msg00302.html

The key reason for not using inetOrgPerson is the flat vs. complex data
model. Having said that, I think the WG should evaluate and consider
using other options like vCard4 which is a lot closer to the SCIM schema
than any native LDAP schema.

Cheers,
Morteza

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stephen Farrell
Sent: Tuesday, April 17, 2012 11:35 AM
To: Samuel Erdtman
Cc: Radovan Semancik; [email-masked]
Subject: Re: [scim] SCIM Issues

On 04/17/2012 06:09 AM, Samuel Erdtman wrote:
>> >
>> > The familyName and givenName attributes have culture-neutral names.

>> > This is a nice take from FOAF. But the middleName is not that good.

>> > It enforces "american" point of view to the schema. Maybe 
>> > "additionalName" would be more appropriate.

Note - I'm not saying "use ldif" here, but wondering why this putative
WG would need to go re-do all that data modelling work, as would be
implied by the quoted text above.

S