4. Service Provider Configuration = Endpoints SCIM 2 defines 3 endpoints to facilitate discovery of SCIM service provider features and schema that MAY be retrieved using HTTP GET: /ServiceProviderConfig An HTTP GET to this endpoint will return a JSON structure that describes the SCIM specification features available on a service provider. This endpoint SHALL return responses with a JSON object using a "schemas" attribute of "urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig". The attributes returned in the JSON object are defined in Section 5 [I-D.ietf-scim-core-schema]. An example representation of SCIM Service Provider configuration may be found in Section 8.5 [I-D.ietf-scim-core-schema]. /Schemas An HTTP GET to this endpoint is used to retrieve information about resource schemas supported by a SCIM Service Provider. An HTTP GET to the endpoint "/Schemas" SHALL return all supported schemas in ListResponse format (see Figure 3). Individual schema definitions can be returned by appending the schema URI to the schemas endpoint. For example: /Schemas/urn:ietf:params:scim:schemas:core:2.0:User The contents of each schema returned is described in Section 7 [I-D.ietf-scim-core-schema]. An example representation of SCIM schemas may be found in Section 8.7 [I-D.ietf-scim-core-schema]. /ResourceTypes An HTTP GET to this endpoint is used to discover the types of resources available on a SCIM Service Provider (e.g. Users and Groups). Each resource type defines the endpoints, the core schema URI that defines the resource, and any supported schema extensions. The attributes defining a resource type can be found in Section 6 [I-D.ietf-scim-core-schema], and an example representation can be found in Section 8.6 [I-D.ietf-scim-core-schema]. In cases where a request is for a specific "ResourceType" or "Schema", the single JSON object is returned in the same way a single User or Group is retrieved as per Section 3.2.1. When returning multiple ResourceTypes or Schemas, the message form described by "urn:ietf:params:scim:api:messages:2.0:ListResponse" (ListResponse) form SHALL be used as shown in Figure 3 and Figure 9 below. Query parameters described in section 3.2 such as, sorting, attributes, and paging SHALL be ignored. If a "filter" is provided, the service provider SHOULD respond with HTTP Status 403 (FORBIDDEN) to ensure clients cannot incorrectly assume any matching conditions specified in a filter are true. The following is a non-normative example of an HTTP GET to the /ResourceTypes endpoint: { "totalResults":2, "itemsPerPage":10, "startIndex":1, "schemas":["urn:ietf:params:scim:api:messages:2.0:ListResponse"], "Resources":[{ "schemas": ["urn:ietf:params:scim:schemas:core:2.0:ResourceType"], "id":"User", "name":"User", "endpoint": "/Users", "description": "User Account", "schema": "urn:ietf:params:scim:schemas:core:2.0:User", "schemaExtensions": [{ "schema": "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User", "required": true }], "meta": { "location":"https://example.com/v2/ResourceTypes/User", "resourceType": "ResourceType" } }, { "schemas": ["urn:ietf:params:scim:schemas:core:2.0:ResourceType"], "id":"Group", "name":"Group", "endpoint": "/Groups", "description": "Group", "schema": "urn:ietf:params:scim:schemas:core:2.0:Group", "meta": { "location":"https://example.com/v2/ResourceTypes/Group", "resourceType": "ResourceType" } }] } Figure 9: Example Resource Type JSON Representation

It has been pointed out that the core-schema = and api drafts are in slight conflict regarding the definition of = Complex = attributes.

In the = API draft, we had filter ABNF that supports nested complex attributes = enabling a search filter of:

ABNF:

 FILTER    =3D =
attrExp / logExp / valuePath / *1"not" "(" FILTER ")"

 valuePath =3D attrPath "[" FILTER "]"

Nested complex attribute filter = example:

filter=3Daddresses[state eq "CA" and rooms[type eq "bedroom" =
and
  number gt 2]]

Yet the core-schema draft = defines a complex attribute as containing only simple = attributes:

Complex Attribute
      A singular or multi-valued attribute whose value is a composition
      of one or more simple =
attributes; e.g. "addresses".

PROPOSED CORECTION:

