►
From YouTube: IETF110-STIR-20210312-1430
Description
STIR meeting session at IETF110
2021/03/12 1430
https://datatracker.ietf.org/meeting/110/proceedings/
A
Out,
okay,
so,
while
he's
getting
that
figured
out,
he.
A
A
A
We
have
a
very
large
agenda
for
a
one-hour
slot,
we'll
try
and
keep
the
pace
moving,
and
if
we
don't
get
to
everything,
we
will
schedule
an
interim
virtual
interim.
C
A
lot
more
time
between
this
meeting
and
the
next
than
there
was
between
this
and
the
last.
I
expect
we
will
have
at
least
one
virtual
between
this
meeting
and
the
next
in
any
case,
but
as
russ
noted,
if
we,
if
we
don't
finish
our
agenda
today,
we'll
have
one
very
soon.
A
Okay,
the
the
first
two
drafts
I
expect
are
going
to
be
short
because
they're
pretty
far
along
at
the
process,
but
we'll
start
with
that.
D
Slide
my
pandemic
hair
is
looking
worse
than
usual
this
morning,
so
yeah
just
a
quick
update
on
things
in
flight.
We
have
some
rc's
now
front
of
band
and
diversion
wow.
Like
you
know,
after
these
been
practiced
for
years,
we
finally
have
rfcs
for
those.
That's
always
a
good
thing
eventually.
D
So
certificate
delegation
has
been
revised
to
reflect.
Actually
our
discussion
previously
about
things
like
removing
the
ability
to
let
intermediate
certs
sign
passports
or
acquiring
e-search
for
that
now,
which
is
just
you
know,
an
administrative
task
really
rather
much
of
a
technical
change.
There
are
a
few
other
miscellaneous
things.
D
Obviously
ben
as
usual
had
some
very
detailed
and
insightful
comments
that
we
we
managed
to
plow
our
way
through
on
that,
but
hopefully
we'll
be
hearing
back
from
them
about
that
soon,
and
that's
it
on
this,
since
we
have
a
long
agenda.
A
A
We
were
going
to
just
take
this
moment
to
say
regarding
the
rph
emergency
services
document
that
is
now
just
finished,
isg
evaluation.
So
it's
shifted
just
yesterday.
I
believe
to
the
rc
editor's
queue
yep
and
the
next
one
we're
talking
about
is
rich
call,
data
chris
or
john.
That
must
be
chris.
E
Hey
everyone:
you
can
hear
me:
okay,
ready,
yep,
cool
yeah,
so
quite
a
bit
to
talk
about,
but
I'll
try
to
go
through
it
quickly.
Hopefully
it
makes
sense
and
and
I'll
also
reference
since
they're
sort
of
jointly
dependent
on
each
other.
The
sip
core
document
as
well,
but
the
major
thing
to
talk
about
is
integrity
mechanism,
but
next.
E
E
So
just
I
have
a
list
of
all
the
different
edits
here.
I
think
john
had
a
comment
about.
Maybe
160
characters
was
a
little
too
long,
although
he
still
say
should
so
updated
that.
E
I
added
a-
and
this
is
maybe
an
important
thing
to
you-
know-
get
feedback
on.
I
added
a
must
for
uri
usage,
as
I
was
looking
through.
All
the
properties
in
j
card
there's,
one
exception,
which
I
note
in
the
next
bullet
point,
which
is
url,
but
there
really
doesn't
seem
to
be
much
need
for
having
multiple
layers
of
uris.
E
So
I
thought
just
to
nip
a
security
hole
or
potential
security
hole.
I
put
some
text
to
say
that
you
know
you
can
only
have
one
url
reference
and
I
say
unless
updated
by
a
future
spec.
E
The
next
one
I
put
some
guidance
in
specific
to
url
so
like
url,
would
probably
be
like
a
web
page
that
you
want
to
send
to
the
to
the
callee
or
or
something
like
that.
I
I
say
something
about.
Oh
I'm,
sorry,
that's
not
the
that's,
not
the
next
one,
but
I'll
talk
about
it
anyways!
I
I
have
some
guidance
in
the
url
section
that
says,
do
not
you
know,
follow
links
automatically
or
or
you
know,
that
type
of
language
that
you
know
just
for
guidance
about
not
following
web
pages.
E
That
you
know-
and
this
goes
to
some
of
the
integrity
needs
that
we
have
and
the
potential
uses
of
multiple
images
to
represent
multiple
resolutions
or
file
formats
that
different
devices
may
be
able
to
render
or
not
render.
E
Some
guidance
around
that
I've
included
cardinality
from
the
jaycard
spec
directly
just
for
convenience,
but
that
goes
to
the
point
of
you
know
which
properties
specifically,
we
can
add
multiple
instances
of
the
original
spec
I
had
some
must
should
I
was
trying
to
like
think
about.
E
You
know
like
what
should
clients
implement
as
a
must
and
versus.
I
should,
and
I
I
think,
just
decided
that
that
wasn't
necessarily
necessary
and
it
wasn't
clear
what
was
must
versus
should
so
I
actually
just
removed
that
type
of
language,
but
but
but
to
be
clear,
I
don't
include
all
of
the
j
card
properties.
E
I
only
include
a
set
that
I
think
are
relevant
to
calls
or
even
remotely
relevant,
to
calls
telephone
calls,
there's
a
bunch
that
are
obviously
not
relevant
to
telephone
calls,
but
I'd
like
people
to
review
that
and
make
sure
that
you
know
I'm
not
limiting
something
or
or
even
feedback
about
what
I
have
included
next
page.
E
Okay,
so
for
the
rcd
spec,
like
I
said,
a
new
update
to
integrity
and
modes,
I
have
a
few
dedicated
slides
for
that.
So
I'll.
Leave
that
to
that
there's
some
clarification
I
made
in
the
text
for
the
third
party
section
with
iss.
E
E
E
Oh
yeah
there's
a
security
note
for
using
rcd
claims
as
part
of
passports
that
are
not
part
of
rcd
extensions,
ex
passports
that
aren't
rcd
passports;
that
if
there's
integrity
rules
you
know
we.
We
want
to
make
sure
that
any
jwt
constraints
that
are
applied
to
rcd
passports,
if
they're
transferred
into
any
other
passports.
A
E
E
Okay,
sorry
about
that
kind
of
blip.
I
guess.
Were
you
clarifying
john,
like
ting
ting
up
what
the
last
bullet
was
go
on
free,
oh
okay,
yep,
so
so
yeah,
I
heard,
must
exclude
so
yeah.
I
added
in
the
security
considerations,
part
of
the
document,
the
use
of
that.
Let
me
know
if
there's
any
thoughts
that
it
should
be
included
any
other
place,
but
I
thought
that
was
appropriate
at
least
for
now.
E
Okay,
next
page,
okay,
so
to
get
a
little
bit
more
detailed
into
the
integrity
updates.
Basically,
I
got
a
couple
of
feedback
from
folks
that
are
starting
to
implement
this,
and
I
think
they
were
good
enough
points
that
really
did
need
to
extend
this.
A
little
more
one
point
was
that
if
the
integrity
is
broken,
if
you
detect
that
the
digest
isn't
matching.
E
E
You
don't
know
if
the
integrity
of
the
other
parts,
the
the
other
you
know,
parts
of
the
rcd
are
broken
or
not.
So
you
have
no
information
that
you
can
provide.
The
second
part
is.
E
When
you
have
multiple
images
or
uri
content
that
you
don't
necessarily
support
with
a
single
hat
with
a
single
digest,
you
basically,
you
know
you're
forced
to
download
all
the
content
in
order
to
calculate
the
digest,
and
that
would
be
a
burden
on
a
a
device
that
an
unnecessary
so
proposing
a
new
framework
which
has
a
lot
more
flexibility.
Actually,
I'm
pretty
happy
with
how
it
turned
out.
E
It
defines
a
way
to
define
multiple
digest.
It
solves
both
of
those
problems
and
it
actually
has
sort
of
a
nice
property
that
it
could
cover.
If
you
want
to
cover
multiple
objects
with
one
digest,
you
can
still
actually
do
that.
E
But
you
know
the
general
usage
is
probably
just
targeting
like
uris
and
things
like
that,
and
the
nice
thing
is
use
this
sort
of
part
of
json
spec,
json
pointer,
which
does
have
pretty
wide
implementation
where
it.
It
provides
a
nice
sort
of
compact
way
of
pointing
to
what
part
of
the
rcd
that
the
digest
is
being
used.
So
the
next
page
shows
some
examples.
E
So
I
have
two
examples:
one
is
using
a
jcl
one
is
using
jcd.
So
this
is
the
jcd
version
where
the
url
uris
are
included
directly
in
the
claims
itself.
E
The
if
you
look
at
the
rcdi
below
I
have
a
digest,
that's
over
the
entire
jcd
and
then
I
have
a
digest.
That's
over
the
contents,
I
mean
of
the
the
the
rcd
j
card
and
then
and
then
digests
that
are
specific
to
each
of
the
urls.
E
So
I
sort
of
color
coded
where
what
the
json
pointer
references,
if
you
go
to
the
next
slide,
one
caveat
with
this
and
I
sort
of
took
the
liberty
of
defining
a
little
bit
of
a
shortcut
here
and
certainly
would
like
to
get
feedback
on
that
is
this.
Doesn't
when
you
use
the
jcl
when
you
use
a
uri
linked
content,
so
that
so,
in
other
words,
this
vcard
earth
j
card
json,
that's
linked
that
doesn't
exactly
follow
the
rules
of
json
pointer,
I'm
sort
of
trying
to
connect
it
where
the
slash
jcl.
E
If
there's
a
slash
after
that,
it
sort
of
assumes
that
you're
going
into
the
json
as
if
it
was
part
of
the
original
json
object,
so
that
just
helps
keep
it
compact
and
nice
and
not
have
any.
You
know
odd
rules
there,
but
it
is.
It
is
sort
of
an
extension
to
the
json
pointer
spec
and
I
and
I
provide
text
to
explain
those
rules,
but
I
just
wanted
to
note
that
and
maybe
get
some
comments,
maybe
I'll
pause
here.
E
If
there's
any
comments,
anyone
has
about
the
mechanism
in
general
or
the
use
of
json
pointer
or
just
make
sure
I'm
giving
people
the
ability
to
comment.
D
I'll
at
least
say
something:
this
is
john
yeah,
so
we
we
we
looked
at
this
quite
a
bit
and
it
is
a
little
bit
of
a
hack,
as
chris
said,
the
way
that
first
line
of
the
rcdi
works
in
this
instance.
Given
how
jsonpointer
works-
and
I
know
when
I
was
looking
at
this-
I
was
initially
concerned-
you
know
if
you
have
to
specify
with
json
pointer
kind
of
okay.
This
is
you
know
the
first
first
sub
element.
D
Certainly,
if
any
scheme
moved
beyond
like
one
level
of
dereferencing,
I
I'd
have
some
skepticism
about
the
applicability
of
this
but
kind
of
given
the
limited
scope
for
choosing
for
this.
I
think
this
should
work.
Okay,.
E
E
A
E
A
A
So
the
because
what
we
were,
after,
I
think,
is
the
hashes
of
the
content
that
you're
going
to
get
back
from
the
dereferencing,
the
url
right,
except
the
first
line,
which
is
a
hash
of
the
structure
itself.
E
E
A
D
A
E
Great
yeah,
I
just
wanted
to
make
sure
I
guess
you
know
rush
you
had
pushed
for
the
integrity
thing.
I
wanted
to
make
sure
that
it's
maintaining
the
property
that
you
had
originally
proposed.
Brian.
F
I
I
don't
know
if
this
is
any
help,
but
there
is
a
piece
of
work
going
on
now
to
do
a
json
path
which
is
an
equivalent
to
xpath.
It
has
a
lot
more
expressiveness.
F
F
E
E
Right
so
I'm
just
thinking
simpler
is
better,
but
but
I
can
look
at
that
a
little
bit
and
see
if
there's
anything
there.
D
I
mean
in
an
ideal
world,
you
know
when
I
was
looking
at
this,
I
was
like
it'd
be
great.
If
actually
you
know
the
keys
and
our
cdi
stanza
could
refer
to
the
actual
names
like
photo
logo,
and
so
the
problem
is,
then
you
have
multiple
versions
of
logo.
You
need
to
differentiate
like
you
know,
and
then
basically
you
end
up
with
something
that
looks
pretty
much
like
this
at
the
end
of
the
day,
so
I
mean
I
think
this.
This
is
probably
sufficient
for
what
we're
trying
to
do
anyway.
E
Okay,
any
other
comments,
all
right.
I
wanted
to
go
over
this
part
quick.
So
originally
we
had
talked
about
three
modes.
It
was
pretty
clear
once
we
sort
of
thought.
You
know
a
little
more
deeply
at
this.
That
there's
really
it's
better
to
think
about
this
in
two
dimensions.
E
One
is
whether
the
signer
is
authoritative
over
the
information
or
non-author,
authoritative,
and
that
generally
corresponds
to
whether
a
delegate
certificate
is
being
used
or
not,
although
it
might
not
be
strictly
that
and
then
the
other
dimension
is
whether
there's
uri
references
or
not.
So
I
think
this
lays
it
out
a
little
more
clearly
and
is
what
we
originally
intended.
E
Anyways
and
just
has
the
very
clear
rules
that
you
know
like
rcd
integrity
is
needed
when
there's
uri
references
and
jwt
cr
claims
constraints
is
needed
when
you're
providing
this
to
a
non-authoritative
signer.
D
Yeah,
I
mean
you
know
the
the
only
thing
on
this
that
I
keep
wondering
about.
I
mean
because
jdy
t
constrains
the
claims
constraints.
They're
not
you
know,
I'm
always
worried.
There's
some
mischief
where,
like
you
can
put
in
a
hash
for
some.
You
know.
Let's
say
you
have
both
like
logo
and
icon
or
something
and
you
put
your
hashes
for
both
logo
and
icon
into
the
bucket
of
the
jwt
claims
constraints.
D
And
could
you
mix
them
up
or,
like
you
know,
is
there
some
way
you
you
know
then
could
reorder
them
in
the
j
card.
But
again
I
think
the
the
lexical
ordering
helps
in
that
it.
You
make
sure
that
you
actually
are
associating
the
right
image
with
the
right
field
in
the
the
j
card,
and
so
I
I
you
know.
I
have
like
still
some
nagging
doubts
about
this,
but
as
far
as
I
can
tell
it
works.
E
D
E
D
E
Any
other
questions
on
that,
I
think,
other
than
that.
I
know
we're
sort
of
we.
We
had
already
initiated
work
group
last
call-
and
this
is
you
know,
substantive
changes,
so
I
guess
I'd
look
back
to
what
we
think
we
should
do.
If
she,
we
should
have
a
little
more
review
of
this
and
then
continue
or,
but
I
I
felt
like
this
was
important
enough
to
make
these
changes.
A
Well,
I
think
this
is
a
substantive
change
and
I
think
we
should
just
redo
working
group
last
call
just
to
make
sure
that
everybody's
had
a
chance
to
look
at
it.
You
think
it's
stable
at
this
point
and
it's
ready
for
that.
E
Well,
certainly,
you
know
I
will
share
this
more
broadly
in
the
other
groups
that
are
relevant,
so
I
think
giving
giving
it
you
know.
Maybe
a
meeting
cycle
would
would
be
good.
A
So
maybe
in
a
week
or
so
we'll
just
do
a
stir.
Working
group
last
call
and
flesh
out
that'll
flush
out
reviewers,
exactly
yep.
H
Activate
your
mic
man
yeah.
I
found
the
button
yeah.
I
do
actually
have
a
quick
question
about
not
the
rcd
stuff,
the
the
iss
claim
it
can't.
I
believe
the
language
at
the
moment
is
something
like
it
must
reflect.
The
subject
name
of
the
certificate,
but
reflect
is
very
vague,
and
I
was
just
wondering
if
there's
any
aim
to
put
something
a
bit
more
possible
by
a
computer
in
there,
so
that
we
can
actually
check
that.
E
Yeah,
we
have
sort
of
similar
thing
with
you
know,
just
the
subject
of
the
in
in,
in
general,
the
certificates
for
stir
shaken
as
well.
We
provide
some
like
at
least
in
the
outer
specs.
We
provide
guidance
about
including
the
sbc
and
the
name
of
the
company.
D
I
mean
we
so
we've
gone
back
and
forth
about
this
like,
and
I
think
this
is
still
a
little
like
half
baked
to
be
honest
and
we'll
need
to
sort
this
out.
It's
I
think
it's
largely
starting
on
the
out
at
a
side
to
be
honest,
just
in
the
sense
of
whatever
we
do,
it
has
to
be
compatible
with
the
way
that
we
imagine
like
these
things
can
be
used,
especially
in
the
delegate
cert
context
for
addis,
and,
like
so
I
mean
that's
kind
of
like
a
pa.
You
know
ga
level
decision
right.
D
It's
like
how
you
and
we've
gone
back
to
should
it
be
the
organization
should
it
be
the
subject.
Name
like
you
know
what
what
component
of
it
is
it's
supposed
to
reflect
and
like
who
vets
those,
and
so
I
don't
disagree
that
there's
there's
a
little
bit
of
fungibility
around
all
that
still
that
we're
working
through
and
we'll
just
have
to
get
that
nailed
down
this
cycle.
E
Ultimately,
you
need
to
be
authorized
to
have
a
certificate,
so
I
think
that
bounds
it,
but
I
think
it's
sort
of
I
don't
know
if
there's
strict
security
associated
with
that
association
right
john.
D
What
do
you
do,
especially
if
these,
like
enterprise,
you
know
spirit
delegation
cases
on
the
you
know
on
the
shaken
side
right
and
that
I
don't
think
the
its
spec
needs
to
be
prescriptive
about
that,
but
it
needs
to
be
aligned
that
this
is
the
problem.
Right
is
that
we
just
need
to
make
sure
that
whatever
we're
doing
doesn't
end
up
stomping
on
or
being
you
know,
being
incompatible
with
right.
Whatever
the
decision
is
in
the
other
side
about
that.
E
Yeah
and
to
be
clear,
we
we
have
talked
about
studying
this
in
ipn
and
I
side,
so
it
will
get
looked
at.
D
We
can
so
that
then
people
are
going
to
profile,
because
you
know
who
knows
what
various
other
people
who
are
looking
at
this
are
going
to
want
to
do
for
it.
So
I
kind
of
want
the
itf
version
of
this
to
be
a
blanket.
You
know
not
not
too
prescriptive
version
of
it.
It'll
end
up
getting
nailed
down
for
the
north
american
shaken
ecosystem
my
way
and
at
us
and
that's
you
know
it's
a
very
familiar
tune
that
we
sing
in
this
group
all
right.
So
why
don't?
D
I
talk
a
little
bit
about
this
strap
which
actually
I'm
going
to
punch
on
basically
for
the
cycle
for
time
reason
so
next
slide.
So
I'd
rather
talk
about
connected
identity
and
messaging
today,
so
so
yeah.
This
is
the
draft
we
have.
That
is
looking
at
out
of
ban
from
a
slightly
different
security
model
where
actually
it
is
in
nad.
D
D
You
know
this
is
a
topic
of
some
discussion
over
at
gsma
fines
group,
obviously
in
addis
in
the
ptsc
there's
discussion
about
alternative
authorization,
models
for
storage
and
retrieval
that
are
focused
kind
of
more
on
the
gateway,
transit
carrier
cases
or
kind
of
an
adapter
sort
of
case,
where
you're
doing
out
of
band
just
just
to
kind
of
bridge
people
into
the
ipn,
and
I-
and
you
know
similar
to
the
philosophy
I
was
just
expanding
a
moment
ago,
like
we
want
to
make
sure
that
the
spec
we
have
for
this
encompasses
the
options
that
are
being
explored
in
different
spaces.
D
For
this
without
you
know,
stipulating
anything
that
would
make
it
incompatible
with
one
of
those
approaches.
This
is
always
a
difficult
needle
to
thread.
Definitely
the
exact
relationship
between
the
cps
and
service
providers
in
this
is
another
case
that,
where
you
know,
there's
just
variance,
for
example,
looking
at
the
way
that
the
gsma
is
looking
at
this
versus
the
way
that
ptsd
is
looking
at
those.
And
so
you
know,
as
a
consequence
of
that,
I'm
kind
of
working
through
that
stuff
and
we'll
have
more
on
this
later
so
yeah.
D
So
yeah
we'll
we'll
revise
and
it
sings
things
are
still
a
ways
from
being
settled
for
this
one.
I
expect
next
time
we'll
have
more
to
say
about
it.
That's
all.
I
want
to
say
this
time,
because
I
want
to
move
on
to
cooler
things
we
want
to
talk
about
here.
A
A
A
So
here's
a
simple
example:
it
says
the
first
part
that
the
confidence
claim
must
be
present
in
the
passport
and
the
next
part
says
the
confidence
claim
must
contain
either
high
or
medium,
and
then
the
third
part
says
that
the
priority
claim
must
not
be
present,
and
the
fourth
part
says:
if
the
assurance
claim
is
present,
it
must
not
have
a
value
of
love.
So
those
are
the
kinds
of
statements
that
the
new
syntax
allows,
which
is
in
line
with
chris's
requirements
that
he
just
talked
about
next
slide.
A
I
am
not
aware
of
any
outstanding
comments
and
I
think
it's
ready
for
working
group
last
call
unless
anybody
has
comments
now.
Obviously,
since
I'm
took
the
pen
on
this,
one
robert
will
make
any
consensus
calls,
I
think,
that's
it
I'd
like
to
hear
whether
people
think
it
is
ready
for
working
group
last
call.
A
Okay,
robert,
would
you
take
that
action
please,
after
probably
next
week,
right
sure
next,
free,
though
then.
D
So
this
is
a
document
that
chris
and
I
put
together,
that
is
exploring
the
possibility
of
using
the
same
kinds
of
credentials
that
we
use
to
sign
calls
with
star
to
actually
sign
messages
in
some
form.
Those
can
be
either
message,
streams
or
individual
messages
like
using
the
message
method,
and
the
idea
for
the
moment
is
for
scoping
it
to
basically
just
things
that
use
rfc
8226
credentials,
in
other
words,
things
with
a
tm
off
list,
as
opposed
to
more
generic
email
style
identifiers.
What
have
you
for
sip?
Why
are
we
doing
this?
D
We
do
believe
message.
Spam
is
a
problem.
I've
slide
about
that,
and
it
would
really
just
be
silly
if
people
were
to
be
looking
at
solutions
for
signing
messaging.
That
you
know
was
based
on
telephone
numbers
that
did
not
use
the
credentials
that,
in
fact,
are
being
rolled
out
very
widely
due
to
regulatory
mandates
and
u.s
law
and
everything
else.
It
seems
reasonable
to
have
a
way
to
do
this,
where
those
messages
will
end
up
being
secured
by
stir
certificates.
D
We
still
are
looking.
You
know
hard
at
this
last
question,
though,
like
you
know
where,
where
do
we
get
into
this
ecosystem?
Obviously,
it's
an
entrenched
ecosystem
with
a
ton
of
participants,
ton
of
legacy
attack,
and
so
the
very
real
question
I
think,
as
we
look
towards
adoption,
is
whether
we
think
this
will
really
make
a
difference
or
get
utilized
next
slide.
D
So
is
it
really
a
problem?
I
mean
we've
seen
some
reports
on
the
mailing
list
of
people
saying
this.
This
isn't
really
a
problem.
I
just
wanted
to
from
my
personal
experience
like
this
says
that
this
is
a
text
I
got
yesterday.
I
guess
I
made
these
slides
on
on
wednesday,
so
that
would
have
been
like
on
tuesday.
I
at
least
get
a
lot
of
this
stuff.
D
I
don't
know
of
anybody
else,
but,
like
you
know,
I
I'm
really
not
that
sympathetic
to
the
argument
that,
like
messaging
spam
from
telephone
numbers
is
like
not
an
issue.
Definitely
there
are
other
mitigation
strategies
that
exist.
Obviously,
a
lot
of
service
bureaus
who
are
doing
great
work.
You
know
we
kind
of
email
style
analysis
of
messages
in
order
to
try
to
break
this
down.
D
I
at
least
think
would
be
great
if
you
could
not
spoof
the
numbers
associated
with
messages
and
if
there
was
some
accountability
from
where
they
originated,
and
I
don't
know
if
anybody
on
this
call
wants
to
go
to
bat
for
it's
not
a
problem.
Looking
at
the
attendee
list,
I'm
not
sure
I
see
too
many
people
who
are
making
that
argument,
but
if
anybody
would
like
to
make
the
argument
speak
now,.
I
I
I
I
D
Yes,
yeah,
I
mean
a
lot
of
there's.
A
lot
of
tfa
considered
considered
harmful
these
days
that
hopefully
we
could
nip
in
the
pod
with
something
like
this
so
yeah,
I
don't
mean
to
say
that
this
is
like
just
for
spam.
I
know
brian
wants
it
for
something
very
different,
for
example,
but
like
I
I
want
to
make
clear,
I
think,
there's
spam
and
like
I
would
like
that
to
be
fixed.
So
next
slide-
and
this
is
a
broader
question
I
know
christor.
I
think
christopher
zahn
raised
this
one.
You
know.
D
Is
this
really
in
the
scope
of
stir?
You
know
I've
made
the
argument
on
the
list
that
I
believe
it
is
that
really,
once
we
made
mkey
in
scope,
you
know
binding
passports.
Media
security
necessarily
became
a
part
of
stir.
Obviously
we
use
this
for
sip
brandy
and
to
me
I
don't
really
see
a
huge
distinction
between
using
m
key
for,
like
dtls
over
s,
detail
ssrdp
versus
msrp
over
tls.
D
I
can
see
that
message.
I
is
different.
I
think
that
draws
in
the
president
of
rcdi,
but
I
at
least
wanted
to
have
this
discussion.
I
mean,
I
think
this
is
one
of
the
points
we
need
to
get
through
on
this.
You
know:
are
there?
People
here
who
want
to
make
the
case
really
doing
messaging
should
not
be
in
the
scope
of
star.
J
Well,
I'm
certainly
not
here
to
make
that
case.
I
guess
it
would
just
be.
I
I'd
like
to
get
a
lot
lighter,
slightly
better
sense
of
the
you
know
what
you,
how
you
see
the
problem
being
scoped,
namely,
like
you
know,
like
there's,
like
one
version
where
it's
like
hey,
you
know,
we'll
create
it.
I
mean
extra
already
has
like
a
certificate.
So
it's
something!
That's
like
something
like
silly
version
where
it's
like.
Well,
look!
It's
a
certificate.
D
I
mean
we
cut
the
line,
I
think
at
full:
sweet
security
for
sip.
I
mean
that
was
the
intention
anyway,
with
m
key
and
the
whole
zipper
andy
effort,
right
was
to
say
we
want
a
way
to
bind
the
security
of
the
media
sessions
set
up
with
sip
like
to
the
stir
assurance,
and
so
like.
I
think
anything
that
is
you
know
has
roughly
that
property.
That's
what
I
informally
understand
to
be
the
scope.
I
mean
I'm
not
also,
I'm
also
not
sure
what
the
creep
is
like.
D
You
know
where
you
know,
if,
if
we're
really
just
concerned
about
things
that
are
either
secured
by
m
key
or
this
new
message
integrity,
you
know
a
parameter
that
we
propose
to
add.
Like
you
know,
I
I
think
that
pretty
clearly
binds
it
to
that.
This
is
the
the
content
that
sip
is
either
negotiating
or
delivering
like
that
counts
as
the
media
and
like
that's,
what
we're
trying
to
hear
with
that.
J
Yeah,
it
seems
that
seems
reasonable
yeah.
I
think
so
I
mean
I'm
not
worried
about
like
I'm,
not
also
not,
I'm
also
not
worried
about
like
whether
it's
just
go
for
this
working
group
like
that's
like
the
kind
of
thing,
that's
the
kind
of
like
administrative
thing
we
fix
regularly.
So
I
guess
you
know.
D
I
mean
the
only
thing.
The
only
thing
that's
vaguely
new
we're
doing
here
is
this
message.
Eye
thing
is
the
notion
you
could
actually
have
like
an
integrity
signature
over
the
the
contents
of
a
message
itself.
That's
conveyed
by
like
the
sip
message
method
or
something
that's
that's
the
only
thing
here
that,
from
my
perspective,
is
actually
like
new
chris.
E
Just
gonna,
I
don't
know
if
this
is
an
obvious
statement
or
not,
but
you
know
like
in
terms
of
scope.
You
know
this
is
really
just
protecting
the
fact
that
the
message
came
from
the
person
that's
associated
with
the
telephone
number.
You
know
it
doesn't
imply
anything
else
about
that
content
or
you
know
if
that
person
is
sending
content
that
is
illegitimate
or
whatever
it's
it's
on
them.
So
I
I
don't
think
it
implies
anything
further
than
that.
E
D
Not
fair
enough,
I
mean
it's,
it's
never
any
of
the
same
thing
beyond
what
baseline
stirrer
gives
us
right,
and
that's
certainly
for
going
beyond
that.
I
would
be
concerned
that
we
aren't
really
in
the
scope
of
stir,
so
I
mean
to
the
chairs
I
mean
is:
should
we
consider
this
issue
based
on
the
list
discussion
in
this?
We
kind
of
agree.
Would
you
want
to
do
a
consensus
call
show
hands?
Do
people
think
that
this
is
in
the
scope
store?
How
do
you
want
to
do.
C
C
So
russ,
if
you're
not
going
to
jump
in,
I
will
suggest
that
we
just
proceed
and
I'm
not
hearing
a
a
great
deal
of
dissent
and
concern
about
it
being
in
scope.
It
was.
It
was
good
that
the
question
was
raised,
but
I
think
we've
I
think,
we've
looked
at
it
and-
and
I
don't
think
that
we're
really
going
to
have
controversy.
D
Slide
so
this
whole
question
of
exactly
what
a
message
is
is
certainly
the
the
biggest.
I
think
open
issue
around
this
in
the
sense
of
like
there's
a
bunch
of
billion
different
formats,
by
which
contextual
messages
of
various
kinds
potentially
send
and
like
you
know,
can
we
arrive
at
one
thing
we
say
message:
eye
is
going
to
actually
be
securing
and
like
can
we
do
this
as
vinyl
security
yeah?
D
Probably
we
could,
if
we're
convinced
that
everything
that
we
want
to
cover
is
you
know
expressed
as
a
my
button,
and
you
know
this
this
a
lot
of
these
out
of
band
cases.
You
know
there
are.
You
know
some
potential
questions
about
what
formats
those
kinds
of
protocols
use
they're
different,
using
protocols
than
sit,
for
example
that
are
conveying
messages
and
we
still
want
stir
certificates
to
sign
for
those
messages.
Are
we
just
opening
this?
Like
endless
bucket?
D
D
This
is
my
little
security
assume
that
anything
you're
going
to
be
signing
for,
even
if
it's
not
natively,
carried
as
a
mind
body,
we,
like
you,
know,
turn
it
into
a
mind
body
for
this
or
something
just
you
know
anything
that
can
get
us
to
a
point
where
we
don't
end
up
having
to
hunt
down
the
distinctions
between
the
15
different
versions
of
smpp.
There
are
you
know
things
like
that,
I
think
would
put
us
on
a
better
footing
towards
having
like
an
actual
implementable
standard.
D
So
I
think
my
pros
will
be:
let's
just
do
my
mobile
security,
because
it's
easy,
you
know
and
you're
just
doing
one
thing
and
then
you're
done
it
works.
We
know
it
worked
for
the
sip
message
method.
We
know
there's
at
least
some
out-of-band
things
that
we
work
for
our
people
cared
and
like
I,
I
would
be
content
to
just
do
that.
A
So
ben
said
ben
agreed
in
chat
and
I
also
agree,
I
think
that's
the
place
to
start,
let's
find
out
if
there's
any
problem
with
it,
but
I
don't
see
one
right
from.
D
K
All
right
yeah,
I
I
don't
know
if
any
issue,
but
just
something
we
should
keep
in
mind
that
we
have
now
also
defined
the
the
transport
of
msrp
of
our
data
channel.
So
so
you
may
have
that
taking
place
somewhere
in
the
network
so
just
to
it
may
not
have
any
impact,
but
but
just
to
keep
in
mind.
D
So
do
you
think
that,
having
again
we're
talking
about
two
modes,
we're
talking
about
these
two
modes,
the
message
I
mode
and
then
you
know
there
is
a
normal
kind
of
stir
mode
where
we're
negotiating
sessions
and
streams
and
using
m
key.
So
this
would
be
something
where
you
could
use
m
key
like
to
signal
the
self-signed
keys
used
for
mr
p
for
tls,
for
example
like
is
there
something
that
doesn't
work
if
we're
using
it
in
that
mode?.
K
I
I
don't
know
I
I
I
you
know,
but
we
need
to
think
about
it,
but
but
just
to
keep
in
mind
that
if
we
are,
for
example,
sending
setting
up
msrp
session
that
it
could
be
converted
into
a
data
channel,
I
may
you
may
still
have
sip
for
for
the
signaling.
So
so
so
you
will
still
be
able
to
transport
everything.
But
but
just
a
transport
of
the
message
itself
would
change,
but
maybe
it
doesn't
matter,
but
maybe
work
to
keep
in
mind
and.
D
Yeah
I
mean,
I
think
anything,
we're
negotiating
with
srtp
we'd,
be
able
to
figure
out
a
way
to
make
it
work,
provided
that
you
know
the
king
was
available
to
the
asmb
assets
right
at
the
time
that
they
needed
to
assert
the
m
key,
I
mean:
are
these
data
channel
examples
ones
where
you're
not
using
like
gls
at
all,
or
these
are
just
in
the
clearer
or
like?
What's
the.
E
D
E
D
I
I
hope,
there's
not
like
redundant
levels
of
security
between
the
data
channel
and
then
msr.
You
know
they're,
then
there's
absolutely
favorite
tls
over
the
data
channel
and
the
data
channel
has
its
own
like
ttls.
So
if
it's
just
gtls
right
and
msrp
is
over
that,
I
think
I
think
that
should
work.
Okay,
then.
D
Yeah,
I
understand
I
mean
again
the
ciprandi
case
was
designed
to
get
you
as
close
to
end
to
end
as
you
can
now.
I
mean
that
you
know
that.
Has
this
big
caveat
to
it,
though,
right
that,
like
it's
really
the
authentication
and
verification
services
that
fix
those
keys
and
if
there
are
hops
that
are
prior
to
or
subsequent
to
the
as
and
bs,
then
you
know
that
that's
just
part
of
the
assumed
security
model
of
zip
randy.
D
Now,
there's
hops,
between
the
a.s
and
b
asteroid,
where
the
security
associations
are
being
terminated
in
the
middle
agreed
that
that
won't
work.
But
I
think
that's
working
as
intended
in
the
sense
that
if
there
is
a
man
in
the
middle
that
should
show
up
as
a
security
failure
for
at
least
the
model
we'd
be
proposing
here,.
I
I
think
there
are
hops
that
aren't
just
at
the
asmbs.
You
have
things
like
message
stories
and
and
storing
forward
and
such
things.
So
I
I
I
don't
know
the
answer
to
this,
but
I
think
we
should
think
hard
about
whether
m-key
is
securing
tls
or
whether
m-key
is
doing
object,
level
security
doing
some
kind
of
session
key
for
object
level,
security
on
a
session.
D
I
mean
the
virtue
of
doing
object.
Level
security
is
precisely
that
it
can
be
stored
and
forwarded
right.
If
you're
using
accept
message
for
this,
then
it
just
works.
But,
like
the
you
know,
I
I
I
would
kind
of
put
my
foot
down.
I
think
on
that,
if
there's
some
intermediary
that
is
inspecting
your
messages
between
the
as
and
the
ds,
we
want
that
to
show
up
to
the
vs
as
a
security
failure
or
they're
tampering.
D
With
your
messages
I
should
say,
and
like
that's
that's
part
of
the
I
mean
that
that's
working
is
intended
and
it
may
not
be
practical
for
some
environments,
but
I
certainly
want
a
mode
that
works
that
way
and
if
we
wanted
to
find
other
modes
that
don't
work
that
way
for
special
environments.
We
can
do
that,
but
that's
that's
something
I
would
do
after.
We
have
established
a
way
to
make
it
so
you
have
this
assurance
for
like
at
least
between
the
ais
and
vs
for
messaging
yeah,.
D
See
but
that's
the
point
that
for
those
there's
a
very
different
like
situation
right
and
that's
part
of
the
supernatural
security
model,
I'm
okay
with
that
it'd
be
great
if
everyone
had
their
ass
and
vs
like
built
into
their.
D
You
know
mobile
devices
and
your
phones,
but
I
think
we
all
pragmatically
recognize
that
they're
going
to
be
environments
where
that's
not
possible
as
far
as
I'm
concerned,
as
soon
as
the
vs
terminates
the
security
association,
though
anything
that
happens
after
the
fact,
that's
the
operator's
business,
the
user's
business
and,
like
you
know,
if
we
have
a
model
that
just
lets
us
get
the
assurance
between
whoever
has
the
asmr
as
the
vs.
I
think
we're
we're
doing
our
job.
D
Okay,
that's
good,
so
I
think
I
think
we've
got
a
good
good
consensus
for
my
little
security
on
this
next
slide,
trying
to
go
as
fast
as
I
can
on
this.
So
you
know,
there's
still
a
lot
we're
thinking
about
on
this.
I
think
we're
closer
now
that
we've
got
some
idea
that
probably
this
is
in
scope
and
that
mime
is
a
good
approach
to
this.
You
know
my
question:
the
group
is:
shall
we
adopt?
This
is
still
an
individual.
I
think
it's
worth
doing.
I
think
a
lot
of
people
need
it.
A
Chairs
so
robert
and
I
didn't
have
a
chance
to
convince
about
this,
but
we
have
a
call
for
adoption
and
I
guess
we
need
to
make
a
call
for
consensus
on
the
list
or
make
a
call
on
about
consensus
on
that
call,
and
so
we'll
do
that
next
week.
A
L
D
This
is
a
very,
very
crude
picture
of
what
something
like
that
might
look
like
where
you're
getting
after
your
invite
has
gone
into
some
financial
institutions
signed,
requests
coming
in
the
backwards
direction.
Next
slide,
this
is
good,
so
you
know
you
actually
reached
the
bank
you're
trying
to
call,
and
then
you
did
not
in
fact
get
hijacked
or
something.
So
in
this
version
I
tried
to
flesh
out
a
bit
more
about
like
what
this,
how
this
actually
works.
D
This
is
largely
reiterating
the
guidance
in
4916,
but
with
you
know
in
in
my
own
words-
and
you
know,
with
some
kind
of
more
modern
story,
thinking
around
it,
some
arguments
why
why?
I
don't
think
we
make
this
work
for
cancel?
D
I
also
added
a
bit
about
the
interaction
with
div,
which
I
think
is
very
interesting.
There
are
some
concerns
that
surround
all
that
about
whether
you
want
to
reflect
give
passports
that
were
received
on
the
terminating
side
back
to
the
originators.
They
know
why
their
call
ended
up
where
it
did.
Obviously,
you
know
whenever
we
talk
about
this.
There
are
concerns
about
what
it
means
to.
D
You
know
reveal
that
forwarding
logic,
potential,
business
logic
or
relationships
that
are
associated
with
that,
but
I
feel
like
the
ability
to
do
that
is
an
important
part
of
this
mechanism,
even
if
not
everybody
is
going
to
want
to
do
it
every
time.
So
those
are
the
major
things
that
I
added
to.
This
is
just
kind
of
fleshing
out
more
here's.
How
updates
and
these
kinds
of
things
work?
Here's
what
it'd
be
like
to
do
this
for
pi
and
so
on,
and
you
know
you
there's
something
in
common
between
this
draft
and
the
previous
one.
D
We
are
looking
at
what
more
requests
other
than
invites
reasonably
could
hold
passports,
and
I
think
that
is
if
we're
looking
at
the
scoping
of
stir
in
general,
that
is
kind
of
one
of
the
bigger
questions
that
we're
now
examining
more
broadly
about
where
we're
taking
this
going
forward.
Now
that
it's
taken
off
and
the
marketplace
turns
out
next
slide
so
yeah,
I
still
need
to
like
revise
the
examples.
D
John
had
some
great
examples
of
this,
I
think
it'd
be
important
to
have
those
in
and
to
do
anything
that
we
actually
think
is
like
normative
revisions
to
4916
like
things
that
result
from
the
deprecation
of
the
identity
info
header
in
favor
of
the
parameter.
That's
now
present
in
identity,
I'm
still
on
the
fence
of
whether
this
is
really
abyss.
I'm
calling
it
4916
update
for
the
moment,
probably
it's
abyss.
D
And
finally,
I
know
we
really
want
to
flesh
out
more
this
concept
of
doing
some
medialis
pre-dialogue
for
connect
identity.
So
you
know
really
before
media
starts
that
you
ended
up
reaching
like
the
the
right
entity
and
have
some
expectations
around
whether
or
not
the
energy
you're
calling
supposed
to
support,
stir
and
whether
you
have
security
in
this
well
that
potentially
could
be
deferred
to
another
draft.
We
feel
like
it,
but
you
know
next
slide.
D
You
know
my
basic
question,
even
though
there's
still
stuff
to
do
here,
I
mean
I
think
this
is
a
pretty
important
use
case
again.
There
are
a
lot
of
threat
models,
especially
we're
looking
at
things
like
mobile
networks,
where
even
securing
buys-
and
things
like
that
are
significant,
but
having
this
bilateral,
this
mutual
authentication
of
the
entities
that
are
the
endpoints
of
a
call,
or
at
least
the
end
networks
of
a
call,
really
helps
with
the
threat
model.
I
don't
know
if
this
requires
recharter
to
look
at
this.
D
J
D
Spam
prevent
you
know,
voicemail
hacking
and
things
like
that.
It
is
a
different
threat
model
to
be
looking
at.
Did
I
end
up
reaching
unity
that
I
wanted
to
reach,
and
can
I
have
an
assurance
for
that
and
that
that's
why
I
think
there
is
a
there's
effectively
a
separate
threat
model
and
problem
statement
built
into
this
document.
You
know
it
builds
on
earlier
work
4916,
but
just
without
preface
so
murray.
G
C
Okay,
so
I
guess
it
would
help
me
to
know
who
have
we
got
in
the
room
today
that
thinks
this
is
something
that
we
that
it's
time
to
address
this
and
they'll
put
effort
in
on
really
exploring
the
the
problem
and
making
sure
that
that
we're
doing
the
right
thing.
A
A
Okay,
well,
we
are
out
of
time
so
we're
not
going
to
get
to
the
next
presentation,
but
I
not
hearing
anyone
speak
against
just
one
who's,
not
sure
it's
needed.
D
And
I
do
worry
that
like
what
what's
the
thing
in
24
29
now,
the
additional
identity
or
whatever
that
there
are
going
to
be
solutions
to
the
marketplace,
they're
going
to
try
to
do
this
movies
that
I
think
are
not
not
but
bluntly,
they're,
just
less
secure,
so
yeah.
I
think
it's
important
that
we
articulate
a
way
to
do
that,
especially
as
potential
alternatives
to
the
marketplace
start
to
start
to
bubble
up.