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

[Shelley <[e-mail]>]

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 <[e-mail]>
wrote:

> 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 <[e-mail]> 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": "[e-mail]"
>     },
>     {
>       "value": "[e-mail]"
>     }
>   ]
> }
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/scim
>
>