►
From YouTube: IETF104-SECEVENT-20190327-0900
Description
SECEVENT meeting session at IETF104
2019/03/27 0900
https://datatracker.ietf.org/meeting/104/proceedings/
B
C
A
D
D
D
D
D
We
announced
the
working
group
last
call
for
our
next
upcoming
document.
Push
delivery
didn't
get
enough
responses.
If
I
remember
correctly,
we
only
had
three
responses
to
the
working
group
last
call
which
was
insufficient
to
announce
consensus,
and
so
this
is
where
we're
at
right.
Now
we
have
a
document,
that's
back
to
the
working
group,
no
consensus
announced
and
we
need
to
understand
together
em
what
we
can
do
about
it.
E
Good
morning,
everybody
names
Annabelle,
Backman,
Amazon
I
am
here
to
talk
about
push
based
hook
and
delivery,
as
Yaron
just
said
it.
So
just
quick
run-through
of
what
we're
talking
about
here.
This
is
the
goal
here
is
to
be
able
to
deliver
sets
via
HTTP
posts
from
a
set
transmitter
to
a
set
recipient.
The
protocol
is
pretty
simple:
the
it
starts
with
a
post
from
the
transmitter
with
a
set
in
the
body
next
and
hopefully
ends
with
a
202
response
from
the
recipient.
E
Alternatively,
it
ends
in
a
failure
response,
pretty
straightforward,
you've
all
probably
seen
this
before,
because
you've
read
the
spec
right
where
we're
at
right.
Now
we
had
a
go
for
draft
published
early
this
year
with
the
working
group
last
call
that
yarn
mentioned
in
January
in
February,
and
then
we
had
the
most
recent.
Oh
five
draft
published
after
that,
with
updates
from
the
few
responses
we
did
get
and
to
that
last
call.
E
Implementations
are
about
where
they've
been
one
update
on
that,
as
Google
has
actually
gone,
live
with
a
set
transmission
for
risk
events
for
there,
oh
I
DC
clients,
so
there's
actually
a
live
in
the
wild
production
implementation
of
this
out
right
now.
Next,
so
talk
about
what's
changed
since
oh
three,
one
of
the
more
significant
changes
was
adjusting
the
language
or
unvalidated.
The
validation
requirements
are
a
few
things
that
weren't
clear
there.
E
So
you
added
a
couple
of
statements
there,
one
to
make
it
explicit
that
the
set
recipient
should
be
validating
the
fact
or
must
must
validate
the
fact
that
they
are
willing
to
receive
sets
from
this
issuer.
So
in
the
example
diagram
there,
the
recipient
should
check
the
issue
or
make
sure
they
they
know
who
set
that
example.com
is
demo
com.
They
trust
us
they
expect
to
receive
sets
from
those
issuers
they
like
that
they
don't
know
who
set
unknown
commas,
so
they
don't
want
to
receive
offence
there
separately
from
that.
E
The
recipient
also
needs
to
validate
that
they're
willing
to
receive
this
particular
set
from
the
transmitter.
That's
transmitting
it
they
might
want
to
receive
set.
Example.Com
sets
from
example
court,
but
they
don't
expect
that
from
demo
Inc,
so
they're
gonna
reject
that
set.
This
is
two
different
kinds
of
failure:
modes
that
the
recipient
needs
to
watch
out
for
next.
E
E
So
there's
a
lot
of
different
ways
that
a
set
could
be
rejected
or
by
the
recipient,
but
it
turns
out
that
there's
not
a
lot
of
ways
that
it
could
be
rejected
where
the
transmitter
could
actually
do
something
useful
in
response
to
that
other
than
just
notify
at
the
administrators
that
hey
this
was
reductant.
We
don't
know
why
something's
wrong,
so
he
came
up
with
this.
E
So
where
are
we
right
now?
There
aren't
really
any
open
questions
that
are
before
the
working
group
there
that
are
before
this
spec.
So
the
question
really
goes
to
yahrens
point
earlier
of
how
do
we
move
forward
on
this
draft?
How
do
we
get
engagement,
get
people
to
read
it
comment
on
it,
decide
if
it's
something
we
want
to
push
forward
with
or
or
not
ace.
You
want
to
have
that
discussion
at
the
end
of
the
time,
so
we
can
punt
on
that
for
now,.
E
Okay,
item
number
two
is
subject:
identifiers
for
security
event;
tokens
quickly
summarize
what
we're
talking
about
here
a
subject.
Identifier
is
a
JSON
object
that
has
a
subject
type
and
contains
a
set
of
claims
that
whose
meaning
is
defined
by
that
type.
What
is
a
subject
type?
Let's
look
at
the
next
slide
a
subject.
Identifier
type
is
just
a
simple
schema
for
representing
a
or
identifying
a
subject
by
some
set
of
claims.
E
The
use
case
here
is
that
in
sets,
we
sometimes
need
to
represent
or
identify
a
subject
in
a
variety
of
ways
and
even
within
a
single
use
case,
you
might
need
to
support
multiple
types
of
identifiers,
so
we
want
to
be
able
to
know
what
type
of
identifier
this
is.
How
are
we
supposed
to
have
process
it?
So.
E
Here's
an
example
from
risk
in
the
account
disabled
event
we
have
within
risk.
We
have
a
subject
claim
in
the
event
payload
that
identifies
the
subject
via
some
subject.
Identifier,
in
this
case
it's
an
issuer,
slash,
subject,
identifier
and
it's
just
a
way
of
expressing
subject
in
terms
of
the
issuer
and
subject
claim
pair
that
you
would
normally
see
in
a
job
okay.
E
E
Also
from
as
I
talked
about
this
last
I
80
F,
based
on
the
feedback
I
made
the
change
to
where,
instead
of
having
this
ID
token
claims,
subject
type
as
a
way
to
try
and
handle
multiple
types
of
multiple
identifiers
for
the
same
subject.
We
replace
that
with
a
more
generic
aliases
concept.
So,
in
the
event
where
you
have
a
number
of
identifiers
for
a
subject-
and
you
don't
know
which
one
your
recipient
is
actually
using,
you
can
put
all
of
those
together
into
this
meta.
E
E
And
then
I
think
the
last
thing
here
is
this
note
on
semantics.
This
was
discussed
somewhat.
Last
IETF
is
kind
of
another
iteration
on
trying
to
clarify
the
meanings
of
what
exactly
these
subject.
Types
are
supposed
to
refer
to,
based
on
feedback
from
last
IETF
updated
these
to
use
this
identified
with
language
on
so
I
think
that
that
makes
it
a
little
clearer.
We
can
happy
to
have
more
feedback
on
that
as
well.
I.
E
Think
the
the
one
open
item
we
have
is
this
question
of
a
defining
a
jot
claim
for
subject
identifiers.
This
is
something
that
I
think
Brian
suggested.
I,
don't
see
him
here
to
talk
about
it,
unfortunately,
but
the
the
suggestion
is
basically
that
we
define
a
claim
in
the
claim
space
to
generically
represent
a
jot
subject
the
subject
of
the
the
job
as
a
subject
identifier.
E
E
F
John
Bradley
yubico
this
actually
came
up
at
the
security
workshop
last
week.
Vittorio
has
an
almost
identical
use
case
for
John
access.
Tokens,
probably
not
surprising,
so
I
suggested
that
he
also
have
a
look
at
this,
so
it
has
the
need
for
such
a
thing
has
come
up
in
other
contexts.
Besides
just
set.
F
G
I've
been
connect,
I
guess
one
thing
that
we
would
probably
have
to
keep
in
mind.
If
we
did,
you
know
specify
such
a
standard
claim.
Is
you
know
how
is
it
gonna
interact
with
so
like
if
they're
both
present?
Does
this
one
take
precedence?
What
happens
if
you
send
such
a
thing,
yeah
we're
both
so
and
the
new
thing
or
present
to
somebody
who
only
understands
sub.
You
know,
there's
just
some
education
is
to
make
sure
that
we
think
about
and
write
down
right.
D
D
They
might
send
different
things
just
in
case
and
regarding
this,
this
one
I
really
don't
like
the
fact
that
we
define
it
by
syntax
versus
semantics.
I,
don't
have
any
problem
with
the
job
being
the
subject,
but
I
think
we
need
to
define
the
semantics
and
probably
at
least
some
of
the
contents
of
this
job.
I.
Think.
E
D
F
This
is
kind
of
an
alias
I,
don't
see
it
as
being
mutually
exclusive
to
sub.
So
in
the
example
of
an
access
token,
that
Vittorio
had
was
that
you're
using
Google
to
authenticate
the
person
to
an
a
s.
The
a
s
may
have
a
subject
in
its
scope
that
it
knows
the
user
by,
but
it
may
be
useful
to
the
RS
to
also
know
that
you
were
foo
at
gmail.com.
F
E
Think
it's
would
be
safe
to
say
that,
in
the
event
that
a
jot
contains
both
sub
and
whatever
claim,
this
is
that
they
must
both
identify
the
same
principle
as
long
as
that's
the
case.
Then
there
shouldn't
be
too
much
in
the
way
of
confusion.
As
far
as
how
do
you
process
that
and
which
one
do
you
prioritize.
G
E
If
memory
serves
they're
still
in
the
the
specs,
some
language
around
that
around
privacy
considerations,
that
a
transmitter
should
not
be
should
should
take
care
when
transmitting
subject
identifiers
to
make
sure
they
are
not
revealing
information
that
that's
a
shouldn't
necessarily
be
communicated
or
that
shouldn't
be
shared
with
the
recipient.
I
think
there's
a
section
in
there
that
specifically
mentions
that
in
some
cases,
even
the
subject,
identifier
itself
can
be
perceived
as
sensitive
information.
So
I
think
we
have
guidance
for
that
in
the
in
the
current
draft
and.
D
H
So
what
is
this?
This
defines
a
way
to
Paul
for
events,
which
is
something
you
might
use
if
you're
in
a
context
that
you're
not
able
to
push
them,
maybe
because
of
connectivity
or
firewall
relationships.
This
complements
the
push
delivery
draft
you
could
do
one
or
the
other
or
both
depending
upon
your
use
cases.
Next,
so
what's
happened
since
we
last
met
our
heroes.
I
did
a
major
editorial
pass,
mostly
continuing
to
simplify
the
exposition.
The
precursor
drafts
that
we
started
with
was
pretty
wordy,
and
it's
not
wordy
anymore.
H
H
Finally,
I
did
something
which
I'd
also
suggested
for
the
push
draft,
which
is
that
used
to
say
that
TLS
is
required
and
that
language
has
been
softened
to
say
that
if
there's
PII
you
have
to
encrypt
it,
you
could
do
it
with
jwe.
You
could
do
it
with
TLS.
You
could
even
do
it
with
both
but
tried
to
get
it.
What
are
we
trying
to
achieve
rather
than
saying
this
is
the
mechanism
you
must
use
to
achieve
it
next.
H
So
this
is
now
a
chair
conversation,
but
I
don't
see
anything
left
to
do
on
this
other
than
working
group
last
call,
and
as
long
as
I
have
the
microphone
before
I
sit
down,
I'll
say
two
things
about
push.
One
is
I
believe
that
Adobe
also
has
an
implementation
in
deployment
as
they're
receiving
events
from
Google.
So
that's
another
implementation
in
the
wild
and
I
was
one
of
the
recalcitrant
ones
that
didn't
produce
a
working
group
last
call's
feedback
on
time.
H
I
did
eventually
pop
it
to
the
top
of
the
stack
and
produce
a
detailed
review
which
Annabel
acted
upon
and
I
think
there's
others
that
we
could
kajal
in
to
do
a
review
of
some
kind
to
move
this
forward,
but
now
I'm
being
an
individual
and
editorializing.
So
that's
the
end
of
my
presentation.
Are
there
any
questions
about
the
poll
draft
or
its
status
or
next
steps.
I
D
D
E
D
G
Responsible
ad,
you
know
just
to
clarify
you,
it's
completely
up
to
the
chairs
how
you
want
to
determine
that
there
is
or
is
not
consensus.
You
only
carry
out
there.
Is
that
if
you
do
something
really
crazy,
you're,
probably
gonna
get
a
feel,
but
you
know
we
are
definitely
open
to
hearing
suggestions
for
things.
The
working
group
can
do
to
give
you
more
confidence
that
we
do
have
consensus.
H
One
thing
that
other
working
groups
is
often
done
is
used
the
opportunity
of
such
face-to-face
time
to
try
to
elicit
or
draft
volunteers
to
do
additional
reviews.
So
I
don't
know
if
there's
those
in
the
room
that
would
be
willing
to
sign
up
on
the
spot
to
at
least
do
a
skim
review
and
make
sure
that
things
are
saying
from
their
perspective.
E
F
H
H
F
D
G
A
pancake
another
thing
we
can
do
is
if
we
have
people
that
we
know
if
you've
amended
this,
we
could
just
arm
a
little
bit
and
say
you
know,
can
you
look
this
over
is?
Does
this
match
up
what
you've
implemented
because,
yes,
people
are,
are
using
it,
that's
sort
of
an
indication
that
they
think
it's
it's
worth
publishing.
D
H
H
A
D
D
F
D
F
D
D
I
E
D
So
I
don't
know
if
it's
and
as
an
individual
or
working
group,
sure
I
think
we
should
actually
wait
with
this
until
we
have
closure
on
push,
because
there
are
more
constituents
for
the
push
protocol
as
well
as
push
protocol
is
anyway,
a
dependency
of
the
poll
protocol.
So
I'd
rather
wait
for
these
few
weeks,
get
more
people
to
express
their
opinion
on
the
post
protocol
and
then
move
forward
to
a
working
group.
Last
call.
H
H
D
In
fact,
since
we,
since
we
have
this
dependency,
people
who
review
push
should
know
that
also
contributing
to
pull
Plus,
there's
nothing
stopping
them
from
reviewing
Paul
and
given
the
procedural
changes
that
we're
making.
These
reviews
will
actually
count
when
we
get
to
the
more
formal
they're
working
to
a
breast
call.
I.