Subject: [scim] Attributes Request Parameter and Sub-Attributes

From: Shelley <[email-masked]>
Date: Fri, 11 Sep 2020 09:48:58 -0500

I just wanted to get some clarification regarding the "attributes" request
parameter when specifying sub-attributes.

When a consumer requests a default-scoped sub-attribute using the
"attributes" parameter but does *not* specify the corresponding
default-scoped parent attribute, or vise-versa (such that they specify the
attribute, but not the desired sub-attributes), I'm assuming the
sub-attribute should *NOT* be returned?

For instance, given the following attribute, sub-attributes, and "returned"
characteristics (other characteristics omitted for brevity):

{
    "name": "emails",
    "returned": "default"
    "type": "complex",
    "multiValued": true,
    "subAttributes": [
        {
            "name": "primary",
            "returned": "default",
            ...
        },
        {
            "name": "type",
            "returned": "default",
            ...
        },
        {
            "name": "value",
            "returned": "default",
            ...
        }
    ],
    ...
}

If a caller requests just the "emails.value" attribute, but does not
specify "emails" in the attribute list, the "emails.value" will *not *be
returned?

GET /Users/2819c223-7f76-453a-919d-413861904646?attributes=emails.value
{
  "id": "2819c223-7f76-453a-919d-413861904646"
}

Likewise, if a caller requests just the "emails" attribute, but does not
specify any sub-attributes in the attributes list, the sub-attributes will
not be returned?

GET /Users/2819c223-7f76-453a-919d-413861904646?attributes=emails.value
{
  "id": "2819c223-7f76-453a-919d-413861904646",
  "emails": [{},{}]
}

Instead, based on my interpretation of the RFC, it seems that the caller
must specify *both* the "emails" attribute and the "emails.value"
sub-attribute in order to return the sub-attributes?

GET
/Users/2819c223-7f76-453a-919d-413861904646?attributes=emails,emails.value
{
  "id": "2819c223-7f76-453a-919d-413861904646",
  "emails": [
    {
      "value": "[email-masked]"
    },
    {
      "value": "[email-masked]"
    }
  ]
}

Please let me know if this understanding is correct, or if I'm overlooking
some kind of special treatment defined in the spec that includes transitive
retrieval for parent/sub-attributes. Thank you!

---

From: Phillip Hunt <[email-masked]>
Date: Fri, 11 Sep 2020 17:35:19 -0700

My understanding/recollection is 
if one requests attributes=emails.type, you would expect only the type sub-attribute to be returned. 

If one says attributes=emails, then the default sub attributes are returned.   

Phil

> On Sep 11, 2020, at 7:49 AM, Shelley <[email-masked]> wrote:
> 
> 
> I just wanted to get some clarification regarding the "attributes" request parameter when specifying sub-attributes.
> 
> When a consumer requests a default-scoped sub-attribute using the "attributes" parameter but does not specify the corresponding default-scoped parent attribute, or vise-versa (such that they specify the attribute, but not the desired sub-attributes), I'm assuming the sub-attribute should NOT be returned?
> 
> For instance, given the following attribute, sub-attributes, and "returned" characteristics (other characteristics omitted for brevity):
> 
> {
>     "name": "emails",
>     "returned": "default"
>     "type": "complex",
>     "multiValued": true,
>     "subAttributes": [
>         {
>             "name": "primary",
>             "returned": "default",
>             ...
>         },
>         {
>             "name": "type",
>             "returned": "default",
>             ...
>         },
>         {
>             "name": "value",
>             "returned": "default",
>             ...
>         }
>     ],
>     ...
> }
> 
> If a caller requests just the "emails.value" attribute, but does not specify "emails" in the attribute list, the "emails.value" will not be returned?
> 
> Likewise, if a caller requests just the "emails" attribute, but does not specify any sub-attributes in the attributes list, the sub-attributes will not be returned?
> 
> Instead, based on my interpretation of the RFC, it seems that the caller must specify both the "emails" attribute and the "emails.value" sub-attribute in order to return the sub-attributes?
> 
> GET /Users/2819c223-7f76-453a-919d-413861904646?attributes=emails,emails.value
> {
> Please let me know if this understanding is correct, or if I'm overlooking some kind of special treatment defined in the spec that includes transitive retrieval for parent/sub-attributes. Thank you!
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim

---

From: Shelley <[email-masked]>
Date: Fri, 11 Sep 2020 19:48:47 -0500

Can you clarify what part of the RFCs that comes from? The behavior you
describe seems reasonable, but by a strict reading of the returned
characteristics and attributes/excludedAttributes request parameters, I'm
not seeing any special treatment for sub-attributes.

On Fri, Sep 11, 2020 at 7:35 PM Phillip Hunt <[email-masked]>
wrote:

> For instance, given the following attribute, sub-attributes, and
> "returned" characteristics (other characteristics omitted for brevity):
>
> {
>     "name": "emails",
>     "returned": "default"
>     "type": "complex",
>     "multiValued": true,
>     "subAttributes": [
>         {
>             "name": "primary",
>             "returned": "default",
>             ...
>         },
>         {
>             "name": "type",
>             "returned": "default",
>             ...
>         },
>         {
>             "name": "value",
>             "returned": "default",
>             ...
>         }
>     ],
>     ...
> }
>

---

From: Shelley <[email-masked]>
Date: Fri, 11 Sep 2020 20:33:28 -0500

To clarify, there was a mistake in my original post. The second example
which returned the empty "emails" attributes should have read as follows,
such that the requested "attributes" value was "emails" not "emails.value":

GET /Users/2819c223-7f76-453a-919d-413861904646?attributes=emails
{
  "id": "2819c223-7f76-453a-919d-413861904646",
  "emails": [{},{}]
}

Also, to clarify, I don't think this behavior is desirable; this is just
how I have interpreted the specification since it does not call out any
special behavior for sub-attributes in partial resource representation
requests.