Re: [scim] Multi-Valued Attribute "Value" Requirement

[Phillip Hunt <[e-mail]>]

Shelley,

This looks like the SCIM client has a serious bug and is failing to map the number correctly and is not intending to delete all values. As a service provider, to be careful, I would change the phoneNumbers value attribute schema to be required. This would cause the operation to fail. I think following the “null” or “empty set” rule might risk deleting data that was not intended.

Phillip Hunt
@independentid
[e-mail]




> On May 10, 2022, at 1:30 PM, Shelley <[e-mail]> wrote:
> 
> Thanks for the feedback. 
> 
> > Is the clients sending all of the numbers at once?  Or are these meant as individual examples?  
> 
> The client is not sending all of those values in a single "phoneNumbers" array; the example was just to illustrate several value-less "phoneNumbers" that SCIM implementations would need to handle, and to help provide different examples in case each may be interpreted differently.
> 
> > I would look to Section 3.3 (Create) and 3.5.1 (Put) and also 7643 Sec 2.5, where “null” (or [] in the case of multi-values) means to override existing or default values to assert them as null.  Doing so inside of a MV attribute makes a little less sense. 
> 
> Correct, those sections don't really speak directly to sub-attributes. For reference, on a POST or PUT our implementation does accept any of the following, inline with the RFC:
> "phoneNumbers": null
> "phoneNumbers": []
> omission of the multi-valued attribute
> > The ugliness of this example does show why making “value” as required in phoneNumbers for the next iteration of 7643 might be a good idea.  :-)
> 
> Is there somewhere that we can log this to keep track of this for inclusion in the next RFC?
> 
> In the meantime, I'm still curious as to how other server implementations and clients handle this scenario. My first preference would be to continue requiring the "value" subattribute in these cases, but if we need to make changes for broader compatibility with such clients, I'm assuming we should just ignore the value-less multi-valued attributes? And/or are others actually persisting and returning these valueless objects (e.g. with just the "type"/"primary" subattributes)?
>  
> 
> On Tue, May 10, 2022 at 3:02 PM Phillip Hunt <[e-mail] <mailto:[e-mail]>> wrote:
> Shelley,
> 
> I would look to Section 3.3 (Create) and 3.5.1 (Put) and also 7643 Sec 2.5, where “null” (or [] in the case of multi-values) means to override existing or default values to assert them as null.  Doing so inside of a MV attribute makes a little less sense. 
> 
> Is the clients sending all of the numbers at once?  Or are these meant as individual examples?  
> 
> For a SCIM PUT operation, sending “phoneNumbers”: [],  or “phoneNumbers”: [{}] would likely result in reseting the phoneNumbers value to unasserted removing any existing values. In the case of create, it overrides any default values that would otherwise be generated.   This is useful because some servers might default work number to a company 1-800 number. Using “null” allows clients to override to say no number for this person.
> 
> The ugliness of this example does show why making “value” as required in phoneNumbers for the next iteration of 7643 might be a good idea.  :-)
> 
> Phillip Hunt
> @independentid
> [e-mail] <mailto:[e-mail]>
> 
> 
> 
> 
>> On May 10, 2022, at 12:41 PM, Shelley <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> How should a SCIM server implementation interpret and manage multi-valued attributes that are sent without values?
>> 
>> For example, if a SCIM client sends any of the following phone numbers:
>> 
>> "phoneNumbers": [
>>   {},
>>   {
>>     "value": null
>>   }, 
>>   {
>>     "value": null,
>>     "type": null
>>   },
>>   {
>>     "value": null,
>>     "primary": true
>>   },
>>   {
>>     "type": "work",
>>     "primary": false
>>   }
>> ]
>> 
>> Should the SCIM server accept, ignore, or reject some/all of these phone numbers? The spec does not strictly require the "value", but it seems quite ambiguous to send a phone number without a phone number, for example.
>> 
>> In our SCIM 1.1 and 2.0 server implementations, we have marked the "value" subattribute for all supported multi-valued attributes as "required" in our schema, documentation, and functionality. After 11 years, we have just now encountered a SCIM client that sends multi-valued attributes without value subattributes, however, to which we return a 400 error. We have documented the "value" subattribute as required in the schema we return from the "Schemas" endpoint:
>> 
>> {
>>   "name": "value",
>>   "type": "string",
>>   "multiValued": false,
>>   "description": "The phone number.",
>>   "required": true,
>>   "caseExact": false,
>>   "mutability": "readWrite",
>>   "returned": "default",
>>   "uniqueness": "none"
>> }
>> 
>> However, the SCIM specification does not explicitly require it in the example schema nor in the RFC text.
>> 
>> In my opinion, since the "value" is "the significant value", it should be required for the multi-valued attributes that support it, and SCIM clients should simply omit the object if there is no enclosed value. Without a value, the object seems invalid/incomplete/ambiguous. In lieu of that, is our next best bet just to completely ignore any valueless multi-valued attributes, regardless of whether any other subattributes are provided? How do other SCIM providers and consumers handle this?
>> _______________________________________________
>> scim mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/scim <https://www.ietf.org/mailman/listinfo/scim>
>