From nobody Wed Jul 13 15:10:08 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 6FEE9C14F720 for ; Wed, 13 Jul 2022 15:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.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_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=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 SIHNRz8CXRRc for ; Wed, 13 Jul 2022 15:10:01 -0700 (PDT) Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (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 C8949C14F723 for ; Wed, 13 Jul 2022 15:10:01 -0700 (PDT) Received: by mail-pg1-x536.google.com with SMTP id f65so2407388pgc.12 for ; Wed, 13 Jul 2022 15:10:01 -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=TRS7o8xxSd+v/tvbt6SXuKjhW22/yS2Oz09jW7uU6DA=; b=oGL3s3ZwSbBhUBpxKAyENIlrxTHK4Dll7xAVLxDQ2GhQR0328IXStH833lr4+CCYMO CmrEz0btAFGMz2qT+4h05na059QAsi0/kkvarjQto2CdGjJ7hNw39S3nKr2dssaAiS0S KH5aqG6lQAebcB6MPkfThbszpp+67gM1fNgLpin6tzqTffJmxjGjysV+sy5kTy0OjkrY FDMmHQDnyCOsUjhjektLxHYjmZkg7YQemWvOImAmJF/XAd+VSJ9YTC/hQrYHKGOk/Lph 4y8L/CL5EwwXuYEIGLhOzvzBKabFb5XAzapmvMpq5aCHcE/fM11moGOnI119hn2jb7To Wncw== 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=TRS7o8xxSd+v/tvbt6SXuKjhW22/yS2Oz09jW7uU6DA=; b=0Sl6cTBfiigYBpd/+aa2IWO/nCDZIv4ZZyj/SzneMnssp2BKZTor0Wq7rKx4yp1rwd lwAg49+cJzH4Xi5X2Gk1rHWn7R6PKZxpb17rMJ03O2d5pg4abPXYPko3Dvxz/gEhSI5J F4CaldlGAgCC28mYaEx/cLN49YAqQiH2hUO5xzR/5zKXC1PZ0xjYctWvyNgch6gfIcuB Qo2ujAEdCIx5tlleeGKdS8s/G91iNkij35UO3zmoE+8AH/cHsJEAHo0Z+wSqRhBNFWpa AoX7bbgDknliwUGZXMMXrovvobadDgrUvAwRvhirsoS2hJE+EJLpFXqhxHuY2OaKGwhU DF1g== X-Gm-Message-State: AJIora/oIQEPFIE5Ege1/Hq2jmOKG3R8UiHUW4/nqkjTLWvgumcWcdAc yIZdHot9Y/m+QFyqSHo741gyK5eYWNE165X+ X-Google-Smtp-Source: AGRyM1t3f7jzAi6gT0Vvr8VW3P7t8mDJnG5sMj+539uz2qUN80cjgNcZZM3Qnuwprd9lePkBrJvfmw== X-Received: by 2002:a05:6a00:2446:b0:528:5f22:5b6f with SMTP id d6-20020a056a00244600b005285f225b6fmr5321814pfj.73.1657750200820; Wed, 13 Jul 2022 15:10:00 -0700 (PDT) Received: from smtpclient.apple (d207-6-202-204.bchsia.telus.net. [207.6.202.204]) by smtp.gmail.com with ESMTPSA id z16-20020aa79490000000b0052512fdaa43sm20375pfk.163.2022.07.13.15.10.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 13 Jul 2022 15:10:00 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-51797475-D8C2-4F95-9F20-50F7D07DB8A1 Content-Transfer-Encoding: 7bit From: Phillip Hunt Mime-Version: 1.0 (1.0) Date: Wed, 13 Jul 2022 15:09:43 -0700 Message-Id: <4BE102C2-6BBD-416D-B58E-7DE5F7669FFC@independentid.com> References: Cc: Matt Peterson , "Nancy Cam-Winget (ncamwing)" , scim@ietf.org, Pamela Dingle , "Janelle Allen (janelall)" In-Reply-To: To: Danny Zollner X-Mailer: iPhone Mail (19F77) Archived-At: Subject: Re: [scim] [EXTERNAL] Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2022 22:10:06 -0000 --Apple-Mail-51797475-D8C2-4F95-9F20-50F7D07DB8A1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Danny The question remains. Why not download the entire result set in one GET?=20 Phil > On Jul 13, 2022, at 2:30 PM, Danny Zollner w= rote: >=20 > =EF=BB=BF > Hi Phil, > =20 > On the topic of cursor-based pagination, I=E2=80=99m not sure how it would= conflict with the SCIM Events draft. I think this is a case of different pa= rticipants in the working group coming at the spec from different use cases.= In the case that I=E2=80=99m trying to represent, it=E2=80=99s a client/ser= ver model where a client is trying to retrieve large amounts of data at once= . In the same way that some SCIM implementations may not wish to implement t= he SCIM Events draft, cursor-based pagination as an optional extension to pr= ovide a method to break large amounts of data into smaller, more efficiently= consumable chunks should be fine. For those who cannot implement it due to t= heir own architecture limitations, they can potentially look at other option= s for traversal of large amounts of data. > =20 > On the topic of multi-valued attribute pagination and filtering, I (and Mi= crosoft) are very interested in this, and from discussions with some service= provider implementers, I believe there is adequate interest. Specifically o= n the filtering piece, I recall that there was some previous feedback about t= he value of it. I do not have a strong opinion on the filtering component, b= ut given the past feedback I was suggesting that it may be worth discussing.= I=E2=80=99d like the working group to discuss your draft, draft-hunt-scim-m= v-filtering. If you=E2=80=99d like to present on it I think that would be gr= eat, otherwise we can attempt to have someone else speak to it if that=E2=80= =99s OK. > =20 > On the topic of change detection, this again may be a case of different us= e cases and lack of precision in the terminology that I used in my last emai= l =E2=80=93 sorry for that. While ETAGs are helpful in some circumstances su= ch as version controlling when multiple actors may be interacting with the s= ame resource, the problem I=E2=80=99m hoping to see solved is different. Sim= ilar to the above profile of a client/server model where a large number of r= esources are being retrieved, I=E2=80=99m proposing some form of change trac= king that allows a client to request from a server =E2=80=9CReturn all objec= ts that have changed since some prior point in time=E2=80=9D. This of course= could also have filters applied, so you could structure requests like =E2=80= =9CReturn all users where department =3D Sales that have changed since some p= rior point in time=E2=80=9D. The problem is then =E2=80=93 how do you repres= ent that point in time? You mentioned detecting changes either via ETAGs or v= ia =E2=80=9Chas/has not changed since a specified date=E2=80=9D. Having disc= ussed this topic with some of my more senior coworkers, the feedback I=E2=80= =99ve heard is that dates of any format (lastModified, etc..) are a bad choi= ce as they are not monotonically increasing, and services backed by multiple= physical devices (so.. almost anything operating at large scale nowadays?) w= on=E2=80=99t have consistent dates/times between them. The approach I=E2=80=99= ve got in mind right now would be a state cookie that is managed by the serv= er and is likely opaque to the client. > =20 > Finally, on the topic of version incrementing/changes to the existing core= schema and protocol docs, I am not advocating for incrementing the version o= r making any specific changes at this point, but rather that we defer on thi= s until later, as there is ample work in front of us with the dozen+ topics t= hat can easily be implemented as extensions. We should start compiling a lis= t of proposed changes that have to occur in the core schema and protocol RFC= s rather than in an extension, and once we believe we=E2=80=99ve exhausted t= hings there can discuss how best to implement those changes at that time (th= e version increment/reissue 2.0/other option discussion). > =20 > Thanks, > =20 > Danny > =20 > =20 > =20 > From: Phillip Hunt =20 > Sent: Wednesday, July 13, 2022 11:42 AM > To: Danny Zollner > Cc: Matt Peterson ; Nancy Cam-Winget (ncamw= ing) ; scim@ietf.org; Pamela Dingle <= Pamela.Dingle@microsoft.com>; Janelle Allen (janelall) > Subject: [EXTERNAL] Re: IETF 114 preliminary Agenda and call for other age= nda requests > =20 > I=E2=80=99ve put some comments below. These are discussion items that pres= enters might want to include in their presentation. > =20 > Phillip Hunt > @independentid > phil.hunt@independentid.com > =20 > =20 >=20 >=20 >=20 > On Jul 12, 2022, at 9:12 PM, Danny Zollner w= rote: > =20 > I=E2=80=99d like to cover the following items related to protocol and sche= ma work: > =20 > Cursor-based pagination =E2=80=93 via Matt=E2=80=99s draft (that I somehow= didn=E2=80=99t realize existed until last month!) > Much of the use case for this was to support replication and co-ordin= ation of events across domains. How does/doesnot this specification conflict= with the SCIM Events WG draft? > =20 > I remain ocncerned about the resource costs for service providers and the d= enial of service attack vector that results. I have heard that many clients= can=E2=80=99t hold a result set in memory. Fair enough. But in this case, w= ould it be better to use a streaming parser OR simply store results direct t= o local disk for processing? > =20 > Why cursors are hard: If a client has limited resources to store one resu= lt set, the cost to a service provider with thousands of clients is multipli= ed and may not be possible. In todays systems, causing a SCIM service provi= der to hold temporary state over data impacts a cluster in many ways. Today= =E2=80=99s server is simply making calls to a database and doing some transl= ation. The server itself is largely stateless. With cursors, the results set= s have to be maintained and could effectively mean storing a copy of the ent= ire database. In clusters enviornments (most of them) access to that result s= et likely needs to be shared. If not the load-balancer has to maintain =E2=80= =9Csticky=E2=80=9D connections so that each client request goes to the same c= luster node. This could still lead to problems if the client is too slow an= d the connection is reset. As written now, SCIM servers don=E2=80=99t need t= o hold =E2=80=9Cstate=E2=80=9D across requests. Implementing cursors would m= andate a major re-write for most implementations. =20 > =20 > There is also a mistaken assumption that we need paging because SCIM has a= result size limitation. That=E2=80=99s not part of SCIM Protocol. The spec s= imply permits service providers to set limits for things like Javascript UI c= lients. Presumably for a priviledged provisioning client, they ahve access t= o the enitre data set. It makes no sense to enforce a 1000 result set limit i= n these scenarios. =20 > =20 > =E2=80=94> The problem is that many implementations make max results a ser= ver setting rather than an access control entitlement. This is not so much s= omething we need to deal with. We may just need to alert industry product ma= nagers of why they need to support provisioning clients properly. >=20 > =20 > Multi-valued attribute pagination =E2=80=93 Phil=E2=80=99s draft is a good= place to start there. Based on feedback on the mailing list a few months ag= o, I think there are questions on whether multi-valued attribute filtering i= s needed, which is also included in Phil=E2=80=99s draft. Splitting multi-va= lued attribute pagination away from multi-valued attribute filtering if/when= it is adopted by the working group may be the best choice. > The current draft re-uses aspects of SCIM that already supports CMVA f= iltering. For this reaon, pulling the functionality apart doesn=E2=80=99t ma= ke sense. AFAIK there are only a couple of requestors (e.g. Gregg Wilson/Ora= cle) for this draft. Without wider support, should we drop the spec? > =20 > I wasn=E2=80=99t planning on presenting this. Please let me know if I shou= ld. >=20 > =20 > Discussion on change detection/delta query approaches =E2=80=93 I=E2=80=99= ll prepare some slides on this and may try to send out an email this week or= next week as well, but won=E2=80=99t have a draft for this by IETF 114. > The current SCIM Protocol spec indicates support for ETAGs specifical= ly in Sec 3.14 of RFC7644 (versioning resources) and can be used in queries.= In SCIM=E2=80=99s case an ETAG is a hash of the resource. ETAGs more broadl= y in HTTP allow a requestor to make queries or changes using HTTP Preconditi= ons (RFC7232). For example, you can do a GET conditional only on the resour= ce having changed. You can also condity a modify (PUT, PATCH, DELETE) on a r= esource 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 S= CIM implementations. I have implemented it in i2scim.io. > =20 > I am not sure if this is what you are really after, but you may want to di= stinguish your requirement from the HTTP standard if different. :-) > =20 > 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 r= esource). >=20 > =20 > Soft deletion > Expansion of account status context beyond active true/false =E2=80=93 Jan= elle is working on a draft for this, although I do not know if this will mak= e it in time for IETF 114 > My roles/entitlements draft =E2=80=93 it has expired but I=E2=80=99ll rene= w it and would like to put it up for a call for adoption. I don=E2=80=99t kn= ow if we need to figure out the contains/containedBy topic that I wrote to t= he mailing list about last month prior to adoption or if that can be left fo= r 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 fo= r now. Once we=E2=80=99re further along in the new features (i.e.: the above= + others from the charter) we can determine the final approach of how to ma= ke changes to the protocol and schema =E2=80=93 that is, do we revise SCIM 2= .0 schema and protocol docs while remaining 2.0 but issuing new RFCs (appare= ntly possible), or increment version. > I haven=E2=80=99t really seen a need to go to SCIM 2.x or 3. Almost a= ll the enhancements can be positioned as extensions to the current SCIM 2 RFC= s. =20 > =20 > Some of the discussion about extending groups etc suggest much more comple= x CMVA objects (e.g. verified claims etc). This is interesting. But I would p= refer to simply deifne new objects rather than version the protocol first. T= here is also nothing saying you can=E2=80=99t have a group represented =E2=80= =9Cvirtually=E2=80=9D where extended schema is available at one resource pat= h =E2=80=9C/Groups/=E2=80=9C while =E2=80=9C/Groups=E2=80=9D holds= the old schema version of the same groups. > =20 > The more complex extension would be to add meta data to attributes like ro= les. In some systems, a role binding is actually a policy that has thins l= ike conditions and expiry dates. =20 > =E2=80=94> I guess what I am saying here is this topic deserves a lot of d= inner time and hallway discussion over many glasses of wine and beers. > =20 > As for editorial clean ups, I am not sure myself what the IETF permits mov= ing from =E2=80=9Cproposed standard=E2=80=9D to =E2=80=9Cstandard=E2=80=9D w= hich is another possible route. In particular, I think many of the example= s need to be improved as people depend too much on figures and have gotten m= is-leading impressions. Some of the figures need to better reflect the norm= ative text intent. I have a concern that many don=E2=80=99t realize that SC= IM is technicly a profile of HTTP and that the HTTP RFC do apply. I wonder i= f in the introduction, we can make this more obvious/clear. > =20 > There is one issue with PATCH that we should clarify. I believe it was we= ther replacing a value for an attribute value that does not exist MAY be con= verted to an ADD. In Postel=E2=80=99s ROBUST design, I would say go for it.= There are others that say the transaction that must fail. The spec is ambi= guous on this point and any clarfication would result in a normative change f= or some. >=20 > 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. > =20 > Thanks, > =20 > Danny Zollner > =20 > From: Matt Peterson (mpeterso) =20 > Sent: Monday, July 11, 2022 11:35 PM > To: Nancy Cam-Winget (ncamwing) ; s= cim@ietf.org; Pamela Dingle ; Janelle Allen (ja= nelall) ; Danny Zollner ; P= hillip Hunt > Subject: [EXTERNAL] RE: IETF 114 preliminary Agenda and call for other age= nda requests > =20 > Nancy, > =20 > 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 c= ursor pagination (draft-peterson-scim-cursor-pagination).=20 > =20 > 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 m= y part to create a new revision of the draft to address 2 interoperability i= ssues that were raised on the mailing list last month. > =20 > -- > Matt > =20 > From: scim On Behalf Of Nancy Cam-Winget (ncamwing= ) > Sent: Monday, July 11, 2022 6:51 PM > To: scim@ietf.org; Pamela Dingle ; Janelle Al= len (janelall) ; Danny Zollner ; Phillip Hunt > Subject: [scim] IETF 114 preliminary Agenda and call for other agenda requ= ests > =20 > CAUTION: This email originated from outside of the organization. Do not fo= llow guidance, click links, or open attachments unless you recognize the sen= der and know the content is safe. > =20 > Hello SCIMers, > =20 > Here is the current proposed agenda and a call for other requests: > =20 > 5 min: Agenda Bash & Logistics > SCIM Chairs: Nancy Cam-Winget, Aaron Parecki > =20 > TDB min: Use Cases=20 > Pamela Dingle > =20 > TBD min: Protocol & Schema > Janelle Allen and Danny Zollner > =20 > TBD min: SCIM Events > Phil Hunt > AOB > =20 > @Pamela Dingle, @Janelle Allen (janelall), @Danny Zollner and @Phillip Hun= t: can you provide requested times to provide updates on the work above? > =20 > If there are other requests for agenda slots, please reply to this email o= r send a request to scim-chairs@ietf.org > =20 > Thanks, Nancy > =20 --Apple-Mail-51797475-D8C2-4F95-9F20-50F7D07DB8A1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Danny

