►
From YouTube: IETF103-STIR-20181105-1120
Description
STIR meeting session at IETF103
2018/11/05 1120
https://datatracker.ietf.org/meeting/103/proceedings/
A
B
C
B
C
C
C
You
you
should
be
familiar
with
the
note
well
by
now,
if
you're
not
please
pay
attention,
this
has
implications
about
how
you
were
supposed
to
behave.
How
you're
supposed
to
disclose
IP
are
a
variety
of
other
important
things
and
down
near
the
bottom.
Are
the
specific
documents
to
talk
about
exactly
how
this
works
so
today,
I've
already
got
a
minute
taker
to
diversify
blue
sheets,
we're
going
to
be
talking
about
see
out
of
and
shaken
the
divert
draft
and
our
CD.
Is
it
good
I.
B
Think
Chris
will
actually
be
doing
our
CD
instead
of
me.
Okay,
so
that's
batch
number
one
any
other
bashes
anything
else.
People
would
love
to
discuss.
Martin,
Dali,
I'm
sure
you
have
a
five
minute
lightening
talk.
You
want
to
give
okay,
okay,
so
I,
don't
know
we
actually
have
any
of
the
other
materials
uploaded
here.
B
B
G
E
B
B
H
I
I
I
Indicator
that
might
expose
something
it's
important
to
recognize.
Orage
ID
is
not
the
does
not
have
anything
to
do
with
the
originator
of
a
call.
It's
actually
something
that
we
put
into
shakin
as
an
I
as
a
unique.
I
opaque,
unique
identifier
so
that
the
service
provider
would
have
some
way
of
tracing
back
to
where
the
call
was
originated,
not
the
originator
themselves.
I
guess
I
recognized
that
that
is
somewhat
confusing
potentially,
but
suffice
it
to
say.
I
B
Mean
so,
to
be
honest,
I
mean
thirty,
thirty,
three,
twenty
three.
You
know
the
privacy
properties
that
it
provides.
Probably
aren't
that
well
aligned
with
this
particular
issue
anyway,
I
think,
what's
what's
more
material
to
it
would
be
again
that
the
fact
that
they're
this
does
not
contain
personally
identifying
information
in
any
real
way
right.
B
This
is
something
that
is
used
as
a
very
opaque
identifier
for
network
resources
rather
than
people,
and
you
know
in
the
second
place
that
there
are
known
countermeasures
right
if
you're
concerned
about
people
tracking
these
things,
you
can
just
generate
a
new
one
that
you,
because
this
is
basically
internal
to
service
Rider
networks
right
so
like
if
you,
if
there's
one
Shrunk,
that
you're
identifying
with
orig
ID,
you
could,
if
you
felt
like
it
like,
generate
a
different
orig
ID.
That
pointed
to
that
same
trunk.
B
Every
time
you
please
to
call
so
I
think
that
the
aggregate
of
those
two
things
probably
closes
any
privacy
cap
I'd
be
worried
about
it's.
It's
worth,
I'm
sure
pointing
in
general
to
security
properties
of
8225
to
the
passport
case
back
in
that,
but
yeah
I,
think
I.
Think
those
two
things
really
probably
satisfy
me.
Anybody
on
it.
B
I
I
I
got
specifically
to
describe
in
the
abstract
a
little
more
consistent,
contextually
for,
what's
being
described
in
the
document
versus
talking
about
like
how
it's
coming
from
shaken
and
IP,
n
and
I,
and
all
that
other
stuff
and
I
actually
agree
with
that.
So
I
wrote
some
new
text.
You
know
talking
about
giving
a
brief
description
of
both
via
test
and
Orage
ID.
The
purpose
of
those
and
what's
described
in
the
document.
I
I
C
K
C
K
B
B
So
for
those
of
you
that
do
not
recall
this
document
at
all,
it
has
been
in
working
group
last
call
here
for
a
bit.
We
did
have
these
some
eyeballs
on
it.
This
is
the
document
that
is
fixing
known
kind
of
gap
and
stores
capabilities
in
cases
where
there
is
call
forwarding,
basically
where
the
administrative
domain,
that
was
the
original
target
for
a
call
wants
to
be
able
to
tell
you
now
go
somewhere
else
instead,
and
so
we
created
this
new
div
attribute
it's
a
new
kind
of
Passport.
B
This
would
be
like
this.
This
was
to
John
right,
but
of
course,
if
sending
Chris
sends
me
an
invite
and
I
then
generate
this
div
of
passport.
It'll
show
ya,
I'm,
John
and
I'm
saying
this
calls
actually
supposed
to
go
to
Martin,
so
Martin
gets
it
don't
go.
Oh
I
see
how
that
worked
is
a
verification
service.
B
A
lot
of
people
seem
to
want
it
next
slide,
so
based
on
the
enlightened
guidance
of
Eric
Berger
at
the
previous
IETF
meeting,
we
have
made
nesting
in
this
a
must,
that
is
to
say
that
whenever
you
see
a
div
passport,
it's
going
to
have
within
it
the
original
passport
encoded.
With
this
new
up
element
that
we
have
defined
for
passport,
we
also
made
opted
completely
independent
of
did
so.
Actually,
a
future
extensions
want
to
make
use
of
having
some
original
passport
embedded
inside
a
passport.
B
For
some
reason,
they'll
be
able
to
just
reference
the
specification
to
pick
that
up.
There
are
a
couple
of
their
use
cases
that
people
have
batted
around
where
that
might
actually
be
useful.
The
one
of
course
consequence
of
this.
It
kind
of
it's
a
trade
off
right
previously
we're
talking
about
doing
this
all
with
multiple
identity,
headers
and
then
you'd
have
to
try
to
figure
out
okay,
which
one
of
these
divs
goes
with,
which
of
these
original
passports.
B
B
B
That
is
that
this
is
a
different
administrative
domain,
for
example,
then
what
the
original
two
header
field
signified,
like
kind
of
how
do
you
handle
it?
And
what
do
you
make
of
that
situation?
Then
this
comes
back
to
it.
That
kind
of
the
core
principles
behind
stir.
You
know
we
want
to
sign
over
the
to
header
field
in
order
to
make
it
possible
for
verification
services
to
have
an
idea
of
who
the
original
caller
was
trying
to
reach
right
and
whether
or
not
they
are.
B
You
know
that
person
or
that
administrative
entity,
and
so
you
know
I-
think
that
that
that
principle
is
a
good
one
and
if,
if
we
wanted
to
alter
it,
we'd
have
to
go
back
into
44:24,
really
alter
it
and
44:25.
This
isn't
something
that's
like
specific
to
the
did:
spectrum
there's
nothing.
We
do
and
did
that
would
kind
of
change
that,
and
there
is
kind
of
a
gap
that
opens
in
this
to.
B
If,
for
example,
you
were
only
signing
over
the
request
URI
and
not
over
up
the
two,
which
is
one
one
proposal
that
I
heard,
you
know
that
then
I
think
you
know,
I
can
imagine
a
class
of
attacks
where
you
want
to
say
convince
United
Airlines
that
the
original
called
number
was.
You
know,
1-800
United,
1,
and
that
you
know,
but
you're
only
signing
over
the
request,
URI
and
that's
what's
in
the
dast,
and
you
could
kind
of
just
represent
oh
well.
B
This
had
gotten
securely
redirected
previously
to
you
and
that
there
there
could
be
vulnerabilities
that
would
open
up
from
that.
So
my
initial
intuition
on
this
anyway,
was
that
kind
of
like
things.
The
way
they
are
I
guess,
I
kind
of
I
think
did
was
created
specifically
to
take
care
of
these
use
cases
where
there
was
a
change.
They've
been
astray
of
domain
that
is
semantically,
meaningful
and
so
I
guess.
My
thinking
is
I'm
pretty
comfortable
with
the
way
the
mechanism
scans
now.
B
I
Like
call
forwarding
case,
where
you
know
it's
going
from
network
to
network
versus,
you
know
the
case
where
you
know
you're
calling
1-800
United
and
it's
just
a
geographic
telephone
number,
that's
being
retargeted
to
and
therefore
the
end
consumer
of
that
call
knows
that
it's
representing
1-800
United
versus
it's
actually
like
a
totally
different
telephone
number
yeah
does
need
to
be
verified.
So
I
think
we
just
need
to
well
in
this
draft
it'd
be
nice
to
talk
about
the
differentiation
between
those
two
cases
and
then
I
think
on
the
shake
inside.
B
I
think
uses
for
the
redirection
or
the
retargeting
has
already
occurred
on
the
originating
side.
You
know
this
is
exactly
what
diversion
might
was
greeted
for
back
in
the
day,
and
we
don't.
We
don't
love
diversion
here
in
the
ITF.
So
much,
but
history
in
Fela
right
is
the
mature
version
of
that
and
we
have
created
these
plugins
that
make
div
work
with
those
things
specifically
for
precisely
this
use
case.
So
I
mean
I.
B
I
hope
that
it
works
I
mean
I,
can
imagine
an
authentication
service
right
that
is
privy
to
a
dip
that
has
been
made
to
us
hundred
locally,
even
creating
the
whole
like
dip
being
like
provide.
They
can
sign
for
it
like
that's,
not
in
any
way
outside
growing
possibilities,
so
yeah
I
mean
my
preference
would
be,
of
course,
that
whoever
is
you
know,
fielding
those
SMS
800
queries
actually
in
turn
generates
the
full
did
for
the
call
and
sends
it
back,
but
I
could
imagine
other
architectures
where
that
is
much
more
internal
to
a
network.
B
B
Yeah
I
mean
I,
guess
you
know,
we
don't
lay
a
lot
of
constraints
on
what
policy
decisions,
authentication,
services
and
verification
services
make
for
good
reason.
I
could
imagine
authentication
services
that
would
be
upset
about
that,
but
I
can
also
imagine
ones.
That
would
say.
I
know
why
this
is
happening
and
I'm
still
confident
signing
the
two
right,
and
so
that
that
you
know,
as
long
as
you
have
the
proper
credentialed
assigns
that
you
had
her
field.
I
can
kind
of
see
you
still
doing
it
in
that
case,
but.
I
B
B
It's
like
here
are
some
not
insane
policies
or
why
authentication,
services
and
verification
services
should
sign,
and
you
know,
validate
things
respectively
and
what
we
imagine
they're
going
to
present
to
the
application
or
ultimately,
they
might
get
render
to
a
user
on
the
verification
side
as
a
result
of
receiving
a
valid
password,
and
you
know
that
maybe
there
is
more
exact
guidance
than
we
give
in
80
to
20
or
there's
a
bit
of
guidance
in
there
right.
But
it's
it's
very
policy
free,
it's
very
much
like
well.
B
If
the
date
is
within
like
this
threshold,
this
we
should
do
and
things
like
that,
but
we
very
intentionally
ignoring.
Is
there
anything
about
why
you
sign
or
accept
these
things?
If
there
was
an
appetite
to
explore
that
more
I
think
we
would
be
getting
into
that
territory
very
quickly.
If
we
started
trying
to
answer
the
question
well,
should
it
not
think
you
should
service
really
sign
a
two
letter
field?
If
you
know
the
requests
that
comes
to
it
has
request
your
I.
That
is
radically
different,
I.
B
I
B
That's
my
preference
yeah
that
my
preference
is
that
you
are
creating
a
div.
If
you
have
you
know
the
skull
has
been
forward.
If
there's
a
request,
URI
that
is
radically
different
from
from
the
original
to
header
field.
That
would
be
my
preference
because
it
just
because
it'll
make
it
easier
for
a
verification
service
to
make
sense
of
it
when
it
actually
ultimately
receives
the
request.
That's
the
eyehole
idea
of
behind
us
is
so
you
can
have
some
assurance
that
this
is
not
a
cut
and
paste
attack
against
you
say:
look
we
had
some
discussion.
B
We
had
substitutive
discussion
about
div
I
promised
a
little
bit.
Yeah
I,
think
I
think
we're
pretty
close
on
this
I
would
say
I'm
comfortable
last
calling
it,
as
is
you
know,
I'd,
always
be
happy
to
see
more
eyes
on
it.
Eric
actually
caught
a
lot
of
just
fumble
grammar
and
malformed
ideas.
So
if
other
people
feel
like
reading
it
during
working
class
ball,
that
would
be
great.
C
Actually,
on
the
previous
draft,
so
Adam
wrote
as
area
director
again
I
realized
when
I
sat
down
that
I
had
mixed
some
things
up
in
my
head,
and
the
shaken
draft
has
been
through.
Ietf
asked
already
we're
not
doing
that
again.
What
I
meant
to
say
is
as
soon
as
the
oh
five
comes
out,
we'll
be
putting
it
on
an
IE
SG
agenda,
so
yeah
for
closer
to
the
finish
line.
That's
when
I
interpreted
your
words
to
me.
It's
so
I
think
we're
transferring
I
got
some
confused
email
on
the
topic.
K
B
The
thing
like
I
got
all
like
right,
so
I
I
had
it
in
PowerPoint,
I,
converted
to
keynote
and
then
I'd
like
I'd
to
mail
it
from
my
anyway.
I
won't
do
that
again.
I
have
virtually
nothing
to
say
about
this
document
next
slide,
it's
called
out
AB
and
it's
this
document,
that's
about
the
out
of
and
stuff
about,
the
notion
that
maybe
some
protocol
other
than
sip
might
have
use
for
passports.
This
is
an
idea
that
I
think
we
can't
afford
to
ignore.
B
B
The
studio
I
think
it
may
be
complete
around
now.
We're
gonna
go
class.
Call
what
if
there
really
was
a
you
know
some
heated
discussion
about
this
in
the
list
you
know,
I
was
receiving
a
lot
of
instant
messages
and
texts
and
there's
some
really
interesting
blog
posts.
Nobody
had
anything
to
say
about
this
document,
which
it's
not
surprising.
I
know
that
this
is.
B
This
is
a
pet
cause
of
me,
but
our
idea,
of
course
here,
was
just
to
declare
a
victory
without
really
specifying
much
more
than
a
sketch
of
a
mechanism
and
to
say
put
a
pin
in
it.
You
know
we
kind
of
defined
what
the
problem
looks
like
what
the
solution
space
looks
like
and
if
a
fire
gets
lit
under
this
by
someone
who
say
wakes
up
tomorrow
and
realizes
not
all
telephone
calls,
you
said
maybe
we'll
go,
spend
something
back
up
and
like
use
use
this
for
something
to
be
clear
where
we.
K
B
B
K
A
I
I
I
We
thought
it
would
be
nice
to
have
a
mechanism
that
would
allow
you
to
simply
add
this
without
having
to
define
a
sort
of
like
I,
have
an
example
here
of
a
shaken
Plus,
RCD,
passport
extension,
so
I
think,
because
this
is
probably
going
to
be
pretty
commonly
used,
we
thought
why
don't
we
had
the
ability,
if
you
support
this
specification,
that
you
just
add
an
RCD
claim
to
your
existing
extension
passport
and
all
of
the
rules
that
are
defined
in
this
document
for
interpreting.
That
claim
could
be
followed.
It's
just
at
the
verification
service.
I
B
I
I
H
I
More
than
just
the
name,
so
I
came
up
with
this
term
plain
old,
calling
name
versus
rich
call:
data
clean
off
calling
name
being
you
know
the
mechanism
that
we
all
know
and
love
currently
we're
in
the
from
or
the
paid.
You
include
the
name
and
that's
well
used
in
a
lot
of
scenarios.
So
we
don't
want
to
change
the
mechanism
and
that's
all
described
in
the
current
draft.
I
But
adding
this
new
mechanism,
perhaps
defining
it
as
a
standard
mechanism
as
well
so,
but
the
only
difference
here
is
that
other,
rather
than
the
typical,
including
verifying
the
claim
and
then
doing
a
string
compare
against
what's
in
the
existing
SIP
headers,
you
actually
use
the
passport
as
the
transport
of
the
information.
So
you
know
just
in
particular
for
precise
reasons
to
be.
I
To
be
honest,
you
would
included
the
J
card
in
the
as
a
as
part
of
the
the
RCD
claim,
and
then
you
know
encode
it
and
sign
in
and
then
that
would
actually
be
the
transport
message
mechanism
rather
than
repeating
it
in
the
SIP
header
and
as
a
results.
I
sort
of
have
a
note
here
that,
while
compacts
and
full
form
would
to
be
supported
for
the
name,
you
know
because
we're
transporting
the
information
only
full
form
would
be
supported.
B
Hey
it's
John,
so
yeah
I
think
this.
This
so
I
think
we
definitely
need
it
and
there
are
a
couple
of
different
ways
to
approach
this,
and
probably
we
need
to
do
a
little
bit
of
an
exercise
of
figuring
out
how
we
want
to
approach
that,
especially
and
if
we
just
discussed
this
before
I
know
whether
we
want
to
include
something
like
a
J
card
by
reference
or
by
value.
That
is,
if
we
want
to
have
like
a
URL
in
there.
B
The
interesting
thing
about
the
URL
is,
of
course,
there
are
mechanisms
in
sip
to
convey
a
urls
which
give
information
about
the
call
in
general.
That
could,
you
know
be
repurposed
for
that.
You
could
actually
sign
that
form
style
rather
than
actually
including
it
in
passport.
Necessarily
and
there's
like
a
couple
of
trade
offs
like
that
of
different
ways.
You
might
approach
it
that
are
probably
interesting
and
that
we
should
kick
the
tires
on
a
bed
totally
agreed.
B
Is
it
does
allow
more
flexibility
if
they're
formats
other
than
J
card
say
that
people
are
interested
in
for
this
and
I
haven't
conducted
that
particularly
beauty
contest
myself
of
what
I
think
is
the
best
thing
to
express
the
qualities
of
a
caller.
But
you
know
that
that
might
give
us
basically
just
some
modularity
to
be
able
to
plug
in
different
things.
B
K
This
is
Russ,
we
have
experience
where
a
certificate
contains
a
URL
and
people
realizing
that's
a
longer
lived
thing
than
a
passport,
but
when
that
is
done
often
you
will
see
a
URL
followed
by
a
hash
that
way,
if
you
snap
the,
if
you
choose
to
chase
the
value
from
the
URL,
you
compare
it
what
you
got
to
the
hash
and
that
way
you
know
the
signer
and
the
validator
are
both
using
the
same
dereferenced
value.
Yeah.
L
L
So
I
appreciate
that
in
certificates
having
these
there's
potentially
a
value,
but
the
rich
called
data
I'm
not
sure
that
the
value
is
exactly
the
same
and
so
I
would
I
would
be
hesitant
to
to
do
that.
Unless
you
are
quite
sure
that
for
the
elements
which
you
wanted
to
do
a
URL
and
a
hash
that
the
the
nature
of
the
object
being
dereferenced
was
sufficiently
static
that
these
hashes
were
going
to
last.
As
long
as
the
the
passport
itself
did
so.
K
John
started
his
comment
by
saying:
there
are
other
places
and
sip
where
we
do
this,
and
so
I
was
responding
to
that
thinking
that,
if
we're
going
to
build
a
mechanism,
that's
more
general,
let's
be
were
be
cognizant
that
we
want
to
make
that
some
of
them
will
have
the
situation
where
the
signer
and
the
validator
need
to
be
sure
they
got
the
same
object.
I.
B
L
L
K
L
L
A
L
Sever
D
again,
but
that's
actually
quite
different
right,
because
you're
going
to
you're
going
to
sign
the
J
card
as
an
assemblage
you're
not
going
to
be
trying
to
guarantee
anything
about
the
particular
objects
which
are
key
referenced.
You're,
merely
saying
that
this
is
what
was
presented.
It's
the
J
card
and
the
the
results
of
that
and
the
results
of
trying
to
sign
the
D
reference
value
if
you're
incorporating
it
by
reference,
actually
are
pretty
different
in
a
lot
of
these
situations.
B
B
Size
that
these
things
are
like
growing
to
write
and
if
it's
like
a
shake
and
passport
right
that
we're
then
adding
our
CD
to-
and
you
know
it's
kind
of
like
I,
just
anything
we
can
do
to
like
cut
the
passports,
Dale
and
I.
Think
I'd
like
to
at
least
preserve
a
way
to
do
that,
and
so
that
this
could
be
something
where
we
allow,
both
by
reference
and
by
value
right
that
that
I
think
would
be
fine
with
me
and
yeah.
My
reference
may
have
some
edges
on
it.
B
I
And
I
have
no
opposition
to,
and
in
fact
I
was
like,
including
that
and
I
think
it's
too
early
to
know
what
the
industry
will
do
or
prefer
to
do,
but
I
certainly
could
see
a
future
where
all
J
cards
are
dereference
through
a
URL
for
sure
I
think
we
actually
talked
through
some
of
this
stuff.
I
just
mentioned
here.
Proposing
jcd
as
a
name
and
I
did
make
a
reference
to
the
security
or
verification
of
logos
by
your
eyes,
which
we
just
discussed
so
I
think
other
than
that
I'm
I'm
done.