►
From YouTube: SIG-Auth Bi-Weekly Meeting for 20220706
Description
SIG-Auth Bi-Weekly Meeting for 20220706
A
Hello:
everyone
welcome
to
july
6
2022
meeting
of
sigoth.
Let's
kick
it
off
first
item
on
our
agenda.
Nick.
Do
you
to
talk
through
this?
Do
you
want
to.
B
I
will
I
it's
okay,
if
you
just
share
I'll,
just
give
a
quick
summary
of
it
and
kind
of
explain
where
it
is
right
now
so
yeah.
Basically,
this
steps
been
open
for
a
while.
I
didn't
get
a
chance
to
work
on
it
over
the
last
release,
so
I'd
like
to
keep
the
discussion
going
early
for
126,
but
basically
it
is
a
proposal
to
solve
a
number
of
use
cases.
B
One
of
the
use
cases
that
that
I'm
interested
in
is
basically
request
signing
so
allowing
clients
to
use
request,
signing
something
that
aws
would
like,
but
there's
a
number
of
other
use
cases
that
others
are
interested
in.
You
know
I've
been
working
with
mo
and
he
is
interested
in
an
external
tls
certificate,
signer
which
this
would
also
enable.
So
basically,
the
most
recent
update
there's
been
a
decent
amount
of
conversation
and
iteration.
B
On
this,
the
most
recent
update
was
changing
the
api
a
bit
to
to
meet
what
basically
respond
to
some
some
comments.
By
mo
he
he
wanted
some
changes
in
the
api.
B
Originally,
I
had
kind
of
done
a
separate
like
new
objects,
and
he
wanted
me
to
use
the
existing
exec
auth
api
objects,
which
makes
complete
sense.
I
kind
of
I
wasn't
a
fan
of
how
they
use
spec
and
status,
but
I
mean
there's
no
reason
to
recreate
what
we
already
have
so
ended
up
just
going
with
that
and
yeah.
So
I
think
it's
ready
for
another
round
of
review.
It's
it's
really
mostly
been
mo.
B
Reviewing
and
and
mike
denise
did
a
couple
rounds,
but
I
think
probably
other
people
should
take
a
look.
C
B
Take
a
look,
it
was
the
the
api
structure.
I
think
that
was
the
one
thing
that
mo
was
like
the
reason
for
his
like
requesting
changes
and
that
he
didn't
want
it
to
go,
for
he
said
it
wasn't
ready
for
125..
B
There
was,
I
think,
the
rest
of
the
comments
were
relatively
small,
just
like
asking
for
more
explanation
in
certain
places.
There's
so
one
area
is
whether
or
not
so,
we've
kind
of
settled
on
uds
so
that
the
the
proxy
gets
exact
by
the
client
and
then
the
proxy
returns
information
that
allows
the
client
to
talk
to
it.
So
right
now
we're
we've
kind
of
settled
on
a
ca
bundle
for
authentication
and
then
the
uds
like
socket
path.
B
B
But
it's
I
mean
the
ca
just
likes
returning
a
ca
bundle,
just
kind
of
is
easy,
and
if
we
end
up
supporting
like
tls
or
tcp,
then
instead
of
uds,
then
we
can
kind
of
just
reuse
that
so
that
was
one
thing,
and
then
there
was
some
like.
B
There's
a
we
changed
the
so,
if
the
proxy,
if
the
client
dies,
then
there
was
either
like
the
proxy
would
just
kind
of
time
out
and
kill
itself
after
a
while,
or
there
could
be
some
mechanism
with
like
a
file
lock
to
to
cause
it
to
kill
itself
faster
if
it
ever
is
able
to
take
that
lock,
and
so
we
ended
up
doing
the
latter.
B
Whereas
the
original
proposal
had
the
former,
those
are
the
things
that
I
remember
well,
there
might
have
been
a
few
other
comments.
C
Yeah,
can
you
remind
me
what
the
proxy
protocol
would
be?
Is
it
just
connects
like
an
http
proxy
https
proxy?
C
C
Awesome
yeah.
I
thought
this
was
pretty
close
to
the
last
time
I
looked
at
it.
I
would
be
happy
for
just
to
get
into
1.26.
C
Yeah,
I
don't
remember
anything
particularly
objectionable
I'll.
Do
it
last
pass,
but
I
think
is:
is
the
prr
complete
yet
no
okay,
so
I'll
do
another
pass
and
then
we
can
ask
moe
who
gets
back
next
week
to.
C
C
Yeah,
unfortunately,
mo
is
the
last
reviewer
and
he's
currently
out
of
office.
So.
C
C
Yeah,
the
the
service
count,
discovery,
doc,
looks
kind
of
flaky,
even
excluding
that
ci.
C
Yeah
those
are
spread.
Those
failures
are
spread
across
a
couple
of
couple
of
jobs.
C
A
A
Okay,
well,
what
do
we
do
this,
but.