Subject: [scim] AuthZ proposal for SCIM

From: Travis Spencer <[email-masked]>
Date: Fri, 25 May 2012 11:01:57 +0200

Hi All,

Please find below a proposal for changing how entitlements are handled in
SCIM. This proposal is based on various discussions that have been
happening in the community, so hopefully there is agreement on the general
idea. If there are objections or details that need to be worked out, I
welcome the feedback.

To be added to .well-known, SP Config, or whatever we end up w/ in the
long-run (i.e., section 9 of the draft):

The following multi-valued attribute is defined in addition to the common
attributes defined in Core Schema:

entitlementSchemes

A complex type that specifies supported Entitlement Scheme properties.
Instead of the standard Canonical Value for type, this attribute defines
the following Canonical Values to represent common schemes: none and basic.
REQUIRED.

name

The common Entitlement Scheme name; e.g., XACML. REQUIRED.

description

A description of the Entitlement Scheme. REQUIRED.

specUrl

An HTTP addressable URL pointing to the Entitlement Scheme's specification.
OPTIONAL.

documentationUrl

An HTTP addressable URL pointing to the Entitlement Scheme's usage
documentation. OPTIONAL.

When basic is supported, a service provider MUST also support the following
single value attribute which defines the entitlements that it supports.

basicEntitlements

A list of string values that represent the entitlements that the service
provider supports. REQUIRED if the basic Entitlement Scheme is supported.

To replace entitlements in section 6.2 of the core schema doc:

entitlements

A complex attribute containing the entitlements of a User. Entitlements are
the rights that a User has at the Service Provider as expressed according
to the policy language stipulated by the type sub-attribute. A basic syntax
is defined in this specification that allows the Client to specify a list
of entitlements as strings. There are NO canonical values specified, but a
Client can learn what values are supported by requesting the Service
Provider Configuration Resource and examining the list found in the
basicEntitlements attribute.

type

A string indicating the type of policy language. The only acceptable
canonical value is basic. REQUIRED. If the type of policy is not
understood, the Service Provider MUST return an HTTP 400, bad request.

value

The entitlements of the user. If the type is basic, this MUST be a list of
strings where the elements are from the list of supported entitlements
defined in the Service Provider's basicEntitlements schema attribute. If
the type is NOT basic, then the value MUST be a complex object that the
Service Provider is expected to know how to process. If the complex object
cannot be processed according to the syntax of the policy language
specified in the type attribute, the Service Provider MUST return an HTTP
400, bad request.

A non-normative examples of using the basic Entitlement Scheme is as
follows:

{

  "entitlements" : {

     "type": "basic",

      "value" : [ "calendar", "email", "spreadsheet" ]

  }

}

Service Providers MAY support additional policy languages instead of or in
addition to the basic one define herein. For example, a Service Provider
may support XACML and the Client may send the entitlements of a User in
accordance to that specification as in the following non-normative example:

{

  "entitlements" : {

         "type" : "xacml",

         "value" : { /* XACML policy encoded in JavaScript */ }

   }

}

-- 

Regards,
*
*
*Travis Spencer, BSCS, MBA*  | Sr. Technical Architect, CTO Office
*Ping* *Identity*                              |   www.pingidentity.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
*M:* +46 72 725 5655
*Email:* [email-masked]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
*Connect with Ping*
Twitter: @pingidentity <http://twitter.com/pingidentity>
LinkedIn: Ping's Identity
Cloud<http://www.linkedin.com/groups/Ping-Identity-Cloud-2603712>

Facebook: Ping Identity Page <https://www.facebook.com/pingidentitypage>
*Connect with me*
Twitter: @travisspencer <http://twitter.com/travisspencer>
LinkedIn: travisspencer <http://linkedin.com/in/travisspencer>

---

From: Igor Faynberg <[email-masked]>
Date: Fri, 25 May 2012 17:07:54 -0400

Trevis,

  A question (out of curiosity, since you have mentioned that all 
examples are non-normative):  Is it essential that XACML policy be 
encoded in JavaScript? Or maybe you ment  a JSON structure here?

