►
From YouTube: Digital Identity Attestation (April 14, 2021)
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
Cool,
okay
and
now
we're
recording
so
welcome
everyone
to
the
digital
identity,
attestation
working
group
meeting.
We
have
just
two
items
on
the
agenda
today.
The
link
to
the
meeting
notes
is
in
the
chat
right
now
I
thought
maybe
we
could
do
the
the
survey.
One
quick.
We
have
someone
from
tide
lift
here,
even
though
they
didn't
add
it
to
the
agenda.
They
could
probably
speak
to
it
and
then
gavin's
gonna
lead
us
to
somewhat
of
a
working
group
goals
and
open
discussion.
A
We
can
talk
about
things
that
we
want
to
do
during
this
working
group
that
sound
good
any
any
other
items.
People
want
to
add.
A
B
Yeah
sure,
well
just
a
quick
little
bit
about
what
tidelift
does
first,
because
that'll
help
provide
a
little
bit
of
contact,
so
we
work
with
maintainers
to
improve
various
qualities
of
their
packages
and
provide
that
metadata
about
that
quality,
assurances,
indemnities,
etc
to
our
enterprise,
customers
and
part
of
how
we
do
that
is
by
having
a
pretty
deep
knowledge
across
technically.
We
cover
something
like
40
package
managers,
including
things
like
the
emacs
package
manager
as
a
practical
matter.
Our
customers
do
not
care
about
the
emacs
package
manager,
but
nevertheless,
there's
code.
B
This
particular
survey
was
something
one
of
our
engineers
put
together
just
to
sort
of
survey
the
state
of
play
in
terms
of
what
various
package
managers
do
and
don't
do
about
signing
packages.
So
I
won't
bore
you
by
repeating
all
of
the
data
in
there,
but
suffice
to
say
the
major
package
managers.
B
Has
slightly
different
ways
of
looking
at
the
problem,
slightly
different
feature
sets
that
are
supported
and
so
yeah,
and
so
this,
this
blog
post
was
an
attempt
to
put
together.
You
know
what
we
know
based
on
our
work,
which
is
in
part
around
figuring
out
things
like.
How
can
we
you
know?
D
B
The
kind
of
structure
that
we're
looking
to
build
out
and
again
purely
coincidentally,
that's
why
I'm
me
or
somebody
from
the
team
we
haven't
really
fully
decided
yet
we'll
be
joining
the
identity,
working
group
and
we
just
joined
ossf
formally
a
week
or
two
ago.
So
any
questions
about
it.
I'm
happy,
I
didn't
put
the
survey
together,
but
I'm
happy.
E
E
I
work
for
greatness
hi.
My
name
is
jonathan
lightshow.
I
work
for
gradle,
it's
it's
funny,
so
I
look
at
maven
grade
all
packages.
Uploaded
maintenance
are
required
to
be
pgp
signed
and
all
three
package
managers
have
tooling
to
sign
and
verify.
It
is
true
that
we
support
publishing
and
uploading
signatures,
the
ecosystem
and
the
amount
of
usage
of
actually
verifying
those
certificates
is
very
like
the
adoption
of
of
checking
those
signatures
is
very
limited.
E
I
think
that,
like
great
breedl
is
one
of
the
few
repositories
that
actually
checks
itself
and
checks
its
dependencies,
but
there's
currently
the
state
of
the
ecosystem,
at
least
in
the
maven
and
java
equals
them,
is
that
it's
really
hard
to
do
the
verification
on
the
user
side.
So
most
of
the
time
it
doesn't
happen.
B
Right
well
so
one
of
the
things
that
we're
looking
at
is
how
we
can
help
our
customers
do
that
validation.
So
but
yeah
I
mean
the
state
of
validation
is
poor
everywhere.
B
As
I
understand
it,
and
I
could
talk
to
the
engineer
involved,
you
know
part
of
what
we're
doing
here
was
surveying,
even
just
whether
or
not
it
was
possible
definitely
agreed.
Your
gradle
is
certainly
not
alone.
C
B
The
gap
between
what's
possible
and
what
actually
being
done
is
very
large
so
but
yeah
I'll
pass
that
feedback
on.
Let's
see,
if
there's
anything
else,
we
can
do
around
servicing
that
kind
of
data
or
surveying
all
of
you
all
for
for
data.
E
Yeah,
I
think
it.
I
think
it
break
the
way
that
it's
written
crafts,
a
disingenuous
reality
where,
like
oh
yeah,
these
support
signing,
but
actually
the
reality
is
it
supports
signing,
which
means
the
authors
can
sign
them
it
just.
It
means
that
this,
the
ver
on
the
verification
side,
that
the
amount
of
adoption
there
is
very
limited.
So
I
I
you
know
it.
I
it's
cool
to
see
that
they'll
have
you
know
one
side,
but
I
think
that
representing
both
sides
is,
is
valuable
here.
B
Sure
yeah
well,
I
can
definitely
say
that
that
was
not
our
intent.
You
know
the
more
the
more
uncertainty
there
is
as
a
general
matter.
You
know
the
more
people
come
to
us,
so
we
definitely
didn't
mean
to
present
it
more
cert
with
more
certainty
than
it
is
but
yeah
I
mean
that
might
actually
be
a
great
subject
for
a
follow-up
post
because
what's
the
reality
on
the
ground,
so
thanks
for
raising.
B
F
Yeah
sure
so
you
know
just
thinking
through
the
structure
of
open
ossf
and
you
know
each
of
the
work
groups-
and
you
know
this
work
group's
been
going
for
a
couple
of
quarters.
Now,
we've
had
a
lot
of
you
know
interesting
presentations
about
identity,
related
technologies
and
those
sorts
of
things,
but
we
haven't
really
identified.
You
know
out,
you
know,
goals
and
output
of
the
working
group
right.
F
What
are
the
things
we
actually
want
to
get
done
with
that
information,
so
I'm
thinking
it
might
be
good
to
you
know
at
least
set
some
high
level
goals
and
things
you
might
want
to
do
through
the
rest
of
this
year.
F
F
You
know
I
think,
the
first
bullet
there,
we
put
quite
a
bit
of
time
last
year
into
the
threat,
modeling
document
that
sort
of
stalled
out
as
we
we
moved
into
holiday
season
right.
So
we
have
a
lot
of
work
there.
We
could
pick
up.
You
know
other
things
we're
thinking
about.
Is
you
know,
there's
the
badging
and
scorecard
projects.
Are
there
elements
of
identity?
We
want
to
push
there
as,
as
you
know,
hallmarks
of
a
secure
project.
F
A
Yeah,
I
think
the
exercise
we
did
in
the
beginning
was
super
helpful
and
I'm
just
looking
back
to
remind
myself
of
all
the
good
stuff
we
put
in
there.
I
think
the
one
one
thing
we
could
probably
start
adding
to
this
doc
is
like
the
mitigation.
A
So
like
we
identified
all
the
you
know
different
roles
of
identity,
but
I
don't
think
we
went
through
and
actually
said
like
how
you
know,
how
would
a
threat
this
piece
in
the
supply
chain
actually
be
mitigated
against,
and
then
you
know
putting
together,
like
you
were
saying,
like
white
paper
or
best
practices,
or
things
I
think
could
be
really
really
valuable,
is
something
that
that
we
strive
for.
That's
just
my
my
thoughts
on
on
that.
F
G
Right
yeah,
this
is
david
wheeler.
Two
quick
notes,
I
think
originally
the
notion
of
when
this
working
group
was
formed
was
that
we
were
going
to
do
that.
I
think
the
challenge
has
been
that
I
think
people
were
expecting
we'd
hear
a
couple.
People
everybody's
doing
the
same
thing
and
then
we'd
write
that
down
and
that
hasn't
that
hasn't
been
the
experience
at
all.
F
G
G
It's
much
harder.
Let
me
speak
specifically,
you
mentioned
adding
to
badging
and
scorecards
the
ci
best
practices
badge
actually
already
does
have
a
signed
release
requirement
for
the
silver
level
which
isn't
the
passing
level.
It's
the
one
level
higher
it's
called
signed
releases.
G
H
F
G
G
G
I
think
it's
more
than
just
you
know
you
could
do
it
by
using
character
pigeons,
but
we're
hopefully
not
going
to
say
that
sort
of
thing.
So
you
know
something
this
is
a
reasonable
way.
This
is
a
reasonable
recommended
approach.
Not
here's
how
you
must
do
it,
but
not
here's
how
you
could
do
it.
H
H
How
you
do
it
do
you
know
the
if
you're
a
package
owner
you
do
x,
y
and
z
and
boom,
you
are
salsa
3
or
whatever,
and
we
have
like
a
kind
of
like
a
a
well-lit
path
for
how
to
actually
reach
these
things.
It's
maybe
not
the
only
way
to
do
it,
but
it
is
like
the
one
recommended
way
to
do
it
with
salsa.
It
is
like
looking
at
the.
I
wasn't.
I
wasn't
there
for
the
previous,
like
threat
models
work.
H
The
threat
models
listed
here
are
wider
than
what
we
are
talking
about
with
salsa,
because
salsa,
at
least
as
it's
currently
proposed
is
specifically
around,
like
the
two
principles
are
auditable
and
like
two-party,
control
or
non-unilateral
versus
here.
I
think
there's
there's
more
threats
that
are
being
considered.
H
I
I
don't
know
like
kind
of
what
the
best
way
to
proceed
is
like.
Would
it
make
sense
to
kind
of
expand
like
what's,
should
salsa
be
like
adopted
by
this
working
group?
Should
that
be
the
framework?
Should
that
be
one
outcome
of
this?
H
Should
it
be
something
else?
I
guess
I
don't
know
exactly
how,
like
the
the
different
efforts
would
fit
together,
maybe
kim.
If
you
have
thoughts
or
gavin
or
someone,
another
option
would
be
to
like
expand
like
if
it's
so
desired
by
the
working
group
kind
of
make
the
framework
larger
to
address
all
these
threats.
I
don't
know.
F
H
G
Yeah
there
is
a
charter
for
it
I'll
have
to
pull
it
up,
real
quick,
but
it's
just
from
the
name.
You
can
guess
it
involves
determining
digital
identities
being
able
to
show
and
prove
them.
G
Let's
see
here
objective
is
to
here's
the
objective
statement
from
the
readme.
Our
objective
is
to
enable
open
source,
maintainers
contributors
and
users
to
understand,
make
decisions
on
the
providence
of
origin
of
the
code.
They
maintain,
produce
and
use.
H
So
that
I
I
mean
like
from
hearing
that
it
sounds
like
the
it's
there's
a
whole
lot
of
overlap
with
with
salsa.
Like
my
in
I
mean
the
our
goal
with
salsa
is
to
like
get
something
useful
and
we
don't
want
to
have
like
another
competing.
H
A
Yeah,
I
think
you
know
the
part
with
salsa
too
is
one
of
the
first
principles
is
non-unilateral
access,
something
we're
striving
for
which
then
again
ties
back
to
identity,
and
then
I
you
know,
I
thought
working
on
salsa
within
this
working
group
would
make
a
lot
of
sense
too,
because
very
early
on
we
got
some
pushback
about.
You
know
just
the
scope
of
the
working
group
in
general
and
other
people
were
asking
for
more.
A
You
know
just
broaden
the
scope
around
like
the
supply
chain,
so
that
was
you
know
some
of
the
motivation
for
for
discussing
that
here.
I
When
folks
are
talking
about
supply
chain
of
say
packages,
and
things
are
we
talking
about,
does
it
make
sense
to
think
of
because
there
was
a
attestation
in
the
title
sort
of
the
witnessing
of
you
know,
validation
of
identity?
Is
there?
C
I
You
know
as
someone
who's
done,
you
know
when
you're
managing
say
large
computer
systems-
and
I
think
kind
of
the
point
here
is
to
find
where
there
might
be
what
they
call
vectors
or
ways
software
got
in
there
that
you
don't
know
where
it
came
from
or
it
might
have
something
malicious
in
it,
and
then
you
also
want
to
see
where
it
came
from
and
kind
of
validate
who
it
came
from
things
like
that.
I
I
Should
you
know
rmrf
this
thing
like
you
know
what
I
mean:
don't
don't
get
into
the
implementation
as
much
as
the
suggestion
that
hey
potentially
this
entity
from
this
time
to
this
time
might
have
an
unverifiable
on
there's.
No
attestation
been
done
on
not
only
like
who
these
people
are,
but
this
set
of
changes
or
something,
and
then
also
the
person
that
did
these
changes.
They
don't
meet
a
bar
like
kind
of
it's,
it's
not
really
like
identity
like
can
they
be
named
it's
more,
as
is
it
a
strong
identity?
Has
it
been
proofed?
I
You
know
things
like
that
and
then,
and
so
at
a
station.
You
know
as
a
group,
it
would
be
like
saying
it's
reasonable
to
have
this
bar,
where
you
have
to
have.
I
mean
a
silly
example,
like
five
years
of
google
location
data
to
this
office,
to
prove
that
you're
really
the
person
that
worked
there,
because
that
would
be
hard
to
simulate
and
that
bar
is
high
enough
that
we
feel
like
this
questionable
thing.
I
We
should
just
ask
them
why
it
looks
so
questionable
or
something
you
know,
because
it
is
really
gray
when
you
start
getting
into
like,
but
an
easy
one
is
we
don't
know
who
this
person
is,
and
they
did
this
commit
and
it
just
went
out
to
every
single
router.
You
know
what
I
mean.
That's
that's
that
one's
easy,
but
you
know
having
a
bar
like
if
a
group
sets
a
bar
saying
we
trust
someone
at
this
level
is
interesting.
I
think
in
kind
of
publishing
something
like
that
would
be
interesting.
I
I
I
did
try
to
take
a
look
at
salsa
a
little
before
I
got
here,
but
and
the
intent
is
kind
of
that
same
thing
and
also,
I
think
these
things
happen
in
time
frames.
So
what
you
were
calling
it.
I
usually
call
it
remediation,
but
I
think
it
was
used
another
word
but
yeah.
What
do
you
do
once
you
find
out?
Sometimes
it's
good
enough
to
just
go
out
of
that
time
frame
or
honestly.
Usually
it's
not
just
go
turn
it
off
everywhere.
F
Yeah
I
mean,
I
think
the
other
thing
to
bring
back
up
to
is
the
it
is
an
explicit
non-goal
to
to
go
after
real-world
identities.
Right,
there's
a
lot
of
good
reasons
not
to
do
that
kind
of
went
around
about
that
for
a
while,
but
identifying.
F
Is
not
a
goal?
I
don't
think.
G
Me
now,
but
I
I
think
it's
it's
it's
something
about
real
identity
certainly
described,
but
I
don't
think
it's
quite
we
we
forbid
the.
I
don't
think
it's
we
forbid
the
identity
of
real
people.
I
I
think
it's
don't
require
the
identity
of
real
people,
which
is
a
different
statement.
Let
me
go
click
on
things.
I
Right,
it's
strong,
strong
identity
proofing
doesn't
mean
just
handing
out
your
personal
identifiable
information.
It's
more
just
strongly
I,
by
proofing
that
this
is
the
the
thing
it
says
it
is
whether
what
that,
whatever
that
is
and
the
I
think
we
have
the
tools
now
to
do
what
some
people
call
like
the
slider.
It's
you
know
just
reveal
as
much
as
necessary
right.
We
can
do
that
easily.
Now
you
don't
there's
no
anonymity
and
there's
also
no
full
thing.
You
can
kind
of
control.
I
G
I
think
the
goal,
in
fact
it
says,
like
we
are
able
to
work
under
a
pseudonym.
It's
not
requiring
people
to
work
under
pseudonyms
is
a
different
statement.
I
think
I'm,
for
example,
I
I'm
actually
fine
working
under
my
actual
real
name.
Well,
at
least
everybody
thinks
that's
my
real
name
right,
but
but
others
will
not,
and
that's
that's
fine
as
long
as
we,
but
I'd
still
like
to
know
that
you
know
x.
Y
z
is
the
same
x
y
z,.
I
But
I
guess
what
I'm
saying
is:
names
are
just
one:
what
they'd
call
a
predicate
to
an
identity,
so
you
know
we're
all
made
up
of
thousands
of
things.
We
could
say
about
ourselves
that
we
could
prove,
and
you
know
if
I'm
a
person
of
color
and
people
are
going
to
not
respect
my
opinion
about
this
software.
I
G
F
Details,
well,
I
think
it's
not
just
name
two
right:
there
there's
a
host
of
sensitive
information
that
could
potentially
get
people
in
trouble
right
location
as
well.
I
think
we
probably
need
to
flesh
that
out.
You
know
from
a
tools
perspective,
whether
it's
also
anything
else.
I
I
think
from
we
recommend
any
any
particular
tool.
F
F
C
G
If,
if
I
can
jump
in,
you
know
those
of
you
don't
know,
I
lead
the
ci
best
practices
badge
project.
We
we
had
a
lot
of
experience
and
built
on
previous
experiences
too
of
you
know
the
criteria
say
this
is
the
actual
requirement
and
it's
very
high
level.
You
can
meet
it
a
thousand
ways
and
then
but
but
it's
very
specific.
This
is
the
criterion
and
then
hey
here's
some
guidance
for
typical
cases.
Here's
a
way
you
would
typically
meet
that.
G
It's
not
a
requirement,
you
can
do
it
other
ways,
but
these
are
ways
that
will
meet
and
it's
I
think
it
is
challenging
to
to
make
that
split,
but
it
also
means
that
your
your
criteria
are
going
to
last.
So
you
know
somebody
makes
a
better
tool.
Great.
You
can
use
the
better
tool,
you
don't
need
to
change
the
criteria.
You
just
have
a
better
way
to
implement
the
criteria
great,
but
it
is
true
that
if
you
don't
give
any
people
any
hints
about
how
to
do
it,
you
know:
hey,
don't
worry.
G
A
Yeah,
I
think,
and
some
of
the
stuff
you
know
on
the
salsa
proposal
is
almost
like
a
step
I
don't
know
higher
if
higher
is
the
right
word,
but
like
even
just
looking
at
the
basics
of
like
the
source
code,
management
systems
and
builders
that
are
exist.
Like
you
know,
one
of
the
things
we
want
to
do
with
salsa
is
work
with
the
community
on
defining
like
what
are
strict
requirements.
We
should
have
for
all
the
source
code
management
systems,
like
you
know,
if
you
can't
even
trust
those
and
like
what
do
you
like?
A
What
do
you
have
at
the
end
of
the
day?
So
you
know
it's
a
lot
of
things
that
people
are
already
using
and
and
in
their
workflows
and
then,
of
course,
popular
ci
cd,
tooling,
and
what
does
it
mean
to
be
a
secure
builder?
What
what
what
properties
should
a
secure
builder
have
what
what
you
know?
What
what
policy
should
you
be
able
to
apply
against?
You
know
stuff,
that's
coming
out
of
the
builder
things
like
that,
so
I
don't
know.
A
If
folks
have
you
know
internally
in
their
organizations
in
some
ways
that
you
evaluate
those
types
of
things
now
like,
how
do
you
know
that
you
can
trust?
Even
you
know
the
source
code
management
systems?
Are
you
just
trusting
them
blindly?
Do
you
just
trust
that
you
know
the
the
information
that's
given
to
you
on
commits
is
what
you
know.
What
is
supposed
to
be
there
so.
J
Yeah
I
mean,
as
you
describe,
that
problem
kim
you
know,
I'm
biased,
because
I
work
every
day
in
the
public
infrastructure
world
these
days,
but
it
sort
of
reminds
me
of
like
the
root
trust
program,
guidance
and
ca
browser
forum,
guidance
for
web
certificate
authorities,
where
you
know
everyone
gets
together
together
periodically
and
agrees
on
criteria
that
these
publicly
trusted
certificate
authorities
are
audited
against
around.
J
You
know
how
they
issue
certificates,
but
also
operational
things
like
you
know,
their
signing
keys
have
to
be
in
hsms
and
their
route
and
key
can't
be
online.
You
have
to
like
physically
enter
a
command
into
a
keyboard,
so
they
sort
of
you
know
it's
not
a
it's,
not
a
piece
of
software.
It's
it's
an
agreement
right.
G
I
think
that's
key
is
you
know
you
have
to
interpret
texts
and
that's
okay,
but
it's
not
fair
to
interpret
them
in
a
quiet
building
and
poof
and
here's
your
answer
without
any
ability
to
to
question
it,
but
but
the
idea
of
here's
the
criteria,
here's
some
guidance,
oh
wait!
What
the
heck
is
that
and
a
way
to
say,
here's
how
we
interpret
this
and
a
process
so
that
you
can
figure
out?
Does
this
meet
the
real
goal?
G
I
I
will
say
that
one
thing
that
I
found
really
really
helpful
in
some
cases
and
we
tried
to
do
this
for
the
ci
best
practices.
Also
is
we
had
rationale
for
not
just
here's
the
criteria,
but
we
also
documented.
Why
is
this
criterion
there
at
all
and
when
you're
trying
to
interpret
well
wait
a
minute?
I
have
this
weird
way
of
doing
it.
G
You
you
you,
I
don't
know
if
that
meets
the
letter
or
spirit
of
the
law.
Well,
what's
the
point
of
that?
Oh
the
point
is
to
do
this.
Well,
this
totally
fails.
Well
then,
or
you
know
what
that
that
does
it
then
so
I
and
that
would
be
I
I
think,
that's
a
I
don't
want
to
say.
G
Hey
salsa
folks
do
lots
more
work,
but
I
think
that
would
be
a
good
thing
would
be
a
little
bit
and
I
know
you're
trying
to
make
it
short
to
start
with,
and
I
commend
that,
but
it
might
be
useful
to
for
anything
we
do
with
salsa
or
if,
if
this
working
group
does
salsa
or
anything
else,
we
do
try
to
have
some
rationale
so
that
we
can
know
whether
or
not
a
particular
approach
actually
does
the
job.
H
One
of
the
things
that
we
are
proposing
with
salsa
is
that
we
don't
think
it's
practical
that
everyone
is
going
to
agree
on.
Those
like
different
organizations
will
have
different
kind
of
levels
of
trust,
like
I
won't
mean
particular
orgs,
but,
like
one
organization
like,
maybe,
would
trust
another
like.
Yes,
we
believe
that
they're
going
to
do
the
right
thing.
We,
according
to
our
threat
model
and
like
the
level
of
security,
that
we
want
that's
good
enough,
but
another
org
might
not
we.
H
They
might
say,
no,
no,
no,
we're
not
going
to
trust
just
anyone
we're
only
going
to
pick
and
choose,
and
so
I
think
kind
of
like
thinking
about
that
as
a
first
class
concept
is
kind
of
worthwhile
that
you
know
effectively
whether
or
not
something
meets
a
requirement
is
according
to
someone
right
like
the
ci
best
practices.
I
Think,
there's
in
in
large
organizations,
if
it's
impossible
to
validate
or
audit,
I
I
just
looking
back
at
the
slas
or
the
salsa
stuff
in
unless,
in
a
way
like
the
extremely,
unless
everything's
tracked,
like
every
single
dependency
has
already
been
solved,
you
can't
you
can't
audit
it,
and
so
what
some
of
us
are
finding
like
I'd,
say
in
the
field
doing
this
stuff
day
after
day,
is
that
unless
there's
really
no
way
around
the
fact
that,
like
if
you
arrive
here
from
like,
say,
docker,
there's
no
way
to
get
around
the
fact
that
essentially,
there's
been
no
there's
no
articulated
policy
and
software
writing
programming
or
even
docker
files
is
not
actually
policy
until
there's
like
an
abstract,
articulated
policy
that
says
what
you're,
using
in
a
declarative
fashion,
there's
it's
impossible
to
actually
go
back
through
and
solve
for
where
the
dependencies
are,
and
on
top
of
that,
everyone
here
is
basically
asking
for
a
system
of
transitive
trust
when
there's
just
this
lack
of
basic
policy
around
these
things,
so
writing
say
a
build
job
or
even
following
the
rules
of
best
practice
of
ci.
I
I
Without
the
policy
you
got
to
come
from
that
direction,
which
is
to
say,
even
if
you
start
small
witches.
We
know
that
the
curl
was
compromised.
Now
we
have
a
policy
about
curl
and
we
know
where
we
use
it
and
unless
you
have
that
it's
almost
impossible
to
do
any
kind
of
fact
tracking,
but
also
we're
finding
that
it
also
helps
to
actually
reason
about
what
you
all
are
trying
to
do.
I
As
your
working
group,
which
is
people,
can
articulate
their
policies
for
themselves
and
then
they
can
check
their
list
against
stuff
people
are
finding
or
vulnerabilities,
and
so,
but
without
that
kind
of
common
communication
language,
it's
almost
like
we're.
Looking
into
things
like,
can
you
actually
add
tests
like?
I
Is
there
a
deed
for
your
or
title
or
some
kind
of
license
for
your
ci,
and
and
can
it
be
a
test
it
and
then
can
I
check
that
for
vulnerabilities
and
then
I'll
sign
off
on
that
and
say
you
did
a
good
job
and
I
will
take
on
that
liability
like
a
house
inspector,
so
this
stuff
is
going
on.
That's
why
we
kind
of
found
this
group,
but
you
know,
without
those
policies
you're
it's
just
needle
and
haystack
stuff.
It's
it's
complex.
F
I
I
mean
I
I
would
suggest
like
with
especially
around
identity
or
security
of
of
supply
chains
and
software.
We
I
I
would
propose
that
there
should
be
at
least
some
kind
of
start
of
a
document
that
is
sort
of
like
either
the
policy.
That
is
recommendations
like
you
said
it
shouldn't
be
too
abstract.
It
should
be
implementable
or
some
kind
of
way
to
advise
people
on
how
to
articulate
their
own
policy,
so
that
tools
like
salsa
can
better
like
there's
not
such
an
impedance
mismatch.
I
So
like
it's
or
something
like
helping
people
understand
one.
Are
you
able
to
map
your
supply
chain
and
to
to
hold
it
up
to
something
that
says?
There's
issues
over
here
that
someone
found-
or
this
has
not
been
validated
right,
you're
using
things
that
no
one
knows
who
wrote
it
or
something
like
that.
I
So
I
guess
I'm
I'm
saying
writing
things
down
in
an
abstract
policy
that
isn't.
Software
might
potentially
be
a
necessity,
because
software
is
not
a
good
policy.
Even
if
you
write
your
jobs
or
you
have
sort
of
software
policies
around
what's
being
built
and
how
it
all
fits
together.
I
It's
not
as
good
as
an
abstract,
declarative
policy
is
one
of
the
things
I
think,
if
that's
a
little
wonky
sorry,
it's
it's
hard
to
describe
these
things,
but
one
layer
outside
of
the
software
itself
to
say
what
you're
trying
to
do
would
help
a
lot
to
be
able
to
track
these
things
down
and
and
then
have
conversations
around
them
about
safety
and
things.
A
Sorry
I
just
stepped
away
for
a
quick
second,
not
following
everything.
There's
tree
people
coming
to
my
house,
so
I'm
not
yeah.
I
don't
know.
If
you
can,
you
might
be
willing
to
write
down
on
some
of
the
stuff
that
you're
thinking
about,
so
we
can
sort
of
ingest
it
a
bit
more.
I
mean
with
the
salsa
thing
like
what
I
envision
is.
You
know,
once
we
sort
of
all
agree
on
basic
principles
and
terminology
and
everything
that,
like
justice,
also
levels
could
be
used
as
part
of
policy.
A
So
you
could,
you
know,
as
an
organization
be
able
to
say
I
don't
want
anything
going
in
production
that
only
meets
salsa
level
one
or
everything
has
to
meet
salsa
level.
Three
or
the
builder
that
I'm
using
you
know
it
needs
to
meet
these
the
salsa
level,
one
for
all
the
components
and
like
the
builder.
D
I
Yeah,
it's
exactly
that,
like
you
said
you
know,
where
do
you
actually
write
down
that
sentence
that
we
want
to
be
salsa
level?
Three
there's
things
called.
I
wanna
be
cis
level,
two
on
all
my
computers,
you
know
so,
but
it's
not
a
statement,
it's
something
you
write
down
and
that
ends
up
being
the
policy
I'm
talking
about.
So
even
us
saying
that
as
a
group
we
want
to
be
salsa
level
one
and
we
all
write
that
down.
I
A
Well,
I
think
we're
trying
to
agree
on
those
definitions.
First,
you
know,
because
open
source
isn't
only
controlled
or
owned
by
one
person.
We
need
to
work
with
a
community
to
actually
define
what
those
those
that
criteria
is
and-
and
you
know
we
put
a
first
draft
up
there
and
left
a
few
blanks
that
we
were
hoping
folks
would
want
to
help
us
fill
out.
A
We
can
certainly
put
our
own
ideas
of
what
we
would
think
should
be
recommended
at
those
different
criteria
and
then
and
then
once
we
have
that
that
sort
of
in
agreement,
people
or
people
are
happy
with
it,
then
I
think,
then
the
policy
part
comes
in
and
that
could
be
like
per
organization
or
depending
on
the
different
use
cases.
You
know,
maybe
maybe
certain
things
in
your
stack.
A
G
I
I
I'm
not
one
of
the
salsa
authors,
but
I
did
read
it.
I
see
mark
lodatos
on
here
and
he
he
should
probably
speak
up
and
correct
me,
but
my
understanding
from
reading
it
is
that
specifically
talking
about
salsa
because
of
the
very
problem
that
stephen
locke,
I
believe,
has
mentioned
that
you
know
trying
to
figure
out.
Total
transit
of
closure,
for
everything
is
really
hard.
This
also
folks
have
ex
have
explicitly
said
the
level
is
for
this
particular
product,
not
for
the
things
that
get
included.
G
If
you
want
those
you
transitively
reapply
salsa
to
those
now,
you
can
argue
that
that
has
a
problem.
Obviously
you
can
have
this
high
salsa
level
and
bring
in
garbage,
but
I
I
think
I
I
I
actually
see
the
wisdom
and
what
they're
doing,
because
you
know
I
I
think
we're
gonna
have
to
we
have
to
start
walking
before
we
run
and
very
few
projects
are
going
to
be
able
to
say
you
know.
Not
only
do
we
do
this,
but
the
entire
transit
of
closure
does.
I
think,
that's
unlikely.
G
If
anything,
you
can
work,
one
level
back
and
that's
probably
the
best
any
one
project
can
do
and
even
then
it's
going
to
be
limited
and
mark
feel
free
to
or
kim
feel
free
to
correct
everything.
I
said.
H
No,
that's
exactly
right
and
and
just
to
be
clear
because
I
know
like
no
one
is
like
super
aware
of
all
the
ins
and
outs
of
our
proposal
like
salsa
is
not
a
tool.
H
It
is
I
it's
actually
kind
of
the
it
overlaps
very
heavily,
as
I
understand
it
with
this
working
group,
which
is
like
the
mission,
which
is
to
propose
a
set
of
standards
for
like
what
we
think
software
like
organizations
or
software
supply
chains,
what
properties
we
think
they
should
have
those
we're
calling
standards,
some
accreditation
process
for
like
how
you
verify
that
those
standards
are
met
and
then
a
specific
set
of
recommended
tools
that
you
can
use
to
to
accomplish
that,
and
actually
you
know
in
practice
achieve
it
both
as
a
software
producer
and
a
software
consumer,
but
it
would
it
wouldn't
be
mandated
tools.
H
F
G
He
means
you
presumably
mean
the
ci
best
practices,
badge
yeah,
yeah,
I've,
I've
reviewed,
they're,
not
identical.
I've
haven't
really
talked
to
mark
about,
what's
overlapped
and
not
overlapped,
but
there's
a
whole
bunch
of
things
in
the
cia.
Best
practices
badge
that
aren't
in
salsa
the
ci
best
practices
badge
is
way
more
focused
on
things
that
you
should
be
doing
to
increase
the
likelihood
that
you're
going
to
produce
good
code
and
and
there's
some
other
thing.
G
You
know
and
salsa,
for
example,
is
really
heavily
focused
on
the
what
I
call
two,
what
what
has
at
least
the
last
couple
decades
been
called
two
person
control.
I
keep
forgetting
the
name
that
you
call
it,
but
at
least
in
the
military
it's
been
called
two-person
control
and
the
problem
with
two
person
control
is
that
most
open
source
projects
can't
do
it,
so
the
ci
best
practices
badge
doesn't
even
try
to
get
there
till
gold.
G
G
Yeah,
so
it's,
but
it's
a
different
set
of
criteria,
so
one
hand
clapping
what
I.
G
So
yeah,
actually,
no
that's
not
true,
though,
there's
a
huge
number
of
things
you
can
do
as
a
single
person
project
to
reduce
risks
and
sure
multiple
people's
better.
I
don't
think
anybody
doubts
that,
but
the
question
is
what
you
know
for
those
projects
that
are
that
don't
have
that.
What
can
you
do,
and
the
answer
is
quite
a
bit
yeah.
I
Oh
go
ahead
and
see
to
make
it
more
clear
kind
of
where
I
would
so.
I
do
see
a
distinction
here
and
it
will
probably
help
what
mark
is
is
talking
about.
I
think
in
some
ways
is
how
you
def
you're
sort
of
defining
on
what
what
good
looks
like
I'd
say,
I'm
someone
who
could
take
that
and
run
it
on
computers.
I
So
what
we
do
is
we
take
complex
government
level,
stigs
and
nist
stuff,
and
you
have
to
lower
it
down
into
something
you
can
check,
or
you
know
like
it's,
it's
kind
of
the
reverse
of
how
you
read
your
salsa
page,
which
is
take
those
policies
and
then
make
it
checkable
across
that
whole
depth
chain,
and
so
some
of
us
are
when
you
when
I
would
like
to
participate
in
some
of
the
more
like
what
good
looks
like.
I
But
honestly,
once
you
know
it's
like,
I
know
how
to
write
it
down
and
run
it
on
computers
and
give
you
an
answer
and
that's,
like
you
know,
anyone
from
sort
of
the
traditional
config
management
space
security
compliance.
This
is
all
we
do.
So
if
that
helps
it's
like
once,
we
know
what
it
looks
like,
even
if
it's
just
one
thing,
I
can
run
it
all
the
way
through.
If
that
makes
sense,
and
so
your
docker
example
is
really
great
once
you
know
what
you're
looking
for.
I
And
and
where
we
meet
is
that
sort
of
you
know
maybe
it's
some
sentences,
but
it's
hard
to
run
some
sentences
on
a
computer,
and
so
I
think
your
intent
here
is
you
know,
categorizing,
risk
and
and
and
sort
of
defining
trust
and
mapping
it
to
these
complex
software
pipelines.
I
But
once
you
know
kind
of
what
good
looks
like
if
we
can
write
it
in
some
format
like
essentially
like
something
a
computer
understands
or
lower
it
down
into
things,
we
can
actually
make
checks
and
and
actually
do
some
actual
running
of
these
things,
assertions
and
and
give
people
some
idea
of
how
vulnerable
they
are.
You
know
and
and
where
it's
at
that's
the
part
at
scale.
I
So
if
that
helps
it's
like
I'm
no
policy
expert,
but
I'm
a
policy,
I'm
a
compliance
expert,
let's
remediation,
if
that
makes
sense
so,
but
you
can't
run
what
you
didn't
write.
I
unless
you
tell
me
what
it's
like
going
to
the
doctor
and
they
say
what's
wrong,
you
got
to
tell
them
somewhere
to
start
looking
so.
H
And
and
just
to
be
clear
for
the
salsa
piece
like
we
are
proposing
those
two
principles:
auditable
and
two-party
control,
because
that's
what
within
google
we've
found
a
useful,
manageable
thing
that
we
could
actually
accomplish
and
do
it
at
scale,
but
I
don't
we're
not
tied
to
that
being
the
only
set
of
principles
or
if
the
working
group
thinks
like
there
ought
to
be
some
other
principle,
that's
orthogonal
to
those,
and
that
should
be
added
like
again.
H
I
just
want
to
make
it
clear
like
it's
not
like
we're
saying:
here's
salsa.
Does
it
work
but
rather
like
we
would
like
to
help
achieve
this
mission.
Here's
a
starting
point
that
we
think
might
be
helpful.
G
Yeah-
and
I
think
the
one
of
the
differences
is
salsa,
with
the
exception
of
two
person
which
does
get
into
development.
A
lot
of
it
is
really
more
focused
on
the
after
it's
delivered.
How
do
I
make
sure
it
gets
out
and
signed
and
so
on,
which
I
think
is
is
distinguishing
it's
not
the
it's,
not
that
you
with
the
the
google
folks
permission,
I'm
sure
we
can
steal
some
things
into
the
badge
too.
So.
F
Well,
that
was
kind
of
my
point
right.
It
just
feels
like
we're
getting
super
fragmented
already
right.
Not
even
you
know,
six
months
into
the
life
of
the
foundation,
you
know
if
there's
concept
and
saul
so
they're
useful,
then
contributors
into
the
badging
program.
If
there's
other
stuff
that
doesn't
belong,
there
then
find
a
home
for
it
yeah.
We
should.
H
We
should
I,
I
didn't
realize
you're
the
owner
of
the
badging
thing
david,
that
we
should
definitely
talk
about
that
and
how,
like
we
think,
like
put
those
together
yeah,
I
agree
it
should
not
be
fragmented.
I
think
it
should
be
nameless.
I
wouldn't.
G
F
A
Yeah
I
mean
I
when
I
was
looking
at
the
badge
program
again
too
it
just
I.
I
saw
enough
differences
where
I'm
not
sure
if
you
could
take
like
all
the
criteria
we
have
in
salsa
today
and
apply
it
to
the
different
batch
levels,
because
there's
more
of
you
know
more
of
the
supply
chain
sort
of
connected
piece
in
there,
and
I
like
when
you
look
at
them
david.
Do
you
think
like
we
could
take
all
the
criteria
from
salsa
and
apply
it
to
the
different
badging
levels.
D
G
My
goal
is
to
let
salsa
be
salsa,
but
you
know,
could
we,
I
suspect
at
least
some
of
them
sure
the
bigger
challenge,
and
I
think
it's
a
procedural
challenge,
as
I
said,
and
I
think
we've
you
know
mark
and
I've
already
talked
about
this-
and
I've
already
alluded
to
it
earlier-
the
challenge
for
the
many
projects
that
don't
have
multiple
people,
but
but
you
know,
but
for
some
of
these
I
think
that
wouldn't
be
hard.
I
have
not
focused
on
it
that
way,
because
I
don't
want
to.
A
Got
you
know
when
I
just
took
a
look,
I
was
like.
Could
this
fit
and
it
felt
like
to
me
best
practices
was
more
about
like
the
general
hygiene
of
a
project
and
everything,
and
I
wasn't
sure,
if,
like
salsa
criteria
in
spirit,
would
would
map
well
within
the
existing
levels,
but
yeah,
certainly
something
we
could.
G
Yeah,
you
know
what
we
one
thing
we
could
do
is
just
take
a
take,
a
look
and
and
try
to
see
because
if,
if
indeed,
even
if
they
all
don't
fit,
if
some
fit,
that
would
make
it
easier
to
for
somebody
to
do
salsa
if
they're
doing
the
badges-
and
you
know
we
can
go
from
there,
but
we
could
certainly
see
if
it
if
it
could
fit
in
that.
In
that
framework,.
G
So
mark
I
mean,
if
you're,
if
you're
willing
to
have
some
time,
we
can
kind
of
sit
down
and
just
kind
of
talk
through
what
that
might
look
like
and
it's
okay
if
it
doesn't
work
out.
But
you
know
we
can
and
it
wouldn't
be
surprising
if
some
are
harder
and
some
are
easier
and
you
know
yeah
we'll
know,
then
we'll
know
more.
H
Yeah
we
should
I
mean
we,
you
and
I
have
a
meeting
planned
for
later
today,
scheduled
for
later
today.
We
we
could
go
through
and
kind
of
see
like
where's
where's,
the
overlap
and
where
the
difference
is.
I
would
imagine
the
two
as
I
understand
it,
which
is
probably,
which
is
a
little
bit
shaky.
There's
two
main
differences.
H
One
is
like
the
principles
or
the
focus
is
different,
like
the
set
of
threats
we're
worried
about
is
there's
probably
a
little
bit
of
a
lot
there,
and
I
I
don't
know
as
much
here
like
salsa
is
more
focused
on
like
an
end-to-end
guarantee
that
when
you
receive
a
software
artifact
that
all
those
properties
were
chewed
throughout
this
entire
supply
chain
and
weren't
subverted,
whereas
the
best
practices
badge
is
more
about
the
intent
I
think
of
like
this
is
configured
to
do
it
properly,
but
no
verification
at
the
end
that
it
was
done
properly.
G
Well,
it
gets
it
gets
a
little
murky
because,
as
I
mentioned,
for
example,
there
are
so
you
know
when
you
get
to
silver.
All
of
a
sudden,
you
there's
requirements
to
do
signed,
there's
requirements
to
do
signatures
and
I'll
note
that
by
you,
you've
been
you've
been
worried
about.
Reproducible
builds,
that's
a
gold
requirement,
so
it's
a
straight
up.
You
know,
which
is
something
salsa
does
not
guarantee,
is
reproducible
builds,
and
that
is
a
requirement
for
the
gold
badge
for
seattle
best
practices.
So
you
know
so
it's
not
it.
G
F
You
know
it's
probably
more
of
a
an
existential
question
for
the
the
tack
or
the
board
right,
which
is
you
know
the
foundation
level.
Is
that
the
intention
that
you
know
the
goodness
of
the
working
groups
or
sort
of
aggregates
at
a
couple
of
touch
points
for
end
user
projects
to
consume?
Or
is
it
more
of
an
a
la
carte?
You
know
each
track
is
independent.
It
has
its
own
set
of
recommendations
and
tools
and
things
and
people,
just
you,
know,
go
in
and
choose
what
they
want.
I
Would
gavin
would
the
gold
in
some
in
some
ways
to
be
to
help
smaller
projects,
then
kind
of
have
some
kind
of
way
to
do
very
efficient,
transitive
trust
to
a
larger
thing?
Is
that
what
the
or
is
it
more
like?
Is
that
and
then
this
group
sort
of
maintains
or
helps
build,
that
larger
thing
kind
of
like
a
commons
of
trust
for
this
stuff
for
the
supply
chains?
Or
is
it
because
I
will
say
I
don't
and
it's
this
might
be
more
on
the
like?
I
I
don't
want
it
to
make
it
like
a
technical
thing,
but
I
will
say
that
these
graphs
sum,
so
it's
it's
more
like
a
basketball
bracket
than
a
supply
chain,
which
is
you
can
trust
the
the
person
who
everyone
else
trusted.
So
for
these
small
projects
it
will
sum
for
them,
but
so
intense,
for
I
think,
and
so
for
this
giant
graphs
that
we're
talking
about
giant
dependencies
all
through
this
chain.
I
What's
cool,
is
it
actually
sums,
and
so
you
can
actually
trust
everybody
up
to
some
certain
point
and
you're
good
so
like
for
a
small
project,
they
can
just
start
by
sort
of
trusting
a
larger
entity
and
while
they
figure
out
whether
their
house
is
in
order
from
there
on
out
is
that
kind
of
the
model
that
people
are
talking
about,
because
it
is
insurmountable
if
you're
saying
that
someone
who
writes
curl
is
responsible
for
curl
being
in
a
docker
image,
distributed
by
docker
than
used
by
everyone.
I
That's
really
tough
right,
and
so,
but
it
does
sum
so
you
can
do
it
in
very
small,
tiny
little
increments
on
on
both
ends
and
work.
Your
way
through,
and
it
just
adds
up
like
map,
reduce.
H
A
A
Maybe
we
continue
this
conversation
next
week.
Gavin,
I
don't
earn
the
next
meeting.
I
don't
know
if
we
got
to
the
whole
crux
of
what
we
were
trying
to
drive
in
terms
of
goals,
but
I
thought
it
was
a
healthy
discussion.
Nonetheless,
yeah.
A
Yeah,
I
mean
it's
tough
to
know
what
folks
are
excited
about
and
want
to
work
on
too,
I
mean
I
can't
even
tell
google
engineers
what
to
do.
I
just
have
to
get
them
excited
about
working
on
specific
things.
So
you
know
other
working
groups
have
projects.
So
it's
really
obvious
what
folks
are
working
on
together
this
one.
A
You
know,
there's
no
real
projects
right
now,
just
a
bunch
of
standards
and
white
papers
and
things
which
I
think
is
all
great,
because
that's
the
first
step
is
people
have
no
idea
what
they're
supposed
to
be
doing
and
what
to
be
worried
about.
So
I
think
things
that
we
do
will
add
value
in
one
way
or
another.