Re: [scim] Multi-Valued Attribute "Value" Requirement
Phillip Hunt <phil.hunt@independentid.com> Wed, 11 May 2022 01:26 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 9945DC14F743 for <scim@ietfa.amsl.com>; Tue, 10 May 2022 18:26:53 -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.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 qgBeJtB7IiZm for <scim@ietfa.amsl.com>; Tue, 10 May 2022 18:26:48 -0700 (PDT)
Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (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 2E45FC1594BA for <scim@ietf.org>; Tue, 10 May 2022 18:26:47 -0700 (PDT)
Received: by mail-pl1-x632.google.com with SMTP id x18so422570plg.6 for <scim@ietf.org>; Tue, 10 May 2022 18:26:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=independentid-com.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=ikpEFaZelapytm24ec6erHIIhzXhuOOrsvv9CykTF1M=; b=AkQf5Qq34htB+ipObdgYvxZPziPGrkXgkuS3KPDi8zLNhbMEp2V1CdSCYdqHoQpfQs fKu2Y6Lj++qmilfLeBpznIkki9DQyQurwsgG+c21Sm23qEDg3tcQGfJ290oFyG1shEi3 84XSb3v8te0WIcXJAwrMoqi5otEMPp5LS1o9R0AKoWzNfBnMTcF+Cmzpn+Xli/DeRwwp S7YcRWAMem684iSGoN09+1Q55UzILBX9ZuqlfnzzmXHlKbKUrSc4RuHWlnW1dMR407+J vRt8ir/i340QN/LrOK6+s0xjuFDAKMSgOyxXE5LTcGspRFK3agDkk07ZqRtnOwh1oMdK Pb+w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=ikpEFaZelapytm24ec6erHIIhzXhuOOrsvv9CykTF1M=; b=IqXhjEgB1ITA3LNpWTQCRX5/VPcMtLFcYC/Ry9m9P8Z5hRqmsOcDof8PihyADgGHP7 uxB0gip+TItTTIM+B7bZBZF+jPHSlFdzPuJ2dbbzfEmKhYVppfc8nvWfp/yUiPKfSmJs vU/oZP5fwEyvQXnVQkzew8BZnN7MyWAUAFbp+Flp1Ys0eLA2EL3z1QVUbh0GMmcTShOn b+2vm7qSxJWvGx2bFPQMEfWgA5VccrMrf3ZeXIPr1h4VNMHdQIHa5k7ILIkzs2RL9rWe JuMtfDx12STmcxEd9jPxFfzgWeksJbZkqYsN4klzL3+3IoFD3XeUVSRCEacMcMgfbNg/ LBiQ==
X-Gm-Message-State: AOAM531SiL9IImg+x+4SLyhASKWaCJNE4VhrKvwACUTTAuLs1MpaqJq8 ec1qqxIKlY6q9/IzJL+MHfB6cCUhqeACfg==
X-Google-Smtp-Source: ABdhPJw5ZR19qyZ+QOYXPckP2MhCmmzhJa1hzgst1vG0qaeKE0bXc5BUC7tTaHiDQhSi4S5BycAY3g==
X-Received: by 2002:a17:90b:35cb:b0:1dc:7905:c4c1 with SMTP id nb11-20020a17090b35cb00b001dc7905c4c1mr2682893pjb.95.1652232406890; Tue, 10 May 2022 18:26:46 -0700 (PDT)
Received: from smtpclient.apple (node-1w7jr9qjhqzxpbuel2rdt2pwq.ipv6.telus.net. [2001:569:7316:ae00:a446:6ba6:9093:b0aa]) by smtp.gmail.com with ESMTPSA id o13-20020a170902d4cd00b0015ee24acf38sm254852plg.212.2022.05.10.18.26.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 May 2022 18:26:46 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-9BD9E253-D95F-4223-B2D7-789FAA553955"
Content-Transfer-Encoding: 7bit
From: Phillip Hunt <phil.hunt@independentid.com>
Mime-Version: 1.0 (1.0)
Date: Tue, 10 May 2022 18:26:45 -0700
Message-Id: <5172D113-B3F1-47FA-A742-D2C259AC4E32@independentid.com>
References: <CAGUsYPwD_OW2jBcCeBUMeTrq2sB=71LGbQLSfgLaY1OoMcTw2w@mail.gmail.com>
Cc: scim@ietf.org
In-Reply-To: <CAGUsYPwD_OW2jBcCeBUMeTrq2sB=71LGbQLSfgLaY1OoMcTw2w@mail.gmail.com>
To: Shelley <randomshelley@gmail.com>
X-Mailer: iPhone Mail (19E258)
Archived-At: <https://mailarchive.ietf.org/arch/msg/scim/_eFD1MEjstgL06FDI1IoWLKIE0w>
Subject: Re: [scim] Multi-Valued Attribute "Value" Requirement
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.34
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: Wed, 11 May 2022 01:26:53 -0000
Agree. {} is undefined. [] is only way to erase all values on a put for multi-value. Phil > On May 10, 2022, at 4:03 PM, Shelley <randomshelley@gmail.com> wrote: > > > I think the SCIM client is intending to delete all phone numbers; they only manage zero or one phone number, and when there is no phone number, they send the "phoneNumbers" attribute with a single phone number object that has no "value" subattribute. > > "phoneNumbers": [ > { > "value": null, > "type": null > } > ] > > Our implementation already does require the "value" subattribute for multi-valued attributes, including "phoneNumbers", so we are failing fast here, which is still my preference. However, the SCIM client is using the SCIM core spec for their basis on allowing null "value" subattributes to be sent since it doesn't explicitly require it (although we do). As such, with their current implementation, they are unable to successfully send users that have no phone numbers to us, which is why we were (reluctantly) considering lifting this restriction. > > If I'm understanding correctly, you agree that the client should not be sending this data (although the spec is somewhat ambiguous in this regard) and would advise SPs to require "value" subattributes to eliminate any ambiguity in handling this scenario? > > >> On Tue, May 10, 2022 at 5:43 PM Phillip Hunt <phil.hunt@independentid.com> wrote: >> Shelley, >> >> This looks like the SCIM client has a serious bug and is failing to map the number correctly and is not intending to delete all values. As a service provider, to be careful, I would change the phoneNumbers value attribute schema to be required. This would cause the operation to fail. I think following the “null” or “empty set” rule might risk deleting data that was not intended. >> >> Phillip Hunt >> @independentid >> phil.hunt@independentid.com >> >> >> >> >>> On May 10, 2022, at 1:30 PM, Shelley <randomshelley@gmail.com> wrote: >>> >>> Thanks for the feedback. >>> >>>> > Is the clients sending all of the numbers at once? Or are these meant as individual examples? >>> >>> The client is not sending all of those values in a single "phoneNumbers" array; the example was just to illustrate several value-less "phoneNumbers" that SCIM implementations would need to handle, and to help provide different examples in case each may be interpreted differently. >>> >>>> > I would look to Section 3.3 (Create) and 3.5.1 (Put) and also 7643 Sec 2.5, where “null” (or [] in the case of multi-values) means to override existing or default values to assert them as null. Doing so inside of a MV attribute makes a little less sense. >>> >>> Correct, those sections don't really speak directly to sub-attributes. For reference, on a POST or PUT our implementation does accept any of the following, inline with the RFC: >>> "phoneNumbers": null >>> "phoneNumbers": [] >>> omission of the multi-valued attribute >>>> > The ugliness of this example does show why making “value” as required in phoneNumbers for the next iteration of 7643 might be a good idea. :-) >>> >>> Is there somewhere that we can log this to keep track of this for inclusion in the next RFC? >>> >>> In the meantime, I'm still curious as to how other server implementations and clients handle this scenario. My first preference would be to continue requiring the "value" subattribute in these cases, but if we need to make changes for broader compatibility with such clients, I'm assuming we should just ignore the value-less multi-valued attributes? And/or are others actually persisting and returning these valueless objects (e.g. with just the "type"/"primary" subattributes)? >>> >>> >>>> On Tue, May 10, 2022 at 3:02 PM Phillip Hunt <phil.hunt@independentid.com> wrote: >>>> Shelley, >>>> >>>> I would look to Section 3.3 (Create) and 3.5.1 (Put) and also 7643 Sec 2.5, where “null” (or [] in the case of multi-values) means to override existing or default values to assert them as null. Doing so inside of a MV attribute makes a little less sense. >>>> >>>> Is the clients sending all of the numbers at once? Or are these meant as individual examples? >>>> >>>> For a SCIM PUT operation, sending “phoneNumbers”: [], or “phoneNumbers”: [{}] would likely result in reseting the phoneNumbers value to unasserted removing any existing values. In the case of create, it overrides any default values that would otherwise be generated. This is useful because some servers might default work number to a company 1-800 number. Using “null” allows clients to override to say no number for this person. >>>> >>>> The ugliness of this example does show why making “value” as required in phoneNumbers for the next iteration of 7643 might be a good idea. :-) >>>> >>>> Phillip Hunt >>>> @independentid >>>> phil.hunt@independentid.com >>>> >>>> >>>> >>>> >>>>> On May 10, 2022, at 12:41 PM, Shelley <randomshelley@gmail.com> wrote: >>>>> >>>>> How should a SCIM server implementation interpret and manage multi-valued attributes that are sent without values? >>>>> >>>>> For example, if a SCIM client sends any of the following phone numbers: >>>>> >>>>> "phoneNumbers": [ >>>>> {}, >>>>> { >>>>> "value": null >>>>> }, >>>>> { >>>>> "value": null, >>>>> "type": null >>>>> }, >>>>> { >>>>> "value": null, >>>>> "primary": true >>>>> }, >>>>> { >>>>> "type": "work", >>>>> "primary": false >>>>> } >>>>> ] >>>>> >>>>> Should the SCIM server accept, ignore, or reject some/all of these phone numbers? The spec does not strictly require the "value", but it seems quite ambiguous to send a phone number without a phone number, for example. >>>>> >>>>> In our SCIM 1.1 and 2.0 server implementations, we have marked the "value" subattribute for all supported multi-valued attributes as "required" in our schema, documentation, and functionality. After 11 years, we have just now encountered a SCIM client that sends multi-valued attributes without value subattributes, however, to which we return a 400 error. We have documented the "value" subattribute as required in the schema we return from the "Schemas" endpoint: >>>>> >>>>> { >>>>> "name": "value", >>>>> "type": "string", >>>>> "multiValued": false, >>>>> "description": "The phone number.", >>>>> "required": true, >>>>> "caseExact": false, >>>>> "mutability": "readWrite", >>>>> "returned": "default", >>>>> "uniqueness": "none" >>>>> } >>>>> >>>>> However, the SCIM specification does not explicitly require it in the example schema nor in the RFC text. >>>>> >>>>> In my opinion, since the "value" is "the significant value", it should be required for the multi-valued attributes that support it, and SCIM clients should simply omit the object if there is no enclosed value. Without a value, the object seems invalid/incomplete/ambiguous. In lieu of that, is our next best bet just to completely ignore any valueless multi-valued attributes, regardless of whether any other subattributes are provided? How do other SCIM providers and consumers handle this? >>>>> _______________________________________________ >>>>> scim mailing list >>>>> scim@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/scim >>>> >>
- [scim] Multi-Valued Attribute "Value" Requirement Shelley
- Re: [scim] Multi-Valued Attribute "Value" Require… Phillip Hunt
- Re: [scim] Multi-Valued Attribute "Value" Require… Shelley
- Re: [scim] Multi-Valued Attribute "Value" Require… Phillip Hunt
- Re: [scim] Multi-Valued Attribute "Value" Require… Shelley
- Re: [scim] Multi-Valued Attribute "Value" Require… Phillip Hunt