Re: [scim] Call for support on proposed SCIM/SINS (re)charter

Phillip Hunt <phil.hunt@independentid.com> Tue, 14 September 2021 17:04 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 574883A25D5 for <scim@ietfa.amsl.com>; Tue, 14 Sep 2021 10:04:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=independentid-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P18UzZUHS31c for <scim@ietfa.amsl.com>; Tue, 14 Sep 2021 10:04:49 -0700 (PDT)
Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C62313A07CB for <scim@ietf.org>; Tue, 14 Sep 2021 10:04:49 -0700 (PDT)
Received: by mail-pj1-x1030.google.com with SMTP id k23so100452pji.0 for <scim@ietf.org>; Tue, 14 Sep 2021 10:04:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=independentid-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=G7M1GJ8o8Wg/ndysnLSETAADWhpdpINhIRjRAcO6ep8=; b=Si8qQ41DK+vFifni216g5vkTY9C44i07C28M1HubpAv4Kew7v15xvyjeyQQJqI4fc6 m6Nxj3uIXk8Qf/qg39UmxyZvuM6CM4Tys+6BjICIV4eTv2ZXtYyEJssc6B0YyQzPDYcd 2MSx+P2H/b7kgP2oSOS4H0zVMtWNOatvBl/QesKxtgPS5h7Ke9qMkfJ96E0dgpNgkMpr 4zJHLhvywjA0TdfLazbk2f/i1Lf6rQsb0TPHG75EMOSuc/p+K4uvOpl4sqM1Cpp09ahc MSUZm9tMyNM/uWfEOlA9RT3p7YaWTcLNWcOk36mzxRE+/A9vhFYDkCKqlYN9dwBcHuS8 6Udg==
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=G7M1GJ8o8Wg/ndysnLSETAADWhpdpINhIRjRAcO6ep8=; b=D95dN29pl+jDfQQ/tcI4WuyKbr7TtuOQ+dUJKK6Af7TJgo97jaawF6ekzqnDsgc98q hHJI6fZHll0LTjA9Gz10iOWHYfPA/Xzyn0BuuBVYdIOy4VZG/+3A9N1WEyDyX3Wxmw6H 1ECmZCoUaEkXYM8Re4LPrgRRfew5O0t/vE6oGcK/FmQK4HidpD538uEyoPQfdwgfuQxN RllB7uLnLDg+/ujOQIkrIUmuFk5zbsw98lzUkc8UqMvjGtDK6k2JhX/mRGS+nLXIQvtY fHlZl6yoESKzvszPghO0bqqBUB7DnUMsnVMy+eRtjQo/AbPQanoKNHY6SZstmBGIXg+1 NSmQ==
X-Gm-Message-State: AOAM532mJYEiCBOary3/ypakoI9XDfk3HRMBxvAURJfqviXQTVX3/use 5YAf3FZmLDYs1r/JkzkAcJCsYg==
X-Google-Smtp-Source: ABdhPJye2v93K/E10C/cKPwSiKmjbaiFrDdP9edInfpj4y3S0olb+kWg87cCYzS4Cd0lHev4DKRH6Q==
X-Received: by 2002:a17:902:ab98:b029:12b:acc0:e18c with SMTP id f24-20020a170902ab98b029012bacc0e18cmr15901653plr.10.1631639088063; Tue, 14 Sep 2021 10:04:48 -0700 (PDT)
Received: from smtpclient.apple (node-1w7jr9plyoqwtbnshojyl4qph.ipv6.telus.net. [2001:569:540c:4900:50f2:5611:601c:8d35]) by smtp.gmail.com with ESMTPSA id y3sm2285987pjg.7.2021.09.14.10.04.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 14 Sep 2021 10:04:47 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-C5F09866-8FBF-4191-8108-51372D9AA88C
Content-Transfer-Encoding: 7bit
From: Phillip Hunt <phil.hunt@independentid.com>
Mime-Version: 1.0 (1.0)
Date: Tue, 14 Sep 2021 10:04:45 -0700
Message-Id: <AFA4C5C7-2F5A-413F-BF55-E6E6B7938075@independentid.com>
References: <1f7befb0-8f13-2b67-7447-9b65f738f5c9@pdmconsulting.net>
Cc: "Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com>, scim@ietf.org, "Matt Peterson (mpeterso)" <Matt.Peterson=40oneidentity.com@dmarc.ietf.org>
In-Reply-To: <1f7befb0-8f13-2b67-7447-9b65f738f5c9@pdmconsulting.net>
To: Danny Mayer <mayer@pdmconsulting.net>
X-Mailer: iPhone Mail (18G82)
Archived-At: <https://mailarchive.ietf.org/arch/msg/scim/pkj997O_N91TUKcgrlXx_HOM45g>
Subject: Re: [scim] Call for support on proposed SCIM/SINS (re)charter
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 14 Sep 2021 17:05:09 -0000

The authz token contains scopes that enable access. Part of the policy can be to allow unlimited or different limits to list responses.

Nothing says results sets are limited to 1000. The spec just says there may be limits. 