The question remai= ns. Why not download the entire result set in one GET? 

<= div dir=3D"ltr">Phil

On J= ul 13, 2022, at 2:30 PM, Danny Zollner <Danny.Zollner@microsoft.com> w= rote:

=EF= =BB=BF =

Hi Phil,

 

On the topic of cursor-based pagination, I=E2=80=99m n= ot sure how it would conflict with the SCIM Events draft. I think this is a c= ase of different participants in the working group coming at the spec from d= ifferent use cases. In the case that I=E2=80=99m trying to represent, it=E2=80=99s a client/server model where a= client is trying to retrieve large amounts of data at once. In the same way= that some SCIM implementations may not wish to implement the SCIM Events dr= aft, cursor-based pagination as an optional extension to provide a method to break large amounts of data into smaller, more effic= iently consumable chunks should be fine. For those who cannot implement it d= ue to their own architecture limitations, they can potentially look at other= options for traversal of large amounts of data.

 

On the topic of multi-valued attribute pagination and= filtering, I (and Microsoft) are very interested in this, and from discussi= ons with some service provider implementers, I believe there is adequate int= erest. Specifically on the filtering piece, I recall that there was some previous feedback about the value of it= . I do not have a strong opinion on the filtering component, but given the p= ast feedback I was suggesting that it may be worth discussing. I=E2=80=99d l= ike the working group to discuss your draft, draft-hunt-scim-mv-filtering. If you=E2=80=99d like to present on it= I think that would be great, otherwise we can attempt to have someone else s= peak to it if that=E2=80=99s OK.

 

