Subject: [scim] Root Query & Search Requirements

From: Shelley <[email-masked]>
Date: Wed, 26 Feb 2020 12:47:07 -0600

The server root is not defined as a supported endpoint [1] for querying
(GET), yet the inline text for the Query Resources section [2] implies that
it is a required endpoint responsible for returning all resource types:

*> Queries MAY be performed against a SCIM resource object, a resource type
> endpoint, or a SCIM server root.*
>

*> A query against a server root indicates that all resources within the
> server SHALL be included, subject to filtering...*
>

*> When processing query operations using endpoints that include more than
> one SCIM resource type (e.g., a query from the server root endpoint)...*
>

Similarly, searching (POST) [3] seems to assume that the search is attached
to a valid SCIM endpoint, although the root is not clearly defined as such:

* > The inclusion of "/.search" on the end of a valid SCIM endpoint...*

I found some old tickets/discussions [4,5,6] that proposed making these
requirements more clear in the RFC text and service provider configuration,
but that clarity doesn't appear to have made its way into the final RFCs.

Can someone provide some clarity on whether the server root must be a
supported SCIM endpoint responsible for returning all resources (subject to
standard filtering) and/or if it must support the .search capability?

Our SCIM implementation does not currently have any use cases that would
benefit from querying/searching across resource types, any I would prefer
to add any custom support there unless it becomes necessary (i.e. just
return a basic 404 response for any requests to the server root as an
unknown/unsupported resource).

[1] https://tools.ietf.org/html/rfc7644#section-3.2
[2] https://tools.ietf.org/html/rfc7644#section-3.4.2
[3] https://tools.ietf.org/html/rfc7644#section-3.4.3
[4] https://trac.ietf.org/trac/scim/ticket/42
[5] https://mailarchive.ietf.org/arch/msg/scim/WOT40hJ9t5RB1vEnwGoePWW18dI/
[6] https://mailarchive.ietf.org/arch/msg/scim/MXu6yJ3TxYTm566hW99TGTpvoZg/

---

From: Phillip Hunt <[email-masked]>
Date: Sat, 29 Feb 2020 10:05:28 -0700

Shelley,

Section 3.4.2.1 of RFC7644 states that the server root is a valid search endpoint. 

The root is not and endpoint for the purpose of holding resources. It only holds the resource type containers (which each define their own endpoint) and which in turn contain resources 

The use case for querying from the root came from implementers who were using SCIM in a directory lookup style of functionality and performing search while typing type of functionality. In these cases the scim client does not know what type of resource the user wants and wants to be able to return all resource types, or a specific set of types (like Users and Groups).

Phil Hunt
@independentid
[email-masked]

> On Feb 26, 2020, at 11:47 AM, Shelley <[email-masked]> wrote:
> 
> The server root is not defined as a supported endpoint [1] for querying (GET), yet the inline text for the Query Resources section [2] implies that it is a required endpoint responsible for returning all resource types:
> 
> > Queries MAY be performed against a SCIM resource object, a resource type endpoint, or a SCIM server root.
> 
> > A query against a server root indicates that all resources within the server SHALL be included, subject to filtering....
> 
> > When processing query operations using endpoints that include more than one SCIM resource type (e.g., a query from the server root endpoint)...
> 
> Similarly, searching (POST) [3] seems to assume that the search is attached to a valid SCIM endpoint, although the root is not clearly defined as such:
> 
> > The inclusion of "/.search" on the end of a valid SCIM endpoint...
> 
> I found some old tickets/discussions [4,5,6] that proposed making these requirements more clear in the RFC text and service provider configuration, but that clarity doesn't appear to have made its way into the final RFCs.
> 
> Can someone provide some clarity on whether the server root must be a supported SCIM endpoint responsible for returning all resources (subject to standard filtering) and/or if it must support the .search capability?
> 
> Our SCIM implementation does not currently have any use cases that would benefit from querying/searching across resource types, any I would prefer to add any custom support there unless it becomes necessary (i.e. just return a basic 404 response for any requests to the server root as an unknown/unsupported resource).
> 
> [1] https://tools.ietf.org/html/rfc7644#section-3.2 <https://tools.ietf.org/html/rfc7644#section-3.2>
> [2] https://tools.ietf.org/html/rfc7644#section-3.4.2 <https://tools.ietf.org/html/rfc7644#section-3.4.2>
> [3] https://tools.ietf.org/html/rfc7644#section-3.4.3 <https://tools.ietf.org/html/rfc7644#section-3.4.3>
> [4] https://trac.ietf.org/trac/scim/ticket/42 <https://trac.ietf.org/trac/scim/ticket/42>
> [5] https://mailarchive.ietf.org/arch/msg/scim/WOT40hJ9t5RB1vEnwGoePWW18dI/ <https://mailarchive.ietf.org/arch/msg/scim/WOT40hJ9t5RB1vEnwGoePWW18dI/>
> [6] https://mailarchive.ietf.org/arch/msg/scim/MXu6yJ3TxYTm566hW99TGTpvoZg/ <https://mailarchive.ietf.org/arch/msg/scim/MXu6yJ3TxYTm566hW99TGTpvoZg/>_______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim