►
From YouTube: Key Event Receipt Infrastructure (KERI): A secure identifier overlay for the internet with Sam Smith
Description
https://ssimeetup.org/key-event-receipt-infrastructure-keri-secure-identifier-overlay-internet-sam-smith-webinar-58/
Samuel M. Smith will present KERI that stands for Key Event Receipt Infrastructure. Its a ledger-less approach to identity that enables a universal decentralized key management infrastructure (DKMI). KERI is the basis for a new proposed universal DID method DID:uni. Because KERI identifiers are portable they are truly self-sovereign. The primary root-of-trust in KERI is a self-certifying identifier that is cryptographically bound to a set of key-pairs. These have fully generalized derivation mechanisms including content addressability with support for both rotatable and non-rotatable key-pairs. Its secondary root-of-trust are end-verifiable key event receipt logs. End verifiability means that KERI is not dependent on any intervening infrastructure. This fixes the primary security weakness of internet identity system security overlays thereby making KERI a candidate for a universal trust spanning layer for the internet to replace DNS-CA. KERI is an open-source project within the Decentralized Identity Foundation.
Samuel M. Smith Ph.D. works at the intersection of AI, blockchain, and decentralized computing systems as both an entrepreneur and strategic consultant. He has written and continues to write seminal white papers on decentralized identity, reputation AI, distributed computing, and tokenomics. He provides strategic technical and business model guidance to startups in these fields and is active in shaping the underlying standards and driving their adoption. Samuel received a Ph.D. in Electrical and Computer Engineering from Brigham Young University in 1991. He spent 10 years at Florida Atlantic University, reaching full professor status before retiring to become an entrepreneur. He has over 100 refereed publications in the areas of machine learning, autonomous vehicle systems, automated reasoning, and decentralized systems. He was principal investigator on numerous federally funded research projects. Dr. Smith is an active participant in open standards development and is a serial entrepreneur.
A
This
needs
to
have
that
needs
to
happen.
If
you
really
want
to
achieve
that,
so
very
happy
to
have
stand
with
us
today
and
we're
gonna
go
briefly
to
the
next
slide.
To
tell
you
what,
as
I
meet
up
is
about
for
those
of
you
that
never
joined
us
before
so
SSI
meetup
is
basically
an
initiative
that
we
started
two
years
ago
that
is
open
to
everyone.
A
Who's
interested
in
their
society
doesn't
matter
what
you
do
or
where
you
are,
if
your
company,
an
individual
or
an
association
and
all
the
content,
we
share
here
this
shared
with
the
creative
comments
by
share
alike,
license,
which
basically
means
it's
open
source
and
you
can
reuse
all
the
material
that
is
being
published
here.
Only
thing
you
have
to
do.
Please
give
cut
it
back
to
the
creator
of
the
content.
Today,
please
give
credit
back
to
Sam
Smith.
A
If
you,
if
you
use
his
content
and
all
of
course
also
tests
I
meet
up,
then
everything
will
be
uploaded.
The
video
recording
of
this
presentation,
the
SlideShare
presentation
and
a
Google
slide
deck
itself
will
be
available
too,
so
you
can
download
it
and
use
it.
A
lot
of
people
are
doing
this
all
over
the
world.
A
If
you
have
any
questions
during
the
presentation,
please
bring
them
up
using
the
crashing
tool
and
I'll
share
those
questions
with
Sam
during
the
presentation
or
at
the
end
of
the
presentation
and
yeah,
and
that's
the
main
technical
stuff
we
have
recovered,
and
the
next
thing
is
to
go
into
the
really
interesting
stuff
that
Sam
has
to
share
with
us
today.
Sam
welcome
some
welcome
so
much
too,
as
I
meet
up.
Oh.
B
There
is
what
what
we
call
a
human
basis
of
trust,
how
we
interact
with
people
and
how
we
trust
them
and
in
person
we
have
developed
the
ability
to
trust
other
people,
because
we
can
know
them
in
person.
We
can
recognize
them.
We
we
know
who
they
are
and
and
therefore
we
have
a
basis
of
trusting
them,
but
on
the
internet
we
can't
really
know
somebody,
because
all
we
see
on
the
internet
are
bits
bits
transmitted
over
the
inner
Internet.
B
So
we
really
can't
trust
anyone,
because
we
don't
know,
we
just
know
bits,
and
so
we
need
to
replace
the
human
basis
of
trust
with
the
cryptographic,
root
of
trust
and
that's
the
core
of
carry
and
key
management
and
identify,
errs
and
and
everything
that
that
we
want
to
do
with
decentralize
identity
and
sell
sovereign
identity
is
that
we
have
to
start
with
something
we
have
to
start
with
the
root
of
trust
and
that
root
of
trust
is
based
on
verifiable
digital
signatures
using
asymmetric
key
cryptography.
Cryptography,
which
that
means
is,
is
that
we
we.
B
We
can't
trust
or
may
not
trust
in
what
was
said,
but
we
may
trust
and
who
said
it,
and
that
who
is
the
controller
of
a
private
key
from
a
public/private
key
pair.
So
we
we
can
digitally
sign
something,
and
we
know
that
the
controller
of
the
private
key
made
the
statement.
But
we
can't,
we
don't
know
that
the
statement
itself
was
valid
in
any
way.
We
just
know.
We
just
know
that
that
we
can
we
can.
B
We
can
make
attribution
to
the
controller
of
the
private
key,
and
so
the
route
of
trust
is
consistent
in
via
non
reputable
statements
from
the
digital
signatures.
That's
all
we
have
to
start
with.
We,
we
don't
have
anything
better
than
that.
That's
all
crypto
gives
us,
but
if
we
are
able
to
maintain
that
consistent
attribution
over
time
via
histories
of
these
statements,
then
we
can
build
trust
in
a
reputation
about
about
what
was
said,
and
so
people
often
confuse
trust
when
they
talk
about
trust
and
cryptography
and
identity
systems,
and
they
miss
this.
This.
B
This
connection
that
you
really
own
cryptography
only
gives
you
trust
in
in
the
that.
Somebody
that
controlled,
a
private
key
made
a
statement
and
everything
else
comes
from
consistent
attribution
to
those
statements,
and
so
where
that
leads
us
is
to
how
do
we
fix
the
internet?
The
Internet
Protocol
is
broken
because
it
it
has
no
security
layer
when
it
was
designed.
It
left
out
the
two
layers
in
the
seven
layer:
OSI
model
where
you
have
security.
The
session
layer
is
authentication
now
had
they
put
one
in
there.
B
It
probably
would
be
a
bad
form
of
authentication
because
you
know
30
years
ago,
crypto
wasn't
as
good
as
it
is
now
so.
But
that
said,
what
has
happened
is
is
that,
instead
of
having
a
standard
security
layer
that
everybody
uses
for
the
Internet
Protocol,
we
have
bolt-on
identity
system,
security,
overlays
and
the
prime
example
is
the
domain
name
system
certificate
authority
system
that
everybody
uses
in
the
web?
What
that
means
is
is
that
security
on
their
internet
comes
through
some
form
of
an
identity
system,
security
overlay.
B
So
what
we
want
to
do
is
establish
the
authenticity
of
an
IP
packets
message,
payload
and
the
reason
we
want
to
do
that
is
that
Internet
Protocol
anybody
can
forge
the
source
in
an
IP
packet.
So
you
don't
know
who
sent
the
packet,
because
anybody
anybody
can
forge
that
anything
along
the
path
can
can
substitute
and
force
the
packet.
So
you
have
to
add
some
sort
of
authenticity
or
authentication
to
the
packet.
B
So
the
standard
approach
for
you
know-
and
this
is
a
zine-
pretty
much-
every
identity
system,
security
overlay
that
that
is
used
for
the
Internet-
is
that
you
have
a
mapping.
The
identity
system
provides
a
mapping
between
a
cryptographic
key
pair
and
an
identifier,
and
then
the
message
itself
includes
this
identifier,
the
data
and
then
a
signature
using
the
key
pair
that
you
can
then
verify
it
to
determine
if
the
message
was
is
authentic.
B
The
security
of
this
approach
is
contingent
on
the
security
of
the
mapping
between
the
key
pair
and
they
identify
err.
What
that
means
is
is
that
when
you
issue
an
identifier,
you're,
making
three
bindings,
you're
binding
a
controller
to
a
key
pair
you're
binding
a
key
pair
to
an
identifier
and
you're
binding
the
controller
to
the
identifier,
because
you're
basically
saying
this
controller
is
associated
with
this
identifier
and
controls
this
identifier
through
this
key
pair,
and
if
any
of
those
bindings
are
weak,
then
you
have
a
security
Valatie.
B
So,
let's
look
at
how
administrative
identifiers
issuance
and
binding
works-
and
this
is
this
is
the
way-
and
this
is
the
pattern
that
that
almost
every
administrative
identity
system
that
that
we
would
have
been
exposed
to
uses-
and
so
I've
I've,
simplified
and
generalized
it,
but
but
it.
But
it
is
the
pattern
that
that
that
is
generally
applicable.
You,
you
have
entropy
cryptographic
entropy.
The
controller
captures
that
gender
repair
and
then
an
administrator
of
the
identifier
makes
an
assertion
binds
the
key
pairs,
the
identifier.
B
So
this
might
be
a
certificate
as
in
a
certificate
authority
is
the
administrator
and
it
makes
it
creates
a
certificate
that
binds
the
key
pair
to
identifier.
And
then
you
can
verify
that
identifier
against
the
administrator
based
on
their
certification
means
now
is
that
in
this
issuance
process
you
have
a
strong
binding
between
the
controller
and
the
key
pair,
because
the
controller
is
the
only
entity
on
the
planet
that
can
capture
that
energy
and
generate
the
key
pair.
B
So
the
strength
of
that
binding
is
the
public
private
key
system
that
you're
using,
but
the
binding
between
the
keep
here
and
the
identifier
is
weak,
because
it's
just
an
assertion
made
by
an
administrator
and
if
you
can
hack
or
compromise
that
assertion,
then
you
can
replace
that
binding
with
a
different
binding.
And
so
the
pattern
is
an
example
of
DNS
hijacking.
B
So
there
was
a
spate
of
thousands
of
DNS
domains
that
were
hijacked
in
2019
and
continue
to
say,
because
people
haven't
in
general
fix
their
systems
that
basically,
where
someone
goes
in
and
either
hacks
a
DNS
provider
or
a
hacks
registrar
of
a
name,
server
record
and
then
is
able
to
convince
let's,
in
some
other
certificate
provider,
to
issue
a
valid
certificate
against
that
that
domain
name
with
with
a
key
pair.
But
the
key
pair
is
controlled
by
the
hacker,
not
by
the
actual
controller
of
the
identity.
B
So
they
basically
they
basically
hijacked
the
administrative
pin
of
that
binding
and
that
pattern
exists.
You
know
throughout
the
identity
space,
you
know
a
similar
pattern
for
sim
jacking
of
your
phone
anytime.
You
have
an
identifier
where
the
the
binding
between
the
key
pair
and
they
identify
is
asserted
by
an
administrator
or
administrative
entity.
The
security
is
dependent
on
the
infrastructure
of
that
administrator
policies.
How
the
administrator
runs
our
system
and
those
are
all
subject
to
various
types
of
exploit.
B
So
what
that
means
is
is
that
when
you're
building
identity
systems,
you
have
a
secure
identity,
overlay,
that's
based
on
some
trust
basis
and
in
most
cases
it's
some
form
of
infrastructure
and
then,
based
on
that
overlay,
you
have
a
trust
omein
of
interactions
that
can
mutually
interact
in
a
trusted
way
because
they
all
share
the
same
identity,
overlay
and
the
same
trust
basis.
And
so
so
that
gives
rise
to
the
the
modern
idea
of
security
on
the
Internet.
B
B
But
now
everybody's
recognized,
it's
the
dominant
protocol
and
one
of
the
things
that
led
to
its
dominance
is
the
structure
where
it
had
a
variance
banning
layer
which
is
the
IP
layer
that
spanned
all
of
the
supporting
protocols
beneath
it
and
spanned
all
of
the
applications
that
use
it
above
so
that
anybody
write
it
in
an
application
doesn't
need
to
see
anything
below
the
IP
layer.
They
just
can
address
the
IP
layer
and
anybody
below
the
IP
layer
doesn't
need
to
see
the
applications
above.
B
They
can,
just
you
know,
use
the
IP
layer,
and
so
that's
a
very
powerful
construct
that
has
led
to
the
current
shape
of
the
Internet
and
and
the
term,
for
it
is
the
hourglass
shape,
there's
a
narrow
waist,
which
is
the
IP
layer
and
there's
a
theorem
called
the
hourglass
theorem
that
talks
about
why
that
is
the
case.
I
insist
UM's
to
have
a
spanning
layer.
So
the
problem
is
that
the
current
IP
spanning
layer
doesn't
have
a
trust
layer
that
is
also
a
spanning
layer
and
since
IP
doesn't
have
security
built
into
it.
B
So
that
is
a
problem,
because
now
we
have
trust
domain
based
segmentation
of
the
internet.
So
so
that's
that
what
leads
to
the
idea
that
the
internet
is
broken
because
we
don't
have
interoperability,
trust,
we
don't
have
trust,
able
interoperability,
it's
it's
highly
segmented,
so
we
want
to
fix
that.
We
want
it.
We
don't
want
to
have
a
bifurcated
internet
trust
map.
We
want
to
have
a
single
internet
trust
mat
and
to
do
that,
we
need
to
add
a
trust,
Fanning
layer.
B
B
But
but
if
we
can
add
that
trust
Fanning
layer,
then
we
can
have,
we
can
get
rid
of
the
silos
and
Trust
and
have
global
interoperability
across
the
internet.
So
that's
a
very
ambitious
idea,
but
that
is
the
motivation
for
Kerry
is
to
be
able
to
eventually
reach
the
point
where
we
have
a
universal
trust
spanning
layer
for
the
internet,
and
that's
why
the
title
is.
You
know
a
secure
identity
overlay
for
the
identifiers
overlay
for
the
internet
to
give
us
that
spanning
layer.
So
how
do
we
do
that?
So
how
we
do
that?
B
Is
we
start
with
the
root
of
trust
that
is
truly
decentralized,
and
that
is
a
self-certifying
identifier.
So,
if
I
have
a
cell
sort
of
an
identifier,
this
is
what
my
issuance
looks
like
a
controller
and
entity
captures
entropy
generates
a
key
pair.
The
controller
also
derives
the
identifier
from
the
key
pair,
which
makes
the
binding
between
the
key
pair
and
they
identify
err
strong,
and
that
also
makes
the
identify
ourselves
certifying.
So
the
controller
becomes
the
certificate
authority
for
its
own
identifier.
B
The
controller
doesn't
isn't
it
doesn't
need
to
refer
defer
to
any
other
entity
or
any
other
infrastructure,
because
the
controller
itself
or
created
the
key
pair,
the
identifier
and
all
the
bindings,
and
so
so.
The
root
of
trust
is
fully
cryptographic,
there's
no
infrastructure
associated
with
it,
and
so,
if
we
start
there,
then
we
can
build
a
secure
system
on
top
of
that
and
that's
the
key
insight.
B
So
what
that,
what
that
means
is
is
if
we
do,
if
we
start
with
this
self-certifying
identifier,
that
we
have
strong
bindings
between
the
controller
key
pair
and
identifiers,
so
it
fixes
the
main
weakness
of
any
administrative
issued
identifier,
which
is
the
administrator
asserting
the
binding
between
the
key
pair
and
the
identifier
and
between
the
controller
and
the
identifier.
Those
are
all
cryptographically
strong
bindings.
B
So
let's
look
at
a
basic
self,
sorted
font
identifier,
a
basic
identifier,
derivation
process,
looks
like
this.
You
collect
entropy
and
a
random
seed.
You
stretch
it
it's,
which
is
a
cryptographic,
one-way
function
and
the
the
definition
of
a
cryptographic
one-way
function
is
a
function
which
is
easy
to
commute
in
one
direction
and
impossible
or
practically
impossible
to
compute
in
the
other.
So
a
random
seed
stretch,
usually
using
some
sort
of
cryptographic
hash,
is
an
example
of
a
one-way
function.
B
A
private
key
public
key
generation
function
like
an
elliptic
curve,
cryptography,
ed2,
55119
or
a
nice
EDS
DSA
set
PE.
You
know,
256
k1
are
examples
of
one-way
key
generation
functions
that
are
practically
impossible
to
invert
through
brute
force
but
easy
to
generate
in
one
direction.
Then
you
attach
a
code
for
the
derivation
and
that
generates
what
I
call
an
identifier
prefix
there.
B
Fire
prefix
is
your
root
identifier
that
you've
derived
and
it
is
cryptographically
bound
to
the
public
key
because
of
the
derivation
process,
because
in
this
case
the
the
prefix
includes
the
public
key
explicitly,
and
so
you
have
a
prefix
that
consists
of
a
derivation
code
and
a
public
key.
You
have
an
inception
state
which
has
information
about
the
identifier
that
is
signed
with
the
public,
and
so
that
is
a
very
basic
cell
sort
of
fund
identifier
root
of
trust.
B
A
more
sophisticated
one
is
the
self
addressing
self-certifying
identifier,
and
in
this
case
you
get
to
the
public
key
and
its
derivation.
And
then
you
add
your
inception,
configuration
and
then
compute
a
digest
of
the
concatenation
of
those
to
add
a
derivation.
That
tells
you
that
you
did
a
digest,
and
now
you
have
a
prefix
that
not
only
strongly
binds
to
the
public
key,
but
now
strongly
binds
to
your
inception
configuration.
What
this
allows
you
to
do
now
is.
B
So
you
don't
have
to
attach
a
separate
signature.
So
it
may
be
more
efficient
to
do
it
that
way.
So
so
so,
a
lot
of
people
are
familiar
with
ledger.
Registration
and
I
want
to
spend
a
little
bit
of
time
to
contrast,
self-certifying
identifiers
with
ledger
registered
identifiers
and
the
ledger
in
this
case
I'm,
referring
to
a
blockchain
like
aetherium
or
bit
or
or
sovereign
or
some
other
identity,
totally
order
distributed.
Consensus
ledger
in
ledger
registration.
B
You
have
to
identify
errs
the
first
identifier
is
an
access
identifier
that
allows
you
to
access
the
ledger,
and
so
the
access
identifier
is
usually
self-certifying.
So
on
aetherium,
your
self
certifying
identifier,
is
your
aetherium
address.
It's
just
the
public
key
of
your.
You
know:
well,
it's
derived
from
the
public
key
of
your
public
private
key
pair
right.
It's
a
fingerprint
of
the
public
key
and
since
you
create
the
public/private
key
pair
or
the
individual
that
creates
the
the
address.
B
Then
then
it's
it's
their
identifier
and
if
they're
the
first
ones
to
use
it,
you
know,
then
then
they
have
access
to
the
two
aetherium
using
that
access
identifiers.
But
then,
if
you
want
to
register
an
identifier
on
on,
say
a
ledger,
then
you're
going
to
have
a
registered
identifier.
So
so
the
ledger
transaction
is
validated.
B
Given
the
access
identifier
and
the
access
key
pair
signature,
and
then
you
create
a
transaction
that
in
the
transaction,
is
a
registered
identifier
and
it
may
in
it
and
includes
a
binding
to
a
registered
key
pair
and
the
registration
key
pair
signature,
and
so
now
the
root
of
trust
in
the
register
desire
is
the
ledger
transaction?
Not
the
not
the
cryptographic
root
of
trust
that
this
that
the
access
identifier
is
using.
So
even
though
the
register
that
the
the
register
identifier
may
appear
to
be
self-certifying,
its
route
of
trust
is
the
ledger
transaction.
B
C
B
So
an
on
an
identifier
is
not
just
self-certifying,
it's
also
self-administering,
because
the
controller
is
is
the
administrator
for
its
own
identifier,
and
that
makes
them
portable
and
truly
self
sovereign.
So
that's
the
the
basis,
and
then
this
prefix
now
can
be
used
in
in
a
universal
identifier
by
adding
namespacing
to
it.
So
it
did
a
w3c
did
if
using
a
self
certified
autonomic
identifier
for
the
prefix
could
be
a
form
of
an
autonomic
identifier
and
and
that
lends
to
what
I
call
a
an
autonomic
identity
system
and
in
an
identity
system.
B
B
So
the
first
thing
is
the
root
of
trust
and
we've
talked
about
that.
The
root
of
trust
is
a
cryptographic
autonomic
identifier,
alright,
so
that
answers
the.
Why
and
the
how
of
who
controls
the
identifier.
The
source
of
truth
is
the
controller
of
the
private
key,
alright.
So
so
that's
the
who
and
and
and
and
we
can
bind
that
to
the
root
of
trust
and
then
the
final
one
is
what
I
call
the
low
sigh
of
control,
which
is
what
you're
controlling
and
you're
controlling,
authoritative
operations?
B
And
so
you
can
verify
all
the
authoritative
operations
by
signing
with
the
key
pair
that
is
cryptographically
bound
to
the
identifier,
and
so
there's
no
place
that
anybody
can
intervene
in
the
establishment
of
the
of
the
authenticity
of
a
control
operation.
Because
you
can,
you
can
verify
it
all
the
way
back
to
the
root
trust.
B
So
in
doing
a
systems
design
for
an
identity
system.
You
have
a
bunch
of
different
things
that
you
can
trade
off.
So
I
have
a
diagram
here
of
the
system,
design,
trade,
space
and
different
features
that
you
can
leverage
from
block
chains
and
cryptography
to
get
different
features,
and
one
of
the
things
in
designing
carry
is
I
realized
that
if
I
wanted
portability,
I
needed
to
not
use
some
features.
That
constrain
me
so,
but
I
don't
need
total
ordering,
because
the
controller
is
the
only
one
that
can
order
events.
B
The
control
over
the
key
pair
so
I,
don't
need
total
ordering
I,
don't
need
a
cryptocurrency
to
do
an
identity
system.
I
can
use
some
other
cryptocurrencies
for
payment.
It
doesn't
have
to
be
embedded
in
MIDI
system.
I
can
get
I,
don't
need
shared
control,
because
the
controller
is
the
only
controller
so
so
I
can
I
can
avoid
that
and
I
don't
need
to
be
locked
to
a
ledger,
and
so,
given
that
I
take
those
out,
I
can
come
up
with
a
system
that
has
these
features
that
that
is
an
identity
system.
B
So
it's
a
matter
of
trading
off
different
things
in
composing
in
a
different
way.
So,
let's
look
at
carry
specifically
carry
stands
the
event
receipt
infrastructure,
so
it
starts
with
key
events
and
the
key
event
is
basically
a
data
structure
that
has
a
header
some
configuration
information
and
signatures,
so
it
so.
It
is
an
authentic
payload
that
you
can
send,
and
if
those
signatures
are
generated
by
a
self-certifying
identifier,
then
it's
verifiable
and
there
are
and
the
events
are
chained
together.
B
It's
it's
a
chain
in
the
sense
that
a
controller
composes
messages
and
has
changed
them
together,
and
so
you,
you
now
have
a
hash
chain
data
structure
that
can
be
verified
by
anybody
who's,
given
a
copy
of
that
has
changed
it
data
structure,
and
so
that's
the
that's
the
the
core
of
carry.
There
are
two
types
of
events:
there:
establishment
events
which
established
control,
Authority,
so
control
Authority
is
what
are
the
authoritative
key
pair
at
any
point
in
time
for
a
trivial
system,
there's
one
authoritative
key
pair
and
it
never
changes.
B
But
if
I
want
persistence
in
my
identifier
and
I
want
to
be
able
to
survive
compromise
of
my
keys.
That
I
need
to
be
able
to
do
things
like
rotate
keys,
so
in
carry
we
have
to
establishment
events.
One
is
an
inception
event,
which
is
the
first
event
that
establishes
the
identifier,
and
then
we
can
have
any
number
of
rotation
events
that
that
allow
us
to
change
the
authoritative
public
key.
B
So
we
start
with
a
route
of
trust
in
a
public
key
pair,
that's
bound
to
the
identifier,
and
then
we
can
rotate
authoritative,
Li
to
other
key
pairs
given
signed
rotation
messages.
So
the
infrastructure
that
we
need
is
infrastructure
that
keeps
track
of
those
rotations
or
key
event.
Receipts
which
are
signed
signed
key
events
infrastructure.
So
that's
where
the
term
carry
comes
from
is
keeping
track
of
these
establishment
events,
the
other
type
of
event,
and
so
we
have
an
establishment
subsequence
of
an
inception
event
in
any
number
of
rotation
events,
there's
also
non
establishment
events.
B
The
purpose
of
a
non
establishment
event
is
to
be
able
to
do
something
with
the
identifier
and
primarily
what
a
non
establishment
event
is.
Is
that
it
anchors
data
to
the
key
event
sequence
so
that
you
can
do
things
like
issue
a
verifiable
credential
or
revoke
a
verifiable
credential
or
engage
in
a
transaction
where
you
make
a
commitment
of
some
form
to
some
other
entity,
and
you
can
anchor
that
that
commitment
or
that
credential
issuance
to
the
to
the
key
event
receipt
log
so
that
anybody
can
verify
it.
B
B
The
key
thing
here
is
that
is
that,
given
the
event
log
I
can
establish
for
each
interaction
event
in
anything
anchored
in
that
interaction
event:
the
control
authority
over
that
event,
because
it's
in
the
log
and
by
replaying
the
log
I
know
what
keys
were
authoritative
at
any
point
in
time.
So
so
I
don't
need
any
intervening
infrastructure
to
make
the
establishment
I
just
need
to
produce
a
copy
of
this
sequence,
and
anybody
can
verify
it.
B
That's
the
term
when
we
use
the
term
end
verifiable,
so
the
anchors
we
call
holes
because
the
definition
of
seal
means
evidence
of
authenticity.
So
so
anything
that's
anchored
now
provides
evidence
of
authenticity
of
whatever
is
anchored,
and
so
the
the
the
three
types
of
seals
are
a
digest
of
data,
a
Merkle
tree
root
or
hash
tree
root
or
an
event
seal
which
is
anchoring
an
event
in
some
other
key
event,
log
to
a
particular
location.
In
this
key
event,
log
which
is
primarily
used
for
delegation.
C
B
This
way
we
can
anchor
arbitrary
dairy
data
and
provide
proof
of
a
control
Authority
for
that
data
at
the
location
of
the
anchoring
event.
The
seals
make
carry
privacy,
perversely,
preserving
and
data
semantic
agnostic,
because
all
we're
putting
on
carry
our
digests
we're
not
putting
anything
else.
So
if
you
want
to
know
what
the
data
that
is
anchored
means,
whoever
created
the
data
can
produce
that
off
chain,
it
there's
no
on
chain
disclosure
or
correlation
of
the
data
other
than
the
digest.
B
So
that
gives
us
the
ability
to
be
content
context,
independent
extensible,
which
is
the
goal
of
carry
which
is
to
be
universal
and
not
not
tied
to
any
particular
data
schema.
So
we
get
interoperability
with
respect
to
establish
a
control
Authority
totally,
but
we're
using
the
minimal
and
sufficient
means
to
get
there,
and
so
that's
that's
an
important
design
feature
of
carry
so
so
now
we
want
to
talk
about
the
security
of
a
carry
log.
If
we
never
rotate
Keys,
then
then
we're
good.
B
We
don't
have
to
do
anything,
but
if
we're
gonna
rotate
keys
then
we
need
to
then
we
need
to
track
that
and
establish
the
security
of
that.
So
in
care
we
use
that.
We
use
a
couple
of
terms,
one
that
and
the
terms
are
inconsistency
and
duplicity.
So
the
dictionary
definition
of
inconsistent
is
lacking
agreement,
one
or
as
two
or
more
things
in
relation
to
each
other.
B
So
if
I
make
an
inconsistent
statement,
it
means
I
made
a
statement
about
something
and
made
another
statement
that
that
didn't
agree
to
the
first
statement
and
because
all
the
statements
are
signed
then
they're
provably,
inconsistent
duplicity
is
acting
in
two
different
ways
to
two
different
people
concerning
the
same
manner.
So
I
inconsistent
statements
to
two
different
people,
but
they're,
not
duplicitous
I,
have
to
make
inconsistent
statements
of
the
same
thing
to
two
different
people
and
then
they
would
compare
notes
and
then
there
we
go.
B
Oh
you
told
me
one
thing:
you
told
him
another
thing
you're
being
duplicitous,
and
so
that's
what
duplicity
is,
and
so
what
that
allows
us
to
do
is
distinguish
between
the
internal
and
external
link.
See
internal
inconsistent
log
is
not
verifiable
by
the
construction
of
the
log
being
a
has
changed
data
structure.
So
if
I
put
something
in
a
log
and
it
doesn't
it's
inconsistent
I
can
verify
that's
inconsistent
if
I
so
log,
verification
from
a
self-certifying
root
or
trust
protects
against
internal
inconsistency.
B
All
logs
are
must
be
internally
consistent
and
anybody
can
determine
that
they're,
not
external,
inconsistent
log.
It
comes
when
I
have
a
purported
copy
of
a
log
that,
and
both
logs
are
internally
consistent.
They're
both
are
both,
but
the
logs
themselves
are
different,
so
I've
got
a
purported
copy.
That
is,
that
does
not
match
that
means.
I
have
a
duplicitous.
Log
and
and
duplicity
is
protected
by
you
by
using
duplicity
detection.
So
we
need
duplicity,
detection
added
on
to
internally
consistent
logs
to
protect
against
external
inconsistency.
C
B
A
B
That's
a
good
question
right
now:
there
is
a
project
within
the
decentralized
identity
foundation
that
just
started
recently,
there's
a
little
bit
of
code
there.
The
goal
is
to
have
a
working
reference
implementation
of
Kerry
by
September
of
this
year,
and
so
we've
got
some
developers
that
are
working
on
it,
but
there
is
no
code
today,
but
if
you
want
to
help
you're
welcome
to
help
it's
an
Apache
2
license
to
open-source
project,
and
we
welcome
all
you
know:
I'll
help
we
can
get
Austin.
A
B
Ok
well
so
the
key
event
logs
are
what
established
the
root
of
trust.
So
the
question.
So
so
you
have
a
self-certifying
identifier
and
a
key
event
log.
The
key
event
log
is
ordered
with
respect
to
the
identifier
by
the
controller.
You
don't
need
total
ordering
with
respect
to
other
identifiers,
to
establish
the
route
of
trust
in
Kerry
and
that's
probably
the
hardest
thing
to
get
your
mind
around.
B
And
this
is
why,
and
so
so
that's
a
good
segue
to
the
duplicity
game,
because
I'm
protected
against
internal
inconsistency
by
this
structure
of
the
log,
because
it's
a
hash
chain
data
structure,
the
only
the
only
authority
that
can
sign
the
log
is
the
controller
itself
and
and
that
authority
is
established
by
virtue
of
only
one
controller
can
be
a
signer
and
the
identify
ur
is
uniquely
attached
to
those
through
the
initial
keys.
So
it's
a
cryptographic
root
of
trust.
It's
not
based
on
a
blockchain
and
then
and
then
the
key.
This.
B
The
events
are
all
signed
by
the
same
controller,
and
so
the
question
now
is
what,
if
the
controller
produces
two
different
logs
and
so
we're
going
to
play
the
duplicity
game.
To
answer
that
question
so
Cates,
the
controller
kate
creates
a
log
of
of
key
events
that
are
signed
by
kate
and
and
so
what
is
kate
going
to
do
with
that
law?
Kate
wants
to
interact
with
other
entities
in
private
one-to-one
interactions,
so
I
want
to
use
this
identifier
for
private
one-to-one
interactions
so
putting
it
on
the
blockchain.
B
You
know
destroys
privacy
because
I
publicized
it
but
I
want
to
I
want
to
engage
in
private
one-to-one
interactions
that
are
secure,
so
Eve
is
a
validator
of
for
kate.
Kate
is
going
to
send
events
to
Eve
and
Eve
is
going
to
validate
those
and
try
to
establish
whether
or
not
kate
is
being
consistent,
because
the
root
of
trust
is
consistent
attribution.
So,
if
kate
is
consistent
in
all
of
Kate's
statements,
then
Eve
can
trust
Kate
up
until
the
moment
that
kate
is
not
consistent
and
then
Eve
can't
trust,
Kate
anymore,
so
Kate's
at
risk.
B
Anytime
Kate
is
inconsistent
and
she's
provably
inconsistent.
If
she
signs
in
something
with
a
non
repeatable
signature
and
also
Kate
wants
to
interact
with
Joe
and
Joe
as
a
validator
for
Kate.
Now
for
the
interaction
Kate
is
making
a
local
consistency,
guarantee
kate
promises
to
provide
a
consistent,
pairwise
log
with
Eve,
says
Eve
I'm
going
to
be
consistent.
B
I'm
gonna
give
you
a
log
and
I
promise
to
be
consistent
and
Eve
can
verify
at
any
point
in
time
whether
Kate
has
been
inconsistent
by
just
by
keeping
a
copy
of
the
log
that
that
or
the
events
that
Eve
has
received.
So
Eve
has
a
log
of
what
Kate
sends
or
Kate
has
an
internal
law.
Joe
has
a
log,
so
Eve
uses
the
identify
our
a
in
this
case.
B
It's
actually
a
self
sort
of
find
identifier
which
would
be
you
know,
44
by
8,
base64,
random,
random,
appearing
string
of
characters,
but
but
a
is
is
what
we're
representing
with
compactly
so
and
then
Kate
uses
a
different
identifier
for
Kate's
interactions
with
Joe,
so
Joe
knows
Kate
by
B
and
Eve
knows
Kate
by
a
Joe
can't
correlate
a
and
B.
You
know
even
Joe
can't
correlate
to
Kate
because
she's
using
different
identifiers
so
that
so
she
can
keep
privacy.
B
B
B
There's
no
way
that
cake
can
be
duplicity
us
and
not
get
caught
as
long
as
Eve
keeps
a
copy
of
the
log
if
he
loses
the
copy
of
the
log
and
Kate
sends
a
new
copy
of
the
log,
then
Eve
won't
know
that
Kate
was
being
duplicitous,
but
if
the
new
log
is
internally
consistent,
that
Eve
might
be
fine
with
that,
because,
for
whatever
reason,
Eve
didn't
care
about
keeping
a
log.
So
Eve
doesn't
care
about
maintaining
consistency
over
time.
B
B
So
let's
say
that
now
that
Kate
doesn't
like
talking
directly
to
even
Joe
Kate
likes
to
be
offline,
and
so
Kate
wants
to
have
high
availability,
but
still
private
one-to-one
interactions.
So
Kate
creates
a
service
or
an
agent
that
Kate
controls
that
holds
Kate's
log
and
then
and
then
Eve
can
talk
to
the
service
and
Joe
can
talk
to
the
service
and
the
service
has
high
availability,
so
both
of
them
so
Kate
can
go
away.
So
how
does
this
change?
Well
it
changes.
Now.
Is
the
the
service
now
is
a
point
of
vulnerability?
B
Kate
needs
to
make
sure
that
the
service
is
consistent
and
not
duplicitous,
but
the
guarantee
is
still
the
same.
A
local
consistency
guarantee.
So
you
know
how
many
Kate
slash
service,
a
cessation,
be
duplicitous
not
get
caught.
It's
the
same
guarantee.
You
can
use
different
identifiers
if
they
use
a
different
log,
even
detect
the
Kate's
being
duplicity
by
virtue
of
a
different
log.
B
If
Kate
truncates
the
log
then
Eve
will
did,
will
it
won't
match
their
log
I
mean
if,
if
the
service
deletes
the
log
Eve
once
see
the
log
at
all
which
only
hurts
Kate
right,
because
Kate
can't
talk
to
Eve
without
the
log
he
says:
there's
no
log,
so
I
guess:
there's,
there's
no
interaction.
So
all
the
things
that
the
service
can
do
to
hurt
Kate
to
hurt
Kate,
but
they
don't.
They
don't
hurt
Eve.
It
makes
it
makes
Kate
unable
to
talk
to
Eve,
but
it
doesn't
hurt
Eve
and
that's
the
important
point.
B
B
But
so
that
brings
up
a
different,
a
different
question
and
that's
where
duplicity
comes
in.
So
if
I
break
the
promise
of
global
consistency,
its
provable
and
how
is
approval,
because
any
time
that
I
send
events
to
one
person
and
sign
them
and
send
in
consistence
events
into
the
same
person
or
distant
person
and
sign
them,
then
all
they
have
to
do
is
compare
events
to
prove
that
I
was
duplicitous.
So
so
the
Kate
is
always
at
risk
of
being
found
out
if
she
ever
acts.
B
Duplicity,
even
once
right
forever,
because
that
that
signature
that
she
signed
that
inconsistent
event
is
non
reputable
and
which
means
it
can
be
produced
at
any
point
in
time
and
say:
hey
10
years
ago.
You
did
this,
so
how
make
a
be
duplicitous
and
not
get
caught.
So
what
are
the
exploits
that
Cait
can
employ?
Well,
she
can
send
two
different
versions
of
logs
to
Joe
and
Eve,
and
so
she
hasn't
got
caught,
but
if
she
can
truncate
the
logs,
so
look
Joe
has
a
different
version
of
log.
That
Eve
has.
B
B
If
she
has
sent
different
logs
to
Eve
and
Joe
and
they
interact
and
compare
notes,
they
will
know
right
away
that
Kate
is
duplicitous,
so
so
the
only
way
Kate
can
be
duplicity
us
and
not
and
guarantee
she
does
not
get
caught-
is
to
prevent
Joe
and
II
from
ever
talking
to
each
other,
which
is
possible.
Kate
could
control
them
such
that
Joe
and
Eve
can
never
talk
to
each
other.
But
if
Joe
and
Eve
need
to
interact,
then
it
then,
then
it
defeats
us
because
that
by
being
isolated,
the
interaction
fails
right.
B
So
in
that
case,
if
global
consists,
the
only
matters
after
they
need
to
interact,
then
then,
then
locates
duplicity
does
is
prevent
the
the
interaction
from
completing.
But
let's
say
that:
that's
not
not
a
problem.
Let's
say
that
that
they
don't
necessarily
need
the
end
act,
but
sometime
in
the
future,
they
need
to
interact
and
they
want
to
protect
it
against
that
one
way
to
protect
it
for
them-
and
this
is
what
Carrie
uses
is
that
I
can
have
another
entity
Doug
and
Doug
Lobel,
duplicity,
log.
B
B
It
hasn't
been
duplicitous
so
far,
so
so
as
long
as
I
have
a
way
of
detecting
duplicity,
both
even
Joe
are
always
protected.
Doug
serves
the
same
purpose
as
a
blockchain,
but
doesn't
have
to
be
a
blockchain.
He
just
has
to
have
a
copy
of
the
log.
That's
all
he
has
to
have
it's
the
minimal
amount
of
infrastructure
that
you
need
to
ensure
that
Kate
is
caught.
B
If
she
tries
to
be
duplicitous
so
so,
if
there
are
enough
Doug's
out
there
or
enough
infrastructure
that
is
providing
copies
of
duplicity
logs,
then
you
get
what's
called
ambient
duplicity
detection,
which
means
you
can
detect
duplicity
anytime
by
anybody
anywhere
and
there's
actually
something
that's
very
similar
this
that
is
used
right
now
and
it's
called
certificate
transparency.
So
there's
a
the
there's
references
for
that,
but
the
DNS
system,
unfortunately,
doesn't
have
a
strong
root
of
trust.
B
But
but
if
you
use
the
certificate
transparency,
you
basically
have
a
global
duplicity,
log
or
inconsistent
log
that
allows
you
to
detect
if
somebody
is
using
certificates
in
an
inconsistent
way,
and
so
Carrie
takes
advantage
of
that
same
idea
and
adds
that
on
to
a
cryptographic,
root
of
trust
with
strong
bindings
to
get
an
inviolable
security
guarantee,
based
on
both
internal
consistency
from
a
cryptographic,
root
of
trust
and
external
consistency
using
ambient
duplicity
detection.
So
that's
why
Kate
that's
why
Carrie
works.
So
so,
let's
think
about
what
that
means.
B
Carrie
enables
a
cryptographic
proof
of
control,
Authority
provenance
for
each
identifier.
The
provenance
comes
from
the
log,
the
proof
in
the
form
the
key
event
receipt
log.
The
key
event
receipt
log
is
an
verifiable
anybody
that
wants
to
to
read
the
law
can
verify
it.
It
isn't
dependent
on
trusting
anything.
You
don't
have
to
trust
anybody.
It's
it's
zero
trust,
the
end
user.
One
might
verify.
There's
zero
trust
in
the
intervening
infrastructure.
B
Curls
may
be
ambient
verifiable
right,
which
is
you.
You
have
a
global
verifiability
right.
Anyone
can
verify
the
log
anywhere
at
any
time.
The
result
is
that
you
have
this
thing
that
has
these
features.
You
have
a
search,
self-certifying,
root
of
trust,
ambient
verifiability
via
certificate
transparency,
there's
a
couple
of
other
algorithms
casey,
which
is
a
which
allows
recovery
and
post
quantum
security,
because
something
called
pre
rotation
which
which
will
we
can
talk
about
a
minute
for
those
of
you
that
are
familiar
with
dids.
What
does
Carrie
mean?
B
Well,
Carrie
provides
the
equivalent
of
did
key
if
I
use
a
non-transferable,
ephemeral,
self-certifying
identifier.
It
provides
the
equivalent
of
did
peer
if
I'm
doing
direct
mode
one-to-one,
private
conversations
and
the
Quillen
of
public
identifiers
like
did
solve
if
I'm
using
the
indirect
mode
one
to
any.
So
it's
it
basically
does
everything
in
one
identifier
system
and
so
we're
building.
Something
called
did
uni
or
did
on,
which
is
the
universal
did
method
to
be
compatible
with
it
with
the
dead
spec.
So
this
is
that's
a
good
point
to
Depaz
to
answer
questions
yeah.
A
C
B
Term,
but
from
a
code
perspective,
yeah
validator
does
certain
things:
they
verify
the
log,
they
apply
any
other.
You
know
they
apply
a
duplicity
detection
or
they
leverage
somebody
that
is
duplicity,
detection
and
whatever
other
logic.
They
want
to
apply
to
say
that
yeah
this
is
this
is
this?
Is
these
events?
I?
Can
trust.
A
C
B
There's
no
duplicity,
because
Kate's
only
produced
one
copy,
the
I
mean
there
are
obviously
race
conditions
where
Kate
produces
two
copies:
Doug
doesn't
have
a
copy,
yet
you
verify
your
copy
and
then
the
second
copy
shows
up,
but
those
are
no
different
than
the
same
things
that
happen
with
any
any
blockchain
right.
You
take,
you
take
any
blockchain
and
if
I
can
isolate
you
from
the
network,
so
you
can
only
talk
to
one
node
on
Bitcoin.
Then
then,
then,
that
node
can
provide
you
with
a
fort.
B
B
You
know
randomize
their
Bitcoin
node
access
to
guarantee
that
they're
not
isolated
from
the
network,
so
Doug
is
doing
the
same
sort
of
thing,
so
you
can
make
Doug
as
reliable
as
you
want
it
to
be,
because
because
all
Doug
is
doing
is
providing
redundant
copies
of
logs,
it
doesn't
have
to
do
distributed
consensus
in
the
sense
of
total
ordering.
So
it's
it's
its
IP
of
F
Doug
could
be
ipfs.
B
For
all
intents
and
purposes,
for
those
of
you
familiar
with
the
interplanetary
file
system,
you
could
say
we're
just
gonna
put
everything
in
ipfs
and
and
and
and
if
in
and
check
it,
make
sure
that
that
I,
the
copy
that
I
have
is
the
same
copy.
That's
in
ipfs
and
if
it's
not
then
I
know
they've
been
duplicity,
us
and
I.
Don't
at
that
point,
I
don't
care
which
one
is
the
valid
copy,
because
they're
they've
been
duplicity
us
so
I
can't
trust
them
from
that
point.
A
B
Duplicity,
yes,
the
last
one
because
it's
has
chained.
So
if
you
have
an
event,
the
that
that
that
that
doesn't
match
your
latest
event
or
doesn't
hash
chain
back
to
your
latest
event,
then
you
know
that
they're
logged
from
your
log
and
you
and
you
could
also
do
a
Merkel
tree
of
the
events
in
your
log
and
then
verify
any
event
in
your
Merkel
tree
in
in
the
log.
Without
having
to
keep
a
copy
of
the
log.
You
just
have
to
keep
a
copy
of
the
Merkel
tree
of
the
log.
B
Yes,
because
they
can't
verify
the
root
of
trust,
so
they
have
so
they
have
to
have
access
to
a
full
log
at
some
point
in
time,
so
that
they
can
verify
to
the
brew
good
for
us
once
they
verify
to
the
root
trust
once
they
don't
actually
have
to
keep
a
copy
of
the
log.
Does
that
make
sense
just
need
to
keep
the
last
event
that
they've
seen
in
any
events
since
then,
they
just
need
to
verify
as
they
go.
C
B
If
they
don't,
if
they
don't
at
least
Vera
or
the
route
of
trust,
then
they're
trusting.
You
know
in
something
that
they
haven't
ever
verified,
but
you
can
certainly.
You
can
certainly
cache
the
fact
that
you've
that
you
verified
some
time
in
the
past
and
now
you
just
have
to
make
sure
that
all
event
is
chained
back
to
the
last
event
that
you've
verified
so
you're,
basically
just
verifying
as
you
go
and
then
just
keeping
the
last
event.
B
B
On
the
like,
let's
say
the
in
the
pre
rotation
and
the
key
management
scenes
it's
a
little.
It's
a
little
more
detailed,
but
I
can
give
a
brief
overview,
and
this
might
be
helpful
to
people
who
understand
key
management.
So
we
can
cover
just
the
basis
of
pre
rotation.
There
aren't
any
more
question
so
we've
talked
about
inception
events,
patient
events
in
Carrie
Carrie
uses
something
called
pre
rotation.
B
What
this
looks
like
is
that
in
the
inception
event
you
have
the
initial
public
key
and
this
is
simplified
to
a
single
key
instead
of
multi
signature,
but
all
of
this
works
for
multi
signature.
So
instead
of
a
single
key,
you'd
have
a
set
of
keys,
but
I
have
this
initial
set
of
keys
and
then
in
the
inception,
event
I
declare
the
next
key
and
make
a
cryptographic
commitment
to
it,
where
I
have
a
digest
of
that
next
key.
So
the
next
key.
Isn't
there
just
a
digest
of
it.
So
I've
created
two
key
pairs.
B
The
initial
one
public
key
and
the
second
one,
which
is
the
next
one,
but
this
private
key
of
the
of
the
next
one
is
now-
is
not
exposed
at
this
point,
so
you
could
create
it
in
your
coal
mine
down
at
the
bottom.
You
know,
air-gapped,
you
create
this
key
pair
and
the
private
key
you
keep
down
in
the
coal
mine.
You
bring
the
created
hash
of
it,
and
then
you
bring
the
hash
out
of
the
out
of
the
coalmine
and
stick
the
hash.
B
In
this
event,
you
sign
this
event
with
the
initial
private
key,
so
the
private
key
has
been
exposed
by
the
signature,
but
the
next
key
isn't-
and
this
is
post
quantum
secure
because
hashes
if
they're
strong
enough,
aren't
any
weaker
than
are
weakened
by
quantum
computers.
So
now,
even
if
somebody
has
a
surprise
attack,
they
can
invert
your
next
key.
So
you
can
always
recover
your
control
authority
by
doing
a
rotation
event
to
the
the
unexposed
next
key.
B
So
that's
what
free
rotation
is
it's
a
pre
commitment
to
the
to
the
next
key
you've
pre
wrote
your
your
key,
and
this
is
your
next
key.
Is
your
next
rotation
key?
So
when
I
do
a
rotation
event,
I
go
extract.
My
private
key
buried
at
the
bottom
of
the
coal
mine
I
create
a
rotation
event.
I
expose
that
key.
They
can
verify
that
the
hash
of
that
key
was
in
this
event,
so
there's
no
way
for
an
exploiter
to
create
an
alternative
rotation
event,
because
I
have
forward
chained
right.
B
So
it's
not
just
back
chain
if
I
were
chained,
my
rotation
event
by
by
the
next
key,
so
I'm
protected
both
forward
and
backward
cryptographically.
So
now,
I
expose
this
key
I
sign
with
this
one,
but
I
also
make
a
forward
commitment
to
the
next
key,
which
is
still
at
the
bottom
of
my
coal
mine
and
so
now,
with
pre
rotation.
I,
don't
need
to
have
multiple
layers
of
key
I.
Just
have
a
single
sequence
of
keys.
That
is
both
back
and
forward
chain
to
preserve
my
control
authority.
B
So
that's
the
simplest
infrastructure
for
key
management
that
allows
me
to
rotate
keys
in
a
best
practices
scripted
out
for
these
sugar
way.
So
this
just
shows
you
a
sequence
and
you
can
see
the
keys.
The
underbar
means
it's
a
hash
all
right,
so
I
have
C
0
C
1.
The
current
key
signature
was
C,
0,
patient,
I've,
rotated
to
C,
1,
I,
pre,
declare
C
2
or
commit
to
C
2
I
sign
with
C,
1
and
so
on,
and
then
and
then
I
can.
B
A
C
A
A
B
C
B
Far,
the
only
code-
that's
on
there
is
the
Python
stuff
that
I've
written,
but
but
there
is
a
pull
request
for
some
JavaScript
stuff
and
I
know.
Somebody
has
volunteered
to
work
on
a
rust
one,
but
hasn't
hasn't
submitted
a
pull
request
yet,
and
that's
probably
because
there
isn't
enough
Python
code
to
go
on
yet
for
somebody
to
get
really
serious
about
the
other
implementations
without
you
know
a
lot
of
stepping
on
toes
and
doing
stuff,
because
it's
it's
really
early.
A
A
B
Yeah
no
great,
this
is
great,
so
so
one
of
the
things
that
Kerry
does
is
it
changes
the
the
conversation
about
security,
from
a
conversation
about
the
security
of
infrastructure,
to
a
conversation
about
the
security
of
your
key
management
and
your
key
management
infrastructure.
So
most
people
when
they
think
security
they
think
oh
blockchain,
how
secure
is
my
blockchain
is
a
permission
or
permissionless?
How
hard
is
it
to
get
a
51%
attack,
etc,
etc?
None
of
that
matters
for
carry
carry
is
all
about.
B
Are
your
private
keys,
private
and
if
your
private
keys
are
private,
then
the
only
exploits
are
brute-force
attacks
against
the
public
keys
and
because
the
next
public
keys
are
actually
protected
by
a
hash.
You
can't
even
do
you
have
to
brute-force
attack
hash
algorithm,
which
is
post
quantum
secure,
so
that
is
a
very,
very,
very
high
level
security,
and
now
your
exploits
are
limited
to
exploiting
your
private
keys,
which,
if
you're
so
now
private
key
management
and
protection
is,
is
the
root
of
your
security.
B
So,
if
I
think
about
key
infrastructure,
not
blockchain
infrastructure,
not
administrative
structure,
not
server
infrastructure,
but
my
key
infrastructure.
The
term
baylin's
to
talk
about
how
my
hat,
how
multifaceted
my
key
infrastructure
is
so
the
simplest
key
infrastructure
is
au,
Nevada
and
infrastructure,
and
so
what
I
have
is
a
key
pair
generation
infrastructure,
so
I
might
be
generating
key
pairs.
B
Like
the
example
I
gave
in
the
bottom
of
coal
mine
using
an
air
gap,
whatever
handwritten
on
paper,
you
know
engraved
into
platinum
bars,
you
know
infrastructure
or
it
might
be
the
secure
Enclave
on
my
iPhone
or
the
equivalent
on
on
you
know,
or
some
trusted
execution,
environment
or
some
trusted
platform
module
that
is
generating
my
key
pairs
and
then
I
have
a
key
event
signing
infrastructure
and
so
in
the
signing
infrastructure.
I
have
to
take
my
private
key
put
it
in
this
infrastructure
so
that
it
can
be
used
to
sign
things.
B
So
the
signing
infrastructure
might
be
just
some
software
running
on
my
server
of
my
agent
or
it
might
be
a
TPM
or
a
trusted
execution
environment
or
something
more
sophisticated.
I
get
to
choose
how
I
want
to
manage
that
Carrie
Carrie
doesn't
care
because
Carrie
says
you
get
to
pick
and
if
you
care
about
your
security,
then
you
you
pick
well
appropriate
to
to
what
you're
going
to
use
your
keys
for.
B
I'm
sorry
I
expose
the
public
and
private
key
in
the
key
event:
signing
image
structure,
I
publicized
the
public
key
in
the
events,
the
private
key
stays
in
my
infrastructure
and
I
publish
eyes
the
next
key
as
in
a
hash,
because
I've
got
to
hash
it,
so
so
the
public.
He
goes
to
my
key
event
where
I,
where
I
hash
it,
but
the
private
key
never
leaves
my
key
pair
generation
infrastructure
till
I
need
to
use
it.
So
as
long
as
my
key
pair
generation
infrastructure
stays
secure,
then
I'm
fully
fully
secure.
B
I
can
always
recover
my
control
authority
by
rotating,
even
if
my
private
key
for
my
current
signing
gets
compromised.
So
a
Bible
in
infrastructure
says
well,
you
know
what
I
want
to
have
different
degrees
of
security
and
different
degrees
of
performance
and
scalability.
For
my
signing,
and
so
I
want
to
segregate
my
route
control
authority
from
a
lesser
control
Authority
for
signing
in
high
volumes,
so
in
this
case
I
have
a
delegator
which
is
my
route
control
authority
that
is
using
my
coal
mine
for
my
carrot
generation
and
my
delegate
is
just
some
server.
B
Someplace,
that's
going
to
be
signing
webpage,
you
know,
interactions
or
data-driven,
you
know,
processing
of
whatever
I'm
doing
and
so
I
don't
need
that
to
be
as
secure
and
because
these
are
delegated
and
we
haven't
talked
about
delegation
in
Cary.
I
can
always
revoke
these
keys
and
recover
them
with
this
guys.
B
I
now
have
two
layers
of
infrastructure:
a
highly
secure
infrastructure
that
controls
a
more
scalable,
pure
infrastructure,
and
then
I
can
go
to
a
multivalent,
so
I
can
get
horizontally
scalability,
where
I
have
one
delegator
infrastructure,
that's
controlling
multiple
delegate
infrastructures
and
each
delegate
infrastructure
may
have
its
own
security
guarantees.
It's
own
key
management
policies,
but
they're
all
using
the
pre
rotation
scheme,
they're
all
using
the
same
events,
they're
all
using
the
same
self-certify
on
fires.
Derivate.
You
know
the
set
of
derivations
that
we've
generated.
B
So
the
another
way
thinking
about
it
is
I
have
a
set
of
signing
keys
that
have
been
used
once
to
rotate
and
now
I
use
those
keys
over
and
over
again
the
sign,
if
at
some
point,
I'm
worried
about
these
keys
being
compromised,
then
I
do
a
rotation
to
a
new
thing,
and
so
now,
I'm
protected
I
can
always
rotate
away
from
from
from
an
attack
in
that
that
case
or
in
carry.
If
I.
B
A
B
No
because
the
derivation
code
allows
you
to
to
use
whichever
format
you
want,
so
anybody
that
sees
that
identifiers
looks
at
the
first
byte
or
two
right
now.
All
of
the
all
the
formats
that
are
that
are
reasonable
use
that
are
elliptic
curve
formats
are
32,
byte
keys,
which
requires
which,
when
you
base64
them,
there's
one
pad
byte
and
so
in
carry
we
replace.
We
prepend
the
pad
byte
replace
the
pad
byte
with
the
derivation
code
byte.
So
it's
very
much
like
a
multi,
codec
type
approach.
B
A
B
Yes,
you
could
use
that
in
your
key
derivation.
If
you
chose
carry
would
be,
would
would
not
know
that
very
but
but
if
you
chose
to
organize
your
keys
across
your
different
identifiers
that
way,
you
certainly
could
and
I
know
some
people
that
are
doing
that
with
with
with
you
know,
in
their
architecture,
designs
for
things
with
carry
where
they're
just
saying.
C
A
B
So
what
you
have
actually
is
you
have
a
in
the
full
key
config?
It's
not
just
the
public
key
is
actually
a
threshold,
so
your
Kayvan
you'd
put
and
then
the
public
keys
is
a
list.
So
now
you
know
the
end
from
the
number
of
keys
in
the
list.
So
you
you
keep
ka
vanna's,
provided
this
way
and
there's
also
actually
in
carry
a
aided
key
scheme
which
yeah,
so
your
threshold
actually
could
be
a
list
of
lists
of
weights
of
threshold
weights.
So
you
could
do
any
relatively
any
arbitrarily
complex
logic.
B
Threshold
operation
using
this
scheming
carry,
and
it
would
take
a
while
to
explain
how
that
works,
but
I
anticipated
people
being
able
to
want
to
do
like
I
need
two
of
these
signatures
and
three
of
these
signatures
and
one
of
these
signatures,
and
that's
what
this
shows
here
so
I
hope
that
answers
the
question.
Yeah.
B
All
right
so
any
more
questions.
That's
it.
Okay,
so
delegation
have
his
delegation
work
there's
two
ways
to
whoops.
Are
you
hit
the
wrong
button?
Sorry,
there
are
two
ways
to
delegate
and
carry
one
is
using
interaction.
Events
and
the
other
is
used
in
rotation
events.
Interaction
events
are
going
to
be
a
little
more
scalable
rotation.
Events
are
gonna
are
not
going
to
scale
perform
in
his
white
because
you're
using
a
lot
more
keys
but
they're
more
secure.
It
just
depends
on
what
sort
of
application
you're
using
I
think
most
people
are
use.
Interaction.
B
Events
delegation,
payload
in
your
delegator,
the
payload
in
an
interaction
event,
is
actually
an
inception
event
for
a
delegated
identifier.
The
delegate
identify
er
has
and,
and
you
have
a
seal
or
an
anchor
either
cross
anchor.
How
is
an
inception
event
that
is
declared
as
a
delegated
inception
event,
and
then
this
key
log
can
do
interactions
and
at
some
point,
if
you,
if
the
delegator
says
okay
I,
need
to
rotate
keys
for
this
guy,
because
I
think
they've
been
compromised
sort
of
detected
a
compromise,
so
they
do
a
new
interaction
event.
B
C
B
If
you
want
to
revoke
keys
you
can
you
just
do
a
rotation
that
rotates
to
a
null
key
and
then
you've
revoked
the
delegate
key
event.
Anybody
wanting
to
verify
this
can
just
go
to
this.
This
key
log
verify
up
to
this
point.
Use
the
anchor
to
go
back
to
here
verify
up
to
the
root
of
trust,
and
this
can
be
done.
You
know,
and
then
here's
all
of
the
associated
information
in
the
events
right.
So
here's
the
delegating
inception
event.
B
Here's
the
delegation
anchor
the
digest
here
is
the
digest
of
this
data,
which
is
the
delegation
data.
There's
a
delegation
seal
and
the
delegated
event
right
here.
That
points
back
to
the
delegating
events
of
this
digest
is
of
this
event,
and
then
here's
the
delegated
data
that
they
came
from
this
data
right
here
is
essentially
the
same
data,
and
so
so
they're
cross-linked
delegated
events
that
are
that
are
verifiable
and
verifiable.
B
Anybody
that
gets
a
copy
of
the
delegate
event
stream
and
then
can
look
it
up
and
verify
it,
and
then
this
of
course,
and
then
there's
the
interaction
event,
data
and
the
interaction.
A
delegating
an
interaction
event
looks
no
different
than
a
retraction
event,
because
it
doesn't
rotate
keys
or
do
anything
special,
but
it
can
delegate
other
key
event
streams.
So
you
can
have
something
like
this,
where
I've
got
one
master,
delegator
and
a
bunch
of
minion
delegated
streams,
and
each
of
these
streams
could
also
delegate
streams.
B
I
know
an
arbitrary
you
can
do
a
one-level
tree,
but
but
you
can't
you
can't
do
all
the
way
down,
because
these
these
these
don't
have
authority
to
rotate
themselves
or
to
wrote
rotate
in
a
rotation
of
it
in
a
rotation
event,
because
the
rotation
event
is
pointing
back
to
the
to
the
delegator.
Although
a
future
version
of
Kari
could
allow
that,
but
I
don't
I,
don't
know,
there's
a
strong
need
for
that.
B
So
in
Kari
a
live
exploit
of
the
current
signing.
Keys
is
protected
by
a
rotation
you
just
rotate
and
in
you're
protected
you
recovered
control
authority,
so
pre
rotation
provides
protections
from
successful,
live
ex
point
of
the
current
signing
keys.
A
dead
exploit
is
that
you
have
stay
L
next,
signing
keys
that
have
been
exposed
passed
and
somebody
wants
to
create
a
delayed
event
history
and
because
the
keys
are
exposed,
they
may
be
able
to
exploit
that
and
compromise
them.
So
they
can
generate
whoops.
What
I
do?
B
Okay,
they
may
be
able
to
generate
an
alternate
event
history,
but
the
key
is
the
alternate
event.
History
must
be
delayed
because
they
can't
invert
the
next
keys.
They
have
to
have
to
compromise
them
after
they've
been
exposed,
which
means
that
your
duplicity
detection
will
your
original
copy
will
be
first,
and
so
you
will
be
protected
against
dead
exploit
because
the
worst
case
the
dead
exploit,
is
just
going
to
say.
Oh
you've
been
duplicity,
so
you
can't
trust
it
anymore.
B
But
as
long
as
you
have
an
original
copy,
you
know
which
copy
to
trust
and
if
you
have
Doug,
which
is
the
your
global
duplicity,
detector
Doug
will
only
have
one
original
copy,
because
any
any
copies
people
say
well.
This
is
this
came
later,
and
so
it
must
be
duplicitous.
And
then
you
can
decide
whether
you
want
to
trust
the
original
or
or
not,
and
the
validator
gets
to
make
that
decision.
It's
not
up
to
the
the
controller
to
make
that
decision.
B
It's
up
to
the
validator,
so
the
validator
can
protect
themselves
by
using
duplicity
detection
and
a
live
exploit
of
the
next
signing
keys
is
practically
impossible
because
it
requires
you
who
invert
a
digest
and
do
a
brute
force,
inversion
of
the
next
digest
and
the
underlying
public
key.
And
if
you
can
do
that,
then
no
key
management
scheme
on
the
planet
is
secure,
and
so
so
I'm
not
worried
about
that.
B
Now.
If
someone
can
do
a
side
channel
attack
against
your
private
key
store,
because
you
happen
to
publicize
your
privates
key
core,
then
yeah,
then
anybody
can
exploit
you
and
you're
not
protected
at
all.
But
understand
protection
is
solely
based
on
key
management.
Now,
not
any
other
thing,
and
so
that
changes
the
whole
discussion
about
about
identity.
B
It's
truly
decentralized.
It's
just.
Do
you
manage
your
private
keys?
Then
you
can
have
decentralized
identity,
you
don't
you
don't
have
to
have
anything
else.
I
mean
anything
in
the
sense
of
some
thumbs
in
heavyweight.
Like
a
bunch
of
block
chains.
You
just
need
key
event
logs
which
anybody
can
stand
up
and
spin
up
for
duplicity
detection.
So
there
are
two
operational
modes,
a
direct
event
replay
mode.
So
when
we
did
the
duplicity
game,
we
needs
two
modes
in
passing
so
I'm.
So
this
is.
B
C
B
Rotation
knocked
off
half
the
people,
so
there
we
go
so
direct
mode,
a
to
B.
So
what
does
Ana
DEA?
Have
they
have
an
event
generator?
They
have
their
own
copy
of
their
key
log.
They
have
fire
a
they
send.
Key
events
to
be
be
is
validating
those
events
to
know
whether
they
can
trust
a
so
they
have
an
event
validate
Jick.
They
respond
to
events
by
acknowledging
them
and
signing
them.
So
now
a
has
a
signed
copy
that
be
saw
and
acknowledge
the
event.
B
So
not
only
is
a
providing
proof
of
its
events,
but
he
now
has
proof
that
B
saw
an
event
in
order.
So
B
can't
later
say:
oh
I
didn't
know
about
that
event,
because
they,
you
can
say
no
I,
have
the
event
and
here's
your
signature.
So
you
you
acknowledged
it
I
know
that
you
have
the
event.
You
know
you.
C
B
Lie
about
you
can't
be
duplicitous
about
not
seeing
the
event
I,
you
saw
it
so
they're
both
protected
and
then
like
is
Bea's
identifier
to
a
has
the
the
mirror
image
where
B
generates
events
for
B's
identifier,
a
validates
those
sends
back
a
receipt
that
B
keeps
track
of
some
now.
Both
of
them
are
mutually
protected
in
a
private
pairwise.
You
know
one-to-one
interaction
and
a
can
have
any
number
of
those
one-to-one
interactions
with
any
number
of
other
entities
with
any
note
using
any
number
of
identifiers
without
deference
to
anything
else.
B
No,
they
don't
need
anything
else
on
the
planet
to
be
able
to
have
private,
secure,
one-to-one
interactions
ad
nauseam
right
completely
totally
decent
rise.
All
they
have
to
do
is
standardize
on
the
event
sequence
and
and
and
do
their
validation,
but
if
I
want
to
have
availability
so
that
are
not
directly
talking,
then
that's
in
direct
mode
and
so
in
indirect
mode,
a
creates,
an
event
promulgation
service.
The
event
promulgation
service
consists
of
witnesses
who
witness
what
a
does
so
these
are
controlled
by
a
designated
by
the
controller.
B
B
He
now
has
a
copy
that
that
witnessed
the
first
witness
witnessed
it
has
a
copy
when
a
then
sends
that
event
to
the
next
witness
a
can
also
send
a
receipt
from
the
first
witness
saying,
not
only
here's
the
event
with
my
signature,
but
here's
the
signature
of
this
other
witness.
So
now
this
witness
has
a's
and
this
witness's
signature.
B
So
this
witness
knows
that
this
witness
can't
be
duplicitous
and
then
and
then
he
can
talk
to
all
of
them
and
then,
when
he
gets
to
this
last
witness
he
a
will
have
a
fully
witnessed
event.
Log
was
science
Englishers
from
all
the
witnesses,
and
then
he
can
just
send
those
copies
of
that
or
broadcast
orgoth
gossip
copies
of
that
to
the
other
witnesses,
so
that,
at
the
end
of
two
rounds
of
talking
to
the
witnesses,
every
witness
has
a
fully
signed,
fully
receded
copy
of
the
event.
B
You
know
high
availability
and
as
long
as
a
trust
controller,
to
not
be
duplicitous
a
doesn't
have
to
trust
the
witnesses
because
the
witnesses
are
mutually
signing
stuff
and
if
controller
didn't
sign
it,
then
the
witness
can't
sign
it
because
they
can't
verify
it.
So
so
it's
all
the
way
through.
So
so
so
that's
the
basic
system,
but,
but
you
know
valid
validator
may
not
trust
controller.
A
a
may
be
malicious.
A
may
say
you
know
what
I'm
gonna
create
a
duplicitous
copy
of
my
event,
log
and
since
I
control.
B
The
witnesses
that
are
gonna
provide
two
different
copies,
so
a
then
adds
Watchers
and
Watchers
are
designated
by
the
validator
and
the
Watchers
basically
have
copies,
and
then
now
I've
got
a
high
availability
key
confirmation
service.
This
is
my
duplicity
detection.
This
is
Doug
right,
so
I
can
spin
up
some
servers
that
are
my
Doug
and
and
and
if
controller
a
ever
generates
an
event
that
is
duplicitous
and
and
any
one
of
these
guys
read
it,
then
a
will
be
able
to
detect
it.
C
C
B
So
it's
inherently
scalable
you
can
run
a
service
architecture
or
a
market
service
architecture.
Do
tens
of
thousands
of
transactions
per
second
and
you
know
not
skip
a
beat
with
this
kind
of
an
infrastructure
and
if
you,
and
if
you
really
have
a
reason,
why
you
need
to
use
a
blockchain
which
there
are
really
good
reasons
to
use
a
blockchain,
you
can
actually
do
it
this
way,
you
can
basically
say
my
ledger.
Whoops
the
blockchain
Ledger
is
going
to
be
the
witness
and
I'm
going
to
I'm.
Gonna
have
an
Oracle.
B
Sorry,
the
Oracle
on
the
ledger
is
my
witness
and
if
be
the
validator
trusts,
the
ledger
then
B
just
spins
up
an
Oracle
plain
ledger
to
be
the
bees
watcher.
And
now
you
you
now
you
just
using
a
blockchain
as
an
immutable
data
store
to
provide
your
event
log,
but
I
can
change
out.
This
ledger
at
will:
I
just
do
a
rotation
event
in
the
rotation
event,
I
specified
picture
or
a
stiff.
You
know,
because
I
can
specify
the
witness
at
every
rotation,
and
so
I
can
move
from
Ledger's
ledger
at
will.
B
The
controller
can
and
and
and
I'm
good
to
go
and
portable.
So
that's
the
thing
that
Kari
does
is
that
it
interacts
the
whole
idea
of
security
to
an
end
verifiable
event.
Log
in
any
immutable
data
store
can
provide
the
the
immutable
data
store
service
and,
if
I
want
to
use
the
ledger
for
that
letters
are
really
good
immutable
data
source,
they're,
they're,
expensive
and
slow,
but
they
do
immutable
data
source
really
well,
and
so,
if
I
have
other
reasons
to
do,
the
ledger.
B
I
can
continue
to
use
it,
but
I'm
not
locked
to
that
ledger
and
that's
the
key
difference
with
with
Kari.
So
what
Kari
does
is
it
introduces
the
idea,
separation
of
control,
so
a
shared
permission
ledger
has
shared
control
over
shared
data,
so
shared
data
is
good.
The
shared
data
is
the
key
event
log.
The
share
control
is
bad
because
well,
I
got
to
get
people
to
agree
to
permission
to
work
together
to
to
do
whatever
they
do
to
make
sure
that
that
that
share
control
works
and
that's
a
lot
of
work.
B
That's
that's
bad,
relatively
speaking,
so
share
control
between
controller
and
validator
may
be
problematic
because
the
controller
may
not,
and
the
validator
may
not
trust
each
other
right,
and
so
that
introduces
governance,
scalability
performance
issues
when
I
have
short.
That's
that's
what
Ledger's
are
their
shared
control
over
shared
data,
but
Kari
allows
you
to
separate
the
control
so
that
you
can
have
separated
control,
but
over
shared
data.
The
shared
data
is
the
log,
but
the
separated
control
is
the
promulgation
service
and
the
confirmation
service
or
my
witnesses
and
my
Watchers.
B
B
We
our
goal
is
to
have
a
working
reference.
Implementation
by
iaw
fall,
so
you
know
between
now
and
then
it
should
be
working,
hopefully
in
in
in
two
months.
You
know
which
is
half
way.
We
should
have
something
that
you
could
that
you
could
actually
play
around
with
it's
basically
working.
Just
not
you
know
not
fully
featured
I've
already
got.
You
know,
you
know
some
of
what's
been
happening.
Last
couple
three
weeks
has
been
just
nailing
down
the
serialization
stuff
and
that
seems
to
be
nailed
down.
B
So
there
really
isn't
anything
right
now
that
stopping
development,
I,
think
all
of
sort
of
architectural
questions
and
and
standard
approaches
have
been
answered
which
the
serialization
a
couple
of
other
things
were
things
that
were
open
questions
as
of
iaw
a
month
ago,
and
so
those
have
been
nailed
down.
But
you
know
what,
if
you
want
it
to
go
faster,
come
help.
A
B
No,
no,
no,
the
the
chain
is
completely
generated
by
the
controller.
The
the
controller
is
the
only
source
of
truth.
All
the
witnesses
are
doing
are
receding
that
they're
confirming
that
they
saw
that
and
once
they
confirm
they've
made
a
commitment
that
that
is
the
that
is
the
authoritative
event
from
their
perspective.
So
the
first
event
they
see
that
they
validate
against
their
copy
of
the
chain
is
the
only
one
they
will
ever
sign
against.
B
So
that's
that's.
That
provides
a
very
important
security
guarantee
because,
because
I
there's
a
concept
in
Kerry
called
the
threshold
of
accountable
duplicity,
which
allows
us
to
recover
from
a
key
compromise
and
once
I
reach
the
threshold
of
witnesses
that
have
signed
a
version
of
the
log.
They
can't
go
back
because
they
signed
it,
and
so
when
I
get
a
majority,
then
I
can
make
the
same
sort
of
guarantees
that
I
make
with
any
distributed
consensus.
B
Algorithm
that
says,
if
I
have
you
know
three
F
plus
one
where
F
is
the
number
of
potentially
failure
Faline
witnesses.
If
two
f
plus
one
sign,
then
then
there
can
only
be
one
authoritative
copy
of
the
log
or
none
there
can't
ever
be
two,
which
means
that
I'm
that
the
the
validator
is
protected
because
I
have
a
I,
basically
have
neutralized
any
other
possible
copy
right.
So
I
get
the
same
guarantee
it's
the
same,
guarantee
that
I
get
with
any
pbft
algorithm
I,
just
don't
need
to
I.
B
Just
don't
need
to
have
a
3-phase
commit
because
there's
only
one
source
of
truth
and
that's
the
controller,
so
I
take
advantage
of
a
single
source
of
truth
and
I
only
need
to
order
events
with
respect
to
identifiers
to
greatly
simplify
the
whole
idea
of
distributed
consensus,
but
I'm
still
using
the
same
guarantees
in
the
sense
that
if
I
get
a
majority
of
witnesses,
witness
then
it's
immutable
its.
It
can't
go
backwards.
I've
neutralized
any
other
copy.
A
Wonderful,
let
me
just
comment
that
and
Sam
is
working
together
with
Drummond
read
on
the
chapter
for
decentralized
key
management,
which
incorporates
a
lot
of
this
thinking.
So
it's
part
of
yourself
so
an
identity
book
that
we've
been
working
on
for
ages
now
and
if
we
will
continue
working
on
for
ages,
but
you
can
acquire
like
that.
B
A
Wonderful
that
sounds
very
promising
for
everyone
else.
If
you
want
to
keep
on
learning
and
hearing
about
the
nexus
I
meet
ups,
please
sign
up
to
a
newsletter.
Just
go
to
website
ssi
meet
up.
Okay,
you
can
sign
up
that's
the
quickest
way.
You
also
have
our
telegram
channel
and
all
the
other
social
media
like
Facebook,
Twitter,
etc,
and
our
next
session
will
be
with
Tim
boma
from
who's
mr.
identity
in
Canada,
and
he
will
be
talking
about
the
Canadian
trust
framework
and
that
he
he
has
been
working
on
together
with
Dave
Roberts.
A
Well,
and
without
further
stuff
to
deal
with
vii.
Thank
you
so
much
for
joining
us
today.
I
think
this
was
really
interesting.
It
was
one
of
the
more
technical
sessions,
but
there
were
a
lot
of
questions.
So
that's
really
good
and
I
hope
to
have
you
back
in
the
future
to
when
you
feel
like
yes,
but
if
we
can
keep
on
digging
into
the
details
about
how
you're
making
progress
with
this
yeah.