Re: [scim] Groups Member Type

[Shelley <[e-mail]>]

>
> *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) <[e-mail]>
wrote:

> 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 <[e-mail]>
> 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
>
>
>
> *From:* Shelley [mailto:[e-mail] <[e-mail]>]
>
> *Sent:* Wednesday, August 9, 2017 9:02 AM
> *To:* Kelly Grizzle <[e-mail]>
> *Cc:* [e-mail]
> *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 <[e-mail]> 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 <
> [e-mail]> wrote:
>
> I opened ticket #35 to change this.
>
>
>
> 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
>
>
>
> *From:* [e-mail] [mailto:[e-mail]] *On Behalf
> Of *Shelley
> *Sent:* Monday, February 11, 2013 11:36 AM
> *To:* Kelly Grizzle
> *Cc:* [e-mail]
> *Subject:* Re: [scim] Groups Member Type
>
>
>
> +1 to mark it as "immutable".
>
> On Mon, Feb 4, 2013 at 8:08 AM, Kelly Grizzle <[e-mail]>
> 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:* [e-mail] [mailto:[e-mail]] *On Behalf
> Of *Shelley
> *Sent:* Friday, February 01, 2013 1:37 PM
> *To:* [e-mail]
> *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?
>
>
>
>
>
>
>
> _______________________________________________
> scim mailing list
> [e-mail]
> 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=
>
>