Re: [scim] Attributes Request Parameter and Sub-Attributes

Phillip Hunt <phil.hunt@independentid.com> Sat, 12 September 2020 00:35 UTC

Return-Path: <phil.hunt@independentid.com>
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 EA99D3A08ED for <scim@ietfa.amsl.com>; Fri, 11 Sep 2020 17:35:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=independentid-com.20150623.gappssmtp.com
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 P81uGWqq328s for <scim@ietfa.amsl.com>; Fri, 11 Sep 2020 17:35:21 -0700 (PDT)
Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C3EC3A079F for <scim@ietf.org>; Fri, 11 Sep 2020 17:35:21 -0700 (PDT)
Received: by mail-pg1-x534.google.com with SMTP id v15so7673170pgh.6 for <scim@ietf.org>; Fri, 11 Sep 2020 17:35:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=independentid-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=DPWiOynxECqPTEtOj4sdPkNp6fuoK7kIIcXW5G58uR4=; b=y0nB8fr7pdzOq+ktYGp0WSWLSQ3YPY4SjvCyzEr8YaaA5gkA7Kk+07YrvyjBQKdH3M ZzvClJmcqkArgJ5pWNTjfQ8gLD7+mIG1w5fESBodsE335c22Jc7Ji1LYYI/I79O4sMVs VRLmS286CPBdaO3zZ052e0iFjum+Tc3+VEZcHx9piKp15DdBCwoze7JPGfNpjxsd20va iREOdd4tztjZmG3Tjzh1qUO3rlCczLh510zAojSsAG6NSOKn1cfOfbV5zTs/6bklnw21 7372GpKaK92xi2Ru1YBYbZO/+UVVUlpg6JpU+CQjjZDEnO6rXWo18w/KXmZDi3Hzl9w2 ttjA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=DPWiOynxECqPTEtOj4sdPkNp6fuoK7kIIcXW5G58uR4=; b=S0B+nQ4CnIxy8hL4DUVR4j+I1ZjRGcm1ORoHhudg0P9rq6ZXX5TxYOEVX3zqsq7R4v Bmic4WgToWQMC0Z4DSU+RSEyv04p4BxdJ/kGfpeHVMns1Yz9WkVSSpQXjfmgwDKd8R5k uexShPe7AfAnkH7d8NqpkjsrbDn5cZnQiJ21Wi5W9Ur8u+RtONsB5791zBStVrgySsJ1 x3SVSETG4Crer1B3QNkHJTgX2GRG5GhOinsLJ+xGyFXthUAW4CZDNWb9IzVJbpOH6V0E UqiJpjXC+1hhjsbS9qUuUNLxTCFddHPFvWiGsNXwiGBcPTQ2eMIMXnwF9BoWxW3TfGlu BDPg==
X-Gm-Message-State: AOAM532Yev+ujDEc+0LFtun4PD1empvEQFvVvSJTP+QvJINfVjSBYJ3J o2ImbdQHml0MlolcYJ7RCq5+7/Z++7BVKg==
X-Google-Smtp-Source: ABdhPJyuq0KqL+JZ0RfoX/Y/4KR1WB+DGKz7SJ1q2hJKQZ3uTtfv699M+PXn7zbz2bnkr3m5NotQ+g==
X-Received: by 2002:a63:651:: with SMTP id 78mr3583226pgg.344.1599870920537; Fri, 11 Sep 2020 17:35:20 -0700 (PDT)
Received: from ?IPv6:2001:569:7a71:1d00:dc82:ecce:ece5:5d02? (node-1w7jr9qrfoxxavly22j0q8vsy.ipv6.telus.net. [2001:569:7a71:1d00:dc82:ecce:ece5:5d02]) by smtp.gmail.com with ESMTPSA id u4sm3528879pfk.166.2020.09.11.17.35.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 11 Sep 2020 17:35:19 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-F5CCD79F-F9A1-42F0-AA3F-4C597D5B3E5E"
Content-Transfer-Encoding: 7bit
From: Phillip Hunt <phil.hunt@independentid.com>
Mime-Version: 1.0 (1.0)
Date: Fri, 11 Sep 2020 17:35:19 -0700
Message-Id: <7F91477D-9927-4CAD-9FD0-FB274BB4F2F7@independentid.com>
References: <CAGUsYPxeyMYqMuZcfhvdE7Sdnf3F2iFPVYYtrXAW06ZT2JTt_A@mail.gmail.com>
Cc: scim@ietf.org
In-Reply-To: <CAGUsYPxeyMYqMuZcfhvdE7Sdnf3F2iFPVYYtrXAW06ZT2JTt_A@mail.gmail.com>
To: Shelley <randomshelley@gmail.com>
X-Mailer: iPhone Mail (17G80)
Archived-At: <https://mailarchive.ietf.org/arch/msg/scim/FdiUHNDyQY0RNwAG8ox7yqjiRu0>
Subject: Re: [scim] Attributes Request Parameter and Sub-Attributes
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Simple Cloud Identity Management BOF <scim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/scim>, <mailto:scim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/scim/>
List-Post: <mailto:scim@ietf.org>
List-Help: <mailto:scim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/scim>, <mailto:scim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 12 Sep 2020 00:35:23 -0000

