Subject: [scim] Query - What should attributes parameter inconsistency

From: Phil Hunt <[email-masked]>
Date: Thu, 5 Sep 2013 07:03:47 -0700

A colleague of mine has pointed out an inconsistency in the spec regarding what should be returned when the attributes parameter is used. I have no opinion other then results should be consistent, and shouldn't the record identifier always be returned at minimum?

> I have a question on the query of SCIM resources. 
> In the SCIM specifications (draft-ietf-scim-api-02), in the paragraph "3.2.2 List/Query Resources", the following request processing is described:
> 
> Get /Users?attributes=userName
> 
> In the response, 2 resources are returned to the client with for each one only the attribute userName:
> 
> HTTP/1.1 200 OK
>    Content-Type: application/json
>    {
>      "schemas":["urn:scim:schemas:core:2.0:ListResponse"],
>      "totalResults":2,
>      "Resources":[
>        {
>          "userName":"bjensen"
>        },
>        {
>          "userName":"jsmith"
>        }
>      ]
>    }
> 
> 
> 
> Then in "3.7 Additional retrieval query parameter", a similar request is described with the difference that the id is specified:
> 
> Get /Users/<id>?attributes=userName
> 
> In the response, the resource returned contains the userName attribute, but also the attributes schemas, id, and meta (with all its sub-attributes):
> 
> HTTP/1.1 200 OK
>    Content-Type: application/json
>    Location: https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646
>    ETag: W/"a330bc54f0671c9"
>    {
>      "schemas":["urn:scim:schemas:core:2.0:User"],
>      "id":"2819c223-7f76-453a-919d-413861904646",
>      "userName":"bjensen",
>      "meta":{
>        "resourceType": "User",
>        "created":"2011-08-01T18:29:49.793Z",
>        "lastModified":"2011-08-01T18:29:49.793Z",
>        "location":"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646",
>        "version":"W\/\"a330bc54f0671c9\""
>      }
>    }
> 
> So it is confusing to understand what to return when query attributes are required: 
> do we have to have 2 separate processing: one when a list of resources is returned, and one when a single resource is returned
> or is it an error in the specification examples.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Phil Hunt <[email-masked]>
Date: Thu, 5 Sep 2013 09:22:20 -0700

As an addition, we should specify what should happen when a complex attribute is specified.

I believe on the design call yesterday we discussed that the entire complex attribute and all of its values are always returned.

Phil

@independentid
www.independentid.com
[email-masked]

On 2013-09-05, at 7:03 AM, Phil Hunt <[email-masked]> wrote:

> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim

---

From: Kelly Grizzle <[email-masked]>
Date: Thu, 5 Sep 2013 18:27:14 +0000

This is definitely a spec bug since it is not consistent.

My vote would be that when the attributes query parameter is specified, *only* the requested attributes are returned (ie - not schema, id, meta, etc...).

Issue #3 deals with adding an excludedAttributes query parameter, which might be easier to use if a client were to want most of the information.

--Kelly

