Subject: [scim] Question regarding roles.type

From: Thomas Krille <[email-masked]>
Date: Wed, 29 Jan 2014 13:27:14 +0100

Hello,

the current SCIM schema defines the type sub-attribute for entitlements
multi-valued attribute as "useful as a means to scope entitlements" (
http://tools.ietf.org/html/draft-ietf-scim-core-schema-02#section-6.2).
Thinking about this, I realized that the roles multi-valued attribute could
benefit from such kind of type sub-attribute, too. Are there any plans to
specify the type sub-attribute for roles with the same semantics as in
entitlements? Or are there considerations against doing so? The
specification just says "This value has NO canonical types".

Kind regards

Thomas Krille
Softwareentwicklung
tarent solutions GmbH

Telefon +49 (0) 30 138803-128
Telefax +49 (0) 228 54881-235
[email-masked]

Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-0 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander
Steeg

---

From: Chris Phillips <[email-masked]>
Date: Wed, 29 Jan 2014 13:57:28 +0000

Hi Thomas,

I would like to draw your attention to ticket #11[1] in regards to your question if you haven't already checked it out.

For the other questions:

Q: Are there any plans to specify the type sub-attribute for roles with the same semantics as in entitlements?

A: Not at this time AFAIK.

Q: Or are there considerations against doing so? The specification just says "This value has NO canonical types".

A: I think it's neutral against or for so keep it as is.

The notion of sub-typing the attribute kicks it into complex attribute territory which increases complexity rather than a simple multi-valued attribute.

What I believe people are asking for when sub-typing either/or/both roles & entitlements is some way to capture 'this is an XACML entitlement, not an eduPerson Entitlement' or 'this is an application X role sub-type of 'subscriber' not Application Y role sub-type of 'subscriber' yes it is in the same field so how do I prevent collisions on permissions since I want to use that field for my application?.

The original intent of role and entitlement can be found here[2] (2011) and ultimately made it into the original spec as you see it.

Having the three main variations of how controls are applied  is to avoid hammering one model of 'control'(group vs role vs entitlement) into another just to transport it from A to B. The SCIM protocol remains neutral so that anyone could use SCIM out of the box and not dilute their model by having to transpose a role based policy structure into faux groups or entitlements into groups.  What I have seen happen is an exponential growth of groups in this regard and becomes nightmarish to navigate and manage.

What would be helpful is to describe some real world use cases to support the notion of sub-typing. This will help us all to understand the larger picture behind the questions.

If you would like to see an example of entitlements in schema take a peek at eduPerson[3]

Chris.

[1] http://trac.tools.ietf.org/wg/scim/trac/ticket/11
[2] https://groups.google.com/d/msg/cloud-directory/bvpv9HBfdYQ/_8OMgELbSF4J
[3] http://software.internet2.edu/eduperson/internet2-mace-dir-eduperson-201310.html#eduPersonEntitlement

From: Thomas Krille <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, 29 January, 2014 7:27 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [scim] Question regarding roles.type

Hello,

the current SCIM schema defines the type sub-attribute for entitlements multi-valued attribute as "useful as a means to scope entitlements" (http://tools.ietf.org/html/draft-ietf-scim-core-schema-02#section-6.2). Thinking about this, I realized that the roles multi-valued attribute could benefit from such kind of type sub-attribute, too. Are there any plans to specify the type sub-attribute for roles with the same semantics as in entitlements? Or are there considerations against doing so? The specification just says "This value has NO canonical types".

Kind regards

Thomas Krille
Softwareentwicklung
tarent solutions GmbH

Telefon +49 (0) 30 138803-128
Telefax +49 (0) 228 54881-235
[email-masked]<mailto:[email-masked]>

Rochusstraße 2-4, D-53123 Bonn * http://www.tarent.de/
Tel: +49 228 54881-0 * Fax: +49 228 54881-235
HRB AG Bonn 5168 * USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

---

From: Thomas Krille <[email-masked]>
Date: Thu, 30 Jan 2014 13:29:10 +0100

Hi Chris,

understood. Thank you very much for the clarification of this question.

Kind Regards

Thomas Krille
Softwareentwicklung
tarent solutions GmbH

2014-01-29 Chris Phillips <[email-masked]>

>  Hi Thomas,
>
>  I would like to draw your attention to ticket #11[1] in regards to your
> question if you haven't already checked it out.
>
>  For the other questions:
>
>  Q: Or are there considerations against doing so? The specification just
> says "This value has NO canonical types".
>
>  The notion of sub-typing the attribute kicks it into complex attribute
> territory which increases complexity rather than a simple multi-valued
> attribute.
>
>  What I believe people are asking for when sub-typing either/or/both
> roles & entitlements is some way to capture 'this is an XACML entitlement,
> not an eduPerson Entitlement' or 'this is an application X role sub-type of
> 'subscriber' not Application Y role sub-type of 'subscriber' yes it is in
> the same field so how do I prevent collisions on permissions since I want
> to use that field for my application?.
>
>  The original intent of role and entitlement can be found here[2] (2011)
> and ultimately made it into the original spec as you see it.
>
>  Having the three main variations of how controls are applied  is to
> avoid hammering one model of 'control'(group vs role vs entitlement) into
> another just to transport it from A to B. The SCIM protocol remains neutral
> so that anyone could use SCIM out of the box and not dilute their model by
> having to transpose a role based policy structure into faux groups or
> entitlements into groups.  What I have seen happen is an exponential growth
> of groups in this regard and becomes nightmarish to navigate and manage.
>
>  What would be helpful is to describe some real world use cases to
> support the notion of sub-typing. This will help us all to understand the
> larger picture behind the questions.
>
> [2]
> https://groups.google.com/d/msg/cloud-directory/bvpv9HBfdYQ/_8OMgELbSF4J
> [3]
> http://software.internet2.edu/eduperson/internet2-mace-dir-eduperson-201310.html#eduPersonEntitlement
>
>
>   From: Thomas Krille <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim
>
>