►
From YouTube: Trusted Data Ecosystems: Finding The Value In Identity
Description
A virtual meetup hosted by Hyperledger Denver featuring Ken Ebert, CTO of Indico, and Scott Harris, COO of Indicio who discuss how Indicio designed trusted data ecosystems to easily integrate into existing infrastructure, how easy they are to update, and easy to interoperate among one another—and how an open-source base enables continuous, sustainable improvement and innovation.
More about the meetup is at: https://www.meetup.com/Hyperledger-Denver/events/280759112/
----
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 #HyperledgerMeetup #Blockchain
A
A
B
Sure
we're
glad
to
be
here
from
indicio,
I'm
the
cto
currently
and
scott
is
our
vp
of
operations,
scott
harris
and
we
enjoy
working
together,
not
only
inside
of
our
own
company,
but
with
the
community
to
help
build
and
grow
the
ecosystem
that
is
based
on
some
of
the
open
source
code
that
has
been
developed.
Scott.
Do
you
want
to
take
it
away.
C
Yup,
thank
you,
ken
and
thank
you,
john.
The
description
creates
a
whole
lot
of
expectations
for
this
presentation.
I
hope
I
meet
them
all
and
ken
meets
them
all.
So
we
we
want
to
tell
you
a
little
bit
about
our
company.
First
and
dco
is
in
the
business
of
trusted
data
ecosystems,
and
that
covers
a
lot
of
ground.
The
trusted
data
ecosystem
is
a
the
minimum
viable
setup
that
enables
the
exchange
of
verifiable
credentials.
C
Building
this
in
the
real
world
and
we've
had
great
success
at
ndco,
because
we've
really
focused
on
building
things
in
the
real
world
and
putting
things
to
use,
and
so
I'm
going
to
go
and
do
a
little
bit
of
a
history
lesson
and
start
with
the
whys.
Why
are
we
building
this
for
our
clients?
Why
are
we
here?
C
Where
do
we
start
so
the
trusted
data
ecosystem,
as
I
as
I
said,
is
what
we
view
as
the
minimum
standalone
unit
of
decentralized
identity
and
that
consists
of
a
credential
issuer,
a
credential
holder
and
a
credential
verifier,
and
when
we
put
something
like
this
in
action,
we
find
that
all
three
participants
in
the
ecosystem
start
to
derive
some
immediate
value
from
the
execution
of
this.
It
eliminates
the
cost
of
untrust
trustworthy
data
and
I'll
talk
in
a
minute
about
the
cost
of
untrustworthy
data
to
all
of
the
participants.
C
So
the
trusted
data
ecosystem
is
our
our
starting
point
and
the
very
very
simplistic
view,
but
very
valuable
view
of
how
we
exchange
verifiable
credentials.
Why
do
we
do
it?
Well,
because
we
have
a
lack
of
trust
in
the
existing
data
models.
As
things
are
exchanged,
everybody
probably
has
a
linkedin
account
and
everybody
signed
up
for
linkedin
using
an
email
address,
and
the
question
is:
what
did
you
do
to
get
that
email
address?
C
It's
clear
that
needs
to
change
it'd,
be
great
to
know
that
somebody
on
linkedin
was
actually
who
they
claimed
to
be,
and
our
ceo
heather
likes
to
use
the
case
that
I
believe
there
are
at
least
seven
of
her
on
linkedin
all
using
her
same
profile
picture.
So
we
have
a
problem
with
identifying
individuals.
C
The
goal
of
decentralized
identity
now
is
to
take
that
concept
of
trust
and
add
in
efficiency.
So
here's
my
history
lesson
for
the
day
when
we
go
back
in
time
to
3200
bc.
Up
until
about
1964,
we
had
an
analog
system
of
document
exchange
where
we
would
hand
carry
things
or
we
would
put
them
in
the
mail
and
we
had
means
a
means
of
deciding
whether
or
not
to
trust
that
information
we
had
seals
from
notaries.
C
What
has
happened
since
1964
until
now
is
a
what
what
I
call
a
hybrid
world
of
trust,
deficiency
and
privacy,
so
we've
sacrificed
a
whole
lot
of
trust
in
the
exchange
of
documents
and
data
and
and
identifying
individuals
for
the
sake
of
some
efficiency.
So
we
do
things
like
upload
documents
and
scan
things
and
email
them
around
and
we
do
gain
some
efficiency.
C
So
why
does
a
document,
identity,
document
work
and
analog
life?
Well,
it
works
because
the
person
who
receives
it,
this
shop
owner
on
the
right,
has
a
means
to
visually
or
or
somehow
verify
the
source
of
the
data,
and
they
have
a
means
to
validate
whether
or
not
that
data
has
been
altered.
So,
in
the
case
of
something
simple
like
a
driver's
license,
we
can
determine
whether
it's
still
laminated
and
we
can
read
the
source
of
it
right
on
the
top
and
we
can
look
for
holograms
and
things
of
that
nature.
C
That
say
that
it's
real
and
what
that
amounts
to
is
that
it's
trustworthy
and
that
trust
comes
from
two
two
general
source
buckets.
It
comes
from
the
integrity
of
the
data,
so
that's
being
able
to
identify
whether
it's
real.
In
other
words,
has
it
arrived
as
issued
or
as
as
created
by
the
issuer
and
another
way
of
putting
it
is.
Has
it
been
altered
or
tampered
with?
Did
I
take
an
exacto
knife
to
it?
Did
I
hack
into
it
and
alter
a
date
or
a
name
or
a
photo?
C
So
it's
the
integrity
bucket
and
it's
the
authenticity
bucket.
So
there's
a
means
to
identify
the
source
of
the
data
and
and
verify
that
that
source
is
something
you
trust.
Does
this
driver's
license
come
from
where
it
claims
to
be
from
if
it
was
delaminated,
and
you
couldn't
see
the
state
name
at
the
top?
You
might
question
that,
so
in
the
analog
world,
we
have
a
really
great
way
of
identifying
data,
integrity
and
data
authenticity.
C
We
don't
have
that
in
the
hybrid
digital
world,
but
we
can
have
that
in
the
decentralized
identity
world
right
now
in
the
hybrid
world,
we
place
trust
in
what
I
call
representations
and
attestations
of
data
and
that
carries
costs
and
risk
to
ask
all
of
the
questions.
How
do
I
know
it's
real?
How
do
I
know
if
it's
been
altered?
How
do
I
know
if
it's
coming
from
where
it
claims
to
have
come
from
really
2fa
with
email
is
fine,
because
we
all
know
that
the
email
never
gets
hacked
right.
C
So
there
are
problems
with
that
and
what
this
does
is
it
forces
a
choice
between
trust
and
efficiency?
If
we
get
a
document
in
this
manner,
that's
been
scanned
and
emailed
or
uploaded.
We
have
to
go
through
some
exercises
or
processes
in
order
to
decide
whether
to
trust
a
document
and
all
of
those
processes
are
costly
or
inefficient
or
expensive,
or
have
privacy
and
gdpr
concerns,
and
we
decide.
Okay,
we
don't
want
to
go
through
all
those
exercises.
C
So
choosing
trust
right
now
moves
you
away
from
the
efficiency
side,
and
if
you
choose
efficiency,
then
you
go
down
to
the
bottom,
where
there's
more
risk
the
decentralized
identity
model
using
a
trusted
data
ecosystem
no
longer
forces
a
choice.
It
becomes
a
linear
scale
rather
than
a
triangular
relationship
where
risk
exists
on
one
side
and
trust
and
efficiency
exist
together.
On
the
other
side,.
C
And
my
slides
are
going
to
click
the
next
time.
I
promise
so
trust
exists
within
a
trust
model,
and
this
is
what
largely
falls
under
the
heading
of
governance
and
it
takes
two
forms.
It
takes
the
form
of
cryptographic,
trust,
that's
the
the
code
bases
and
all
of
the
good
things
that
we're
going
to
talk
about
here
in
just
a
minute
that
make
this
function
and
work.
And,
of
course,
if
all
of
that
works
as
intended,
then
we
do
have
cryptographic
trust.
C
We
have
a
means
of
going
to
a
ledger
or
reading
signatures
and
determining
whether
some
data
is
authentic
and
whether
or
not
it
has
integrity.
But
there's
also
the
philosophical
trust.
The
decision
that
the
receiver
of
the
data
over
here
on
the
right
needs
to
make
as
as
to
whether
or
not
the
data
they
received
comes
from
a
trusted
source.
C
So
that's
a
governance
thing
and
it's
a
thing
that
we
can
actually
execute
in
a
machine-readable
way
as
well
as
long
as
the
the
shop
owner
on
the
right
has
made
a
determination
that
these
things
are
trustworthy
and
these
things
are
not
or
these
sources
are
trustworthy.
In
these
sources,
or
not
and
in
a
trusted
data
ecosystem
trust
accumulates
where
we
have
a
credential
issuer
here
on
the
left.
That's
doing
some
trust
exercises.
Some
kyc
work.
Some
background
checks.
C
Start
to
attract
each
other
in
the
way
that
a
constellation
might
give
birth
to
new
stars.
So
once
one
ecosystem
is
actually
deployed
in
the
wild,
we
have
an
issuer
and
a
holder
and
a
verifier,
and
they
start
to
see
value
because
they
gain
the
efficiencies
that
I
talked
about,
that
that
triangle
becoming
a
linear
scale
and
gaining
trust
and
gaining
efficiency,
all
the
while
reducing
risk,
and
so
what
we
found
is
a
small
deployment
of
a
trusted.
C
Data
ecosystem
starts
to
attract
others
to
say,
hey
I'd
like
to
issue
some
credentials
in
this
way
too.
For
this
use
case,
whether
it's
health
care
or
financial
services
or
travel
or
any
of
the
many
things
that
we're
working
on
one
issuer
attracts
others
once
a
verifier
is
able
to
take
some
data
in
and
trust
it
and
execute
a
business
function.
Based
on
that
data
very
quickly,
other
verifiers
come
in
and
say
hey.
We
want
that
efficiency
too.
We
want
that
trust.
We
want
that
fraud
production
and
we
want
to
start
to
potentially
participate.
B
It's
attracted
scott.
I
think
that
one
of
the
key
points
that
you
made
there
is
that
each
of
the
participants
is
deriving
some
kind
of
value
or
benefit
out
of
the
system,
and
that's
what
makes
the
magic
happen
and
attracts
the
other
people
in
it's,
because
they
want
some
of
the
same
magic
and
if
a
holder
sees
I
can
pass
through
the
airport
in
two
minutes.
Instead
of
a
half
an
hour,
they
see
a
benefit.
B
If
a
holder
says
I
can
open
a
bank
account
with
less
friction,
and
I
don't
have
to
sit
in
the
lobby
of
the
bank
for
a
half
an
hour.
I
can
do
it
online
and
open
a
bank
account
more
rapidly
than
they
see
benefit,
and
each
of
the
people
in
the
ecosystem
by
by
driving
benefit,
attracts
other
people
who
want
that
same
type
of
benefit
to
the
system,
or
they
see
auxiliary
benefits
that
might
not
have
been
initially
anticipated
with
the
minimum
viable
trusted
data
ecosystem.
C
Yeah
that
that's
an
excellent
point
and
worthy
of
restating
in
a
number
of
different
ways.
You
know
a
great
example
in
financial
services
is
a
government
that
might
issue
a
credential
to
a
resident
within
that
jurisdiction,
such
as
a
driver's
license
or
or
even
just
based
on
their
existence
with
tax
returns,
or
things
like
that.
C
So
now
they
have
some
trusted
information
that
they
can
go
use
and
open.
A
bank
account
instantly
with
and
great
okay.
So
now
we've
got
the
minimum
viable
setup
where
we
have
a
government
issuer
and
an
individual
is
a
government
credential
holder
who
opens
a
bank
account
here
and
that's
great,
and
now
the
bank
suddenly
realizes
that.
C
Now
that
we
have
them
in
our
system,
we
can
issue
them
our
own
credential,
and
now
they
can
go
and
log
into
our
systems
in
a
credential
based
setup
rather
than
a
username
and
password
setup
and
and
expedite
all
of
that,
and
not
only
do
we
expedite
it,
but
we
lose
all
of
those
inefficiencies
that
surround
user
names
and
passwords.
So
this,
even
the
the
single
verifier
suddenly
decides
that
they
can
move
to
the
other
side
of
the
equation.
C
And
so
once
these
start
to
exist
as
long
as
they
are
proven
to
be
interoperable
and
ken
will
discuss
that
quite
a
bit
more
in
a
minute,
we
find
that
that
different
ecosystems
can
and
do
attract
each
other
a
lot.
The
way
you
know
a
set
of
molecules
might
attract
each
other
in
a
solution.
Here,
a
holder
in
one
ecosystem
in
a
travel
ecosystem
may
find
themselves
able
to
exchange
a
credential
with
a
verifier
in
a
financial
ecosystem.
C
Somebody
an
issuer
in
a
healthcare
system
may
give
something
to
a
holder
that
they're
going
to
use
in
the
travel
ecosystem
and
very
quickly.
We
find
a
lot
of
moving
arrows
and
a
lot
of
moving
pieces
and,
and
our
view
of
things
is
to
set
up
these
individual
units,
these
trusted
data
ecosystems,
so
that
they
bring
value
even
if
they
exist
entirely
on
their
own
in
isolation.
The
participants
have
value,
but,
of
course,
what
we
found
is.
B
The
whole
system
in
dco
operates
its
own
networks.
It
operates
a
test
net,
a
demo
net
and
a
production
network.
I
think
we
have
the
one
of
the
largest
hyperledger
indie
based
networks
that
are
available
for
permissioned,
write
and
public
read.
We
are
in
five
different
continents
with
over
25
node
operators,
that's
available
the
the
test
net
and
is
typically
for
rolling
out
new
versions
of
the
of
the
software
itself,
the
node
and
plenum
code,
that's
at
the
very
basis
and
foundation
of
the
how
a
node
operates
in
the
network.
B
The
demonet
is
for
places
for
people
to
test
out
their
solutions
on
top
of
the
network
and
then
the
main
that
is,
for
production,
use
cases
where
interactions
can
take
place.
There
are
other
networks,
indie
networks
around
the
world
in
europe,
the
united
states
and
and
elsewhere
that
offer
that
type
of
functionality.
B
Some
as
you
work
with
your
customers,
you
might
discover
that
some
of
them
require
their
own
private
network,
for
some
governments,
for
instance,
require
that
all
of
their
data
stay
within
their
their
jurisdiction,
and
so
they
won't
want
to
operate
off
of
a
worldwide
network.
That's
professionally
maintained.
They
need
their
own
network,
no
matter
what
the
available
solutions
elsewhere
might
offer.
That
forms
the
basis
of
the
network
at
the
bottom.
B
The
validator
nodes
are
the
the
nodes
participating
in
the
consensus
algorithm
to
arrive
at
what
are
the
immutable
objects
that
have
been
written
to
the
network.
The
optional
observer
nodes
are
not
in
used
in
practice,
yet
those
are
to
allow
for
if
the
network
ever
gets
constrained
in
performance
to
be
able
to
offer
the
ability
for
basically
a
read.
Only
cache
of
the
of
the
data
to
be
available.
Most
operations
are
verifications,
not
creating
a
new
issuer
and
registering
their
particulars
on
the
network.
B
The
operations
writing
to
the
network
are
only
to
set
up
to
be
able
to
issue
once
you're
starting
to
issue
those
go
directly
from
the
issuer
to
the
holder
and
don't
have
to
involve
updates
to
the
network
itself,
but
the
optional
observer
nodes
make
performance
people
to
be
boosted
beyond
the
limitations
of
just
a
set
of
validator
nodes
above
that
are
the
agents.
That's
where
the
fun
and
exciting
stuff
happens
once
you've
selected
a
network
to
build.
B
B
If
you
don't
have
any
holders,
there's
nobody
to
take
the
data
and
do
anything
useful
with
it,
and
if
you
don't
have
any
verifiers
you're
missing
the
the
actual
derivation
of
primary
value
of
a
credential
minimum
viable
ecosystems
need
to
address
all
three:
you
don't
have
to
have
12
issuers,
you
don't
have
to
have
100
verifiers.
You
need
one
of
each
at
least
to
start
the
system
out
and
get
started.
B
In
our
circumstances,
we've
found
that
as
soon
as
an
issue
or
actually
before
we
finish
the
first
implementation
of
a
minimum
viable
product,
our
customers
start
to
see
the
value
of
how
this
works
and
other
use
cases
that
they
can
use
it
for.
So
it's
really
critical
to
get
out
there
and
start
showing
something,
even
if
it's
not
in
public
you're,
showing
it
to
the
to
the
internal
company
and
making
sure
that
that
value
is
communicated
to
all
the
different
departments
and
all
the
different
partners
of
that
company.
B
B
B
Many
of
the
agents
will
have
a
web
ui
to
control
them.
There'll
be
a
cloud
agent
instead
of
a
pure
enterprise
agent
on
premise
that
might
be
hosted
in
the
cloud
with
a
web
ui
to
control
it.
The
web
uis
also
have
the
capability
of
hosting
the
control
modules
that
might
be
necessary
for
integration
with
existing
systems.
Most
of
these
systems
aren't
written
fresh
from
the
ground
up
as
a
revolution,
they're,
typically
evolutionary,
and
need
to
cooperate
and
participate
with
existing
systems.
B
That's
where
you're
going
to
have
the
least
disruption
to
the
to
assist
to
organization-
and
I
add
value
to
the
organization
without
having
them,
have
to
make
a
costly
rip
and
replace
type
of
a
strategy.
So
you
want
to
pay
attention
to
what
the
controllers
look
like.
How
do
you
integrate
and
obtain
data
to
issue
it,
and
how
do
you
integrate
verifications
into
existing
processes
to
make
them
smoother
and
more
manageable
edge
agents,
typically
on
a
mobile
device
or
laptop
desktop
type
of
orientation?
B
Allow
for
the
end
users
of
a
system
to
have
an
agent
that
represents
them,
because
mobile
devices
move
around
and
don't
have
fixed
endpoints
it's
advantageous
to
have
something
like
a
mediator
agent
that
provides
a
fixed
endpoint
and
also
provides
caching
and
buffering
of
those
messages
that
are
being
sent
to
a
an
edge
agent
to
allow
that
edge
agent
to
participate
in
an
exchange.
Even
if
they
might
be
offline,
they
can
have
the
initial
invitation
arrive
at
their
mediators.
B
Pick
it
up
the
next
time,
they're
connected
and
continue
the
conversation
to
go
through
either
a
message
exchange.
Other
type
of
protocols
such
as
issuance
or
verification,
the
edge
agents
that
we
use
are
using
a
mediator.
There's
a
two
that
are
fairly
reasonably
well
supported
the
occupy
functioning
as
a
mediator
agent
to
provide
that
secure
routing
function
or
the
aries
framework.
Javascript
is
another
one
that
we
have
used
to
provide
similar
functionality.
B
Our
edge
agents
are
based
on
again
aries
and
they
operate
in
react
native
and
it's
the
bifold
project
also
sometimes
called
the
aries
framework
react
native
agent
or
something
like
that,
something
really
complicated.
We
call
it
bifold,
because
it's
simpler
to
refer
to
that
wallet,
provides
the
user
interface
to
be
able
to
exchange
credentials
to
be
issued
them
and
present
them
in
a
user-friendly
way.
Those
are
all
open
source
projects
that
allow
for
the
building
of
the
custom
or
generic
agents
that
will
represent
the
businesses
or
organizations
in
your
ecosystem.
B
B
Typically,
data
is
not
stored
in
credentials
right
now,
so
they're,
the
issuer
agent,
it
might
be
stored
inside
of
a
database
and
that's
a
typical
location
to
find
source
data.
So
looking
at
integrating
with
a
controller
and
accommodating
that
data
as
its
data
source
and
being
able
to
put
into
a
verifiable
credential
allows
for
participation
with
the
holder's
consent
and
they
become
the
transport
mechanism.
B
B
There
is
documentation
and
it
is
published,
and
whoever
wants
to
dig
that
deep
can
dig
right
down
to
the
bottom
of
the
cryptography
and
figure
out
that
it
is
indeed
viable.
It's
been
evaluated
by
other
cryptographers
people
who
are
smarter
than
I
am
about
cryptography,
but
it
the
math,
makes
sense
to
me.
The
mechanisms
make
sense
to
me
and
that's
how
we
get
the
signatures
to
make
sure
that
the
data
is
transmitted
safely
again.
B
The
issuer
is
going
to
use
those
cryptographic
tools
to
do
the
signing
using
their
did
and
the
public
keys
that
they
use
or
the
equivalent
of
a
public
key
that
they
put
on
the
ledger
so
that
the
verifier
can
verify
that
it
was
signed
and
done
process
props,
processed
properly
the
credentials
given
to
the
issuer
from
the
issuer
to
the
holder,
the
holder,
because
of
the
zkp
style.
Zero
knowledge
proof
mechanisms
that
are
used
in
in
hyper
ledger.
D
B
The
end
user
is
able
to
do
some
something
called
selective
disclosure
or
predicate
proofs
to
either
obscure
fields
and
reveal
others
or
to
put
together
a
predicate
like
a
birth
date
greater
than
19
years
ago,
so
that
they
can
present
a
proof
that
they
meet
a
certain
requirement
without
having
to
reveal
all
the
data.
That's
an
important
part
of
the
cryptography
that
kamenish
latinskia
signatures
the
cl
signatures
that
are
used
allow
for
that
to
happen.
There
are
other
signature
styles
that
are
compatible
with
w3c
standards
that
don't
allow
for
selective
disclosure.
B
The
the
awesome
part
about
the
verifier
is
that
they
can
cache
most
of
the
things
that
they're
using
to
allow
for
fewer
accesses
to
the
internet
required
to
do
the
verification.
So
if
you're,
in
a
place
where
you
have
sketchy
internet
connection,
you
can
still
do
an
interaction
between
the
the
holder
and
the
verifier
and
still
get
the
the
that
to
occur
in
an
offline
manner
or
in
a
limited
connectivity
manner
to
be
able
to
do
the
presentation
of
the
thing.
B
This
diagram
is
taken
from
the
cardia
project,
where
a
medical
issuer
gives
data
to
a
holder.
Who
then
takes
it
and
presents
it
to
a
government
or
an
official
or
an
airline
for
verification
and
validation,
governments
and
medical
communities?
Don't
always
integrate
well
together
and-
and
so
this
is
an
awesome
way
to
transport
that
data
without
a
direct
integration
and
allow
for
privacy
to
be
preserved.
At
the
same
time,.
A
C
A
quick
thing
to
add
there
and
when
you
were
speaking
about
parsing
out
and
selective
disclosure,
is
that
so
many
of
our
clients
are
under
extreme
gdpr
pressure
to
not
retain
or
obtain
any
data
that
is
not
necessary
to
the
execution
of
a
business
service
and-
and
that's
where
some
of
this
magic
happens
is
to
take
a
a
credential.
That
is,
is
quite
robust
and
beefy
and
may
contain
a
lot
of
pii
and
a
verifier
can
request
and
only
obtain
the
pieces.
B
It's
important
to
balance
out
both
the
techie
parts
and
the
business
parts
of
any
type
of
solution
that
you're
building.
If
you
don't
take
both
into
consideration,
you're
going
to
have
a
nasty
surprise,
one
way
or
the
other,
and
so
having
that
coordination
between
the
business
people
and
the
legal
people
and
the
marketing
people
and
the
techie
people
makes
for
a
happier
outcome.
B
Some
people
look
at
and
say.
Well.
Why
did
you
do
that?
Why
would
you
have
algorithms
that
aren't
universally
trusted?
It's
because
the
different
components
of
the
cryptographic
library
may
need
to
be
altered
to
meet
certain
regulatory
requirements
in
certain
jurisdictions
for
the
hyperledger
indie
project.
Primarily,
we
focus
on
the
the
cl
signatures.
B
There
are
new
signatures
being
evaluated
and
added
to
the
that
cryptographic
suite
to
allow
for
simpler
signatures,
two
five,
nine
one,
twenty
five
one,
one
nine
I
I
can
never
get
the
numbers
right,
but
there's
a
new
signature
that
allows
for
a
basic
jason,
ld
type
signature
that
just
signs
the
entire
package
and
turns
it
over.
If
you're
going
to
reveal
all
the
data
and
there's
only
five
fields
anyway,
then
zkp
style
signatures
might
not
make
sense
for
that
type
of
credential.
There's
also
bbs,
plus
that's
being
explored.
B
B
There
are
currently
a
consensus
algorithm,
the
indie
plenum
code,
that's
the
byzantine
fault,
tolerant
algorithm
that
keeps
the
ledger
talking
in
sync,
so
that
the
the
everybody
agrees
on
what
was
written
to
the
ledger
and
it
can't
be
tampered
with.
The
indie
node
is
the
piece
that
receives
the
transaction
and
actually
evaluates
and
writes
it
or
reads
a
transaction
from
the
ledger
to
to
produce
it
back
out
to
anybody
who
needs
to
consume
it.
B
The
there
are
also
hyperledger
indie
plugins,
there's
a
experimental
token
plug-in,
for
instance,
that
allows
for
tokens
to
be
used
on
a
network
for
either
token
network
fees
or
other
types
of
value
exchange.
Their
their
plugins
can
be
allowed
to
extend
the
functionality
of
the
network
without
having
to
have
everybody.
Take
the
change
by
forcing
it
into
the
node
or
the
plenum
code
on
the
right
are
the
the
stacks
that
sits
slightly
higher
above
the
the
node
code
to
allow
for
applications
to
be
written.
B
The
indie
resolver
takes
the
the
dids
that
are
basically
addresses,
so
they'll
take
a
did
method
and
resolve
it
and
figure
out
where
to
go
on
a
on
the
ledger.
To
get
that
particular
information.
The
sdk
above
that
is
a
form
of
packaging
to
make
those
calls
a
little
easier.
The
agent
code
itself
sits
above
that,
and
typical
agent
code,
like
I
said,
is
aries
agent
cloud
agent,
python
or
accupy,
or
the
bifold
project
built
on
top
of
the
aries
framework.
Javascript
are
the
ones
that
we
favor.
B
There
are
other
frameworks
as
well.
There's
one
for
go.
There's
one
for
java,
there's
different
frameworks
that
can
be
used
that
are
all
interoperable
because
they
maintain
the
same
protocols
and
standards
for
interacting
the
enterprise
mo
and
mobile
apps
that
sit
on
the
very
top
are
the
places
where
the
customization
to
make
it
work
with
your
community
take
place.
You
need
to
stay
if
you
had
to
start
somewhere
start
at
the
top
and
work
your
way
down.
B
Don't
try
to
start
at
the
bottom
and
work
your
way
up,
figure
out
how
you're
going
to
take
some
existing
agents
and
code
and
samples
to
to
modify
to
fit
your
particular
vertical.
The
cardia
project
that
ceta
and
dco
worked
on
and
contributed
back
to
the
linux
foundation.
Public
health
built
this
on
this
same
technique.
B
It
took
the
bifold
project
and
built
on
top
of
that
to
customize
the
user,
end
user
experience
and
also
customize
the
bifold
same
bifold
project
to
create
a
mobile
verifier
for
small
businesses
to
use
in
verification
once
a
traveler
had
arrived
in
in
country
that
complete
ecosystem
preserves
the
privacy
and
health
data
by
having
a
both
a
primary
credential,
a
vaccination,
a
test
result
or
a
vaccine
exemption
credential.
That
is
then
presented
to
a
government
agent.
B
The
government
agent
evaluates
it.
According
to
the
machine,
readable
governance
determines
whether
it
meets
the
rules
or
not,
and
then
issues
a
a
type
of
derivative
credential,
which
is
basically
a
subset
of
data
that
says:
here's
your
name
and
and
some
identifier
to
to
help
associate
it
with
you
and
then
whether
or
not
the
government's
approved
you
for
entry
into
their
country.
So
that's
called
a
trusted
traveler
credential
and
that
trusted
traveler
credential
can
be
used
with
the
local
restaurant
casino
hotel
sports
venue.
B
C
C
Ecosystem
deployment
and
our
philosophy
at
ndco
has
always
been
to
start
small
and
start
with
that
minimum
viable
unit,
the
trusted
data
ecosystem
with
one
issuer,
one
holder
and
one
verifier,
and
understand
that
when
you
you
package
it
up
that
way,
you
can
derive
some
immediate
value
from
that,
even
very
small
deployment
and
the
the
ease
with
which
it
integrates
with
existing
systems
without
having
to
do
all
the
complicated
integrations.
So
it's
a
phased,
agile
approach
that
we
take
and
we've
got
to
be
very
successful.
C
C
Yeah,
certainly
starting
with
the
top-down,
you
know,
bill
grohmann
a
day
approach.
Is
you
do
a
lot
more
problem
solving
before
you
ever
derive
any
value
out
of
the
system?
So
it's
an
evolutionary
approach
that
we
like
to
take,
and
so
when
we
have
or
put
tdes
trusted
data
ecosystems
out
with
our
clients,
there's
a
business
side
of
things
that
we
provide
and
a
technical
side
and
we've
discussed
both
of
those
things.
C
But
you
get
everything
from
you
know
the
ui
ux
and
workflow
designs,
architecture,
governance,
marketing
and,
of
course,
all
of
the
the
agents
and
applications
and
the
network
to
power
it
that
it
can
discuss.
So
this
is
the
foundation
of
a
trusted
data
ecosystem,
our
we
feel
that
it
can't
exist
and
provide
value
with
all
of
without
all
of
these
components
in
that
same
package,.
B
One
of
the
things
that
trips
some
people
up
is
that
there's
a
difference
between
governance
of
a
network.
What
are
the
rules
and
operations
for
working
with
a
network
and
what
are
the
rules
and
operations
for
the
actual
issuers
and
verifiers
in
a
system
if
you're
using
we,
we
advocate
using
machine,
readable
governance
for
the
operation
of
the
day-to-day
business
operations,
because
it
can
be
uploaded
and
dynamically
pulled
into
the
agents
and
operated
on
that
way.
B
You
can
take
things
like
bad
actors,
so
if
a
an
issuer
is
determined
to
have
gone
sour
or
gotten
hacked,
you
can
remove
them
from
the
governance
or
replace
their
their
trusted
issuer
with
a
new
trusted
issuer
id
and
deactivate,
basically
all
of
the
old
credentials
and
and
give
them
a
new
chance
to
start
over
in
the
ecosystem
or
remove
them
from
the
ecosystem.
If
it's
as
malicious
action,
I
think
that's
one
of
the
interesting
things
so
that
the
the
governance
bits
of
how
to
do
the
day-to-day
who's
trusted
who's,
not
trusted.
B
What
are
the
rules
for
presentations
are
covered
in
machine,
readable
governance,
the
operation
of
a
network
has
its
own
governance
and
they're,
typically
external
rules
that
that
determine
that
there's
also
probably
a
written
governance
that
that
goes
for
operating
a
a
mini
ecosystem
to
describe
behavior
trusted,
behavior
and
so
forth.
That
then
gets
translated
into
that
machine,
readable
bit.
C
A
Yeah
definitely
time
for
quiz
scott.
So
let's
take
a
look
here
and
we've
got
some
great
questions
that
have
come
through
the
chat,
so
I'll
go
ahead
and
address
those
with
you
first
and
then
what
I'd
like
to
do
is
I
have
a
few
questions
that
I
have
from
your
wonderful
presentation
and
I'll
just
go
through
those
as
well.
So
michael.
I
know
you
had
about
two
or
three
questions
here
and
I
think
ken
and
scott
did
a
great
job
of
answering
some
of
those.
E
E
E
B
So
there's
a
couple
of
interesting
things:
when
you
find
credentials
normally,
errors
occur
even
with
good
good
issuers.
You
may
need
to
revoke
individual
credentials.
There
is
also
the
case
where
you
need
to
take
all
of
the
credentials
out,
and
you
can
do
that
with
the
the
machine,
readable
governance,
you
just
delete
their
entry
and
they're
no
longer
trusted.
B
Typically,
a
more
common
scenario
would
be
that
there's
a
hack
or
some
kind
of
an
event
where
they
need
to
they
can
the
issuer
themselves
can
revoke
a
whole
bunch
of
credentials
and
then
come
back
online
or
you
can
say
that
agent
is
was
corrupted.
We
don't
trust
anything
that
came
from
that
particular
agent
and
you
can
reinstantiate
them
with
a
different
did
and
credential
definition.
E
So
ken
at
that
point,
though,
at
that
point
though,
yes,
so
at
that
point,
you've
determined
I'm
a
bad
actor
now
do
you?
Does
anyone
have
the
ability
to
push
out
notifications
to
all
those
people
that
hey
you
went
to
ken
he's
now
a
bad
actor?
You
need
to
do
something
about
it,
or
is
it
just
something
I'm
going
to
find
out
on
my
own
the
next
time
I
try
and
use
that
credential.
B
Well,
hopefully,
your
your
your
agent
can
be
updated
when
the
machine,
readable
governance
changes
and
you
can
your
agent
can
notify
you
directly.
You
can
also,
if
the,
if
you
have
a
more
reasonable
person
who
is
trying
to
replace
the
credentials,
they
can
send
a
message
because
they
do
have
a
connection
and
they
know
you're
dead
because
they
issued
it
to
you
right
right.
They
can
notify
you,
that's
a
normal
business
process.
A
E
A
E
Yes,
thank
you
so
much
for
for
the
information
so
far,
so
I'm
familiar
with
in
this
show
and
and
and
I've
I
just
wanted
to
see
like
how
can
we
expand
that
vision
even
further,
so
this
secure
is
currently
one
of
your
node
operator
and
the
also
wallet
that
compatible
with
with
your
system
is.
Is
my
previous
starter
company
for
my
current
startup
we're
building
something
where
we're
expanding
on
the
on
the
possibility
of
using
something
like?
E
Maybe
it
could
be
like
a
data
friendly
method
like,
for
example,
the
ceramic
network
and
their
x
id
and
there's
other
basically
implementations
where
you
can
use
multiple
kind
of
notes
instead
of
just
nd
on
the
ledger
side
and
and
just
the
possibility
would
be
also
like
the
the
the
basically
the
use
of
token
and
the
and
and
fees
and
so
on.
So
that's
just
just
would
like
to
know
if
there's
any,
if
you
have
any
thoughts
on
that.
B
There's
a
you
brought
up
an
interesting
topic
that
we
could
probably
spend
a
half
an
hour
on,
but
let's
try
to
cover
some
of
the
basics
really
quickly.
So
the
right
now
we're
at
single
ledger,
support
kind
of
is
the
norm
and
it
can
support
one
indie
ledger
at
a
time
the
cardia
project
on
our
interop
next
interacthon
we're
trying
to
focus
and
and
look
to
multiple
indie
ledgers
at
the
same
time
that
I
think
will
be
pushed
along
happily
by
the
the
did.
B
Indy
method
instead
of
did
sovereign,
so
that
would
that
will
promote
that.
There
are
also
efforts
to
increase
the
ability
to
resolve
first
credentials
that
come
from
different
ledgers
that
are
also
w3c
compatible
to
that
for
all
the
the
basic
verifiable
credentials
model
data
model,
although
they
might
have
different
ledgers
that
they
support
different
types
of
ledgers
like
ethereum
or
bitcoin
or
whatever
different
other
types
of
ledgers.
B
B
A
E
E
B
So
those
are
both
good
questions
as
well.
Inside
knowledge
is
not
something
particular
to
an
open
source
project
because
yeah,
it
is
mostly
controlled
by
community
meetings,
because
we
do
have
a
number
of
maintainers
on
the
project.
We
do
have
some
say
in
getting
things
done
mostly
because
we
contribute
the
effort,
but
that
those
are
both
interesting
topics,
so
backup
and
restore
of
wallets
is
one
one
thing
wallet.
B
Migration
is
a
second
topic
where
you
can
take
it
from,
for
instance,
the
in
the
bifold
wallet
and
import
it
into
the
intrinsic
wallet
or
something
like
that.
So
those
are
two
interesting
topics
and
I
both
think
they're
in
the
cards
for
the
future.
Exact
dates
are
something
that
in
open
source
projects
are
not
always
nailed
down,
but
those
are
those
are
topics
of
interest
and
will
be
addressed.
I'm
pretty
sure.
A
E
C
It
works
better
when
I'm
not
on
mute
yeah
absolutely
so
we
have
a.
I
have
to
think
carefully
because
we
do
have
a
lot
of
number
of
clients
developing
use
cases
that
that
are
still
you
know,
top
secret
in
their
eyes.
So
the
high
profile,
one
that
we
did
was
with
ceta,
the
global
airline
travel
consortium
and
the
nation
of
aruba,
where
we
and-
and
that
was
the
origins
and
source
of
the
cardia
code.
C
So
that
was
taking
a
health
credential
from
a
healthcare
provider
using
it
to
send
to
the
government
of
aruba
where
they
did
a
verification
checked.
The
health
status
made
the
determination
that
a
traveler
was
covered,
free
and
healthy,
and
then,
as
I
described
in
my
portion
there,
the
government
turned
around
and
went
from
becoming
being
a
verifier
to
becoming
an
issuer
and
issued
the
traveler,
a
derivative
credential,
a
trusted
traveler
credential
that
they
could
share
with
with
other
verifiers
on
the
island
and
protect
privacy.
B
So
liquid
avatar
is
primarily
focused
on
financial
services
market
and
they
provide
identity
credentials
they've.
Also,
since
the
cardia
project
was
announced,
they've
decided
to
become
compatible
with
that
they
do.
They
used,
I
think
the
the
enterprise
agent.
That's
the
part
of
the
open
source
cardia
project
code
as
a
basis
for
their
issuer
to
try
to
support
healthcare
credentials,
but
they
had
their
very
own
wallet
that
they
wrote.
That
is
a
cloud
hosted,
custodial
wallet
controlled
by
a
mobile
app.
So
it's
a
little
bit
different
spin.
They
did.
B
C
A
D
D
If
we're
talking
about
blockchain
and
we're
talking
about
the
integration
of
all
of
these
things,
then
that
means
you
need
to
integrate
the
iot
world,
which
is
the
physical
world
with
the
blockchain,
which
is
you
know,
on
the
on
the
digital
side,
with
a
digital
twin
and
you
need
a
digital
footprint
time
stamp,
thumb
fingerprint,
etc,
etc.
This
is
kind
of
what
we're
doing
so.
D
Your
colleagues
have
actually
reached
out
to
me,
as
I'm
on
you
on
your
webinar,
and
that
was
really
really
fast
fantastic,
but
I
see
lots
of
synergies,
but
my
question
is
because
we're
providing
trusted
auth
trusted,
identity,
authentication
and
data
privacy
protection
as
well,
so
I'm
just
trying
to
find
where
the
synergies
are
with
what
we
do
with
what
and
with
what
you
do.
That's
what
that's
that's
why
I
asked
this
question.
B
D
B
They
don't
have
any
smarts
in
them
at
all.
They're
inanimate
objects
that
have
no
electronics,
so
you
do
absolutely
need
a
digital
twin
for
an
inadequate
object.
Right,
yeah,
lower
capability
iot
devices
might
need
a
an
agent.
That's
cloud
hosted
for
them
as
well.
Some
of
the
smarter
drones
and
things
like
that
might
have
the
agent
built
into
the
iot
device
itself
and
be
able
to
interact
directly
as
a
just
like
a
human
would
with
a
cell
phone
right.
So
so
there's
kind
of
a
spectrum
of
use
cases.
B
I
think
in
the
end,
the
iot
devices
will
outnumber
us
and
should
be
a
very
important
part
of
consideration
for
how
the
devices
can
interact
in
a
similar
way
to
establish
trust
and
both
be
issuers
of
verifiable
data
that
might
be
useful
in
interactions
between
the
iot
devices
themselves,
like
if
you
imagine,
a
a
drone
delivering
a
package
that
may
need
to
interact
with
a
with
the
package
itself
that
has
its
digital
twin.
It
may
need
to
interact
with
airspace
control.
It
may
need
to
interact
with
buildings
or
a
company
receiving
the
package.
B
Iot
devices
that
are
sources
of
data
only
monitors
on
sensors
and
those
sorts
of
things
might
need
to
just
be
issuers
of
credentials
that
can
be
aggregated
or
relied
on
as
a
chain
of
data
that
that
can
be
trusted
and
known
that
it
has
been
tampered
with.
So
there's
a
number
of
interesting
bits
of
establishing
an
identity
for
an
iot
device,
and
then
what
do
you
do
with
the
credentials
that
are
either
issued
to
it?
D
B
Yeah,
the
there's
other
fun
topics
that
come
up
that
are
related
to
people
and
iot
devices
about
establish
discovery.
How
do
you,
how
do
you
find
people
in
organizations
and
iot
devices?
You
know
how
do
you
discover
and
make
connections
with
them?
What
are
the
authority
mechanisms
that
are
in
place?
Some
some
hierarchies
require
authority
faa,
for
instance,
has
authority
over
the
air
spaces
and,
and
then
regional
controllers
and
and
so
forth.
B
D
So
it's
better
to
slice
and
dice
the
data
refine
it
at
the
edge
before
you
reach
the
cloud
and
that's
what
we
see
going
on
with
module
vendors.
So
it's
it's!
It's
pre
cloud
that
they're,
adding
the
ai
and
it's
in
the
module,
and
it's
at
this
at
the
edge
of
the
sensor
collection.
This
is
what
we're
seeing
more
and
more.
B
A
B
A
A
B
So
the
the
bad
actor
question
is
typically
dealt
with
at
the
governance
level.
That's
one
level,
it's
the
people
level
above
the
the
organization.
It's
the.
How
does
the
the
ecosystem
define
itself
and
its
rules
and
how
does
how
do
they
take
care
of
introducing
new
trusted
issuers
and
verifiers
or
holders
into
the
equation?
And
how
do
they
remove
people
who
are
behaving
poorly
and
what
kind
of
remediation
is
involved?
B
B
But
the
you've
got
to
deal
with
it
in
at
least
those
two
different
levels.
So
how
do
the?
How
do
the
organizations
running
the
whole
network
deal
with
it
and
then
how
do
they
inform
all
the
participants
so
that
that
bad
actors
are
now
no
longer
recognized,
as
recommended
participants?
There's
nothing
that
prevents
in
machine,
readable
governance.
An
agent
from
interacting
outside
of
the
governance
rules,
the
governance
rules.
B
There
are
help
to
help
protect
the
interactions
and
flag
things
that
might
be
dangerous,
but
they
shouldn't
override
a
person's
ability
to
do
some
type
of
an
ad
hoc
interaction.
In
most
cases,
in
some
cases
like
national
security
issues
or
something
like
that,
they
might
restrict
the
the
rules
and
the
agents
to
only
obey
the
rules
that
are
in
force
at
the
time.
But
most
instances
like
if
you're,
setting
up
a
loyalty
program
for
your
for
your
customers,
you
shouldn't
prohibit
them
from
interacting
in
ways
that
were
unanticipated
just
because
you
didn't
think
of
them.
B
C
I
was
going
to
add
that
I
think
that's
where
the
machine,
readable
governance
provides
an
agility
to
make
those
ad-hoc
decisions,
because
those
unanticipated
uses,
while
some
of
them
may
be
on
the
negative
side
of
the
spectrum,
others
may
provide
some
some
unintended
or
unrealized
value
that
that
wasn't
there
at
the
beginning
of
the
ecosystem
development.
So
the
machine,
readable
governance
really
is
key
to
realizing
those
those
unrealized
values
and
also
to
be
able
to
slowly
remove
those.
A
Perfect,
scott
and
ken,
I
really
want
to
thank
both
of
you
for
the
session
today
and
anyone
that
has
any
questions.
Both
ken
and
scott
have
posted
their
emails
in
the
slide
presentation
there,
and
then
this
is
gonna.
Go
out
on
the
hyperledger
youtube
channel,
so
check
it
out.
If
you
missed
anything
as
far
as
any
portion
of
this
presentation-
and
I
hope
everyone
has
a
wonderful
day-
and
we
look
forward
to
the
next
hyperledger
meetup
coming
up.
A
F
F
Yeah
that'd
be
great,
so
there
are.
There
were
questions
about
how
you,
what
sort
of
data
you
could
produce
zkp's
over
so
proofs
proofs
around,
and
I
was
wondering-
is
there
any
standard
that
you
know
of
right
now
that
can
take
a
some
sort
of
coordinates
reference
and
identify
that
the
coordinates
are
within
a
scope
of
a
boundary
of
a
geographic
area
such
as
a
a
whole
bunch
of
different
proofs?
F
B
B
It'd
be
a
lot
of
complex
polygons
in
order
to
pull
it
off
and
you
could
do
it,
but
I
haven't
seen
anybody.
That's
done
anything
beyond
rudimentary.
Rectangular
type
coordinates
for
distance
within
type
of
computations.
The
the
computations
involved
in
seeing
if
a
geo
set
of
lat
long
coordinates
are
inside
of
a
particular
location.
B
Could
could
be
done,
but
I
don't
think
that
the
the
predicate
proofs
are
up
to
that
particular
challenge
yet
because
you
have
to
tailor
it
to
a
particular
geographies.
So
you
could
as
long
as
you
know
the
geography
of
the
thing
you're
going
to
do.
You
could
make
a
very
complex
predicate
proof
that
would
satisfy
that,
but
it
would
be
really
really
difficult
to
codify
that
for
multiple
geographies
and
make
it
more
universally
useful.
F
If
you
had
a
a
a
data
standard
in
which
is
being
used
to
for
reference
for
computation
to
determine
whether
or
not
you
know,
these
points
fall
within
this
geographic
boundary
and
the
code
involved
in
that
computational
process
was
deterministic
and
was
sort
of
a
able
to
have
its
source.
But
the
code
and
the
source
verified.
F
B
Yeah
the
the
approach
I've
seen
most
people
use
for
that.
Your
particular
problem
is
the
trusted
execution
environment
methodology
and
it's
basically
sending
it
out
to
a
third
party,
hopefully
in
a
trusted
way.
You
know
communicating
that
data
securely
and
then
trusting
that
the
the
computation
done
by
the
third
party
is
accurate
and
then
getting
a
return
result.
I
haven't
seen
anybody
wedge
that
into
a
a
nice
neat,
zkp
style,
predicate
proof
to
to
achieve
your
goal.
It's.
F
B
Yeah
I've
seen
people
do
that
with
basically
assigning
a
credential
to
the
algorithm
to
the
code
itself
or
to
the
data
set.
That's
the
reference
data
set
and
but
you're
still
trusting
the
trusted
data
and
execution
environment
to
accurately
produce
that
and
then
yeah
there's
a
result
that
you
trust.
B
It's
a
good
line
of
thinking
and
it's
a,
I
think,
an
appropriate
way
to
solve
the
problem
in
the
in
the
present,
not
in
the
future,
so
that
that
that
could
be
done
and
then
a
credential
issued
on
the
by
the
trusted
data
trusted
execution
environment
to
say
that
I'd
performed
the
computation
and
here's.
My
here's,
my
credential,
that
I
have
a
certified
set
of
code
running
here
and
I
have
a
certified
data
set
as
a
reference
that
I'm
operating
against.
So
that's
that's
one
mechanism.