From nobody Wed Jul 13 09:42: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 9AE23C14CF1D for ; Wed, 13 Jul 2022 09:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=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 Me5N9uoqmR8Q for ; Wed, 13 Jul 2022 09:42:27 -0700 (PDT) Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (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 6092DC14CF16 for ; Wed, 13 Jul 2022 09:42:27 -0700 (PDT) Received: by mail-pg1-x534.google.com with SMTP id bh13so10959847pgb.4 for ; Wed, 13 Jul 2022 09:42:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=independentid-com.20210112.gappssmtp.com; s=20210112; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=XgW16OhmccZMGsH9PgyHFO3pUAppnk+QE4zkZz+xSIw=; b=qiRw7lELycxbHkMFJlmanisQKzMq6TjxkdiGWZjFwHDxqT923Sa0OWCB3vud0qQk3k mANCvpsMb6ACnd6pOSDwCoW9nYb8bYgcetKw3tcwknNI2AKreUoH5nMM5YKsJZbPW1mV KOoi+QyWuQXrJH2bIWX5bz0dgj9kfe7kfn5Uk0JJC6YCUbZApTIxUVzNym2b1G85489W MtAIxS91gSDreARWnmYJ64WZyETXlC5VIo6p233NNK+yg4wmwdiYYrTi+3OSRvnGS1LP FB0TvGFEmxeLaBV0fa2782rJWNVEJD2BmxtG7Fkbrqqi2oG96ire+QcSw+t4BD7O7rR8 KyZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=XgW16OhmccZMGsH9PgyHFO3pUAppnk+QE4zkZz+xSIw=; b=3tHB/EJtBEMhPfu7nGGkSdEE0dmmlTinVnKSOQg1As9WSxZ4bQo2xWnzp1Lcnad4yH m5CFcmeVMjPon2RXBsiFWM/DY/zKl94AGLsZUZHtCDiOhUzGXzKkxsS7jWdwC61u6sqj srqoUUc4+g2RLHGa+x3G7UbUFpqm8r6L+vpD9C0JfymXxFR8B3fozq0Fa6G2PPeyqmDi S1ig6eWVUenizE4m2oI9XXhrW73veDPwnIEfc3Rzr/ocE9j2waOYXdXSlT2507NHb5d9 n6WvFUvfQmNgJjIpQPGGX6qmv+7BKWeg11C9Hnl7YudPi5bvUJtj6/u4vhjjcdv5CFB5 tECA== X-Gm-Message-State: AJIora8ckiTy4E+uvLtw3Dx+b4Ab/G2MuZPmodzcWAfru1F37EuP3MPj 3uVtAAEg+A1kBnmDlbYt30hPbw== X-Google-Smtp-Source: AGRyM1tsATSivhK5+8E/Xt2eCofq41YWSv5e6zuN8qKIhbwqF/wuZZnhIu5rAZBw1wZLgzn2yGQudA== X-Received: by 2002:a65:6409:0:b0:416:f21:a651 with SMTP id a9-20020a656409000000b004160f21a651mr3718887pgv.300.1657730546593; Wed, 13 Jul 2022 09:42:26 -0700 (PDT) Received: from smtpclient.apple (d207-6-202-204.bchsia.telus.net. [207.6.202.204]) by smtp.gmail.com with ESMTPSA id u8-20020a1709026e0800b0016c1cdd2de3sm9053029plk.281.2022.07.13.09.42.25 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Jul 2022 09:42:25 -0700 (PDT) From: Phillip Hunt Message-Id: <949B6EF6-6923-4442-A439-CEE7B8D4F504@independentid.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_223A9EFF-B109-4EE3-B5EE-BB659A41A557" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\)) Date: Wed, 13 Jul 2022 09:42:24 -0700 In-Reply-To: Cc: Matt Peterson , "Nancy Cam-Winget (ncamwing)" , "scim@ietf.org" , Pamela Dingle , "Janelle Allen (janelall)" To: Danny Zollner References: <20B7C97B-6276-47EA-8531-0EB7467823BD@cisco.com> X-Mailer: Apple Mail (2.3696.100.31) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2022 16:42:32 -0000 --Apple-Mail=_223A9EFF-B109-4EE3-B5EE-BB659A41A557 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99ve 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 = wrote: >=20 > I=E2=80=99d like to cover the following items related to protocol and = schema 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-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=E2=80=99t 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=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 them) access to that result set 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 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=E2=80=99t need to = hold =E2=80=9Cstate=E2=80=9D across requests. Implementing cursors = would mandate a major re-write for most implementations. =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 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. =20 =E2=80=94> 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 =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 ago, I think there are questions on whether multi-valued = attribute filtering is needed, which is also included in Phil=E2=80=99s = 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. The current draft re-uses aspects of SCIM that already supports = CMVA filtering. For this reaon, pulling the functionality apart = doesn=E2=80=99t 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=E2=80=99t planning on presenting this. Please let me know if I = should. > 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 = specifically 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 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 =E2=80=93 = 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 =E2=80=93 it has expired but I=E2=80=99ll = renew it and would like to put it up for a call for adoption. I don=E2=80=99= 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=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 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. 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 extensions to the current SCIM = 2 RFCs. =20 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=E2=80=99t have a = group represented =E2=80=9Cvirtually=E2=80=9D where extended schema is = available at one resource path =E2=80=9C/Groups/=E2=80=9C = while =E2=80=9C/Groups=E2=80=9D 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. =20 =E2=80=94> 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 =E2=80=9Cproposed standard=E2=80=9D to =E2=80=9Cstandard=E2=80= =9D 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=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 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. > =20 > Thanks, > =20 > Danny Zollner > =20 > From: Matt Peterson (mpeterso) =20 > Sent: Monday, July 11, 2022 11:35 PM > To: Nancy Cam-Winget (ncamwing) ;= scim@ietf.org; Pamela Dingle ; Janelle = Allen (janelall) ; Danny Zollner = ; Phillip Hunt = > Subject: [EXTERNAL] RE: IETF 114 preliminary Agenda and call for other = agenda 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 cursor 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 my part to create a new revision of the draft to address 2 = interoperability issues 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 Allen (janelall) >; Danny Zollner >; Phillip Hunt = > > Subject: [scim] IETF 114 preliminary Agenda and call for other agenda = requests > =20 > 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. > =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 Hunt = : 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 or send a request to scim-chairs@ietf.org = > =20 > Thanks, Nancy --Apple-Mail=_223A9EFF-B109-4EE3-B5EE-BB659A41A557 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I=E2=80=99ve put some comments below. These are discussion = items that presenters might want to include in their presentation.

Phillip Hunt
@independentid




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 didn=E2=80=99t 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=E2=80=99t 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=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 them) access to that result set 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 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=E2=80=99t need = to hold =E2=80=9Cstate=E2=80=9D 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=E2=80=99s 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.   

=E2=80=94> 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 =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 ago, I = think there are questions on whether multi-valued attribute filtering is = needed, which is also included in Phil=E2=80=99s 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=E2=80=99t 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=E2=80=99t planning on = presenting this. Please let 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 next = week as well, but won=E2=80=99t 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=E2=80=99s 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 =E2=80=93 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 =E2=80=93 it has expired but = I=E2=80=99ll renew it and would like to put it up for a call for = adoption. I don=E2=80=99t 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=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 = 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=99= 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=E2=80=99t have a group represented = =E2=80=9Cvirtually=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 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.  
=E2=80=94> 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 =E2=80=9Cproposed standard=E2=80=9D to = =E2=80=9Cstandard=E2=80=9D 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=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 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=3D40cisco.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
          &nb= sp;     SCIM Chairs: Nancy Cam-Winget, Aaron = Parecki
 
TDB min: Use Cases 
          &nb= sp;     Pamela Dingle
          &nb= sp;     
TBD min: Protocol & Schema
          &nb= sp;     Janelle Allen and Danny Zollner
          &nb= sp;     
TBD min: SCIM Events
          &nb= sp;     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

= --Apple-Mail=_223A9EFF-B109-4EE3-B5EE-BB659A41A557--