On the topic of change detection, this again may be a= case of different use cases and lack of precision in the terminology that I= used in my last email =E2=80=93 sorry for that. While ETAGs are helpful in s= ome circumstances such as version controlling when multiple actors may be interacting with the same resource, the problem= I=E2=80=99m hoping to see solved is different. Similar to the above profile= of a client/server model where a large number of resources are being retrie= ved, I=E2=80=99m proposing some form of change tracking that allows a client to request from a server =E2=80=9CReturn all o= bjects that have changed since some prior point in time=E2=80=9D. This of co= urse could also have filters applied, so you could structure requests like =E2= =80=9CReturn all users where department =3D Sales that have changed since some prior point in time=E2=80=9D. The problem is then =E2= =80=93 how do you represent that point in time? You mentioned detecting chan= ges either via ETAGs or via =E2=80=9Chas/has not changed since a specified d= ate=E2=80=9D. Having discussed this topic with some of my more senior coworkers, the feedback I=E2=80=99ve heard is that dates of any form= at (lastModified, etc..) are a bad choice as they are not monotonically incr= easing, and services backed by multiple physical devices (so.. almost anythi= ng operating at large scale nowadays?) won=E2=80=99t have consistent dates/times between them. The approach I=E2=80= =99ve got in mind right now would be a state cookie that is managed by the s= erver and is likely opaque to the client.

 

