►
From YouTube: IETF92-SCIM-20150326-1740
Description
SCIM meeting session at IETF92
2015/03/26 1740
A
For
instance,
sam'l
profiles
and
ldap
mappings
and
those
things
haven't
really
gotten
traction.
Nobody
stepped
up
to
write
them
some,
and
so
we,
you
know,
set
on
a
couple
of
occasions
that
it
somebody
doesn't
come
up
with
a
draft
we're
going
to
ask
to
cut
them
from
from
from
our
shorter
and
and
we're
actually
asking
very
to
allow
us
to
cut
them
from
our
shorter.
A
A
B
C
There's
a
camera
now
so
yeah
we've
been
talking
about
something
like
this
for
a
while
I
guess
next
slide
almost
since
we
started
with
skim,
let's
go
to
the
introduction
and
I
was
actually
sort
of
rereading
the
use
case
document
and
right
there
in
the
use
case
document.
Is
this
concept
called
triggers
because
we've
been
talking
about
spontaneous
state
changes
and
wanting
to
know
about
the
state
changes
before
deciding
what
to
do
so
in
our
current
mandate.
This
really
talks
about
triggers
evolve
into
actions
that
are
taken
which
becomes
the
skin
protocol.
C
So
really
what
we
want
to
do
here,
then,
is
provide
that
triggered
formalize,
that
trigger
mechanism
which
can
be
used
to
feed
data
back
to
a
provisioning
system,
which
then
decides
what
it
wants
to
do,
and
it
may
in
turn,
do
more
skin
operations
somewhere
else.
In
response
to
that,
so
that's
that's
where
we're
coming
from
next
slide,
so
two
extreme
cases
on
the
spectrum
one
end
to
let
domains
coordinate
with
each
other
when
changes
have
occurred.
C
Another
one,
though,
could
be
a
very
simple
subscription
against
one
resource
so
that
a
mobile
app
can
know
that
the
users
profile
has
changed
for
some
reason
and
that
it
should
go,
get
the
information
or
we'll
just
pass
the
app
the
information.
So
there
can
be
a
feed
that
describes
one
individual
or
it's
going
to
one
place,
and
you
can
have
feeds
that
might
represent
your
entire
repository
and
you
could
have
thousands
of
updates
per
second.
C
So
that's
sort
of
the
extreme
thing,
and
there
are
probably
many
use
cases
in
between
a
lot
of
it-
comes
from
our
customers
who
want
to
coordinate
things
that
are
happening
in
their
enterprise
domain
and
things
that
are
happening
independently
in
the
cloud
and
they
may
want
to
set
up
rules.
If
this
changes
in
the
cloud
we're
going
to
do
something
on
our
side
to
coordinate
that
what
that
is
really
depends
on
what
the
business
scenario
is.
So
it's
not
just
a
simple
because
their
name
changed
or
their
role
changed
here.
C
C
So
the
general
architecture
is
one
where
we
define
a
notification
hub,
which
is
receives
events
from
the
skin
service
provider.
That
can
be
actually
the
same
server,
but
the
idea
is
to
be
able
to
offload
the
work
of
delivering
those
messages
and
figuring
out
which
subscribers
need
to
be
notified
once
an
event
has
occurred.
C
We'd
rather
have
event
messages
just
be
delivered
for
those
that
are
interested
and
have
a
service
take
care
of
that
one
of
the
things
we
talked
about
this
in
Hawaii
and
we
said
well,
doesn't
web
push
do
this
and
it
does.
But
it's
really
the
delivery
mechanism
and
what
we're
talking
about
is
sort
of
the
information
plan
related
to
skim
as
to
how
I
define
a
feed.
What
are
the
messages
and
so
forth
and
then
to
us
web
push
is
just
one
possible
way
to
deliver
it.
C
Another
two
possibilities:
sort
of
in
a
restful
model
is
I'll
call
it
call
back
where
the
hub
does
an
HTTP
POST
to
a
subscriber
or
if
I
got
to
go
across
a
firewall
and
prize
might
do
an
hdb
get
to
pick
up.
Events
on
some
frequency
that
get
means.
Then
the
notification
hub
has
to
be
concerned
with
how
many
events
can
its
store
over
a
period
of
time.
C
We're
dealing
with
registries
in
a
lot
this
week
so
come
on
wrong
standard.
Okay,
next
slide,
so
typical
slint
skim
on
the
left,
a
state
change
or
a
trigger
occurs,
and
the
provisioning
system
says:
okay,
I
need
to
update
my
local
repository
and
I
need
to
update
the
other
domain
and
so
forth.
That's
the
normal
skin
flow
next
slide.
C
What
we
want
to
do
is
set
up
some
process
whereby
the
enterprise
can
be
notified,
that
something's
changed
now
that
could
include
the
actual
data.
That's
changed,
there
might
be
just
John.
Bradley's
record
has
changed.
You
figure
out
what
you
want
to
do
so,
eventually
the
event
message
gets
sent
back
to
the
provisioning
controller.
It
interprets
that
and
then
decides
what
it
needs
to
do
with
that
event,
which
means
maybe
updating
its
local
repository
next
slide.
C
C
C
Then
we
have
to
create
another
high
level,
one
that
seems
to
come
up,
and
this
will
also
sort
of
come
up
a
bit
in
more
Tesla's
presentation
on
soft
delete.
The
idea
of
activate
and
deactivate
I
think
is
a
relationship
between
instead
of
doing
a
delete,
you
might
do
a
deactivate
and
a
deactivate
really
is
a
business
concept.
That
says
this
is
what
we
mean
by
deactive
like
its
status
inactive,
but
there
seems
to
be
that's
an
important
event
to
track
independently
of
this
specific
data
has
changed,
modified
delete,
password
change.
C
There
are
requests
to
notify
and
to
do
it
for
password
syncing,
which
I
do
not
like
as
a
deliverable,
but
it's
there.
So
we
can
talk
about
it
and
then
I
have
a
confirmation
type,
which
is
a
special
type
that
notify
needs
when
you're
trying
to
set
up
a
connection.
The
subscriber
you
just
want
to
confirm.
Can
you
hear
me
now?
Can
you
hear
me
now
if
I
got
the
right
endpoint,
so
that's
more
of
an
administrative
detail,
so
that's
just
the
where
it
is
now.
C
C
You
have
a
publisher
URI,
where
the
skin
service
provider
thinks
what
feeds
this
is
relevant
for,
and
so
then
the
notification
hub
can
say:
well,
it's
relevant
to
these
two
feet.
I'll
start
delivering
that
and
figuring
out
who
the
subscribers
are
the
resource.
Your
eyes
is
what
what's
the
resource
that
was
affected
and
then
what
was
the
operation
there
was
to
create
and
the
ID
name,
username,
password
and
emails,
was
modified
or
set.
C
C
C
There
in
the
document
there
are
five
models
for
defining
a
feed,
so
you
can
have
a
static
feed.
That's
more
like
a
group,
you
just
put
objects
in
it.
You
could
have
a
dynamic
feed.
The
question
I
have
about
that
is:
what's
the
cost
to
the
server
but
calculating
all
your
dynamic
feeds
every
time
so
I
came
up
with
five
different
models
for
feeds
and
I.
Think
that's
one
thing
we
have
to
talk
through
as
a
group.
C
The
in
this
one
shows
you
that
we
could
put
raw
data
and
in
the
spec
I've
said,
if
you
feel
you
must
send
raw
data,
then
it
should
be
encrypted.
So
the
way
we
actually
send
this
is
to
encode
it
into
a
JWT.
So
in
this
case
we
would
actually
encrypt
it
as
well,
so
I've
put
stuff
around
signing
and
encrypting
to
secure
the
message.
So
the
idea
is
now
I
can
have
a
message
it
gets
delivered
to
multiple
subscribers.
C
The
hub
is
that
really
the
trusted
entity,
because
it
has
to
encrypt
the
message
for
each
entity
to
make
sure
that
the
correct
subscriber
got
it
so
we've
had
to
work
through
what
are
some
of
those
issues
and
what
would
that
look
at?
So
we
have
all
this
Jose
technology
we
can
use
so
I'm
proposing.
We
just
do
that,
and
that
gives
us
them
the
ability
to
push
these
messages
out.
/,
AP
NSF,
that's
what
we
want
to
do,
and
we
don't
have
to
worry
about.
C
It's
my
assertion,
though,
that
a
lot
of
times
you
don't
need
to
send
the
raw
data.
It's
enough
for
many
of
the
provisioning
systems.
To
simply
know
the
state
has
changed,
this
resource
has
been
modified
and
then
the
provisioning
system
does
it
get
if
it
thinks
it's
important.
Does
it
get
and
said?
Tell
me
about
the
current
state
now
I'll
decide
what
I
need
to
do
to
reconcile.
C
If
you're
curious,
there
is
from
the
Hawaii
presentation
some
material
about
how
just
because
a
modify
occurs
in
one
domain
doesn't
mean
it's
the
same,
modify
in
the
other,
so
I
went
through
some
theory
on
that.
I
talked
about
it
a
little
bit
in
the
draft,
but,
for
example,
it
delete
in
one
domain
is
not
necessarily
a
delete
in
the
other.
Take,
for
example,
your
its
say
it
Salesforce
and
my
crm
role
has
disappeared.
So
it's
a
delete
in
Salesforce.
It's
not
a
delete
in
my
home
domain.
C
So
that's
what
I
mean
by
reconciliation
and
why
eventing
is
useful
next
slide.
So
the
next
slide
is
there's
a
JWT
encoded
message.
It's
not
really
useful
here.
But
the
point
is
this:
that's
what
the
speck
is
calling
for
and
that's
the
container
like
slide
I-
think
that's
it
so
I
didn't
want
to
spend
too
much
time
because
we
didn't
have
that
much
time.
But
if
anybody's
read
the
spec
I
can
answer
questions
I
think.
The
ultimate
goal,
though,
is
to
decide.
Do
we
want
this
on
the
Charter
going
forward.
D
A
A
E
C
That's
talked
about
in
the
spec,
although
I
don't
think
it's
fully
addressed
yet
it's
a
starting
point.
We
have
to
go
back
to
what's
the
model
for
a
feed.
How
do
you
define
the
feed
one
of
the
one
of
the
reasons
why
I
think
it's
it's
not
a
great
thing
to
pass
data
is
that
your
access
control
model
becomes
dramatically
simple.
C
If
I
just
say,
John
Bradley
record
has
changed,
I,
don't
have
to
get
into
a
lot
of
processing
about
which
fields
can
I
tell
you
about
and
all
of
that
kind
of
stuff,
so
it
makes
it
faster.
If
I
do
decide
to
send
you
data,
then
I
should
have
to
check
an
access
model
to
see
whether
you
can
be
told
about
that.
But.
E
C
E
F
F
The
soft
delete
came
up
as
one
of
the
requirements
that
we
wanted
to
deal
with
and-
and
we
never
really,
even
though
it
sort
of
was
high
on
on
everybody,
that
implemented
it,
or
at
least
a
bunch
of
folks
that
implemented
that
we
never
really
got
to
write
it
down.
I
know:
various
implementation
have
addressed
this
in
different
ways,
and
the
discussion
was
about
whether
we
want
to
sort
of
French
standardize
it
or
not.
They're
really
sort
of
two
big
drivers
for
this.
One
of
them
is
essentially
referential
integrity.
F
We
we
use
sort
of
the
ID
notion
for
references
for
obvious
reason
and
then,
once
you
have
the
record
gets
deleted.
Then
how
do
you
say
when
which
has
uploaded
a
file
into
box
and
mortiser
deleted?
Because
he's
no
longer
employee
of
this
company,
I
still
want
to
see
more
Tesla's
name
on,
as
the
person
had
uploaded
sort
of
the
ownership
and
sort
of
you
know,
a
lot
of
other
things
might
be
transferred
to
somebody
else
or
administrator
or
something.
F
But
you
still
want
to
see
where
the
comments
or
a
lot
of
sort
of
historical
data
or
webex
sort
of
fee
no
recordings
or
somebody
that
sort
of
you
know
schedule
the
WebEx
meeting
or
whatever.
So
there's
a
lot
of
that
referential
integrity
that
that
becomes
really
important
and
then
the
second
part
of
it
is
restoration.
We
actually
sort
of
you
know
in
our
implementation.
We
hit
this
with
our
first
very
first
deployment,
which
was
actually
our
own
IT
department.
F
Somebody
accidentally
went
and
wiped
out
a
whole
bunch
of
record
out
of
active
directory,
and
we
had
a
connector
that
was
sort
of
sending
stuff
to
the
cloud,
and
then
they
said
oops
and
then
they
went
and
sort
of
you
know
created
a
new
connector
and
then
started
creating
a
whole
bunch
of
new
thousands
and
thousands
of
new
users
and
becoming
brand
new
users
which
are
not
connected
to
any
of
existing
objects.
So
everybody
got
new
ID
and
oh
wow
sort
of
you
know
you
had
all
these
like.
F
F
Next,
the
basic
concept
is
really
about.
We
want
sort
of
all
the
clients
that
do
really.
This
is
model
after
what
we
did
with
sort
of
a
lot
of
the
ldap
extends
a
lot
of
sort
of
ldap
control
extension
extended
controls
that
we
had
on
in
the
ldap
world.
We
want
all
the
clients
that
don't
know
anything
about
skim
to
sort
of
you
know
continue
to
operate
as
skin
course
game
specifies
it's
just
that
the
semantics
of
that
object
is
really
different.
F
So
a
client
that
doesn't
know
anything
about
softly
can
still
do
a
query
and
see
all
the
objects
that
are
not
deleted,
not
soft
deleted,
but
it
doesn't
have
any
ability
to
see
a
soft
deleted
objects
unless
it's
aware
of
the
extension.
Similarly,
if
I
do
a
delete,
I
just
want
to
see
that
record
gone.
So
if
I
do
a
delete
followed
by
a
read.
F
I
should
not
see
that,
if
I'm
not
requesting
for
the
soft
deleted
options
but
and
as
a
result
of
that,
I
should
be
able
to
sort
of
do
the
classic
I
create
more
teza
I
delete,
martez,
oh
and
then
I
create
more
teza
again
I
shouldn't
see
a
conflict.
Ba
basalt
of
you
know
create
more
teza
the
second
time,
and
it
would
get
a
new
record
for
me
on
this
I'm
aware
of
the
soft
elite
semantics.
F
So
that's
that's
the
basic
sort
of
semantics
that
we
wanted
to
keep
because
a
lot
of
clients
don't
care
that
it's
not
applicable
to
them.
It's
really
around
the
administrative
aspects
of
it
that
that
we
want
to
sort
of
do
this
as
opposed
to
every
single
client,
a
tox
skin,
so
that
that
was
the
first
one.
F
Actually
thing:
I
recover
the
other
one
too.
Next,
so
the
basic
model
is
you
have
a
snore
mille
state
of
an
object?
If
you
do
a
delete
operations
on
it,
it
goes
into
a
soft
deleted.
That
record
still
exists,
but
it
does
not
sort
of
play
into
regular
operations
of
skin.
Non
sort
of
you
know
soft
deleted
operations,
and
it
does
not
affect
your
uniqueness
criteria
or
any
other
sort
of
semantics
like
that.
F
You
can
go
from
that
state
with
with
doing
an
undelete
and
bring
a
tray
state
in
this
into
a
regular
state,
or
you
can
do
a
hard
delete
and
potentially
you
could
do
the
hard
delete
operations
as
a
cleanup
or
sort
of
you
know
batch
process
saying
so.
If
we
have
a
webex
user
that
that
doesn't
sort
of
you
know
deleted
their
record,
then
they
sort
of
haven't
logged
in
for
six
months.
F
You
need
to
be
added
to
that.
The
draft
doesn't
really
cover
this
in
detail.
It's
just
kind
of
puts
a
few
question
marks
really
is
how
do
you
do
things
with
references?
How
do
you
do
things
with
group
membership
when
you
go
and
delete
a
user?
Do
you
want
to
go
and
update
that
you
want
to
sort
of
you?
Don't
necessarily
want
to
go
as
soon
as
you
undelete,
a
user
that
was
deleted,
go
and
add
them
to
the
group,
because
the
administrator
might
have
actually
wanted
to
remove
them
during
that
process.
F
There's
a
lot
of
questions
around
what
you
want
to
do
with
references,
and
we
did
actually
an
implementation
of
something
similar
to
this.
What
we
did,
what
we
chose
was
all
the
references
are
gone,
that
we
took
the
easy
route
you
when
you
read
undelete
an
object.
You
really.
Basically,
you
have
to
come
back
and
recreate
all
the
references
that
was
sort
of
the
easy
way
out.
Potentially,
this
is
what
we
want
to
do.
I,
don't
know.
If
that's
that's
open
to
discussion,
I
think
Active
Directory
does
very
similar
model.
F
They
basically
get
rid
of
majority
of
not
only
all
the
references
but
a
lot
of
other
attributes.
They
actually
delete
and
then
sort
of
undelete.
You
have
to
resupply
them
in
our
in
our
implementation,
sort
of
in
our
experiment
that
I
wouldn't
call
that
implementation.
It
was
more
of
an
experiment.
We
basically
just
get
rid
of
the
references
next,
so
the
basically
same
same
question
as
Phil.
Is
this
something
that
I
know
there
are
a
few
vendors
that
are
interested
in
this?
F
But
the
question
is
this
is
something
that
we
want
to
sort
of
you
know
take
it
on
as
a
broader
set
of
work
that
we
want
to
do
and
then
obviously
the
second
question
is:
is
this
something
that
would
be
interesting
to
their
skin
as
a
charter,
change
or
sort
of
individual
submission
type
of
work?
Tony.
D
Yes,
Tony
Madeline
I
think
this
diddly
I
think
you
have
a
use
case,
for
we
have
a
use
case
for
create
and
so
I'm
just
wondering
if
that
shouldn't
be
just
narrowed
down
to
active
or
not
active
or
something
else.
Instead
of
specifying
this
as
a
specific
delete,
we
could
have
a
state
that
you
know
does
that
does
the
same
characteristics
that
you
said
for
delete
which
would
affect
be
for
create
also
and
other
states
that
and
other
things
that
people
want
to
do
so.
Yeah
I'm.
G
F
I'm
not
only
open,
I'm
very
interested
in
actually
talking
to
you
and
getting
a
little
bit
more
sort
of
understanding
of
the
use
cases
in
our
implementation.
When
we
went
through
this
process,
we
handled
all
the
crate,
because
we
have
this
or
sort
of
you
know
create,
but
it's
not
really
done
whether
it's
not
validated
by
the
administrator
or
by
the
end
user
itself.
So
like
the
classic
I,
send
you
an
email
until
you
click
on
that
link.
I
don't
actually
add
you
to
the
system.
F
The
semantics
of
that
was
slightly
different
and
we
handled
that
differently,
but
I
totally
agreed
that
that
is
a
problem
as
well,
whether
that's
part
of
this
or
it's
a
separate
draft
or
we
generalize
it
and
do
it
for
all
operations
I'm
totally
open.
This
is
just
I
just
threw
out
the
idea
and
it's
totally
open
to
taking
it
where
we
think
is
the
right
sort
of
Pat.
B
Bjorn
on
a
stud
I'm
tending
to
agree
with
Tony,
because
in
a
hyper-connected
world,
where
lots
of
data
is
move
lots
of
places,
we
might
be
short-sighted
in
thinking
of
delete
as
something
special,
because
there
are
resources
that
are
created,
but
not
yet
provisioned
or
active,
but
not
active
or
existing,
but
have
invoked
the
right
to
be
forgotten,
and
there
may
be
a
more
general
case
here
for
resources
that
can
be
used
for
different
types
of
purposes
or
different
levels.
Rather
than
going
from
a
two-state
model.
B
E
B
A
B
We're
saying
it's
not
just
a
virtual
but
there's
a
literal
box.
Okay,
all
right!
Okay,
go
back
one
slide,
oh
we're
here
to
talk
about
passwords,
okay,
skin
passwords.
So
the
first
question:
when
the
idea
of
adding
some
password
or
credential
management
to
skim
came
up,
my
first
reaction
was
wait.
A
minute.
Aren't
we
like
20
years
too
late
to
be
thinking
about
standardizing
this,
because
aren't
we
done
with
passwords
and
can't
we
just
forget
that
and
move
on
to
something
else.
B
The
use
cases
often
involve
managing
users
within
the
service
provider,
not
just
creating
them
and
provisioning
them
and
then
having
them,
go
their
separate
ways
as
two
different
entities,
but
actually
allowing
things
like
a
client
application
to
change
a
letter.
User
change
refine
reset
recover
their
account
with
that
service
provider,
where
it's
not
necessarily
the
same
party
being
the
service
provider
and
the
identity
management
client.
They
may
be
separate.
Okay.
B
Okay,
we're
also
thinking
about
using
skin
for
general
purpose
and
I
use.
The
word
directories
here
of
people
and
things
right.
We
hear
about
identity
of
things.
We
have
about
the
coming
era
of
identity
at
the
center
of
the
hub
of
everything,
and
we
like
to
have
skin
as
that
protocol
and
we're
relying
on
it
in
our
designs
for
doing
that.
So
when
you
think
about
how
do
I
provision
things,
how
do
I
create
credentials?
Allow
things
to
access
my
data
passwords
come
into
that
so
anyway,
handling
credentials
and
passwords
would
believe
is,
is
relevant.
B
I
know
Oracle
has
similar
use
cases
and
there
may
be
other
companies
that
are
also
interested
in
standardizing
on
that
we've
actually
done
some
work
here.
We
have
some
designs:
we're
going
down,
one
particular
architectural
route
for
the
schemas
and
the
the
protocol
for
this
and
Oracle's
going
a
different
way.
So
if
this
is
of
interest,
then
we'll
try
to
bring
those
together
take
the
smartest
from
both
of
those
as
the
oh,
the
phrase
Phil
he
is
earlier,
so
it
is
quoted
on
that.
B
Yeah
I
guess
there
is
a
consideration
slide
here.
There
are
a
number
of
things
to
think
about
before
we
decide
voluntarily
to
take
on
this
effort
as
a
standards
body.
The
multiple
approaches
we
talked
about,
but
they're
also
things
to
deal
with,
like
representations
of
the
count
state.
I
alluded
to
that.
B
In
my
my
comment
earlier
to
marquez's
presentation
and
then
you've
got
some
very
basic
mundane
things
like
what
is
the
exchange
between
the
client
application
and
the
service
provider
in
terms
of
saying
yes,
that
password
or
credential
is
strong
enough
right,
we've
got
the
classical
you've
got
to
have
eight
characters.
3
of
them.
Must
you
know
let
this
meet
this
reg
ex,
but
you
may
also
have
things
like
the
signal-to-noise
ratio
on
a
voice
print
or
the
clarity
of
a
thumb,
print
scan
or
something
like
that.
B
That
could
eventually
become
part
of
a
protocol
for
a
credential
policy,
and
then
the
big
one
is
really.
How
do
you
recover
an
account-
and
that's
the
most
challenging
use
case
here,
because
at
that
point,
you've
got
an
anonymous
user
who
wants
to
regain
control
of
something
using
a
credential?
They
no
longer
have,
and
if
we
can
solve
for
that,
then
I
think
the
other
things
will
pretty
much
fall
into
line.
B
A
D
B
I
agree
with
you
Tony.
In
fact,
my
comment
to
my
engineering
team
was:
let's
not
think
about
this
in
terms
of
passwords.
Let's
call
it
credentials
right.
Passwords
have
some
specific
attributes
that
make
them
a
subclass
of
credential
and
then,
of
course,
other
subclasses
of
credential
will
have
their
own,
but
I
definitely
agree
with
you,
because.
G
At
it
from
the
point
of
view
of
credentials,
there
are
some
things
that,
having
looked
at
how
skin
works
with
federated
protocols,
specifically
open,
ID
connect
there
in
a
lot
of
cases,
we
see
the
identity,
provider
or
authentication
provider
is
not
the
tenant,
which
creates
a
interesting
conceptual
problem
with
skim,
because
everything
is
looked
at
from
the
point
of
view
of
the
tenant.
So
what
is
the
better?
What
is
that
federated
authentication
assertion
that
that
the
SAS
is
supposed
to
expect
that's
going
to
be
tied
to
that
account?
G
There
isn't
an
obvious
way
of
doing
that.
At
the
moment
there
is
no
password,
but
that's
just
nasty.
So
how
do
you
map
an
authentication
provider,
credential
provider
into
that
tenant?
Account
we're
also
looking
at
you
know.
Logging
in
is
one
thing,
there's
also
the
whole
problem
of.
How
do
you
do
session
management?
How
do
you
signal
that
for
a
given
device,
because
these
sasses
have
some
people
coming
in
via
the
web's,
they
have
some
people
coming
in
through
native
apps,
etc?
How
does
the
enterprise,
through
its
or
or
the
authentication
provider
signal?
G
Oh
this,
this
this
users
iphone,
is
gone.
So
we
want
all
of
the
tokens
blown
away
on
that
particular
device
or
all
of
their
sessions,
terminated,
etc,
and
so
far
I
haven't
found
any
plausible
way
of
actually
mapping
that
through
skim,
which
leads
us
to
saying,
we've
got
to
do
session
management
outside
of
skim,
which
sort
of
takes
away
from
the
momentum
of
people
wanting
to
deploy
skin.
G
So
if
well,
if
you,
if
you
were
people,
are
going
to
want
to
do
session
management
to
kill
off
these
things,
sort
of
independent
of
the
provisioning
aspects
of
skin
if
they
get
both
for
for
deploying
one
protocol
they're
more
likely
to
do
it
if
you're
mean
SAS
providers
are
incredibly
lazy,
and
so,
unless
we
come
up
with
some
highly
motivating
factors,
I
talked
to
one
of
the
larger
ones
who
recently
looked
at
skim
and
said:
that's
nasty,
yellow
not
going
to
do
that.
They're,
probably
the
largest
SAS
provider.
G
I,
don't
know,
Mike
probably
got
there
with
Microsoft,
but
somebody
who
you
know
they're
on
the
on
defense
about
skin.
Is
it
really
worth
the
pain
or
could
they
come
up
with
something
simpler
that
covers
eighty
percent
of
what
they
need
to
do
so
if
we
could
come
up
with
some
way
that
the
notions
of
the
identity,
the
authentication
provider
is
not
necessarily
the
tenant
needs
to
be
delegated
by
the
tenant
and
some
way
of
mapping
those
sessions
so
that
we
don't
have
to
have
a
completely
separate?
You
know
SLO.
G
Again
sessions-
or
you
know,
we've
traditionally
thought
of
them
as
being
web
things,
but
I
think
at
some
point
we're
going
to
have
to
come
to
in
the
very
near
future
we're
going
to
have
to
come
to
grips
that
all
of
the
things
that
are
coming
off
of
a
device
or
particular
api's
to
a
particular
website
are
going
to
need
to
be
terminated
in
the
same
way
that
we
want
to
do
single
log
out
from
from
web
sessions.
There's
a
bunch
of
things
that
need
to
be
done.
B
Think
it's
a
certainly
a
valid
point
that
you
know
more
things
covered
by
one
protocol
might
make
it
more
attractive,
but
they
may
also
make
it
more
complicated.
So
we
drew
the
line
at
authentication
is
not
skim,
but
keeping
track
of
the
credential
data
is
part
of
the
resource
definition
and
there
comes
under.
What
we
would
want
to
do
is
ask
in
extension,
or
something
like
it.
C
C
We
can
all
build
our
own
UI
and
our
own
components
to
do
things
like
token,
revocation
and
things
like
that,
but
I
think
when
you
look
at
it
from
an
identity
management
perspective,
we're
definitely
getting
a
lot
of
requests
from
enterprise
organizations
that
say:
I
want
to
be
able
to
connect
a
management
system
in
my
enterprise,
which
is
paying
up
with
with
your
Oracle
cloud
and
I
want
I
expect
those
to
be
able
to
work,
and
this
is
where
we
come
back
to
saying.
Well,
okay,
then
we
need
a
standard
I,
don't
like
that.
So.
C
Just
sum
this
up,
I
think
that
we
might
have
to
do
some
words
wordsmithing
on
the
the
Charter,
because
I
think
John
also
brought
up
the
other
aspect
of
how
to
map
which
might
have
been
missing,
because
we
didn't
do
the
sam'l
thing.
How
do
I
map
a
sam'l
credential
in
is
there?
Is
there
a
key
that
looks
up
other
than
username
or
some
other
thing
that
that
becomes
the
mapping?
F
This
is
quick,
so
yeah
I
generally
agree.
I
think
the
missing
piece
is
really
around
authentication
policy
and
that's
the
part,
that's
not
handled
by
Federation
standards
and
it's
not
handled
by
the
provisioning
sort
of
skim
course
Kim
that
that
we're
doing
it's
it's,
this
sort
of
the
missing
in
between
and
everybody's
doing,
their
own
sort
of
solution
for
it,
and
certainly
as
an
extension
of
skim.
It
would
be
a
nice
idea
to
sort
of
you
know,
add
semantics
to
deal
with
that
policy.
F
E
A
B
Okay,
so
there's
not
a
lot
of
meat
here,
but
it
really
is
a
concept
and
the
concept
is
if
we're
already
modeling
resources
that
are
provision,
resources
that
have
an
identity,
potentially
resources
that
have
a
life
cycle
can
be
deleted,
have
credentials
etc.
Perhaps
there's
reason
to
add
to
the
core
schema
the
concept
of
a
device,
a
nonhuman
right,
just
like
we
have
users,
and
then
we
have
groups
of
users
and
we
have
a
subclass
extension
of
users
called
an
enterprise
user.
B
Perhaps
we
need
to
add
something
for
devices
so
that
all
those
people
out
there
who
building
provisioning
systems
for
Fitbit
devices,
for
automobiles,
for
airplanes,
for
power
plants
etc
for
medical
devices
might
look
at
skin
as
a
nice
protocol.
For
that,
and
in
fact
before
skin
was
even
came
up.
I
had
a
case
for
that
working
with
a
large
fleet
company,
where
we
had
to
provision
trucks,
trailers,
GPS
devices,
drivers
who
were
not
users
and
locations
as
well.
B
So
we
I
think
there
is
definitely
an
industry
need
for
this
okay,
so
the
idea
would
be
to
add
to
this
model.
This
is
the
current
model,
go
on
and
add
another
class
of
core
resource
here
called
a
device
with
some
set
of
attributes
to
be
determined,
and
then
out
of
that
there
could
be
extensions
for
particular
industries
for
particular
use
cases.
Okay,
next,
so
more
Tesla's
put
a
little
list
together
here
with
some
input.
B
For
me,
where
a
device
would
have,
of
course
its
own
ID,
it
would
have
a
name
there
would
be
/
devices
endpoint
just
like
there
is
for
/
user
/
groups
today
schema
there
and
then
extensions
in
particular
for
that
device.
Next,
okay,
so
the
only
required
ones
are
at
the
top
there,
the
ID
a
device
named
the
meta
attribute.
Of
course.
What
you
find
in
this
realm
is
that
devices
have
a
lot
of
identifiers
and
it
varies
by
indus
tree
right.
B
Many
of
them
have
MAC
addresses
serial
numbers
unit
numbers
license,
numbers
registration,
numbers,
IP,
addresses
serial
numbers
and
I
mentioned
that
one
already.
So
there
are
a
lot
of
those
there's,
also
a
rich
world
of
owners
right
who
owns
the
device
whose
data
is
collecting
is
being
collected
by
the
device
who's
using
the
device
right
now,
various
properties
like
that
which
we
would
probably
want
to
leave
out
of
the
schema,
so
we're
not
trying
to
incorporate
all
of
that.
We
also
need
to
consider
the
type
of
device
and
what
its
capabilities
are
now.
B
Is
it
able
to
do
two-way
communication?
Is
it
just
streaming
data?
Does
it
have
this
that
or
the
other
capability,
maybe
even
potentially,
does
it
have
the
ability
to
capture
an
authentication
credential?
That
might
be
one
capability
right?
If
it's
a
scanner
or
an
eyeball
reader
or
something
like
that
and
then
the
other
one
that
I
would
argue
might
be.
B
An
important
type
of
attribute
to
generalize
is
location
because
not
all,
even
though
not
all
devices
can
keep
track
of
a
GPS
location,
they
are
physical,
general
physically,
they
are
located
in
physical
space
somewhere,
whether
statically
or
dynamically.
So
there
might
be
a
use
for
a
location
attribute
as
part
of
the
standard
schema
and
that's
I
think
that's
it.
B
Well,
communication
devices
being
one
specific
example:
telephone
cell
phones,
video
conferencing
systems
to
a
elevator
emergency
buttons,
whatever
they
might
be.
One
example
I
think
we'll
leave
the
details
of
the
example
and
then
the
same
discussion
is
we've
had
on
the
other
three
points.
Is
this
something
there's
general
interest
in
working
on?
Thank
you.
F
Actually
this
one
specifically
anybody
interested
in
this
I
mean
everybody
is
implementing
something
like
this.
The
question
is:
is
there
value
in
standardizing
the
core
device
model
and
then
potentially
some
of
the
extensions
I'm
sort
of
sitting
on
the
fence?
I
mean
we've
implemented
a
whole
bunch
of
these,
but
when
I
look
at
it,
I
don't
I'm
not
sure
if
there's
value
in
interoperability
for
that
level
or
not
that
so
it
it's
really
a
question.
E
Yeah
hold
our
I,
don't
think
we're
exactly
that
really
interest
in
this,
but
I
think
we
would
be
interested
in
using
the
devices
for
authentication
so
tying
it
into.
This
is
disuse
or
cell
phone.
You
can
use
as
a
two-factor
authentication
mechanism,
and
things
like
that
I
think.
That's
the
biggest
use
case
that
I
can
see
right
in
our
insurance.
F
F
E
F
I
actually
disagree
with
you
that
this
is
outside
the
realm
of
identity
management.
We
see
that
all
the
time
device
ID
is
actually
is
just
as
important
as
user
ID.
For
us
at
least
I
certainly
can
speak
for
a
collaboration
side
of
it
and
I
see
that
in
IOT
all
over
the
place,
but
not
only
that
we
actually
sort
of
have
a
very
desperate
need
for
Apple
ID
as
well,
which
is
a
separate
conversation,
but
but
I
actually
see
that
as
identity.
F
The
question
is
how
much
value
there
is
in
standardizing
some
of
this
stuff,
because
if
you
really
sort
of
boil
it
down
to
the
core
essence
of
that,
it
comes
down
to
a
very,
very
small
set,
and
it's
like
is
how
much
value
do
yet
with
that,
because
a
lot
of
it
becomes
specific
to
that
device
to
that
vendor
to
that
solution
and
type
of
thing
ever
really.
That's.
F
A
So
actually,
don't
want
us
to
keep
sort
of
drilling
at
this
particular
point,
because
we
have
ten
minutes
left
and
I
want
to
have
the
conversation,
but
next
step.
So
so,
just
as
a
leading
into
that
conversation
is
you
know,
you
may
notice
that
we
only
requested
one
hour
here
and
that
the
reason
for
that
is
because
we
in
Hawaii
said
you
know
if
there
are
no
extension
proposals
by
Dallas
we're
not
going
to
schedule
a
meeting
and
we.
A
A
We
would
support
creating
a
spin-off
working
group
words
Kim
extensions
without
the
buff
cycle,
and
at
that
point
there
is
actually
very
little
difference
between
the
recharter
process
and
spinning
up
a
new
working
with.
You
know
that
that's
basically
the
same
thing
right
so
I
think
what
we
should
talk
about
now
is,
you
know,
is
there
energy
to
work
on
these
things?
Is
their
interest?
Is
their
interest
to
do
it
now?
Would
meeting
in
Prague
and
Yokohama
actually
be
a
realistic
option
for
the
working
group?
Will
people
come
to
program
work
on
this?
D
Tony
goblin
for
the
majority
of
what
was
proposed
I
would
be
in
favor
of
working
on
them.
I'm,
not
anxious
to
work
on
the
notifications
at
all,
but
I'm
not
against
the
notifications,
as
I
believe
that
steps
into
territory
that
is
just
nasty.
As
far
as
that's
concerned,
I
can
understand
why
some
people
need
it,
but
I'm
not
sure
totally
belongs
in
skin,
but
I'm
not
going
to
be
you.
E
E
But
perhaps
one
thing
that
would
work
would
be
to
let
people
go
off
for
a
while
and
play
with
this
in
an
operational
environment
and
work
with
each
other
sort
of
outside
of
working
group
and
figure
out,
which
ones
would
really
get
used
and
how
you
wanted
to
do
them
like,
for
instance,
for
the
soft
delete
which
way
you
wanted
to
go.
Whether
it
was
different.
E
Attributes
in
those
states
right,
different
states
or
whether
you
wanted
to
do
a
soft,
a
leader
or
whatever
go
off
and
figure
that
out
and
play
with
it
and
do
some
testing
and
then
come
back
with
a
proposal,
and
if
that
would
be
the
better
way
to
do
that,
then
we
might
close
this
working
group
and
create
an
extensions
working
group
when
y'all
were
ready
to
come
back
and
do
the
documents
or,
if
you're,
ready
to
do
them
now
till
now.
So
that
was
the
trade.
Oh.
C
C
A
Think
the
question
is
filled.
Are
you
ready?
Let's
say
Barry
says?
No.
You
guys
need
to
produce
serious.
Give
me
the
Brisby
results
by
viper.
All
right.
Are
you
guys
ready
to
100
yeah?
I
mean
I'm
playing
with
Oh.
Putting
it
on
I
mean
yes,
I'm,
being
a
little
bit
on
the
nose
hair,
but
you
know
it
or
we
are
we
going
to
be
like
in
just
waiting
around
until
the
next
time
we
can
meet
in
the
in
North
America,
because
then
there's
really
no
point
in
having
the
working
group
open
right.
A
Then
it's
going
to
be
until
2017
until
we
can
make
physically
I'm
right
again
right
or
no.
No,
it
doesn't
matter
right.
We'll
keep
these.
We
keep
these
work
documents
coming
out
and
we're
going
to
hyrum
up
on
the
mailing
list.
We
don't
have
to
meet
physically
right,
I
mean
what
are
we
talking
about
in
terms
of
planning
right?
Is
it.
C
A
Really
about
sizes
right
now,
if
I
work,
if
you
come
say,
if
I
have
this,
notify
drive,
want
to
talk
about
it
right.
Some
people
say:
yes,
it's
useful
some
say:
I'm
not
opposed
to
doing
it.
It
seems
that
there's
interest
we
could
get
it
done.
Is
it
if
I'm
asking
about
milestone
for
a
red
shorter?
Would
you
say
within
the
next
year
within
the
next
two
years
or
within
the
next
six
months,
I
mean?
Where
are
we
that's
the
kind
of
the
kind
of
discussion
I
think
we
should
well.
C
I
think
of
my
personal
impression,
I
think,
notify
is
well
along
and
we
could
start
working
on
that
in
detail
and
it's
fairly
well
scoped
password
credential
management.
We
kind
of
opened
the
door
if
anything,
we
didn't
scope
it
down.
So
that's
my
hesitation,
I'm
not
sure
what
to
say,
because
everybody
said
well:
I
want
to
talk
about
devices
and
everything
else,
and
that
seems
like
a
good
thing,
so
I'm
just
kind
of
like
okay.
If
we're
going
to
do
this,
let's
get
going
on
it
and
I'm
concerned
about
an
implied
delay.
That's
all
right!.
A
I
mean
we
can.
We
can
also
talk
about
sort
of
staging
and
I
mean
we
could
test
right.
We
could
say
okay,
so
no
defiance
off
till
it
seemed
to
be
fairly
well
along
right.
So
let's
ask
Barry
to
put
those
on
the
Charter
right
now
and
see
if
we
can
complete
them
right,
if
we
don't
complete
them
within
the
reasonable
time.
A
lot
of
time
say
by
significant
progress
by
my
prog,
then
we're
really
pulling
the
plug
right.
A
A
D
A
E
Sperry
thought
yeah
that
all
sounds
good.
I,
like
the
approach
that
wave
just
said,
no
changes
to
the
charter,
no
changes
to
anything
else.
You
guys
start
putting
out
some
proposed
documents
and
discussing
them,
and
in
a
few
months
we
see
what
progress
you've
made
and
decide
whether
to
recharter
or
not.
That
sounds
like
a
good
plan.
E
Miss
kelly,
I
would
say
from
my
perspective,
it
seems
like
the
credential
management
has
the
most
desire
behind
it
or
the
broad
desire
behind
it.
So
if
we're
going
to
prioritize,
I
would
definitely
help
out
and
say
that
that's
we're
going
to
do
them
serially,
instead
of
parallel.
That's
something
that
we
should
attack.
First
I
mean.
A
B
E
D
A
But,
but
I
think
that
this
so
we
I
think
that
we
have
consensus
here
to
everybody
sure
now
to
your
individual
submissions
and
whether
we
meet
physically
in
program
doesn't
matter.
I
think,
but
we're
talking
about
the
prog
time
time
scale
that
kinda
in
in
the
next
three
to
four
months,
we're
going
to
make
a
decision
on
whether
it
this
stuff
needs
more
time
to
develop
or
if
we're
just
reach
offering
or
maybe
there's
so
much
energy
that
we
just
change
the
name
of
the
working
group.
A
Basically,
this
game,
xed
and
you
know,
keep
doing
extensions
robot
that
can
be
decided
at
that
at
a
later
time,
right:
okay,
it's
the
that
feel.
Okay
for
the
working
here,
you
can
have
more.
You
know,
say
yes
or
grace
your
answer,
yeah!
It's!
Okay!
Okay!
I
mean,
I
guess
it
sounds
here
that
there's
so
few
for
those
of
you
who
are
listening
in
on
the
on
the
wireless
yeah.
This
is
the
this
is
clear
consensus.
There
are
few
people
in
the
room,
but
they're
unloading,
their
heads
and
I'm.
C
A
A
C
A
E
The
well
we
can't
write,
you
can't
produce
the
document,
you
can
certainly
discuss
it
and
we,
you
could
discuss
it
here.
You
could
discuss
it
on
the
email
list.
What
I
would
like
to
see
is
it's
not
pushing
it
off.
What
I'd
like
to
see
is
a
demonstration
that
people
are
willing
to
review
these
documents
and
discuss
them
on
the
mailing
list
and
right
then
move
them
forward,
and
so
that's
everybody-
everybody
who's
here
or
is
listening,
is
charged
with
doing
that.
Phil
has
a
document
or
two
whatever
other
people.