From nobody Thu Jul 7 11:05:06 2022 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37CEEC15A748 for ; Thu, 7 Jul 2022 11:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.752 X-Spam-Level: X-Spam-Status: No, score=-2.752 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.745, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4uYYrnlMMrv for ; Thu, 7 Jul 2022 11:05:01 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-bl2nam06on2111.outbound.protection.outlook.com [40.107.65.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A43DC15948B for ; Thu, 7 Jul 2022 11:05:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MrlRYmmv0KmJ6K4Y782pM7KKhzciCQ8nirQZnXMIQBZ7TaFbJZRUOQ86hvzQpnV6qBeLqygzblyHWMJ503WnU71iZ55vg+5Hnuesny8yJryipNKurWnhzWkEeQCWYWE2TlTgSqxo8oqccBoGeObCXFsTTXHyORGrnBjWLYDK1hxbW6NSPZWSOrTxWUb20vCGPzR/ZHDzZ3nw682Efp3eeCswQvkMOB4CANRpAd7ODXmAisB85Q/H5joJa70GgGYR+vzMNKRMa0CIM7WzT7pZB06DdnFgBpH5K2j2u5lvhCyKWSpLW0J5H8t7DnNJKFJrAv0uRK9LnfIMQWYvK+f8fQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=NO0msA4XNmBECYG2FeIrnAbzdQgAkX8OlcfW337nYO8=; b=l8JM4U5Pw9ddMbvMVKS8hDhnV/4eEYk18Sv4b2/xOVqUmA2p1OmHOJhclMRGgy1WnGgOcezvIIYxfKUu7yUTyrdrPx8QI4T4bj9+aDGSy1UHzdndGWy4uIyGVQdZ80JcEqjfghOTiDWyO+kifIdKEPmo6uJxAeXJuLeoxNMF5EnDVA5BA1LNTcqax2teAyHFbDQl67ZMEtgaKAWJzFWGsfNfFb8x9gL/FXT6m9NioC4Hj9gxdCsMXXuvPhGE1/rqqku4+oCSC7BFnkqdCLhpQtPGOtMwmzT6DPbYKaLZoFgpSwnYyaxC1yVtScrREVUXoX5bMorOvQGMwWGiD8Qs1A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NO0msA4XNmBECYG2FeIrnAbzdQgAkX8OlcfW337nYO8=; b=d8mMA6GywK0FTPk7dFt27px/ym1mFBhi/imtFOkU1TOKH6mcj9Wc11BCza/5yVIxxOj1YNxoDNayfEfSiLtEkrMoHV0/SpGPKoUeeVP3fftAyCG0dBVevsRYwMU0QFdPdZS6/4VbQprhzYGK+lhTQHtiUFizHH56UHoH4fyGtqQ= Received: from MN2PR00MB0720.namprd00.prod.outlook.com (2603:10b6:208:1d8::15) by DM6PR00MB0782.namprd00.prod.outlook.com (2603:10b6:5:1be::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5454.0; Thu, 7 Jul 2022 18:04:56 +0000 Received: from MN2PR00MB0720.namprd00.prod.outlook.com ([fe80::b40e:4537:5ae8:2306]) by MN2PR00MB0720.namprd00.prod.outlook.com ([fe80::b40e:4537:5ae8:2306%8]) with mapi id 15.20.5457.000; Thu, 7 Jul 2022 18:04:50 +0000 From: Danny Zollner To: Phillip Hunt , Julien Schneider CC: "scim@ietf.org" Thread-Topic: [scim] [EXTERNAL] Query on a specific known resource Thread-Index: AQHYkdd8kWrSUoMLB0u6CRlCI7heSq1zLFiAgAACqTA= Date: Thu, 7 Jul 2022 18:04:50 +0000 Message-ID: References: <7792b174-48ad-181c-11e1-9adb5ff3bc54@audriga.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2022-07-07T18:04:46Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=d5d030a8-776b-4098-bee3-e82301d6b10f; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=microsoft.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d794c2ad-aa68-4045-8362-08da60432f6a x-ms-traffictypediagnostic: DM6PR00MB0782:EE_ x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: H3ogychQTcU6JyyfzBHpxxfza7vGTa7/fjwYGg8PNkqLuJbIhAkR/NKxGf1uIxba/NrMejgFrDxfOZmUAfbnvgOULgJPVpxhAQQmsxI3E87Rl0mJtFWa9hqTZz/o8FcxsSBqGTU0kfljUjYwrS8IFrTxVJTpWy58oohnuLXsu6qZam/eGkK4S7E4eiBxbGw2YV2Ewk6wSO09x+WTIIk0iC/T8fHnQUzi5AIcXCRClriau0lpXPIljHxbtYLA8fxHMfbuI3hqab/83wa/2lTaoZkmD/eCqNBVBIsIZcEf9rD5FMB/Lys5m8mhDzLGdaItSmwrnoLziE3QHSpaeHQokuVdSSEpXKkZlKJoItp/3EIEEOtw0SCKNA69OTnT7FCug+QChZCPc54gtftSaVNaaZKr3q0c7bKExcMKwJsM68yqv1Qaeu4tna5MCRtFsRPjT2pJ1mV8B2bt7xhYE9oqe+Mn/pJGPvzFFVi4NZS9AzJXaaCbf+6wN5B2mwpTzbhCG3KZ/sCYTPyk02Z9Wfi0i1RHYrKVI9zX+XxzWeTQkTLzrq1DwCS0Q61AHjNIvgEi8wo6i+7YO+DuEgsew2yRwS6QCCLbAD5GJ84FKwgC+VDkM2+bU0sl7H+HSoyfN4vHOGoX7KaukuUhTF4gtAqqlFoYqusWGlZqajwwzt/R4PlTQHIzQY/EKeFoOgNOMgIXzD4tNqIxdEhb3qNf3EHyn6OGITlYhbs4v0QFnJif2AUMuUVTd4IUQer/HYanTE8fOI/kwu3qshgVCV0nziZdJlcI9CH4WH5/Sj9WuBVA089oghOq6mZ3+JD224wJUQUXOZFuojhmsIbNPfmQle5eh/YS45LbL4vKK6S7/i9M5wqYOee922Ahmzr+63ARIU9K20yd7l/1Q7t7x+7hxBHLOJ4Zsxc+kpO9928pwDcoTww= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR00MB0720.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230016)(4636009)(376002)(346002)(136003)(396003)(366004)(39860400002)(451199009)(122000001)(53546011)(82960400001)(86362001)(55016003)(71200400001)(66446008)(66946007)(10290500003)(478600001)(966005)(2906002)(316002)(186003)(66476007)(64756008)(66556008)(76116006)(82950400001)(52536014)(38100700002)(166002)(4326008)(110136005)(6506007)(9326002)(8936002)(83380400001)(66574015)(5660300002)(33656002)(41300700001)(38070700005)(8990500004)(9686003)(7696005)(8676002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?azYVloSrClo5tZ2trHXBJ5trOJH0QVTsvTP3KRb8qFu2F0OUJRg15yVRA8?= =?iso-8859-1?Q?lqnd/Pa3YH1uqWmI5NnpSFMHBBdYDqKlz1hiSSusnjd47RD6MzibRDGruP?= =?iso-8859-1?Q?okqXwuPf6mbZiC9zII/VNrJiYyJSoR7H+nA+by+ocP0YYahE7S71bb84Ht?= =?iso-8859-1?Q?fYodDUDH/JtWFRaGr7U56Btqq5O+y7+nl6rT2WCmAe5q+rPv8ySwKzltM+?= =?iso-8859-1?Q?2i64HUCkbEAVPYKTAg8/L2lvsZCX8AaWtsAO2ozQUEZ60wG2vjczeOjHsS?= =?iso-8859-1?Q?lVf74ERZwZBsM11kOAd8wQd01RdRjQ6LewoNIJLerL1aLoW7t5iDHsieSK?= =?iso-8859-1?Q?5/SyXeDJ/7rz5l+94JDLi/REdWV5M1d1SePhzJuYWJ8R8EKVXbNCqfcrf0?= =?iso-8859-1?Q?AM1tQaQppRPlekcU5soUW08jeCoH2Tna8JuzXkApoU1eYXUQFl41Un7bG4?= =?iso-8859-1?Q?50Y7INaJ8LpZYk3qHLc+GgRCOtAhkQ49+W0pykZFdNhzxVRhsEbX4kuVnY?= =?iso-8859-1?Q?lkXtzSfG3IKhuStOEM7a5IjdXaxBFGJ45w51y5gWW1b3/DAij5u3Bsufpe?= =?iso-8859-1?Q?zbTMsOBpvxGC3mmsqYxvSpHI4hXHNLm/rVgSRxnkEq30KsBBX9AgzlwzPQ?= =?iso-8859-1?Q?pKDU/L7UE9gPI65ELJ0lhwIYfsRjGnIGnPQtfDKppola7FKKdL+SHXkywo?= =?iso-8859-1?Q?64U7rjjdb4HD0YCcmusgRDBbQt8Mj+dX38T79Smr1xtl2Z28qSUZ59dJ2t?= =?iso-8859-1?Q?84Q/ysjXx5bCiULA2MF7XItTOBTyp8pQF2ag/eqDQb+bpSM8f+rCXDNpeh?= =?iso-8859-1?Q?5ImG7z5i4nKhq9jVEwCzxs9Cgax8NULxZS6plo0tVzXudckJEyHi27qEbP?= =?iso-8859-1?Q?+ho3XiHa+52DZuXnZvq7Q/jeHNgTpR+wTSihf/jGbW5Qfhl0EGvOmA9Erq?= =?iso-8859-1?Q?kIfyjkvzrWAJHKgcdfkK7/00UgrZQCORwHEB1LGY/oqNd1227ILe+B3uKC?= =?iso-8859-1?Q?r7VNnNSYVePxJevPeu9b3gn1iC99niGsH/Yxp+7yIbYDdfEHxFFLnGSFwU?= =?iso-8859-1?Q?+fZtQ/fRiZpYiix8bnRjm9nWgV7N/a3DhPLhtrfa4cMkU5xQJI8jot9Ch4?= =?iso-8859-1?Q?EifK/LlZTshDbwDe8Ijs3snPwnqaDnbt7w8HifM0wWtq5KUHPtLLgpV7h0?= =?iso-8859-1?Q?0+4mOsOxcKptLzvEjS0diGjNxlGTBurGBZpTpqfRGFUJwRxKrT4Dk8tisw?= =?iso-8859-1?Q?icZOvpfC0Bvg/gUK9fzG/p/i6c6jdoSPxeJ0cj0Ew/RDcMeI9Yp6x+SisB?= =?iso-8859-1?Q?QXzGmTJRfHtUbFC1Hz/cBS9vOKamy8ADp+dBn8cvhormk9KmpY81jo7YgY?= =?iso-8859-1?Q?XL0/BQSRw6ysRNxVvamYKxI8uAR0S55h6Y1obSY5oATwQBCsGBr5sYBVJX?= =?iso-8859-1?Q?kes9fq1Jnn5mQ956qs8zTYBqBAh7PPgpVku2oAF4mrffBxb0GNH6dcdE9q?= =?iso-8859-1?Q?k0sbuBPgcfqJ9vWNqsdcq1fuxgN29L4DBgb/JExmcJH+z7gIPkjQJw0Ulo?= =?iso-8859-1?Q?EM6XfQO9RkfbgZym4IF0k/eDCva3BiLi4lsfQOevoTJ95XY3lOh4MslY5q?= =?iso-8859-1?Q?ZMytsd2uNjDK473dkFLNqs5YlppdGLsUvIUfPoFGbrCVlFlZT1jcypKgRQ?= =?iso-8859-1?Q?+LsJgAGTn/ucP7hgxXOLpGsLy2GvVPj1iEQGESh9?= Content-Type: multipart/alternative; boundary="_000_MN2PR00MB0720FB58CB201915199826FDFF839MN2PR00MB0720namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR00MB0720.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d794c2ad-aa68-4045-8362-08da60432f6a X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jul 2022 18:04:50.0776 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: yg+cOVeToAyOxbLICoMSa1FquDlJ8W1ngAXKN6x5hMLPXAxJwDpXazvrF23X24UiLfO2up4vJE+hLawQNgGCaA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0782 Archived-At: Subject: Re: [scim] [EXTERNAL] Query on a specific known resource X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2022 18:05:06 -0000 --_000_MN2PR00MB0720FB58CB201915199826FDFF839MN2PR00MB0720namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Phil, I'm attempting to clarify what you've said here for both my own knowledge a= nd 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 expl= icitly listed - /AnyOtherResource/{id} as well. Features that fall under the label of queries and therefore require a ListR= esponse type response would be: Filtering - i.e.: GET /x?filter=3DuserName eq "blah" Sorting Pagination Attributes - both ?attributes=3D and ?excludedAttributes=3D Looking at 3.4.2.1, where the query endpoints are listed, the following par= ts of 3.4.2.x make sense and what you're saying is apparent. From my own ob= servations, I think there may be hundreds of implementations out there that= implement ?attributes and ?excludedAttributes without a ListResponse wrapp= er when the query URL is a known resource such as GET /Groups/456?excludedA= ttributes=3Dmembers. I think we're still a while away from attempting major changes to the proto= col and schema RFCs, but in the future I'd be interested in having a discus= sion on adding an exception to the ListResponse requirement for querying kn= own 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?fi= lter=3DuserName eq "x" - is there a use case there that I'm missing? Simila= rly, I can't think of scenarios where you'd sort or paginate results for GE= T /Users/123. Thanks, Danny From: Phillip Hunt Sent: Thursday, July 7, 2022 12:36 PM To: Julien Schneider Cc: Danny Zollner ; scim@ietf.org 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 fo= r a query that can only return a single result, but this is not permitted i= n the RFC. From a protocol point of view, allowing skipping ListResponse ma= kes 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 comp= lex 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 perfo= rm a search function. In the case of GET, url based filters cause privacy c= oncerns because of the leak of confidential information in URLs. The GET me= thod does not allow request bodies. Because of thies, SCIM also supports ht= tp POST queries. The HTTP definition suggests creation a resource. Dual pu= rposing these methods for search queries created necessary complexity. One = of the basic rules of thumb is that whenever a "filter" shows up in a reque= st, the request becomes a SCIM Query which mandates a ListResponse. I discussed this at length with authors of the HTTP specifications and work= ed 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 proto= col 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 au= thors. 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-mate= rials/ietf93/ietf-93-httpbis-search.pdf Phillip Hunt @independentid phil.hunt@independentid.com On Jul 7, 2022, at 12:57 AM, Julien Schneider > wrote: Hi Danny, hi Phillip, hi everyone, Thanks for your answers. I think the confusing part (for me at least) is "Q= ueries MAY be made against a single resource or a resource type endpoint ..= ....." at the beginning of RFC7644 section 3.4.2., followed by "Responses M= UST be identified using the following URI: "urn:ietf:params:scim:api:messag= es:2.0:ListResponse" ". My interpretation is that "GET /Users/2819c223-7f76-453a-919d-413861904646?= attributes=3DuserName" is a query against a single resource, and should the= n have a "ListResponse" response? Where am I wrong here? Thanks Julien Schneider Tel: +49 721 170293 16 Fax: +49 721 170293 179 http://www.audriga.com | http://www.t= witter.com/audriga -------------------------------------------------------------------------- audriga GmbH | Alter Schlachthof 57 | 76137 Karlsruhe Sitz der Gesellschaft: Karlsruhe - Amtsgericht Mannheim - HRB 713034 Gesch=E4ftsf=FChrer: Dr. Frank Dengler, Dr.-Ing. Hans-J=F6rg 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 Lis= tResponse type response. A query of GET /Users?filter=3Ddisplayname contain= s "contoso.com" or GET /Users?attributes= =3DuserName would require a ListResponse type response, as it does not iden= tify a specific resource in the query URL via ID value (i.e.: "12345" in th= e previous example). On the other hand, GET /Users/12345?attributes=3DuserN= ame does not require the ListResponse type response as it does identify a s= pecific resource. To explicitly answer the final question in your email - the expected respon= se to GET /Users/2819c223-7f76-453a-919d-413861904646?attributes=3DuserName= would be the second example you provided. Cheers, Danny Zollner From: scim On Behalf = Of Julien Schneider Sent: Wednesday, July 6, 2022 3:41 AM To: scim@ietf.org Subject: [EXTERNAL] [scim] Query on a specific known resource Some people who received this message don't often get email from julien@aud= riga.com. Learn why this is important Hi all, I have a question about queries performed against a SCIM resource object (l= ike "/Users/{id}"). The RFC (https://datatracker.ietf.org/doc/html/rfc7644#section-3.4.2) state= s: 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 respon= se 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 app= lies to queries on a specific resource object. If I understand correctly, queries on a specific resource object actually a= re quite identical to "retrieving a known resource" (https://datatracker.ie= tf.org/doc/html/rfc7644#section-3.4.1) which are a GET on a specific resour= ce, 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 t= o what value should the "schemas" parameter of the response be set? GET /Users/2819c223-7f76-453a-919d-413861904646?attributes=3DuserName 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", "version":"W\/\"f250dd84f0671c3\"" }, "userName":"bjensen" } Thanks a lot in advance -- Julien Schneider Tel: +49 721 170293 16 Fax: +49 721 170293 179 http://www.audriga.com | http://www.t= witter.com/audriga -------------------------------------------------------------------------- audriga GmbH | Alter Schlachthof 57 | 76137 Karlsruhe Sitz der Gesellschaft: Karlsruhe - Amtsgericht Mannheim - HRB 713034 Gesch=E4ftsf=FChrer: Dr. Frank Dengler, Dr.-Ing. Hans-J=F6rg Happel -------------------------------------------------------------------------- _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_MN2PR00MB0720FB58CB201915199826FDFF839MN2PR00MB0720namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Phil,

 