Phil

> On Sep 14, 2021, at 8:53 AM, Danny Mayer <mayer@pdmconsulting.net> wrote:
> 
> 
> I don't know what scenarios would require more than one ID for the scim protocol. You are not logging into the system, it's a REST service call, and only one system should be performing management on that system. What's the use case for more than one application making scim protocol calls?
> 
> Danny
> 
>> On 9/13/21 8:22 PM, Phillip Hunt wrote:
>> 
>> Ahem. Maybe just change the maximum results limit for privileged clients that need it?
>> 
>> Maybe this is a best practice item?
>> 
>> Phil
>> 
>>> On Sep 13, 2021, at 4:53 PM, Danny Mayer <mayer@pdmconsulting.net> wrote:
>>> 
>>> 
>>> The experience I've had in doing pagination mostly (but not exclusively) involved HR systems which had a 1000 per response limit but were not related to usage of scim. However any API call that returns a list can be subject to a limit by the scim server, most likely in order to preserve resources and not to tax the memory.
>>> 
>>> Danny
>>> 
>>> On 9/13/21 5:45 PM, Matt Peterson (mpeterso) wrote:
>>>> I agree.  
>>>>  
>>>> Pagination and Synchronization show up under the same bullet in the charter, but, like you, I think of them as separate (possibly related) topics.  I am interested in both topics. 
>>>>  
>>>> As proof, I’m hoping to get feedback from anyone that has additional pagination use case besides the “use of pagination for initial load of synchronized objects”:
>>>>  
>>>> Fetch all users and groups for the application side cache so that the application can use this cache to quickly make authorization decisions. ß Pagination
>>>> Incrementally keep the application-side cache of users and groups up to date with changes being made on the SCIM server.  ß Synchronization
>>>>  
>>>> One classic use case for pagination is to support pages of results in a UI.   Like Google search results.   Is anyone doing this?  
>>>>  
>>>> We aren’t.  For UI to find/search SCIM objects, we use a more modern  “Typeahead Find” pattern that is preferred by our users – and it does not require pagination.
>>>>  
>>>> Again… I don’t know all the use cases for pagination.  I’m sure there are more out there that are very relevant.  Step one is making a list of reasons people need pagination.   
>>>>  
>>>>  
>>>> From: Danny Mayer <mayer@pdmconsulting.net> 
>>>> Sent: Monday, September 13, 2021 2:27 PM
>>>> To: Matt Peterson (mpeterso) <Matt.Peterson@oneidentity.com>om>; Nancy Cam-Winget (ncamwing) <ncamwing@cisco.com>om>; Phil Hunt <phil.hunt@independentid.com>
>>>> Cc: scim@ietf.org
>>>> Subject: Re: [scim] Call for support on proposed SCIM/SINS (re)charter
>>>>  
>>>> 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.
>>>>  
>>>> Matt,
>>>> 
>>>> Synchronization and paging are different issues and should be handled separately. You may need paging for synchronization but that may not be the only case. I don't personally know of other cases but I would like to hear other people's experience of this so that the requirements be properly included in the draft RFCs.
>>>> 
>>>> Danny
>>>> 
>>>> On 9/13/21 11:02 AM, Matt Peterson (mpeterso) wrote:
>>>> Danny,
>>>>  
>>>> One of the goals of the workgroup is to understand what the pagination use cases are (besides initial loading of object set to be synchronized). 
>>>>  
>>>> I’m eager to start keeping track of pagination use cases.  Can you posting to the list the use cases that you are thinking of you’d need pagination for?   Thanks! 
>>>>  
>>>> From: scim <scim-bounces@ietf.org> On Behalf Of Danny Mayer
>>>> Sent: Friday, September 10, 2021 6:11 PM
>>>> To: Nancy Cam-Winget (ncamwing) <ncamwing=40cisco.com@dmarc.ietf.org>rg>; Phil Hunt <phil.hunt@independentid.com>
>>>> Cc: scim@ietf.org
>>>> Subject: Re: [scim] Call for support on proposed SCIM/SINS (re)charter
>>>>  
>>>> 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.
>>>>  
>>>> Pagination and synchronization are really different issues. Synchronization MAY need pagination but not necessarily. There are other reasons why pagination may be necessary.
>>>> 
>>>> Danny
>>>> 
>>>> On 9/10/21 8:00 PM, Nancy Cam-Winget (ncamwing) wrote:
>>>> Thanks for the feedback Phil.  I’m trying to determine proposed changes to the charter text…..I suspect there might have been a translation issue for synchronization being more about pagination than paging?
>>>>  
>>>> If you can provide suggested updates, it will be helpful to rally agreement for the updates too.
>>>>  
>>>> Best, Nancy
>>>>  
>>>> From: Phil Hunt <phil.hunt@independentid.com>
>>>> Date: Wednesday, September 8, 2021 at 6:34 PM
>>>> To: ncamwing <ncamwing@cisco.com>
>>>> Cc: "scim@ietf.org" <scim@ietf.org>
>>>> Subject: Re: [scim] Call for support on proposed SCIM/SINS (re)charter
>>>>  
>>>> Nancy,
>>>>  
>>>> Thanks for putting this together.
>>>>  
>>>> For this go around my interest lies mainly in Events and Synchronization and profiles.  I am willing to provide updated drafts for this process after some initial agreement on cases.  Drafts already in the archive (they may be fairly out of date!):
>>>>  
>>>> * SCIM Events - draft-hunt-idevent-scim  (needs to be updated to reflect the work we did in RFC8417)
>>>> * OpenId Connect Profile for SCIM - https://openid.net/specs/openid-connect-scim-profile-1_0.html
>>>>  
>>>> Regarding the MV-Paging draft.  This draft has nothing to do with synchronization and is intended for clients who need to pull a limited number of values in a multi-valued-attribute in situations such as large groups. Most typical use would be in building a user interface allowing the searching of MVAs.
>>>>  
>>>> As far as exploring using paging as a synchronization approach is not something we should explore (ie in the charter). IMHO this appraoch an anti-pattern.  If its needed, I am happy to add text in the best practices or elsewhere as to why this isn’t a great approach from the perspective of security, DoS, timeliness, scale, and cost.
>>>>  
>>>> That said, a couple people indicated they wanted stateful paging. Unfortunately they didn’t elaborate on a use case.
>>>>   
>>>> Phil Hunt
>>>> @independentid
>>>> phil.hunt@independentid.com
>>>>  
>>>>  
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On Sep 8, 2021, at 5:21 PM, Nancy Cam-Winget (ncamwing) <ncamwing=40cisco.com@dmarc.ietf.org> wrote:
>>>>  
>>>> Hello SCIM participants,
>>>>  
>>>> After some virtual meetings (thank you Pam for hosting these!) and discussion, there is a new proposed charter that addresses the points raised at the IETF 111 SINS session. 
>>>> This is a call for support of the charter defined below, please provide your response by Sept. 24, 2021. 
>>>>  
>>>> As you respond in support for the charter, please also specify if you are willing to produce, review and/or implement the resulting documents.
>>>> Otherwise, do provide feedback in the time window if there are concerns or issues you see with the charter below:
>>>>  
>>>> Charter
>>>> 
>>>> The System for Cross-domain Identity Management (SCIM) specification is an HTTP-based protocol that makes managing identities in multi-domain scenarios easier. SCIM was last published in 2015 and has seen growing adoption.
>>>> 
>>>> One goal for this working group is to shepherd SCIM, currently RFC series 7642, 7643, 7644, through the Internet Standard process. The group will deliver revised specifications for the SCIM requirements as Informational, and for the SCIM protocol and base schema suitable for consideration as a Standard. This work will be based upon the existing RFCs, errata and interoperabilty feedback, and incorporate current security and privacy best practices.
>>>> 
>>>> In addition to revising the requirements, protocol and base schema RFCs, the group will also consider additional specifications as extensions to SCIM that have found broad adoption and are ready for standards track. This includes profiles and schemas for interoperability in additional scenarios. The working group will develop additional Proposed Standard RFCs based on outcomes of the following work:
>>>> 
>>>> Revision of the informational RFC 7642 will:
>>>> Focus on Use cases and implementation patterns
>>>> Pull vs. Push based use cases
>>>> Events and signals use cases
>>>> Deletion use cases
>>>> New use cases may be added to the revised RFC
>>>> Revision of RFC 7643/44 will include:
>>>> Profiling SCIM relationships with other identity-centric protocols such as OAuth 2.0, OpenID Connect, Shared Signals, and Fastfed
>>>> Updates to the evolution of the externalid usage
>>>> Document SCIM support for synchronization-related goals between domains focused on:
>>>> Handling returning large result sets through paging, based on [draft-hunt-scim-mv-paging-00]
>>>> Incremental approaches to synchronization
>>>> Support for deletion-related goals including:
>>>> Handling Deletes in SCIM Servers that don’t allow Deletes (Soft Deletes) - based on [draft-ansari-scim-soft-delete-00]
>>>> Support for advanced automation scenarios such as:
>>>> Discovery and negotiation of client credentials
>>>> Attribute mapping
>>>> Per-attribute schema negotiation
>>>> Enhance the existing schema to support exchanging of HR, Enterprise group and privileged access management (using draft-grizzle-scim-pam as a base)
>>>>  
>>>> Best, Nancy (as one of the BoF chairs)
>>>>  
>>>> _______________________________________________
>>>> scim mailing list
>>>> scim@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/scim
>>>>  
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> scim mailing list
>>>> scim@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/scim
>>>> 
>>>> 
>>>> _______________________________________________
>>>> scim mailing list
>>>> scim@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/scim
>>>> 
>>>> 
>>>> _______________________________________________
>>>> scim mailing list
>>>> scim@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/scim
>> 
>> 
>> _______________________________________________
>> scim mailing list
>> scim@ietf.org
>> https://www.ietf.org/mailman/listinfo/scim