Re: [scim] [Technical Errata Reported] RFC7644 (7122)

Phillip Hunt <phil.hunt@independentid.com> Fri, 09 September 2022 19:33 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 09B11C15256C for <scim@ietfa.amsl.com>; Fri, 9 Sep 2022 12:33:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.904
X-Spam-Level:
X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=unavailable 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 Xtj_1MNrnv_G for <scim@ietfa.amsl.com>; Fri, 9 Sep 2022 12:33:26 -0700 (PDT)
Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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 9F66EC1524C2 for <scim@ietf.org>; Fri, 9 Sep 2022 12:33:26 -0700 (PDT)
Received: by mail-pl1-x630.google.com with SMTP id c2so2708354plo.3 for <scim@ietf.org>; Fri, 09 Sep 2022 12:33:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=independentid-com.20210112.gappssmtp.com; s=20210112; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date; bh=ZUkBD4pkmRSuHeJgpFcaWnorDy1ir6yhbIkbDcccftM=; b=XUsoA4Oeh6l7j0tbnXQFTMcQ5A3fNxprG/nqGxC2gmLavv00we6DlnsUhoLtkU90y4 iVfh/00/QyuLGiZWM1gQYb9x45s0PYJOWBHjBdV7Eqh6kQREBaRvq+znC/4BrP1Hs4Fb 6U7fO7aCha2pjThddOgrh0ckPHnviLYtCiSGQXiOXIRviIh2vaSTYypcneP7LSZB5A0v JES6nVgflTIrGEAGnZ5gyphC2+TTb0NGlFkCazLwxRtDXagXQDfIiCJErb+XyqBsVf8W RYW/ZOfc6XVsS2L+f8onnIW8sCa2A8l/tpsoXURN0hYV9XgQJO9tSayqK/EqNcMuIFOU w6jQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date; bh=ZUkBD4pkmRSuHeJgpFcaWnorDy1ir6yhbIkbDcccftM=; b=gxldMugJplrS88MnDIxhiHWF2Mwz++EBU4lzs0yGOD8sLqC6UNmEUFG+0upRJSUhrK Ra8T5uYzHygBqUqSqnetPGRxFIaNkZQJTV1gCuBgGoa4N5Ksf9k7rWATiWWC7NKU/+bo SFtc3C5/rFNuN2cVyVNd1wjES2XRS4clxKz3d79bCXKAR7FXfFxvvClucn7njhG3N1k+ VITL+4KAFZGNzltvnjNIAqt6LADFIamev9OyBs29cO8PfDTrkQpiog/wCxFLKsvPi09V tEgTdQhXUApS4JwKQxxxUSu1e47drT/G9Hoq6RiqJ8TTa+zt7Sl6WD+nkH7W4kMlD8m0 i7iA==
X-Gm-Message-State: ACgBeo1GsKpFX9i2yl6hSQW9V2XmHTMOZxKndPXcWlkgbVt3sNSPlmjP GRw1Q/Bltxs6Uap1+y3ExkrXWw==
X-Google-Smtp-Source: AA6agR4RrpFGvxOUZbpt/8GwY24NOak8fwhAOc1j6+JanevOEQPp1p0ZmWPdXtZJrS3dZcF0CZPDCQ==
X-Received: by 2002:a17:903:2104:b0:176:a9ef:418b with SMTP id o4-20020a170903210400b00176a9ef418bmr14984690ple.134.1662752005575; Fri, 09 Sep 2022 12:33:25 -0700 (PDT)
Received: from smtpclient.apple (d207-6-202-204.bchsia.telus.net. [207.6.202.204]) by smtp.gmail.com with ESMTPSA id y1-20020a17090a104100b001fa80cde150sm811008pjd.20.2022.09.09.12.33.25 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Sep 2022 12:33:25 -0700 (PDT)
From: Phillip Hunt <phil.hunt@independentid.com>
Message-Id: <60B14532-1C26-43F0-B3ED-AF936957BCB9@independentid.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F85366ED-DDBF-470E-9057-CCE6EB4EB991"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Date: Fri, 09 Sep 2022 12:33:23 -0700
In-Reply-To: <20220908103346.D4F111D3D@rfcpa.amsl.com>
Cc: Murray Kucherawy <superuser@gmail.com>, francesca.palombini@ericsson.com, Nancy Cam-Winget <ncamwing@cisco.com>, egil@assimilated.dk, SCIM WG <scim@ietf.org>
To: RFC Errata System <rfc-editor@rfc-editor.org>
References: <20220908103346.D4F111D3D@rfcpa.amsl.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/scim/k3v-zwj2wReWWttgZIRZhwPtA2s>
Subject: Re: [scim] [Technical Errata Reported] RFC7644 (7122)
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.39
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, 09 Sep 2022 19:33:31 -0000

