[scim] Attributes Request Parameter and Sub-Attributes

Shelley <randomshelley@gmail.com> Fri, 11 September 2020 14:49 UTC

MIME-Version: 1.0
From: Shelley <randomshelley@gmail.com>
Date: Fri, 11 Sep 2020 09:48:58 -0500
Message-ID: <CAGUsYPxeyMYqMuZcfhvdE7Sdnf3F2iFPVYYtrXAW06ZT2JTt_A@mail.gmail.com>
To: scim@ietf.org
Content-Type: multipart/alternative; boundary="00000000000088839705af0ac922"
Archived-At: <https://mailarchive.ietf.org/arch/msg/scim/0EdVcK714jht8uTRu8_N26Mlh7M>
Subject: [scim] Attributes Request Parameter and Sub-Attributes
Precedence: list

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": "bjensen@example.com"
    },
    {
      "value": "babs@jensen.org"
    }
  ]
}

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] Attributes Request Parameter and Sub-Attri… Shelley
Re: [scim] Attributes Request Parameter and Sub-A… Phillip Hunt
Re: [scim] Attributes Request Parameter and Sub-A… Shelley
Re: [scim] Attributes Request Parameter and Sub-A… Shelley