►
From YouTube: IETF111-SINS-20210729-2030
Description
SINS meeting session at IETF111
2021/07/29 2030
https://datatracker.ietf.org/meeting/111/proceedings/
A
12
was
chartering
that
working
group
we
had
morteza
ansari
and
leif
johansson
as
the
chairs,
and
they
are
both
on
this
call
and
morteza
is
up
here
on
the
podium.
The
virtual
podium
co-chairing
this
one,
as
is
nancy
cam
inject
thanks
both
of
you
for
co-chairing
and
thanks
roman
de
niro,
for
sponsoring
this
buff.
A
So
the
the
goal
here
is
to
look
at
what
we've,
what
we
did
in
the
skim
working
group
update.
It
move
it
to
internet
standard
and
do
some
additional
things
that
are
necessary
and
we'll
go
over
that
all
in
the
next
hour
and
yeah.
We
are
at
the
top
of
the
hour,
so
welcome
to
the
ietf
111
sins
buff,
which
I
keep
thinking
of
pika
mundi.
But
I
guess
it
doesn't
work
anyway.
So
let's
go
ahead
and
get
moving.
A
The
note
well,
which
most
of
you
have
noted
well
already,
but
note
it
well
again,
if
you
are
unfamiliar
with
any
of
this,
please
read
the
relevant
documentation.
That's
referenced
on
this
slide
and
check
with
your
legal
team
if
necessary.
If
you
have
a
legal
team,
so
what
we're
going
to
do
here,
I
guess
I
should
turn
on
my
video,
so
you
can
get
a
picture
of
me
there
we
go.
A
So
what
we're
going
to
do
here
is
each
of
these
items
on
the
agenda
is
roughly
a
15-minute
slot.
We
have
an
hour
something
going
over
the
history,
how
we
got
here
and
where
we
intend
to
go
the
body
of
work
going
into
a
bit
more
detail
on
that,
and
then
we
will
review
the
draft
charter.
That's
been
floating
out
there
for
a
bit
and
talk
about
the
next
steps
and
look
at
how
whether
this
buff
accomplished
what
it
needed
to
accomplish.
A
So
with
that,
I'm
going
to
turn
this
over
to
ruler
and
hunt
there
we
go,
who
are
doing
the?
What
is
skim,
I
guess
phil
is
starting
us
off
because
he
has
joined
the
queue
so
go
ahead
and
unmute
and
head
head
forward.
A
Just
fine
phil,
if
you
put
your
audio
your
video
on,
go
ahead
and
do
that.
Otherwise,
it's
okay.
B
So
what
a
scam?
Let's,
let's
just,
go
back
into
the
next
slide!
It
started,
I
guess
when
it
started
actually
before
2012,
is
an
informal
project
where
people
were
recognizing.
They
needed
a
way
to
pre-provision
identities,
to
major
cloud
service
providers
like
salesforce.com
or
or
webex
and
and
other
services.
B
This
happened
around
a
time
when
roy
fielding's
restful
apis
were
taking
off,
but
I
think
one
of
the
things
that
were
happening
was
the
most
successful
apis
on
large
scale
were
asymmetric.
There
was
only
one
implementer
of
the
service
and
many
thousands
of
clients,
and
it
worked
quite
well.
What
market
was
seeing?
B
B
B
There
was
a
need
immediately.
Interrupt
issues
emerged
because
of
things
like
data
typing
agreement
on
data
typing
or
uniqueness
of
attributes,
mutability
of
attributes,
and
things
like
that.
So
the
group
came
together
and
formalized
decided
to
formalize
skin,
which
became
the
skin
to
initiative,
started
with
barry's
help
in
2012..
B
We
worked
for
four
years,
I
guess,
and
we
published
in
2015,
and
we
introduced
things
like
identifier,
stability,
the
notion
that
the
urls
don't
change,
they're,
fixed
agreement
on
skim
filters
that
allowed
you
to
query
json
structured
documents,
the
idea
of
complex
multi-valued
attributes,
which
now
allowed
us
to
have
equivalency
to
something
as
new
and
modern
as
vcards,
where
you
could
have
multiple
telephone
numbers
where
you
have
a
home
number
and
a
work
number
and
different
things
like
that
that,
in
comparison
to
old
protocols
like
ldap,
which
were
just
attribute
pairs
and
very
simple
in
comparison,
we
had
a
an
initial
allowance
for
paging,
but
the
paging
we
had
was
very
simple.
B
We
did
not
want
to
have
a
complexity
there.
We
recognized
that
skim
was
going
to
be
an
api.
People
would
implement
on
many
underlying
systems,
so
you
might
have
skim
in
front
of
a
payroll
system.
You
might
have
it
in
in
front
of
a
contact
management
system,
you
might
have
it
on
top
and
many
have
implemented
on
top
of
a
directory.
B
B
But
at
least
we
have
a
common
data
format
and
a
common
protocol
to
work
with-
and
I
think
that's
another
characteristics
of
skim
is
that
it
is
a
first
of
all
it's
a
profile
of
http,
which
is
broadly
capable,
but
it's
it's
a
profile
because
it
combines
a
json
document,
format
that
go
together
and
that
can
create
its
own
error,
signaling
and
formatting
problems.
B
Another
part
of
the
philosophy
that
skim
had
was
to
try
and
be
robust.
Now
I
know
that's
a
tricky
word
in
the
itf
these
days,
but
the
idea
was
that
when
you're
going
cross-domain,
not
every
attribute
is
of
interest,
for
example,
to
every
every
domain,
but
we
don't
want
to
make
the
client
developers
life
a
nightmare.
So
if
you
send
an
attribute
that
the
service
provider
isn't
interested
in
it's
free
to
ignore
that
attribute,
so
the
key
always
is
as
with
tcp.
B
B
We,
the
spec,
defines
rfc
7643,
defines
two
main
resources,
users
and
groups,
and
then
an
extension
which
demonstrates
how
you
can
extend
a
user
for
enterprise
claims.
Skim's
schema
structure
is
not
schema
in
the
xml
sense.
It's
really
there
to
tell
a
generic
document
handler.
What
are
the
claims
you
and
attributes
you
expect
to
find
in
this
document
and
where
to
go?
Look
for
them
so
that
there's
some
consistency
and
the
schema
extension
mechanism
allows
for
local
customization
and
an
easy
way
to
separate
the
standard
attributes
from
extensions
that
people
may
have.
B
So
nick
and
I
just
whipped
this
up
off
the
top
of
the
head-
there's
not
any
strong
data
behind
this
and
it's
controversial.
I
know,
for
example,
there
are
deployments
in
excess
of
50
million,
if
not
a
billion
now
in
size.
There
are
now
over
65
implementations
documented
at
simplecloud.info,
and
I
suspect
many
more
that
haven't
registered.
B
You
wouldn't
expect
many
people
who
are
building
their
own
implementation
for
their
own
purpose
to
necessarily
register
unless
they
were
sharing
it.
So
these
are
open
source
implementations
that
are
available
and
I
think
nick
made
a
guess
as
to
how
many
users
and
api
servers
might
have.
So
that's
where
I'll
leave
it.
I
think
if
there
are
any
questions
on
the
history,
I
can
help
you
with
that,
but
I
think
I'll
give
the
rest
of
the
time.
B
A
So
the
link
s
that
puts
us
into
our
second
section
body
of
work.
I
don't
remember
offhand
who's
presenting
that
bit.
Let
me
flip
back
to
the.
A
Agenda
slide:
do
we
have
a
lancia
lanciera
peterson
here,
matt
peterson?
Okay,
there
you
are
body
of
work
back
to
that,
carry
on.
C
All
right
thanks
so
much
phil.
I
think
you
did
a
great
job
of
recapping
where
we've
been
and
matt,
and
I
here
to
talk
a
little
bit
about
where
we
want
to
go.
So
if
you
go
ahead
and
go
to
the
next
slide
great,
so
as
phil
did
a
fantastic
job
of
laying
out,
you
know
the
history
behind
skim.
We
also
we
want
to
drive
things
forward.
There
are
definitely
some
new
and
emerging
use
cases
that
have
come
to
life
subsequent
to
skim,
2.0
and,
as
with
any
sufficiently
complicated
protocol.
C
There's
also
a
number
of
paper
cuts,
but
the
existing
use
cases
that
various
participants
in
the
sessions
we've
had
so
far
have
raised
up.
So
we
really
want
to
see
if
we
can
make
some
changes
to
the
protocol
or
make
some
proposed
changes
to
the
protocol.
That
would
address
some
of
those
things.
We
also
think
that
the
7643
and
7644
have
now
reached
the
level
of
maturity
that
they
truly
are
internet
standards,
and
so
we
want
to
drive
that
work
forward
as
well.
C
C
C
So
the
first
one
we'll
talk
about
here
is
I'm
just
going
to
name
these
off
at
a
high
level
and
then
matt
will
take
over
and
show
you
how
you
can
help
participate
in
this
conversation.
So
the
first
one
is
around
schema,
so
scam
is
operating
over
certain
domains
of
data
and
having
some
well-defined
schemas
around
that
we
think
is
one
of
the
things
that
might
be
useful,
one
of
the
schemas
being
hr
information
with
respect
to
privacy.
C
We
need
to
keep
those
considerations
in
mind,
but
also
exchanging
enterprise
group
information
and
things
like
privilege,
access
data
as
well.
There
are
a
number
of
pagination
drafts
that
that
matt
will
talk
about
here
in
a
second
he's.
Actually,
the
author
of
one
of
them
and
then
some
synchronization
related
functionality,
best
practices
for
the
use
of
an
external
id
that
exists
in
this
game.
Spec
today
privilege
access
management
more
broadly
and
then,
of
course,
we
want
to
be
open
to
thinking
about
things
that
we've
missed.
C
So
we
have
lots
of
really
smart
folks
participating
in
the
conversation
so
far,
but
entirely
it's
very
possible.
We
don't
have
a
monopoly
on
good
thinking
when
it
comes
to
skim,
and
so
we
want
to
be
made
aware
if
there's
any
other
pain,
points
or
emerging
use
cases
out
there
that
we
haven't
already
thought
of
or
discussed
next.
D
E
All
right,
I've
pasted
into
chat
the
url
that
you
see
on
the
slide.
It's
just
a
really
simple
collaboration,
app,
that's
called
padlet,
and
if
you
go
to
that
url,
you
should
see
something
that
looks
very
similar
to
the
screenshot
that
you
see
on
this
slide
and
I'm
going
to
switch
over
and
talk
to
the
padlet.
So
hopefully
everyone
can
just
open
another
tab
in
their
browser
and
go
to
that
url,
and
you
should
see
something
very
similar
to
what's
on
the
slide
here.
A
A
That
okay
now
grant
screen.
Okay,
there
you
go:
okay,
I'm
just
gonna,
see
this.
E
A
E
I
love
you
all
right,
so
this
first
tile
is
just
for
people
to
you
can
just
you
know,
click
the
like
button
or
you
know,
enter
in
a
little
message
to
see
if
it's
working
seems
like
a
few
people
have
tried
this
out
already,
but
if
you
want
to
just
check
to
see
if
it's
working
and
responding
to
your
mouse,
clicks
and
and
typing,
you
can
do
that,
while
people
are
doing
that.
The
first
question
that
we
wanted
to
ask
is
just
kind
of
a
general.
You
know
question
about
you
know.
E
Are
there
improvements
that
we
need
to
make
by
rechartering
the
skin
work
group?
Really
simple
question?
I
don't
really
think
we
need
too
much
commentary
there
unless
you're
really
interested
in
writing
something
because
there
will
be
an
opportunity
later
to
to
add
some
comments
about
specific
areas
of
interest.
E
I
I
don't
use
skim
at
all,
but
I
would
use
it
if
there
were
some
there's,
something
in
particular
that
it
had
that
that
I
need,
for
my
use
case,
all
right,
so
those
are
just
kind
of
our
general
questions
and
the
the
meat
of
what
we
want
to
talk
about
here
are
some
of
these
interest
areas
that
came
up
in
the
interest
group.
E
E
How
many
people
would
be
interested
in
just
additional
kind
of
standard
information
that
you
can
get
through
skim
things
that
have
come
up
have
been
like
hr
information,
enterprise
groups.
There's
things
about
enterprise
groups
that
are
that
are
maybe
important.
Maybe
owners
of
groups
a
description
of
a
group,
something
that
isn't
that
needs
to
be
standardized
in
a
way
that
is
interoperable.
E
Another
example
is
authentication
data
like
you
know
what
kind
of
authentication
types
are
available?
Maybe
certificates
and
keys
for
users.
So
if
you
have
interest
in
schemas
as
your
chance
to
vote
for
that,
and
if
you
have
a
specific
schema
that
you're
interested
in
just
add
a
comment
there
second
little
card
here
is
about
pagination
and
you
know
pagination
and
synchronization
related
functionality.
These
may
be,
like
might
actually
be
a
little
bit
related
and
I'll.
E
Explain
in
a
second,
but
just
generally,
pagination
is
about
receiving
large
result,
sets
in
an
efficient
way
a
way.
That's
both
efficient
for
the
server
and
also
the
client.
We
feel
like.
We
need
to
understand
what
the
use
cases
are
for
pagination.
You
know.
A
really
good
example
is.
Maybe
I
want
to
get
all
the
members
of
a
group
and
that
talks
to
multi-valued
attributes
can
be
very
large.
E
Do
we
need
to
page
those,
or
is
there
another
way
that
we
can
go
about
handling
that
same
use
case
and
not
need
pagination
for
that
use
case,
I'll
I'll
segue
to
synchronization
functionality,
because
one
situation
that
seems
to
require
pagination
is
a
common
pattern
that
we
see
in
implementation,
where
a
skim
client
wants
to
keep
a
copy
of
objects
that
they
retrieve
from
skin
local
to
the
application
for,
for
whatever
reason,
and
then
they
want
to
keep
that
copy
up
to
date
with
changes
that
are
being
made
on
the
provisioning
domain,
that
the
skim
service
provider
is
in
front
of,
and
this
synchronization
use
case
seems
to
be
really
popular
for
identity
management
systems
or
possibly,
for
applications
that
need
the
ability
to
enforce
authorization
based
off
of
changes
that
are
being
made
from
objects
that
they've
retrieved
using
skim.
E
That
could
be
groups,
group,
memberships
and
users.
The
the
really
difficult
scenario
is,
of
course,
when
users
are
deleted
or
group
memberships
are
removed.
That's
an
important
scenario
that
often
requires
a
large
amount
of
data,
at
least
in
the
current
spec,
to
be
transferred
in
order
to
detect
deletions
and
that's
where
pagination
comes
in.
How
do
I
page
through
all
of
those
results,
so
if
you're
interested
in
either
those
topics
give
it
a
heart?
E
And
if
you
have
any
specific
comments,
comment
on
those
in
rfc
7643
there's
a
section
on
external
id,
and
this
is
a
kind
of
an
interesting
scenario
where
we
want
to.
We
want
to
learn
what
people
are
doing
with
external
id.
This
can
be
really
confusing,
I
think
for
some
people
for
some
implementers,
like
what
should
I
use
for
external
id?
What
should
I
expect
back
for
external
id,
and
you
know
it's
it's
it's.
Basically,
you
can
read
it
here.
E
I
won't
read
the
rfc,
but
take
a
second
and
read
what
external
id
is
and
if
you've
implemented
a
skim,
client
or
skim
service.
You
probably
have
a
memory
of
of
having
read
this
and
maybe
some
questions.
Could
we
clarify
that?
Do
we
need
external
id?
I
think
that's
an
interesting
conversation
last
one
here
in
our
list
of
categories
is:
there's
a
draft
about
privileged
access
management.
E
This
is
specific
for
using
skim
to
manage
fine-grained
access
to
privileged
sessions
or
privileged
passwords
privileged
credentials
and
also
using
skim
to
grant
access
to
those
same
resources
and
would
like
to
know
what
kind
of
interest
there
is,
or
is
this
something
that
you
know
maybe
scheme
wouldn't
be
as
good
for
as
some
other
protocol,
but
there
is
a
draft
for
privileged
access
management
and
would
like
to
know
if
that's
something
that
we
should
pursue
now
I
guess
the
last
one
is,
you
know,
there's
some
other
interest
category
and
we
hope
that
we
get
some
feedback
in
here
and
if
we
have
time
maybe
hear
some
people
talk
about
interest
that
they
have.
E
E
C
Yeah
just
to
reflect
a
couple
things
I
saw
in
the
comments
here
so
bob.
Thank
you
very
much
for
raising
the
question
around
iot.
If
iot
was
mentioned
in
the
introduction,
it
may
have
been
either
me
or
someone
else.
Misspeaking
we
haven't,
we
haven't.
We
hadn't,
we
hadn't
thought
particularly
about
iot
as
a
use
case
around
skim,
but
I
think,
having
sat
through
the
danish
session
the
other
day
around
bringing
dane
authentication
to
iot
devices,
I
think
there
could
be
some
interesting
ways
in
which
skim
might
be
able
to
help
with
that.
C
So
thanks
for
thanks
for
raising
that
question,
though,
as
I
added
in
the
chat,
I
am
a
newbie
when
it
comes
to
understanding
dane,
so
I
might
not
be
the
best
person
to
answer
that
one
and
then
yeah
anything
else
in
the
chat
here
that
I
saw
not
anything
else.
You're
saying
here
in
the
chat.
A
C
Oh
thanks
phil
for
clarifying.
Yes,
you
had
mentioned
privately
extending
for
iot
for
their
own
use.
Yeah
no
standards
work
so
far
agreed
yeah.
E
Yeah,
there's
there's
a
couple
of
comments
on
the
padlet
that
if
we
have
time
I'd
like
to
hear
someone
talk
about
someone
mentioned
in
the
padlet
about
currently
we're
very
restricted
to
groups
and
any
provisioning
of
these
groups
to
entitlements
in
the
targets
is
not
possible.
E
There
you'd
have
to
get
in
the
queue
by
go
ahead.
A
Hear
you,
if
you're
are
you
still
muted,
maybe.
C
Okay,
we
in
register,
if
you're
able
to
speak,
but
please
please
do
so
just
to
just
guess
a
little
bit
of
what
you
might
have
been
getting
at
here.
You
know
some
of
the
schema
work
that
that
matt
talked
about
the
sort
of
the
very
top
one
here
in
the
padlet
talks
about
taking
information
of
various
kinds,
potentially
including
entitlement
data
and
figuring
out
how
to
exchange
that
in
a
standard
way
between
systems
using
skim.
C
So,
let's
give
pam
spec,
which,
which
matt
mentioned,
is
an
example
of
taking
entitlement
data
and
pushing
that
back
and
forth
between
the
two
systems,
extending
that
and
generalizing.
That
is
something
that's
also
envisioned,
as
essentially
being
part
of
the
work
here.
They
need
to
add
to
that.
F
No,
can
you
can
you
hear
me
now?
Yes,
oh
there,
you
are
sorry
about
that.
Yeah,
that's
exactly
right,
so
we
have
different
target
applications
like
you
know,
let's
take
a
example
of
aws
right,
aws
provisioning.
F
F
That
has
to
be
done
through
an
api
right
and
for
that
there
is
no
scheme
or-
and
that
is
just
one
example
right-
and
there
are
many
other
entitlements
that
are
being
provisioned
out
into
different
applications
like
for
ebs,
oracle,
ebs.
There
are
roles
and
responsibilities
and
so
on
and
so
forth.
So
I'm
just
trying
to
see.
Why
is
this
only
restricted
just
to
users
and
groups,
as
we
extend
that
beyond
provision
provisioning
of
just
these
roles,
we
should
also
be
able
to
provision
entitlements
as
well
as
part
of
the
scheme.
Payload.
E
Yeah,
I
think
that's
we'll
figure
out
a
way
of
summarizing
that
and
adding
it
in
darren.
Mcadams
said
mentioned
something
in
the
padlet
about
clarity
in
how
to
represent
reference
attributes
such
as
the
manager
attribute
and
enterprise
user,
which
point
to
other
resources
in
the
skim
service,
which
would
be
like,
maybe
another
user.
That's
the
manager,
we've
noted
inconsistencies
across
implementations.
D
D
Yeah
or
the
id,
so
you
sort
of
see
people
making
their
best
guess.
So
I
think
it's
the
some
missing
best
practices,
guidance,
perhaps
or
some
profiling,
or
just
some
way
to
sort
of
get
get
some
consensus
on
how
to
handle
those
things.
Okay,.
B
That
skim
only
defines
a
couple
of
objects,
as
I
mentioned
on
the
earlier
part
of
the
presentation,
but
that
wasn't
intended
to
restrict
it
to
those
objects.
B
B
Customers
want
things
like
expiry
dates
and
other
metadata
around
membership
in
a
group
or
a
role,
so
that
entitlements
can
expire
and
have
a
life
cycle
all
on
their
own.
It
increases
complexity,
but
I
can
understand
the
complexity
for
implementers,
because
if
it's
not
appearing
in
the
skin
service,
it
has
to
go
elsewhere.
B
H
I
mean
speaking
to
both
of
these
comments
about
schema.
The
other
thing
that
we
get
to
do.
If
we
can
bring
these
new
schema
extensions
to
the
forefront
is
we
can
do
interoperability,
testing
right,
and
so
I
you
know,
I
think,
there's
there's
both
a
reliability
advantage
to
that
kind
of
interoperability
testing
once
we
can
get
some
profiles
done,
but
also
there's
a
security
attribute.
You
know
security
piece
here
that
I
think
is
important.
H
So,
for
example,
if
we
look
at
the
hr
schema
right
that
hr
data
is
flying
around
now,
it's
just
flying
around
in
ways
that
are
proprietary,
so
you
know,
I
believe,
there's
an
advantage
to
you
know
making
the
the
requirements
around
sending
that
kind
of
data
more
rigorous
so
that
we
can
apply
better
rules,
especially
to
areas
where
we
know
there
are
important
security
privacy.
You
know
requirements
right.
It
means
the
entire
group
is,
is
examining
the
the
api
and
choosing
the
you
know
the
best
combination
to
fit
security
and
privacy.
E
A
C
I
just
said
we'll
we'll
leave
the
padlet
open,
and
so,
if
thoughts
occur
to
you
later
on,
feel
free
to
revisit
the
padlet
at
the
next
meeting
of
the
the
folks
that
have
been
meeting
to
put
this
together,
we'll
also
take
a
look
at
the
updated
padlets.
If
more
thoughts
occur
to
you,
please
please
add
them.
There.
A
Okay,
so
clickable
on
in
the
slides,
if
you
downloaded
them
and
displayed
on
your
screen
here,
is
the
link
to
the
charter
and
pamela
is
going
to
lead
us
through
a
charter
review.
So
go
ahead.
Hello.
H
Yes-
and
I
do
have
the
text
of
the
charter
on
a
slide-
that
we
can
look
at
in
one
second,
just
so
that
people
can
take
the
time
to
to
go
through
it.
It's
not
very
long,
but
these
are
some
of
the
desired
outcomes
that
we
spoke
of
in
our
you
know
in
our
bi-weekly
meetings
about
why
we
think
a
skim
recharter
is
valuable,
so
we
do
think
that
we
can
help
adoption
by
clarifying
some
of
the
concepts
right.
It's
not
that
the
concepts
were
bad
in
the
beginning.
H
H
The
other
piece
that
there
has
been
a
ton
of
discussion
about
is
paper
cuts,
so
the
small
things
that
are
preventing
people
from
easily
connecting
and
that
that's
another
outcome
we
we
think
we
can
really
affect
which
is
to
take
all
of
this
accumulated
knowledge
of
all
these
implementations
and
all
of
these
implementers
and-
and
you
know,
apply
that
knowledge,
and
then
you
know
there
is
a
question
of
optimization
as
well.
H
So
now
that
you
know
the
cloud
is
a
is
a
humming
place
since
2012
and
it
you
know,
there's
a
lot
of
understanding
around
developer
environments
and
developer.
You
know
how
developers
work,
how
clients
work.
Can
we
apply
those
to
make
things
more
performant
as
well
and
then
the
last
one,
of
course,
is
security
wise?
Can
we
up
the
level
of
security
by
default?
Can
we
give
people
better
security
guidance
given
our
current
world
and
our
current
reach
response
and
feel
free
to
raise
your
hand
to
to
comment
at
any
point?
H
A
H
H
A
A
H
Okay,
perfect,
so
so
the
first
thing
that
we
cover
here,
I
think,
if
you
go
to
the
next
slide
very,
I
think,
there's
a
sort
of
a
breakdown,
but
I
could
could
be
wrong
right.
So
the
real
question
here
that
you
know
there's
a
lot
of
things
we
could
do
and
there's
a
lot
of
really
great
proposals
on
you
know
for
drafts.
Some
of
them
have
been
around
for
a
very
long
time.
Some
of
them
are
already
well
implemented,
so
the
question
becomes:
what
do
do
we
do
first
and
how
do
we?
H
You
know
unfold
a
working
group
successfully.
So
you
know
these
are
the
things
that
you
know
the
group
has
discussed
around
what
to
do.
Obviously,
we
want
as
much
feedback
as
possible
and
barry
nancy.
I
don't
know
if
it's
worth
mentioning
this,
but
this
this
buff
has
been
set
up
as
a
non-work
group
forming
buff.
However
we're
you
know,
we
want
this
charter
to
be
mature,
we're
hoping
to
take
steps
immediately
to
do
a
work
group
forming
based
on
the
feedback
from
everyone
here.
H
I
I
wanted
to
quickly
comment
on
your
working
group
forming
non-working
group
kind
of
forming
yeah.
I
mean
that's
a
little
bit
of
kind
of
a
nuance
and
kind
of
finesse
if
we
can
get
strong
support
here
behind
the
charter
that
we're
about
to
talk
about,
that's
that'll,
be
a
great
signal
kind
of
for
me,
we'll
want
to
take
it
to
the
main
list
for
confirmation,
but
that
is
going
to
be
more
than
enough.
I
If
we
can
demonstrate
strong
interest
here
from
the
text
you
present
and
on
the
mailing
list,
confirming
that
we
we
don't
need
anything
more
to
to
potentially
proceed
to
to
chartering
with
the
isg
for
the
first
pass.
Thanks.
H
H
You
know
changing
the
language
to
be
more
modern
right,
so
talking
more
about
use
cases
where
there
could
be,
for
example,
skim
proxying
or
where
you
have
two
cloud
service
providers
talking
to
each
other
versus
talking
to
a
sas
app.
That
might
be.
You
know
a
leaf
node
if
you
will
so
we
want
to
really
make
it
clean
and
we
want
to
make
it
easy
for
people
who
adopt
to
understand
which
role
they
would
naturally
fall
into
right.
Are
they
pushing
data?
Are
they
pulling
data
right?
H
H
So
that's
really
that
first
work
item.
The
second
one
is
to
look
at
the
core
specification
and
to
understand
what,
if
anything,
we
need
to
change
about
that
core
specification.
So
you
know
this.
This
certainly
means
a
security
review.
Talking
about.
Have
we
put
enough
metadata?
Is
there
enough,
in
the
schema
of
the
metadata,
to
be
able
to
actually
create?
You
know
to
to
specify,
for
example,
which
oauth
paradigm?
H
You
know
how
to
get
an
oath
key,
for
example,
those
those
kinds
of
bits
and
pieces
are
what
we're
looking
at
and,
of
course,
in
this
case
this
is
where
we're
looking
at
the
paper
cuts
we're
getting
the
implementer
feedback,
we're
really
looking
at
where
the
pain
is
here,
so
that
we
can
eliminate
it.
H
H
We
don't
really
know
until
we
start
to
get
people
signing
up,
but
the
assumption
is
that
they're,
you
know
some
of
these
schema
extensions
will
be
very
popular
and
will
have
very
specialized
participants
and
then
the
next
one
is
extension
breakouts,
and
because
we
have
so
many
drafts
already
in
place
right,
we
will
have
to
make
some
choices
about
what
happens.
First,
we
don't
want
to
split
the
conversation
so
much
up
that
we
fragment
and
and
nobody
can
get
anything
done,
because
there's
too
many
things
happening
at
once.
H
So
you
know
that
work
item
has
to
involve
choosing
what
we
you
know,
choosing
the
right
options
to
go
first
and
then
creating
us,
a
streamlined
plan
for
how
we
work
through
all
of
the
things
that
the
working
group
has
appetite
for
and
then
last
but
not
least,
is
interrupt
testing.
So
we
are
really
hoping
that
you
know
the
whole
reason
why
we
want
this
thing
to
become
simpler.
H
A
A
J
So
the
schema
issue
it
it
feels
kind
of
dangerous,
because
from
what
I've
seen,
implementations
typically
do
a
lot
of
private
schema,
and
you
know
something
like
an
hr
schema.
J
It
feels
like
something
we
could
like
really
get
bogged
down
in
in
in
details
and
people
have
different
conceptions
of
what
constitutes
an
employee,
etc,
etc.
The
information
modeling
in
there
is
going
to
be
pretty
difficult.
I
think
I
would
be
very
careful
sort
of
taking
on
that
kind
of
work.
J
Even
things
like
enterprise
groups
that
I've
heard
mentioned
here
seemed
like
it's
full
of
of
sort
of
hidden
conceptions
of
and
sort
of
assumptions
about
what
the
group
should
be
and
not
be
so
I
would
you
know,
I
think
it
would
be
better
to
spend
time
trying
to
figure
out
ways
to
make
scheme,
implementations,
less
schema,
dependent
or
at
least
sort
of
more
schema
agnostic
or
more
schema,
where,
depending
on
what
you
want,
how
you
want
to
so
you
know,
if
I
buy
a
a
skim
product,
make
sure
that
I
can
load
schema
through
skim.
J
J
Where
I
can
actually
buy
a
skim,
implementation
or
a
sas
provider
and
then
dump
my
schema
onto
it
and
make
it
work
in
a
standardized
way
in
in
my
community
in
the
research
and
education
community
there
are,
there
are
like
tons
of
of
of
schema,
that's
sort
of
been
widely
deployed,
and
it's
been
around
for
for
for
a
long
time,
it's
never
going
going
to
get
like
itf
standardized,
and
it
will
never
get
sort
of
picked
up
by
any
of
the
major
vendors
right.
J
But
when
we
go
buy
products
we
would
like
those
schema
to
be
at
least
have
at
least
a
fighting
chance
to
get
to
be
deployable
on
standard
products.
So
you
know
having
like
less
hardwired
schema
in
skin
products.
I
guess
would
be
my
preference
instead
of
trying
to
come
up
with
us
like
a
the
smallest
common
denominator
for
for
hr
schema.
That
feels
like
a
waste
of
time.
G
K
K
Before
we
get
to
that,
I
have
one
more
question
for
pam,
because
I'm
a
little
bit
confused.
So
some
of
these
things,
so
I
heard
two
things:
one
is
sort
of
moving
it
into
sort
of
moving
the
skim
spec
into
standard
and
then
the
other
part
is
some
of
the
extensions
and
changes
and
I'm
not
quite
sure
which
one
is
the
priority.
K
Whether
compatibility
between
scheme
2.0
and
whatever
work
comes
out
is
requirement
like
how
hard
those
things
compare
and
also
on
the
last
sort
of
slide
that
we
were
looking
at
the
synchronization
stuff
wasn't
listed
and
having
been
involved
with
for
some
of
you
guys
that
are
old
enough
to
remember.
L
dupe
the
ldap
replication
working
group,
we
spent
years
working
on
it
and
it
ended
up
sort
of
going
nowhere.
So
how
much
do
we
want
to
work
on
that
in
synchronization?
How
much
the
work?
H
My
my
thought
was
that
this
will
come
as
part
of
sort
of
profiling,
the
roles
and
talking
about
the
original
roles,
but
you're
absolutely
right.
This
there's
tension
and
I
believe,
there's
always
been
tension
between
essentially
participants
who
want
to
use
scam
as
essentially
a
database.
H
You
know
who
basically
need
to
be
able
to
do
things
like
queries,
but
there's
also
folks
who
want
to
use
it
for
loosely
coupled
provisioning
and
there's
a
question
of
how
tight
how
tight
does
the
synchronization
have
to
be
between
the
you
know,
the
client
and
the
server
on
what
are
those
mechanisms
so
that,
for
example,
you
know
what
you're
talking
about
really?
Is
the
proposal
to
do
like
change?
Log
tracking?
H
I
don't.
I
don't
think
we
came
to
a
consensus
in
the
run-up
to
this
working
group
on
what
kind
of
work
you
know
I
that
was
a
a
topic,
but
not
a
topic
that
ran
to
the
top
of
the
flagpole.
But
if,
if
there's
anyone
else
in
the
group
that
would
like
to
state
more
about
that.
B
B
That
is
very
concerning,
because
it's
a
costly
way
to
do
things.
It
means
you're
dumping,
all
the
data,
every
synchronization
cycle,
so
if
you're
paying
for
bytes
of
transfer
and
the
risk,
any
kind
of
coordination
or
synchronization
approach
to
me
means
dealing
with
change
events
only
or
security
events
only,
and
so
I
do
think
it's
worth
building
a
consensus
first
on
what
is
the
problem
and
I
think,
a
subsequent
charter.
They
could
say
we
know
what
the
problem
is.
This
is
what
we
need
to
do
and
I
think
that
might
be
definable.
B
J
Yeah,
I
was
gonna
say
like
el,
duke,
let's
not
do
that
again.
What
I
would
like
to
add,
though,
is
that
I
think
there
is
there
is
a.
There
is
a
credible
sort
of
story,
around
notification,
maybe
basing
out
on
the
ident
identity
events,
sort
of
something
that
looks
like
security
events
or
identity
events
and
then
sort
of
not
going
for
synchronization,
but
going
for
change
notification
instead,
which
removes
a
lot
of
the
problems
around
authorization
of
data
associated
with
synchronization,
not
to
mention
some
multi-um
multi-master.
J
I
I
J
I
mean,
I
think,
a
lot
of
people
are
building
versions
of
sync
already,
because
it
is.
It
is
something
that
you
kind
of
need
to
do
in
so
many
situations
in
our
implementation.
We
we
found
that
we
did.
We
couldn't
deal
with
all
of
the
authorization
problems,
so
we
sort
of
boiled
it
down
to
reduce
the
problem
to
to
notification
or
the
synchronization.
A
L
A
All
right,
I
think
we
clearly
have
a
critical
mass
of
of
skim
folks
who
want
to
proceed
with
this.
I
don't
think
I
really
need
to
ask
the
do.
We
have
authors,
questions
and
stuff
like
that,
because
I
think
we
have
evidence
of
that
from
a
number
of
drafts
that
are
out
there,
and
I've
already
asked
the
question
of
whether
anyone
would
not
want
to
see
a
working
group
along
these
lines
chartered.
A
So
I
think
we
have
what
we
need
for
the
buff
discussion
of
the
charter
and
the
work
that's
proposed
will
continue
on
the
mailing
list,
which
is
skim
ietf.org
and
what
I
would
like
to
see
if
this
proceeds
to
a
working
group
is
rather
than
having
a
working
group
with
a
new
name.
Have
the
working
group
called
skim
rechartered
with
a
fresh
charter
nancy?
Do
you
have
any
comments.
G
I
I
think
I'll
I'll
just
echo
that
I
would
think
that
the
next
steps-
very
I
don't
know
if
I'm
undercutting
you,
but
given
that
there's
been
enough
discussion,
it
seems
like
the
next
step
is
to
get
the
feedback
to
get
the
charter
more
tightly
clarified.
G
I
think
roman
had
mentioned
the
two
steps
of
the
body
of
work
that
we
should
be
focusing
on.
So
if
people
can
look
at
the
charter
and
and
think
about
what
that
body
of
work
should
be,
is
that
well
articulated
there
or
are
there
things
that
we
need
to
remove
and
then
the
second
piece
of
that
is
how
we
prioritize
it.
A
Yes,
yeah
and
clearly
that
can
go
two
ways
we
can
put
in
a
first
set
of
work
and
say
that
we're
going
to
recharter
to
continue
with
other
work
or
we
can
just
lay
it
all
out
in
this
charter,
but
put
a
priority
on
and
say
that
this
work
will
happen
only
after
this
initial
work
is
complete
so
that
we
can
bash
all
that
out
on
the
mailing
list.
But
let's
yeah,
let's
proceed
that
way.
A
A
I
No,
I
I
would
have
just
first
off
thanked
the
proponents
and
the
chairs
for
the
immense
amount
of
preparation
you
did
in
picking
up
all
this
material,
and
I
think
the
conversation
that
was
just
had
about
next
steps
is
exactly
right.
You
know
the
charter
appears
to
me
to
be
relatively
close.
I
think
we
need
to
talk
about
priority.
There
are
some
talk
a
little
bit
about.
I
A
You
and
I'll
repeat:
roman's
thanks
to
the
proponents
for
being
so
organized
and
getting
a
good
presentation
and
a
good
off
set
up
here
and
to
my
co-chairs
for
helping
helping
chair
it.
So.
A
See
you
all
in
gather,
town
and
other
sessions.