►
From YouTube: CNCF Notary Project Meeting 2020-06-15
Description
CNCF Notary Project Meeting 2020-06-15
C
A
A
D
So
I
think
at
least
one
avenue
of
discussion
here.
We
also
added
a
few
scenarios
that
I
think
are
lacking
from
the
document
that
are
not
necessarily
the
most
important
scenarios
to
they're
useful
scenarios
to
have,
because
I
think
that
the
next
level
of
questions
will
be
what
about
these
things.
But
they're.
Not.
I
can
understand
why
they
weren't
in
the
original
document,
because
they're
more
of
the
less
common
cases
like
setting
up
setting
things
up
when
they're
not
already
set
up.
A
D
Yeah
I
mean
there
are
things
that
have
to
be
handled,
they
have
to
be
somewhere,
we
put
them
somewhere
and
I
don't
think
I
mean,
I
think
the
actual
steps
you
do
are
very
slightly
different,
but
I
don't
necessarily
think
the
number
of
steps
or
the
like
the
the
purpose
of
the
step
is
fundamentally
different
across
different
solutions.
I
think
it's
just
a
matter
of,
maybe
you,
you
know
you
put
your
signature
here
versus
there
or
you,
like.
A
A
E
If
it's
okay,
I'd
like
to
have
a
quick
discussion
about
the
this,
this
idea
of
targets
delegation,
because
I
think
that
in
whatever
solution
can
we
come
up
with
this-
will
be
an
issue
that
we'll
want
to
figure
out
is
kind
of
who's
in
charge
of
delegating
control.
To
who
like
when
a
developer,
you
know,
joins
a
product
or
is
in
charge
of
uploading
something.
How
does
the
registry
know
that
this
developer
is
trusted
for
this
project?
E
C
Is
this
just
saying
that
you
know
we're
going
to
provide
a
pki
like
we're
going
to
provide
integrations
with
the
pki
and
how
you
manage
that
pki
is
entirely
up
to
you
versus?
Does
the
registry
actually
need
to
track
something
to
kind
of
enable
this
track?
This
delegation
of
access,
so
there's
a
difference
between
delegating
access
to
keys
versus
generating
keys,
that
kind
of
are
delegated
to
sort
of
like
a
route,
and
I
think
we
want
to
dive
into
that
a
little
bit
more
to
understand
the
trade-offs
between
those
two
approaches.
A
I'd
put
a
note
in
the
dock,
and
maybe
it's
just
me
because
I
don't
drill
into
the
details
of
key
management.
But
I
I
was
wondering
if
there's
something
written
up
because
there's
the
targets
and
delegations.
There
are
there's
general
terms
and
I'm
not
sure
if
those
apply
here
so
be
really
good.
Just
to
clarify.
If
you
have
some
docs
or
pointers
or
something.
D
Yeah,
it
marina
is
completely
right.
I
just
want
to
add
one
very
minor
additional
point,
which
is
that
it
also
makes
it
so
there's
really
never
ever
a
need
to
share
keys,
which
is
something
that
we
say.
We
see
people
operationally
do
a
fair
amount,
and
so
it
just
it
gets
rid
of
that
which
causes
you
to
have
just
so
much
better
operational
security.
A
So
the
idea
there
isn't
one
master
key
that
lots
of
people
having
like
the
build
system
have
multiple
build
servers.
Have
it
some
individuals
have
it
and
somebody's
laptop
gets
compromised?
Then
all
things
are
off.
You're
saying
that
we
would
be
able
to
know
that
that
laptop's
delegated
version
of
the
key
was
the
thing
that
was
compromised,
and
you
can
just
revoke
that.
One.
A
Sounds
great
yeah
if
we
can
have
some
kind
of
portrait
to
it
like
I
said,
maybe
it's
just
me,
but
I
think
there's
a
bunch
of
people
like
me
that
are
not
willing
to
say
anything
that
are
kind
of
wondering
what
exactly
means
by
all
this,
and
it
sounds
very
official
and
nobody
wants
to
ask
the
stupid
question.
But
so
I
will.
E
A
Yeah,
it's
there's
certainly
a
good
priority
to
folks.
Next,
I
think
some
questions
came
out
there,
because
there's
a
couple
of
people
also
piled
on
there,
the
on
the
scalability.
It's
not
one
of
the
things
that
I'm
also
I
keep
on
seeing
I'm
concerned
and
questioning
is
the
role-based
access
control
concerns
that
two
repos
don't
have
the
same
permission
sets
and
people
that
have
access
to
those
repos,
don't
so
having
a
single
metadata.
Repo
is
the
concern,
as
opposed
to
the
metadata
being
stored
with
the
artifact,
and
that.
A
D
A
A
A
We
assume
each
cloud
each
registry
cloud
being
part
of
them
have
its
own
permission,
security
model
that
they
put
in,
and
one
of
these
things
is
that
one
of
the
constraints
are
different.
Registries,
have
different
permission
models
and
even
within
a
registry
there's
different
permission
models.
I
think
acr
is
one
of
the
few
that
we're
kind
of
late
we've
assumed
each
registry
was
the
permission
boundary,
but
we're
now
adding
we've
already
added
we'll
be
adding
more
repo
bound
permissions.
A
And
I'm
happy
to
explain
it
now
or
we
can
just
write
it
up,
but
just
think
of
it
as
multiple
repos
or
actually
docker
hub
is
like
this
also
right.
It's
like
there's
justin
and
I
both
have
accounts
on
dockerhub.
I
obviously
don't
have
access
to
his
private
images.
He
doesn't
have
access
to
mine.
We
can
both
make
stuff
public,
but
those
are
public
is
not
actually
a
normal
scenario
in
private
registries,
in
fact
it's
the
anti-pattern
of
registry,
so
two
teams
that
have
a
collection
of
images.
D
A
A
So
did
you
want
to
go
through
the?
How
did
you
want
to
do
this?
Did
you
want
to
go
through
that
doc
that
you
guys
had?
Did
you
want
to
yeah?
We,
I
saw
it
late
last
night
and
didn't
get
a
chance
to
start
editing,
putting
comments
into
it.
Reading
it
putting
comments.
Until
this
morning
I
saw
a
bunch
of
other
people
did
as
well.
C
Can
we
actually
have
a
separate
discussion
to
go
through
the
scenario
section?
I
think,
as
I
was
commenting
on
the
doc
I
realized.
Some
of
my
questions
are
actually
for
the
original
scenarios
that
we
posted
up,
and
so
I
think,
going
through
the
whole
document.
With
the
changes
that
have
been
suggested
and
addressing
questions.
There
would
be.
E
D
F
A
F
F
A
A
good
idea-
I,
I
guess
I
wanted
to
ask
the
larger
group,
because
we
do
have
a
good
showing
today,
where
we
were
going
down
this
path
of
having
working
groups.
We
didn't
really
we
kind
of
paused
there's
lots
of
things
that
happened.
So
I
don't
care
about
the
details
of.
Why
do
we
want
to
get
back
to
doing
the
working
groups?
Because
I
think
it
was
yeah?
As
you
mentioned,
you
were
going
to
start
having
some
time
for
key
management
thoughts
and.
D
I
worry
a
bit
about
that
model
because
I
feel
like
I
feel
like
if
we
were
all
on
the
same
page
and
we
just
needed
to
like
break
up
into
groups
to
do
things
and
then
make
sure
the
pieces
fit.
I
think
that
would
would
be.
You
know
a
good
model,
but
I
worry
that
we're
not
like
doing
this
is
going
to
cause
us
to
go
off
and
do
very
different
things
and
get
more
entrenched
and
make
it
harder
for
us
to
come
together.
In
the
end.
C
Yeah
part
of
the
mechanism-
I
think
we
came
up
to
address
that
was
the
30-minute
agenda
meeting-
was
also
like
a
forum
to
kind
of
share
updates
from
the
different
working
groups.
So
we'd
have
a
weekly
checking
and
make
sure,
like
you
know,
we're
you're,
absolutely
right
like
we're
not
going
down
and
checking
and
and
going
down
paths
that
are
sort
of
bifurcating
right.
So
the
as
long
as
I
think
we
have
regular
updates
within
the
30-minute
agenda
meeting
from
the
different
working
groups.
I
think
that
should
address
the
concern
right.
A
That
was
the
model
yeah
and
there's
nothing.
Stopping
anybody
from
attending
the
breakout
groups
like
it
was
just
a
matter
of
yeah
I'll.
Just
pick
on.
You
like
he
was
more
interested
in
some
of
the
key
management
stuff
so
how
things
get
signed
and
the
in
that
part
of
it
he'd
probably
divert
to
some
others
and
then
he'd
be
focusing
on
the
key
management
with
some
other
folks,
and
then
we
are
kind
of
reporting
up
our
status,
but
the
assumption
is
there's
overlap
of
people
between
the
different
meetings.
C
I
at
least
for
key
management
I
can
speak
to
that
like
I
just
did
not
go
start
the
group
and
reach
out
and
kind
of
get
that
thing
started.
So
that's
something
that
I've
started
on
and
I'll
follow
up
on
slack
on
that,
I
think
that's
definitely
something
I
can
drive
and
see
if
we
can't
make
contributions
back
to
the
group
and
share
that
justin,
if
we
like
does
that,
does
that
make?
Does
that
work
for
you
like?
C
D
It
feels
like
we're
not
necessarily
going
to
benefit
that
much
from
the
breaking
up
into
groups,
but,
but
I
you
know,
I'm
very
often
like
this
is
an
organizational
thing
that
all
depends
on
how
we
as
people
make
it
happen,
and
so
you
know
it's
it's
really
impossible
to
predict
with
any
accuracy
how
this
will
go.
I'm
I'm
happy
to
try
whatever,
if
others
are
supportive.
C
Yeah,
I
think
this
addresses
a
much
larger
concern
for
us
than
it
does
for
for,
like
you
know,
tough,
for
example,
because
you're
right,
like
tough,
is
going
to
have
to
take
part
in
almost
all
the
different
working
groups,
but
from
an
organizational
perspective
for
us,
like
we
have
different
people
that
would
weigh
in
on
key
management
versus
different
people,
wayne
on
sort
of
like
the
registry
specifics
and
so
for
us.
It
just
makes
sure
that
we
can
get
the
right
people
for
the
right
working
groups
and
meetings.
A
How
about
why
don't
we
do
this,
make
a
suggestion.
It
sounds
like.
I
know
that,
there's
on
our
side
too
there's
some
people
focused
on
key
management
that
aren't
aren't
they're
they're
sensitive
to
their
time.
I
don't
say:
they're,
not
interested
they're,
definitely
interested,
but
to
respect
for
their
time
and
commitments
that
they
have.
A
They
would
like
to
focus
uniquely
on
the
key
management
aspects,
but
it
sounds
like
certainly
from
the
the
nyu,
tough
and
toto
notary,
I'm
not
sure
what
to
call
the
group
that
group's
perspective
you're
probably
involved
with
all
of
them.
So
what?
If
we
did
this?
What
if
you
set
up
some
of
your
the
key
management
working
group
off
to
the
side,
you
know
an
officer
side
meeting.
A
Whatever
time
frame
you
want
I'll
ask
amy
to
move
this
back
to
an
hour,
I'm
justin
cormac,
I'm
assuming
you
didn't
already
commit
your
first
half
an
hour,
trying
to
overlap
your
time
zones
and
then
we'll
leave
15
minutes
for
your
team
to
kind
of
give
an
update
either
at
the
beginning.
So
we
you
know
time
box.
It
will
just
make
sure
we
time
box
it
at
the
end
either
way.
D
A
My
understanding
is
the
key
management
has
a
bunch
of
complex
scenarios
that
we
hadn't
previously
thought
of,
where,
like
the
offline
keys,
was
the
example
and
having
aws
and
azure
and
others
are
invited
from
other
clouds
as
well.
But
those
are
pretty
good
representations
of
really
complex
problems,
so
just
having
those
folks
having
a
chance
to
break
out
on
that,
because
I
think
that
they
will
tie
up
an
hour
of
their
own
just
trying
to
figure
that
part
out.
D
D
Can
we
talk
about
this
from
a
standpoint
of
what
scenarios
you
have
from
a
key
management
standpoint
that
aren't
captured
and
what
situations
are
problematic,
because
if
we
kind
of
go
in
and
just
say
you
know,
okay,
we're
doing
a
v2
on
this
thing,
you
already
do
everybody
has
their
own
ideas
about,
like
it's
v1,
plus
these
eight
features
I
wanted,
and
these
three
things
removed.
I
didn't
want
and
then
we're
kind
of
battling
from
a
different
starting
point
and
trying
to
get
people
on
board
in
a
more
difficult
way.
F
Yeah
I
mean
that
that
they
were
it
didn't
inherently.
It
was
more
on
implementation
detail.
There
was
no,
I
mean,
I
think
that
I
mean
there
was
a
and
there's
are
some
pr's
to
make
some
changes
and
that's
the
thing
that
we've
kind
of
mainly
deferred
to
v2.
But
but
you
know
there
wasn't
anything
inherently
problematic.
It
was
purely
the
registry
implements
practical.
F
A
A
All
right,
why
don't
we
try
that?
Because
I
don't
hear
anybody
say
no
either
so,
since
the
voting
didn't
seem
to
work
very
well
all
right,
we're
at
time,
okay,
so
moving
it
to
an
hour
going
forward
yeah
as
we'll
try
to
get
something
scheduled
over
the
next
week
and
a
15-minute
recap
in
that
meeting,
and
there
we
go.
I
I
was
trying.
I
think
I've
been
busy,
like
I'm
sure,
everybody's
been
busy
with
their
various
planning
and
so
forth,
or
whatever
people
do
for
their
day
jobs.