►
Description
Identity projects need to support business objectives, be easy to adopt, and protect the rights of the identity holder. That is a tall order, but real world deployments show this to be possible through the use of distributed ledgers. In this session, Hyperledger member, Evernym, will focus on the analysis and discussion of two use cases where legacy identity solutions were unable to meet the needs, but ledger based solutions have been successful: covid credentials for travel, and employment credentials for staff movements. Andy and James will introduce the solutions and are eager for feedback. By the end of the session, we hope you will be able to distinguish use cases where digital identity makes sense, as well as understand how Hyperledger Indy and Aries can play a role.
Learning outcomes:
* Why digital identity projects need a distributed ledger like Indy
* Why digital identity projects need an open protocol like Aries
In the “Hyperledger In-depth: An hour with… .” series, Hyperledger members share learnings from their projects and try to answer all the hard questions about the pains of working with DLTs. It is not yet another webinar: participants will be encouraged to take part, come with prepared questions and voice opinions. Expect live demos and tutorials, stories from the battle field and hopefully some heated discussions. Let's get out of the zoom fatigue and engage to share experiences and build a stronger community.
----
Hyperledger – Open Source Blockchain Technologies
Hyperledger is an open source community focused on developing a suite of stable frameworks, tools and libraries for enterprise-grade blockchain deployments.
It serves as a neutral home for various distributed ledger frameworks including Hyperledger Besu, Fabric, Sawtooth, Indy, as well as tools like Hyperledger Avalon, Cactus and libraries like Hyperledger Aries, Ursa. Learn more about Hyperledger projects: https://www.hyperledger.org/use
Case Studies: https://www.hyperledger.org/learn/case-studies
Training & Certification: https://www.hyperledger.org/learn/training
Tutorials: https://www.hyperledger.org/use/tutorials
Webinars: https://www.hyperledger.org/learn/webinars
Events: https://www.hyperledger.org/events
Vendor Directory: https://www.hyperledger.org/use/vendor-directory
Subscribe to the Hyperledger Newsletter: https://www.hyperledger.org/newsletter
Follow-us on Twitter @Hyperledger
Learn about Hyperledger Membership: https://www.hyperledger.org/about/join
#Hyperledger #HyperledgerMemberWebinars #Blockchain
A
B
A
Okay,
we
are
getting
a
good
crowd
here,
I'll
start,
allowing
people
to
talk
of
course
bear
in
mind
that
standard
zoom
etiquette
is
still
in
place.
So
please
don't
don't
talk
over
each
other
hello,
julian
good,
to
see
you
hello,
everyone,
okay!
So
while
we
wait
how
about
we,
we
have
a
good
crowd,
but
not
overly
big.
So
I
think
it
would
be
great
if
we
can
start
with
everyone.
A
C
Hi
there
I'm
karsten
davenhut
and
I'm
from
germany
and
work
for
dfine
and
yeah.
We
are
at
the
moment
working
or
starting
to
work
on
a
poc
that
is
related
to
ssi
and
so
yeah.
We
are
very
much
interested
to
hear
from
avenue
about
their
use
case
and
yeah.
So
I'm
excited
to
hear
about
how
such
a
use
case
can
be
implemented.
E
Yeah
hi,
I'm
darling
from
frankfurt.
I
work
with
carson,
so
it's
basically
the
same
reason.
We
recently
started
working
on
this
product
for
with
an
ssi
use
case,
and
we
already
talked
to
evernum
about
it
and
now
we're
eager
to
learn
more
about
what
what
evernote
has
to
offer
in
this
space.
Exactly
here.
F
H
A
D
I
J
K
A
M
A
G
A
A
A
Everybody's
allowed
to
speak,
but
let's
stick
to
the
good
practices,
meaning
let's
mute
ourselves,
while
not
speaking,
if
you
feel
like
there's
a
whole
big
discussion
going
on
and
you
can't
jump
in
or
you
just
want
to
signal
raise,
do
the
raise
your
hand,
thing
I'll,
be
observing
it
and
we'll
make
sure
to
to
let
you
speak.
You
can
also
ask
questions
in
the
q,
a
box.
A
I
realized
that
I
didn't
do
one
thing
so
I'll
stop,
sharing
and
now,
andy
and
and
james
you
are
able
to
share
your
screens
and
andy
and
james
will
walk
us
through
the
solutions
that
everyone
built
with
ssi,
specifically
the
use
case
of
their
work
with
ayata,
as
well
as
their
covered
work.
It's
my
great
pleasure,
I'm
a
huge
fan
of
ssi,
so
I'm
looking
forward
to
this
session
as
much
as
you
do,
probably
so.
Take
it
away.
R
R
So
really,
I
think,
we'll
just
kick
off
quite
quickly
andy
and
I
will
introduce
ourselves
we'll
talk
a
bit
about
the
history
of
our
involvement
with
with
hyperledger
and
in
particular
the
the
aries
in
india
project,
and
then
we
can
spend
as
much
or
as
little
time
as
you'd,
like
on
a
couple
of
use
case,
examples
that
we've
got
but
do
raise
hands
interject
with
questions
and
all
that
kind
of
stuff
as
we're
going
through.
Because
that's
that's
the
point.
R
So
in
terms
of
ourselves,
so
I'm
james
monaghan,
I'm
head
of
product
here
at
evernum,
where
I've
been
since
september,
2016,
which
I
think
is
about
20
years
in
blockchain
years,
but
it's
been,
it's
been
wild
and
I'm
coming
to
you
live
from
my
my
very
green
study.
It
is
actually
this
color
green,
although
this
is
a
fake
background
here
in
west
london
andy.
Do
you
want
to
give
a
little
intro
yeah.
S
R
Exactly
and
andy-
and
I
have
the
the
questionable
pleasure
of
knowing
each
other
from
a
previous
startup
venture,
actually
along
with,
along
with
sam
who's,
on
the
call
thanks
for
joining
sam.
It's
great
to
see
you
buddy,
so
here
we
go.
We
go
way
back.
Okay,
so
I
think
a
lot
of
people.
In
fact,
we
could
do
a
quick
show
of
hands
for
this.
R
Couldn't
we
from
the
intros,
I
gather
there's
a
number
of
people
who
are
aware
of
ssi
generally
and
there's
quite
a
few
folks
who
are
who
are
familiar
with
with
hyperledger
indian
areas,
but
I'm
I'm
curious
sort
of
as
as
as
an
audience
goes,
how
valuable
would
a
would
a
brief
overview
be?
Do
you
want
to
do
a
quick,
quick
raise
of
hands
if
you're
familiar.
R
S
R
One
of
them
has
gone
down,
oh
dear,
all,
right
well,
we'll
make
we'll
make
this
part
super
quick,
then
andy,
very
good.
Look
the
there's
two
main
well
actually,
three
high
pleasure
projects
that
evidence
I'm
very
closely
involved
in
and
they're
they're
hyper
legit
aries
have
legit
indie
and
hybrid
ursa.
Historically,
they
came
out
of
a
out
of
a
common
code
base,
but
they've
since
evolved
into
three
quite
distinct
and
full-fledged
projects
in
their
own
rights.
R
It
doesn't
doesn't
really
matter,
but
really
aries
gives
you
a
framework,
so
there's
a
set
of
rfcs
which
tell
you
how
to
build
things,
there's
also
a
plethora
of
code
bases
that
implement
those
rfcs
in
a
number
of
different
languages
that
let
you
go
and
actually
build
concrete
implementations
of
identity
agents
to
to
create
all
kinds
of
trusted,
peer-to-peer
interactions,
and
that's
that
blockchain
rooted
part.
That's
where
hyperledger
indie
comes
in
so
hyperledger
indie
is
a
an
implementation
of
a
public
permissioned
distributed
ledger
with
rbft
consensus.
R
We
wanted
something
that
was
open
and
auditable
and
had
a
lot
of
the
the
valuable
properties
of
a
public
distributed
ledger,
but
you
knew
more
than
nothing
about
who
the
individuals
were
that
were
actually
writing
those
transactions,
and
so
that
was
what
led
to
the
creation
of
the
plenum
consensus
mechanism
and
the
the
indie
blockchain
that's
built
around
it.
Obviously,
technology
has
moved
on
quite
a
bit
since
then,
so
there
are.
S
S
Where
did
indy
come
from?
Well
back
in
2015,
2016
ebonym
wrote
all
the
code
that
makes
indeed
work
and
we
wanted
that
code
to
be
open
source
to
allow
anyone
to
use
it,
because
you
know
if
it
was
just
an
ebonym
thing
and
proprietary,
then
we
wouldn't
get
the
global
traction
that
we
wanted
for
for
this
whole
principle
of
self-sovereign
identity.
S
So
what
was
previously
really
complex,
really
expensive,
highly
sophisticated
cryptography
was
then
available
for
free,
essentially
with
all
of
the
infrastructure
around
it,
to
enable
you
to
to
run
this
amazing
capability
that
lets
you
move
digital
credentials
around
and
do
dids,
and
that
kind
of
thing
the
origin
of
some
of
the
other
components,
like
decentralized
identifiers,
wrote
about
95
of
that
decentralized
identifier,
spec,
that
is,
is
now
elevated
up
to
the
worldwide
web
consortium.
So
that's
why
james
and
I
are
in
the
room.
R
What
what's?
What's
wonderful
about
that
is
you
know,
while
it's
true
that
we
were,
we
were
very
early
to
the
scene
along
with,
along
with
a
bunch
of
other
collaborators.
You
know
now
you
look
at
both
those
both
those
specs
and
these
code
bases,
and
you
can
count
tens
of
thousands
of
contributions
from
hundreds
of
different
organizations.
So
it's
you
know
that
I
meant
what
I
said
earlier
about
these
truly
being
you
know
fully
fledged
independent
projects
in
in
no
way.
R
In
no
way
is
this
an
evidence
show
which
is
which
is
really
really
cool
and
and
how
they
fit
together.
I
mean,
I
think,
andy
just
described
the
relationship
between
the
pieces,
but
just
in
terms
of
the
self-sort
and
identity
piece
and
where
indian
areas
fit.
The
simplest
kind
of
interaction
in
in
ssi
is
one
where
you
would.
You
know
an
issuer,
so
some
trusted
entity,
a
passport
authority
say
or
a
club
offering
membership.
Anything
really
wants
to
give
a
credential
to
a
holder.
R
R
The
the
way
you
make
that
work
is
that
the
the
dids
so
the
identifiers
of
the
public
entities
like
the
issuers,
they
live
on
on
a
public
registry,
and
so
we
use
hyperledger
indie
for
that
and
the
protocol
for
exchanging
credentials
and
proofs
and
negotiating
those
connections
between
dids.
That's
where
hyperledger
aries
comes
in
in
our
case.
R
So
when
you
think
about
this
kind
of
canonical
w3c
style,
verifiable
credentials
exchange
and
there
are,
there
are
other
protocols
and
other
blockchains
and
other
projects
that
are
used
to
achieve
these
things.
But
in
our
ecosystem,
we've
chosen
hyperlogic
indie
for
the
for
the
blockchain
layer,
inhabited
aries
for
the
agent
to
agent
communication
protocol,
and
so
that's
where
that's,
where
that
stuff
fits
in
and.
S
Just
a
quick
sort
of
demystifying
bit
as
well
james,
because
at
the
heart
of
this
it's
what
we're
doing
is
essentially
providing
an
ability
to
move
some
data
digitally
from
a
to
b,
the
issuer
to
the
verifier
via
the
holder
right
digital
data.
That
data
would
be
the
same
data
as
you
might
print
out
on
a
piece
of
paper
like
in
a
passport
or
a
bit
of
plastic
like
a
driving
license,
but
it's
being
wrapped
in
a
container
a
cryptographic
container
with
some
data
watermarking
on
it,
the
data.
S
This
capability
now
enables
the
data
that
would
be
on
that
bit
of
paper
to
be
put
in
a
watermark
digital
envelope,
with
lots
of
other
sophisticated
things
under
the
skin
that
make
it
much
better
than
paper.
So
just
think
of
it
like
that,
when
people
often
say
who
are
these
issues
well,
they're
the
same
organizations
who
currently
issue
you
with
bits
of
paper
at
the
moment.
R
Yeah
and
then
I
think
one
point
on
you
know
I
alluded
to
fact:
there
are
different
different
implementations
and
different
kind
of
code
bases
for
achieving
the
same
basic
construct,
one
of
the
things
that
makes
the
the
indian
aries
ecosystem
quite
special
and
the
reason
that
we've
we've
really
emphasized
that
in
our
work
is
the
very
strong
emphasis
on
the
on
the
privacy
of
the
identity
owner
themselves.
So
there's
a
lot
of
kind
of
blockchain
identity
projects
or
self-sovereign
identity
projects
that
follow
the
cryptocurrency
route
of.
R
Basically,
the
emphasis
is
on
public
immutable
records
of
things,
and
they
have
some
useful
properties.
That
means
they
can
never
be
taken
away.
It's
hard
to
dispute
them.
You
know
you,
you
can
be
absolutely
certain
and
that
the
person
who
signs
a
transaction
possesses
the
keys
that
pertain
to
their
wallet
and
therefore
they're.
Probably
that
person
it's
quite
useful,
but
the
disadvantage
of
some
of
those
approaches
is.
R
R
That
would
be
considered
kind
of
quite
egregious,
but
we
know
that
happens
online
all
the
time,
because
it's
made
very,
very
easy,
and
so
what
we
didn't
want
to
do
was
create
an
identity
infrastructure
that
made
it
really
really
easy
to
dial
up
that
level
of
quite
invasive
and
kind
of
anti-privacy
surveillance,
and
so
indian
areas
have
a
couple
of
really
powerful
features
that
make
it
useful.
One
is
that
these
agent-to-agent
connections
here
that
are
broken
by
hyperledger
areas.
R
R
That
would
be
a
very
simple
way
of
doing
it,
but
that
would
have
the
consequence
of
meaning
that
you're
revealing,
say
all
the
attributes
on
your
driver's
license
and
because
you're
revealing
the
signature,
something
that
uniquely
identifies
you
everywhere,
you
go
so.
Instead,
what
these
code
bases
include
is
a
really
cool
way
of
selectively
disclosing
certain
attributes
from
the
credential
that
you
want
to
prove
and
doing
so
in
a
way
that
can
be
indisputably
linked
back
to
the
issue
of
that
credential,
but
not
to
the
particular
credential
itself.
R
Authority
has
not
been
tampered
with
and
hasn't
been
revoked,
but
they're
not
learning
anything
else,
except
that
your
date
of
birth
is
within
a
particular
range
because
you
didn't
choose
to
reveal
that,
and
that's
that's
quite
a
unique
capability
that
there's
not
a
lot
of
other
ssi
projects
out
there.
That
can
can
make
all
of
those
promises
and
andy's
just
posted
a
link
in
the
chat
to
this
safe
credentials,
set
of
kind
of
principles
which
which
we
in
evidence
and
also
the
the
aries
in
india
ecosystem,
I
think,
feel
very
strongly
about.
R
A
R
O
R
Well,
you
you,
could
you
could
do
it?
What
we've?
What
we've
tried
to
make
sure
is
that
that's
not
the
default
behavior
right,
which
is
how
things
work
today,
is
that
you're
sort
of
always
disclosing
if
the
verifier
needs.
You
know
if
you're
renting
a
car,
and
they
literally
need
all
of
the
attributes
from
your
driver's
license
and
because
that's
a
legal
requirement,
then
there's
nothing
that
prevents
you
from
from
sharing
that.
But
what
we
don't
want
is
a
situation
where
actually,
in
most
cases,
people
don't
need
all
of
the
attributes.
R
They
just
need
a
subset.
So
we
want
to
encourage
minimum
disclosure
by
default,
and
so
the
protocol
makes
it
very
very
easy
to
verify
to
say
look.
I
just
need
your
legal
first
and
last
name
from
any
one
of
these
10
issuers
that
I
trust
and
your
agent.
If
you've
implemented
it
using
the
the
indiana
various
projects,
your
agent
will
be
able
to
go
into
the
wallet,
find
credentials
which
satisfy
that
criteria
and
provide
azure
knowledge
proof
very
easily
to
the
verifier.
So.
R
Yeah
I
I
would
because
you
want
to
share
the
facts
either.
You
know
the
claims
within
the
credential.
What
the
verifier
probably
doesn't
need
is
the
the
original
signature
or
the
d
id.
That
is
specific
to
your
relationship
with
the
issuer,
for
example
those
those
kind
of
unique
identifiers
that
could
be
used
to
learn
more
about
your
relationships
elsewhere
than
you
necessarily
needed
to
disclose
in
that
interaction.
S
I
think
another
important
point
actually
is:
there's:
there's
lots
of
companies
kind
of
jumping
onto
this
digital
credential
bandwagon,
if
you
like,
and
not
all
digital
credential
solutions
are
the
same.
It's
really
important
to
realize
that
the
problem
is
that
you
don't
realize
they're,
not
all
the
same
unless
you're
quite
low
down
in
the
detail.
You're
looking
at
is
the
issuer's
signature
shared
to
the
verifier
or
not
right.
S
So,
as
james
says,
the
the
thinking
that's
gone
into
how
these
protocols
work
has
been
based
on
a
very
high
privacy
requirement,
such
as
not
sharing
the
issue
of
signature,
because
if
you
share
the
the
signature
the
issuer
uses
when
they
sign
a
credential-
and
you
share
that
everywhere,
you
use
information
from
that
credential.
All
those
verifiers
can
correlate
what
you're
doing,
because
they
can
all
see
the
same
signature.
S
So
there's
a
kind
of
a
wall
between
the
issuer
and
the
verifier.
There
says
no
integration
needed,
but
also
the
amount
of
information
shared
that's
been
used
to
create.
The
credential
has
been
limited,
such
that
the
verifier
can
check
it,
but
isn't
given
more
data
that
they
need
to
check
it,
and
it
prevents
the
verifiers
from
colluding
behind
your
back
to
piece
together.
More
information
about
you
than
you
would
want
to
share.
R
That's
a
really
really
great
question:
rick!
Thank
you
for
that
and
actually
before
we
I
think
it's.
This
is
an
optimum
point
to
pause
before
we
move
into
to
the
use
case
conversation.
If
anyone
else
has
questions
about
you
know,
indian
areas
and
how
they
how
they
actually
helped
to
to
build
this
kind
of
enabling
infrastructure
for
for
self-sovereign
identity.
Then
then,
please
speak
up
or
or
raise
your
hand
and
we'll
call
on
you,
whichever
you
prefer.
A
R
R
The
original
hyperledger
indicate
base
contains
both
the
the
plenum
consensus
algorithm
and
a
concrete
implementation
of
a
distributed
ledger
using
that
and
a
cryptographic
wallet
for
agents
to
use
and
an
agent
to
agent
protocol
for
them
to
use,
and
it
was
opinionated
about
the
transport
layer
and
things
like
that.
The
protocol
used
and
it
contained
an
implementation
of
the
zero
knowledge
credentials
and
so
on
and
so
forth
right.
So
it
was,
it
was
an
opinionated
implementation
of
a
identity.
R
Meta
system,
if
you
will
and
what's
been
great,
is,
as
the
community
has
picked
this
up
and
got
involved,
there
have
been
really
fantastic
contributions
about
well.
Actually,
we
could
use
different
ledgers
that
have
different
properties
like
indie
suits
some
projects
really
well.
Other
people
would
prefer
something
permissionless
like
like
the
ion
project,
from
from
microsoft,
for
example,
and
so
on
and
so
forth.
R
Other
people
are
very
interested
in
different
flavors
of
agents
that
that
aren't
about
individuals
having
wallets
on
mobile
phones,
for
example,
but
might
be
more
about
connected
devices
or
so
forth,
and
so
there's
a
whole
separate
flavor
of
work
around
the
the
agents
themselves
and
then,
finally,
a
lot
of
the
cryptographic
primitives
that
were
created
to
enable
these
zero
knowledge.
Proofs,
they're,
based
on
on
20
year
olds,
20
year
old
work.
R
But
they
were
some
of
the
first
like
practical
implementations
of
those
things,
and
they
were
useful
in
other
types
of
projects,
aside
from
specifically
identity
projects,
and
so
what
that
led
to
was
essentially
these
those
three
separate
components:
the
the
ledger,
the
agent
to
agent
protocol
and
the
the
underlying
crypto
primitives
each
becoming
full-fed
full-fledged
projects
in
their
own
right,
because
they
each
have
a
separate
community
around
them.
So
they
fit
together
really
really
nicely
when
you're
building
ssi
things
but
they're,
quite
pluggable
and
useful
elsewhere
in
their
own
right.
T
Oh
no,
I
was
just
getting
set
up,
but
I
mean
no.
I
think
that
all
makes
sense,
because
the
last
time
I
seen
it
I
was
a
bit
not
confused.
I
I
remember
ares
coming
out
of
indy
and
I
was
it
was
aries
yeah,
it
was
areas
I
was
trying
to
arsenal
was
trying
to
get
my
head
around,
but
no
that
was
a
good
explanation,
makes
a
lot
of
sense.
S
Typically,
you
won't
do
much
with
indie
if
you're
going
to
implement
a
deployment
of
some
of
the
the
sorts
you'll
see
in
a
second
you'll,
be
typically
interacting
with
aries
from
a
mobile,
app
perspective
or
an
enterprise
integration
perspective
ursa
looks
under
the
skin
there.
You
know
if
you're,
a
real
crypto
geek,
you
know
dive
in
and
have
a
look.
It's
pretty
amazing.
An
indie
is
used
at
their
bottom
layer
for
the
the
ledger
infrastructure,
so
most
interactions
will
happen
with
with
aries.
R
Yeah,
what's
great
is
that
there's
you
know
there's
for
people
looking
to
get
involved
in
in
open
source,
though
there's
there's
projects
that
can
scratch
all
these
all
these
different
itches
right.
So,
if
you're
go
back
here,
if
you're
into
consensus,
algorithms
and
things
like
that
state
proofs,
you
know
indie's
a
fascinating
project
to
to
get
involved
with
you
know,
at
the
application
layer
there
are
rfcs
in
aries
for
doing
all
kinds
of
things
that
are
not
just
related
to
exchanging
credentials
back
and
forth.
R
You
know
people
have
have
looked
at
what
a
chat
protocol
might
look
like
what
digital
receipts
might
look
like
for
purchases.
What
payments
might
look
like
over
aries
all
these
kinds
of
things?
So
all
the
different
layers
of
the
stack,
which
should
be
should
be
really
great.
So
for
folks
who
are
looking
to
get
involved,
there's
there's
different
projects
that
suit
different
predilections
there
as
well.
R
O
G
O
R
That's
such
a
good
question
rick,
because
that
is
that
is
a
point
of
you
know
quite
active
debate.
Honestly,
you
know
there's
having
a
having
a
cloud
agent
where
the
mobile
ui
is
essentially
a
remote
control,
for
it
is
offers
a
number
of
practical
benefits.
You
know
it's
easy
to
build,
scalable
cloud
infrastructure.
There
are
well-established
patterns
for
how
you
secure
that,
and
things
like
that,
and
so
it's
it's
it's
a
very
practical
way
to
get
started,
and
likewise
the
thin
client
on
mobile.
R
You
know
the
development
talent,
for
that
is
widely
available.
It's
it's
an
incredibly
pragmatic
way
to
get
started,
and
so
that
is
the
path
that
a
lot
of
people
have
chosen
it.
It
introduces
some
challenges,
though,
that
are
not
unlike
the
trade-offs
of
the
legacy
identity
world
which
self-sovereign
identity
tries
to
get
away
from,
which
is
that
it
makes
you
place
a
lot
of
trust
in
whoever
is
running
that
cloud
agent
for
you,
because
at
the
end
of
the
day
you
don't
actually
control
those
keys
and
those
credentials
you
are.
R
You
have
an
app
that
issues,
some
instructions
to
a
piece
of
software
that
runs
on
someone
else's
machine
and
you
hope
that
it
does.
What
what
you
ask
it
to,
and
that
is
you
know
you.
You
could
make
the
case
that
that
is
not
that
different
to
using
a
federated
identity
provider
like
a
sign
in
with
signing
with
google
or
microsoft
azure
active
directory,
or
something
like
that.
R
R
Our
connect.me
mobile
app
and
the
the
mobile
sdk
that
we
give
to
to
our
customers
who
want
to
build
their
own
apps,
is
a
full-fledged
edge
agent,
so
that
the
keys
and
the
wallet
and
the
credentials
themselves
all
live
on
the
mobile
device
itself
and
the
there
is
a
cloud
component.
But
it's
really
just
an
aries
mediator
that
is
used
to
relay
messages
back
and
forth
encrypted
messages
that
it
can't.
It
can't
read
that
that
approach
is
to
make
it
work
well.
R
On
mobile,
I
used
this
phrase
opinionated
earlier.
You
know
it
had
to
make
some
implementation
choices
to
to
make
it
actually
work
reliably
on
on
ios
and
android,
and
so
there
is,
there
is
an
open
source
implementation
of
that.
It's
it's
the
original
agent
to
agent
protocol.
That
was
part
of
that
code
base.
Andy
mentioned
in
the
kind
of
the
little
history
lesson
there.
R
It's
called
called
vcx,
which
is
evidence,
verifiable,
credential
exchange
library,
and
so
that
that
is
open
source
as
and
comes
with,
builds
for
for
ios
and
android.
The
the
aries
community
itself
is
is
not
a
big
fan
of
the
approach
that
we
took
at
evonim.
So,
while
that
that
project
is
open
source,
it's
not
actually
part
of
the
the
aries
code
base,
and
so
it's
made
available
as
evidence
open
source.
Instead,
you
know.
So
that's
that's
where
that
exists.
R
You
know-
and
this
is
the
this-
is
the
beauty
of
community
governed,
open
sources
that
you
know,
there's
a
there's,
a
lively
debate
about
the
right
way
to
do
things,
and
you
know
we
we
welcome
that.
Frankly,
so
we
we
don't
get
to
say,
hey
look.
We
did
loads
of
work,
we're
gonna,
we're
gonna,
put
this
in
your
project
and
you're
gonna
take
it.
You
know,
there's
a
conversation
about
whether
it's
it's
consistent
with
the
direction
that
that
project
wants
to
go
so.
S
It
is
worth
saying
the
dividend
connect
me
app
and
the
sdk
that
it's
built
on
is
areas
compatible,
though
james,
isn't
it
and
actually
that
we
are
open
sourcing,
all
of
our
propriety
software
right
now,
so
our
verity
enterprise,
credential
exchange
platform
has
been
open
sourced
already.
You
can
have
a
look
at
it.
S
S
So
get
it
right
from
the
start,
and
part
of
that
is
having
an
edge
agent
that
is
fully
capable
fully
featured,
is
a
full
wallet
with
the
ability
to
create
peer
deds
on
the
fly
and
hold
credentials
and
create
proofs
with
all
the
crypto
in
it.
So
that's
what
connect
me
is,
and
the
code
underneath
it
with
aries
compatibility
is,
is
very
capable
as
well
yeah,
and
you
could
probably
show
us.
R
How
it's
used
can't
we
exactly
and
it
and
it
does
so.
I
think
the
point
is
that
it
works
in
its
past.
It's
past
the
interoperability
tests
with
other
areas
compatible
wallets
like
occupy,
for
example,
so
you
can
use
occupy
to
issue
credentials
into
into
our
edge
wallet
connect
on
me
and
likewise,
connect.me
can
prove
to
occupy
verifiers,
and
things
like
that.
A
R
R
Let's
do
that
then,
all
right,
oh
gosh,
look
at
that
so
yeah
I'll.
Do
this
I'll.
Do
this
fairly
quickly,
then,
because
the
most
interesting
part
is
going
to
be
the
discussion,
but-
and
also
probably,
some
of
you
have
read
about
this
this
anyway,
because
you
can't
open
a
newspaper
these
days
without
a
conversation
about
health
passports,
community
passports-
I
think
everyone
is
looking
forward
to
the
summer-
wants
to
go
traveling
again
these
kinds
of
things.
R
This
is
public
health
experts
and
sovereign
governments,
and
things
like
that
are
proposing
that
a
reasonable
risk-adjusted
way
to
reopen
travel
might
be
to
have
you
prove
that
you've
had
a
recent
negative
covert
test.
In
addition
to
proving
that
you
have
a
legal
travel
document
and
there's
a
lot
more
nuance
to
it
and
a
lot
of
policy
debate
around
it-
which
I
I
don't
think
I
don't
think
is-
is
our
place
to
weigh
in
on
frankly.
But
this
is
what
this
is.
R
What
a
number
of
governments
and
and
trade
bodies
have
decided
is
the
way
they
want
to
solve
the
problem,
and
so
seeing
that
we
think
gosh
well,
there's
there's
a
number
of
damaging
and
harmful
ways.
You
could
do
that
from
a
private
perspective
or
there's
there's
some
quite
quite
elegant
ways.
You
could
do
it
so
working
with
iata.
What
we
have
come
up
with
is
an
industry
solution
for
this.
R
The
required
proof
that
hey
you're
allowed
to
travel
from
your
passport.
You
have
a
valid
boarding
pass
and
you
have
a
negative
code
test
and
doing
all
that
with
with
the
privacy
properties
that
we
were
just
discussing,
and
so
that
sounds
fairly
simple.
Obviously
you
could
hand
a
an
opportunity
like
that
to
a
large
tech
vendor
and
they
build
you
a
big
database
right.
R
Let's
say
no
problem:
hundreds
of
airlines,
thousands
of
airports,
a
few
hundred
passport
issuers,
easy
peasy,
let's
get
oracle
on
the
case,
and
you
know
that
that
works
to
a
certain
extent.
Until
you
have
to
answer
the
question
of
well,
who
runs
that
database
and
who
pays
for
it
and
who
decides
who
connects
into
it?
And
what
do
you
do
about
the
fact
that
if
this
has
to
be
global,
there
is
no
one
sort
of
global
standard
for
handling
the
data,
governance
and
privacy
concerns
and
very
quickly?
R
You
end
up
in
a
place
where
you
realize
you
know
ayat,
as
a
trade
body
are
very
well
positioned
to
to
advocate
for
a
common
standard
for
how
you
do
this,
but
it
wouldn't
make
a
lot
of
sense
for
them
to
build
a
centralized
system
with
a
master
record
of
every
traveler
in
the
world's
health
status.
That
would
be
prohibitively
expensive
and,
frankly,
quite
a
bad
thing.
Now,
there's
a
as
andy
posted
a
link
to
in
the
chat.
There
was
a
whole
kind
of
90-minute
webinar.
R
We
did
that
that
goes
into
detail
on
this,
with
with
the
team
from
iata,
actually
you'll,
be
able
to
find
a
link
to
that
on
our
website,
but
at
a
high
level.
The
the
way
the
solution
looks
is
is
like
this,
so
armed
with
privacy,
enhancing
verifiable
credentials
and
the
hyperledger
areas
in
indies
indie
projects,
you
can
see
how.
R
R
This
would
show
you
that
classic
truss
triangle
that
almost
every
ver
verifiable
conditioner's
use
case
ends
up
coming
down
to
it
ends
up
it's
really
quite
simple,
but
what's
powerful
about
it
is
the
scale
that
building
it
on
these
open
frameworks
enables
because
not
everybody
has
to
use
the
iata
app
as
long
as
they
use
the
standards
that
iata
promotes.
Then
airlines
can
embed
this
in
their
own
mobile
app
and
build
their
own
solution.
Not
every
testing
lab
needs
to
get.
R
You
know
a
solution
from
evidence
or
even
from
iata
as
long
as
they're,
following
the
governance
process
associated
with
it,
with
issuing
a
compatible
credential
and
as
long
as
they're
using
the
hyperlinked
areas
protocols,
then
then
they're
good
to
go,
and
similarly
we're
not
asking
every
airline,
airport
and
immigration
authority
in
the
world
to
plug
into
one
big
centralized
system.
That
would
be
awful
from
a
scalability
perspective.
R
You
know
we
want
to
get
back
to
four
billion
travelers
a
year,
and
so
instead
they
can
all
choose
solutions
that
meet
these
requirements
from
the
vendors
of
their
choice
and
and
go
and
implement
something.
In
together,
we
build
a
vibrant
global
ecosystem
that
starts
off
with
airline
travel
that
can
easily
expand
into
not
just
other
forms
of
travel,
but
a
number
of
other
sort
of
high
occupancy
scenarios
where
people
are
very
worried
about
the
implications
of
of
admitting
people
that
have
unknown
health
status,
and
so
in
a
nutshell.
R
S
S
Normally
your
phone
will
be
backed
up
and
you
can
elect
to
have
contents
of
various
apps
backed
up
so
the
the
first
put
a
call
here
with
the
what,
if
I
lose
my
phone
question
and
we
have
got
a
really
good
blog
article
on
this,
which
we'll
have
to
dig
up
actually.
Is
that
what
would
happen
if
you
lost
your
paper
credentials
right?
S
S
That
worst
worst
case
scenario
is
the
same
as
the
the
best
case
with
paper
documents,
which
is
you
you
go
start
again
and
you
you
get
them
reissued
again.
So
there's
a
lot
of
advantages
to
having
digital
credentials
in
the
digital
wallet
and
they
they
can
be
backed
up
and
restored,
and
this
is
probably
a
new
business
opportunity
for
maybe
organizations
like
banks,
who
you
trust,
to
hold
your
monetary
credentials.
Are
you
your
money
and
a
bank
account
and
well?
S
R
You
know
the
the
paper-based
process
will
still
need
to
exist
and
will
for
some
time,
but
this
this
is
going
to
be
offered
to
travelers,
who
you
know
who
will
see
the
benefits
in
it,
and
I
think
certainly
a
lot
of
a
lot
of
frequent
travelers
definitely
will
right.
Mark
mark
has
his
hand
up
you.
What
would
you
like
to
say
mark.
E
Yes,
thank
you
so
much.
I
like
this
picture,
it's
very
clear,
but
what
I'm
missing
is
who
offers
credentials
to
the
testing
lab?
I
mean
at
some
point.
The
airport
or
airline
will
have
to
deal
with
thousands
of
testing
labs
worldwide
and
they
cannot
travel
to
each
of
them
and
check
if
that's
actually
legit
right.
So
there
must
be
some
government
or
someone
who
issues
credentials
to
the
testing
lab
such
that.
I
know
that
I
can
trust
that
lab.
R
R
Basically,
so,
if
you're,
a
citizen
of
country
a
with
a
passport
from
country
b,
with
a
visa
of
type
c
and
you're
traveling
to
destination
d
volume,
e
et
cetera,
it
can
figure
out
whether
or
not
you
can
get
on
the
plane
and
and
what
what
requirements
you
need
to
meet.
So
that's
used
at
check-in
and
all
kinds
of
things
to
try
and
make
sure
that
airlines
are
not
boarding.
R
Passengers
who
will
be
turned
away
at
their
destination,
and
so
ayata
is
extending
the
capabilities
of
that
to
bring
in
government's
own
requirements
about
what
type
of
test
is
going
to
be
permitted
for
for
entry.
So
the
first
thing
is
to
capture
okay.
You
know
we
require
pcr
tests
72
hours
before
before
flights,
or
you
know
we
need
a
rapid
flow
test
that
happens
in
the
departure
board.
R
You
know
whatever
happens,
to
be
and
they're
capturing
all
those
requirements
and
then
they're
working
with
the
airlines
themselves,
who
have
been
very
busy
in
the
last
several
months.
Signing
partnerships
with
labs
in
the
countries
that
they
operate
to
provide
these
types
of
services
and
ayatu
is
on
boarding
them
all
into
a
registry,
and
it's
a
simple
trust
registry
that
says:
okay,
these
these
labs,
which
meet
the
requirements
of
these
airlines
which
are
guided
by
these
government
requirements.
R
R
So
I
can
infer
some
level
of
trust
from
it.
I
can
make
some
decisions
and
there's
a
whole
stack
that
sort
of
sits
next
to
the
technical
stack,
which
is
the
governance
stack
and
the
trust
over
ap
principles
show
you
how
to
how
to
build
that
framework
up
from
the
did
level
through
the
credentials,
change
level
to
the
wallet
level
and
and
so
on
and
so
forth.
So
iata
and
a
number
of
industry
participants
in
the
good
health
parts
foundation.
R
Correct
it's
it's
a
locus
of
centralization
for
this
particular
use
case,
because
what
everybody
here
has
in
common
is
they
want
to
know
that
they
want
to
know
that
someone
they
trust
issued
that
credential
and
so
in
the
beginning.
Ayato
is
acting
as
as
a
proxy
for
that
they're
saying.
Well,
look!
We!
We
have
some
expertise,
not
really
in
the
technology
level.
T
I
can
try
and
be
a
bit
quick,
so
I
have
to
drop
off.
I
have
another
call
about
to
start.
You
see
just
on
the
whole
losing
my
phone
does.
Does
that
mean?
Does
the
device
play
a
part
in
the
verification
between
issuer
and
verifier
or
or
is
it
really
just
a
wallet
at
one
time
they
goes.
If
I
issued
a
credential
to
device
a
and
suddenly
it
was
being
asked
to
be
verified
from
device
b
that
would
raise
a
red
flag
for
some
people.
R
Yeah,
that's
a
really
good
point,
and
so
there
are
different
approaches
to
supporting.
You
know
multiple
devices
that
have
control
of
the
same
wallet
and
I
think
it's
safe
to
say
that
there's
no
at
the
moment
there's
no
one
approach
that
the
whole
community
has
agreed
on.
You
know
in
the
case
of
a
cloud
wallet.
R
So
we've
said
well
for
now
we
want
everyone
to
have
a
primary
device
and
a
primary
wallet
associated
with
it,
and
we
we
accept
that
that
might
preclude
us
from
playing
in
some
use
cases.
But
what
it
means
is
you've
got
a
very
strong
answer
to
that
question
because
basically
it's
either
your
primary
device
or
it's
not
you
yeah.
So
you
have
a
very
strong
guarantee.
T
G
A
S
Yeah
I
mean
recovery
is
a
really
important
point.
Actually,
you
need
to
make
sure
that
the
right
person
is
recovering
the
right
thing
in
the
case
of
loss,
there's
quite
a
few
different
approaches.
Everything
from
you
know
social
key
sharding
to
you
know
a
kind
of
guardian-like
approach
like
having
a
bank
look
after
your
backups
there's
lots
of
different
approaches
and
they'll
differ
depending
on
on
different
use
cases.
So
I
think
the
answer
that
paul
is
is
yes,
that
approach
could
work.
S
Aaron
says
how
can
I
stop
my
credentials
from
being
shared
by
airports
or
airlines
to
others
without
your
permission?
Okay,
that
is
a
good
one.
So,
when
you
provide
a
proof
that
proof
is
provided
down,
a
singular
unique
channel
you
have
with
the
verifier
that
proof
is,
is
not
usable
down
any
other
channel.
You've
you've
got
it's.
It's
particular
to
that
request
that
the
verifier
has
made,
and
it's
down
that
pairwise
connection
that
unique
link
you
have
with
that
particular
verifier.
S
Of
course,
if
you're
providing
some
data,
like
my
name,
is
andy,
that's
wrapped
up
in
a
nice,
secure,
watermark
cryptographic
envelope
right
the
verify
gets
that
unwraps.
It
unwraps
it
checks,
it
verifies
it
and
then
it
says
andy
and
this
the
fact
that
I
am
andy
was
issued
by
the
passport
office.
So
that's
great.
They
now
have
a
bit
of
data
that
says
andy
on
it.
R
Yeah
yeah,
okay,
we've
got
a
question
in
the
in
the
q
a
as
well
so
this
says
what
will
be
the
disadvantages
if
we
use
certificate
authorities
and
centralized
repositories
instead
of
dids
and
blockchains,
to
create
verifiable
credentials,
as
the
ecosystem
still
has
to
trust
the
stewards,
doing
onboarding
of
issues
etc
and
then
there's
a
sub-question,
which
is
what
are
the
incentives
for
stewards?
So
it's
a
two-parter,
so
disadvantages
of
of
using
centralized
repositories
instead
of
blockchain-based
dids.
S
Wow
and
it's
no,
it's
no
accident
that
some
of
the
biggest
certificate
authorities
in
the
world
are
involved
in
in
this
whole
space.
Looking
at
how
you
know
their
processes
from
boarding
businesses,
for
example,
to
issue
them
with
certificates
can
be
converted
into
verifiable
credentials
as
well.
So
there's
a
lot
of
interest
from
the
certificate
authority
space
which
you
could
see
as
being
them
being
positive,
looking
at
new
opportunities
and
also
being
defensive
as
well.
S
The
difference
here
is
the.
I
don't
need
a
certificate
authority
to
set
up
a
digital
relationship
with
another
party
in
this
this
new
world.
I
can
just
set
it
up.
So
if
I
need
a
digital
relationship
with
james
to
share
some
information,
I
can
set
that
up
independently
of
anyone
else.
Okay,
and
we
can
then
share
data
down
the
secure
link
and
that's
a
huge
capability
that
it's
hugely
important.
It's
not
really
existed
before.
S
We've
always
had
to
rely
on
somebody
else
now,
with
the
protocols
in
aries
for
free
anybody
can
create
a
software
stack
that
allows
two
parties
to
create
by
themselves
a
secure
digital
connection
and
share
information
across
it,
and
that's
that's
massive
that
can
be
used
for
so
many
things,
whereas
previously
you'd
have
to
rely
on
a
ca
to
give
you
a
certificate
that
you
can
then
use
and
then
have
to
get
back
to
the
ca
to
be
checked.
Yeah.
R
R
But
for
some
use
cases
like
you
know,
individual
enterprise
use
cases
and
things
like
that
using
a
centralized
like
literally
a
database
for
your
dids
would
be
perfectly
practical
and,
and
we
wouldn't
discourage
it,
the
only
issue
becomes
when
you
want
to
open
that
up
and
allow
use
cases
to
bleed
over
from
from
one
into
the
other.
And
then
you
really
want
something
that
that
can
be
open
and
suitable
for
everyone.
S
The
common
questions
on
steward
incentives,
actually
yeah
yeah
dave
and
one
from
nilesh,
maybe
I'll,
just
cover
that
quickly
james,
we
did
have
another
use
case
to
share
as
well,
which
we
could
probably
do.
But
let's,
let's
do
the
questions.
First,
that's
what
people
are
interested
in?
Obviously,
so
what
drives
the
students
to
be
part
of
the
sovereign
foundation
other
than
to
increase
the
trust
in
the
main
net
itself?
So
that
is
a
good
question.
S
S
R
S
R
R
S
I
think,
martin,
why
don't
we
just
do
like
a
couple
of
minutes
on
this
other
use
case,
and
then
I
want
to
just
james
you'll,
see
I've
just
dropped
in
slides
19
to
21
as
well.
So
we
could
cover
that
off
in
a
second
just
a
really
really
high
level.
In
fact,
let's,
let's
just
hit
slide
19.
First,
actually
could
we
james,
because
we
can
then
drop
back
into
this
use
case.
S
S
You
wanted
yeah
perfect
thanks,
so
I
mean
this
is
I
speak
bank
specific,
but
it
doesn't
matter,
but
imagine
a
large
global
bank
with
many
departments,
many
organizations
organizations
within
it,
often
for
regulatory
reasons.
They
can't
talk
to
each
other
right
or
they
may
be
allowed
to
talk
to
each
other.
But
if
you
just
say
the
next
slide
james,
what
they
have
to
do
to
make
that
work
is
they
have
to
create
loads
and
loads
of
spaghetti
behind
the
scenes.
Millions
of
apis.
S
S
S
The
customer
can
move
that
data
from
one
part
of
the
business
to
another
part
or
from
one
silo
to
another
silo
and
the
recipient
silo
can
verify
the
authenticity
of
that
data
straight
away.
So
the
customer
becomes
the
api
right,
the
customer,
the
user,
the
holder
they
they
take
the
data
and
they
move
it
between
the
silos.
For
you,
which
is,
is
epic,
if
you
think
of
it
from
an
efficiency
perspective,
it's
absolutely
fantastic.
S
S
By
giving
the
passenger
the
data,
the
passenger
can
move
the
data
around
the
silos
for
you
and
it
saves
a
huge
problem
with
apis
and
integration
behind
the
scenes.
So
that's,
if
you
can,
you
can
take
this
concept
and
put
it
into
any
use
case.
You
want
so
just
do
another
minute
on
the
employee
mobility
use
case.
S
If
we
just
hit
that
one
james
slide,
you've
got
to
go
up
and
down
here,
yeah
that
one
there.
So
imagine
if
you
will
a
massive
health
care
provider
in
the
uk,
that
happens
to
be
the
world's
fifth
largest
employer,
with
1.3
million
staff
composed
of
230
fairly
siloed
hospitals,
where
employees,
because
of
the
covert
situation,
have
to
move
around
an
awful
lot
between
these
different
hospitals.
S
They
can
onboard
and
prove
all
that,
in
a
matter
of
seconds,
as
opposed
to
24
to
48
hours.
Checking
paperwork
making
phone
calls
faxing
stuff,
so
a
huge
opportunity
there
and
one
that's
rolling
out
at
the
moment
under
the
skin.
It's
the
same
problem
being
solved.
How
do
you
get
verifiable
data
from
a
to
b
and
here
they're,
giving
it
to
the
employees
who
carry
it
and
move
it,
and
it
can
be
verified,
same
approaches
for
iata
where
it's
given
to
a
traveler
and
they
can
carry
a
mover
to
get
it
verified.
R
R
You
know
so
they're
thinking
that
of
this
less
as
placing
a
bet
on
a
tiny
company
like
ebonym
and
more
of
you
know,
investing
in
an
approach
where
actually,
everyone
and
a
constellation
of
other
vendors
will
be
able
to
to
to
bring
to
bear
their
respective
talents
and
solve
this
problem
for
the
whole
enterprise
and
in
many
ways
that's
the
first
time.
This
kind
of
thing
has
been
possible
in
the
old
world.
R
You
would
have
to
just
sign
a
big
contract
with
a
big,
a
big
vendor,
and
you
know
for
projects
of
this
size,
there'd
be
a
very
small.
You
know.
Probably
a
single
digit
length
list
of
vendors
would
be
candidates
and
that's
going
to
be
expensive
and
leave
you
locked
in,
for
probably
at
least
a
decade,
and
so
you
know
by
by
basing
this
on
trust
over
ip
principles
and
the
hyperledger
areas
framework
we've.
R
The
fact
that
not
every
employee
is
a
full-time
employee
adds
the
fact
that
partners
need
access
to
certain
systems
and
the
old,
the
old
way
of
doing
things.
The
idea
that
well
you
just
you
know
what
we
need
is
a
single
source
of
truth
just
build
a
bigger
database
that
reaches
breaking
point
really
quickly
in
these
scenarios,
and
so
we've
seen
this
same
pattern
play
out
with
large
global
technology
service
providers.
R
We
have
as
a
customer
and
also
there's
a
couple
of
other
regulated
entities
outside
of
the
healthcare
space
who
have
the
same
family
of
use,
cases,
I.e,
staff
moving
around
lots
of
locations,
really
strict
regulatory
requirements
about
knowing
who
those
staff
are,
and
this
approach
works
really
really
well
there
in
a
way
that
the
traditional
approaches
might
not.
So
it's
been
really
cool,
but
actually,
since
we've
got
since
we've
got,
I
don't
know,
I
I've
got
probably
another
five
five
or
six
minutes
unable
to
stay
on.
I'm
actually
really
interested.
R
We've
got
26
folks,
still
on
the
call,
I'm
I'm
desperate
to
hear
what
other
people
are
working
on
actually.
So,
if
anyone
feels
like
sharing
some
of
some
of
how
their
projects
are
working
and
where
they've
found
benefits,
and
in
particular,
if
you've
had
experiences
which
are
different
from
ours,
I
would.
I
would
really
love
to
hear
that.
S
R
S
R
Q
Q
Is
the
ability
to
spoof
really
critical
infrastructure
so
being
able
to
allow
an
individual,
particularly
for
phone
numbers
which
can
roam
globally
to
assign
that
as
a
credential
and
as
long
as
the
the
owner,
which
is
the
issuer,
which
is
typically
the
communications
authority
for
the
government
at
the
time?
I'm
not
sure
who
it
is
in
the
uk,
but
it's
the
ac
main
australia.
Q
They
own
the
number
databases,
and
then
they
allow
carriers
to
actually
leverage
that
associated
with
a
plan.
So
it's
really
the
individuals
identity
at
the
end
of
the
day,
so
being
able
to
retain
that
identity
and
move
between
carriers.
As
you
port
numbers,
it
should
be
a
credential,
it
shouldn't
be
sitting
somewhere
else,
so
it
helps
helps
with.
I
guess
identifying
that
you.
G
R
R
Well
super
exciting.
In
my
in
my
past
life,
I
I
worked
at
a
company
that
was
using
the
phone
number
as
a
second
factor
authentication
on
behalf
of
a
number
of
the
large
large
internet
providers,
and
so
we
we
were
involved
in
in
that
very
battle
that
you're
describing
you
know
the
arms
race
against
people,
spoofing
numbers,
porting
them
off
impersonating,
and
things
like
that.
So
I'm
painfully
aware
of
the
challenge.
R
A
Seems
seems
seems
like
everybody's
a
bit
overwhelmed
or
yeah.
I
mean
this
session
was
incredible
and
I
do
wish
that
we
will
have.
We
would
have
more
time,
and
hopefully
we
can
schedule
some
time
to
talk
a
bit
more
about
the
last
last
use
case
you
shared
with
us.
Thank
you
so
much
for
participating
everyone
and
for
a
great
discussion.
A
I
really
appreciate
it
james.
Of
course,
you
know
you
guys
did
an
incredible
job
with
with
presenting
with
facilitating
the
discussion
and
everything
else.
The
sheer
fact
that
we
ran
over
that
much
shows
that
everybody
was
really
excited
and
interested
and
yeah.
The
last
thing
that
I
wanted
to
mention
to
everyone
is
that
we
have
two
coming
sessions
coming
up.
A
One
of
them
is
that
will
be
handled
delivered
by
digital
assets,
again,
the
same
concept
very
interactive,
very
full
of
questions
on
the
utxo
and
account
models,
and
then,
in
on
march,
17th
consensus
will
continue
with
the
ethereum
and
hyperledger
series.
This
time
it
will
be
tech,
demos
and
ama
session
on
hyper
ledger,
basu
and
interactions
between
hyperledger,
community
and
ethereum
community,
and
with
that,
thank
you
so
much
for
participating,
everyone,
safe,
stay
say,
stay
safe
and
I'll
talk
to
you
very
soon.
Thank
you.