►
From YouTube: Hyperledger Geneve hosts "TrustID decentralized Hyperledger Fabric ID project by Telefonica"
Description
A virtual meetup hosted by Hyperledger Geneve featuring a discussion of the new TrustID Hyperledger Lab project started by Telefonica.
More about the event is at:
https://www.meetup.com/Hyperledger-Geneve/events/271915693/
----
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 #HyperledgerMeetups #Blockchain
B
A
A
B
A
B
A
Good,
it's
1705.!
So,
let's,
let's,
let's
start
now
so
hello,
everybody.
Thank
you
all
for
joining
this.
This
geneva,
hyperledger
meetup,
where
we
have
actually
guests
from
spain
from
telefonica,
who
will
be
talking
about
one
of
their
project,
called
trust
id
this
session
was
run.
I
think,
last
week
in
spanish.
So
this
is
the
english
version
of
of
the
session.
I
was
gonna,
say
international,
but
I
think,
there's
a
whole
bunch
of
international
countries
where
spanish
applies
as
well.
A
So
this
is
the
english
version
of
this
session.
We'll
have
two
main
speakers
we'll
have
maria
teresa
and
alfonso
both
from
telefonica,
who
I
will
let
them
present
themselves
just
as
a
little
bit
of
logistics.
This
event
is
being
broadcast,
live
on
youtube
with,
I
think,
about
20
to
30
seconds
delay
on
youtube.
It
is
recorded.
I
am
also
recording
it
myself
for
backup
purposes.
So
if
you
have
any
issues
with
being
recorded,
it
probably
is
a
good
idea
to
to
express
them
now,
but
we
will.
A
B
B
So
thank
you
jealous
for
the
presentation
and
thank
you
david
again
for
for
helping
us
to
to
to
organize
the
meetup
and,
let's
going
to
present
ourselves
hi
everyone
again.
This
is
maria
teresa
and
alfonso
is
going
to
to
talk
later
he's
going,
I'm
going
to
be
part
of
the
more
theoretical
part
about
trust
id,
and
then
we
are
going
to
make
a
demo
with
the
code
that
we
have
developed
and
also
is
going
to
be
in
charge
of
the
demo.
B
So
I
let
me
let
me
start
with
a
a
little
story.
So
I
don't
know
if,
if
you
know
a,
what
is
the
work
that
that
we
have
been
sorry
is
damage.
This
is
the
problem
for
of
teleworking,
so
yeah.
Well,
everything
started
with
with
rustoes
the
the
product
that
that
we
have
been
developing
in
in
telefonica,
and
the
main
purpose
of
trustos
is
to
to
offer
of
clients
an
abstraction
of
a
set
of
use.
Cases
related
with
the
blockchain
technology,
like
tracking
tokenization
settlement,
trust
and
identity.
B
B
So
if,
if
we
forget
blockchain
technology
and
if,
if
we
go
to
a
traditional
model,
when
we
have
to
make
any
authentication
method
in
a
in
a
current
application,
we
usually
use
database
or
lda,
sorry,
ldap
or
any
stuff,
with
a
storage
to
authenticate
users
in
a
centralized
way.
However,
we
were
in
the
blockchain
technology
in
the
decentralized
world,
and
also
we
were
using
more
than
one
platform.
We
were
using
ethereum
and
hyperline
fabric,
so
we
need
to
create
an
access,
management
and
decentralize
it
and
also
compatible
with
without
with
two
blockchain
platforms.
B
So
we
started
to
to
analyze
how
to
create
user
management
in
different
blockchain
platforms.
So
as
to
start,
we
started
with
the
basics
that
how
identities
are
managed
in
blockchain
technology,
so
we
started
to
to
to
to
analyze
the
identity
management
in
hyperlayer
fabric.
Where
do
you
have
a
ca
and
you?
You
can
enroll
users
and
use
their
certificates.
B
B
B
Each
organization
represents
a
company
and
it's
every
company
have
their
own
ca
and
it's
peers
right.
So
if
we
enroll
users
in
a
ca
of
the
company
a
and
then
the
company
a
disappears,
all
the
users
that
have
been
presented
in
that
company
are
going
to
lose
their
access,
because
this
company
has
a
go
away.
So
again
we
have
a
problem
also,
if,
if
we
want
to
create
an
authentication
method
with
the
certificate
authorities,
you
don't
have
that
functionality.
B
B
And
finally,
the
two
most
important
things
for
us
is
that
the
custody
of
the
keys
also
belongs
to
the
sdk.
When
we
use
the
sdk,
we
can
enroll
an
an
identity,
and
this
identity
is
stored
in
a
wallet.
But
if
you
want
to
give
the
users
like,
for
example,
in
ethereum,
that
you
can
give
the
users
the
public
key
and
the
private
key,
and
he
can
use
it
in
metamask
or
any
wallet,
we
cannot
do
this
with
hyperlink
fabric.
B
B
Their
kills
create
a
model
of
keys
that
could
be
interoperable
with
other
platforms
or
methods
and
to
give
different
access
to
chain
codes,
but
because,
for
example,
if
I
deploy
a
chain
code
in
high
player
fabric
in
in
a
channel,
everyone
in
this
channel
can
interact
with
this
jingle
and
can
perform
any
operation,
reads:
rights,
etc.
But
what
happens
if
we
want
to
give
users
in
the
same
channel,
access
to
any
only
one
chain
code
and
only
great
taxes
and
not
write
access?
B
B
So
now
that
we
have
understand
the
requirements
that
we
want
to
to
the
to
trust
twice.
In
our
case,
we
started
to
thinking
about
how
to
create
trust
id.
At
the
end,
when
we
started
to
think
about
how
to
create
the
solution,
we
realized
that
trust
id
is
a
will
not
be
going
to
to
be.
Only
a
model
of
our
trustus
trustee
could
be
a
project
that
could
be
integrated
with
trustworthy,
but
it
could
be
a
project
that
could
be
integrated
with
with
other
solutions.
B
B
So
what
are
the
basics
of
of
this
project
and
we
want
to
to
create
well
in
this
case,
we
want
to
to
to
sign
every
interaction
with
any
blockchain
platform,
so
in
hyperled
fabric
by
native,
we
we
have
a
a
public
infrastructure
and
its
transaction
is
sign
it.
But
in
this
case,
instead
of
using
the
case
of
hyperlink
fabric,
we
want
to
use
a
the
standard,
json
object,
assignment
and
encryption
and
use
a
json
web
signatures
to
sign
every
transaction
in
the
network.
B
B
We
don't
have
to
use
a
player
ca,
for
example,
if
we
don't
want
to
to
use
it.
So,
on
the
other
hand,
identities
will
be
verified
by
a
set
of
controllers.
What
that
means.
We
are
going
to
use
some
entities
that
are
going
to
be
the
controllers
of
the
network,
and
in
this
way
we
are
going
to
decentralize
it.
So
if
we
want
to
to
create
an
identity,
I
for,
for
example,
on
a
user.
This
identity
is
going
to
have
some
controllers
that
have
verified
this
identity
before
so.
B
And
finally,
the
most
important
thing
that
we
were
searching
at
first
is
to
to
make
it
everything
interoperable.
So
in
this
way
now,
if,
if
we
have
an
application
that
wants
to
connect
with
any
dlt
platform,
we
are
going
to
have
on
the
work.
On
the
one
hand,
the
trust
ids
sdk,
that
is
going
to
implement
all
the
client
logic
to
connect
to
any
blockchain
platform
and
on
the
other
hand,
we
are
going
to
have
the
trust
id
same
code.
B
So,
at
the
end
a
trust
id
is
not
only
a
part
of
our
trustus
is
a
complete
project
that
can
be
independent
of
trustworthy.
So
we
have
to
make
a
lot
of
work
because
we
want
to
make
it
compatible
with
different
blockchain
platforms,
not
only
with
hyperlayer
or
ethereum,
maybe,
for
example,
with
corda
at
the
future,
and
and
that's
why
we
decided
to
to
to
move
it
to
hyper
to
high
player
labs
to
to
grow
the
project
and
to
have
some
collaboration
with
the
community.
C
C
C
What
it
does
is
to
get
the
signature
of
this
request
and
check
if
first,
if
it's
a
valid
user,
because
if
the
user
is
is
registered
in
the
in
the
platform
through
the
registry
id
user,
that
that
you
see
there
that,
in
the
end,
is
just
a
register
with
all
the
registered
users
in
the
trustee
platform
and
it
checks
if
the
corresponding
user
has
permission
to
access
the
the
service.
In
the
end,
the
service
is
just
another
10
code
inside
the
platform.
C
If
this
is
the
case,
the
proxy
delegates,
the
call
from
the
user
to
the
specific
chaincode
with
all
the
attributes
and
and
specifying
the
level
of
access
that
the
that
the
user
has.
So
you
see
that
at
the
beginning,
this
just
was
a
way
of
having
authorization
and
access
policies
inside
fabric
in
a
dynamic
way.
But
then
we
started
like
growing
the
the
the
model
and
we
started
thinking.
Okay,
maybe
we
could
start
we,
because
we,
as
mandatory
mentioned
trust
os,
is
compatible.
C
C
So,
as
I
said,
we,
we
first
started
with
this
proxy
chain
code,
and
then
we
started
building
a
an
sdk
to
manage
all
the
identities,
all
the
ids
and
all
the
signatures
and
interactions
with
the
trust,
id
platforms,
either
fabric
or
any
other
any
other
network.
So
let's
go
to
the
repo
here.
You
have
the
hyperledgers
labs,
trust
id
repo
and
the
code
is
divided
in
two
main:
let's
call
them
sub
projects,
first
of
all
the
fabric
chain
code
and
the
sdk.
I
was
mentioning
here.
C
So
the
idea
is
that-
and
this
is
something
that
we're
starting
to
do
and
we're
open
to
contributions
is
to
the
same
way.
We
have
here
this
fabric
chain
code
to
have
a
an
ethereum
proxy
smart
contract.
This
is
the
one
that
we
see
more
straightforward
to
have
a
a
set
of
quota
state
and
flows
to
to
manage
just
idea,
identity
so
that
we
can
start
interoperating
with
a
single
identity
in
several
israel
private
networks
we
are.
We
are
mainly
focused
on
on
private
environments.
C
So,
let's
start
with
this
with
the
fabric
chain
code.
Here
in
the
in
the
fabric
channel,
you
will
have
like
the
implementation
of
all
the
parts
that
I've
explained
in
the
in
the
figure
you
have
the
the
proxy
you
have,
the
the
service
registry
and
gateway
the
same
for
the
ident
identity
registry
and
the
gateway,
and
here
in
the
model,
we
have
some
interesting
information
about
how
I
request
build
to
send
them
to
the
to
the
network.
C
C
C
But
here
it
would
be
like
here
we
opened
the
the
opportunity
to
create
new
policies
so
that
anyone
can
start,
including
policies
that
they
feel
are
useful.
Here,
as
I
said,
we
have
the
same
controller
policy
that
it
means
that
the
trust
anchor
for
the
service
is
the
same
trust
that
for
the
user
and
there's
this
fine
grain
policy.
That
is
more
a
unix-like
approach
in
which
here
we
have
a
get
registry
with
a
list
of
of
users,
and
each
user
has
an
actual
access
level.
C
C
So
imagine
that
you
want
to
deploy
your
or
trust
id
over
your
fabric
network
in
this
case.
So
the
first
thing
you
would
do
I
mean
here
we
have
all
the
all
the
all
the
the
operations
that
you
can
do
with
with
this
fabric
chain
code
and
also
a
maritere,
is
working
on
on
requesting
getting
started
so
that
you
can
follow
how
to
deploy
your
own
trust
id
in
your
fabric
platform
and
start
interacting
with
it
using
the
sdk.
C
So
here
in
the
initialization
of
the
chain
code,
one
of
the
things
that
you
would
have
to
to
set
is
the
trust
anchor
of
this
specific
trust
id
deployment.
Again.
Is
it's
a
way
of
having
like
a
super
admin
or
the
first
valid
identity
in
the
system?
That
would
be
the
one
responsible
for
generating
the
the
trust
anchor
tree.
Let's
say,
but
again,
we
are
starting
to
generalize
this
model
to
move
into
a
more
like
open
ecosystem,
a
more
dif
compatible
approach.
C
So
once
we
have
our
chenko
deployed,
the
kind
of
operations
that
we
can
do
with
these
senkos
are,
for
instance,
creating
a
self-identity
here.
What
we
will
do
is
we
create
with
the
sdk
keeper
a
dad,
and
we
will
register
into
the
platform
is
the
id
this
registration
would
be
without
a
trust
anchor
without
controller
so
that
anyone
could
come
afterwards.
A
trust
uncle
could
come
afterwards
and
and
and
verify
our
identity
and
set
and
and
become
the
trust
tanker
of
this
identity.
C
This
is
just
for
the
case
that
we
may
have
a
fabric
network
where
we
have
a
lot
of
public
services
where
we
don't
need
the
there
is
no
need
for
a
for
trust
tanker
for
identity.
So
in
order
for
users
to
be
able
to
freely
interact
with
the
system,
we
added
this
creates
an
identity
and
then
the
the
process
of
creating
or
or
becoming
the
trust,
anchor
or
identity.
C
In
the
case
that
we
want
a
more
like
fine-grained
access
with
access
rights
in
the
in
the
system,
we
have
a
typical
get
identity
to
see
all
if
specific
the
id
is
registered
in
the
in
the
system,
we
will
be
able
to
revoke
identities
and
the
same
or
or
analogously
with
with
services.
We
will
be
able
to
create
new
services
in
the
system,
update
the
the
access
policy
and
get
if,
if
an
identity
exists
in
the
in
the
system
and
finally,
this
invoke
operation.
C
This
invoke
function
that
what
it
does
is
what
I
mentioned
whenever
we
send
an
invoked
transaction
to
the
proxy,
the
proxy.
What
it
does
is:
first
authenticate
the
user
and
check
its
access
policies
and,
according
to
the
access
policies
and
the
if
the
user
is,
has
permissions
to
access
the
specific
chain
code.
It
delegates
a
call
or
it
delegates
the
transaction
and
routes,
the
transaction
to
the
specific
chain
code.
C
Apart
from
the
chain
code,
we
also
have
the
sdk.
So
just
to
give
you
a
bit
of
context,
we
started
with
the
10
code
and
the
10
code
started
like
solving
all
our
our
initial
problems,
with
with
identity
in
fabric
and
then
with
the
sdk
is
when
we
started
realizing
that
this
could
be
generalized
and
become
way
more
than
it
was
so
here
in
the
sdk.
C
You
will
see
many
of
the
things
that
are
starting
to
be
generalized
and
that
it's
easier
so
the
the
the
transition
and
the
migration
from
the
user-specific
use
case-specific
content.
We
were
moving
to
the
more
general
dia.
The
id
and
decentralized
identity
framework
is
in
the
sdk.
So
here
we
we,
we
very
in
mind
many
of
the
things
that
we
wanted
to
do
in
the
future.
C
Again.
Here
you
have
all
the
documentation.
We
will
grow
this
documentation
as
much
as
possible
around
the
sdk
if
you
want
to
start
playing
with
the
sdk
there's
an
npm
package
that
we
have
to
update
with
the
latest
version.
But
here
in
this
repository
and
then
in
this
mp
and
package,
you
will
have
the
the
latest
implementation
of
of
the
sdk.
C
C
First,
all
the
operation,
all
the
management
of
the
dids,
the
interaction
with
networks
and
interaction
with
key
stores
is
done
and
and
exposed
through
a
wallet.
So
the
first
thing
we
would
do
if
we
want
to
use
a
trust
id.
The
trusted
sdk
is
to
create
a
wallet,
the
wallet
abstracts,
the
operation
of
network
drivers
and
key
stores.
C
The
keystore
is
the
the
specific
storage
where
we
store
private
keys
and
use
to
manage
the
ids,
and
then
the
network
driver
is
the
drivers
that,
where
we
implement
the
communication
with
the
proxy
contract
in
either
of
the
platforms
we
want
to
interact
with.
So
here
you
have
an
explanation
of
all
the
parts
the
sdk
is
divided
on
and
I
will
go
directly
to
the
source
codes
to
to
show
you
a
few
things.
So
these
are
the
three
main
models
we
have
right
now
in
the
sdks.
C
I've
said
the
wallet
where
we
have
the
implementation
of
the
ids,
the
did
management
and
and
how
to
communicate
with
the
with
the
key
store
and
and
the
networks,
and
and
call
the
the
driver
for
the
network
in
order
to
interact
with
a
specific
blockchain
platform,
and
then
we
have
the
keystore.
As
I
said,
the
keystore
is
where
we
store
information
about
our
keys
and
the
custody
of
our
keys
right
right
now
we
have
three
main
keystores
implemented
in
the
trusted:
sdk
first
file
keystore,
it's
it's
pretty
similar
to
how
geth
manages
keys.
C
C
We
have
kister
because
one
of
the
things
for
our
so
there
are
a
lot
of
people
that
want
to
have
the
custody
of
their
own
keys
and
be
the
ones
managing
the
keys.
But
in
other
use
cases
we
face
the
the
issue
that
users
don't
want
to
have
the
responsibility
of
being
the
custodials
of
their
kids.
So
we
we
released
a
service
where
we
become
the
custodials
and
they
delegate
the
custody
of
their
keys
to
us.
C
C
There
is
a
funny
story
here
with
the
local
storage
kister,
because
at
the
beginning,
all
this
work
around
trust
id
and
the
sdk
was
done
for
back-end
technologies
and
when
we
moved
into
a
front-end
development.
What
we
realized
is
that
the
cryptographic
library
that
we
used
in
javascript
was
only
compatible
with
node
and
not
with
with
front
end
js.
So
we
had
to
refactor
completely
the
whole
code
of
the
cryptographic
primitive
that
we
used
so
that
we
used
crypto
js
and
in
that
way
we
were
compatible
with
node
and
front-end
javascript.
C
So
there
are
a
few
funny
stories
with
this
local
storage
kisser
that
it
seems
pretty
simple,
but
in
the
end
it
brought
a
lot
of
paint.
And
finally,
if
you
want
to
add
again,
you
want
to
contribute
and
add
your
own
compatibility
with
kister
this.
You
only
have
to
inherit
from
this
abstract
class
that
defines
the
simple
functions
or
the
minimum
functions
that
we
enforce
for
for
key
stores.
C
C
Sorry,
someone
has
the
mic
open
and
it
seems
funny
thanks
so
yeah
all
the
functions
that
that
we
would
have
to
to
implement
in
our
driver
in
order
to
to
be
compatible
with
all
the
structure
in
in
the
trusted
sdk
and
in
the
trust
interface.
We
will
have
all
the
the
operations
that
we
will
so
so
here
what
we
are
doing
is
the
the
functions
that
we
build
the
transaction
and
sign
the
transaction
that
we
will
send
to
the
proxy
chain
code
in
order
to
interact
with
the
platform.
C
So
here
we
will
have
what
what
I
mentioned
already
in
the
in
the
proxy
chain
code
like
create
self
identity,
create
a
new
service,
update
the
service
and
invoke
and
query
a
specific
service.
So
in
this
way,
with
the
sdk,
once
we
have
implemented
the
specific
driver,
we
as
we
will
see
in
a
moment
we
will
have
to
only
select
to
what
network
we
want
to
interact
with
and
use
this
abstract
class
to
communicate
with
it.
C
C
C
So
that's
why
this
sdk
wallet
instance,
but
I
mean
if
the
issues
are
open,
so
any
suggestion
feedback
that
you
may
have,
please
let
us
know,
and
we
can
start
having
it.
So.
The
first
thing
that,
as
I
said,
the
first
thing
that
you
do
is
to
create
the
instance
of
a
wallet.
You
choose
the
specific
key
store
you
want
to
to
use
in
your
wallet.
C
In
my
case,
I'm
going
to
use
a
file
pistor
and
we
set
the
keystore
and
then
the
next
thing
that
we
have
to
do
is
to,
in
my
case
we
only
have
fabric
right
now
and
compatible
with
trust
id
and
the
driver.
Our
current
driver
of
fabric,
because
at
the
beginning,
in
the
implementation
of
trust
id,
we
had
a
like
a
gateway
between
the
a
gateway
api
between
the
peer
and
the
and
the
sdk
as
a
way
of
of
of
not
exposing
the
specific
peer
to
the
network.
C
Then
we
changed
this
because
we
didn't
want
to
have
first,
it
wasn't
like
pretty
standard
to
have
a
gateway
for
everyone
that
wanted
to
use
a
fabric
with
trusted,
and
then
we
felt
that,
in
order
to
decentralize
as
much
as
possible
the
model
we
had
to
open
at
least
one
of
our
peers
to
allow
the
connection
to
it
from
our
clients.
So
what
we're
doing
right
now,
in
our
case
with
our
fabric
deployments,
is
each
client
may
have
their
own
peer
in
our
infrastructure.
C
So
we
give
them
the
connection
profile
and
this
configuration
to
them
so
that
they
have
a
way
of
connecting
directly
to
their
peers
and
interacting
with
using
trustee
with
their
peers.
So
with
the
with
this,
what
I'm
I'm
trying
to
explain
is
that
in
our
driver
right
now,
what
we
need
to
authenticate
to
and
communicate
with
fabric
is
to
have
a
correct.
This
is
the
the
standard
structure
of
a
fabric
connection
profile
and
this
config
that
points
to
this
connection
profile
with
information
about
the
the
crypto
material
to
interact
with
the
peer.
C
So
once
we
have
the
keystore,
we
have
all
this
information
for
the
network.
We
create
a
new
trust,
id
hf
driver
and
we
add
the
network
to
our
wallet
and
with
this.
What
we
have
right
now
is
a
file
key,
a
wallet
that
abstracts
the
file
keystore
and
the
the
driver
and
has
configured
a
driver
to
a
to
hyperledger
fabric.
C
Again,
if
we
want
to
in
the
future,
when
we
have
other
networks
here,
it
would
be
as
easy
as
having
the
same
configuration.
Probably
in
ethereum
is
way
easier
to
configure
the
communication
to
to
appear
because
it's
only
an
end
point
and
we
will
set
like
similar
to
web3
the
the
specific
endpoint
for
the
node
and
then
add
the
network
to
the
wallet
so
that
we
can
start
interacting
with
it
using
our
trust
id
wallet.
C
C
C
C
They
have
different
implementations
in
the
crypto
library
for
go
in
the
chain
code
and
here
in
the
sdk,
so
there
are
sometimes
certain
incompatibilities.
So
with
this
I
mean
you
can
even
use,
apart
from
electric
curves,
any
ed
curve,
but
you
may
have
problems
when
interacting
with
the
fabric
chamber.
Just
let
you
know
if
you
face
this
problem,
please
let
us
know
in
the
issues,
because
we
are
trying
to
replicate
it
after
our
factor
we
made
and
we
didn't
manage
to
do
it.
C
So,
please,
let
us
know
if
you,
if
you
find
this
issue
again
so
here
what
we
will
do
is
generate
id
id
this
function.
What
it
does
is,
it
generates
a
a
pair
of
keys,
rsa
keys
with
a
pass
rate
encrypted
and
the
private
key
with
a
passphrase
that
is
test
and
using
a
controller
that
is
test.
So
here
our
trust
anchor
would
be
an
identity
test
here
you
would
have
to
put
any
other
identity
that
you
want
to
be
your
trust
anchor.
C
So
in
that
way
we
generate
the
keeper
locally
and
we
can
create
the
self
identity
and
register
it
to
the
trust
id
platform
here.
So
we
only
we
take
the
wallet
we
we
choose
the
network
where
we
want
to
register
the
self
identity
in
this
case
is
hf
and
we
create
the
self
identity
and
under
the
hood,
this
function.
What
he's
doing
is
signing
a
transaction
and
sending
a
request
to
the
proxy
chain
code
with
our
the
id
with
our
keeper,
like
for
the
private
key
of
the
id
that
we
just
generated.
C
It's
it
sends
the
information
to
the
proxy
contract.
The
past
your
contract
verifies
that
you
are
the
the
the
owner
of
the
public.
You
want
to
register
and
it
registers
in
the
in
the
the
id
registry
and
what
we're
going
to
do
afterwards.
So
we
will
create
a
self
identity
and
get
the
identities
to
see
that
the
identity
was
correctly
registered
in
the
translated
platform.
So,
let's
see
how
this
would.
C
C
We're
configuring
the
network
driver
here,
you
see,
we
generated
the
the
id
here
are
all
the
algo
types
the
crypto
configured
the
d80
is
generated,
so
this
is
something
again
that
we
are
starting
to
standardize.
This
is
the
the
structure
of
the
ids
identities.
I
mean
unique
identifiers
that
we
used
where
here.
This
is
the
hash
of
the
public
key.
C
We
are
starting
to
check
how
in
the
dif
and
under
these
projects,
they
are
doing
this
to
to
be
as
compatible
with
them
as
as
possible,
so
that
we
could
have
interested
the
identities
or
the
ids
generated
in
other
in
other
identity
solutions,
and
here
the
private
key
that
is
encrypted
with
with
the
passphrase
that
we
that
we
defined,
then
we
register
the
self
identity
and
then,
when
we
get
the
registered
entity.
This
is
the
information
that
is
stored
in
the
id
registry
in
the
proxy
chain
code
on
chain.
C
So
this
information
is
already
unchained.
So
in
this
way
we
create
a
idea
id
and
we
would
register
it
in
the
in
the
infrastructure.
How
can
we
interact
with
with
services?
In
this
case,
we
are
going
to
so
we
also-
I
have
some
some
we'll
see
this
in
a
moment,
we
added
in
the
wallet
some
convenient
functions
to
add,
for
instance,
I
default
the
id
so
that,
instead
of
having
to
choose
every
time
what
the
id
in
my
keystroke
I
want
to,
I
want
to
use
I
use
by
default
the
default
one.
C
C
C
So
this
is
our
trustos
platform,
where
we
have
all
of
the
apis
of
the
trustos
product.
The
one
I'm
going
to
use
right
now
is
the
track
api.
This
is
a
simple
api
that
allows
you
to
create
new
digital
assets
in
in
fabric,
so
create
digital
assets
in
its
encoding
fabric
and
then
update
them
and
and
transfer
their
ownership
to
to
follow
all
the
life
cycle
of
of
a
digital
asset
in
the
blockchain.
So
what
we're
gonna
do
in
our
example
is
to
first
see
if
that
service.
C
C
So
that's
why
we
put
here
the
the
channel
where
the
chain
code
leaves,
because
one
of
the
problems
we
faced
is
that
if
we
have
a
general
purpose
fabric
network,
you
have
maybe
a
channel
between
only
three
of
the
organizations
and
there's
a
chain
code,
a
public
chenko
that
wants
to
be
used
by
a
fourth
organization
that
is
not
in
that
channel.
In
this
case,
it's
I
mean
there
is
not
an
easy
way
without
giving
a
a
specific
identity
from
one
of
the
existing
organizations
in
the
channel.
C
There
is
not
an
easy
way
of
doing
this,
but
with
this
proxy
contract,
the
proxy
contract
is
able
to
delegate
calls
authors,
authorize
user,
any
user
even
from
modern
organization
and
delegate
calls
to
chain
codes
in
another
channel.
So
that's
why
also
it's
pretty
useful
to
use
trust
id
in
this
case.
C
C
I
mean
here
we're
just
repeating
the
the
generation
of
the
id,
the
the
registration,
the
successful
registration.
Here
we
are
getting
the
the
information
about
the
service,
so
we
see
who's
the
controller
of
the
service
and
the
access
policy.
That,
in
this
case,
is
public
the
channel
where
it
leaves
when,
with
this
information,
we
are
able
to
call
it
as
we
saw
above
and
we're
getting
this
new
asset.
C
This
is
the
hash
of
the
assets,
the
data-
and
this
is
information
that
we
had
in
this
trust
id
sorry
the
track
api
that
we
have
interest
to
us
and
if
we
get
the
asset,
we
see
that
indeed
the
the
asset
was
created
successfully
and
we
get
the
information.
So
so
is
this
simple
I
mean
and
the
same
way
we
could
in
this
way
we
could
interact
with
a
service
living
in
in
hf
and
also
we
had
again
or
any
other
network.
C
We
would
interact
in
the
same
way
without
having
to
worry
of
the
specifics
of
the
implementation
of
the
identity
or
the
key
players
used
to
sign
transactions,
because
is
the
driver,
the
one
that
worries
about
how
to
do
all
this
process?
And
finally,
once
we
have
this,
we
also
add
some
off-chain
functionalities
in
the
wallet
in
case
someone
wants
to
use
their
identity
to
sign,
payloads
off
chain
and
exchange
them
with
other
users
in
the
platform.
This
is
really
interesting
because
this
will
allow
us
to
so.
A
See
while
you're
compiling
the
next
step,
just
a
heads
up
we'll
start
the
q
a
at
6
00
pm
605.
Maybe
if
you
still
have
a
need
a
few
minutes,
because
we
have
quite
a
few
questions
actually
both
on
the
youtube
stream
streaming
and
in
the
chat
channel
and
I'll.
Read
the
questions
out
loud
and
I'll.
Do
let
you
and
maria
answer
them.
C
Perfect,
I'm
almost
done
so.
This
is
the
last
thing
I
wanted
to
shows.
So
we
are
almost
done
wait
I
mean
I
didn't
save
the
yeah,
but
in
the
end
I
mean
we
can
move
to
the
q
a
because
here
it's
you'll
see
that
the
only
thing
I'm
doing
is
signing
the
payload
and
verifying
the
payload,
with
directly
from
the
wallet
and
from
the
jd
in
the
wallet.
So
it's
pretty
straightforward,
yeah,
so
here
you'll
see
that
we're
sending
signing
this
specific
payload.
This
is
the
signature
we
validate
successfully
the
signature.
C
We
get
the
payload
and
if
we
use
the
other
gid,
we
get
an
error.
This
is
something
that
we
are
also
working
on,
that
is
to
try
and
and
make
like
better
the
ux
in
the
of
the
sdk,
because
the
error
management
and
and
how
we
interact
with
certain
things,
are
really
useful
for
us
internally,
but
I
feel
that
they're
not
as
general
as
us
as
we
wish
so
and
finally,
if
you
allow
me
like
three
more
minutes
just
to
give
you
an
overview
of
what
are
our
next
steps?
C
We've
I've
mentioned
all
of
them,
but
just
to
recap
on
what
are
our
next
steps
with
trust
id?
Our
main
focus?
The
next
few
months
is
to
better
the
the
developers
ux
with
our
sdk
and
try
to
decentralize
and
generalize
the
model,
because
we
are
aware
that,
because
of
how
the
the
project
was
born,
we
are
really
focused
on
fabric,
and
we
don't
want
it
to
be
this
way.
So
we
want
to
start
to
add
adding
compatibility
with
best
recorder
and
ethereum
start
implementing
event
listeners
in
the
sdk.
C
That
is
something
that
we've
started
already
and
compatibility
with
other
key
stores.
We
want
to
start
migrating
other
concepts
from
decentralized
identities
like
verifying
credential
trust
anchors
to
be
compatible
with
the
dif
start
push
so
the
standards
produced
by
the
dif.
And
finally,
we
want
we've
seen
I
mean.
Actually,
we've
talked
to
many
of
the
guys
in
in
india
in
trustblock
in
newport,
and
we
want
to
see
how
they
feel
trust
id
could
help
them
or
be
maybe
an
aggregator
of
all
these
solutions.
C
A
Welcome,
thank
you
alfonso,
thank
you
maria,
so
now
we're
going
to
be
doing
the
the
questions
and
answers,
and
so
the
the
general
idea
is
that
I
have
a
bunch
of
questions
that
are
both
in
the
youtube
chat
and
the
and
the
zoom
chat.
So,
first
of
all
we'll
answer
these
questions,
and
once
we've
done
all
of
these,
if
we
still
have
time,
then
we
can
open
up
the
microphone
or,
if
you
have
more
questions,
you
can
add
them
as
well
in
the
general
chat.
B
B
C
So,
if
I
may
add,
we
are
so
what
we
want
to
do
is
to
be
an
aggregator
of
all
these
solutions.
Not
I
mean
the
work
being
done.
There
is
awesome
related
to
the
centralized
identity
so,
but
we
feel
that
if
you
want
to
use
arias,
you
have
to
use
your
own
sdk.
If
you
want
to
implement
ursa
crypto
you
have
to
use.
C
Actually,
we
we're
we're
really
eager
to
start
integrating
it
in
in
our
solution,
because
I
mean
and
one
of
the
things
as
I've
mentioned,
we
are
our
first
priority
right
now
is
verified
credentials
to
have
a
more
extend
access,
policy,
management
and
identity.
So
more
rich
identities
and
the
way
of
of
doing
this,
we
are
considering
using
directly
the
verified
credentials
and
and
the
functionalities
offered
by
by
ending.
A
B
B
So
the
decision
of
who
is
going,
the
physical
entity
or
identity
that
is
going
to
to
have
a
controller
type
identity
is
a
thing
that
we
have
to
decide.
But
the
idea
is,
for
example,
that
if
we
create
a
a
ecosystem,
a
blockchain
approved,
blockchain
ecosystem
with
a
companies
or
a
consortium
or
etc.
The
controllers
are
going
to
be
the
the
principal
entities
of
of
that.
C
C
The
issuer
of
the
identifier
yeah
yeah,
so
that's
a
really
good
question.
We
are
generating
it.
There's
no
issue
here,
okay,
so
this
is
why
I
mentioned
when
we
saw
the
identifier.
This
is
like
ethereum,
like
it's
a
hash
of
the
public
key
and
we
are
not
following
the
did
standard
right
now.
Okay,
this
is
something
that's
why
one
once
we
move
with
the
verified
credentials
and
the
ids
we
want
to
mix
and
generate
more
standard
identifiers.
A
Okay,
super
thanks
one
more
question,
so
I
this
is
all
the
questions
we
have
on
youtube.
So
if
people
listening
to
youtube,
have
more
questions
feel
free
to
add
them
in
the
youtube
chat,
I'm
going
to
now
switch
only
to
well
unless
there
are
new
questions
on
youtube
to
the
next
question
in
the
zoom
chat
is
the
interoperability
with
other
blockchain
technologies,
one
way,
eg
reusing
a
bitcoin
key
for
signing
fabric
transactions,
or
does
it
integrate
multiple
blockchain
technologies,
one
way
or
both
ways.
C
So
the
idea
is
pose
so
once
we,
the
idea
with
stress
id,
is
that
once
we
generate
imagine
that
I
have
my
bitcoin
keys
as
the
proxy
contract.
So
it's
not
the
platform
authenticating
the
user
through
the
transaction,
but
is
the
chance
of
the
one
authenticated
user.
So
as
long
as
the
chain
code
understands
the
cryptography
used
to
sign
the
the
the
request,
it
should
be
able
to
be
compatible
with
any
with
any
with
any
platform.
C
So
one
of
the
tests
that
we
did
is
to
take
that
that
that
is
why
I
mentioned
the
ethereum
keys.
We
took
the
ethereum
address
that
we
had
with
the
keypair
we
we
imported
into,
because
we
also
have
some
import
and
export
functionalities
in
in
trusted
that
we
have
to
to
find
him.
But
we
import
the
the
ethereum
key
into
a
trust
id
id
and
we
made
a
call
in
fabric
using
the
address.
C
So
we
registered
the
the
id
in
interested
in
with
fabric
and
we
managed
to
do
a
service
invoke
using
the
ethereum
keys,
so
sign
in
with
trusted
ethereum
using
the
ethereum
keys
and
calling
the
the
service
in
fabric.
So
this
is
something
that
we
have
in
mind.
This
is
the
the
we
I
mean.
Our
view
would
be
like
one
single
key
should
be
able
to
be
used
in
any
platform,
but
we'll
see
where
we
end
up,
because
there
are
things
that
have
to
be
fixed,
especially
at
a
platform
and
an
underlying
level.
A
Okay
super.
Thank
you
one
more
question
here
that
was
asked.
While
you
were
doing
the
demo,
somebody
asked
if
jefferson
asked
if
there
is
a
github
url,
where
you
can
find
the
sample
code
and
if
you
want
to
write
it
in
the
chat
window
in
the
public
chat,
make
sure
you
write
it
publicly
that
way.
People
can.
You
know.
C
A
B
C
Marital
is
working
on
getting
started
to
ease
the
the
deployment
and
the
use
of
the
of
the
system,
and
I
will
add
an
example
directory
so
that
we
can
start
having
some
simple
examples
that
you
can
like
directly.
Once
you
have
deployed
your
chenko,
you
can
directly
use
and
and
start
playing
with
the
solution.
B
Okay,
this
is
a
very
good
question
in
this
case.
As
I
was
saying
in
the
in
the
beginning
of
of
the
presentation,
when
you
are
creating
an
identity
from
a
ca,
this
identity
is
a
dependent
only
from
a
ca.
You
can
use
in
high
player
fabric
the
the
certificate
revocation
list
and
have
more
control
about
what
identities
issued
by
other
organizations
are
valid
or
not.
However,
we
want
to
to
go
more
step,
a
step
forward
and
and
to
create
a
an
identity
that
could
be
verified
by
by
more
than
one
identity.
A
Okay,
thank
you.
So
this
is
the
end
of
all
the
questions
that
were
written.
We
still
have
a
bit
of
time,
so
I
have
two
options:
either
alfonso
and
or
maria.
You
have
other
things
you'd
like
to
talk
about
on
this
subject,
or
we
can
do
something
a
little
creative
and
unmute
everybody
and
sort
of
turn
this
into
a
discussion,
and
if
it
gets
too
hectic
I'll,
remute
everybody
and
then
we
can
go
one
by
one.
A
C
I
didn't
quite
get
the
actual
desire
for
reusing
the
keys.
To
be
honest
because
from
the
initial
presentation,
I
understood
that
now
we
have
a
high
complexity
with
a
lot
of
key
pairs
that
have
to
be
managed
in
wallets.
So
it's
the
main
contribution
to
integrate
all
the
different
key
mechanisms
and
cryptography
into
a
single
wallet,
or
is
it
more
about
the
reusing
keys
on
the
on
on
different
ledgers?
C
That's
a
really
good
question.
I
the
so
the
second
one.
What
we
want
to
try
and
do
is
to
have
like
the
same.
So
instead
of
you
having
to
have
several,
I
don't
you
can
do
it,
but
instead
of
having
to
have
several
identities
in
different
networks
and
with
specific
cryptography
to
be
able
to
have
a
single
key
with
this
cryptography
of
your
of
your
choice
and
be
able
still
to
interact
with
any
platform.
C
Yeah
yeah,
I
totally
agree,
that's
why
I
mentioned
several
times
that
we're
in
the
corporate
environment,
because,
for
instance,
imagine
that
we
have
a
supply
chain
and
I'm
a
pro
I'm
one
of
the
of
the
actors
in
this
supply
chain.
But
I
also
interact
with
several
other
supply
chain
solutions.
So
I
may
be
the
provider
for
I'm
a
logistics
company
that
I
give
service
to
a
telco
company
and
to
a
retailer
company.
C
They
probably
will
have
their
own
implementation
or
post-invest
implementation
of
their
supply
chain
to
have
and
track
all
the
for
the
life
cycle
of
their
of
their
assets.
And
what
happens
now
is
that
if
one
of
the
solution
is
in
coda
and
the
other
one
is
in
fabric,
I
have
to
worry
about
implementing
my
back
ends
and
my
wallets
with
fabric
and
with
corda.
C
Have
the
keys
manage
the
keys,
have
the
custodial
so
so,
there's
not
a
seamless
way
of
having
a
single
identity
and
be
able
to
interact
with
several
of
the
systems
that
potentially
will
appear
and
also
in
the
corporate.
So,
in
a
public
context,
blockchain
context,
the
platforms
are
really
general
purpose,
but
usually
what
it
happens
in
the
corporate
and
the
private
technologies.
C
A
B
So,
in
this
case
we
we
started
to
think
about.
How
can
we
only
use
one
identity
right
now?
There
is
no
solution
in
the
market
that
is
implementing
this
type
of
things.
Interoperability
in
blockchain
is
the
future,
but
there
are
there
are
projects,
but
these
projects
are
are
growing
up
and
are
like.
Babies
are
in
the
in
the
first
steps.
So
that's
why
we
started
hyper
a
trust
id,
but
we
don't
think
that
high
player
fabric
is
is
but
furthermore,
a
you're
doing
high
player
fabric.
B
C
And
now
I'm
going
to
add
my
personal
view:
fabric
identity
lacks
flexibility,
and
this
is
a
reality.
So,
whenever
and
that's
why
I
mentioned
like
the
the
I
think
that
fabric
is,
is
prepared
to
have
really
static
concerns
with
you
and
use
case-specific
networks
and
the
moment
you
want
to
move
into
a
general-purpose
environment,
it
lacks
flexibility
and
decentralization
because
of
the
ci
approach
that
they
follow.
So
these
sits
in
our
case.
Initially.
This
was
an
attempt
of
trying
to
add
flexibility
to
the
identity
management
in
in
public.
A
C
I
will
say
yes,
but
we
haven't
tried
it
it.
I
think,
there's
a
lot
of
work
to
be
done
before
it
is
ready.
It
would
be
great
because
you
will
do
kyc
once
and
be
able
to
use
it
for
several
platforms,
several
use
cases.
That's
the
idea,
that's
one
of
the
ideas,
but
there's
a
lot
of
work
to
be
done.
For
this
to
be
ready.
I
feel.
C
B
C
Yeah,
it's
the
so
the
connection
profile
you
will
have
the
connection
profile
is
like
the
your
ticket
to
the
pier
and
that's
the
the
one
that
signs
the
fabric
transaction.
So
everyone
I
mean,
that's
why
I
said
that
that
we
would
offer
a
connection
with
the
specific
fear
of
our
clients.
It's
the
way
of
permissioning
him
to
to
send
requests
to
the
infrastructure.
A
B
Well
in
in
this
case,
trust
id
is
built
on
the
top
of
high
player
fabric
at
the
end,
if
going,
if
we
are
going
deeper
with
the
implementation
of
high
player
fabric
at
the
end,
we
are
going
to
have
an
identity
issued
by
high
player
fabric,
and
we
are
going
to
in
our
case
we
are
using
always
the
same
identity.
So
at
the
end,
at
high
player
fabric
level,
the
the
transaction,
all
the
transaction
are
signed
with
this
identity
from
the
this
m.
B
So
the
logic
that
we
have
implemented
is
implemented
on
the
on
the
single
part.
So
we
are
signing
the
transaction
in
the
client
and
then
we
are
verifying
everything
in
the
in
the
chain
code.
But
at
the
end
it's
a
standard,
high
player
fabric
application,
so
trust
id
right
now
is
built
on
the
top.
It
would
be
a
really
really
cool
if,
if
in
in
the
future,
a
trust
id
could
be
implemented
in
a
as
a
native
way
in
hyperlayer
fabric,
but
right
now
it's
built
on
top
of
us
as
a
solar.
A
Application,
okay,
every
time,
I'm
about
to
say
we
finished
with
all
the
questions.
Somebody
pops
up
a
new
one.
So
here
is
your
chance
to
pop
up
a
new
question
before
before
we
actually
close
this
this
video
conference,
I
okay
so
a
question
on
youtube.
I
am
doing
a
thesis
about
blockchain
and
identity
management
and
I
want
to
know
if
you
can
share
your
linkedin
to
change
somebody
to
exchange
some
ideas.
A
C
B
A
A
Okay,
if
we
have
five
more
minutes,
if
there
are
no
more
questions.
I'll
take
a
second
just
to
talk
a
bit
about
a
hyperledger
geneva,
meetups
it
started
and-
and
while
I
talked,
we
have
an
option
for
people
to
write
an
additional
question,
but
it
started
about
a
year
ago
and
it's
a
very
occasional
type
of
meetings.
A
A
A
All
right,
so
I
want
to
thank
everybody
who
attended
this
session,
in
particular
the
people
who
asked
questions
and,
more
so
alfonzo
and
maria,
for
having
answered
for
having
answered
the
the
questions.
The
numerous
questions
presented,
what
you
guys
are
doing.
I
I
get
from
the
interest
and
the
questions
that
it
was
interesting.
So
thank
you
very
much
for
for
being
here
today.