►
From YouTube: IETF111-COSE-20210728-2130
Description
COSE meeting session at IETF111
2021/07/28 2130
https://datatracker.ietf.org/meeting/111/proceedings/
A
A
A
Like
all
the
itf
meetings,
this
is
covered
by
the
note.
Well,
you'll
find
this
in
the
chair,
slides
online
and
many
other
places.
A
So
the
administrivia
we're
in
the
middle
of
we'll
talk
about
document
status,
eva
we'll
talk
about
the
kaze
x,
509
status.
The
editors
will
talk
about
the
c
encoded
cert
status,
kyled
and
hartug
will
talk
about
individual
draft
proposing
to
register
some
curves
and
that
actually
brings
up
a
position
that
the
chairs
and
ben
thought
it
might
be
useful
to
have,
which
is
what
criteria
we
want
to
have
for
registering
additional
algorithms
within
the
working
group.
A
So
importantly,
we
need
people
to
participate
in
note
taking
for
us
to
have
an
official
meeting,
so
I
would
like
to
ask
the
people
present
if
one
or
more
of
you
would
be
willing
to
collaborate
in
the
collaborative
note
taking
session
there.
A
A
Okay,
so
we
have
your
idea
is
not
great,
but
I
think
we
have
a
minute
taker.
Is
that
correct?
Yes,
okay,
great
and
I'd
like
some
people
to
also
be
monitoring
the
jabber
and
feel
feel
free
to
interrupt
me
or
the
other
presenters?
If
something
comes
up
in
jabber
that
you
feel
should
be
discussed
in
real
time
all
right.
Are
there
any
amendments
that
people
would
like
to
make
to
the
agenda
before
we
continue.
B
A
Okay,
who
proposed
that.
A
Okay,
thank
you
all
right.
These
are
the
documents
in
the
working
group
repository.
There
are
three
of
them,
which
are
the
best
documents
to
take
coza
to
internet
standard
status.
A
Those
are
in
auth
48,
with
the
rfc
editor
in
lieu
of
jim
shad,
not
being
matt
miller,
is
responding
to
the
auth
48
comments
in
order
to
get
this
done
so
look
forward
to
three
new
working
group.
Rfc
internet
standard
status,
not
too
long
russ
is
leading
the
countersign
effort.
A
Evo,
is
in
charge
of
the
x
509
effort,
and
the
editors
are
leading
the
seaboard
encoded
cert
work.
Are
there
any
comments
that
people
want
to
add
to
document
status.
A
All
right!
Well,
if
that's
the
case
first
matt,
I
know
you
don't
have
slides,
but
is
there
anything
that
you
want
to
say
about
the
the
best
documents.
A
A
B
B
B
B
Point
that
I
know
for
this
thing
is
that
we
were
waiting
ben
to
save
the
new
texts.
Resource
case
concerns,
so
then,
if
you
could
check
this,
that
would
be
really
appreciated
and
yes.
B
Okay,
thank
you
and
then
there
is
one
extra
issue
that
was
suggesting
and
not
using
strings
at
all
for
representing
some
data
in
some
cases.
Right
now
we
can
either
have
like
a
binary
string
if
we
have
only
one
element
presenter.
B
We
have
an
array
if
we
have
multiple
elements
and
there
was
a
suggestion
to
simplify
the
protocol
by
removing
one
of
the
options,
and
my
personal
opinion
is
that
this
might
be
inconsistent
with
other
places
where
we
are
supporting
compost-
and
I
am
inclined
not
to
to
take
this
suggestion,
but
it
has
other
people
have
other
opinions.
B
B
People
from
so
for
that
text,
I'm
not
sure
I
would
be
the
best
person
to
write
it.
B
B
So
from
my
point
of
view,
those
are
all
the
open
questions
for
this
document.
I
really
hope
we'll
be
able
to
finish
it
soon,
and
there
are
some
external
dependencies
on
the
document
which
kind
of
try
to
urge
us
to
finish
it
sooner
so
or
at
least
provide
feedback.
If
we
would
be
changing
anything
substantial.
B
A
A
G
So
this
is
seabor
encoded,
x509
c509,
this
presentation.
I
think
it
will
be
quite
quick
and
it's
a
bit
recap
from
the
previous
interim
since
110.
G
We
have
new
things
are
rpki
and
russ
was
nice
enough
to
provide
us
with
the
example
certificate
which
we
had
now
support.
We
also
read
the
gsma
certificate
profile
for
e-uscc
and
adopted
the
spec
to
be
sure
to
support
that
michael
has
provided
a
dev
id
search.
The
spec
should
be
compatible
with
dev
id,
but
I
will
as
soon
as
I
have
time.
I
will
test
my
implementation
and
respect
with
michael's
tester
to
get
an
update
if
needed.
G
G
So
sadly,
the
draft
now
supports
all
the
extensions
in
five
two
eight
zero,
at
least
all
this
certificate
extension.
I
think,
through
some
crl
specific
extensions
that
are
not
supported
yet
the
following
are
extensions,
are
fully
supported.
G
Then
there
are
more
extensions
that
are
only
partly
supported
and
basically
every
certificate
we
have
a
scene
is
supported,
but
there
are
some
more
exotic
options
or
combinations
that
we
do
not
support
in
the
seaboard,
encoding
and
and
more
comments
on.
These
would
be
very
we're.
Gonna
be
happy
to
receive
then
there's
here
more
extensions
that
are
also
partly
supported.
G
The
csr
looks
like
this,
and
this
was
very
easy
to
specify
using
all
the
existing
definitions
yeah.
I
think
we
right
now.
It's
specified
that
you
can
request
two
types
of
both
types
of
certificates
and
the
yeah.
G
G
There
was
some
discussion
of
the
signature
format
and
I
think
also
we
have
comments
that
attributes
are
needed
for
extensibility
that
needs
for
discussion.
We've
done
the
similar
thing
for
crl
at
some
earliers
in
stream.
It
was
yesterday
c509
should
support
signing
requests,
crl
and
ocsp.
G
I
have
done
the
first
draft
on
crl.
That
was
also
very
easy
to
using
the
existing
definitions.
I
think
there's
some
certificate
serial
extensions
that
are
not
supported.
Seabor
encoding
of
them
are
not
supported.
These
have
not
been
tested.
I
think
there
could
be
a
discussion
if
we
want,
is
the
group
still
wanting
crl
and
ucsb
and
should
then
should
they
be
in
the
same
document
or
should
they
potentially
be
an
another
right
now?
This
seem
quite
easy
to
include
in
the
same
tournament,.
G
Here's
a
table
showing
the
sizes
of
the
cosi,
x509
and
cosi
c509
and
it's
the
first
is
a
very
typical
iut
certificate
and
there's
where
c509
do
a
very
big,
quite
big
relative
difference
and
general
compression
algorithm
doesn't
work
c509,
also
compresses
http
certificate
chains.
Quite
much
and
here's
two
examples.
This
is
or
www.idef.org
and
tools.idf.okay.
G
G
G
In
that
case,
then,
we
have
the
rpka
I
certificate
and
you
can
see
that
c49
is
to
start
with
a
bit
more
efficient
than
yes
broadly
and
that
both
combined
provides.
G
Basically
one
of
them
provides
half
size
and
both
of
them
provides
a
quarter
size,
and
this
is
quite
a
large
difficult.
I
don't
know
how
how
that
well,
that
represent
the
average
rpki
sort
of
get
then
three
different,
two
different
same
change
and
back
and
as
you
can
see
here,
what
you
can
get
all
using
both
c5009
and
broccoli.
You
shave
basically
400
bytes,
for
this
https
shapes.
G
E
Of
those
chains
on
the
previous
slide
and
I
wanted
to
apply
sibo
pack
to
it
just
to
see
what
happens.
Unfortunately,
I
uncovered
a
bug
in
my
zebra
effects.
Implementation-
and
I
haven't
had
time
to
fix
that.
So
I
would
love
to
report
numbers
today,
but
maybe
on
friday
in
the
siber
meeting.
G
Yeah,
okay,
looking
forward
to
that-
and
here
is
some
issue
regarding
that-
I
think
conclusion
that
one
option
would
could
provide
broadly
in
the
c5
serum
nines,
but
that's
not
very
useful.
For
iot,
we
discussed
that
in
the
interim
and
carson
said
need
we
should
discuss
what
the
use
case
is
for
that.
She
also
discuss
if
seaboard
packed
how
that
works
or
it
can
if
it
can
be
used
to
work
better.
I
think
simple
practice
is
a
better
solution
for
iot
devices.
G
G
G
G
A
A
A
We
can
do
powerpoint
karaoke
if
you
will.
F
There
does
seem
to
be
enough
text
in
the
slides
that
it
it
could
be
worth
out,
especially
given
that
I
don't
think
there's
much
else
on
the
agenda.
A
So
for
the
minutes,
I'm
curious
what
fraction
of
you,
of
course
we're
not
in
person.
A
I
can't
just
people
raise
hands
easily,
I'm
curious
how
many
of
you
have
heard
of
what
they
call
pairing
friendly
curves
in
the
cryptographic
literature.
Maybe
those
of
you
who
know
something
about
it
can
say
something
in
the
chat
just
for
the
record.
A
These
are
used
for
zero
knowledge,
proof,
algorithms,
some
of
which
are
being
used
in
the
decentralized
identity
world.
At
this
point
that
much
background,
I
do
know
for
sure.
A
A
Let's
see
dan
benet
is
who's
a
long
time
ago.
Use
nick's
friend
of
mine
as
one
of
the
bees
who
was
the
inventors
of
that
signature
scheme
and
their
choice
of
curves
for
this
scheme
is
something
called
bls12
381
and
there's
different
representations
of
that,
and
currently
there's
no
either
jose
or
jose
registrations
for
those
curves
or
any
of
the
friends
of.
A
They
and
there
is
an
irtf
document,
as
he
points
out
on
pairing
friendly
curves,
and
that
builds
upon
that.
So
the
notion
of
pairing,
friendly
curves
is
known
to
the
irtf,
which
are
our
crypto
experts
and
it
does
registrations
for
the
128
bit
security
and
256
bit
security
curves
for
these
curves.
A
A
A
I
know
there's
other
rep
representations
in
the
wild
for
compressed
point
curves
that
just
use
the
number
in
the
dead
world.
I'm
not
advocating
that.
But
I
think
that's
what
he's.
A
So
I
asked
a
question
to
kyle
offline.
I
felt
like
this
was
kind
of
incomplete
because
curves,
without
corresponding
signing
algorithms
or
at
least
saying
how
to
make
use
of
them
sort
of
don't
give
us
an
end-to-end
solution.
Now
I
recognize
that
in
his
use
case,
there's
a
w3c
community
group
defining
the
use
of
this
particular
bbs
plus
scheme,
and
so
this
would
support
that.
But
in
general
I
would
think
in
the
ietf.
A
He's
asking
what
would
be
the
best
path
forward
for
this
draft
and
the
last
bullet
I
really
can't
speak
to
about
curves
registered
with
prohibited
steps.
F
So
I
will,
I
guess,
chime
in
unless
jonathan
wants,
to
join
the
queue,
but
my
understanding
here
is
that
the
bn256,
g1
and
g2
are
going
to
correspond
to
these
sub
groups
that
were
in
the
third
bullet
point,
and
so
my
sense
is
that
in
general,
it's
good
to
have
identifiers
for
these
things.
If
we
are
going
to
need
to
refer
to
them
and
the
code
point
space
for
curve
names
is
not
particularly
scarce.
F
So
on
the
face
of
it.
The
proposal
to
to
register
these,
but
to
have
in
the
comments
or
other
notes,
an
indication
that
these
are
sort
of
placeholders
they're
not
expected
to
be
used
for
actual
signatures,
but
they
might
appear
in
protocol
elements
that
require
a
curve
for
some
of
these
other
uses
that
take
advantage
of
the
pairing
friendly
nature
of
these
curves.
F
So,
on
the
face
of
it,
the
proposal
to
register
them
but
give
them
a
prohibited
status,
does
seem
to
make
some
sense.
But
I
will
yield
to
jonathan
who
has
gotten
into
the
queue.
H
Yeah,
double
click
yeah,
so
the
the
issue
with
the
bn256
curves
is
that
there
was.
There
was
an
attack
that
reduced
they.
They
were
believed
to
have
128-bit
security,
but
there
was
an
attack
that
reduced
the
security
to
100
bits.
So
generally
there
were,
they
were
well
deployed,
but
there's
been
a
number
of
efforts
in
different
standards:
organizations
to
define
new,
more
secure
bn,
curves.
E
Minutes,
well,
I
think
the
the
oh
sorry,
I
think
the
one
thing
we
need
to
discuss
at
some
point
is
the
comments.
So
there
are
several
references
to
sec.
One
here.
Is
that
really
the
form
we
want
these
to
be
in
or
do
we
actually
use
something
more
like
okp,
so
yeah
I
haven't
read
the
irtf
draft.
This
is
apparently
based
on,
so
that
seems
to
be
stuck
on
the
document
shepard
for
54
days,
so
we
probably
have
to
ask
stanislav
what
status
that
has.
A
F
F
Since
you
know,
if,
if
we
can
use
okp,
that
would
be
good.
So
the
question
I
guess
would
be
then,
to
kyle
or
to
anyone
else
about
whether
there's
existing
deployments,
where
these
curves
are
strongly
associated
with
scc1
encoding,
because
we
don't
want
to
go
off
and
do
something
different.
Just
for
the
sake
of
something
different.
A
A
Among
the
chairs,
because
of
this
presentation,
I
both
depict
the
brains
of
the
working
group,
members
and
possibly
ben
as
ad,
and
how
should
we
be
thinking
about
when
it
makes
sense
to
accept
a
draft
to
register
new
cryptographic,
algorithms
and
curves
and
what
criteria
we
want
to
apply?
I
know
we
are
chartered
for
being
able
to
do
that.
Won't
stay
in
existence
forever,
but
there
may
be
some
additional
outcomes
and
curves
coming
our
way.
A
A
C
I
think,
there's
a
a
big
argument
to
be
made
for
starting
to
register
some
pqc
algorithms.
There's
obviously
going
to
be
a
lot
of
interest
in
that,
especially
once
the
nist
competition
finishes,
and
certainly
there's
already
been
some
discussion
of
these
where
stateful
hash
pay
signatures
are
concerned.
So
I
think
that
we
should
probably
consider
taking
a
role
in
registering
pkc
algorithms.
A
C
So,
while
I'm
by
no
means
an
expert
my
on
on
this
topic,
my
understanding
is
that
there
is
an
ongoing
competition
for
both
key
agreement
and
signing,
and
so
as
such,
it
fits
in
where
we
use
ephemeral,
static
ec
ecdh,
for
example,
and
we
would
probably
want
to
consider
something
in
a
similar
space
and
likewise
there's
a
number
of
of
algorithms
for
for
signing
as
well.
Now,
obviously,
I
think
russ
probably
has
already
put
through
one
on
the
the
topic
of
stateful
hash
based
signing.
C
I
think
we've
already
registered
that
algorithm.
So,
along
the
same
vein,
I
would
argue
that
we
probably
should
be
prepared
once
that,
once
that
finishes
to
look
at
registering
algorithms
for
the
winners
of
the
of
the
nist
competitions.
A
That
certainly
makes
sense
garen
go.
I
Ahead,
yeah
I'd
like
to
chime
in
also
on
this
in
this
discussion,
so
I'm
one
of
the
designated
experts
for
certain
cosy
code
points
and
together
with
derek
and
sean
we
sort
of
we
were
very
happy
with
jim
chad
being
around
because
he
was
very
eager
to
provide
input
about
registration
requests.
So
we
basically
follow
followed
his
advice
and
when
we
now
have
been
asked
to
review,
we
have
been
looking
looking
at
the
patents
in
rfc,
8152
and
so
on.
I
Admittedly,
it's
not
it's
not
always
clear
how
these
registrations
should
be
made
in
some
cases.
It's
it's
quite
clear,
but
there
are
there
are
corner
cases,
and
so
on
so
I
mean
jim.
He
knew
very
well
about
jose
and
ekix
assignments.
I
So
it's
it's
definitely
a
conscious
decision
here
and
and
some
of
the
constructions
are
made
for
good
reasons,
so
like,
for
example,
issues
with
truncation
or
hash
algorithms
and
how
you
need
to
be
explicit
of
that,
and
there
are
rules
like
which
I
mean
which
which
we
may
want
to
deviate
from,
but
that's
there
at
least
our
rules,
not
in
the
current
allocations
like
signature.
Algorithms
are
are
typically
bundled
with
a
hash
function
to
pre-digest
the
signature
input,
but
they
are
not
bundled
with
an
elliptic
curve.
I
Instead,
algorithms
use
specific
key
type
and
the
key
will
indicate
the
curve
c.
Crv
is
one
of
the
cosy
key
parameters.
I
I
So
I
just
want
to
say
that
if
we
are
deviating
from
what's
currently
defined
in
the
cosian
arrays,
we
do
want
to
open
open,
make
cosi
available
for
for
many
other,
seos
and
and
deployments.
I
think
that's
really
good,
but
if
we
want
to
change
a
lot,
then
we
need
to
proceed
quite
carefully
because
we
risk
creating
a
greater
mess
than
it's
already
there.
I
So
we
could
have
a
plan
for
I
think
for
for
how
to
deviate
from
that
or
what
how
to
assign,
which
probably
something
we
won't
crack
in
in
a
working
group
meeting
that
probably
needs
some
larger
effort
beyond
that.
Another
item-
I'd
like
to
add
is
that
in
particular,
we
should
be
careful
with
short
identifiers.
E
Yeah
I
got
in
the
queue
to
just
quickly
say
that,
just
because
in
this
competition
is
complete,
doesn't
mean
that
we
have
an
algorithm
to
register
because
they
usually
need
some
time
to
write
up
the
result
and
then
to
derive
some
some
actually
standards
compatible
description
of
what
they
actually
have,
but
on
on
euron's
point,
I
think
we
we
really
need
to
address
this.
I
think
we
actually
should
write
a
document
that
explains
our
the
guidelines
that
we
are
using.
E
That
will
probably
at
some
point,
become
a
bcp,
but
I
think
it's
important
that
we
start
writing
these
things
up.
So
it's
not
just
law
that
is
traded
from
the
engines,
but
we
can
just
point
to
a
document
look.
This
is
what
we
have
decided,
and
so
one
of
the
things
that
ben
just
said,
we
prefer
okp
or
say
one
but
yeah.
E
A
Good
point,
I
I
do
know
that
you
know
from
jose
and
some
other
contexts.
We
wanted
things
to
be
registered,
that
we
expect
to
be
commonly
used,
not
that
you
couldn't
register
esoteric
things,
but
there's
also
the
criteria
that
you,
the
designated
experts
at
least,
want
to
believe
that
there's
been
a
public
cryptographic.
Analysis
of
the
safety
and
effectiveness
of
the
algorithms.
A
This
is
where
you
know,
I'm
a
complete
novice
in
the
pairing
friendly
curve
space,
for
instance.
I
would
want
to
defer
to
the
cfrg
and
or
other
experts
about
which
of
these
probably
passes
muster.
That
said,
we
don't
want
to
make
experimentation
hard
by
not
having
common
algorithms.
So,
let's
see
I'll
I'll
recognize
brendan,
and
then
I'd
like
to
ask
to
close
this
out
if
ben
wants
to
say
anything
from
the
isg
perspective,
brandon.
C
Yeah,
so
one
of
the
things
you
just
mentioned
brings
up
an
important
topic.
You
you
said
that
you,
you
want
some
kind
of
indication
that
there's
been
cryptographic
analysis
and
that
the
algorithms
we
register
have
had
some
kind
of
security
review
behind
them.
So
that
brings
me
to
the
the
question
of
what
do
we
do
about
independent
submissions
that
register
a
an
algorithm
identifier
to
an
outside
observer?
Those
might
appear
to
have
exactly
the
properties
you've
mentioned,
but
because
they
haven't
gone
through
the
regular
stream.
C
A
I
I
do
know
that
our
registries
have
a
field
for
the
documents
that
in
which
that
analysis
was
supposed
to
have
been
done,
so
we
wouldn't
even
accept
a
registration.
If
there's
no
evidence
provided
I'm
not
saying
that's
a
fail-safe
check,
but
it's
a
start.
G
Yeah,
I
I
think
the
current
recommended
column,
which
have
it's
it
can
be
yes
or
no
recommended,
is
maybe
too
little.
I
think
it
would
be
good
to
have
more
flexibility
here
to
add
more
information.
G
Similar
discussions
have
been
had
in
the
tls
working
group,
which
also
have
a
single
recommended
column,
and
I
think
the
conclusion
earlier
discussions
is
that
that's
not
enough.
It
should
be
updated
in
the
future.
A
Indeed,
jose
has
more
granularity
as
a
result
of
some
input
from
sean
turner
when
he
was
a
d,
but
because
a
is
binary,
although
I
think
we
have
a
deprecated
or
prohibited
value
as
well
as
yes
or
no
but
okay
ben.
Do
you
want
to
make
any
closing
remarks
to
this
discussion
and
then
I'll
move
on
to
aob.
F
Yeah
thanks
for
passing
it
over
to
me.
I
think
the
points
that
definitely
that
euron
and
carson
were
making
are
good
ones,
that
it
would
be
good
to
have
some
clarity
about
our
expectations
and
to
write
it
down
for
so
that's
available
for
people
who
are
asking
for
registrations.
F
It's
definitely
not
something.
We
resolved
in
this
session
they're
planning
to
resolve
in
this
session
I
mentioned
in
the
chat.
Hopefully,
carson
can
volunteer
to
help
start
writing
those
down
within
the
form
of
a
draft,
and
so
I
look
forward
to
seeing
that
kind
of
guidance
from
enough.
I
think
it's
within
the
current
charter
to
be
able
to
do
that,
and
it's
very
useful
to
do
so.
F
A
All
right,
thank
you,
all,
let's
go
to
aoe
and
there
was
a
request
to
discuss
the
rat's
uccs
draft.
Please
come
to
the
queue
and.
A
J
Let
me
turn
on
my
camera
hi.
So
I
assume
there's
a
question
associated
to
the
topic
of
uccs.
J
E
I
mean
this
is
technically
entirely
trivial,
but
we
have
to
write
it
up
and
we
probably
also
have
to
write
up
some
security
considerations
because
yeah
these
are
not
cwts,
so
you
cannot
use
them
the
same
way.
You
would
just
see
the
wt's,
you
would
use
them
in
communicating
about
things
that
might
go
into
a
cwt
and
you
would
use
them
on
secure
channels
and
we
have
to
to
describe
what
the
properties
of
these
secure
channels
are
and
so
on.
K
F
J
J
Wrapper
there
is
a
definition
in
cwt
that
defines
claims
sets
yeah,
and
it
is
exactly
that
it
is
so
so
so,
but
but
we
want
to
retain
the
guarantees
that
you
that
come
to
the
cwt.
So
now
you
need
an
alternative,
and
the
alternative
is
the
conveyance
method
here
and
yeah
that
that
is
then
providing
this
the
same
guarantees
and
as
the
cwt
would
have
done,
an
object,
security
and-
and
that
is
that
is
unfortunately,
application
specific.
J
So
the
guarantees
you
expect
from
cwt
are
intrinsic
to
the
object
with
cwt,
but
they
are
not
intrinsic
to
the
arbitrary
general
that
is
secured
somehow,
so
these
channels
have
to
be
established
under
certain
circumstances.
When
you
receive
something
that
is
a
claim
set,
then
you
suddenly
are
burdened
with
responsibility.
J
Maybe
it's
the
burden
of
the
responsibility
of
the
issuer.
Maybe
it's
a
dedicated
role
that
you
define
in
your
scenario
and
and
therefore
you
can't
just
define
uccs
as
there's
a
claim
set
that
encased
in
the
cwt
and
done
no,
you
have
to
always
provide,
and
I
think
there
was
carson
hinting
at
a
security
consideration
that
are
specific
to
the
user
scenario
and
and
but
but
the
core,
of
course,
is
relatively
easy.
It's
it's
an
unprotected
claims
set
yeah.
E
Yeah,
I
think
it's
important
to
clarify
this,
because
the
ucsds
is
an
unprotected
claim
set.
It's
unprotected
and
the
rest
of
the
document
is
a
little
bit
speculative
and
tells
you
what
properties
a
secure
channel
might
have
to
have.
So
you
can
make
useful
use
of
an
uccs
in
the
same
way
that
you
could
make
use
of
a
cwg,
and
it's
a
bit
unfortunate
that
that
we,
we
are
forced
to
put
the
two
things
into
a
single
documents,
because
it
really
confuses
the
issue.
But
that's
where
we
are.
A
I'll
state
not
wearing
my
chair
hat,
just
as
a
point
of
comparison,
open
id
connect
does
utilize
a
jot
set
in
one
flow
without
it
being
a
job.
There's
this
thing
called
a
user
info
endpoint,
which
must
be
protected
by
tls,
where
you
send
claims
about
the
end
users,
such
as
your
first
and
last
name.
If
you
choose
to
disclose
those
they're
just
sent
as
bear
claims
now
they
use
the
job
registrations,
but
they're
protected
by
tls,
not
protected
by
jws.
J
I
think
we
have
to
if
it's
comparable,
we
have
to
check
that
because
every
let's
call
it
similar
example.
A
proof
of
concept
here
is
is
is
extending
the
the
intuitive
message
that
we
want
to
convey
here,
but
it
is
not
intuitive,
unfortunately
without
context
and
yeah.
Maybe
another
example
would
provide
that.
Thank
you.
J
A
Okay,
well,
this
is
certainly
a
relevant
topic.
Thank
you
for
the
explanation
we
are
at
time.
Does
anybody
want
to
make
a
final
remark
or
otherwise
we'll
end
here,
and
thank
you
for
your
participation.
F
Yeah,
I
was
just
going
to
jump
in
to
say
thanks
to
hank
and
carson
for
letting
us
know
about
ucts
and
why
it's
not
as
simple
as
it
might
appear.
It
seems
like
we
should
probably
continue
discussion
about
that
on
the
this.
Is
the
rats
group
that's
in
kirsten
on
the
appropriate
list
where,
where
the
document
is
actually
homed,
which
I'm
pretty
sure
is
rats
but
we'll
check
shortly,
but
thank
you
again
for
bringing
it
up
here.
That
was
all
I
had
to
summarize.