►
From YouTube: Kubernetes SIG Auth 2021-03-17
Description
Kubernetes Auth Special-Interest-Group (SIG) Meeting 2021-03-17
Meeting Notes/Agenda: https://docs.google.com/document/d/1woLGRoONE3EBVx-wTb4pvp4CI7tmLZ6lS26VTbosLKM/preview
Find out more about SIG Auth here: https://github.com/kubernetes/community/tree/master/sig-auth
A
Hello:
everyone
welcome
to
the
march
17th
2021
meeting
of
sig
auth
looks
like
the
first
item
on
the
agenda.
Is
an
announcement.
B
Yeah,
so
we've
been
doing
these
bi-weekly
pod
security
policy
replacement
discussions
in
the
sigoth
off
weeks
and
we've
basically
gotten
agreement
to
move
forward
with
this
proposal.
B
So
if
you,
if
you
haven't
seen
this,
the
idea
is
basically
to
implement
the
pod
security
standards,
so
that's
the
three
levels:
restricted
baseline
and
privileged
in
a
built-in
controller
enforced
at
the
namespace
level
and
then
to
add
in
a
whole
bunch
of
nice
user
experience,
features
on
top
of
that
I'll.
B
Let
the
document
kind
of
speak
for
itself
on
that.
Also,
jordan
gave
a
great
demo
that's
linked
to
the
top.
If
you
want
to
kind
of
see
that
in
action
so
yeah.
Basically,
the
next
steps
here
is
to
convert
this
document
over
to
a
cap
which
I'll
try
and
do
in
the
next
few
days,
there's
still
a
fair
amount
of
implementation,
details
that
are
unresolved,
but
that's
the
sort
of
thing
that
we
can
iron
out
in
the
kep
review
process.
C
Sections
in
the
cat
and
then
we
might
stop
those
meetings
and
move
remaining
discussions
back
into
regular
sigoth
meetings.
B
A
Awesome,
thank
you,
tim
and
everyone
else
for
spending
time
on
this,
this,
it's
good
to
hear
that
we.
A
Cool,
I
guess,
let's
review
the
doc
or
the
cap.
If
it
comes
out,
and
maybe
we
can
have
a
deeper
discussion
next
sig
off
meeting
people
have
time
to
review.
E
E
So
in
the
process
of
doing
that,
I
was
reading
through
the
code
and
the
back
dating
logic
that
exists
today
doesn't
really
make
sense
to
me,
which
is
that
it
it
back
dates
both
the
not
before
and
the
not
after.
E
So
it
keeps
the
duration
of
the
cert
same,
but
it
shifts
both
times
back
and
it
shifts
them
back
by
five
minutes.
So
if
you
were
to
ask
for
a
five
minute
cert,
you
would
get
a
cert
that
was
valid
for
roughly
zero
seconds.
You
might
get
a
request
in
before
it
failed.
We
like
to
call
that
super
secure.
Yes,
I
mean
yes
technically,
it
is
perfectly
secure.
It
trails
closed
exactly
the
way
you
want
it.
I
guess
so.
E
I
wanted
to
ask
folks,
I
think,
and
mike
you
had
sort
of
commented,
it's
not
necessarily
clear
what
back
dating
actually
means.
In
this
context,
I
had
always
took
it
to
mean
that
the
starting
point
of
the
cert
is
sort
of
arbitrarily
made
earlier
to
sort
of
try
to
adjust
for
clock
skew
between
different
consumers
of
the
cert,
but
it
does
not
affect
the
end
date
of
the
cert.
E
E
I
just
always
consider
that
I
guess
not
to
be
an
issue,
because
the
bulk
of
that
extended
period
was
in
the
past
so
and
that's
according
to
whom
exactly
yes,
you
are
assuming
that
clocks
are
vaguely
in
sync,
if
they're
very,
very
far
off,
then
I
don't
know
if
any
of
this
matters,
because
I
don't
really
know
what
a
consumer
would
do
with
the
client
cert.
Then,
if
it's
clock
is
really
far
off,
it
could
just
not
be
able
to
use
it
all
or
it'll
use
it
for
too
long
or
something
I
don't
know.
B
I
thought
I
thought
mike's
point
about
like
this,
probably
not
mattering
for
long-lived
certs
and
the
ttl,
maybe
actually
mattering,
for
long-lived
certs,
that
we
don't
want
to
extend
it
like
if
the
one-year
policy
must
not
be
valid
for
longer
than
a
year
like
we
wouldn't
want
to
have
a
year
and
five
minutes
and
then
have
some
automated
policy
be
like
nope.
I
will
reject
your
cert
because
of
that,
so
the
the
back
dating
like
mattering
for
the
overall
ttl,
I
think
only
matters
for
like
really
short
lived,
certs,
yeah.
D
B
A
I
I
would
be
interested
so
yeah,
I
guess
I
don't
know
what
is
right
and
I
definitely
do
not
object
to
somebody
saying
that
what
we
do
today
is
wrong.
I
would
be
interested.
I
think
there
are
like
a
couple
questions
that
may
be
opinions.
One
is
like,
like
you
said
mo,
there
could
be.
There
are
various
ways
to
interpret
back
date.
Another
one
is:
should
we
be
implementing
leeway
here
or
should
clients
implement
leeway,
do
certificate
libraries
like
go
or
open
ssl.
A
Have
some
leeway
on
the
date
and
then
I
guess,
if
the
answer
is
yes,
does
that
leeway
exist
on
the
not
after
on
the
not
before
validation
or
does
it
exist
on
both
not
sure
what
the
answers
to
those
things
are
and
yeah
I'd
agree
with
jordan,
who
was
maybe
agreeing
with
me
that
this
seems
like
we
can
do
whatever
we
want
for
short-lived
certs?
I
just
think
that
I
don't
want
to
change
it
again.
E
Right,
so,
if
I'm
hearing
stuff
correctly,
we
just
we
just
want
to
for
some
some
duration
that
we
consider
short
we'll
do
slightly
different
things,
just
to
sort
of
accommodate
that
better,
like
maybe,
instead
of
back
dating
by
five
minutes.
We
just
back
date
by,
like
I
don't
know,
15
seconds
or
something.
B
B
E
E
Okay,
that's
fine
yeah!
I
I.
What
I
did
not
want
to
do
was
not
back
date
on
short-lived
certs,
because
then,
if
clock
suit
does
come
into
effect
and
clients
aren't
necessarily
honoring
for
it
like
if
you,
if
you
literally,
are
being
issued
very
short-lived
shirts
all
the
time.
That
means
you
have
a
chance
of
encountering
that
clock
skew
all
the
time,
because
if
you
had
a
long
lift
cert
after
the
first
few
minutes
of
that
long,
lift
you're,
probably
fine,
because
the
clock
skews
already
been
sort
of
handled.
B
Yeah,
I
suspect,
if
we
allow
shortening
a
certain
we
probably
want
to
set
a
minimum
like
we
did
for
tokens
so
that
you
can't
say
like
give
me
a
cert
good
for
30
seconds
or
one
minute
and
like
that.
That
seems
like
a
good
recipe
for
outages
and
doses
on
like
perpetually
renewing
clients.
E
Okay,
that
might
be
a
good
segue,
then
into
the
not
after
hint
field.
So
last
time
we
discussed
there
was
not
really
consensus
on
it.
Should
it
be
ttl
or
should
it
be
not
after
I
just
arbitrarily
picked,
not
after
because
it
technically
lines
up
with
x,
509
better,
I
actually
don't
care
at
all.
E
C
E
B
I,
like
duration,
for
two
reasons.
One
is
that
you
don't
require
the
client
to
have
a
nsync
clock
and
because
approval
and
signing
is
asynchronous,
if
I
ask
for
a
five-minute
cert
and
it
takes
two
minutes
for
it
to
be
approved
and
then
signed,
I
end
up
getting
a
cert
good
for
three
minutes.
If
I
pinned
to
a
particular
ends
time
when
I
think
client
intent
is
probably
more
like,
I
want
to
cert
good
for
this
period
of
time,
like
I'm
prepared
to
renew
every
five
minutes.
B
So
I
want
a
cert,
that's
good
for
eight
minutes
or
whatever,
and
so
that,
however
long
it
takes
to
approve
and
sign
lets
you
get
something
good
for
as
long
as
you
wanted.
Okay.
E
F
E
The
the
thing
with
the
not
after
is
I
I
thought
it
would
be
more
clear
for
an
approver
right.
I
approve
this
cert
to
this
point,
or
I
assigned
this
sir,
to
this
point,
but
no.
F
B
E
Or
leave
that,
but
it's
a
data
point
okay
and
then
someone
linked
x509
verification
and
go
which
has
zero
zero
leeway
and
those
are
problems.
B
E
Okay,
okay,
I
mean
that
I
I
think
my
gut
says
we'll
we'll
do
something
slightly
different
for
short-lived
starts
and
it'll
probably
be
okay.
It'll
serve
those
clients
better
and
it'll.
Keep
existing
clients
that
may
have
policies
attached
to.
You
can
only
have
like
a
one
year,
cert
or
whatever,
also
functioning
as
we
expect.
E
F
E
A
E
If
we
want
to
move
on
to
the
next
one
awesome,
I
at
some
point
I
got
pinned
on
this.
I
didn't
even
know
it
was
a
thing
this
was
like.
I
think
I
was
on
fraternity
leave
when
this
was
raised,
so
it
just
showed
up-
and
I
was
like
right
so
this
sig
owns
this
string
that
is
possibly
contentious.
E
G
F
Actually,
right,
like
I
know,
openshift,
does
it
to
create
a
backup
cert
that
can
be
used
for
order
of
years
to
be
able
to
recover
a
cluster
if
things
go
badly.
E
E
F
Guess
what
I'm
saying
is
that
the
code
that
allows
authorization
for
system
masters
is
going
to
need
to
exist
for
order
of
a
decade
in
the
authorizer
yeah
as
a
baseline.
A
Yeah
we
can
create
an
alias
for
things
talking
to
the
api
server.
I
think
and
document
that
no
longer
document
system
masters
but
and
those
certs
continue
to
exist
for
a
decade
or
however
long.
A
I
kind
of
don't
know
how
we
phase
this
out
for
things
that
are
upstream
of
the
kubernetes
api
server
like
either
like
authorization
web
hook
or
maybe
a
cube,
aggregated
api
server.
That
seems
harder
because
we
have
less
control
over.
D
Them
anybody
that
has
that
hard-coded
is
just
gonna
have
to
be
told
a
long
time
ahead
of
time.
Hey
system
masters
is
is
deprecated
like
for
the
for
the
next
seven
releases.
You
can
use
system
masters
or
system
admins,
but
like
eventually
system
masters
is
gonna
go
away
and
then
just
hope
that
they
pick
up
on
it
and
do
it.
A
B
Okay,
I
providing
a
way
to
use
an
alternative
like
thinking
through
what
it
would
take
to
allow
use
of
an
alternative
seems
like
a
good
first
step
that
allow
that
would
allow
consumers
that
wanted
to
use
a
different
name
to
do
so.
B
That
would
need
to
come
with
the
caveats
about
like
if
you
have
aggregated
api
servers
or
sort
of
external
systems
that
have
picked
up
this
special
case.
Like
you,
you
have
to
update
those
two
versions
that
are
aware
of
the
sort
of
second
supported
special
case.
E
We
couldn't
we
just
do
like,
so
we
make
a
new
magic
string.
Whatever
I
don't
know,
system
called
admin
system,
phone
cluster
admins,
whatever
some
something
reasonable
and
then
in
our
bootstrap
policy.
We
also
bind
that
to
cluster
admin
at
the
cluster
scope,
so
that
we're
at
least
reusing
all
of
our
code
and
did
make
a
authorization
subject:
access
review
back
to
us.
E
B
Yeah,
so
the
the
three
aspects
that
I'm
thinking
through
are
places
that
are
currently
using
this
credential,
like
david
mentioned,
like
break
glass
things
like
starts
good
for
10
years
type,
scenarios
that
are
not
expecting
to
ever
need
to
change
that
ever
like
what?
What
do
we
describe?
B
B
That's
that's
a
matter
of
like
add
a
second
case
and
then
support
both
for
a
year
or
two
years
or
whatever,
and
then
we
can
be
confident
that
all
of
our
components
recognize
this
new
thing,
but
then
the
consumers
outside
of
the
code
we
control,
is
the
biggest
unknown
for
me,
and
so
that's
things
like
policies
that
are
expecting
that
this
is
the
only
like
special
cased
group
that
isn't
going
to
show
up
in
our
back
policy
or
something
like
that,
and
so
they
guard
against
it
specifically
in
policies.
E
F
Credential,
you
have
other
things.
B
You
really
don't
want
the
brake
glass
to
be
like.
I
used
it
three
years
down
the
road
and
that's
when
it
didn't
work
yeah.
My
my
sense
is
that
this
will
likely
fall
into
the
same
bucket
as
other
things
in
client
go
where
we
can
accept
a
second
name,
along
with
the
existing
name.
E
E
E
E
F
That's
fair.
I
just
want
some
time
scale
right.
I
still
think
an
alternative
is
going
to
be
a
fairly
drawn
out
process,
given
how
well
known
and
the
number
of
integrating
systems
right,
you
don't
want
to
start
using
something
new
like
system
administrator,
maybe,
and
have
it
not
honored
in
some
places.
E
So
I
was
going
to
ask
in
relation
to
that
so
one
would
we
ever
get
rid
of
system
colon
masters
at
all,
or
we
just
say
it's
forever.
It's
just
there's,
basically
two
magic
groups.
Now,
instead
of
one
and
they're
both
equally
good,
we
just
stopped
documenting
the
bad
one.
Let's
go
and
put
that
and
just
say
use
the
new
one,
please.
E
The
other
question
that's
related
to
is
whatever
string
that
we
use
for
the
new
group
now
magically
becomes
all
powerful
in
the
cluster
when
it
previously
was
not
magically
all
powerful
in
the
cluster.
Now
you
could
say
that
people
should
not
be
bad
and
not
use
system,
colon
prefixes
in
their
group
names.
If
they're,
I
don't
know
their
idp's
assert
or
whatever
but
they're.
We.
E
B
B
Like
system
authenticated
system,
anonymous
system,
unauthenticated
system
masters
aren't
versioned
apis,
so
pretty
much
all
of
the
guidelines
around
api
changes
that
talk
about
like
can
can
only
be
replaced
by
a
newer
version
of
the
same,
like
the
it's
hard
to
map
those
to
this
exactly
there's
a
minimum
time
frame
of
one
year
for
breaking
changes
to
ga
features
generally,
but
as
we've
seen
as
cube,
has
matured
like
one
year
is
not
long
enough
for
the
ecosystem
to
make
a
change
like
this.
B
So
I
think
supporting
an
alternative
and
doing
that
like
trying
to
understand
how
to
do
that
safely
and
the
earlier
we
can
start
consuming
an
alternative,
probably
the
better
and
then
once
that
reaches
the
trailing
end
of
the
support
window.
G
E
G
E
I
know
micah.
This
is
a
problem
for
you
guys
and
like
eks,
because
when,
when
customers
have
this
magic
string,
it
causes
problems
because
they
become
root,
and
you
didn't
want
them
to
be
rude.
You
wanted
them
to
be
almost
rude
or
whatever
like
something
that
you
controlled,
and
this
is
problematic
because
it
also
bypasses
your
authorizer
completely
your
web
hook,
authorizer
or
whatever
else
all
right,
which
is
very
frustrating.
F
E
E
D
B
To
mica's
question
about
configurability
the
the
biggest
thing
I
see
there
when
they're,
when
something
is
technically
configurable,
but
99.99
of
deployments
just
use
the
default.
Many
many
many
consumers
don't
realize
it's
configurable,
and
so
they
effectively
hard
code
it.
And
so
then
you
get
interoperability
issues.
It's
like
technically,
it's
configurable,
but
if
you
pick
a
value
other
than
the
default
like
you're,
just
like
stuff
isn't
going
to
work
for
you,
because
no
one
realized
it
was
configurable.
A
B
B
Good,
my
if
I
recall
correctly,
I
think
the
workflow
was
supposed
to
be.
The
naming
working
group
makes
a
recommendation,
but
then,
like
actually
driving.
The
implementation
is
more
for
the
component
owners
because
they
understand,
like
the
constraints
and
technical
issues
involved,
makes.
A
B
We
can
start
with
the
issue
and
maybe
copy
it
to
the
mailing
list
and
see
if
there's
a
person
or
people
who
want
to
help
drive
that
yeah.
I
was.
E
At
the
tl
meeting
that
said
to
sort
of
email,
the
working
group
naming
mailing
list,
I
just
wanted
to
discuss
it
with
you
guys
first
and
then
so
yeah
we
can.
We
can
make
the
issue
and
then
I
don't
know,
ask
for
next
steps,
but
I
do
agree
with
you
that
there
should
be
a
cap,
because
it'll
touch
important
things.
A
A
Like
got
some
cluster
api
stuff.
G
Yeah
so
this
came
up,
I
actually
so
I
opened
a
kind
of
unrelated
issue
in
cluster
api
and
they
bundle
they.
They
use
cube
builder
to
build
cluster
api
and
q.
Builder
automagically
adds
cube
rvac
proxy
to
everything
which
does
a
subject.
Access
review
on
incoming
connections
to
see
is,
is
the
requester
authorized
to
make
this
call,
and
so
I,
my
original
question
to
cluster
api
was
hey.
Do
we
do
we
really
need
this?
G
Can
we
like,
if
we
don't
need
this,
can
we
remove
it
and
it
came
up
there
that
which
I
still
am
following
that
right
now,
if
it's
not
needed,
it
might
maybe
just
not
remove
it
or
not
include
it
for
cluster
api,
but
it
does
seem
useful
in
maybe
in
other
contexts
where
you
want
to
guard
some
endpoint
with
some
kind
of
authorization
and
there's
discussion
about
donating.
G
This
cube
rvac
proxy
to
sig
off
for
ownership.
It's
currently
owned
just
by
a
developer
developer,
like
seems,
like
a
you,
know,
trustworthy
developer,
not
trying
to
comment
on
him
specifically
or,
or
you
know
his
his
work
or
his
project,
but
just
saying
like
is,
does
ziggo
seem
like
a
good
home
for
this
project.
D
E
But
they
don't,
you
can
still
configure
it
without
it.
It's
just
like
a
broken
config.
In
my
opinion,.
A
Yeah,
the
other
thing
that
comes
to
mind
now
is
the
scalability
issues
that
we
talked
about.
Maybe
a
meeting
or
two
ago
with
subject
access
reviews.
F
F
So
I
know
of
this
project.
I
know
both
you
know,
frederick
and
serge.
I
know
that
it
is
often
used
when,
for
whatever
reason
you
don't
want
to
make
something
running
in
a
cube
cluster
natively
cue
aware
it's
handy,
I'm
surprised
that
controller
runtime
would
automatically
add
it
for
you,
though,.
E
G
That's
my
impression,
and
I
think
for
so
for
cluster
api
specifically,
I
don't
even
think
that
that
sounds
like
they're,
not
even
emitting
metrics,
so
they're
like
what
we're
just
saying
you
need
to
install
this,
but
it's
not
even
really
necessarily
being
used,
so
that
specifically
can
be
cut
but
yeah.
G
F
I
have
found
it
very
useful.
I
do
know
it's
heavily
used
in
openshift
to
protect
components
where
you
don't
own
the
actual
final
server
itself.
It
gives
you
a
way
to
link
whatever
you're,
deploying
into
the
cube
authentication
authorization
for
your
cluster,
which
is
handy.
A
I
guess
it
needs,
maybe
a
sponsor
which
do
you
feel
like
I
I
don't
know,
what's
your
opinion,
having
more
familiarity
than
others
on
the
project
to
micah's
question
whether
this
should
be
a
cigar
sub
project.
F
F
Me
so
much
pain
with
that
repo
yeah,
so
several
of
us
have
clearly
been
through
the
sins
of
the
past
on
their
related
projects.
I
think
the
idea
of
having
such
a
thing
is
useful.
It
was
useful
for
us.
B
B
I
think
we
want
to
have
a
clear
idea
that
yeah
this
is
a
thing
we
would
encourage
people
to
use
and
maybe
clarify
like
what
it's
good
for
and
not
good
for
in
terms
of
scale,
and
if
you
don't
make
this
your
api
gateway,
that
gets
like
1000
qps,
but
maybe
it's
okay
for
protecting
like
a
metrics
endpoint
against
for
like
a
small
set
of
users.
I
I
don't-
I
don't
know,
but
I
think
we
probably
want
clarity
on
like
the
use
and
also
clarity
on
like.
B
Are
we
expecting
more
work
to
be
done
on
it
because
sigoth
picks
it
up
and
if
so,
who
is
going
to
do
that?
Is
it
sort
of
in
maintenance
mode
now?
Are
they
looking
for
people
to
help
run
it,
or
is
this
just
purely
like
an
endorsement
like?
Oh
yeah,
it's
a
sick
off
project
like
they're
in
touch
with
sigoth,
and
it's
on
our
radar
for
best
practices
and
stuff.
E
F
E
F
The
classic
would
be
metrics,
or
probably
maybe
they
put
in
front
of
health
c,
but
normally
you
let
authenticated
there
anyway,
but
you
would
configure
it
so
that
it
uses
a
checks
to
see
if
whoever
is
calling
the
metrics
on
point
actually
has
general
metrics
access
in
the
cluster.
That's
a
classic
case
to
do
it.
We've
also
used
them
to
protect
certain
endpoints
around
some
part
of
a
logging
stack
used
it
for
something.
I
don't
know
what
it
was
for,
and
I've
seen
it
for
consoles.
F
A
I
guess
my
architectural
concerns
are
additional
load
on
the
subject
access
review.
I
think
that
is
mostly
mitigated.
If
this
thing,
I
don't
actually
know
what
the
shape
of
the
request
it
makes
are,
but
if
they're
fairly
cachable,
I
don't
know
if
that's
actually
a
concern
and
then
I
guess
the
amount
of
traffic
you
have
to
push
through
this
proxy
worries
me
or,
if
we're
on
the
hook.
For
somebody
trying
to
put
this
in
between,
you
know
high
traffic
servers
and
we
have
to
invest
in
secure.
F
I
have
not
seen
it
against.
I
have
not
seen
it
used
to
protect
a
high
volume
endpoint
before.
A
That
is
good
yeah.
I
agree
with
jordan
that
if
we
have
one
or
more
sig
sig
sub
projects
using
this,
it
might
be
get
adopted.
At
this
point
I
know
we've
had
this
discussion
before
so.
B
F
So
yeah
I'd
be
interested
in
being
the
champion
on
this,
but
it
would
be
something
I
guess
I'll
talk
with
them.
It'll
be
something
I'd
get
to
later.
It
probably
would
not
be
on
my
do
it
in
the
next
month
list.
Probably
next
quarter.
E
F
E
B
On
them,
it's
possible
that
that
wasn't
as
clean
to
wire
like
three
or
four
years
ago,
so
it
may
be
an
artifact
of
when
this
was
added.
It
was
a
reasonable
standalone
thing
and
the
reuse
of
api
server.
Generic
authorization
wasn't
up
to
stuff.
Yet
I
don't.
A
A
Sounds
good,
I
guess
david
has
next
steps
does
any?
Does
anybody
want
to
follow
up
on
how
easy
it
would
be
to
add
the
delegated
delegated
authorization
to
the
cube
builder
endpoints,
any
volunteers.
A
B
Solid
failure
all
right,
so
the
metadata
concealment.
That
needs
a
clear
issue.
I
will
make
sure
there's
an
issue
open
for
that
and
route
that
afterwards.
B
The
the
next
one
is
the
oidc
discovery.
It
looks
like
the
there's
already
an
issue
open
against
windows,
aks
yeah
issuer.
They
were
going
to
adjust
to
comply
with
the
rfc
and
be
a
valid
issuer
name.
The
local
ede
I
was
not
aware
of
so.
A
Failing
yeah,
I
will
do
local
e
to
e
and
route
it.
Okay
and
cc
me.
You
can
see
you
see
me
on
the
metadata
concealment
one.
I
think
okay.
C
A
B
That
is
our
upgrade
test,
which
gives
a
signal
on
things
like
token
service
account
token
migration.
So
we
got
good
solid
signal
on
that
during
this
debt
cycle,
but
we're
going
to
want
it
again
for
the
next
cycle,
so
I
will
make
sure
that
gets
going
again.
B
B
Unit
tests,
we
should
always
be
passing
there
like.
This,
should
be
super
solid.
A
Okay,
are
we
doing
cigars
secret
store
csi
drivers
here,
or
is
this
something
that
is
done
usually
in
the
csi.
C
Oh,
you
can
ask
rita,
but
it
looks
like
she
dropped
yeah
I
mean
I
can
help
answer
the
questions.
C
So
these
are
you
just
for
the
prs,
but
the
periodic
one.
Yes,
we
do
cover
those
okay,
okay,.
A
Yeah
there
are
a
few
pr
ones
and
then
a
few
periodics
all
right.
Well,
if
they
are
covered,
I
don't
think
we
need
to
cover
them
in
this
meeting.
A
And
what
are
these
other
ones?
We
have
time
for
one
open
id
token.
Authenticator
cannot
be
easily
used
in
a
controller.
E
This
was
the
issue
that
had
been
brought
up.
I
think,
like
two
cigars
ago,
when
we
had
the
demo,
I
was
gonna,
make
a
trivial
change
to
this
option,
struck
to
take
our
like
ca
provider
interface
thing
that
we
have
in
the
tube
api
server
or
see
a
content
provider
and
just
pass
it
static,
ca
content
from
the
file
that
you
normally
would
have.
E
A
Using
this
in
this
way,
so
they
cannot
use
just
odc
discovery.
E
A
All
right,
thank
you.
Everybody
for
joining,
see
you
all
in
two
weeks
or
in
one
week
for
the
psp
discussion.
All.