Finally, on the topic of version incrementing/changes= to the existing core schema and protocol docs, I am not advocating for incr= ementing the version or making any specific changes at this point, but rathe= r that we defer on this until later, as there is ample work in front of us with the dozen+ topics that can easil= y be implemented as extensions. We should start compiling a list of proposed= changes that have to occur in the core schema and protocol RFCs rather than= in an extension, and once we believe we=E2=80=99ve exhausted things there can discuss how best to implem= ent those changes at that time (the version increment/reissue 2.0/other opti= on discussion).

 

Thanks,

 

Danny

 

 

 

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 <Matt.Peterson@oneidentity.com>; Nancy Cam-Wi= nget (ncamwing) <ncamwing=3D40cisco.com@dmarc.ietf.org>; scim@ietf.org= ; Pamela Dingle <Pamela.Dingle@microsoft.com>; Janelle Allen (janelall= ) <janelall@cisco.com>
Subject: [EXTERNAL] Re: IETF 114 preliminary Agenda and call for othe= r agenda requests

 

I=E2=80=99ve put some comments below. These are discu= ssion items that presenters might want to include in their presentation.

 

Phillip Hunt

@independentid=

 <= /p>

 



On Jul 12, 2022, at 9:12 PM, Danny Zollner <Danny.Zollner@microsoft.com>= wrote:

 