As one of the RFC authors (phil.hunt@yahoo.com), I think this probably has to be rejected because it introduces a normative change.


Reason: The specified way to handle multi-valued attribute is to use a valuePath expression using “value” as the sub-attribute (even when the attribute is not complex) per: 
>  o  If the target location is a multi-valued attribute and a complex
>       filter is specified comparing a "value", the values matched by the
>       filter are removed.  If no other values remain after removal of
>       the selected values, the multi-valued attribute SHALL be
>       considered unassigned.

I agree the errata suggests an easier way that is likely supported in many implementations but still represents a normative change. There is also a side-effect if introducing new conditional logic on single valued attrubtes that were not originally intended.

As to the example cited in the errata the correct way to specify per the paragraph above is:
{
 "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
 "Operations":[{
   "op":"remove",
   "path":”schemas[value eq \"urn:ietf:params:scim:schemas:extension:enterprise:2.0:User\]""
 }]
}

With that said, I find myself sayinig why not?  The working group may wish to take this on in any SCIM 2.x discussions.

Phillip Hunt
@independentid
phil.hunt@independentid.com




> On Sep 8, 2022, at 3:33 AM, RFC Errata System <rfc-editor@rfc-editor.org> wrote:
> 
> The following errata report has been submitted for RFC7644,
> "System for Cross-domain Identity Management: Protocol".
> 
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7122
> 
> --------------------------------------
> Type: Technical
> Reported by: Egil Hansen <egil@assimilated.dk>
> 
> Section: 3.5.2
> 
> Original Text
> -------------
>   The "path" attribute is described by the following ABNF syntax rule:
> 
>                   PATH = attrPath / valuePath [subAttr]
> 
>                      Figure 7: SCIM PATCH PATH Rule
> 
>   The ABNF rules "attrPath", "valuePath", and "subAttr" are defined in
>   Section 3.4.2.2.  The "valuePath" rule allows specific values of a
>   complex multi-valued attribute to be selected.
> 
> Corrected Text
> --------------
>   The "path" attribute is described by the following ABNF syntax rule:
> 
>                   PATH = attrPath / valuePath [subAttr] / attrExp
> 
>                      Figure 7: SCIM PATCH PATH Rule
> 
>   The ABNF rules "attrPath", "valuePath", "subAttr", and "attrExp" are 
>   defined in Section 3.4.2.2. The "valuePath" rule allows specific 
>   values of a complex multi-valued attribute to be selected.
> 
> Notes
> -----
> In section 3.5.2.2. (Remove Operation), states:
> 
> "If the target location is a multi-valued attribute and a complex
> filter is specified comparing a "value", the values matched by the
> filter are removed.  If no other values remain after removal of
> the selected values, the multi-valued attribute SHALL be
> considered unassigned."
> 
> This means it should be possible to create a filter that selects a value from a multi-valued attribute that is not complex. Writing such a filter seems impossible without having "attrExp" as a possible legal PATH.
> 
> In section 3.4.2.2.  (Filtering) there is an example that shows how such a filter could look for a multi-valued attribute, i.e.:
> 
> filter=
> schemas eq "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"
> 
> This would also work for a path filter, e.g.:
> 
> {
>  "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
>  "Operations":[{
>    "op":"remove",
>    "path":"schemas eq \"urn:ietf:params:scim:schemas:extension:enterprise:2.0:User\""
>  }]
> }
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC7644 (draft-ietf-scim-api-19)
> --------------------------------------
> Title               : System for Cross-domain Identity Management: Protocol
> Publication Date    : September 2015
> Author(s)           : P. Hunt, Ed., K. Grizzle, M. Ansari, E. Wahlstroem, C. Mortimore
> Category            : PROPOSED STANDARD
> Source              : System for Cross-domain Identity Management
> Area                : Applications and Real-Time
> Stream              : IETF
> Verifying Party     : IESG