►
From YouTube: IETF101-SECEVENT-20180323-0930
Description
SECEVENT meeting session at IETF101
2018/03/23 0930
https://datatracker.ietf.org/meeting/101/proceedings/
A
A
A
B
Do
have
one
remote
participant,
Annabel,
Backman
Amazon
there's
been
some
discussion
on
the
list
just
in
the
past
couple
days
about
the
exp
claim
in
set
and
whether
that
should
be
not
recommended
or
recommended.
Do
we
want
to
make
five
or
ten
minutes
for
that.
A
So
I
was
planning
to
do
that.
Assuming
we
have
someone
who
can
I
represent
Mario's
concerns
on
that,
so
that
would
be
you
I
think
I
can
make
a
stab
at
it
all
right
and
then
I
feel
asked
for
a
slot
a
again
if
we
have
some
time
remaining
to
say
a
few
words
about
SSDP
the
new
proposal
that
is
submitted
just
tonight
so
again,
if
we
have
some
time
remaining
after
we
speak
after
we
finish
talking
about
the
main
meat
of
the
meeting.
C
C
This
is
just
recap
of
status.
We
have
published
four
drafts
since
we
last
met
our
heroes
in
Singapore.
There's
been
a
lot
of
productive
working
group
discussion
that
included
some
consensus,
calls
that
didn't
result
in
actual
ITF
style
consensus
and
then
some
follow-up
discussions
both
in
person
and
on
the
list
that
eventually
did
so
I'm
happy
with
that
outcome.
I
think
we
have
a
better
result
than
we
would
have
had.
We
just
proceeded
in
December,
so
thank
you,
you're
on.
C
C
It
is
scheduled
to
be
evaluated
by
the
IES
G
on
the
May
10
tell
a
chat,
so
those
of
you
who
may
not
have
been
around
this
process
as
much
before
expect
to
see
a
number
of
reviews
from
special
groups
in
the
ITF,
such
as
the
security
Directorate.
The
Operations
Director
at
the
applications
group
will
send
us
reviews
that
are
sort
of
ITF
wide
that
often
contain
a
lot
of
really
useful
content,
as
well
as
the
number
of
the
area
directors
will
submit.
C
B
B
We
have
two
mechanisms
for
this:
one
that
focuses
on
we're,
calling
it
HTTP
push
the
transmitter
is
making
a
request
to
the
receiver
to
send
the
set
to
them.
The
other
is
HTTP
pole
where
the
receiver
is
making
requests
to
the
transmitter
to
retrieve
the
sets
from
the
transmitter.
The
next.
It's
gonna
walk
through
these
real
quick,
as
I
said,
with
HTTP
push
it's
a
transmitter
sending
the
set
to
the
receiver.
They
make
a
post.
The
receiver
replies
with
a
202
if
they
accept
it
or
400.
B
Yeah,
it's
nothing
too
surprising,
the
400
and
400.
We
have
an
error
body
with
an
error
code
and
a
description
for
the
for
the
transmitter
to
consume
next.
The
other
side
is
HTTP.
Pol
receiver
is
making
posts
to
the
transmitter
and
retrieving
zero
or
more
sets
depending
on.
If
there
are
any
sets
available
for
them.
B
In
the
initial
request,
they're
going
to
make
a
post
they're
going
to,
they
can
optionally
specify
a
number
of
sets.
They
want
back
a
maximum
number.
They
can
also
specify
whether
or
not
they
want
to
do
long
polling
via
the
return
immediately
parameter
there
mm-hmm
the
transmitter
replies
with
a
200
that
may
contain
some
number
of
sets.
It
may
not
on
subsequent
calls
the
receiver
in
addition
to
requesting
sets.
They
can
also
acknowledge
receipt
of
sets.
B
They
got
in
the
previous
request,
so
they
can
send
this
ACK
parameter
that
contains
a
list
of
jdi's
from
sets
that
they
accepted
next.
They
can
also
send
this
set
error
parameter,
which
is
a
map
of
jdi's,
to
error
responses
for
those
for
those
sets.
So
you
put
that
all
together.
This
is
what
a
request
from
the
receiver
might
look
like.
They
can
specify
max
of
n,
so
you
can
say
if
they
want
long
polling,
they're,
acknowledging
they're
specifying
errors,
and
hopefully
they
get
back
some
sets
from
the
from
the
transmitter.
B
So
where
are
we
at
with
this?
We
had
a
new
draft
published
just
a
few
weeks
ago,
two
big
one
minor
open
issue,
one
major
of
an
issue,
the
the
minor
open
issues.
There
is
a
recent
question
around.
How
do
we
want
to
handle
status?
Error
codes
for
the
in
the
the
push
scenario?
Currently,
the
spec
says
we're
just
going
to
return
404
everything.
Do
we
want
to
do
something
different?
The
other
open
issue
is
we
have
two
protocols
in
one
spec
which
one's
nti?
What
are
we
doing
there?
Well
we'll
get
into
that.
B
C
B
Ok,
so
let's
talk
through
the
error,
open
issue,
real
quick.
We
saw
this
briefly
in
the
are
the
protocol
examples,
but
for
both
push
and
pull
we
have.
This
error
object,
has
an
error
code
and
a
description
you're
next,
in
the
push
use
case,
requests
by
the
transmitter
are
gonna,
be
responded
to
by
the
receiver,
with
either
a
200
or
a
status
code
400.
Regardless
of
what
the
actual
error
message
is.
I
was
raised
on
the
list
that
maybe
we
could
be
more
specific
with
our
status
codes
here.
B
A
couple
of
things
came
out
of
that
discussion
so
far,
namely
that
for
two
of
these
we
could
actually
specify
a
403.
This
error
is
probably
actually
not
needed
and
we
can
get
rid
of
it,
but
that
still
leaves
everything
else
is
a
400,
so
there's
kind
of
still
an
open
question.
Is
it
worth
doing
any
of
this?
Do
we
just
want
to
stick
with
400
for
everything
and
be
consistent
or
they're,
actually
other
status
codes
that
we're
not
thinking
about
that
we
could
use
for
some
of
these
use
cases.
D
Phil
hunt
document
editor
and
from
Oracle
raise
a
caution
here
that
this
is
similar
to
issues
we've
had
with
redefining
jot
attributes
for
a
different
purpose.
What
happens
in
403
is
you're
redefining
something
that
HTTP
is
defined.
It
also
causes
a
problem
that
you
can't
tell
the
difference
between
an
authorization
error
and
a
JWT
error,
so
I'd
advise
against
redefining
403
in
this
way,
Thanks.
E
E
So
it's
kind
of
like
it's
it's
machine,
readable,
so
I
think
the
thing
about
status
codes
in
HTTP
is
that
if
it's,
if
it's
an
HTML
response,
it's
really
the
status
code,
that's
kind
of
telling
the
browser
like
what
actually
happened.
So
the
browser
can
display
perhaps
a
meaningful
message,
because
the
HTML,
while
kind
of
machine
readable,
is
not
really
machine.
Processable
in
this,
we
don't
have
this
problem
here.
So
I
think
each
of
these
error
messages
are
very
explicit
anyway.
E
B
B
D
Was
because
when
we
talked
about
possibilities
for
a
failed
delivery,
the
transmitter
needs
to
have
the
ability
if
it
thinks
that
the
receiver
may
not
have
received
it,
to
send
it
again,
and
it
will
keep
within
some
reasonable
period
that
it's
able
to
to
do
that
until
it
gets
an
acknowledgement
back.
So
a
duplicate
is
now
a
normal
condition,
as
was
the
issue
so.
D
B
Other
question
push
versus
poll:
should
one
of
these
VMT
I
should
the
other
BMT
I?
Should
they
both
be
empty
I
should
neither
of
them
be
MTI.
This
is
the
big
question
of
the
day.
We've
gone
back
and
forth
over
this
issue
in
several
meetings
and
I.
Don't
think
we've
really
made
a
lot
of
progress
on
it.
There
are
arguments
for
both
protocols,
there's
legitimate
technical
reasons.
People
have
given,
for
preferring
one
versus
the
other
I
think
the
biggest
concern
that's
been
raised
for
polling.
B
Why
people
would
not
necessarily
want
to
use
polling
is
there
are
skilling
concerns
there,
on
the
other
hand,
for
push
the
enterprise
space
has
scenarios
where
they
maybe
don't
want
to
open
holes
and
firewalls,
so
opening
up
an
endpoint
that
transmitters
would
push
sets
to
doesn't
necessarily
work
for
them.
It's
a
big
technical
reason.
D
Hole
there's
no
mandatory
requirement
to
persist
sets.
It
is
obviously
slower
if
you're
polling
cycles
are
long,
whereas
in
push
you
can
get
rid
of
it
relatively
immediately,
so
you
might
be
talking
about
retaining
the
set,
not
persisting
it
for
a
period
of
minutes
rather
than
then
milliseconds.
So
that's
that
is
the
trade-off,
so
there
is,
but
it's
not
a
permanent
requirement.
That's
what
I
want
verify.
Yes,.
B
It's
not
yeah,
as
persist.
That's
not
meant
to
imply
permanence
of
that,
but
it
does
mean
that
the
the
transmitter
has
to
hold
on
to
the
set
all
of
their
sets
for
potentially
a
longer
period
of
time,
whereas
with
push
they
generate
it.
Potentially
they
push
it
immediately.
They
got
a
202
back
or
back
and
they're
done
with
that.
F
I'm
wondering
if
you
want
on
I'm
wondering
whether
there
is
you
have
to
think
about
a
little
bit,
the
MT
I
for
the
client
and
the
server
here
or
the
sitrep
sender
and
the
receiver,
and
it
might
be
asymmetric.
So
you
might
sort
of
try
push
and
have
a
have
text
in
the
specification
that
says
how
you
fall
back
to
pool
if
that
fails
right
or
what
the
expectation
is
on
the
sender
and
receiver
to
make
it
so
to
maximize
your
chances
on
interoperability.
E
William
Dennis
Google
and
I
apologize
for
the
OLAP
analogies
again,
but
well,
there's
kind
of
my
background
when
I'm,
when
I
analyzed
the
MT
and
I
sent
a
couple
of
emails
yesterday
on
this
topic,
the
two
good
examples
I
found
from
all
three
having
Intel
really
helped
was
when
it
was
kind
of
like
a
recommended
way
to
do
something
and
then
like
an
inferior
way
for
like
some
subset
of
kind
of
constrained
clients.
So
in
a
number
of
places
we
mandated
the
superior
way
and
then
we
made
the
inferior
way
kind
of
optional.
E
That
has
been
extremely
useful
for
clients,
because
if
the
client
is
capable
of
the
superior
way
they
can
just
implement,
they'd
have
to
worry
about.
You
know
working
out
what
they
need
to
do.
It
was
Eastern
the
available
in
this
case,
I
feel
like
these
two
things,
they're
just
completely
diametrically
different.
So
to
me
these.
This
is
just
kind
of
two
aspects
of
something
it's
kind
of
like
again
the
Olaf
analogy.
You
know
we
have
the
code
flow.
We
have
the
implicit
flow
and
I,
don't
actually
think
either
alike.
E
Mti,
there's
also
like
client
credentials
and
various
other
kind
of
all.
These
optionality
in
the
spec
and
people
can't
have
to
you
know
each
had
its
own
use
case
and
what
I'm
sort
of
seeing
here
is
that
there
is
very
explicit
use
cases
for
each
I,
don't
see
how
empty
I
actually
would
aid
the
development
of
clients-
and
you
know
there
was
the
option
of
like
splitting
the
spec.
E
Maybe
don't
need
you
that
maybe
it's
just
like,
like
other
specs,
that
we
have
just
document
two
options
and
there's
discovery
or
something
that
people
use
to
work
out
which
one
of
these
it
seems
like
this
is
a
really
kind
of
big
topic
that
people
will
choose
and
not
so
trivial
like
are
using
Shire
or
using
like
something
else
where
it
makes
sense.
That's
just
that's
my
opinion.
I
think
I.
Think
I'm
speaking
for
the
team
there
on
that
I'd.
A
A
B
The
flip
side
to
that
is
a
few
years
down
the
line
we'll
have
a
few
years
of
implementation,
experience
and
I
think
a
much
better
idea
at
that
point
of
which
of
these
protocols
make
sense
in
what
circumstances.
Ultimately,
the
the
answer
for
the
little
guy
who
wants
to
work
with
the
big
guy
is
they're
gonna,
implement
whatever
the
big
guy
implemented
nine
times
out
of
ten.
B
D
Another
category
is
that
many
people
are
classic
business
customers
who
are
on
a
trend
to
close
firewalls
further,
not
open
them
there.
Their
argument
is,
if
we're
moving
services
to
the
cloud
what's
left
inside
our
castles,
even
more
important
and
they're
reticent
to
open
it.
So
regardless
I
see
Network
challenges
on
that.
D
B
All
sounds
to
me
like
a
really
good
argument
for
not
trying
to
institute
a
single
MTI
set
delivery
spec
as,
as
you
noted
there
I
think,
there's
not
going
to
be
use
cases
for
a
set
that
for
which
neither
of
these
make
sense
and
and
and
for
which
they
may
not
be
using
any
delivery
method
at
all.
You
mentioned
IOT
I
think
that's
a
great
example
of
where
push
and
pull
both
are
probably
not
going
to
work
in
their
current
design.
Correct,
Phil,.
D
Again,
I
think
my
hesitation
is
not
based
on
like
I
agree
with
you.
My
imitation
is:
what
will
the
broader
IETF
community
accept
and
based
on
what
Williams
told,
and
in
my
personal
experience
over
the
10
years
we
can
say
we
want
something
all
we
want,
but
my
concern
is
people
want
to
get
it
done,
taking
a
chance
by
having
two
optional
things
and
having
it
thrown
back
delays
of
significantly
and
if,
if
we
can
come
to
a
single
method,
that
would
be
the
ideal
case.
D
It's
just
my
feeling,
based
on
experiences
that
that
people
want
libraries
to
be
developed
and
the
libraries
would
generally
work
with
each
other
when
people
try
to
use
it.
I
think
leaves.
Comments
are
important
about
client
option
versus
server
options.
You
have
to
kind
of
all.
We
have
to
get
that
clearly,
meshed
together
thanks.
My.
E
I
definitely
agree
with
that
comment.
I
think
I
think
it's
our
job
to
put
forward
the
best
document.
We
can
kind
of
a
point
of
order.
I'd
like
to
ask
the
chair,
like
I,
don't
quite
understand
how
you
can
sort
of
say
it's
like
there
should
be
MTR
with
your
chair
hat
on
to
me.
That's
more
of
an
individual
comment:
I've
not
heard
of
a
chair
kind
of
requiring
an
MPI
in
aspect.
F
So
I
actually
think
that
that's
it,
you
know
it's
just
experience
right.
Isd
will
bring
this
up
right.
It's,
but
but
it's
also
Annabelle
is
absolutely
Tori.
I
mean
you,
we
don't
you
know
it
doesn't
mean
you
actually
have
to
use
by
that
right.
So
you
can
use
you
can
if
they're
working
past
consensus,
they're
working
past
consensus
right,
a
well-documented
concerns
was
saying
there.
There's
there's
like
good
reason
to
have
to
write.
E
E
What
my
observation
here
is
that,
when
I
sort
of
saw
that
argument
between
the
two
groups
like
we
won't
pull
me
or
push
it
just
seemed
like
they
were
just
completely
separate
ecosystems
as
well
sort
of
you
know
a
bunch
of
people
doing
something
say
with
risk
implication:
they're
a
bunch
of
people,
maybe
do
some
B's,
skim
and
I.
Think
if
you
go
back
to
like,
why
do
we
want
empty
I-it's
country,
improve
interoperability
and
simplify
things,
but
it
seems
like
there's
no
interoperability
issue
there.
E
So
I,
don't
I,
don't
sort
of
see
how
like
or
seen
one
method
on
a
group
of
people
that
don't
want
to
do
it.
That
it'll
kind
of
happy
with
your
Interop,
helps
and
and
yeah
I
do
think.
There
is
precedent
for
documenting
two
equally
viable
methods,
so
if
I
suggest
will
be,
let's
take
that
forward
and
and
if
there's
significant
pushback
can
address
it,
then
and
I.
B
Think
there
was
probably
an
action
item
there
for
for
those
of
us
who
of
the
draft
to
add
more
context
around
what
are
the
use
cases
here?
What's
what's
motivating
you
push?
What's
motivating
poll
I
think
that's
something
that
you
do
see
in
67
49
that
isn't
really
present
in
this
draft
and
that
might
help
clarify
and
give
that
context
for
why
we,
both
of
these
methods,
make
sense.
C
That
being
the
case,
I
think
we
are
procedurally
better
off
to
keep
them
in
one
draft,
and
you
know,
have
discussions
about
whether
one
is
MTI
separately
than
that,
but
if
I
were
trying
to
take
two
drafts
to
the
isg
and
I
would
then
expect
comments
like
pick
choose
one
or
the
other,
whereas
if
we
have
one
draft
that
clearly
lays
out
for
these
kinds
of
use
cases,
this
method
works
for
these
kinds
of
use
cases.
This
other
method
works
and
for
this
other
set
of
use
cases
either
could
work.
A
Just
one
more
thing,
so,
first
of
all,
I'd
like
to
to
echo
what
left
said
said
about
my
my
previous
comment
coming
from
experience
and
about
the
working
group
ultimate
decision
on
whether
we
want
to
go
with
a
single
MTI
or
not
it's
it's
my
advice
to
have
a
single,
empty
I
and
the
working
group
can
decide.
Otherwise
if
it
wants
to
and
then
back
to
the
discussion
on
on
which
weather
in
which
so
I'm
I'm
a
bit
worried
about
when
I
hear
that
they're
going
to
be
additional
methods
proposed
for
various
use
cases.
A
So
are
we
so
if
we
start
with
having
two
methods
that
are
both
sort
of
optional
sort
of
were
describing,
which
use
case
for
which?
What
do
we
do
and
when
the
third
and
fourth
ones
come
along
and
then,
when
I
hear
that
that
we
have
clearly
defined
use
cases
or
well
that
kind
of
conflicts
with
with
the
whole
firewall
whole
notion.
So
if
I
have
a
firewall
whole,
that's
a
clear
use
case.
B
So
let
look
at
a
bunch
of
slides
about
what
we
just
talked
about
so
briefly
before
we
get
to
the
ones
we
actually
just
talked
about.
One
additional
option
that's
been
brought
up,
particularly
for
the
kind
of
the
firewall
use
case,
is
the
idea
that
a
lot
of
those
those
clients
may
actually
be
operating
through
sort
of
a
service
provider
acting
as
a
proxy
between
their
systems
and
the
event
transmitters
that
they
actually
want
to
get
a
signal
from.
So,
as
you
can
see.
B
B
So
in
this
scenario,
you're
still
doing
push
and
you're
doing
poll,
but
it's
a
question
of
who's
implementing
what
the
cert
the
transmitter
is
only
implementing
one
of
these
protocols,
the
service
providers
implementing
both
but
they're,
implementing
them
in
different
directions,
and
the
receiver
is
also
only
implementing
one
of
these
protocols,
so
you
eat
even
with
two
protocols
and
people
wanting
to
implement
different
ones.
You
still
got
ways
to
bridge
between
them
that
you
know.
If
the
use
case
is
there,
the
industry
can
provide.
D
I
saw
this
posted
on
the
list
and
my
reaction,
it's
fill,
hunt
by
the
way
again
was
it
doesn't
address
the
interoperability
issue,
because
you
still
have
interoperability
for
the
receiver.
It
has
to
be
standardized.
It
does
I
think
it's
a
natural
consequence,
though,
as
a
negative
of
having
two
methods
that
then
we
can
expect
complication
and
network
architectures
of
needing
mediators
between
the
methods.
B
Thank
you,
I
think.
If
I
remember
correctly,
I
think
Adam
Dawes
was
probably
the
first
person
to
bring
up
this
this
approach
and
if
I
understand
it
correctly,
he's
putting
it
forward
not
as
a
replacement
or
a
reason
why
we
don't
need
to
standardize
poll.
We
would
want
to
standardize
both
push
and
pull.
So
you
have
standardization
on
both
of
these
links,
but
the
proxy
service
provider
acts
as
a
bridge
between
the
two.
So
you
know
people
have
made
claims
that
well,
everyone's
gonna
have
to
implement
poll
anyway.
B
You
know,
with
with
the
intermediary
service
provider,
solution
that
that
may
not
actually
be
true,
so
other
option.
We've
already
talked
about
splitting
the
draft.
We
could
do
that.
There
are
consequences,
though,
which
we've
also
already
talked
about
thanks
Mike.
If
we
split
the
draft,
what
happens
when
we
get
to
IETF.
B
B
B
A
F
Want
so
all
we,
it
is
the
working
group
clear
on
what
the
question
is
at
this
point
again.
Yes,
that
was
my
comment
on
on
client
asymmetry.
I
like
stuff,
like
that
I
mean.
If,
if
we
have
that
analysis
in
hand,
it
may
actually
be
easy
to
answer
this
that
question,
but
you
know
you
know
skipping
over
that
issue.
B
H
B
Actually
something
that
has
also
been
brought
up,
I
don't
think
week.
Any
one
mentioned
it
here,
but
set
is
going
to
be
profiled
by
applications.
You
know,
risk
is
profiling.
It
oh
I
de
C
log
out
is
profiling,
it
others
will
and
those
profiles
can
and
likely
will
mandate
one
or
another
delivery
method,
as
MTI
for
different
use
cases
and
for
different
contexts.
So
I
think
that
that
speaks
to
your
point.
That
set
really
is
is
the
it's
the
information
model.
B
I
G
A
So
my
whether
ambitious
plan
is
to
take
three
harms
one
on
whether
we
want
a
single
empty
eye
method.
Well,
if
the
answer
is
yes,
which
one
it
should
be,
whether
push-up
ople,
because
these
are
the
two
ones
that
we
actually
have
on
the
table
and
then
a
harmon
whether
we
want
to
split
the
draft
comments,
objections
questions
I
will
clarify
their
arms
more
as
we
move
into
them,
but
case
so.
I
John
Bradley,
as
it
was
pointed
out,
I
think
one
of
the
speaker's
the
MTI
doesn't
necessarily
need
to
be
symmetric
for
both
the
client
and
the
server.
So
it's
confusing
to
me
your
question
are:
we
is
this
that
there
should
be
a
single
MTI
for
that
both
client
and
server
must
implement
I,
think
there's
more
options
than
what
you
enumerated
would.
I
I
G
G
I
B
B
That
I
mean
that's
sort
of
the
fundament
that'sthat's.
That's
the
question!
No,
like
it
you
you
can't
say
one
is
MTI
for
transmitter.
One
is
MTI
for
receiver
because
they
must
necessarily
have
to
be
functioning
in
the
appropriate
role
within
the
protocol
they
transmit
are.
Implementing
push
is
only
going
to
be
able
to
send
messages
to
a
receiver
who's
implementing
push
in
the
receiver
role
same
thing
for
poll.
J
Just
enricher
so
I
think
that
we
could
approach
this
hum
in
a
couple
of
different
ways.
It's
we
may
want
to
take
a
hum
specifically
from
the
perspective
of
the
transmitter
say,
should
push
be
implemented,
should
push
be
MTI
for
transmitter?
Should
pole
be
an
MT
I
for
transmitter.
If
we
wanted
to,
we
could
take
the
same
hums
from
the
perspective
of
the
receiver.
J
In
addition
to
those
I
think
those
two
at
the
very
least
are
necessary
and
people
can
hum
for
both
if
you
think
we
should
have
both
or
you
can
make
that
a
separate,
a
separate
option
that
both
should
be
empty.
I
Annabelle's
very
salient
point,
though
the
receiver
doesn't
really
have
a
choice
here.
This
is
not
the
kind
of
protocol
where
you
can
like
try
one
and
then
negotiate
the
other.
When
it
fails,
it's
it's
either
going
to
be
there
or
it's
not,
because
they're
drastically
different
models
from
each
other.
J
That's
the
whole
confusion
about
client
versus
receiver
and
stuff
like
that
right.
So
I
think,
in
my
view
of
looking
at
this,
that
MTI
from
the
clients
perspective
is
dictated
by
whatever
sorry
see.
I'm
doing
it
now,
MTI
from
the
receivers
perspective
is
dictated
by
whatever
the
transmitter
supports,
so
I
think
that
we
should,
at
the
very
least,
get
a
sense
for
what
people
think
should
be
MTI
for
the
transmitter
to
support
if
we
want
to
do
all
of
this
other
stuff
for
clarity.
On
top
of
that
sure.
D
So
transmitter
fill,
hunt
here,
transmitter
and
receiver,
or
you
know
the
a
player
concept.
The
way
you
have
to
look
at
it
or
I
look
at
it
is
that
at
the
receivers
perspective
they
have
a
choice.
It
boils
down
HTTP.
Are
they
able
to
be
an
HTTP
endpoint
or
not?
So
if
you're
a
mobile
app,
probably
not
if
you're
an
IOT
device
behind
a
number
of
gateways
and
security
things?
Probably
not.
You
have
a
hard
choice.
D
D
Anyways
and
the
whole
problem
repeats
as
you
reverse
transmitter
receiver
rolls.
So
that's
something
to
think
about
about
how
this
evolves
and
where
complexity
lies,
but
in
general
those
that
are
behind
some
network
restrictions
are
going
away.
I
understand
by
the
way
yearns
comments
about
the
firewall
I
was
that
way
two
years
ago,
when
we
started
and
was
behind
push
all
the
way
I'm
finding
it's
a
hard
note,
they
won't
do
that.
It's
a
little
bit
like
TLS
one
three
they're
getting
rid
of
things
that
support
man-in-the-middle.
That's
now
hard!
D
F
So
I
think
a
lot
of
what
she'll
said.
It's
actually
about
the
confusion
between
mandatory
to
implement
a
mandatory
to
deploy
and
in
practice
mandatory
the
deployer
is
going
to
wind.
Up
with
you
know
everything
it's
you
know,
that's
what
people
will
have
to
in
order
to
handle
all
the
use
cases
I
actually
can
come
up
with
something
else,
but
I
find
myself
agreeing
with
Justin
I.
B
Annabel
Backman
Amazon
I
think
we
should
be
careful
about
making
assumptions
that
transmitters
are
going
to
have
to
implement.
You
know
both
protocols
or
all
protocols,
implicit
in
that
is
the
assumption
that
every
transmitter
is
going
to
have
use
cases
that
require
both,
and
that
may
or
may
not
be
the
case.
There
may
be
transmitters
who
don't
care
about
and
don't
have
use
cases
for
getting
events
from
clients
who
can't
act
as
a
HTTP
server.
There
may
be
applications
for
set
where
that
concept
just
doesn't
apply.
K
There
qunit,
you
pointed
out,
I
UT
devices
and
if
you
think
about
the
MT
ie,
that's
actually
the
IOT
devices.
There
is
very
important
because
that
stay
where
you
want
to
grow
minimal
implementation,
you
want
to
do
what
is
their
smallest
possible
implementation,
what
to
do
and
then
you
want
to
only
implement
the
empty
I
am
algorithm
and
nothing
else.
And
then,
if
you
implement
an
MPI
implementation
in
your
end
and
you
probably
associated
ITT,
you
should
talk
to
some
a
bigger
device.
K
K
That's
actually
makes
it
very
hard,
I
think
to
understand
which
one
would
be
better
for
them,
but
usually
having
single
empty
is
better
than
having
multiple,
because
that
make
it
easier,
and
even
if
you
say
you
do
not
have
to
deploy
it,
but
if,
if
the
code
isn't
there,
you
can't
even
change
the
configuration
to
get
them
to
work
together.
Unless
you
have
one
single
emptyeye
that
is
implemented,
or
at
least
one
singular
in
painter
at
a
three-bladed
Potence,
will.
B
B
Frequently,
we've
seen
you
know
what,
regardless
of
whatever
protocol
whatever
standard
protocol,
we
want
them
to
be
talking
to
us
with
inevitably
they'll
plumb
everything
through
their
data
center,
so
their
IOT
devices
are
all
calling
home
to
their
systems
that
they
can
control
and
they
can
update
and
then
they'll
talk
whatever
protocol
to
us
so
yeah,
it's
just
some
extent,
I
think.
As
far
as
the
device
side
code
is
concerned,
they're
largely
insulated
from
these
kinds
of
discussions.
E
William
Dennis
I
agree
with
that
viewpoint.
I
think
I
think
this
comes
down
to
again
the
kind
of
the
application
of
this
set
delivery
and
that
there
are
different
applications
for
it.
So
I
don't
think
we
have
like
an
ID
use
case.
That's
sort
of
a
generic
set
delivery
to
use
case
that
anyone
has
been
discussing
so
I
think
again,
there's
just
it's
application
specific
and
therefore
the
the
usual
kind
of
interrupt
concerns,
don't
necessarily
apply
because
it's
kind
of
constrained
to
their
application
domain
anyway.
I
think
we're
expecting
that
there'll
be
profiles
of
this.
E
So,
as
you
said,
risk
will
will
likely
have
a
profile,
that's
with
risk.
You
know
we're
using
set
we're
using
a
bunch
of
events
that
have
been
defined
by
set
wagon
a
mandate,
push
for
that
particular
profile,
and
so
that's
the
application
that
you
know
that
governs
the
Interop.
For
that
you
know
that
group
of
people
and
any
IOT
device
using
risk
you
know,
can
they
rely
on
those
on
that
profile.
They're
mandatory
things
specified
by
it.
Okay,.
A
A
So
if
it's
a
yes
means,
yes,
we
think
we
need
a
single
method
to
be
empty
now
for
transmitters.
If
it's
a
no,
it
means
we
don't
think
we
need
an
empty
rifle
transmitters
and
we
as
a
group,
believe
that
we
can
that
we
can
specify
we
can
define
use
cases
and
the
actual
usage
scenarios
for
each
of
the
two
methods
on
the
table.
Yes,
John
Justin,
Richard,
Justin,.
J
A
J
J
B
A
A
B
Annabelle
Backman
Amazon
have
agreed
with
Mike
agreeing
with
me
also
the
reason
I
I
hummed
against
making
both
of
these
MTI
and
their
real
reason
is
that,
because
I
think
we
should
split
the
spec,
which
sort
of
makes
them
both
MTI
for
each
use
case.
So
it's
a
little
bit
weird
to
say:
they're,
not
both
MTI.
B
Basically,
what
I'm
against
is
keeping
or
what
I'd
prefer
to
see
is
separating
them.
So
if
you're
doing
HT
push
you're
doing
HTTP
push
that
becomes
MTI,
482
e.push,
if
you're
doing
HTTP
poll.
Obviously
HDPE
pole
is
MTI
for
that.
If
you're
doing
set,
that
doesn't
necessarily
mean
you're
doing
either
one
of
them.
J
J
For
kind
of,
you
know
the
ecosystem
for
transmitters
to
support
both,
because
every
single
comment
that
I
have
heard
about
constraints
and
being
able
to
support
something
and
not
support.
Something
has
always
been
on
the
receiver
side.
Oh
this
receiver
won't
be
able
to
do
that
or
this
receiver
won't
be
able
to
do
an
endpoint
follow
of
law,
whatever
transmitters
for
set
for
the
most
part
aren't
going
to
be
as
constrained.
J
B
About
back
Amazon
just
to
make
you
know,
good
points
are
up
regarding
the
procedural
Nisour
not
of
splitting
the
speck
it
to
add
on
that
right
now.
You
know
we
have
a
set
draft.
That
says
nothing
about
delivery
methods,
so
people
can
do
set
and
not
do
set
delivery
over
HTTP,
as
it
is
so
we're
already
in
a
world
where
people
can
and
will
do,
set
and
not
use
either
of
these
delivery
methods.
The
best
we
can
do
at
this
point
from
a
MTI
standpoint
to
say
this.
B
B
B
E
William
Dennis
the
reason
I'm
against
the
both
being
empty
I,
I.
Think,
theoretically
it
to
me,
it
just
seems
like
we
have
two
different
groups
that
that
can
have
their
own
applications
and
be
quite
happy
in
that
world
and
then
practically-
and
this
is
something
nml
mentioned
earlier-
there
are
some
concerns
around
scalability,
for
example.
So
from
a
practical
sense,
the
two
teams
from
Google
and
Amazon
that'll
work
on
Interop
are
likely
not
going
to
be
implementing
and
likely
not
going
to
be
implementing
pull
so
from
a
practical
sense.
I
So
John
Bradley
I
think
splitting
the
specs
in
sidestepping
the
issue
is
probably
the
best
thing.
As
Phil
pointed
out.
There
are
a
lot
of
cases
where
we
may
have
bi-directional
by
directionality
and
because
of
network
topology,
a
device
acting
as
a
receiver
may
only
be
able
to
accept,
may
only
be
able
to
do
pol,
but
because
of
the
same
network
constraints
it
can
only
do
push
when
it's
acting
as
a
transmitter
and
trying
to
put
empty
eyes
in
is
just
it's
going
to
be
wrong,
yeah
for
it
from
a
deployment
scenario.
A
E
C
Yeah
I
mean
one
of
the
biggest
complaints
about
the
josé
work
was
that
we
put
all
the
algorithms
in
a
separate
draft
than
the
places
that
uses
them
so,
for
instance,
all
the
signature
algorithms
in
our
in
75
18,
even
though
the
generic
signature
is
in
75
15
and
it
confuses
the
heck
out
of
a
lot
of
people.
So
my
experience
is
no
don't
do
that
again.
B
B
The
that
both
methods
use
is
like
the
error,
signaling
and
most
of
that
I
believe,
is
coming
from
Jha
anyway.
So
I.
If
that's
the
concern,
I'd
suggest
we
go,
you
know,
look
at
the
draft
and
see
if
there
realistically
is
actually
any
significant
overlap
between
the
two
at
this
point
that
isn't
already
standardized
somewhere
else.
B
Annabel
Backman
Amazon,
if
need
be,
I'd,
be
happy
to
edit
poll
as
well,
since
we
have
a
bunch
of
volunteers
for
push
I
think
it'd
be
better
for
somebody
who
is
closer
to
those
use
cases
to
do
it,
but
if
we
don't
have
any
volunteers,
I'd
be
happy
to
do
it.
If
it
means
that
we
can
move
forward.
Thank.
C
A
A
B
Okay,
so
this
is
a
little
bit
different.
Some
of
you
may
recall
around
the
beginning
of
the
year,
there
was
discussion
over
whether
we
want
to
change
the
format
of
the
security
event
token,
and
one
of
the
elements
of
that
alternative
design
was
this
idea
of
subject
identifiers
types
at
the
time
it
was
discussed?
Hey,
maybe
we
should.
This
is
something
we
should
standardize
within
set,
but
you
know
not
move
forward
with
a
totally
different
set
draft
that
was
discussed
on
list.
B
Never
went
anywhere,
I
thought
I
would
bring
it
back
up
here,
show
what
we're
doing
with
this
in
the
RISC
working
group
and
kind
of
toss
it
out
there
to
see
if
people
want
to
pick
it
up,
lift
it
out
of
risk
and
into
set
into
second
vents.
So
from
the
risk
standpoint,
a
risk
by
the
way
for
anyone,
who's
not
familiar,
is
a
risk
and
incident
sharing
and
collaboration
or
cooperation.
B
I
can't
remember
which
one
it
is,
but
the
idea
here
is
authorities
for
identifiers
or
for
an
identity,
can
communicate
security
events
about
that
identity
to
providers
or
to
two
services
that
are
relying
upon
that
identity.
So
we
sort
of
have
two
big
use
cases
for
this,
so
we
have
to
think
about.
The
first
is
the
explicit
reliance
scenario
where
you
have
a
party:
that's
actually
acting
as
a
relying
party
to
some
kind
of
identity
provider.
B
B
The
challenges
presents
for
risk
is
in
all
of
these
scenarios.
We
are
identifying
the
subject
in
very
different
ways.
In
the
explicit
use
case,
you
have
typically
some
kind
of
shared
identifier
between
the
relying
party
and
the
IDP
and
in
oh,
I
DC
it's
an
issue
or
the
subject
and
sam'l
it's
who
the
hell
knows.
Whatever
it's
specified
in
the
the
the
metadata
on
the
implicit
side,
it's
probably
something
like
email
address
and
phone
number.
Theoretically,
it
could
be
other
identifiers.
The
point
is
that
there's
a
lot
of
different
use
cases
here.
B
So
how
do
we
within
risk
make
sure
we
have
a
consistent
way
of
saying
what
kind
of
identifiers
we're
talking
about?
How
we're
identifying
these
subjects
the
the
salut
we
have
four?
That
is
something
we
termed
subject,
identifier
type
and
it's
basically
just
a
simple
way
to
define
a
set
of
claims
that
we
are
using
to
identify
a
subject:
we've
defined
four
types
within
risk,
email,
phone
number
issue
or
in
subject,
and
then
the
fourth
one
ID
token
claims
which
I'll
show
in
the
example
will
help
explain
what
that
one
is.
B
So
we
can
step
through
just
some
quick
examples
in
risk.
What
we,
what
we
have
within
our
event,
definitions,
if
you
recall
and
set
every
event,
has
a
capability
of
having
a
event
body
with
with
additional
metadata
within
that
within
risk.
We're
using
this
subject
claim
within
that
body
to
represent
the
subject
of
the
risk
event.
This
allows
us
to
have
this
kind
of
multi-part
subject
where
you
know
we
have
n
different
claims
that
collectively
identify
the
subject.
B
One
of
those
you
can
see
a
subject
type
that
tells
us
what
kind
of
subject
identify
our
type
we're
working
with,
and
then
everything
else
within
this
subject
object
is
the
claims
for
that
type
so
step
through
that
phone,
pretty
self-explanatory
issuer
and
subject
again
here
you
can
see.
We've
got
both
issuer
and
subject
claims
here.
So
you
know
who
we're
talking
about
importantly,
note
that
the
issuer
here
could
be
different
from
the
issuer
of
the
set.
B
That's
why
we're
specifying
it
here,
there's
no
guarantee
that
the
system
that
are
the
entity
that
is
generating
the
set
is
actually
the
issuer
of
the
identifier
mm-hmm.
It
could
perhaps
be
the
relying
party
who
is
transmitting
events
back
to
the
identity
provider
and
in
that
case
they
want
to
communicate,
who
they're
talking
about
what
subject
they're
talking
about
in
a
way
that
the
identity
provider
is
going
to
understand
and
the
best
way
for
that
is
this
existing
shared
identifier
that
they
already
have.
B
The
last
one
is
this
ID
token
claims.
This
is
a
use
case
that
is
important
for
the
in
the
explicit
space
as
much
as
we
would
like
as
identity
providers
for
all
of
our
relying
parties
to
be
performing
account,
linkages
based
on
issuer.
In
subject
the
standardized
identifiers
x'.
That
doesn't
always
happen
a
lot
of
times.
They
will
just
use
email
or
phone
number
or
some
other.
B
What
other
claim
that
is
theoretically
unique
to
establish
those
linkages
and
if
that's
the
case,
then
they're
not
necessarily
in
a
place
to
be
able
to
use
just
issuer
and
subject
so
we
introduced
this
ID
token
claims
type
as
a
way
to
say
here
are
all
the
claims
I
know
about
this
entity
about
the
subject.
I
know
you're
using
one
or
a
couple
of
these
to
identify
the
subject.
So
here's
what
I
know
I've
shared
with
you,
you
figure
out
whatever
makes
sense
on
your
side.
B
So
the
question
or
the
reason
I'm
I'm,
presenting
this
as
I
said
we
we
talked
about
this
earlier
in
the
working
group
in
the
context
of
a
different
token
Draft.
We
opted
not
to
go
that
route.
Risk
has
since
pulled
this
concept
down
to
our
working
group.
It's
in
our
our
draft
of
the
risk
profile
of
set.
Currently
people
had
expressed
interest
in
the
idea,
so
we
want
to
raise
the
question
should
I
just
do
we
want
to
take
this
work
back
up
into
second
and
make
a
say
second
vent?
B
C
B
They
can't
define
an
arrest
you
at
all,
but
you
can,
but
you
can
specify
third-party.
B
B
F
H
A
F
E
I
B
B
A
A
A
B
Valve
acumen
Amazon
so
for
context,
the
expiration
claim
the
jot
expiration
claim
in
the
set
draft.
Today,
the
guidance
on
that
is
not
recommended
and
the
the
rationale
behind
that
is
the
statements
being
made
about
about
by
the
the
security
event
or
token
about
the
security
event,
don't
really
expire.
Reality
doesn't
expire,
which
is
generally,
hopefully
true
and
and
so
putting
an
expiration
on
that
doesn't
necessarily
make
sense.
Mm-Hmm.
B
The
counter
argument
to
that
is
expiration
plays
an
important
role
in
indicating
to
the
recipient
of
a
jaw.
How
long
they
need
to
worry
about,
cashing
JT
is
for
collisions
and
honoring.
The
the
the
the
the
jaw
in
general
on
the
the
further
argument
is
that
the
expiration
is
not
a
statement
about
the
data
within
the
jaw.
It's
a
statement
about
the
jaw
itself,
so
the
by
say
by
putting
an
expiration
in
a
security
event
token.
What
you're
saying
is
this
token
expires.
This
token
should
no
longer
be
interpreted
or
accepted
after
this
point.
B
C
C
If
the
transport
protocol
uses
caching
as
a
cache
lifetime
hint,
whereas
if
you
look
at
most
transport
protocols
that
do
support
caching,
HTTP
being
probably
one
of
the
most
well
known,
the
caching
information
is
provided
as
protocol
headers,
not
in
the
content
being
communicated.
So
you
don't
add
stuff
to
the
HTTP
body
about
caching,
you
add
stuff
to
the
HTTP
headers,
that's
specified
by
the
transport.
Similarly,
we
should
not
be
injecting
transport
specific
information
into
the
set,
because
that's
a
layering
violation,
so
the
spec
already
has
it
right.
B
Anabelle
back
man,
Amazon,
I
I,
think
we're
missing
the
word.
Caching
here,
yeah
I
think
it
was
using
in
the
email
thread.
I,
don't
think
we're
actually
talking
about
caching
here
we're
talking
about
the
the
record
of
which
jdi's
you've
seen
and
therefore,
which
sets
you
can
throw
out
or
which
jot
syndrome
generally
we
can
throw
out
of
which
guts
you
shouldn't
necessarily
trust.
B
B
How
long
do
you
have
to
hang
on
to
a
JT
eye
for
before
you
can
safely
get
rid
of
it
with
expiration
baked
into
the
token
that
gives
you
an
out,
because
after
that
expiration
time,
you're
gonna
ignore
that
that
jaw,
whether
or
not
you
see
in
each
84
cuz,
it's
expired,
so
you
that
that
gives
you
an
upper
bound
for
what
your
your
expiration
time,
I
or
a
lower
bound
for
your
expiration
time
needs
to
be
so
yeah.
It's
called
cashing.
It's
not
really
cashing.
D
A
concern
I
have
here
is
that
sets
are
statements
about
state
changes
that
occurred
in
the
issuer.
We're
not
making
commands
we're,
not
making
security
assertions
and
we're
trying
to
treat
them
as
commands
and
assertions
which
brings
up
the
issue
of
how
long
do
I
keep
it
for
how
long
is
it
good?
For
the
reason
there
is
no
expiry
as
we're
saying
something
occurred
in
the
past,
so
the
past
doesn't
expire.
It's
a
statement
of
record.
D
That
was
the
key
reason
we
started.
Sac
was
to
differentiate
from
access
tokens
in
this
regard
in
a
very
strong
way,
so
I.
But
that
said,
people
are
free
to
use
it.
However,
they
want,
but
I
don't
see
if,
if
family
animals
saying
that,
where
the
Interop
issue,
it's
it's
up
to
the
receiver
based
on
how
they're
using
it
to
decide
how
to
mitigate
the
problem
at
the
level,
the
spec
is
written.
I
can't
see
how
he
would
solve
this
in
an
interrupt
way
or
a
specific
use
like
this.
D
D
Don't
think
so,
but
it's
not
the
same
kind
of
a
damn
'putin,
so
you
would
expect
because
it
depends
on
what
the
receiver
decides
to
do
that
and
in
the
introductory
text
we
may
be
clear
that
the
receiver
decides
their
own
actions
and
therefore
the
consequences
of
their
actions
determine
whether
a
replay
attack
is
possible
or
not.
That's
how
I
read
it
because
we're
not
issuing
a
command
we're,
not
issuing
an
assertion
like
like
a
log
on
assertion.
D
This
is
a
different
animal,
so
there
shouldn't
be
a
replay
attack
because
we're
not
asking
somebody
to
do
something:
we're
not
changing
a
state
explicitly.
The
receiver
is
the
one
that
decides
what
to
do
and
what
action
to
take.
Therefore,
the
actions
they
take
could
trigger
a
replay
attack,
but
that's
of
their
own
making
do.
C
We've
already
provided
the
j-team
that
mike
jones
microsoft,
we've
already
provided
the
jti
value
such
that
if
they
want
to
detect
replay,
they
can
do
so.
So
we've
done
that
I
mean
that
being
said
and
again,
I
said
this
on
list.
But
since
we're
discussing
this
in
the
room,
I'll
say
it
again
because
sets
are
factual
statements
about
something
that
occurred.
C
We
should
not
be
like
encouraging
sort
of
random
values
to
be
generated
now
particular
use
cases
and
transport
protocols
probably
can
and
will
have
time
values
that
are
used
in
particular
ways,
but
it
may
not
be
expiration.
It
might
be
based
on
the
issued
time,
which
again
is
a
true
thing
that
doesn't
change.
C
G
B
Think
it's
dangerous
for
us
to
make
any
claims
that
replay
attacks
aren't
going
to
be
relevant.
Yes,
theoretically,
a
receiver
could
keep
a
record
of
every
GTI
they've
ever
seen
that
won't
scale.
There's
a
reason
expiration
is
in
John
and
not
ID
token.
It's
clearly
intended
to
be
there
for
more
than
just
assertion.
Token
use
cases.
I
think
the
the
use
case
we're
talking
about
here
is
very
much
in
line
with
what
is
described
within
within
John
itself.
I
You
know
the
the
reason
why
we
added
JT
I
was
to
be
able
to
detect
receiving
the
same
token
multiple
times
without
having
to
sniff
through
lots
of
different
fields,
so
that
you
know
sometimes
that's
the
security
concern.
Sometimes
it's
just
you.
May
you
may
wind
up
having
processing
errors,
processing
the
same
thing
twice
the
expiry
is
intent
was
intended
to
be
you
do
not.
I
You
should
not
receive
process
this
token
if
you
receive
it
after
this
time,
not
that
the
content
of
the
token
is
invalid,
which
is
I,
think
that
that
the
information
in
the
token
is
no
longer
valid,
which
I
think
was
the
the
point
that
that
some
people
were
making.
But
if
you
don't
have
some
period
at
which
point
you
will
no
longer
process
the
token
based
on
time,
then,
as
Annabelle
points
out,
you
have
an
infinite
list
of
jdi's
that
you
must
keep
in
that
just
as
impractical
from
a
deployment
point
of
view.
I
So
there
is,
you
know
when
JT
I
was
created
in
in
light
of
having
the
expiry
time
that
the
interrelationship
of
those,
as
pointed
out,
is
that
it's
not
a
layering
violation.
It's
how
long
do
you
need
to
keep
that
list
of
jdi's
to
successfully
detect
duplicates
I?
Think
that's
a
perfectly
fair
use
for
it.
I
think
we
may
need
to
be
clear
that
you
shouldn't
interpret
the
expiry
as
being
the
information
contained
in
the
in
it's
no
longer
valid.
I
It's
just
that
you
can't
receive
it
anymore
for
processing
reasons
which
is
sort
of
the
way
that
we
sort
of
simplified
some
of
the
many
fields
in
sam'l,
not
not
on
or
after
in
various
other
things
into
expiry,
but
this
is
expiry
is
intended
to
be
the
top
the
processing
time.
For
the
token,
not
when
the
information
expires.
C
Mike
Jones
again
and
again,
I
said
this
on
list,
but
it's
fine
for
profiles
to
say
that
they're
going
to
use
the
expiration
claim
in
a
particular
way,
including
the
way
that
John
or
Marius
are
describing,
but
the
reason
I'm
reacting
so
strongly
is
Marius
was
proposing
making
it
mandatory
and
there's
plenty
of
use
cases
where
that's
the
wrong
thing
to
do.
I'm,
not
against
using
the
field
I'm
against
jamming
it
down
people's
throats.
B
Anabel
Backman,
Amazon
I
think
my
concern
with
that
is
currently
the
draft
says
it's
not
recommended
I
would
I
would
honestly
say:
let's
just
strike
the
content
in
the
draft
that
refers
to
exp
and
and
let
the
the
text
that's
in
John
stand
as
guidance
for
that.
C
What
Mike
responding
directly
that
one
of
the
problems
was
striking?
That
is,
there's
other
places
in
the
draft
where
we
had
working
group
consensus
to
use
the
lack
of
the
XP
as
one
of
the
ways
of
clearly
breaking
any
ID
token
implementations,
so
that
there
couldn't
be
confusion
even
in
the
absence
of
explicit
typing.
And
so,
if
we're
going
to
keep
our
ID
token
differentiation
rule,
we
have
to
allow
this
to
be
optional.
B
Anabel
Backman
again
responding,
there's
also
other
mechanisms
for
differentiating
those.
In
some
cases,
providers
probably
have
to
use
something
like
exp
omission:
to
protect
against
the
the
ID
token
mimicking
scenarios
I
think
other
other
scenarios.
They
won't
need
to
I
think
we
can
have
that
guidance
without
saying
that
exp
is
not
recommended.
You
know
full
stop
for
for
sets,
I
think
it's!
It's
primarily
that
not
recommended
language
that
that
I'm
objecting
to
and
I
can't
speak
for
Marius
on
that,
whether
he'd
be
fine
with
just
removing
that
and.
C
H
Benkei
duck
so
I
guess:
I
have
a
question:
there's
someone
hypothetical
but
perhaps
interesting
to
consider.
So
if
we
consider
the
case
where
exp
is
present-
and
it's
used
to
you
know
for
the
replay
protection
purposes
and
I
as
a
receiver
know
for
some
reason
that
I
have
not
processed
this
event
before
perhaps
do
the
issuance
time
and
I
have
been
processing
for
a
while
if
I
trust,
the
expiration
claim
and
I
should
not
process
that
event
but
I
know,
I
have
not
processed
it
and
perhaps
I
want
to
what
options
do
I
have.
H
G
C
I
The
other
potential
alternative
is
to
have
an
explicit
expiry
of
the
jti,
which
could
be
a
new
claim,
which
would
then
solve
the
be
more
explicit
about
solving
the
confusion
about
what
expiry
actually
means.
So
that
should
also
be
considered
as
as
an
option
and
might
would
let
us
say
something
like
if
you're
sending
a
jti.
You
should
say
how
long
you
need
to
maintain
that
jti
for
before
it's
I'm
not
going
to
send
it
again.
So
there
are
potentially
other
solutions
that
could
be
looked
at.
D
The
reason
exp
was
not
recommended
was
a
group
decision
and
a
time
the
group
decision
was
is
that
we
were
not
using
it.
The
way
JWT
defines
it,
and
nor
would
we
redefine
it.
We've
made
a
lot
of
changes
to
stop
redefinition
of
JWT
claims,
so
I
would,
as
your
editor
counsel,
strongly
against
changing
that
text
at
all.
D
A
Let
me
clarify
this
point,
so
the
document
is
going
into
ITF
last
quarter,
where
everybody
can
make
comments,
including
ourselves.
Of
course
we
would
have
liked,
or
we
would
like
the
document
to
be
closed
as
far
as
the
working
group
before
that,
but
we
we
are
free
to
make
smaller
changes
without
interrupting
the
flow
without
interrupting
their
workflow.
A
D
Yeah
I
wanted
caution
about
that.
I
feel
that
the
replay
and
the
caching
things
are
gonna
be
different
from
push
then
from
poll
and
that
Mets,
why
I
would
prefer
it
and
an
HTTP
header,
because
you
may
have
a
different
recommendation.
You
expect
push
to
happen,
delivery
instantaneously.
So
if
you
don't
process
it
in
the
next
few
minutes,
you
should
probably
ignore
it
where
it's
poll,
if
you're,
only
picking
it
up
every
once
an
hour,
then
it's
a
different
expectation.
So
it
seems
to
have
you
have
more
flexibility
if
it's
an
HTTP
Thanks.
L
L
So
I
think
that
that
there's
sufficient
information
already
available
to
to
implement
the
kind
of
policy
that
mario's
is
looking
for
through
the
introduction
of
XP,
without
using
the
XP
at
all,
but
but
relying
more
on
the
the
issued
time
of
the
token
itself
and
and
maintaining
its
own
internal
policy
around
how
to
do
that,
and
that
also
takes
any
Onis
off
of
the
sender
to
dictate
to
the
receiver.
How
long
it
needs
to
remember
things
or
anything
like
that.
It
puts
all
the
the
role
of
the
policy
and
the
needs
on
the
system.
B
And
about
back
when
Amazon,
just
to
clarify
again
since
apparently,
there's
still
ambiguity
around
that
no
one
is
advocating
use
of
the
exp
claim
in
cashing
systems
whatsoever,
no,
where
nobody
has
suggested
that
if
the
word
cashing
has
been
used,
it
was
a
misuse
of
that
word.
We're
not
talking
about
cashing
on
that
note
I.
As
far
as
I'm
aware,
HTTP
has
never
been
concerned
with
issues
of
replay
attacks.
That's
that's
not
something
that
we
try
to
address
at
that
level.
B
And
bear
in
mind
we're
not
introducing
expiry
here.
Expiry
was
introduced
in
John.
What
we're
saying
is
there
are
valid
use
cases
for
using
expiry
as
it's
defined
in
John
with
sets.
The
question
is,
then:
is
there
actually
a
strong
argument
at
the
set
level
to
say?
No,
you
can't
use
expiry.
Oh
no.
You
shouldn't
use
expiry
as
its
described
in
John
when
working
with
sets
and
I
I.
Don't
really
see
that
here.
G
A
All
right
to
conclude
this
discussion,
I,
don't
think.
Well,
we
obviously
are
not
ready
to
take
a
ham
on
anything.
Concrete
I
think
it's
clear
that
the
sense
of
the
room
is
that
there
is
an
issue
and
we'll
take
it
back
to
the
list
and
make
a
decision,
and
the
decision
may
involve
a
small
change
to
the
document.
While
it's
going
through
is
reprocessing.
A
D
D
D
It
actually
turns
out
that
a
lot
of
things
peel
away
and
simplify
at
least
the
draft
is
smaller.
It's
symmetric
in
the
sense
that
the
parameters
used
in
requesting
response
are
the
same,
regardless
of
which
direction
you're
sending
we
also
end
up
with
the
possibility
of
having
not
only
push
mode
pull
mode,
but
now
you
can
do
push
pull,
which
means,
if
you
get
to
the
point-
and
we
have
a
lot
of
cases
for
bi-directional
communication-
you
can
have
that.
D
The
key
benefit,
though,
is
we
change.
Optionality
in
the
spec
from
two
completely
separate
methods
to
one
method:
that,
from
understandably
from
the
standard
perspective
of
push,
is
slightly
more
complex
because
you
you
have
the
ability
to
send
more
than
one
set
in
one
post,
but
that's
really
the
only
change
in
the
previous
delivery
draft.
The
air
signaling
remains
the
same
from
the
delivery
draft.
Everything
else
is
unchanged:
it's
almost
95
percent
backwards,
compatible
for
pol
the
one
parameter.
I
changed,
I
simplified
one
parameter
that
was
there.
The
max
events
was
changed
to
return
events.
D
So
it's
a
boolean.
Now
nothing
else
new
was
introduced.
So
I'm
not
saying
it's
the
solution,
but
it
might
be
a
compromise
that
gets
us
to
a
single
method
that
can
be
deployed
in
both
cases.
Your
choice
here
is
to
choose
whether
you
want
to
be
a
client
or
a
server
or
not
which
protocol
you
use.
So
information
can
flow
either
way
in
independent
of
which
HTTP
mode
you're
running
in
so
that's
one
possibility
and
I
throw
that
out
there.
D
D
Do
want
to
apologize
to
the
group
for
not
releasing
it
earlier.
There
was
the
closed
zone
time,
but
I
wanted
the
discussion
to
proceed
on
the
current
draft.
I
still
support
the
delivery
draft
going
forward
if
it
can
and
I
did
not
want
to
distract.
But
a
number
of
people
in
urged
me
yesterday
to
get
it
on
the
table
so
there
it
is.