►
From YouTube: CNCF Notary Meeting 2020-08-10
Description
CNCF Notary Meeting 2020-08-10
A
A
A
A
A
A
A
A
A
A
A
Start
said
yes,
thumbs
up
all
right
cool
all
right,
so
the
first
one
is
really
just
some
cleanup.
Well,
it's
two
things.
Obviously
it's
a
cleanup
moving
things
to
the
root
readme,
because
the
more
people
that
were
trying
to
get
up
to
speed
on
what
we're
doing
with
notre
dame
tracking
what
we're
doing
with
notary
v2.
I
realized
we
started
slipping
into
the
tribal
knowledge
thing
of
a
bunch
of
stuff,
that's
assumed,
but
not
actually
clearly
documented
outside
of
our
notes.
A
A
C
A
So
I
tried
a
more
bulleted
approach
so
and
the
reason
I
kind
of
pushed
on
this
one
is
you'll
see
in
the
other
pr,
when
I
was
trying
to
talk
about
the
various
options
for
distribution
apis,
I'm
trying
to
refer
to
requirements
as
to
why
we
took
a
certain
approach,
and
I
realized
we
just
didn't-
have
these
written
down
in
a
way
that
really
made
sense
and
ralph
also
committed
before
he
left
on
vacation
for
most
of
the
month,
which
is
great.
He
should
do
that.
A
A
A
A
D
A
A
All
we're
saying
is
we
want
to
integrate
with
whatever
the
key
management's,
the
actual
key
part
management
solution,
the
discovery
and
how
those
keys
are
fetched
and
retrieved
is
something
that
I'm
again
deferring
to
the
key
management
group.
All
I'm
saying
here
is
and
and
maybe
cormac
if
you
could
help
me
here,
because
I'm
trying
to
relate
to
what
we
talked
about
in
the
weight,
docker
distribution
or
docker
notary
v1
was
done.
E
I
think
there's
two
requirements
being
joined
into
one
here.
One
is
the
support
for
the
vendor
cloud.
Key
management
solutions,
which
is
the
second
sentence
here,
which
says
notary
v2,
must
provide
extensibility
enabling
key
management
by
any
one
of
many
solutions,
and
then
the
second
requirement
is
that
registries
should
not
be
required
to
play
a
role
in
signature,
verification
or
any
any
any
part
in
that
process,
which
is
what
allows
us
to
move
containers
across
multiple
registries
right.
A
Yeah,
it's
fair.
I
was
struggling
with
a
couple
of
things
that
I
felt
were
core
requirements
that
the
scenarios
support
and
again.
This
is
why
it's
a
pr
for
discussion,
but
I
really
until
I
did
this
it
was.
We
didn't
actually
have
these
things
specifically
called
out
anywhere.
Immutable
tags
does
reflect
in
the
scenarios,
but
we
want,
but
I
was
trying
to
call
it
a
more
deliberate
thing,
including
the
key
management
solution.
So
is
the
scenarios
support
the
requirements
and
the
requirements
support
the
scenarios?
A
B
B
B
A
C
A
So
when
I,
when
we
write
other
design,
approaches
like,
for
instance,
when
we
get
to
the
distribution
apis,
I
was
trying
to
refer
to
something
that
was
not
necessarily
just
a
scenario
but
kind
of
some
core
requirements.
That
we've
said
was
difference
between
v1
and
v2.
So
I
can
certainly
merge
this
into
the
scenarios.
Doc
and
just
say
you
know,
in
support
of
scenario
1.2
or
whatever
we
you
know
call
it.
I
guess
I
was
trying.
A
D
No
because
I
think
the
way
you
want
like
you,
want
a
security
outcome
for
these,
and
you
want
actions
that
people
can
take
and
so
on.
I
think
some
of
this
is
covered,
and
some
of
this
isn't-
and
some
of
it
isn't
really
clear
some
of
it
you're
describing
like
a
feature
rather
than
sort
of
like
a
way
in
which
somebody
uses
something
like
a
like
a
workflow
scenario,
justification-
and
I
think
that's
that's
also
part
of
what
I'm
trying
to
push
back
on
here.
D
D
So
you
have
a
party
that
has
no
state
or
very
old
stale
state
and
has
to
be
able
to
pull
things
images
through
a
repository
that
may
have
been
compromised,
and
so
that's
sort
of
a
scenario
like
basically
enable
you
know
describing
an
outcome
you
want
to
have,
and
then
you
know,
but
if
you
look
in
three,
for
instance,
the
second
sentence
on
the
initial
poll
when
the
client
is
discovered
to
need
initialization
a
secured
process
is
initiated
like
I
don't.
I
don't
really
know
what
that
means.
D
At
the
time
of
the
you
know
on
the
initial
pull,
it
isn't
necessarily
that
that
solution
is
wrong
or
doesn't
work
doesn't
meet
the
actual
need
of
the
system,
but
the
goal
is,
is
to
have
that
transmission
and
have
things
happen
securely,
despite
a
potentially
hacked
registry,
and
whether
this
happened
on
the
initial
poll
or
whether
some
other
way
of
this
happening
happened.
You
know
like
something
else
occurred
to
make.
That
feasible
is,
I
think,
irrelevant
to
what
your,
what
your
like,
the
way
in
which
you
would
judge
as
a
security
solution.
A
I
mean
part
of
it
is
they
are
intentionally
vague
in
some
ways,
because
I
wanted
to
stir
the
conversation,
get
the
experts
in
the
areas
to
come
up
with.
You
know
what
should
the
specs
say
so
to
speak,
like,
for
instance,
the
thermal
clients
came
out
of
this
conversation
around
the
verification
concepts
of
the
update
semantics
we've
been
talking
about
because
we're
saying
that
these
clients
are
ephemeral.
So
how
do
we
support
that?
It's
not
implying
that.
A
F
D
A
D
D
It's
not
expected
to
have
information,
that's
let's
say
less
than
something
like
a
month
or
a
year
old
or
something
somewhere
in
that
range,
something
that
that
is
that
totally
makes
sense,
but
but
then,
like
part
of
the
yeah.
But
what
I'm
pushing
back
is.
Is
that
you
don't
you
want
to
be
careful
not
to
add
design
in
to
requirements
or
to
scenarios.
A
A
E
I
think
I'd
agree
that
this
is
probably
by
saying
must
provide
extensibility.
I
think
we
may
be
going
a
little
too
strong
on
the
language
here,
but
at
least
the
goals
and
objectives
that
we
addressed.
I
think
documenting
them.
Whenever
I've
been
working
through
some
of
the
scenarios
and
use
cases
for
key
management,
we
have
had
to
come
back
and
say
these
are
the
things
that
we
want
to
address
right,
and
so
I
don't
think
like
I
don't
think,
there's
harm
in
covering
them
as
a
goal.
A
E
I
think
that's
a
question
for
organizations
like
if
we
want
to
eventually
merge
them
in.
I
think
it
makes
sense
right
now.
I
think
keeping
the
docs
separate
makes
it
easy
to
iterate
on
those
and
cleaner
pull
requests,
and
I
can't
also
see
why
we
can't
link
one
to
the
other
as
well
right
if
we
just
kind
of
call
out
in
this
overall
sizing
scenario,
where
sort
of
like
the
key
management
scenarios
or
documents
at
least
we're
not
losing
track,
and
the
new
reader
at
least
knows
to
go.
B
E
A
Okay,
so
I
didn't
really
hear
that
these
that
we're
not
we
don't
want
these,
it's
just
a
and
it
was
intentional
to
should
we
put
some
requirements,
but
let's
make
sure
we
get
these
put
in
the
right
place
because
they
were
not
some
of
them
weren't
captured
in
in
its
detail,
and
I
wanted
to
make
sure
we
brought
those
in
the
next.
What
was
this?
Oh,
this
was
the.
A
This
is
the
thing
I
just
popped.
Oh
no,
this
is
the
distribution
thing.
Was
that
the
next
one?
Actually,
let
me
do
this
jwt
one.
No,
I'm
gonna!
Do
it
the
way
I
put
it
in
the
list?
Actually,
okay,
so
the
next
one
on
the
list,
as
we
talked
about
a
couple
weeks
ago,
is
now
that
we're
getting
some
structure
around
what
a
signature
object
could
look
like
and
we're
iterating,
including
the
gwt
format,
as
opposed
to
a
json
formatting
which
we'll
come
to
in
a
moment.
A
A
So,
as
you
see,
what
I
was
trying
to
do
was
here
was
highlight
some
of
the
requirements
in
in
here,
and
I
pulled
them
out
and
I'll.
You
know
we'll
fix
this,
to
be
able
to
link
them
back
to
a
specific
scenario
and
so
forth,
but
basically
the
original
digest
and
the
collection
of
associated
tags
shouldn't
change.
A
This
way,
a
cust,
a
user
that
has
deployed
something
or
is
referencing
something
as
part
of
their
deployment
scripts
that
doesn't
have
to
change
just
to
be
able
to
get
a
signature
verification
we
want
to
say
the
signature.
Verification
verifies
the
thing
that
I'm
referencing
multiple
signatures
per
artifact.
We
did
push
a
better
picture
of
this.
A
Where
did
I
push
that
hold
on
and
get
a
distribution?
No,
not
distribution,
second
might
have
been
the
right
one
requirements.
So
in
the
scenarios
this
now
has
the
updated
picture
that
talks
about
this
walkthrough.
I
updated.
The
text
also
refer
to
this,
so
the
the
wabit
networks
builds.
This
network
monitor
image
and
their
registry
doesn't
matter
where
they
have
them.
They've
got
a
registry
whether
it's
public
or
not,
is
irrelevant.
A
They
push
it
to
something
like
docker,
hub
or
docker
up
where
the
wabit
network
signature
is
available
there.
Somebody
may
or
may
not
trust
it
yet,
but
docker
can
say
this
is
certified
content
and
they
trust
docker.
So
now,
there's
a
second
key
on
it.
This
reload
right
here
says
the
distrib,
the
and
digest
can't
change,
because
we're
just
adding
another
signature
as
it
gets
pulled
into
the
acme
rockets
environment,
they
can
put
their
own
signature
as
they
verify.
This
content
works
for
their
environment
and
then
their
policy
management
says.
A
I
only
trust
things
that
the
acme
rocket
team
has
certified
and
it's
often
deployed
in
life
is
good.
So,
and
this
has
been,
you
know,
updated
with
the
text
to
refer
to
that.
We've
been
talking
about
this
for
a
while.
I
just
I
hadn't
gone
back
and
updated
the
picture
in
the
text
to
reflect
the
the
feedback
that
we
had
previously.
A
So
where
was
I
sorry?
So
that's
the
multiple
signatures
that
we've
been
talking
about
native
persistence.
This
is
the
I
don't
know
what
the
star
is
doing
there
we'll
fix
that
that
we
don't
want
to
have
a
side
car
another
service
sitting
alongside
the
registry,
because
things
get
out
of
sync
very
quickly,
depending
on
where
you
pull
the
tag
from.
We
want
to
make
sure
that
we've
got
that
included.
Let
me
just
pop
this
out.
A
Oh
okay,
great
these
are
recorded,
so
that's
helping
with
people
in
different
time
zones
and
different
schedules.
So
that's
the
native
distribution
native
persistence.
We
wanted
to
support
moving
right.
We
talked
about
and
multi-tenant
registries
making
sure
that
sites
like
docker
hub,
that
has
multiple
organizations
or
the
github
and
google
model
where
it's
a
single
domain,
but
they
have
multiple
customers
in
that
same
domain
or
the
aws
and
azure
version
where
it's
different
domain
for
each
cut
each
registry.
A
But
within
that
we
have
different
groups
that
need
to
be
able
to
support.
There's
lots
of
ways
people
hash
out
how
they
do
multi-tenancy.
We
want
to
make
sure
that
we
can
support
the
aggregation
of
that
content
private
registries,
so
they
move
from
public
to
private
as
the
picture
showed
and
then,
of
course,
within
those
private
registries,
new
content
is
created
and,
of
course,
the
air
gap
environments.
A
So
to
support
this
we've
been
discussing,
and
we
haven't
really
had
a
chance
to
review
it
in
detail
that
we
want
to
use
the
oci
artifacts
approach,
because
it
allows
us
to
leverage
all
of
the
infrastructure
that
a
registry
already
supports
everything
from
garbage
collection
to
object,
listing
tag,
repo
delete
management
and
so
forth.
So
we're
trying
to
not
have
yet
another
end-to-end
model
for
dealing
with
something
it's.
It
is
a
special
type
of
object,
artifact,
but
we're
hoping
we
can
make
it
just
one
of
those.
A
A
All
right,
not
not
in
this
one
but
basically
use
the
artifact.
Oh
here
we
go
notary,
v2,
config
and
we'll
see
how
this
will
switch
over
to
a
jwt
and
the
other
pr
and
then
inside
of
it
it
references
the
digest,
but
this
is
in
the
config
object.
The
question
is:
should
we
be
parsing?
Well
sorry,
this
is
what
would
work
today,
because
we
can
stick
the
signature
in
the
config
object
and
the
config
and
the
artifact
itself
can
be
defined
as
a
signature.
A
A
So
we
can
and
we
can
use
the
rs
client,
whether
it's
a
library
or
not.
The
problem
is
that
you
would
need
to
actually
add
a
new.
I'm
sorry,
I'm
trying
to
read
my
own
notes.
I
guess
I
I
finished
this
friday
night
and
I
was
debating
and
presenting
this,
and
I
realized-
I
don't
have
it
all
done
here.
So
the
problem
with
this
approach
is
you
actually
have
to
parse
the
config
to
figure
out
the
linkage?
Oh,
I
know
why
there's
a
separate
conversation
of
how
we
do
linkage.
A
That's
why
I
left
that
out.
So
the
at
this
point
there's
a
reference.
The
other
approaches
in
an
index
an
index
already
has
the
ability
to
reference
other
manifest,
including
manifest
lists,
and
that's
what
registries
are
the
ones
that
are
actively
adding
this.
In
fact,
we'll
have
a
conversation
on
wednesday
around
the
use
of
index,
but
the
design
is
there
that
it
index
already
knows
how
to
reference
other
manifests,
and
that
was
the
original
proposal
that
I
had.
A
The
problem
is
that
it
also
requires
the
index
to
support
a
config
object,
which
we
said
we
wanted
to
do
as
part
of
the
artifacts
conversation,
but
we
haven't
actually
gotten
to
it
yet
so
this
and
cnab-
and
I
think,
there's
one
other-
might
be
the
impetus
to
you
know
kind
of
say:
maybe
it's
time
to
go,
do
that,
but
that
would
actually
be
yet
another
change.
We'd
have
to
do
the
so
then
we
get
into
how
to
link
them.
This
is
where
I
separated
out
so
in
the
current
current.
A
Whatever
current
means
in
the
json
version
of
the
signature
object,
there's
a
digest.
That's
already
in
here.
In
fact,
we've
made
this
a
full
descriptor
by
putting
the
media
type
in
here
as
well
of
what
it
is
that
you're
signing
the
digest
of
this
is
separate
information
for
verification,
but
this
digest
right
here
for
that
same
repo,
says
hey.
I
can
link
this
but
again.
You'd
have
to
parse
the
config
object
to
pull
this
out.
Is
that
the
right
approach?
A
So
the
idea
is
where
am
I
with
this?
Oh,
so
then
what
we're
trying
to
figure
out
is:
how
should
we
do
this?
Should
we
be
parsing,
the
json
object.
Sorry,
the
sig.
The
config
object
to
do
that,
and
or
is
there
a
separate
api
that
we
use
for
linking,
so
you
would
still
upload
it
using
the
standard
apis
for
uploading
to
a
distribution
right
to
a
registry
and
then
there's
a
separate
api
for
signature.
A
A
Sorry,
if
we
do
it
as
part
of
the
upload
and
parsing
the
config
object,
then
you're
saying
hey,
somebody
might
have
push
rights
to
the
registry,
but
because
they're
pushing
a
signature,
they
also
need
signer
rights
and
that
felt
a
little
weird
to
be
sticking
it
into
that
api
in
the
middle
of
that
as
all
of
a
sudden,
the
push
is
successful,
but
it
fails
because
the
type
of
object
you're
pushing
with
this
approach
on
the
upload.
Sorry
as
a
linkage,
you
can
actually
put
the
rights
check
the
roll
check
on
the
api.
A
A
The
other
is
there's
a
unique
signature.
Upload
api.
Since
the
signatures
have
no
layers
at
this
point,
they
are
literally
just
amount
of
a
layerless
layerless,
manifest
or
zero
layer
manifest
with
a
config
object.
Then
you
know.
Maybe
this
is
another
approach,
because
here
what
we
can
do
is
we
can
do
the
roll
check
on
the
upload
and
it's
a
little
more
cleaner.
The
the
downside
is,
we
are
treating
it
on
the
front
end
a
little
different
than
other
objects
that
get
uploaded.
A
You
could
argue
it's
a
special
artifact,
it's
still
better
than
having
a
separate
notary
server.
That's
part
of
the
conversation
we
get
into
signature
discovery
and
we
go
into
another
set
of
conversations.
So
I'm
going
to
pause
there
and
and
kind
of
ask
for
feedback,
and
I
again
I
apologize.
I
meant
to
get
this
done
last
wednesday,
so
there's
feedback
on
the
to
read
it
first.
So
I
I
don't
expect
all
feedback
here.
I
just
will
start
the
conversation.
C
I
don't
see
any
benefits
to
to
using
oci
artifacts
in
here.
All
we
really
want
is
a
mime
type
and
a
blob
either
way.
The
registry
must
have
a
special
support
for
creating
links
and
listing
links
either
way.
Every
client
must
have
a
special
support
for
downloading
or
uploading
signatures
together
with
the
image.
C
C
A
Yeah,
it's
interesting.
The
distribution
spec
doesn't
completely
drill
into
the
details
over
how
we
all
store
these
things
as
blobs
and
so
forth.
There
is
some
discovery,
not
just
whether
it's
discovery
there
is
pull
apis
that
we're
also
trying
to
be
consistent
with
so
once
you
have
a
manifest
of
a
signature
or
standard
artifact
poll
would
just
work,
but
we
we
have
been
debating
the
upload
one
and
we're
also
trying
to
make
sure.
A
Well,
while
each
registry
has
slightly
differences
in
how
we
persist
the
objects,
there
is
a
mechanism
there
and
we're
trying
to
make
sure
that
we
don't
make
major
changes
to
how
an
operator
could
would
have
to
store
them.
But
to
your
point,
if
somebody
wants
to
go
off
and
store
them
in
a
different
way,
because
they
can
retrieve
them
differently,
there's
nothing
that
stops
that.
C
A
C
C
C
A
No,
no,
it's
the
index
part
that
you're
referring,
and
I
think
that's,
maybe
where
I
wasn't
clear
when
you
push
a
signature,
the
idea
is
that,
instead
of
using
manifest-
which
you
would
have
this
new
thing
in
the
config
object
to
have
to
know
the
linkage
or
the
separate
api
to
do
the
language
so
to
your
points
to
the
idea
is:
do
we
use
index
which
already
has
a
means
for
tracking
linkage
between
a
list
and
other
manifests
and
a
list?
A
list
can
technically
port
to
another
list
which
is
totally
valid.
A
So
the
registries
are
already
rephrase
that
registries
that
support
index,
which
is
growing
that
not
all
registries
did.
I
was
surprised
actually
so
we've
been
starting
to
see
more
and
more
registries
support
index
now
and
the
idea
is
that
we're
trying
not
to
introduce
yet
another
way
to
do
tracking.
So,
if
you
would
support
index,
you
already
have
to
support
the
idea
that
an
index
references
other
manifests
the
manifest
have
to
get
uploaded
first
and
then
an
index
gets
uploaded.
A
If
you
delete
an
index
that
doesn't
necessarily
have
to
delete
the
manifest
right,
there's
a
a
rough
check,
ref,
counting
system,
trying
to
say
the
word
game,
because
it's
some
it's
it's
kind
of
like
this
guacamole
game
anyway,
there's
a
rough
checking,
ref,
counting
implementation
that
should
already
be
put
in
place.
I'm
trying
to
leverage
not
not
create
another
one,
but
there
is
no
single
index
that
has
all
of
the
signatures,
because
that
would
make
them.
You
know
that
would
make
it
updated
and
we're
trying
to
your
original
point,
content,
addressable
and
immutable.
A
Every
signature
is
a
new
object.
It's
uploaded.
We
don't
expect
to
have
hundreds
of
signatures
per
specific
digest.
Even
you
know
the
one
or
two
that
we
talked
about,
but
the
idea
is
that
I
keep
on
adding
more
signatures
and
nothing
else
has
to
change.
So
I
don't
have
to
worry
about
updating
any
semantics
in
place.
A
A
One
was
signed
by
the
wabbit
networks
and
one
was
signed
by
acme
rockets,
so
the
original
signature
for
the
net
monitor
image
came
from
wabit
networks
and
then,
when
it
got
moved,
I
didn't
show
the
third
for
docker
registry
just
because
it
was
getting
to
be
too
much.
I
was
trying
to
show
the
beginning
and
end,
but
here
acting
rockets
said
hey.
I
also
attest
to
this
contents
for
my
environment,
but
they're
separate
completely
separate
object,
because
this
one
got
copied
in
from
the
original
registry
through
docker
hub
to
the
wabit
networks
registry.
A
A
B
A
A
A
We
stick
the
config,
the
signature
in
a
config
object,
but
there's
no
way
to
reference
another
manifest
an
index
has
a
way
to
reference
another
manifest,
but
it
doesn't
have
the
index
yet.
Oh
sorry,
it
doesn't
have
the
config
object
yet
and
that's
a
problem
for
two
reasons.
It's
a
problem
here
for
a
notary
because
we
want
to
be
able
to
store
the
signature
in
a
config
object
and
it's
an
also
a
problem
is
that
an
index
doesn't
know
how
to
say
it
is
something
other
than
a
collection
of
arbitrary,
manifest.
A
There's,
no
way
to
say
that
this
signature,
sorry
this
index
is
a
cnab.
This
index
is
a
signature
object,
so
if
we
can
add
config
to
the
index
format,
which
we
said
we
wanted
to
do
for
a
while,
then
we
unlock
the
ability
to
get
both
persistence
and
linkage
through
standard
mechanisms.
That
registry
should
be
supporting
today.
Well
as
they
support
index,
they
would
support
today.
B
B
A
So
it's
just
a
matter
of
us.
Look
we're
adding
in
we're
going
to
have
to
add
something
like
no
we're
not
going
to
get
notary
v2
for
free,
like
we
know,
we
don't
want
it
to
be
as
big
as
a
notary
server,
but
we
recognize
there'll
be
some
apis
that
have
to
change
we're,
trying
being
a
registry
operator
we're
trying
to
make
sure
that
we
don't
have
to
redo
our
whole
storage
and
and
all
the
infrastructure
there,
and
we
feel
the
same
pain
for
other
registrars,
especially
because
we've
all
done
optimizations
around
our
own
clouds.
A
So
the
theory,
if
you
remember
back
originally,
we
said,
look
adding
another
api,
isn't
the
end
of
the
world
because
look
we're
coders.
We
write
apis
all
the
time,
but
persistence
is
like
a
major
change,
so
the
thought
process
is
rev
the
index
because
we
have
multiple
reasons
to
do
it
and
all
the
rest
of
the
infrastructure
comes
in
place.
A
So
I'll
leave
that
for
some
digestion,
obviously
reading
staring
giving
feedback
is
the
conversation
we
want
to
have,
but
there's
a
lot
of
a
lot
to
digest
here.
Let
me
go
on
to
the
discovery
apis,
because
this
one
also
had
some
interesting
conversations
that
came
out.
I
don't
think
I've
done
a
really
good
job.
A
A
So
we
said
for
the
discovery:
api
notice,
I'm
skipping
the
poll
api.
For
now
the
pull
api
is
assumed
to
just
be
another
artifact,
but
we'll
come
back
to
that.
The
discovery.
One
is
the
interesting
one,
because
we
want
to
be
able
to
say
that
I
want
a
list
of
signatures.
I
want
a
specific
artifact
type.
I
want
a
list
of
signatures
for
a
given
digest,
so
it
doesn't
matter
whether
it's
an
oci
image,
whether
it's
an
oci
image
index,
an
s-bom,
a
helm,
chart
a
marky
mark
document.
It
doesn't
matter
right.
A
Anything
in
a
registry
should
be
able
to
be
signed
and
for
artifacts
that
don't
have
a
signature
model,
they
can
adopt
this
and
it
will
just
work
for
them
and
for
ones
that
have
special
ones.
Then
that's
great.
They
can
persist
those
as
well
the
so
you
regard
this
to
almost
realize.
First
question
originally
was
a
registry.
Is
this
thing
that
you
can
use
a
tag
to
get
a
digest,
but
once
you
have
a
digest,
it's
a
content,
addressable
storage.
Using
that
digest.
I
want
a
list
of
keys.
A
The
list
of
keys
could
is
a
collection.
We
don't
expect
it
to
be
thousands.
But
of
course
we
don't
know-
and
I
don't
know
if
I
want
to
say
the
list
should
never
be
more
than
5
or
124
or
128,
or
something
right,
some
arbitrary
thing.
So
what
we're
saying
is
we
want
to
do
a
paged
api
as
all
rest
list?
Api
should
be
the
interesting
problem
or
question
that
we
have
is.
There
is
a
I
don't
know
how
to
title.
Let
me
put
it
this
way
start
with
this
way
in
the
distribution.
A
A
So
my
question
is:
I
don't
want
to
reference
just
google
docs
of
google
apis,
because
google
didn't
invent
the
way
to
do
rest
apis.
They
just
have
a
good
doc
to
reference.
It
there's
other
ways
of
do.
You
know
that
also
talks
to
I
don't
know
how
to
refer
to
the
non-distribution
spec
way
of
getting
standard
paging
through
a
rest
api,
so
I
need
some
help
there,
but,
more
importantly,
we
need
to
make
a
decision.
A
A
A
I
don't
know
how
to
describe
it,
so,
in
fact
this
is
where
it
got
to
be
dinner
time
on
friday,
and
apparently
this
is
where
I
left
off.
I
look.
I
haven't
written
these
in
a
while.
It's
been
a
couple
years
since
I've
written
production
rest
apis,
so
there's
apparently
a
different
way
of
doing
it,
and
I
need
to
find
the
doc
that
referred
to
it.
It
was
actually
in
the
pr
feedback.
I
think
it
was
sam,
provided
the
pr
feedback
to
what
was
originally
the
signature.
A
A
A
A
A
We
agree
that
the
signature
request,
the
signature
collection
api
also
needs
to
say.
I
only
want
the
signatures
of
rabbit
networks.
I
only
want
the
signatures
from
docker
hub.
I
only
want
the
acme
rocket
rocket
signatures
and
I
want
to
filter
the
rest,
so
there's
there's
that
part
of
it,
but
regardless
of
what
parametering
parameterizing
we
put
on
it,
what
should
the
standard
paging
apis
be?
Is
the
question.
A
So
that's
the
place
of
looking
for
some
feedback
and
then
the
the
last
one
and
again
this
is
where
I
was
editing
some
stuff
so
overall
gave
some
great
details
here,
which
obviously
I'm
still
digesting,
because
this
is
where
it
goes
into
the
sausage
factory.
But
the
signature
pull
should
just
basically
be
any
other
artifact.
You
just
pull
once
you
know
through
the
requesting
the
the
signatures
api.
A
Just
like
you
do
for
any
other
artifact
right,
you
get
a
manifest,
you
say
hey,
I
know
what
I
want
now
now
I'm
going
to
go
request
it.
The
idea
here
is
hey.
I
would
get
to
figure
out
what
the
digest
is
of
the
signature
object
and
then
just
going
to
do
a
standard
signature
pull
because
we
don't.
We
don't
think
that
pulling
a
signature,
a
verification
object
of
an
artifact
should
be
any.
A
I
can't
imagine
registries
would
want
to
put
any
more
rights
on
a
pull
of
a
verification
object
than
they
do
for
the
artifact
itself.
In
fact,
I
could
see
lots
of
holes
where
hey,
I
can
pull
the
artifact,
but
I
can't
pull
the
signature
to
verify.
That's
the
right!
Artifact,
so
that
feels
wrong,
so
we're
trying
to
say-
and
I
obviously
don't
remember
what
I
wrote
here-
but
this
should
align
with
any
other
artifact
pope.
A
So
that
tees
up
the
content
that
I
had
in
the
conversation
today,
the
only
other
one
that
I
just
got
this
morning
and
I'm
just
going
to
queue
this
up.
Also,
when
I
put
it
in
the
slack
conversation
is
we
took
the
feedback
on
doing
a
jwt
format
for
the
signature
that
she
was.
He
actually
didn't
make
the
pr
all
the
way
up.
Yet
it's
on
his
registry
so
or
his
git
repo
will
push
this
up
as
well
to
the
notary
v2
project.
A
But
the
idea
here
is
this-
and
I
was
scanning
this
myself
this
morning,
but
basically
the
signature
is
no
longer
a
json
object
that
we
have
to
have
all
these
conversations
around.
How
do
you
encode
it
in
white
space
and
not
and
so
forth?
The
interesting
challenge,
though,
is
once
it
becomes
this
encoded
string
to
the
conversation
justin
and
I
were
just
having-
is
we
don't
want
to
have
to
parse
the
config
object,
to
figure
out
the
linkage
and
then
to
milo's
leosov's
question?
We
don't
want
to
have
to
have
two
separate
apis.
A
A
So
this
way
we
can
put
role
management
on
it,
but
the
parsing
of
that
would
be
a
standard
index
object,
and
then
we
don't
have
to
read
into
the
signature
itself
to
understand
which
digest,
because
you
don't
want
to
have
to
parse
this
encoded
object,
which
is
a
performance
hit,
that
we
want
that.
We
don't
want
to
take
on
every
upload.
B
B
Api,
because
you
want
separate
role,
management
is
not
in
the
end
of
design
that
scales
for
any
kind
of
object
you
want
in
ici.
So
I
think
it's
a
more
it's
a
more
general
question.
That's
worth
asking
of
oci
as
to
how
you
would
do
role
management
for
different
types
of
things.
I
mean
you
could
imagine
a
registry
in
which
you
want
to
give
people
different
roles
to
be
able
to
upload
under
helm,
charts
and
container
images,
but
doing
that
by
having
a
separate
api
doesn't
scale.
A
A
So
what
I
think,
what
I'm
hearing
you
say
is
just
building
on
the
conversation
we
just
had
is
index
is
good,
but
do
we
need
a
separate
upload
for
signature
indexes
as
opposed
to
no
just
use
the
index
the
upload?
It
happens
to
be
an
index
and
there's
a
roll
check
that
is
implied
based
on
the
artifact
type
and
that
yeah
those
customers.
B
B
A
A
I
have
to
jump
out
of
the
call,
so
I
think
we
got
the
right
conversations
teased
up
by
all
means.
Slack
and
pr
feedback
is
our
friend.
It
gives
everybody
a
chance
wednesday.
We
have
a
conversation
on
index
specifically
darren.
I
got
shafer
stuck
in
my
head.
That's
not
his
last
name
darren's
going
to
talk
about
his
experience
with
index
and
we'll
do
that
on
the
oci
weekly
call.
So
with
that
I'll
see
folks
on
slack
and
thank
you
very
much.