Re: [scim] Root Query & Search Requirements

[Shelley <[e-mail]>]

Thanks.

If I'm understanding correctly, the server root supports two types of
requests:

   - Searching via POST /.search [1]
   - Querying via GET / [2]

Questions:

   - The root server endpoint is not defined as a well-known endpoint in
   Section 3.2 [3]. Given that general purpose querying (not just searching)
   seems to be supported on this endpoint, should it be defined in this
   section?
   - Are SCIM service providers REQUIRED to support querying and/or
   searching on the root server endpoint? Ticket #42 [4] provided text and an
   SP configuration attribute that more clearly indicated that support for
   this was OPTIONAL, but this was omitted from the final spec. Does this mean
   SPs MUST support querying/searching at the server root?

[1] https://tools.ietf.org/html/rfc7644#section-3.4.3
[2] https://tools.ietf.org/html/rfc7644#section-3.4.2
[3] https://tools.ietf.org/html/rfc7644#section-3.2
[4] https://trac.ietf.org/trac/scim/ticket/42

On Sat, Feb 29, 2020 at 11:05 AM Phillip Hunt <[e-mail]>
wrote:

> 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
> [e-mail]
>
>
>
> On Feb 26, 2020, at 11:47 AM, Shelley <[e-mail]> 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
> [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/
> _______________________________________________
> scim mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/scim
>
>
>