With thanks,

Igor

On 5/25/2012 5:01 AM, Travis Spencer wrote:
> Hi All,
>
> Please find below a proposal for changing how entitlements are handled 
> in SCIM. This proposal is based on various discussions that have been 
> happening in the community, so hopefully there is agreement on the 
> general idea. If there are objections or details that need to be 
> worked out, I welcome the feedback.
>
> The following multi-valued attribute is defined in addition to the 
> common attributes defined in Core Schema:
>
> entitlementSchemes
>
> Instead of the standard Canonical Value for type, this attribute 
> defines the following Canonical Values to represent common schemes: 
> none and basic. REQUIRED.
>
> name
>
> An HTTP addressable URL pointing to the Entitlement Scheme's 
> specification. OPTIONAL.
>
> documentationUrl
>
> When basic is supported, a service provider MUST also support the 
> following single value attribute which defines the entitlements that 
> it supports.
>
> basicEntitlements
>
> A list of string values that represent the entitlements that the 
> service provider supports. REQUIRED if the basic Entitlement Scheme is 
> supported.
>
> A complex attribute containing the entitlements of a User. 
> Entitlements are the rights that a User has at the Service Provider as 
> expressed according to the policy language stipulated by the type 
> sub-attribute. A basic syntax is defined in this specification that 
> allows the Client to specify a list of entitlements as strings. There 
> are NO canonical values specified, but a Client can learn what values 
> are supported by requesting the Service Provider Configuration 
> Resource and examining the list found in the basicEntitlements attribute.
>
> type
>
> The entitlements of the user. If the type is basic, this MUST be a 
> list of strings where the elements are from the list of supported 
> entitlements defined in the Service Provider's basicEntitlements 
> schema attribute. If the type is NOT basic, then the value MUST be a 
> complex object that the Service Provider is expected to know how to 
> process. If the complex object cannot be processed according to the 
> syntax of the policy language specified in the type attribute, the 
> Service Provider MUST return an HTTP 400, bad request.
>
> Service Providers MAY support additional policy languages instead of 
> or in addition to the basic one define herein. For example, a Service 
> Provider may support XACML and the Client may send the entitlements of 
> a User in accordance to that specification as in the following 
> non-normative example:
>
> {
>
>   "entitlements" : {
>
>          "type" : "xacml",
>
> <http://www.pingidentity.com/>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
> - - - - -
> *M:* +46 72 725 5655 <tel:%2B46%2072%20725%205655>
> *Email:* [email-masked] <mailto:[email-masked]>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
> - - - - -
> *Connect with Ping*
> LinkedIn: Ping's Identity Cloud 
> <http://www.linkedin.com/groups/Ping-Identity-Cloud-2603712>
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim

---

From: Samuel Erdtman <[email-masked]>
Date: Mon, 28 May 2012 08:52:24 +0200

Great write-up, I have some thoughts regarding the examples and how
the entitlements are encoded in the user object.

As I understand it the packaging in your example would make entitlements to
a new complex type. For simplicity reasons I would like to propose to use a
multivalued string as follows:
{
  "entitlements": [
    {
      "type": "basic",
      "value": "calendar"
    },
    {
      "type": "basic",
      "value": "email"
    },
    {
      "type": "basic",
      "value": "spreadsheet"
    }
  ]
}
This representation would be a bit more verbode but no new type would be
needed.
However it would be possible to mix entitlements types since the type is
placed individually on each entitlement.
{
  "entitlements": [
    {
      "type": "xacml",
      "value": "/*XACML policy*/"
    },
    {
      "type": "basic",
      "value": "email"
    }
  ]
}

Further, if we add language saying that basic is the default type we could
represent the entitlements list as follows:
{
  "entitlements": [ "calendar", "email", "spreadsheet" ]
}

Thoughts?

Cheers
//Samuel

On Fri, May 25, 2012 at 11:01 AM, Travis Spencer
<[email-masked]>wrote:

> following single value attribute which defines the entitlements that it
> supports.
>
>
>
> basicEntitlements
>
>
>
> A complex attribute containing the entitlements of a User. Entitlements
> are the rights that a User has at the Service Provider as expressed
> according to the policy language stipulated by the type sub-attribute. A
> basic syntax is defined in this specification that allows the Client to
> specify a list of entitlements as strings. There are NO canonical values
> specified, but a Client can learn what values are supported by requesting
> the Service Provider Configuration Resource and examining the list found in
> the basicEntitlements attribute.
>
>
>
> type
>
>
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - -
> *M:* +46 72 725 5655
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - -
> *Connect with Ping*
> LinkedIn: Ping's Identity Cloud<http://www.linkedin.com/groups/Ping-Identity-Cloud-2603712>
>

---

From: Radovan Semancik <[email-masked]>
Date: Mon, 28 May 2012 16:55:10 +0200

Hi,

I would like to point out that it is not yet resolved whether roles and 
groups are considered to be entitlements, whether they should also 
appear in the "entitlements" definition or just in the "groups" and 
"roles" part or also in the "entitlements" part, how are the 
entitlements assigned to user and whether it needs or needs not to be 
consistent with group and roles assignment, etc. These are severe 
problems of existing specification that were not yet resolved. I see 
very little sense in extending the entitlements part of the 
specification and not resolving existing problems.

I guess that such problems originate in the lack of (theoretical) model 
that could be used to describe entitlements and entitlement-like 
concepts. A model that was tested in real deployment and that should be 
used to guide the protocol design. I believe that proceeding without 
such model will most likely introduce even more inconsistencies and 
ambiguities into the specification.

-- 

                                            Radovan Semancik
                                           Software Architect
                                              evolveum.com

---

From: Chris Phillips <[email-masked]>
Date: Mon, 28 May 2012 11:35:40 -0400

Hi Radovan,

Actually, I think it was never a problem to begin with. I see it is a perspective and scope question, not something done right or wrong.

SCIM is a transport for identity information.  It shouldn't care (and currently doesn't, or at least very little) what rules are overlaid on top of it (e.g. consistency between groups and roles like you talk about).  Everyone is going to want to have their own criteria beyond the default.

If someone wants to enforce referential integrity between attributes or apply a certain information management philosophy on top of the data, that's great. Go right ahead, SCIM can carry the data to and from the endpoints to allow that to happen.  SCIM is the lego building block for the transport so interesting things can be done in whatever flavour you want above and beyond SCIM and not have to worry about the mechanics at the lower levels.

>From my perspective, the challenges you describe exist regardless of the transport layer.  In this  effort around SCIM, we are talking about how it can encapsulate data, but the challenges you highlight exist if things were in  SQL tables or text files SCP'd around.

Maybe this boils down to: What is considered a Practice and what is the Protocol?

Chris.

From: Radovan Semancik <[email-masked]<mailto:[email-masked]>>
Date: Mon, 28 May 2012 10:55:10 -0400
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [scim] AuthZ proposal for SCIM

Hi,

I would like to point out that it is not yet resolved whether roles and groups are considered to be entitlements, whether they should also appear in the "entitlements" definition or just in the "groups" and "roles" part or also in the "entitlements" part, how are the entitlements assigned to user and whether it needs or needs not to be consistent with group and roles assignment, etc. These are severe problems of existing specification that were not yet resolved. I see very little sense in extending the entitlements part of the specification and not resolving existing problems.

I guess that such problems originate in the lack of (theoretical) model that could be used to describe entitlements and entitlement-like concepts. A model that was tested in real deployment and that should be used to guide the protocol design. I believe that proceeding without such model will most likely introduce even more inconsistencies and ambiguities into the specification.

--

                                           Radovan Semancik
                                          Software Architect
                                             evolveum.com

Please find below a proposal for changing how entitlements are handled in SCIM. This proposal is based on various discussions that have been happening in the community, so hopefully there is agreement on the general idea. If there are objections or details that need to be worked out, I welcome the feedback.

To be added to .well-known, SP Config, or whatever we end up w/ in the long-run (i.e., section 9 of the draft):

The following multi-valued attribute is defined in addition to the common attributes defined in Core Schema:

entitlementSchemes

A complex type that specifies supported Entitlement Scheme properties. Instead of the standard Canonical Value for type, this attribute defines the following Canonical Values to represent common schemes: none and basic. REQUIRED.

name

description

specUrl

An HTTP addressable URL pointing to the Entitlement Scheme's specification. OPTIONAL.

documentationUrl

An HTTP addressable URL pointing to the Entitlement Scheme's usage documentation. OPTIONAL.

When basic is supported, a service provider MUST also support the following single value attribute which defines the entitlements that it supports.

basicEntitlements

A list of string values that represent the entitlements that the service provider supports. REQUIRED if the basic Entitlement Scheme is supported.

entitlements

A complex attribute containing the entitlements of a User. Entitlements are the rights that a User has at the Service Provider as expressed according to the policy language stipulated by the type sub-attribute. A basic syntax is defined in this specification that allows the Client to specify a list of entitlements as strings. There are NO canonical values specified, but a Client can learn what values are supported by requesting the Service Provider Configuration Resource and examining the list found in the basicEntitlements attribute.

type

A string indicating the type of policy language. The only acceptable canonical value is basic. REQUIRED. If the type of policy is not understood, the Service Provider MUST return an HTTP 400, bad request.

value

The entitlements of the user. If the type is basic, this MUST be a list of strings where the elements are from the list of supported entitlements defined in the Service Provider's basicEntitlements schema attribute. If the type is NOT basic, then the value MUST be a complex object that the Service Provider is expected to know how to process. If the complex object cannot be processed according to the syntax of the policy language specified in the type attribute, the Service Provider MUST return an HTTP 400, bad request.

A non-normative examples of using the basic Entitlement Scheme is as follows:

{

  "entitlements" : {

     "type": "basic",

  }

}

Service Providers MAY support additional policy languages instead of or in addition to the basic one define herein. For example, a Service Provider may support XACML and the Client may send the entitlements of a User in accordance to that specification as in the following non-normative example:

{

  "entitlements" : {

         "type" : "xacml",

   }

}

--

Regards,

Travis Spencer, BSCS, MBA  | Sr. Technical Architect, CTO Office
Ping Identity                              |   www.pingidentity.com<http://www.pingidentity.com/>
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
M: +46 72 725 5655<tel:%2B46%2072%20725%205655>
Email: [email-masked]<mailto:[email-masked]>
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Connect with Ping
Twitter: @pingidentity<http://twitter.com/pingidentity>
LinkedIn: Ping's Identity Cloud<http://www.linkedin.com/groups/Ping-Identity-Cloud-2603712>
Facebook: Ping Identity Page<https://www.facebook.com/pingidentitypage>

Connect with me
Twitter: @travisspencer<http://twitter.com/travisspencer>
LinkedIn: travisspencer<http://linkedin.com/in/travisspencer>

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

---

From: Travis Spencer <[email-masked]>
Date: Tue, 29 May 2012 10:21:38 +0200

Whatever policy language is used, it needs to be relayed in a JSON message
because that data model is MTI. So, you could take a XACML message, for
example, and escape it or encode it in JSON as it's passed along. Whatever
policy language is used and however its packaged up, it needs to be able to
slip in via JSON; otherwise, it won't be compatible w/ SCIM.

On Fri, May 25, 2012 at 11:07 PM, Igor Faynberg <
[email-masked]> wrote:

> **
> Trevis,
>
>  A question (out of curiosity, since you have mentioned that all examples
> are non-normative):  Is it essential that XACML policy be encoded in
> JavaScript? Or maybe you ment  a JSON structure here?
>
> With thanks,
>
> Igor
>
>
>
> scim mailing [email-masked]://www.ietf.org/mailman/listinfo/scim
>
>

-- 

Regards,
*
*

---

From: Travis Spencer <[email-masked]>
Date: Tue, 29 May 2012 10:26:48 +0200

I thought of that, Samuel, but imagined that you'd never have policies of
multiple types. It's gonna be basic, XACML, SecPal, or whatever but its
highly unlikely to be a mix. Because of that, I thought
the simplification was good. If it creates a new complex type which
actually makes implementations more complex, not simpler, we can go w/ your
suggestion.

Feedback and thoughts from others?

On Mon, May 28, 2012 at 8:52 AM, Samuel Erdtman <[email-masked]> wrote:

> As I understand it the packaging in your example would
> make entitlements to a new complex type. For simplicity reasons I would
> like to propose to use a multivalued string as follows:
> {
>   "entitlements": [
>     {
>       "type": "basic",
>       "value": "calendar"
>     },
>     {
>       "type": "basic",
>       "value": "email"
>     },
>      {
>       "type": "basic",
>       "value": "spreadsheet"
>     }
>   ]
> }
> On Fri, May 25, 2012 at 11:01 AM, Travis Spencer <
> [email-masked]> wrote:
>
>> Hi All,
>>
>> The entitlements of the user. If the type is basic, this MUST be a list
>> of strings where the elements are from the list of supported entitlements
>> Service Providers MAY support additional policy languages instead of or
>> in addition to the basic one define herein. For example, a Service Provider

-- 

Regards,
*
*

---

From: Phil Hunt <[email-masked]>
Date: Tue, 29 May 2012 09:03:24 -0700

Why not simply encode it since the endpoint likely wants it back in XML form anyway?  

Phil

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

On 2012-05-29, at 1:21 AM, Travis Spencer wrote:

> Whatever policy language is used, it needs to be relayed in a JSON message because that data model is MTI. So, you could take a XACML message, for example, and escape it or encode it in JSON as it's passed along. Whatever policy language is used and however its packaged up, it needs to be able to slip in via JSON; otherwise, it won't be compatible w/ SCIM.
> 
> On Fri, May 25, 2012 at 11:07 PM, Igor Faynberg <[email-masked]> wrote:
> Trevis,
> 
>  A question (out of curiosity, since you have mentioned that all examples are non-normative):  Is it essential that XACML policy be encoded in JavaScript? Or maybe you ment  a JSON structure here?
> 
> With thanks,
> 
> Igor
> 
> 
> 
>> Ping Identity                              |   www.pingidentity.com
>> M: +46 72 725 5655
>> Email: [email-masked]
>> Twitter: @pingidentity
>> Facebook: Ping Identity Page	
>> Connect with me
>> Twitter: @travisspencer
>> LinkedIn: travisspencer
>> 
>> 
>> 
> Ping Identity                              |   www.pingidentity.com
> M: +46 72 725 5655
> Email: [email-masked]
> Twitter: @pingidentity
> Facebook: Ping Identity Page	
> Connect with me
> Twitter: @travisspencer
> LinkedIn: travisspencer
> 
>

---

From: Igor Faynberg <[email-masked]>
Date: Tue, 29 May 2012 12:33:45 -0400

Which makes me think that it is important to decide early whether 
support of multiple types is a requirement.

But in either case, once the individual types for entitlemes are 
defined, I don't see a problem with having a super type, too.

Igor
> I thought of that, Samuel, but imagined that you'd never have policies 
> of multiple types. It's gonna be basic, XACML, SecPal, or whatever but 
> its highly unlikely to be a mix. Because of that, I thought 
> actually makes implementations more complex, not simpler, we can go w/ 
> your suggestion.
>
> On Mon, May 28, 2012 at 8:52 AM, Samuel Erdtman <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Great write-up, I have some thoughts regarding the examples and
>     how the entitlements are encoded in the user object.
>
>     make entitlements to a new complex type. For simplicity reasons I
>     would like to propose to use a multivalued string as follows:
>     {
>       "entitlements": [
>         {
>           "type": "basic",
>           "value": "calendar"
>         },
>         {
>           "type": "basic",
>           "value": "email"
>         },
>         {
>           "type": "basic",
>           "value": "spreadsheet"
>         }
>       ]
>     }
>     This representation would be a bit more verbode but no new type
>     would be needed.
>     However it would be possible to mix entitlements types since the
>     type is placed individually on each entitlement.
>     {
>       "entitlements": [
>         {
>           "type": "xacml",
>     Further, if we add language saying that basic is the default type
>     we could represent the entitlements list as follows:
>     {
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         Hi All,
>
>         Please find below a proposal for changing how entitlements are
>         handled in SCIM. This proposal is based on various discussions
>         that have been happening in the community, so hopefully there
>         is agreement on the general idea. If there are objections or
>         details that need to be worked out, I welcome the feedback.
>
>         To be added to .well-known, SP Config, or whatever we end up
>         w/ in the long-run (i.e., section 9 of the draft):
>
>         The following multi-valued attribute is defined in addition to
>         the common attributes defined in Core Schema:
>
>         entitlementSchemes
>
>         A complex type that specifies supported Entitlement Scheme
>         properties. Instead of the standard Canonical Value for type,
>         this attribute defines the following Canonical Values to
>         represent common schemes: none and basic. REQUIRED.
>
>         name
>
>         usage documentation. OPTIONAL.
>
>         When basic is supported, a service provider MUST also support
>         the following single value attribute which defines the
>         entitlements that it supports.
>
>         basicEntitlements
>
>         A list of string values that represent the entitlements that
>         the service provider supports. REQUIRED if the basic
>         Entitlement Scheme is supported.
>
>         Entitlements are the rights that a User has at the Service
>         Provider as expressed according to the policy language
>         stipulated by the type sub-attribute. A basic syntax is
>         defined in this specification that allows the Client to
>         specify a list of entitlements as strings. There are NO
>         canonical values specified, but a Client can learn what values
>         A string indicating the type of policy language. The only
>         acceptable canonical value is basic. REQUIRED. If the type of
>         policy is not understood, the Service Provider MUST return an
>         HTTP 400, bad request.
>
>         value
>
>         The entitlements of the user. If the type is basic, this MUST
>         be a list of strings where the elements are from the list of
>         supported entitlements defined in the Service Provider's
>         basicEntitlements schema attribute. If the type is NOT basic,
>         then the value MUST be a complex object that the Service
>         Provider is expected to know how to process. If the complex
>         object cannot be processed according to the syntax of the
>         policy language specified in the type attribute, the Service
>         Provider MUST return an HTTP 400, bad request.
>
>         Service Providers MAY support additional policy languages
>         instead of or in addition to the basic one define herein. For
>         example, a Service Provider may support XACML and the Client
>         may send the entitlements of a User in accordance to that
>         specification as in the following non-normative example:
>
>         {
>
>           "entitlements" : {
>
>                  "type" : "xacml",
>
>         *Ping* *Identity*                              |
>         www.pingidentity.com <http://www.pingidentity.com/>
>         <mailto:[email-masked]>
>         <https://www.facebook.com/pingidentitypage>
>         	
>         *Connect with me*
>         [email-masked] <mailto:[email-masked]>

---

From: Anthony Nadalin <[email-masked]>
Date: Tue, 29 May 2012 16:41:00 +0000

We have many cases where the policy is defined in multiple forms and is input to same resource as some parts of a company use XACML, the other part will use SECPAL and this is mixed input on a single resource that we have to deal with

From: [email-masked] [mailto:[email-masked]] On Behalf Of Igor Faynberg
Sent: Tuesday, May 29, 2012 9:34 AM
To: [email-masked]
Subject: Re: [scim] AuthZ proposal for SCIM

Which makes me think that it is important to decide early whether support of multiple types is a requirement.

But in either case, once the individual types for entitlemes are defined, I don't see a problem with having a super type, too.

Igor

I thought of that, Samuel, but imagined that you'd never have policies of multiple types. It's gonna be basic, XACML, SecPal, or whatever but its highly unlikely to be a mix. Because of that, I thought the simplification was good. If it creates a new complex type which actually makes implementations more complex, not simpler, we can go w/ your suggestion.

Feedback and thoughts from others?
On Mon, May 28, 2012 at 8:52 AM, Samuel Erdtman <[email-masked]<mailto:[email-masked]>> wrote:
Great write-up, I have some thoughts regarding the examples and how the entitlements are encoded in the user object.

As I understand it the packaging in your example would make entitlements to a new complex type. For simplicity reasons I would like to propose to use a multivalued string as follows:
{
  "entitlements": [
    {
      "type": "basic",
      "value": "calendar"
    },
    {
      "type": "basic",
      "value": "email"
    },
    {
      "type": "basic",
      "value": "spreadsheet"
    }
  ]
}
This representation would be a bit more verbode but no new type would be needed.
However it would be possible to mix entitlements types since the type is placed individually on each entitlement.
{
  "entitlements": [
    {
      "type": "xacml",
      "value": "/*XACML policy*/"
    },
    {
      "type": "basic",
      "value": "email"
    }
  ]
}

Further, if we add language saying that basic is the default type we could represent the entitlements list as follows:
{
  "entitlements": [ "calendar", "email", "spreadsheet" ]
}

Thoughts?

Cheers
//Samuel

On Fri, May 25, 2012 at 11:01 AM, Travis Spencer <[email-masked]<mailto:[email-masked]>> wrote:
Hi All,

entitlementSchemes

name

description

specUrl

documentationUrl

basicEntitlements

entitlements

type

value

{

  "entitlements" : {

     "type": "basic",

  }

}

{

  "entitlements" : {

         "type" : "xacml",

   }

}

--

Regards,

Connect with me

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

--

Regards,

Connect with me

scim mailing list

[email-masked]<mailto:[email-masked]>

---

From: Igor Faynberg <[email-masked]>
Date: Tue, 29 May 2012 13:37:44 -0400

...Phil stole my question!

Igor

On 5/29/2012 12:03 PM, Phil Hunt wrote:
> www.independentid.com <http://www.independentid.com>
> [email-masked] <mailto:[email-masked]>
>
>
>
>
>
>> Whatever policy language is used, it needs to be relayed in a JSON 
>> message because that data model is MTI. So, you could take a XACML 
>> message, for example, and escape it or encode it in JSON as it's 
>> passed along. Whatever policy language is used and however its 
>> packaged up, it needs to be able to slip in via JSON; otherwise, it 
>> won't be compatible w/ SCIM.
>>
>> On Fri, May 25, 2012 at 11:07 PM, Igor Faynberg 
>> <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>     Trevis,
>>
>>     examples are non-normative):  Is it essential that XACML policy
>>     be encoded in JavaScript? Or maybe you ment  a JSON structure here?
>>
>>     With thanks,
>>
>>     Igor
>>
>>
>>
>>>     that have been happening in the community, so hopefully there is
>>>     agreement on the general idea. If there are objections or
>>>     To be added to .well-known, SP Config, or whatever we end up w/
>>>     in the long-run (i.e., section 9 of the draft):
>>>
>>>     service provider supports. REQUIRED if the basic Entitlement
>>>     Scheme is supported.
>>>
>>>     stipulated by the type sub-attribute. A basic syntax is defined
>>>     in this specification that allows the Client to specify a list
>>>     of entitlements as strings. There are NO canonical values
>>>     specified, but a Client can learn what values are supported by
>>>     requesting the Service Provider Configuration Resource and
>>>     examining the list found in the basicEntitlements attribute.
>>>
>>>     type
>>>
>>>     The entitlements of the user. If the type is basic, this MUST be
>>>     a list of strings where the elements are from the list of
>>>     object cannot be processed according to the syntax of the policy
>>>     language specified in the type attribute, the Service Provider
>>>     MUST return an HTTP 400, bad request.
>>>
>>>     example, a Service Provider may support XACML and the Client may
>>>     send the entitlements of a User in accordance to that