►
From YouTube: IETF105-SECEVENT-20190723-1330
Description
SECEVENT meeting session at IETF105
2019/07/23 1330
https://datatracker.ietf.org/meeting/105/proceedings/
B
B
A
C
Yes,
it
is
on
now:
okay,
Wow,
okay.
My
name
is
n
Belle,
Becker
and
I'm
here
to
talk
about.
Subject:
identifiers
for
security
event
tokens
shockingly
exactly
what
is
on
the
slide?
D
C
And
I
I'm,
just
gonna,
have
have
our
wonderful
chair
here,
scroll
for
me,
okay,
subject,
identifier
z'
we've
been
through
this
before,
but
for
anybody
who's
unfamiliar
with
this
work,
the
goal
is
to
define
lightweight
schemas
for
the
various
ways
that
we
might
identify
a
subject,
be
it
by
email
or
phone
number
or
issue,
or
in
subject
pair
or
any
number
of
other
things.
So
the
the
spec
defines
the
format
for
defining
these
schemas
and
then
defines
a
few
of
them
in
the
the
spec
itself
and
defines
Ayana
registry
for
that
work.
C
Next,
just
to
give
it
add
some
clarity.
Here's
an
example
of
one
of
these
things
in
action
in
a
risk.
Subject,
event:
excuse
me
security
event,
token.
You
see
it
in
this
particular
example.
We
have
a
subject,
identifier
of
the
issuer.
Subject
type
it
has
a
subject
type
field
saying
what
type
it
is
and
then
it
has
a
couple
of
claims,
the
meaning
of
which
are
defined
in
the
the
spec.
C
C
A
couple
of
two
small
updates
and
one
more
significant
update
here.
There
was
some
concern
over
identify
our
correlation,
and
should
we
have
some
text
in
this
document
about
that?
So
we
added
that
to
privacy
considerations
I'm
not
going
to
go
into
the
specifics
of
that.
You
can
look
at
the
draft
and
read
the
paragraph.
D
B
C
Good
next,
the
next
notable
change
is
that
we
added
language
to
prohibit
nesting
aliases.
What
that
means
to
we
added
this
type
subject:
identifier
type
called
aliases.
The
purpose
of
this
is
to
allow
you
to
include
multiple
identifiers
for
the
same
subject.
So
this
is
particularly
useful
in
cases
where
it's
unclear
how
the
intended
audience
of
say
set
is
identifying
the
subject
or
knows
how
to
identify
the
subject,
and
so
you
want
to
send
a
couple
of
identifiers
x'.
C
Ideally,
the
client
is
using
issuer
and
subject
to
identify
the
subject
and
they're
storing
that
in
their
database,
but
they
don't
always
do
that.
Sometimes
they
just
map
based
on
email
address.
We
don't
want
them
to
do
that,
but
that's
what
people
do
in
practice.
So
this
gives
a
way
for
the
issue
or,
if
they're,
sending
a
set
to
include
multiple
identifiers.
C
So
that
the
recipient
is
gonna,
be
able
to
figure
out
who
they're
talking
about
even
if
they
didn't
do
the
right
thing,
that's
what
aliases
is
for
this
update
just
makes
it
so
you're
not
going
to
have
aliases
nested
and
aliases
nested
and
aliases.
Have
this
like
nested
list
structure
that
doesn't
make
any
sense
and
doesn't
have
any
meaning
so
we're
just
gonna,
say:
let's
not
do
that
next.
C
E
C
F
C
C
So
what
we
did
in
this
draft
is
we
added
this
sub
underscore
ID?
This
definition
for
this
sub
underscore
ID
jot
claim
the
language
I
have
there
is
copied
from
the
text.
It's
a
subject,
identifier
that
identifies
the
principal
that
is
the
subject
of
the
jaw
and
that
underscore,
or
that
underlined
portion
there
is
copied
from
the
definition
of
the
sub
claim
in
jaw
itself.
So
the
intention
here
is
that
both
of
these
claims,
sub
and
sub
ID
are
going
to
point
to
the
same
subject
the
same
principle.
C
You
can't
have
one
pointing
to
one
thing
in
one
pointing
to
another
that
would
be
against.
That
would
be
a
violation
of
the
spec
and
there's
language
in
the
spec
to
that
effect.
So
at
the
bottom
here
we
have
an
example.
Kind
of
the
simple
case
of
I
just
have
a
sub
ID
on
the
next
couple.
Slides
I've
got
some
other
examples
of
how
sub
and
sub
ID
interact
with
one
another.
C
So
the
jaw
can
have
sub
it
cannot
have
saw
that
kind
of
sub
idea
cannot
have
sub
ID.
Both
of
these
can
exist.
At
the
same
time,
you
can
have
a
job
with
neither
of
them
if
they
both
exist.
As
I
said
earlier,
if
they're
both
present
in
the
same
job,
they
have
to
point
to
the
same
principle.
If
you
put
sub
and
sub
ID
in
the
same
job,
you
are
making
a
statement
that
the
these
identifiers
point
to
the
same
principle.
C
B
C
E
Benedick
just
for
myself,
so
freezing
mist
like
you
know,
the
issuer
is
making
an
assertion
that
the
principal
of
the
subject
or
the
principal
identified
by
the
subject,
the
principal
identified
when
the
subject
ID
are
the
same
principal.
That's
sort
of
gives
me
a
little
bit
of
pause
because
now,
when
I
receive
that
assertion
am
I
allowed
to
use
that
assertion
and
to
use
that
information
only
in
the
context
of
processing
this
jot
or
this
yeah
this
job
or
am
I
allowed
to
use
that
in
arbitrary
contexts.
New
York
completely
unrelated.
C
Any
other
questions
on
on
that
before
we
move
on
I.
Think
I've
got
another
couple
slides
on
on
this
particular
piece.
Do
you
want
to
maybe
elaborate
why
it's
important
sure?
So
the
question
was:
if
a
transmitter
is
by
including
sub
and
sub
ID
in
a
job,
if
that's
making
an
assertion
that
those
to
identify
as
point
to
the
same
principle,
then
the
recipient
of
that
job,
then
can
you
can
correlate
those
two
identifiers
basically
say:
okay,
I
I
have
records
for
the
sub.
C
C
That's
why
the
the
ID
token
example
that
I
gave
earlier
is
a
good
one,
because
they're
the
issuer
knows
that
they've
previously
sent
these
identifiers
to
the
recipient.
So
they
know
if
the
recipient
can
already
correlate
those
so
sending
them
together
in
another
context,
doesn't
give
the
recipient
more
information.
C
C
These
values
may
or
may
not
be
the
same.
It
is
possible
for
a
job
to
be
issued
by
entity
a
but
use
and
a
subject,
identifier
where
the
issuer
is
entity
B
and
a
good
example
of
this
is
shown
here
where
in
this
case,
we
have
a
John
being
issued
by
a
client
and
they're
using
the
issuer
subject.
Subject:
identifier
type
to
indicate
that
the
subject
is
based
off
is
defined
relative
to
the
issuer.
C
So
you
we
can
imagine
this
happening
in
an
open,
ID,
Connect
relationship
where
a
the
issuer
has
provided
some
subject
identifiers
via
an
ID
token,
the
client
wants
to
communicate
some
information
back
up
to
the
issuer
via
a
jot.
The
only
shared
identifier
they
have
is
the
one
that
the
the
issuer
communicated
in
in
the
ID
token.
C
It
would
be
incorrect
to
just
take
that
subject
from
that
ID
token
and
put
it
in
the
jot
the
client
is
sending
because
then
it
would
say
issuer
his
client
and
subject.
Is
this
identifier,
that's
defined
relative
to
the
issuer,
which
would
be
incorrect,
so
this
gives
us
a
way
around.
That
problem
gives
us
a
way
to
clearly
specify
that
we
have
one
entity.
That's
make
it
that's
issuing
this
John,
but
we're
identifying
it
using
an
identifier
issued
from
in
this
case,
actually
the
recipient.
C
So
this
point
I
think
we
only
won
one
concern
raised
about
phone
number,
but
other
than
that.
We're
looking
for
feedback
on
subject,
ID
and
if
there's
a
anything
else,
people
think
are
is
missing
from
the
spec.
At
this
point
you
can
don't
have
any
other
open
items
right
now,
so
open
to
feedback.
There.
G
A
G
Only
one
question
I
did
have
is
and
I
don't
know
that
it's
germane
here,
but
I
think
that
the
risk
working
group
uses
subject
spelled
out
throughout,
like
all
their
messages
and
I'm.
I
honestly,
don't
know
if
that's
a
if
they're,
using
it
as
a
top-level
claim
or
like
more
nested
stuff
and
if,
if
there's
any
potential
issue
between
a
mismatch,
then
right.
C
So
the
risk
working
group
defines
a
subject
claim
within
the
event
payload.
So
it's
not
at
the
job
level.
So
we
you
that
could
arguably
be
replaced
by
sub
ID
and
and
shift
that
up
to
to
the
Javal
that
yeah.
That's
something
that
the
working
group
hasn't
really
looked
at,
hasn't
really
considered,
but.
C
C
No
right,
I
believe
the
risk
spec
already
says
that
the
subject
of
the
event
and/or
our
set
might
say
that
actually,
that
the
subject
of
the
event
and
the
subject
of
the
of
the
set
are
the
same,
so
there
shouldn't
be
any
conflict
there.
It
would
just
be
another
case
of
the
subject
specified
and
the
event
payload
points
to
the
same.
If
there
is
a
sub
I,
it
points
to
the
same
principle
as
that
I
think
one
of
the
strategies
that
was
discussed
or
patterns
that
was
discussed
with
inset
was
that
specs
that
are
profiling.
B
B
B
B
H
F
F
F
So
what's
happened
since
we
last
met
our
heroes
in
Prague,
we
published
a
new
revision
where
I
did
what
I
said,
but
I
would
do
which
was
go
through
the
push
Draft
find
text
that
appeared
to
be
applicable
to
the
pawl
draft
and
either
incorporated
directly
if
it
was
descriptive
or
if
it
was
normative,
I
changed
to
reference
it
rather
than
duplicate
it.
So
we
finished
aligning
the
descriptive
text.
There
were
no
normative
changes
next,
so
this
is
how
I
intend
to
use
the
rest
of
the
time.
This
is
my
last
slide.
F
B
F
B
B
B
E
Yeah,
it
seems
like
we're
in
pretty
good
shape.
I
know
that
the
the
push
Draft
has
been
with
me
for
longer
than
it
should
have
a
couple
months,
but
I
had
a
pretty
busy
personal
life,
so
all
of
my
IETF
time
was
like
working
on
the
telly
chap
prep
and
so
I
haven't
gotten
much
in
the
publication
requested
documents
from
the
organ
groups,
but
I'm
back
and
I'm
catching
up
on
that.
So
I
think
I
will
get
to
the
push
in
probably
another
few
weeks
and
start
getting
things
moving
again.
So,
okay.