I=E2=80=99d like to cover the following items related= to protocol and schema work:

 

  • Cursor-based pagination =E2=80=93 via Matt=E2=80=99s draft (that I somehow d= idn=E2=80=99t realize existed until last month!)

<PH> Much of the use case for this was to suppo= rt replication and co-ordination of events across domains. How does/doesnot t= his specification conflict with the SCIM Events WG draft?

 

I remain ocncerned about the resource costs for servi= ce providers and the denial of service attack vector that results.  I h= ave heard that many clients can=E2=80=99t hold a result set in memory. Fair e= nough. But in this case, would it be better to use a streaming parser OR simply store results direct to local disk for p= rocessing?

 

Why cursors are hard:  If a client has limited r= esources to store one result set, the cost to a service provider with thousa= nds of clients is multiplied and may not be possible.  In todays system= s, causing a SCIM service provider to hold temporary state over data impacts a cluster in many ways.  Today=E2=80= =99s 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 th= em) access to that result set likely needs to be shared.  If not the lo= ad-balancer has to maintain =E2=80=9Csticky=E2=80=9D connections so that eac= h client request goes to the same cluster node.  This could still lead to problems if the client is too slow and the connection i= s reset. As written now, SCIM servers don=E2=80=99t need to hold =E2=80=9Cst= ate=E2=80=9D across requests.  Implementing cursors would mandate a maj= or re-write for most implementations.  

 

