Re: [scim] Groups Member Type

["Phil Hunt (IDM)" <[e-mail]>]

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]] 
> 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
>  
> --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=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=nXj1uLbLovxxCW-VPX0d1geWghpaAIZtMXKkPYyACLo&s=rCY_ttBwpsTcGVSsZT2hsLHWPXL17cWyIBS5WDT4oDs&e=