►
From YouTube: IETF-SCITT-20230821-1500
Description
SCITT meeting session at IETF
2023/08/21 1500
https://datatracker.ietf.org/meeting//proceedings/
B
B
Well,
I
guess
a
few
of
the
other
folks
would
join
in
a
minute
or
so
John.
Should
we
okay
good
to
see
if
anyone
knows
more
about
the
deep,
deep,
Bomb
Group?
Well,
thanks
to
you,
dick
and
Ole
I
think
we
have
some
contacts
established,
so
we
will
hopefully
see
them
in
a
future
conference
call
and
they
will
explain
us
on
what
they
do.
F
F
F
Yeah
yeah
midi's
already
replied
so
he's
happy
to
come
and
present.
We
just
need
to
pick
up
I
think,
especially
as
that's
a
sort
of
special
guest.
In
liaison
thing.
We
have
to
be
super
careful
with
the
reminder
we
got
about
organizing
meetings
in
advance,
so
I
think
we
need
to
have
two
weeks
notice,
so
we
could
potentially
selfishly
I.
Don't
want
to
suggest
this
because
I'll
be
on
vacation
in
two
weeks,
but
two
Mondays
from
now.
B
B
E
Yeah
well,
I
just
didn't,
want
to
interrupt
I
think
what
would
be
very
useful,
despite
any
differences
that
John
mentioned
is
above
the
API
like
how
what
kind
of
data
are
they
submitting
to
their?
You
know
their
machine,
and
maybe
we
can
do
that
before
we
get
any.
You
know
before
the
we
get
someone
to
present
it
to
us,
because
that's
what
I
would
find
interesting
is
I
would
like
this
to
know
more
about
the
like.
E
B
E
Well,
only
to
the
extent
of
just
pulling
in
his
information
and
trying
to
recognize
what
I'm
trying
to
trying
to
blend
what
he
seems
to
want
to
have
and
what
other
people
tend
to
be
saying
that
the
skit
machine
actually
is
at
this
point
and
so
I
I
think
we
made
a
little
bit
of
progress.
I
created
the
a
just,
a
a
document
to
try
to
to
pull
in
all
the
information
and
and
I
did
an
initial
round
there
and
I.
E
D
So
I'm
I'm,
aware
of
Chris's
debum
activity
for
quite
some
time
now
and
I'm
I'm
I
find
it
very
interesting
how
the
direction
changed
a
little
bit.
So
now
it's
basically
a
pub
sub
service
for
the
contributors
to
the
information
exposed
and
that's
fine
I
I
understand
how
subscriptions
work.
I,
don't
really
understand
why
a
publisher
is
called
a
commit,
probably
because
they
assume
there's
some
verifiable
data
structure,
providing
some
append
Only
log.
D
Do
you
need
that
and
I
I?
It
seems
to
me
as
it's
as
trillion.
It
was
highlighted,
I
think
at
some
point,
I
don't
know
if
it
still
is
as
an
example
that
skit
would
be
the
the
bomb
could
be
a
vehicle
for
for
using
a
sketch
transparency
service,
for
example.
So
for
me
it
seems
these
are
orthogonal,
Concepts
and,
and
that
might
be
interesting
to
our
explore,
but
but
that
that
might
also
delve
into
hackathon
and
and
testing
run.
D
B
B
B
F
B
B
B
B
It
would
be
good
to
combine
them
because
they
is
they
at
the
level
of
the
protocol.
They
mean
the
same
thing
in
my
opinion,
maybe
maybe
I'm
oversimplifying,
but
it
gets
tricky.
The
document
gets
tricky
to
read
if
you,
if
sometimes
sort
of
one
term,
is
used
and
then
sometimes
Another,
one
not
so
well
defined
top
in.
In
essence,
there
are
some
entities
that
query
the
the
log
and
do
something
with
that
information
and
that
could
be
in
in
some
cases
could
be
an
auditor
or
it
could
be
a
consumer.
B
One
I
copy
that
that's
the
the
issue
of
harmonizing
the
terms
issue
and
client
post
that
link
in
the
chat
window
too
there.
The
issue
is:
the
issue
is
the
one
that
creates
the
sign
statement
and
then
the
client
is
used
to
actually
refer
to
the
protocol
that
sends
the
signed
statement
over
to
the
transparency
service.
B
B
So
the
document
is
a
little
bit.
Maybe
that's
a
leftover
from
an
earlier
version
of
the
document.
The
text
talks
about
the
envelope
sort
of
wrapping
sort
of
as
a
reference
to
the
whole
structure.
That
includes
the
sign
statement,
but
it's
I
think
only
an
a
technical
artifact
or
maybe
a
leftover
from
from
earlier
days
of
the
documents.
B
But
ultimately
what
the
sign
statement
is
is
just
a
cozy
sign
one
and
get
that
gets
sent
and
so
talking
about
the
the
envelope.
There
is
just
confusing
it's
another
term
that
just
appears
in
the
text
and
and
you
just
wonder
where
it
comes
from
and
if
you
and
I
I
had
difficulties
sort
of
like
I,
don't
want
to
go
ahead
and
proactively
sort
of
rip
out
terms
and
merge
terms
and
go
through
the
whole
document
and
to
replace
them.
G
B
One
I,
independently
from
from
the
issues
above
I,
tried
to
clean
up
one
section
and
I
sent
a
starting
a
pull
request
on
on
Section
six.
It's
not
finished
yet,
but
yogish
already
gave
me
a
little
bit
of
feedback.
So
there's
this
so
from
an
implementation
point
of
view,
there
is
the
need,
obviously,
to
for
the
issuer
to
create
these
sign
statements
and
then
to
issue
and
send
them
to
the
transparency
service
and-
and
that's
that's
perfectly
fine,
so
there's
some
text
I
cleaned
up.
B
Think
that
could
be
separated
out
a
little
bit
clearer
by
just
saying
like
the
first
step
is
issue
a
creates.
This
sign
statement.
Here's
the
structure,
how
it
looks
like
and
then
again
the
transparency
service
does
some
processing,
and
then
it
sends
a
response
back
and
here's
how
response
looks
like
and
I
think
what
is
done
today
is
in
the
document
that
has
been
submitted
is
to
collapse.
B
The
two
which
I
think
makes
it
more
difficult
to
read,
but
maybe
this
is
just
in
in
my
opinion,
so
in
that
sense,
I
would
appreciate
your
feedback
on
this
too.
Specifically,
if
you
read
through
it
think
about
how
someone
would
want
to
implement
this
in
in
terms
of
step
by
step,
so,
and
so
so
that's
what
what
I
was
trying
to
do
here
like
trying
to
create
this,
make
the
steps
a
little
bit
easier
to
read,
at
least
from
from
my
point
of
view.
H
H
You
mentioned
a
few
of
them
there,
but
there
are
others
that
also
create
similar
ambiguities.
The
the
the
US
sister
group,
that's
working
on
a
document
called
cict
supply
chain
risk
management
task
force,
is
actually
working
on
some
definitions
for
these
various
supply
chain
rules
and
they're
not
ready
to
reduce
or
publish
that
information.
H
Yet
we're
waiting
to
get
some
feedback
from
the
state
procurement
officers
and
some
more
Federal
inputs
before
we
go
forward
with
you
know
providing
a
public
view
of
what
those
Define
roles
are,
and
this
is
an
area
that,
as
you
know,
is
going
to
have
perhaps
as
much
discussion
as
this
whole
software
identity
discussion,
so
that
that's
coming
I,
don't
and
I'll.
Let
the
group
know
as
soon
as
I
can
when
those
role
definitions
are
available
for
review.
It
may
be
useful
for
this.
H
Secondly,
I
wanna
I
wanna
say
thank
you
to
Cassie
Crossley
for
joining
this
effort.
Kesley
is
a
long
time,
s-bomb
contributor,
so
to
have
her
in
this
work.
Group
is
going
to
be
beneficial
to
helping
us
work,
those
software
supply
chain
issues.
And
thirdly,
I'd
like
to
say
Ray
you,
you
did
a
great
job
of
getting
us
started
on
the
API
topic.
It's
an
area
that
is
fundamental
to
the
purpose
of
skit
and
so
I
I
think
we
need
to.
H
B
Definitely,
or
at
least
speaking
for
myself,
only
interested
in
looking
at
the
terminology,
as
you
pointed
out,
I
I
struggled
with
that
a
little
bit
as
well.
It
would
be
good
to
harmonize
it
with
what
other
people
do
and
basically
create
the
links,
so
we
don't
have
to
do
everything
ourselves
and
yeah.
Also
thanks
to
Casey
for
joining
that's
excellent.
B
F
Yeah,
so
on
on
that
I
mean
clearly
everybody
reviewing
and
certainly
fresh
eyes.
Reviewing
is
great
to
that
end.
I've
got
a
new
person,
my
engineering
team,
looking
at
looking
at
the
specs,
seeing
if
we
can
Implement
from
first
principles
you'll
remember
we
managed
it
last
time,
but
that
was
a
very
sort
of
low-level
deep
implementation.
F
F
F
So
there
is
potentially
a
very
big
change
to
make
there
if
we
want
to
be
harmless
harmonized
with
with
those
communities,
otherwise
yeah.
We
need
to
be
much
clearer,
I
think
there's
a
job
for
the
skit.io
site
to
maybe
have
a
much
higher
resolution,
cleaner
diagram
that
we're
able
to
do
in
RFC
text
ASCII
art,
because
it
is.
B
John
I
think
he
would
be
like
and
for
me
it
would
be
useful
feedback
to
say,
like
I
would
like
I
scrambled
down
notes
on
on
literally
on
paper
of
the
skid
architecture.
Document
and
I
was
thinking
like
how
would
I
propose
some
changes,
but
I
I,
don't
really
know
which
group
which
direction
the
group
wanted
to
go.
E
B
H
Well,
actually,
very
briefly,
honest
I'm,
going
back
to
something
I
said
earlier:
I
was
a
little
late,
so
I
don't
know
if
Cassie
had
a
chance
to
introduce
herself
to
the
group,
but
she
works
at
Snyder,
Electric
and
she's.
She
has
a
significant
contribution
to
make.
Have
you
had
an
opportunity
to
let
Cassie
introduce
herself.
B
G
G
The
details
of,
but
I
do
have
the
s-bomb
Team
reporting
directly
to
me
and
I'm
working
very
closely
with
different
customers
and
with
governments
on
product
transparency
in
regards
to
their
needs,
but
also
trying
to
make
it
realistic
and
one
of
the
items
that
I've
been
involved
with
and
just
on.
The
periphery.
Along
with
this
one
is
the
d-bomb.
So
I've
got
s-bombs
in
I've,
got
thousands
of
s-bombs
for
our
products
collected
and
stored
and
have
been
sharing
them
under
NDA
to
customers.
G
But
we
have
not
up
to
this
point:
I
have
not
worried
about
signing
them
or
doing
you
know
the
the
more
detailed
layers
of
trust
and
transparency,
and
that's
the
topic
I'm
working
on
now,
a
lot
around
Providence
and
such
so.
This
has
been.
This
has
been.
The
next
stage
is
getting
to
that
layer
and
that's
why
I
wanted
to
be
able
to
look
at
fully
implementing
you
know
things
like
d-bomb
and
skit
and
see
where
that
takes
us.
G
H
Yeah
I
just
want
to
say
Cassie
I
didn't
mean
to
put
you
on
the
spot
there,
but
you
you've
been
such
an
influential
participant
in
the
software
supply
chain.
Work
effort
that
I
I
thought
it
would
be
worthwhile.
Just
you
know
giving
you
an
opportunity
to
let
the
work
group
know
what
you're
bringing
to
the
party
you're
you're,
a
very
valuable
contributor
and
I
I
think
it
would
be
it's
going
to
be
very
helpful
having
you
as
part
of
this
effort.
F
F
They
want
to
accidentally
embarrass
anybody,
I
think
it's
right,
but
I
want
to
be
careful
and
the
other
thing
is
there
are
videos
from
the
hackathon.
So
if
you
had
sort
of
half
an
hour
to
spend,
I
can
send
you
the
the
time
codes
for
the
YouTube
videos
to
see
what
we
did
with
the
medical
device
use
case
and
then
that
might
that
might
accelerate
some
of
the
learning.
If
you're
interested
in
that
yeah.
B
Yeah,
it's
not
it's
I
didn't
put
it
on
of
text
India,
because
the
problem
is
not
so
much
is
not
so
much
the
text
that
is
in
there.
It's
actually
the
text
that
is
not
in
there.
So
it's
a
little
bit
It's
tricky
to
sort
of
to
share
something
specifically
I,
think
I'm,
just
missing
text
in
the
in
the
document
on
on
nailing
down
exactly
what's
really
relevant
to
the
protocol
and
to
to
the
architecture
and
what
we
are
working
on.
I
B
I
Which
is
I'm
producing
this
software
or
I'm
vouching?
For
this
software
to
be
that's
the
issuers
role
and
the
client
is
who
is
authorized
to
interact
with
this
kid
with
a
given
role?
Basically,
so
he
can
be
different
entity
than
as
issuer
of
the
statement
who
is
responsible
for
the
claims
made
within
the
statement
so.
E
I
B
You
sort
of
like
make
the
client
as
like
you
said
like
is,
is
someone
who
is
authorized
to
contact
the
transparency
service
and
and
register
something
then
the
question
arises.
Unlike
is
there
a
need
to
like?
What's
the
authentication
and
authorization
Machinery
to
us
to
to
deal
with
the
client
authentication,
because
we
have
a
story
for
authenticating
and
authorizing
the
issue,
but
not
for
the
client?
B
So
that's
that's
missing
in
the
document
in
and
also
what
it
is
any
relationship
between
the
issue
and
the
client
and
whether
that
needs
to
be
indicated
somewhere
like
do
we
require
the
transparency
service
to
let's
say
to
understand
that
certain
issues
issue
us
or
issue
signed
statements
by
issuers
come
from
certain
clients.
Only
is
that
is
that
a
thing
or
not.
I
B
B
And
and
I'm
happy
to
contribute
some
text
if
I,
if
I
know
what
what
the
answer
is
like
it's
easier
to
write,
something
I
would
have
naively
said
that
there's
no
specific
client
authentication,
the
client,
the
rest
API
is
kind
of
a
transport
and
and
that's
it.
But
maybe
the
story
is
more
complex
in
I.
Don't
know
how
some.
I
I
H
Thanks
again,
harness
I
don't
feel
like
I'm
dominating
this,
but
I
just
did
want
to
bring
one
more
item
to
the
surface.
So
Roman
sent
an
email
to
the
list,
asking
questions
about
something
that
Ray
had
sent
about
the
new
SEC
regulations
that
go
into
effect,
December
2023
and
he
asked
you
know
how
does
how
does
this
have
any
relationship
with
the
with
the
work,
we're
doing
and
and
I
will
go
just
go
on
the
record
and
say
I.
H
Think
in
my
personal
opinion,
this
is
the
biggest
change
in
the
software
supply
chain.
Regulatory
space
in
the
U.S
and
I
even
include
the
s-bomb
work.
This
is
even
bigger
than
that.
This
goes
well
beyond
what
what
the
s-bomb
work
did
and
NTI
minimums.
And
of
course
you
know,
the
question
will
be
what
role
will
skip
play
in
this
in
helping
to
implement
or
satisfy
these
SEC
regulations?
H
I
will
say:
I
I,
don't
have
an
answer
to
that
question
at
the
moment,
but
I
I
think
there
is
certainly
a
potential
for
the
skit
trust
registry
to
serve
some
role
in
ensuring
the
you
know
that
the
information
these
you
know
these
companies
present
is
in
fact
trustworthy.
So
I
see
a
potential
there.
If
anyone's
interested
in
discussing
I
will
say
this
whole
SEC
thing
is
creating
a
huge
flurry
here
in
the
U.S
thanks.
B
H
B
H
F
Yeah,
so
I
want
to
go
backwards
for
a
minute,
so
yeah
thanks
dick
yeah,
there's
often
sensitivity
about
skit,
straying
outside
of
its
Lane,
as
we've
heard
a
couple
of
times,
but
I
I
can't
see
any
way
that
this
is
that
that
is
straight
solidly
down
the
software
supply
chain,
software
artifacts
thing
in
any
case
yeah.
So
on
the
issue,
a
versus
client
thing.
It
is
clearly
there's
work
to
be
done.
We
deliberately.
F
I
say
we
I
mean
I
I,
don't
do
much
of
the
spec
writing
I
just
implement
it
to
make
sure
it
works,
but
we
as
a
community
deliberately
went
very
vague
on
the
access
controls
at
the
scrappy
layer.
So
the
the
the
difference
here
that
we
need
to
drive
back
towards
is
one
that
says:
we
have
a
kind
of
API
access
which
allows
access
controls
and
there
used
to
be
a
whole
section.
F
If
people
remember
saying
things
like
our
back,
but
our
back
was
definitely
wrong
and
then
we
started
saying
things
like
certificates,
but
certificates
was
also
definitely
wrong,
because
you
can
do
ODC
and
things
like
that.
So
we
don't
want
to
be
prescriptive
on
it,
but
nonetheless
there
does
need
to
be
an
application
layer.
You
know,
am
I
allowed
to
call
this
API
type
access
control,
that's
what
the
client
is
doing
and
then
the
issuer
is
the
issuer
of
the
statement
itself.
F
The
signer
indeed
of
the
statement
itself,
which
is
a
different
Authority
and
a
different
identity.
So
I
think
the
the
difference
between
two
is
very
clear
and
is
extremely
important
to
tell
the
difference
between
proof
of
possession
of
a
signing
key
for
making
statements
about
a
feed
and
proof
of
integration
with
an
application.
That's
allowed
to
make
Network
calls.
F
I
B
Would
make
life
easier
because
otherwise
it's
it's
kind
of
a
little
bit
of
struggle
from
from
like?
We
also
have
to
think
about
the
readers.
It's
not.
Of
course,
there
would
be
people
who
are
involved
in
a
group
and
and
know
what
this
is
about
and
then
they
Implement
and
so
on
and
so
on.
But
there
are
also
other
readers
who
don't
want
to
go
into
looking
at
the
code
and
so
on.
They
just
want
to
read
the
document
and
understand.
What's
going
on.
F
F
B
B
Like
the
readings
through
the
document,
it's
like
you
have
some
parties
that
basically
take
what
is
stored
in
the
in
the
log
and
then
do
all
sorts
of
processing
on
on
on
that
data,
and,
of
course
they
need
to
some
need
to
download
everything
and
then
construct
everything.
Others
have
a
maybe
are
more
interested
in
in
a
very
specific
response.
Only
and
so
I
think
it's
good
to
indicate
that
there
may
be
multiple
different
interests
for
those
parties
to
get
the
data
and
do
something
Vivid.
B
But
from
a
writing
point
of
view,
it's
difficult
to
mix
and
match
the
terms
all
over
the
place,
because
sometimes
I'm
wondering
like,
if
it
says
auditor,
is
that
really
is
it?
Does
it
have
to
be
the
auditor
it
can
it
be
like
a
consumer
who
is
only
interested
to
a
subset
it
of
it
or
is
it
a
verifier
who
is
sort
of
like
if
they
verifier
the
generic
version
of
the
consumer
and
the
auditor
or
the
Monitor,
and
so
I
yeah
I'm,
sometimes
lost
I
hope
that
makes
sense.
C
C
I
I,
don't
know
if
it's
a
use
case,
but
somehow
I
I
think
the
architecture
document
should
at
least
be
talking
if
it
doesn't
already-
and
maybe
it
does
about
how
kind
of
the
ecosystem
gains
trust
in
any
particular
transparency,
Vlog
and
that's,
presumably
via
things
like
Auditors
and
monitors
and
defining
the
architecturally.
The
notion
that
everything
has
to
be
coherent
enough
to
be
audited
and
monitored
and
also
be
useful
for
again
what
I
call
a
relying
party
that
that
is
just
interested
in
a
particular
claim.
C
I
I
What
is
the
role
of
a
verifier?
What
is
the
role
of
an
auditor
and
what
is
just
role
of
a
monitor,
and
then
we
should
have
a
clear
definition
of
these
in
the
document
I
think
so
far.
We
have
just
followed
the
use
of
the
term
end
user
or
consumer
which
is
kind
of
and
encapsulate
all
these
folded
together
as
one
big
role.
B
Yeah
I
wonder
who
is
going
to
write
that
text
and
you
and
Neil
just
had
brought
up
I
think
it
would
be
obviously
useful
to
distinguish
this
a
little
bit
better
and
to
sort
of
make
it
clear
on
what
the
properties
are.
The
security
properties
that
yeah
the
consumers
or
whatever
relying
parties
get
out
of
this
and
I
think
it's
also
in
line,
but
dick
has
been
asking
for
a
number
of
times,
but
I
think
we
need
some
text
text
is
not
there.
C
H
D
B
D
D
Buckets
if
you
need
a
more
detailed
one
like
Auditors
versus,
monitor.
I.
Think
that's
helpful
if
there
is
enough
meat
to
the
bones
here
in
the
use
cases,
so
so
the
other
that
I
think
there
are
tons
of
relying
parties,
types
that
all
behave
at
the
same
time
same
sorry,
the
same
manner
in
the
end,
and
so
so
we
have
to
be
careful
just
to
overload
terms
glossary
here,
just
just
because
you
might
not
be
able
to
differentiate
a
auditor
from
a
monitor
technically
right.
D
E
E
You
know
interfaces
to
machines
like
this.
They
usually
have
a
every
a
way
to
to
understand
what
the
capabilities
are
of
the
machine
to
inquire
about
what
what
is
the
profile
or
what
are
the
capability
profile
of
the
machine,
and
if
we
have
that
kind
of
thing
so
for,
for
example,
in
the
old
days
like
you
know,
working
with
modems
and
stuff,
you
would
you
would
have
an
interface
to
it
and
you
could
say
like
like.
Can
you
do
this?
What
are
your
capabilities
you
know?
E
I
can
do
these
baud
rates
all
this
and
having
a
a
some
that
that
API
like
if
you,
if
you
said
well,
I,
want
to
talk
to
the
skit
instance
here
there
should
be
a
way
to
to
first
ask
it:
you
know:
what
can
you
do
and
and
what
it?
What
what?
What
is
the
manner
in
which
I'm
gonna
work
with
you
and
then
it
may
say,
like
we
may
only
have
one
right
now.
E
This
is
exactly
the
only
way
that
I
work
is
the
way
that's
defined
by
the
skit
docking,
but
there
may
be
enhancements
and
so
forth,
or
our
Market
differentiation
by
different
folks
that
they
want
to
do,
and
so
those
would
be
added
in
there
and
that.
But
then,
at
this
higher
level,
the
concept
is
that
the
level
of
roles
and
actually
requiring
certain
documents-
or
it
seems
to
me,
like
we're,
probably
going
to
be
needing
to
handle
the
identity
like
in
the
d-bomb
thing.
E
E
B
C
Oh
thanks,
sorry
just
to
say
that
at
least
from
an
API
perspective,
I
can
just
imagine
that
there
might
be
a
different
low
level
important
to
have
it
at
the
low
level
capability
to
be
downloading
stuff
in
bulk
efficiently
versus
kind
of
a
more
targeted
relying
party,
and
you
know,
I
I,
appreciate
the
all
the
efforts
to
it's.
It's
usually
important
that
we
make
this
usable
for
real
people
for
real
problems
so
that
they
adopt
it,
but
as
people
keep
pointing
out,
that
implies
so
many
different
things.
C
For
so
many
different,
specific
use
cases.
It's
going
to
be
a
real
challenge,
so
I
still
think
it's
useful
to
at
least
address
the
question
and
maybe
answer
the
question
in
their
in
the
architecture
document
you
know.
Are
we
addressing
both
systematically
the
need
to
have
an
ecosystem
where
we
trust
particular
logs
and
somebody's
actually
watching
them
to
see
if
they
misbehave
as
a
completely
different.
F
Yeah
two
two
comments
on
that.
So
one
is
the
the
Eternal
comment
on
the
charter
and
yeah
we're
having
very
use
case,
specific
stuff
or
whatever
I
think
we've.
We've
many
times
said
that
we
want
to
stay
payload,
agnostic
or
payload
blind,
which
prevents
sort
of
degrees
of
semantic
search
and
things
like
that.
F
But
it
is
absolutely
possible
to
Define
grammars
for
making
queries
that
Transit,
the
skit
layer
and
I
think
that's
important,
so
I
think
we
demonstrated
some
of
that
at
the
hackathon
and
and
certainly
happy
to
to
keep
pushing
that
forward.
So
saying
we
we
Faithfully
are
able
to
to
make
those
queries
without
knowing
what
they
mean.
I
think
is,
is
potentially
a
thing
to
to
go
for,
but
yeah
as
Neil
says
getting
too
specific.
Or
is
he
understanding
what
these
questions
are
asking
would
be
a
significant
expansion
of
the
work
product.
I
On
top
of
that
and
there
we
can
expand
the
end
user
role
into
much
more
concrete
as
exemplify
that
into
much
more
concrete
instantiation
of
monitor
verifier,
so
that
there
is
a
scope
for
modifying
n
number
of
further
roles,
if
required,
be
based
on
a
particular
implementation
instance.
So
the
guidance
document
can
help
clarify
what
the
end
users
are
and
we
can
live
with
the
main
architectures
back
with
just
a
common
blog
of
end
user.
That's
what
I
I
think
would
be
a
best.
That's
my
view.
Best
compromise
can
happen.
D
Yeah,
so
this
is
saying
just
barging
in
sorry
for
ignoring
queue,
but
my
name
was,
and
so
yeah
I
think
exactly
that.
So
we
have
the
architecture
document
to
Define
all
the
building
blocks.
We
have
the
use
cases
in
there.
We
have
the
scrappy
document
that
will
tell
you
how
to
technically
facilitate
that
and
then
the
guidance
document.
The
guidance
document
will
pick
up
on
use
cases
and
and
and
maybe
on
the
terminology
of
rules
as
discussed
before.
D
For
my
for
my
scenario
and
and
such
so,
the
guidance
document,
I
think
is,
is
the
thing
we
have
to
take
into
a
hand
like
a
like
a
pamphlet
and
then
walk
around
with
for
people
to
do
yourself
identify
with
this.
No,
why
not?
What?
What
can
we
do
to
help
you
make
use
of
this
and
I?
Think
that's
a
real
helpful
guidance
in
the
end.
The
informative
documents
that
accompany
the
standards
text
and
I
would
absolutely
give
you
that.
C
I
I
won't
call
it
a
guarantee
because,
if
nobody's
watching
a
log,
I
think
I,
we
need
to
acknowledge
I,
I,
hope,
I.
Think
if
nobody's
watching
a
log,
then
it
could.
You
know
not
be
append
only
and
muck
with
things
and
not
be
trustable,
and
somebody
in
the
ecosystem
needs
to
be
watching
that
so
I
would
just
advise
kind
of
any
user
of
a
log
that
we
need.
That
kind
of
a
role
and
and
I
I
like
the
idea
of
the
guidance
documents.
B
E
Yeah
I
think
there
is
a
big
difference
there
between
that
that
particular
role
and
it's
at
the
low
level
API
would
need
to
have
probably
that
information
exposed
like
I,
say
in
in
that,
as
some
sort
of
a
request
about
the
profile
of
whatever
the
skit
machine
at
that
level
can
do
and
and
say.
Perhaps
here's
how
you
can.
E
We
have
a
you
know:
I
guess
a
digital
twin
I'm,
not
sure
I,
quite
understand
that
yet
but
but
maybe
you
know,
there's
two
of
them
or
something
and
and
they
check
each
other
or
some
manner
in
which
that
they
that
they
maybe
there's
an
embedded
Checker
that
that
checks
it
some
way
that
it
is
it
it
is,
or
maybe
it's
not
Czech,
maybe
they
just
say
look,
that's
our
policy.
We
don't
really
check
things.
E
We
just
put
it
in
this
and
we
think
that's
a
pretty
good
solution
and
if
you
don't
mind
that
level
of
security
then
go
ahead
and
use
it
so
it
I
I
mean
it
wouldn't
necessarily
need
to
have
the
same
same
thing,
but
that's
different
from
the
the
the
user
level,
whether
you're
a
submitter
or
a
viewer.
Maybe
somebody
needs
to
search
for
things
which
would
be
at
that
higher
level.
Api,
okay,
enough
said
for
me,
thank
you.
I
I
do
and
I
do
support
this.