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

[Shelley <[e-mail]>]

I *think *the SCIM client is intending to delete all phone numbers; they
only manage zero or one phone number, and when there is no phone number,
they send the "phoneNumbers" attribute with a single phone number object
that has no "value" subattribute.

"phoneNumbers": [
  {
    "value": null,
    "type": null
  }
]

Our implementation already does require the "value" subattribute for
multi-valued attributes, including "phoneNumbers", so we are failing fast
here, which is still my preference. However, the SCIM client is using the
SCIM core spec for their basis on allowing null "value" subattributes to be
sent since it doesn't explicitly require it (although we do). As such, with
their current implementation, they are unable to successfully send users
that have no phone numbers to us, which is why we were (reluctantly)
considering lifting this restriction.

If I'm understanding correctly, you agree that the client *should not *be
sending this data (although the spec is somewhat ambiguous in this regard)
and would advise SPs to require "value" subattributes to eliminate any
ambiguity in handling this scenario?


On Tue, May 10, 2022 at 5:43 PM Phillip Hunt <[e-mail]>
wrote:

> 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]>
> 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]
>>
>>
>>
>>
>> On May 10, 2022, at 12:41 PM, Shelley <[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]
>> https://www.ietf.org/mailman/listinfo/scim
>>
>>
>>
>