I’m attempting to clarify what you’ve sa= id here for both my own knowledge and others. Anything under a subsection o= f RFC 7644 3.4.2 counts as a query. Query endpoints can be /Users/{id}, /Us= ers, /Groups, and although not explicitly listed - /AnyOtherResource/{id} as well.

 

Features that fall under the label of queries and th= erefore require a ListResponse type response would be:

 

Filtering – i.e.: GET /x?filter=3DuserName eq = “blah”

Sorting

Pagination

Attributes – both ?attributes=3D and ?excluded= Attributes=3D

 

Looking at 3.4.2.1, where the query endpoints are li= sted, the following parts of 3.4.2.x make sense and what you’re sayin= g is apparent. From my own observations, I think there may be hundreds of i= mplementations out there that implement ?attributes and ?excludedAttributes without a ListResponse wrapper when th= e query URL is a known resource such as GET /Groups/456?excludedAttributes= =3Dmembers.

 

I think we’re still a while away from attempti= ng 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 ListR= esponse requirement for querying known resources. The attributes queries are a bit different from the others. For filter, so= rt 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=3DuserName eq “x” – is= there a use case there that I’m missing? Similarly, I can’t th= ink of scenarios where you’d sort or paginate results for GET /Users/= 123.

 

Thanks,

 

