►
From YouTube: IETF-SCITT-20230710-1500
Description
SCITT meeting session at IETF
2023/07/10 1500
https://datatracker.ietf.org/meeting//proceedings/
A
B
B
We
have
two,
as
you
have
all
seen.
We
have
two
agenda
items
for
today.
We'll
wait
a
few
more
minutes
for
folks
to
join,
but
you
remember,
like
I,
put
forward
two
agenda
items
but
and
and
I
think
we
would
be
happy
if
we
if
we
managed
to
go
through
them.
The
first
one
was
about
the
draft
submission
deadline.
We
have
these
two
documents
to
submit
so
we're
going
to
look
at
those
and
then
we
also
have
the
hackathon
preparation,
which
is
the
hackathon,
is
in
two
weeks.
B
B
C
D
B
B
I
may
not
make
it
to
that
yeah
if
you,
if
you
can't
make
it
then
there's
obviously
no
choice
but
other
than
remote
participation.
But
let
me
send
so
I
just
sent
a
link
to
the
hackathon
into
the
chat
window
and
I'm
going
to
send
also
the
link
to
the
agenda
interchat
Windows
files.
So
you
can
have
a
look.
E
B
B
B
I,
as
I
mentioned,
we
have
these
two
topics:
the
submission
of
the
of
the
documents
and
also
the
hackathon
preparation.
We
had
a
fairly
Lively
discussion
on
the
mailing
list.
I,
don't
think
we
will
manage
to
get
into
that
topic.
It's
probably
something
for
side
conversations
to
see
where
this
is
going
yeah.
It
was
I
since
I
asked
the
question.
I
also
kind
of
feel
a
little
bit
guilty,
because
that
basically
turned
into
a
larger
debate
than
I
had
fought,
but
yeah.
That's
what
it
is.
B
E
B
G
We
can
revert
the
revert
if
we
need
to
I
think
it
depends
what
happens
to
these
other
ones,
because
if
it
goes
first,
we
revert
the
revert.
If
we
don't
it's
going
to
be
different
anyway,
because
it'll
need
rebasing
and
it's
all
just
typos
and
pluralization
and
stuff.
So
yeah
we'll
go
through
these
and
work
out
what
to
do.
Okay,.
E
G
There
are
quite
a
lot
of
places
where
we
have
singed
statements
instead
of
signed
statements.
You
know
transparency
Services
instead
of
transparency
service.
So
it's
all
just
little
bits
like
that.
That
I
thought
would
be
necessary
to
get
a
clean
look
from
the
rest
of
the
community,
but
we
don't
need
to
you
know
this
is
very
unsubstantial
sort
of
stuff,
so
we'll
come
back
to
it.
I
think
we
should
do
this
before
the
submission,
but
it's
it's
just
picking
up
typos,
so
the
ones
that
need
a
lot
of
discussion.
H
H
G
G
C
B
C
G
C
G
That's
completely
fine
I,
guess,
I
I,
understand
and
appreciate
that,
and
you
are
correct
what
that
does
mean,
because
today
is
the
deadline
for
submission.
That
means
we're
deciding
to
submit
a
draft
that
is
full
of
typos
and
grammar
mistakes.
But
if
you
think
we
won't
get
pilloried
for
that,
that's
okay,.
H
G
B
B
D
G
On
this,
one
is
I
I
like
these
changes,
I
think
they're
good,
but
there
has
since
been
a
thing.
I
think
Hank
made
a
change
to
talk
about
authorization
and
split
out
what
we
used
to
have
a
role-based
access,
control
and
stuff.
So
there
might
be
a
small
contraindication
that
just
needs
to
be
checked
with
the
current
base.
G
B
Well,
it
shouldn't,
if
you
look
at
the
files
change
like
it's
always
nice,
that
if
you,
if
like
if
they're
open
issues,
if
the
open
issues
are
in
the
issue,
tracker
not
directly
embedded
as
to
be
done
Cindy
in
in
the
document
itself,
because
in
this
case
it
was
even
included
in
the
in
the
suction
subject
headings.
And
that
looks
weird
right.
G
C
I
just
thought
of
giving
one
one
kind
of
it
was
just
a
minor
comment.
Actually
I,
don't
know
what
Hank
and
it
it
is.
Could
you
please
provide
a
suggestion
for
the
meeting
on
Monday,
so
basically,
what
we
have
done
in
other
drafts
is
wherever
there
is
it
to
be
done.
We
have
created
an
issue
in
GitHub
for
that
section
and
added
it
as
an
issue
number
in
the
document
itself.
Yeah.
So
that's
what
it's
just
a
cleaner,
improved
suggestion,
but
it
is
nothing
to
block
highness
from
submitting
so
I'm
perfectly
fine.
If
it's.
B
B
C
B
B
C
B
D
G
B
B
G
The
discussion
seemed
to
say
you
know,
let's
have
the
section,
but
just
make
it
a
link
to
the
use
cases
document
that
seems
sensible
to
me
and
I've
made
a
suggestion
and
Hank
has
improved
on
that
suggestion.
So
I
think
this
is
a
great
thing
to
put
in
it's
not
clear
that
it's
actually
ready
to
merge.
If
we
still
have
these
these
things
to
do.
G
Okay,
so
Hannis,
this
is
your
PR,
so
it
looks
like,
if
you
add
the
informative
header
and
accept
my
suggestion.
What
I've
done
you
know
clearly
with
this
text
here
is
I've
just
covered
the
software,
the
iot
CC
and
the
cold
chain.
So
it's
all
what
was
there
before
just
in
in
high
summary.
So
if
you
accept
those,
it
seems
like
we
yogish
can
can
approve
that
in
short
order.
After
the
after
the
call
foreign.
B
F
G
E
B
B
B
B
C
G
E
C
C
D
B
C
B
So
the
issue
here
like
I,
can
I
can
summarize
the
issue
here
and
and
I
think
it's
actually
unrelated
to
the
to
what's
that
to
to
the
main
issue,
to
find
it
to
the
main
PR
content.
So
I
I,
flattened
this
list
and
yogish
was
wanted
to
have
it
expanded
as
a
list
not
I
said,
but
I
think
the
sort
of
problem
we
can,
we
can
turn
it
back
to
what
what
it
was,
but
the
important
thing
here
is
to
tell
the
reader
like
what
are
these?
B
What
are
these
payloads,
like
like
we
write
them
down
as
pretending
we
sort
of
like?
Oh,
we
know
so
many
different
Technologies
and
abbreviations
right,
but
we
need
at
least
expand
the
acronyms
so
that
the
reader,
who
is
maybe
unfamiliar
with
those
Technologies
or
these
specifications,
understands
like
what
does
like
course
with
in
total
sales
Etc.
What
what
does
this
all
mean
and
then
have
a
reference
in
there?
So,
yes,.
C
B
Can
just
list
it
as
such,
like
sooner
or
later,
like
at
latest
during
the
I
achiever
review.
People
would
ask
you
for
references
and
they
will
want
you
to
expand
the
acronyms
which
is
kind
of
logical
correct.
So
someone
has
to
do
that.
I'm
happy
to
revert
the
change,
so
it
becomes
a
list
again
if
that
helps,
but
I
think
that's
a
kind
of
a
distraction
from
the
original
issue
which
we
had
been
debating
for
a
long
time,
which
is
the
question
about
these
registration
policies.
E
B
C
C
I
think
we
should
we
can
keep
the
list
and
each
one
of
them
list
can
be
clickable.
Each
item
is
a
click
clickable
link
which
takes
you
to
the
reference
in
the
bottom
of
the
document
where
somebody
interested
in
knowing
and
Json
spdx
would
be
able
to
go
there
and
same
for
c
bar
sit
and
cause
weight.
Yeah
be
the
right
way
of
doing
it.
Yeah.
B
C
D
E
B
B
C
B
B
G
H
B
C
B
C
So
there
was
a
fundamental
bug
in
the
spec
where
incorrectly
different
places.
We
were
using
the
term
transparent
statements
where
actually
we
meant
to
use
registered
statements
or
sign
statements.
So
I've
done
the
correction
or
he
has
thanks
to
Ori.
He
has
reviewed
it
and
looked
it
and
approved
it.
I
think
Steve
has
also
looked
at
it,
but
I'm,
not
sure
Steve.
C
C
B
D
C
No,
basically,
there
is
a
there
was
a
confusion
of
what
is
issued
by
the
transparency
service
and
what
is
registered
within
the
transparency
service.
So
registration
is
done
for
the
sign
statement
and
when
the,
when
the
statement
comes
out
of
the
transparency
service,
it
becomes
a
transparent
statement
because
there
is
a
receipt
part
app
and
unprotected
header,
so
that
Clarity
was
lacking
in
the
document.
So
I
made
it
clear
and
unambiguous,
where,
where
should
what
stuff
should
be
going?
So
that
was
the
main
motivation
behind
the
pull
request.
G
A
B
A
H
A
C
H
A
B
K
G
J
E
J
G
J
F
J
F
J
I'm
I
I,
don't
really
have
a
opinion
on
whether
it
goes
in
before
or
you
know
after
we
discuss
it
at
117.
The
thing
to
keep
in
mind
is
that
we
currently
describe
a
did
manifest
document,
which
sort
of
just
doesn't
really
align
with
the
current
did
specification,
and
so
this
is
a
little
bit
more
concretely
aligned
to
terminology
in
the
did
specification
and
Christina
even
pointed
out
a
few
other
places
where
it
could
be
more
direct
in
managing
that
alignment.
B
And
we
also
like,
if
you
guys,
agree
with
it,
we
also
have
one
discussion:
possibility
next
Monday
like
independently
of
whether
we
merged
this
or
not.
We
can
still
have
a
discussion
next
Monday
to
talk
about
this
and
and
maybe
other
topics
as
well,
hackathon,
preparation
and
so
on,
and
so
on,
because
this
is
actually
a
topic
we
want
to
also
address
during
the
hackathon.
Obviously
the
whole,
this
identity
management
thing.
I
D
K
K
A
Process,
how
do
we
want
to
handle
these
kind
of
things?
Do
we
want
to
work
with
these
drafts
deal
with
draft
PR
or
do
we
want
to
merge
and
then
have
conversation
there?
If
we
don't
merge
them,
we
things
that
take
a
while
tend
to
get
very
out
of
sync.
So
if
we
think
this
is
good
enough
for
a
draft,
my
vote
would
be
to
merge
it
in
as
well.
A
K
B
J
You
know
essentially
the
problem
statement.
Is
you
have
a
signed
message
envelope
of
some
format
and
it
has
a
protected
header
and
a
payload,
and
today
you're
going
to
be
looking
in
that
protected
header
or
the
payload
to
discover
hints
that
you're
then
going
to
use
to
discover
key
material
and
then
you'll
use
the
key
material
to
verify
that
envelope.
F
J
Then,
after
verification
of
that
envelope,
you
can
start
to
trust
that
these
statements
were
made
by
a
company
that
you
believe
is
associated
with
that
key
material,
and
the
hints
that
you
use
to
discover
that
key
are
usually
the
ISS
field
and
the
kid
field
in
cozy
and
Hosey,
and
so
when
dids
were
invented.
They
made
use
of
these
existing
registered
claim
names
for
cozy
and
Jose
headers.
To
convey
that
you
can
discover
keys
from
kid.
You
can
discover
keys
from
ISS.
J
J
This
is
the
same
process
that
secures
ID
tokens
and
access
tokens
in
openid
Connect,
but
you
know
importantly
like
the
JWT
RFC,
which
is
what
you
know.
Oauth
and
open
Ida
connect
use
it
just
defined
these
registered
claim
names,
it
didn't
tell
you
how
to
actually
get
keys
from
them,
and
so,
if
we
at
skit,
don't
make
it,
you
know
consistent
for.
If
I
have
a
identifier
for
a
key
that
looks
like
this,
then
I
know
how
to
get
the
public
key.
J
Then
no
one
can
actually
verify
any
of
the
statements
that
we're
making
and
there
could
be
many
other
ways
that
you
might
end
with
a
public
key
that
you
believe
is
associated
with
a
company.
This
is
just
documenting
dids,
which
are
one
of
the
ways
listed
in
the
current
document.
You
might
follow
a
similar
approach
if
you
want
to
direct
compatibility
with
openid
connect
and
you
might
follow
a
similar
approach.
If
you
want
to
direct
compatibility
with
the
header
parameters
that
convey
x509.
J
K
K
D
J
K
B
F
Thank
you
harness
so
I
I
have
to
admit
I
I'm,
not
at
all
familiar
with
did
either,
but
but
I
do
see
a
lot
of
software
supply
chain
activity.
I
mean
there's
a
huge
Corpus
of
you
know
software
in
the
world
today,
but
I
I,
don't
think
I've
ever
seen.
A
did.
Use
in
the
software
supply
chain
work
that
I'm
that
we
do
at
Rea.
The
most
common
things
we
see
are
things
like
you
know:
pgp
digital
signatures
and
xd509
digital
certificates
and
digital
signatures
that
are
applied
to
software.
F
J
So
specific
to
the
two
signing
formats
you
mentioned,
pgp,
usually
pgp
keys,
are
either
discovered
out
of
band
like
I.
Give
you
my
pgp
key
or
you
go
to
a
pgp
key
server
that
helps
you
resolve
pgpk
from
another
identifier
like
an
email
address,
I,
don't
skip,
doesn't
support
pgp
in
any
format.
You
know
the
envelope
formats
we're
creating
are
cozy
envelopes,
so
I,
don't
really
I
can't
answer
the
question
on
like
what's
gonna
happen
for
pgp
the
the
documents
that
we're
creating
are
about
Cozy
envelopes
for
x509.
F
D
F
I
It
might
be
fair
that
we're
starting
off
with
excellent
and
CA
issued
certificates
because
they
have
a
well-formed
way
of
trust
and
chain
up
to
to
Roots,
because
the
volume
of
of
Roots
around
the
world
is
just
too
many.
If
we
go
to
pgp
or
to
self-signed
certificates,
or
we
do
SSH
keys,
they
need
a
way
to
distribute
and
that's
where
we
get
into
discussions
of,
did
documents
and
self-signed.
I
And
how
to
cheapen
up
the
whole
model,
the
working
Charter
does
talk
about
whether
we
push
towards
a
different
identity
mechanism
and
whether
it
be
did
web
ion
or
DNS.
We
don't
care
we're
willing
to
have
that
discussion.
This
change
is
about
how
to
Crispen
up
the
language
in
here
about
dig.
We
truly
believe
that
this
is
probably
the
way
to
distribute
and
deal
with
cheaper
Keys.
The
fact
that
that
people
believe
that
pgp
as
a
key
ring
solution
is
going
to
distribute
it
to
the
size
of
the
problem.
I
We're
in
I
think
is
not
going
to
bear
fruit.
We
kind
of
need
a
distribution
mechanism,
and
all
that
already
is
doing
here
is
cleaning
up
the
definition
being
in
line
with
did
as
it's
currently
sits.
So
people
can
now
hang
their
head
on
it
and
say
hey
if
I
move
from
from
JWT
or
to
other
things.
This
is
how
potentially
it
would
migrate
forward
having
the
text
wrong,
doesn't
help
the
argument.
It
also
doesn't
limit
us
to
say:
hey.
We've
changed
our
mind
at
a
later
time,.
F
I
I
K
F
I
Arguing
that
is
not
an
old
technology.
It
was
written
into
the
specs.
Even
self-signed
certificates
is
exactly
the
same
thing.
It's
pgps
all
over
again,
whether
SSH
or
not.
We
need
to
start
having
a
discussion
of
distribution,
and
this
change
does
not
restrict
that
discussion.
This
comes
up
with
a
way
to
distribute
the
problem
in
a
consistent
way
that
scales
it
out.
F
Okay,
well
I
I've
made
my
thoughts
known
so
I
I
think
you
know
wherever
we
go
is
fine,
but
I
think
that
you
know.
One
thing
we
may
want
to
consider
is
the
existing
practices
that
are
so
prevalent
across
the
software
supply
chain
today
and
whether
or
not
we
need
to
support
those
right
out
of
the
shoot
so
I
I
made
that
yeah
known
so
I'll
just.
D
K
Do
agree,
I,
don't
see
why
we
can't
make
an
explicit
reference
to
supporting
Legacy,
Technologies
or
techniques,
and
simply
you
know
not
do
any
more
than
that,
because
if
I
see
a
pgp
key
in
there
and
I
know
the
sender
and
I
have
that
pgp
public
key.
That
I
can
match
that
quite
easily.
I
don't
have
any
place
to
get
it
if
I'm
an
anonymous
dude,
but
at
the
same
time,.
I
Returns
that
comes
that
comes
back
to
our
broader
question.
It's
then
the
transparent
Ledger
that
validates
the
identity
and
it
would
have
to
change
its
configuration
for
every
pgp
key
adds
to
its
key
ring
to
say:
hey,
our
trust
policy
has
changed
and
that
to
me
gets
at
the
other
conversations
we've
been
having
so
I'm,
not.
I
K
I
I,
so
Roy
I,
don't
disagree
with
that
at
all.
I
just
think.
We
need
to
have
something
explicit
in
there.
That
says,
if
you're
not
doing
scale,
if
you've
got
a
small
supply
chain
where
a
bunch
of
people
are
exchanging,
you
know
pgp,
Keys
informally,
you
know
they're
emailing
them
to
each
other
or
whatever
it
is.
There
should
be
something
some
capability
in
the
spec
that
says.
Yes,
we
can.
We
can
support
that,
although
it
is
not
our,
you
know,
that's
not
our
first
choice.
K
I
I
think
that
gets
back
to
the
other
conversation
we've
had,
which
is
how
do
I
talk
to
a
notary,
transparent
service
and
find
out
what
a
key
ring
it
would
trust
is,
and
somebody
would
then
have
to
put
that
as
an
open
issue.
To
add
to
the
discussion
of
if
we
went
for
pgp
style
keyrings,
how
would
you
distribute
and
share
the
key
ring
I'm
going
to
hand
over
to
Steve.
A
Time
check
here,
so
maybe
just
a
proposal,
because
there's
no
question
of
History
I
think
part
of
what
we're
trying
to
do
with
skid
is
obviously
create
a
new
Baseline
that
leverages
the
best
practices
of
what's
available
and
I.
Think
we're
also
seeing
more
identity
providers
stand
up.
That
will
help
with
where
pgp
had
filled
gaps
in
the
past.
So
I
guess.
My
proposal
would
be
to
not
bring
in
too
many
open
doors
that
might
not
allow
us
to
establish
a
new
Baseline
and
readdress
it
in
the
future.
A
F
I
From
what
I
see
open
up
an
issue
and
point
into
the
architecture
document
where
you
think
that
is
missing,
because
right
now
there's
nothing
in
there
that
states
that
as
well.
The
whole
point
of
the
did
document
solution
is
to
light
up
these
sorts
of
capability
and
as
identities,
change,
and
you
issue
yourself
a
new
pgp
key.
How
do
we
track
that?
I
The
two
of
them
are
related
is
a
future
problem
that
we
need
to
think
about
and
write,
because
currently
the
architecture
document
does
not
preclude
any
of
those
things
you're
talking
about
all
this
pull
requests
that
Maria
has
here
is
create
and
strengthening
the
text
around
did
that
was
pre-existing.
It
doesn't
limit
anything
else.
F
So
I
think
there's
a
fundamental
disconnect
here.
So
I
think
there's
a
belief
that
these
keys
are
used
for
identity
and
they're.
Really
not
the
identity
is
of
an
entity
and
they
use
these
Keys
as
an
expression
to
prove
their
identity.
So
I
think
we
need
to
resolve
really
early.
The
fact
that
there
is
this
concept
of
an
identity
of
an
entity
and
that
there
are
methods
to
communicate
that
information
about
those
identities-
and
these
are
one
of
the
supporting
artifacts
dick.
I
Even
in
the
software
supply
chain,
self-attested
statements
is
insufficient.
The
noun
Dad
to
have
third
party
attested,
which
identity
now
Chimes
into
you,
know
this
and
tracking
identity,
as
it
moves
with
different
key
material
is
precisely
going
to
be
this
problem
and
even
if
you
say,
hey
I
have
a
self-signed
certificate,
I'm
going
to
use
it
for
the
next
20
years,
not
everybody
else
is
going
to.
I
B
D
Yeah
I
mean
I
just
wanted
us
to
bring
us
back
to
the
the
issue
at
hand.
I
I
respect
the
the
notion
of
trying
to
figure
out
in
the
future
how
we
get
backwards,
compatibility
I
it.
My
notion
is
that
we
could
have
a
way
of
having
people
with
dids
or
some
other
scalable
approach,
assert
that
a
pgp
key
is
of
interest
and
that
people
should
trust
it,
and
and
do
it
kind
of
by
by
a
branch
like
that.
D
B
D
D
A
B
I'm
I'm
also
hoping
to
see
the
text
for
the
other
things
right
like
we
talked
about
some
of
those
things
in
the
past,
and
it
takes
us
a
very
long
time
to
come
up
with
some
text
that
we
could
actually
review
and
I
think
we
need
to
get
better
at
that
writing
texts
so
that
I
couldn't
read
it
and
then
we
can
advance
the
our
documents.
We
didn't
even
manage
to
get
to
the
use
case
document.