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

Shelley <randomshelley@gmail.com> Sat, 12 September 2020 01:33 UTC

MIME-Version: 1.0
References: <CAGUsYPxeyMYqMuZcfhvdE7Sdnf3F2iFPVYYtrXAW06ZT2JTt_A@mail.gmail.com>
In-Reply-To: <CAGUsYPxeyMYqMuZcfhvdE7Sdnf3F2iFPVYYtrXAW06ZT2JTt_A@mail.gmail.com>
From: Shelley <randomshelley@gmail.com>
Date: Fri, 11 Sep 2020 20:33:28 -0500
Message-ID: <CAGUsYPxXNYyv3hCqajbg0pGAr1v5W+Veu7+_yThVTPy-prYHpA@mail.gmail.com>
To: scim@ietf.org
Content-Type: multipart/alternative; boundary="0000000000006db02105af13cab3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/scim/dF70gehGNnBDHW4afSIw60k1acs>
Subject: Re: [scim] Attributes Request Parameter and Sub-Attributes
Precedence: list

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.


On Fri, Sep 11, 2020 at 9:48 AM Shelley <randomshelley@gmail.com> 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?
>
> 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