►
From YouTube: IETF-SCITT-20230925-1500
Description
SCITT interim meeting session
2023/09/25 1500
https://datatracker.ietf.org/group/scitt/meetings/
B
C
C
C
Okay,
it's
three
after
and
it
looks
like
a
good
bunch
of
people
are
on
now:
Hank's
gonna
be
late.
So,
just
speaking
on
his
behalf
briefly
we're
going
with
the
standing
agenda
today
of
trying
to
sort
out
our
primary
item,
which
is
feeds
Hank
knows
some
of
the
folks
at
omnibor.
So
we
will
continue
looking
into
whether
we
can
get
get
that
guest
speaker
in,
but
I
think
we'll
assume
for
now
that
we
won't
do
that.
C
We'll
need
to
give
a
couple
weeks
notice
anyway,
so
yeah,
let's,
let's
try
and
keep
on
topic
and
get
this
feed.
Id
thing
worked
out
ahead
of
118.,
so
I
know,
there's
been
quite
a
lot
of
work
in
the
background
with
with
Steve
some
folks
from
the
archivist
team
and
I.
Think
Ori
has
been
helping
with
that
as
well.
So
I
don't
know
if
it's
Steve,
If
you're
sort
of
equipped
and
ready
to
just
sort
of
kick
off
with
some
ideas
or
lead
a
discussion
that
would
be
most
useful.
D
E
Can
we
separate
those
two
things
out
so
that
we
can
make
some
progress
on
those
independently
and
what
I
mean
by
that
is?
If
we
think
about
the
way
skit
does
things
is
it's
does
things
one?
One
thing
really
well
in
that
it
stores
statements
made
by
an
identifier
and
those
are
separate
objects
that
are
linked
together.
E
E
If
a
feed
ID
is
just
a
generic
string
of
some
sort,
we
should
talk
about
that
more.
But
what
I,
if
you
tease
out
the
identity
from
being
embedded
into
the
feed
ID,
when
you
create
a
feed,
does
that
act?
Is
it
created
by
an
identity?
Does
that
give
us
the
one
thing
that
skit
does
well
ability
to
reuse?
E
F
D
F
F
You
know
company
X,
what
are
all
of
the
products
that
are
in
in
the
in
the
skit.
If
you
don't
put
it
in
there,
then
you're
gonna
have
to
have
some
other
additional
registry
that
says:
okay,
they
could
maintain
it
themselves,
they
put
it
somewhere
else,
but
then
you
do.
You
trust
that.
So
then,
there's
a
list
of
here's
all
the
things
that
I
put
into
skid
I.
F
Think
you've
got
to
have,
to
put
it
in
I,
mean
I
I
I'd
love
to
see
all
the
arguments
for
not
doing
it,
but
I
think
that
that
the
joining
of
the
identity,
not
all
the
details,
but
just
the
some
kind
of
a
a
a
pointer
to
the
identity
record,
whether
that
be
the
x509,
you
know
thumbprint
or
hopefully
a
did
web
URL
type
thing
that
is
essential
for
for
it
in
that's
the
statement
of
what
I
my.
What
I
think
kind
of
supports
that
argument.
Thanks.
E
I
so
I
I'll
Hank
is
next.
Are
you
are
you
referring
to?
So
if
you
look
at
skid,
IO
and
or
even
the
ITF
slack
thread,
because
I
updated
where
it
says
claim
to
statement,
but
if
you
go
to
skip.io
there's
a
reference
at
the
beginning
when
we're
trying
to
Define
what
is
skit
is
there's
an
identity
that
makes
a
statement
word
read
statement
instead
of
Claim
about
an
artifact,
there's
optional
pointers
to
evidence,
that's
the
link
to
some
Doc
and
again.
We
can
change
the
words
on
here,
because
this
is
the
dated.
E
F
I
think
if
you're
saying
that
that
gee
it's
a
great
idea
to
use,
skip
for
creating
identities
and
actually
before
we
get
started
with
submitting
products
Gee,
let's,
let's
submit
the
the
the
like
the
semantic
name
of
this
person-
and
you
know.
Basically
here
is
the
URL
to
the
did
web
information
for
this
identity
and
then
that
submitted
as
a
sign
statement.
That
sounds
fine
to
me.
B
C
So
Kelly
we're
still
talking
about
the
one
end,
only
primary
target
for
both
Scrappy
and
the
architecture
document,
which
is
to
determine
feed
structure.
This
was
the
action
item
that
came
out
of
117.,
so
there
are
a
handful
of
small
edits
coming
in,
but,
as
you
might
have
experienced
in
a
couple
of
Prior
meetings,
we're
trying
to
work
out
even
the
requirements
that
everybody
wants.
C
All
the
discussion
about,
how
we
search
things
or
whether
we
should
search
things
also
ultimately
comes
down
to
the
distillation
that
Steve's
come
to,
which
is
you
know,
the
feed
ID
may
or
may
not
be
comprised
of
the
things
you're
searching
for
and
I.
Think.
The
the
discussion
we're
having
now
is
is
essentially
arguing
the
case
for
you
can
find
it,
but
it
is
not
composed
of
those
of
those
things.
C
B
B
Yeah
I,
don't
have
slack
so
I
mean
is,
is
that
is
that
now
the
official
means
of
communicating
we
have
email,
slack,
we've
got
GitHub
and
we've
got
this
call.
I
mean
I,
just
I'm
having
trouble
following
all
the
threads
I
mean
I'm
involved
in
you
know,
probably
12
different
projects
similar
to
this,
and
it's
really
hard
to
keep
all
the
all
the
threads
straight.
So
I'll
withdraw
right
now,
but
I
think
we
need
to
get
that
down
because
I
can't
follow
it.
Honestly,
yeah.
C
E
G
So
this
is
the
thing
hi
everybody
I
want
to
come
back
to
the
feed
topic.
I
had
some
in
between
times
that
I
have
no
time
in.
There
are
some
extensive
feedback
sessions
with
authors
and
editors
of
IDs
and
and
feeds
do
not
exist
in
a
vacuum.
They.
There
are
three
header
parameters
for
issued
statements,
sign
statements,
sorry
I'm
defined.
One
of
them
is
the
issuer,
of
course.
G
So
a
feed
is
always
a
subordinate
to
the
issue
and
there
is
a
subordinate
to
the
feed,
which
is
the
registration
and
for
funded
I,
want
to
say
right
now,
and
so
in
this
registration
info
bundle.
It
might
be
a
useful
point
to
to
keep
the
the
general
specification.
Actually
they
are
and
then
create
from
that
point
of
that
bundle
so
that
registration
for
container
a
a
kind
of
I
want
to
say
profile,
although
it's
literally
not
a
substrate,
it's
only
augments
and
and
then
for
the
supply
chain.
G
One
of
them
is
a
sequence
number,
and
it
already
was
hard
for
me
to
argue
that
that
is
an
optional
item,
because
maybe
I
always
want
to
keep
track
or
put
the
burden
of
keeping
track
actually
because
you're
issuing
it,
which,
which
sequence
number
now
happens
in
this
feed,
so
that
you
have
a
counter.
Maybe
it's
too
much
burden
to
prescribe
an
issuer
to
prescribe
it
to
to
keep
that
counter.
G
So
you
just
move
on
without
it,
and
you
have
to
need
an
index
service
to
create
that
on
top
of
the
append
Only
log
I
don't
know
yet.
But
what
I
I
think
is
a
viable
way
might
be
true
to
test
at
least
is
to
figure
out
which
defining
characteristics.
We
need
below
a
feed
identifier,
maybe
a
sequence
number,
maybe
a
version,
maybe
other
things,
and
that
an
issuer
can
put
into
this
registration
for
and
then
move
from
there.
G
G
Unfortunately,
not
so
I'm,
I'm,
I
think
it's
in
the
architecture.
I
also
think
it's
not
expressed
very
so
the
editors
are
fixing
that
so
tomorrow,
they've
been
added
to
this
meeting
and
I
think
then
we
can
assess
what
the
phrase
looks
like
yeah
tomorrow
and
and
from
there.
I
can
take
on
the
task
to
write
that
up
and
push
it
to
the
email
list
as
a
proposer,
and
then
we
have
to
find
out
what
might
be
needed.
G
Maybe
there's
nothing
else
in
a
sequence
number
you
know,
I
don't
know,
and
maybe
we
have
to
go
through
certain
example
sets
and
I
highlighted
it
before
it
might
be
useful
to
create
a
a
reference
example
set
of
statements
about
software
supply
chain.
In
order
to
then
come
up
with
some
of
these
items,
that's
an
issue
wants
to
put
into
this
registration.
For,
but
again
that's
very
preliminary
and
I
would
not
know
what
the
what
is
there
and
how
it
would
be
phrased.
C
C
It
comes
from
the
sort
of
the
the
constant
discussion
about
whether
or
not
skit
is
useful
for
a
whole
application.
And
of
course
you
know
it's
not
supposed
to
be
an
application,
and
it's
not
supposed
to
be
an
instance
of
a
service,
but
you
do
have
to
be
able
to
build
services
off
it,
and
that
raises
the
questions
of
searching
and
so
on,
and
so
on.
C
The
architecture
does
already
say
what
a
feed
ID
is
or
a
feed
is
rather
than
a
feed
is
just
a
collection
of
statements
about
an
artifact.
Unfortunately,
it
doesn't
explain
what
an
artifact
might
be
and-
and
that's
where
you
get
into
this
ambiguation,
so
just
to
reinforce
one
of
the
things
that
I
said
a
moment
ago
in
a
slightly
different
context.
C
C
I
think
that's
good
enough
and
I.
Think
that's
the
place
that
that
we're
coming
to
here
is
that
we
can
support
the
software
supply
chain
in
that
way.
Without
imposing
any
unnecessary
sort
of
scope
creep
or
or
application
semantics
in
in
skid,
so
yeah
apologies
to
folks
like
like
Charlie
and
many
of
us
who
work
on
100
things
at
once.
C
H
So
yeah
I'm
next
on
the
Queue,
so
few
things
I
kind
of
agree
with
what
Hank
mentioned
is
we
need
to
provide
an
example
of
how
feet
can
be
utilized
and
how
it
can
look
like
in
some
way
in
the
document,
otherwise,
just
making
a
statement
that
it's
some
some
identity
regarding
the
artifact
is
something
and
another
point
I
wanted
to
mention
is
about
the
Steve
statement
is:
why
should
the
issuer
identity
be
part
of
the
feed?
I
am
feeling
to
understand
it.
H
Is
the
issuer
trying
to
identify
any
any
assertions
or
any
metadata
associated
with
an
artifact
with
some
kind
of
an
identifier
which
is
logically
increasing
and
any
data
Associated
to
an
artifact
being
pushed
into
the
skit
registry
be
identifiable
so
that
linkage
to
the
issue
or
identity?
Is
something
I'm
not
very
clear
about?
That's
what
I
wanted
to
say
that
yeah.
I
I
It
had
something
that
I
guess.
Others
are
now
also
wondering
about
about
the
feed
having
some
indication
in
the
in
the
name
of
the
feed
about
who
is
posting
statements
and
I.
Guess
my
concept
that
I
see
reflected
in
the
in
the
questions.
In
the
note
taking
is
surely
a
feed
is
going
to
have
the
ability
to
have
statements
from
multiple
issuers
about
you
know
an
artifact
a
product.
I
E
Yeah
Neil
sorry,
my
comment
was
I,
read
the
thread
from
and
was
leading
up
to,
117
on
the
whole
company
identifier
conversation
so
I
pasted
in
the
chat
here,
but
I
will
reply
to
the
email
thread
with
it
and
we'll
use
that
for
because
I
totally
appreciate
that
it
there's
a
few
people,
there's
several
people
that
are
not
on
the
slack
and
that's
totally
fine.
The
mailing
list
is
the
appropriate
place,
so
I'll
respond
there,
I
pasted
it
here
for
if
that
helps
but
I.
E
B
Amen
thanks
yeah
excuse
me,
I
have
just
one
other
thing:
I
wanted
to
talk
about
briefly
on
this
topic,
and
that
is
the
the
larger
issue
of
searchability,
and
you
know,
indexing
and
query
capabilities
of
of
many
kinds
is
sort
of
orthogonal
to
a
log.
I
mean
you
can
search
the
log
but
pretty
much
your
grepping
at
that
point
right,
especially
if
we're
talking
about
sort
of
a
blockchain
structure,
it
becomes
I,
think
quite
heavyweight.
B
So
we
should
really
consider
that
carefully
what
we
want
to
do
there,
and
maybe
there's
you
know-
maybe
it's
an
informational
database
that
goes
along
with
skit
that
can
be
done.
It
can
be
used
for
those
utilities,
but
I
think
skid
as
it
stands.
Right
now
is
going
to
be
it's
going
to
groan
under
the
weight
of
query
loads
in
an.
A
Yeah
I
I,
raised
plant,
so
I
I.
Think
one
of
the
main
issues
that
where
this
feat
topic
came
into
the
picture
as
John
mentioned,
was
really
related
to
the
the
need
to
search
through
that
database
and
and
I.
Think
that's
because
that
there's
one
entity
or
several
issuers
putting
something
to
the
skit
registry.
And
then
there
are
other
entities
trying
to
get
some
information
out
of
it.
If
there's
no
searchable
function
or
as
Charlie
put
it,
there's
a
separate
database
to
search
for
something
I.
A
Think
then
the
the
issue
or
challenge
is
kind
of
mitigated
to
a
certain
extent
but
and
I
think
as
a
the
history.
Why
that
topic
surfaced
was
a
little
bit
triggered
by
the
debate
about
the
key
trends
because
they
had
specifically
added
an
extra
feature
to
make
their
database
searchable
and
they
have
a
I
forgot.
H
D
Thank
you
yogash,
so
I
just
want
to
comment
about
the
company
ID
information
and
product
identification.
There
was
a
lot
of
discussion
that
went
down
in
the
ntia
when
we
were
developing
the
s-spons
spec
standards.
I
should
say
the
framework
about
about
this
very
concept
and
a
couple
of
things.
I
think
we
settled
on
understanding
or
believing.
If
you
will
is
that
you
know
number
one.
A
a
company,
a
company
that
creates
software
is
the
sole
owner
or
the
decider.
D
If
you
will
of
what
to
name
those
products
and
are
they
also
are
the
sole
entity
that
can
decide
what
versioning
information
it
goes
with
those
so
the
you
know
so
so
those
those
two
portions
of
pieces
of
naming
are
pretty
much
already
determined
by
the
parties
that
create
software.
So
one
area
that
was
definitely
needed.
D
For
example,
DNS
as
a
one
way
to
register
a
company
using
it's
a
you
know,
DNS
registration
and
the
other
was
a
potentially
use
things
like
mail
to
as
a
way
to
identify
specific
individuals
who
could
be
also
could
also
be
supplying
products
so
that
that's
just
one
of
the
one
of
the
findings,
I
think
that's
worth
keeping
in
mind
here.
Is
the
company
identifiers
need
to
be
unique,
but
companies
make
the
decisions
to
name
products
and
assign
version
numbers
thanks.
H
G
E
Thanks
dick
it,
so
it
was
actually
a
lot
of
your
feedback
and
others
that,
in
the
thread
that
I
was
reading,
that
really
helped
me
resonate
this
little
more,
at
least
in
my
head.
When
I
look
at
the
way
we've
been
discussing
the
conceptual
structure,
let
me
just
paste
the
link
to
it.
Where
you've
got.
You
know
the
feed,
ID,
sorry,
Dr,
vid,
an
identity
makes
a
statement
read
statement
instead
of
claim
there
about
an
artifact
I
think
that's
teasing
out
exactly
what
you're.
E
Looking
for
what
I
saw
in
that
discussion
was
a
little
bit
of
maybe
trying
to
group
too
much
the
identity
into
the
feed,
as
opposed
to
a
feed,
is
created
by
an
identity.
So
if
we
can
use
that
same
structure,
then
whatever
we
decide,
whatever
that
particular
instance
uses
to
use
as
identity
is
totally
fine
in
other
discussions-
and
this
has
been
a
while
back-
we've
been
having
these
discussions
around.
What
exactly
is
the
way
identity
is
represented.
Is
it
x509
is
a
gpg?
Is
it
an
email?
E
Is
it
did
and
basically
what
I-
and
this
is
why
I'm
trying
to
tease
them
out
as
two
separate
topics
is
if
we
can
separate
how
we're
using
identity,
meaning
identities,
there's
different
identity
types
and
they're
associated
with
a
statement
through
the
Cozy
header,
then
the
the
envelope,
then
it.
If
we
use
that
same
model
to
define
a
feed,
then
we
don't
need
to
put
the
identity
into
the
feed,
because
we've
already
said
we
have
a
way
of
defining
identity.
E
D
Yeah,
that's
a
really
good
point,
Steve
and
and
I
think
we
we
also
know
I.
Think
it's
intuitive
really
is
that
you
know
these
identities
need
to
be
managed.
They
need
to
be
unique,
so
we
need
to
leverage,
you
know
whatever
we
can,
and
in
this
case
the
DNS
system
is
is
is
already
maintaining
this
level
of
uniqueness
for
identities
and
the
emails
addresses
are
doing
essentially
the
same
thing
with
the
mail
twos
and
each
you
know,
male
Hub
will
sort
of,
of
course,
assign
email
addresses,
so
those
two
could
be
leveraged.
H
Thanks
I
have
a
point
that
the
feed
is
much
more
than
the
company
identity,
because
it
is
about
company,
maybe
company,
as
the
top
level,
then
a
particular
product
and
then
a
product
and
a
particular
revision
of
the
product.
So
you
could
have
statements
or
associated
with
a
particular
product
and
a
particular
revision
of
the
product
so
and
different
organizations
may
want
to
kind
of
give
identities
for
their
deliverables
or
artifacts,
so
to
speak.
H
F
B
With
the
danger
in
defining
too
many
different
ways
of
going
about
this,
and
if
you
simply
have
you
know
some,
you
know
a
random
identifier
that
is
definable
by
the
feeder
or
the
sort
of
the
administrator
of
the
feed.
That
is
probably
good
enough,
and
if
you
go
beyond
that,
I
think
we're
starting
to
get
into
some
serious
complexities,
but
just
might
without
reading
the
you
know,
the
feed
stuff,
hopefully,
which
will
be
along
later
today
or
whenever
it's
hard
to
progress
it
up.
B
But
I
haven't
done
that
part
that
I
wanted
to
make
as
well,
and
that
is
on
the
mailing
list
topic
from
this
morning
and
over
the
weekend
we
talked
about
the
definition
of
attestation
and
the
I.
You
know
this
I
haven't
really
been
following
this
too
closely
honestly
on
this,
but
the
flavor
of
attestation,
now
in
use
in
regulations
in
the
United
States,
is
that
it
is
that
letter
that
says
here's.
B
My
here's,
my
assertion
of
some
qualities-
and
you
know
it
is
from
me
so
therefore
it
should
be
trusted.
There
isn't
really
any
requirement
for
authentication
in
there,
and
so
my
proposal
is
that
we
actually
say
digitally
authenticated
attestation
when
we
mean
that,
rather
than
just
using
the
shorter
term
attestation
that
would
solve
the
problem.
I.
Think
of
the
confusion
that
nist
has
created
for
itself.
G
Yeah
hi
Charlie
yeah,
thanks
for
bringing
that
up.
Of
course,
quick
Deep
dive,
there's
a
lot
of
baggage
here.
So
this
is
about
25
years
too
late
to
Hawk
that,
unfortunately,
so
the
yeah
we
can't
ignore,
what's
already
out
there
by
trusted.
Computing
groups,
Fidos
Global
platforms,
Etc
and
now,
including
iitf
with
rats
and
I,
think
a
concise
qualified
term
that
is
not
just
education
is
good.
F
But
that's
that's.
Certainly
what
it
looks
like
is
going
to
be
the
best
approach,
because
there
is
some
movement
to
change
right
now
and
fix
some
other
things
from
x509
that'll
be
a
smart
way
to
go.
The
the
feed
thing
you
know
really
wasn't
part
of
the
initial
discussion
and
I
know
it's
a
handy
little
word,
but
I
don't
even
know
if,
if.
F
F
I
think
that
if
we
had
the
product
semantically
defined
like
for
software,
there's
a
name
there's
a
revision,
there's
something
you
know
that
we
go
by
at
some
point:
it
has
to
come
back
to
a
human
being
semantic
label
to
things
so
that
we
can
match
it
up.
It
can't
be
a
hash
okay,
so
it
has
to
be
something
that
we
can
look
at
and
understand
what
it
is
and
then
for
different
Supply
chains,
though
those
might
be
very,
very
different
kinds
of
things:
you're
not
going
to
have
the
same.
F
You
put
in
the
issuer,
you
make
a
statement
and
then
and
then
up
a
level
if
you
will
in
the
API
is
where
we
can
deal
with
saying:
okay,
look
for
software,
we're
going
to
have
the
name
of
the
package,
the
revision
code
and
so
forth
and
say:
here's
how
we're
going
to
have
a
semantic
name
for
what
software
is.
Perhaps
anyway,.
D
F
D
D
A
H
A
That
is
obviously
in
a
product,
but
not
necessarily
in
a
in
as
part
of
skit,
because
the
benefit
such
approach
has
is
that
we
don't
need
to
go
into
the
details
of
of
what
the
the
index
is
to
do
the
lookup
and
so
because,
then,
you
could
search
essentially
for
anything
you
like
in
in
key
trans
case,
because
it's
a
very
specific
application.
It's
a
little.
They
have
the
advantage
that
they
from
the
start
want
to
store
a
username
to
public
key
binding.
So
they
look
up.
A
The
search
is
basically
given
as
a
that's
the
username,
but
we
are.
We
have
a
little
bit
of
more
quite
I,
think
we
have
a
more
complicated
scenario,
and
so,
if
we
kind
of
acknowledge
that
this
is
application,
specific,
as
as
Ray
was
saying,
like
different
Supply
chains,
may
have
different
sort
of
ways
to
identify
the
artifacts
and
whatever
they
have
in
there.
Then
we
can
sort
of
like
point
this
out
and
basically
toss
it
to
the
application
or
do
a
profile
that
of
that
application.
E
Yeah
so
I'm
making
the
queue
so
I'll
just
jump
in
so
I
totally
agree.
This
has
been
one
of
the
conversations
we've
also
been
thinking
about
is:
where
is
the
skit
layer
and
where
is
the
application
specific
layer,
because
we
see
skit
being
used
in
multiple
scenarios?
We're
focused
on
software
supply
chain
as
the
initial
scope,
but
where?
Where
else
can
it
be
used?
The?
E
So
that's
that
makes
a
lot
of
sense
on
the
purpose
of
a
feed
ID
if
I
go
back
to
what
Antoine
and
Cedric
were
kind
of
pointing
at
and
what's
in
the
document
in
the
architecture
document
is
the
ability
to
group
a
collection
of
statements
on
a
on
a
thing.
So
the
question
we've
been
discussing
and
and
I've
found
the
issue.
I
put
it
in
the
notes
there.
As
clarification,
what
a
feed
ID
is
is
how
do
you
group
a
collection
of
things
and
I?
E
Think
that's
the
piece
that
we've
been
trying
to
balance
is
how
prescriptive
should
that
structure
be
including
version
and
architecture
was
one
of
the
things
I
was
discussing
last
week
and
I'm
now
in
the
pendulum
swing
of
pivoting
back
to
should
a
feed,
ID
and
just
be
a
a
unique
string,
an
identity
creates
it,
and
in
that
is
a
set
of
name
value
pairs
that
could
have
platform
architecture
version.
It
could
have
gleef
ID
if
I'm
pronouncing
it
right
and
all
the
other
types
of
IDs.
E
What
I
think
the
root
thing
we're
trying
to
address
here
is:
how
does
a
skid
instance
represent
a
set
of
a
collection
of
statements
on
a
thing
and
can
evolve
over
time
a
time
being
the
time
timestamp
of
the
capture
signature
putting
on
the
envelope
and
then
because
that
information
is,
is
structured
and
there's
different
content
types.
Application
layers
can
choose
how
much
they
index
into
that
and
make
sense
of
for
what
their
for
the
scenario
they're
trying
to
solve.
E
I
Hi
thanks:
this
is
slowly
coales,
saying
I,
appreciate
it.
I
I
just
wanted
to
quickly
talk
about
the
nursing
of
identities
and
quote-unquote
companies,
I,
don't
think
I.
So
dick
talked
about
identities
being
unique.
That's
a
good
idea,
but
verifiable
I,
I,
think
verifiable
and,
and
the
notion
that
there
are
only
companies
is,
is
too
restrictive,
and
so
what
they
need
is
some
sort
of
I'll
call.
It
cryptographic,
coherence
or
something
I
mean
there
needs
to
be
a
way
for
an
identity,
to
establish
a
reputation
and
continue.
I
You
know
proving
that
it's
who
it
started
off
being
and
others
can
comment
on
it
and
refer
to
it.
So
I,
you
know
I,
just
don't
want
us
to
lock
us
lock
us
into
companies
are
the
only
things
that
can
make
statements
and
you
have
to
find
them
in
Dunn,
Brad's,
Creed
or
whatever,
and
certainly
I
I
love
Steve's
comment
that
you're
a
registration
policy
could
say
we're
only
going
to
deal
with
people
that
we
can
find
in.
I
You
know
some
other
external
database
and
then
I
just
wanted
to
come
back
to
this
notion,
which
is
raised
in
the
chat
and
or
in
the
notes
and
I'm,
not
sure.
If
we've
pinned
it
down,
it
seems
very
critical
to
me
to
well
I
I,
think,
multiple
entities,
actors,
issuers
or
whatever
need
to
be
able
to
show
up
in
a
certain
feed.
So
the
feed
isn't
uniquely
identified
by
you,
know
the
identity
of
of
the
statement.
B
C
Yeah,
so
so,
just
to
jump
in
I
wrote
that
note
and
I
wrote
it
specifically
to
agree
with
you.
Two
there
are.
There
are
implications
of
some
of
the
technical
chat.
That's
been
happening.
That
would
stick
it
to
one
person
and
I.
Think
that's
a
bad
thing
to
restrict
to
so
I
think
we're
all
if,
if
only
one
thing
comes
out
of
that
this
meeting
we're
agreed
on
that
one.
Thank
you.
Thank
you.
So
much.
A
H
D
D
We
didn't
limit
it
to
just
companies
because
there's
a
ton
of
Open
Source
software,
that's
been
written
by
individuals,
and
so
they
need
to
have
unique
identifiers
as
well,
and
so
the
concept
between
behind
identification
was
not.
You
know,
strictly
limited
to
being
companies,
but
being
companies
or
email
addresses
that
could
be
used
to
represent
Unique
Individuals
and
those
are
verifiables
you,
as
you
know
that
you
could,
you
know,
send
an
email
to
to
an
address,
and
if
it's
not
valid,
it
gets
bounced.
So
you
know
you
you.
D
H
Hi
I
know
this
is
slightly
off
topic,
but
we
are
coming
close
to
the
hour,
so
I
think
we
last
last
Monday.
We
had
agreed
to
kind
of
resolve
the
pull
requests
open,
but
I
just
checked
this
still.
The
pull
request
opened
from
Hannah's.
So
are
we
going
to
progress
this
and
discuss
this
during
this
remainder
of
the
meeting
or
what
is
the
state
has?
Maybe
you
can
check
some
light
little
later.
A
In
the
risk
of
jumping
the
queue
Steve
yeah,
the
so
the
one
of
the
issues
was
that
there
was
this
other
PR
that
was
accepted,
and
so
it
created
some
merge
conflicts
which
need
to
be
resolved
first,
because
the
I
think
Antoine's
or
Cedric's
pull
request
made
changes
throughout
the
whole
document.
So
that's
something
to
to
be
done.
E
E
You
know
then
questionable
so
I
think
we
need
to
figure
out
how
to
entity
an
identity
of
an
entity
is
not
meant
to
be
limiting
to
any
particular
type
A.
When
we
think
about
the
registration
policies,
I've
heard
us
talk
about
the
ability
of
a
registration
policy
can
choose
who
it
accepts
and
to
and
I'm
sorry
I've
lost
track
of
who
brought
this
up
by
Kim,
Rose,
Charlie
or
Neil.
That
a
skid
instance
can
choose
to
accept
input
from
lots
of
entities,
so
a
particular
company
might
say
I,
don't
accept.
E
You
can
host
their
information
around
a
particular
product
on
your
skid
instance
and
that's
totally
valuable,
if
you
think
of
security
companies,
they
make
they
make
information
available
where
they
rate
a
quality
of
another
company
right.
That's
what
all
security
scanners
do
that's
a
valid
scenario.
E
If
a
company
you
know,
let's
just
at
Microsoft,
run
that's
drivers,
for
instance,
and
unfortunately,
Roy
was
traveling
today,
so
I
should
bring
it
up
when
he's
here,
but
they
they,
let
others
put
information
around
Microsoft
drivers
on
the
Microsoft
feeds,
so
those
are
valid
scenarios
but
I
think
it's
really
just
up
to
whoever
is
hosting
that
feed
to
decide
who
I
said.
I
said
feed
sorry
feed
in
the
generic
sense,
not
the
feed
ID.
E
We'll
talk
about
here
that
there
is
a
service
that
elicits
information,
provides
information
and
it's
up
to
that
service
host
to
decide
who
can
put
information
on
it.
The
thing
that
makes
why
feed
ideas,
important
is
if
the
scenarios
I've
been
using
with
rabbit
networks
being
the
producer
and
acne
Rockets
being
a
consumer.
E
The
last
one
I
started
playing
with
is
Cosmic
security
as
a
security
company
that
makes
statements
the
way
Cosmic
security
can
make
comments
or
the
of
statements
of
quality
Around.
The
Net
monitor
software
from
the
wabat
networks
company
is
the
feed
ID,
that's
the
correlation
between
those
so
I.
That's
why
I
think
feed
ID
is
important,
not
just
because
I
can
make
a
stream
of
updates
on
a
particular
skid
instance,
but
another
skid
instance
can
make
statements
of
quality
on
an
artifact
that
somebody
else
produces
so,
but
I
totally
also
recognize.
F
Thanks
what
I
know
we're
getting
close
to
the
end,
but
I
guess
he
just
brought
something
up
that
I
thought
was
a
maybe
a
good
idea,
and
that
is,
it
might
be
useful
to
use
the
same
architecture
that
they
use
with
the
did
web,
where
they
have
another
document
that
defines
the
feed.
If
you
will
and
then
that
would
be
included
in
the
skit
instance
as
another
reference
so
inside
this
then
by
instance,
I
mean
statement
or
or
submission,
so
the
header
would
be
the
I
guess.