►
From YouTube: IETF-SCITT-20230605-1500
Description
SCITT meeting session at IETF
2023/06/05 1500
https://datatracker.ietf.org/meeting//proceedings/
A
A
C
A
A
A
A
Okay,
maybe
they
turn
later
and
and
then
we
can
talk
about
that
stuff.
The
the
other
thing
where
we
stopped
last
time.
Last
week
we
had
a
holiday,
so
we
we
skipped
that
meeting,
but
the
week
before
we
talked-
or
we
looked
at
the
list
of
open
issues,
and
we
specifically
spent
some
time
on
one
open
issue
that
Antoine
created.
He
was
talking
about
the
the
URL
for
the
transparent
statements,
I
believe,
if
I
remember
that
correctly,
but
there
are
tons
of
other
issues
that
we
need
to
go
through.
A
G
A
A
B
A
H
A
H
G
C
H
H
H
A
A
D
E
D
A
G
Too
many
buttons
to
turn
things
on
and
off
all
right,
so
we'll
spend
a
couple.
I
guess,
10
minutes
going
through
some
of
this
stuff.
I
was
gonna
work
from
the
back
for
some
ones
that
possibly
hopefully,
that
we
can
close
more
quickly
and
triage
some
of
these.
So
this
one
was
the
terminology:
I
think
we've
got
the
majority
of
it
done
with
this
PR.
G
F
G
F
So
I
think
one
of
the
things
that
that
we
can
just
say
if
it's
pretty
sure
this
is
true,
we're
saying
append
Only
log
instead
of
registry
or
Ledger,
even
though
we
it
may
be
implemented
in
some
other
way.
Okay,
so
it
was
just
a
to
use
that
named
as
a
as
a
way
to
just
say
that
and
then
get
rid
of
the
other
other
type
of
nomenclature,
and
then
probably
in
our
definition,
we
can
say
an
append.
Only
log
might
not
be
in
a
pen,
Only
log.
G
A
G
F
Yeah,
okay,
so
I
I,
think
transparency
service
has
been
pretty
useful
thing
to
say
and
helps
people
kind
of
understand
what
it
is
without
anything
more.
They
they
just
kind
of
shake
their
head
and
go
okay.
I
know
what
it
is
a
little
bit:
okay,
so
that
that's
that's
probably
going
to
help
us
is
to
have
that
that
change
versus
saying,
skit
or
skit
registry,
or
something
else,
because
that
doesn't
doesn't
do
it.
But
okay.
Thank
you.
E
E
A
C
H
H
F
F
And
I've
been
coming
across
this
a
lot
and
maybe
it'll
be
a
good
tool
for
us.
Okay,
and
that
is,
if
you
have
there's
there's
us,
there
can
be
a
signature.
You
know
somebody
signed
something
and
then
there
is
away-
and
this
was
all
in
the
nist-
they
have
a
whole
thing
about
how
to
you
know
how
to
get
the
to
prove
that
the
person
actually
has
that
signature
at
that
time,
where
you
send
them
a
nonce
and
there's
also
I,
think
that's
the
way
to
do
it.
F
So
that's
kind
of
like
a
wet
signature
on
something
so
that
you
can
say:
okay
I
sent
you
a
non,
so
you
did
it
right
now
and
you
signed
it
so
I
know
you
have
that
signal
that
private
key
then
there's
a
secondary
thing,
which
would
be
that
I,
don't
see
discussed
in
places,
but
I
think
it's
the
way
they
use.
They
do
a
lot
of
the
open,
SSL
stuff.
Where
or
that's
not
the
name
of
it
at
where
you
you
have
something
that
you
actually
do
trust
and
then
it
observes
it.
F
So
if
you
had
an
entity
that
did
a
wet
signature,
checking
of
the
private
of
the
you
know
the
public
key
and
private
key
connection
that
seems
like
that
would
be
the
definition
of
a
notary
and
not
the
transparency
service,
which
is
a
little
bit
different
than
than
what
I
think
of
as
a
notary,
and
that's
how
I
think
about
it.
Now
I
I'm,
so
so
I
would
take
out.
F
G
I
mean
I.
Think
of
the
when
we
have
this
particular
issue,
we're
tracking
it
was
the
registering
transparency
service.
I
think
this
was
where
we
were
trying
to
figure
out,
and
we
do
have
this
piece
here.
I
think
the
notary
is
a
part
of
it,
but
not
the
a
synonym
I
would
agree
with
that.
I
thought
we
had
a
different
issue
tracking
that.
G
So
we
can
put
it
in
I
mean
we
can
leave
this
one
open
and
revisit
here
or
we
can
track
it
as
part
of
the
other
issue,
because
we
we
wind
up
with
this
one
being
a
larger
specifically
around
registry
and
transparency
service.
Then
we
have
another
one
that
specifically
talks
around
the
notarization
process.
F
F
What
I
will
do
is
write
up
what
I
understand
as
these
little
pieces,
because
I
I've
I've
been
trying
to
just
you
know,
understand
the
various
cryptographic
mechanisms,
and
these
are
mechanisms
that
are
are
they
are
mentioned
in
places,
but
I
I
see
that
the?
What
what
is
the
name
of
the
everybody's
using
now
and
say,
because
you
know
they
had
trouble
with
people
getting
you
know
paying
for
a
a
public.
F
Is
there
a
clear
definition
of
what
a
notary
is
because
it
certainly
is
not
not
a
transparency
Service
in
itself,
it's
in
it's
a
function
that
is
a
cryptographic
function
and
and
I
think
it's
this
deferral.
If
somebody
watching
a
wet
signature
being
done
and
then
saying,
I
watched
it
and
you
can
and
I'm
I'm
a
very
trusted
entity
because
I
have
the
paid
for
public
key,
and
so,
if
somebody
does
then
maybe
in
the
chat
you
can,
let
me
know
where
it
is
and
I'll
go.
F
Look
at
it
but
I'm
trying
to
I'm
trying
to
absorb
everything
about
this,
because
just
to
let
you
know,
I'm
working
on
a
a
air
gapped
protocol
which
basically
will
be
requesting
for
data
or
delivering
data
and
then
securing
it
on.
You
know
flash
drive
or
jump
drive
or
something,
and
so
I
we're
working
on
this
right
now,
but
anyway.
Thank
you.
F
A
I
A
J
You
hey
yeah,
so
I'm
following
the
key
transparency
work.
So
if
you
haven't
watched
the
boss,
videos
you,
you
should
they're
really
excellent
from
the
last
ietf.
They
had
a
lot
of
really
relevant
content
and
I.
Think
the
important
thing
for
folks
here
to
understand
is
when
you
say
key
transparency.
They
mean
like
key
Value,
Store
transparency.
They
don't
mean,
like
cryptographic,
key
transparency.
J
F
J
So
they,
you
know,
they
talk
a
lot
about
applying
key
transparency
to
username
like
identifiers,
like
email
addresses
or
or
phone
numbers.
Where
you
know
you
want
a
consistent
public
key
for
a
given
phone
number
and
you
want
the
property
that
no
network
adversary
can
partition
the
network
in
some
way.
That
would
you
know,
disrupt
the
end-to-end
encryption
capabilities
of
communications
Networks.
D
Yeah
just
a
short
bit,
so
thanks
Ari
for
filling
in
do
we
have
maybe
I'll
go
find
them.
We
should
put
links
to
the
buff
videos
in
the
in
the
Hedge
docks
to
make
it
easy
yeah.
So
I
got
a
similar
impression.
I
had
a
bit
of
a
dialogue
on
the
chartering
process
and
I
think
the
words
they're
using
look
like
a
huge
overlap
and
I
also
think
it's
kind
of
confusing
key
transparency
and
certificate.
D
Transparency
to
me
are
extremely
closely
related
things,
but
maybe
they're
further
away
in
these
groups
than
than
it
seems
because,
indeed,
when
I
questioned
the
sort
of
aims
or
the
overlap,
the
response
that
I
got
back
was
very
much
focused
on
a
user-centric
personal
privacy.
Anti-Stooping
prove
these
are
the
so
the
reason
it's
looking
at
bits
of
keys
is
prove.
These
keys
are
actually
the
keys
that
were
made
over
there
and
not
some
that
were
replaced
in
the
middle,
which
is
a
very
special
use
case.
D
I
Problem,
it's
just
like
a
different
different
thing:
that's
stuck
in
the
than
the
logger
in
the
tree
at
the
end
of
the
day
and
there's
there's,
of
course,
like
deployment,
specific
considerations
that
go
into
what
goes
in
the
log.
With
regards
to,
for
example,
who
owns
the
thing
that
goes
in
the
log?
Who
is
the
public
key
correspond
to
who
produced
the
software
artifact
whatever,
but
like
the
core
of
this
work?
That
is
like
how
the
law
is
structured,
how
proofs
are
generated?
Who
audits
the
log
all
that
stuff?
D
I
think
that's.
The
crucial
difference
is
that
I
I
would
be
inclined
to
agree
with
you
and
the
reason
we
started
this
thread
is
that
for
a
great
many
use
cases,
the
writer
answer
just
from
an
efficiency
of
work,
point
of
view,
if
nothing
else
would
be
to
use
skit
and
cozy
Merkel
tree
proofs
to
do
all
this
stuff,
the
pushback
on
that
opinion.
C
D
D
If
a
friend
comes
at
you
and
and
if
they
want
to
solve
those
use
cases,
we
could
expand
our
scope
and
our
on
our
Tech
to
solve
those
use
cases,
but
I
think
we're
not
quite
there
yet,
and
the
the
interesting
question
would
be
whether
they
are
constrained
to
that
or
whether
we
accidentally
get
this
big
overlap
that
we're
talking
about,
but
that
that's
that's,
where
I'm
kind
of
convinced
that
there
is
other
work.
That's
that's
worth
doing,
not
to
say
that
they're,
in
many
cases,
very
overlapping.
D
F
Yeah
I
think
there
is
a
big
difference
there
from
what
I've
seen
and
I
did
did
view
all
those
they
were
great.
It
seems
like
they
do,
have
a
different
problem
at
hand.
At
least
constraints
on.
It
are
different
in
that
they
have
a
much
higher
volume
of
participants
and
we're
probably
looking
at
here
and
those
participants
are
like.
The
the
the
entities
that
are
probably
submitting
to
skit
are
are
less
likely
to
have
any.
F
You
know
problem
with
identifying,
like
they
probably
have
a
domain
name
already
associated
with
them,
for
example,
and
whereas
just
people
messaging
each
other
or
something
don't
really
have
that
they
might
have
an
email,
something
less
significant.
So
so
I
think
that
those
constraints
are
different
enough,
such
that,
if
I
were
making
a
call
myself
with
no
one
in
the
room.
F
I
would
say
that
that
if
we
try
to
overlap
with
what
they're
doing,
then
we're
going
to
get
ourselves
with
a
lot
of
features
that
we
don't
need
and
features
that
they
that
we
need
that
they
don't
have
so
so.
I
think
that
that
I
would
not
push
for
for
trying
to.
But
I
think
we
should
still
be
very,
very
cognizant
of
what
they're
doing
and
and
what
the
issues
are,
that
they're,
seeing
making
sure
that
those
are
dealt
with
on
our
site.
F
A
A
E
Thank
you,
honest,
yeah,
I
think
we
need
to
also
keep
in
mind
that
this.
This
is
not
a
green
field
opportunity.
There
is
a
fairly
large
supply
chain
implementation,
that's
underway
that
that's
existed
for
you
know
a
few
years
you
know
things
like
signed
software
products
and
so
on
and
so
forth.
So
whatever
we
do
here,
hopefully
it
will
be
Center.
You
know,
synergistic
with.
What's
out
there
already
I!
E
Think
that's
going
to
be
important
to
adoption
of
skit
is
that
we
can
accommodate
the
practices
that
are
already
being
used,
but
we're
adding
some
value
that
people
will
will
find
useful
like
the
authenticity
and
integrity,
verification
components
that
will
help
bring
that
trust
to
the
to
the
public,
so
that
they
can
check
this
registry
or
transparency
service
to
see
if
a
piece
of
software
is
indeed
really
trustworthy.
Thanks.
A
J
I
B
C
A
commuter
is
the
abbreviation
for
concise,
Merkel
tree
proofs.
There
are
two
types
of
them,
but
I'm
not
going
into
the
details
here.
So
we
were
why?
What
are
we
doing
here?
We
are
standardizing
two
tiny
fragments.
One
of
them
is
about
the
sign
statements.
It's
what
the
issuer
the
supply
chain
entity
emits
as
the
as
the
actual
statement
about
the
supply
chain.
C
That
is
the
sign
statement,
and
then
we
use
the
transparency
service
to
to
give
some
additional
assurances.
That's
what
the
transparent
statement
then
is,
and
that's
basically,
the
sign
statement
plus
the
receipt
and
the
receipt
is
the
other
tiny
thing
that
the
standardizing
here,
and
so
therefore
it
is
too
cozy
using
envelopes.
The
science
team
is
rather
straightforward.
I'm
not
going
into
details
about
that.
The
receipt
needs
to
include
information
about
the
trees
used.
There
is
not
just
one
tree
out
there.
C
There
are
different
flavors
of
ash
trees.
There
are
balanced,
they
are
small,
they
are
labeled,
they
are
a
lot
of
again
mechanisms
and
metadata.
You
can
add
to
that.
There
are
consistency,
proofs
and
inclusion
proofs
and
such
so.
What
are
we
doing
here?
We
are
going
overloading
a
a
receipt
that
is
just
for
skit.
C
Then
we
decided
to
cut
it
into
halves
if
we
go
to
the
Cozy
world
and
make
a
generic
Mercury
proof
document
there
that
already
exists,
and
then
I
wanted
to
profile
that,
for
example,
foskit
trying
to
do
that
we
realized.
Now.
That
is
a
lot
of
things.
We
overload
this
document
with
also
we
are
already
initially
overloading
it
with
a
cherry-picked
algorithms
that
might
be
a
little
bit
too
much
and
it
actually
might
be
contested
somehow
under
question,
and
so
so
I
think
we're
diving
that
back
I.
C
Think
Ari
is
the
leader
of
this
document
and
you
can
add
something
from
this
point
of
view
after
I'm
I'm
done
with
this.
So
what
we
did
is
we.
We
decided
to
use
the
one
algorithm
as
a
hash
algorithm
for
trees
that
is
already
known
in
the
iitf,
and
that
is
for
certificate
transparency
that
is
already
an
RFC,
and
so
when
you
want
to
enumerate
algorithms
for
trees,
we
just
start
with
the
one
that
is
well
known
in
the
ITF,
make
a
cozy
structure
for
that.
C
That
is
basically
the
basis
for
all
the
other
things
and
the
receipt
and
and
we're
not
only
doing
that
I
think
it's
it's
a
good
current
practice
at
the
moment
to
to
start
a
base
document
and
immediately
a
profile
for
it.
So
you
understand
that
we
had
looking
at
the
second
document
how
to
profile
the
base
document.
The
base
document
comes
with
a
very
known
algorithm
and
the
profile
document
will
come
with
a
not
so
well
known,
algorithmet's,
also
popular
and
I.
C
Think
it's
CCF,
depending
on
the
author's
decision
and
so
going
from
there.
We
now
have
the
agreement
I
think
internally
how
to
proceed
with
this.
We
are
doing
a
cozy
document
that
is
still
the
concise
Mercury
proofs,
with
just
a
single
algorithm
from
CT
that
is
well
known,
establishing
the
registry
and
immediately
in
parallel
having
a
profiling
document
for
the
base
document,
says
how
to
add
other
algorithms
to
the
registry
and
how
to
describe
the
extensions
to
the
structure
that
is
used
in
sibo
here
so
I
think
that's
the
current
Way
Forward.
C
It
took
a
while
to
find
our
sweet
spot
here.
To
be
honest,
especially
with
the
Chun
and
involves
stakeholders,
and
especially
with
a
lot
of
inputs
here,
I
think
that's
that's
the
way
we
want
to
do
it
right
now
and
that's
why
I'm
highlighting
this
again.
This
is
not
about
the
science
statements
about
the
receipt
structure,
we're
doing
cozy
first
CT
first
and
the
Pro
5
CCF,
probably
in
parallel,
and
therefore
we
should
have
a
good
basis.
C
Open
items
are
registration
policies
at
the
time
of
creation
of
the
C
because
they
can
alter
the
believability
of
receipt
and
einsight.
So
a
receipt
might
might
need
a
link
back
to
the
registration
policy
enforce
at
the
point
of
creation
of
receipts,
to
understand
who
was
allowed
to
put
a
sign
statement
into
the
service
at
the
time.
C
C
C
Exactly
it's
not
there
yet,
unfortunately,
I
I
was
I
was
counting
on
it
a
little
bit,
but
unfortunately
as
availability,
always
as
far
as
we
are
probably
going
to
do
it.
This
week
we
are
agreed
on
the
file
name.
We
agreed
on
content
and
I
think
we
have
to
move
on
the
pull
request.
It
exists
on
the
links
that
already
probably
shared
I'm
checking
this.
E
C
C
A
J
J
A
prototype
implementation
and
it
follows
the
latest
pull
requests
on
the
draft
and
it
defines
cozy
representation
of
assigned
inclusion,
proof
and
a
cozy
representation
of
a
signed
consistency.
Proof
and
those
are
the
two
proof
types
that
RFC
9162
defines
which
is
RFC.
9162
is
the
certificate
transparency
RFC,
which
defines
the
minimal
consistency
proof
for
our
binary
Merkle
tree.
So
there's
good
reason
to
implement
that
particular
algorithm,
because
it's
you
know,
provably
the
smallest
consistency
proof
for
an
append,
Only
log.
That's
it.
J
A
A
D
G
D
A
H
B
C
It
is
kind
of
inline.
Ray
has
its
opinion
here,
but
I
think
I
can.
If
you
would
like,
if
there's
agreement
on
this,
if
there's
a
yes
give
us
a
proposal,
I
can
do
a
PR
on
the
definition
of
a
pen,
Only
log,
that's
pretty
concise.
I
can
run
it
with
Ray
reviews.
Okay
with
that
and
some
other
initially
I,
don't
know
early
Alpha
testers
for
the
text,
and
then
we
can
go
from
there.
If
you
want
this,
I
I,
don't
think
it's
a
blocker.
G
C
F
C
D
J
J
K
My
remembrance
of
this
is
that
even
the
configuration
changes
need
to
be
recorded
and
generate
a
receipt
onto
the
append
Only
log,
so
we
know
that
it's
there.
The
real
question
was
any
other
receipts
generated,
needs
to
be
able
to
point
at
what
the
registration
policy
they
were
acting
on
at
the
time-
and
this
is
what
this
discussion
was
about.
A
C
So
foreign
would
be
nice
if
two
different
transparency
servers
would
immediately
by
by
Design,
understand
what
to
look
at
and
how
to
resolve
it,
and,
and
so
so
that
that's
I
think
one
one
of
the
aspects
here.
Of
course,
it
would
be
nice
to
have
a
a
standard
way
to
to
resolve
the
policy
and,
as
Ray
already
sorry
as
foreign.
C
Assertions
in
the
in
your
own
tree,
so
so
the
registration
policy
of
the
tree
can
be
stashed
in
the
tree
and
there
will
be
a
specific,
very
known,
feed,
for
example,
inside
HV,
and
that
the
the
the
pointer
back
to
these
policies
could
be
standardized
in
that
way
to
to
have
a
well-known
feat,
so
to
speak.
That
has
always
to
exist
in
a
transparency
service,
so
that's
maintained
a
history,
and
that
is
the
decision
to
be
made.
I
think
that
is
an
excellent
Way
Forward,
but
I'm
not
sure
if
everybody
agrees.
C
So
that
is
basically
the
topic.
Do
we
want
to
have
well-known
Feats
for
certain
things
and
just
to
give
another
example,
the
trustworthiness
of
a
processing
node
in
a
tree
called
stash.
It's
Red's
things
in
a
tree,
basically
about
frustrating
is
right,
so
so
there
could
be
a
few,
a
limited
number
of
of
feeds
that
we
would
support
and
are
mandatory
to
implement
for
certain
assertions
about
the
the
three
service
itself.
The
transparency
service
itself,
and
one
of
them
is
definitely
the
registration
policy.
C
E
Thank
you,
harness
yeah
I.
One
thing:
that's
really
important
from
a
consumer
standpoint
is
the
ability
to
you,
know,
verify
and
validate
these
identities
and,
of
course,
the
ability
to
do
that.
I
think
skit
has
a
role
in
part
of
that,
but
it's
it's
not
alone.
It's
not
the
only
party.
That's
involved,
for
example,
using
an
x.509
certificate.
E
You
know,
as
a
consumer
I
want
to
know
two
things
is
that
an
is
that
an
authentic
entity,
an
identity
and
is
it
still
valid
and
that's
still
valid
part
is
important,
because
these
these
certificates
can
be
invalidated
because
of
many
reasons
they
can
be
found
to
have
been
used
to
sign
malware
and
they
can
be
invalidated.
So
these
are
important
aspects
that
I
don't
think.
Skit
is
going
to
be
able
to
maintain
a
constant
update
on
validity,
I
think
that
has
to
come
from
another
party
who's
monitoring
for
for
those
valid
certificates.
Thanks.
A
K
Yeah,
that's
a
dick.
The
problem
becomes
the
time
validity
of
certificates
is,
is
a
problem
so
being
able
to
do
that?
Forevermore
is
impossible
at
the
current
fix,
509
capabilities.
The
whole
point
of
the
notarization
is
to
basically
say
at
the
point
in
time
the
evidence
was
received.
Here's
what
the
state
of
that
identity
was,
and
that
is
your
longer
term
ability
to
audit
the
signature.
Yes,
you
basically
need
to
be
able
to
know
the
identity
of
who
signed
it,
but
the
ability
to
check
it
is
limited
to
a
very
finite
window.
K
The
statement
that
it
got
it
revoked
at
some
point
is
why
we
get
into
the
discussions
of
endorsements
and
claims
saying
hey.
This
has
been
revoked
as
a
product
with
a
negative
endorsement.
Backfills
this
whole
conversation
I
think
you
we
need
to
get
out
of
Simply
using
x509.
Revocation
as
a
way
is
the
only
way
to
invalidate
things
it
just
doesn't
flow.
It
doesn't
work
past
a
finite
window
of
two
years.
K
Well,
that
better
alternative
is,
is
basically
that
you
kind
of
need
to
know
that
there's
a
number
of
problems
with
individual
signatures.
Is
you
now
have
to
push
out
a
new
set
of
trusted
roots
from
across
the
world
and
I?
Don't
think
we
want
300
more
Roots
being
sent
around
as
here's
how
you
here's
trusted,
Cas
and
so
forth.
Yeah.
H
So
so
on
Dick's
thing
if
I
may
interpret
their
dick
for
you,
you
first
said
this
is
a
you
know.
This
is
something
that
we
have
to
work
into
the
existing
infrastructure
and
for
that
reason,
I
think
he's
right.
You
have
to
have
some
way
of
bridging
to
certificates,
while
understanding,
obviously
the
drawbacks
that
Roy
mentioned
here
so
yeah
so
I
think
that's
that's
a
good
question.
H
I
have
my
hand
up
for
a
while,
so
I
wanted
to
just
jump
in
here
and
the
the
topic
I
wanted
to
discuss.
Was
you
know
the
policy
piece
besides?
If
there's
a
policy
right,
the
way
we've
kind
of
architected.
This
thing
is
that
it's
supposed
to
be
somewhat
administrator
independent,
even
though
in
reality
it's
probably
going
to
be
trusted
third
party
most
of
the
time
implementing
it,
but
who
is
in
charge
of,
for
example,
stating
you
can
only
use
spdx
and
one.
K
K
H
Don't
agree
and
I
guess,
but
I
do
think
there
is
a.
There
is
a
missing
piece
here.
It's
kind
of
a
vacuum
on
who
gets
to
talk
about
policy,
because
otherwise,
if
it
is
in
fact
a
you
know,
administrative
independent
architecture,
you
could
end
up
having
policies
in
there
from
all
kinds
of
untrusted
sources,
and
then
everyone
would
have
to
evaluate
the
policy
for
its
trustworthiness
independently.
H
K
The
the
trick
here
to
understand
is:
if
we
do
it
whatever
way,
we
we
pick
here
either
it's
by
the
receipt
of
the
policy,
we're
pushing
that
as
a
requirement
for
anything
on
top
that
has
to
support
search
right.
So
there
is
some
ripple
effect
of
how
we
encode
this
putting
on
the
outer
system
as
to
what
basic
search
requirements
we
kind
of
need.
H
H
K
H
H
A
H
A
H
A
C
Really
quick,
so
personally,
my
personal
point
of
view
is
that
we
need
to
provide
the
in
in
in
data
formats
speak.
We
need
to
provide
the
place
for
the
very
to
put
the
pointer
through
policy
too.
Yes,
I
think
that
that's
that's
pretty
mandatory.
If
there's
other
opinions
about
this,
please
say
so
on
the
list
or
here
I
think
that's
highly
important
because
you
have
to
detect
if
that
pointer
changes
that
could
be
a
buy
compute
right.
So
you
can
just
have
like
four
ages,
the
same
pointer
and
suddenly
changes.
C
Then
you
have
to
understand
what's
pointing
to
now
right,
so
this
indication
of
change
of
policy
that
might
impact
your
trust
in
the
service,
it's
highly
important
to
Consumers
of
the
receipt,
and
that
is
why
it
should
be
indicated
already
in
the
receipt
blessing
and
and
and
how
to
deal
with
it.
That
is
a
more
complicated
question
right
to
resolve
it.
Do
we
do
degree
standard
ways
to
represent
it?
I
don't
know
so
so,
but
I
think
the
the
place
has
to
be
there.
I
think
that's
it.