There is also a mistaken assumption that we need pagi= ng because SCIM has a result size limitation. That=E2=80=99s not part of SCI= M Protocol. The spec simply permits service providers to set limits for thin= gs like Javascript UI clients. Presumably for a priviledged provisioning client, they ahve access to the enitre data s= et. It makes no sense to enforce a 1000 result set limit in these scenarios.=   

 

=E2=80=94> The problem is that many implementation= s make max results a server setting rather than an access control entitlemen= t.  This is not so much something we need to deal with. We may just nee= d to alert industry product managers of why they need to support provisioning clients properly.

  •  
  • Multi-valued attribute pagination =E2=80=93 Phil=E2=80=99s draft is a good p= lace 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 n= eeded, which is also included in Phil=E2=80=99s draft. Splitting multi-valued attribute pagination away from multi-valued attribut= e filtering if/when it is adopted by the working group may be the best choic= e.

<PH> The current draft re-uses aspects of SCIM t= hat already supports CMVA filtering. For this reaon, pulling the functionali= ty apart doesn=E2=80=99t make sense. AFAIK there are only a couple of reques= tors (e.g. Gregg Wilson/Oracle) for this draft.  Without wider support, should we drop the spec?

 

I wasn=E2=80=99t planning on presenting this. Please l= et me know if I should.

  •  
  • Discussion on change detection/delta query approaches =E2=80=93 I=E2=80=99ll= prepare some slides on this and may try to send out an email this week or n= ext week as well, but won=E2=80=99t have a draft for this by IETF 114.

<PH> The current SCIM Protocol spec indicates s= upport for ETAGs specifically in Sec 3.14 of RFC7644 (versioning resources) a= nd can be used in queries. In SCIM=E2=80=99s case an ETAG is a hash of the r= esource. ETAGs more broadly in HTTP allow a requestor to make queries or changes using HTTP Preconditions (RFC7232). &n= bsp;For example, you can do a GET conditional only on the resource having ch= anged. You can also condity a modify (PUT, PATCH, DELETE) on a resource bein= g unchanged (has a specific etag) or has/has not changed since a specified date.  I suspect pre-conditio= ns are not widely supported in many SCIM implementations.  I have imple= mented it in i2scim.io.

 

I am not sure if this is what you are really after, b= ut you may want to distinguish your requirement from the HTTP standard if di= fferent.  :-)

 

Also, SCIM Events intent is to notify subscribers of c= hanges 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 =E2=80=93 Janel= le is working on a draft for this, although I do not know if this will make i= t in time for IETF 114
  • My roles/entitlements draft =E2=80=93 it has expired but I=E2=80=99ll renew i= t and would like to put it up for a call for adoption. I don=E2=80=99t know i= f we need to figure out the contains/containedBy topic that I wrote to the m= ailing 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 t= his?)
    • Current plan is that we work on a bunch of the new features in the form of s= eparate extension drafts to SCIM 2.0, and leave RFC 7643 and 7644 alone for n= ow. Once we=E2=80=99re further along in the new features (i.e.: the above + o= thers from the charter) we can determine the final approach of how to make changes to the protocol and schema =E2=80= =93 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=E2=80=99t really seen a need to go= to SCIM 2.x or 3. Almost all the enhancements can be positioned as extensio= ns to the current SCIM 2 RFCs.  

 