Danny

 

From: Phillip Hunt <phil.hunt@independenti= d.com>
Sent: Thursday, July 7, 2022 12:36 PM
To: Julien Schneider <julien@audriga.com>
Cc: Danny Zollner <Danny.Zollner@microsoft.com>; scim@ietf.org=
Subject: Re: [scim] [EXTERNAL] Query on a specific known resource

 

Julien,

 

You are not wrong.  All queries regardless of p= ath MUST have a ListResponse.

 

It may seem logical to make the jump to just returni= ng 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 s= kipping 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 bec= ause of the leak of confidential information in URLs. The GET method does n= ot allow request bodies. Because of thies, SCIM also supports http POST que= ries. 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 when= ever a “filter” shows up in a request, the request becomes a SC= IM 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 POS= T 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 t= here is too much water under the bridge.  See: https://httpwg.org/wg-materials/ietf93/ietf-93-httpbis-search.pdf<= /a>

 



On Jul 7, 2022, at 12:57 AM, Julien Schneider <julien@audriga.com> wrote:<= /o:p>

 

Hi Danny, hi Phillip, hi everyone,

Thanks for your answers. I think the confusing part (for me at least) is &q= uot;Queries MAY be made <= b>against a single resource or a resource type endpoint ......." at the beginning of RFC7644 section 3.4.2., followed by "Responses MU= ST be identified using the following URI: "urn:ietf:params:scim:api:me= ssages:2.0:ListResponse" ".

