From nobody Thu Jul 7 10:36:46 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 3A76FC15A73F for ; Thu, 7 Jul 2022 10:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 (2048-bit key) header.d=independentid-com.20210112.gappssmtp.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 hi1klrMY4fA8 for ; Thu, 7 Jul 2022 10:36:41 -0700 (PDT) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6A35C157B4A for ; Thu, 7 Jul 2022 10:35:59 -0700 (PDT) Received: by mail-pg1-x531.google.com with SMTP id q82so12597196pgq.6 for ; Thu, 07 Jul 2022 10:35:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=independentid-com.20210112.gappssmtp.com; s=20210112; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Nw1f1JvuThEjVRdWAyN0Y+yhVJYZjZRnvjelWbRLDjA=; b=XgeQ1cGi1Hz0F+Yi55hEyCsJz+d2ciEE69mMHWz7qAUb+Y3UOvN1ruKRWbmKBW448+ EuBST03vdjIaXvTbb+rkf1imvm/9/OvzAVmlbH1CAaggvT4sde1zYW3w1nD6wE5I29Pi /5SAr8d4Vd2+54oSmuXO0YfKs2qNLt8g3bIKT3wMhM/clf3rAJxIvgVwCcG4/LLMYg0d b9KDqXPO3175Mad3a2HwFM4CtKeQu6cxbkflzaYbpscNUt1EQxN1auMc6LE3UgGODhog rIJJv5cm3eJ+ZjuEeZpoRaIpSJZIKcABL/X4m4VQp+8WKAkEVzW0HYiGNaTcXiSu1/F9 exkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Nw1f1JvuThEjVRdWAyN0Y+yhVJYZjZRnvjelWbRLDjA=; b=qhOy0TguusnMPqCKQ9VyFQ5MNKfqFN6c39NWl88haYjFMXfusFhcF7C8j50YGtdOrG h7m5HMjBKyTxESusiQVgaYu6j5w44W/3VeFRCsaNn8CpCTZ1PxmdZMbf7cxJrHmQEiYC E9/BNHSgpSHRvo/rPJiUTmNFqNUPKujwEsErfBDJnctk77n9SpK11CUekxW2YKQQ/PuK tS2u6G5yODMLMPFz7fbjTxVb2N8BTKg71nWkk4LfBszUvo/t/tCoNiSDDRMY5lwnEM7C 3TlWG5H6Mghk19l2bRPZqm4Fd4H3GAfWvG0A8pUMVqSAI5CFwoXBDDEqkp9jFmNPkzCB +t5A== X-Gm-Message-State: AJIora8BIIUFQTkqklkj30BauN3V52d6o1nJGIsM+eyygbjgMVLU8XA+ RcofsRigRqGE9MRvQovA6ceeS4R+DUxUUw== X-Google-Smtp-Source: AGRyM1vMRQfWACzFaWr4XVFq16kk/Y2HvA8f4b1HCivlsw/eq7Xi58zECv5GZIt/v61Iles1OmGb9g== X-Received: by 2002:a17:903:1207:b0:16a:7e87:dad3 with SMTP id l7-20020a170903120700b0016a7e87dad3mr53990184plh.99.1657215358857; Thu, 07 Jul 2022 10:35:58 -0700 (PDT) Received: from smtpclient.apple (node-1w7jr9qjhqzxomcnng94hruik.ipv6.telus.net. [2001:569:7316:ae00:75b5:8761:3d20:a43c]) by smtp.gmail.com with ESMTPSA id n8-20020a170902d2c800b0016be593b9e6sm9043295plc.167.2022.07.07.10.35.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Jul 2022 10:35:58 -0700 (PDT) From: Phillip Hunt Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_C1A9D46B-F07A-49A2-B391-48030302D75A" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\)) Date: Thu, 7 Jul 2022 10:35:57 -0700 In-Reply-To: <7792b174-48ad-181c-11e1-9adb5ff3bc54@audriga.com> Cc: Danny Zollner , "scim@ietf.org" To: Julien Schneider References: <7792b174-48ad-181c-11e1-9adb5ff3bc54@audriga.com> X-Mailer: Apple Mail (2.3696.100.31) 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 17:36:45 -0000 --Apple-Mail=_C1A9D46B-F07A-49A2-B391-48030302D75A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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. =46rom a protocol point of view, allowing skipping = ListResponse makes the protocol more complex because it creates = =E2=80=9Cexceptions=E2=80=9D 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=E2=80=99s 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 =E2=80=9Cfilter=E2=80=9D 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 Phillip Hunt @independentid phil.hunt@independentid.com > On Jul 7, 2022, at 12:57 AM, Julien Schneider = wrote: >=20 > Hi Danny, hi Phillip, hi everyone, >=20 > 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" ". >=20 > My interpretation is that "GET = /Users/2819c223-7f76-453a-919d-413861904646?attributes=3DuserName" is a = query against a single resource, and should then have a "ListResponse" = response? Where am I wrong here? >=20 > Thanks >=20 > Julien Schneider > Tel: +49 721 170293 16 > Fax: +49 721 170293 179 >=20 > http://www.audriga.com | = http://www.twitter.com/audriga >=20 > = --------------------------------------------------------------------------= > audriga GmbH | Alter Schlachthof 57 | 76137 Karlsruhe > Sitz der Gesellschaft: Karlsruhe - Amtsgericht Mannheim - HRB 713034 > Gesch=C3=A4ftsf=C3=BChrer: Dr. Frank Dengler, Dr.-Ing. Hans-J=C3=B6rg = Happel > = --------------------------------------------------------------------------= > On 07/07/2022 04:51, Danny Zollner wrote: >> Hi Julien, >> =20 >> 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 =E2=80=9Ccontoso.com=E2=80=9D or = GET /Users?attributes=3DuserName would require a ListResponse type = response, as it does not identify a specific resource in the query URL = via ID value (i.e.: =E2=80=9C12345=E2=80=9D in the previous example). On = the other hand, GET /Users/12345?attributes=3DuserName does not require = the ListResponse type response as it does identify a specific resource. >> =20 >> To explicitly answer the final question in your email =E2=80=93 the = expected response to GET = /Users/2819c223-7f76-453a-919d-413861904646?attributes=3DuserNamewould = be the second example you provided. >> =20 >> Cheers, >> =20 >> Danny Zollner >> =20 >> 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 >> =20 >>=20 >> Some people who received this message don't often get email from = julien@audriga.com . Learn why this is = important =09 >> Hi all, >>=20 >> I have a question about queries performed against a SCIM resource = object (like "/Users/{id}"). >>=20 >> The RFC (https://datatracker.ietf.org/doc/html/rfc7644#section-3.4.2 = ) states:=20 >> Responses MUST be identified using the following URI: >> "urn:ietf:params:scim:api:messages:2.0:ListResponse" >>=20 >> 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"] >>=20 >> 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 = ) 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", >> ... >> } >>=20 >> 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=3DuserName >>=20 >> Should it be: >> { >> = "schemas":["urn:ietf:params:scim:api:messages:2.0:ListResponse"], >> "totalResults":1, >> "Resources":[ >> { >> "id":"2819c223-7f76-453a-919d-413861904646", >> "userName":"bjensen" >> } >> ] >> } >>=20 >> 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" >> } >>=20 >> Thanks a lot in advance >>=20 >> --=20 >> Julien Schneider >> Tel: +49 721 170293 16 >> Fax: +49 721 170293 179 >> =20 >> http://www.audriga.com = | = http://www.twitter.com/audriga = >> =20 >> = --------------------------------------------------------------------------= >> audriga GmbH | Alter Schlachthof 57 | 76137 Karlsruhe >> Sitz der Gesellschaft: Karlsruhe - Amtsgericht Mannheim - HRB 713034 >> Gesch=C3=A4ftsf=C3=BChrer: Dr. Frank Dengler, Dr.-Ing. Hans-J=C3=B6rg = Happel >> = --------------------------------------------------------------------------= >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_C1A9D46B-F07A-49A2-B391-48030302D75A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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. =46rom a protocol point of view, allowing skipping = ListResponse makes the protocol more complex because it creates = =E2=80=9Cexceptions=E2=80=9D 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=E2=80=99s 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 = =E2=80=9Cfilter=E2=80=9D 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.p= df

