SCIM PATCH of Complex Multi-Valued Attribute Includes Filter and Sub Attribute in Path

Question

In testing SCIM PATCH operations with Azure, we're seeing operations in the form:

{
  "op": "Add",
  "path": "emails[type eq \"work\"].value",
  "value": "******@someplace.com"
}

I would read this as "add the value ******@someplace.com to any complex value that already exists in the multi-valued attribute emails and has a type attribute with the value work; if no complex value already exists within emails that matches the criteria, then do nothing". This seems really odd, because it doesn't actually result in the addition of a work email to the list of emails if it doesn't already exists or emails is unassigned. And even if it DID, technically we are not being provided a type or any other part of the complex value (i.e. the filter does not provide values for type - what if the filter was "type ew \"ork\""). In short, it feels like this isn't right.

My understanding is that an add operation should be performed on the multi-valued attribute itself (i.e. the path should not contain a filter or sub-attribute), and then the value would be - in this case - an array of complex values that should be added to emails. For example, to add an email we should see something like:

{
  "op": "Add",
  "path": "emails",
  "value": [{ "type": "work", "value": "******@someplace.com" }]
}

If there happened to already be a duplicate value (e.g. another work address), then it would effectively be a replace of that value. I believe all of this is consistent with 3.5.2.1 in RFC 7644, which doesn't even really address filters on an add operation, whereas filters are heavily discussed in 3.5.2.2 and 3.5.2.3. The examples in 3.5.2.1 also align with not having a filter on an add operation.

Given that Azure is likely doing this with many published systems, I'm wondering if somebody could help me understand what I'm missing. What would the intended behavior of the first patch in this post be when run against an unassigned emails attribute? Should we try to extract values for "type" from the filter itself knowing Azure only uses "eq"?

Thanks for any assistance!

Answer 1

Thanks for your patience here.

In short - I think what you wrote above is a reasonable interpretation of what should be expected here. This part of the SCIM spec feels a bit tricky no matter how you look at it, but there are certain parts of the SCIM spec (RFC7644 3.5.2.1) tied to the Patch Add operation that are relevant here:

• If the target location does not exist, the attribute and value are added.
• If the target location specifies an attribute that does not exist (has no value), the attribute is added with the new value.

When interpreting what those mean - you then end up trying to define "target location", which doesn't have a strict definition inside of any of RFCs 7642/43/44. This in turn may be where the trouble is - if "target location" is considered to be emails[type eq "work"].value - if the location does not exist, then the attribute(emails[type eq "work"]) is added, and the value (of the "value" sub-attribute) is added.

What Azure AD's SCIM client should do here is still being investigated, but any changes won't materialize for at least a few quarters. Regardless of whether the spec supports the way our client does this, there's a simpler and more widely compatible solution to achieve the same goal. For the time being, what Azure AD's SCIM client expects is a patch add on a filtered path - such as emails[type eq "work"].value - should add values to both the "type" (if no value of "emails" already exists with a type sub-value of "work") and the "value" sub-values.