Re: [scim] Groups Member Type

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

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

Phil

> On Aug 9, 2017, at 2:59 PM, Shelley <[e-mail]> wrote:
> 
> 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 <[e-mail]> wrote:
>> Your plan sounds good to me, Shelly.  That’s how I would implement it.
>> 
>>  
>> 
>> From: Shelley [mailto:[e-mail]] 
>> Sent: Wednesday, August 9, 2017 1:42 PM
>> To: Phil Hunt (IDM) <[e-mail]>
>> Cc: Kelly Grizzle <[e-mail]>; [e-mail]
>> 
>> 
>> Subject: Re: [scim] Groups Member Type
>>  
>> 
>> 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 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]] 
>> 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=
>> 
>>  
>> 
> 
> _______________________________________________
> 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=r2m_MvDPC_E054FW8iS_KN21BYONvlP0VoG5jrqmY1s&s=XfPtR8usf3qjskybyrZ_GpfWNWTn_l3pKiZNBe8O4tU&e=