Since nobody appears to be = using this feature and no core schema is defined with nested complex = attributes, the api draft will be amended to change the ABNF to not = allow nested valuePath elements and to remove the above filter example = from the text.

New ABNF:

 FILTER    =3D attrExp / logExp / =
valuePath / *1"not(" FILTER ")"
 valFilter =3D attrExp / logExp / *1"not(" valFilter ")"
 valuePath =3D attrPath "[" valFilter "]"

If possible please provide = any objections or comments to this correction by Tuesday.

Regards,

Phil

@independentid

www.independentid.com

phil.hunt@oracle.com

= --Apple-Mail=_1BC0A318-7C89-4937-8EC4-385E71B936FC-- From nobody Mon Dec 15 06:57:15 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 213CA1A6F5B for ; Mon, 15 Dec 2014 06:57:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.079 X-Spam-Level: X-Spam-Status: No, score=-0.079 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWWvFbG_ikDp for ; Mon, 15 Dec 2014 06:57:09 -0800 (PST) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0274C1A3BA7 for ; Mon, 15 Dec 2014 06:57:08 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id x13so14796821wgg.5 for ; Mon, 15 Dec 2014 06:57:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=bGgbkC4PB3IvBiQp6ZPhVuxIJEncM949XyVT9Wh43lg=; b=HlXoBNZFNyoMkBvW1OoKf32UqZHB906b2bn7WXKBVzQdwogj5kfDS6WZBVqNCTu+qB meWP1fgxCAAk3ONRy9uZ481REnQXle9mLvAcAVEia/rm5UHoq2JmhZK496wxOTOf+QTr o9HO+ldaRFJbqtD936NhPzLZrOecLOtQqi/oDbOYotnijuDIn1pbBZr99rUUlugwcPUp 8ul4U9icn2NSFiwORNWV/rfavt5NtfZiPPkMV/tofBd+2PT7Oo4jQfDMkp9cKCuTNn6m R5a3Aisy2Ni7bz+5mQUdpyL/AqdFiCpl5d6p9qxyTRJ1bQTcxBrTIYAtGNA3hFOAnW0y 4Ujg== X-Gm-Message-State: ALoCoQnDcyS38JDQSOC1ZYrVde5bV6WHNsKYLtyizi0cogPwjigMhUTqAxKAJoAZ3nn76flgyWxM X-Received: by 10.180.76.201 with SMTP id m9mr31760050wiw.52.1418655427416; Mon, 15 Dec 2014 06:57:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.217.123.70 with HTTP; Mon, 15 Dec 2014 06:56:46 -0800 (PST) In-Reply-To: <7AFB51E4-10FB-4530-BAE5-2E068C9AFEB2@oracle.com> References: <53AB4DD1-D4AB-4D17-9BD6-22F4DEF4DDDA@oracle.com> <7AFB51E4-10FB-4530-BAE5-2E068C9AFEB2@oracle.com> From: Ian Glazer Date: Mon, 15 Dec 2014 09:56:46 -0500 Message-ID: To: Phil Hunt Content-Type: multipart/alternative; boundary=f46d043c08b6cf6a69050a427409 Archived-At: http://mailarchive.ietf.org/arch/msg/scim/R262n5KPcgjT_7hz5_AC0Dr9VO8 Cc: SCIM WG Subject: Re: [scim] Clarification to Response formats for ServiceProviderConfig, ResourceTypes, and Schemas X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 14:57:13 -0000 --f46d043c08b6cf6a69050a427409 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Phil - Just to be perfectly clear this clarification on the /ResourceTypes endpoint means GETs will either get all of the Resource Types or just one and that's it. Correct? On Fri, Dec 12, 2014 at 11:08 AM, Phil Hunt wrote: > > > It has come to my attention that the configuration endpoints may be > somewhat under-defined and may lead to inconsistent implementation. Durin= g > Wednesday's working group call, we discussed a clarification that should > not impact most implementations with normative changes and focused on a > clarifying solution. Accordingly, I=E2=80=99ve written up a new section f= or the > SCIM API specification that defines the Service provider config endpoints= . > > Of special note, we also discussed query support in these endpoints. We > wanted to avoid the complex situation of a client having to discover what > configuration discovery features are available (configuration for the > configuration? where does it end?). Tto keep things simple, we decided > either all servers must support configuration queries or none of them > should. Given that query is optional for SCIM resources, we decided that > the configuration endpoints should not support query for all servers. In > the text below, I am proposing that most query parameters (attributes, > startIndex, etc) are ignored and use of query filters should return HTTP > status 403 (FORBIDDEN) to indicate the feature is not supported. > > I will revise the drafts on Tuesday. Please voice any objections or > concerns to the list as soon as possible. > > PROPOSED TEXT: > > 4. Service Provider Configuration Endpoints > > SCIM 2 defines 3 endpoints to facilitate discovery of SCIM service > provider features and schema that MAY be retrieved using HTTP GET: > > /ServiceProviderConfig > An HTTP GET to this endpoint will return a JSON structure that > describes the SCIM specification features available on a service > provider. This endpoint SHALL return responses with a JSON object > using a "schemas" attribute of > "urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig". > The attributes returned in the JSON object are defined in > Section 5 [I-D.ietf-scim-core-schema]. An example representation > of SCIM Service Provider configuration may be found in Section 8.5 > [I-D.ietf-scim-core-schema]. > > /Schemas > An HTTP GET to this endpoint is used to retrieve information about > resource schemas supported by a SCIM Service Provider. An HTTP > GET to the endpoint "/Schemas" SHALL return all supported schemas > in ListResponse format (see Figure 3). Individual schema > definitions can be returned by appending the schema URI to the > schemas endpoint. For example: > > /Schemas/urn:ietf:params:scim:schemas:core:2.0:User > > The contents of each schema returned is described in Section 7 > [I-D.ietf-scim-core-schema]. An example representation of SCIM > schemas may be found in Section 8.7 [I-D.ietf-scim-core-schema]. > > /ResourceTypes > An HTTP GET to this endpoint is used to discover the types of > resources available on a SCIM Service Provider (e.g. Users and > Groups). Each resource type defines the endpoints, the core > schema URI that defines the resource, and any supported schema > extensions. The attributes defining a resource type can be found > in Section 6 [I-D.ietf-scim-core-schema], and an example > representation can be found in Section 8.6 > [I-D.ietf-scim-core-schema]. > > In cases where a request is for a specific "ResourceType" or > "Schema", the single JSON object is returned in the same way a single > User or Group is retrieved as per Section 3.2.1. When returning > multiple ResourceTypes or Schemas, the message form described by > "urn:ietf:params:scim:api:messages:2.0:ListResponse" (ListResponse) > form SHALL be used as shown in Figure 3 and Figure 9 below. Query > parameters described in section 3.2 such as, sorting, attributes, and > paging SHALL be ignored. If a "filter" is provided, the service > provider SHOULD respond with HTTP Status 403 (FORBIDDEN) to ensure > clients cannot incorrectly assume any matching conditions specified > in a filter are true. > > The following is a non-normative example of an HTTP GET to the > /ResourceTypes endpoint: > > { > "totalResults":2, > "itemsPerPage":10, > "startIndex":1, > "schemas":["urn:ietf:params:scim:api:messages:2.0:ListResponse"], > "Resources":[{ > "schemas": ["urn:ietf:params:scim:schemas:core:2.0:ResourceType"], > "id":"User", > "name":"User", > "endpoint": "/Users", > "description": "User Account", > "schema": "urn:ietf:params:scim:schemas:core:2.0:User", > "schemaExtensions": [{ > "schema": > "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User", > "required": true > }], > "meta": { > "location":"https://example.com/v2/ResourceTypes/User", > "resourceType": "ResourceType" > } > }, > { > "schemas": ["urn:ietf:params:scim:schemas:core:2.0:ResourceType"], > "id":"Group", > "name":"Group", > "endpoint": "/Groups", > "description": "Group", > "schema": "urn:ietf:params:scim:schemas:core:2.0:Group", > "meta": { > "location":"https://example.com/v2/ResourceTypes/Group", > "resourceType": "ResourceType" > } > }] > } > > Figure 9: Example Resource Type JSON Representation > > > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > --=20 Ian Glazer Senior Director, Identity +1 202 255 3166 @iglazer --f46d043c08b6cf6a69050a427409 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Phil -=C2=A0