My interpretation is that "GET /Users/2819c223-7f76-453a-919d-41386= 1904646?attributes=3DuserName" is a query against a single resourc= e, and should then have a "ListResponse" response? Where am I wro= ng here?

Thanks


Julien Schneider
Tel: +49 721 170293 16
Fax: +49 721 170293 179
 
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=E4ftsf=FChrer: Dr. Frank Dengler, Dr.-Ing. Hans-J=F6rg 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=3Ddisplayname contains “contoso.com” or GET /Users?attributes=3DuserName&nbs= p;would require a ListResponse type response, as it does not identif= y a specific resource in the query URL via ID value (i.e.: “12345R= 21; in the previous example). On the other hand, GET /Users/12345?attributes=3DuserName&n= bsp;does not require the ListResponse type response as it does i= dentify a specific resource.

 

To explicitly answer the final question in your emai= l – the expected response to&nb= sp;GET /Users/2819c223-7f76-453a-919d-413861904646?attributes=3Du= serNamewould be the second example you provided.

 

Cheers,

 

Danny Zollner

 

From:&n= bsp;scim <scim-bounces@ietf.org> On Behalf Of Julien Schneider
Sent: Wednesday, J= uly 6, 2022 3:41 AM
To: scim@ietf.org
Subject: [EXTERNAL= ] [scim] Query on a specific known resource

 

