►
From YouTube: SIG-Auth Bi-Weekly Meeting for 20230816
Description
SIG-Auth Bi-Weekly Meeting for 20230816
A
Hey
folks
welcome
to
say:
goth
today
is
August
16
2023
and
today
we'll
start
with
our
agenda
here
Mo
you
want
to
go.
B
Yeah,
so
the
first
item
today
is
basically
the
the
document
that
we've
used
in
the
past
to
track
caps
and
stuff,
so
Rita,
Anish
and
I.
We
worked
on
updating
this
for
what
we
believe
is
already
in
flight
for
like
129
and
then
also
things
that
are
in,
like
our
backlog,
so
with
the
intent
of
trying
to
see
if
we
can
make
sure
that
anything
that
folks
are
interested
in
working
on
has
both
someone
who's
signed
up
to
do
that
work
and
someone
from
the
leads
list.
B
So
you
want
to
go
through
the
list.
Three
I
guess.
B
So
the
first
one
is
KMS
V2
that
one
is
I
think
we
could
GA
at
this
release.
If
we
finished
all
the
remaining
items
in
the
board
which
have
yeah.
C
B
Linked
there
not
too
worried
about
that
one.
If
we
don't
G8
that
won't
be
the
end
of
the
world
Jordan
and
Rita.
What
is
our
state
of
authorization
config.
A
I,
just
ping
number
in
on
slack
I
think
he's
going
to
split
his
PR
out.
Hopefully,
I
asked
if
he
could
have
it
by
next
week
and
then
we
can
get
folks
to
review
and
then
get
the
ball
rolling
for
129..
That's
the
goal,
but
we'll
see.
A
B
Yeah
Jordan
were
you
planning
on
working
on
this
in
this
release.
Yeah
yeah
I'll.
B
E
I
am
in
a
different
dock,
the
structured
authorization.
F
E
E
I
think
my
comments
were
addressed
a
while
back
so
I
can
be,
but
I'm
satisfied
with
the
solution.
I
got.
C
G
A
A
E
B
I
mean
you
have
50
50
chance
of
getting
it
right.
Okay,
so
then
we
we
normally
just
talked
about
a
structured
authentication
config.
So
Anish
has
one
PR
out
that
I've
reviewed
and
approved,
and
that
needs
approval
on
API
server
changes
and
like
some
vendor
changes
and
then
another.
Unless
you
have
like
a
series
of
PRS
that
you're
working
on
which
I've
been
sort
of
reviewing
with
you,
so
I
guess
David.
If
you're
helping
me
with
that,
that
would
be
fine
too.
D
Yeah
that
one
was
actually
in
my
review
queue
so
I'm
happy
to
try
to
get
through
the
one
that
was
already
in
my
queue.
If
or
if
David
wants
to
pick
it
up.
That's
funny,
but
I
I
told
Anish
I
would
review
it
so
I'm
happy
to.
B
Okay,
good
stuff,
all
right
so
I
think
for
cluster
trust
bundle.
We
just
did
an
API
review
on
some
of
the
stuff.
Recently
I
don't
see
to
hear
on
the
call.
B
Sir,
do
you
know
if
he
plans
on
working
on
it
in
the
coming
release?
I
I
told
you
here
that,
like
Edition
I
would
help
him,
but
I.
D
B
And
then
see,
standard,
U
and
David
are
on
the
call.
Are
you
guys
still
interested
in
the
undecryptable
resources
cap.
C
Oh
yeah,
I
I,
also
work
on
that
and
just
I
I
think
that
I
need
somebody
to
improve
the
Gap
review
things
and
so
on
and
so
on.
B
C
I
think
that
the
most
of
the
parts
that
where
that
were
already
wearing
around
the
API,
oh
a
little
specifically
what?
If
I
only
remember
so.
E
G
B
Okay,
that
would
be
good
to
have
so
on
that
one.
Are
we
so.
A
B
C
That
yeah
I
think
that
the
code
shouldn't
be
too
bad
ones.
Once
we
agree
on
with
the
errors,
look
like
great.
B
Okay,
then
there
was
the
reference
Grand
stuff
I
have
not
spoken
with
Rob
or
Nick.
I,
don't
actually
know
where
we're
at
on
this
stuff.
At
the
moment,.
D
I,
haven't
seen
much
happen
with
this,
given
what
else
we
have
for
implementation?
Stuff
queued
up
I,
don't
know
that
we
would
have
room
for
this
in
129.
B
B
Let's
see,
Micah
I
see
you
on
the
call,
but
I
don't
see
Nick
on
the
call.
Do
you
guys
still
want
this
I
think
you
guys
are
the
primary
Oscars
for
The
Client
exec
proxy.
B
Okay,
I'm
gonna
say
he's
on
leave
because
no
you
can't
you
can't
just
show
up
and
react
being
gone
for
months
and
just
somehow
magically
function.
Okay,
Rita
just
can
you
leave
a
comment
on
fine
exact
proxy
and
to
just
move
it
out
of
the
release?
Oh.
B
Okay,
I
see
I,
don't
see
James
on
the
call,
and
if
we
get
to
it,
we
can
talk
about
the
specifics
on
the
bound
essay
token
Improvement,
since
I
had
the
like
a
stub
PR
for
it
Jordan
and
I
guess
David.
What
is
y'all
sense
for
us
being
able
to
maybe
get
some
of
the
code
in
for
this.
One
like
I
feel
like
the
cap
would
be
pretty
small
for
this
one,
because
I
think
we're
not
asking
for
anything
crazy
right.
B
Right
and
I
I've
spoken
to
Jordan
about
it
a
little
while
back
and
I
tried
to
transcribe
what
we.
G
D
D
B
B
Fine
I
think
we're
all
in
agreement
there
I,
don't
think
the
change
is
anything
dramatic,
either.
So
I
think
that
will
help
okay.
We
can
talk
about
this
more
in
a
little
bit.
If
you
have
time
Rita
can
we
go
back
to
the
other
doc.
B
A
B
Okay,
this
is
one
that
I
haven't
spoken
to
y'all
at
all
about,
but
it
is
something
I'm
quite
interested
in
which
is
and
I
think
this
was
brought
up
in
the
early
days
of
when
we
were
discussing
the
request-
bundle
stuff
with
to
here,
but
basically
I
would
like
to
be
able
to
use
the
certificates
API
to
have
the
sorry,
the
CSR
API
from
the
certificates,
API
Group,
be
able
to
provision
credentials
for
pods
like
via
the
cubelet
kind
of
like
what
we
do
for
token
request.
B
B
B
B
Yeah
so
I
I.
The
reason
I
wanted
to
avoid
a
CSI
driver
is
because
it
just
adds
a
lot
of
Machinery
onto
cubelets
and
I
wanted
to
very
much
be
able
to
run
my
signer
off
of
the
cluster.
B
So
basically
like
co-located
with
my
control
plane,
and
then
you
know
in
the
same
way
that
I
run
controller
manager.
Today,
I
guess
AKs
runs
controller
manager.
Today,.
A
E
E
E
E
B
Yep,
that
makes
sense,
but
that
does
at
least
sound
like
you're
vaguely
interested
or
have
thoughts.
E
I
can
see
why
someone
would
want
to
do
it.
You
know
I,
don't
have
I,
don't
have
an
immediate
use
case
at
this
moment,
I
think
if
I
were
ordering
them
and
saying
like
which
one
gets
me
more
excited
the
workload
certificate
work
gets
me
more
excited.
B
E
Witch
work
workload,
certificate
from
I'm,
gonna
butcher,
his
name
Ahmed.
C
E
B
All
right,
that's
fine,
yeah,
that
makes
sense.
Yeah
I
mean
actually,
it
literally
has
a
signer
name
and
a
service
account
it.
It's
just
a
slight
abstraction
on
top
of
CSR.
B
Okay,
that's
cool!
That's
fine,
though
cool
I
I
thought
to
hear
had
something
like
that
to
it.
I
just
forgotten
about
it.
G
B
Cool
all
right,
we're
done
with
that
one.
For
now
Jordan
you
were
the
one
that
I
saw
reviewing
a
PR
associated
with
the
next
thing.
You
don't.
D
Yeah
I
I,
don't
I'm,
not
convinced
this
is
kind
of
priority.
There
are
some,
so
the
next
thing
was
saying
nodes
are
currently
given
person
to
list
watch
all
pods.
They
happen
to
filter
down
to
just
font
schedule
to
themselves
through
the
field
selector,
but
that's
mostly
for
efficiency
reasons.
That's
not
actually
enforced
and
right
now
authorization
doesn't
have
visibility
to
deal
selectors
label
selectors
to
be
able
to
enforce
that.
So
someone
open
a
pull
request,
doing
some
things
to
try
to
enforce
that
and
I'm
saying
it.
D
If
we're
going
to
enforce
that,
we
should
actually
do
it
by
making
authorization
have
visibility,
the
field
selector
label
selector
and
then
actually
plummet
through
the
authorization
information
I,
see
value
in
having
that
it
raises
a
bunch
of
kind
of
weird
edge
cases.
I
know
David
has
talked
about
that
for
other
things,
I
think
in
reference
Grant,
it
came
up
like
having
visibility
to
labels
and
enforced
permissions
on
label
selection
in
list
watch.
D
It's
come
up
a
few
different
time,
so
there's
probably
something
there
but
priority
wise
I
I.
This
doesn't
seem
like
something
that
we
would
do
next.
There
are
other
things,
I
think
we
would
work
on
or
try
to
complete
or
try
to
get
going
next.
B
A
B
Right
now,
Rita,
when
you
opened
that
issue,
did
he
actually
make
a
kept
doc
right
right?
There's
a
proposal
right
there
right.
B
The
proposal
is
the
pr
I
see
what
he's
doing
yeah.
Okay
well,
either
way
tell
the
person
not
to
write
a
cap,
because
we
won't
read
it.
D
Yeah
I'll
yeah
I'll
point
to
the
stock,
probably
if
we
want
to
order
sort
of
priority
order,
these
things
that
might
be
helpful
to
give
a
concrete
sense
of
like
what
the
other
things
we're
spending
time
on
in
129.
B
Sorry
you're
going
like
going
back.
Okay,
then
we
have
the.
B
We
had
a
cap
that
I
guess
is
currently
closed,
but
it's
still
there
as
a
PR
for
the
external
signing
for
service
account
tokens
I
know
from
last
kubecon
I
had
an
action
item
to
describe
splitting
Trust,
which
I
never
did,
which
I
can
still
do
if
we
care
yeah.
Is
this
a
priority
for
us?
Also
I
see
Michael
you're
on
the
call
and
I
see
you
are
you're
on
the
call
you
all
still
care
before
we
even
ask
if
there's
priority?
Yes,
okay,.
B
Okay,
so
they're
like
maybe
is
it
like
Jordan
David
Mike's,
not
here
I
would
ask
Mike.
Mike
is
probably
the
best
one
in
terms
of
this
one
I'm
trying
to
think
of.
D
B
B
The
first
one
I
know
we
don't
really
hear
about
this
and
say
odds,
but
apparently
I
was
talking
to
Anish.
Apparently
people
do
ask
about
this
in
secret
CSI,
not
too
infrequently,
which
I
guess
kind
of
makes
sense,
because
it's
kind
of
all
that's
what
secret
CSI
is
all
about
is
having
volumes
with
secrets.
So
I
guess
the
people
that
care
show
up
there
and
ask
about
it.
B
G
C
D
D
That
requires
like
opt-in
or
adoption
by
everybody
in
order
to
be
effective
as
limited
right
out
of
the
gate
in
terms
of
how
big
of
a
dent
it's
going
to
make
like
security
posture,
if
we
have
other
mechanisms
for
people
to
get
access
to
Secrets
like
fetching
them
from
the
API
which
was
mentioned
here
for
people
who
are
worried
about
that,
don't
want
these
things.
Persistent
on
disk
inside
their
containers
like
there
is
already
a
thing
they
can
do
to
get
up
an
API
and
hold
it
in
memory
and
then
clear.
D
The
memory
when
they're
done
using
it
like
there
are.
There
are
alternate
things
we
can
recommend
today:
I'm
not
really
sure
like
a
complicated
and
sort
of
encrypted
on
disk,
and
then
you
get
the
key
from
somewhere.
I
think
I
just
have
a
hard
time,
seeing
something
like
that.
Getting
wide
adoption
so
I'm
not
sure
how
much
effort
it's
worth.
B
Do
you
have
a
sense
of
like
what
people
ask
for
us
see,
hey,
look
I,
see
the
link
where
you
probably
the
encryption
of
mounted
contents
yeah.
G
I
think,
like
the
most
common
scenario,
is
because
we
do
temp
FS
on
Linux,
so
we
do
whatever
we
do
with
kubernetes.
You
can
mount
it
as
volumes
right
and
the
question
that's
often
asked
is
like
hey.
Is
there
a
way
these
can
be
encrypted
in
the
file
system
and
with
the
CSI
driver
approach
like
one
of
the
things
that
we
show
off?
Is
the
power
portability
rate
like
if
you're
moving
from
one
cloud
provider
to
another
and
so
you're,
just
relying
on
file
systems?
G
You
don't
have
to
make
any
code
changes
so,
like
you
can
use
Secrets
manager,
you
can
use
like
Azure
keyboard
and
you
can
just
move
the
application
to
a
different
cluster
or
a
different
sequence
manager.
So
I
think
a
lot
of
users
have
been
adopting
CSI
and
they
want
to
take
advantage
of
it.
And
then
we
get
asked
this
question
that
it's
all
available
in
plain
text.
Is
there
a
way
we
can
encrypt
it
and
whatever
we
do,
it
won't
be
specific
for
CSI
like
it
would
just
be
for
every
other
thing.
D
My
sense
for
this
issue
was
less
about
the
container
being
able
to
read
it,
but
that
if
the
container
was
compromised,
something
else
was
running
in
that
process.
Space
it
couldn't
just
read
plain
text
from
any
file
container
process
has
access
to
like
more
another
step
would
be
required
like
getting
a
key
from
somewhere
in
order
to
decrypt
the
thing
on
the
file
system.
But,
like
my
question,
is,
however,
you
Pro.
You
know
that
the
container
needs
to
get
that
key
from
somewhere
to
make
use
of
this.
D
You
can
become
more
and
more
elaborate,
like
you
need
information
from
the
file
system,
and
then
you
need
to
get
the
key
from
somewhere
else
to
do
the
decrypt
or
you
do
it
and
it's
only
available
at
start
time
and
then
it
becomes
unavailable.
So
there's
like
a
window
where
the
the
decrypting
key
or
the
secret
content
is
available.
D
D
I
think
before
we
spend
a
lot
of
time
and
effort
building
something
in
to
do
those
things,
you
need
to
be
pretty
confident
that
it's
going
to
be
worth
the
effort
that
it
will
actually
get
adoption
and
people
will
actually
use
it
in
ways
that
people
who
can't
use
the
existing
sort
of
emulation
mechanisms.
D
Like
as
soon
as
you
make,
the
container
process
have
to
do
something
other
than
read
it
from
a
file
like
that
impacts,
their
application
logic
right.
They
have
to
integrate
with
some
library
or
go
change.
The
their
program
to
go
do
a
thing,
and
as
soon
as
you
do,
that,
like
the
bar
for
difficulty
of
consumption,
goes
up
like
orders
of
magnitude.
D
B
I,
don't
that
sentence
is
less
clear.
I
think
there's
a
lot
of
context
in
what
they're
saying
that
involves
the
like
the
50
comments
above
them.
So
it's
okay,
based
on
this
discussion,
Anish,
if
I,
could
give
you
an
action
item
based
on
what
we
just
talked
about.
Could
you
maybe
make
a
comment
on
that
issue?
B
B
We
would
need
stronger
evidence
that
it
meaningfully
raises
the
bar
and
it
would
actually
have
adoption
basically
I
think
what
I
got
from
Jordan
is
that,
like,
like
any
implementation,
would
be
non-trivial
for
both
the
application
consumer
and
us
the
kubernetes
Developers?
E
B
G
Then
also
just
for
context
right
like
when
we
had
users
asking
about
it,
we
were
trying
to
come
up
with
a
way
to
do
it.
In
the
CSI
driver,
like
we
tried
a
bunch
of
proposals
and
pocs,
but
everything
required
like
application
changes,
and
it
would
there
was
no
generic
way
to
do
it
like
you
had
to
come
up
with
different
ways
for
different
providers,
and
at
that
point
it
just
made
more
sense
to
for.
A
D
The
the
only
generic
mechanism
I
can
think
of
is
once
the
container
is
healthy,
like
unmount
the
volume
or
remove
the
content
from
the
file
system,
like
assume
that
it
only
reads
it
on
Startup
and
once
the
thing
is
running
and
healthy
and
ready
and
like
whatever
signals
they've
put
on
the
container,
then
clear
it
all
like.
That's
the
only
generic
thing
I
can
think
of
the,
and
that
mechanism
would
belong
entirely
to
six
storage,
like
that
would
be
an
option,
probably
for
config
maps
and
secrets,
and,
like
I,
mean
all
of
these
all.
D
I
mean
the
compromise
of
the
container
is
probably
more
the
concern
right
and
if
you
compromise
a
container
and
then
the
container
gets
reinitialized.
Presumably
your
compromise
isn't
persistent
between
different
instances
of
the
container
or
it's
less
likely
to
be.
You
know
if
I
compromise
a
web
server
I
get
into
that
process
and
then
I
crash
it
and
another
new
container
starts
up
well.
E
D
Naive,
the
the
concern
that
I
hear
in
the
issue
is
from
people
who
don't
control
the
application
code,
but
do
want
to
protect
against
file
system
exposure,
and
that
intersection
seems
really
weird
like
they
don't
control
the
application
code.
So
they
can't
make
it
go
fetch
the
API,
the
secret
from
an
API,
but
they
do
want
to
do
things
like
require
decryption
of
content
on
disk
that
require
changing
the
application
code,
like
that,
I,
don't
see
how
those
two
things
can
both
work
together.
C
B
Okay,
I,
don't
see
Tim
all
clear
on
the
call,
but
I
was
going
to
ask
him
if
he
had
any
interest
in
working
on
all
the
random
things
that
people
keep
asking
about
like
I
want
this
tiny
change
in
audit
logs,
which
some
of
which
are
like
good
and
some
of
which
are
not
great.
B
This
is
just
one
of
those
like
there's
like
many
many
issues,
kind
of
like
this
one
I
don't
know
if
we
necessarily
need
to
dive
into
those
right
now,
but
yeah
I
think
this
one
and
like
the
system
called
Masters,
rename
I've
just
kind
of
been
hanging
out
as
placeholders,
but
nobody's
said
that
they
were
interested
I,
think
those
are
things
that
we
could
theoretically
work
on.
If
someone
was
interested
okay,
do
we
want
to
order
things.
B
E
B
C
C
E
Yeah
you're
timing
on
that's
awesome,
though,
don't
you
Jordan,
never
gonna
finish.
It.
D
B
D
Like
the
the
projected
volume
aspect
makes
the
existing
API-
that's
already
merged
you
actually
usable
for
pods,
so
getting
that
in
Alpha.
So
it
can
progress
like
that's
part
of
making
the
existing
work.
Usable
so
I
think
that's
probably
more
important
than
starting
a
new
thing.
G
B
B
D
I'm
moving
PMS
up
to
implementable,
since
it's
the
only
one
that
doesn't
actually
need
kept
work.
C
A
I
mean
technically
to
an
technically
authorizational
authentication.
Configs
are
also
implementable
right
because.
B
G
D
In
my
mind,
those
should
be
the
default
top
of
listings
unless
something
is
just
clearly
more
important,
but
taking
the
things
where
we
actually
figured
out
what
the
design
should
look
like
and
we're
done
with
that
I
think
we
should
make
progress
on
or
make
a
conscious
decision
to
say
you
know
what
we're
going
to
defer
implementation,
but
it's
by
default.
Let's
implement
the
things
we
already
hammered
out
to
find
one
okay.
D
My
my
default
secondary
ranking
is
like
what's
the
current
stability
level,
so
KMS
being
beta
to
me,
says
that
should
be
the
priority
thing
like.
We
should
finish
beta
things
before
we
introduce
new
Alpha
things
or
continue
progress
on
Alpha
things.
So.
F
B
G
D
Yeah
I
guess
things
that
we're
planning
to
work
on
caps
for
in
the
one
in
29
time
frame.
So
undergradable
resources
sounds
like
we're
wanting
to
make
progress
on
the
cup
there.
The
bound
token
improvements,
I
think
that
design
is
going
to
be
small
enough
that
that's
reasonable
to
pull
into
129
and
useful
enough
like
it,
it's
filling
a
gap
in
that
people
have
with
tokens
today
and
I.
Think
it'll
be
pretty
small.
B
Next,
going
to
fast
food,
I
can't
read.
B
B
D
Not
necessarily
I
think
it's
best
effort
right,
like
the
the
things
that
we're
actually
wanting
to
get
a
design
nailed
down
for
129
are
going
to
get
priority,
and
so,
as
we
have
bandwidth,
I,
think
it's
okay
to
revisit
other
things,
but
it's
like
if
we're
choosing
between
things
in
the
review
between
stuff,
that's
being
implemented
or
stuff.
That
is
in
the
list
for
like
we're
going
to
try
to
get
this
nailed
down
for
129.
D
G
B
Was
what's
after
five
and
sorry,
what's
that
so?
Okay,
are
we
saying
we
won't
order
anything
after
six,
because
those
are
everything
after
number?
Six
is
this
best
effort
anyway,
so
there's
in
the
priority
is
that
what
we're
saying.
B
Okay,
so
that's
reference
Grant
and
client
exec
proxy.
We
said
we're
going
to
move
out.
This
one
is
just
about
making
a
design.
B
Where
do
we
land
on
external
signing,
I
heard
from
David,
and
you
Jordan
I,
guess
that
it
wasn't
a
high
priority
for
you
guys,
and
the
same
is
true
for
me.
So
I'm
assuming
it's
just
gonna
stay
there
better,
oh
yeah,
and
we
talked
about
the
other
stuff.
B
B
The
ordering
we've
still
got
10
minutes
if
we
want
to
talk
some
more
about
the
bound
essay
token
stuff,
so
Jordan
I,
don't
know.
If
you
had
a
chance
to
read
that
paragraph
I
tried
to
write
down
what
we
spoke
about
into
what
I
thought.
You
said.
D
Yeah,
so
the
the
two
main
questions
I
had
were
about
privacy
of
user
info
like
human
user
info,
especially
and
token
size,
pragmatic
things
like
only
including
the
username
in
uid
and
not
groups
and
figuring
out
what
we
do
if
I
took
you
use
a
token.
You
request
a
token
to
request
a
token
to
request
a
token
like.
D
Do
we
compress
the
chain
of
requesters,
or
do
we
only
have
the
first
and
last
in
the
list
or
like
figuring
out
how
we
keep
the
token
from
just
growing
in
size
in
unbounded
ways,
while
still
giving
visibility
to
sort
of
the
the
original?
Where
did
this
the
original
token
in
this
chain
come
from
and
what
was
the
most
recent
requester
so
first
and
last
is
probably
what
I
would
do
I.
D
It
would
be
good
to
hear
from
people
in
different
environments
who,
like
what
the
considerations
are
for
putting
human
usernames
into
claims.
That
would
then
be
visible
to
anyone.
They
presented
the
token
to
I.
Don't
know
if
that
presents
like
pii
personally
identifiable
information
concerns
or
not.
Obviously,
the
API
server
already
has
visibility
to
that.
D
Because
you're,
you
know
making
request
to
the
API
server,
but
then
to
take
that
information
and
put
it
in
a
claim
that
other
consumers
of
the
token
could
see
so
that
that
would
be
something
we
might
like
send
out
to
the
list
or
kind
of
talk
to
different
providers
and
ask
like:
is
this
a
concern?
If
we
hear
that
it
is,
we
might
consider
scoping
this
just
to
system
users,
although
that
kind
of
hurts
some
of
the
value
of
this.
D
C
B
D
F
F
C
B
D
Information
is
there.
Well,
the
information
is
not
there.
Once
we
put
a
identifier
on
the
token,
the
information
could
be
there
if
you
went
back
to
an
audit
log,
but
it's
certainly
inconvenient
to
correlate
so
I
think
the
minimum
is
putting
an
identifier
on
the
token
instance
and
making
that
part
of
the
audit
log,
so
that
someone
could
correlate
a
particular
credential
with
a
particular
request
that
emitted
that
credential.
D
Right,
whether
we
want
to
make
life
easier
for
people
or
make
it
possible
for
people
who
don't
have
access
to
audit
logs,
we
may
but
yeah,
we
need
to.
We
need
to
understand
what
we're
exposing
and
size
downside.
G
B
It's
just
less
useful,
but
it
would
still
be
in
the
audit
log
with
the
once
we
had
the
identifier,
so
you
so,
sir,
so,
basically
in
all
states,
the
audit
log
is
complete.
As
long
as
you
keep
all
the
events.
C
B
B
I
was
gonna,
ask
like
would
if
we
were
concerned,
like
let's
say
we
get
feedback
that
people
are
concerned
about
pii
and
we
scope
it
down
to
some
set
of
identities
where
we
would
give
people
the
option
of
not
scoping
it
down
like
like.
We
would
probably
default
to
the
scope
down
approach,
then
I
guess
I,
don't
know.
B
C
D
C
D
It
is
an
on
system,
one.
We
could
just
collapse
that
to
say
a
non-system
user
requested
this
or
we
could
emit,
omit
the
claim
and
for
people
who
wanted
to
include
the
username,
no
matter
what
good
I
think
we'd
probably
wait
until
we
hear
back
about
whether
it's
an
issue
or
not
to
think
about
what.
B
I
think
so
the
other
thing
I
think
Jordan
you
and
I
spoke
about.
Is
you
I
think
you
mentally
mapped
this
in
the
same
way
that
we
have
impersonation
today,
which
is
that
impersonation
is
a
concept
that
audit
fully
understands,
but
basically
nothing
after
the
impersonation
layer
can
make
any
decisions
based
on
the
fact
that
the
request
was
impersonated
and
based
on
that
sort
of
train
of
thought.
I
think
your
desire
was
to
not
include
any
new.
B
Like
you,
I
mean
you
did
not
want
to
include
any
of
The
Originals
requester
information
in
the
user
info
that
the
service
account
presents
to
the
API
on
the
basis
that
people
would
do
bad
things,
basically
in
authorization
or
admission
right
that
you
are
the
service
account,
but
the.
D
D
Yes,
I
I
think
if
who
requested
the
credential
the
who
requested
the
credential
as
an
attributed
to
credential,
it's
not
an
attribute
of
the
principle
identified
by
the
credential
and
so
Translating
that
into
user
info,
so
that
I
think
people
would
do
bad
things
with
it
and
it
just
seems
like
a
layer
violation,
it's
better
to
omit
it
for
now
and
if
there's
evidence
that
we
should
include
it.
B
D
Oh,
oh,
knowing
the
first
requester
of
the
token,
so
if
I
get
a
token
and
then
use
that
token
to
get
a
token
and
use
that
token
to
get
a
token
and
use
that
token,
to
get
a
token
knowing
who
got
the
first
token
is
the
one
you
care
about.
Is
that
what
you
meant.
A
F
F
B
Jordan
on
the
whole
impersonation
thing,
so
how
would
we
sort
of
document
our
rationalization
about
the
claims
are
sort
of
there
in
the
payload
and
they
do
include
all
the
requests
or
information?
So
if
you
are
an
entity
like
an
STS
endpoint
for
a
cloud
provider.
D
D
That's
the
part.
Those
things
are
not
deciding
whether
a
credential
is
valid,
like
the
authentication
layer
decides
if
a
credential
is
valid
once
a
credential
has
been
decided
to
be
valid
like
another
layer
sort
of
undoing.
That
decision
and
saying
like
this
was
a
valid
credential
that
identified
this
service
account,
but
because
of
who
got
that
credential
I,
don't
I,
don't
think
this
request
is
actually
authenticated,
like
I.
D
Who
requested
a
credential
doesn't
seem
relevant
after
you've
decided?
The
credential
is
valid
to
identify
that.
C
B
E
E
B
E
D
E
Those
things
I
I
would
just
like
to
clarify
between
a
permanent,
not
never
and
not
yet,
but
maybe.