Just to be perfectly clear= this clarification on the /ResourceTypes endpoint means GETs will either g= et all of the Resource Types or just one and that's it. Correct?

<= /div>

On Fri, Dec = 12, 2014 at 11:08 AM, Phil Hunt <phil.hunt@oracle.com> wr= ote:

It has come to my attention that t= he configuration endpoints may be somewhat under-defined and may lead to in= consistent implementation. During Wednesday's working group call, we di= scussed a clarification that should not impact most implementations with no= rmative changes and focused on a clarifying solution. Accordingly, I=E2=80= =99ve written up a new section for the SCIM API specification that defines = the Service provider config endpoints.

Of special note, = we also discussed query support in these endpoints. We wanted to avoid the = complex situation of a client having to discover what configuration discove= ry features are available (configuration for the configuration? where does = it end?). Tto keep things simple, we decided either all servers must suppor= t configuration queries or none of them should.=C2=A0 Given that query is o= ptional for SCIM resources, we decided that the configuration endpoints sho= uld not support query for all servers.=C2=A0 In the text below, I am propos= ing that most query parameters (attributes, startIndex, etc) are ignored an= d use of query filters should return HTTP status 403 (FORBIDDEN) to indicat= e the feature is not supported.

I will revise the = drafts on Tuesday. Please voice any objections or concerns to the list as s= oon as possible.