My understanding/recollection is 
if one requests attributes=emails.type, you would expect only the type sub-attribute to be returned. 

If one says attributes=emails, then the default sub attributes are returned.   

Phil

> On Sep 11, 2020, at 7:49 AM, Shelley <randomshelley@gmail.com> wrote:
> 
> 
> I just wanted to get some clarification regarding the "attributes" request parameter when specifying sub-attributes.
> 
> When a consumer requests a default-scoped sub-attribute using the "attributes" parameter but does not specify the corresponding default-scoped parent attribute, or vise-versa (such that they specify the attribute, but not the desired sub-attributes), I'm assuming the sub-attribute should NOT be returned?
> 
> For instance, given the following attribute, sub-attributes, and "returned" characteristics (other characteristics omitted for brevity):
> 
> {
>     "name": "emails",
>     "returned": "default"
>     "type": "complex",
>     "multiValued": true,
>     "subAttributes": [
>         {
>             "name": "primary",
>             "returned": "default",
>             ...
>         },
>         {
>             "name": "type",
>             "returned": "default",
>             ...
>         },
>         {
>             "name": "value",
>             "returned": "default",
>             ...
>         }
>     ],
>     ...
> }
> 
> If a caller requests just the "emails.value" attribute, but does not specify "emails" in the attribute list, the "emails.value" will not be returned?
> 
> GET /Users/2819c223-7f76-453a-919d-413861904646?attributes=emails.value
> {
>   "id": "2819c223-7f76-453a-919d-413861904646"
> }
> 
> Likewise, if a caller requests just the "emails" attribute, but does not specify any sub-attributes in the attributes list, the sub-attributes will not be returned?
> 
> GET /Users/2819c223-7f76-453a-919d-413861904646?attributes=emails.value
> {
>   "id": "2819c223-7f76-453a-919d-413861904646",
>   "emails": [{},{}]
> }
> 
> Instead, based on my interpretation of the RFC, it seems that the caller must specify both the "emails" attribute and the "emails.value" sub-attribute in order to return the sub-attributes?
> 
> GET /Users/2819c223-7f76-453a-919d-413861904646?attributes=emails,emails.value
> {
>   "id": "2819c223-7f76-453a-919d-413861904646",
>   "emails": [
>     {
>       "value": "bjensen@example.com"
>     },
>     {
>       "value": "babs@jensen.org"
>     }
>   ]
> }
> 
> Please let me know if this understanding is correct, or if I'm overlooking some kind of special treatment defined in the spec that includes transitive retrieval for parent/sub-attributes. Thank you!
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim