►
From YouTube: IETF109-STIR-20201120-0900
Description
STIR meeting session at IETF109
2020/11/20 0900
https://datatracker.ietf.org/meeting/109/proceedings/
B
A
C
D
A
Welcome
to
the
star
working
group
session
at
ietf
109,
it's
one
of
the
later
sessions-
hopefully
you've
seen
the
note
well
before,
but
this
is
if
this
is
the
first
session
that
you've
attended
this
week,
please
make
sure
you're
familiar
with
what
is
on
this
slide.
It
is
important
for
you
to
understand
everything.
That's
on
it
before
you
speak
up
or
say
anything
in
the
jabber
ring.
A
Our
agenda
today
is
to
go
through
the
working
group
drafts
that
we
have
in
flight
and
as
time
allows-
and
I
expect
time
does-
will
allow
to
talk
about
a
couple
of
new
drafts
that
that
john
is
asking
us
to
take
a
look
at
we're
going
to
start
with
the
status
of
the
dress
that
we
have
past
pub
wreck.
Does
anybody
have
anything
else
that
they
think
we
need
to
be
talking
about
during
today's
session.
D
F
B
B
Do
it
it's
not
important
enough
to
warrant
a
slide,
but
if,
if
there's
a
slide
to
get
out,
so
I
mean
the
long
and
short
of
it
is
as
most
pure
rare,
ob
and
div,
they
seem
like
a
distant
memory.
These
are
things
that
we
did
like
you
know
in
the
dark
ages.
Long
long
ago,
speaking
of
dark
ages,
I
should
probably
turn
my
lights
on
alexa
turn
the
office
lights
to
white,
but
those
drafts
actually
are
with
the
isg
and
both
are
passed
past
the
isg.
B
At
this
point,
I
think
I
agreed
to
allow
div
to
block
until
ob
has
an
rfc
number,
because
div
does
refer
to
ob,
and
so
really
it's
just
waiting
on
ob,
which
is
waiting
on
one
last
bit
of
adventist
trivia,
so
that
should
be
done
extremely
quickly.
Yes,
that's
a
slide
delegation.
Whoever
does
have
some
outstanding
issues.
This
is
still
an
isg
review
and
ben
sent
quite
a
laundry
list
of
comments
on
it,
which
are
good
comments,
actually
really
only
two
of
them.
B
I
think
that
I
would
bring
to
the
attention
of
the
working
group
in
case
people
here
would
like
to
discuss
them
a
bit.
One
of
them
is
we
kind
of
floated
this
notion
in
the
delegation
draft
that
you
could
sign
a
passport
with
your
ca,
sir.
In
other
words,
if
we
get
an
intermediate
cert
for
the
purpose
of
doing
delegation,
we
floated
hey.
You
know,
there's
really,
no
reason
you
should
have
to
make
any
ease
or
to
sign
a
passport
ben
flagged
that
and
it's
like.
B
And
I
mean
this
is
something
that
came
about
back
in
the
day,
because
people
expressed
some
concerns,
and
the
second
bullet
here
relates
to
that
as
well
about
having
to
manage
a
lot
of
keys
at
their
authentication
service
and
like
just
having
to
manage
a
lot
of
keys
in
general.
There's
a
consequence
of
that.
B
You
know
I
kind
of
looked
at
this
squinted
at
it
a
bit
and
was
like
I'd,
be
willing
to
float
that
as
a
possibility
that
you
can
just
sign
passports
with
with
a
certificate
that
has
a
ca
boolean
set
to
true.
That
means,
of
course,
they
would
live
where
your
authentication
service
lives
and,
like
a
lot
of
times,
we
think
of
a
ca
cert,
we
think
of
it
in
an
iron
mountain.
B
I
guess
I
look
at
the
starts
for
delegation
as
being
a
bit
less
protective
than
those
in
part
because
much
like
with
rpki
right.
They
have
this
encompassing
semantics
and
so
there's
ways
to
kind
of
limit
what
you
can
issue
certificates
for
and
kind
of,
the
worst
thing
you
could
do
if
you
had
like
access
to
that
as
issue
a
certificate
for
some
subset
of
the
permissions
that
the
entity
that
was
granted.
B
This
particular
intermediate
cert
has-
and
so
you
know,
I'm
kind
of
on
the
fence
about
this,
because
it's
something
I
floated,
I
don't
know
if
anybody's
actually
use
it
like
in
the
discussions
we're
having
about
delegation
and,
like
you
know,
addis
and
the
shaking
ecosystem.
For
example,
it's
not
clear
that
people
are
like
jumping
at
this
chance.
It's
really
something
like
I
said.
We
floated
because
people
just
want
to
have
less
keys.
Does
anybody
feel
strongly
about
this
either
way
rusty?
Do
you
think
this
is
terrible
and
we
should
like
stop
and
not
do
it.
C
B
B
Yeah-
and
I
mean
kind
of
my
my
intuition
ben
suggested
some
language
that
I
think
improves
it
a
bit
and
kind
of
talks
about
more
about
the
option
of
putting
you
know,
generating
an
ease
or
off
of
that
intermediate
serve,
which
is
fine
with
me.
Let
me
go
with
that
and
be
okay,
and
is
there
anybody
else
on
that.
F
B
You
have
to
make
another
instrument
with
permissions,
identical
to
the
permissions
of
your
intermediate
cert,
and
you
have
the
easer
you
made
from
it
to
sign
your
passports,
got
it
yep
and
like
again,
we
introduced
this
just
because
people
I
mean
you
know,
I'm
thinking,
martin
among
others.
Back
in
the
day
like
was
like,
we
can't
have
too
many
too
many
certs,
like
I
don't
have
this
key
ring
or
whatever,
and
so
like.
This
is
one
of
the
things
that
pushed
us
to
say
consolidated.
B
B
B
So
nobody
nobody's
yelping-
I
I
think
I'll,
probably
push
back
to
ben
and
say
we'll
keep
it
and
we'll
put
in
some
language
some
better
language
about
the
alternative
which
he
proposed.
The
second
issue
here
is
about
cross
certification,
about
aggregating
permissions
from
multiple
asserts
same
justification
precisely
the
same.
B
Aka!
That's
kid
ordering
is
very
deterministic
much
more
so
than
ordinary
path,
construction
you
might
perform
to
try
to
get
back
to
a
particular
trust
route,
but
once
you
start
throwing
cross
certification
into
that,
even
if
you
have
a
single
route,
even
if
you
have
like
a
shaken
like
you
know,
rude
you're
still,
potentially
gonna
run
into
some
middle
path,
construction
issues
that
are
weird-
and
so
you
know
we
could
it's
it's
tendered
really
in
an
exploratory
way
in
the
draft,
it's
kind
of
like
hey.
B
If
you
wanted
to
do
this,
you
could
probably
you
know,
use
aia
to
do
it
and
I
think
it's
probably
okay
to
do.
There's
no
normative
language
surrounding
any
of
this
is
it.
This
is
in
one
of
these
paragraphs.
It's
like,
if
you
felt
like
it,
you
could
go
down
this
path,
so
I
mean
I,
I
think,
we're
probably
okay
to
keep
it
if
we
want,
but
anybody
having
strong
feelings
about
that.
We
need
to
clarify
this
before
we
can
proceed
with
the
document.
C
It
is
kind
of
complicated
and
ugly.
I
think
penn
was
right
to
flag
it.
Do
you
really
mean
to
do
this
because
you're,
basically
taking
two
different
branches
in
the
middle
of
your
pki
and
pulling
them
together
at
the
leaf
and
yeah,
and
the
cost
to
the
signer
is
that
they
just
have
to
pick
the
correct
leaf?
If
you
don't
allow
this
bowing
and
that
isn't
an
awful
thing
either,
and
it
may
actually
force
the
signers
to
be
a
little
more
cleanly
than
they
might
otherwise
be.
B
B
I
think
it's
more
realistic
that
people
might
have
like
five
and
a
lot
of
people
just
have
like
one
or
two.
You
know
I.
I
don't
think
there's
that
many
entities
that
aren't
effectively
carriers
and,
of
course
you
know
the
shakiness
ecosystem
is
transforming
in
terms
of
how
it
deals
with
some
of
these
non-carrier
entities.
At
this
point,
that's
something
that's
like
changing
this
week,
so
I
mean
you
know
I
I
I
think
I'm
okay
tell
them
if
we,
if
we
want
to
take
that
out.
F
B
F
C
G
B
C
A
C
A
F
Okay,
rcd,
I'm
sort
of
combining
this
with
the
sip
core
stuff,
which
is
you
know,
there's
no
meeting
and
all
the
relevant
people
are
probably
here
anyways.
So
you
know
we're
sort
of
pretty
much
still
at
the
point
where
it's
mostly
editorial,
updates
coming
in
most
of
it
related
to
clarification
on
the
zip
core
call
info
stuff,
since
we
made
that
a
a
pretty
tight
dependency.
F
F
F
F
F
Yeah,
so
for
call
info
one
question
that
came
up
and
I
wasn't
sure
how
to
handle
this
actually
was
that
if,
if
we
only
had
name
and
call
reason
but
no
j
card,
so
in
other
words
no
real
url,
that
could
be
pointed
to
and
call
info
the
first.
The
first
thing
is
the
url:
does
that
mean
we
really
should
be?
F
We
we
made
call
reason
a
parameter
at
the
end,
and
should
we
really
have
made
it
that
we
have
to
use
the
same
cid,
cid
style,
link
in
to
the
body
for
call
reason
also
so
just
curious.
If
anyone
has
any
opinion
there,
I'm
sort
of
thinking,
I'm
not
sure,
there's
any
way
to
avoid
that
but
curious.
If
people
have
any
thoughts
there.
B
B
A
I
think
that
we
not
that
we
know
of
any
real
uses
of
subject
in
the
field.
I
think
that
the
the
the
co-opting
of
it
would
likely
run
into
it.
Would
it
would
close
doors
in
other
places,
that
with
a
weird
side
effect-
and
I
don't
think,
that's
really
what
we
want
to
do
so
it
may
be
3
30
in
the
morning
talking,
but
the
what
about
just
jamming
all
this
stuff
into
a
data
uri
in
the
since
you
can
already
carry
a
uri
in
that
header.
B
Just
did
it
data
your
eyes
are
never
my
personal
favorite
kind
of
a
pet
peeve
of
mine,
but
you
know
this
might
be
the
time
time
has
come.
For
that
I
mean,
I
think,
the
the
only
reason
why
I'm
not
just
saying,
like
you
know
some
kind
of
quoted
string
that
we
pack
into
the
call
info
header
should
suffice,
even
if
we
don't
parameterize
it
in
some
fashion.
B
Is
I
think
the
argument
we've
mostly
made
but,
like
I
can
imagine
other
kinds
of
structure
as
well,
that
might
make
it
look
more
like
a
body
at
the
end
of
the
day,
you
know
more,
like
you
know,
an
xml
document
or
json
document
that
contains
information
that
is
separated
out
into
segments
for
display
purposes,
and
you
know
that's
one
of
the
things
just
just
trying
to
create
something
that
at
least
leave
us
the
opportunity
to
do
that.
It's
one
of
the
reasons
why
I've
looked
at
it
as
being
kind
of
independent.
B
F
F
F
Yeah,
so
I
think,
might
be
worth
having
another
round.
Hopefully
you
know,
but
we
do
do.
We
do
want
to
sort
of
knock
this
out.
People
are
hopping
on
on
this
bandwagon
pretty
quickly
so
but
like
I
do
want
to
solve
like
some
of
these
fundamental
issues
before
we
start
talking
about
working
with
class
call.
A
A
B
So
this
is
a
document
that
is
examining
doing
ob
from
more
constrained
environment
places
where
you
assume
that
cps
is
not
a
third-party
service,
but
instead
something
that
is
actually
in
the
call
path
enough
that
it
already
sees
the
called
and
calling
party
numbers
and
it's
either
operating.
You
know
it's
operated
by
the
virginia
terminating
domain
or
kind
of
on
behalf
of
it,
and
there
are
gateway
cases
parallel
to
that.
B
We'll
talk
about
a
bit
as
well,
but
this
is
something
that's
becoming
an
increasing
subject
of
interest,
because
a
lot
of
people
are
coming
up
against
this
wall
that
their
tdm
providers
exist.
People
are
trying
to
figure
out
how
to
accommodate
them,
and
so
this
is
a
version
that
is
trying
to
solve
the
fundamental
problem
of
dealing
with
tdm
without
having
to
have
a
third
party
service,
you
treat
as
an
adversary,
be
the
call
placement
service,
as
we
stipulated
in
the
original
out-of-band
rfc
next
slide.
B
That's
the
crucial
component
of
it,
so
that
enables
transit
providers
to
participate
as
gateways,
and
there
are
a
variety
of
mechanisms
that
are
under
consideration
for
how
cpss
can
discover
one
another.
There
has
been
a
lot
of
conversation
at
us
recently
about
kind
of
having
a
federated
cps
that
you
know
uses
some
kind
of
like
gossip
protocol
or
something
to
share
passports
between
cpss
that
are
all
mutually
participating
to
provide
a
service
to
the
entire
ecosystem
as
all
enrolled
in
trusted
entities
that
are
kind
of
independently
vetted
and
accountable.
B
This
is
entirely
the
wrong
deck.
I
don't
know
how
I
ended
up
sending
this,
but
so
what
I
think
I
said
in
my
previous
one
is
there's
more
work
that
needs
to
be
done
to
align
with
this.
This
is
something
that
is
literally
changing
like
this
week.
I've
been
on
a
bunch
of
calls
about
this
this
week,
and
so
you
know,
I
I
think,
there's
we're
gonna
have
to
wait
another
cycle
before
we're
actually
able
to
really
kind
of
start
talking
about
advancing
the
document
beyond
this
at
least
another
cycle.
B
B
H
B
B
B
There
are
things
about.
You
know
that
approach
that
I
don't
think
it
would
be
appropriate
for
us
to
specify
in
the
it
apple
put
it
that
way,
but
I
mean
I
think
we
want
to
make
sure
that
we're
articulating
why
we
think
this
is
a
plausible
security
environment,
and
you
know
kind
of
what
some
of
the
design
choices
are,
that
you
have
when
you
go
down.
Some
of
these
paths
make
sense.
F
F
And
I
have
some
examples
below
that
that
show
that
so
and
you
know
the
document
I've
updated
pretty
much
for,
I
think
all
the
scenarios
that
would
actually
happen,
but
I
think
there
was
one
more
example.
Maybe,
but
you
sort
of
get
the
point
there.
Yes,
the
zip
priority.
Header
stays
the
same
for
the
psap
callback.
F
F
No
okay,
yeah,
that
was
the
major
change,
so
I
think
you
know
we're
already
headed
down
the
path
in
working
group
last
call,
so
I
don't
think
that
needs
to
change.
I
assume
you
know,
like
maybe
I'll,
pause,
to
get
any
comments.
If
anybody
has
anything
to
say
about
that
change,
but
I
think
I've
pulled
most
of
the
people
that
care
about
this
subject.
So.
F
A
F
A
F
H
F
A
D
Good
my
draft
through
sip
core,
but
that
this
draft
is
not
dependent
on
that
it
can
and
reference
the
thing
it
doesn't
reference.
What
I
have
so
that's
just
motivation
and
and
there'll
be
a
sip
core
mechanism
thing
because
there's
a
change
that
this
draft
introduces
so
there's
no
there's
no
dependencies
on
the
this
draft
does
not
have
it
at
penn
state.
On
that.
B
All
right
all
right
so
now
we're
getting
the
exciting
stuff
so,
rather
than
just
updates
of
things
that
we're
talking
about
each
time.
This
is
one
we
haven't
talked
about
in
a
while.
I
think
we
last
talked
about
this
actually
itf
101,
but
there
was
a
new
version
of
it
last
time
that
we
did
not
discuss
and
there's
another
new
version
of
it
this
time
this
is
connected
identity.
B
B
I
mean
the
basic
classic
problem
that
4916
explored
was
the
problem
of
what
happens
when
you
connect
to
some
unanticipated
target
of
a
sip
request,
and
it
needs
to
use
the
identity
header
when
it
sends
an
update
request
in
the
backwards
direction
to
affirm
its
identity,
but
that's
not
the
identity.
You
actually
expected
to
see
and
the
way
that
dialogue
matching
works
and
sip
you're
supposed
to
have
the
same
from
header
field.
Unless
you
have
this
new
thing
that
he
put
in
it's
called
a
change
from
that.
B
You
know,
allows
the
terminating
side
to
be
able
to
send
back
its
own
address
of
record
in
the
front
header
field
in
something
like
an
update
request,
which
is
pretty
cool,
and
so
we
need
something
like
that.
That's
going
to
work
with
4474
as
well.
It's
just
in
general
principle.
It's
probably
a
good
idea
for
us
to
articulate
what
you
do
in
that
circumstance.
B
There
are,
unfortunately,
a
number
of
attacks
that
arise
in
mobile
networks
and
as
well
if
the
horizon
is
kind
of
any
ip
network
that
doesn't
use
pstn-style,
tn
routing,
where
you
could
end
up
with
an
attacker
who
somehow
manages
to
you
know,
respond
to
a
dialogue
that
you
started
and
like
the
route
hijacking
this
and
the
mobile
networks.
Is
that
probably
the
most
famous
case
like
it?
So
I
mean
I,
I
there's
actually
security
vulnerability.
B
We
think
that
you
address
with
that
alone,
but
then
there's
this
whole
class
of
attacks,
like
you
know,
short
stopping.
This
is
an
attack.
That's
in
international
mobile
networks,
especially
where
untrusted
intermediate
or
transit
networks,
kind
of
make
one
side
of
the
call
think
that
the
call
is
terminated
but
convince
the
other
side
that
it's
still
ongoing
in
order
to
do
a
kind
of
toll
fraud-
and
you
don't
you
do
this
for
just
like
a
couple
seconds.
But
you
know
you
do
this
for
like
a
lot
of
calls.
B
If
anybody
wanted
to
actually
use
sip
to
negotiate
and
then
be
security,
full
stack,
we'd
need
something
like
this
to
work
as
well,
and
the
ciprandi
documents
do
note
that
now
the
kicker
is,
of
course,
this
does
take,
stir
a
bit
past
the
threat
model
of
7374
of
7375,
and
also
you
know
the
stir
problem
statement
which
articulates
that
we're
here
to
beat
things
like.
You
know,
robocalling,
which
is
really
just
about
the
initial
invite
that
establishes
dialogue,
and
so
we
kind
of
have
to
be
cognizant
if
we're
taking
this
on.
B
We
are
kind
of
changing
the
scope
of
what
we're
discussing,
but
I
think
it
is
a
natural
extension
to
the
practices
that
are
articulated
in
age.
24
that
you'd
be
able
to
sign
requests
other
than
an
invite
with
an
identity
header
it
just
it's
gonna
happen
and
we
might
as
well
kind
of
bite
the
bullet
and
figure
out
how
to
do
it.
So
next
slide.
B
So
I
mean
a
good
question
is
like
how
useful
practically
is
this.
You
know
an
authorization
decision
that
you
make
after
a
call
has
connected
after
you've
already
gotten
the
200.
Okay
is
obviously
of
somewhat
limited
utility
and
arguably
even
like
an
authorization
decision
you're
making,
while
the
call
is
alerting
like
if
you're
holding
you
know
your
phone
to
your
head,
and
you
know
it's
trying
to
show
you
something
about
who
it
is
you've
connected
to.
B
That's
probably
not
terribly
useful,
but
it
is
something
that
we
could
treat
much
the
same
way
as
we
treat
you
know:
a
failure
of
negotiating
srtp,
for
example,
where
the
king
isn't
successful.
Like
you
know,
media
just
isn't
passed
and
I
could
imagine
implementations
that
would
actually
you
know
if
during
alerting
you
get
back
an
update
in
the
backwards
direction
that
contains
you
know
new
identity,
it's
not
who
you
expect
or
there's
something
broken
about
it
that
that
would
you
know,
cause
you
to
not
allow
media
to
flow
to
the
user.
B
B
I
want
it
to
fail
if
I'm
not
reaching
the
entity
that
I
intended
to
reach-
and
you
know
we're
not
going
to
dictate
user
experience
in
this
draft,
but
I
think
it's
worth
at
least
articulating
what
some
of
the
options
are
and
what
you
could
achieve
with
this
assurance
and
I've
always
been
fascinated.
I
mean,
since
we
first
started
thinking
about
this
by
what
you
could
do
before
the
call
even
starts.
B
You
know
negotiating
like
a
medialis
session.
For
example,
when
you
have
your
address
book
contact
or
when
you
know
that
exact
moment
when
you're
clicking
on
the
link
and
that
sms
that,
oh
so
trustworthy
sms,
you
got
that
claims,
it's
bank
of
america
there's
a
number
in
there
and
you
click
on
it.
What
happens
then?
What
gets
displayed
to
you
before
you
then
press
the
confirmed?
B
I
want
to
call
that
that's
an
example
of
a
place
that
a
hook
could
exist
to
something
that
negotiates
the
media's
mediala
session,
make
sure
you're,
seeing
the
right
key,
the
other
side
that
no
funny
business
is
going
on.
So
I
mean
there's
a
bunch
of
things
like
that.
I
think
that
we
could
at
least
provide
hooks
for
that
implementers
could
dig
into
next
slide.
Oh
or
you
want
to
talk
to
us.
F
I
was
just
gonna
say
that
that
is
to
me
one
of
the
more
important
cases
for
sure
in
terms
of
you
know
like
in
you
know
you
you,
the
right
thing,
I
think,
is
from
a
user
experience
point
of
view
like
like
that's
most
critical,
and
I
I
think
thinking
about
how
we
can
make
that
work.
You
know,
maybe
even
without
having
to
come,
have
complete.
F
You
know
the
the
question
is:
can
that
work
across
all
use
cases
or
like
existing
call
flows
could
support
that
somehow,
like
you
know,
so
that
you
can
more
globally
deploy
this
without
having
to
have
everyone
supporting
it?
I
think
there
might
be
some
techniques
to
think
about
there,
but
but
yeah.
I
just
wanted
to
give
my
plus
one
to
that
use
case
specifically.
B
Yeah,
it's
cool
use
case
I
mean
I,
I
think
the
best
we're
going
to
be
able
to
do
is
create
some
books.
Like
I
said,
and
you
know
we
define
the
way
the
protocol
can
support
this.
You
know
people
that
are
in
a
position
implementing
we'll
implement
that
I
mean
you
know.
I
don't
know
how
much
prac
and
update
and
things
like
that
are
practically
used.
You
know
in
like
the
ipn
and
I,
for
example,
grass.
A
B
Yeah,
it's
a
it's
a
fair,
fair
cop.
I
mean
the
user.
Experience
may
be
one
where
you're
not
gonna,
have
a
ton
of
alerting
time
for
a
variety
of
reasons.
I
saw
you
mention
183
and
the
jabber
I
mean
I
I
think
you
know
it
really
comes
down
to
if
you
have
a
criticality
for
a
particular
call
and
you're
expecting
to
see
that
update
in
the
backwards
direction
that
is
signed
has
a
passport
in
it.
And
if
you
don't
see
that
you
know
you,
you
want
the
user
to
stop.
B
B
A
You
could
just
you
could
start.
I
mean
down
that
path.
You
you
you've
got
to
have
something
to
crack
right,
oh
right,
right,
right
right!
So,
but
anyhow,
that's
it's
just
something
to
talk
to
to
to
consider
in
in
the
the
set
of
attacks
that
you're
trying
to
protect
against.
If
the
industry
practice
is
still
to
leave
the
call
in
that
alerting
state,
it's
going
to
be
hard
to
apply
the
protection.
B
Is
this
something
you
think
is
interesting
enough
that
we
want
to
potentially
adopt
this
and,
like
start
work
on
it
here,
because
this
is
really
the
first
time
that
I
think
we've
had
enough
of
a
statement
of
what
this
is
and
how
it's
supposed
to
work
to
articulate
like.
Should
the
working
group
adopt
this
or
not?
B
B
B
There
are
a
couple
of
things
as
well,
like
you
know
something
we're
doing:
sip
brandy
that
adam
roach
flagged
then
about
how
kind
of
the
resending
mechanisms
that
we
put
into
8224
work
for
cases
where,
like
there's,
a
failure
of
the
structure
perceived
by
the
other
side
and
so
on,
like
there
are
things
like
that,
we
would
just
have
to
reconcile
with
4916,
but
I
don't
think
it's
a
terribly
heavy
lift
to
get
there.
And,
of
course
all
the
examples
need
to
be
redone
and
everybody
knows
people
just
go
to
the
examples.
B
B
Yeah,
that's
it
so
I
guess
the
question
really
posing
is
you
know?
Is
this
an
idea
whose
time
has
come?
Do
we
think
that
it's
worth
looking
at
this
and
you
know,
if
so
happy
to
do
some
more
work
towards
it
and
kind
of
start
looking
at
putting
together
new
examples,
and
you
know
fixing
some
of
the
things
that
adam
was
talking
about?
But
you
know
my
real
question
is:
is
this
something
we
think
we
should
adopt?
Is
this
a
interesting
area
to
work
in.
A
C
A
Some
more
support
and
and
and
fish
for
people
that
think
that
there's
a
problem
with
us
pursuing
this
murray.
When
you
have
time,
could
you
take
a
look
at
what
we're
doing
and
make
sure
that
you're
comfortable
that
we
pursue
this
under
our
current
charter,
which,
as
john
mentioned,
it
walks
us
a
little
bit
out
of
the
the
the
box
that
we
originally
laid
out?
C
B
A
B
E
C
B
Stir
for
messaging
okay,
I
can
muster
enough
energy
to
do
just
this
last
one
all
right,
so
yeah
start
from
messaging
next
slide,
pretty
exciting
new
idea,
new
work,
new
draft
completely
new,
not
something
we're
recycling
from
itf
101.
This
is,
in
fact
an
entirely
new
draft
about
leveraging
stir
for
text
and
multimedia
instant
messaging
services.
B
We
think
this
is
obviously
most
applicable
to
services
that
happen
to
use
telephone
numbers
as
their
originating
identifier,
and
you
know
the
reason
why
we
think
this
is
important.
These
days
is
because
message
spam
is
becoming
a
much
much
bigger
problem
all
the
time
and
I'm
sure
that
every
step
we
take
that
makes
voice
spam
harder
will
make
message
spam
more
attractive.
B
There
are
certainly
a
class
of
entities
today
that
are
pretty
good
at
doing,
like
bayesian
analysis
of
the
contents
of
these
things
to
try
to
pick
up
spam
patterns,
but
there's
also
this
trend
for
encrypted
messaging,
which
seems
to
just
get
more
and
more
traction
every
day.
I
think
I
just
saw
something
about
like
the
entire
google
system,
moving
to
their
rcs
system
into
encrypted
messaging.
Things
like
that.
B
Is
there
something
we
want
to
say
about
what
the
interaction
is
both
with
age,
26
and
h,
224,
with
with
messaging
of
course,
as
with
many
phishing
expeditions
like
this,
you
know,
there's
not
a
ton
of
like
messaging
providers
on
the
call
at
the
moment-
and
you
know
the
this.
This
is
not
a
slam
dunk
in
terms
of
the
overlap
of
some
of
the
crucial
entities
who
are
performing
those
functions
and
people
are
getting
stir
starts
today,
who
are
at
least
responsible
for
the
messaging
applications
for
the
telephone
numbers
in
question.
B
B
So,
there's
stuff
that
we
basically
get
for
free
like
pretty
much
all
session
based
messaging,
we
pretty
much
get
for
free
because
it's
just
negotiated
with
sep
right
as
a
session.
These
are
things
like
msrp
or
text
over
rtp
and
as
a
consequence
of
that,
you
know
pretty
much.
You
should
be
able
to
stick
an
identity
header
and
the
invites
that
are
setting
those
things
up,
and
you
know
with
a
few
little
questions
like
okay,
like
how
does
m
key
interact
with
that.
B
You
know
maybe
some
things
about
how
some
of
the
particular
extensions
to
passport
might
interact
with
it.
Those
things
just
kind
of
work,
I'd
like
to
think-
and
you
know
we-
we
kind
of-
have
a
scope
question
around
this.
You
know
we
could
literally
restrict
what
we're
talking
about
in
this
document
to
just
messaging
from
phone
numbers,
though
I
know
that
again,
age
24
really
is
broader
than
telephone
numbers.
B
It
just
happens
that
the
8226,
the
star
certificates,
that
we
define
are
pretty
focused
on
telephone
network
identifiers,
but
it's
never
our
intention
that
the
identity
mechanism
would
be
restricted
literally
to
use
of
telephone
numbers.
So
I
mean
that's
one
thing
we
kind
of
have
to
negotiate
out
as
we
did
this,
but
you
know
at
least
the
nesting
from
numbers
part.
I
think
it's
pretty
straightforward
to
see.
You
know
what
we
get
for
free
from
that
next
slide.
B
And
then
there's
like
low
hanging
fruit,
like
you
know,
as
I
said,
we're
probably
gonna
have
to
start
thinking
about
ways.
Identity
headers
can
be
integrated
into
most
types
of
sip
requests.
You
know
things
like
buys
things
like
updates,
and
then
we
have
a
message
method.
It's
not
used
a
tremendous
amount,
but
again
in
the
low
hanging
fruit
category.
It's
pretty
easy
to
imagine
how
you
could
apply
passport
to
something
like
the
message
method
and
the
basic
way
that
we
talk
about
doing
this
is
by
having
a
new
claim.
You
add
the
passport.
D
B
Okay,
good
yeah,
and
I
I
think
this
one's
pretty
pretty
straightforward
right,
just
whatever.
However,
the
message
is
being
encoded
in
the
body
just
to
have
your
integrity
check
over
with
message
I
and
like
pretty
much
once
you've
created
a
passport
that
has,
you
know,
message
eyes
a
claim
and
a
new
passport
type
to
go
with
it.
You
can
kind
of
imagine
like
a
lot
of
non-set
cases
where
you
might
be
able
to
glom
a
passport
onto
something
so
next
slide.
B
Okay,
if
you've
drunk
all
of
the
kool-aid
so
far,
you
agree
that
it's
probably
worth
at
least
articulating.
Okay,
there's
stuff
we
get
for
free,
there's
some
something
they're
pretty
easy
to
do.
Like
you
know
the
this
is
this
is
the
the
hard
version,
the
things
that
we
would
kind
of
add
onto
the
scope
and
see
if
we
could
accomplish
we're
going
to
do
this,
I
mean
we
could
look
at
things
like
xmpp
right.
B
B
I
suspect
that
probably
it'll
be
of
more
value
for
us
to
create
a
framework
that
it's
just
easy
for
non-sip
systems
to
leverage
than
it
would
be
to
really
kind
of
try
to
go
through
every
protocol
and
say,
like
you,
know,
here's
how
passport
work
with
that
there's
going
to
try
to
be
a
lot
of
proprietary
ecosystems
that
just
have
their
own
security
and
are
doing
it.
Fine,
like
you
know,
I
I'm
not
sure
how
much
value
imessage
is
going
to
get
from
this.
B
You
know
I
don't
really
follow
mls
much
here
I
mean
I
mean
maybe
like
russ
or
somebody
like
follows
it
more
than
me.
But,
like
you
know,
mls
integration
is
another
thing
we
could
potentially
look
at
because
it
it
is
in
fact
a
framework.
As
far
as
I
understand
that
a
lot
of
different
messaging
systems
are
going
to
use
as
their
underpinning
and
we
might
be
able
to
help
provide
like
an
authentication
service
to
mls
chris
did
you
have
a
note.
F
Yeah
sort
of
related
to
mls,
I
was
watching
the
s
frame
stuff
and
they
were
talking
about
associating
participants
with
each
media
stream,
and
you
know
that
sort
of
cries
out
for
a
framework.
I
I
I
don't.
I
think
going
to
the
media
stream
is
a
pretty
going
step
too
far.
So,
like
you
know,
at
the
signaling
layer,
whatever
that,
if
you
know
whatever
that
turns
out
to
be
for
an
application
that
uses
s
frame,
it
should
probably
incorporate
this
framework.
So
just
another
example
sure.
B
Again,
so
it's
really
more
just
kind
of
where,
where
you
know
this
is
the
question
of
where,
where
things
would
take
work
right,
so
we're
kind
of
looking
for.
Are
there
any
places
that
we
could
try
to
plug
into
in
the
itf
that
we
want
to
plug
into
that?
We
think
would
be
sailing
to
this
not
necessarily
shopping
for
much
there,
but
I
mean
I
think,
having
just
a
generic
description.
Imagine
we
do
like
the
message.
I
think
we
just
described
having
some
kind
of
a
framework
that
says.
B
Okay,
if
you
wanted
to
apply,
you
know
passports
with
message
eye
to
your
proprietary
or
you
know
open
messaging
system.
Here
are
some
guidelines.
You
know
here's
the
kind
of
credentials,
you'd
use
yours,
you
know
et
cetera,
et
cetera,
and
so
I
mean
we
could
do
something
like
that
and
then
it's
just
kind
of
up
to
the
community.
If
people
think
it's
worth
integrating
that
in
with
anything,
I
think
we
might
actually
get
some
takers
just
because
so
many
carriers,
enterprises
and
you
know,
systems
out
there
are
just
going
to
have
the
store
credentials
anyway.
B
B
B
G
Intellectually,
I
really
like
this-
I
mean
I,
I
have
a
soft
spot
for
msrp
and
message
and
would
love
to
see
anything
to
add
security
to
them.
The
reservation
I
have
for
messaging
systems
in
general,
I
posted
in
the
chat
earlier
with
you.
I
saw
the
google
announcement
about
doing
end-to-end
encryption
in
rcs
and
if
you
dig
down
in
technical
paper,
they
it
seems
to
say
they're,
using
the
signal
protocol
which
yeah
to
me
with
the
mls
direction.
G
In
the
long
run-
and
I
also
you
know
hope,
someday
to
see
things
like
rces
and
imessage
integrate
and
wonder
if
they
would
use
something
like
this
or
if
they
would
go
more
down
the
mls
mls
line,
and
you
know
maybe
just
then
point
to
point
two
person.
You
know
one,
not
group
messaging,
whatever
you
call
the
opposite
of
group
messaging
mls
might
be
too
heavy
weight
for.
I
don't
know,
but
that's
my
concern
about
whether
it
will
get
used
in
the
general
case.
F
This
is
chris,
I
think
you
know,
certainly
as
it
relates
to
telephone
number
associated
things.
You
know
and
sort
of
the
industry
connections
we
have
with
star
shaken,
like
I
think,
and
those
certificates.
You
know,
it'd
be
nice
to
have
a
common
framework.
So
I
think
that's
part
of
the
reason
for
for
doing
this.
One
other
thought
I
thought
I'd
bring
up,
which
goes
back
to
the
last
draft
we
talked
about
with
connected
identity.
Is,
you
know,
like
you,
obviously,
don't
want
to
send
rcd
information
in
every
message.
F
You
know
that
would
be
a
lot
of
overhead.
So
should
there
be
more
of
a
framework
of
using
getting
the
person,
you're
taught
you're
chatting
with
their
information
via
some
connected
identity
mechanism
at
the
beginning
or
as
part
of
your
address
book,
or
you
know
all
those
use
cases
and
then
that
sort
of
ties
in
with
the
same
credentials,
for
you
know
the
messages
that
are
being
sent-
and
you
know
again
a
broader
framework
here
for
for
identity
in
general,.
C
D
I
I
need
this
bad
enough
that
I
don't
want
to
get
bogged
down
in
general
frameworks
getting
beyond
message.
Msrp
things
you
do
with
sip,
so
I'm
a
little
concerned
that
it'll
take
two
or
three
years,
because
we're
doing
all
this
generic
use,
use
it
outside
of
sip
and
and-
and
my
simple
use
case
will
be
waiting
for
all
of
that.
So
I.
H
B
B
We
need
some
typing
of
messages
in
order
to
you
know,
give
different
profiles
for
how
the
hash
is
generated,
and
I
mean
I
know
even
like
smvp
there's
like
there's
different
versions
of
it
right
and
like
there's
like
a
bunch
of
it.
Just
there's
like
a
bunch
of
craft
is,
I
guess,
the
issue
around
how
these
messages
are
structured,
and
so
I
mean,
I
think,
that's
the
only
thing
we
actually
need
to
resolve
for
that
to
be
stable,
and
you
know
the
general
framework
thing
I
mean
yeah.
B
D
H
B
Well
and
there's
some
text
in
the
document
already
about
out
of
band,
and
that
text
already
says
you
know
the
the
most
obvious
thing
you
could
say
about
the
interaction
of
messaging
and
ob,
which
is
if
you
have
an
internet
stream
that
lets
you
deliver
passports
and
you
can't
deliver
instant
messages
over
it
like
this.
Isn't
a
voice
call
like
you
know,
they're
what
what
aberrant
condition
exists,
such
that,
like
you,
you
know,
can't
you
know,
integrate
the
passport
in
with
whatever
message:
you're
you're
sending
along,
and
so
I
mean
yeah.
B
F
F
B
A
D
Yeah
I
mean
I
I
I
to
be
honest:
we
plan
to
just
do
it
anyways
right,
because
message
is:
can
have
an
identity
header
and
you
know
it
doesn't
need
to
be
invite
and-
and-
and
so
we
just
assumed-
we
could
just
do
it
for
for
the
for
for
a
message.
So
we
have
in
the
north
american
emergency
number
nina
specs
explicit
text
now
about
their
about
verification,
for
incoming
emergency
calls,
and
we
assumed
that
we
could
apply
it
to
message
exactly
the
same.
D
There
are
equivalence,
outgoing
right,
so
think
of
an
incoming
text.
That
again
is
might
be
nsrp,
so
that
was
something
we
haven't
really
thought
through,
but
we
do
use
msrp
for
instant
messaging
and
and
but
we
set
that
up
with
sip.
So
you
know
again,
we
we
we
assumed
that
we
could
just
use
the
invite
use,
use
the
the
identity
coming
in
with
that
invite
to
protect
against.
We
have
the
problem
going
out
going
right.
D
B
D
Well,
so
the
emergency
services
have
the
problem
that
they
can't
realistically
implement
25
different
messaging
inputs.
So
we
we
we
go,
go
back
to
look
just
interwork
the
msrp
and
everything
will
be
fine
because
we
can't
handle
a
lot
of
proprietary
messaging.
Now
we
there's
statements
in
the
dra
and
the
in
the
standards
that
say
that
may
not
work
we
may
have
to
implement.
You
know
another
few
instant
messaging
protocols
in
order
to
get
enough
coverage
so
that
you
know
my
message
is
the
obvious.
B
D
B
D
We
we
don't
cur,
I
mean
we
don't
currently
have
a
concern
there.
I
think
anything
that
improves
integrity
of
any
part
of
the
communication
with
emergency
services
is
worthwhile.
You
know
I
I
we
we
do.
People
have
expressed
the
issue
of
you
know
all
right.
You
get
this
real
nice,
signaling
authentication
and
then
someone
crashes,
the
media
stream.
D
You
know
we
want
to
use
srtp
blah
blah
blah,
but
you
know
deployment
of
that's
pretty
pretty
limited,
so
you
know
if
it
offered
the
ability
to
do
integrity
of
better
integrity
of
messaging
and
things
like
that.
We
would
say:
oh
yes,
we'll
do
that.
I
mean
we'll
implement
that
in
a
flash,
but
not
the
primary
concern.
The
primary
concern
is
swatting
right
right.
D
B
D
B
D
Same
same
issue,
it's
the
identity,
that's
the
primary
problem.
Don't
claim
you're
from
991,
don't
be
able
to
claim
that
you're
from
9-1-1,
but
but
but
all
of
those
things
are
are
are
are
useful
and
I'd
like
to
have
it.
But
it's
it's
a
like
to
have
the
the
gotta
have
is
an
identity
protection
for
all
these
one-shot
messages,
msrp
things
like
that.
H
D
A
A
F
Sure
yeah,
I
submitted
a
draft.
I
an
individual
draft.
I
put
a
note
out
onto
the
list.
It's
called
store,
identity,
header
error
handling.
It
covers
two
main
topics,
at
least
for
now,
unless
there's
others
that
want
to
contribute
to
to
it.
The
first
one
is
a
technique
that
we
defined
in
ipni,
but
I
recalled
that
you
know
it's
not
supported
in
82
24,
which
is
the
ability
to
send
provisional
error
responses
to
signal
errors
back
to
the
authentication
service
without
terminating
the
call.
F
The
second
thing
is
related
to.
We
didn't
cover,
there's
actually
a
note
in
8224
that
that
talks
about
this
issue,
but
doesn't
propose
a
solution.
So
this
is
proposing
a
solution
to
when
you
have
multiple
identity,
headers,
and
you
have
some
that
succeed
and
some
that
fail.
What
do
you
do
in
that
situation,
which
is
becoming
more
relevant?
F
F
You
know
we
didn't
really
include
any
unique
identifiers
for
each
identity-
header,
which
is
maybe
unfortunate,
but
the
passport
itself
can
be
the
the
unique
identifier.
That's
the
proposal.
You
know
obviously
be
great
if
people
can
take
a
look
and
suggest
things
open
to
comments.
Obviously,
so
maybe
try
to
beef
up
the
document
and
if
there's
any
list
discussion
that
would
be.
That
would
be
much
appreciated.
B
That's
it.
I
agree
this.
This
is
probably
the
best
way
to
handle
this.
I
mean
you
know
I'd
rather
do
this
than
hack
like
uids,
or
something
into
passports,
that
you
know
you
correlate
and
play
with
to
figure
out
which
ones
are
broken,
and
if
you
do,
I
mean
you
know,
depending
on
which
entities
add
passports
as
they.
The
message
you
know
goes
goes
by.
You
know
it
won't
be
useful
to
everybody
to
even
see
what
those
uids
are
and,
like,
I
think,
the
only
like
you
know
reservation.
B
I
have
about
this
approach
and
it's
it's
so
minor.
I
don't
really
think
it's
we
need
to
do.
A
lot
of
work
on
is
the
div
part
is
like
you
know.
If
we
end
up
revealing
service
logic
responsible
for
forwarding
decisions
in
the
backwards
direction
like
and
connected
has
the
same
problem
by
the
way.
So
it's
not
like
unique
to
this,
but
you
know
that
that's
something
I
can
imagine
somebody
hollering
about,
but
I
mean
if
div
is
the
failure.
F
B
F
Yeah
div
might
be
an
exception.
I
mean,
I
think
we
already
have
caveats
on.
You
know
where
people
should
verify
those
things,
and
you
know
so.
I
I
do
think
there
is
thought
that
needs
to
be
put.
I
mean
the
the
more
critical
use
case
here,
for
me,
at
least
is
like
you
know,
the
shaken
identity,
header
succeeds
and
rcd
fails,
or
vice
versa,
and
you
know
those
are
the
more
critical
light
things
to
identify
and
notify
the
authentication
service
that
maybe
there's
an
issue
going
on
that
the
signature
failed
or
whatever.
B
B
Yeah
I
mean
so
this.
This
is
a
this
is
a
patch
to
824
and
specifically
to
sips,
request,
handling
and
error
response
mechanisms
and
to
the
sip
response
codes.
So
I
think
it
is
actually
specific
to
824.
to
the
broader
question.
Should
there
be
a
way
to
do
this?
If
you're
doing
out
of
band,
I
mean
that
that'd
be
great.
You
know,
I'm
certainly
open
to
ideas,
but
if
we
can
just
patch
8224
I'd
be
happy
right.