Skip to main content

Minutes interim-2022-scim-01: Wed 15:30
minutes-interim-2022-scim-01-202205111530-00

Meeting Minutes System for Cross-domain Identity Management (scim) WG
Date and time 2022-05-11 19:30
Title Minutes interim-2022-scim-01: Wed 15:30
State Active
Other versions markdown
Last updated 2022-05-13

minutes-interim-2022-scim-01-202205111530-00

May 11, 2022 19:30-20:30UTC SCIM Virtual Interim

Agenda Bash

Danny Zollner presents updates to SCIM RFC's

Update on schema and protocol work.

Just getting started with Janelle as a newbie. Requesting feedback to
the current documents posted on GitHub :)
Have converted the SCIM specs into Kramdown and posted in GitHub.

Jeremy Palenchar: interested in the schema, especially details to how
client implement. Volunteers to review what is in the document for
feedback.

Nancy: there was a discussion early on whether we start with current
drafts and edit vs. start with new documents.

Danny: It is still a bit unclear as to whether this is a 2.1, 2.0, or 3.
2.0 was written as an extensible standard and so it is not clear if 3.0
is warranted if it disrupts adoption. Let's first try not to make
breaking changes.

Nancy: in the interest of making progress let's not worry about the
choice for now. We can take feedback from the rest of the participants.

Danny: I can see pros and cons from both sides.

Question about putting links in github. https://github.com/ietf-scim-wg

Aaron: This is repository is just for the group and is not part of the
official IETF process.

General discussion on permission problems for editors etc in github.
Repos are public and anyone can pull from it and submit a pull request
(except for the editors who can work directly).

Aaron: who is primary author?
Danny is primary author for both api and schema

Phil:
https://datatracker.ietf.org/doc/html/draft-hunt-scim-mv-filtering-00.html

no substantial discussion to the multivalue filtering draft. But as time
passed, Greg Wilson from Oracle is interested in co-authoring but unsure
of his level of activity. Concern if there's interest to implement and
do it. But would like to see it move forward personally as it's a
compatible extension. Part of the issue is that SCIM's targetted to
provisioning vs. a directory where Oracle's interest lie. Phil remains
neutral.
Danny as Microsoft: believes this feature is needed. There is interest
even in the provisioning aspect. Believes there is interest.
Nancy: can do a call for interest in the topic, (a) interest to author
(b) interest to implement (c) interest to review
Jeremy: can review and make an informed decision
Phil: comment on the mail list
Jeremy: I see the link, are we tracking on GitHub or are we tracking
somewhere else?
Aaron: URL in datatracker are actual snapshots for us as group have
decided to be for public review. Mail list is the official place for
feedback. The GitHub is the author's too to manage the process for the
drafts to be worked.

Phil: https://datatracker.ietf.org/doc/draft-hunt-scim-events/
Following from last official meeting, questions were raised that are
covered in the non-normative section of the draft. There are two methods
described as examples: domain to domain as a single stream, but within a
domain with event replication with many listeners and publishers so a
pub/sub would be needed which is not what SET was designed for. But
those are not in scope for the actual sharing of the information as
there are many bus technologies. Phil lost battle of "I want a single
method for communicating in all ways", the SET ended up with two drafts
to address the use cases and want to avoid having to repeat that path.
What's most important for interop is the domain to domain which should
be discussed in use cases. Can be done prior to adoption. Phil expects
that some advisory text will be needed for the transport
recommendations. Would like to have a co-authors as he will be
challenged in traveling.
Danny raised the async event to be pulled out as a separate draft; would
like to understand the behavior. If a client requests, is it only the
client or a service that gets the request? If that's the case, then
maybe it should be considered as a separate topic.
Danny comments: as the draft defines the async requests makes sense but
will try to understand requirements better.
Phil: tried to describe it as a use case; e.g. a UI setting up an
account. Some services do it instant vs. a few minutes. In the workflow
would like to provide some level of feedback; so individual client doing
a specific operation can get feedback to respond to UI. Another system
could be using a whole stream of transactions and needs to reconcile
which has a different set of requirements.
Danny: was thinking of the latter example.
Phil: need to think about client to client vs. multiple clients,
recievers and nodes as the group considers proposals.
Nancy: can post similar call for interest to the mail list.