►
From YouTube: DRIP WG Interim Meeting, 2020-10-28
Description
DRIP WG Interim Meeting, 2020-10-28
B
A
A
A
B
C
C
Yeah,
so
so,
for
this
one
we
have
seen
some.
I
would
say
some
comments
on
the
list
about
the
whether
we
need
to
merge,
I
would
say
the
architecture
and
the
solution
draft.
I
think
this
is
something
that
was
read
by
miss
stewart
yeah
as
chairs
we
don't
we
don't,
we
are
not.
I
would
we
don't
think
it's
it's
a
good
idea
to
have.
C
I
would
say,
to
merge
the
dissolution
documents
with
the
architecture
that
we
want
really
to
be
a
reference
document
so
that
the
people
who
are
working
on
drip
to
understand
really
the
scope
of
what
we
are
doing
and
also
this
really
is
grafting.
I
would
say
the
individual
solution
to
the
architecture.
C
So
we
we
really
yeah,
really
recognize
there.
We
see
the
important
effort
that
made
by
a
basic
word
on
say
on
the
past
versions
of
this
of
this
document,
and
we
would
like,
I
would
say,
to
balance
the
effort
and
the
various
documents
we
have
so
far,
so
we
have
adam
who
is
working
on
the
authentication
on
the
claims
document
bob
on
the
on
the
s,
air
id
and
stewart
on
the
requirement.
C
So
we
thought
that
it
would
be
a
really
good
if
we
have
someone
else
with
fresh
ideas
and
fresh
eyes
on
the
on
the
academic
draft.
So
we
have
asked
sure
if
he
he
can
accept
to
to
take
the
delete
on
this
one.
So
he
he
is
really
okay,
and
this
is
a
good
news
so
that
he
can
take
the
the
editor
lead
on
the
architectural
draft.
So
the
really
the
next
step
for
this
one
is
is
mainly
to
to
prepare
it
for
the
working
of
last
call.
C
A
A
E
A
Yeah
sure,
so
my
understanding
is
that
what
you
probably
have
to
to
see
is
that
every
pieces
that
we
will
define
so
it
includes
the
rid,
but
it
also
includes
the
authentication
firmware,
but
it
also
includes
the
registries
with
the
dns.
For
example,
all
these
pieces
have
to
be
linked
somehow
together,
and
I
my
guess,
is
that
the
architecture
document
should
be
it's
not
it's.
I
mean,
I
would
say,
defining
defining,
but
it's
not
going
to
be
a
normative
document.
A
A
A
I
think
in
our
case,
because
we
only
have
one
solution:
we
we
can,
we
can
afford
not
to
be
too
generic,
but
we
should
not
try
to
a
a
architecture.
A
document
expected
to
be
a
little
bit
conceptual
in
the
sense
that
we
are
not
trying
to
have
a
global
document
that
is
gonna,
repeat
our
id
authentication
framework
and
so
on.
E
That
sounds
great
and
I'm
glad
that
shui
has
found
the
time
to
step
up
to
provide
some
relief,
and
I
want
to
remind
everybody
that
andre
also
volunteered
to
help
with
this
and
he's
been
stymied
by
my
lack
of
providing
him
with
what
he
needed
to
to
get
started.
So
my
focus
for
the
next
36
hours
is
going
to
be
making
sure
that
all
the
co-authors
and
shui
in
particular,
have
all
of
the
inputs
that
received,
and
hopefully
I
can
figure
out
how
to
sort
them
out.
H
Well
thanks:
this
is
a
straight
thanks
to
I
think
when
I
said
yes
to
to
daniel
adamad,
I
I
wasn't
thought
that
no
it's
it's
going
to
be
rewrite.
I
mean,
I
think
I
think.
As
a
beginning,
when
we
started
the
architecture
draft,
the
initial
idea
should
be
generic,
and
now
I
think
it's
it's
not
great,
because
at
this
moment
the
the
architecture
traffic
is
all
it's
only
including
the
generic
concept
and
as
as
stu
mentioned
already,
we
did
not
define
the
architecture.
C
Yeah
yeah,
just
before
before
giving
the
the
floor
to
eric
to
because
he
has
asked
to
yeah
the
you
can
just
one
comment:
we
are
not
changing
the
scope
of
the
draft.
We
are
just
helping
the
the
team
to
move
forward.
So
that
means
that
you
need
to
what
we
have.
You
have
a
list
of
comments
and
the
that
need
to
be
to
be
implemented,
and
then
your
your
in
their
in
your
role.
You
will
you
will
help
moving
and
implementing
this
comment.
So
that's
the
the
point
I
want
to
make
eric.
Please.
F
Yes,
so
sorry,
first,
I
would
like
to
apologize
for
joining
late.
This
quote
by
a
few
minutes,
so
I'm
is
part
of
the
stu
presentation
and
just
arrived
at
the
point
where
stu,
probably
and
with
quotes
around
it,
because
I
arrived
late,
you
probably
said
that
the
architecture
is
coming
from
another
sdo
assuming
is
faa.
E
My
thought
is
that
what
has
been
defined
externally
provides
pretty
much
only
an
identity.
It
fails
in
two
respects.
It
doesn't
make
that
trustworthy
and
it
doesn't
make
it
immediately
useful
for
much
of
anything,
and
so
the
requirements
for
drip
go
beyond
the
requirements
for
narrowly
simply
providing
an
unverified
id
to
making
it
a
trustworthy
id
and
making
it
something
that
can
be
immediately
put
to
use
to
establish
communications
or
look
things
up
in
a
database
or
whatever.
F
A
G
A
A
A
I
mean
when
a
new
I
mean
the
architecture
document
should
not
be
it's
basically
a
starting
document,
so
it
doesn't
need
all
the
document
to
be
finalized
and
new
documents
might
be
created
after
the
architecture
document
is
published.
So
just
one
clarification
are
we
done
with
the
architecture.
Questions
comments,
thoughts.
E
So
I'm
guessing
that
at
least
those
of
us
who've
been
around
for
a
few
years,
had
seen
this
joke.
The
earliest
reference
I
found
to
it
was
from
like
1993
on
this
site
that
I've
linked
and
just
just
jumped
to
the
bottom
line.
All
the
other
stuff.
That's
out
there
about
rid,
provide
a
nominally,
correct
answer.
We
try
to
provide
a
trustworthy
and
immediately
useful
answer
and
to
eric's
earlier
points.
This
is
how
drip
goes
beyond
narrow,
uas
rid
as
specified
externally
next
slide.
A
Okay,
so
yeah
so
for
for
for
the
people,
I'm
not.
I
mean
in
my
case
for
the
reviews,
I'm
not
asking
a
response
for
it.
Any
reviews
I
provide,
I
think
I
mean
when
you're
editing
the
document,
take
all
the
reviews
and
we
will
provide
the
next
reviews
later
on.
So
I
mean,
I
think,
the
the
the
what
should
be
prioritized
is
to
have
an
o5
version.
E
Do
you
want
me
to
proceed
yeah,
yeah,
yeah,
sure,
okay,
so
this
long
laundry
list
is
all
of
the
things
that
have
been
done
to
requirements
04
in
the
last
month
to
yield
requirements.
O5,
let's
see
what
here
should
be
highlighted,
the
second
bullet,
the
whole
document
has
been
massively
restructured
because
there
was
a
lot.
The
introduction
was
ridiculously
long
and
had
a
lot
of
details
in
it.
E
Okay,
there
were
three
things
that
had
been
suggested
by
one
or
more
individuals
on
which
we
did
not
have
working
group
consensus
to
rename
the
document
to
remove
definitions
of
terms
that
we
didn't
use
in
that
document.
Even
though
we
were
likely
to
use
them
in
other
drip
documents
and
to
weaken
any
of
the
privacy
requirements,
then
there
were
five
suggestions
that
had
been
made
that
I
just
plain,
don't
know
how
to
do.
E
I
don't
know
how
to
say
the
multicast
requirement
any
more
clearly
than
I've
said
it.
I
gave
a
definition
of
aaa
which
actually
has
seven
terms
rather
than
three,
because
it
has
been
my
experience
that
every
author
picks
a
different
three
of
those
seven
terms
and
so
to
verify
that
I
took
all
of
the
seven
choose
three
permutations
of
those
terms:
googled
every
one
of
them
and
discovered
that
every
one
of
them
has
broad
support.
E
Although
a
couple
of
orders
of
magnitude
difference
in
popularity
of
the
different
subsets
of
three,
so
I
left
that
definition
alone,
I
didn't
attempt
to
define
authentication
or
any
of
the
other
words
in
aaa,
and
I
didn't
attempt
to
define
ridge
service
and
that's
a
great
embarrassment
to
me,
because
I
know
what
a
ridge
service
is,
but
that
is
intuitively
from
having
read
lots
of
documents
and
working
in
the
field.
I
do
not
find
rich
service
actually
defined
explicitly
anywhere,
and
so
I
cannot
cite
such
a
definition.
E
E
And
finally,
I
don't
want
to
remove
the
brief
description
of
the
discovery
and
synchronization
service
and
the
uas
traffic
management
system,
because
I
do
not
believe
that
rid
can
be
understood
without
that
context,
and
then
finally,
bob
did
a
review
of
dash
05
two
days
ago,
which
obviously
that
review
is
not
in
dash
o5.
It
would
have
to
be
in
dash
06
if
we
feel
that
an
06
is
a
worthwhile
thing
to
do.
E
At
this
point,
bob
has
agreed
that
most
of
these
things
are
minor,
but
one
thing
that
may
be
significant
is
he's
suggesting.
Maybe
we
need
some
more
ascii
art,
because
there's
more
than
one
variation
on
how
the
data
flow
may
go
in
network
remote
id.
So
I'd
like
to
pause
here
and
open
the
floor
to
any
yelling
and
screaming
about
these
things
that
I
didn't
do.
D
B
B
I
should
probably
not
click
on
a
thing
and
start
putting
spaces
everywhere.
I
just
want
to
point
stu
if
casey's
not
paying
attention
to
the
chat,
because
there's
some
good
comments
in
the
chat
from
eric,
carson
and
alex
here,
but
I'm
of
the
agreement,
I
think,
with
alex
that
triple
a
is
about
access
control
at
iets
specifically
and
I'm
tainted
because
of
work.
I've
done
I'm
more
versed
in
other
areas,
so
I
see
aaa
as
the
full
seven
terms.
So
I
can't
really
say
much
on
that.
B
B
E
E
Okay,
here
are
the
actual
numbered
requirements
changes.
There
were
massive
changes
to
the
document
going
from
four
to
five,
but
there
were
minimal
changes
to
the
numbered
requirements,
which
makes
me
very
happy.
Apparently,
people
did
have
a
pretty
good
consensus
on
you
know
where
the
rubber
ultimately
meets
the
road.
I
had
abbreviated
end
to
end
as
e2e.
E
E
There
were
a
couple
of
requirements
that
said
that
you
either
must
not,
or
must,
in
the
case
of
public
and
private
respectively,
restrict
access
based
upon
the
identity
of
who
was
asking
the
question,
and
that
was
expanded
to
identity
or
role.
It's
not
that
I'm
stu,
it's
that
I'm
the
editor
or
whatever.
Also
we're
periodically
reminded
that
my
writing
tends
to
be
u.s.
A
A
few
minutes
discussing
those
changes
that
have
not
been
done
just
so
that
you
get
a
feedback
from
the
working
group.
What
I'm
afraid
is
that
if
we
bring
back
to
the
mailing
list,
I
mean
it's
gonna
stall
for
a
long
time.
So
I'm
wondering
if
there
are
any
comments
that
can
be
helpful
to
move
the
document
move
forward.
C
C
To
that
I
would
say
to
that
message
from
from
stillwater,
so
the
plan
I
I
would
personally
attempted
to
to
suggest
that
the
steelwork
prepared
new
revision
of
the
draft
to
take
into
account,
I
would
say,
depending
issues
that
are
not
in
2d
this
version
and
then
see
any
comments
that
we
will
have
by
then
and
run
a
one
week.
Last
last
call
to
check
that
all
tanks
are
are
there
and
then
we
can
ship
the
document
to
to
eric.
E
So
the
only
ones
that
are
actually
in
my
queue
at
this
moment
are
the
very
last
line
on
this
slide,
based
upon
bob's
review
of
dash
05,
which
is
the
only
explicit
review
of
the
document
that
I
received,
and
bob
has
said
that
all
of
these
are
minor
and
he
could
live
with
the
document,
as
is
bob's
online.
So
he
can
correct
me
if
I'm
wrong,
except
possibly
for
the
ascii
art
the
ascii
art
may
require
revision
or
the
insertion
of
a
couple
more
document.
E
G
And
I
think
that
the
way
some
delivery
services
are
going
to
be
are
looking
at
this.
We
need
to
reflect
that
and
that's
why
I
had
in
my
comment
that
there
may
be
direct
from
the
ua
from
from
that
delivery.
Drone
for
the
network
id
communication
to
their
lt
connection,
that
they're
going
to
undolly
have
or
5g
connection.
G
G
A
Yeah,
okay,
so
if
we
don't
have
any
huge
concerns,
I
think
you
can
continue
the
conversation
with
bob.
I
still
believe
that
I
mean
we.
We
don't
expect
in
the
next
version,
some
huge
changes
from
what
we
have
now
and
if
that's
the
case,
it's
an
invitation
to
the
people
to
have
a
look
at
the
document
to
review
it
so
that
we
can
and
say
if
they
agree
with
the
document
or
not,
so
that
we
can
ship
it.
A
A
E
E
F
Yeah
just
to
check
on
some
dates,
so
the
deadline
competition
date
before
the
atf
is
next
monday,
midnight
european
nightly
time
a
little
bit
of
time
and
then
typically
the
last
goal
around
the
itf
time
is
three
weeks
and
not
two
weeks
just
to
allow
people
to
get
more
time
beside.
It
is
perfectly
fine
and
the
question
to
be
asked
at
some
point
of
time.
Do
you
want
to
publish
the
architecture
and
the
requirements
all
together.
A
I
I
mean
it
would
be
good,
but
I
don't
see
that
necessary
and
maybe
I'm
I
would
try
to
well.
I
would
probably
send
avenue
this
is
me
might
disagree
with
me,
but
I
don't
care
sending
a
document
to
eric
as
soon
as
possible,
but
I
I
would
understand
that
eric
says
yeah.
I
prefer
to
have
the
architecture
document
ready
because
that's
easier
to
read
and
understand
the
requirement
document.
F
And
that's
basically
my
point:
you
got
it
right
danielle,
so
mostly
what
will
happen
and
it
will
be
my
decision
right.
That's
before
launching
the
itf
last
goal
to
the
complete
community
is
to
get
the
two
documents
together.
As
one
I
mean
there
are
twins
right.
You
can't
really
understand
one
without
reading
the
other,
they
need
to
go
together.
D
A
A
H
E
H
Just
one
quick
comment
for
us
to
just
really
for
the
first
bullet
clarify
drip
scope
in
the
requirement.
I
don't
understand
why
we
needed
to
clarify
scope
being
the
requirement
it
should
be
in
the
charter
right.
If
people
have
issues
to
understand
the
scope
is
referred
to
the
charter,
I
don't
think
we
should
do
any
clarification
in
the
requirement.
Fact
that
make
sense
to
you,
though,.
B
Yeah
mine
should
be
fairly
quick,
all
right,
so
I'm
going
to
remove
the
mask,
so
you
guys
can
hear
me
a
bit
better.
Hopefully
all
right
next
slide,
please
daniel
drip
charter.
Just
in
case
someone
has
not
seen
it
trustworthy
internet
local
connect
scenarios
so
the
overview
so
there's
been
some
discussion
back
and
forth
between
me,
stu
and
bob
on
between
editors
on
claim
versus
certificate.
B
I
think
I
want
to
keep
this
to
the
list,
but
I
want
to
bring
up
that
this
discussion
is
going
to
happen
on
the
list
we
chose
claim
originally
because
certificate
had
some
connotation
to
it.
Revolving
around
x,
509s
stu
sent
a
email
to
the
list
earlier
this
morning
and
I
believe
karsten
and
hank
and
michael
answered
to
that.
Adding
to
that
discussion.
So
that's
where
that
discussion
is
the
decision
is
in
flux,
so
that
will
be
feedback
to
come
to
the
next
one.
B
The
identity
claims
are
special
to
the
uas
ecosystem
for
remote
id
and
it's
binding
stuff.
The
possibility
of
a
draft
name
change,
I'm
thinking,
changing
it
to
identity
proofs,
to
try
to
encompass
certain
claims
and
not
choose
one
over
the
other.
I
would
like
some
comments
on
that,
but
we'll
get
into
that.
Once
people
read
the
draft
a
bit
more
and
I
get
into
details
on
it
next
slide
so
changes
since
version
zero
one.
So
the
draft
originally
was
all
in
xml.
B
I've
switched
it
over
to
markdown
to
make
my
life
easier,
and
I've
noticed
significantly
that
a
lot
of
the
text
was
broken.
So
I
updated
a
lot
of
the
text.
I
basically
grew
all
the
text
out
of
the
document
put
it
in
word
and
started
rewriting
it
because
it
was
just
a
mess,
as
such
references
were
lost
during
the
conversion.
B
B
B
So
this
is
the
cscxx
form.
It's
a
self-signed
unverified
claim
asserting
a
binding
of
an
hi
to
a
given
entity
known
as
x,
and
it's
116
bytes
in
length.
It's
basically
the
atomic
unit
that
I'm
using
for
all
of
these
claims
proofs.
What
have
you
and
three
of
them
are
created
during
a
provisioning,
and
you
can
see
the
listing
there,
aircraft
on
aircraft
operator
and
operator
and
registry
on
registry-
and
it's
kind
of
a
sub
form
next
slide.
B
B
There
are
three
forms
of
this
registry
and
operator
operator
and
aircraft
and
registry
on
operator
on
aircraft,
which
is
608
bytes
long
and
uses
the
crr
and
coa
as
its
two
certificates
within
it.
Next
slide,
please
yeah.
So
this
is
the
small
registry
on
aircraft.
This
is
the
200
by
certificate.
That's
used
in
broadcast
remote
id
asserting
the
binding
between
the
registry
and
the
aircraft.
B
This
might
be
going
through.
Some
changes
me
and
bob
have
had
some
discussions
where
bob
realized
that
the
structure
I
was
using
has
some
replay
attack
possibility
to
it.
So
this
will
be
changing,
hopefully
in
version
three,
so
I
won't
linger
on
this
too
much.
But
it's
what
we've
been
using
up
until
this
point
next
slide,
so
I'm
gonna
go
over
to
the
provisioning
process.
B
B
So
the
registry
provisioning
is
a
little
bit
complicated.
There
is
some
question
open
questions
on
this.
This
is
what
I've
been
thinking
at
the
moment
where
the
rra
and
the
hda
form
appearing
together.
How
the
rra
gets
provisioned,
I
think,
is
out
of
scope,
but
how
we
pass
delegation
down
through
and
trust
through.
It,
I
think,
is
important,
and
this
is
the
generic
way
of
just
doing
it
just
create
certs
and
have
signs
against
each
other
note
that
after
this
point
in
hda,
the
registry
is
referring
to
an
hda.
B
Registers,
creates
its
own
cert
and
there's
some
verification
checking
some
collision
checking
to
see
if
there's
points
in
dns,
so
that
hip
resource
record
can
be
added,
and
then,
if
it's
successful
you
get
back
certificates
next
slide
and
michael
has
put
some
stuff
in
the
chat.
I
see,
I
think
maybe
yeah,
there's
a
lot
of
discussion
in
the
chat,
so
aircraft
positioning
has
two
different
forms
that
we
have
seen
between
me
and
stu,
discussing
stuff
from
the
icao
work
and
what
we've
been
doing.
This
is
the
first
one.
B
This
is
the
operator
assisted
form
where
the
aircraft
can't
actually
on
its
own
connect
to
the
registry.
It
doesn't
have
internet
connectivity
on
its
own,
so
there's
this
dance.
That
happens
where
things
are
extracted
and
injected
back
and
forth
into
the
aircraft
and
sent
to
the
registry.
I
will
let
the
diligent
student
read
this.
There
is
some
text
there's
more
succulent
text
in
the
draft
this
process.
This
is
just
a
quick
run
through
on
what
it
is
next
slide.
B
So
the
standard
aircraft
provisioning
under
icao
requires
that
the
aircraft
be
able
to
connect
to
the
internet.
So
there's
a
token.
That's
passed
from
the
registry
through
the
operator
to
the
aircraft,
because
there's
a
two-star
two-step
process.
First,
that
the
operator
binds
the
aircraft
to
himself
and
tells
the
registry
I'm
taking
ownership
of
this
aircraft,
and
then
the
aircraft
saying
I'm
using
this
identity
for.
G
B
B
D
B
B
Are
and
I'm
wondering
if
anybody
has
any
comments
on
that
once
they
read
the
draft
next
slide,
I
think
it's
my
last
slide.
Yes,
this
is
my
last
slide,
so
any
questions,
comments
or
concerns.
Please
feel
free
to
do
them
read
the
draft
help
me
out
I'll
be
moving
to
the
architecture
in
a
little
bit.
So
that's
where
I'm
at
and
it's
getting
loud
here.
G
G
Here
and
my
concern
in
terms
of
the
ordering
in
the
certificate,
I
will
post
that
up
to
the
list,
take
what
I
send
a
private
message
to
adam
and
I'll
retake
that
that
that
message
and
I'll
post
that
to
the
list,
it
was
a
little
concern
in
terms
of
when
somebody
reads
it.
What
is
the
the
intention
of
the
the
claim,
so
I
will
present
that
for
this
and
let's
move
on
it
says,
as
daniel
just
said,.
F
G
Actually
I
had
sent
the
adam
accept
me
before
submitting
it.
He
sent
me
a
free
copy,
and
so
he
hadn't
submitted
it
yet,
and
I
sent
the
comments
to
what
he
said
what
he
sent
me.
He
took
some
of
those
comments
and
he
drafted
them
and
definitely
submitted,
and
some
of
the
comments
have
not
been
anybody
submitted.
So
I
will
take
what
he
didn't
do
and
I'll
turn
that
to
a
list.
B
I
So
adam,
if
I
could
speak
real
quick,
I
just
sent
a
response
to
the
mailing
list,
since
you
would
suggested
that
some
of
the
definitional
stuff
take
place
there.
What
I
wanted
to
just
point
out
briefly
is
in
connection
with
the
identity
in
the
medical
space,
some
of
the
work
I've
been
doing
there.
I
actually
came
up
with
what
I
called
the
identity
rosetta
stone.
So
I
looked
at
some
of
the
work.
That's
been
done
with
nist
with
the
wc3
dids
mixed
in
both
gdpr.
I
I
C
G
G
I
have
initial
section
on
the
non-transferability
of
hits,
which
is
kind
of
important,
but
I
don't
think
it's
adequate.
Yet
I
ex
expand
the
remote
id
authentication
section
3.4,
and
this
was
able
to
take
out
the
direct
reference
to
drip
off
my
goals.
I'll
say
at
the
end
is
get
is
to
make
this
document
not
reference
anything,
but
the
requirements.
Draft
moving
on.
G
G
The
other
thing
is
I've
added
support
for
the
8-bit
suite
id,
which
is
in
7401,
but
not
really
used
in
7401
and
and
I'll
go
into
what
and
then
the
form
part
for
discussion.
The
list
is
this
allows
an
hda
to
have
its
own
domain
of
suite
ids,
which
could
be
used
for,
say,
experiment,
experimentation,
purposes,
saying
quantum
post
quantum
use
or
something,
but
there's
no
provision
for
how
to
do
post
quantum
host
identities.
G
G
G
G
We
had
some
discussion
earlier
in
the
month
on
this
order,
change
and
I've
implemented.
This
is
important
and
I
believe
this
is
the
correct
order.
Moving
on,
I
fully
parameterize
the
length
of
all
fields,
and
this
is
for
alex.
I
pointed
out
the
value
to
this,
so
if
I
do
minus
the
prefix
must
be
20
or
less
no
bigger
than
28.
G
the.
If
the
info
equals
to
here.
This
is
not
variable,
so
the
orchid,
the
info
chemical
variable,
but
here
for
hardcore
hits.
The
input
is
always
32
bits
and
the
and
the
oga
is
only
four
or
eight
it's
it's
parameterized,
but
it's
either
four
or
eight
the
orchid
encoding.
I
added
the
context
id,
but
just
last
night.
I
realized
that
I
put
it
in
the
wrong
place.
G
So
that's
my
minor
restructuring
and
I
added
the
fixed
length
support
as
in
orchid
v2,
so
that
anybody
implementing
the
code
has
here
in
one
place
how
to
handle
both
rc
7401
orchid
needs
as
well
as
we're
doing
it
with
hierarchical
hits.
They
don't
have
to
look
at
two
separate
documents
to
get
it
right.
Moving
on.
G
G
G
This
is
the
other
big
change.
I
now
have
two
examples
of
the
self
claims,
and
these
are
examples.
They
are
loosely
written,
not
something
that
you
can
really
so
much
see
how
the
things
are
laid
together.
It
I've
addressed
a
repeat
attack
on
the
old
version
that
was
in
the
last
group.
It
was
my
bad
because
my
design
is
a
year
ago.
I
knew
that
I
had
to
be
careful
that
the
signature
was
on
the
current
time,
not
on
some
future
time,
so
that
somebody
can
play
this
claim
back
themselves.
G
G
Next,
I
have
the
offline
self
claim.
Please
note
how
is
necessary
to
turn
this
inside
out
to
address
the
replay
attack
and
and
then
I
will
have
a
little
bit
of
provisioning
in
there
and
then
include
a
text
on
how
the
server
could
do
it
by
the
way
the
the
84
bit
self
claim.
This
is
important
for
making
it
as
small
as
possible
as
little
overhead
as
possible
versus
adam's
116
bit
self
clay.
Moving
on.
G
And
appendix
f,
I
just
added
a
nice
little
table
of
here's
the
size
of
your
hash
and
here's
what
the
collision's
like
and
next
and
still
to
do.
I
referenced
the
crowd
source
rid
and
the
secure
network
id
c2
graphs,
and
I
said
you
should
change
me
to
move
these
dependencies
and
I'm
going
to
do
that.
I
want
this
document.
They
will
stand
on
its
own,
so
we
can
say
it
is
done.
There
are
no
dependencies
and
and
people
can
implement
it
and
work
with
it
without
while
we're
having
it
be
completed.
C
G
C
C
G
D
Do
you
hear
me?
Yes,
sir?
Yes,
yes,
this
is
alex
petrasco.
I
looked
closely
at
the
presentation
you
gave
bob.
Thank
you
for
the
presentation
and
I
was
happy
to
see
a
few
points
mentioned,
like
parameterizing
all
fields
within
hit,
and
but
of
course
I
would
need
to
read
again
the
documents
and
I
will
try
to
do
that
soon
and
then
post
on
the
mailing
list
about
these
modifications.
D
D
The
signature
based
on
time
and,
of
course,
it's
a
good
things
which,
but
which
brings
in
this
this
necessity
of
having
synchronized
time
between
most
entities
or
a
little
bit
of
synchronization,
or
here
we
talk
about
well.
We
are
not
sure
whether
this
all
these
entities
are
fully
connected
prior
to
being
authorized,
and
maybe
these
are.
D
These
are
things
to
to
consider
to
to
to
make
sure
when,
when
we
design
secure
things
that
are
based
on
time
that
these
entities
have
the
right
time
yeah,
I'm
I'm
putting
this
forward
since
I
have
noticed
in
practice
a
few
times
these
problems
with
time,
and
they
happen
at
least
twice
a
year
when
we
change
time
right.
We
just
changed
down
here,
so
it's
good
to
consider
this.