Phillip Hunt
@independentid




On Jul 7, 2022, at 12:57 AM, Julien Schneider <julien@audriga.com> = 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=3DuserName" is a query against a single = resource, and should then 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.twitter.com/audriga

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

audriga GmbH |  Alter Schlachthof 57  | 76137 Karlsruhe
Sitz der Gesellschaft: Karlsruhe - Amtsgericht Mannheim - HRB 713034
Gesch=C3=A4ftsf=C3=BChrer: Dr. Frank Dengler, Dr.-Ing. Hans-J=C3=B6rg =
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 =E2=80=9Ccontoso.com=E2=80=9D or GET = /Users?attributes=3DuserName would require a = ListResponse type response, as it does not identify a specific resource = in the query URL via ID value (i.e.: =E2=80=9C12345=E2=80=9D in the = previous example). On the other hand, GET = /Users/12345?attributes=3DuserName does not require the = ListResponse type response as it does identify a specific resource.
 
To explicitly answer the = final question in your email =E2=80=93 the expected response to GET = /Users/2819c223-7f76-453a-919d-413861904646?attributes=3DuserNamewould= be the second example you provided.
 
Cheers,
 
Danny Zollner
 
From: scim <scim-bounces@ietf.org> 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@audriga.com. Learn why this is important

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= ) 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= ) 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=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-413861904=
646",
       =
"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.twitter.com/audriga
 
---------------------------------------------------------------=
-----------
audriga GmbH |  Alter Schlachthof 57  | 76137 =
Karlsruhe
Sitz der Gesellschaft: Karlsruhe - Amtsgericht Mannheim - HRB =
713034
Gesch=C3=A4ftsf=C3=BChrer: Dr. Frank Dengler, Dr.-Ing. =
Hans-J=C3=B6rg Happel
---------------------------------------------------------------=
-----------

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

= --Apple-Mail=_C1A9D46B-F07A-49A2-B391-48030302D75A--