Re: [scim] [EXTERNAL] Query on a specific known resource

[Julien Schneider <[e-mail]>]

Hi Phil, hi all,

Thanks a lot for your extensive response and forgive my late response, 
I'm just back from vacations!

I think we agree on the fact that all query responses must be in the 
form of a ListResponse (unless an error occurred).

Again, the main confusing point (in my opinion) is the presence of the 
"3.4.2.5. Attributes" section under the "3.4.2. Query Resources" 
section, without specifying that while attributes can be used on 
queries, their usage by itself do not fall under the query definition.
In other words:
- According to 3.4.1, when retrieving a know resource (e.g. GET 
/Users/abcd) the resource should directly be returned
- According to 3.4.2
     - Standard query parameters are filter/sort/pagination parameters 
<= attributes parameters are NOT listed here
     - Queries responses must be in the form of a ListResponse
     - Queries can be done on a set of resources or on a single resource 
<= this implies that using a filter/sort/pagination parameter on a known 
resource retrieval requires a ListResponse response
- Attributes CAN be used on queries, but attributes usage do not 
requires a ListReponse response by itself (it depends on the type of 
request on which attributes are used)

As examples:
- GET /Users/abcd?attributes=id,userName is /*not?*/ a query and do 
/*not?*/ require a ListResponse response <= this is my pain point :)
     - There is a similar example in 
https://datatracker.ietf.org/doc/html/rfc7644#section-3.9 which doesn't 
have a ListResponse response
- GET /Users/abcd?filter=userName eq "Blah" *is* a query and requires a 
ListResponse response
- GET /Users?filter=userName eq "Blah" *is* a query and requires a 
ListResponse response
- GET /Users?attributes=id,userName *is* a query and requires a 
ListResponse response <= this is similar as the first one, except it's 
on the resource endpoint (hence the ListResponse) and not on a known 
resource
- GET /Users?attributes=id,userName&filter=userName eq "Blah" *is* a 
query and requires a ListResponse response

The core point of my messages is to know if that affirmation is correct: 
"Attributes CAN be used on queries, but attributes usage do not implies 
a ListReponse response by itself (it depends on the type of request on 
which attributes are used)"

If it is correct, I think it would have been good to explicitly say that 
in the RFC. However, I don't know if other people here agree with that, 
I don't know if it is worth to do something about it, and I don't know 
the best approach to have IF we agree it's worth to do something :) (in 
that case we thought about an Errata, but it may not be the correct 
approach)

In practice, I fully agree that different implementations probably exist 
and that it's safer for a client to check the "schema" attribute to be 
as compatible as possible.

Side question: is "GET /Users" allowed according strictly to the RFC? I 
think it implicitly falls under the query definition (even without any 
query parameter)?

Thanks again!

Julien Schneider
Tel: [phone]
Fax: [phone]

http://www.audriga.com  |http://www.twitter.com/audriga

--------------------------------------------------------------------------
audriga GmbH |  Alter Schlachthof 57  | 76137 Karlsruhe
Sitz der Gesellschaft: Karlsruhe - Amtsgericht Mannheim - HRB 713034
Geschäftsführer: Dr. Frank Dengler, Dr.-Ing. Hans-Jörg Happel
--------------------------------------------------------------------------

