Re: [scim] IETF 114 preliminary Agenda and call for other agenda requests

Phillip Hunt <phil.hunt@independentid.com> Fri, 15 July 2022 00:21 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 472AEC16ECFB for <scim@ietfa.amsl.com>; Thu, 14 Jul 2022 17:21:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level:
X-Spam-Status: No, score=-6.902 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=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=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 7U0YSiDThHFW for <scim@ietfa.amsl.com>; Thu, 14 Jul 2022 17:21:09 -0700 (PDT)
Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (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 534CBC16ECF3 for <scim@ietf.org>; Thu, 14 Jul 2022 17:21:09 -0700 (PDT)
Received: by mail-pj1-x1032.google.com with SMTP id z12-20020a17090a7b8c00b001ef84000b8bso10110168pjc.1 for <scim@ietf.org>; Thu, 14 Jul 2022 17:21:09 -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=Wf6wqC0PVUIlz41n1icN6W1W8E9H+J9FpFJVg29+H58=; b=ho/AtapFpJIYXHn9AgQfShyDDGK85KfgA86y1j60WUIoCD4+JB/kSi9//5/u5KyIu2 0Jdh24UvZnXJ/pO5j73IMO1ffMU4Ea8Kqt/prl52cifCtzfHk7Ko0CdBtcVtCGJ5sfpS iD0l0RdnhgIFIUY1ybK+NMzT2alZ/pnzRGb3bP4+shaFZNQ7BIOgVl4I6KOZUTSOQR1p PIlo1h0bJAmb1G1Ly6FDvdnA7MZvkhyHi0JLbuMwTV5dsHSuIKBE6J4UYw7Ckfedygp9 2+jYmZkky/2xE/SHOXd1nAd3kQuNyWKs26AaNYDgMqVuRYA03Pb0AmA/AAqSgkq/Pk/M M88g==
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=Wf6wqC0PVUIlz41n1icN6W1W8E9H+J9FpFJVg29+H58=; b=zcsTR8A6pCi+lXslg6IeL5zLf+75EmO0hGroghS/qC1+IZx9CRKN1o4ibA6dk/SVhZ Qr9GjTQaRCJ3B8YikNnU+x1bIBB+hjLdNyLtM2h2jcDzE7pp8ptnWnthBqKtpC1NPpY+ X/m3hqpHflh1cN45w7jZx0DUVfSazKAMda+a5cYJY2QpBsKfX5O1bFnt5P/flUqUmA2D tFaTwmOlnJe4pEiQzpvq9Ffa4ZVv1gDivpTkg3f2QKY3L1Glt3VkhAuGEz+SCmWAuIEl bHyKaVKkHaZzK9VJaqByp/jT8ND1HohfOmlpMg5zymyi+Zkxwihf4NDTKjSupuuNXLIV O/Fg==
X-Gm-Message-State: AJIora9kxO2eKy5jmBXCpN/2ZTRedeWCQlwr/GiGLb0K/lVTxeseeThn qbGkI2fEhBcnBa9PLLPp2pq+1TKscD0fjXIM
X-Google-Smtp-Source: AGRyM1tmka7df9RPC4grDcr41IvripearTFhvkntpNMgAdw3j7n0Ou7KW+mvpfJ6olYOQWvfYE9kNQ==
X-Received: by 2002:a17:90b:268f:b0:1ef:ba7e:3fe4 with SMTP id pl15-20020a17090b268f00b001efba7e3fe4mr12607996pjb.23.1657844468170; Thu, 14 Jul 2022 17:21:08 -0700 (PDT)
Received: from smtpclient.apple (node-1w7jr9qjhqzxpymreqlcm6g3e.ipv6.telus.net. [2001:569:7316:ae00:cde6:42b1:cdf0:ecfa]) by smtp.gmail.com with ESMTPSA id c13-20020aa7952d000000b0052ac5e304d0sm2346656pfp.179.2022.07.14.17.21.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 14 Jul 2022 17:21:07 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-9CBF1D6F-2DF9-4EE9-98D5-32B60337A590"
Content-Transfer-Encoding: 7bit
From: Phillip Hunt <phil.hunt@independentid.com>
Mime-Version: 1.0 (1.0)
Date: Thu, 14 Jul 2022 17:21:06 -0700
Message-Id: <74B141BF-BF2D-4B7C-AA1D-3F161A84485B@independentid.com>
References: <SJ1PR19MB6138FAAC718EC82367140F50E1889@SJ1PR19MB6138.namprd19.prod.outlook.com>
Cc: Danny Zollner <Danny.Zollner@microsoft.com>, "Nancy Cam-Winget (ncamwing)" <ncamwing=40cisco.com@dmarc.ietf.org>, scim@ietf.org, Pamela Dingle <Pamela.Dingle@microsoft.com>, "Janelle Allen (janelall)" <janelall@cisco.com>
In-Reply-To: <SJ1PR19MB6138FAAC718EC82367140F50E1889@SJ1PR19MB6138.namprd19.prod.outlook.com>
To: "Matt Peterson (mpeterso)" <Matt.Peterson@oneidentity.com>
X-Mailer: iPhone Mail (19F77)
Archived-At: <https://mailarchive.ietf.org/arch/msg/scim/C7e6HT_YnwlUjusBFqkr2BmAl9s>
Subject: Re: [scim] IETF 114 preliminary Agenda and call for other agenda requests
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, 15 Jul 2022 00:21:13 -0000

Matt

I think we are going to have to agree to disagree on the performance and scalability issues of cursors. :) 

