►
From YouTube: IETF-SCITT-20230703-1500
Description
SCITT meeting session at IETF
2023/07/03 1500
https://datatracker.ietf.org/meeting//proceedings/
A
C
D
A
D
Yeah,
when
I
reached
out
to
Jessica
Wilkerson,
really
just
looking
for
validation
of
what
we
were
thinking
about
for
hackathon
was
even
you
know,
practical
in
regard
to
what
they're
you
know,
they're
trying
to
do
with
their
new
rules,
and
that's
all
I'm,
really
hoping
we
can
do
is
get
some
sense.
That's
out
or
validation
that
we're,
at
least
in
all
partners.
D
A
A
D
B
Absolutely
so
I'm
a
co-founder
of
gosh,
which,
which
is
a
project
that
doing
concentrating
on
securing
software
supply
chain.
Among
other
few
things
beforehand,
I
was
a
CTO
and
Chief
Architect
of
everscale
blockchain,
where
I
worked
on
like
node
development,
consensus
protocol
research
and
some
other
things
beforehand.
I
was
working
on
ethereum
blockchain,
mostly
like
several
projects
and
basically
I
go
like
25
years,
25
years
back
in
the
started
from
voiceover
it
back
in
2000
and
what
it
was
five.
B
A
Yeah
thanks
a
lot
yeah
Steve,
who
doesn't
seem
to
be
on
the
call
today
yet
introduced
to
each
other
because
of
your
company.
So
it's
always
good
to
know
like
all
the
different
parties
sort
of
working
on
this
supply
chain,
security
topic,
essentially
good
I,
don't
know
how
familiar
you
are
with
the
meet
Echo
and
with
the
ietf
process,
happy
to
sort
of
give
you
a
separate
intro
into
that.
B
A
A
Think
so
we'll
talk
about
attack,
Upton
stuff,
and
then
we
should
maybe
conclude
with
the
key
trends
working
group
formation
and
see
what
a
conversation
status
is,
as
they
are
currently
doing,
going
through
an
approval
process
of
the
chart
that
yeah
I
hope.
We
will
manage
to
go
through
these
three
items.
A
A
G
G
A
A
G
G
The
security
guarantees
that
they
might
offer
and
even
sort
of
application
layer
stuff
like
feed
integrity
and
and
how
you
can
restrict
things
like
who
can
write
to
a
software
package
as
opposed
to
who
can
write
to
a
skit
artifact
which
are
all
starting
to
get
very
sort
of
tentacally
in
terms
of
their
technical
implications.
So
I've
been
through
the
spec
in
all
the
places
where
registration
policies
and
feeds
are
defined
and
and
used
and
I
haven't
quite
got
as
far
as
making
a
PR
for
it.
G
Yet,
although
I'm
close,
but
the
sort
of
issues
that
I
I
came
to
that
have
slowed
me
down
a
bit,
is
that
actually,
if
you
look
at
the
definitions
of
feed
and
registration
policy
on
their
own
they're,
pretty
close
to
what
we've
been
discussing
so
question
marks
over
violating
the
application
layer,
I
think
are
actually
easy
to
deal
with.
We
don't
questions
over
whether
we
understand
the
semantic
value
of
the
payloads.
G
According
to
desires
of
of
what
people
wanted,
we
just
need
to
clean
up
the
side,
references
so
a
few
bits
where
John
I'll
make
a
few
statements
and
then
see
if
anybody
has
comments
or
questions
on
them.
But
the
place
is
in
the
core
specification
or
definitions
of
these
things
that
are
still
a
bit
tricky
is
that
we
do
have
this
I
think
not
quite
finished
idea
of
having
sort
of
two-sided
registration
policies.
G
So
there's
something
that
looks
a
lot
like
the
server
imposing
Access
Control,
but
there's
also
another
dimension
to
that
which
is
not
the
sort
of
standard,
obvious
access
control,
but
also
things
like.
Don't
register
this.
If
it's
more
than
a
week
old
or
don't
don't
register
this,
if
it
is
sequentially
earlier
than
something
I
already
know,
I
don't
personally
have
an
issue
with
those
things
being
possible,
but
they
do
make
it
more
complicated
the
place
where
I
think
it
it
does
need
to
be
really
simplified.
A
But
before
you
go
there,
I
just
for
the
for
the
new
participants,
I
I,
hope
everyone
saw
that
I
posted
two
links
into
the
chat
window.
One
was
to
the
architecture
document,
which
is
what
John
was
talking
about,
and
the
other
one
is
the
link
to
the
meeting
minutes,
which
is
also
in
the
panel
at
the
top
and
John
posted
some
text
with
what
he
has
just
been
talking
about
into
that
into
the
meeting
minutes.
A
F
I
F
Some
of
the
intent
that
I
think
are
possibly
leading
to
some
confusion
in
the
community,
so
so
I
I
think
we.
We
all
agree
that
we
don't
want
any.
We
want
to
be
very
selective
as
to
what
other
certain
policies
we
make
a
normative,
so
we
don't
want
to
put
too
much
pressure
there
and
I.
Think
right
now
we
have
a
monetary
registration
policies
about
checking
the
signature
and
shaking
that
right.
F
Entity
makes
sense,
and
even
that
is
going
to
depend
on
the
on
the
DI
method
and
so
I
think
these
are
important
and
we
don't
need
to
request
to
make
many
more
registration
policies.
Monetary
at
the
same
time,
I
think
that
in
almost
earlier
a
practical
use
of
a
skit
for
given
a
siblachen,
there
will
be
a
meaningful
registration
policies
and
that
being
able
to
declare
an
enforcement
policies
is
essential,
and
so
because
we
think
it's
going
to
be.
F
Explain
that
it's
important
and
give
some
meaningful
examples
of
policies
we
may
apply,
but
not
not
normative
than
that.
So
one
of
the
other
thing
that
was
discussed
at
length
in
the
discussion
or
discussion
policies
and
that
made
the
expansion
of
the
human
right
thing
is
that
right
now
we
are
trying
to
avoid
putting
too
much
pressure
on
implementations,
because
some
registration
policies
require
keeping
some
auxiliary
state
or
using
more
resources
and
that's
an
even
stronger
reason
not
to
make
them
mandatory.
But
as
an
example.
F
If
you
want
to
check
for
her
secure
version
numbers
for
example,
then
you
need
to
be
able
to
fetch
what
was
the
at
the
constances.
That
is
what
was
the
last,
the
actual
number
that
was
registered
and
that's
usual,
but
that's
also
quite
hard
to
implement
at
scale.
So
so
that's
another
reason
why
we
want
to
provide
examples,
but
we
don't
want
to
be
Innovative,
because
some
things
are
can
be
quite
hard
to
implement
in
in
some
settings.
F
Regarding
the
what
the
client
does
I
think
the
the
one
provision
we
have
is
that
there
is
a
registration
info
header
that
is
meant
to
provide
the
input
to
the
registration
policies
and
again
we
don't.
We
should
not
see
that
as
demands
or
request
that
the
client
is
making
that's
more
like
providing
input
for
the
registration
policies
that
may
be
specifically
and
so
on.
So
it's
a
place
to
play
to
pass
arguments
rather
than
I
think
a
way
to
control
what
the
policies
are
going
to
do,
although
it
can
be
used
for
that.
F
G
I
want
to
clean
up
a
bunch
of
the
sections
that
are
giving
these
examples,
because
it's
good
in
a
way
that
the
text
is
not
normative,
but
it's
still
text
that's
present
and
it
it
can
be
confusing.
So
I
think
I'll,
I'll
I
agree
with
everything
you
said,
I
think
on.
As
long
as
the
registration
info
header
is
considered
to
be
not
security
relevant
as
you
know.
Obviously
it's
it.
G
It
comes
from
a
known
person
and
you
can
believe
that
they
said
it
that
otherwise,
you
know
if
we
have
a
one-sided
security
protocol,
there
I'm
happy
with
everything
else
and
I.
Think
I
just
want
to
make
those
examples,
make
it
very
clear
that
that's
that's
what
we're
doing
otherwise.
Otherwise
that
sounds
good.
F
G
F
G
H
So
that,
where
I'm
hung
up
here,
John
is
that
the
configuration
for
the
transparency
service
for
types
of
identity
that
it
will
generate
a
receipt
for
is
the
under
the
control
of
transparency
service
itself.
The
air
back
in
storage
and
everything
else
that
might
be
surrounding
this
is
secondary
to
my
concern.
In
fact,
I.
Don't
even
think
it
belongs
in
this
conversation,
isn't
just
I
don't
understand
how
to
represent
the
identity,
configuration
for
the
transparency
service
and
how
it
changes,
and
how
do
we
track
that
and
I
didn't
quite
get
that
from
your
text.
G
No,
it
was
a
it's
it's
not
a
bit.
I've
been
looking
at,
because
I
was
hoping
to
sort
of
remove
a
lot
of
the
need
for
that.
You
know.
There's
a
there's
a
whole
other
thing
to
look
at
which
I
don't
think
I
want
to
sort
of
pick
up
today,
but
just
to
say
well,
I
didn't
pick
it
up
in
the
last
review,
which
is
to
Define
whether
or
not
and
I
would
suggest
not.
H
G
H
But
what
I
don't
understand
is
how
to
track
whether
an
existing
service,
configures,
a
Sig
store
provider
and
then
a
did
web
provider
a
week
later,
how
we
understand,
or
how
do
we
un
rationalize
over
the
receipts
generated
based
on
time
specifically,
if
you
were
to
do
an
audit
in
a
federation
to
archivist,
let's
say
and
then
somebody
goes
and
changes
the
configuration
to
allow
different
identity
provider.
How
would
you
detect
that-
and
that's
always
been
my
why
I
focused
on
in
on
the
wording
here:
okay,.
G
Gotcha
so
I'm
glad
you
made
that
last
point,
because
I
was
about
to
go
down
a
long
sort
of
zero
trust
certificate,
transparency,
kind
of
wrote.
So
the
way
with
my
chair
off
for
a
second.
The
way
we
deal
with
that
in
in
archivist
is
that
every
feed
includes
signed
statements
from
the
platform
with
an
inclusion
proof
and
a
cryptographic
proof
of
the
new
cryptographic
group
that
has
been
provided
created
for
the
access
control
management
of
that
particular
feed.
G
But
fundamentally,
if
you're
reconstructing
from
the
Merkle
tree
inclusion
proofs
that
that's
the
audit
and
the
the
complete
history
that
you
get
so
that
that's
the
sort
of
system
level
solution
that
that
we
chose
I,
don't
know
if
we
need
to
go
into
the
depths
of
specifying
that
as
the
way
to
do
it.
But
I
mentioned
that
largely
to
to
observe
that
it
is
possible
to
do
that
on
top
of
the
building
blocks.
That
skit
specifies.
H
G
This
might
be
a
thing
we
need
to
take
to
a
more
detailed
offline
conversation,
because
I
think
the
change
that
you're
suggesting
it
would
depend
on
how
the
enrollment
of
a
user
and
the
chaining
up
of
their
issuer
identity.
This
actual
key
that
does
the
content-based
stuff
I
think
we
agreed
on
it
would
depend
how
that
is
enrolled
with
the
system
and
I'm,
not
sure
off.
The
top
of
my
head
I
could
come
up
with
a
complete
I
think
sometimes
it
would
matter,
and
sometimes
it
wouldn't.
This.
H
Is
this
is
exactly
the
whole
problem
space
where
you
you,
we
say:
hey
we're
not
going
to
care
about
this,
and
you
have
to
do
a
long-form
way
to
to
prove
the
identity
provider
or
you
just
validate
the
the
identity
of
the
transparency
service
and
say
hey.
It
proved
that
that
John
signed
this
not
looking
at
who
issued
or
what
method
John
was
used
to
generate
his
identity.
H
I
could
definitely
see
that
fast
path
being
used.
If
we're
saying
hey,
you
should
never
do
that
and
you
should
always
look
at
who
the
issuer
is.
On
top
of
that
means
every
single
endpoint
every
customer
needs
to
understand
the
same
root,
truss
or
configuration
policy
as
the
server,
and
that's
why
I
was
struggling
to
not
do
that
saying
hey
that.
Basically,
as
long
as
you
trust
the
transparency
service,
then
you
believe
that
the
configuration
for
the
system
is
the
Danny
for
John
or
Roy
was
exactly
there
and
that's
this.
H
A
G
H
A
But
I
think
I
think
we.
We
need
to
stay
sort
of
precise
on
on
the
specific
functions
because
we
we
otherwise
get
lost
in
the
in
the
function
as
we
currently
there's
no
text
in
there
how
federations
work
even
among
skate
servers,
let
alone
interoperability
into
other
ecosystems.
I
I
think
that
that's
a
a.
H
G
G
G
A
G
A
F
D
F
G
That
that
is
correct
and
the
own
the
the
details
we've
been
talking
through
and
again
to
sort
of
reference
Roy's
point.
My
understanding
of
it
is
just
to
make
sure
that,
where
things
are
referenced,
we
either
remove
that
reference,
which
allows
us
to
lean
on
this
very
simple
non-normative
approach
that
you're
talking
about
which
I
prefer
or
if
it's
really
hard
to
do
that.
D
Thank
you,
harness
yeah
I,
just
on
the
record
of
supporting
what
Roy
said
earlier,
that
we
really
just
need
to
trust
the
transparency
service
and
I
think
we
have
real
world
examples
of
how
this
works
today.
For
example,
land
records
which
are
registered
here
in
the
U.S
by
the
registrars
of
these
records
have
a
process
they
follow
and
when
I
go
to
land
records
registry
I
cross.
D
The
data
that
I
receive
so
I
think
trusting
the
data
in
the
registry
that
the
registry
contains
and
provides
is
the
way
to
go
and
I
also
believe
it's
up
to
us
to
define
the
correct
processes
and
procedures
in
skit
that
will
ensure
that
the
people
that
this
transparency
services
that
are
contain
these
registrations
are
locked
solid.
They
are,
they
are
impeccable
integrity
and
it's
a
process
and
protocols
that
we
create
will
ensure
that
thanks.
E
A
E
E
B
A
B
If,
for
example,
the
draft
will
say,
okay,
you
will
need
to
use
this
particular
Miracle
tree,
then
we
won't
be
able
to
Simply
comply
ever
so.
For
me,
this
is
like
very
important
topic
to
make
sure
at
least
that
it's
quite
open,
so
implementations
are
possible
and
zero.
One
architecture,
I
think,
provides
great
great
kind
of
framework
for
that,
thanks.
A
That's
good
to
hear
yeah,
you
definitely
so.
I
posted
the
link
into
the
chat
window,
but
we
have
been
talking
a
lot.
Then
there
have
been
changes
made
to
the
document,
but
I
would
say
that
they,
many
of
them
are
more
cosmetic,
like
readability,
etc,
etc,
not
fundamental
in
the
way
that
they
would
totally
change
the
the
way.
Zero
one
works
in
by
any
stretch
of
imagination,
so
I
think
you
should
be
fine,
but
please
double
check
in
and
Trace.
Those
points
immediately.
B
A
A
But
if
you
look
at
the
editors
copy,
that's
the
that's
called
kind
of
the
current
snapshot,
but
there
are
still
two
PRS
India
and
I
haven't
added
the
BR
of
the
discussion
that
we
just
had
a
minute
ago
about
the
registration
policies,
and
maybe
there
would
be
other
PRS
coming
this
week
as
we
are
sort
of
like
editorial
sort
of
fixes.
So
I
saw
because
there
are
still
a
few
glitches
in
the
in
the
document
like
so.
A
A
E
Just
had
one
sort
of
detail
that
I
found
where
the
the
term
feed
is
defined,
to
mean
the
issuer's
name
for
the
artifact,
and
is
that
right,
I
mean
it's
or
is
that
some
sort
of
a
because
feed
to
me
doesn't
normally
mean
that?
But
maybe
within
this
this
realm
of
technology,
it
does
is
a
feed.
To
me
would
I
would
think
would
mean
something
that
you
tap
onto
when
you
start
watching
all
kinds
of
stuff
coming
through,
instead
of
just
a
name
for
one
artifact.
This
is
the
question.
A
E
E
Also,
and
so
on
on
section
6.1,
it
goes
through
all
signed
statements
must
include
the
following
protected
headers
and
one
of
them
is
called
the
feed
and
it's
a
third
one
down,
and
it
says
the
issuer's
name
for
the
artifact
is
a
string.
So
maybe-
and
it
does
but
I
hear
in
the
conversation
here-
people
talking
about
the
feed
and
I
was
understanding
that
you
could
have.
Maybe
several
people
subscribe
to
the
feed
off
of
the
off
of
the.
I
Okay,
so
the
the
feed
is
a
a
a
topic.
You
could
relate
it
to
a
topic
of
a.
What
would
typically
is
done
with
brokering
subscription
published
models,
the
pub
sub
models,
so
the
the
feed
here
is
about
a
product,
and
we
acknowledge
the
fact
that
just
a
name
for
a
feed
might
not
be
enough
that
there
might
be
a
hierarchy
here,
so
to
speak.
I
E
I
It
means
yes,
yes,
it's
Associated
information.
Of
course,
easiest
scenario
is
I,
have
a
distinguishable
piece
of
software
that
I,
maintain
and
I
post
sorry
register
statements
about
that
software,
but
you
could
also
have
standard
subtopics
that
every
piece
of
software
comes
with
vdrs
with
they
mean
that's
true
to
take
Optics
use
case
or
would
come
up
with
with
this
updates
versus
patches
versus
duplication
or
something
statements,
and
so
there
might
be
specific
feeds
and-
and
we
have
to
agree
on
a
certain
structure
here,
but
for
now.
I
Yes,
it
is
a
next
iteration
problem,
so
to
speak.
We
will
keep
it
simple
for
now
on
the
feed
level,
but
but
expect
that
we
have
to
bring
the
topic
up
again
and
make
it
a
little
bit
more
complex
same
goes
with
the
registration
policies,
I
think
always
in
line.
So
I
will
not
talk
about
that
too
much.
But
there's
there's
issuers
May
register
things.
That
is
the
minimal
viable
registration
policies
is
to
restrict
issuers.
I
Of
course,
I
think
that
is
a
must
for
the
core
API,
but
then
also
we
might
want
to
restrict
they
did
methods
here
and,
and
that
is
by
the
way
why
it
was
at
some
point.
You
said
it
was
just
a
string-
the
issue,
because
we're
using
the
did
method
here
and
and
I
think
every
year,
the
flow
for
Ori
to
elaborate
on
that,
hopefully,
in
contributing
what
he's
going
to
say.
I
J
Yep
I,
basically
was
going
to
say
all
the
things
that
Hank
said.
I
think
you
know
the
important
thing
to
keep
in
mind
here
is
there's
different
ways
to
look
at
this
ecosystem.
You
can
look
at
it
from
the
perspective
of
the
transparency
service
and
The
Operators
of
the
service.
The
first
question
that
they
have
is,
who
is
allowed
to
send
me
sign
statements
and
then
the
second
question
that
they
have
is:
are
there?
J
J
That's
great.
Each
of
them
might
have
a
different
feed
that
they're
commenting
on
or
they
might
both
be
interested
in
making
comments
about
the
same
fee
and
my
policy
as
a
transparency
service
is
what
determines
whether
I
accept
that
so,
for
example,
I
could
have
a
policy
that
says
this
issue
is
only
allowed
to
talk
about
fish.
This
issue
is
only
allowed
to
talk
about
beef
or
I
might
have
a
policy
that
says
these
issuers
are
allowed
to
talk
about
fish
or
beef,
but
only
when
they
use
these
keys.
J
C
H
H
C
J
Clarity,
I'll
jump
to
the
the
front
of
the
queue
to
try
and
answer.
So
the
feed
is
just
one
part
of
the
solution.
The
registration
policy
is,
it
could
be
complicated.
The
simplest
version
just
says
these
are
the
issuers
that
I'll
Trust
to
accept
sign
statements
from
and
and
that
by
itself
also
doesn't
really
fix
these
problems.
J
But
you
can
imagine
you
know
the
seafood
industry
might
have
a
whole
set
of
shared
policies
that
add
on
to
the
registration
policy
that
protect
their
specific
business
scenarios,
like
you
know,
never
accepting
a
temperature
sensor,
you
know
from
Cold
Storage,
you
know
vessel
if
it's
outside
of
a
certain
range,
because
it
would
represent
some
liability,
like
that's
very
specific,
to
the
kind
of
information
that
provider
might
want
to
be.
Anchoring
and
policies
will
work
for
that,
but
it
might
not
be
policies
we
would
discuss
here.
H
J
H
So,
let's
be
really
crisp!
So
when
the
software
supply
chain
space,
we
have
s-bombs
that
we
have
to
build
a
tree
for
so
we
got
a
whole
bunch
of
s-bombs.
We
got
a
whole
bunch
of
of
vet
statements
and
cves
that
we
all
have
to
process
for
every
single
product
as
we
try
to
reference
it.
So
there's
multiple
things
coming
in
Flight
if
I
vetted
trust
with
a
transparent
Ledger.
How
do
I
detect
when
the
configuration
is
changed?
H
J
H
J
Changed
so
you're
saying
if
the
transparency
service
changed
the
allowed
issuers,
how
do
I
know
correct
right
and,
and
there
isn't
a
way
for
you
to
know
that
right
now
you
might
as
a
client
you
would
so.
The
thing
is,
the
transparency
service
is
always
going
to
be
giving
you
transparent
statements
that
are
from
it
and
it
might
have
like
today.
It
supported
these
guys
that
are
all
great,
but
tomorrow
they
lower
their
standards,
and
now
everyone
can
send
stuff.
The
signatures
are
still
going
to
come
from
the
transparency
service.
J
The
current
architecture
for
you
to
detect
anything
regarding
that,
because
the
trust
route
that
the
client,
the
consumer
of
the
software
or
the
consumer
of
the
transparent
statement,
that's
a
trust,
relationship
between
them
and
the
transparency
service,
and
there
isn't
a
way
to
sort
of
grade
the
transparency
service.
Based
on
what
we
have
today.
H
If,
if
you
look
it,
we
put
in
the
fact
that
we
wanted
the
identity
provider
path
to
be
discussed
as
part
of
this
working
group.
As
part
of
that,
we
have
to
think
through
what
it
means
for
the
receipts
that
we
generate
in
this
form.
So
that's
why
I
keep
harping
it
I.
You
know,
I
I,
understand
what
Rory
is
saying
about
the
different
verticals
and
the
and
the
specific
stuff.
But
when
it
comes
to
this,
the
weakening
of
the
transparency
service
scares
the
bejesus
out
of
me
here.
A
H
C
I
mean
I'll
just
jump
in
and
say
that
I
I'm
still
going
to
be
able
to
see
the
signatures
from
the
issuers
themselves,
so
the
the
consumer
might
see
a
broader
range
of
stuff
coming
through
her
feed,
but
the
consumer
I
don't
know
I.
In
my
mind
the
consumer
isn't
trusting
the
transparency
service
to
be
an
authority
on
whether
software
is
secure
or
whatever
it's
trusting.
The.
H
C
H
H
No
because
we
basically
are
forcing
and
distributing
trusted
Roots
down
to
everybody,
either
through
group
policy
or
through
Windows
update
or
through
some
other.
This
is
a
we're
trying
to
say
hey.
This
is
offloading
a
lot
of
that
problematic
if
you
trust
the
transparency
service
to
do
this
job
The
Knowing,
When,
Somebody,
Mis
reconfigured.
It
is
super
important.
H
A
H
A
D
Thank
you,
Johannes
yeah.
This
is
related
to
the
policy
and
the
issues
we're
discussing
right
now.
There's
a
debate
underway
inside
the
sisa
in
usdhs
on
software
identity,
how
to
express
or
how
to
identify
software
and
I
think
this
is
going
to
be
germane
to
our
registration
policies
as
well
is
that
we
need
to
have
a
unique
identifier
for
software.
D
If
we're
going
to
be
providing
software
supply
chain
artifacts
through
a
registry,
then
we
need
to
be
able
to
identify
the
specific
software
products
that
the
material
relates
to
so
I
think
we
may
need
to
address
the
need
for
a
agreed
standard
for
how
to
identify
software
products
within
a
registry.
Thanks.
A
Okay,
we
still
have
four
minutes
for
the
key
trends.
John.
Do
you
want
to
sort
of
summarize
a
little
bit
on
the
on
the
key
trends
discussion?
There's
currently
so
I,
don't
know
if
you
guys
are
on
the
keytrans
mailing
list,
but
there's
currently
a
call
for
what
is
actually
the
call
exactly
to
approve
the
the
chart
of
the
group
based
on
a
text
that
is
has
been
floating
around.
G
It
is
correct,
I'm,
not
the
best
place,
to
talk
about
this
necessarily
I,
think
Ori
and
dick
and
others
have
been
more
involved
this
this
week,
but
yeah
there's
a
birds
of
a
feather
on
the
Tuesday
of
itf117
and
ahead
of
that
they're.
Looking
to
get
statements
of
support
for
the
current
draft
of
the
of
the
spec.
A
Yeah,
but
it's
definitely
worthwhile
to
read
through
the
specification
I
think
already.
You
posted
it
to
the
mailing
list
to
the
skit
mailing
list
and
it
it's
interesting
in
a
sense
because
they
have
obviously
a
specific
problem.
They
want
to
solve,
like
the
storing
The
Binding
between
user
identities
and
the
public
keys,
and
they
also
have
some
specific.
J
A
I
Yeah,
this
is
saying
sorry
again:
I
have
to
put
off
something
like
yeah,
okay,
I
think
it's
very
important
that
we
do
not
create
parallel
structures
that
can
be
avoided
with
key
trends.
I
think
we
try
to
reach
out
a
few
times.
That
was
not
super
successful.
That
is
just
my
gut
feeling.
I,
don't
know
how
other
perceive
that
I
think
at
iitf
in
in
San
Francisco.
I
We
really
have
to
make
sure
to
find
debuff
performance,
Champions
on
site
and
such
and
and
or
key
proponents,
and
such
and
and
find
out
that
we
will
not
create
non-interoperable
parallel
structures
here.
That
would
be
the
only
thing
I'm
I'm
a
little
bit
unsure
about.
If
that
is
a
wider
at
the
moment,
because
I
can't
see
anything
in
the
charter
that
would
disallow
creating
these
parallel
structures.
I
Maybe
it's
it's
Justified
I
think
that's
what
the
isg
to
find
out,
but
also
we
can
highlight
maybe
a
few
domains
where
there's
Synergy
and
some
other
domains
where
we
can
learn
from
each
other
and
I.
Think
that
that's
a
job
I
think
someone
has
to
take
that
on
I'm,
not
entirely
sure.
If
we've
been
very
good
at
it,
yet,
including
me,.
A
F
A
F
So
it
is,
it
is
an
effect
or
should
be
a
chain
for
our
public
keys,
with
specific
events
on
privacy
that
also
regardless
you
can
close
to
what
we
are
doing.
The
third
aspect,
maybe
is
in
terms
of
Merkel
trees.
They
are
neither
will
be
different
from
us
because
they
critically
need
a
labeled
Mercury
so
that
they
can
do
lookups,
not
just
full
of
inclusions,
and
so
it's
possible
with
Cosmic
retreatment.
That
will
require
extending
the
scope
of
what
you
are
doing
there
so
far.