►
From YouTube: IETF95-SCIM-20160405-1620
Description
SCIM meeting session at IETF95
2016/04/05 1620
A
B
E
F
Quiet
place,
I'll
feel
free
to
do
so
too,
so
we're
we,
we
actually
have
a
the
agenda
post,
it
is,
is
mostly
about
reach
out
to
discussion,
and
there
are
we
actually
have
one
press
enter
here.
We
have
filled
is
going
to
talk
to
us
a
little
bit
about
ID
events,
but
our
sort
of
our
or
next
step
for
this
working
group
is
to
figure
out
what
to
do
next
and
that
sort
of
the
context.
You
should
be
that's
how
you
should
be
looking
at
this
phil
has
some
ideas.
Other
people
have
proposed.
F
You
know
various
extensions
to
scam
and
various
work.
Some
of
you
have
stuff
lying
around
in
your
yours
or
on
your
hard
disks
that
look
like
skim
extensions.
This
is
this
may
be
the
time
to
do
the
bubbles,
let
some
of
those
things
bubble
up
to
the
surface
and
and
through.
So
we
can
possibly
have
a
discussion
in
this
working
group
about
where
we
go
next
I'm
not
saying
we
have
to
reach
Artur
today,
but
in
the
not
too
too
distant
future.
F
We
have
to
figure
out
the
way
to
reach
other
this
work
and
you
close
it
down
or
do
something
else,
because
our
core
documents
are
done
and
through
at
present,
we
don't
have
any
outstanding
deliverables
right,
so
top
phil
has
some
stuff.
He
wants
to
talk
to
us
about
and
we
hope
to
leave
time
in
open
mic
so
for
people
to
talk
about
their
their
other
stuff.
F
I
J
F
I
Had
we
had
enough
planning,
this
presentation
was
actually
going
to
be
an
identity
events
bought.
The
suggestion
was
made
since
it's
related
skin
as
an
interest.
We
could
do
it
here,
so
we
wanted
to
bring
you
up
to
date
on
some
discussion.
A
bunch
of
us
have
been
having
you
know
in
the
next
slide
that
started
in
Tokyo
about
defining
events
and
I'll
go
through
and
do
a
bit
of
a
level
set
for
those
that
don't
know.
Many
of
you
do
talk
about
why
it's
different
from
say,
skim
itself.
I
Why
it
matters
that
we
do
this
and
why
is
it
useful?
We
have
three
graphs
that
have
been
submitted
to
get
things
started,
they're
very
rough.
It
has
been
some
good
input
from
from
William
and
more
tezu
and
myself.
So
there
is
some
experience
here,
but
we're
not
really
at
the
stage
where
anybody
has
any
realistically
working
coat.
People
do
have
working
architectures,
that's
similar
and
there's
a
desire
now
to
standardize
that
and
that's
where
we're
at
today.
The
next
slide
so
some
background,
as
I
mentioned.
I
I
There
is
the
risk
working
group
in
the
open
identity
foundation,
which
is
looking
to
send
security
information
between
providers
that
would
help
deal
with
issues
like
people
use
a
recovery
account
at
another
email
provider
to
recover
their
account,
and
then
we
know
the
mat
Honan
story
where
hackers
were
able
to
leverage
the
fact
that
people
use
the
same
information
across
multiple
providers
and
that
in
itself
causes
problems.
So
maybe
I
don't
know
folium
if
you
want
to
talk
more
to
risk,
but
a
little
later
on,
there's
all
of
that.
There's
skim.
I
There
are
some
event
scenarios
where
we
want
to
notify
another
party
where
we've
provision
to
possibly
in
the
past
of
a
change
we'd
like
to
make,
but
sometimes
it's
not
practical
to
actually
send
a
rest
command
and
I'll
explain
why
those
situations
come
up.
There's
the
hard
working
group
and
I
don't
know
much
about
that,
but
they
expressed
an
interest
here
as
well.
I
The
other
thought
I
mean
the
consensus
that
the
informal
consensus
that
happen
in
Tokyo
is
hey.
Maybe
we
can
use
job
for
this.
It's
it's
a
portable
format.
We've
got
signing
and
encryption.
Let's
use
that
with
the
caveat
that
there's
no
confusion
that
these
are
sawing
on
assertions
or
sessions.
We
have
to
make
that
clear.
Next
slide.
I
So
we're
rest
protocols,
transfer
state
from
clients
deserves
an
event,
is
really
just
a
statement
that
a
state
change
has
occurred.
We
can
make
some
kind
of
qualifier
about
that
state.
This
is
a
new
resource.
This
subject
has
been
modified.
A
count
takeover
event
has
occurred.
Any
number
of
things
that
might
be
important
to
security
could
be
expressed.
I
One
thing
we
want
to
say
clearly
is
that
this
isn't
a
way
to
do
RPC.
These
are
not
commands.
These
are
simply
one
server
saying
to
another.
This
has
happened
and
I'm
sending
it
to
you,
because
you've
registered
and
interest
in
knowing
it
does
a
number
of
cool
things.
When
you
don't
use
a
command
is
by
having
the
the
sender
simply
say
this
happened,
it's
up
to
the
receiver,
the
subscriber
to
decide
what
to
do
out
it.
That
makes
your
error
signaling
problems
go
away.
It
also
gets
you
away
from
the
RPC
question.
I
So
the
way
to
think
about
an
event
is
an
event.
It's
simply
a
statement
about
a
statement
of
fact
about
a
change.
That's
occurred
with
a
publisher
and
they're,
now
notifying
a
subscriber
that
this
has
happened.
That's
happened
in
the
historical
context
might
be
near
real-time,
but
its
historical.
That's.
K
D
I
Title
so
for
now
the
graphs,
we're
writing
or
focused
on
identity
events.
So
what's
unique
about
identity,
I
think
the
observation
is
that
whether
our
systems
are
tightly
coupled
or
loosely
coupled
or
not
coupled
at
all,
because
we're
often
talking
about
the
same
people,
there
are
cross
system
effects
that
occur
because
the
same
claims
are
known:
the
multiple
parties,
so
whether
that
was
done
through
intent
because
of
provisioning
system
connected
those
systems
or
whether
it's
because
it's
the
same
person
that
two
parties
happen
to
know
about.
I
I
At
the
same
time,
we
want
to
do
it
in
a
way
that
doesn't
wouldn't
be
great
if
Google
started
telling
people
others
providers
about
all
sorts
of
stuff.
These
changes
in
detail
that
the
other
party
shouldn't
know
about
so
the
great
things
it
turns
out
that
there's
a
way
to
express
events
that
really
reduces
the
amount
of
information
flowed
to
a
minimum
and
that
we
we
get
the
idea
that
the
subscriber
only
actually
gets
the
data
or
confirms
the
data
based
on
what
they
already
know.
I
Sometimes
you
have
a
choice.
There
are
different
scenarios
that
that
I've
observed
where
all
that
needs
to
happen
is
to
say
the
state
of
this
record
has
changed.
Then
it's
up
to
the
subscriber
to
decide
what
to
do.
If
they
need
more
information.
There's
nothing
saying
they
can't
do
a
call
back
and
say
give
me
the
current
state.
Do
a
an
HTTP
GET,
pull
that
record
back
at
that
point.
The
cool
thing
is
normal
access
control
kicks
in
normal
information
filtering
kicks
in.
We
do
that.
I
We
don't
have
to
build
those
security
measures
in
the
event
system.
The
ideal
case
is
you,
give
minimal
information
but
you're
also
weighing
a
performance
and
privacy
consideration
if
there's
a,
for
example,
an
enterprise
to
the
cloud
there's
a
tight
contractual
relationship
and
the
enterprise's
asserting
control
over
the
cloud-
and
there
may
be
a
performance
concerns,
so
it
may
be
valid
in
some
cases
to
pass
raw
data,
but
in
other
cases,
particularly
when
it's
cross
cross
cloud
in
a
completely
decoupled
environment
instead
of
passing
data
across,
we
might
pass
a
hash
across
that
says.
I
If
you
have
an
identifier
that
matches
this
hash
and
William
will
show
you
that
example,
you
might
care
about
that,
and
that
way
we
get
out
of
the
issue
of
chem.
We
expose
that
piece
of
raw
information
like
an
email
address
or
not,
and
so
the
other
party
has
to
know
about
it,
for
it
to
make
sense
or
to
be
an
issue,
but
at
the
same
time
we've
conveyed
the
security
event
without
conveying
and
information
yeah.
J
I
Well,
it
didn't
render
too
well
No,
so
the
only
thing
here
is
that
that
I
was
sort
of
seeing
a
full
spectrum
of
systems
that
share
common
data
that
have
no
relationship
active
relationship
that
completely
decoupled
and
that's
the
case
might
be
where
Google's
letting
yahoo
know
of
a
security
event
that
they
might
care
about.
Even
though
there's
no
provisioning
relationship
in
place
to
the
other
extreme,
where
an
enterprise
is
saying,
I
want
to
sync
my
directory
with
this
cloud
and
I
want
them
to
look
exactly
the
same
so
tightly
coupled
environment.
I
M
We
have
actually
examples
for
some
of
those
cases
because,
like
it
may
help
us
to
understand,
like
what
information
needs
to
be
passed
around
that
what
the
implication
is
of
that
information,
because
I
can
imagine
if
there's
a
for
example
in
the
google
yahoo
case.
I
wonder
like
it
obviously
why
I'm
sure
there's
a
lot
of
difference
between
what
this
pass
around,
because
hopefully
not
my
use,
I
accounts
and
so
on,
because
what
would
ya?
Who
do
with
that
them?
I
don't
have
accounts
on
on
on
both
sides,
and
so
so
we
have
a.
M
M
N
Honest
William
is
from
google
just
to
take
that
question,
and
this
is
just
a
completely
strawman
implementation.
But
if
you
have
an
agreement
to
share
signals
between
two
companies
about
their
mutual
users,
you
could
you
could
do
that
list
using
like
a
privacy-preserving
hash.
We
say
you
would
you
would
know
who
the
yahoo
uses
work
and
vice
versa
and
then
only
share
those
with
risk
signals
when
it's
when
you
know
that
it's
actually
that
you
go
so.
E
I
I
F
It's
gonna
go
stand
in
the
audience
for
a
while,
so
there
is
a
is
one
point
out
that
there's
a
difference
between
the
engineering
approach
and
the
legal
approach
here
right
so
that,
whatever
we
say
about
you
know
as
engineers
and
as
sitting
here
is
building
an
engineering
solution
to
this
problem.
You
know
it
might
be
a
big
difference
between
sending
a
reference
on
sending
the
data
right
from
the
legal
point
of
view.
At
least
me,
you
doesn't
make
a
hell
of
a
lot
of
difference.
F
It's
still
piii
doesn't
actually
matter
right,
but
you
know
we
should.
That
means
that
we
have
to
figure
out
when
we're
building
that
or
the
architectures
for
information
flow
architectures.
They
have
to
be
able
to
support
directed
as
well
as
you
know,
publish-subscribe
models
I
think,
because
there
are
certain
deployment
situations
where
a
information
sharing
over
a
bus
would
be
problematic.
I
Sure
one
of
the
things
I
hope
in
the
initial
sort
of
idea
we
put
forward
is
that
there
is
a
delineation
between
a
base,
token
format,
which
just
says:
here's
how
you
express
an
event
and
then
I
put
forward
a
proposal
for
what
a
set
of
skim
events
might
be
that
that
is
a
profile
of
identity.
Events
that
helps
in
a
couple
of
ways
in
that
the
rules
and
the
privacy
considerations
really
depend
on
the
overall
data
situation
that
you're
dealing
with.
I
So
in
some
sense,
the
risk
events
are
dealing
with
a
different
set
of
problems.
They're
still,
events
then
say
what's
kims
dealing
with
or
what
Oh
auth
is
dealing
with,
trying
to
revoke
a
session
or
token,
and
the
great
thing
is
by
separating
those
one
advantage
is
that
you
can
deal
with
the
privacy
and
the
security
considerations
of
each
without
having
to
deal
with
it
in
one
big
spec.
I
What's
one
of
the
challenges
for
skin
exactly
when
the
state
isn't
quite
the
same
and
I
give
the
example
of
say,
Oracle
and
Salesforce
the
number
of
users
we
have
are
probably
a
superset
of
our
users
that
also
use
Salesforce,
and
so
we
could
have
a
situation
where
one
service
provider
changes,
changes,
a
user
and
add
CRM
user
to
their
roles,
and
the
intent
is
is
that
an
event
goes
off.
Our
command
goes
off
to
Salesforce.
I
I
We
know
you
care
so
here
it
is,
and
then
sales
force
as
the
receiver
of
the
event
says.
Oh,
we
don't
know
what
this
identifier
is.
First
of
all,
we
have
to
resolve
that
identify
er.
Then
we
decide
what
to
do,
and
the
idea
here
is
that
the
receiver
of
the
event
decides
what
to
do
and
then
based
on
what
they're
allowed
to
know
they.
They
discover
that
information.
So
it
becomes
self
resolving.
I
So
I've
mentioned
this
before
the
event
model.
Lets
us
reduce
error.
Signaling
lets
us
reduce
the
actual
event
payloads
the
amount
of
data
we
transfer.
We
did
a
discussion
years
ago,
four
or
five
years
ago
about
how
would
we
do
cross
provisioning
between
sam'l
providers?
We
wrote
essentially
the
rest
side
to
sam'l.
It
fell
flat
on
its
face
because
the
security
paradigm
of
sam'l
is
really
not
to
reveal
anything
if
you're
not
supposed
to
know
about
a
set
of
claims.
I
I
So
there's
three
current
drafts
that
we've
published
these
are
just
to
get
discussion
going.
The
first
one
is
the
event,
the
identity,
token
event,
format,
that's
based
on
jot.
It
does
show
a
couple
of
example
offense,
but
those
aren't
normative.
The
intent
is
that
another
draft,
like
like
the
idea
of
n
skin
graph,
would
say
this
is
what
it
means
for
skin
I
would
expect
open.
Id
would
publish
in
the
future
a
a
risk
event
draft
that
extends
the
ID
event
token
draft
and
then
to
get
discussion
going.
I
Is
it's
all
good
to
have
an
event
token,
but
how
do
we
propose
they
be
delivered?
I've,
had
lots
of
conversations
with
many
people
and
there's
many
different
cases
and
and
life
just
raved.
The
question
is
it
point
to
point:
is
it
a
bus?
The
answer
is
I've
heard
all
sorts
of
needs
and
requirements.
So
what
I'd
like
to
see
is
to
start
with
is
an
HTTP
POST
profile
and
an
HTTP
GET
profile.
One
allows
us
to
deliver
an
event
to
a
registered
endpoint
that
somebody's
provided.
We
can
just
post
the
events.
I
I
So
what's
the
identity
event
token,
it's
just
a
jot
token.
It
uses
reuses
all
the
job
attributes
and
really
only
defines
one
attribute,
but
then
we
create
what
I
call
an
attribute
bag
so
that
each
event
can
have
its
own
set
of
attributes
without
having
to
worry
about
collisions
between
other
than
definitions.
Oh
that's
kind
of
small,
so.
I
Better
we're
getting
sophisticated,
yeah
mom.
There
can
be
some
debate
as
to
what
the
format,
whether
it's
aur
na
URI
I'm,
not
hung
up
on
that
I
just
followed
what
skim
and
OAuth
were
using.
So
in
this
case
this
would
be
a
skim.
Create
event
is
being
indicated.
The
issuer
is,
is
this?
Is
the
publisher
the
audience
in
this
case?
I
define
it
as
saying
the
audience
is
this
event
would
went
out
on
these
two
feeds,
so
those
people
that
have
subscribed
to
these
feeds
are
the
audience
for
this
event.
I
Now
it
doesn't
have
to
be
a
feed.
It
could
be
some
other.
Some
other
thing
entirely,
then,
to
convey
the
attributes.
Skim
defines,
would
define
for
itself
the
set
of
attributes
and
how
it
wants
to
do.
This.
I
just
took
this
based
on
like
a
skin
bulk
event
format
and
copied
that,
but
it
could
be
any
other
design,
and
the
skin
working
group
may
change
that.
The
main
point
is
that
the
event
can
contain
anything
it
wants
to
contain,
based
on
what
that
standard,
trac
wants
to
do
and
here's
a
risk
event.
N
Alright,
well
in
Venice
again
so
again,
it's
just
kind
of
a
straw,
man
example,
but
here
we
have
the
urine
for
risk
for
a
particular
event
signal
risk
and
then
wanted
to
call
it.
The
attribute
to
kind
of
pocket
yeah
wish
keeping
bag
bag,
which
can
contain
kind
of
all
the
details
of
the
event,
in
this
case,
like
a
hash
of
the
email
and
to
the
earlier
question
only
like
this
assumes
there's
a
pre-established
relationship
with
risks.
N
So
we're
only
sending
this
event
to
people
that
we
know
actually
care
about
this
user
and
to
take
it
back
a
little
bit.
I
guess
to
explain
what
risk
is,
so
we
noticed
that
there's
kind
of
an
informal
relationship
between
providers
of
identities
say
a
user
may
use
a
particular
email
address
from
one
provider
as
a
recovery
option
at
a
different
provider,
and
what
this
event
here
is
is
an
example
of
is,
is
if
that
is
that
one
of
those
providers
reassigns
that
email
address
we
kind
of
want
to
tell
the
other
provider
hey.
N
O
You
know
we're
interested
in
finding
out
what
has
changed,
but
we
don't
want
to
receive
individual
events
for
everything
that
changes.
We
find
that
very
networking
and
very
cumbersome
to
deal
with
right.
So
you
know
we
have
a
draft
out
there
on
polling
and
it's
basically
to
get
everything
that
you
watermark,
they're,
bright,
right
and
so
I'm
still
trying
to
figure
out
what
the
main
driver
is.
A
sigh
I
can
see
if
you're
after
account,
compromise
and
stuff.
N
I
think
that
they
had
two
orthogonal
problems
there.
This
particular
draft
the
event
type
doesn't
really
go
into
how
its
distributed
I.
Think
the
poly
mechanism
is
quite
legitimate,
I
guess
you
could
use
you
know
the
JD
I
or
you
could
have
another
serial
or
some
serial
number
in
there
or
something
but
I
think
that's
why
I
feel
you
intentionally
kind
of
kept
the
draft
separate,
so
we
can
have
like
well.
This
is
what
the
event
looks
like
an
and
then
sort
of
separately
is
how
it's
delivered.
So
I
think
risk
is.
N
P
N
I
I
would
say
the
other
uniting
quality
is
that
for
the
receivers
of
these
events,
they're
all
arriving
asynchronously,
so
you
have
situations
where
I
might
have
positive
control
with
salesforce
and
I
can
send
them
all
the
changes
I
want,
but
since
they're
an
independent
organization-
and
they
have
changes
that
I
know
they
know
we
care
about-
but
they
don't
know
the
state
of
our
data.
What
they
might
want
to
do
is
send
us
back
an
event
that
says:
we've
changed
this.
So
if
you
care
about
it,
you
can
decide
what
to
do
so.
I
N
I
So
the
issue
is,
is
that
I
might
have
positive
control
over
Salesforce
and
my
customers
that
are
at
Salesforce.
This
is
hypothetical,
so
let's
say
I
do
and
I
can
send
them
all
the
commands.
I
want
rest
commands
to
transfer
the
state
I
want
to
give
to
salesforce
and
they
follow
our
commands
and
do
it
yeah,
but
let's
say
salesforce
being
salesforce
makes
independent
changes
and
that's
a
realistic
thing
and
some
of
those
changes
have
impacts
back
to
the
provider
of
that
or
basically
to
our
enterprise
customer.
I
So
the
question
is:
should
Salesforce
do
a
skim,
rest
command
back
to
us
and
then
we
get
into
complex
error,
signaling
situations
or
does
sales
for
simply
say:
we've
changed
their
roles,
so
you
might
want
to
know
about
it
because
you're
paying
for
it
that
kind
of
thing.
So
that's
what
this
sets
up
is
is
the
ability
for
an
asynchronous
callback
to
let
another
party
that
you're
working
with
know
about
estate
change.
I
H
Mort
is
on
sorry,
I.
Think
I
think
there
might
be
a
bit
of
a
confusion
here
so
to
just
kind
of
step
back
in
and
do
a
bit
of
a
history
on
this
so
last
year.
One
of
the
extensions
were
skim
that
we
sort
of
started
thinking
about
and
we
propose.
We
wrote
the
draft
for
was
the
event
notification
that
started
a
bunch
of
discussion
that
hey.
We
have
the
need
around
sort
of
notification
of
events
for
a
whole
bunch
of
other
identity
related
stuff.
H
So
one
of
the
other
example
that
we
sort
of
wrote
up
the
draft
is
the
risk
as
another
example
and
there's
there
could
be
a
whole
bunch
of
additional
profiles
for
it,
so
the
overall
ID,
then
type
itself,
has
nothing
to
do
with
scam.
Skin
is
just
one
of
the
consumers
of
that
and
that's
that's
I,
think
that's
one
of
the
reasons
that
we're
confusing
these
two,
because
a
lot
of
the
examples
of
all
that
discussion
is
Orion
skin,
but
it's
not
just
for
skin.
Does
that
help
a
bit
with
which
sort
of
understanding
you.
I
P
P
I
I
would
expect
different
standards,
organizations
or
different
work
groups
are
going
to
take
that
shot,
format
and
decide,
what's
appropriate
for
their
scenario.
So
you
could
have
somebody
who
says
I
want
to
deliver
events
to
mobile
apps,
say
I'm
going
to
use
web
push,
and
we
have
our
own
set
of
events
that
we're
going
to
do,
and
that's
fine,
I
think,
are
the
reason
why
I've
said
identity
events
is
what
links
it
together
is
because
the
notion
that
identity
events
seem
to
occur
across
parties
that
are
even
not
actively
cooperating
with
one
another.
I
I
I
This
is
an
example
of
an
event:
I
apologize,
it's
so
small
with
a
distance.
The
idea
here
is
that
we
could
have
a
standardized
event.
This
is
like
a
password
reset
event,
but
an
enterprise
might
find
it
in
their
environment.
They
want
to
carry
extra
data,
so
I
might
want
to
say,
keep
track
of
the
number
of
reset
attempts.
So
the
standard
event
is
simply
say:
there
was
a
reset
attempt
against
this
account
and
I'm
notifying
some
systems.
I
They
might
want
to
reset
tokens
or
do
other
things,
and
here
we
want
to
keep
track
of
the
number
of
resets.
There
might
be
an
argument
to
include
all
that
as
an
optional
feature
that
skim
decide
to
do
or
they
might
not,
but
what
I'm
opening
the
door
for
is
that?
There's
no
reason
why
events
can't
be
extended
themselves.
I
I
I
I
Where
history
is
there,
the
entire
history
of
any
server
is
there
and
because
the
entire
history
is
there,
then
only
truly
trusted
God,
like
clients
can
read
that
that
part
on
ldap,
that
was
one
of
the
downside,
was
a
huge
security
problem
and
one
of
the
things
chuck
expressed
was
Chuck.
Mortimer
from
Salesforce
was
to
avoid
too
much
history,
keeping
where
I
could
get
events
from
a
year
ago.
That
might
not
scale
well.
I
I
O
Tony
nebulas
are
on
that
one.
You
know
we're
interested
in
specific
objects,
they
may
have
changed
given
a
watermark
time
and
the
watermarks
can
be
set
at
any
can
be
reset
at
any
time.
So
we're
not
always
going
back
to
the
to
his.
You
know
going
through
years
worth
of
history.
This
is
very
short,
yeah
yeah.
O
I
F
I
think
that's
so
one
approach
to
doing
that
is
to
look
at
merkle
trees,
probably
because
they
were
that
provides
you
a
way
to
prove
that
you've
got
an
entire
history
of
something
missing
yeah.
But
so
you
have
a
you.
Have
us,
you
have
a
trusted
third
or
two
that
keeps
track
of
hashes
of
your
all,
be
expensive,
sure
certificate,
transparency.
This
is
exactly
the
technical
part
right
if
you
want
to
spend
the
power
consumption
of
Denmark
doing
this.
Yes,
absolutely.
D
A
Q
Everybody,
this
is
sarah
squire,
sorry,
I'm
in
a
little
bit
of
a
delay,
and
so
one
of
the
use
cases
that
we've
been
looking
at
that
hasn't
been
brought
up.
Yet,
as
the
issue
of
consent
and
consent,
receipts
and
specifically
in
a
healthcare
context,
were
interested
in
Ferris
fire.
Sorry
I'm
on
a
little
bit
of
it.
Q
A
Q
Q
I
R
Q
I
D
L
I
Data,
these
events
might
occur
randomly
to
them
and
you
want
a
way
to
deliver
those
messages.
To
say
this
events
change
this
event
has
occurred,
so
I
don't
see
any
reason
why
that
wouldn't
work
I'm,
not
sure
whether
whether
there
couldn't
be
just
an
endpoint
to
do
that
and
what
would
be
the
difference
between
a
restful
approach
in
an
event
approached
the
event.
I
I
Okay,
a
couple
of
us
have
talked
about
mrs.
Moore
jaw
related
the
issue.
Dat
value,
if
I
understand
correctly,
is
the
date
that
the
jaw
was
minted.
So
there's
some
questions
in
large
production
systems,
whether
the
event
the
date,
the
event
occurred
versus
the
time
it
gets
published.
You
know
a
jot.
There
might
be
a
delay
seconds
minutes,
don't
know
just
a
placemark
for
an
issue
that
we
might
need
another
attribute
that
says
the
event
occurred
at
and
the
Miss
jot
was
issued
at
some
trade-offs.
I
There
I
think
the
reasoning,
and
maybe
my
core
John
can
explain
if
it's
really
important
that
issued
at
be
the
same
date
as,
for
example,
the
signature
on
the
job.
That's
what
I
was
thinking
was
relevant
if
you're
testing
that
the
job
is
valid,
is
it
important
that
they
issued
at
correspond
to
the
signature
time.
T
I
agree
with
that,
if
you
start
monkeying
around
with
saying
when
the
token
was
issued,
you
could
wind
up
having
all
sorts
of
unintended
consequences.
If
you
want
to
say
that
the
event
was
at
a
different
time
than
the
token
was
issued,
it
should
probably
be
a
different
value,
rather
than
people
use
issued
at
for
cash
control
and
in
D
duplicating
randomly
changing
around
these.
What
appears
to
be
the
sequence
of
the
of
the
packets
might
not
be
such
a
good
idea.
Yeah.
I
F
You
just
a
note
there
I
mean
we've
got
like
about
20
minutes
left
and
that's
fine
right,
but
it
may
not
be
the
best
use
of
our
time
to
sort
of
just
try
to
solve
all
of
the
all
aspects
of
ID
events.
Today,
right
I
mean
part
of
the
discussion
I'd
like
us
to
have
this
weather.
You
know
this
work
is
worth
doing
and
if
so
is
it
as
is
it
I
skim
extension
item
or
is
it
something
else?
No.
I
I
think,
as
the
point
was
made
earlier,
about
privacy
considerations,
I
think
this
can
get
tricky.
I
haven't
started
looking
at
those,
but
I
know
there
are
going
to
be
some
the
way
we'll
have
to
capture
this,
and
it
might
be
good
the
way
we've
proposed
to
segment
this
out,
that
there
be
a
core
draft
and
then
there'll
be
a
skim
draft,
and
then
the
skin
graft
would
deal
with
what
are
the
considerations
in
the
context
of
the
skim
environment,
which
may
be
entirely
different
than
say
the
heart
spec
or
the
risks
back.
T
So
John
Bradley
ping,
so
different
things
using
this
may
actually
have
different
notions
of
what
the
event
time
is
so
with
risk.
There's
when
did
the
event
occur?
When
was
it
discovered
and
when
was
the
token
issued?
Those
in
some
contexts
are
very
important,
distinct
values,
whereas
heart
may
have
a
somewhat
different
different
notion
of
what
what
actually
needs
to
be
captured.
That's
why
I
wouldn't
overload
it.
It
probably
is
up
to
the
individual
risk
should
define
you
know
if
they
want
to
have.
T
I
Possibility,
then,
is
if
a
protocol
let's
say
takes
Kim
wants
to
say:
when
the
change
occurred
from
skims
perspective,
it
could
go
in
the
skin
payload
and
so
that's
a
different
value
than
then
they
issued
at
time
and
it
might
be
relevant
to
skim
infrastructure
because
that's
the
date
that's
on
the
server.
If
you
query
the
record
so.
F
D
F
I
Going
back
to
those
were
sort
of
the
groups,
we
talk
to
you
so
far,
I
think
the
question
I
have
is
informally.
Is
this
a
good
start,
and
how
would
you
guys
like
to
see
this
move
forward?
If,
at
all,
is
this
something
one
of
the
questions
could
be?
There's
the
course
back.
We
get
the
course
back
down
and
then
the
skin
working
group
takes
care
of
the
skin
profile.
F
So
this
is
just
one
individual
observation
level
home.
So
just
because
it
looks
like
it
sort
of
culturally
inherited
some
of
the
formatting
convention
from
skin.
Does
it
mean
it
has
to
be
asked
in
working
item
or
items
right?
This
could
just
as
well
be
an
idea
that
working
group
doing
I
Kaskaskia
set
of
schema
for
ID
identity
events,
and
then
you
know
the
skin
working
group
can
do
a
profile
or
transport.
I
F
So
I
this
I
think
this
is
a
question
for
you
guys.
You
know
what.
How
would
you
prefer
because
there
seems
to
be
enough
interest
in
the
room
to
actually
work
on
stuff
like
this
I
mean
I'm
will
will
do
hum
sense
yet
right,
but
I
wouldn't
surprise
me
if
there's
interest
in
working
on
this.
So
the
question
is:
if
it
is
this
just
because
it
happens
to
that,
there's
a
skim
culture
here,
but
there
it
doesn't.
There's
there's
nothing
here
that
ties
this
to
skim
right.
F
F
Guess
I'm
actually
saying
both
if
we're
going
to
do
this,
because
I
think
skin
needs
to
do
a
profile
document
right,
which
means
that
pretty
at
least
Kim
needs
the
recharter
to
deliver
that
right.
But
but
the
question
is
whether
the
core
work
items
that
relate
to
the
scheme
of
ID
events-
and
you
know
how
do
you?
What
do
you
need
to
do
in
order
to
profile
this
for
your
transport
stuff
like
that
right?
Is
that,
should
that
happen
in
skin
I?
Don't
see
that
as
a
logical
risk?
I
don't
see
the
logic
of
that.
I
F
G
U
M
Had
a
son,
this
hat
is
nice
I
personally
think
it
would
be
good
to
have
a
separate
working
group.
It
could
be
created
very
fast
with
the
help
of
AD.
The
reason
for
this
is
that
it
from
a
disability
and
publicity
point
of
view
you,
if
it's
money
somewhere
into
the
milestone
and
chart
a
text
of
this
group,
fewer
people
get
to
know
about
it
vs.
if
it's
actually
dedicated
group
with
the
right
title
and
so
on,
I
think
it's
just
from
a
visibility
point
of
view:
transparency
on
the
viewing
much
better.
O
Tony
nodland,
I'm
sort
of
inclined
to
say
keep
it
in
the
skin
working
group
only
because
I
think
there's.
You
know
I
thought
I'd
like
to
make
sure
that
we
at
least
get
some
bowling
stuff
that
is
integrated
into
easy.
These
events
and
make
sure
all
that
stuff
works
in
parallel
and
to
put
it
in
another
working
group
mean
there
you
can
do
some
coordination
and
I
could
sort
that
all
its
gets
message.
I
Until
22
I
think
to
repeat
there's
some
element
of
that
that
I
agree
what
there
may
be
requirements
that
we
would
talk
about
in
the
skin
working
group
that
have
to
come
back
to
the
core,
I
think
minimally
we
would
have
to
commit
to.
If
we
keep
them
separate,
we
would
have
to
commit
to
working
on
this
simultaneously
in
both
groups
and
then
that
would
that
would
work
that
the
skin
working
group,
as
is
the
risk
and
open
ID,
would
would
be
part
of
the
participants
in
the
ID
token
group
and
provide
that
feedback.
K
N
K
V
Toast
motion
I
would
assume
the
day
of
working
group
would
not
only
define
a
basic
setup
claims
but
also
define
the
distribution.
Economic
I
mean
if
the
solution
mechanism
should
be
the
same
independent
of
the
different
schemes
for
the
events
of
something
like
that
would
be.
There,
then
beneficially
would
be
a
reason,
separate
working
group,
yeah.
V
I
Like
to
see
a
couple
of
methods
defined
as
a
base
and
then
maybe
establish
a
registry,
so
we
don't
close
the
door,
we
say
it's
there,
but
the
idea
would
be
say
if
you
haven't
got
anything
else
in
mind:
here's
here's,
a
method
that
you
can
use
that
these
events
can
be
distributed
with
how
far
we
go
with
that
and
how
much
of
a
registry
we
need.
I
would
like
to
get
a
lot
more
discussion
on.
I
For
example,
you
know
what
are
the
terminologies
that
we're
using
to
describe
such
a
relationship
where
somebody's
publishing
events
and
do
we
need
to
standardize
that
or
not
right
now,
in
the
distribution
draft
I
put
forward,
I
suggested
a
bunch
of
attributes,
but
it
may
not
turn
out
to
matter.
I
was
talking
with
a
few
people.
That
said,
a
lot
of
this
will
be
dealt
with
administrative
Lee
and
there
isn't
really
an
interrupt
need,
but
at
the
same
point
it's
valuable
to
just
to
at
least
define
the
terminology.
V
O
Terminado
into
torsten
from
the
skin
perspective,
there's
already
hit
use
directors,
but
there's
always
there's
repositories
that
already
have
mess
for
mashed
in
ways
to
distribute
these
types
of
pub/sub
stuff,
and
I'm
not
going
to
you
know,
have
to
recreate
that
in
in
this
area
of
this
year's
worth
of
work,
that's
gone
into
a
lot
of
the
pub
sub
engines
already.
So
if
you
want
to
do
a
profile
of
a
pub
sub
engine
that
may
exist,
I
think
that's
fine,
but
in
been
a
brand
new
oops
of
protocol.
V
Sawsan
again
I'm
one
of
the
guys
that
typically
does
not
turn
up
on
a
skin
meeting,
so
I'm,
not
so
Finland
familiar
with
that.
So
if
there
is
already
a
mechanism
and
skim
22
pops
up
mechanism,
why
is
there
a
distribution,
dr?
No
oh
you're,
right
but
you're
referring
to
proprietary
mechanisms
it
built
into
repro
stories.
O
O
D
F
The
first
question
I
think
I'm
gonna
ask-
is
that:
do
you
think
the
people
in
this
room
that
did
not
I
identity
events
is
a
useful
piece
of
work
and
that
the
IDF
should
work
on
it?
You
know
let's
talk
about
where
it
gets
done
later,
if
you
think
that
if
you
think
that
ID
events,
roughly
as
described
by
Phil
or
some
variant
variant
of
it,
is
a
useful
thing
and
that
the
ITF
should
work
on
it.
Please
hum
now.
F
F
We
can
have
that,
so,
if
you
don't
have
enough,
feel
you
don't
have
enough
information
or
don't
care
about
this
stuff,
please
hum
all
right.
You
guys
are
sitting
way
too
close
to
the
microphone
I'm
still
saying
it.
There's
there's
reasonable
consensus
for
for
that
there
is
something
here
that
could
be
work
that
should
be
worked
on
India
idea.
So
the
second
question
is:
is:
is
this
something
we
should
extend
skin-to-skin
working
to
work
on,
or
should
we
do
a
separate
working
group,
so
I'm
gonna
do
like
a
two-part
hum
here?
F
F
F
We
need
to
actually
find
volunteers
to
do
that,
work
so
hands
up
if
you're
willing
to
work
on
shorter
texts
for
a
new
working
group,
all
right
take
names,
torsten
and
Mike
and
John.
Oh
yeah,
there's
a
fair
number
of
people.
Okay-
and
let's
do
this
like
it-
was
a
both
raise
your
hand
if
you're
willing
to
write
and
or
review
drafts
in
that
working
group
same
people
all
right
all
right.
You
know
it
says
it's
the
usual
suspect
in
the
identity
space
in
the
IDF.
F
F
Here's
what
I'm
going
to
say
nowadays
that
we
need
to
have
a
conversation
on
the
mailing
list,
all
the
skin
made
in
this
about.
You
know
future
work
items
for
skin,
and
if
that
means
that
very
concretely,
if
you
do
have
I
day
IDs
written
up
or
ideas
for
stuff,
you
need
to
send
it
to
the
list
right.
It
would,
and
you
did
and
yes,
absolutely
there,
one
or
two
people
have
actually
done
that
right
and
this
time
around
we
only
had
we
only
got
one
hour,
so
it
in
that
time.
Right.
W
F
Need
to
get
to
that
point
yeah,
and
you
know
that
an
idea
vent
working
group
could
sort
of
buy
us
a
little
time,
because
obviously
we
would
have
to
to
a
profile,
and
that
would
be
a
rich
or
terrible
thing
right,
but
we
actually
have
to
read
shorter
at
this
point,
so
me
and
motel,
so
we
left
the
cake.
Oh
I,
think
we're
have
to
kick
off
a
conference
call
or
two
to
actually
talk
about
this
in
skin.
F
Do
you
have
anything
else,
mr.
area,
director
that
you
want
us
to
cover
before
we
left
everybody
go
all
right,
right,
I
think
that
the
idea
vent
people
need
to
sit
down
with
each
other.
Just
because
this
was
a
task
in
event
doesn't
mean
that
we're
necessarily
the
scheme
folks
are
reading
this
right.
You
guys
need
to
sit
down
and
do
each
other.