Re: [scim] unknown attribute type in attribute selection parameter

Phil Hunt <phil.hunt@oracle.com> Fri, 11 May 2018 02:52 UTC

Return-Path: <phil.hunt@oracle.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 7BD96120727 for <scim@ietfa.amsl.com>; Thu, 10 May 2018 19:52:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.709
X-Spam-Level:
X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.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 PhWQDcofSm24 for <scim@ietfa.amsl.com>; Thu, 10 May 2018 19:52:31 -0700 (PDT)
Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (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 5A85812D82F for <scim@ietf.org>; Thu, 10 May 2018 19:52:31 -0700 (PDT)
Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w4B2pivE170653; Fri, 11 May 2018 02:52:30 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2017-10-26; bh=EUbbZoyrBRgu9QphpQRpSaiaYUyX0106DV0B6JaghCw=; b=pvhuybCx3cCh2nNYQVTrWPcuQtrF1tq4eawfUCYfYfMjRgiyKUaRQDtW/iWwh4oPkZgO UhAMuSEWEpO+32p/b0daJ2rMR9rpjhuLsDGFzCIDXAOYI8EH7B6tEDAF6P9SC6JqRvqn +lzCIlaQzbrH4sYkGjGDKHHdN7oDGS1wMwjLf6k4B/4D5DY9ZzO7r2iv4Qr3j7u0gFZG rLdXeDHTEB1TJvxnoCgT+jCFvYVtlCQPOY6Yi8XQhRrbhnVRCaDn7X/ps1u0s0f4zoIN r1ZtBm9VIM4ctalu1LzoshNJ3Sn1pfICG+iWi+mlMuZk9ysYyZgX8cieaeyOB/HukB0y hw==
Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2130.oracle.com with ESMTP id 2hvth9228b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 11 May 2018 02:52:30 +0000
Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w4B2qSFb011453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 11 May 2018 02:52:29 GMT
Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w4B2qS30017405; Fri, 11 May 2018 02:52:28 GMT
Received: from [192.168.1.27] (/70.70.142.148) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 10 May 2018 19:52:28 -0700
Content-Type: multipart/alternative; boundary="Apple-Mail-5B4BFBAE-DD6C-4EAB-ADD3-E30E7D15DE24"
Mime-Version: 1.0 (1.0)
From: Phil Hunt <phil.hunt@oracle.com>
X-Mailer: iPhone Mail (15E302)
In-Reply-To: <8d8688e2-cbcd-d6ac-cf45-703794a30354@vmware.com>
Date: Thu, 10 May 2018 19:52:26 -0700
Cc: scim@ietf.org
Content-Transfer-Encoding: 7bit
Message-Id: <F172EEE1-B88B-4A0C-A245-420DD99CE19B@oracle.com>
References: <546bd659-175a-f036-4fa2-0d2575091336@vmware.com> <9F5709A3-FC58-481C-A909-DB526D12D1D7@oracle.com> <8d8688e2-cbcd-d6ac-cf45-703794a30354@vmware.com>
To: Dale Olds <olds@vmware.com>
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8889 signatures=668698
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805110021
Archived-At: <https://mailarchive.ietf.org/arch/msg/scim/GedTk0MBDW51qVOPina02nKckw0>
Subject: Re: [scim] unknown attribute type in attribute selection parameter
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 11 May 2018 02:52:33 -0000

Dale

This is what I was thinking of. 

3.4.2.1
> When processing query operations using endpoints that include more than one SCIM resource type (e.g., a query from the server root endpoint), filters MUST be processed as outlined in Section 3.4.2.2. For filtered attributes that are not part of a particular resource type, the service provider SHALL treat the attribute as if there is no attribute value. For example, a presence or equality filter for an undefined attribute evaluates to false.

Cheers,

Phil

> On May 10, 2018, at 7:34 PM, Dale Olds <olds@vmware.com> wrote:
> 
> Thanks, Phil. I agree that the behavior should be consistent with filter rules, but I didn't see where the Filtering section mentioned undefined attributes. By searching for "undefined" I see what you describe is there, in the Query Endpoints section. Odd, but good enough. Thanks again. 
> 
> --Dale  
> 
>> On 05/10/2018 07:19 PM, Phil Hunt wrote:
>> Dale
>> 
>> I believe your view is correct. 
>> 
>> The spec is a bit weak on the processing rules for the attributes parameter. 
>> 
>> One would expect behavior consistent with the filter rules which say undefined attributes can be evaluated as null or false etc. 
>> 
>> Phil
>> 
>>> On May 9, 2018, at 2:52 PM, Dale Olds <olds@vmware.com> wrote:
>>> 
>>> I have a question regarding how a SCIM server should handle unknown attribute names in an attribute selection parameter. The SCIM 2.0 spec, section 3.9, defines the "attributes" parameter. We're seeing an implementation that returns an error if one of the given attribute types is unknown to that server. 
>>> 
>>> From previous experience working with directory services it was very important that servers not return an error, but simply ignore that attribute since resources will not contain a value for it. This allowed for requests to be coded in a more portable fashion. If an app really needed to know what schema was supported, it could query the schema.
>>> 
>>> However, in looking over the SCIM 2.0 spec, I can't find anything that would directly address this case. It is somewhat indirectly addressed in that I can't find an error defined for invalid or undefined attribute type. 
>>> 
>>> Is there an expected behavior for this situation or is it up to the server implementation? 
>>> 
>>> --Dale Olds
>>> _______________________________________________
>>> scim mailing list
>>> scim@ietf.org
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_scim&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=pb0U4X3Kl2WACP79HHA7FmtCfg6YoFmk97APnIwAGrM&s=9BqVUKO4TTZGgD7H4U1tHHM7ZvxspP3xipmcFjyfWaE&e=
>