PROPOSED TEXT:
4. Service Provider = Configuration Endpoints SCIM 2 defines 3 endpoints to facilitate discovery of SCIM service provider features and schema that MAY be retrieved using HTTP GET: /ServiceProviderConfig An HTTP GET to this endpoint will return a JSON structure that describes the SCIM specification features available on a service provider. This endpoint SHALL return responses with a JSON object using a "schemas" attribute of "urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig&quo= t;. The attributes returned in the JSON object are defined in Section 5 [I-D.ietf-scim-core-schema]. An example representation of SCIM Service Provider configuration may be found in Section 8.5 [I-D.ietf-scim-core-schema]. /Schemas An HTTP GET to this endpoint is used to retrieve information about resource schemas supported by a SCIM Service Provider. An HTTP GET to the endpoint "/Schemas" SHALL return all supported s= chemas in ListResponse format (see Figure 3). Individual schema definitions can be returned by appending the schema URI to the schemas endpoint. For example: /Schemas/urn:ietf:params:scim:schemas:core:2.0:User The contents of each schema returned is described in Section 7 [I-D.ietf-scim-core-schema]. An example representation of SCIM schemas may be found in Section 8.7 [I-D.ietf-scim-core-schema]. /ResourceTypes An HTTP GET to this endpoint is used to discover the types of resources available on a SCIM Service Provider (e.g. Users and Groups). Each resource type defines the endpoints, the core schema URI that defines the resource, and any supported schema extensions. The attributes defining a resource type can be found in Section 6 [I-D.ietf-scim-core-schema], and an example representation can be found in Section 8.6 [I-D.ietf-scim-core-schema]. In cases where a request is for a specific "ResourceType" or "Schema", the single JSON object is returned in the same way a= single User or Group is retrieved as per Section 3.2.1. When returning multiple ResourceTypes or Schemas, the message form described by "urn:ietf:params:scim:api:messages:2.0:ListResponse" (ListResp= onse) form SHALL be used as shown in Figure 3 and Figure 9 below. Query parameters described in section 3.2 such as, sorting, attributes, and paging SHALL be ignored. If a "filter" is provided, the servi= ce provider SHOULD respond with HTTP Status 403 (FORBIDDEN) to ensure clients cannot incorrectly assume any matching conditions specified in a filter are true. The following is a non-normative example of an HTTP GET to the /ResourceTypes endpoint: { "totalResults":2, "itemsPerPage":10, "startIndex":1, "schemas":["urn:ietf:params:scim:api:messages:2.0:ListRe= sponse"], "Resources":[{ "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Res= ourceType"], "id":"User", "name":"User", "endpoint": "/Users", "description": "User Account", "schema": "urn:ietf:params:scim:schemas:core:2.0:User&= quot;, "schemaExtensions": [{ "schema": "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User&= quot;, "required": true }], "meta": { "location":"https://example.com/v2/ResourceTypes/User", "resourceType": "ResourceType" } }, { "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Reso= urceType"], "id":"Group", "name":"Group", "endpoint": "/Groups", "description": "Group", "schema": "urn:ietf:params:scim:schemas:core:2.0:Group&= quot;, "meta": { "location":"https://example.com/v2/ResourceTypes/Group<= /a>", "resourceType": "ResourceType" } }] } Figure 9: Example Resource Type JSON Representation

=
=
Phil

@independentid
www.independentid.com
phi= l.hunt@oracle.com

_________________________________= ______________
scim mailing list
scim@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/scim

Ian Glazer

Senior = Director, Identity

+1 202 255 3166

@iglazer

--f46d043c08b6cf6a69050a427409-- From nobody Mon Dec 15 09:46:26 2014 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9593B1A8720 for ; Mon, 15 Dec 2014 09:46:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6PtsiCtdbqBD for ; Mon, 15 Dec 2014 09:46:22 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E787C1A8716 for ; Mon, 15 Dec 2014 09:46:21 -0800 (PST) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sBFHkKwU011220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 15 Dec 2014 17:46:21 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id sBFHkKaZ029912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 15 Dec 2014 17:46:20 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sBFHkJc8019597; Mon, 15 Dec 2014 17:46:20 GMT Received: from [10.0.1.3] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 15 Dec 2014 09:46:18 -0800 References: <53AB4DD1-D4AB-4D17-9BD6-22F4DEF4DDDA@oracle.com> <7AFB51E4-10FB-4530-BAE5-2E068C9AFEB2@oracle.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-5A2367F7-2467-42BE-8B07-73187970BC13 Content-Transfer-Encoding: 7bit Message-Id: <3B47BF17-0A91-4F2A-B7D5-126257B2148E@oracle.com> X-Mailer: iPhone Mail (12B435) From: Phil Hunt Date: Mon, 15 Dec 2014 09:46:11 -0800 To: Ian Glazer X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/scim/Y5venuafEMdJfh_HnM0tRy52Hyk Cc: SCIM WG Subject: Re: [scim] Clarification to Response formats for ServiceProviderConfig, ResourceTypes, and Schemas X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 17:46:24 -0000 --Apple-Mail-5A2367F7-2467-42BE-8B07-73187970BC13 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yes.=20 /ResourceTypes/{name} Returns a single /ResourceTypes Returns all.=20 Phil > On Dec 15, 2014, at 06:56, Ian Glazer wrote: >=20 > Phil -=20 >=20 > Just to be perfectly clear this clarification on the /ResourceTypes endpoi= nt means GETs will either get all of the Resource Types or just one and that= 's it. Correct? >=20 >> On Fri, Dec 12, 2014 at 11:08 AM, Phil Hunt wrote:= >>=20 >> It has come to my attention that the configuration endpoints may be somew= hat under-defined and may lead to inconsistent implementation. During Wednes= day's working group call, we discussed a clarification that should not impac= t most implementations with normative changes and focused on a clarifying so= lution. Accordingly, I=E2=80=99ve written up a new section for the SCIM API s= pecification that defines the Service provider config endpoints. >>=20 >> Of special note, we also discussed query support in these endpoints. We w= anted to avoid the complex situation of a client having to discover what con= figuration discovery features are available (configuration for the configura= tion? where does it end?). Tto keep things simple, we decided either all ser= vers must support configuration queries or none of them should. Given that q= uery is optional for SCIM resources, we decided that the configuration endpo= ints should not support query for all servers. In the text below, I am prop= osing that most query parameters (attributes, startIndex, etc) are ignored a= nd use of query filters should return HTTP status 403 (FORBIDDEN) to indicat= e the feature is not supported. >>=20 >> I will revise the drafts on Tuesday. Please voice any objections or conce= rns to the list as soon as possible. >>=20 >> PROPOSED TEXT: >> 4. Service Provider Configuration Endpoints >>=20 >> SCIM 2 defines 3 endpoints to facilitate discovery of SCIM service >> provider features and schema that MAY be retrieved using HTTP GET: >>=20 >> /ServiceProviderConfig >> An HTTP GET to this endpoint will return a JSON structure that >> describes the SCIM specification features available on a service >> provider. This endpoint SHALL return responses with a JSON object >> using a "schemas" attribute of >> "urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig". >> The attributes returned in the JSON object are defined in >> Section 5 [I-D.ietf-scim-core-schema]. An example representation >> of SCIM Service Provider configuration may be found in Section 8.5 >> [I-D.ietf-scim-core-schema]. >>=20 >> /Schemas >> An HTTP GET to this endpoint is used to retrieve information about >> resource schemas supported by a SCIM Service Provider. An HTTP >> GET to the endpoint "/Schemas" SHALL return all supported schemas >> in ListResponse format (see Figure 3). Individual schema >> definitions can be returned by appending the schema URI to the >> schemas endpoint. For example: >>=20 >> /Schemas/urn:ietf:params:scim:schemas:core:2.0:User >>=20 >> The contents of each schema returned is described in Section 7 >> [I-D.ietf-scim-core-schema]. An example representation of SCIM >> schemas may be found in Section 8.7 [I-D.ietf-scim-core-schema]. >>=20 >> /ResourceTypes >> An HTTP GET to this endpoint is used to discover the types of >> resources available on a SCIM Service Provider (e.g. Users and >> Groups). Each resource type defines the endpoints, the core >> schema URI that defines the resource, and any supported schema >> extensions. The attributes defining a resource type can be found >> in Section 6 [I-D.ietf-scim-core-schema], and an example >> representation can be found in Section 8.6 >> [I-D.ietf-scim-core-schema]. >>=20 >> In cases where a request is for a specific "ResourceType" or >> "Schema", the single JSON object is returned in the same way a single >> User or Group is retrieved as per Section 3.2.1. When returning >> multiple ResourceTypes or Schemas, the message form described by >> "urn:ietf:params:scim:api:messages:2.0:ListResponse" (ListResponse) >> form SHALL be used as shown in Figure 3 and Figure 9 below. Query >> parameters described in section 3.2 such as, sorting, attributes, and >> paging SHALL be ignored. If a "filter" is provided, the service >> provider SHOULD respond with HTTP Status 403 (FORBIDDEN) to ensure >> clients cannot incorrectly assume any matching conditions specified >> in a filter are true. >>=20 >> The following is a non-normative example of an HTTP GET to the >> /ResourceTypes endpoint: >>=20 >> { >> "totalResults":2, >> "itemsPerPage":10, >> "startIndex":1, >> "schemas":["urn:ietf:params:scim:api:messages:2.0:ListResponse"], >> "Resources":[{ >> "schemas": ["urn:ietf:params:scim:schemas:core:2.0:ResourceType"], >> "id":"User", >> "name":"User", >> "endpoint": "/Users", >> "description": "User Account", >> "schema": "urn:ietf:params:scim:schemas:core:2.0:User", >> "schemaExtensions": [{ >> "schema": >> "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User", >> "required": true >> }], >> "meta": { >> "location":"https://example.com/v2/ResourceTypes/User", >> "resourceType": "ResourceType" >> } >> }, >> { >> "schemas": ["urn:ietf:params:scim:schemas:core:2.0:ResourceType"], >> "id":"Group", >> "name":"Group", >> "endpoint": "/Groups", >> "description": "Group", >> "schema": "urn:ietf:params:scim:schemas:core:2.0:Group", >> "meta": { >> "location":"https://example.com/v2/ResourceTypes/Group", >> "resourceType": "ResourceType" >> } >> }] >> } >>=20 >> Figure 9: Example Resource Type JSON Representation >>=20 >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 >=20 > --=20 > Ian Glazer > Senior Director, Identity > +1 202 255 3166 > @iglazer > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail-5A2367F7-2467-42BE-8B07-73187970BC13 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Yes.

/R= esourceTypes/{name}

Returns a single

/ResourceTypes

Returns all.

<= div>
Phil

On Dec 15, 2014, at 06:56, Ian Glazer <iglazer@salesforce.com> wrote:
=

Phil -
<= br>
Just to be perfectly clear this clarification on the /Resource= Types endpoint means GETs will either get all of the Resource Types or just o= ne and that's it. Correct?

On Fri, Dec 12, 2014 at 11:08 AM, Phil Hunt <phil.hun= t@oracle.com> wrote:

It has c= ome to my attention that the configuration endpoints may be somewhat under-d= efined and may lead to inconsistent implementation. During Wednesday's worki= ng group call, we discussed a clarification that should not impact most impl= ementations with normative changes and focused on a clarifying solution. Acc= ordingly, I=E2=80=99ve written up a new section for the SCIM API specificati= on that defines the Service provider config endpoints.

Of= special note, we also discussed query support in these endpoints. We wanted= to avoid the complex situation of a client having to discover what configur= ation discovery features are available (configuration for the configuration?= where does it end?). Tto keep things simple, we decided either all servers m= ust support configuration queries or none of them should. Given that q= uery is optional for SCIM resources, we decided that the configuration endpo= ints should not support query for all servers. In the text below, I am= proposing that most query parameters (attributes, startIndex, etc) are igno= red and use of query filters should return HTTP status 403 (FORBIDDEN) to in= dicate the feature is not supported.

I will revise t= he drafts on Tuesday. Please voice any objections or concerns to the list as= soon as possible.

PROPOSED TEXT:
4. Service Provider C= onfiguration Endpoints SCIM 2 defines 3 endpoints to facilitate discovery of SCIM service provider features and schema that MAY be retrieved using HTTP GET: /ServiceProviderConfig An HTTP GET to this endpoint will return a JSON structure that describes the SCIM specification features available on a service provider. This endpoint SHALL return responses with a JSON object using a "schemas" attribute of "urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig". The attributes returned in the JSON object are defined in Section 5 [I-D.ietf-scim-core-schema]. An example representation of SCIM Service Provider configuration may be found in Section 8.5 [I-D.ietf-scim-core-schema]. /Schemas An HTTP GET to this endpoint is used to retrieve information about resource schemas supported by a SCIM Service Provider. An HTTP GET to the endpoint "/Schemas" SHALL return all supported schemas in ListResponse format (see Figure 3). Individual schema definitions can be returned by appending the schema URI to the schemas endpoint. For example: /Schemas/urn:ietf:params:scim:schemas:core:2.0:User The contents of each schema returned is described in Section 7 [I-D.ietf-scim-core-schema]. An example representation of SCIM schemas may be found in Section 8.7 [I-D.ietf-scim-core-schema]. /ResourceTypes An HTTP GET to this endpoint is used to discover the types of resources available on a SCIM Service Provider (e.g. Users and Groups). Each resource type defines the endpoints, the core schema URI that defines the resource, and any supported schema extensions. The attributes defining a resource type can be found in Section 6 [I-D.ietf-scim-core-schema], and an example representation can be found in Section 8.6 [I-D.ietf-scim-core-schema]. In cases where a request is for a specific "ResourceType" or "Schema", the single JSON object is returned in the same way a single User or Group is retrieved as per Section 3.2.1. When returning multiple ResourceTypes or Schemas, the message form described by "urn:ietf:params:scim:api:messages:2.0:ListResponse" (ListResponse) form SHALL be used as shown in Figure 3 and Figure 9 below. Query parameters described in section 3.2 such as, sorting, attributes, and paging SHALL be ignored. If a "filter" is provided, the service provider SHOULD respond with HTTP Status 403 (FORBIDDEN) to ensure clients cannot incorrectly assume any matching conditions specified in a filter are true. The following is a non-normative example of an HTTP GET to the /ResourceTypes endpoint: { "totalResults":2, "itemsPerPage":10, "startIndex":1, "schemas":["urn:ietf:params:scim:api:messages:2.0:ListResponse"], "Resources":[{ "schemas": ["urn:ietf:params:scim:schemas:core:2.0:ResourceType"], "id":"User", "name":"User", "endpoint": "/Users", "description": "User Account", "schema": "urn:ietf:params:scim:schemas:core:2.0:User", "schemaExtensions": [{ "schema": "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User", "required": true }], "meta": { "location":"https://example.com/v2/ResourceTypes/User", "resourceType": "ResourceType" } }, { "schemas": ["urn:ietf:params:scim:schemas:core:2.0:ResourceType"], "id":"Group", "name":"Group", "endpoint": "/Groups", "description": "Group", "schema": "urn:ietf:params:scim:schemas:core:2.0:Group", "meta": { "location":"https://example.com/v2/ResourceTypes/Group", "resourceType": "ResourceType" } }] } Figure 9: Example Resource Type JSON Representation

Phil

<= div>@independentid
www.independentid.com
phil.hunt@oracle.com
=

__________________________________= _____________
scim mailing list
scim@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/scim

Ian Glazer

Senior Dire= ctor, Identity

+1 202 255 3166

@iglazer

4. Service Provider Configuration En= dpoints SCIM 2 defines 3 endpoints to facilitate discovery of SCIM service provider features and schema that MAY be retrieved using HTTP GET: /ServiceProviderConfig An HTTP GET to this endpoint will return a JSON structure that describes the SCIM specification features available on a service provider. This endpoint SHALL return responses with a JSON object using a "schemas" attribute of "urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig&quo= t;. The attributes returned in the JSON object are defined in Section 5 [I-D.ietf-scim-core-schema]. An example representation of SCIM Service Provider configuration may be found in Section 8.5 [I-D.ietf-scim-core-schema]. /Schemas An HTTP GET to this endpoint is used to retrieve information about resource schemas supported by a SCIM Service Provider. An HTTP GET to the endpoint "/Schemas" SHALL return all supported s= chemas in ListResponse format (see Figure 3). Individual schema definitions can be returned by appending the schema URI to the schemas endpoint. For example: /Schemas/urn:ietf:params:scim:schemas:core:2.0:User The contents of each schema returned is described in Section 7 [I-D.ietf-scim-core-schema]. An example representation of SCIM schemas may be found in Section 8.7 [I-D.ietf-scim-core-schema]. /ResourceTypes An HTTP GET to this endpoint is used to discover the types of resources available on a SCIM Service Provider (e.g. Users and Groups). Each resource type defines the endpoints, the core schema URI that defines the resource, and any supported schema extensions. The attributes defining a resource type can be found in Section 6 [I-D.ietf-scim-core-schema], and an example representation can be found in Section 8.6 [I-D.ietf-scim-core-schema]. In cases where a request is for a specific "ResourceType" or "Schema", the single JSON object is returned in the same way a= single User or Group is retrieved as per Section 3.2.1. When returning multiple ResourceTypes or Schemas, the message form described by "urn:ietf:params:scim:api:messages:2.0:ListResponse" (ListResp= onse) form SHALL be used as shown in Figure 3 and Figure 9 below. Query parameters described in section 3.2 such as, sorting, attributes, and paging SHALL be ignored. If a "filter" is provided, the servi= ce provider SHOULD respond with HTTP Status 403 (FORBIDDEN) to ensure clients cannot incorrectly assume any matching conditions specified in a filter are true. The following is a non-normative example of an HTTP GET to the /ResourceTypes endpoint: { "totalResults":2, "itemsPerPage":10, "startIndex":1, "schemas":["urn:ietf:params:scim:api:messages:2.0:ListRe= sponse"], "Resources":[{ "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Res= ourceType"], "id":"User", "name":"User", "endpoint": "/Users", "description": "User Account", "schema": "urn:ietf:params:scim:schemas:core:2.0:User&= quot;, "schemaExtensions": [{ "schema": "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User&= quot;, "required": true }], "meta": { "location":"https://example.com/v2/ResourceTypes/User", "resourceType": "ResourceType" } }, { "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Reso= urceType"], "id":"Group", "name":"Group", "endpoint": "/Groups", "description": "Group", "schema": "urn:ietf:params:scim:schemas:core:2.0:Group&= quot;, "meta": { "location":"https://example.com/v2/ResourceTypes/Group<= /a>", "resourceType": "ResourceType" } }] } Figure 9: Example Resource Type JSON Representation