Some of the discussion about extending groups etc sug= gest much more complex CMVA objects (e.g. verified claims etc). This is inte= resting. But I would prefer to simply deifne new objects rather than version= the protocol first.  There is also nothing saying you can=E2=80=99t have a group represented =E2=80=9Cvir= tually=E2=80=9D where extended schema is available at one resource path =E2=80= =9C/<extended>Groups/=E2=80=9C while =E2=80=9C/Groups=E2=80=9D holds t= he old schema version of the same groups.

 

The more complex extension would be to add meta data t= o attributes like roles.   In some systems, a role binding is actually a= policy that has thins like conditions and expiry dates.  

=E2=80=94> I guess what I am saying here is this t= opic deserves a lot of dinner time and hallway discussion over many glasses o= f wine and beers.

 

As for editorial clean ups, I am not sure myself what= the IETF permits moving from =E2=80=9Cproposed standard=E2=80=9D to =E2=80=9C= standard=E2=80=9D which is another possible route.   In particular, I t= hink many of the examples need to be improved as people depend too much on figures and have gotten mis-leading impressions.  Some of the f= igures need to better reflect the normative text intent.  I have a conc= ern that many don=E2=80=99t 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=E2=80=99s ROBUST= design, I would say go for it. There are others that say the transaction that must fail.  The spec is ambiguous on thi= s point and any clarfication would result in a normative change for some.

I think these topics could easily take an hour, if no= t more. Whatever time is not used by use cases or SCIM Events can be allocat= ed here.

 

Thanks,

 

Danny Zollner

 

From:&nb= sp;Matt Peterson (mpeterso) <Matt.Peterson@oneidentity.com> 
Sent: Monday, July 1= 1, 2022 11:35 PM
To: Nancy Cam-Winge= t (ncamwing) <nc= amwing=3D40cisco.com@dmarc.ietf.org>; scim@ietf.org; Pamela Dingle <Pamela.Dingle@microsoft.com>= ; Janelle Allen (janelall) <janelal= l@cisco.com>; Danny Zollner <Danny.Zollner@microsoft.com>; Phillip Hunt <phil.hunt@i= ndependentid.com>
Subject: [EXTERNAL]= RE: IETF 114 preliminary Agenda and call for other agenda requests

 

Nancy,

 

There has been recent activity on the mailing list (a= nd also discussion in the SCIM interest group before our chart) that shows c= ontinued interest in cursor pagination (draft-peterson-scim-cursor-paginatio= n). 

 

If appropriate for our charter, I would like one more= opportunity to check if cursor pagination is interesting to enough people t= o 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:&nb= sp;scim <scim-bounces@ietf.org> On Behalf Of Nancy Cam-Winget (ncamwing)
Sent: Monday, July 1= 1, 2022 6:51 PM
To: scim@ietf.org; Pa= mela Dingle <Pamela.Dingle@microsoft.com>; Janelle Allen (janelall) <janelall@cisco.com>; Danny Zollner <<= a href=3D"mailto:Danny.Zollner@microsoft.com">= Danny.Zollner@microsoft.com>; Phillip Hunt <phil.hunt@independentid.com>
Subject: [scim] IET= F 114 preliminary Agenda and call for other agenda requests

 

CAUTION: <= /span>This email originated from outside of the organization. Do not follow guidance, c= lick links, or open attachments unless you recognize the sender and know the= content is safe.<= /p>

 

Hello SCIMers,<= /o:p>

 

Here is the current proposed agenda and a call for ot= her requests:

 

5 min: Agenda Bash & Logistics

         = ;       SCIM Chairs: Nancy Cam-Winget, Aaron P= arecki

 

TDB min: Use Cases 

         = ;       Pamela Dingle

         = ;      &= nbsp;

TBD min: Protocol & Schema

         = ;       Janelle Allen and Danny Zollner

         = ;      &= nbsp;

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 w= ork above?

 

If there are other requests for agenda slots, please r= eply to this email or send a request to scim-chairs@ietf.org

 

Thanks, Nancy

 

= --Apple-Mail-51797475-D8C2-4F95-9F20-50F7D07DB8A1--