►
From YouTube: IETF106-STIR-20191118-1330
Description
STIR meeting session at IETF106
2019/11/18 1330
https://datatracker.ietf.org/meeting/106/proceedings/
A
B
C
D
E
G
A
By
now,
hopefully,
since
is
the
second
session
you've
probably
been
in
at
least
today
note
well,
please
note
the
note
well
as
we
will
be
using
it
and
the
agenda
for
bashing
the
this
was
posted
a
couple
weeks
ago,
since
it
was
posted,
Martin
asked
for
a
chunk
of
the
time
allows
section.
So
if
we're
expeditious
with
the
other
I
will
get
to
hear
about
the
emergency
services
work
any
agenda
fashion.
H
Is
that
working
okay,
I
think
that's
good
hi,
I'm
Jon
we're
gonna
talk
about
certificate
delegation
and
I
have
engineered
my
deck
this
time,
so
it
will
not
eat
the
entire
session,
as
it
did
last
time
next
slide,
please.
So
what
is
this?
This
is
a
working
group
item
on
certificate
delegation
and
it
sets
out
to
explain
exactly
how
delegation
works.
I
mean
there's
some
language
in
80
to
26.
H
That
says
you
can
like
create
delegations
and
they
can
have
like
child
certs
on
parent
certs
and
they
can
inherit
some
of
the
permissions
that
these
parents
arts
possessed,
but
it
didn't
really
spell
out
much
of
the
mechanics.
What
that
meant
have
like
an
a
s
and
BS
deal
with
certificates
like
that,
so
this
is
really
just
trying
to
explain
something
we
hinted
at
in
82
26,
but
didn't
actually
explain.
H
H
This
could
work
as
well
for
like
end-user
--is--
cases,
one
common
one
that
comes
up
is
like
the
doctor's
office
case
where
the
doctor
wants
to
be
able
to
like
spoof
the
main
number
of
a
medical
facility
from
his
cell
phone,
and
maybe
an
individual
sir,
could
be
kind
of
delegated
to
his
phone
or
something
that
would
let
him
do
it.
There's
like
possibilities
for
that,
but
that's
not
really
what
we're
talking
about
at
this
point
next
slide.
H
Guess
we're
using
this
document
is
a
place
to
make
sure
we
explain
what
what
the
hell--
supposed
to
mean
if
you
actually
have
OC
ends
and
telephone
numbers
in
a
bucket,
in
a
single
certificate
and
based
on
the
design
from
long
long
ago.
That
rests
out
that,
with
back
in
the
day,
permissions
are
added.
If
what
that
means
is
like,
you
know,
if
it
contains
two
OC
ends,
what
that
doesn't
mean?
H
Is
it's
the
intersection
of
the
telephone
numbers
that
they
support
that
it's
this
particular
certificate
is
authorized
to
sign,
for
it
is
the
superset
of
all
the
telephone
numbers
covered
by
those
two
OC
atoms.
And
similarly,
if
you
have
heterogeneous
resources
like
an
OC
N
and
a
telephone
number
range,
it's
not
saying
like
within
this
OC
n,
you
can
sign
this
telephone
number
range.
Instead
of
saying
you
know,
you
can
sign
for
anything,
that's
another,
so
CN
and
anything
under
this
telephone
number
range,
even
if
they
are
kind
of
overlapping.
H
So
we
just
want
to
make
that
clear.
I
guess
this
is
where
we're
gonna
end
up
making
that
clarification
added
a
bit
more
text
about
collapsing
the
certificate
chain
in
cases
where
the
CA
that
issued
a
parent
cert,
a
parent
wants
to
delegate
down
to
you,
know
a
new
delegate
certificate
for
an
enterprise
or
whatever,
but
really
that
you
know
the
the
carrier.
Let's
say
who
controls
that
parents
heart
is
going
to
the
same
CA
to
get
the
delegates
hurt
issue
that
issued
them
their
own,
so
yeah
their
own
certificate.
H
In
that
case,
there
may
be
ways
to
collapse
the
certificate
chain,
so
I
kind
of
explain
that
a
bit
more.
There
is
a
bit
of
a
trade-off
in
that
and
that
you
may
discard
information
about
who
the
entity
was
that
issued.
The
initial
cert
in
the
first
place,
so
we'd
have,
to
you
know,
figure
out
some
way
to
make
sure
that
the
resulting
collapse
chains
are
actually
correctly
identifies,
who
the
parent
is.
H
But
there's
been
some
interest
in
this
rather
than
having
like
these
sprawling
chain
certificates
that
could
potentially
in
aberrant
use
cases
arise
from
delegation
and
finally
I
added
a
bit
of
language
on
sub
certs.
This
was
a
TBD
that
we
discussed
a
bit
last
time
and
I
think
we
spend
quite
a
bit
of
time
on
it
actually
and
kind
of
what
the
draft
does
now
is
say
we'll
get
to
that
if
we
need
it.
In
other
words,
okay,
we're
defining
a
delegation
system
here,
but
there
could
be
some
regulatory
environment.
H
You
know,
maybe,
if
Germany
wakes
up
tomorrow,
insides
we're
gonna
do
stir.
They
may
not
like
the
idea
of
issuing
certificates
to
carriers
with
CA
equals
true
in
it,
and
so
it
just
kind
of
leaves
the
door
open
to
okay.
If
it
turns
out
that
is
gonna
be
possible
in
some
regulatory
environments
we
should
at
least
know
that
there
is
a
plan
for
how
to
deal
with
that
in
those
cases
next
slide
more
stuff
left
over
from
last
meeting.
H
I
did
just
restrict
pretty
much
using
x5u
since
everyone's
using
x5u
and
understand,
there's
already
like
PEM
chains
and
x5u
home.
We
could
use
x5c
because
it's
designed
with
a
specific
purpose
in
in
job,
but
you
know
if
people
want
to
start
doing
it.
That's
fine
right
now,
pretty
much.
Everyone
is
using
x5u,
though
so
I
would
probably
stick
with
that.
H
We
had
a
big
discussion
last
time,
a
good
bit
about
the
idea
that
maybe
we
should
put
some
piece
of
markup
in
the
certificate
that
says
that
the
entity,
the
CA
that
issued
this
cert
did
the
vetting
process
to
make
sure
that
the
encompassing
semantics
had
actually
been
validated
before
it.
The
delegate
cert,
but
as
many
people
pointed
out
like
it
should
just
do
that
and
there
shouldn't
be
any
need
for
you
to
say
there
has
to
be
a
good
bit
to
say
that
you
just
did
that
instead,
we're
just
assuming
you
did
that
so.
A
H
Enough
fair
enough,
and
so
we're
no
longer
talking
about
good
bits
for
that.
This
does
not
whoever
preclude
if
you
were
AVS-
and
you
still
want
to
just
double-check
that
this
particular
telephone
number
is
within
the
scope
of
the
OCA
and
in
the
sir
that
signed
yet
you
can
still
do
that.
We're
not
forbidding
you
from
doing
it.
We're
just
saying
that's
kind
of
belt-and-suspenders
at
this
point,
because
that
delegation
should
have
been
assured
by
the
CA
that
issued
the
cert
in
the
first
place
and
for
now
I
I
didn't
Li.
H
Do
anything
about
acne,
star
I!
Think
we're
gonna
push
that
probably
into
the
short-lived
certs
draft.
If
we
get
around
to
doing
that,
which
we
probably
will
at
some
point,
if
we
have
any
spare
time
today,
we
may
talk
about
what
future
directions
will
be
for
work.
We're
gonna
explore
here,
but
for
now
I'm,
not
really
saying
anything
about
it
in
this
draft
next
slide.
H
That's
it
like
I'm,
not
here,
to
raise
any
issues.
I'm,
not
really
aware.
There
are
any
issues,
I
think
we.
We
still
are
kind
of
waiting
to
see
what
Addis
is
going
to
emit
from
the
process.
It's
going
through
right
now
to
kind
of
measure,
ways
that
enterprises
know
TTS
might
participate
in
the
shaken
ecosystem
and
I
think
once
we
have
something
more
concrete
from
that
there
there
may
be
just
Corrections
course:
corrections
they're
required
in
this
approach,
but
I
think
this.
You
know.
H
For
that
reason
we
may
hold
it
another
cycle,
not
advanced
it
just
yet.
Maybe
we
could
use
that
time
to
get
some
eyes
on
it
and
see
if
anybody
has
any
comments,
but
as
far
as
I'm
turned,
basically,
this
should
be
ready
to
advance.
This
was
never
intended
to
be
particularly
complicated
draft.
Just
trying
to
explain
what
we
meant
by
saying
delegation
was
possible
when
we
wrote
RFC,
82
26.
H
I
mean
you
could
go
either
way.
I
don't
have
strong
feelings
about
that.
I
mean
you
know.
Working
group
last
calls
are
two
weeks
and
cycles
are
like
four
months
so
I.
Don't
think
it
is
essential
that
we
do
that
immediately,
but
we
certainly
could
if
that'll
help
get
some
eyes.
Maybe
you
wanna,
that's
what
the
point
was.
Is
that.
H
H
H
Understand
that
people
are
kicking
the
tires
on
this
in
the
marketplace
like
I
said,
so,
this
is
not
exactly
science
fiction
stuff.
This
is
being
again,
it
is,
is
in
82
26
that
you
can
do
this
is
in
some
RFC
we
previously
published.
This
is
just
really
further
people
who
are
now
trying
to
implant
explaining
what
it
means
to
implement
it.
So,
okay,.
D
H
J
K
J
The
second
one
is:
if
any
of
the
content
in
the
RCD
claims
does
have
any
URLs,
then
you
must
sign
with
an
integrity
claim
digest.
So,
if
anybody's
new,
to
that,
it's
a
digest
over
the
content
that
the
urls
point
to
there's
a
there's,
a
serialization
mechanism
that
tells
you
which
order
to
do
the
URLs
and
insert
the
content
and
to
the
digest
and
all
that
other
stuff
and
the
third
one
is
the
case
where
you
know
you
might
have
some
non-authoritative
users
signing.
J
J
J
J
Call
info
purpose,
I
think,
is
the
verb
that
I
sort
of
read
out
of
that
of
j-card
so
in
other
words,
add
to
the
currently
defined
I.
Think
it's
info,
icon
and
card
which
card
really
means
be
card
in
that
case,
so
we
wanted
to
create
one
that
was
specific
to
our
CD
with
a
purpose
of
J
card,
so
I
submitted
that
draft.
J
J
I'm
curious
what
people
think
about
that
I'm,
actually
thinking
that,
instead
of
in
this
sip
core
draft,
it
might
be
good
actually
to
keep
that
in
the
stir.
Rcd
draft,
because
you
know
other
people
might
have
other
opinions
for
what
you
know,
that
the
uses
of
j-card
our
first
sip
for
other
applications
or
things
like
that.
So
I
was
more
targeting.
You
know
interoperability,
where
terminals
may
want
to
display
certain
logos
in
certain
ways
you
know
icon
should
be
certain
sizes.
You
know,
I
I
didn't
know
how
far
to
go
there
so
I'm
just
curious.
J
J
Okay,
so
yeah
so
I
sent
a
message
to
the
SIP
core
mailing
list
and
we
can
discuss
it
there,
but
I'm
thinking
like
keeping
it
as
simple
as
possible.
It's
probably
the
best
policy.
There
I
also
gave
some
details
about
compact
foreign.
You
know
explicitly
using
this
call
info
J
card
and
then
also
a
display
name
for
the,
where
the
name
claim
that's
in
our
CD
and
I
removed.
J
H
John
Peterson,
so
everybody
who
knows
me
knows
that
my
favorite
thing
in
life
is
the
data
URL
and
that
this
is
a
joke.
It's
like
the
thing
I
think
is
the
most
architectural
sloppy
use
of
URLs
and
history
of
the
universe,
but
there
there
are
lots
of
ways
to
actually
just
encode
bodies
right
that
you
can
insert
them
into
sip
requests
and
there's
a
so
you
get
kind
of
my
media
type
4c
ID,
which
indicates
that
you're
actually
pointing
to
a
body
that
exists
like
elsewhere.
H
In
the
sip
message
now,
I
mean
all
these
CID
uses
require
my
multi-part
and
in
the
past
my
multi-part
support
has
been
a
bit
spotty
and
sip
implementations,
so
I
mean
that
that's
not
a
fantastic
solution,
I
still
think
did
URLs
are
a
worse
solution.
Probably
if
you
had
to
pick
something
based
on
the
way
that
we
have
dealt
with
these
things
lately,
it
would
be
just
encoding
it
in
a
header.
H
Writing
the
entire
thing,
like
you
know,
is
it
a
basic
ste
4,
parameter
that
we
tack
on
to
call
info
itself
that
contains
the
entire
j
card.
I'm
sure
that
everyone
who's
thrilled
about
the
size
of
identity,
headers
will
be.
You
know
very
excited
to
see
what
that
will
happen.
When
you
have
logos
and
icons
like
you
know,
being
a
64
encoded
these
things,
but
I
mean
at
the
end
of
the
day
you
know
I
think
you
do
have
to
bite
the
bullet
on.
If
you
are
gonna.
J
H
Let
me
provide
it
that
we
are
not
proposing
to
actually
encode
those
things.
Probably
we
can
have
a
profile
of
J
card
which
we
wouldn't
specify
in
this
call
info
document
specified
the
RCD
document
right
right.
That
would
say:
well,
here's
here's
some
kind
of
minimal
representation
that
gets
you.
What
you
want
specifies
these
URLs,
that
encode
that
and
stick
it
into
a
parameter
or
header
and
zip.
It
won't
be
too
much
worse
than
you
know.
Your
passports
already
are
right,
so
I
mean
that's
yeah,
the
other
alternatives.
H
L
Brian
Rosen:
this
is
probably
not
what
you
want,
but
I'll
just
make
you
aware
that
for
emergency
call
services,
we
created
a
thing
called
additional
data
which
can
hold
up
currently
it's
an
X
card,
but
we
want
to
make
a
J
card
version
of
that
anyway.
So
we
would
help
you
do
that
we
do
allow
direct
in
the
body
or
URI
indirect,
but
that
that
thing
exists.
If
you
wanted
to
use
it,
calling.
J
J
J
And
you
know
the
first
instinct
was,
let's
just
stuff
it
all
in
our
CD,
but
I
think
we
want
to
sort
of
purposefully.
Think
about
you
know
things
that
are
related
to
caller
versus
you
know,
information,
that's
part
of
a
call.
I
know
handing
has
a
call
info
thing,
that's
related
to
like
typing
the
caller
and
they're.
You
know
like
what
side
of
the
fence
is
that
on
so
just
curious?
If
people
have
opinions
on
on
that
topic
to
go,
are
you
going
back
to
the
know.
J
J
Don't
know
that
was
my
question.
I
didn't
get
a
chance
to
take
a
look
at
the
draft,
but
the
question
is:
are
the
are
all
yeah
if
I
believe
it's
using
call
info
and
I
guess
the
question
is
you
know,
are
they
all
externally
referenced
data
or
is
there
some
way
that
the
data
has
actually
been
incorporated
into
the
head
or
not.
H
John
Peterson
again
yeah,
it's
you
know
to
degree
that
you
seen
em
like
incorporates
things
like
logos
like
how
does
it
do
it
and
in
particular,
has
the
whole
structure
that,
like
you
know
the
URLs
to
logos
and
so
on,
exist
in
encode
it
in
call
it,
though
right
I,
think
that's.
H
H
H
At
the
end
of
the
day,
like
the
stuff,
that's
in
card
we
get
into
what
they
call
reason
is
I
think
it
could
potentially
be
an
entirely
separate
a
component
of
entirely
separate
data
structure.
There
are
a
couple
of
other
examples
of
things
that
work
along
these
lines.
That
I
can
think
of.
One
of
them
is
URLs
for
interacting
outside
the
call,
usually
post
call
interaction
is
the
kind
of
thing
that
you
know.
H
I
can
enterprise
want
to
be
able
to
deliver
to
an
end
user
or
so
if
they
could,
like
click
a
URL
after
a
call
or
even
if
they
didn't
answer
the
call
and
those
things
aren't
like
J
card,
or
you
know,
B
card
they're,
something
that
is
specific
to
who
that
particular
entity
is
that
and
and
really
what
the
call
was
about,
and
that
seems
to
be
the
same
for
call
reason.
So
just
architectural
II
I
think
both
of
these
things
can
fall
in
the
scope
of
our
CD
of
rich
call
data.
H
A
component
of
rich
call
data
is
who
is
this
joker?
Who
is
placing
this
call
and
all
the
things
that
are
kind
of
Jake?
Our
dish
will
help
answer
that
component
of
it.
It
just
could
be,
there's
a
need
for
a
separate
data
structure.
I
think
that
it
would
still
be
under
the
RCD
rubric,
but
would
cover
things
like
call
visa
that
do
to
seem
to
be
kind
of
like
architectural.
A
separate.
H
You
know
why
they're
calling
it's
not
I,
think
supposed
to
be
dynamic
that
way,
but
you
know
this,
if
anybody
else
has
any
views
about
whether
kind
of
B
card
it
should
be
extensible,
this
is
it
more
dynamic
than
I
think
it
is,
and
I'm
just
gonna
miss
this
over
the
years,
or
does
it
make
sense
to
have
this
kind
of
separation
between
what
you
know?
Who
would
the
caller
info
and
the
call
info.
L
C
On
genetics,
I'm,
just
discussing
with
John,
was
on
talking
about
there
with
a
vCard
vCard
was
designed
that
all
of
the
data-
and
it
was
mirja
belen
other
things
it
was
persistent
in
savable
I
mean
this
type
of
information.
Vcard
would
break
the
merge
of
all
semantics
of
e
card,
so
I
mean
I,
totally
support
it
being
in
something
separate
it.
It
doesn't.
Map
to
the
I
mean
it'll,
be
a
problem.
If
you
try
and
stuff
it
right
in
the
car.
C
J
It's
just
a
JSON
version.
The
other
thing
I
was
going
to
bring
up
too
is
like
I
can
see,
definitely
use
cases
of
you
know,
especially
thinking
about
the
integrity
stuff.
You
know
the
person,
the
person
or
the
company
or
whatever
it
never
changes,
but
you
know
the
reason
for
the
call
does
change,
and
so
you
may
want
even
separation
of
the
integrity
part
as
well.
So
we
might
want
to
think
about
that
as
well.
Yeah.
H
I
John
person
again
I,
think
that
makes
a
lot
of
sense.
I
mean
I.
Think
one
thing
I
would
be
interested
in
knowing
is,
if
anybody
thinks
we
there's
anything,
we
can
steal
for
this.
I
guess:
there's
something
out
there
already
that
communicates
roughly
what
collinsville
means
versus
what
Collard
in
pro
means
that
and
I'm
not
sure
there
would
be
in
the
IHF
of
maybe
like
outside
the
ITF.
Is
there
something
in
like
some
like?
Let's
see,
Typhon
like
I,
don't
know
what
it
is
but
like
somewhere
that
someone
has
actually
looked
at.
H
J
H
Like
I
said
it's,
it's
gonna
include
things
like
your
URL
for
post
call,
interaction
and
there's
gonna,
be
like
a
bunch
of
stuff
that
we're
gonna
be
able
to
put
into
that,
and
so
it
has
to
be
something.
That's
relatively
extensible.
Anybody
have
any
ideas:
CDRs,
that's
not
bad!
Well,
we
found
yeah
John
CDRs
I
mean.
H
J
H
H
H
Now
this
is
a
case
where
an
OB
right,
where
you
know
if
the
call
is
coming
in
to
a
target-
and
you
want
to
try
to
impersonate
a
call
to
a
target
if
you
as
the
attacker,
have
some
way
predicting
that,
like
an
enterprise
you
want
to
impersonate
is
already
placing
a
call
to
the
person
that
you
want
to
impersonate
them
to.
You
can
like
do
a
race
condition
against
them
right
and
if
your
call
wins,
then,
when
the
called
parties
phone
rings,
they'll
go
talk
to
the
CPS,
where
passports
restored
in
the
out-of-band
model.
H
They'll
get
this
passport
that
tells
them
Oh
a
call.
Exactly
like
your
looks
just
like
your
call
is
actually
in
progress
at
the
moment.
Fantastic
and
so
I
know
that
it
must
be.
You
I
think
it's
an
extremely
difficult
attack
practically
execute
the
only
conditions
under
which
it
seems
remotely
plausible
our
callback
services.
These
are
cases
where,
if
you
imagine
a
big
enterprise
like
American
Express
or
something
has
a
number
that
you
or
maybe
even
a
webpage,
that
you
can
put
in
and
say
hey,
you
know.
H
Please
call
me:
have
an
agent
call
me
at
the
following
number
and
if
you,
you
know
you're
an
attacker
and
you
did
like
10,000
practice
calls
and
timed
them
against
a
random
selection
of
numbers
that
you
control
and
got
a
good
sense
of
exactly
how
long
it
took
for
their
callback
service
to
like
emit
a
call.
Maybe
then
I
could
predict
right
when
I'm
doing
a
callback
to
add
them.
H
H
So
we
put
in
smart
text
about
mitigation,
for
that
there
are
a
couple
of
ways
to
mitigate
at
the
main
ones
are
reducing
the
window
which
the
passport
is
actually
available
in
the
CPS,
including
potentially
putting
it
in
after
you
place.
The
call
the
text
is
sad
for
some
time.
You
know.
First,
you
put
your
passport
in
CPS
and
then
you
place
your
call.
You
can
reduce
the
window
on
that
side
and
also
the
other
thing
talks
about.
H
Is
doing
some
kind
of
post
call
coordination,
and
this
is
based
on
the
exposure
of
call
state
information
on
both
sides
of
the
call,
and
what
this
requires
really
is
that
the
enterprise,
if
it
calls
and
and
the
Android
phone
says,
hey
I'm
connected
and
the
enterprise
says,
I'm
not
connected
I
I
got
a
busy
signal
or
I
got
sent
to
voicemail.
Then
you
know
that
their
shenanigans,
it's
somebody
won
the
race
condition
and
if
you're
super
paranoid
about
this,
then
you
can
implement
things
like
that.
H
What
would
be
much
simpler
to
implement
is
a
random
timer.
That
gives
you
about
two
seconds
of
leeway
and
how
long
your
callback
service
takes
to
execute
its
calls.
You
did
that
on
the
enterprise.
Is
it
you
know
a
hundredth
of
the
expense
of
implementing
any
other
things
that
I
just
described.
You
would
make
this
attack
impossible,
but
that
much
said
we
have
some
more
mitigation
stuff
about
that
in
there
and
we're
getting
some
preliminary
data
even
about
how
common
predictable
callback
services
really
are
I,
don't
think
they're,
actually
very
common.
H
In
my
experience,
most
callback
services
already
have
30
seconds
worth
of
like
random
delay
to
them,
just
because
of
human
interactions
and
things,
but
there's
some
text
in
there
to
make
those
people
feel
better.
We
also
added
some
text
about
discovering
a
CPS
through
provisioning,
as
opposed
to
having
some
kind
of
service
discovery
function
because
and
a
lot
of
the
toy
implementations
of
OB
that
are
out
there
today,
they're
happening
in
more
closed
environments,
right
they're
happening
these
more
enterprise
environments
and,
as
a
consequence
of
that,
you
really
can
just
provision.
H
H
These
this
would
be
I
mean
effectively
in
those
cases,
the
CPS
we
probably
authenticate
both
parties,
the
person
putting
it
in
putting
out
it's
an
intranet
environment,
or
you
can
assume
that
security,
Association,
yeah,
okay,
thanks
so
on
div
I,
fixed
examples.
We
had
some
temp
examples
in
there
that
really
need
to
be
repaired.
They
are
hopefully
now
correct.
They
are
hot
from
a
actual
implementation
that,
hopefully,
is
working
there's
a
bit
more
discipline
in
json
language.
H
This
is
something
adam
pointed
out
that
there
was
really
sloppy
usages
of
like
what
arrays
and
values
and
elements,
and
things
like
that
were
so.
I
tried
to
put
in
stricter
language
that
is
correct.
How
you're
supposed
to
talk
about
json
and
I
had
am
also
pointed
out
that
the
language
about
how
many
divs
you
need
per
redirection
in
these
cases,
where
you
have
kind
of
multiple
baseline
divs
in
a
single
passport,
for
example,
I
know
Martin's
going
to
talk
about
our
pH.
H
If
you
have
one
our
pH
passport,
one
shaken
passport
that
are
in
the
same,
you
know
invite
you
want
to
make
sure
that
you
don't
end
up
having
like
exponential
multiplication
of
these.
If
you
go
through
multiple
redirections,
and
so
the
language
is
hopefully
clear
now
that
there
will
be
one
non
div
passport
for
you
know
each
baseline
passport
without
a
common
origin
guest
in
the
message
and
maybe
a
lot
to
unpack
when
actually
say
it,
but
the
language
in
the
draft
I
think
is
clear
about
this
and
no
longer
suggests.
H
This
is
an
exponential
multiplication
problem
and
I.
Think
that
resolves
the
issues
that
is
Adam
saw
them
of
the
major
ones,
I
hope.
So
let
me
know
if
there's
anything
more
there.
I
did
also
and
I
don't
have
this
on
the
slide.
I
know
there's
been
some
concern
in
Addis
that,
because
of
like
attended
transfer
sorts
of
use
cases,
we
should
make
the
window
more
generous
for
passport
expiry
in
these
div
cases,
and
these
are
cases
where
we're
using
like,
like
third-party
call,
control
or
something
like
that.
M
Martin
dali
18
t
well
an
example
of
that
is
in
support
of
9-1-1
for
transfer,
where
you
know
you
end
up
at
an
agent
that
agent
stays
on
the
call
and
then
forwards
the
original
signing
to
you,
the
ultimate
destination
for
verification
there.
So
there's
an
example
of
some
type
of
relight
type
function.
Sure.
H
I
mean,
of
course,
these
problems
all
go
away
if
you
use
refer
instead
through
you
see,
which
would
be
great,
but
here
we
are,
and
it's
2020
in
a
few
weeks,
and
we
still
aren't
really
using
prefer,
so
we
were
supposed
to
so
given
that
that
seems
to
be
the
situation
and
there's
nothing.
We
can
do
about
it,
I
relaxed
that
interval
and
you
you
can
be
more
generous
with
kind
of
scale
passports
for
that
next
slide.
H
Oh
yeah
I
see
no
slide
about
this
every
time,
so
I
did
send
a
note
to
the
list
a
couple
weeks
ago,
talking
about
whether
we
should
bother
to
errata
8220.
For
this
issue
of
whether
you
need
quote
marks
around
the
PPT
values
in
the
identity,
header
parameter.
This
is
something
that
I'll
admit.
The
text
in
84
is
not
particularly
helpful
and
we
have
baked
into.
However,
the
rph
draft
and
the
div
draft
doing
this
with
quotes
around
the
values
for
PPT.
Miss
has
induced
me
at
least
to
be
like.
Let's
make
it
firmly
crooked.
H
That
way,
and
you
know
I,
think
that
the
mailing
was
traffic
about
this
I
got
like
three
responses,
and
it
was.
It
was
like
two
or
like
yeah
I,
just
quote
it,
and
one
was
like
nah,
don't
quote
it?
Anybody
else
wants
to
like
find
that
thread
and
reply
and
say
like
what
they
want.
That
would
be
helpful
and
I
would
then
be
happy
to
errata
this
to
whatever
people
want,
but
I
really
didn't
feel
like
there's
enough,
like
consensus
around
what
we
should
actually
do.
J
H
C
H
C
For
this,
but
but
it
means
that
ever
I
mean
given.
This
replaces
not
updates
that
it
means,
like
you,
can't
have
everybody
that's
producing
those
identities
with
that
hasn't
upgraded
to
the
latest,
I
mean
you
have
to
have
backwards
compatible
at
some
level
with
that
or
you're
gonna
break
every
identity
on
every
these
things
and
it'll
be
a
hundred
percent
reason
why
every
vendor
will
go
we're
not
deploying
that,
because
it
breaks
our
stuff
yeah.
H
H
C
H
Tell
you
this
is.
This
is
absolutely
the
number
one
thing
from
interoperability
testing
there's
a
problem
is
that
some
people
are
doing
it
quoted.
Some
people
are
doing
it
uncoated
and
there
apparently
some
implementations
it
just
refused
to
accept,
quoted
and,
like
you
know,
even
though,
like
that's
what
we
wrote
into
the
div
and
the
are
pH
specs,
it's
like
any
examples
is,
like
you
know
everything
in
there
and
so
yeah.
H
L
N
I
Adam
wrote-
and
this
is
just
as
an
individual
contributor
when
I
think
about
the
way
that
we
want
to
address
this,
and
this
sort
of
came
up
when
you're
talking
about
the
Interop
issues
that
people
are
kind
of
crete,
lee
encountering
I
think
we
probably
want
something.
A
little
more
complex
than
we
could
do
in
just
a
simple
errata
we
might
want
is
a
very
short
document
that
says
when
you
generate
these
put
quotes
around
it.
When
you
receive
them,
you
need
to
be
able
to
handle
both
well.
H
I
H
I
H
H
Guy
here,
Obi
is
coming
soon
to
tell
a
chat
near
you.
You
know,
I
think
we
do
now
that
we
have
the
framework
and
architecture
pro-v
out.
I
suspect
there
will
be
some
new
documents
that
are
going
to
talk
about
these
very
specific
use
cases
in
which
people
want
to
use
Obi.
There's
the
public
option.
I've
heard
a
lot
of
people
interested
and
trying
to
figure
out
how
to
do
public,
Obi
and
public
Obi
is
really
cool
and
it
could
be
meaningful
for
a
number
of
solutions
out
there
in
the
universe.
H
I
am
NOT
going
to
do
all
this
work
myself,
especially
not
on
the
public
option,
but
if
there
is
a
will
to
get
those
things
done,
then
I
will
certainly
pitch
in
the
private
option.
Is
the
one
that
I
think
is
more
interesting
as
kind
of
what
some
of
these
more
enterprises
use
cases
look
like.
Maybe
the
enterprise
is
interacting
with
that
smartphone
app
things
like
that,
those
I
think
are
because
they
are
practically
starting
to
appear
in
the
field.
Now
this
is
not
hypothetical.
H
A
I
F
A
M
M
The
Nina
EF
community,
you
know,
made
a
request
of
the
IP
n
and
I
for
signing
of
the
are
pH
for
civil
9-1-1
calls
for
yes,
I
net,
similarly
to
what
we
did
for
government
priority
services,
ETS,
WPS
and
so
next
slide.
Okay,
so
in
the
the
rigid,
the
first
signing
our
pH
for
government
priority
services,
we
built
upon
the
twenty
8225
for
inclusion
of
a
cryptographically
signed
our
pH
header
field.
M
Their
registry
was
created
so
that
additional
new
would
be
easier
for
Standardization
within
Ayane,
and
so
what
this
document
here
is
provides.
New
assertions
for
emergency
services,
call
origination
and
emergency
services
call
back,
and
so
the
new
assertion
values
are
es,
org
for
the
emergency
services
origination
and
yes,
call
back
for
emergency
services,
call
back.
M
We
had
a
conversation
at
the
last
ipn
and
I'm
meeting.
So
the
example
I
gave
it
to
Mike,
where
you
you
make
emergency
services.
Call
you
end
up
at
emergency
service
operator,
but
then
needs
to
transfer
you
and
when
they
transfer
you
it's
not
a
hard
transfer.
They
stay
on
the
call
and
it's
more
like
a
conference,
and
so
we
talked
about.
Do
we
need
new
assertion
for
that,
and
the
answer
would
be
no,
because
the
original
signing
of
the
passport
would
be
passed
along
during
that
transport
process.
M
Okay,
and
so
that's
the
reason
for
not
requesting
a
a
1
for
the
for
the
transport
case
next
slide,
and
so
the
syntax
that
we're
proposing
is
for
the
orig,
the
orig
to
Yen
calling
party
number
now,
here's
something
where
this
can
be
either
9-1-1
or
you
RN
service.
You
were
n,
as
in
you
are
NSO
s,
yeah.
H
H
Like
short
draft
that
somebody
needs
to
do
not
necessarily
leave
talked
about
this
rapport,
yes,
I'm
aware
that
there
there's
a
little
bit
of
crufty
text
and,
if
you're
24,
that
seems
to
imply
this
can
really
have
to
be
like
a
safe
person.
You
are
basically
so
yes,
we
will.
We
will
patch
something
now
you're
welcome
to
do
it
in
this
draft.
J
Yeah,
we
actually
a
discussion
about
a
related
topic.
I,
don't
know
Morgan.
If
you
want
to
talk
about
that
now
or
later,
the
the
fact
that
you
know
for
cellphones
that
don't
have
SIM
cards
in
them,
you
still
need
to
support
9-1-1
and
there's
no
telephone
number
associated.
So
what
do
you
do
for
orage
when
there's
no
telephone
number
and
I
was
wondering?
Is
there
something
that
can
represent
unknown
like
a?
U
RN
or
something
like
that?
Or
should
we
make
something
up
for
curious.
L
M
Was
that
was
part
of
the
that
was
part
of
the
discussion?
We
had
an
IP
n
and
I
Brian
that
there
would
be
there
would
there
would
be
some
thing
that
would
syntactically
mean
you
know
it's
not
that
it's
anonymous,
but
that
the
originating
carrier
can't
verify
the
identity
of
the
origination.
Originator
of
the
call.
H
L
You
you
can't
vouch
for
the
person,
but
you
can
vouch
for
the
device
which
is
all
you
ever
device
provide
for
all
that
all
that
all
the
emergency
services
guys
care
about
is
that
two
calls
at
the
same
from
the
same
uninitialized
phone
have
the
same
identifiers.
Okay,
all
they
care
about.
Okay.
So
let's.
M
J
L
H
In
other
words,
if
we
created
or
just
maybe
we
can
reuse
some
existing
like
you
are
on
right.
That
just
contains
some
just
just
a
UID
of
some
kind
that
is
gonna
be
created
by
the
service
providers.
That
would
be
sufficient
for
this
function.
Okay,
let's
so,
let's
just
figure
out
what
exactly
what
that
you
were
in
should
be
I'm
sure,
there's
something
we
can
reuse
for
this.
N
M
No,
so,
basically
for
callback
is
you
make
a
call,
but
for
whatever
reason
you
get
disconnected,
and
so
now
the
emergency
network
is
calling
you
back
right.
Okay,
so
like
if
you
dial,
nine-one-one
and
hang
up
the
and
then
you
actually
got
to
the
to
the
peace,
app,
the
peace,
apps
gonna
call
you
back
and
that's
what
we're
that's,
what
we
referring
to
as
a
callback
here
correct,
but.
N
L
H
Yeah
John
Peterson,
yes,
I
I
think
it
is,
and
you
know
my
only
question
about
it
is:
we've
talked
about
a
couple
of
other
things.
It
sounds
like
it
might
be
useful
to
specify
along
with
this.
Do
we
kind
of
need
a
stir
or
working
group
document?
That
is,
how
did
you
serve
from
refuse
to
services
that
contains
this
and
that
stuff,
every
all
the
different
you
are
n
stuck
we
need
to
do
and
like
is
it
just
seems
like
there's
a
bucket
of
stuff.
H
That
needs
to
be
done,
or
do
you
just
want
to
kind
of
do
this
alone
and
have
another
document
that
is
gonna
specify?
Okay,
here's
where
you
are
an
SOS
lives
inequity
how
that
should
work
with
tast
and
things
like
that,
especially
the
question
for
Martin,
in
terms
of
just
how
you
want
to
organize
those
I
think.
H
A
H
Point
is
this
is
just
specifying
what
the
procedure
like
there
may
be
unique:
a
s
and
BS
procedures
that
are
associated
with
receiving
a
call
for
you,
RN,
as
what's
right
and
like
I
mean
I
had
to
write
him.
Forgive
I
had
to
write
him,
400
be
like
and
I,
wouldn't
be
surprised
if
there
wasn't
something
unique
about
the
way
this
was
supposed
to
work,
and
some
of
the
things
we've
just
been
talking
about
suggesting
you
know
probably,
is
so
I
guess.
L
M
Just
one
more
thing
to
note,
and
so
it
doesn't
come,
look
like
it's
going
to
come
serious
seriously
in
serial
form.
The
other
namespaces
in
our
in
the
our
pH
name.
One
is
for
I.
Think
there's,
there's
there's
two
defined
for
mission,
critical
push-to-talk,
which
is
the
responder
so
in
the
US
that
would
be
for
firstnet
and.
M
You
know
signing
of
our
pH
for
their
calls
and
I
haven't
gotten
a
positive
answer
and
the
examples
there
would
be
there's
a
Katrina
event
and
someone
is
calling
from
the
event
to
Washington
to
FEMA
as
an
example.
Now
they
may
also
be
against
WPS
user,
which
would
likely
be
the
signing
that
could
occur,
but
they
may
they
don't
necessarily
have
to
be,
and
and
therefore
you
know
what
do
they
want
priority
handling
for
those
calls
that
Brian
Rosen.
L
A
A
H
H
Actually,
this
is
something
that
we
floated
an
initial
draft
about
like
a
year
or
so
ago,
but
hasn't
been
on
the
front
burner,
but
these
are
all
the
use
cases
where
you
want
to
try
to
figure
out
when
you're
placing
a
call
who
you've
actually
reached
and
to
be
able
to
use
stir
in
the
backwards
direction
rather
than
the
forwards
direction.
There
are
a
couple
of
variations
on
this,
including
doing
pre
call
star
checks
of
various
kinds.
H
If
you
have
a
telephone
number
that
you
know,
you're
about,
to
call
that
you
can
see
in
a
UI
actually
be
able
to
see
like
RCD
data
associated
with
who
it
is
you're
calling
before
you
press
call,
and
to
know
that
it's
secure
things
like
that
this.
This
is
something
that
is
already
hinted
at
in
the
connected
identity
draft
that
was
submitted
like
a
year
or
so
ago.