From: [email-masked] [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Thursday, September 05, 2013 11:22 AM
To: [email-masked] WG
Subject: Re: [scim] Query - What should attributes parameter inconsistency

Phil

@independentid
www.independentid.com<http://www.independentid.com>
[email-masked]<mailto:[email-masked]>

On 2013-09-05, at 7:03 AM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:

HTTP/1.1 200 OK

   {

     "totalResults":2,

     "Resources":[

       {

         "userName":"bjensen"

       },

       {

         "userName":"jsmith"

       }

     ]

   }

HTTP/1.1 200 OK

   {

     "userName":"bjensen",

     "meta":{

       "resourceType": "User",

       "location":"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646"<https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646>,

     }

   }

So it is confusing to understand what to return when query attributes are required:
1.   do we have to have 2 separate processing: one when a list of resources is returned, and one when a single resource is returned
2.   or is it an error in the specification examples.
Phil

@independentid
www.independentid.com<http://www.independentid.com/>
[email-masked]<mailto:[email-masked]>

_______________________________________________
scim mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/scim

---

From: Bjorn Aannestad <[email-masked]>
Date: Thu, 05 Sep 2013 13:57:02 -0500

Only the requested attributes should be returned. Although "meta" is 
arguably a special attribute, it's easy enough for a client to include 
it in the request if they depend on it.

-Bjorn

__________________________________________________________
Bjorn Aannestad | Dir, Product Management | UnboundID Corp
mailto:[email-masked] | 512-769-6461

On 2013-09-05 11:22 AM, Phil Hunt wrote:
> I believe on the design call yesterday we discussed that the entire 
> complex attribute and all of its values are always returned.
>
> Phil
>
> @independentid
> www.independentid.com <http://www.independentid.com>
> [email-masked] <mailto:[email-masked]>
>
>
>
>
>
>
>
>> A colleague of mine has pointed out an inconsistency in the spec 
>> regarding what should be returned when the attributes parameter is 
>> used. I have no opinion other then results should be consistent, and 
>> shouldn't the record identifier always be returned at minimum?
>>
>>
>>> In the SCIM specifications (draft-ietf-scim-api-02), in the 
>>> paragraph "3.2.2 List/Query Resources", the following request 
>>> processing is described:
>>>
>>> Then in "3.7 Additional retrieval query parameter", a similar 
>>> request is described with the difference that the id is specified:
>>>
>>> In the response, the resource returned contains the userName 
>>> attribute, but also the attributes schemas, id, and meta (with all 
>>> its sub-attributes):
>>>
>>> HTTP/1.1 200 OK
>>>     Location:https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646
>>>  1. do we have to have 2 separate processing: one when a list of
>>>     resources is returned, and one when a single resource is returned
>> www.independentid.com <http://www.independentid.com/>
>> [email-masked] <mailto:[email-masked]>
>>
>>
>> [email-masked] <mailto:[email-masked]>

---

From: Phil Hunt <[email-masked]>
Date: Thu, 5 Sep 2013 12:02:51 -0700

We should discuss meta attributes that are always returned vs. those that are "operational" (only returned on request).  For example, I doubt a client asking for "username" is interested in any time stamp values.

My feeling is that only the requested attributes and the record identifier should be returned.

One other consideration is schema -- the client needs enough information to parse the result.

Phil

@independentid
www.independentid.com
[email-masked]

On 2013-09-05, at 11:57 AM, Bjorn Aannestad <[email-masked]> wrote:

> Only the requested attributes should be returned.   Although "meta" is arguably a special attribute, it's easy enough for a client to include it in the request if they depend on it.
> 
> -Bjorn
>

---

From: Samuel Erdtman <[email-masked]>
Date: Thu, 5 Sep 2013 17:51:27 -0500

+1 on requested attribute only.

It will give better flexibility since it is not hard to include meta and
schema if those are desired.

Cheers
//Samuel

On Thu, Sep 5, 2013 at 2:02 PM, Phil Hunt <[email-masked]> wrote:

> We should discuss meta attributes that are always returned vs. those that
> are "operational" (only returned on request).  For example, I doubt a
> client asking for "username" is interested in any time stamp values.
>
> arguably a special attribute, it's easy enough for a client to include it
> in the request if they depend on it.
>
> -Bjorn
>
> Bjorn Aannestad | Dir, Product Management | UnboundID Corpmailto:[email-masked] <[email-masked]> | 512-769-6461
>
>
> regarding what should be returned when the attributes parameter is used. I
> have no opinion other then results should be consistent, and shouldn't the
> record identifier always be returned at minimum?
>
>
> In the SCIM specifications (draft-ietf-scim-api-02), in the paragraph
> "3.2.2 List/Query Resources", the following request processing is described:
>
> Then in "3.7 Additional retrieval query parameter", a similar request is
> described with the difference that the id is specified:
>
> In the response, the resource returned contains the userName attribute,
> but also the attributes schemas, id, and meta (with all its sub-attributes):
>
> HTTP/1.1 200 OK
>
>        "location":"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646" <https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646>,
>
> scim mailing [email-masked]://www.ietf.org/mailman/listinfo/scim
>
>

---

From: Thorsten Roßner <[email-masked]>
Date: Fri, 06 Sep 2013 15:11:18 +0200

+1

Requested attribute(s) plus mandatory attribute record identifier. I
don't think schema is necessary, but would rather see schema in there
than missing the record-id.

Cheers
Thorsten

Am 05.09.2013 21:02, schrieb Phil Hunt:
> We should discuss meta attributes that are always returned vs. those
> that are "operational" (only returned on request).  For example, I
> doubt a client asking for "username" is interested in any time stamp
> values.
>
> On 2013-09-05, at 11:57 AM, Bjorn Aannestad
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>> Only the requested attributes should be returned.   Although "meta"
>> is arguably a special attribute, it's easy enough for a client to
>> include it in the request if they depend on it.
>>
>> -Bjorn
>>
>>>> used. I have no opinion other then results should be consistent,
>>>> and shouldn't the record identifier always be returned at minimum?
>>>>
>>>>