►
From YouTube: STIR WG Interim Meeting, 2021-04-14
Description
STIR WG Interim Meeting, 2021-04-14
A
B
It's
right
in
the
document
that
says
b64
and
specifies
the
base64
character
set
in
the
grammar
and
it
should
be
url,
save
base64
and
should
specify
the
url
save
base64
character
set
in
the
grammar,
so
the
characters
are
wrong,
but
the
but
the
incorrect
encoding
is
actually
mentioned
throughout
the
document.
It's
not
the
only
grammar,
but
it's
mentioned
in
like
section
for
one
like
in
other
places,
but
it's
can
be
fixed
by
just
going
through
the
document
and
looking
for
everywhere
where
base64
is
mentioned.
B
B
A
E
I
was
just
going
to
say
I
mean
I
again,
I
I
don't
know
how
deep
we
need
to
go
in
in
the
text.
It's
supposed
to
be
enough.
There
are,
there
may
be
a
couple
of
the
places,
but
just
skimming
through
it.
Now
I
mean
places
they're
like
non-normatively,
referring
to
that
it's
b64
encoded.
I
think
it's
okay,
but
like
yeah,
we
let's
do
that
work,
let's
go
through
and
like
check
them
all
and
figure
out,
which
ones
actually
need
to
be
changed.
A
E
I
mean
again
there's
there's
like
three
other
instances
where
it's
mentioned,
like
in
the
document.
As
far
as
I
can
see
just
on
a
quick
find
and
like
I'm,
not
super
worried
about
any
of
them.
To
be
honest,
but
I
mean,
is
this
a
discussion
like
roman,
since
you
kind
of
raised
this
point
I
mean:
do
you
feel
that
those
other
references
are
material
like.
E
I
mean
when
I
read
a
piece
of
non-normative
text
of
the
forum.
After
these
two
json
objects,
the
header
and
payload
have
been
constructed
in
base64
encoded.
They
must
be
hashed
and
signed
per
rfc
8225
section
6.
right.
I
don't
believe
that
needs
to
be
fixed
to
say
b64
url
encoded
for
it
to
like
do
its
job.
E
B
E
A
All
right,
then,
that's
our
action
for
that.
So,
let's
move
on
to
our
double
quote
question,
so
we
explicitly
discussed
several
things
in
this
thread
as
the
as
our
core
documents
were
being
put
together.
So
the
conversations
around
whether
or
not
we're
going
to
change
the
grammar
to
allow
comma
separated
values
or
things
that
that
we
actually
reach
consensus
on,
and
I
don't
believe
that
we're
going
to
try
to
open
this
up.
At
this
point
we
did
have
a
discussion
at
iepf101.
A
I
went
back
and
listened
to
the
recording.
There
was
not
a
lot
of
depth
in
that
discussion.
It
was
basically
a
hey.
Let's
make
a
decision,
let's
require
that
we
put
double
quotes
around
things.
Are
everybody?
Is
everybody?
Okay
with
that,
and
the
answer
was
yes,
we've
got
some
feedback
that
there
are
implementations
out
there
that
are
are
mixing
it,
probably
because
of
implementation
through
example,
or
or
just
mistakes,
and
the
question
now
is:
is
it
do
we?
B
I
I
I
E
So
that,
if
I
get
in
on
this,
I
mean
I
think
it
would
be
okay,
for
me
at
least
to
do
generic
program,
provided
that
we
also
say
we're
asked
you
know
you
should
send,
quotes
right
and
like
do
the
so
I
mean
what
we
don't
want
to
do
is
create
a.
I
agree.
Abn
f,
that
invalidates,
if
quotes,
aren't
present
that
that,
I
think,
is
the
issue
right,
because
if
we
do
that-
and
there
are
implementations
that
are
for
whatever
reason
sending
without
quotes
then
like
they
would
not
be
compliant.
E
B
E
D
B
D
Yes
bring
the
microphone
closer,
so
my
proposal
would
be
to
not
touch
the
grammar
at
all
to
leave
it
at
it
is
which
is
without
code
and
then
to
add
a
sentence
somewhere.
That
said,
receiving
implementation
should
ignore
if
there
is
a
cut
outside.
So
we
don't
don't
change
the
meaning,
which
still
said
that
we
should
send
a
token
without
cutter,
but
if
there
is
cut
outside
just
remove
them
and
treat
it
as
a
as
a
token,
and
it
should
work,
fine.
E
E
J
I'm
not
convinced
that's
true,
I'm
hoping
I'm
currently
reading
the
right
email.
But
from
what
I
can
see.
It
says
that
the
json
value
has
to
be
the
quoted
value
of
the
parameter
on
the
identity
header,
which
would
mean
that
I
read
that,
as
you
put
quotes
around
the
value
in
the
identity
header
and
stick
it
in
the
json
field,
which
is
an
odd
way
of
explaining
it.
But.
E
E
So
no
one
here
has
put
on
the
table
that
implementation
shouldn't
accept
both.
I
think
that's
one
point
we
all
agree
on
right
like
every
example,
the
question
is
really
just
what
is
the
least
intrusive
least
problematic
fix
we
can
make
to
this
so
that
there's
no
more
confusion-
and
you
know
I
think
mark-
may
have
been
barking
up
the
right
trade
on
this.
In
the
sense
of
I
mean
the
the
least
intrusive
and
most
compatible
fix
is
just
to
say
that
implementation
should
treat.
E
This
is
identical,
but
I
still
don't
think
that
take
that
gets
us
off
the
hook
of
having
to
say
here's.
What
you're
supposed
to
do
right
right,
like
I
said
that
we
were
under
some
obligation
to
give
guidance
on
whether
it's
supposed
to
be
quoted
or
unquoted,
even
if
you're
supposed
to
wait
from
what
you're
supposed
to
say.
E
Agree
entirely-
and
this
was
exactly
a
discussion
at
itf
101,
which
is
why
that
discussion,
as
robert
said,
was
so
kind
of
you
know
high
level,
because
because
it
doesn't
matter,
I
agree,
and
so
like
you
know,
we
basically
we
flipped
the
coin,
perhaps
and
we're
like
okay,
we'll
do
quoted
and
like
if
we
want
to
keep
flipping
coins
until
we
get
different
results.
We
can
do
that
but,
like
I
don't
think,
that's
a
good
use
of
our
time.
Let's
just
do
quoted.
F
E
E
A
A
A
A
I
A
I
L
A
Webex
roster,
but
I
guess
there's
a
chance
that
we
lose
the
webex
roster
on
the
recording.
So
yes,
please
help
make
sure
that
the
kodi
md
is
correct.
Would
somebody
cover
getting
me
into
that
and
if
it
hasn't
already
been
posted
to
the
webex
chat
yeah,
it
looks
like
russ
posted
the
cody
md
link
to
the
webex
chat.
A
E
A
A
A
A
F
F
Two
new
additions
to
error
handling
one
is
directly
adapted
from
some
of
the
addis
specs
that
I
thought
would
be
useful
to
define
over
an
ietf
side
and
then
the
other
one
is
something
new.
So
first
one
is
essentially
the
mechanism
that
the
way
we
have
it
in
82,
20,
sorry
80
to
24,
is
that
for
the
400
errors
that
will
that
that
is
essentially
killing
the
call.
F
So
we
wanted
to
allow
for
not
having
to
kill
the
call,
even
if
you
have
an
error
with
verifying
the
the
the
identity
header.
So
we
define
the
mechanism
that
you
should
send
the
reason
header
with
the
error
code
in
provisional
responses
or
final
responses
back
to
the
authentication
service
just
to
let
them
know,
but
in
general,
in
the
shaken
world
we
didn't
want
to,
and
we
still
don't
necessarily
want
to
kill
calls
because
of
the
verification
status
would
may
have
failed.
F
F
F
So
this
was
sort
of
a
proposal
to
solve
the
case
where
you
might
have
some
identity,
headers
that
pass
verification
and
some
that
may
not
pass
verification,
and
if
you
send
the
reason
code
back,
how
do
you
identify
which
ones
have
errors
and
which
ones
don't
have
errors
and
sort
of
thought
through?
You
know
like?
Is
there
some
way
we
can
identify
it?
We
just
thought
the
easiest
and
best
way
to
do.
F
D
D
F
E
E
F
K
F
B
F
F
B
B
E
It
would
it
could
potentially
at
least
give
you
an
insight
into
where
else
in
the
network
for
forensic
purposes,
things
were
dysfunctional
now
what
I
can
see
both
sides
of
that
coin.
It
could
be,
you
know,
there's
a
privacy
revelation
or
something
people
are
concerned
about
from
that,
but
like
that,
that
would
be
the
case.
It
would
be
something
where
a
passport
was
subsequently
added.
You
know
this.
This
could
be
like
a
delegate,
cert
originally
signed
it,
and
then
the
second
passport
was
added
for
shaken
purposes.
F
E
F
E
Yeah,
that's
unbalanced.
I
could
see
doing
compact.
For
that
reason
you
know
I
mean
if
we
want
to
get
fancy,
we
could
also
put
rules
right
about
what
you're
supposed
to
do
when
you're
generating
this
object.
As
the
the
sender
that,
like
for
div,
for
example,
you
only
only
send
compact
form
and
there's
there's
a
bunch
of
things
like
that.
We
could
do
if
we
felt
like
a.
D
E
F
J
E
That's
that's
we're
considering
now
so
we're
considering
case
service
like,
for
example,
where
you
know
three
diff
passports
have
been
added
right
and
like
one
of
them
fails,
and
so
you
get
back
here's
the
thing
that
failed
and
like,
but
you
know
you're
revealing.
Potentially,
if
you
put
the
full
form
passport
in
something
about
the
service
logic
that
led
to
that
diversion
and.
F
E
K
Well,
so
if
let's
say
just
talking
about
service
providers,
service
provider,
a
creates,
a
shaken
passport
sends
the
call
to
service
letter
b,
who
creates
a
div
passport
who
sends
it
to
c
search
letter
a
never
had
the
div
password.
I
never
saw
it
so
if
search
letter
c
sends
back
a
response,
you
know
200
whatever
response
code
with
both
passports.
If
service
letter
b
leaves
that
in
and
sends
the
200
to
a
then
service
fighter,
a
now
sees
the
div
passport.
E
E
E
I
mean
operationally:
is
it
useful
to
be
able?
I
guess
this
is
maybe
a
point
in
just
the
a
to
b
case,
like
if
b
feels
like
sharing
this
information
in
the
backwards
direction,
because
it's
helpful
to
a
like,
I
think,
having
a
mechanism
like
this
is
worth
doing.
That's
kind
of
how
I
felt
about
the
600
error
codes
as
well.
J
F
I
I
I
do
agree
with
adding
some
something
about
the
framework
where
the
authentication
service
that
we
that
sent
that
passport
should
terminate
the
reason
and
or
strip
the.
I
guess,
we'd
want
to
just
remove
the
the
reason
header
right
and
the
multi-part
mine
body
that
would
be
the
stripping
would
be
essentially
right.
B
B
B
E
We
could
consider
that
yeah
that
plus
some
guidance
as
jack
was
suggesting,
I
think,
would
get
us
a
pretty
long
way
in
terms
of
covering
privacy
for
service
logic
when
it
matters
and
still
having
the
flexibility
to
be
able
to
do
this.
I
I
think
it
is
actually
quite
valuable
to
be
able
to
do
this,
especially
for
success
cases
where
you
know
you
just
want
to
be
able
to
express
in
the
backwards
direction.
Sorry,
this
didn't
work
to
the
people
that
generated
it
and
here's.
Why.
B
F
K
Not
to
derail
this,
but
you
know
one
interesting,
maybe
thought
might
be,
does
it
make
sense
to
put
it
in
the
reason,
header
and
not
use
a
custom
header?
I
know
we
right
now
use
like
an
x,
authentication
or
verification
failure.
Reason,
because
we
sometimes
you
want
to
have
the
reason
be
for
other
purposes,
and
it
makes
it
more
clear
that
you
know
this
is
the
shaken
reason
that
the
call
may
have
been
accepted,
but
some
other
reason
for
some
other
failure.
You
know
analytics
or
you
know
whatever
thing
you
know,
using
the
reason.
B
K
We
we
don't,
you
know,
we're
not
really
operating
a
switch,
so
kind
of
that's
up
to
a
service
provider
we,
but
we
in
the
vs,
with
a
sip
interface,
respond
back
with
a
custom
x
header
for
verification
response.
That
is
frequently
proxy
backed,
but
you
can't
you
could
so
I
can't
really
answer
that
because
we
don't
really
specifically
do
anything,
but
we
provide
an
x
editor
that
is
frequently
used.
Okay,.
B
F
A
C
A
Okay,
so
I'm
going
to
attempt
to
stop
sharing.
Has
that
done
the
right
thing?
Yes,
yes,
all
right!
My
apologies
for
the
errant
application
behavior.
I
will
review
the
recording.
I
may
have
to
ask
the
secretariat
to
redact
some
of
the
other
things
that
popped
up
before
the
recording
is
posted
and
again
my
apologies.
A
C
Okay,
so
I
think
ben
raised
a
question
about
matches
within
the
values
for
the
must
include
or
must
exclude,
and
so
to
address
those.
I
think
that
most
of
the
actual
use
cases
use
simple
values,
strings
or
numbers,
and
we
can
deal
with
some
simple
text
about
that.
Like
numbers,
you
need
to
compare
the
numbers,
not
the
string
that
carries
the
number
so
that
leading
zeros
and
stuff
like
that
are
not
an.
K
C
Regarding
more
complex
structures,
where
you
could
have
things
in
different
orders,
I
don't
think
we
have
many
of
those
cases,
but
we
can
put
some
warning
text
in
here
about
how
to
deal
with
them.
Basically,
you
know
if
you
have
something
where
red
green
blue
can
appear
in
any
order.
If
you
really
want
to
exclude
it,
you'll
have
to
put
all
the
permutations
yuck
hope
we
don't
ever
actually
have
to
do
that.
C
C
L
L
I'm
not
sure
I
see
one
for
rcd
and
the
reason
for
that
is
is
there's
so
many
ways.
A
bad
actor
could
evade
and
exclude
value,
given
that
a
lot
of
rcd
is
aimed
for
human
consumption,
and
so
you
run
into
the
fusible
string
problem,
you
run
into
all
the
string
identifier,
problems
with
confusable
strings
and
things
like
that.
That
are
ways
that
you
can
just
trivially
sneak
past
the
verifier.
That's
trying
to
verify
and
exclude
values
things
I
wonder
to
me.
Absolute
values
makes
a
lot
more
sense.
L
If
you
have
a
claim
whose
values
are
a
strict
enumeration,
you
know
maybe
rph
or
something
like
that
where
you
have
known
values,
people
can't
just
make
up
so
the
example
I
had
I
was
sharing
with
robert
earlier
is
so
I'm
a
bad
actor,
and
I
want
people
to
answer
my
call.
So
I'm
going
to
stick
potus,
president
of
the
u.s
photos
in
my
display
name.
I
can't
remember
the
claim
off
hand,
and
oh
so
you
put
in
a
musty,
exclude
value
for
potus.
L
C
A
C
A
E
I
mean
the
point
is,
I
would
put
a
little
differently
for
most
of
the
cases
where
there
are
a
constrained
set
of
things
you
want
to
exclude
what
you
actually
want
is
included
values
right
absolutely
like
I
want
to
say
your
included
values.
Level
of
attestation
is
b
and
c,
and
don't
include
that
right
and
so
like
both
must
include
and
must
exclude.
Have
you
know
effectively
the
same
properties,
for
those
values,
except
must
include,
is
an
additive
permission
that
is
very
clear
about
what
you're
assigning
and
the
other
one
is
not.
Chris.
F
Yeah,
I
I
agree
with
the
conclusion
there
that
excluded
claimed
is
definitely
needed,
but
how
do
you
there
is
a
lot
of
loopholes?
I
agree
with
ben
on
that
point,
but
there
may
be
some
so
I
I
could
go
either
way
really
on
whether
we
keep
it
or
not
keep
it.
But
I
think
you
would
have
to
put
some
pretty
explicit
security
concerns
about
you
know
trying
to
found
things
or
eliminating
it
to
its
explicit
values.
E
L
So
I
was
trying
to
think
about
it.
I
was
trying
to
think
about
this
just
earlier
today
and
thought.
Well,
maybe
there's
some
case
where
we
have
this
set
of
permitted
values
except
you're
not
allowed
to
use
one
of
the
permitted
values,
and
then
I
convince
myself.
No,
that's
dumb
you,
you
wouldn't
ever
do
that.
L
So
I
agree
with
you
and
unless
there
was
some
case
where
the
exclu,
where
the
the
only
thing
I
could
think
of,
if
the
enumeration
is
really
really
big
but
still
constrained,
you
might
not
want
to
put
the
whole
enumeration
in
just
a
safe
space,
but
that's
otherwise.
I
think
this
is
a
attractive
hazard
feature.
E
Yeah,
it's
also
not
a
very
forward
compatible
approach
to
it
is
the
other
thing
that
you
know,
because
if
you
are
then
defined
values,
for
example,
you
need
to
exclude
those
explicitly
rather
I'd.
Rather,
you
know
then
force
people
to
change
the
certs
to
introduce
new
things
to
exclude
like
in
an
on
an
emergency
basis.
You
know
the
day
after
a
new
value
is
approved
for
this,
do
it
the
other
way.
E
K
L
K
M
K
You
you
know
if
you,
if
you
excluded
rph,
but
you
also
wanted
to
exclude
this
new
claim,
you're
kind
of
in
the
same
position.
So
is
it
not
better
to
say
if
this
user
is
not
allowed
to
do
any
claim,
including
all
future
claims,
here's
the
ones
they're
allowed
to
do
so
that
it
fails
closed?
They
can't
do
that
new
claim.
Otherwise,
you
have
to
redefine
the
search.
H
F
B
M
K
K
Because
if
you
do
exclude
and
then
a
new
claim
is
defined,
you
know
they've
now
got
additional
permissions
versus.
If
you
do
a
permitted
of
nothing.
That's
what
I'm
saying
you
know
not
that
excluding
claims
is
not
important,
but
isn't
the
better
way
to
exclude
claims
to
list
the
allowed
claims
well
even
base.
E
E
L
E
I
bet,
but
if
we
introduced
something
that
was
like
you
know,
these
are
the
only
claims
they're
allowed
to
be
in
the
passport
right
and
like
that.
That's
the
way
we
frame
this.
We
would
be
running
a
valve
ben's
innovation
argument,
precisely
so
like
the
criticality
of
certain
things
that
we're
adding.
I
agree
that
with
alec,
this
is
an
issue.
F
F
C
K
K
L
L
E
Yeah,
I
think
I
think
I
agree
that
there
is
some
value
actually
in
being
able
to
do
that,
even
though
it's
not
future
proof
like
I
said,
and
I
I'm
kind
of
wary
of
the
the
implication
that,
like
you,
can't
have
proprietary
things,
for
example,
or
just
non-standard
things
that
you
choose
to
add
to
the
job.
That's
yeah.
F
Does
prevent
that,
but
is
there
any
mechanism
that
we
can
use
that
says
like
you
can
use
whatever
you
want
as
long
as
it's
not
ayana
defined,
or
something
like
that?
You
know
like
special
ones
that
that
have
special
uses,
but
you
know,
if
you
have
something
outside
of
that
set,
you
know,
go
go
for
it.
Should
we
put
some
rule
like
that,
keep
in
mind
that.
L
E
I
mean
we
still
want
to
have
shaken
passports
that
have,
you
know,
ran
well
rcd
and
them
are,
for
example,
right,
but
like
that
aren't
necessarily
passports,
but
the
yeah.
My
point
was
more
if
it
has
a
ppt.
In
other
words,
if
we,
if
we
separate
claims
into
two
buckets
one
that
is
special
super
claims,
we're
concerned
about-
and
the
other
is
like
you
know
not
so
much
then,
and
that
the
bar
between
those
two
could
be.
Does
it
have
a
ppt.
K
I
mean,
if
you
do,
let's
say
we
created
may
include,
which
is
the
list
of
claims
that
you
may
include,
but
we
treat
that
as
if
you
include
something
outside
of
that
list,
the
vs
should
not
interpret
that
as
you
had
authority
over
it,
but
that
doesn't
mean
it
can't
trust
the
passport.
It
just
needs
to
be
aware
of
that
value.
So,
for
example,
let's
say
you
know
just
here's
a
thing
that
I
think
would
be
useful
passports
had
a
jti
parameter
to
uniquely
identify
them.
K
You
could
include
that
that
doesn't
need
to
be
trusted
by
the
other
end.
It's
just
for
you
know,
traceback
kind
of
whatever
you
want
to
use
it,
for
that
may
include,
may
not
specify
that,
and
that
just
means
the
vs
shouldn't.
Take
that
as
authoritative
information
doesn't
mean
that
they
should
just
outright
reject
the
passport,
because
it
has
a
claim
that
wasn't
in
the
may
include
list.
L
E
A
F
Yeah,
so
I
think
I
can
just
give
an
update
we
in
the
last
meeting
we
did
discuss
the
major
changes
to
the
integrity.
I
haven't
gotten
a
lot.
We
we
had
good
discussion.
I
think
on
that
call,
but
I
haven't
gotten
any
real
further
feedback
on
it.
So
you
know
I
don't
know
if
we
want
to
wait
for
any
more
feedback
or
if
we
want
to
proceed
with
that
document.
Any
comments
that
anybody
has
in
this
forum.
E
E
M
K
E
K
Sorry
I
haven't
been
as
caught
up
on
this.
The
the
oh
are
you
saying
the
ish
iss
claim
in
the
rcd
passport
would
have
to
match
the
organization
attribute
in
the
subject
the
end
of
the
certificate
that
signed
it
yeah,
one
one
problem
with
that
that
I
was
dealing
with
in
the
ad
is
kind
of
looking
at
one
of
those
documents.
At
least
the
way
it's
currently
defined.
K
A
potential
problem
is
that
there
can
be
non-unique
organization
names
like
I
know
there
are
many
service
fighters
that
have
the
same
name
across
different
states.
So
does
that
you
know
if
you
mandated
that
it
has
to
be
the
o.
The
way
that
some
of
the
addis
documents
say
kind
of
the
o
would
be
duplicated,
potentially
across
different
organizations.
E
Yeah,
but
I
mean
the
good
news
about
addis-
is,
of
course,
that
it
has
this
whole
like
certificate,
issuing
structure
and
guidance
around
that
right,
and
so
I
mean
there
are
all
kinds
of
things
that
could
be
done
to
ensure
the
uniqueness
of
oh
in
a
constrained
context
like
that
now
out
in
the
open
world
beyond
the
stij
scope.
This
is
an
entirely
different
issue,
but
I
think
for
average
that
should
that
that
should
be
doable
right
like
you
would
just
have
some
different
way.
You
would
describe
entities
that
are
different.
E
F
K
No
they're
kind
of
yeah
outside
of
addis
there
kind
of
can't
be
because
the
within
you
know
with
subject
not
issuer.
If
you,
if
you
combine
both
subject
and
issuer,
then
it's
not
a
problem,
but
you
have
multiple
cas,
so
they
they
can't
really
necessarily
do
anything
to
ensure
that
there's
uniqueness
across
the
cas
the
advantage.
K
What
addis
has,
though,
is
that
there's
this
ocn
that
if
you
include
the
ocn,
then
you
know
you
have
a
reasonable
sense
that
you
know
it's
not
duplicates,
although
technically
I
guess
a
service
writer
could
get
assert
from
two
different
cases
right,
but
but
that
is
still
the
same
entity.
If
you
include
the
ocn,
it's
I
mean
it's
still
the
same
issuer
entity.
The
problem
is
just
that
the
organization
does
that
necessarily
include
the
ocn
that
gets
funny
when
you
have.
F
F
E
L
So
I
was
under
the
impression-
and
maybe
I'm
wrong,
because
other
people
know
the
added
stuff
better
than
I
do
that
the
addis
definition
of
the
o
in
a
certificate
was
just
kind
of
informational
to
make
it
easier
for
troubleshooting
and
stuff
and
people
looking
at
it
to
understand.
I
it's
important
to
me.
They
would
ever
try
to
match
against
it.
G
G
E
E
And
all
we
want
in
this
value
is
to
have
something
like
that.
That's
the
point
we
want
to
have
something
that
says
the
entity
issued.
This
is
canonically
known
as
this.
We
don't
want
people
to
just
be
able
to
arbitrarily
set
that,
so
there
has
to
be
some
process
right,
like
the
ca
process
and
at
us
that
you
know
at
least
it
doesn't.
Let
nustar
claim
that
it's
yeah,
you
know
as
long
as
that
exists
and
there's
like
a
human,
readable
field
in
the
s
that
indicates
who
this
entity
broadly
is.
K
E
And
honestly,
I
I
don't
think,
there's
there's
a
ton
of
practical
difference.
I
mean
it
like.
I
said
I
think
the
intention
was
just
that
there'd
be
something
human
readable
in
the
passport
that
indicates
roughly
who
the
organization
is
and,
like
you
know,
doing
the
whole
subject.
Yeah
might
be
overkill
for
that,
but
like
if
people
think
there's
some
material
distinction.
Certainly
we
can
look
at
that.
E
I
mean
not
maybe
a
little
really
like
in
the
sense
of
I
think.
Like
I
said
it's
it's
useful.
It's
certainly
useful
that
nustar
not
trying
to
be
able
to
pass
itself
off
as
a
t
right,
so
I
mean
I
want
something:
that's
human
readable
that
has
some
forensics
around
it.
That
indicates
yeah
like
this.
This
is
the
entity
is
supposed
to
be,
and
yeah
be
good.
If
you
check
that
against
the
o
field
in
the
actual
cert.
F
The
important
part
is
that
it's
representing
that
the
information
came
from
a
third
party,
not
the
so
and-
and
you
know,
will
you
want
to
represent
that
to
the
user?
Somehow,
maybe
will
you
want
to
have
reputation
over
those
third
parties?
Maybe,
but
I
think,
that's
part
of
the
whole
framework
that
people
have
to
figure
out
going
forward.
K
E
If
you're
doing
reputation,
you
would
do
it
from
the
cert.
That's
the
point.
This
is
just
like
a
human
readable
hint
that
we're
embedding
into
the
passport
like
you,
you
reputation
should
be
based
on
rights
like
signed
it
and
that
should
be
based
on
the
cert
itself
and
so
again
I
look
at
look
at
this
as
just
an
indication
that
it
is
a
third
party
source.
F
F
J
Was
my
point
right
like
it
just
matters,
we
fix
it
one
way
or
the
other.
It
was
very
unclear
to
me
when
I
read
it
that
the
verifier
should
not
be
machine.
Checking
that
iss.
It
seemed
like
the
that
that
claim
needed
to
be
checked
in
order
to
know
whether
or
not
to
trust
the
rcd.
I
think
I
agree
that
that
that's
not
true,
you
should
just
be
checking
the
certificate,
but
it
hadn't
quite
occurred
to
me.
While
I
was
reading
it.
C
So
as
the
shepherd
for
this
document,
I'm
a
little
bit
confused
about
what
change
people
want
and-
and
I
warn
you
that
ldap
went
down
this
path
of
taking
a
subject-
name
and
converting
it
to
a
text
form
and
back
and
forth
and
they're,
not
always
one
to
one
and
onto
so.
I
think
we're
much
safer
if
we're
able
to
pick
a
portion
of
the
name
that
must
be
used
here.
K
I
think
I
think
so
long
to
john's
point
so
long
as
it's
clear
that
it's
not
used.
You
know
the
the
iss
claim
is
not
used
by
a
machine,
it's
purely
for
a
human.
It
doesn't
really
matter
as
long
as
people
don't
interpret
the
document
as
oh
I'm
going
to
use
that.
For
my
you
know,
reputation
analytics.
No,
that's
a
bad
idea,
then
yeah.
I
agree.
I
don't
think
it
matters.
F
K
K
F
C
A
A
C
E
It
is
that's
that's
why
I
was
kind
of
hesitating
on
this
as
well
yeah,
I
feel
like
the
addis
test.
Bed
is
specific
to
shaken
right
and
like
if
the
itf
is
doing
this,
I
don't
really
feel
like.
We
should
be
measuring
shaking
compliance,
not
that
that's
the
the
hard
edge
on
this,
but,
like
I
mean
in
principle,
there's
nothing
I
think
precluding
us
getting
together
and
just
making
sure
implementations
work
together.
It
just
would
not
be
we're
going
to
make
this
compliant
with
like
this
out
of
spec.
C
F
G
J
B
B
Well,
one
of
the
things
that
I
see
and
then
again
I'm
not
sure
how
to
address
that,
like
the
issues
that
I
see
are
from
like
big
sbc
vendors
like
ribbon
and
I'm
not
sure
they
participate
in
the
ietf
directly.
At
least
I
haven't
seen
anybody
from
them
and
just
there
should
be
a
way
to
get
figure
out
a
way
to
get
them
involved.