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

[Shelley <[e-mail]>]

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
>
>
>