Some people who received this message don't often get email from julien@audriga.com. Learn why this is important

Hi all,

I have a question about queries performed against a SCIM resource object (l= ike "/Users/{id}").

The RFC (https://datatracker.ietf.org/doc/html/rfc76= 44#section-3.4.2) states: 

Responses MUST be identified using the following URI:
   "urn:ietf:params:scim:api:messages:2.0:ListResponse&=
quot;


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:ListR=
esponse"]


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 ho= w that applies to queries on a specific resource object.
If I understand correctly, queries on a specific resource object actually a= re quite identical to "retrieving a known resource" (https://datatracker.ietf.org/doc/html/rfc7644#section-3.4.1) which are a GET on a specific resource, like:

GET /Users/2819c223-7f76-453a-919d-413861904646

Responses to those requests should have the "sc= hemas" parameter set to the resource schema(s):

{
     "schemas":["urn:ietf:params:sc=
im:schemas:core:2.0:User"],
     "id":"2819c223-7f76-453a-919d-=
413861904646",
...
}


Now, how should the response to the following query should look like? And t= o what value should the "schemas" parameter of the response be se= t?

GET /Users/2819c223-7f76-453a-919d-413861904646?attributes=3DuserName<=
o:p>


Should it be:

   {
     "schemas":["urn:ietf:params:sc=
im:api:messages:2.0:ListResponse"],
     "totalResults":1,
     "Resources":[
       {
         "id":"=
2819c223-7f76-453a-919d-413861904646",
         "userName":=
"bjensen"
       }
     ]
   }


Or something like:

   {
     "schemas":["urn:ietf:params:sc=
im:schemas:core:2.0:User"],
     "id":"2819c223-7f76-453a-919d-=
413861904646",
     "meta":{
       "resourceType":"Us=
er",
       "created":"2011-08=
-01T18:29:49.793Z",
       "lastModified":"20=
11-08-01T18:29:49.793Z",
       "location":<=
/pre>

   "https://example.com/v2=
/Users/2819c223-7f76-453a-919d-413861904646",


       "version":"W\/\&qu=
ot;f250dd84f0671c3\""


     },


     "userName":"bjensen"=



   }






Thanks a lot in advance










-- 


Julien Schneider


Tel: +49 721 170293 16


Fax: +49 721 170293 179


 


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=E4ftsf=FChrer: Dr. Frank Dengler, Dr.-Ing. Hans-J=F6rg Happel


----------------------------------------------------------------------=
----


_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim

 

--_000_MN2PR00MB0720FB58CB201915199826FDFF839MN2PR00MB0720namp_--