Subject: Re: [scim] Groups Member Type

From: Shelley <[email-masked]>
Date: Wed, 9 Aug 2017 09:01:42 -0500

*Resurrecting this old thread, as this question has recently come up during
some of our interoperability testing, and there still appears to be some
ambiguity in the spec...*

The SCIM 1.1 and 2.0 specifications do not seem to indicate the expected
behavior if the type sub-attribute is not provided on a Group resource
member. Neither spec seems to explicitly require this attribute, so what is
the expected behavior if no type is provided? Is there a default (e.g. "User"
or "Group"), must Service Providers search for the member across *all *resource
types, or should it be treated as REQUIRED (e.g. returning a 400 error)?

On Mon, Feb 25, 2013 at 10:38 AM, Shelley <[email-masked]> wrote:

> Thanks, Kelly. Given that the ID may represent either a User or Group and
> only the combination of "type" and "value" uniquely identify the reference,
> should the canonical "type" attribute for group members be REQUIRED as
> well? (Further, the majority of examples throughout the Protocol
> specification only include a "value" and not "type", so it's ambiguous as
> to whether these "values" represent Users or Groups.)
>
>
>
> On Mon, Feb 11, 2013 at 4:02 PM, Kelly Grizzle <
> [email-masked]> wrote:
>
>> I opened ticket #35 to change this.
>>
>>
>>
>> http://trac.tools.ietf.org/wg/scim/trac/ticket/35
>>
>>
>>
>> --Kelly
>>
>>
>>
>> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
>> Of *Shelley
>> *Sent:* Monday, February 11, 2013 11:36 AM
>> *To:* Kelly Grizzle
>> *Cc:* [email-masked]
>> *Subject:* Re: [scim] Groups Member Type
>>
>>
>>
>> +1 to mark it as "immutable".
>>
>> On Mon, Feb 4, 2013 at 8:08 AM, Kelly Grizzle <
>> [email-masked]> wrote:
>>
>> Good point.  It seems like this should say “immutable” rather than
>> “read-only”, since it can be set initially but not updated.  Thoughts from
>> anyone else?  If this seems reasonable I’ll open an issue to get this fixed.
>>
>>
>>
>> --Kelly
>>
>>
>>
>> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
>> Of *Shelley
>> *Sent:* Friday, February 01, 2013 1:37 PM
>> *To:* [email-masked]
>> *Subject:* [scim] Groups Member Type
>>
>>
>>
>> As indicated in Section 8, the canonical types for Group members are
>> READ-ONLY. As such, how can consumers provide the type (i.e. "User" or
>> "Group")? Is it implied that IDs are unique across both users and groups in
>> order for service providers to fulfill this requirement?
>>
>>
>>
>
>

---

From: Kelly Grizzle <[email-masked]>
Date: Wed, 9 Aug 2017 15:32:13 +0000

Given the general desire for SCIM to allow loose reading but strict writing, I would vote for option 1.  If type is not specified in a PUT/POST/PATCH then the server can assume “User”.

--Kelly

From: Shelley [mailto:[email-masked]]
Sent: Wednesday, August 9, 2017 9:02 AM
To: Kelly Grizzle <[email-masked]>
Cc: [email-masked]
Subject: Re: [scim] Groups Member Type

Resurrecting this old thread, as this question has recently come up during some of our interoperability testing, and there still appears to be some ambiguity in the spec...

The SCIM 1.1 and 2.0 specifications do not seem to indicate the expected behavior if the type sub-attribute is not provided on a Group resource member. Neither spec seems to explicitly require this attribute, so what is the expected behavior if no type is provided? Is there a default (e.g. "User" or "Group"), must Service Providers search for the member across all resource types, or should it be treated as REQUIRED (e.g. returning a 400 error)?

