Re: [scim] [EXTERNAL] Extension Clarification Request

[Phillip Hunt <[e-mail]>]

Danny,

The spec is very clear on this. I think you are trying to take a rule and say it applies everywhere ignoring all other rules. In this case there it is an additive condition.  If A is present then B MUST be present.

If one includes an extension schema in schemas, then there MUST be a correspoinding schema extension attribute for it.  
>  "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User": {},


So why list a schema extension that is not in use?  It turns out there is an occasion where this is needed.  For example in a PUT operation, specifying the extension object without attributes is expressing that those extension attributes are to be removed.   E.g.  if one used Chad’s third example record in a PUT, that would allow the SCIM service provider to infer that the attributes are to be removed (See “readWrite” under 3.5.1 Replacing with PUT).

Best,

Phillip Hunt
@independentid
[e-mail]




> On Oct 21, 2022, at 12:01 PM, Danny Zollner <[e-mail]> wrote:
> 
> Looking at RFC 7643, I can see how the language isn’t crystal clear on the requirement for each in-use schema to be represented by a value in the schemas attribute. I think the line that states this is in 7643 3.3:
>  
> All representations of SCIM schemas MUST include a non-empty array with value(s) of the URIs supported by that representation. 
>  
> The latter half of that sentence being key, I think. The MUST applies to both “include a non-empty array” and “with values of the URIs supported by that representation” – meaning every schema represented on the resource needs to be present in the array of values for the schemas attribute. 
>  
> I think if we end up revising the core schema RFC and publish a new version in the future, there may be a way to word this requirement more clearly.
>  
> (As a side note, originally, I was going to say that based on a past reading I’d had of the spec that it wasn’t clear if including each schema value was a requirement, but while rereading to make that case the above quoted part of 7643 3.3 made sense to me as meaning the same thing that Phil said in his email) 
>  
> Thanks,
>  
> Danny Zollner (He/Him)
> 
> From: scim <[e-mail]> On Behalf Of Phillip Hunt
> Sent: Friday, October 21, 2022 12:12 PM
> To: Chad Vincent <[e-mail]>
> Cc: [e-mail]
> Subject: [EXTERNAL] Re: [scim] Extension Clarification Request
>  
> Chad,
>  
> The logic should be: The ResourceType for the ServiceProvider defines what schemas are possible in the User resource type.  The schemas attribute indicates what attributes are present in the JSON object and how to parse them (by looking up the schema in the /Schemas endpoint). So if you add an enterprise user attribute to a User, you have to make sure the enterprise user schema URI value is in the schemas attribute.
>  
> If no enterprise user attributes are present, then the schema value is not there either.  
>  
> The idea here is to help parsers know what to look for.
>  
> Phillip Hunt
> @independentid
> [e-mail] <mailto:[e-mail]>
>  
>  
> 
> 
> 
> On Oct 21, 2022, at 9:50 AM, Chad Vincent <[e-mail] <mailto:[e-mail]>> wrote:
>  
> If I could get clarification on this from an official source, it would be most helpful.
> 
> A Service Provider responding to a SCIM request has a User with none of the fields in the Enterprise Extension set.  Based on RFC 7643 Section 3, the "schemas" attribute is "used to indicate the namespaces of the SCIM schemas that define the attributes present in the current JSON structure."  As there are no Enterprise Extension attributes present, the extension schema urn would not be included.  However, later in the same paragraph it says that it, "MUST include a non-empty array with value(s) of the URIs supported (emphasis mine) by that representation."
>  
> Section 3.3 is likewise not helpful in clarifying, as I am reading "Each value in the "schemas" attribute indicates additive schema that MAY exist in a SCIM resource representation." as being indicative of the particular representation/response, not the service provider as a whole.  And in Section 6 it says that including the extensions in the Resource Type schema is optional.
>  
> This comes up because we've identified an Identity Provider that will not add the extension and its attributes if the extension isn't already in the user when performing a GET.  It will, however, include the extension on net-new user creation or update it if already present.  Okta and Azure have no issue with seeing a User object without the Enterprise Extension and then adding one if they want to set one of those fields.  The library we're using likewise doesn't include the schema if it's not present in the User.  This has us reviewing our interpretation of the specification.
>  
> So for a SCIM response where all the fields in an extension do not exist, is it correct to send just the root schema, include the extension schema in the "schemas" attribute, or include the extension schema in the "schemas" attribute and an empty extension attribute/object?
>  
> Sample objects:
>  
> -- No values --
> {
>   "schemas":
>     ["urn:ietf:params:scim:schemas:core:2.0:User"],
>   "id": "2819c223-7f76-453a-919d-413861904646",
>   "externalId": "701984",
>   "userName": "[e-mail] <mailto:[e-mail]>",
>   "emails": [
>     {
>       "value": "[e-mail] <mailto:[e-mail]>",
>       "type": "work",
>       "primary": true
>     }
>   ],
>   "userType": "Employee",
>   "title": "Tour Guide",
>   "active":true,
>   "meta": {
>     "resourceType": "User",
>     "created": "2010-01-23T04:56:22Z",
>     "lastModified": "2011-05-13T04:42:34Z",
>     "version": "W\/\"3694e05e9dff591\"",
>     "location":
> "https://example.com/v2/Users/2819c223-7f76-453a-919d-413861904646 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fexample.com%2Fv2%2FUsers%2F2819c223-7f76-453a-919d-413861904646&data=05%7C01%7Cdanny.zollner%40microsoft.com%7Ca40158f6408c4669e01108dab3876be8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638019691494951041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=fmk9GAxu6%2FFZr6VQ%2F5NihrHbeO3UVBhziJ4%2FEl1UW00%3D&reserved=0>"
>   }
> }
>  
> -- Schema but no Object --
> {
>   "schemas":
>     ["urn:ietf:params:scim:schemas:core:2.0:User",
>       "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"],
>   "id": "2819c223-7f76-453a-919d-413861904646",
>   "externalId": "701984",
>   "userName": "[e-mail] <mailto:[e-mail]>",
>   "emails": [
>     {
>       "value": "[e-mail] <mailto:[e-mail]>",
>       "type": "work",
>       "primary": true
>     }
>   ],
>   "userType": "Employee",
>   "title": "Tour Guide",
>   "active":true,
>   "meta": {
>     "resourceType": "User",
>     "created": "2010-01-23T04:56:22Z",
>     "lastModified": "2011-05-13T04:42:34Z",
>     "version": "W\/\"3694e05e9dff591\"",
>     "location":
> "https://example.com/v2/Users/2819c223-7f76-453a-919d-413861904646 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fexample.com%2Fv2%2FUsers%2F2819c223-7f76-453a-919d-413861904646&data=05%7C01%7Cdanny.zollner%40microsoft.com%7Ca40158f6408c4669e01108dab3876be8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638019691494951041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=fmk9GAxu6%2FFZr6VQ%2F5NihrHbeO3UVBhziJ4%2FEl1UW00%3D&reserved=0>"
>   }
> }
>  
> -- Empty object present --
> {
>   "schemas":
>     ["urn:ietf:params:scim:schemas:core:2.0:User",
>       "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"],
>   "id": "2819c223-7f76-453a-919d-413861904646",
>   "externalId": "701984",
>   "userName": "[e-mail] <mailto:[e-mail]>",
>   "emails": [
>     {
>       "value": "[e-mail] <mailto:[e-mail]>",
>       "type": "work",
>       "primary": true
>     }
>   ],
>   "userType": "Employee",
>   "title": "Tour Guide",
>   "active":true,
>   "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User": {},
>   "meta": {
>     "resourceType": "User",
>     "created": "2010-01-23T04:56:22Z",
>     "lastModified": "2011-05-13T04:42:34Z",
>     "version": "W\/\"3694e05e9dff591\"",
>     "location":
> "https://example.com/v2/Users/2819c223-7f76-453a-919d-413861904646 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fexample.com%2Fv2%2FUsers%2F2819c223-7f76-453a-919d-413861904646&data=05%7C01%7Cdanny.zollner%40microsoft.com%7Ca40158f6408c4669e01108dab3876be8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638019691494951041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=fmk9GAxu6%2FFZr6VQ%2F5NihrHbeO3UVBhziJ4%2FEl1UW00%3D&reserved=0>"
>   }
> }
>  
> -- 
> Chad Vincent (he/him) | Software Engineer, Senior - CrashPlan
> [e-mail] <mailto:[e-mail]>
> 400 S 4th St Suite 410 PMB 31083 Minneapolis, MN 55415-1419
>  
> _______________________________________________
> scim mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/scim <https://www.ietf.org/mailman/listinfo/scim>