On 15/07/2022 19:54, Phillip Hunt wrote:
> Julien,
>
> I believe the answer was that whenever a “filter” is supplied, the 
> response MUST (as in normative) be in the form of a ListResponse 
> unless an error has occurred. Returning the resource is not valid.
>
> I don’t believe your suggestion would qualify as an Errata (but you 
> can still submit it). This issue has a “wouldn’t it have been simpler 
> if SCIM just did this” feel.  Such a change would be “normative” 
> change to the protocol rather than an Errata.
>
> Chairs, please correct me appropriately if I am wrong…
>
> IETF RFCs can’t be directly revised this way even if the consensus of 
> the group has changed since RFC7644 was published. The correct process 
> would be the working group discussing changing behavior in a future 
> SCIM version (meaning a new RFC and protocol version).
>
> Is just returning a resource for a query against the resource really 
> simple?
> In my opinion no. The simpifying assumption only handles the “match” 
> case and fails to consider negative cases. If such a change would 
> made, SCIM Service Providers would lose the ability to signal filter 
> NOT MATCHED vs. NOT FOUND (404) as servers would only be able to 
> respond with Status 404. Yes, instead of 404 we could still return a 
> ListResponse, but now you are making single resource queries 
> signalling very complex.  As written now, a query returns a 
> ListResponse unless there is an error (no match is not an error).
>
> —> again…this is all debatable as to what way is right. It is 
> something for the group to discuss in a future draft.  I am not that 
> against this. It’s just that there is a process. :-)
>
> As practical advice, I would assume mistakes in implementation are 
> made.  Make sure your client parser looks at the “schemas” attribute 
> to see what you have. If you don’t find the “ListResponse” schema, you 
> can then check to see if it is a resource.  That’s one of the 
> “failsafe" features of SCIM that allows parsers to figure out what was 
> received by looking at the “schemas” attribute.
>
> Phil Hunt
> Editor for RFC7644
>
>> On Jul 15, 2022, at 6:14 AM, Julien Schneider <[e-mail]> wrote:
>>
>>  Hi all,
>>
>> I didn't get any answers to my previous mail, so I guess my thinking 
>> and interpretation are more or less correct.
>>
>> I still think that the RFC is a bit confusing on that topic. I'd 
>> probably like to shortly discuss the issue with the working group to 
>> decide if I should file an errata for this. Unfortunately, I wont be 
>> able to participate to IETF 114, but my colleagues Joris and 
>> Hans-Jorg (in CC) will participate in person.
>> Joris is aware of all that and should have some time to talk about it 
>> in the side meetings if that makes sense for some of you (I guess 
>> side meetings might be sufficient/more appropriate for this kind of 
>> things?).
>>
>> Thanks again,
>> Julien Schneider
>> Tel: [phone]
>> Fax: [phone]
>>
>> http://www.audriga.com  |http://www.twitter.com/audriga
>>
>> --------------------------------------------------------------------------
>> audriga GmbH |  Alter Schlachthof 57  | 76137 Karlsruhe
>> Sitz der Gesellschaft: Karlsruhe - Amtsgericht Mannheim - HRB 713034
>> Geschäftsführer: Dr. Frank Dengler, Dr.-Ing. Hans-Jörg Happel
>> --------------------------------------------------------------------------
>> On 08/07/2022 10:22, Julien Schneider wrote:
>>> Hi all,
>>>
>>> Thanks a lot for your answers, it really helps.
>>> By re-reading the RFC at the light of your responses, I think I'm 
>>> starting to understand.
>>>
>>> Section 3.4.2 starts with:
>>>     The SCIM protocol defines a standard set of query parameters that can
>>>     be used to*filter*,*sort*, and*paginate*  to return zero or more
>>>     resources in a query response.  Queries MAY be made against a single
>>>     resource or a resource type endpoint (e.g., "/Users"), or the service
>>>     provider Base URI.
>>>
>>> Here queries are defined only by filtering, sorting and pagination. 
>>> Attributes are not part of it, which suggests that their usage do 
>>> not fall under the "query" definition.
>>> Now, one could wonder how would a filter/sort/pagination make sense 
>>> on a single resource. I (personally) cannot see any use case. Maybe 
>>> that should be clarified in the RFC, or even removed.
>>>
>>> What is very confusing is that, although not listed in the query 
>>> section "introduction", attributes have their own sub-section 
>>> 3.4.2.5 under the query section. I guess (?) that was done to 
>>> explicitly specify that attributes can be used on queries as well 
>>> (and not only on basic operations). In that case, it would maybe be 
>>> better to either:
>>> - explicitly specify in the 3.4.2.5 subsection that attributes can 
>>> be /used/ with/on queries, but do not define a query by themselves
>>> - remove the 3.4.2.5 subsection and (more explicitly) specify in the 
>>> 3.9 section that attributes can be used on queries
>>>
>>> Anyway, I think things are clearer now? Do you agree with those 
>>> affirmations?
>>> - attributes do not imply a query but can be used on queries
>>> - only filtering, sorting and pagination define a query
>>> - GET /Users/abcd?attributes=userName *is not* a query and do not 
>>> require a ListResponse response
>>> - GET /Users/abcd?filter=userName eq "Blah" *is* a query (which make 
>>> little sense, but still) and requires a ListResponse response
>>> - GET /Users?filter=userName eq "Blah" *is* a query and requires a 
>>> ListResponse response
>>>
>>> Thanks a lot again!
>>> Julien Schneider
>>> Tel: [phone]
>>> Fax: [phone]
>>>
>>> http://www.audriga.com  |http://www.twitter.com/audriga
>>>
>>> --------------------------------------------------------------------------
>>> audriga GmbH |  Alter Schlachthof 57  | 76137 Karlsruhe
>>> Sitz der Gesellschaft: Karlsruhe - Amtsgericht Mannheim - HRB 713034
>>> Geschäftsführer: Dr. Frank Dengler, Dr.-Ing. Hans-Jörg Happel
>>> --------------------------------------------------------------------------
>>> On 07/07/2022 20:42, Phillip Hunt wrote:
>>>> In practical terms, only the presence of a filter defines a query 
>>>> that mandates a ListResponse.  The other time a ListResponse is 
>>>> needed is a GET at the root level (which many don’t permit) or at 
>>>> the Resource folder level.
>>>>
>>>> Attributes/excludedAttributes are listed under both 3.4.2 and 3.9. 
>>>>  In practical terms, the presence of the 
>>>> attributes/ecludedattributes qualifiers does not indicate a 
>>>> ListResponse.  Attributes are simply permitted on any SCIM 
>>>> operation. POST, GET, Query, etc.  A simple GET with Attributes 
>>>> does NOT require ListResponse (unless a filter is present) as per 
>>>> Section 3.9 and shown in the example.
>>>>
>>>> Phillip Hunt
>>>> @independentid
>>>> [e-mail]
>>>>
>>>>
>>>>
>>>>
>>>>> On Jul 7, 2022, at 11:04 AM, Danny Zollner 
>>>>> <[e-mail]> wrote:
>>>>>
>>>>> Hi Phil,
>>>>> I’m attempting to clarify what you’ve said here for both my own 
>>>>> knowledge and others. Anything under a subsection of RFC 7644 
>>>>> 3.4.2 counts as a query. Query endpoints can be /Users/{id}, 
>>>>> /Users, /Groups, and although not explicitly listed - 
>>>>> /AnyOtherResource/{id} as well.
>>>>> Features that fall under the label of queries and therefore 
>>>>> require a ListResponse type response would be:
>>>>> Filtering – i.e.: GET /x?filter=userName eq “blah”
>>>>> Sorting
>>>>> Pagination
>>>>> Attributes – both ?attributes= and ?excludedAttributes=
>>>>> Looking at 3.4.2.1, where the query endpoints are listed, the 
>>>>> following parts of 3.4.2.x make sense and what you’re saying is 
>>>>> apparent. From my own observations, I think there may be hundreds 
>>>>> of implementations out there that implement ?attributes and 
>>>>> ?excludedAttributes without a ListResponse wrapper when the query 
>>>>> URL is a known resource such as GET 
>>>>> /Groups/456?excludedAttributes=members.
>>>>> I think we’re still a while away from attempting major changes to 
>>>>> the protocol and schema RFCs, but in the future I’d be interested 
>>>>> in having a discussion on adding an exception to the ListResponse 
>>>>> requirement for querying known resources. The attributes queries 
>>>>> are a bit different from the others. For filter, sort and paginate 
>>>>> you can only really use them against the root of the server or the 
>>>>> root of a resource (i.e.: /Users) as I understand it. I can’t 
>>>>> think of a scenario where you’d do a filter like GET 
>>>>> /Users/123?filter=userName eq “x” – is there a use case there that 
>>>>> I’m missing? Similarly, I can’t think of scenarios where you’d 
>>>>> sort or paginate results for GET /Users/123.
>>>>> Thanks,
>>>>> Danny
>>>>> *From:*Phillip Hunt <[e-mail]>
>>>>> *Sent:*Thursday, July 7, 2022 12:36 PM
>>>>> *To:*Julien Schneider <[e-mail]>
>>>>> *Cc:*Danny Zollner <[e-mail]>; [e-mail]
>>>>> *Subject:*Re: [scim] [EXTERNAL] Query on a specific known resource
>>>>> Julien,
>>>>> You are not wrong.  All queries regardless of path MUST have a 
>>>>> ListResponse.
>>>>> It may seem logical to make the jump to just returning a single 
>>>>> resource for a query that can only return a single result, but 
>>>>> this is not permitted in the RFC. From a protocol point of view, 
>>>>> allowing skipping ListResponse makes the protocol more complex 
>>>>> because it creates “exceptions” which have to be handled. For 
>>>>> example, what happens if no filter match etc.
>>>>> For the group:  For historical information, the issue is actually 
>>>>> more complex than it seems.   For SCIM queries SCIM’s profile of 
>>>>> HTTP overrides both HTTP GET (retrieves a resource) and HTTP POST 
>>>>> (create a resource) to perform a search function. In the case of 
>>>>> GET, url based filters cause privacy concerns because of the leak 
>>>>> of confidential information in URLs. The GET method does not allow 
>>>>> request bodies. Because of thies, SCIM also supports http POST 
>>>>> queries. The HTTP definition suggests creation a resource.  Dual 
>>>>> purposing these methods for search queries created necessary 
>>>>> complexity. One of the basic rules of thumb is that whenever a 
>>>>> “filter” shows up in a request, the request becomes a SCIM Query 
>>>>> which mandates a ListResponse.
>>>>> I discussed this at length with authors of the HTTP specifications 
>>>>> and worked with Julian Reschke (co-author of HTTP) to submit a 
>>>>> proposal for a HTTP SEARCH method.  This would unburden GET and 
>>>>> POST methods and simplify protocol overall.  Julian indicated to 
>>>>> me at the time of finalizing SCIM (around IETF93), that this issue 
>>>>> comes up frequently for him as one of the HTTP authors.  In the 
>>>>> end, the HTTPbis WG chose not to create a new method because there 
>>>>> is too much water under the bridge.  See: 
>>>>> https://httpwg.org/wg-materials/ietf93/ietf-93-httpbis-search.pdf 
>>>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhttpwg.org%2Fwg-materials%2Fietf93%2Fietf-93-httpbis-search.pdf&data=05%7C01%7CDanny.Zollner%40microsoft.com%7C61a3ef6cefda487b73ef08da603f27f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637928122539415111%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=ahU2tOHPGFEjoaXkz16HWA6W50waT9m5kcYXXIIpRzA%3D&reserved=0>
>>>>> Phillip Hunt
>>>>> @independentid
>>>>> [e-mail]
>>>>>
>>>>>
>>>>>
>>>>>     On Jul 7, 2022, at 12:57 AM, Julien Schneider
>>>>>     <[e-mail]> wrote:
>>>>>     Hi Danny, hi Phillip, hi everyone,
>>>>>
>>>>>     Thanks for your answers. I think the confusing part (for me at
>>>>>     least) is "Queries MAY be made*_against a single resource_*or
>>>>>     a resource type endpoint ......." at the beginning of RFC7644
>>>>>     section 3.4.2., followed by "Responses MUST be identified
>>>>>     using the following URI:
>>>>>     "urn:ietf:params:scim:api:messages:2.0:ListResponse" ".
>>>>>
>>>>>     My interpretation is that "*GET
>>>>>     /Users/2819c223-7f76-453a-919d-413861904646?attributes=userName*"
>>>>>     is a query against a single resource, and should then have a
>>>>>     "ListResponse" response? Where am I wrong here?
>>>>>
>>>>>     Thanks
>>>>>
>>>>>
>>>>>     Julien Schneider
>>>>>
>>>>>     Tel: [phone]
>>>>>
>>>>>     Fax: [phone]
>>>>>
>>>>>     http://www.audriga.com  <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.audriga.com%2F&data=05%7C01%7CDanny.Zollner%40microsoft.com%7C61a3ef6cefda487b73ef08da603f27f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637928122539415111%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=ugCOwiY5EXLH8EfrAacwK9%2FDCGnhMp3Sh7L%2Fo8WQNOA%3D&reserved=0>  |http://www.twitter.com/audriga  <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.twitter.com%2Faudriga&data=05%7C01%7CDanny.Zollner%40microsoft.com%7C61a3ef6cefda487b73ef08da603f27f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637928122539415111%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=e6nmZrdOJiUBA%2F31N1TwKLeeQTuwCVla%2FE4UuOds7AU%3D&reserved=0>
>>>>>
>>>>>     --------------------------------------------------------------------------
>>>>>
>>>>>     audriga GmbH |  Alter Schlachthof 57  | 76137 Karlsruhe
>>>>>
>>>>>     Sitz der Gesellschaft: Karlsruhe - Amtsgericht Mannheim - HRB 713034
>>>>>
>>>>>     Geschäftsführer: Dr. Frank Dengler, Dr.-Ing. Hans-Jörg Happel
>>>>>
>>>>>     --------------------------------------------------------------------------
>>>>>
>>>>>     On 07/07/2022 04:51, Danny Zollner wrote:
>>>>>
>>>>>         Hi Julien,
>>>>>         RFC 7644 section 3.4.2 specifically is talking about
>>>>>         queries. Retrieving or modifying known resources (i.e.:
>>>>>         GET /Users/12345 ) does not require a ListResponse type
>>>>>         response. A query of*GET /Users?filter=displayname
>>>>>         contains “**contoso.com*
>>>>>         <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcontoso.com%2F&data=05%7C01%7CDanny.Zollner%40microsoft.com%7C61a3ef6cefda487b73ef08da603f27f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637928122539415111%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=%2B7DoMHkSX3An6CfG913vNi5zgP%2BAJY28kXSnR%2FgBr80%3D&reserved=0>*”*or*GET
>>>>>         /Users?attributes=userName*would require a ListResponse
>>>>>         type response, as it does not identify a specific resource
>>>>>         in the query URL via ID value (i.e.: “12345” in the
>>>>>         previous example). On the other hand,*GET
>>>>>         /Users/12345?attributes=userName*does not require the
>>>>>         ListResponse type response as it does identify a specific
>>>>>         resource.
>>>>>         To explicitly answer the final question in your email –
>>>>>         the expected response to*GET
>>>>>         /Users/2819c223-7f76-453a-919d-413861904646?attributes=userName*would
>>>>>         be the second example you provided.
>>>>>         Cheers,
>>>>>         Danny Zollner
>>>>>         *From:*scim<[e-mail]>
>>>>>         <mailto:[e-mail]>*On Behalf Of*Julien Schneider
>>>>>         *Sent:*Wednesday, July 6, 2022 3:41 AM
>>>>>         *To:*[e-mail]
>>>>>         *Subject:*[EXTERNAL] [scim] Query on a specific known resource
>>>>>
>>>>>         	
>>>>>         Some people who received this message don't often get
>>>>>         email [e-mail]
>>>>>         <mailto:[e-mail]>.Learn why this is important
>>>>>         <https://aka.ms/LearnAboutSenderIdentification>
>>>>>         	
>>>>>
>>>>>         Hi all,
>>>>>
>>>>>         I have a question about queries performed against a SCIM
>>>>>         resource object (like "/Users/{id}").
>>>>>
>>>>>         The RFC
>>>>>         (https://datatracker.ietf.org/doc/html/rfc7644#section-3.4.2
>>>>>         <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7644%23section-3.4.2&data=05%7C01%7CDanny.Zollner%40microsoft.com%7C61a3ef6cefda487b73ef08da603f27f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637928122539415111%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=jbbn1Y43e0GFmChjRVbpMnTKZEqlB5TzLgiJmhz7ZRY%3D&reserved=0>)
>>>>>         states:
>>>>>
>>>>>         Responses MUST be identified using the following URI:
>>>>>
>>>>>             "urn:ietf:params:scim:api:messages:2.0:ListResponse"
>>>>>
>>>>>
>>>>>         If I understand correctly, that means the "schemas"
>>>>>         parameter of the response to those queries must be set to:
>>>>>
>>>>>         "schemas":["urn:ietf:params:scim:api:messages:2.0:ListResponse"]
>>>>>
>>>>>
>>>>>         While I understand how that applies to queries on a
>>>>>         resource type endpoint (like "/Users") or on the SCIM
>>>>>         server root, I don't understand how that applies to
>>>>>         queries on a specific resource object.
>>>>>         If I understand correctly, queries on a specific resource
>>>>>         object actually are quite identical to "retrieving a known
>>>>>         resource"
>>>>>         (https://datatracker.ietf.org/doc/html/rfc7644#section-3.4.1
>>>>>         <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7644%23section-3.4.1&data=05%7C01%7CDanny.Zollner%40microsoft.com%7C61a3ef6cefda487b73ef08da603f27f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637928122539415111%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=wbOMKvqD9T7hP5OFtruAwY2r26XrKdncriLPSapazGQ%3D&reserved=0>)
>>>>>         which are a GET on a specific resource, like:
>>>>>
>>>>>         GET /Users/2819c223-7f76-453a-919d-413861904646
>>>>>
>>>>>         Responses to those requests should have the "schemas"
>>>>>         parameter set to the resource schema(s):
>>>>>
>>>>>         {
>>>>>
>>>>>               "schemas":["urn:ietf:params:scim:schemas:core:2.0:User"],
>>>>>
>>>>>               "id":"2819c223-7f76-453a-919d-413861904646",
>>>>>
>>>>>         ...
>>>>>
>>>>>         }
>>>>>
>>>>>
>>>>>         Now, how should the response to the following query should
>>>>>         look like? And to what value should the "schemas"
>>>>>         parameter of the response be set?
>>>>>
>>>>>         GET /Users/2819c223-7f76-453a-919d-413861904646?attributes=userName
>>>>>
>>>>>
>>>>>         Should it be:
>>>>>
>>>>>             {
>>>>>
>>>>>               "schemas":["urn:ietf:params:scim:api:messages:2.0:ListResponse"],
>>>>>
>>>>>               "totalResults":1,
>>>>>
>>>>>               "Resources":[
>>>>>
>>>>>                 {
>>>>>
>>>>>                   "id":"2819c223-7f76-453a-919d-413861904646",
>>>>>
>>>>>                   "userName":"bjensen"
>>>>>
>>>>>                 }
>>>>>
>>>>>               ]
>>>>>
>>>>>             }
>>>>>
>>>>>
>>>>>         Or something like:
>>>>>
>>>>>             {
>>>>>
>>>>>               "schemas":["urn:ietf:params:scim:schemas:core:2.0:User"],
>>>>>
>>>>>               "id":"2819c223-7f76-453a-919d-413861904646",
>>>>>
>>>>>               "meta":{
>>>>>
>>>>>                 "resourceType":"User",
>>>>>
>>>>>                 "created":"2011-08-01T18:29:49.793Z",
>>>>>
>>>>>                 "lastModified":"2011-08-01T18:29:49.793Z",
>>>>>
>>>>>                 "location":
>>>>>
>>>>>             "https://example.com/v2/Users/2819c223-7f76-453a-919d-413861904646"  <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fexample.com%2Fv2%2FUsers%2F2819c223-7f76-453a-919d-413861904646&data=05%7C01%7CDanny.Zollner%40microsoft.com%7C61a3ef6cefda487b73ef08da603f27f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637928122539415111%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=1BDZsY%2B1DkxD3t2ZObBwf5UHRZlnoXdE9UFuuBZioS0%3D&reserved=0>,
>>>>>
>>>>>                 "version":"W\/\"f250dd84f0671c3\""
>>>>>
>>>>>               },
>>>>>
>>>>>               "userName":"bjensen"
>>>>>
>>>>>             }
>>>>>
>>>>>
>>>>>         Thanks a lot in advance
>>>>>
>>>>>
>>>>>         -- 
>>>>>
>>>>>         Julien Schneider
>>>>>
>>>>>         Tel: [phone]
>>>>>
>>>>>         Fax: [phone]
>>>>>
>>>>>           
>>>>>
>>>>>         http://www.audriga.com  <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.audriga.com%2F&data=05%7C01%7CDanny.Zollner%40microsoft.com%7C61a3ef6cefda487b73ef08da603f27f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637928122539415111%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=ugCOwiY5EXLH8EfrAacwK9%2FDCGnhMp3Sh7L%2Fo8WQNOA%3D&reserved=0>  |http://www.twitter.com/audriga  <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.twitter.com%2Faudriga&data=05%7C01%7CDanny.Zollner%40microsoft.com%7C61a3ef6cefda487b73ef08da603f27f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637928122539415111%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=e6nmZrdOJiUBA%2F31N1TwKLeeQTuwCVla%2FE4UuOds7AU%3D&reserved=0>
>>>>>
>>>>>           
>>>>>
>>>>>         --------------------------------------------------------------------------
>>>>>
>>>>>         audriga GmbH |  Alter Schlachthof 57  | 76137 Karlsruhe
>>>>>
>>>>>         Sitz der Gesellschaft: Karlsruhe - Amtsgericht Mannheim - HRB 713034
>>>>>
>>>>>         Geschäftsführer: Dr. Frank Dengler, Dr.-Ing. Hans-Jörg Happel
>>>>>
>>>>>         --------------------------------------------------------------------------
>>>>>
>>>>>
>>>>>     _______________________________________________
>>>>>     scim mailing list
>>>>>     [e-mail] <mailto:[e-mail]>
>>>>>     https://www.ietf.org/mailman/listinfo/scim
>>>>>     <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fscim&data=05%7C01%7CDanny.Zollner%40microsoft.com%7C61a3ef6cefda487b73ef08da603f27f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637928122539415111%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=lgmWfvOoa2uTk4zhZ2eC6txKydhzire0Hd85sQ4Ib5Y%3D&reserved=0>
>>>>>
>>>>
>>>
>>