►
Description
A virtual meetup hosted by Hyperledger Portugal on May 10, 2023 featuring Alexander Shcherbakov is a Principal Software Engineer and the Decentralized Systems Business Unit Manager at DSR Corporation. Alexander is one of the core maintainers, contributors and authors of such projects as Hyperledger Indy, Hyperledger Aries and Hyperledger Ursa.
Innovations in Digital Identity: Self-sovereign Identity and Blockchain Identity is a fundamental concept present in all of our lives. It defines us and distinguishes us from others. As we have moved into a digital world, digital identity is becoming an increasingly important issue. Self-Sovereign Identity (SSI) provides the means for individuals or organizations to be sole owners of their digital identities. Thanks to SSI, we can control over how our personal data is used and shared.
At the same time, the emerging world of digital identities for devices, applications, etc. also requires new means of handling and controlling what data is exposed to various parties involved. This presents SSI tech a unique opportunity to impact the market at a different level. DSR is a pioneer of this new approach to digital security.
* What exactly is SSI? Another buzzword or a key emerging Web3 tech?
* How is SSI related to distributed ledger and blockchain technologies.
* Is it too late to jump on the $8.9 billion by 2028 market* bandwagon?
* Real-world use cases and applications.
* SSI stack and frameworks.
Alexander Shcherbakov, DSR’s Decentralized Systems Business Unit Manager, has got you covered.
To learn more about decentralized identity and connect with others in the community developing and using this technology, join the Hyperledger identity Special Interest Group at:
https://wiki.hyperledger.org/display/IWG/
----
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
Discord: https://discord.gg/rVCn4j7UFd
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 #Blockchain
License
Creative Commons Attribution license (reuse allowed)
A
Okay,
why
don't
we
go
ahead
and
get
started
and
if
people
join
us
here
in
a
minute,
we'll
just
bring
them
up
to
speed.
So
thank
you
for
joining.
My
name
is
Dave
Boswell
I'm,
the
senior
director
of
community
architecture.
Here
at
hyperledger
before
we
get
into
Alexander's
presentation,
though
I
did
want
to
share
just
a
couple
of
resources
around
decentralized
identity.
If
you're
really
interested
in
this
topic,
there
are
other
places
where
you
can
go
into
the
community.
A
Just
you're
aware
you
know
this,
hopefully
is
the
start
of
a
conversation.
We
invite
you
to
get
involved
in
the
community.
You
know
after
the
end
of
this
Meetup,
you
know.
That's
not
the
end
of
you
know
the
opportunity
to
talk
to
other
people
in
the
community
about
decentralized
identity.
There
are
a
couple
other
places
that
you
may
want
to
consider,
checking
out
and
again
Alexander
we'll
cover
some
other
ones,
but
he
did
want
to
point
out
a
couple
things
before
we
get
started.
A
Just
so
you're
aware
there
is
a
regular
meeting
of
the
identity
special
interest
group.
That
is
an
open
call
where
you
can
get
involved.
This
is
a
really
nice
overview
of
everything
going
on
in
the
space.
It's
an
opportunity
to
meet
other
people,
doing
doing
things
with
the
technology.
So,
if
you're
interested
in
what
Alexander
share
is
today,
please
do
consider
joining
the
identity.
A
Special
interest
group
and
I
dropped
a
link
to
that
in
the
zoom
chat
and
then,
if
you're
interested
in
some
more
of
the
technical
details
about
what
will
be
covered
today,
we
do
have
a
technical
Workshop
coming
up
at
the
end
of
May,
that's
going
to
be
talking
about
using
the
hyperledger
non-cards
project
to
issue
verifiable
credentials.
That's
an
open
Workshop
if
you're,
really
interested
in
the
the
nuts
and
bolts
and
the
technical
details
of
the
some
of
this
technology
that
we're
going
to
cover
today
feel
free
to
take
a
look
at
that
Workshop.
A
So
again,
we
hope
that
this
is
the
beginning
of
a
conversation
that
we
will
have
with
you
on
on
the
topic
of
decentralized
identity.
So
thank
you
for
joining
and
with
that,
let
me
hand
it
over
to
Alexander
sherbakov.
He
is
the
principal
software
engineer
at
DSA.
Dsr
Corporation
has
a
lot
of
experience
with
the
technology,
a
lot
of
experience
and
hyperledger
around
the
different
decentralized
identity.
Technologies
such
as
hyperledger
Indy,
hyperledger,
Aries
Etc,
so
I'm
excited
to
hear
what
he
has
to
share
with
us
today
and
with
that
Alexander.
C
B
Okay,
can
you
see
it
yes,
okay,
perfect?
So
thank
you
all
for
coming
today,
I'm
going
to
just
cast
what
I'm
going
to
discuss
today
as
a
topic
of
decentralized
identity
or
salesforient
identity.
It's
about
kind
of
summarizing
the
years
of
development
in
this
technology,
and
also
one
of
the
interesting
things,
is
how
the
centralized
identities
related
to
the
blockchain,
because
it's
quite
interesting
relationship
before
we
start
just
a
couple
of
words
about
us,
I'm
working
DSR
corporation.
These
are
it's.
B
The
main
headquarter
is
in
Denver
Colorado,
and
this
R
has
been
serving
the
companies
for
more
than
25
years
since
1998
last
year,
these
are
joined.
The
hyper
Ledger
Foundation
has
about
11
technical
departments
like
Wireless,
embedded
web
mobile
computer
vision,
artificial
intelligence
and
one
of
the
important
department
is
a
blockchain
and
the
centralized
identity.
B
One
so
I
left
already
introduced
introduced
me
so
I've
been
working
with
the
centralized
identity
and
blockchain
Technologies
for
more
than
seven
years,
and
during
this
years,
I
had
an
opportunity
to
work
and
contribute
to
such
important
hyper
larger
projects,
test,
hypervisor,
injury,
arrest,
ersta
and
my
main
goal
today
is
to
share
my
experience
and
hopefully
describe
what
self-suring
or
the
centralized
identity
is.
What
are
the
key
Technologies?
What
is
the
stack?
B
B
B
So
we
also
have
an
identity
in
a
real
world
like
we
have
and
I
see
documents
we
have
ourselves.
We
have
some
physical
stuff
representing
us,
but
nowadays
more
and
more
processes
go
to
internet
and
we
are
now
more
online
than
offline.
Moreover,
we
have
the
whole
internet
of
things,
so
it's
not
only
about
identity
of
persons.
It's
about
identity
of
things,
devices
by
identity.
B
The
first
traditional
centralized
model
is
when
we
have
a
centralized
organization
which
manages
our
identity.
The
data
associated
with
us,
usually
most
common
way
to
authenticate
and
authorize,
is
use
some
logins
and
passwords
and,
of
course,
it's
usually
a
mess
because
we
have
to
remember
so
many
passwords,
so
many
logins
and
we
don't
have
almost
no
control
about
our
representation
of
us
within
these
organizations.
B
So
it's
far
from
being
perfect
in
terms
of
privacy
in
terms
of
ux
and
so
on.
The
second
model
second
model
is
leveraging
some
identity
providers.
You
can
call
it
a
Federated
identity,
an
example
when
we
have
a
provider-
and
we
have
a
way
to
sign
in
with
the
same
credentials,
to
multiple
places
usually
based
on
allows
open
energy
connect
Technologies.
B
This
is
probably
better
from
the
X
point
of
view
for
the
end
users,
since
we
may
not
need
to
remember
so
many
passwords,
but
still
in
terms
of
the
privacy
and
control
of
our
data.
It's
still
not
perfect,
still
not
perfect,
because
lots
of
information
about
us,
it's
not
controlled
by
us,
it's
stored
somewhere
on
some
services
and
what
is
unique
about
the
third
approach.
We
can
call
it
decentralized,
Identity
or
storage
identity.
B
The
core
thing
here
that
it's
the
centralized
it's
usually
peer-to-peer
and
there
is
no
Central
entity
which
has
a
control
about
our
data.
So
two
persons
to
agents
can
communicate
with
each
other
and
they
have
a
full
control
of
how
the
data
is
stored,
set
organized
and
in
order
to
still
have
some
trust
in
verification,
usually
distributed.
Ledgers
and
blockchain
Technologies
can
be
used
as
a
source
of
trust
and
the
core
difference
here
that
distributed
ledgers.
B
B
Another
picture
comparing
the
known
as
the
sky
versus
Tesla
style
World
in
not
necessarily
usually
we
have
multiple
representations
of
us.
So
basically,
on
every
service
memory
website,
we
have
different
representation
which
is
taught
on
this
website
right.
So
it's
not
good
from
ux
from
privacy.
Points
of
view,
in
cell
certain
identity,
we
are
at
the
center
of
communication.
We
control
all
the
data
and
it's
up
to
us
how
we
use
and
share
this
data.
C
B
C
B
Well,
first
of
all,
Let's
discuss
what
is
credential
itself
in
this
context.
Credential
is
a
set
of
one
or
more
claims
about
an
entity
made
by
some
issue,
for
example,
for
a
person
with
claim
can
be
like
was
considered
passport,
an
ID
like
a
name
birth
of
date
address
and
so
on,
and
basically
we
have
credentials
like
physical
documents
in
the
real
world
and
you
should
have
the
same,
but
in
internet
in
online
world,
then
the
next
concept
is
verifiable
potential.
B
B
B
B
The
holder.
It's
a
person
like
some
someone
who
actually
owns
the
claims.
Their
credentials
issue
is
a
organizational
person
who
issues
these
verifiable
credentials
and
there
is
this
sign,
buy
some
keys
and
usually
these
keys
are
associated
with
some
gigs
called
dig1
here.
So
that's
where
we
can
see
how
verifiable
credentials
idea
it
is
a
work
with
each
other.
So
the
issue
has
a
div.
B
The
did
has
some
metadata
and
keys
associated
with
this,
and
this
keys
are
used
to
find
some
Revival
credentials,
and
then
these
three
fiber
credential
is
sent
to
the
holder
and
holder
can
store,
it
can
process
it,
and
usually
the
holder
may
also
have
another
jig.
The
ID
to
this
example
and
the
fiber
credential
can
be
associated
with
this
particular
date
and
the
verifier
the
verifier.
It's
an
entity
who
would
like
to
to
know
something
about
the
holder
and
the
holder
can
present
the
information
from
the
verifiable
credential
to
this
verifier.
B
A
very
far
can
do
necessary
steps
and
check
that
this
information
is
correct,
but
it's
important
that
it's
not
necessarily
the
whole
credential
is
bad.
It
can
be
a
different
presentation.
I
will
talk
a
bit
further.
For
example,
some
principles
of
selective
disclosure
can
be
used
so
that
not
all
the
information
is
bad
or
some
predicates
can
be
used
in
presentation.
For
example,
the
holder
can
prove
that
it's
over
18
years
old
without
disclosing
the
exact
age
and
in
order
to
make
this
all
work.
B
In
order
to
verify
this
presentation,
there
needs
to
be
a
place
to
store
public
keys
and
other
metadata,
and
this
place
is
called
verifiable
Data
registry.
In
many
cases,
in
many
cases,
blockchain
or
distributed
ledgers
play
the
role
of
verifiable
data
registers.
What
is
important
here
that
there
is
no
relation?
There
is
no
link
between
verifier
and
Easter.
B
So
it's
a
process
of
presentation.
The
rephire
doesn't
need
to
communicate
with
the
issuer
in
order
to
check
this
information
about
the
holder.
So
it's
kind
of
peer-to-peer
pairwise
in
these
cases
be
sure
Thoughts
with
holder.
It
is
just
credential.
Then
holder.
Talks
with
the
verifier
presents
a
credential
and
verifiable
data
registry,
as
independent
source
of
trust
is
used
for
verification.
B
B
A
diploma
to
the
folder
and
a
holder
can
go
to
the
hospital
and
present
valid
diploma
or
certificate
that
the
real
doctor,
and
he
can
go
there,
no
error
between
issue
and
verifier
right
because
both
of
them,
just
you,
should
put
some
public
key
to
a
fibulator
registry
such
as
blockchain
and
verifier,
can
just
read
these
keys
from
the
registry
or
for
The
Ledger
from
the
blockchain.
In
this
case.
B
Okay,
now,
let's
discuss
a
couple
of
use
cases
and
applications.
Some
popular
applications,
especially
if
you
start
looking
at
some
demos
or
Pilots,
for
example,
very
popular
use
case-
is
to
prove
that
you're
over
18
years
old.
If
you
need
to
go
to
the
store
and
buy
something,
it's
a
one
of
the
ways
where
predicates
and
selected
disclosure
can
be
useful.
B
B
There's
a
number
of
use
cases
which
can
be
applied
to
multiple
domain
areas.
For
example,
know
your
customer
use
case
it's
when
this
checks
are
done
once
and
some
credential
is
issued,
and
then
the
same
credential
can
be
reused
with
another
verifier
without
a
need
to
redo
this
KSC
checks
again,
passwordless
authentication,
it's
one
of
the
ways
when
you
can
just
kind
of
scan
QR
code
and
use
the
verifiable
credentials,
the
IDS
for
this
process
and
the
provenance
origin
of
data.
B
B
There
can
be
a
credential
proving
that
you
own
this
property
and
again
it's
good
from
the
ux
point
of
view
from
another
customer
point
of
view,
sell
and
transport
part
of
use
cases,
Federal
passage,
especially
popular
use
case
where
the
ticket
can
be
actually
a
verifiable
credential,
and
it's
especially
actual
when
there
are
some
other
checks
which
needs
to
be
done
together
with
this
trail
pass.
For
example,
during
pandemic
time,
usually
vaccination
certificate
approval.
Vaccination
was
needed.
B
Density
Concepts
was
a
nice
way
to
implement
these
principles
and
there
were
a
number
of
real
applications
which
implemented
it.
So
you
have
one
credential
like
a
covet.
Vaccination
and
the
second
credential
is
a
travel
pass
and
it
can
easily
be
verified
to
the
airport,
the
gate
and
you
can
board
Healthcare
yeah
again
during
pandemic
time.
Vaccination,
it's
important
thing,
but
it's
not
only
about
the
vaccination
medical
prescriptions.
B
It's
also
quite
important
information
about
the
person
that
actually
only
the
person
should
handle
should
control,
so
it
makes
perfect
sense
to
use
a
verifiable
credentials
for
this
kind
of
use
cases.
Medical
records
again,
that's
something
belonging
to
the
user
too.
Its
identity
and
the
users
should
be
in
full
control
of
this
record
delivery
of
medicine.
It
can
also
be
used.
B
B
With
this
relationship,
it's
possible
to
do
secure,
chatting
it's
possible
to
integrate
payments
and
maybe
to
have
some
discounts
proving
that,
for
example,
your
employee
particular
company
and
this
company
provides
a
discount
for
their
employees
and
iot
and
Manufacturing
I
already
mentioned
the
device,
the
provenance
origin
delegation
of
access,
authentication
and
authorization
of
devices.
It's
all
also
valid
cases
here.
B
Okay
so
now,
let's
look
at
the
SSI
stack,
so
we're
going
more
details
how
this
will
work.
So
we
just
previously
discussed
two
concepts:
the
centralized
identifiers
and
refiable
credentials,
but
let's
see
how
these
Concepts
work
in
more
detail
details,
a
very
nice
representation
of
this
stack.
We
can
use
a
trust
or
IP
stack
with
four
layers
on
layer
4
on
layer
4.
We
have
the
applications,
ecosystems,
domain
areas
like
healthcare,
Supply
chains,
whatever
and
real
applications
on
layer,
3,
layer
3.
B
We
actually
have
this
Prudential
exchange
examples.
This
is
where
we
have
verifiable
credentials.
It's
where
we
have
Easter,
holder
and
verify,
but
if
you're
creates
issues
signs,
the
Revival
credential
holder,
owns
and
presents
it's
to
verifier
and
on
this
layer
also,
there
can
be
the
exact
mechanisms
and
protocols
how
to
exchange
these
credentials.
What
are
the
steps
in
Insurance?
What
are
the
steps
and
verification?
What
are
the
formats
of
messages
and
so
on?
B
Okay,
but
left
three
here,
these
messages,
these
protocols,
these
credentials
that
transfer
from
ensure
to
holder
and
holder
verify
as
a
magic
way
and
actually
led
to
answer
the
question:
how
exactly?
What
is
this
magic
way
for
this
communication
and,
as
I
mentioned,
one
of
the
core
properties
of
the
centralized
alternate
identity
that
it's
usually
peer-to-peer
and
some
peer-to-peer
communication
conduction
is
established
between
the
entities
between
the
agents.
B
So
you
can
see
in
this
picture
so
usually
between
Easter
and
colder
and
holder
and
verifier.
They
have
to
separate
pairwise
connections
and
all
the
protocols
all
the
messages
they
ascend.
On
top
of
this
connection-
and
this
is
where
actually
the
git
com
did
come
happens,
since
we
have
two
JDS,
for
example,
for
issuer
and
for
holder
can
be
paralyzed.
The
80s
or
some
other
did
methods
and
authenticated
encryption
principles.
B
I
use
to
make
sure
that
the
data
through
this
connection
is
encrypted,
is
authorized
and
is
properly
secured
and
on
layer
one
on
layer,
one.
We
have
public
utilities,
Public
Utilities,
as
I
mentioned
before.
In
order
to
be
able
to
do
verification
of
signatures
and
truths,
we
need
to
have
access
to
public
Keys
shared
by
the
issuers,
for
example,
and
that's
where
we
may
have
these
blockchains
ledgers,
which
may
contain
this
information
like
public
Keys,
the
edgy
documents,
the
animated
data,
so.
B
Okay
and
now,
let's
look
at
every
layer
in
more
details,
so
verifiable
credentials.
So
we
already
discussed
the
main
concept,
and
this
is
a
picture
like
the
most
famous
picture
from
the
w3c
standard
describing
the
workflow
of
refiable
credentials.
We
have
these
three
entities
again
like
e-sure
folder
verify,
is
your
issues,
credential
holder
tours
credentials
and
can
present
and
the
presentation
to
the
verifier,
and
we
have
a
reliable
data
registry
as
a
source
of
trust
which
can
maintain
the
schemas
of
the
credentials
and
can
maintain
the
identifiers
and
Associated
metadata
like
public.
B
This
is
schema.
There
is
an
error
from
Boulder
that
it
can
register
identifiers
that
use
schemas
actually,
especially
in
the
Indie
and
areas
world.
Usually
a
pairwise
or
peer
identifiers
are
used,
so
the
holder
is
not
necessarily
need
to
write
some
data,
for
example,
to
The
Ledger
to
the
blockchain
right,
but
for
issues,
it's
quite
common
that
they
use
verifiable
data
registry
such
as
Ledger
blockchain,
to
put
some.
B
B
Three
of
them
are
based
on
w3c
standard.
This
is
Json
LD,
with
LD
signatures
like
more
or
less
common
standard
signatures,
jsonl
DBS
plus
technicians,
which
supports
their
knowledge
and
Json
plus
GPS.
It
starts
a
part
of
the
standard
and
there's
a
force
type.
The
force
flavor
of
your
fiber
credentials
is
steel
allencraft,
but
in
zero
knowledge
and
predicate
historically
still
uncrates.
The
first
implementation
was
part
of
hyperledger
Indie,
which
is
one
of
the
main
apologies
projects,
and
these
two
standards
were
developing
in
parallel.
B
There
are
goals
to
converge
them
eventually,
but
basically,
even
now,
I
believe
these
four
types,
that
kind
of
established
and
every
type
has
their
own
content
pros
and
depending
on
the
use
case,
depending
on
the
exact
needs
and
requirements,
one
of
these
ways
can
be
chosen
before
we
compare
them
in
more
details,
let's
just
because
the
concept
of
selective
disclosure
and
predicates
right.
So
we
have,
let's
assume
we
have
a
credential.
B
We
have
some
claims,
like
ID
of
the
holder
name
address
date
of
birth,
some
other
metadata,
and
we
need
to
present
something
to
verify
what
selected
disclosure
means
that
we
are
not
forced
to
present
and
disclose
all
the
data.
For
example,
we
can
disclose
only
the
nickname
and
that's
can
be
enough
for
the
verifier,
so
the
goal
here
is
to
disclose
only
the
minimally
minimal
required
information
which
is
needed
to
verify.
For
this
particular
use
case
more
hour,
30
kids.
B
We
can
prove
not
just
some
data,
which
is
some
value,
which
is
in
the
claim
itself.
We
can
prove
some
predicates,
for
example,
that
the
H
is
greater
than
20
years,
like
in
this
example
right
and
it's
even
more
better
in
terms
of
their
privacy
in
terms
of
security
and
sharing
really
the
minimally
minimal
minimally
sufficient
information.
B
Now,
let's
look
at
this
comparison
table,
so
we
have
these
four
flavors
that
we
discussed
Json
ldld
proofs,
Json,
ldbs,
plus
Duty,
and
still
allencraft,
as
I
mentioned
before.
The
first
three
are
based
on
tablets.
We
see
recommended
standard
CL
under
correct.
It's
also
mentioned
there,
but
basically
there
is
now
a
separate,
adding
credit
standard
and
David
mentioned.
There
will
be
an
upcoming
webinar
event
devoted
to
this
new
initiative,
but
historical
synonymocrats,
it's
not
new,
as
I
mentioned
to
the
first
implementation,
was
done
in
hyperlogic
engineer.
B
That
we
just
discussed,
as
you
can
see,
selective
disclosure
is
available
for
BBS
plus
and
for
steel
anocrats,
it's
not
available
for
commodity
or
for
Jason
ldld
proofs.
In
these
four,
these
two
types
you
have
to
disclose
all
the
information
which
can
be
a
problem
for
some
use
cases,
but
can
be
perfectly
fine
or
other
use
cases.
B
Predicates
are
the
only
type
of
credentials
that
support
it
is
still
anocrats.
So
for
other
types.
It's
not
available
this
right
now
again.
If
the
use
case
requires
a
need
for
a
predicate,
then
well
statement,
corrects
it's
a
good
option.
If
it's
not
needed,
which
can
be
also
true
for
Simon's
case-
is
them
yeah.
Other
credentials
may
also
work
by
serialization.
Json
LD
is
used
for
the
first
and
second
flavors,
and
just
a
common
Json
is
used
for
Duty
and
still
having
credits,
our
crypto
signature
for
Json
LD,
it's
well.
B
Basically,
we
can
consider
it
like
a
more
common
digital
signatures
is
an
elliptic
curve
for
cryptography
or
a
currency,
and
for
BBS
plus
it's
well
quite
a
new
standard,
but
very
promising
which
allows
to
use
selective
disclosure
and
their
knowledge
proofs
GPS.
It's
also
quite
common
standard
for
WT
and
for
Jose
family
of
standards
and
for
clan.
Here,
it's
quite
unique.
It's
based
on
zero
knowledge
proofs
and
its
implementation
now
is
available
in
hyperledger
Ursa
as
part
of
hyperledger
Ursa,
and
it's
leveraged
by
many
other
Frameworks.
B
Let's
consider
four
more
columns
criterias
here,
Prudential
schema
Financial
schema,
so
we
discussed
previously
that
credential
is
some
set
of
attributes,
like
name
whatever,
but
what
exact
set
of
attributes,
because
it's
pretty
important
in
the
use
cases
to
understand
what
are
what
is
the
set
of
the
attributes?
What
are
possible
values?
What
are
restrictions
is
important
for
interoperability.
B
It's
important
for
the
verifier
to
understand
what
to
expect
what
data
to
expect
it's
important
to
the
holder,
also
to
know
what
format
of
credential
will
be
and
for
Json
Json
LD.
We
can
say
that
Json
knows
the
context
by
itself.
It
provides
some
means,
some
set
of
attributes,
a
credential
schema
plus
optionally.
A
Json
schema
can
be
used
as
well.
In
addition
to
this,
for
json-based
Json
schema
can
be
used
here
and
for
clients,
but
basically
yeah.
B
For
these
types,
it's
kind
of
the
part
of
serialization
I
would
say,
but
for
a
sale
on
credit,
it's
a
bit
different
since
they're
dedicated
object,
a
schema
object
needs
to
be
created
and
the
skill
object
defines
a
set
of
attributes
for
the
claims
for
the
credentials.
Usually,
usually,
this
schema
is
put
on:
The
Ledger
becomes
public,
for
example,
it
can
be
put
to
hyper
larger
in
the
ladder.
B
The
next
important
criteria
is
how
Easter
shares
the
public
key
right,
because,
as
I
mentioned
in
general,
any
credential
any
client
needs
to
be
signed
can
be
more
or
less
common
standard
cryptography
or
it
can
be
a
more
advanced.
Your
knowledge
proof
based
cryptography,
but
the
main
principle
of
I
need
for
a
private
and
public
key.
It's
usually
for
all
four
types
of
tests
and
is
any
asymmetric
or
use
cases.
There
needs
to
be
a
way
to
share
this
public
key
and
in
a
standard,
WCC
credentials.
B
Usually
it's
assumed
that
the
public
key
is
the
one
associated
with
The
Jig
to
jig.
It's
not
just
identifier,
it's
also
custom
metadata
or
like
the
document
which
may
contain
the
public
key
which
may
contain
the
public
keys
and
in
many
cases
usually
these
did.
Indeed.
Dock
are
put
on
The
Ledger
to
make
it
public
so
that
any
verifier
can
resolve
it
and
resolve
it
from
the
ledgers
and
do
the
necessary
verification
of
switches.
B
It's
also
a
bit
different.
There
is
a
dedicated
object,
which
is
called
credential
definition,
which
contains
a
public
key
for
the
issue
which
is
used
by
the
issue
to
sign
the
credentials,
usually
usually
in
addition
to
credential
definition.
Easier
should
also
have
a
jid
and
the
edit
doc,
which
both
of
these
things
usually
put
on
The
Ledger,
for
example,
upper
Ledger
engine,
a
third
important
criteria.
B
Usually
the
holder,
creates
ADHD.
The
corresponding
keys
can
be
either
pairwise
or
can
be
put
on
some
public
Ledger
and
the
folder
can
prove
the
ownership
of
these
keys
by
some
signature
against
this
JD
in
the
presentation.
So,
for
example,
when
the
holder
presents
a
presents
a
claim
to
the
verifier,
there
needs
to
be
two
signatures.
The
first
signature
from
the
issue
and
the
second
signature
is
from
the
folder,
proven
that
the
holder
really
owns
the
key
associated
with
this
very
fabric.
Credential.
B
Okay
and
for
CL
undergrads
again,
it's
a
bit
different
there,
the
con
the
circle,
the
concept
of
so-called
linked
Secrets
is
used
used,
and
this
secret,
it's
just
one
key
which
is
used
during
the
insurance
process,
and
it
links
every
particular
credentials
to
this
particular
holder.
So
only
the
person
who
knows
a
Link
Secret
can
create
a
proof,
can
create
a
presentation
for
the
verifier
and
also
it's
important
that
it
can
create
combined
multiple
credentials
from
even
different
issuers.
B
It
can
all
link
them
all
to
a
particular
holder
so
that
multiple
credentials
from
different
issuers
can
be
used
in
the
same
presentation
in
the
same
truth
and
the
last
criteria,
it's
the
river
case,
it's
rare
case
in
many
use
cases
their
credential
itself.
It
should
not
be
issued
like
forever.
There
should
be
a
way
to
revoke
it.
For
example,
a
driver
license
is
a
good
example
that,
in
case
of
some
issues,
can
be
revoked
by
the
way.
B
In
some
credentials,
relocation
can
be
achieved
just
by
having
the
corresponding
fields
in
the
credential
itself,
like
a
timestamp,
so,
for
example,
after
this
timestamp,
the
credential
is
not
valid
anymore,
but
in
many
cases
a
real,
more
advanced
irrigation
which
is
initiated
by
the
issue
of
the
credential
needs
to
be
present
and
for
the
first
three
types
of
credentials.
Usually
the
status
list
standard
is
used
orientation
or
for
your
occasion
it's
not
anonymized.
B
Basically,
basically,
it's
kind
of
a
list
of
indices
of
credentials
that
revoked
and
the
verifier
can
check
it
and
make
sure
that
credential
is
not
revoked
for
sale
and
credits.
The
anonymous
approach
is
used.
It's
based
on
some
quite
Advanced
cryptography
or
zero
knowledge,
proofs
and
accumulators
and
yeah
it's
well.
It
has
some
constant
Pros.
For
example,
it's
supports
Anonymous
relocation
as
I
mentioned,
but
it's
quite
heavy
quite
heavy
process.
B
We
know
how
it's
kind
of
signed,
but
properties
are
there,
but
how
exactly
the
issuer
can
give
this
credential
to
the
holder?
How
exactly
the
holder
can
give
this
Prudential
presentation
to
verify?
This
is
very
important
for
interpretability
to
define
the
standard
so
that
the
holder
can
work
with
multiple
issuers
with
multiple
verifiers,
multiple
implementations
from
multiple
vendors,
so
interpretability
is
pretty
important.
Yeah
and
hyperledger
areas
is
the
first,
the
first
set
of
protocols.
D
B
B
B
B
B
Of
course,
it
can
be
extended
to
have
like
three
parties
participate
in
the
same
channel,
but
in
most
of
the
cases
it's
usually
just
and
once
this
fears
are
exchanged,
Alice
knows
the
GID
and
the
key,
which
should
be
used
to
send
messages
to
Bob
and
Bob,
knows
the
gads
and
keys
to
be
used
to
send
messages
to
Alice,
and
they
can
establish
a
secure
connection
and
start
exchanging
some
messages
during
this
channel
during
this
channel.
So
basically
they're
doing
authenticated
encryption,
so
it's
encrypted
only
by
Bob.
B
Well,
in
this
case
it's
just
gay,
but
in
our
use
cases
by
protocols
it
can
be
the
protocols
for
insurance
and
verification
of
credentials.
For
example,
if
it
is
a
issuer
and
Bob
is
a
holder,
then
Alice
can
send
messages
for
the
issuance
protocol
like
proposing
a
credential
Bob
can
confirm
accepting
this
credential.
Then
the
address
can
send
the
credential
itself
and
so
on.
There
is
some
State
machine,
basically,
which
is
defined
as
part
of
this
protocol.
B
What
is
important
here
that
it's
not
just
identifier
like
uuid,
it's
also
a
set
of
metadata.
We
call
it
deity
document
which
can
contain,
for
example,
servicing
points
which
can
contain
some
keys
for
different
purposes,
and
this
is
the
names.
This
is
the
examples
of
this
property.
For
example,
we
can
Define
the
keys
to
be
used
for
secure
connection
for
key
agreement.
B
B
B
So
just
to
summarize
again
where
exactly
there
disappear
in
our
use.
Cases
for
the
issuer
for
the
issue
usually
Easter
has
a
dad
and
corresponding
D
document
containing
the
public
key
and
the
corresponding
signing
key
private
key
is
used
to
sign
the
refiable
credence
indeed
did
dog
publicly,
usually
they're
public
and
put
all
some
Ledger
was
a
holder
for
the
holder.
B
The
holders
dad
can
be
used
as
part
of
refiable
credentials
so
that
these
three
fiber
credentials
is
associated
with
its
holders.
Business
holder's
entity
and
the
proof
of
ownership
of
this
did
can
be
created
by
signing
using
the
case
point
in
private
care
of
this
dag
all
some
nouns.
So
it
usually
is
done
during
the
presentation
during
the
presentation
holder
can
prove
to
the
verifier
that
the
ruler
or
the
holder
really
owns.
The
did.
Benson
is
a
refiable
credential
subject
right,
so
credential
is
issued
for
a
particular
holders.
B
This
Yeti
can
be
public
in
some
use
cases,
so
it
can
be
put
on
the
blockchain.
In
some
cases,
it's
okay,
it's
sufficient
to
use
just
a
private
Jad,
like
pairwise
fear
key
dead,
so
there
is
no
need
to
put
it
on
the
ledge
and
JD
methods.
Just
a
couple
of
examples,
actually
the
full
list,
not
the
full
list,
but
this
boss
of
these
message
that
can
be
found
here
in
this
specification
and
there
are
more
than
100
different
methods,
for
example
digital
the
dingy.
B
They
they
describe
how
the
ideas
can
be
created
on
top
of
hyper
legendary
story,
networks
detect
for
checked
Network.
It's
also
a
ledger
for
identity
use
cases
here
in
this
entities.
Usually
they
did
dock
this
Keys
metadata,
it's
kind
of
encoded
into
the
did
identifier
string
itself
so
for
this
key.
Basically,
there
is
no
need
to
have
a
dedicated
place
to
store
the
dock,
because
once
you
have
edit
key,
you
can
decode
it
and
you
get
the
whole
detox.
You
can
get
the
whole
public
keys.
B
Okay,
so
as
a
sign
blockchain
again
just
to
make
it
clear,
but
how
these
concepts
are
related
to
each
other.
So
what
is
the
more
important
blockchain
is
basically
optional
in
many
SSI
cases.
You
can
see
that
in
this
trust
or
IP
technology
stack,
blockchain
appears
only
on
layer
1
only
on
layer
1
on
public
utilities.
B
It's
also
quite
common
to
use
a
ledger
as
a
source
of
trust
for
revocation,
for
example,
hyperledger
injures
number
of
transactions
for
this
purposes,
but
maybe
stored
on
the
blockchain
optionally
holders
did
the
dog
public
keys.
They
can
be
stored
on
the
blockchain,
but
it's
not
mandatory.
In
many
cases,
just
a
pairwise
gag
is
enough,
and
finally,
what
is
never
never
stored
on
the
blockchain.
It's
of
course
private
Keys,
link,
secrets
and
verifiable
credentials,
verifiable
credentials.
The
verifiable
credential
is
never
stored
on
the
blockchain.
B
It's
stored,
usually
in
the
user's
wallet
like
Edge
wallet,
mobile
phone,
or
maybe
some
Cloud
wallets
properly
encrypted,
but
it's
never
stored
on
the
blockchain
since
we're
a
fiber
credential
the
whole
concept
of
cell
soil
identity,
the
centralized
identity
that
it
should
be
owned
by
the
holder.
Only
so
it's
stored.
Only
in
the
place
where
holder
has
access
to
it
should
not
be
public.
It
should
not
be
public.
B
B
B
Permission
Ledger
but
checked
it's
a
public
permissionless
Ledger
based
on
proof
of
stake
with
some
crypto
tokens
involved.
It's
based,
Cosmos
SDK
and
basically
checked
supports.
For
example,
sale,
auto
credits
supports
double
SDC
credentials,
so
all
the
main
use
cases
and
credential
flavors
are
supported
by
this
Ledger.
B
Then
the
next
examples
are
like
lab
two
ledgers,
for
example,
ion
side
tree
protocol
a
type
of
Bitcoin.
There
are
also
versions
setup
of
ethereum
network.
This
is
one
of
the
concepts
there
that
in
many
cases
in
SSI
we
don't
need
like
a
full
ordering
of
everything,
but
it's
sufficient
just
to
have
the
order
within
the
domain
of
particular
jig
particular
user
right.
The
order
of
how
the
keys,
for
example,
are
rotated
there
and
yeah.
B
B
And
S4
SSI
Frameworks
itself,
which
Implement
all
the
built-in
blocks
or
the
centralized
identity.
So
it's
not
only
The
Ledger,
it's
also
the
corresponding
cryptography,
API
wallets
protocols
and
so
on.
Apologic
NG
was
historically
one
of
the
first
implementation
it
was.
It
became
part
of
hyperledger
in
2017
and
later
on,
in
2019's,
hyperledger
areas
are
cleared
and
last
year
a
new
grad
initiative.
Anong
grass
was
outstalk
established,
happy
pleasure,
Indy,
it's
a
graduated
project,
but
it's
important.
It
consists
of
two
main
parts.
B
B
Sorry,
it
was
historically
the
first
deployment
of
in
The,
Ledger
and
well
in
the
SDK.
It's
quite
monolithic
library
that
contains
the
the
code
for
communication,
with
a
ledger
code
for
refiable
credentials,
the
wallet
and
so
on,
and
now
a
new
generation
of
SDK
of
sdks
have
been
created.
For
example,
individr
is
just
focus
on
communication
with
the
India
Ledger
RSS
car.
It's
a
new
wallet
which
is
being
adapted
by
many
areas.
Framework
industry
address
it's
or
unclass
arrest.
It's
a
also.
B
B
Then
hyperledger
areas,
it's
as
I
mentioned
it's
a
graduated
project
as
well,
and
it
was
created
in
2019.
What
is
the
core
think
in
areas?
It's
actually
the
specifications,
the
rfcs
the
set
of
interoperable
protocols
Concepts,
and
there
is
a
number
of
implementations
of
these
specifications
in
various
programming
languages,
for
example,
echapai
RS,
Cloud,
python,
Harris
framework
goal
areas.
Framework
javascript.net
rsvcx,
is
the
rust
implementation.
Also,
we
have
Frameworks
for
creation
of
mobile
applications.
Mobile
wallets
such
as
areas
bifold
as
mobile,
Legend
react
native.
B
B
So
we
can
see
that
this
kind
of
picture
from
monolithic
energy
to
areas
and
to
end
credits-
it's
been
developed
being
adapted
right
now
and
I
believe
the
community
has
a
pretty
good
progress
here
and
almond
Kratz.
It's
a
ledger:
agnostic
specification,
incubation,
hybridledger
project
created
last
year,
uncreased
arrest,
it's
a
rust
implementation
with
wrappers
for
popular
efforts,
and
there
is
some
growing
effort
to
migrate
areas.
Many
areas,
implementation
to
this
new
sale
Democrats
instead
of
things.
D
D
B
Yeah
yeah,
so,
as
I
mentioned,
unicrest
historically
was
part
of
hyperledger
Indie
and
the
corresponding
cryptography
is
implemented
in
hyper
Ledger
Ursa,
which
is
said,
Library,
Geographic,
Library,
hyperledger
and
historically.
This
implementation
was
coupled
with
the
ninja
Ledger
and
in
the
project,
which
is
good
on
one
hand,
since
it
provides
the
full
set
of
SDK
tools
for
creation
of
the
centralized
identity.
B
Ssi
based
applications,
so
all
necessary
tools
are
there,
but
on
the
other
hand,
of
course,
in
terms
of
better
interpretability,
better
adaption,
it's
good
to
support
different
ledgers.
It's
good
to
support
different
methods
and
one
of
the
goals
for
this
initiative
is
to
make
it
Ledger
agnostic.
Another
goal.
B
As
you've
seen,
there
are
kind
of
two
generations
of
Revival
credentials,
the
CL
on
credits,
one
which
was
originated
as
part
of
hyperluster
in
the
areas
and
ws3c
credentials,
and
of
course
it
will
be
great
to
converge
them
eventually,
so
that
they
are
better
interoperable
with
each
other
and
can
work
together.
So
this
is
also
a
goal
and
to
make
sure
that
it's
better
addresses
the
current
needs,
standards
and
convergences.
D
Okay,
thank
you
Alexandra
one
more
question
from
Benjamin
this
time.
How
can
an
issue
verify
about
the
physician's
diploma
submitted
online?
It's
not
counterfeit.
In
other
words,
how
can
the
DD
issue
verify
if
you're
submitting
for
certificate,
for
example,
a
passport
photo
faked
in
Photoshop
on
the
first
submission.
B
Yes,
yes,
what
is
also
important
in
this
poor
layers?
This
stack
is
kind
of
the
governance
procedure
and
the
ways
how
to
establish
this
trust,
so
in
particular,
for
example,
let's
assume
we
have
an
issue
right
and
the
issuer
can
put
the
ID
to
be
used
for
Insurance
to
a
ledger
and
it's
a
similar
needs
to
be
a
prestigious
and
Trust
to
know
that
this
particular
did
belongs
to
this
particular
issuer
and
can
be
trusted.
B
There
are
some
standards,
for
example,
well-known
gag,
which
helps
to
associate,
for
example,
a
domain
with
a
particular
deity.
So,
for
example,
there
can
be
activity
object,
assuming
that
this
domain,
like
example.com
associated
with
this
particular
gig,
which
can
be
used
to
issue
a
fiber
credentials.
D
C
A
Is
let
me
get
a
couple
links
thanks
here.
There's
an
in
there's
a
Wiki
for
Indy,
just
like
all
the
hyperledger
projects
have
a
Wiki
page
with
links
to
different
relevant
resources.
That
may
be
what
you're
looking
for,
if
not
just
Brad
ping
me
and
zoom
chat
and
I'm
happy
to
share
some
other
links
as
well.
D
Thank
you
David
and
thank
you
Brett
for
your
question,
one
more
one,
more
question
from
Suresh:
what
are
the
possible
to
access
the
slides
of
the
decision
of
the
session?
Please
yeah
sure
we'll
share
the
slides,
Jim
Dorsey,
where
the
public
Keys
stored
in
the
Aries
Mobile
Wallet.
Where
would
I
find
them.
B
It
depends
on
the
type
of
the
refiable
credentials,
but
let's
assume
we
use
the
still
uncrats
in
the
types
of
credentials
and
there
basically
exit
tier
methods,
I
used
to
establish
their
connection
right,
so
the
corresponding
public
Keys
doesn't
need
to
be
stored
somewhere
on
the
blockchain.
They
just
toured
locally
kind
of
in
the
wallet
and
exchanged
during
the
connection
establishment
process
right
so
for
the
holder
for
sale
and
credits,
there
is
no
need
to
store
anything
on
the
Block
sheet.
B
E
B
Okay,
you're
talking
about
the
issue
issue
side.
Okay,
for
the
issuer.
For
the
issuers,
the
keys
are
stored
on
The
Ledger
on
The
Ledger.
If
you're
talking
about
the
one
network,
probably
about
clients
and
hyperledger.
Indeed,
then
there
is
a
dedicated
transaction,
which
is
called
credential
definition
credf,
that
it
contains
the
public
key
or
the
issue
which
is
used
to
sign
recognitions.
B
Okay,
there's
another
transaction
in
hyperlogic
index,
it's
called
neem,
which
can
be
used
to
store
the
keys
associated
with
the
did
is
associated
with
the
gig.
We
just
needed
in
order
to
send
natural
definition
actually
so
using
the
process.
The
following
for
the
easier
easier
first
of
all,
creates
a
schema.
Sorry,
first
of
all,
it
creates
a
dag
and
the
corresponding
public
keys,
put
it
on
The
Ledger
on
engine
Ledger.
B
F
Hello
and
thank
you
for
your
presentation,
so
I
asked
the
question
in
the
chat,
but
I
will
repeat
it:
it's
I
haven't
learned
stack
project
and
I
want
to
implement
the
acapai
instance
and
I,
don't
know
how
to
run
it,
how
to
run
it
locally
on
my
machine.
So
if
you
have
an
idea
or
recommended
tutorial
to
follow.
B
Well,
I
believe
you
could
just
look
at
the
echo
bar
repository.
It
contains
a
number
of
pretty
good
tutorials
how
to
do
it.
Also
Echo
Parts,
one
of
the
that's
one
of
the
key
areas
projects
it's
part
of
the
basic
SSI
against
tutorial
provided
by
hyperledger.
So
if
you
go
through
these
steps,
like
I
think
it's
called
how
to
become
a
system
developer
stuff
like
this.
F
And
they
followed
this
I
followed
it's
it's
a
it's
a
course
on
Linux
Foundation
I
followed
it,
but
but
it
doesn't
have
like
a
step-by-step
or
like
clear
information
on
how
to
run
it
locally
on
your
machine.
So
I've
been
running
it
since
yesterday
and
I
followed
the
official
documentation
on
hybridledger
and
GitHub,
but
I
actually
always
find
problems
so
I
don't
know
what
to
do.
C
B
My
condition
would
be,
of
course,
to
look
at
the
repository,
because
I
know
that
there's
some
Docker
images
that
basically
you
can
just
run
right.
So
usually
there
is
no
need
to
just
build
everything
by
itself.
Also,
there
is
like
a
pipey
version.
This
is
written
in
Python
that
you
can
also
run
so
look
for
the
repository,
and
also
there
is
a
channel
in
Discord
for
echapai.
You
can
I
think
you
could
reach
the
community
check
at
the
community
and
ask
questions
there.
If
you
faced
any
issues
of
the
nuclear
points.
D
B
Actually,
hyperledger
didn't
come
up
with
a
separate
tag.
Historically,
historically
still
uncrats
was
implemented
before
before
w3c
standard
was
Major
enough.
So
it's
a
kind
of
was
in
parallel
process.
Historical
process
and
theorem
creates,
as
I
mentioned,
it's
the
part
of
hyperlogic
Industry
since
2017.,
but
w3c
became
a
recommended
standard
only
like
in
20
21.,
so
22.
Actually,
so
there
was
two
separate
processes
coming
in
parallel,
but
yeah.
That's
why
I
need
technology?
Usually
it's
not
that
straightforward.
B
There
is
a
number
of
branches
and
like
in
any
tree
there
can
be
multiple
branches
which
you
can
leave
together
and
it
can
be
perfectly
fine
and
also
as
I
mentioned,
there
are
some
constant
Pros
in
area.
This
approaches.
They're
increases,
probably
the
only
choice
if
you
would
like
to
have
predicates,
but
in
some
cases
more
simple
cases,
maybe
usage
of
WCC
credentials
is
also
fine
and
by
the
way
many
areas
protocols
support
both
types.
Now
they
both
they
support
both
ws50
and.
B
No,
it's
not.
The
only
Advantage
predicate
is
one
also
revocation,
it's
a
bit
more
secure
in
terms
of
privacy.
It's
anonymous,
then
selective
disclosure
before
BBS
plus
signatures
will
create
it.
It
was
quite
significant
difference
between
a
common
Json,
LG
or
dvt-based
credentials,
tension
credits
now
with
BBs
plus,
of
course,
yeah.
It's
not
the
difference
anymore,
but
well.
If
you
need
both
selective
disclosure
and
pedicated
can
be
very
nice
option.
D
B
Hyperledger
in
the
W
Theory
fiber
credentials
is
that
it's
part
of
the
standards,
interoperable
standards,
which
is
really
good
for
adaption
of
the
solution,
which
is
really
good
to
be
able
to
use
a
solution
with
multiple
vendors,
for
example,
one
party
May
implement
the
issue
or
another
party,
you
implement
verifiers
advice,
you
may
Implement
the
wallet
and
they
can
all
work
with
each
other
since
they
support
the
same
standards.
So
it's
pretty
important
about
the
standards.
B
Yeah
so
one
of
the
goals
of
new
CL
and
credits
initiative
to
make
it
Ledger
agnostic
and
basically
yes,
there
is
kind
of
an
interface
in
allencrest
interface
of
this
data
registry,
like
with
a
message
like
write,
read
and
so
on,
and
there
can
be
multiple
implementations
of
this
interface.
Hyperledger
NG
is
one
of
the
implementations
checked.
Ledger
is
another,
so
basically
now
on
prevents
to
create
implementation
based
on
polygon
right.
B
So
now,
with
this
initiative,
it
should
be
quite
straightforward
to
do
it
I'm
not
sure
that
there
are
any
existing
working
implementations
at
least
of
part
of
hyper
Ledger,
maybe
somewhere
in
polygon,
it
is
but
yeah,
basically
technically
I
believe
it
can
be
supported.
There
is
no
reason
why
not
and
that's
one
of
the
goals
of
this
data
and
credits
initiative
is
to
make
it
larger.
D
B
B
Also,
you
just
saw
the
holder
side,
they
are
not
stored
on
some
third-party
entity
and
every
relationship
between
the
older
and
verifier.
It
can
be
done
directly
in
peer-to-peer
fashion,
which
is
better
in
terms
of
privacy.
Preserving
the
issue
part
doesn't
need
to
be
involved,
like
identity
provider
who
issues
the
credentials.
It
doesn't
need
to
be
involved
there,
which
is
of
course
much
better.
Also,
it
allows
opens
the
way,
for
example,
for
passwordless
authentication
ways
for
like
delegation
and
so
on.
B
D
B
Yes,
yes,
yes,
basically
one
of
the
advantages
of
using
as
a
ledger.
Since
we
are
talking
about
decentralized
identity
right,
then
it's
good
idea
to
get
rid
of
any
points
of
centralization
somewhere.
Otherwise
the
whole
concept
can
be
broken
and
the
distributed
ledgers.
The
centralized
it's
one
of
the
decentralized
ways
to
establish
Trust
right,
because
the
public
key
needs
to
be
trusted.
So,
of
course,
it
can
be
stored
in
some
Central
Ledger
if
there
is
a
full
trust
to
the
central
entity.
B
But
if
there
is
no
such
trust,
then
the
centralized
Ledger
can
be
a
very
good
option.
So,
for
example,
even
this
case
is,
for
example,
for
example,
if
the
Easter
will
store
its
keys
on
its
own
company
website.
What
will
happen
if
this
issue
company
organization
is
set
down?
Miss,
not
available
anymore
right?
It
will
mean
that
all
issued
credentials
won't
be
working
because
there
will
be
no
way
to
verify
them.
The
public
key
this
website
or
the
issue
won't
be
available.
B
But
if
you
use
the
ledgers,
the
decentralized
ledgers,
it
provides
a
much
better
guarantee
that
the
service
will
be
available
and
any
blockchain.
Even
if
a
couple
of
notes
are
down
or
malicious,
the
whole
service
will
still
be
functional
and
all
the
issued
verifiable
credentials
can
be
used,
even
if
the
issue
is
unavailable
or
not
in
service
anymore
or
just
get
out
of
business.
So
it's
a
very
nice
thing
to
really
own
the
identity,
independent
of
some
centralized
fighting.
D
D
A
A
Just
gonna
say
thank
you
and
thank
you
to
Alexander
as
well,
and
thank
you
to
everyone
who
joined
yeah
if,
as
Antonio
was
saying,
if
you
have
other
questions,
you
know
again,
please
feel
free
to
reach
out.
You
know.
Hopefully
this
is
the
beginning
of
an
ongoing
discussion
and
we're
looking
forward
to
talking
with
you
more.