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

From: Roman Danyliw <[email-masked]>
Date: Wed, 15 Sep 2021 21:33:43 +0000

Hi!

Various discussion is underway to refine this charter scope.  Endorsements of the charter are also coming.  Both are essentially for us moving forward so thanks for the feedback and keep it coming.

What I'm proposing below are largely editorial recommendations to improve the clarity of the intended scope; ensuring we maintaining flexibility; and catch common IESG/community feedback during the charting process.

More inline ... 

> On Sep 8, 2021, at 5:21 PM, Nancy Cam-Winget (ncamwing) <ncamwing=[email-masked]> wrote: 

[snip]

> 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.

Paragraph 1:
-- the IESG often looks for the RFCs numbers of the prior work up front
-- Make clear that SCIM is actually both a protocol and schema

Rough replacement text:

The System for Cross-domain Identity Management (SCIM) specifications provide an HTTP-based protocol (RFC7643) and schema (RFC76744) that makes managing identities in multi-domain scenarios easier.  Since its publication in 2015, SCIM has seen growing adoption.

> One goal for this working group is to shepherd SCIM, currently RFC series
> 7642<https://datatracker.ietf.org/doc/html/rfc7642>42>,
> 7643<https://datatracker.ietf.org/doc/html/rfc7643>43>,
> 7644<https://datatracker.ietf.org/doc/html/rfc7644>44>, 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.

Para 2:
There is benefit to first establishing what we want to do and why before jumping directly into process.  IMO, we're focusing a little too much on document maturity here.  As a practical matter informational documents don't follow the same maturity (Section 4.* of RFC2026).  I also see value in streamlining the intent is vague way to give us flexibility on what will get updated.

Rough replacement text:

The first goal of this working group is to incorporate implementation experience; errata and interoperatiblity feedback; and current security and best practices into a revised version of RFC7643 (protocol) and RFC7644 (base schema) suitability for consideration as the Internet Standard level of maturity.

> 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. 

Para 3:
-- is there a reason we have to restrict ourselves to extensions which are standards track?  Would there be no reason to publish some profile or extension as something as experimental or informational?
-- it seems like we also want to explicitly thread that there is likely schema/protocol work do in support of the new use cases.

Rough replacement text:
Additionally, implementation experience with SCIM has surfaced new use cases and requirements.  The WG will document them in a revision of RFC7642. The WG will also consider publishing extensions to SCIM that have found broad adoption. These extensions may include profiles and schemas for interoperability in additional use cases.

> The working
> group will develop additional Proposed Standard RFCs based on outcomes of
> the following work:

As noted above I think this gets caught up in whether it extensions need to be PS and it didn't follow for me to reference the information requirement doc.

Rough replacement text:

The scope of the WG will include:

>   *   Revision of the informational RFC 7642 will:

s/informational RFC 7642 will/RFC 7642 that will/ to be consistent with the document status being omitted in the next bullet.

>      *   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:

Nit.  s/RFC 7643\/44 /RFC 7643 and7644 that/

>      *   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<https://tools.ietf.org/id/draft-grizzle-scim-pam-ext-00.html> as a base)

Nit.  s/using draft-grizzle-scim-pam as a base/, based on [draft-grizzle-scim-pam]/ for consistency with the style of "based on [draft-... ]" used above

In addition to this charter prose above, explicit milestones will be needed.  Ideally this would enumerate each document that's planned to be made; it's proposed status; and rough date associated with either it going to WGLC or the IESG.  For example, "2023-Jun: (Informational) Revision of RFC7642 to WGLC".  There is no prescribed format here beyond a date and text blob.

Regards,
Roman

> Best, Nancy (as one of the BoF chairs)