►
From YouTube: Security Policy Working Group Meeting 11.15.17
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
B
B
B
So
the
three
important
component
is
one:
is
we
how
to
filter
on
how
to
select
policy
for
what
connection
we're
going
to
use
the
same
match,
rules
that
we
have
with
general
CID
config?
So,
basically,
you
can
specify
what
is
a
client's
service,
name
or
service
on
your
space
and
target,
which
is
the
workload
name
and
service.
B
B
B
So
for
the
policy
itself,
we
separated
in
two
parts
of
privacy
which
concern
only
like
using
plain
text
or
TOS,
and
the
credential
is
specify
what
can
be
used
for
the
authenticate
so
for
credence.
So
it
can
be
like
mpos,
which
somewhat
imply
privacy
had
to
be
used.
Trs
had
to
be
used,
oh,
it
can
be
as
a
method
like
salt
or
IP,
IP
or
etc,
or
we
can
even
specify
custom
which
the
user
can
provide.
B
C
B
B
Sorry
just
take
notes:
okay,
Noorie,
so
basically
for
the
credential.
We
have
a
method
to
defy
what
what
a
decent
type
going
to
be
used
commands.
That
is
argument,
which
is
that
can
provide
us
information
to
supplement
the
implementations
and
the
actual
beauty.
Basically,
the
output
is
what
can
be
used.
What
can
what
they
should
output
to
be
used
for
the
next
set
like
authorizations
of
the
end-user
authentications.
B
B
One
will
be
inactive
to
make
the
server
ready
to
handle
it,
but
not
accepting
the
supplier
would
have
to
use
that
one
year
and
then
we
update
the
policy
to
flip
the
active
to
inactive
and
vice
versa,
to
help
bind
the
switch
to
use
a
new
policy,
and
then
the
last
step
is
migrate.
Is
move
the
old
policy
away.
So
why
is
it
that
we.
C
C
C
B
B
C
C
That
would
definitely
be
preferable
right
to
have
have
one
CRT
that
your
your
modifying,
even
if
it
contains,
even
if
that
one
CRT,
contains
two
policies
but
like,
if
you're
separating
this
this
out
right,
there's
two
objects
that
you're,
manipulating
and
one
you
mark
inactive
is
actually
having
and
the
the
presence
or
absence
of
an
inactive
object
like
actually
changes
what
the
cluster
is
doing.
That's
that's
super
weird.
B
C
A
C
A
B
B
A
A
So
so
country
we
have
active
discussion
inside
Google
because
we
have
several
epic
systems,
including
how
the
I
am
and
the
FCC
care
policy,
and
we
are
discussing
which
style
we
should
follow
like
a
kubernetes
could
be
naughty
uppercase,
similar
to
a
cloud.
I
am
style,
but
it
has
some
chicken
rice
difference
as
what
I
will
explain.
A
So
in
a
cloud
I
am
style.
We
have
explicit
a
low
definition,
you
define
row
object
and
the
rotating
object
and
the
in
cloud
I
am
the
rows,
are
defined
our
resource
type
and
then
in
the
Piney.
You
basically
find
the
resource
instance
to
the
row.
Row
object.
So,
for
example,
the
row
is
a
project
editor
and
in
the
binding
you
can
bind
it
to
a
specific
project,
so
cloud
I
am
actually
has
the
syntax
called.
A
Who
has
water
on
what
resource
instance
and
the
cloud
I
am
also
provide
a
resource
hierarchy
in
the
absolute
security
policies
is
a
little
different
style.
It's
designed
to
support
master
level
access
control,
so
it
herself
file
every
service
has
the
policy
file
and
the
in
a
policy
file.
You
define
some
permission
stream.
You
say
in
order
to
access
this
method,
you
need
this
permission
and
then
you
find
this
list
of
permissions
to
a
list
of
subjects.
So
so,
in
this
case,
there's
no
explicit
low
definition.
A
A
So
this
is
a
place.
I
could
call
it
this
time.
If
you
look,
if
you
take
a
look,
it's
actually
actually.
My
first
proposal
was
based
on
these
certain
styles,
as
as
I
said
it
has
the
mappings,
and
in
this
case
I
said,
the
resource
type
is
the
service.
So
we
have
list
of
methods.
Oh,
oh
it
because
the
resource
type
is
a
service,
so
actually
the
resource.
Here,
oh
refer
to
a
service
names.
A
A
And
this
our
current
design,
so
our
current
is,
did
I.
We
have
the
service
row
and
the
service
are
open
D,
so
so
in
so
we
are
defining
the
same
policy
just
using
different
language.
In
this
language
we
have
a
low
definition
which
is
defined
on
the
service
object.
We
are
saying
services
rating,
so
this
row
applies
to
this
rating
service
and
the
service
row
painting
Pines
the
rating
service
total
subject,
which
is
a
service
account.
A
You
can
see
that
the
differences
in
the
in
a
physical
equality
style
everything
with
the
within
one
file,
so
this
file
applied
for
a
service
or
apply
to
a
namespace
and
in
the
second,
in
the
current
design,
we
have
Rho
object
and
an
opening
object,
so
the
current
design
is
actually
more
close
to
the
Canadian
style.
I
suggest
go.
A
C
Only
can
it
can
be
to
more
than
one
though
yeah.
Yes,
since
there's
there's,
you
can
have
multiple
rules
like
the
two
examples
that
you
have
are
each
like
one
service,
but
you,
you
could
have
a
role
that
includes
permissions
on
multiple
services,
right
yeah,
as
long
as
they're
in
the
same
namespace,
yeah.
A
A
Think
the
use
case
our
here
mentioned
the
Islam.
They
want
to
have
a
general
row
that
a
predefined
der
Rohe
that
can
apply
to
different
service,
like
every
service,
has
different.
For
example,
you
have
one
service
counters
will
be
able
to
access
service.
A
another
service
can't
be
able
to
access
service
P.
In
this
case,
we
need
to
define
two
rows.
One
row
for
service
a
the
other
row
for
service
P
and
then
create
the
corresponding
bindings.
For
that.
A
Yeah
I'm
just
a
little
difference
country.
That's
the
no
conclusion
which
style
we
want
to
go
is
actually
from
from
Montana
I
actually
prefer
to
a
CO
is
the
Condor
style,
because
it's
create
a
more
consistent
user
experience
for
community
users.
We
propose
to
use
community
event
or
set
access
control
for
modifying
the
course
itself.
Modifying
is
the
effect
itself
and
though
we
want
to
have
the
same
style
for
our
user
tool
to
be
able
to
set
SS
control
further
for
their
services.
A
A
C
A
A
D
C
A
Actually,
I
I
want
you
to
show
some
talks.
I
actually
try
to
suppose
this
proposal.
We
actually
can
group
the
the
number
of
services
using
the
custom
attributes
like
you.
Can
you
can
using
some
label
called
a
TV
and
attached
to
different
services?
And
you
can
say
one
user
can
access
all
the
TV
services
and
the
crater.
We
can
create
a
row
for
all
the
TV
service
and
I.
Also.
A
A
A
Yes,
oh
so
I
was
trying
to
come
up
with
some
proposal
tool
to
provide
a
predefined,
a
row
scenario
yeah.
Basically,
we
want
to
provide
some
predefined
a
row
and
then
reuse
it
for
different
services,
and
this
is
just
general
idea.
I,
don't
think
we
want
to
push
it
forward
at
this
moment.
So
I
want
to
consider
this
as
a
some
possible
extension
to
the
current
iPad
model.
A
So,
in
this
proposal,
register
I
want
to
introduce
some
parameter
to
the
row.
Like
so
calculating
the
services
we
just
thought
directly
post
to
a
service
name,
but
instead
we
can
just
use
some
parameter
here,
and
this
row
is
called
a
service.
Add
me,
and
you
can
create
a
row
binding
to
to
find
this,
so
it's
admin
to
any
so
is
like
in
the
row
reference
you
can.
You
can
specify
was
this
suicide
mission.
A
service
name
should
be
so
so
facilities
in
the
pending.
A
A
In
addition,
we
may
also
extend
it
to
supporter
access
control
for
customer
resources,
I
call
it
the
resource
level,
access
control,
and
so,
for
example,
you
can
consider
a
customer
resource
as
the
Box
total
shelf
and
the
chef
ID
is
the
resource
ID.
So
so
you
can
also
extend
this.
The
parameter
concept
tool
to
the
pass.
A
Basically,
the
chef
ID
here
is
the
pass
inside
pass-
is
the
resource
ID
inside
the
pass,
and
similarly
you
can
also
supply
the
resource
ID.
For
for
this
parameter,
chef
idea,
like
you
can
say
this
user
ID
service
account
for,
has
access
to
a
particular
post.
Op
box
store
shelf
Acme
object,
so
this
will
make
other
role
more
reusable
and
also
potentially
support
the
access
control
for
customer
resources,
but
I
I,
don't
know
yeah.
A
C
A
C
C
A
I,
don't
think,
there's
a
formal
decision.
Yet
that
is
are
the
extensions
just
the
sample,
installing
I
I,
don't
think
leases
are
taking
into
account,
so
you
may,
as
although
I
bring
bring
up
this
extension,
I
just
want
for
brainstorming,
it's
not
actually
in
any
of
the
execution
plan.
So
from
my
cider,
it's
just
a
my
personal
opinion.
I
want
to
have
the
first
step
be
able
to
give
you
the
count
per
bottle.
Then,
after
that,
maybe
we
can
consider
some
extension
yeah.
A
D
A
D
A
E
F
I'm
bhatia
are
working
on
API
management.
Support
for
east.
To
the
you
know,
rough
high-level
idea
is,
you
know
to
enhance
the
current
East.
You
capability,
you
know
in
terms
of
quota,
and
you
know
metrics
reporting
and
lovely
protein
right
and
it
haunts
them
with
for
API
level
control.
We
are
also
planning
to
add
it
like
you
know,
API
key
and
other
than
that.
You
know
we
want
to
support
the
for
API
authentication
and
authorization
right.
Obviously,
there
are
some
overlap
between
the
API
management
capability
and
the
security
capability.
F
So
I
would
like
to
do
this.
As
you
know,
the
John
effort
right
currently,
you
know
just
to
block
you-
know
the
API
management
capability.
We
were
not
proposing.
You
know
how
we
are
going
to
implement
the
authentication
and
authorization
I.
Think
in
the
last
security
meeting
we
talked
about,
you
know
we
need
to
bring
down
the
authentication
with
authorization
and
we
prefer,
to
you,
know,
enforced
authentication
in
the
proxy
and
authorization
to
be
to
be.
You
know
checked
in
mixer
size
right
because
of
potentially
the
authentication
need
to
be
enforced
by
us
Beckett
right.
F
E
So,
to
hopefully
make
this
easier,
I
want
it.
We
want
it
to
I,
want
to
narrow
the
scope
of
auth.
So
it's
not
working
off
policy
for
all
of
this.
Do
its
end
user
auth,
specifically
covering
job
validation
and
a
makey,
should
be
extraction
and
that's
what
the
PR
that's.
The
motivation
for
the
PR
was.
We
are
kind
of
coming
through
some
of
this
from
the
proxy
to
the
party's
configuration
from
pilot,
and
we
need
to
provide
a
configuration
to
the
mixer
client
says.
Here's
there's.
E
So
the
intent
is.
This
is
not,
ideally,
this
wouldn't
be
user
facing.
This
would
just
be
some
internal
implementation,
detail
between
data
rates
of
proxies
configuration
pilot
and
the
proxy
or
mixture
client
itself.
If
there's
some
other
top
level
off
policy,
your
security
policy
that
we
can
derive
this
from
once,
that's
in
place
perfect,
but
we
don't
have
that
yet
so
again,
that's
the
context
is,
is
the
what
the
mixture
client
is
consuming.
Foreign
aid
users
are
off,
so
it
doesn't
we're
not
getting
them
and
TLS
or
anything
like
that,
and
so
this
is.
E
E
So
we
have
the
issuer,
so
there's
there's
ways
that
this
is
repeated
and
mapped
onto
different
services.
But
this
is
a
specific
instance
about
a
validate
you
know
dot.
So
the
the
issuer,
some
of
the
created
list
of
audiences,
the
URI,
where
we
would
that's
the
public
key
from
and
then
here
there
is
some
option
about
whether
we
should
board
that
on
to
the
mixture
or
not
so
it's
in
case
it
might
be
a
security
issue
or
maybe
it's
it's
not
necessary,
require
that
make
sure
it's.
E
E
F
E
E
F
F
C
E
Says
here
about
removing
it
from
the
HTTP
request,
think
the
14
is
correct.
The
words
that
came
out
of
my
mouth
just
now
we're
wrong
yeah
when
in
doubt
refer
to
what's
written.
So
so
that's
that
by
itself
is
it's
a
direct
mapping
of
the
existing
filter
and
then
how
that
maps
onto
so
how
they
make
sure
client
uses
that
they
don't.
We
don't
have
this.
This
spec
there's
some
composability
here.
This
might
be
over-engineered
and
I'm
happy
to
strim
things
out,
but
there's
some
way
to
compose
that
I
think
the
first
thing.
A
E
E
We
will
apply
policy
based
on
an
actually
match,
rather
than
so
it's
a
very
generic
mechanism
that
would
apply
for
a
service
level
policy,
but
also
an
operation
or
an
API
method,
and
you
could
refine
it
further,
but
typically
that
would
be
a
sort
of
a
destination
service
or
an
API
operation
say
for
this
operation.
We
want
to
climb
something
drop
validation
in
this
specific
validation.
I
may
be
for
another
method.
E
C
E
C
C
E
All
gets
derive
from
someone
from
the
open,
API
spec
for
our
purposes,
and
so,
if
you
define
a
an
API
that
has
three
different
methods,
which
we
call
or
three
different
operations
say,
two
of
those
could
have
validation
and
the
third
would
not.
You
would
defer.
That
would
manifest
itself
here.
As
an
end-user
otha
policy
policy,
would've
actually
match
for
the
two
operations.
Did
you
have
that
validation
and
but
that
wouldn't
match
the
third
operation
that
didn't
have
top
validation?
So
so,
in
that
case,
it
wouldn't
match,
and
you
wouldn't
apply,
I
mean.
C
A
F
You
know
these
contexts,
we
are
focusing
on
the
authentication.
Well,
it
is
whether
the
jawed
is
a
valid
job,
cooking
or
not.
Right,
that's
the
first
question
and
the
second
one
is,
even
if
you
can
average
it
onto
there,
maybe
you're
not
allowed
to
access
something
that
is
authorization
party
right
folks,
all
up
in
the
kitchen
you
know
about
you
to
validate
whether
you're
talking
is
valid
or
not
right,
so
what
kind
of
rows
or
what
it
kinda
mean?
Obviously
you
know
you
just
check
that
you
know
the
signature.
C
E
C
E
F
E
C
A
Sir,
so
I
think
the
the
binding
is
talking
about
the
requirement
for
the
authentication,
so
you're
saying
for
this
service
are
required.
Your
authentication,
then
then
you're
each
job
policy
is
specified
one
choice
provider.
Basically,
you
need
to
make
sure
the
job
you're
after
the
chart,
the
issue
of
you,
the
match
is
one
of
the
issuer.
Allow
the
issuer
in
the
list.
Okay,
that
totally
makes
sense:
okay,
yeah
what
it
is.
B
F
C
A
C
Mean
I
think
the
the
idea
of
of
allowing
especially
with
the
aura
rules
definitely
makes
sense,
because
you
may,
you
may
want
to
accept
jots
from
say
more
than
one
issuer
right,
for
example,
so
like
that
that
definitely
makes
sense
to
me
right
out
of
the
gate.
It's
this
attribute
match,
maybe
maybe
not
I'm,
not
I,
don't
necessarily
object
to
it,
but,
like
that's,
that
seems
to
be
much
less
valuable
than
just
the
ability
to
sort
of
compose
these
things
into
saying,
like
I
want
to
be
able
to
exit,
accept
jobs
from
multiple
places.
E
C
I
mean
unless
you're,
unless
the
the.
So,
if
the
design
is
that,
like
a
failed
like
a
missing
job
or
an
invalid
jot
automatically
like
stops
the
request,
then
you
absolutely
do
need
to
be
able
to
I
guess
control
exactly
what
its
gonna
apply
to
below
the
level
of
a
service,
because,
as
you
say,
not
every
API
endpoint
may
require
it,
but
the
the
other
design
would
be
to
say
we're.
Gonna
accept
jots
for
this
service
and
then
sort
of
regardless
of
whether
a
job
was
provided
regard
like
I
guess.
C
F
Even
further
argue
with
that,
you
know
or
even
fear
the
API,
you
know
say
the
they
want
him
on
your
method.
There
will
only
be
operational.
I
will
only
be
service
level.
We
want
to
reject
if
there's
no
door
token
provided
right.
There
should
be
part
of
it.
That
makes
a
check.
That
is
a
decision
we
made
by
the
tech
mast,
not
all
proxy
level.
F
A
E
F
F
A
C
E
So
there's
also
we've
talked
to
it
open,
API,
there's
cases
if
somebody
has
an
API,
but
they
don't
necessarily
so
open
API,
in
which
case
they
could
compose
an
equivalent
granularity
by
saying
by
just
specifying
using
the
the
attribute.
That's
a
call
the
request
path
in
the
request
method,
right,
which
is
it's
roughly
similar
to
an
API
operation,
but
you
can't,
if
you're,
not
doing
a
prefix
match
or
a
templated
match,
but
but
it
is,
there
is
additional
granularity,
like
you
said,
beyond
just
the
service
level,.
F
E
E
We
have
a
good
idea
now
of
what
we're
actually
trying
to
do
here.
Lord
trying
to
do
and
yeah
I
think
so.
If
so,
can
we
follow
up
either
offline
through
the
PR
and
comments,
or
is
there
a
fundamental
problem
here
or
is
it
just
I
mean
I'd,
be
happy
to
change
a
representation
of
that
match?
I'm
a
thirty
there's
something
else
that
people
are
more
comfortable
with.
For
example,
if
there
was,
it
was
explicit
like
an
operation
ID
or
a
service.
C
E
C
That's
about
where
you
locate
those
responsibilities,
not
what
is
the
extent
of
of
those
responsibilities?
Basically,
this
is
about.
Where
do
you
draw
the
line
between
authentication
and
authorization?
Not
where
do
you
where,
in
the
network
architecture,
do
you
locate
the
things
that
are
performing
those
responsibilities,
which
is
what
this
document
is
about?
C
E
And
so
the
goal,
what
are
the
things
I
try
to
do
is
narrow
the
scope
of
this
as
well.
So
it's
it's
not
the
impact.
If
you--if
we
have
to
tweak
this
a
little
bit.
Is
it's
not
user
facing
in
the
same
way
as
the
security
policy
that
you
discussed
at
the
beginning
of
the
movie,
so
it
could
be,
can
still
I
guess
the
borrower
is,
it
may
be
a
bit
lower
in
terms
of
it's
not
set
in
stone.
The
first
time
we
push
the
PR
yeah
yeah.