►
From YouTube: IETF97-SECEVENT-20161116-1110
Description
SECEVENT meeting session at IETF97
2016/11/16 1110
A
A
A
A
So,
as
I
said,
welcome
to
the
first
ever
sacrament
meeting,
the
first
initiatives
were
going
around
even
before
yokohama,
but
then
a
lot
of
them
came
up
in
the
yokohama
meeting
and
the
mailing
list
was
formed.
There
was
a
sort
of
buff
at
the
skim
session
in
90,
f
95,
that's
bonus,
eros.
There
were
similarly
draft
some
discussion
of
skim
use
cases
and
finally,
just
under
a
month
ago,
we
formed
a
working
group
and
we
have
our
charter.
A
The
next
milestone
on
our
charter
is
in
February
of
2017
to
adopt
draft,
so
we're
going
to
see
candidate
going
to
get
presentations
about
candidate
drafts
in
this
meeting
current
status.
So
we
have
a
new
working
group.
There
are
there
a
set
of
derivable
se
T
token
format,
profiling,
it
profiling,
jock,
secure
method
for
a
short
delivery
using
HTTP
POST
pub/sub
management
based
on
SC
I
am,
as
far
as
maturities,
consider
we're
profiling.
The
true
standards
JWT
and
skimmer,
considered
mature
HTTP
POST
is
well
both
simple
and
very
mature.
A
The
idea,
events
and
discussion
for
a
year
since
November
2015,
similar
standing
to
when
we
started
adopting
skin
off,
and
there
are
two
proposed
drafts-
how
many
people
in
the
room
I've
actually
read
the
drafts,
not
including
those
who
are
true,
Lord,
Carlton,
okay,
just
so
that
were
same
page,
how
many
people
are
familiar
with
jock,
JW
t
or
c
60,
75
foot,
19?
Okay,
how
are
familiar
with
skin?
A
B
B
B
So
the
what
is
the
main
problem
we
are
trying
to
solve
with
risk
accounts
are
interconnected,
so
Federation,
it's
the
obvious
use
case.
We
have
identity
providers.
Relying
parties-
and
there
are
also
counts-
are
connected
implicitly
to
recovery
options.
The
most
obvious
one
is
the
email
recovery
option.
B
So
if
the
email
provider
is
compromised
is
probably
most
people
understand
the
use
case,
but
others
sites
or
relying
parties
that
use
that
email
will
also
be
compromised
through
the
password
recovery
for
similar
things,
and
it's
not
only
email
it
can.
Phone
number
is
another
example,
but
the
most
common
one,
it's
email
that
we
talked
about
and.
B
If
an
account
gets
one-on-one
service
that
quickly
leads
to
that
account
being
owned
on
all
others
or
other
services
as
well,
so
in
Federation.
The
main
issue
we
are
facing
is
the
fact
that
relying
party
sessions
once
the
user
is
logged
in
those
sessions
themselves
are
disconnected
from
what
happens
at
the
identity
provider.
B
B
Once
the
account
is
recovered,
then
we
have
reactivated
accounts
again,
there
is
distinction
and
then
accounts
can
be
deleted
and
there
is
distinction
for
many
of
these
events
between
owner
and
provider.
Depending
on
what
the
situation
is,
the
provider
can
be
in
a
consumer
case
and
owner.
It's
an
enterprise
case
when
the
enterprise
administrator
explicitly
does
one
of
these
actions
on
the
account
and
the
other
one
is
the
reissued
accounts.
That's
when
the
an.
B
The
other
group
of
events
are
authentication
changes,
for
example,
password
changes
on
the
account.
For
some
reason.
If
the
older
sessions
are
the
identity
provider
are
evoked
for
the
user
recovery
options,
change,
like
you,
know,
recover
your
phone
recovery
change,
public
identifiers
change,
maybz.
In
some
cases,
users
change
their
email
address
and
many
relying
parties
use
that
in
your
abuse,
as
the
main
key
made
identifier
fact,
second
factor
added
or
removed,
or
grants
or
grants
or
other
kind
of
grants
or
tokens
being
revoked.
B
So
I'm
trying
to
highlight,
and
in
general,
for
security
events
in
particular
for
risk
that
the
recipient
of
these
events-
it's
always
the
users
application,
whatever
application
means.
So
if
it's
in
Federation
cases
based
on
ought
to
its
the
target
of
the
client
or
the
relying
party
that
the
auto
grant
was
issued
to
so
that's
the
only
recipient
for
events
related
to
that
user.
B
One
of
the
tricky
issues
with
with
risk
events
is
how
to
it
rerun.
It
is
around
privacy.
Basically,
how
do
you
keep
the
user?
How
do
you
notify
the
user
in
a
way
that
user
understands
what's
happening,
how
hard
it
transparent
to
the
user
and
the
other
one?
Should
you
or
how
are
you
going
to
give
some
options
to
the
user?
B
The
obvious
point
is
that
ok,
the
user
should
have
the
option
to
opt
out,
but
that's
what
an
attacker
would
do
in
the
first
place.
So
it's
a
it's
a
delicate
situation
and
the
the
more
delicate
one
is.
How
do
you
explain
all
these
events
that
you
are
sharing
to
the
user
in
a
very
meaningful
way,
so
this
is
still
a
work
in
progress.
I,
don't
think
we
have
a
good
solution
for
that,
but
we're
yeah.
That's
that's
still
up.
B
Just
a
few
notes
about
an
early
implementation.
We
we
have
at
Google,
so
we
are
started
publishing
to
type
of
events,
sessions
revoked
and
tokens
revolt.
So
sessions
evoked
happens
when
the
user
changes
the
password
or
explicitly
logs
out,
for
example.
So
we
are
just
not
if
we
can
notify
third
party
simply
by
the
fact
that
all
the
Google
closed
all
the
sessions
for
the
user
and
the
actual
reason
it's
not
shared
and
tokens
revoked
it
shared
with
third-parties
when
the
user
explicitly
terminates
a
relationship
with
one
third
party.
B
So
the
in
this
case
the
event
is
shared
only
with
the
relevant
third
party
in
duckies
and
in
near
future.
We
are
working
on
more
abuse,
related
events
when
accounts
are
locked
and
recovered,
and
currently
we
are
using
because
we
don't
have
a
standard
way
yet
for
distribution
you're
using
a
proprietary
cloud
pub/sub,
but
we
are
going
to
move
to
a
the
standard
one
as
soon
as
we
agree
on
the
implementation
and
also
we
are
implementing
only
a
publisher
with
plans
to
implement
a
subscriber
as
well.
B
So,
in
general,
open
issues
around
security
events
particular
about
risk.
As
I
mentioned,
meaningful
user
experience,
how
do
you
involve?
How
do
you
keep
the
user
in
the
loop?
That's
that's
a
very
tricky
thing
to
do
when
you
get
to
to
hijacking
and
abuse,
to
make
the
clear
distinction
between
hijacking
and
abuse.
Should
we
make
the
distinction?
B
So
we
need
to
solve
that
use
case.
So
we'll
probably
need
some
registration
flow
where
the
relying
party
explicitly
makes
an
API
call
back
to
the
IDP
saying:
hey
I
have
a
new
registration
which
is
email
address.
I
would
like
to
receive
secure
events
for
that,
just
as
the
high-level
plan
for
that
the
we
are
working
on
standardizing
distribution
and
the
sooner
we
get
to
a
standard
the
better.
So
we
can
start
implementing
as
usual.
A
big
problem
is
getting
critical
mass
enough
players.
B
We
can
start
exchanging
these
messages
and,
while
many
things
really
high
level,
we
do
have
understanding
how
are
moving
a
standard.
We
still
haven't
talked
about
how
to
standardize
each
event,
in
particular,
what
attributes
to
exchange
what
you
are
eyes
to
use
for
events,
it's
a
relatively
easy
problem,
but
still
that's
one
step
that
we
it's
one
problem.
We
haven't
sold
it
and
that's
the
last
slide
for
me.
A
D
D
So
the
problem
that
we're
solving
is
having
a
way
to
securely
have
an
identity
provider,
notify
a
relying
party
that
it's
to
log
out
a
particular
user
in
session
for
the
identity
at
that
identity
provider
and
it's
called
back
channel
because
it's
sent
directly
server
to
server
rather
than
communicated
through
a
front
channel
browser
redirect
channel
like
many
kinds
of
log
outs.
Next.
D
So
the
way
this
works
is
a
message
is
sent
to
a
defined
end
point
at
the
relying
party
that
supports
back-channel
logout,
it's
sent
as
an
HTTP
post,
and
the
format
of
the
message
is
a
jot,
which
happens
to
also
be
a
security
event.
Next,
the
claims
in
that
jot
should
be
unsurprising
to
those
familiar
with
ID
tokens.
D
D
It
just
uses
the
normal
top-level
jot
claims
to
identify
the
subject
of
the
event.
The
events
claim
is
used
for
the
spec
to
identify
that
this
is
a
logout
event.
This
does
not
use
a
special
transport,
such
as
the
event
transport
being
defined
in
the
other
draft.
It's
just
an
HTTP
message
next,
so
final
thoughts,
the
security
event
format
is
very
simple.
Just
like
jot
was
very
simple.
D
It
seems
to
work
well
for
this
use
case.
I.
Think
it's
going
to
work
well
for
some
of
the
other
use
cases
such
as
the
security
events
that
were
just
described,
I,
think
being
simple.
It's
likely
to
get
adopted
just
like
jot
appears
to
be
so
I'm
happy
with
this,
and
you
know
there
may
be
other
formats
to
find
for
other
things,
but
that's
outside
the
scope
of
what
I'm
talking
about
any
questions.
E
Just
a
richer
just
one
thing
that
I
think
is
going
to
be
a
sort
of
an
ongoing
discussion
in
this
group
and
I
know
you
and
I
have
talked
about
a
mic
and
that's
the
the
placement
of
the
issue
or
in
subject
inside
all
of
these
various
tokens.
Now,
for
the
case
of
a
log
out
like
this,
the
issue
or
in
subject
pairing
of
an
open
ID
connects
identity.
It
does
make
sense
because
it's
the
IDP
that's
generating
this
log
out
message
but
I.
E
So
there
will
be
another
level
of
issuers
and
I'm
very
afraid
of
us
getting
those
things
mixed
up
with
each
other
and
making
them
look
like
messages
that
they're
not
so
I
just
want
to
raise
that
I.
Don't
think
we
have
time
to
you,
know,
debate
that
here,
but
I
want
to
raise
that
as
an
issue
to
the
group
and
something
that
we
have
to
decide
what
we
want
to
do
with
this,
not
sure
I
acknowledge,
okay,.
E
D
Just
I
acknowledge
that
they're
certainly
going
to
be
events
with
more
complicated
relationships
that
have
to
be
expressed
in
the
data
structure.
This
was
a
simple
bilateral
and
it
works
well
already.
According
to
people
who
looked
at
it,
but
yes,
there
will
be
more
complicated
events
with
different
representations
and
the
spectrum
allows
that.
F
G
You
know
they
put
out
the
events
into
feeds
and
you
can
pull
from
the
feeds
and
and
take
it
from
there,
and
you
can
pick
you
know,
pick
the
events
that
you
want
to
be
interested
in
or
you
want
to
apply
to
your
to
your
directory,
and
so
this
is
probably
some
work
that
may
have
been
able
to
be
done
in
skin,
but
now
skin
is
shut
down.
You
know
we
looked
for
another
way
to
actually
do
this
in
this
one
actually
works
very
well.
G
We
do
not
use
the
sets
okay,
so
that's
one
thing
that
we
would
definitely
like
to
see
changed
is
right.
Now
the
specs
actually
say
that
you
wind
up
using
the
the
JWT
and
we're
not
using
that
we
have
other
things
that
we
put
into
the
as
far
as
events,
different
formats
of
events
and
JWT's
don't
actually
fit
this
particular
case.
So
you
know,
relax
sation
of
what
actually
goes
in
there
may
may
help
us,
you
know,
get
some
things
done.
F
F
Well,
if,
from
a
provisioning
perspective,
a
password
was
reset
or
an
account
was
locked,
we
had
a
similar
set
of
events,
so
one
of
the
things
I
think
we'll
be
thinking
about
going
forward
is:
do
we
have
some
reconciliation
of
events
or
is
what
the
skin
working
group
if
they
want
to
assert
a
separate
set
of
events
and
risk
working
group
sets
it,
and
even
though
there's
overlapping?
Is
that
a
bad
problem
for
me
on
the
set
side
of
things
I'm
looking
at
it
going
are
there?
Is
that
mean
an
issue
in
common?
F
Does
that
mean
some
advice
that
we
can
lay
out
on
the
course
back
that
helps
these
other
working
groups
decide
what
they
want
to
do
if
it
hasn't
been
said,
I
think
one
of
the
when,
when
this
work
started,
it
was
because
I
noticed
that
all
these
working
groups
were
working
on
a
very
similar
problem
and
I
fine
book.
Jays,
maybe
we
could
use
jots
and
bring
them
all
together
and
at
least
have
common
libraries
some
common
interoperability.
F
The
question
is
how
much
is
in
common
and
how
much
independence
so
I
talk,
I'll
use
terminology
like
profiling,
spec.
So
what
I
mean
is
a
spec
like
the
risk
working
group
would
write
their
spec.
They
define
an
event
for
risk
that
leverages
the
set
token
spec,
so
they
get
into
the
specifics
of
what
their
events
mean.
So
a
lot
of
times
when
we're
talking
about
set
its
the
coursepack
that
everybody's
building
off
of
it
doesn't
necessarily
have
real
events
right
now.
F
F
F
We
have
a
couple
things
that
we're
still
talking
about
some
good
ideas
to
optimize
and
I'll
mention
that,
on
a
later
slide,
distribution
is
only
at
revision
1
and
we
are
still
trying
to
sort
out
what
are
the
real
distribution
problems
and
even
harder
is
how
do
we
manage
the
pub
sub
relationship,
so
we've
we've
kind
of
defined
two
issues
in
distribution.
It
may
cause
us
to
split
this
draft
up
into
two
separate
specs.
When
is
the
control
plane?
How
do
I
manage
as
the
subscriber?
F
How
do
I
tell
the
publisher
I'm
interested
in
its
series
of
events?
How
do
I
exchange
all
the
configuration
keys?
I
want
a
signed
event:
here's
my
public
key
or
want
to
encrypt
event,
here's
my
public
key,
so
you
can
encrypt
the
event.
What's
your
public
key,
so
that
I
can
validate
that
that
it
was
sent
by
you
if
the
endpoints
are
protected
by
0
auth,
we
have
to
have
some
management
of
tokens,
and
all
of
that
so
there's
a
fair
amount
of
logistics
to
just
get
these
connections
working
securely.
F
So
the
control
plane
allows
a
client
or
even
a
publisher
administrator
to
manage
those
subscriptions
and
also
check
the
status
of
a
subscription.
If
I've
subscribed
to
google
to
get
a
bunch
of
events
and
I'm
kind
of
normally
getting
a
thousand
events
an
hour
and
I,
not
gotten
anything
for
the
last
couple
hours.
Is
it
because
there's
been
no
events
or
is
because
there's
a
failure,
condition
because
a
key
rollover
occurred
and
guess
what
we're
not
configured
correctly?
F
F
The
only
thing
that
is
complex
about
is
that
we
require
the
receiver
before
acknowledging
receipt
by
sending
it
back
an
accepted
response.
It
should
at
least
check
that
the
event
was
valid
so
that
the
publisher
can
assume
the
event
was
delivered.
It
was
just
a
if
it's
just
a
post
and
they
get
an
accepted
immediately
and
the
subscriber
wasn't
able
to
parse
it
or
wasn't
able
to
sort
of
it.
Just
got
gobbledygook,
we
wanted
to
actually
say
I
couldn't
parse
the
event,
so
that's
as
complex
as
we
want
to
make
that
that
profiles
there.
F
There
has
been
discussion
about
other
modes
of
delivery
through
secure
messaging
from
mobile,
apps,
HTTP
HTTP
to
web
push.
There
are
other
models
and
from
there
I
kind
of
say,
okay,
no
problem,
let's
not
get
crazy,
but
maybe,
if
you
do
it,
we
should
make
you
go
through
some
criteria
for
why
you're
doing
it.
What
are
the
security
issues
you
should
consider
and
how
would
a
client
understand
how
you
choose
to
distribute
that
event?
H
Now
I
see
why
you
had
some
of
the
other,
why
you
had
a
different
transport
listed
on
your
your
notes.
Don't
think
that
one
meets
your
needs.
A
taxi
1,
I'm
wondering
I
haven't,
looked
at
a
draft
untidy
event
distribution,
but
I'm
also
wondering
you
know
we're
in
an
early
stage.
So
let's
compare
what
options
are
there
in
mile
there's
an
XMPP
grid
draft
that
has
pub/sub
capabilities
it's
in
use
by
at
least
10
vendors?
Now
I
I,
don't
know
the
current
number.
But
the
author
is
like
right
right
here.
H
I
F
J
So
this
is
the
easy
just
to
answer
some
of
the
questions
and
we
can
take
it
offline
because
I'm
sure
it'll
be
longer.
So
there
is
bilateral
pneus.
There's
the
question
of
from
this
control,
plane
and
security
aspects.
We
need
to
clarify
on
what
that
bilateral
nest
means
typically
a
whether
it's
XMPP
or
the
other
ones,
whether
it's
amqp
and
you
talk
about
queues,
vs
XMPP.
It
talks
about
topics
right.
J
F
A
check
one
example,
I
think
Mike
sort
of
example
didn't
complete
it,
but
one
simple
example:
is
an
identity
provider
at
an
open,
ID
provider.
Issuing
a
logout
token
to
the
relying
party
website
is
one
direction,
but
often
people
have
cases
saying
I
want
to
initiate
the
login
at
the
retail
site
and
we
want
to
let
the
opie
know
so.
In
effect,
the
initiation
could
occur
at
either
end
and
then
risk
sort
of
talks
about
same
thing,
risk
events.
F
H
I
got
it
because
I
just
remembered
that
working
a
blast
call
will
start
on
that
draft
soon.
So
if
people
from
this
group
want
to
just
jump
on
the
my
list
with
some
reviews
of
it,
that
would
be
really
helpful
just
to
make
sure
if
you
do
go
ahead
with
it
that
you
caught
anything
you
needed
to
catch
thanks.
Kathleen
Moriarty,
ad.
F
F
There
are
some
things
to
sort
out
about
things
like
issued
at
there
can
be
cases
where
the
time
at
which
the
event
is
published
is
not
necessarily
the
time
the
event
actually
occurred.
So
we
may
need
language
on
that
andie
nash
a
couple
of
weeks
ago,
brought
up
a
case
that
they
do
some
analysis
and
discover.
A
week
later
there
was
a
problem
in
the
expected
occurrence
of
the
event
looks
like
a
week
ago,
but
I'm
issuing
the
report
now
so
right
now
we
only
have
one
attribute.
F
There
can
also
be
Delta
differences
just
simply
because
you
have
a
distributed
architecture,
the
component
that
detected
the
state
change
or
the
issue.
It's
not
necessarily
the
one
that
published
the
event
to
its
subscriber
and
there
might
be
a
minute
lag.
Even
so,
we
have
to
sort
that
out.
The
events
was
the
attribute.
Mike
already
mentioned,
that's
how
you
indicate
what
type
of
event
is
being
there.
It
also
might
give
it
a
hint
as
to
what
amount
of
payload
is.
F
We
notice
that
there
are
a
lot
of
cases
where
we
might
express
the
same
event
in
two
or
three
different
ways,
because
the
subscriber,
for
example,
might
not
understand
what
suspicious
activity
means
and
mary
has
brought
up
the
case
a
lot
of
times
they
just
say,
look
cancel
the
sessions.
Just
don't
worry
about
the
reason
why,
since
you
don't
understand
the
reasons
why
and
can't
consume
that
will
just
send
you
a
a
session
revocation
there
are
cases,
then,
when
you
want
to
go
back
and
say
we're
all
these
events
actually
stemming
from
the
same
occurrence.
F
So
if
I
shoot
three
different
representations
of
an
event,
transaction
could
be
used
to
say
this
was
actually
stemming
from
the
same
thing,
even
though
it's
expressed
multiple
ways,
the
event
objects
the
discussion
earlier,
which
was
if
I
need
to
pass
an
issuer
for
the
subject,
as
opposed
to
the
issuer.
For
the
event,
you
would
use
a
payload
for
that.
You
might
have
just
other
data
like
in
password
resets.
You
might
be
keeping
track
of
how
many
times
is
the
user
reset
the
account
as
additional
data.
F
F
Maybe
it's
a
good
thing
or
not
a
good
thing,
but
the
idea
that
when
people
were
saying
I
wanted
to
send
it
out
over
I
message,
we
knew
the
thing
could
be
self-contained
and
encrypted.
If
that's
what
we
want
to
do
so
the
requirement
to
have
a
bulletproof
transport
were
less
dependent
on
it.
There
go
ahead
next,
so
this
is
Mike's
example
of
a
log
it,
but
here
I
show.
F
Sorry,
you
probably
didn't
hear
that
as
I
walked
away
from
the
mic,
the
separate
issue,
where
n
SIDS
the
idea
would
be
that
the
issuer
here
is
the
issuer
of
the
subject
up
above
and
the
publisher
of
the
event
is
server
example
calm.
It
was
not
the
server
that
issued
the
identity,
so
the
optimization
we're
talking
about
is
moving
this
Jason.
I
F
Yeah,
the
optimization
is
to
take
this
JSON
object
after
that
URL
and
move
it
into
the
events
attribute
as
a
sub
object
of
up
there,
so
that
it's
all
self-contained
and
then,
if
you
have
no
data,
would
you
just
put
null
or
would
you
put
MPs
race
brackets
we're
just
coming
down
to
just
empty
brackets
would
be
fine
and
it's
short
and
it's
it's
easier
for
faster
parsing.
So
that's
one
change
to
the
current
draw
next,
so
the
delivery
side
is
to
contain
an
HTTPS
post,
some
call
it
a
web
call
back.
F
We've
talked
about
delivering
multiple
messages
or
one.
So
far
the
testing
saying
don't
bother
with
batching.
Just
do
one
at
a
time
maintain
your
connection,
pooling
and
you'll
be
good.
All
you
do
when
we
start
doing
multi
messages.
We
get
into
a
lot
more
complex
signaling,
so
we
want
to
keep
it
simple.
F
There's
there's
still
discussion
on
that,
but
that
seems
to
be
settling
down
based
on
some
of
the
testing
it.
As
I
mentioned
earlier,
HTTP
status
202
is
used
to
confirm
receipt.
So
when
you
issue
that
receipt,
what
you're
saying
to
the
publisher
is
I
got
it
now,
whether
you
actually
test
or
not,
is
your
business
but
you're
letting
the
publisher
give
up.
So
that's
one
of
the
conditions
were
setting
saying
we're
not
going
to
get
as
sophisticated
as
that.
F
There's
no
call
back
or
act
messages
your
if
you
didn't
get
the
message
or
18
able
to
parse
it.
You
should
throw
an
error,
so
we
do
define
a
bunch
of
HTTP
status,
400
errors
that
are
really
more
often
than
not
relating
to
jot
parsing
issues
that
occur.
You
got
the
wrong
key.
The
signature
wasn't
valid
and
things
like
that
next
slide.
F
So
in
thinking
about
the
broader
scope,
I'm
not
happy
with
this
slide,
yet
it
was
something
I
added
late.
We
are
trying
to
define
what
does
it
mean
to
have
a
feed
of
events?
Is
it
a
category
of
events?
I'm
subscribing
to
get
a
series
of
events
from
a
publisher
and
I
need
an
endpoint
to
deliver
them
to.
So
what
is
the
relationship
to?
This
is
saul
building
towards
a
data
model
for
the
control
plane
and
how
to
deal
with
this.
So,
given
a
hat
there
might
be
I've
only
listed
for
that.
F
There
make
me
many
different
events
that
could
be
generated.
Different
formats
I
could
create
feed.
So
the
example
I
sort
of
chose
was
I
might
have
an
open
ID
provider
that
wants
to
issue
log
out
events,
and
how
would
it
group
those
log
out
events
of
interest?
Well,
it
might
group
those
by
audience
and
the
effect
of
the
audience
might
be
that
everybody
within
a
single
sign-on
domain
carries
the
same,
carries
the
same
audience.
F
So
I
might
have
servers
in
hong
kong
servers
in
china
and
they
both
might
choose
to
subscribe
to
the
single
sign
out
feed
for
asia
for
this
customer.
So
the
idea
was
a
many-to-one
relationship
between
feeds
and
subscriptions
for
various
reasons,
we're
also
talking
about
changing
some
of
the
terminology,
so
this
is
up
in
the
air,
not
very
mature.
F
Then
it's
something
from
our
earlier
discussion.
Merius
anyway,
let's
go
on
Oh
risk
adds
another
concept
of
you
have
a
feed
to
find
a
logical
feed
between
two
entities.
Let's
say
it's:
it's
Oracle
in
Google,
when
we
first
set
that
up,
there's
no
users
in
that
feed,
there's
no
subjects
that
are
going
to
come
across,
but
over
time
through
these
explicit
or
implicit
connections.
F
Google
will.
Let
us
know
that
says
this.
This
user
Phil
hunt
is
using
our
services,
so
we'd
like
to
get
security
events
about
Phil
hunt
and
they
would
they
would
register
and
say,
Phil
hunt
is
to
be
added
to
this
feed
or
Phil
hunt
us
to
be
removed
from
this
feed,
and
that
would
be
part
of
the
control
plane.
F
So
we
were
talking
today
that
that
Mayor
this
morning
that
maybe
what
I
was
calling
a
subscription
is
really
kind
of
a
connection
path.
This
is
where
I'm
going
to
physically
deliver
a
series
of
events
to
specific
web
ed
point
over
a
specific
protocol,
be
at
HTTP
or
XMPP,
or
something
like
that
and
how
do
I
do
that?
What
do
I
need
to
do
to
correct
construct
the
job
correctly
for
that
subscribe
or
all
the
management
information
that
goes
with
it?
So
that's!
F
What's
in
the
definition
for
a
subscription
and
for
any
feed,
there
can
be
many
subscriptions
next
slide,
I
put
in
a
state
diagram
and
it
actually
was
interested.
I
was
already
working
on
it.
When
Kathleen
noticed
you
were
Steve
and
I
raised
the
net
comp
issue,
there's
a
lot
of
parallels.
So
while
we
felt
we
were
very
different
in
our
stack,
we
were
using
jot
and
using
other
things.
F
I
thought
there
was
a
lot
to
be
learned
from
and
one
of
the
things
they
had
I
thought
that
interesting
was
a
state
diagram,
so
you
can
have
a
subscription
and
that
subscription
can
actually
be
in
multiple
states.
It
can
be
on
it
can
be
off,
it
can
be
failed.
What
does
it
mean
in
each
of
those
states?
F
We
have
a
state
when
you
create
a
subscription
called
verify
and
what
that
allows
is
for
a
special
event
to
be
sent
called
a
verification
event,
which
is
simply
is
this
connection
working
and
can
they
parse
my
events
and
if
the
verification
is
good,
then
we're
set
to
go.
I
saw
in
some
other
specs.
It
was
also
a
useful
way
to
prevent
a
denial
of
service
attack
where
somebody
fraudulently
wrecked
reckon
fraudulently
tries
to
set
up
a
subscription
just
to
annoy
someone
else
with
a
lot
of
data.
F
So
if
the
endpoint
you
get
is
actually
doesn't
know
how
to
parse
it
or
isn't
a
real
endpoint,
you'd
quickly
know
this
isn't
going
to
work
and
you're.
Just
doing
you
go
straight
to
fail,
and
it's
done
so
that's
where
we're
going
and
then
operationally
things
change,
keys,
rotate,
Connection
network
problems
are
going
to
exist
and
we
can
anticipate
that.
Maybe,
after
a
bunch
of
trials
to
deliver
an
event,
the
publisher
will
flag
that
has
failed,
and
so
how
does
the
subscriber
know
about
it?
F
C
F
Have
to
apologize
sub
status
is
wrong,
it
would
be
verify
or
or
on
or
one
of
those
pending
was
from
an
earlier
version.
So
that's
wrong,
but
that
would
actually
foremost
ongoing
queries.
When
you're
checking
the
status
of
the
subscription,
you
would
be
looking
to
see
that
it's
on
normally
and
then
on
the
next
slide.
If
I
want
to
pause
it
because
I'm
doing
something
with
my
endpoint
I
have
to
reboot
the
cluster
or
do
something
I
can
ask
the
publisher
to
pause
the
subscription
next
slide
so
down
here.
F
The
subscriber
can
do
a
simple
put
and
he
changes
the
value
of
sub
status
to
paused,
and
that
tells
the
publisher
to
hold
on
to
events
for
as
long
as
you
can.
One
of
the
things
we're
talking
about
is:
what's
the
publishers
ability
to
store
events
or
queue
them
up?
If
it's
a
high
rate
of
events,
it
might
be
completely
unrealistic
beyond
a
few
milliseconds
other
ones
where
it's
a
hundred
events
a
day
could
probably
hold
it
for
days.
That's
something
that
a
publisher
and
subscriber
would
have
to
work
out.
F
F
So
the
verify
I
mentioned
this
earlier,
we
can
probably
go
on,
but
it's
basically
the
pain
command.
That
says.
Can
you
read
this
thing?
It's
not
actually
a
real
event,
so
we're
specifying
the
one
standard
event
which
is
a
verify
event,
and
it
just
simply
says
is
the
connection
work,
and
can
you
read
it
in
parts?
F
So
this
was
the
the
format
that
Justin
proposed
that
we
just
put
the
payload
as
part
of
the
events
attribute
as
a
sub
object,
so
I've
got
it
up
there.
That
seems
very
reasonable
and,
from
my
perspective
of
da
thing,
so
Tony
raised
the
issue
on
distribution
before
the
meeting,
so
it
went
on
to
the
slide
deck
we've
had
other
things
about
this
Lee
subscription
model
good,
but
one
of
the
ones
Tony
said
is
why
arbitrarily
limit
this
to
jots?
F
Maybe
we
can
use
the
control
plane
to
manage
other
relationships
and
other
protocols
and
other
formats
and
they'll
be
some
reworking,
but
I
don't
see.
Why
not,
though
I
come
back
to
that,
the
chartered
objective
is
to
make
sure
we
can
deliver
a
jot
correctly,
but
I
don't
see
any
reason
why
we
should
shut
it
down
so
be
interesting
comments
on
that.
One
yeah
so
and
also
Kathleen's
comments
on
taxing
sticks
are
well
well
advised.
So
that's
it.
H
J
H
F
K
So
this
is
ben
k,
dukh-
and
maybe
I
just
missed
this
when
you're
talking
about
it,
but
at
least
on
the
slides
for
the
verification,
is
that
literally
just
ensuring
that
the
connection
works
properly?
That's
not
doing
anything
about
confirming
that.
You
know
if
somebody's
claiming
that
they
have
a
user
with
this
email
address
that
you
know
they
actually
have
that
email
address
or
anything
like
that.
Yeah.
C
F
I
don't
mind
voting
on
that.
We
actually
had
three
alternatives
for
well
one
following
the
format
in
general.
The
real
question
is
when
there
is
no
payload
what
should
go
after
I?
Would
it
be
the
event
you
are
I
colon?
No,
should
it
be
event
you
are
I
colon
true
or
an
empty
set
of
brackets
and
I
prefer
the
last
one,
the
first
one,
some
people
thought
when
they
read
it.
F
That's
saying
I'm,
not
asserting,
then,
because
it's
null
true
is
valid,
but
a
lot
of
people
who
are
writing
code
might
be
lazy
and
they're
always
expecting
adjacent
object,
so
that
then
we
came
back
to
why?
Don't
we
just
assert
an
empty
object
and
I'm
saying
I
have
no
payload
and
it's
less
characters
so.
C
C
L
John
John
Bradley
ping,
so,
while
I'm
personally
in
favor
of
the
empty
object,
I
think
that
we're
probably
knew
enough-
and
this
hasn't
actually
been
discussed
on
the
group
mailing
list-
that
we
may
actually
want
to
make
sure
that
the
docking
people
have.
The
document
has
been
adopted
as
a
working
group
document
and
people
read
it
before,
we
necessarily
start
making
changes,
but
I
happen
to
be
in
favor
of
the
empty
object.
Hopefully,.
F
I
E
F
M
I
L
Again,
just
one
clarification:
there
were
two
sort
of
issues
that
we're
floating
around.
One
was
whether
or
not
the
subject
should
be
inside
of
the
the
object
or
and
whether
or
not
everything
should
are
whether
or
not
claims
in
general
should
be
inside
the
object.
I'm,
assuming
that
we're
only
talking
about
creating
the
object,
but
not
necessarily
enforcing
that
the
subject
must
always
be
in
there,
because
if
that
was
the
case,
then
other
people
would
be
up
at
the
mic
or
at
your
throat.
My.
F
F
F
A
Okay,
okay,
thank
you
very
much.
So
a
couple
of
notes
from
the
chair.
The
next
milestone
for
this
group
is
to
adopt
drafts
and
all
the
dresses
were
presented
here
are
still
candidate.
Drafts
are
not
working
draft
and
I'm
not
going
to
take
a
ham
now,
because
not
enough
people
in
the
room
who
are
not
authorized
ever
have
read
the
draft
so
we'll
give
you
more
time
to
read
the
drafts
and
then
we'll
make
a
cough
reduction
on
the
mailing
list,
but
that
requires
that
people
actually
read
the
draft.
A
So
please
do
so
and
we
want
to
have
drafts
adopted
before
Chicago,
but
doing
it
earlier
is
better
than
doing
it
right
before
Chicago
second
thing,
the
technical
discussions
should
happen
on
the
list.
I'm
sure
there's
has
been.
There
have
been
a
lot
of
technical
discussions
in
the
last
2-3
weeks
since
I've
become
subscribe
to
the
mailing
list,
and
there
has
been
nothing
so
the
discussions
are
happening
somewhere
else.
Please
move
them
to
the
list.
Third
thing
is
that
some
people
approached
me
in
doing
this
weekend
said
this
shouldn't
be
working
with
this
work.
A
M
Don't
that
all
have
a
problem
with
this
work
being
done,
I
think
it's
great
work
for
identity
security
events.
This
is
not
a
etf
security
events.
This
is
wonderful
work
on
identity,
security,
events
which
needs
to
be
done
and
so
to
call
the
ITF
security
events
and
for
the
outside
world.
Looking
at
it
is,
is
confusion
relating
with
inside
your
organization.
M
You
know,
indeed
what
you're
talking
about,
which
is
great,
but
for
other
people
looking
at
it's
like
what
is
going
on
here,
and
so,
if
there
can
be
maybe
a
little
clarity,
it's
a
middle
point
on
it.
That's
that's
the
first
thing
that
that
I
have
to
say,
as
an
outsider,
though,
who
subsidies
done
a
lot
of
other
identity
work?
M
It
could
be
of
interest
I,
don't
know,
I
haven't
delved
down
that
direction
yet,
but
it's
one
that
intrigues
me
personally
and
if
I
would
have
liked
data
models
for
what
you're
doing
here
I
see
how
I
can
apply
it
in
that
world.
So
those
are
two
requests.
I
have
one's
a
meta
point
in
terms
of
your
your
naming
and
the
second
one
is
in
terms
of
data
modeling,
so
that
we
can
see
if
its
applicability
in
other
areas.
Thank
you,
I'm.
N
Iran's
affirm
hearing
a
lot
of
potential
privacy
issues
as
some
more
subtle,
like
transaction
IDs,
revealing
information
between
applications.
Some
less
subtle,
like
the
implicit
whatever
it
was
called
in
the
race
presentation,
were
the
mere
fact
that
I'm
using
gmail
address
as
a
recovery,
email,
a
means
that
Jim
and
that
Google
gets
to
find
out
about.
Basically
everything
I'm
using,
and
so
I'm
not
quite
sure
how
to
handle
it.
N
H
So
I
was
gonna,
wait
till
the
technical
line
was
was
done
and
but
people
are
leaving
the
room.
So
I
would
like
more
volunteers
for
chairs.
I
am
supposed
to
talk
to
at
least
one
person,
but
yo
F
has
been
kind
enough
to
be
an
acting
chair,
and
so
thank
you
very
much,
but
please
send
a
message
to
Stephen
and
myself
because
we
work
on
these
things
together
about
you
know
if
you'd
like
to
be
a
chair
of
this
group.
K
Benkei
decks
are
just
falling
a
little
bit
off
the
previous
comment
that
you
yes,
this
is
essentially
worth
doing,
but
you
know
identity
and
identity
events
or
not
you
there's
not
a
monopoly
for
them
in
the
web
in
the
world.
There's
certainly
other
things
that
you
might
be
interested
in.
This
are
perhaps
not
even
in
the
room.
E
Just
in
one
of
the
things
that
was
in
the
room
but
was
told,
we
didn't
have
time
for
it
on
the
schedule.
One
of
the
driving
use
cases
that
started
out
this
working
group
is
actually
work
that
we've
been
doing
in
the
open,
ID
foundations,
heart
working
group,
and
that's
all
about
notification
and
audit
ability
of
consent
transactions.
E
So
when
a
user
says
yes,
I'm,
allowing
this
medical
record
to
go
to
this
provider
or
something
like
that,
providing
a
way
to
ship
that
kind
of
information
and
one
of
the
things
that
happen
when
we
first
founded
this
working
group,
what
that
was
due
to
a
realization
that
the
stuff
that
we
were
working
on
and
the
stuff
that
risk
was
working
on
there
was
this
common
thread
that
we
wanted
to
start
pulling
at.
So
there's
a
lot
more
than
just
identity.
Transaction
events.
E
C
Agree
with
that
comment
and
I
just
wanted
to
add
on
the
topic
of
kind
of
why
we're
doing
this?
You
know
one
of
the
one
of
the
reasons
is
that
you
know
job
was
obviously
standardized
in
the
ITF,
and
this
is
a
profile
of
chart
that
describes
how
they
can
use
the
security
events,
and
you
know
doing
on
that
comment
from
justin-
is
that
we
wanted
to
make
sure
that
there's
kind
of
one
way
to
do
this,
that
all
these
different
groups
could
could
use
and
avoid
having
sort
of
competing
ways.
C
And
when
we
first
looked
at
the
problem,
they
were
sort
of
some
messy
hacks
using
jot
to
to
a
sort
of
avoid
like
accidental,
miss
processing,
11
type
of
jhad
as
a
different
type
of
job,
and
so
we
sort
of
felt
like
also
be
safer
and
more
secure
to
have
kind
of
this
one
representation
of
an
event
to
meet
the
process
easier.
So
I'm
personally
in
favor
of
doing
this
work
in
the
IDF.
If
we
can.