From nobody Fri Sep 9 12:33:33 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 09B11C15256C for ; 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 ; 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 ; Fri, 9 Sep 2022 12:33:26 -0700 (PDT) Received: by mail-pl1-x630.google.com with SMTP id c2so2708354plo.3 for ; 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 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, 9 Sep 2022 12:33:23 -0700 In-Reply-To: <20220908103346.D4F111D3D@rfcpa.amsl.com> Cc: Murray Kucherawy , francesca.palombini@ericsson.com, Nancy Cam-Winget , egil@assimilated.dk, SCIM WG To: RFC Errata System References: <20220908103346.D4F111D3D@rfcpa.amsl.com> X-Mailer: Apple Mail (2.3696.120.41.1.1) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2022 19:33:31 -0000 --Apple-Mail=_F85366ED-DDBF-470E-9057-CCE6EB4EB991 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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 =E2=80=9Cvalue=E2=80=9D as the sub-attribute = (even when the attribute is not complex) per:=20 > 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":=E2=80=9Dschemas[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 = wrote: >=20 > The following errata report has been submitted for RFC7644, > "System for Cross-domain Identity Management: Protocol". >=20 > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid7122 >=20 > -------------------------------------- > Type: Technical > Reported by: Egil Hansen >=20 > Section: 3.5.2 >=20 > Original Text > ------------- > The "path" attribute is described by the following ABNF syntax rule: >=20 > PATH =3D attrPath / valuePath [subAttr] >=20 > Figure 7: SCIM PATCH PATH Rule >=20 > 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. >=20 > Corrected Text > -------------- > The "path" attribute is described by the following ABNF syntax rule: >=20 > PATH =3D attrPath / valuePath [subAttr] / attrExp >=20 > Figure 7: SCIM PATCH PATH Rule >=20 > The ABNF rules "attrPath", "valuePath", "subAttr", and "attrExp" are=20= > defined in Section 3.4.2.2. The "valuePath" rule allows specific=20 > values of a complex multi-valued attribute to be selected. >=20 > Notes > ----- > In section 3.5.2.2. (Remove Operation), states: >=20 > "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." >=20 > 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. >=20 > 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.: >=20 > filter=3D > schemas eq = "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User" >=20 > This would also work for a path filter, e.g.: >=20 > { > "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\"" > }] > } >=20 > 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 =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > 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 --Apple-Mail=_F85366ED-DDBF-470E-9057-CCE6EB4EB991 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

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 = =E2=80=9Cvalue=E2=80=9D 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":=E2=80=9Dschemas[va= lue 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




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:

=             &n= bsp;     PATH =3D attrPath / valuePath = [subAttr]

=             &n= bsp;        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:

=             &n= bsp;     PATH =3D attrPath / valuePath = [subAttr] / attrExp

=             &n= bsp;        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=3D
= 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 =             &n= bsp; : 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 =             &n= bsp;: System for Cross-domain Identity Management
Area =             &n= bsp;  : Applications and Real-Time
Stream =             &n= bsp;: IETF
Verifying Party     : = IESG

= --Apple-Mail=_F85366ED-DDBF-470E-9057-CCE6EB4EB991--