On Mon, Feb 25, 2013 at 10:38 AM, Shelley <[email-masked]<mailto:[email-masked]>> wrote:
Thanks, Kelly. Given that the ID may represent either a User or Group and only the combination of "type" and "value" uniquely identify the reference, should the canonical "type" attribute for group members be REQUIRED as well? (Further, the majority of examples throughout the Protocol specification only include a "value" and not "type", so it's ambiguous as to whether these "values" represent Users or Groups.)

On Mon, Feb 11, 2013 at 4:02 PM, Kelly Grizzle <[email-masked]<mailto:[email-masked]>> wrote:
I opened ticket #35 to change this.

--Kelly

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Shelley
Sent: Monday, February 11, 2013 11:36 AM
To: Kelly Grizzle
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [scim] Groups Member Type

+1 to mark it as "immutable".
On Mon, Feb 4, 2013 at 8:08 AM, Kelly Grizzle <[email-masked]<mailto:[email-masked]>> wrote:
Good point.  It seems like this should say “immutable” rather than “read-only”, since it can be set initially but not updated.  Thoughts from anyone else?  If this seems reasonable I’ll open an issue to get this fixed.

--Kelly

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Shelley
Sent: Friday, February 01, 2013 1:37 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [scim] Groups Member Type

As indicated in Section 8, the canonical types for Group members are READ-ONLY. As such, how can consumers provide the type (i.e. "User" or "Group")? Is it implied that IDs are unique across both users and groups in order for service providers to fulfill this requirement?

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Wed, 9 Aug 2017 09:06:19 -0700

I agree the server can decide. 

IMO the server should check referential integrity. By doing so it would likely know the type. The spec is silent (as far as i recall) on whether it expresses it. 

You can also tell via id which is local and $ref path given's scim's strict path rules (look at the parent of the last segment). 

From my recollection some of these items were not that important given scim was provisioning api for apps - apps implementing server side are free to do what they can/want. Now that it is being used as directory, closing some unspecified / loose areas might be better for interop IMO. 

Phil

> On Aug 9, 2017, at 8:32 AM, Kelly Grizzle <[email-masked]> wrote:
> 
> On Mon, Feb 11, 2013 at 4:02 PM, Kelly Grizzle <[email-masked]> wrote:
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Shelley
> On Mon, Feb 4, 2013 at 8:08 AM, Kelly Grizzle <[email-masked]> wrote:
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Shelley
> To: [email-masked]
> _______________________________________________
> scim mailing list
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_scim&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=nXj1uLbLovxxCW-VPX0d1geWghpaAIZtMXKkPYyACLo&s=rCY_ttBwpsTcGVSsZT2hsLHWPXL17cWyIBS5WDT4oDs&e=

---

From: Shelley <[email-masked]>
Date: Wed, 9 Aug 2017 13:41:49 -0500

>
> *You can also tell via id which is local and $ref path given's scim's
> strict path rules (look at the parent of the last segment). *
>

   - Is the id now required to be globally unique across all resource
   types? If not, there is no *guarantee *that an SP can determine the
   resource type from the id.
   - The $ref is also optional, so this cannot be consistently used to
   determine the type. Further, I was under the impression that the $ref is
   primarily used for SPs to communicate the resource location to consumers,
   rather than vice versa (i.e. it's essentially a *read-only* attribute).

Here is my tentative plan for our SP implementation for evaluating *group
members*:

   - Treat *value* as *REQUIRED*. While the example SCIM schema
   <https://tools.ietf.org/html/rfc7643#page-69> does not actually require
   the group member value sub-attribute, this is the most consistent
   identifier for referring to members.
   - Treat *$ref* as *READ-ONLY* (i.e. ignore it completely when processing
   requests). Using a $ref provided by consumers seems a bit fragile (aside
   from eliminating the complexity of URI comparison, it's possible that a
   single resource may have multiple DNS names, which further complicates
   absolute URI comparisons and integrity), and introduces redundancy (and
   potential ambiguity) with value/type.
   - Treat *type *as *OPTIONAL*. My *preference *would be to treat this as
   REQUIRED in order to eliminate any ambiguity, but given that the SCIM specs
   don't require it, doing this would limit interoperability for consumers
   that may not be sending it.
   - If *type *is not provided, assume the *default value is "User"*.
   - Perform *referential integrity *to ensure that any provided group
   member resources exist, based on value and type.

*Examples*

Given the existence of the following resources, here are some example
requests/responses based on this proposal:

   - ../Users/abc
   - ../Groups/xyz

Group Members

Response

"members": [

  {
    "value": "abc",

    "type": "User"

  },

  {

    "value": "xyz",

    "type": "Group"

  }

]

2xx - Success

"members": [

  {

    "value": "abc"

  },

  {

    "value": "xyz",

    "type": "Group"

  }

]

"members": [

  {

    "value": "abc",

    "$ref": "anything at all"

  },

  {

    "value": "xyz",

    "type": "Group",

    "$ref": "anything at all"

  }

]

"members": [

  {

    "value": "xyz"

  }

]

400 - Missing “Group” "type" on nested group member definition

"members": [

  {

    "value": "xyz"

    "$ref": "../Groups/xyz"

  }

]

"members": [

  {

    "$ref": "../Users/abc"

  }

]

400 - Missing "value" on group member definition

"members": [

  {

    "$ref": "../Groups/xyz"

  }

]

"members": [

  {

    "value": "abc",

    "type": "Group"

  }

]

400 - Wrong "type" provided

"members": [

  {

    "value": "xyz",

    "type": "User"

  }

]

"members": [

  {

    "value": "abc",

    "type": "UnsupportedType"

  }

]

400 - Unsupported "type" provided

"members": [

  {

    "value": "no such resource with or without type"

  }

]

400 - Member does not exist

On Wed, Aug 9, 2017 at 11:06 AM, Phil Hunt (IDM) <[email-masked]>
wrote:

> IMO the server should check referential integrity. By doing so it would
> likely know the type. The spec is silent (as far as i recall) on whether it
> expresses it.
>
> You can also tell via id which is local and $ref path given's scim's
> strict path rules (look at the parent of the last segment).
>
> From my recollection some of these items were not that important given
> scim was provisioning api for apps - apps implementing server side are free
> to do what they can/want. Now that it is being used as directory, closing
> some unspecified / loose areas might be better for interop IMO.
>
> Phil
>
> Given the general desire for SCIM to allow loose reading but strict
> writing, I would vote for option 1.  If type is not specified in a
> PUT/POST/PATCH then the server can assume “User”.
>
>
>
> --Kelly
>
>
>
> *From:* Shelley [mailto:[email-masked] <[email-masked]>]
>
> *Sent:* Wednesday, August 9, 2017 9:02 AM
> *To:* Kelly Grizzle <[email-masked]>
> *Cc:* [email-masked]
> *Resurrecting this old thread, as this question has recently come up
> during some of our interoperability testing, and there still appears to be
> some ambiguity in the spec...*
>
>
> member. Neither spec seems to explicitly require this attribute, so what
> is the expected behavior if no type is provided? Is there a default (e.g.
> "User" or "Group"), must Service Providers search for the member across *all
> *resource types, or should it be treated as REQUIRED (e.g. returning a 400
> error)?
>
>
>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__trac.tools.ietf.org_wg_scim_trac_ticket_35&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=nXj1uLbLovxxCW-VPX0d1geWghpaAIZtMXKkPYyACLo&s=azLSrYlOBRiSWZ3BiA7nEnSujz0OPCep2bx8PeAdobE&e=>
>
>
>
> --Kelly
>
>
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.
> ietf.org_mailman_listinfo_scim&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5Y
> TpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=
> nXj1uLbLovxxCW-VPX0d1geWghpaAIZtMXKkPYyACLo&s=rCY_
> ttBwpsTcGVSsZT2hsLHWPXL17cWyIBS5WDT4oDs&e=
>
>

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Wed, 9 Aug 2017 12:17:55 -0700

Shelley,

Yes..

From the defn of id:
> A unique identifier for a 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 SCIM 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 NOT be specified by the client...

Phil

On Aug 9, 2017, at 11:41 AM, Shelley <[email-masked]> wrote:

> Is the id now required to be globally unique across all resource types? If not, there is no guarantee that an SP can determine the resource type from the id.
> The $ref is also optional, so this cannot be consistently used to determine the type. Further, I was under the impression that the $ref is primarily used for SPs to communicate the resource location to consumers, rather than vice versa (i.e. it's essentially a read-only attribute).
> Here is my tentative plan for our SP implementation for evaluating group members:
> 
> Treat value as REQUIRED. While the example SCIM schema does not actually require the group member value sub-attribute, this is the most consistent identifier for referring to members.
> Treat $ref as READ-ONLY (i.e. ignore it completely when processing requests). Using a $ref provided by consumers seems a bit fragile (aside from eliminating the complexity of URI comparison, it's possible that a single resource may have multiple DNS names, which further complicates absolute URI comparisons and integrity), and introduces redundancy (and potential ambiguity) with value/type.
> Treat type as OPTIONAL. My preference would be to treat this as REQUIRED in order to eliminate any ambiguity, but given that the SCIM specs don't require it, doing this would limit interoperability for consumers that may not be sending it.
> If type is not provided, assume the default value is "User".
> Perform referential integrity to ensure that any provided group member resources exist, based on value and type.
> Examples
> 
> Given the existence of the following resources, here are some example requests/responses based on this proposal:
> 
> ../Users/abc
> ../Groups/xyz
> 
> Group Members
> Response
> "members": [
>   {
>     "value": "abc",
>     "type": "User"
>   },
>   {
>     "value": "xyz",
>     "type": "Group"
>   }
> ]
> 2xx - Success
> "members": [
>   {
>     "value": "abc"
>   },
>   {
>     "value": "xyz",
>     "type": "Group"
>   }
> ]
> "members": [
>   {
>     "value": "abc",
>> On Wed, Aug 9, 2017 at 11:06 AM, Phil Hunt (IDM) <[email-masked]> wrote:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_scim&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=wp8wcoem5mojtpf1ZRHs5MIsgJ3x1z1mF4KRgHjkL6c&s=byhGtJG7J3hI2TFkSQI2fne2B4UrhBY1oHZDWyUvuyw&e=

---

From: Kelly Grizzle <[email-masked]>
Date: Wed, 9 Aug 2017 21:45:13 +0000

Your plan sounds good to me, Shelly.  That’s how I would implement it.

From: Shelley [mailto:[email-masked]]
Sent: Wednesday, August 9, 2017 1:42 PM
To: Phil Hunt (IDM) <[email-masked]>
Cc: Kelly Grizzle <[email-masked]>; [email-masked]
Subject: Re: [scim] Groups Member Type

  *   Is the id now required to be globally unique across all resource types? If not, there is no guarantee that an SP can determine the resource type from the id.
  *   The $ref is also optional, so this cannot be consistently used to determine the type. Further, I was under the impression that the $ref is primarily used for SPs to communicate the resource location to consumers, rather than vice versa (i.e. it's essentially a read-only attribute).

  *   Treat value as REQUIRED. While the example SCIM schema<https://tools.ietf.org/html/rfc7643#page-69> does not actually require the group member value sub-attribute, this is the most consistent identifier for referring to members.
  *   Treat $ref as READ-ONLY (i.e. ignore it completely when processing requests). Using a $ref provided by consumers seems a bit fragile (aside from eliminating the complexity of URI comparison, it's possible that a single resource may have multiple DNS names, which further complicates absolute URI comparisons and integrity), and introduces redundancy (and potential ambiguity) with value/type.
  *   Treat type as OPTIONAL. My preference would be to treat this as REQUIRED in order to eliminate any ambiguity, but given that the SCIM specs don't require it, doing this would limit interoperability for consumers that may not be sending it.
  *   If type is not provided, assume the default value is "User".
  *   Perform referential integrity to ensure that any provided group member resources exist, based on value and type.

Examples

  *   ../Users/abc
  *   ../Groups/xyz

Group Members

Response

"members": [

  {
    "value": "abc",

    "type": "User"

  },

  {

    "value": "xyz",

    "type": "Group"

  }

]

2xx - Success

"members": [

  {

    "value": "abc"

  },

  {

    "value": "xyz",

    "type": "Group"

  }

]

"members": [

  {

    "value": "abc",

  },

  {

    "value": "xyz",

    "type": "Group",

  }

]

"members": [

  {

    "value": "xyz"

  }

]

"members": [

  {

    "value": "xyz"

    "$ref": "../Groups/xyz"

  }

]

"members": [

  {

    "$ref": "../Users/abc"

  }

]

"members": [

  {

    "$ref": "../Groups/xyz"

  }

]

"members": [

  {

    "value": "abc",

    "type": "Group"

  }

]

"members": [

  {

    "value": "xyz",

    "type": "User"

  }

]

"members": [

  {

    "value": "abc",

  }

]

"members": [

  {

  }

]

On Wed, Aug 9, 2017 at 11:06 AM, Phil Hunt (IDM) <[email-masked]<mailto:[email-masked]>> wrote:
I agree the server can decide.

Phil

On Aug 9, 2017, at 8:32 AM, Kelly Grizzle <[email-masked]<mailto:[email-masked]>> wrote:
Given the general desire for SCIM to allow loose reading but strict writing, I would vote for option 1.  If type is not specified in a PUT/POST/PATCH then the server can assume “User”.

--Kelly

To: Kelly Grizzle <[email-masked]<mailto:[email-masked]>>

http://trac.tools.ietf.org/wg/scim/trac/ticket/35<https://urldefense.proofpoint.com/v2/url?u=http-3A__trac.tools.ietf.org_wg_scim_trac_ticket_35&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=nXj1uLbLovxxCW-VPX0d1geWghpaAIZtMXKkPYyACLo&s=azLSrYlOBRiSWZ3BiA7nEnSujz0OPCep2bx8PeAdobE&e=>

--Kelly

--Kelly

_______________________________________________
scim mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_scim&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=nXj1uLbLovxxCW-VPX0d1geWghpaAIZtMXKkPYyACLo&s=rCY_ttBwpsTcGVSsZT2hsLHWPXL17cWyIBS5WDT4oDs&e=

---

From: Shelley <[email-masked]>
Date: Wed, 9 Aug 2017 16:59:31 -0500

Thanks for the feedback.

*Now that it is being used as directory, closing some unspecified / loose
> areas might be better for interop IMO. *
>

Is it possible to fold some of these clarifications into the next SCIM RFC?

On Wed, Aug 9, 2017 at 4:45 PM, Kelly Grizzle <[email-masked]>
wrote:

> *From:* Shelley [mailto:[email-masked]]
> *Sent:* Wednesday, August 9, 2017 1:42 PM
> *To:* Phil Hunt (IDM) <[email-masked]>
> *Cc:* Kelly Grizzle <[email-masked]>; [email-masked]
>
>    determine the type. Further, I was under the impression that the $ref
>    is primarily used for SPs to communicate the resource location to
>    consumers, rather than vice versa (i.e. it's essentially a *read-only*
>    attribute).
>
>    <https://tools.ietf.org/html/rfc7643#page-69> does not actually
>    require the group member value sub-attribute, this is the most
>    consistent identifier for referring to members.
>    - Treat *$ref* as *READ-ONLY* (i.e. ignore it completely when
>    processing requests). Using a $ref provided by consumers seems a bit
>    fragile (aside from eliminating the complexity of URI comparison, it's
>    possible that a single resource may have multiple DNS names, which further
>    complicates absolute URI comparisons and integrity), and introduces
>    redundancy (and potential ambiguity) with value/type.
>    - Treat *type *as *OPTIONAL*. My *preference *would be to treat this
>    as REQUIRED in order to eliminate any ambiguity, but given that the SCIM
>    specs don't require it, doing this would limit interoperability for
>    consumers that may not be sending it.
>    - If *type *is not provided, assume the *default value is **"User"*.
> *Group Members*
> *Response*
> *2xx* - Success
> *400 *- Missing “Group” "type" on nested group member definition
>
> "members": [
>
>   {
>
>     "value": "xyz"
>
>     "$ref": "../Groups/xyz"
>
>   }
>
> ]
>
> "members": [
>
>   {
>
>     "$ref": "../Users/abc"
>
>   }
>
> ]
>
> *400 *- Missing "value" on group member definition
>
> "members": [
>
>   {
>
>     "$ref": "../Groups/xyz"
>
>   }
>
> ]
>
> "members": [
>
>   {
>
>     "value": "abc",
>
>     "type": "Group"
>
>   }
>
> ]
>
> *400 *- Wrong "type" provided
>
> "members": [
>
>   {
>
>     "value": "xyz",
>
>     "type": "User"
>
>   }
>
> ]
>
> "members": [
>
>   {
>
>     "value": "abc",
>
> *400 *- Unsupported "type" provided
>
> "members": [
>
>   {
>
> *400 *- Member does not exist
>
>
>
>
>

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Wed, 9 Aug 2017 16:14:20 -0700

I don't know. We would have to have enough interest to re-charter. 

Phil

> On Aug 9, 2017, at 2:59 PM, Shelley <[email-masked]> wrote:
> 
> Thanks for the feedback. 
> 
>> Now that it is being used as directory, closing some unspecified / loose areas might be better for interop IMO. 
> 
>> On Wed, Aug 9, 2017 at 4:45 PM, Kelly Grizzle <[email-masked]> wrote:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_scim&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=r2m_MvDPC_E054FW8iS_KN21BYONvlP0VoG5jrqmY1s&s=XfPtR8usf3qjskybyrZ_GpfWNWTn_l3pKiZNBe8O4tU&e=