►
Description
Building Self-sovereign Identity in South Africa - Jakub Kočí & Patrik Staš, Absa
Absa, together with other banks and financial institutions within SAFBC (South Africa Financial Blockchain Consortium), is building a self-sovereign identity solution for people in South Africa. Our first goal is to reduce the costs of a repeating KYC process. We want to provide users an identity wallet as a mobile app, which they can use for verifying their identity. Then we will issue them a digital identity credential, which they can re-use for communication with Absa or other companies.
Our solution is built with Hyperledger Indy/Aries and we would love to share what we've done so far and what was our experience with these technologies. What went well, what wasn't so good and also what we're planning for the future.
----
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 #HyperledgerGlobalForum2020 #Blockchain
A
I
do
some
open
source
stuff
and
currently
I
work
for
I
work
for
APSA
and
upsize
Bank
in
South,
Africa
upsize,
also
Stewart
in
sovereign
network,
which
means
that
we
are
running
the
node
in
in
a
blockchain
network
and
that
blockchain
network
is
an
instance
of
hyper
hyper
ledger
in
the
in
the
episodes
project.
So
it's
kind
of
the
reason
why
we
are
here
in
I.
A
Browser
I
brought
your
conference,
so
there
are
16
million
people
in
South
Africa
and
there
is
a
question
how
to
deliver
Sauser
and
edit
that
the
solution
to
all
of
them
and
to
be
honest,
I,
don't
know
answer
at
least
not
now
or
not
yet,
but
I
think
we
can
at
least
start
somewhere
start
at
smaller
scale
and
try
it.
What
does
work
and
what
doesn't
and
move
to
higher
scale
after
and
so
where
to
start
I
think
we
can
start
in
existing
processes
and
with
existing
technology.
A
So
banks
are
all
already
reliable
for
verifying
customers
identity,
so
they
need
to
know
who
their
customers
are
and
what's
their
identity.
This
process
is
called
know
your
customer,
our
kyc,
and
in
the
past
you
have
to
go
like
physically
into
the
branch
and
get
to
the
bank
get
get
them
give
them
your
documents,
ID
card
and
other
other
documents
for
like
verification
of
your
identity.
Nowadays,
banks
and
financial
institutions
are
going
to
the
digital
form
of
this
kyc
process.
A
Where
you
just
upload
your
documents
take
a
selfie
and
upload
to
upload
it
to
the
server
and
then
then
the
process
is
done
so
how
the
saucer
and
identity
fits
in
here.
The
basic
idea
is
of
salsa
variant
is
to
convert
physical
paper
based
document
into
the
digital
form
and
put
the
digital
signature
on
it.
These
documents
are
called
verifiable
credentials
and
instead
of
putting
them
into
our
physical
wallet,
we
put
them
into
our
software
wallet,
which
could
run
in
mobile
phone,
for
example,.
A
A
What's
also
important
is
to
have
some
interoperability
and
portability
in
the
solutions,
because
this
topic
is
highly
related
to
collaboration
and
I
will
explain
it
more
in
a
minute
in
a
few
minutes,
and
as
I
mentioned,
that
we
need
to
take
existing
process,
that's
exactly
what
we
are
trying
to
solve
and
we
are
building
mobile
application
and
we
would
like
to
provide
the
customer
or
user
of
the
app
like
possibility
to
go
to
this
kyc
process
in
digital
form.
And
actually
there
are
two
workflows.
A
So
if,
if
something
fails,
we
the
user
just
can
upload
documents
and
then
go
to
the
branch
or
face
to
face
recognition,
but
we
hope
it
won't
be
so
much
use
case.
So
we
hope
it
will
be
in
the
digital
I
as
as
much
as
possible,
and
this
is
about
digital
identity.
Credential.
It's
good
enough
for
out
of
products
which
banks
which
the
bank
offers,
but
for
some
products
the
user
needs
to
have
also
proof
of
residence
or
proof
of
its
address.
A
A
So,
as
I
mentioned
the
importance
of
collaboration,
we
are
not
alone
in
this
effort.
There
is
South
Africa
financial
exchange
consortium,
which
is
consortium
of
banks
and
other
financial
companies,
and
they
are
collaborating
together
on
different,
like
use
cases
or
usages
of
a
blockchain
for
financial
services,
and
one
of
the
use
case
is
is
the
use
case
for
sale
of
stolen
items
they
or
digital
identity.
A
So
there
is
a
term
trust
over
IP,
and
so
so
so
you
can,
you
can
see
on
the
right.
We
have
some
D
IDs
and
verifiable
credentials,
but
these
are
related
to
technology.
So
we
have
technology
for
for
the
trust,
but
we
still
need
something
from
the
real
world
which
call
which
which,
which
is
like
related
to
link
legal
stuff
around,
and
it's
called
like
that
governance
frameworks
or
governance
take
so
for
us,
the
governance
tech
is
the
governance.
Stick
around
the
blockchain
is
sovereign
right
now,
but
used
to.
A
We
still
need
to
define
like
what's
the
trust
about
process
of
the
issuance
of
the
digital
credential.
So
we
are
doing
something
with
our
ad,
but
we
need
we
need.
We
need
it
to
be
like
defined
by
our
course
consortium.
So
this
is
about
what
should
be
the
credential
definition.
Current
schema
for
digital
identity.
What's
the
correct
process,
so
should
we
check
a
phone
number
or
or
another
another
like
email
or
another,
another
verification,
and
what's
like,
what's
good
enough
for
for
this
process
to
be
trusted
by
other
other
parties?
A
And
what
I
didn't
mention
is
that
the
idea
is
to
reuse
this
credential
within
other
banks.
So
if
the
user
goes
through
this
process
with
APSA
with
our
app,
then
he
can
go
to
the
different
bank
and
use
this
digital
credential,
and
he
doesn't
have
to
go
to
this
kyc
process
again.
So
that's
the
like
first
step,
how
to
how
to
use
it
and
how
to
reuse
this
digital
ID
and
the
current
show.
A
So
that's
about
it
kyc,
but
we
don't
want
to
stop
there
and
you
would
like
to
provide
our
users
more
features
and
other
like
two
areas
of
use.
Cases
we
are
currently
discussing
is
what
one
is
the
outer
indication.
So
we
would
like
to
provide
digital
identity
credential
to
to
authenticate
users
in
a
branch
or
in
the
web
site,
and
the
second
kind
of
related
is
that
you
want
to
automate
like
applications
for
the
new
product
when
the
user
go
to
to
some
website
and
apply
for
a
new
product
he
needs
to.
A
A
A
A
A
B
A
A
You
know
in
currently
the
user
sends
you
some
data
within
this
form,
but
you
used
you
don't
know
whether
you
can
trust
this
data
and
the
user
in
this
case,
user
doesn't
have
to
be
looked
into
some
system,
so
there
is
no
logging
in
just
scan
the
QR
code
and
send
the
data
okay.
So
that's
from
me
right
now
and
I
would
like
to
ask,
but
my
colleague
Patrick
on
stage.
B
So
good
morning,
everyone
happy
that
you
chose
our
session.
There
is
nothing
many
other
interesting
happening
right
now.
So
thank
you
for
your
time.
I'm
full-stack
engineer
at
EPSA,
I
work,
I
work
mostly
on
backend
and
operation
side
of
things
also
doing
a
little
bit
of
front-end
and
we
need
within
the
SSI
or
hyper
ledger
in
the
community.
I
might
be
known
as
author
of
in
this
scan,
which
is
hyper
ledger
in
the
blockchain
Explorer.
B
B
So
in
late
2018
we
started
a
simple
PLC
just
to
show
our
stakeholders
what
this
thing
can
do
and
to
to
to
get
it
moving
forward.
So
at
the
beginning
it
was
just
once
it
once
one
see
one
single
service
containing
all
the
KYC
pros:
kyc
business
process
logic
as
well
as
all
the
credential
related
technology,
so
it
was
pretty
simple
PLC
and
then,
after
our
stakeholders
approach,
we
start
start
to
iteratively,
improving
and
building.
B
However,
we
still
had
our
own
proprietary
communication
protocols,
so
we
were
not
interoperable
and
soon
there
was
another
male
member
of
South
African
blockchain
consortium,
which
was
given
a
very
I
institutional
agent
provided
to
them
by
a
burning
and
they
wanted
to
integrate
with
us.
So
we
couldn't
because
the
variables
using
their
proprietary
protocol-
and
we
were
using
our
own,
so
we
were
not
interoperable.
B
B
So
so
we
are
from
the
nice
outcome
of
this
integration
was
that
we
we
found
out
that
Libya
sex
is
really
nice
to
use,
so
we
decided
to
keep
it
and
build
on
top
of
that.
So
let
me
tell
you
just
shortly
about
levy
CX,
it's
a
library
for
a
verifiable
credential
exchange.
It
was
donated
to
in
the
indie
project
by
ever
name
the
core
of
it
is
written
in
rust,
but
it
is
bindings
in
multiple
languages,
including
Python,
nodejs,
Java
and
iOS.
B
So
I'll
tell
you
a
little
bit
about
how
we
start
to
adopt
this
library.
So
as
we
replace
Lib
in
D
the
core
in
the
sdk
library
with
live
vc
acts.
We
took
this
big
refactoring
as
opportunity
to
extract
it
into
a
separate
service.
We
call
it
the
v6
service
and
the
great
thing
about
that
was
now.
It
became
reusable
by
other
team
in
in
APSA,
and
the
KYC
service
basically
became
consumer
of
it
would
I
forget
what
I
did
intentions
intentionally
didn't
tell
you
yet.
Is
that
out
of
the
box
this
she
acts.
B
Although
there's
ways
around
it
out
of
the
box,
the
v6
is
meant
to
be
ran
against
agency
and
agency
is
well
established,
erm
in
SSI
community.
Basically,
what
the
agency
is
is
a
is
a
service
which
which
can
act
on
behalf
of
a
user.
So,
even
when
alice
is
here,
we
have
on
this
example.
We
have
Alice's
phone,
she
wants
to
receive
digital
credentials
and
communicate
with
various
institutions.
B
B
B
So
the
poor
architecture,
if
you
want
to
videos
a
DDoS,
your
system,
make
sure
to
include
polling
model
in
your
system.
So
at
first
there
was
no
other
way
around
this
agency,
then
to
constantly
keep
querying
it,
whether
it
has
any
new
messages.
So
even
if
you
have
just
600
devices
online
for
one
hour
and
you
try
to
pull
new
messages
every
two
seconds
that
it's
1
million
requests
in
an
hour-
and
it's
I
find
this
very
unnecessary.
B
So
then
we
can
respond
or
react
in
subtle
in
in
certain
way,
according
to
of
the
messages
and
from
whom
it
arrived
on
the
opposite
side
of
the
connection,
when
we
as
an
institution
send
a
message
to
someone,
may
be
issuing
a
credential,
this
message
is
sent
to
two
recipients
agent,
and
the
agent
dispatch
is
notification
to
another
special
service
down
there.
The
mobile
notification
service,
which
converts
it
into
a
push
notification
I
believe
there's
a
still
better
way
to
do
this.
B
B
Second
problem
was
that
by
default,
the
agency
was
using
the
the
default
india's
DK
library
bullet
implementation,
which
stores
the
data
in
a
form
of
file,
and
if
you
want
to
scale
and
think
horizontally,
you
need
distributed
persistent
storage.
So
maybe
you
could
attempt
to
somehow
share
these
files
across
multiple
a
nodes
of
agencies,
but
I
don't
find
it
very
elegant
approach.
So
instead
we
implemented
support
for
PostgreSQL
plugin
into
the
agency,
and
therefore
now
we
have
our
wallet
story
it's
distributed.
B
The
third
problem
is
that
the
agency
is
still
very
highly
stateful
and
in
order
to
be
able
to
scale
something
horizontal,
you
need
to
make
sure
that
it's
as
as
stateless
as
possible,
so
we
have
plan
to
make
this
happen
and
start
scaling.
These
open-source
implementation
horizontally
as
a
this
effort,
will
probably
have
three
main
stages
at
first.
B
So,
instead
of
doing
that,
we
want
to
bring
the
load
time
the
startup
time
down
to
a
few
seconds
in
the
second
stage,
we
would
like
to
make
make
it
more
stateless,
so
we
will
start
loading
the
agents
on
demand.
Whenever
there's
a
incoming
request
for
a
certain
agent,
we
can
load
up
the
necessary
state
and
after
we
do
state
update,
we
can
free
this
data
from
memory
and
keep
it
in
the
database
and
the
third
stage.
We
will
will
probably
consist
of
some
optimization
to
make
this
load,
and
this
very
quicker.
B
A
Right,
Thank,
You
Patrick.
So
just
briefly
summarize
what
we
have
said
today,
so
our
use
case
is
kyc,
it's
as
our
starting
use
case,
and
if
you
want
to
build
some
sse
solution
or
something
like
something
like
something
with
ssi,
you
basically
need
some
basic
elements
around
the
ids
and
crypto
and
credential
stuff,
and
but
you
also
need
need
some
protocol
how
to
exchange
of
these
messages.
A
So
we
started
with
approach
in
day
and
the
protocol
as
what
was
just
our
own
and
sending
HTTP
requests,
and
then
we
moved
to
vcx
which
provide
provide
provided
us
some
protocol.
Also,
on
top
of
that
lower
lower
level
elements
and
as
Patrick
mentioned,
the
last
that
is,
is
to
move
to
Ares
protocol,
which
is
because
the
vcx
protocol
is
just
not
stand-up
protocol
and
it
should.
It
should
change
with
with
every
specification,
which
would
be
like
interoperable
for
for
other,
a
lot
of
other
agents
together
and
as
patrick
mesh
mention.
What?
A
A
A
It's
it's
quite
good
right
now,
because
yeah,
it's
it's
quite
good.
What
the
algorithm
we
are
using
now
right
now,
it's
quite
good
with
this
matching,
but
what's
more
important
for
us!
Is
this
this
this
lightness
verification
we
call
life
as
verification,
so
we
need
to
be
sure
that
the
photo
is
from
the
user
with
that
mobile
phone
in
that
in
the
given
time
and
that
that
facial
facial
recognition
service
works
very
well.
So
there
are
some
persons
about
this
I
think
it's
90%
yeah.
B
B
A
A
There's
a
that's
a
good
question:
we
actually,
when
you
see
the
data
in
the
form,
we
actually
have
it
on
our
server
and
then
we
just
just
let's
say
that
we,
the
data
in
the
form
out
just
for
like
to
show
something
to
each
user
and
we
don't
take,
is
take
it
after
all,
so
we
have
it.
We
showed
it
to
the
user
in
the
website,
but
we
have
it
on
the
server.
So
if
user,
it
should
be
disabled
in
that,
in
that
case,
for
example,
don't.
B
B
B
C
A
So
actually,
the
storage
of
your
identity
is
in
your
in
your
mobile
phone
and
then
you,
if
you
you,
need
to
make
a
backup
of
it.
So
you
just
click
on
some
export
functionality,
export
it
and
secure
it
with
with
Pascal
some
or
password
or
some
passphrase,
or
something
like
that.
And
then,
if
you
want
to
import
it,
you
just
click
on
the
button.
Select
that
the
same
file
put
the
passphrase
into
that
back
again
and
we
decrypted
it
and
put
into
the
mobile
phone.
A
C
A
B
A
A
I
would
say
it's
more
about
collaboration
with
other
banks
and
finance
institution
and
in
this
consortium.
So
so
we
are
trying
to
like
discuss
it
with
government,
but
maybe
you
can
imagine
that
it's
not
like,
like
fast
to
coordinate
this
effort,
so
our
pre,
our
priority,
is
at
first
to
like
discuss
it
within
other
banks
with
this
consortium
and
then
maybe
try
to
collaborate
with
government.
A
But
for
this
for
this
use
case,
we
just
need
to
be
able
to
call
the
database
of
the
government,
and
it's
like
it's
possible
right
now
for
the
banks,
so
it'sit's
this
process
and
this
capability
is,
is
in
place
already.
So
it's
not
about
that.
We
are
asking
okay.
Can
we
like
do
this
or
that
we
just
we
are
just
using
the
API,
that's
out
there
and
the
banks
is
already
using
it,
but
we
just
issued
a
digital
credential
based
on
this
information.
A
A
B
A
What
I
didn't
mention
in
presentation,
I
guess
that
it
should
work
in
vice-versa,
so
we
also
should
accept
the
digital
credential
from
other
bank,
so
other
banks
can
have
their
own
mobile
app
and
if
go,
if
the
user
goes
through
this
process
with
with
them,
then
it
goes
to
APSA,
and
we
should
like
accept
this
credential
so
and
then,
then
it
depends.
What's
the
trustable
process
of
doing
this
verification,
I.