The bigger issue is that having two solutions to the same problem is not useful from an interop perspective. Normally when multiple IDs are submitted for the same problem the group adopts one only. I thought that is what we did. 

Maybe the group made an error by adopting scim events?  I encourage revisiting that decision one more time if it means one interoperable and implementable standard for all.

Phil

> On Jul 13, 2022, at 7:27 PM, Matt Peterson (mpeterso) <Matt.Peterson@oneidentity.com> wrote:
> 
> 
> Phil,
>  
> The cursor pagination draft was written for the common use case where SCIM service is written on top of an underlying database or protocol that uses cursors for result pagination.   This is a very common scenario.  We have implemented SCIM services on top of more than 30 different protocols and databases and nearly half of these use cursor pagination.  With this experience as evidence, I do not agree with your statement that cursor pagination requires the SCIM service to maintain copy of result sets.  It is trivial for SCIM service to store the back-end cursor, or even pass the cursor to the SCIM caller.   On the other hand, attempting to implement index/offset pagination on top of a database/protocol that uses cursors *does* require the SCIM service to maintain result sets (possibly the entire result set). 
>  
> Also, there is no evidence that use of cursors for pagination in a web API opens a meaningful “denial of service attack vector”.    Many public (and extensively used) Web APIs use cursor pagination (including Facebook, and Twitter).   I can think of almost as many attacks with on index/offset as cursor.  All are easy to mitigate with trivial safeguards that server-side developers will be familiar with.
>  
> I do agree with you, that the primary use case for a SCIM client retrieving large (paginated) result sets is for the SCIM client to sync a “local cache” of results (especially for detecting deletes) – and that the SCIM events draft is a better approach for this use case.  However, I remember us testing the assertion in one discussion with the interest group (pre charter) with the suggestion that pagination (index or cursor) is not needed at all.   Not everyone agreed with us 😊    
>  
> If we can convince the community that pagination of results is not needed then… great.  However, if we can’t, because people need it (or think they need it), then we should provide guidance for implementing *both* index/offset *and* (optionally) cursor pagination.
>  
> --
> Matt
>  
> From: Phillip Hunt <phil.hunt@independentid.com> 
> Sent: Wednesday, July 13, 2022 11:42 AM
> To: Danny Zollner <Danny.Zollner@microsoft.com>
> Cc: Matt Peterson (mpeterso) <Matt.Peterson@oneidentity.com>; Nancy Cam-Winget (ncamwing) <ncamwing=40cisco.com@dmarc.ietf.org>; scim@ietf.org; Pamela Dingle <Pamela.Dingle@microsoft.com>; Janelle Allen (janelall) <janelall@cisco.com>
> Subject: Re: IETF 114 preliminary Agenda and call for other agenda requests
>  
> CAUTION: This email originated from outside of the organization. Do not follow guidance, click links, or open attachments unless you recognize the sender and know the content is safe.
>  
> I’ve put some comments below. These are discussion items that presenters might want to include in their presentation.
>  
> Phillip Hunt
> @independentid
> phil.hunt@independentid.com
>  
>  
> 
> 
> 
> On Jul 12, 2022, at 9:12 PM, Danny Zollner <Danny.Zollner@microsoft.com> wrote:
>  
> I’d like to cover the following items related to protocol and schema work:
>  
> Cursor-based pagination – via Matt’s draft (that I somehow didn’t realize existed until last month!)
> <PH> Much of the use case for this was to support replication and co-ordination of events across domains. How does/doesnot this specification conflict with the SCIM Events WG draft?
>  
> I remain ocncerned about the resource costs for service providers and the denial of service attack vector that results.  I have heard that many clients can’t hold a result set in memory. Fair enough. But in this case, would it be better to use a streaming parser OR simply store results direct to local disk for processing?
>  
> Why cursors are hard:  If a client has limited resources to store one result set, the cost to a service provider with thousands of clients is multiplied and may not be possible.  In todays systems, causing a SCIM service provider to hold temporary state over data impacts a cluster in many ways.  Today’s server is simply making calls to a database and doing some translation. The server itself is largely stateless. With cursors, the results sets have to be maintained and could effectively mean storing a copy of the entire database. In clusters enviornments (most of them) access to that result set likely needs to be shared.  If not the load-balancer has to maintain “sticky” connections so that each client request goes to the same cluster node.  This could still lead to problems if the client is too slow and the connection is reset. As written now, SCIM servers don’t need to hold “state” across requests.  Implementing cursors would mandate a major re-write for most implementations.  
>  
> There is also a mistaken assumption that we need paging because SCIM has a result size limitation. That’s not part of SCIM Protocol. The spec simply permits service providers to set limits for things like Javascript UI clients. Presumably for a priviledged provisioning client, they ahve access to the enitre data set. It makes no sense to enforce a 1000 result set limit in these scenarios.   
>  
> —> The problem is that many implementations make max results a server setting rather than an access control entitlement.  This is not so much something we need to deal with. We may just need to alert industry product managers of why they need to support provisioning clients properly.
> 
>  
> Multi-valued attribute pagination – Phil’s draft is a good place to start there. Based on feedback on the mailing list a few months ago, I think there are questions on whether multi-valued attribute filtering is needed, which is also included in Phil’s draft. Splitting multi-valued attribute pagination away from multi-valued attribute filtering if/when it is adopted by the working group may be the best choice.
> <PH> The current draft re-uses aspects of SCIM that already supports CMVA filtering. For this reaon, pulling the functionality apart doesn’t make sense. AFAIK there are only a couple of requestors (e.g. Gregg Wilson/Oracle) for this draft.  Without wider support, should we drop the spec?
>  
> I wasn’t planning on presenting this. Please let me know if I should.
> 
>  
> Discussion on change detection/delta query approaches – I’ll prepare some slides on this and may try to send out an email this week or next week as well, but won’t have a draft for this by IETF 114.
> <PH> The current SCIM Protocol spec indicates support for ETAGs specifically in Sec 3.14 of RFC7644 (versioning resources) and can be used in queries. In SCIM’s case an ETAG is a hash of the resource. ETAGs more broadly in HTTP allow a requestor to make queries or changes using HTTP Preconditions (RFC7232).  For example, you can do a GET conditional only on the resource having changed. You can also condity a modify (PUT, PATCH, DELETE) on a resource being unchanged (has a specific etag) or has/has not changed since a specified date.  I suspect pre-conditions are not widely supported in many SCIM implementations.  I have implemented it in i2scim.io.
>  
> I am not sure if this is what you are really after, but you may want to distinguish your requirement from the HTTP standard if different.  :-)
>  
> Also, SCIM Events intent is to notify subscribers of changes in real time.  In the simplest message, the new etag is shared (an etag is a hash of the resource).
> 
>  
> Soft deletion
> Expansion of account status context beyond active true/false – Janelle is working on a draft for this, although I do not know if this will make it in time for IETF 114
> My roles/entitlements draft – it has expired but I’ll renew it and would like to put it up for a call for adoption. I don’t know if we need to figure out the contains/containedBy topic that I wrote to the mailing list about last month prior to adoption or if that can be left for the working group to figure out later
> HR Schema action plan/next steps
> Resetting the milestones that we set last year? (Do we need to worry about this?)
> Current plan is that we work on a bunch of the new features in the form of separate extension drafts to SCIM 2.0, and leave RFC 7643 and 7644 alone for now. Once we’re further along in the new features (i.e.: the above + others from the charter) we can determine the final approach of how to make changes to the protocol and schema – that is, do we revise SCIM 2.0 schema and protocol docs while remaining 2.0 but issuing new RFCs (apparently possible), or increment version.
> <PH> I haven’t really seen a need to go to SCIM 2.x or 3. Almost all the enhancements can be positioned as extensions to the current SCIM 2 RFCs.  
>  
> Some of the discussion about extending groups etc suggest much more complex CMVA objects (e.g. verified claims etc). This is interesting. But I would prefer to simply deifne new objects rather than version the protocol first.  There is also nothing saying you can’t have a group represented “virtually” where extended schema is available at one resource path “/<extended>Groups/“ while “/Groups” holds the old schema version of the same groups.
>  
> The more complex extension would be to add meta data to attributes like roles.   In some systems, a role binding is actually a policy that has thins like conditions and expiry dates.  
> —> I guess what I am saying here is this topic deserves a lot of dinner time and hallway discussion over many glasses of wine and beers.
>  
> As for editorial clean ups, I am not sure myself what the IETF permits moving from “proposed standard” to “standard” which is another possible route.   In particular, I think many of the examples need to be improved as people depend too much on figures and have gotten mis-leading impressions.  Some of the figures need to better reflect the normative text intent.  I have a concern that many don’t realize that SCIM is technicly a profile of HTTP and that the HTTP RFC do apply. I wonder if in the introduction, we can make this more obvious/clear.
>  
> There is one issue with PATCH that we should clarify.  I believe it was wether replacing a value for an attribute value that does not exist MAY be converted to an ADD.  In Postel’s ROBUST design, I would say go for it. There are others that say the transaction that must fail.  The spec is ambiguous on this point and any clarfication would result in a normative change for some.
> 
> I think these topics could easily take an hour, if not more. Whatever time is not used by use cases or SCIM Events can be allocated here.
>  
> Thanks,
>  
> Danny Zollner
>  
> From: Matt Peterson (mpeterso) <Matt.Peterson@oneidentity.com> 
> Sent: Monday, July 11, 2022 11:35 PM
> To: Nancy Cam-Winget (ncamwing) <ncamwing=40cisco.com@dmarc.ietf.org>; scim@ietf.org; Pamela Dingle <Pamela.Dingle@microsoft.com>; Janelle Allen (janelall) <janelall@cisco.com>; Danny Zollner <Danny.Zollner@microsoft.com>; Phillip Hunt <phil.hunt@independentid.com>
> Subject: [EXTERNAL] RE: IETF 114 preliminary Agenda and call for other agenda requests
>  
> Nancy,
>  
> There has been recent activity on the mailing list (and also discussion in the SCIM interest group before our chart) that shows continued interest in cursor pagination (draft-peterson-scim-cursor-pagination). 
>  
> If appropriate for our charter, I would like one more opportunity to check if cursor pagination is interesting to enough people to warrant effort on my part to create a new revision of the draft to address 2 interoperability issues that were raised on the mailing list last month.
>  
> --
> Matt
>  
> From: scim <scim-bounces@ietf.org> On Behalf Of Nancy Cam-Winget (ncamwing)
> Sent: Monday, July 11, 2022 6:51 PM
> To: scim@ietf.org; Pamela Dingle <Pamela.Dingle@microsoft.com>; Janelle Allen (janelall) <janelall@cisco.com>; Danny Zollner <Danny.Zollner@microsoft.com>; Phillip Hunt <phil.hunt@independentid.com>
> Subject: [scim] IETF 114 preliminary Agenda and call for other agenda requests
>  
> CAUTION: This email originated from outside of the organization. Do not follow guidance, click links, or open attachments unless you recognize the sender and know the content is safe.
>  
> Hello SCIMers,
>  
> Here is the current proposed agenda and a call for other requests:
>  
> 5 min: Agenda Bash & Logistics
>                 SCIM Chairs: Nancy Cam-Winget, Aaron Parecki
>  
> TDB min: Use Cases 
>                 Pamela Dingle
>                 
> TBD min: Protocol & Schema
>                 Janelle Allen and Danny Zollner
>                 
> TBD min: SCIM Events
>                 Phil Hunt
> AOB
>  
> @Pamela Dingle, @Janelle Allen (janelall), @Danny Zollner and @Phillip Hunt: can you provide requested times to provide updates on the work above?
>  
> If there are other requests for agenda slots, please reply to this email or send a request to scim-chairs@ietf.org
>  
> Thanks, Nancy
>