►
From YouTube: IETF-SCIM-20220511-1930
Description
SCIM meeting session at IETF
2022/05/11 1930
https://datatracker.ietf.org/meeting//proceedings/
B
C
A
B
B
A
B
B
B
Welcome
everybody.
This
is
an
actual
virtual
interim
for
the
system
for
cross
domain
identity
management,
and
I
know
I
need
to
change
the
name.
I
don't
know
if
I
need
to
change
it
on
the
on
the
on
the
itf
site
too,
to
the
sim.
Somebody
will
have
to
remind
me
the
eye.
Simple
cloud.
Identity
management,
I
think
is,
is
what
it's
for,
but
anyway.
B
B
B
So
with
that,
I'm
going
to
jump
in
straight
through
I'm
going
to
thank
danny
and
phil
since
we're
running
meet
echo.
I
think
the
jabber
just
goes
through
the
chat,
so
I
will
try
and
monitor
that
as
well.
Aaron.
I
don't
know
if
you
can
through
your
mobile,
but
folks
just
there's
only
a
few
of
us
on
the
call
just
call
me
out
if,
if
somebody
has
put
a
comment
or
question
there,
that
needs
to
be
called
out.
B
B
Awesome
great
okay,
so
with
that
in
mind,
I
had
updated
the
agenda,
but
I
didn't
have
enough
time
to
upload
it.
So
I
have
not
heard
back
from
pam
and
I
don't
see
her
on
the
call.
So
this
may
be
a
short
call
unless
somebody
can
speak
to
the
progress
danny.
I
don't
know
if
you've
been
working
with
pam
on
the
use
cases
as
well.
A
A
D
A
B
B
Janelle
sent
her
apologies
for
not
being
able
to
make
it
at
the
last
moment,
but
danny
she
mentioned
that
you
could
provide
the
update,
and
so
that
will
leave
us
plenty
of
time.
So
we'll
kick
off
with
danny,
providing
the
updates
and
then
what
I
added
to
the
agenda
is
phil
has
provided
two
drafts
in
our.
I
call
it
reflector.
B
B
B
B
B
D
D
To
share
it's
like
it's
just
mostly
words
so
yeah
I
tried
to.
I
guess
I
just
want
to
provide
an
update
where
we're
at
with
the
the
schema
and
the
protocol
work.
So
for
anybody
who's
not
aware
it's,
I
think
both
janelle's
and
my
first
time,
like
really
doing
much
of
anything
in
the
standards
world
and
we've
gotten
hit
a
little
bit
by
that
problem
of
like
how
do
you
eat
an
elephant
and,
like
you
know,
like
yeah,
you
have
to
figure
out
where
to
take
the
first
bite
right.
D
So
we've
I,
I
think,
made
a
little
progress
and
on
like
how
we're
approaching
things
at
least-
and
I
sent
out
an
email
this
morning
to
the
the
mailing
list,
just
sort
of
saying
like
what
things
we
at
least
have
some
idea
of
like
what
direction.
We
think
they
should
go.
What
things
probably
need
further
discussion?
D
I
would
be
overjoyed
if
anybody
has
any
strong
opinions,
feelings,
anything
any
any
passion
for
any
of
the
items
on
the
agenda
if
anybody
wants
to
to
join
in
authoring
any
drafts.
Otherwise,
this
might
be
a
bit
of
a
long
and
lonely
process
for
for
janelle,
and
I
but
yeah,
I
think,
the
sorry
god,
jeremy.
F
D
D
We
have
converted
the
the
skim
spec
into
markdown,
or
you
know,
cram
down
and
uploaded
that
into
the
github
as
sort
of
like
newer
editors
who
aren't
particularly
you
know,
I
guess
comfortable
working
in
xml.
It
seemed
like
an
easier
way
both
for
for
any
work
that
janelle
and
I
would
do
as
well
as
just
sort
of
increasing
the
accessibility
of
anybody
who
wants
to
jump
in
and
propose
edits
or
changes
or
whatnot.
D
So
yeah,
the
existing
schema
and
protocol
docs
for
76,
43
and
44
are
now
in
markdown
and
are
in
the
github
there's
still
some
formatting
things
that
need
to
get
taken.
Care
of.
I've
learned
a
lot
about
markdown
during
this
process,
but
not
all
of
it.
So
if
anybody
sees
any
things
that
that
don't
look
right,
please
share
your
skills.
D
Beyond
that
yeah
I
provided
that
list
of
of
the
the
the
major
pieces
of
work
that
we
have
some
form
of
idea
on,
and
I
I
think
for
the
ones
that
don't
already
have
drafts
that
cover
them
from
phil
that
we'll
try
and
have
some
sort
of
at
least
basic
framework
draft
out.
Even
just
you
know
enough
to
get
the
ball
rolling,
I
think
for
a
lot
of
things.
D
There
are
multiple
valid
approaches
to
how
to
you
know,
solve
a
problem
and
whether
we
stick
to
specific
you
know,
one
specific
one
or
multiple
to
you
know
allow
for
sort
of
different
scenarios
for
implementation.
I
think
that's
something
that
we
can
discuss
once
we
have
that
structure
in
place,
but
yeah
I
I
don't
have.
D
Now
I
was
just
gonna
say
I
I
don't
really
have
any
other
sort
of
like
major
earth
shattering
developments.
Any
super
exciting
news
to
share
other
than
I
think,
we've
gotten
a
lot
of
the
sort
of
that
initial,
like
bootstrapping
or
whatever
you'd
like
to
call
it
of.
How
do
we
start
approaching
these
figured
out
now
and
hopefully
we'll
be
able
to
then
capitalize
on
that
to
have
more
progress
in
the
upcoming
weeks
and
months.
B
Okay,
the
the
question
that
I
was
going
to
ask
I've
not
had
a
chance
to
look
at
the
github
repo,
but
basically
you're,
starting
with
the
current
rfcs
as
the
base
and
updating,
because
that
was
one
of
the
discussions
we
had
earlier
on.
I
think,
as
we
had
just
chartered
whether
we
would
create
brand
new
drafts
or
just.
D
Yeah
so
in
the
interest
of
sort
of
we'll
say
making
progress
and
actually
solving
problems,
the
way
that
I
figured
we
could
approach
things
is
to
start
for
any
of
the
new
major
features
by
writing
them
as
standalone
drafts,
and
then
at
some
point
we
then
figure
out.
Do
we
publish
these
solely
as
extensions
to
2.0?
Do
we
start
merging
them
into
the
base?
D
Also
one
of
my
colleagues
at
microsoft,
mark
wahl
his
take
on
it
as
well
is
that
2.0
was
written
as
an
extensible
like
standard
and
that
if
we
were
to
go
towards,
you
know
just
sort
of
immediately
say:
okay,
we're
doing
3.0
that
it
would
potentially
harm
adoption,
because
you
know,
if
there's
news
that
you
know
3.0
is
coming
in
with
two
years
or
whatever
it
doesn't
really
drive.
People
to
want
to
adopt
in
that
two-year
period,
if
they're,
just
gonna,
have
to
redo
a
lot
of
engineering
work.
D
B
D
D
B
B
So
thanks
for
that
update
danny,
if
you
can
please
post,
I
think
you
did,
but
if
you
can
echo
the
github
link
to
where
the
documents
are
just
so
that
people
can
just
click
on
it
for
ease
which
I
think
you
might
have.
No,
I
think
you
put
the
links
to
cram
down
but
to
the
actual
repo
that
you've
started.
D
B
B
F
E
D
So
with
those
two,
I
think
almost
no
matter
what
we
do,
even
if
we
end
up
going
towards
a
new
version
of
skim,
we
may
very
well
start,
at
least
with
that.
You
know
the
2.0
dock
and
start
writing
from
there,
even
if
it
ends
up
looking
nothing
the
same,
but
for
use
cases.
My
understanding
from
conversations
I've
had
with
pam
is
it's
almost.
I
think
a
complete
rewrite
like
starting
from
scratch.
F
B
E
It's
so
the
the
github
think
of
that,
as
just
like
the
the
working
area
to
do
whatever
you
want,
it's
basically
a
free-for-all.
It's
fine
to
do
anything
in
there
and
it
is
only
semi-official
because
it's
within
the
ietf
github
sort
of
realm,
but
none
of
that
really
is
part
of
the
official
process
until
they're
published
as
drafts
in
the
data
tracker.
So
that's
when
it's
more
important
to
get
the
naming
convention
and
stuff
right
of
the
docs,
but
generally
they
will
be
because
they're
not
adopted.
E
B
E
D
D
B
B
E
D
E
B
E
C
B
E
D
B
Already
thanks
aaron
for
helping,
of
course,
okay.
So
I
think
we're
on
to
the
next
piece
of
the
agenda,
the
added
revised
agenda
so
phil.
We
started
the
conversation
on
the
mail
list.
You
asked
interest
in
adopting
the
two
drafts,
the
multivariate
filtering
and
the
skim
profile.
Sorry,
skim
events,
I
think,
is
yeah
skip
events.
B
A
No
there's
not
been
any
for
the
multi-value
filtering.
There
hasn't
been
any
really
substantial
discussion
about
the
draft
itself
and
people
might
not
be
familiar
with
the
process
that
it's
okay
to
do
that
that
they
should
do
that,
and
I
so
one
concern
I
have.
I
I've
had
a
change
in
jobs
since
I
originally
wrote
it
a
few
years
ago
and
at
the
time
it
went
in
skims
charter,
the
ib
decided
to
close
chim
skin
before
it
was
done,
so
it
kind
of
didn't
make
a
rechartering
back
then.
A
A
My
concern
is
to
make
sure
there
is
actually
enough
interest
that
people
would
would
read
the
draft
and
implement
it
to
prove
it,
and
I'm
not
sure
there
is.
I
think
people
are
saying
I
don't
object,
but
I
still
would
like
to
see
more
in
it
and
I'm
not
I'm
not
in
a
position
anymore
to
say
one
way
or
another
on
behalf
of
anyone,
so
I
sort
of
feel
awkward
about
pushing
something
forward
when
I'm
not
sure
anybody
would
actually
implement
it.
A
I
think
oracle
has
and
that's.
Okay,
it's
it's
a
compatible
extension,
but
I
would
like
to
see
that
people
use
it
and
I
think
the
part
of
the
issue
is
skim
is
meant
for
provisioning
oracle's,
one
of
the
companies
using
skim
as
a
directory
and
therefore
needs
multi-value
filtering
for
things
like
user
interfaces,
that
coded
in
javascript
or
what
have
you,
and
so
that's
a
useful
feature
for
that,
and
so,
if
people
are
interested
or
not,
I
sort
of
leave
it
wide
open.
A
B
D
Yeah
I
started
taking
off
my
editor
hat
for
and
putting
on.
Like
my
you
know,
microsoft
chat
or
whatever
I
I
100
think
we
need
this
feature,
and
I
think
there
is
the
interest
there,
even
just
from
that
like
provisioning
aspect,
even
if
it
hasn't
been
articulated
very
well
or
you
know
very
vocally
on
the
mailing
list.
A
B
Okay,
so
maybe,
instead
of
doing
a
call
for
adoption,
is
call
for
interest
in
the
topic
so
interest.
Sorry,
I'm
I'm
also
trying
to
take
notes,
because
both
you,
who
are
going
to
be
note
takers,
are
mainly
speaking
interest
to
author
interest
to
implement
interest
to
review
okay,
we
can
do
that
for
this
draft
jeremy,
I
see
you're
in
the
queue.
A
A
I
think
it's
fine
standing
on
its
own
because
it
could
get
published
sooner
if
you
put
it
into
this
skin
best
work
I'll
call
it
that
could
delay
it
several
years
so,
and
I
was
also
thinking
it's
a
fairly
straightforward
extension.
What
we'll
need
to
do
work
on
is
re-review
any
security
implications
and
privacy
implications
and
just
general
editorial
cleanup,
so
two
places
for
comments.
One
is,
I
would
say,
first
of
all,
comment
on
the
mailing
list
so
that
we
can.
A
E
I
can
try
to
clarify
that
so
yeah,
the
the
urls
on
data
tracker
are
meant
to
be
the
actual
snapshots
of
the
drafts,
as
does
us
as
a
group
have
decided
to
to
publish
once
it's
an
adopted
draft
as
an
individual
drop.
It's
up
to
the
authors
to
do
that.
Those
are
the
ones
that
are
intended
to
be
sent
out
to
people
to
review.
So
that's
the
url
to
say
like
go
read
this.
This
is
the
current
state
base,
your
opinions
and
and
suggestions
on
this
document.
E
B
B
Erin
is
correct
that
the
mail
list
is
the
official
channel
for
us
to
communicate,
but,
as
the
number
of
issues
that
need
to
be
addressed
may
grow,
there's
tools
that
can
help
simplify
and
github
has
become
one
where
the
issues
becomes
the
way
for
us
to
track
right.
The
things
that
we
need
to
address
on
those
particular
documents,
and
particularly
again
coming
back
to
the
authors
right,
the
authors
are
ultimately
responsible
for
ensuring
that
all
of
those
issues
get
addressed.
E
E
Sometimes
that
feedback
is
very
easy
just
to
just
incorporate
into
into
the
document,
with
no
real
discussion
needed
and
other
times
it's
going
to
be
something
that's
going
to
take
a
long
time
to
to
resolve,
and
you
kind
of
just
know
that
as
the
author
of
the
document
and
in
those
cases
you
can
pull
those
into
github,
you
can
just
copy
them
paste
them
into
github
as
individual
issues.
That
way,
it's
easier
for
you
to
keep
track
of.
E
B
Hold
on
so
we
still,
we
are
still
waiting
for
a
document
to
get
adopted
and,
as
danny
is
presented
right,
we're
still
trying
to
work
through
as
a
group
of
what
those
issues
are
once
there's
a
document,
then
you
can
point
to
the
data
tracker
right,
but
jeremy,
I
would
say
the
the
issues
that
you
want
to
bring
forward.
You
should
definitely
go
through
the
official
channel,
which
is
the
mail
list.
B
B
But
again,
official
channels
are
in
the
iepf
data
tracker
and
the
mail
list
for
new
work
and
for
adopted
work,
and
so
currently,
since
we
have
only
met
officially
twice
as
a
working
group,
we're
still
ramping
up
to
get.
You
know
the
core
of
the
work
adopted,
the
core
being
the
use
cases
and
the
protocol
and
schema.
B
B
A
But
within
a
domain
when
you're
doing
things
like
replication
and
event
coordination,
you
have
many
listeners
and
many
publishers
and
a
bus
organization
for
managing
streams
makes
more
sense,
which
is
not
something
set
is
capable
of
doing
so.
I
wanted
to
call
out
and
describe
those
two
use
cases,
but
I
didn't
really
want
to
solve
the
problems
and
the
spec.
A
The
idea
is
to
define
the
events
and
then
you
could
go
and
use
kafka,
which
has
all
the
conflict
mitigation,
backup,
storage
and
restoration,
and
then
there
are
many
other
bus
technologies
as
well
plus
then
there's
set.
If
you
want
to
go
point
to
point
which
does
have
a
standard,
I
lost
the
battle
somebody
raised
the
question
of,
but
we
want
one
way
to
do
everything.
A
I
fought
that
battle
hard
four
years
ago.
In
the
security
event,
token
group
and
our
skim
proposals
were
knocked
out
of
the
park
by
the
ietf
set
group,
and
even
then
the
set
working
group
ended
up
with
two
drafts
for
transmission,
not
one
so
that's
a
battle.
I
think
we
should
avoid
getting
into
solving
things
one
way,
because
I
think
the
use
cases
are
substantially
different
and
we'll
get
into
boundaries
where
people
don't
want
others
saying
how
they
do
replication
and
others.
A
All
we
want
to
do
is
say
it's
possible
and
you
can
exchange
these
messages
with
this
format
and
that's
standardized,
and
then
people
can
choose
to
wire
up
their
infrastructure.
How
they
choose,
I
think,
what's
most
important
for
interop
is
the
point
to
point
or
domain
to
domain,
and
I
think
those
are
things
we
should
talk
through
as
use
cases.
A
A
A
Oh
and
danny
you
brought
up
the
async
event
and
whether
it
should
be
pulled
out,
so
it
can
be
its
own
thing.
I'd
be
interested
to
see
what
you
think.
The
relationship
is
between
the
clients
that
that
invoke
an
asynchronous
operation
and
how
the
notification
comes
back.
Does
it
come
back
to
the
same
client
ignore
the
mechanics
for
now?
A
But
if,
if,
if
I'm
a
client,
I
make
a
request,
is
it
only
me
that
gets
the
response,
or
is
it
a
central
service
that
gets
the
response
in
your
case,
that
was
something
we
started
talking
about
on
the
list,
and
we
should
keep
talking
about
that
because
it's
a
good
point
that
maybe
it
should
be
a
separate
thing
or
maybe
it
just
fits
in
there.
I
don't
know,
but
I'll
I'll,
leave
that
to
you
danny
to
to
to
to
push
push
your
requirements
one
way
or
the
other.
D
Yeah,
like
I,
I
I
think
the
way
that
your
draft
has
defined
asynchronous
requests
and
how
to
then
you
know,
communicate
through
the
eventual
outcome
back
with
set,
makes
sense,
and
you
know,
but
I'm
trying
to
like
color
this
through
the
glasses
that
I,
with
almost
anything
that
really
did
have
almost
no
idea
what
I'm
looking
at,
but
the
yeah.
I
guess
the
sort
of
requirement
that
I
was
trying
to
think
around
was
more
of.
I
guess
it
would
be
a
single
party
getting
like
a
response
back
later.
D
If
there
was
no
other,
you
know
need
for
them
to
use
that
or
that
they
didn't
want
to
do,
and
in
my
mind,
that
probably
comes
down
to
you
know
you
make
a
request,
the
as
a
client,
the
server
responds
back
to
the
202,
and
then
we
find
a
very
basic
scheme
or
whatever
for
a
response.
That
includes
some
sort
of
transaction
id
that
can
then
be
redeemed
against
a
defined
endpoint
later.
A
A
Some
services
will
take
a
few
minutes
and
what
you
want
to
be
able
to
do
is
while
you're
taking
the
user
through
the
workflow.
You
want
to
get
that
notice
back,
so
you
can
let
the
workflow
advance
in
the
ui
and
and
that
there
means
that
an
individual
client,
that's
doing
a
very
specific
operation
is,
is
just
getting
a
response
back
to
to
coordinate
a
ui.
So
that's
one
use
case.
Another
use
case
might
be.
D
A
Would
say
one
thing
for
everybody
to
note
that
a
lot
of
cases
we
have
to
think
about
whether
things
are
a
point-to-point
relationship
between
a
client
and
a
server
or
whether
we're
talking
about
things
in
the
context
of
multiple
clients,
multiple
receivers,
multiple
nodes
and
all
these
kinds
of
things.
So
that's
in
part
why
some
of
these
issues
aren't
so
easy,
because
it's
not
just
a
simple
protocol
anymore
they're,
we're
now
talking
about
streams
of
events
and
who
are
the
receivers
and
who
are
the
senders.
B
I
think
that's
good
advice.
Okay,
with
three
minutes
left,
I
can
pose
a
similar
question,
fill
to
what
we'll
do
with
the
multi-value
filtering.
If
that
will
help
you
get
direction,
I
think
you
had
one
response
on
the
mail
list
from
danny
that
there
is
interest
for
the
for
the
skim
events,
but
we're
gonna
need
more
thanks.
Danny.