Subject: [scim] Use of attributes parameter

From: Phil Hunt <[email-masked]>
Date: Wed, 9 May 2012 08:42:18 -0700

Note: copying the mailing list as this is interesting (I originally thought it was a simple editorial item).

Somehow I missed that modify operations could return the entire resource (and hence the attributes parameter has an effect). That seems noisy. Is this to avoid clients doing read-after-write?

From an access control perspective, this seems more complex (e.g. than say LDAP). What happens with data the client didn't provide?  Does the server withhold "proprietary data" or data contributed by other entities?  Most access control systems set rules attributes that may be returned as part of a query only. This would mean significant enhancements to most data store technologies unless the intent is that the operation acts as a modify (PUT/POST/PATCH) followed by a READ.

Phil

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

On 2012-05-09, at 6:34 AM, Kelly Grizzle wrote:

> I think that it can be used on a PUT/POST/PATCH to constrain what gets sent back as the 200 response body.
> 
>   Consumers MAY request a partial Resource representation on *any*
>   operation that returns a Resource within the response by specifying
>   the URL query parameter 'attributes'.
> 
> 
> Here is some text from the section 3.3.2 describing the use with PATCH:
> 
>   The server MUST return either a 200 OK
>   response code and the entire Resource (subject to the "attributes"
>   query parameter - see Additional Retrieval Query Parameters
>   (Section 3.7)) within the response body, or a 204 No Content response
>   code and the appropriate response headers for a successful PATCH
>   request.
> 
> --Kelly
> 
> -----Original Message-----
> From: Phil Hunt [mailto:[email-masked]] 
> Sent: Tuesday, May 08, 2012 5:56 PM
> To: Kelly Grizzle
> Cc: Trey Drake; Morteza Ansari (moransar)
> Subject: Re: attributes parameter 
> 
> Ok. Missed that.  Wonder if it should be listed on the read operations since it doesn't apply to modify, etc.
> 
> Phil
> 
> @independentid
> www.independentid.com
> [email-masked]
> 
> 
> 
> 
> 
> On 2012-05-08, at 1:11 PM, Kelly Grizzle wrote:
> 
>> The attributes query parameter is defined in section 3.7 - http://tools.ietf.org/html/draft-scim-api-00#section-3.7.  
>> 
>> Interesting point about making some attributes be explicitly requested.  This might make sense for some of the potentially larger attributes (extensions like x509 cert that have binary encoded data).
>> 
>> Issue 44 (http://code.google.com/p/scim/issues/detail?id=44) discusses an "excludedAttributes" query parameter, which may be easier to use than the "attributes" parameter if most attributes are desired.  This still won't auto-suppress certain attributes, but may be good enough.
>> 
>> --Kelly
>> 
>> 
>> -----Original Message-----
>> From: Phil Hunt [mailto:[email-masked]] 
>> Sent: Thursday, May 03, 2012 11:53 AM
>> To: Trey Drake; Morteza Ansari (moransar); Kelly Grizzle
>> Subject: attributes parameter 
>> 
>> Just looking through draft 00 of the api, I notice the attributes parameter is not documented though an example is given on page 9.  I was wondering if like directories, SCIM defines optionality and operational style of attributes.  E.g. I was thinking about yesterdays tenandid use case. Should tenantId be an attribute but likely it would be the kind of thing that should only be returned if requested.
>> 
>> Does SCIM reporting functions follow the LDAP model on this in terms of defining attributes that are always returned vs attributes that must be explicitly requested?
>> 
>> Happy to report on the mailing list later. Just thought I'd get your thought in case this is covered somewhere else in the document.
>> 
>> Phil
>> 
>> @independentid
>> www.independentid.com
>> [email-masked]
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> 
> 
>