►
Description
A recording of a workshop run by Indicio on January 20, 2022. This is a four hour online course to introduce the core concepts and principles of decentralized identity. As you progress, you’ll learn how to use the SelfServe and indyscan network tools, be introduced to the Indy Command Line Interface (Indy CLI) and install and run the Aries toolbox to create, issue, and verify a verifiable credential.
More about the workshop is at:
https://wiki.hyperledger.org/display/events/Build+Your+Identity+Solution+Using+Hyperledger+Aries
If you'd like to go through the workshop following the video, there is a companion document with details you will need at:
https://wiki.hyperledger.org/display/events/Hyperledger+Aries+Workshop+-+Handout
And if you have any questions about the workshop or about Hyperledger Aries, feel free to join the #aries channel and ask questions there: https://discord.gg/hyperledger
----
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 #Blockchain
A
All
right
awesome:
well,
we
are
really
excited
to
be
doing
this
workshop
today.
Thank
you.
Everyone,
who's
able
to
join
us.
This
workshop
is
titled,
build
your
identity
solution
using
hyper
ledger
aries.
We're
excited
to
have
a
great
group
of
moderators
and
instructors.
Today
we
are
excited
to
you
know,
talk
about
the
hyperledger
projects
that
have
made
production
level,
decentralized,
identity,
solutions
possible
in
various
use
cases
across
the
globe
for
introduction.
A
A
The
work
that
the
open
source
community
is
doing
with
these
projects
is
playing
an
important
role
as
more
and
more
enterprises
and
governments
move
towards
decentralized
identity
models,
and
today,
we're
lucky
to
be
joined
by
some
of
the
world's
leading
digital
identity.
Engineers
who
specialize
in
these
protocols
and
you'll
get
a
firsthand
walkthrough
on
how
you
can
use
these
tools
to
build
your
own
decentralize
at
any
solutions.
A
As
mentioned
a
few
minutes
ago,
in
terms
of
technical
support
and
questions
you
have
throughout
the
workshop,
you
can
drop
your
questions
in
the
aries
channel
on
the
hyperledger
chat.
I
think
it
was
previously
called
the
hyperledger
rocket
chat
drop
your
questions
there.
We
have
multiple
and
dcot
members
who
are
watching
the
channels
there
and
we'll
get
to
you
as
soon
as
possible.
B
Thank
you,
james,
a
great
preamble
there
to
get
a
setup
for
for
a
really
productive
and
good
day
of
education
and
discussion.
My
portion
of
the
program
here
is
called
what
is
decentralized
identity,
it's
sort
of
a.
Why
are
we
here
doing
this
in
the
very
big
picture?
Sense
for
those
of
you
that
are
maybe
newer
to
the
space?
This
should
provide
the
sort
of
philosophical
groundwork
that
says.
Why
does
this
technology
even
exist?
B
Why
was
it
created
and
and
what
are
the
values
that
are
going
to
be
derived
from
it?
If
you've
been
in
the
space
or
circling
around
it
a
little
bit
longer,
it
may
be
a
bit
of
a
review,
but
I
think
it's
good
to
have
a
a
leveling
of
the
playing
field
here
before
lynn
and
daniel
star
and
sam
get
into
the
the
technical
content.
So
it'll
give
some
context
to
everything
that
they're
saying
and
talking
about
today.
B
My
name
is
scott
harris,
I'm
the
vp
of
business
operations
at
indicio.
I
wear
a
lot
of
hats,
my
as
you
can
see
by
my
profile
picture,
I'm
probably
the
kind
of
guy
that
likes
hats.
One
of
my
roles,
in
addition
to
helping
in
dco
work
effectively
internally,
both
between
our
work
groups
and
with
our
clients,
is
to
do
some
problem
solving
in
the
use
case
side
of
things.
B
B
Why
are
we
here
the
internet
and
identity?
This
is
a
very
old
cartoon,
I
think
from
the
new
yorker
a
long
time
ago,
and
it's
still
applicable
today
and
the
truth
is
the
internet
was
created
without
a
way
of
identifying
who's
on
the
other
side
of
that
computer
or
that
device,
and
in
some
cases
in
many
cases
anonymity
is
desirable.
B
The
main
reason
we
have
identity
systems
at
all,
usernames
passwords
things
like
that
is
to
establish
some
sort
of
trust.
The
trust
that
we
establish,
however,
only
goes
as
far
as
the
work
that's
put
in
at
the
entry
point
to
that
trusted
ecosystem.
So
if
we
have
a
linkedin
account
and
you've
signed
up
with
an
email,
well,
anybody
can
sign
up
with
an
email
and
pretend
to
be
anybody
else.
They
want,
if
you
say,
okay,
I'm
using
my
email
to
sign
up
for
linkedin
for
my
gmail
account.
B
The
question
I
would
ask
is:
what
did
you
do
to
get
that
gmail
address?
And
the
answer,
of
course,
is
absolutely
nothing
if
you're
like
me,
you
probably
have
10
to
15
email
addresses
floating
around
for
various
purposes
and
again
that
can
be
great
to
help
preserve
some
of
your
privacy
and
protect
some
of
your
information.
But
when
it
comes
to
identifying
who
you
are
some
attribute
about
yourself,
it's
very
untrustworthy
and
not
useful.
B
So
we
need
something
better
to
talk
a
bit
about
our
terminology.
We've
already
said
the
word:
identity,
probably
20,
to
30
times
today.
So
I
think
it's
worth
looking
at
what
we
mean
by
the
word
identity.
It
comes
from
a
lot
of
different
sources.
This
is
sort
of
how
the
world
looks
today
that
your
identity
comes
from
a
a
pie,
if
you
will,
where
a
portion
of
it
is,
is
generated
and
often
held
by
these
entities
that
give
you
some
some
of
this
identity.
B
What
we
really
mean
by
the
word
identity
goes
beyond
what
your
common
definition
might
be,
which
would
be
your
name.
Your
address
your
date
of
birth,
eye,
color
height
weight,
those
sorts
of
things
to
broaden
out
to
be
defined
as
a
set
of
data
that
refers
to
a
particular
data
subject.
So
a
little
bit
that
of
that
is
gdpr
language.
B
The
data
subject,
but
we'll
talk
or
or
the
rest
of
our
group
we'll
talk
today
quite
a
bit
about
an
identity
holder
as
a
data
subject,
and
and
refer
to
that
as
a
person,
but
it
doesn't
have
to
be
a
person
when
you
think
about
it.
Devices
and
iot
things
have
identities
that
are
issued
to
them.
Business
enterprises
have
identities
of
their
own,
so
everything
that
has
any
digital
footprint
has
an
identity
in
that
regard,
and
it
doesn't
necessarily
need
to
be
the
traditional
definition
of
identity.
B
The
problem
with
identity
right
now
is
that
it's
largely
centralized
and
what
we
mean
by
centralized
is
that
data
is
controlled
and
shared
and
handled
primarily
by
third
parties.
Your
digital
identity
is
very
difficult
to
control.
Of
course,
we
know
everywhere
you
go
digitally,
there's
data
that
follows
you,
along
that
you
generate
by
virtue
of
a
relationship
and
that
data
is
not
within
your
control
and
we
can't
completely
solve
for
that.
But
we
can
solve
for
some
of
the
problems
that
are
derived
from
that
and
those
problems
are
consent
and
compliance
and
transparency.
B
Decentralization
looks
a
bit
more
like
this
and
it's
an
oversimplification
really
of
what
we
mean
by
this
decentralization.
But
I
think
that's
a
good
thing,
because
a
nice,
simple
picture
helps
us
wrap
our
heads
around
what
we're,
after
the
decentralization
breaks
apart
those
relationships
but
puts
the
identity
holder,
in
this
case
a
person
at
the
center
of
things
and
there's
a
bit
of
contradictory
language
there,
where
we,
we
think
of
a
person
at
the
center
of
their
identity,
but
call
it
decentralization.
B
So,
of
course,
we
mean
decentralization
and
the
the
with
the
technical
definition,
but
when
we
break
apart
those
relationships
and
and
keep
those
entities
from
sharing
data
behind
our
back
without
our
consent,
it
may
or
may
not
be
a
good
thing.
In
some
cases
it
may
we
may
give
up
some
efficiencies
in
order
to
maintain
privacy
and,
of
course,
privacy,
protection
and
and
efficiency
are
two
of
the
things
we're
after.
But
this
picture
here
with
the
pie
piece
is
broken
apart.
B
B
You
know
website
and
your
hr
portal
and
and
downloading
a
tax
record
or
a
pay
stub
from
your
employer
that
pay
stub
constitutes
part
of
your
identity
that
was
given
to
you
by
your
employer
and
if
you
go
to
apply
for
a
mortgage,
you
would
download
that
and
you
would
send
it
out
to
the
mortgage
company.
So
in
the
old
world,
the
analog
world,
you
would
probably
print
it
out
and
then
mail
it
to
them
and
now
we're
trying
to
do
it
digitally.
B
So
our
goal
here
is
to
create
a
digital
model
of
the
analog
world,
where
you
have
some
control
of
that.
Imagine
walking
in
with
your
driver's
license
here
to
buy
an
age,
restricted
item
and
you
don't
hand
them
your
driver's
license
and
let
them
make
a
copy
of
it
and
say:
hey.
Take
it,
keep
it
do
whatever
you
want
with
it,
don't
worry
about
it,
but
in
the
digital
world
that
is
effectively
what
we're
doing
with
our
with
our
complete
footprint
as
we
go
about
our
interactions
and
and
our
online
relationships.
B
C
B
Come
from
and
where
we
are
now
and
where
we're
headed
in
the
analog
world
that
I'm
speaking
of
and
I'll
throw
some
dates
out
there
of
about
3200
bc
when
the
first
writing
was
recorded,
that
we
know
of
to
roughly
1964,
we
had
a
system
where
it
was
really
easy
to
trust
physical
documents,
because
they
had
some
indicator
visual
or
tactile
of
whether
a
document
was
authentic.
So
we
have
notary,
stamps
and
raised
seals
and
special
paper
and
envelopes
that
are
sealed
or
wax
on
them
registered
mail.
B
We
have
a
lot
of
ways
when
you
receive
a
physical
document
of
saying:
hey.
Is
this
authentic?
Do
I
know
where
it
came
from?
Can
I
trust
it?
But
of
course
that's
really
inefficient
and
we
don't
like
inefficiency
here
in
our
modern
digital
world
with
that
we
also
had
a
lot
of
privacy
and
control,
so
so
not
the
greatest
system
in
our
hybrid
world,
the
one
we're
kind
of
living
in
today,
we've
sacrificed
quite
a
bit
of
trust
to
gain
a
little
bit
of
efficiency.
B
So
now,
what
we're
doing
with
those
physical
documents
is
we're
snapping,
a
picture
of
them
with
our
phone
and
now
we're
sending
a
jpeg
instead
of
the
real
document
or
we're
scanning
something
faxing,
something
and
and
we're
gaining
some
efficiency.
But,
of
course,
what
we're
really
sending
along
to
that
next
party.
It's
just
a
digital
representation
of
the
document
and
not
the
document
itself,
and
it's
it's
not
trustworthy
and,
of
course,
as
I
described
once
it's
given
over
our
ability
to
control
it
is
minimal.
So
we
sacrifice
quite
a
bit
of
privacy
there.
B
B
So
in
the
decentralized
world,
as
we
build
out
some
of
these
tools
that
you're
going
to
see
and
hear
and
learn
about
today,
we
should
be
able
to
gain
back
almost
all
of
that
trust
and
all
of
the
efficiency
and
maintain
our
privacy.
So
why
does
that
analog
model
work?
Well,
as
I
said,
we
have
ways
of
verifying
what
what
attributes
come
to
you,
if
you're
the
one
receiving
some
information
and
it
works,
because
the
person
receiving
it
has
visual
and
tactile
ways
of
determining
whether
that
driver's
license
is
real.
B
There's
a
hologram
and
it's
fully
laminated
and
you
haven't
cut
into
it
with
an
exacto
knife
that
sort
of
thing
and
right
now
the
representations
that
we
send,
along
as
representations
of
an
identity
piece,
of
course,
have
those
risks
and
costs
associated
with
it.
And
that's
a
big
reason
why
we're
here
today
is
that
the
business
world
has
recognized
that
there's
a
massive
cost
to
fraud
to
to
losses
and
hacks,
and
things
like
that.
B
Imagine
you
know
you're
trying
to
verify
who
someone
is-
and
I
did
it
this
morning,
where
let
me
verify
your
email
and
send
you
a
2fa
prompt
and,
of
course,
we
all
know
that
no
one's
ever
given
over
control
of
their
email
address
to
somebody
else.
So
so
it's
really
only
as
good
as
as
the
actual
system
that
you're
using
what
we're
after
here
is
trust
in
the
data,
trust
that
we
don't
have
and
trust
comes
in
two
forms.
B
It
comes
in
the
form
of
integrity
which
is
being
able
to
identify
if
the
data
is
real
or
in
other
words,
has
it
arrived
to
you
as
it
was
created
and
issued
by
that
issuer
and
another
way
of
saying
it.
Has
it
been
altered
or
tampered
with
again,
the
analog
documents
have
some
really
nice
ways
of
identifying
whether
someone
has
put
white
out
over
the
the
page
to
change
their
birth
date.
B
So
we
want
to
get
get
to
be
able
to
verify
data
integrity.
We
also
want
to
verify
authenticity
and
authenticity
means.
Can
I
trace
it
back
to
its
source?
Do
I
know
where
it
came
from
and
if
you
have
those
two
things
you
can
trust
the
data
now,
whether
you
execute
a
business
decision
based
on
that
trust
is
really
up
to
you
as
the
person
receiving
it.
B
B
The
oh
you'll
have
to
forgive
my
word,
wrap
the
participants
in
this
trusted
ecosystem
are
are
usually
placed
in
this
sort
of
triangular
relationship
where
we
have
an
issuer
of
a
credential
here
on
the
left.
Who
gives
some
data
data
about
this
data
subject,
so
their
identity
in
some
form
or
another
to
a
credential
holder?
B
Who
then
takes
control
of
that?
Just
as
you
would
in
your
your
analog
wallet
and
when
asked
or
requested
for
some
data
by
a
verifier
shares
that
with
consent
and
transparency,
so
we
have
issuers
holders
and
verifiers,
and
then
we
have
the
verifiable
data
registry
or
ledger
and
the
networks
that
support
that
type
of
data
exchange.
B
No
more
on
that
for
me,
because
smarter
people
than
I
will
tell
you
about
that
part
of
it.
The
nice
thing
about
this
from
a
privacy
point
of
view.
Remember
we
want
to
maximize
trust
and
privacy
and
efficiency
is
that
the
pii
type
of
things
when
we're
speaking
of
humans
as
credential
holders
stays
with
the
data's
owner
or
the
authorized
controller
of
that
data,
if
you're
not
talking
pii
per
se
about
a
person
if
you're,
if
you're
a
business
enterprise
and
you
have
an
identity
and
you're
exchanging
information.
B
This
way,
it
allows
you
to
maintain
control
of
sensitive
business
information
as
well
the
ledger
that
will
constitute
the
bulk
of
our
content.
Today,
pardon
me
is
just
the
means
of
verifying
those
two
things
I
already
described
authenticity
and
integrity
of
the
data,
so
the
data
itself
stays
up
here,
kind
of
above
the
line
from
the
issuer
to
the
holder
and
given
to
the
verifier.
B
The
question
to
trust
or
not
to
trust
is
really
not
ours
to
make
in
the
context
of
what
we're
talking
about
today,
the
verifier
who
receives
that
data
can
trust
that
it
is
authentic
and
has
integrity,
but
whether
or
not
they
trust
the
issuer
is
up
to
them
and
a
very
simplistic
example
would
be
if
I
were
to
share,
let's
say
a
driver's
license
to
buy
an
age
restricted
process
product
the
verifier
who's
selling
me
that
product
can
verify
that.
Yes,
it's
has
integrity.
B
I
haven't,
I
haven't
changed
my
birth
date
and
it
came
from
the
motor
vehicle
association,
okay.
So
now
it's
got
integrity
and
authenticity
and
they
can
do
the
the
head
scratch
and
say
I
really
trust
that
motor
vehicle
association
so
I'll.
Let
you
buy
that
product.
However,
if
I
was
issued
and
held
and
presented
as
proof
of
age,
a
dunkin,
donuts
or
starbucks
driver's
license,
the
verifier
can
still
say:
yeah,
you
haven't
tampered
with
it
and
yes,
it's
authentic.
B
It
did
come
from
dunkin
donuts,
but
no
we're
not
going
to
trust
that
as
proof
of
your
age,
because
we
don't
trust
them
as
as
a
source
of
your
age,
so
so
to
trust
or
not
to
trust
is,
is
really
a
business
decision.
In
the
end,
some
quick
use
case
examples
to
help
tie
what
I've
just
said
to
the
real
world.
B
In
the
case
of
issuers,
we
can
think
of,
let's
say
a
government
agency
or
entity
that
wants
to
issue
you
a
credential
that
says
hey.
You
live
here
within
the
scope
of
my
domain
here,
and
the
first
thing
you
might
the
government
might
ask
you
to
do
is
to
validate
your
identity
either
using
a
mobile
app
or
by
even
by
showing
up
in
person
and
saying
hey.
Here
I
am
and
here's
my
driver's
license
and.
B
You
can
see
where
they
they
need
that
analog
assurance
of
who
you
are.
However,
once
they've
validated
your
identity,
they
can
take
some
more
information
from
a
holder's
wallet
or
application
and
give
you
a
government
credential
in
this
case
we'll
call
it
a
government
residency
credential
that
says:
hey
you,
you
do
live
here.
We
know
who
you
are
and
we've
got
you
in
our
our
database
that
we
already
have
permission
to
have
you
in
from
you
and
we're
going
to
give
you
this
residence
residency
credential.
B
You
share
it
with
transparency.
You
share
it
with
consent.
You
have
to
take
some
discrete
action,
often
within
the
context
of
an
application
in
your
mobile
device
or
in
a
cloud-based
interface,
where
you
say
I
consent
to
giving
you
this
data,
and
then
the
bank
says
hey,
we
can
verify
it,
we
can
go
and
check
that
it
has
integrity
and
we
can
check
the
source
and
it
has.
B
Once
that
trusted
data
is
received
by
the
bank
and
you've,
given
them
permission
to
have
it
and
hold
it
and
use
it,
they
can
use
it
to
issue
you
a
derivative
credential.
Perhaps
that
says,
hey
here's.
Your
bank
account
holder's
credential,
it's
in
your
device
and
we're
going
to
let
you
log
into
your
account
now
using
this,
so
we're
going
to
let
you
transfer
funds
using
this
or
open
a
second
account
using
this,
because
we
know
who
you
are
and
we
we
have
been
able
to
delegate
that
trust
from
its
original
source.
B
B
We
also
used
some
real
world
names,
bob
and
alice.
That's
sort
of
an
it's,
not
new
to
the
identity,
community
or
unique
to
it.
Bob
and
alice
are
throwing
around
a
lot
of
other
use
case
examples,
but
you
will
see
bob
and
alice
repeatedly
here,
sometimes
as
issuers
and
sometimes
as
verifiers
they're,
not
exclusive
roles,
often
roles
overlap.
B
B
C
C
Going
to
have
my
slides
looking
like
this
a
little
bit
funny
for
you,
because
I
need
to
go
back
and
forth,
and
click
on
links
and
stuff
for
mine
is
part
of
the
hands-on
stuff.
So
apologies
if
it
looks
a
little
weird
compared
to
the
how
nice
it
looked
for
for
scott's
part
of
it,
but
the
I'm
going
to
be
talking
about
some
of
the
tools.
C
Scott
gave
you
some
of
the
background
information
I'll,
be
going
a
little
deeper
and
telling
you
a
little
bit
more
about
some
of
the
tools
and
and
I'm
doing
this,
because
we
want
to
share
a
little
bit
about
some
of
the
background
introducing
more
terminology
and
some
of
the
other
things
so
before
we
get
into
the
aries
part
of
it.
Just
to
give
you
an
idea
about
how
indie
works
so
a
little
bit
about
me
before
we
dig
too
deep
into
tools
here.
I
am
the
director
of
network
operations
head
in
dco.
C
This
atlan
bendix
is
my
handle
for
every
chat
channel
that
I
that
I
know
about.
I
think
so.
You
can
get
a
hold
of
me
there
and
ask
me
direct
questions.
I
am
the
I
should
say
pending
here.
I
think,
because
I
it's
not
quite
100
percent
official,
it's
almost
official
and
be
the
co-chair
in
about
two
weeks
of
the
toip
utility
foundry
working
group
along
with
two
other
excellent
individuals.
C
Utility
foundry
means
public
utilities,
so
trust
over
ip
wants
to
help
people
build
networks
through
this
working
group
and
and
I've
built
a
lot
of
networks,
and
that's
why
I'm
talking
about
some
of
these
tools
is
because
I've
built
networks
and
built
network
tools-
and
you
know
that's
what
I've
been
doing
for
several
years
now
from
both
the
sovereign
foundation,
helping
to
build
their
networks
and
then
also
now
for
indicio.
I've
built
all
of
our
networks.
C
For
that.
So
that's
my
background
and
and
why
you
know
I'm
the
expert
that
gets
to
talk
to
you
about
this
stuff.
So,
let's
start
with
the
developer
tool
this
one,
I
didn't
actually
help
right.
This
one
was
written
by
patrick
stoss,
did
a
great
job
to
where
I
just
had
to
copy
the
code
and
change
a
few
things
to
make
it
work
for
our
dco
networks,
as
you
can
see
here,
so
you
can
go
to
your
link
like
I
just
clicked
on
it
and
browse
around
in
here.
C
If
you
want
to
I'll
talk
just
a
little
bit
about
this
and
give
you
an
intro
to
what
all
this
means
here.
Essentially,
this
displays
three
of
the
sub
ledgers
that
are
on
the
network
right,
so
the
indicio
test,
vent
and
other
indian
hyperledger
indie
networks
have
multiple
sub-ledgers
on
them
that
constitute
what
we
call
the
ledger.
So
there's
some
a
little
bit
more
terminology
for
you
there,
essentially
the
domain
ledger.
Subledger
is
the
main
part
where
you
get
to
add
in
dids.
C
That's
what
nim
means,
as
it
did
and
then
schemas
to
help
build
your
credential
definitions,
which
is
this
one
credential
definition.
So
people
are
out
here
testing
on
this
thing,
46
800
rights
to
our
domain
sub
ledger
on
the
test
net.
It's
getting
a
lot
of
use!
So
writing
things
out.
Here
is
what
an
issuer
does.
It's
got
talked
about
issuers
to
be
able
to
issue
credentials.
C
You
have
to
have
these
things
on
the
ledger
anyway,
then
the
this
pool
ledger
has
the
the
nodes
of
the
ledger
in
it
and
then
the
config
ledger
subledger
has
the
rules
about
how
to
run
the
ledger
following
the
network,
governance
and
there's
other
things
out
here,
we'll
let
you
go
and
click
on
them
and
see
if
it
shows
more
details
about
all
this
stuff.
But
it's
going
to
give
you
a
high
level
introduction
and
later
on.
C
When
you
add
your
an
endorser
to
the
network
as
part
of
our
hands-on
stuff,
then
you
can
come
look
out
here
and
see
your
endorser
right
here
on
the
indicio
test
net
when
we
get
to
that
point.
So
that's
part
of
why
I
show
that
one
before
we
get
too
much
further.
I
just
mentioned
the
word
endorser.
I
should
talk
a
little
bit
more
about
roles.
C
We
scott
talked
about
roles
outside
of
the
ledger:
the
issuer
holder,
verifier
for
the
network
itself.
The
names
of
the
roles
on
the
network
itself
are
the
following:
some
of
them
are
these
ones.
Here
the
trustee
is
the
one
who
writes
those
administrative
transactions
to
the
ledger,
so
the
for
the
the
pool,
sub
ledger
and
the
config
sub
ledger.
A
lot
of
the
administrative
transactions
will
go
into
there
and
they.
C
Have
sorry,
I
just
saw
a
note
that
says:
can
you
please
do
full
screen
and
apologies?
I
can
make
this
a
little
bit
bigger
to
make
it
easier
to
see,
but
we
have
some
some
hands-on
material
behind
there
so
that
we
need
to
have
have
it.
Look
like
this
again.
Apologies
so
yeah
the
trustee,
writes
and
governs
the
network
through
administrative
transactions
to
help
make
things
work
and
then
endorser,
like
I
said,
that's
the
actually,
the
only
role
on
our
ledger.
That's
able
to.
E
C
The
credential
transactions,
a
trustee,
can't
even
write
the
the
schemas
and
the
credential
definitions
and
stuff
that
are
needed
to
issue
credentials
I'll
get
more
details
about
what
all
that
means
and
why
all
that
is.
But
this
role
here
is
the
one
that
can
do
that
and
he
either
writes
them
himself.
Making
him
the
issuer
or
an
author
can
build
transactions
and
then
get
them
endorsed
by
the
endorser.
C
So
an
author
can
also
be
an
issuer
or
eventually
could
be
an
issuer,
but
they
have
to
have
their
transactions
endorsed
by
an
endorser,
and
the
reason
for
that
is
because,
on
the
on
a
main
network,
we
don't
most
people
don't
run
main
networks
for
free,
that's
the
way
they
charge.
People
to
use
the
network
is,
is
to
have
these
endorsed
transactions,
and
so
a
company
might
be
an
endorser
where
they
have
clients
that
are
authors
where
they
endorse
their
transactions
for
them.
C
Hopefully,
that
gets
at
least
a
start.
There's
a
lot
more
information
available
online
and
you
can
ask
questions
in
the
chat.
We'll
get
you
more
information
if
you
need
it
for
that
stuff,
but
the
other
high
level
thing
we
need
to
talk
about
is
the
transaction
author
agreement
care.
That
is
something
that,
whether
you're
an
endorser
or
an
author.
You
have
to
sign
this.
C
If
you
are
going
to
write
transactions
to
the
ledger,
that
means
you
agree
that
you're
not
going
to
write
anything
illegal
or
any
you're,
not
going
to
write
any
pii
or
anything
else.
That's
against
the
governance
and
it's
kind
of
a
long
thing
to
read.
But
if
you
read
through,
you
can
see
that
it's
it.
It
makes
it
makes
sense.
It's
not
super
restrictive,
but
we
don't
want
anybody's
pictures
out
there.
C
We
don't
want
any
personal
identifiable
information
on
the
ledger,
so
that
gets
us
to
the
next
tool
that
I
want
to
talk
about,
and
that
is
the
self-serve
tool
we're
almost
to
the
indie
cli.
So
if
you
haven't
got
your
indie
cli
ready
to
go
yet
your
your
screen,
where
you
can
start
typing
things
in
now's
the
time
to
do
it,
but
we're
going
to
tell
you
a
little
bit
about
self-serve
here.
First,
I'm
going
to
pop
that
guy
up
here.
C
This
is
the
self-serve
web
page
for
in
dcl.
Sovereign
has
one
as
well
looks
similar.
Essentially
you
type
in
the
network
that
you
want
to
use,
and
today
we'll
be
using
the
testnet
and
then
copy
in
the
did,
and
the
ver
key
that
you
get
through
a
method.
We'll
show
you
in
a
little
bit
and
then
click
submit
and
that's
all
there
is
to
it,
and
this
helped
me
get
a
did
down
here,
can
help
you
to
get
a
did
on.
C
C
C
Command
line
here
and
we're
going
to
have
you
guys
follow
along
as
we
set
up
the
indie
cli
to
be
able
to
do
things
in
it.
The
ndcli
is
a
is
kind
of
more
of
an
administrative
tool,
it's
very
manual
and
and
hands-on,
but
it
helps
to
to
show
you
the
basics
of
of
how
a
network
works
and
working
in
that
will
give
you
some
of
the
background
underlying
things
to
help
you
know.
What's
going
on
so
the.
C
What
else
was
I
gonna
say
about
this?
Oh
yeah,
so
it's
a
place
where
you
can
have
your
own
wallets
and
your
own
other
and
then
start
managing
your
date,
your
own
dids
and
your
own
wallets,
and
that
kind
of
thing
so
we'll
just
jump
right
in
so
here's
what
I'm
going
to
do,
I'm
going
to
copy
and
paste
this
thing
into
over
here,
oh
looks
like
I
got
that
priority
set
up
you'll
notice.
I
have
an
extra
g
on
mine.
C
C
What
you
should
see
on
your
screen
is
the
is
for
session
is
used
as
transaction
author
agreement
again,
if
you're
not
able
to
follow
along
or
if
you
have
troubles
here,
you
can
ask
in
the
chat
on
aries
sorry
at
the
hyper
ledger,
chat,
channel
and
the
aries
channel
and
feel
free
just
to
follow
along
and
watch
what
I'm
doing
and
try
it
again
later.
All
this
stuff
is
not
restricted
to
just
during
the
session
today.
So.
C
We
have
a-
I
already
have
a
test
net,
so
I'm
going
to
need
to
create
a
test
net
with
an
extra
t
on
it,
but
the
rest
of
you
shouldn't
have
any
pools
on
your
system.
So
actually
this
pool
isn't
creating
a
new
network
pool.
This
is
as
pool
kind
of
means,
a
pool
of
nodes
that
make
up
the
network,
but
this
is
a
pool
handle
that
points
to
an
existing
pool,
so
we're
making
a
pool
handle
on
our
system.
C
Workstation
or
your
system,
wherever
this
is
before
they
can
break
into
your
wallet
so,
but
it
does
need
to
have
a
password
in
case
someone
does
break
into
your
wallet
and
then
the
next
or
break
into
your
system.
The
next
thing
we're
gonna
do
is
we're
gonna
open
that
wallet
so
we're
using
pretty
much
the
same.
C
Put
in
that
same
password
that
we,
just
if
you
up
your
password
or
can't,
get
in
and
feel
free
to
make
another
wallet
of
a
different
name
to
to
continue
on
with
our
example.
Today,
a
wallet
contains
dids
and
nyms,
but
it
also
contains
the
private
parts
of
your
keys
and
your
other
you're
needed
to
who
you
say.
You
are.
C
C
Where
did
we
get
to
okay,
then
we're
going
to
create
a
dip.
Now
I
kind
of
did
a
little
bit
of
a
disservice
here,
but
I'll
explain
what
I
did
here.
What
what
I
did
is
I
didn't
make
it
so
this
has
a
seed
associated
with
it.
If
you
add
the
word
seed
to
the
end
of
this,
you
need
to
provide
a
seed
for
your
wallet,
seed
or
seed
equals,
and
then
I'm
sorry
for
your
did
that
we're
creating
this
new
did
or
nim
that
we're
creating
and
what
that
does.
C
And
there's
a
there's
a
lot
of
good
reasons
for
doing
it.
That
way,
but
for
our
example
today
we're
just
going
to
make
one
with
an
unknown
seed
that
that's
what
this
does
and
create
one
as
an
example.
So
when
you
do
it
for
real,
that's
what
I'm
saying
learn
a
little
bit
more
about
seeds
and
creating
one
and
and
that's
important
for
for
the
real
thing
when
you,
when
you
really
become
an
issuer,
you'll
want
to
to
keep
track
of
that
seed,
and
that's
a
super
secret
thing
that
you
want
to
place.
C
So
far
everything
we've
done
has
been
local,
though
we
set
up
a
pool,
handle
locally
connected
to
the
network
right,
so
there's
a
connection,
that's
there
now,
but
then
the
wallet
and
the
did
all
that
stuff
is
just
sitting
here.
Local,
nothing
is
on
the
network,
yet
so
just
to
just
to
keep
you
in
the
loop
there,
so
we're
just
going
to
type
help
by
itself
now
and
show
you
what
that
does,
and
that
shows
us
that
there
are
essentially.
The
thing
I
want
to
point
out
here
is
that
there
are
five
major
command
groups.
C
We
can
ignore
the
payment
address
one
here.
That's
not
that's
a
capability
of
the
network.
That's
not
been
put
into
place,
it's
not
something
that
we
have
set
up
or
using
right.
Now,
it's
essentially
the
ability
to
make
on
ledger
payments,
so
we
won't
go
for
that
one,
but
the
we
have
talked
a
little
bit
about
wall.
C
C
If
you're,
what
that
did
is
so
when
you're
creating
a
did,
and
you
want
to
keep
track
of
a
whole
bunch
of
them,
it's
helpful
to
add
the
metadata
on
when
you're,
creating
it
so
that
you
can
keep
track
of
which
ones
which
it's
just
a
little
hint
as
to
what
it
was
doing
there
anyway.
So
let's
jump
into
the
ledger
command
a
little
bit.
If
you
hit
ledger
and
then
you
don't
type
in
tab
tab,
you
just
type
the
tab
key
twice:
it
does
a
tab
complete.
C
All
the
sub
commands,
and
if
you
type
in
ledger,
help
it
shows
a
whole
bunch
of
stuff,
it's
kind
of
hard
to
read
it's
too
much
stuff.
Maybe
so,
let's
just
get
help
for
a
single
command
right.
Let's
just
pick
the
nim
command
like
like
we
did
in
the
in
the
example
there.
Let
your
nim
help.
We
can
copy
that
command
in
now,
and
it
shows
help
for
the
ledger,
nim
command
and
all
the
different
things
you
can.
D
C
C
C
So
I
think
we're
ready
for
our
break
during
the
break.
I'm
happy
to
answer
some
questions
and
stuff,
but
that's,
let's
cut
now
to
our
five
minute
break
and
if
everyone
can
come
back,
it
looks
like
we
can
just
go
at
the
top
of
the
hour.
Give
you
a
little
extra
time
and
go
to
the
top
of
an
hour
on
top
of
the
hour
for
our
break
and
feel
free
to
keep
asking
questions
and
we'll
stay
online
during
the
break
and
and
we'll
see.
D
So,
let's
see
so
I'll
first
start
off
by
thanking
everybody.
That's
presented
so
far.
The
intro
to
the
centralized
identity,
as
well
as
the
indie
network
tools,
is
all
building
up
to
what
we'll
be
doing
in
this
section,
which
is
our
introduction
to
hyperledger
areas
and
some
of
the
tools
and
code
bases
that
we
tend
to
work
with
here.
D
So
my
name
is
daniel
bloom.
I
guess
I
should
go
to
my
intro
slide.
I
am
a
software
engineer
at
indicio.
I
am
I
like
to
think
of
myself
at
least
as
a
veteran
of
the
community.
I've
been
here
for
a
while.
I
started
at
the
sovereign
foundation
and
then
later
joined
the
at
indicio,
and
I
have
been
working
in
this
space
since
before
hyperledger
aries
was
even
around
back
in
the
day
when
it
was
the
indie
agent
working
group
underneath
the
hyperledger
indie
project.
E
Thank
you
daniel.
As
daniel
said,
my
name
is
shar
howland
and
I'm
a
software
engineer
at
indiciotec.
I'm
an
active
developer
on
the
aries
cloud
agent,
python,
ecosystem,
working
on
developing
plug-ins
and
other
purpose-built
agents
and
protocols,
and
I'm
very
excited
to
be
here
today
and
talk
about
hyper
ledger
areas.
So
I
will
hand
it
back
to
you.
Danielle.
D
Cool
so
today,
as
we
go
through
this
introduction
to
hyperledger
areas,
we
will
be
focusing
on
these
areas.
So
we'll
start
off
with
a
general.
What
are
agents
then
describe
in
a
little
bit
more
detail,
some
of
the
tools
we'll
be
using
specifically
aries
cloud
agent,
python
and
the
aries
toolbox
today
and
then
give
you
some
of
the
conceptual
background,
while
discussing
protocols
and
messaging
that
kind
of
lay
the
foundation
for
understanding.
D
D
So,
first
with
the
conceptual
stuff,
so
first,
what
is
an
identity
agent
to
give
an
informal
definition?
My
informal
definition,
an
identity
agent,
is
the
piece
of
software
that
we
use
as
humans
to
interact
in
the
self-sovereign
identity
or
decentralized
identity
world,
especially
where
the
native
language
of
decentralized
identity
is
cryptography
more
or
less.
D
D
D
So
agents
are
often
split
up
into
a
few
different
categories,
or
at
least
they're
they're
used
to
help
us
talk
about
different
types
of
agents.
A
common
one
that
you'll
hear
thrown
around,
I
think
is,
is
cloud
agent
and,
as
opposed
to
having
any
strong
implications
about
the
trust
of
that
agent
or
whether
it's
using
a
particular
transport
or
the
ownership
of
that
agent
cloud
agent
really
is
a
description
of
the
location
of
the
agent.
D
D
So,
in
addition
to
these
descriptions
of
location,
we
also
have
varying
degrees
of
complexity
within
the
agent
ecosystem,
so
starting
from
the
most
basic,
a
static
agent.
This
is
an
agent
that
has
only
a
single
pre-configured,
endpoint
and
set
of
keys
for
a
single
connection,
and
it
does
not
have
the
ability
to
update
that
connection.
D
This
might
be
formed
on
demand
in
the
cloud
you
might
think
you
know.
Amazon
lam
does,
for
instance,
however,
similar
to
a
static
agent,
which
is
typically
very
purpose,
driven
very
use
case
driven
the
thin
agent
retains
this
narrow
focus
on
its
job.
It
has
its
one
job
and
it
does
it
well
and
then
going
further
from
there.
We
have
thick
agents,
and
this
is
an
agent
that
might
have
multiple
updatable
connections
while
still
having
a
a
very
specific
purpose,
the
one
that
comes
to
mind
most
frequently.
D
D
So
a
mediator
agent
can
service
many
agents,
but
its
one
purpose
is
to
mediate.
Those
messages,
as
opposed
to
you
know,
go
on
to
do
further
interaction
beyond
mediation,
so
it
would
be
described
as
a
thick
agent
and
then
finally,
the
most
complex,
you
might
term
as
a
rich
agent
or
a
feature-rich
agent.
D
Whatever
use
case
that
we
have
for
agents
even
within
the
rich
agent
category,
I
would
say
that
there
is
still
a
spectrum
more
or
less
a
functionality
where
some
agents
might
support.
One
credentialing
system
and
or
some
agents
might
not
support
credentialing
systems
at
all
and
are
purpose
built
for
you
know,
connections
and
interaction
over
messages,
as
opposed
to
just
credentials.
D
So,
ultimately,
these
categories
and
this
gradient
of
complexity,
that
I've
just
discussed,
is
kind
of
a
loosely
defined
thing.
There's
no
hard
and
fast
rule
for
exactly
what
an
agent
is,
and
that
is
because
these
categories
are
just
here
to
help
us
succinctly
describe
our
interoperability
goals,
so
a
cloud
agent
might
be
capable
of
more
than
what
we
might
typically
think
of
a
cloud
agent
as
being
that
doesn't
disqualify
it
as
being
a
cloud
agent
just
helps
us
to
understand.
Generally.
This
is
what
we
intended
for.
D
Which
brings
us
to
the
agents
that
we'll
be
working
with
today
to
describe
these
a
little
bit
more.
We've
got
the
aries
cloud
agent,
python
or
occupy
for
short,
as
you'll
probably
hear
me
say,
the
rest
of
this
presentation,
aries
cloud
agent,
python
is
just
a
little
bit
of
a
mouthful
and
occupy
is
a
foundation
for
building
decentralized
identity,
applications
and
services
running
in
non-mobile
environments.
D
D
D
You
might
be
able
to
colluge
it
and
make
it
work
somehow,
but
it's
not
really
intended
for
that.
So
you'll
you'll
experience
some
difficulties
there.
I
imagine,
especially
when
it
comes
to
receiving
messages
where,
in
a
mobile
environment
we
typically
need
to
actively
pull
from
outside
of
the
system
due
to
the
intermittent
connectivity
of
mobile
devices.
Same
story
for
browsers,
you
might
be
able
to
you
know,
push
that
square
peg
in
the
round
hole
if
you
push
hard
enough,
but
it's
just
not
really
designed
for
that.
D
D
D
D
This
makes
occupy
a
pretty
good
candidate
for
agent
as
a
service
type
systems
that,
as
well
as
the
horizontal
scalability
that
we
previously
discussed
so
occupy
is
again
using
the
categories
that
we
described
earlier
is
a
cloud
agent
and
is
a
rich
agent.
It
is
feature-rich,
it
is
capable
of
many
things.
D
D
First
and
foremost,
it's
not
really
intended
as
an
end-user
product
and
the
reason
for
that
being
not
that
we
don't
intend
to
put
as
much
polish
on
the
toolbox
as
possible,
but
rather
we
intentionally
expose
some
of
the
guts
of
the
interactions
that
are
taking
place
as
a
way
of
exploring
the
interactions
and
makes
it
a
really
good
tool
for
things
like
trainings,
debugging
and
testing
your
agents
and
just
all
around
useful.
Hence
the
name
toolbox.
D
The
aries
toolbox
is
a
minimal
or
again
using
that
gradient
of
complexity
term
thick
agent.
It
has
protocol
implementations
that
are
encapsulated
into
their
own
components,
meaning
it's
pretty
easily
extensible.
If
you
ever
wanted
to
add
your
own
features
to
the
toolbox,
it
also
makes
use
of
a
feature
detection
protocol
to
determine
what
the
connected
agent
is
able
to
do
and
then
adjust
the
ui
to
to
match
those
detected
features.
D
D
So
I
wanted
to
briefly
describe
at
a
high
level
a
way
of
thinking
of
agent
architecture.
This
isn't
the
way
this
isn't
even
necessarily
the
way
that
occupy
or
the
toolbox
handles
things.
If
you
were
to
dig
in
and
look
at
the
actual
software
components,
but
at
a
conceptual
level
this
is
a
way
to
break
up
the
different
responsibilities
and
processes
of
processing
a
given
message,
so
all
agents
will
have
some
form
of
a
transport.
D
This
is
what
we're
receiving
the
raw
bites
on
most
frequently
we'll
see
that
the
most
popular
transports
tend
to
be
http,
which
is
not
to
the
exclusion
of
https.
In
fact,
I
think,
usually
we're
using
https
and
in
the
agent
architecture.
This
receives
the
raw
bytes
and
then
passes
it
on
to
the
next
components.
Here,
I've
used
the
term
middleware
to
describe
this
this
section
of
the
stack,
but
I'm
not
sure
I
would.
I
would
really
endorse
the
usage
of
that
continued
phrase.
D
We
receive
a
request.
We
get
the
bytes,
we
have
middleware
that
you
know
adds
data
to
the
request,
and
then
it
gets
passed
along
to
the
handler
for
processing,
so
agents
work
in
a
very
similar
fashion.
We
receive
a
message
on
transport:
it
goes
to
the
security
middleware
where
it
is
decrypted
and
the
security
context
is
annotated
onto
the
message
so
once
it
arrives
at
the
handler,
we
know
which
cryptographic
keys
originated
the
message.
D
So
accupy
has
all
these
pieces
from
our
high
level
agent
architecture.
Discussion
contained
within
it
occupy
also
exposes
something
that
is
generally
referred
to
as
the
admin
api
and
a
controller
is
connected
through
that
admin
api
to
the
agent,
and
it
is
the
controller's
responsibility
to
handle
the
business
logic
so
making
decisions
about
what
needs
to
occur
next,
based
on
what
I,
as
an
individual
or
as
an
enterprise,
would
like
to
do
next,
so
forming
new
connections
would
be
an
action
triggered
by
the
controller
within
act.
D
D
D
D
D
So
plugins,
I
saw
a
question
come
up
in
the
chat
about
this
one,
so
hopefully
this
answers
that
one
so
acuply
has
an
increasingly
mature
plug-in
system.
So
it's
one
of
the
aspects
of
my
contribution
stack
by
that
I'm
actually
most
proud
of
I've
been
really
pushing
for
this
plug-in
system.
This
allows
us
to
do
things
like
additional
protocol
implementations,
making
sure
that,
in
order
to
add
such
and
such
protocol,
we
don't
necessarily
need
to
push
that
all
upstream
to
the
main
act
irico.
D
You
can
also
add
new
admin,
api
endpoints.
If
you
would
like
to
automate
a
workflow
that
you
do
frequently,
you
can
use
a
plugin
to
add
a
new
endpoint
that
performs
that
for
you,
you
can
also
add
custom
event
handlers.
So,
instead
of
making
it
the
controller's
responsibility
to
handle
these
asynchronous
events,
you
can
put
it
into
a
plug-in
have
that
occur
within
the
agent
itself
to
perform
that
whatever
action
is
desired
as
a
result
of
that
event
being
fired,
there's
also,
the
ability
to
add
did
resolvers.
D
D
This
is
the
did,
come
admin
api
for
instructing
occupy
to
take
certain
actions,
and
this
is
what
we'll
be
using
ultimately
to
use
the
toolbox
with
that
right.
So
if
I
bring
up
a
diagram
of
what's
going
on
here,
we
have
the
toolbox.
This
is
what
is
actually
displayed
to
us,
and
then
we
have
occupy
running
with
the
toolbox
plugin
alongside
it.
D
D
We
intend
to
use
react
which
just
has
a
little
bit
more
vibrant
of
a
community
in
general,
as
well
as
within
the
aries
hyperledger
area's
ecosystem,
and
is
our
goal
to
ultimately
have
the
toolbox
resemble
a
little
bit
more
closely.
The
other
agent
frameworks
underneath
the
hyperledger
areas
umbrella
and
provide
us
with
you
know
in
the
future,
more
maintainability
and
a
path
forward
for
ditcom
v2.
D
So
there
are
a
number
of
other
code
bases
as
well
that
I
wanted
to
call
out
here
again,
if
you
absolutely
hate
python
you're.
In
luck,
there
are
other
language
frameworks
for
aries
available
aries
framework.
Javascript
is
one
that
we
work
with
a
lot
at
in
dco.
In
addition
to
acci,
it
is
a
typescript
based
framework
that
is
pretty
close
to
feature
parity
there.
There
might
be
some
differences
in
both
directions
with
occupy,
so
really
good
candidate
there.
D
D
What
do
I
call
it
first
thing
that
comes
to
mind:
is
an
integration
test
style
test
harness
for
other
agents,
but
it's
at
a
little
bit
higher
than
integration
integration
test
level.
So
using
the
aries
agent
test
harness
we
can
take
occupy
and
another
instance
of
occupy,
and
then
the
test
harness
will
trigger
interactions
between
the
two
agents,
observing
the
results
and
then
producing
a
compatibility
matrix
between
the
two
agents
that
were
tested.
D
D
I
am
particularly
fond
of
this
one,
I'm
the
original
author
and
maintainer
the
static
agent
python
library.
It
holds
a
little
bit
of
a
unique
place
within
the
hyperliteraries
ecosystem.
In
that
it
is,
I
think,
the
only
library
purpose
built
for
static
agents,
so
it's
especially
lightweight
but
quite
useful.
We
use
it
for
testing
other
agents
all
the
time,
but
we've
also
used
it
for
proxy
mediator
service
and
in
other
contexts
as
well.
D
This
is
built
using
occupy
and
it
provides
us
with
that
third
party
that
enables
mobile
agents
to
receive
messages
when
they're
otherwise
offline
and
then
the
last
one
is
a
bit
of
an
oddball.
The
aries
ask
our
code
base.
Asgar
is
a
secure
storage
library
which
is
heavily
inspired
by
the
indie
sdk
wallet.
D
It
has
seen
a
little
bit
more
optimization,
I
believe,
in
terms
of
performance,
but
it's
also
a
little
bit
more
flexible
than
the
nd
sdk
wallet,
and
we
anticipate
that
we'll
see
more
and
more
adoption
of
this
code
base.
It
is
currently
pretty
well
supported
within
occupy.
You
have
the
choice
of
using
the
nd
sdk
wallet
or
aresascar,
but
I
think
we'll
start
seeing
adoption
of
it.
In
other
frameworks
such
as
afj.
D
And
then
finally
wanted
to
call
your
attention
to
the
aries
rfc's
repository.
The
majority
of
the
content
that
is
discussed
today
is
directly
available
within
the
aries
rfc
repo.
It
might
take
you
a
while
to
read
through
all
of
it,
but
it's
all
there,
so
the
aries
rfcs
are
a
great
place
to
go
and
participate
in
the
development
of
these
protocols.
If
you'd
like
or
just
to
see
the
specification,
if
you're
implementing
one
of
these
protocols
within
your
own
agent.
D
There's
a
good
question
in
the
chat
that
I'll
I'll
call
out
here
so
matthias
is
saying
wondering
if
there
are
any
light,
did
come
for
iot
environments.
So
iot
is
a
really
interesting
use
case
that
we
have
a
lot
of
interest
in
the
didcom
v1
standard
which
we'll
be
using
and
discussing
today
has
some
crypto
requirements
that
make
it
difficult
to
implement
on
iot
devices.
As
of
right.
D
Now,
however,
in
in
the
did
come
b2
efforts,
which
I
think
I'll
let
sam
allude
to
a
little
bit
more
thoroughly
as
he
gets
into
his
portion
of
his
slides,
is
seeking
to
address
that
a
little
bit
more
and
even
before
we
get
to
com
b2
support.
Iot
devices
can
still
interact
in
a
did
come
space
by
delegating
to
a
hub
that
is
ditcom
capable,
for
instance,
if
you've
got
a
really
lightweight
device.
There
are
some
iot
devices
out
there.
I'm
sure
that
are
are
crypto
capable,
but
that
is
not
universally.
D
Okay,
so
protocols
and
messaging,
so
this
is
a
description
of
what's
going
to
actually
be
taking
place
between
the
agents
as
we
step
through
our
hands-on
portion.
So
we'll
start
off
with
what
is
the
communication?
I've
used
that
term,
I
think
a
few
times
without
defining
it.
So
a
very
simple
definition
would
be
where
verifiable
credentials
are
about
a
subject
about
a
owner
of
a
did.
An
identity
owner
did.
Communication
is
communication
with
the
subject
of
that
the
idea
and
and
verifiable
credentials.
D
So
com
is
ultimately
the
way
for
did
nbc,
capable
entities
to
communicate
securely
and
privately,
which,
by
extension,
means
that
it
is
the
way
for
credentials
and
presentations
to
be
sent
and
received
between
parties,
but
it
doesn't
stop.
There
did.
Com
is
also
just
generally
useful
as
a
mutually
authentic,
authenticated,
secure
communication
channel
between
two
peers,
two
or
more
peers.
I
should
say
so.
D
D
This
means
that
we
are
confident
that
the
person
we
think
we're
talking
to
is
actually
the
person
that
we're
talking
to,
or
in
other
words,
we're
confident.
Our
communications
are
authentic
when
our
communications
are
private.
We
are
confident
that
the
information
passed
from
us
to
the
other
party
is
completely
opaque
to
a
man
in
the
middle
who
might
intercept
that
message.
D
D
That
means
it
doesn't
matter
whether
you're
using
app
from
such
and
such
vendor
with
another
app
from
another
vendor.
It
doesn't
matter
what
operating
system
you're
on,
doesn't
matter
what
decentralized
root
of
trust
or
blockchain
you're
using
it
doesn't
matter
what
the
programming
language
the
agent
was
written
in
interoperability
of
vidcon
means
that
there
is
no
vendor
lock
and
no
lock-in
based
on
any
of
these
constraints
that
we
often
have
to
live
with
today.
D
In
addition
to
that
did,
com
is
transport
agnostic,
meaning
that
it
shouldn't
matter
whether
you're
using
http,
websockets,
bluetooth
or
email,
or
the
ongoing
joke,
has
always
been
carry
your
pigeon
for
transmitting
your
your
vidcon
messages
from
one
party
to
the
other
did
com
is
not
dependent
on
those
transports
to
make
sure
that
the
message
is
secured
and
then
finally
extensible.
So
this
one's
a
little
bit
more
loosely
defined
in
my
head
at
least
but
did
come,
is
an
open
standards
that
you
can
participate
in.
D
D
So
as
a
result
of
those
goals,
we
also
have
a
few
other
attributes
or
properties
of
did
com
that
are
worth
calling
out.
So
did
communication
is
message
oriented
with
senders
with
one
sender
and
one
or
more
receivers
on
receipt
of
the
message.
The
recipient
can
either
take
action
or
not
take
action
depending
on
the
state
of
the
relationship
with
the
sender
message
and
can
choose
to
respond
with
another
message.
Back
to
that
sender
I
did.
D
D
There
might
be
some
temporal
implications
as
a
result
of
the
contents
of
a
message,
but
that
is
delegated
to
the
user
in
the
case
of
email.
In
the
case
of
didcom,
it
is
delegated
both
to
ditcom
protocols
to
determine
whether
there
should
be
a
temporal
aspect
associated
with
the
messages
being
exchanged
or
to
the
user
to
decide
when
it
wants
when
they
want
to
respond.
D
Also,
like
email
did,
communication
is
routable,
meaning
that,
in
order
to
get
from
a
to
b,
the
message
can
be
routed
through
c.
So
this
means
that
did
communication
natively
supports
mixed
network
like
behavior.
So
if
you're
familiar
with
the
onion
routing
network
or
tor,
it
bounces
messages
around
between
a
bunch
of
different
participants
in
the
the
network
to
help
sever
any
traceability
between
the
original
sender
and
the
final
recipient
of
data
sent
over
the
network.
D
So
did
com
supports
similar
behavior
by
default
with
this
routing
mechanism,
it
also
means
that
ditcom
can
transfer
between
different
transport
types
at
a
at
different
hops
in
the
route.
So,
if
I
have
a
agent
running
in
my
closet,
for
instance-
and
it
receives
a
message
over
http-
and
it
is
instructed
to
relay
that
message
onto
my
mobile
phone,
it
can
do
that
over
bluetooth,
even
though
it
was
originally
received
over
http
without
any
breakdown
in
the
security
or.
D
So
there
are
some
interactions
between
these
different
goals
and
properties
that
are
worth
calling
out.
First,
the
security
of
vidcom
is
not
dependent
on
a
given
transport.
I
think
that's
kind
of
a
logical
follow-on
to
what
I
just
previously
discussed,
where
we
can
transfer
between
transport
protocols.
D
The
security
is
actually
wholly
encapsulated
within
a
ditcom
message.
That
being
said,
we
can
use
transports
and
routing
to
augment
the
security
and
usability
of
our
agent
systems,
for
example
using
https
as
a
transport.
Many
of
our
current
agent
implementations
benefit
from
perfect
forward
secrecy,
which
is
a
desirable
attribute
for
cryptography.
D
On
the
other
end
of
that
spectrum,
though
we
have
requiring
specific
transports,
can
actually
damage
interoperability.
So
if
you're
such
and
such
vendor-
and
you
have
this
really
cool
transport
mechanism
that
you
just
devised
and
came
up
with-
and
you
require
only
that
transport
you're
out
of
luck
when
interacting
with
the
rest
of
the
ecosystem,
which
might
be
more
reliant
on
or
more
frequently
using
other
transports
such
as
http.
D
D
There
are
many
layers
underpinning
the
communication
that
have
their
own
protocols
associated
with
them,
such
as
tcp
http,
managing
dids.
You
know
the
communication
channel
used
from
a
user
of
the
indie
network
uses
a
different
set
of
protocols,
as
well
as
a
different
set
of
protocols
for
the
actual
update
process
like
the
algorithm
used
and
then
cryptography
also
has
its
own
protocols
in
the
form
of
you
know,
diffie-home
and
key
exchanges,
and
others
so
did.
Communication
protocols
should
not
be
confused
with
any
of
these
lower
layer
protocols.
D
D
Rest
is
a
one
request.
One
response
style
system,
whereas
did
com,
can
exchange
many
messages
in
order
to
complete
an
interaction
back
and
forth
between
the
two
parties,
not
just
one
there.
One
back
rest
uses
http
methods
to
indicate
which
action
that
should
be
taken.
Didcom
is,
of
course,
not
dependent
on
http,
as
it
is
transport
agnostic,
and
the
action
is
determined
by
the
message.
Type
included
in
the
ditcom
message.
D
D
So,
to
have
a
well-defined
stateful
interaction,
a
protocol
needs
the
following
ingredients:
the
name
and
version
of
a
protocol.
It's
uri
that
identifies
it.
It's
messages,
the
roles
that
the
sender
and
receiver
can
take
in
the
protocol
and
then
essentially,
what
is
a
state
machine
of
how
those
messages
and
roles
are
expected
to
proceed.
D
D
D
D
So
this
basic
message
protocol
is
a
very
simple
or
basic
if
you
will
instant
messaging
protocol
for
agents.
This
is
more
of
a
toy
protocol
as
opposed
to
really
intending
to
be
the
ultimate
in
instant
messaging
between
did
com
connected
peers,
but
it
is
a
basic
protocol
that
we
can
look
at
and
explore
and
implement
early
on
in
our
agents.
Development
like
life
cycle
to
ensure
communication
is
flowing.
D
D
D
And
then
the
next
ver
the
next
portion,
rather
is
the
protocol
version.
This
version
is
loosely
following
the
semantic
versioning
specification,
if
you're
familiar
with
that,
I
say
loosely
because
we
can
see
here
that
it
is
omitting.
The
patch
number,
which
is
generally
required
in
semantic
versioning
patch
number
would
be
accepted.
It's
valid.
The
reason
why
it
is
omitted
in
this
case
is
where
patch
refers
to
a
fix
to
a
major
and
minor
version
that
does
not
impact
the
external
api.
D
So
finally,
the
last
part
of
the
path
here
is
the
message
type
or
name
in
this
case
again,
perhaps
slightly
confusingly,
the
name
is
message.
This
will
differ
for
other
protocols
and
other
messages
and
everything
that
precedes
that
message.
Name
is
referred
to
as
the
protocol,
identifier,
uri
and
then
taken
as
a
whole.
This
string
is
called
the
message.
Type
uri.
D
D
This
is
the
offer
credential
message
from
the
issue:
credential
protocol
version
1.0,
and
this
of
course
includes
the
r-type
string
that
helps
us
identify
what
the
heck
it
is
and
what
attributes
to
expect
and
then
we
expect
to
see
a
comment:
a
credential
preview.
This
offers
attach
object,
and
this
is
again
defined
by
the
issue.
Credential
protocol.
D
An
agent
message
is
a
message
sent
between
identities
to
accomplish
some
shared
goal
again:
those
basic
messages,
those
offer
credential
messages,
all
those
things,
and
then
the
packed
message
is
a
wrapper
around
that
agent
message
that
enables
the
message
to
be
securely,
delivered
and
sealed,
while
in
transport
from
one
agent
to
another,
these
message
envelopes
encryption
envelopes
have
a
couple
of
different
flavors
to
them.
Anonymous
authenticated
encryption.
We
typically
only
really
use
the
authenticated
encryption,
so
I
won't
spend
a
ton
of
time
talking
about
that.
These
messages
are
end
to
end
encrypted.
D
D
So
if
we
take
that
example,
message
again
and
then
transform
it
into
a
packed
message,
the
pseudocode
operation-
for
that
might
look
something
like
this,
where
we
take
the
message
as
our
message
parameter
and
we
stuff
it
into
this
pack
method
that
takes
the
recipient's
verification
key
and
my
signature.
Key
and
verification
key
in
this
context
refers
to
a
public
key
and
then
ed25519,
public
or
public
private
key
pair
and
the
signing
key
is
the
private
portion
there's
a
little
bit
more
going
on
in
the
background
here
than
simply
this.
D
D
And
the
result
of
this
pack
operation
is
somewhat
similar
to
this
I've
truncated,
a
few
values
for
brevity
and
clarity
here,
but
each
of
these
values
are
are
worth
at
least
knowing
generally
what
they
are.
I
think
so.
The
protected
attribute
here
is
a
base64
encoded.
Json
object
containing
headers
for
this
pac
message
inside
of
the
headers
you'll,
see
things
like
the
algorithm,
the
that's
the
portion
where
you'll
see
a
lot
of
the
standard
json
web
encryption
pieces.
It
also
includes
the
recipients
and
the
encrypted
content
encryption
key.
D
Okay,
so
with
that,
we
have
reached
our
second
intermission
here
when
we
return
we'll
begin
our
hands-on
portion
with
char
leading
and
then
we'll
step
through
forming
connections
and
issuing
credentials
and
all
that
interesting
stuff.
We
are
again
pretty
cleanly
set
for
starting
at
the
top
of
the
hour.
So
I
I
think
that
makes
sense.
D
E
E
So
now
that
we've
gotten
the
background
information
on
the
agents
areas
occupy
aries
cloud
agent
python,
there
is
toolbox
and
did
come.
We're
now
ready
to
start
up
the
agents,
create
a
connection
and
issue
and
verify
a
credential,
and
so
in
each
of
these
next
sections
we're
going
to
walk
through
a
demo
with
screenshots
that
indicate
each
step
where
to
click
which
buttons
and
what
information
to
enter
in
and
then
we'll
transition
to
a
live
demo
from
daniel
walking
through
the
same
steps.
E
So
my
demo
with
the
screenshots,
is
more
of
a
quick
primer
for
the
live
demo.
You
can
follow,
along
with
daniel,
to
explore
more
deeply
and
demo
additional
interactions,
and
so
the
first
thing
we'll
need
to
do
is
start
up
the
toolbox
and
the
agents,
and
so
you
may
have
tried
this
out
in
office
hours
or
prior
to
this
workshop,
we'll
walk
through
it.
Briefly,
here
and
again,
a
prerequisite
document
outlines
the
steps
for
cloning,
both
the
aries
toolbox
and
the
aries
accuplay
toolbox
plug-in.
E
E
E
I
get
checkout
to
make
sure
that
you're
on
the
correct
hl
workshop
branch
and
then
this
docker
compose
command
to
build
the
agents
and
if
you
get
a
permissions
error,
it'd
be
a
great
idea
to
run
as
administrator
with
sudo
to
solve
that,
and
this
should
take
10
to
20
seconds
and
at
the
bottom
it
will
print
a
large
qr
code
and
an
invitation
url.
That
should
look
something
like
this
window
on
the
left
and
so
now
we'll
we'll
walk
through
some
quick
screenshots
to
show
what
this
should
look
like.
E
We
will
see
that
bob
now
is
also
connected
to
the
toolbox
and
again
just
a
reminder
of
what
scott
mentioned
earlier
about
the
agents.
These
are
alice
and
bob
commonly
named
commonly
used
names
in
cryptography
discussions
and
they're
a
placeholder
for
different
entities,
so
it
could
be
a
university
in
a
student,
a
business
and
a
customer
could
be
people
named
alice
and
bob
who
have
met
at
a
conference
and
would
like
to
connect,
and
so
with
that
I
will
hand
it
off
to
daniel
for
a
live
demo
of
these
steps.
D
Okay,
thank
you
char,
so
we
will
first
start
off
with,
and
hopefully
this
will
help
everybody
step
along
and
have
a
little
bit
clearer
picture
of.
What's
going
on.
I
know
there's
a
little
bit
of
an
issue
with
slightly
blurred
images,
but
we'll
go
through
all
those
exact
steps
here
as
well,
so
I
am
currently
within
the
I'll
start
off
with
the
toolbox,
actually
just
to
follow
the
same
order.
So
I'm
in
the
folder,
where
I've
cloned
the
aries
toolbox.
This
might
look
a
little
bit
different
for
you.
D
I'll
try
to
be
attentive
to
chat
as
we
go
through
these
steps.
If
there's
anything
that
is
really
just
not
making
any
sense
feel
free
to
to
send
it
there
also
anybody
who's,
seeing
chat
and
would
like
to
holler
out
anything,
that's
unclear.
Let
me
know
okay,
so
then,
now
we're
in
the
aries
toolbox,
repo
that
is
now
done
with
install
we'll
do
an
mpm
run
dev
now,
and
we
should
see
a
window
pop
up
here
in
just
a
moment.
D
For
any
more
technical
questions,
if
you
run
into
difficulties,
I'd
highly
recommend
directing
those
to
the
aries
rocket
chat
channel
on
the
hyperledger
rocket
chat
and
one
of
our
moderators.
There
can
help
you
out
in
a
little
bit
more
detail
than
I
can
here
so
cool.
So
we've
got
the
aries
toolbox
running
ready
to
connect
to
our
agents,
which
we
will
now
start
up.
So
I
am
in
the
aries
acquire
plugin
toolbox.
D
D
Okay,
so
this
should
bring
up
a
number
of
services.
There
are
two
services
for
agents
and
two
services
for
tunnels
that
enable
external
connectivity.
If
we,
if
you
want
to
send
an
invitation
to
somebody
over
rocket
chat
for
instance,
and
have
them
connect
to
your
agent,
that
is
possible,
and
then
we
have
our
two
invitations
and
qr
codes
spat
out
on
the
terminal
here.
D
So
what
we're
going
to
use,
rather
than
the
qr
code,
is
we're
going
to
copy
the
text
just
above
the
qr
code
for
bob
first,
since
he
happened
to
be
the
last
one
in
and
I'll
paste
that
into
the
new
agent
connection
box
here
and
hit
connect,
we
see
some
stuff
happening
in
the
background.
This
is
actually
the
connection
protocol
taking
place.
D
So
once
we're
to
this
point,
we
can
open
up
each
of
these
agent
windows,
I'm
going
to
say
goodbye
to
my
agent
list
for
now,
and
we
now
have
an
alice
and
bob
window
here,
I'm
going
to
increase
our
sizing
just
a
little
bit
and
put
these
kind
of
side
by
side.
So
this
is
the
aries
toolbox.
This
is
the
main
view
that
you'll
be
interacting
with
when
you're
connected
to
a
particular
agent.
D
There's
a
number
of
different
features
involved
here,
I'll
start
off
by
clicking
into
the
discover,
features,
tab
or
section.
I'm
never
sure
what
to
call
these
section
I'll
go
with
section
and
this
enumerates
all
the
protocols
that
are
supported
by
the
connected
agent
and
you'll
notice
in
here,
a
number
of
credentials
that
are
prefixed
with
admin
in
the
protocol
name:
admin
issuer,
let's
see
where's
another
one,
admin,
schemas
admin,
d,
ids,
there's
some
more
in
here
somewhere,
and
these
are
the
protocols
that
the
toolbox
is
detecting
and
then
based
on.
D
D
D
D
So
to
briefly
explore
what's
going
on
in
here,
so
we
see
the
discover
features.
This
is
what
is
triggered
by
the
discover
features
section
and
we
sent
a
query
and
we
received
a
disclose
which
listed
off
all
those
protocols
for
us.
What's
another
good
one,
we
had
an
admin
connections
list,
oh
that's
received.
I
need
to
send
where's
the
send
here.
We
go.
D
D
D
There's
also
an
invitation
section
that
allows
us
to
create
manage
invitations.
We
have
active
connections.
We
can
see
alice's
view
of
her
connections,
which
includes
the
toolbox,
which
is
what
we're
actually
using
to
access
this
view
of
the
connections.
So
we
don't
want
to
get
too
recursive
there.
I
guess,
but
we
can
see
that
the
active
connection
of
the
toolbox
is
present
here.
D
It's
also
a
form
here
to
create
a
static
connection
with
a
static
agent.
We
won't
be
using
that
today
we
can
use
this
to
send
a
basic
message.
I
can
send
one
back
directly
to
the
toolbox,
so
what
I'm
doing
now
is
from
the
toolbox
telling
the
alice
agent
to
send
me
the
toolbox,
a
message
which
is
fun.
D
I
think
yep
there.
It
is
shows
up
in
a
slightly
different
location.
This
makes
a
little
bit
more
sense
when
we're
remote,
controlling
and
communicating
with
other
connections,
and
then
we
have
credential
issuance,
which
we'll
be
getting
into
a
little
bit
more
I'll.
Talk
about
this
transaction
author
agreement
a
little
bit
more
then
too,
mediation
and
routing
will
be
unused
for
today.
My
credentials,
which
list
off
the
credentials
received
by
this
agent
and
a
set
of
presentations
that
have
been
received.
Verification,
on
the
other
hand,
is
requesting
credentials
from
a
connected
agent.
D
D
D
E
The
endpoint
info
and
routing
keys
are
sent
to
make
sure
that
a
message
that
bob
sends
back
to
alice
can
reach
her
and
the
label
is
who
alice
says
she
is
so.
This
is
not
a
verifiable
attribute,
but
more
of
a
suggestion
and
a
convenient
way
to
identify
the
information,
the
invitation
and
we
can't
absolutely
trust
it
and
identity
verification
should
happen
after
the
connection
is
formed.
E
So
here's
what
that
invitation
message
look
looks
like
here.
We
have
the.
We
see
that
the
message
type
is
a
connections
invitation
and
then
it
includes
the
label,
recipient
keys,
service,
endpoint
and
routing
keys.
That
I
mentioned,
and
so
after
bob
receives
the
invitation.
If
he
does
want
to
connect
with
alice,
he
will
send
a
connection
request
back
to
alice's
agent,
so
this
will
contain
a
label
similar.
E
E
So
bob
knows
that
this
response
came
from
alice,
the
same
person
who
originally
created
the
invitation,
and
so
now
that
the
dids
and
did
docs
have
been
exchanged.
This
connection
has
been
established
and
a
few
quick
notes
on
forming
connections
using
did
come.
These
are
peer-to-peer
connections
that
were
forming
and
again
they
are
not
necessarily
direct.
They
could
use.
E
A
third
party
like
a
mediator
is
probably
a
good
example,
and
it
is
actually
built
into
the
capabilities
of
they
come
to
have
a
message
crowded
through
a
third
party,
but
whatever
third
party
is
arranged
to
hold.
These
messages
cannot
see
the
contents
of
the
messages
since
they
are
ended
and
encrypted
between
alice
and
bob
as
daniel
mentioned
earlier.
The
connection
is
not
a
transport
layer
connection
like
socket
or
open
http
request,
et
cetera.
E
E
E
This
invitation
to
bob
should
show
up
here
under
invitations,
and
then
we
can
click
into
it,
and
there
is
a
copy
url
button
that
will
allow
us
to
grab
that
url,
the
invitation
url
and
then
on
bob's
interface.
We
will
navigate
to
connections
and
paste
in
this
invitation.
Url
once
we
click
add,
we
should
see
alice,
show
up
under
bob's
active
connections,
and
then
we
can
also
verify
on
alice's
side
that
we
see
that
bob
is
one
of
her
connections.
D
Okay,
so,
as
shaw
noted,
we'll
first
start
off
on
the
alice
agent
view
here
and
I'm
going
to
return
to
a
couple,
questions
that
were
seen
in
the
chat
as
well
in
just
a
moment,
so
we
will
on
the
alice
agent
optionally
you
can
put
in
an
alias
if
you'd
like
to
help.
You
identify
a
particular
invitation.
D
D
D
Alice
now
has
it
we
can
copy
the
url,
and
then
we
will
go
to
bob's
side
window
here
then
navigate
to
connections
just
below
invitations
and
paste
into
the
invitation,
url
box
here
and
then
click
the
add
button.
This
will
happen
pretty
fast.
We
now
already
see
alice's
connection
in
bob.
I
go
back
to
the
connections
instead
of
instead
of
invitations
connections.
Bob
shows
up
for
alice,
and
so
we
now
have
alice
and
bob
connected.
D
D
So
that's
why
we
can
send
a
message
directly
to
the
toolbox.
The
toolbox
itself
is
actually
a
connection
of
alice,
and
so
when
we
look
into
alice
and
see
her
view
of
the
world,
we
see
the
tool
box
present
there.
We
just
have
a
limited
set
of
functionalities
that
we
support
with
the
toolbox,
and
so
we
don't
do
verifiable
credentials
exchange
here
and
that's
why
we've
got
bob
to
interact
with.
D
D
So
a
message
was
sent
by
view
messages
on
bob
and
then
select
the
alice
conversation.
I
see
that
message
has
arrived
so
what's
occurring
on
the
other
side,
then,
is
bob
on
receipt
of
a
new
message.
The
toolbox
plugin
captures
that
event
and
sends
a
new
message
to
the
toolbox,
which
then
updates
our
window
here.
D
D
I
think
this
is
more
reflective
of
a
controller
scenario,
so
if
we
think
back
to
the
controller
which
is
interacting
with
occupy
over
the
admin,
api
and
http,
we
typically
use
that
from
in
the
enterprise
perspective,
that
is
where
occupy
is
well
suited
for
mobile
agents.
Usually,
we
would
like
to
have
all
the
data
as
close
to
the
user
himself
as
possible
him
or
herself
as
possible.
D
So
a
wallet
is
stored
on
the
actual
mobile
device
in
the
base
case,
and
that's
where
all
the
secrets
and
private
values
are
shared.
That
mobile
agent
is
then
capable
of
contacting
directly
the
aries
cloud
agent
python
and
then,
on
the
other
end
of
that
exchange,
the
enterprise
user
can
interact
with
aries
cloud
agent
python,
with
their
controller,
so
toolbox
is
analogous
to
controller
as
opposed
to
a
mobile,
app
interface.
However,
that
is
technically
possible
as
well.
That
is
not
certainly
out
of
the
question
by
any
means.
D
Okay,
so
I'll
I'll
do
a
little
bit
more
discussion
here
in
the
connections
tab.
So
if
we
expand
the
bob
list
item
here,
we
see
a
little
bit
of
interesting
information
which
I
know
has
been
partially
addressed
by
sam
already.
This
is
the
did
for
alice
that
bob
uses
for
that
relationship.
If
that
makes
sense,
this
is
unique
from
any
other
did
that
alice
has
in
her
wallet.
She
only
uses
it
with
bob.
D
This
is
a
peer
d
id
this
did
is
never
written
to
a
ledger
because
we
like
to
keep
these
dids
private,
so
the
context
of
that
did
remains
something
that
is
only
present
within
our
wallet.
This
removes
points
of
correlation
that
can
be
used
to
fingerprint
attack
people
and
observe
traffic
as
it
blows
between
parties.
D
D
This
is
a
topic
of
ongoing
work
within
the
occupy
community
occupy
as
a
very
early
entrant
into
the
identity,
agent
game
and
one
of
the
first
hyperledger
aries
agents
has
a
little
bit
of
a
history
behind
it
that
I
won't
get
into
too
much
detail.
But
this
is
an
ndd
id,
an
indie
nim.
If
you
will,
and
in
the
very
near
future
these
will
properly
be
prefixed.
In
all
views
of
this,
the
id.
E
I'll
also,
briefly,
call
out
that
we
are
using
indie
and
on
creds
as
daniel
mentioned
earlier,
for
this
workshop.
So
there
are
specific
schema
and
credential
definition.
Requirements
specific
to
a
non-creds
occupy
is
also
capable
of
w3c
credentials.
That's
not
something
we're
covering
in
this
workshop,
but
yeah
just
to
just
to
mention
that
the
indie
and
non-cred
specification
enables
new
knowledge,
proofs
and
selective
disclosure
of
credential
attributes,
so
it
has
better
privacy
guarantees
for
verifiable
credentials
and
also
allows
for
replication,
and
so
now
we
will
talk
about
the
issuer
in
context.
E
This
this
diagram
should
look
a
little
bit
familiar
from
what
scott
talked
about
earlier.
We
have
the
issuer,
the
holder
and
the
verifier
again,
and
so
we
will
focus
now
on
the
steps
that
the
issuer
takes
to
issue
a
credential,
so
the
issuer
needs
to
write
a
did,
schema
and
credential
definition
to
the
ledger
and
after
that
they
can
sign
and
issue
the
verifiable
credential
and
now
the
holder
has
the
credential
and
so
we'll
break
down
each
of
these
steps
and
work
through
it
in
a
demo.
E
So
again,
this
first
step
the
pre-issuance
steps
are
to
anchor
the
public
did
to
the
ledger:
write
a
new
schema
to
the
ledger
or,
alternatively,
you
could
retrieve
a
pre-existing
schema
from
the
ledger
and
then
use
that
schema
to
write
a
credential
definition
to
the
ledger
and
then
finally
issue.
The
verifiable
credential,
so
we
will
start
with
this
first
step
of
anchoring
a
did.
E
This
is
just
briefly
reminding
us
of
what
lynn
talked
about
earlier.
With
the
endorser
and
author
roles.
Again,
the
endorser
can
has
privileges
to
write
to
the
ledger.
The
author
authors,
the
transactions
in
this
demo.
Our
issue
will
have
both
the
endorser
and
author
role,
so
our
issue,
where
we'll
create
the
the
transaction
and
then
endorse
it
and
write
to
the
ledger
as
well,
and
then
we
also
need
to
sign
the
transaction
author
agreement
as
lin
mentioned
earlier.
E
So
now
we
will
navigate
back
to
the
toolbox
and
in
this
interaction,
alice
is
acting
as
our
issuer
and
so
we'll
navigate
to
the
dids
page
on
alice,
and
then
we
will
also
pull
up
the
ndco
self-serve
website.
That
lin
showed
us
how
to
use
earlier
where
we
can
get
an
ndo
endorser,
and
we
want
to
use
the
test
net
to
sit,
because
this
is
a
demo
and
then
we
will
copy
and
paste
the
did
and
the
verification
key
into
the
self-serve
website.
E
Like
so
and
then
after
clicking
submit,
we
will
just
make
sure
that
we've
gotten
a
200,
okay
response
and
then
back
on
alice
the
issuer.
We
need
to
activate
the
dead,
so
we
can
either
use
this
activate
did
button
or
we
can
select
the
did
that
we
want
from
the
drop
down
menu
at
the
top,
and
once
we
do
that
this
did
will
show
up.
D
D
So
we'll
start
off
on
the
alice
side,
which
is
going
to
play
the
role
of
ishwar
in
our
exchange
that
we're
about
to
trigger
so
we'll
first
go
to
dids,
so
we
can
create
a
new
public
did
for
alice.
This
will
trigger
the
transaction
author
agreement
page
coming
up
as
this
does.
This
module
requires
signing
of
the
transaction
author
agreement
as
we'll
be
influencing
the
writing
of
transactions
to
the
ledger.
With
this
module,
this
will
bring
up
the
text
of
the
transaction
author
agreement.
D
D
And
now
we
are
able
to
interact
with
this
dids
section
here,
so
I'm
going
to
create
a
new.
Did
I'm
going
to
give
it
a
label
of
public
just
to
help
me
easily
identify
that
this
is
the
id
that
I've
written
to
the
ledger.
So
to
clarify,
though
this
is
only
creating
the
did
in
order
to
actually
get
it
on
the
ledger,
we'll
be
taking
the
steps
that
share
described
going
through
the
self-serve
application
so
back
to
our
handout
page.
D
Here,
I'm
going
to
click
on
the
dco
self-serve
link
and
the
other
resources
used
section
which
will
bring
up
the
self-serve
app
I'll
jump
back
to
alice,
expand
the
public
did
I
just
created,
so
I
can
see
the
attributes
of
the
did
copy.
The
did
value
out
here
paste
into
this
field
here
and
then
copy
the
key
or
verification,
key
value
and
paste
here
I'll
hit
submit
and
we
get
back
a
status
of
200,
okay
and
a
message
saying
that
we've
successfully
successfully
written
our
nim
identified
by
this
did
to
the
ledger
with
role
endorser.
D
D
E
Okay,
so
the
next
issuer
step
is
to
write
or
retrieve
a
schema,
and
so
a
schema
is
the
data
organization
structure
that
defines
the
attributes
in
a
credential
so
for,
for
example,
in
an
employee
credential,
the
schema
would
likely
have
first
name
last
name
address
date
of
higher
security
clearance.
Anything
that
any
any
of
the
information
that
the
employee
that
the
employer
wants
to
verify
about
the
employee,
employee,
and
so
this
is
what
the
json
of
the
schema
looks
like.
E
It
has
a
schema,
name
version
id
and
shows
the
attributes
here,
that's
just
first
name
last
name
and
age
and
after
we
have
written
the
schema
to
the
ledger,
we
can
also
see
it
on
the
ledger,
using
the
indie
scan
tool
that
lin
demonstrated
earlier
and
if
you
are
retrieving
a
pre-existing
schema.
This
is
where
you
want
to
retrieve
that
schema
id,
and
so
for
a
quick
demo
of
how
to
create
a
schema
in
the
toolbox.
E
So
this
could
be
1.0
or
1.0.0
and
then
you'll
want
to
add
in
attributes
here
we're
just
keeping
it
really
simple
with
name
and
age,
and
these
must
be
all
lowercase
and
if
they
include
multiple
words,
they
must
be
connected
by
an
underscore,
and
so
once
you
click
create
or
confirm.
You
should
be
able
to
see
the
schema
listed
here
under
your
schemas,
and
so
now
that
we
have
created
a
schema.
We
can
use
this
to
write
a
new
credential
definition
to
the
ledger,
and
so
a
credential
definition
creates
the
issuer.
E
Yes,
this
credential
was
issued
by
the
specific
issuer
and
so
creating
the
credential
definition
generates
cryptographic
keys
for
each
attribute,
with
both
a
public
and
a
private
portion,
and
the
public
portion
is
stored
on
the
ledger
with
the
schema.
This
is
what
allows
the
verifier
to
verify
that
the
issuer
issued.
The
credential
and
the
private
key
portion
is
maintained
by
the
issuer,
and
the
issuer
uses
these
to
sign
each
attribute
and
they
need.
E
E
E
So
now
we
will
do
a
quick
toolbox,
walkthrough
of
creating
a
credential
definition
from
the
same
schema
that
we
just
created,
and
so
under
credential
definitions
we
will
click
create.
This
will
bring
up
a
window
that
allows
us
to
choose
from
a
drop
down
menu
of
our
available
schemas,
and
here
we
just
have
the
one.
D
D
Well,
we've
alluded
to
revocation
rather
and
there's
been
a
few
questions
relevant
questions
in
the
chat
regarding
revocation,
you
can
find
more
details
on
each
of
those
topics
within
the
additional
reading
in
the
handout,
while
we're
here
I'll,
also
really
quickly
bring
up
the
nd
scan
page
that
we
can
actually
view
the
transactions
for
on
the
ledger.
So
if
I
go
to
domain,
I'm
going
to
do
a
really
quick
scan
for
my
the
id
that
I
just
anchored
to
the
test
net
over
here.
So
that's
a
dzd.
D
So
this
is
a
an
interesting
way
to
explore
the
transactions
as
they
arrive
on
the
ledger,
as
lynn
very
aptly
pointed
out
earlier
now,
as
we're
creating
the
ids
here
with
the
toolbox
and
anchoring
them
with
the
self-serve
app,
we
should
see
them
showing
up
there
same
thing
with
the
schema
that
we'll
create
in
just
a
second.
So
I'm
going
to
do
that
now,
skipping
over
to
alice
going
to
credential
issuance,
which
is
about
in
the
middle
of
the
list
here,
so
I
will
create
a
schema,
do
what
am
I
gonna?
D
D
D
D
D
This
is
very
simple:
we
just
select
the
schema
and
say
confirm
so,
as
char
pointed
out,
this
does
take
just
a
moment
the
reason
for
that
being
that
it's
generating
rsa
keys
in
the
background
for
each
of
those
attributes.
So
it
can
later
use
that
in
the
credential
issuance
process
for
those
who
are
unfamiliar
with
rsa
keys,
they're,
a
relatively
computationally
intensive
key
to
generate
so
it
takes
just
a
moment
there.
But
now
we
have
our
credential
definition.
D
So
we
now
see
our
credential
definition.
The
credit
id
here
looks
very
similar
to
the
schema,
because
we
are
both
the
issuer
or
issuers.
The
wrong
word
author
of
the
schema,
as
well
as
the
credit
fide,
so
it
is
prefixed
with
the
same
value
which
is
rtid.
I
should
call
that
out
a
little
bit
more
explicitly
and
then
there's
some
version
information,
the
name
of
the
schema
and
the
schema
version.
D
E
No
matter,
no
matter
which
party
initiates
the
interaction
so
once
the
holder
receives
that
they
can
request
credential
and
then
once
the
issuer
receives
that
they
will
issue
the
credential
to
the
holder,
and
once
the
holder
receives
the
credential,
they
will
send
an
acknowledgement
back
to
the
issuer
and
then
their
side
of
the
interaction
is
complete
and
when
the
issuer
receives
that
acknowledgement
as
well.
Their
set
of
interaction
is
complete
too,
and
so
a
quick
note
that
this
language
is
a
bit
awkward
and
not
how
people
would
naturally
talk
about
this
interaction.
E
E
D
D
D
D
And
then
we're
going
to
add
some
values
for
our
attributes
that
we're
issuing
in
this
credential.
So
in
the
real
world.
This
would
obviously
look
a
little
bit
different
if
we
actually
wanted
to
emit
binding
credentials.
We'd
go
through
some
process
to
actually
verify
the
init,
the
identity
of
the
person.
On
the
other
end
of
the
connection,
whether
we
use
analog
credentials
for
bootstrapping
into
that
system
or
not
or
some
other
mechanism,
usually
we
won't
just
say
yeah.
D
D
D
D
The
occupy
instance
we're
using
has
been
configured
to
automatically
accept
those
credential
offers
in
in
normal
circumstances.
That
would
normally
be
something
we'd
allow
the
user
to
decide
whether
they're
going
to
accept
the
credential
or
not,
and
then
a
credentials
exchange
took
place
between
the
two
parties,
and
this
was
the
exchange
that
shah
described
where
credential
offer
was
sent.
Credential
request
was
sent
back
from
bob
and
an
issue
credential
message
sent
from
alice
to
bob
and
then
credential
acknowledgement
sent
back
to
alice.
D
The
issue
credential
protocol
is
pretty
well
defined.
You
can
find
it
in
the
aries
rfc
repository,
but
I
think
it's
worth
briefly
calling
out
that
the
in
indian
non-credits
workflows
we
start
from
either
proposed
credential
or
offer
credential,
and
that
is
because
there
needs
to
be
some
exchange
of
of
blinded
secrets
between
alice
and
bob
in
that
process.
D
Other
credentialing
systems
might
have
fewer
requirements
on
the
number
of
messages
exchanged
back
and
forth,
such
as
json
ld
based
credentials.
However,
that
does
come
with
the
downside
of
in
json
ld
credentials.
You
lack
private
holder
binding,
which
is
the
ability
to
say
that
this
credential
and
this
credential,
while
distinct
objects,
can
be
strongly
correlated
back
to
a
single
holder
for
both
credentials.
If
they
were
issued
to
the
same
individual.
D
Mathias
in
chat
brings
up
a
good
point
that
I'll
bring
up
as
a
brief
aside.
So
all
this
communication
taking
place
between
alice
bob
and
the
toolbox
is
taking
place
over
an
http
connection
technically
between
the
toolbox
and
alice.
It's
actually
a
websocket
connection,
but
it
is
taking
place
over
https
or
websockets
with
ssl
and
same
between
alice
and
bob.
So,
while
did
com
provides
the
security
necessary
to
ensure
that
alice
and
bob
are
the
only
ones
able
to
view
those
messages.
D
We
still
strongly
recommend
using
secure
transports,
especially
when
we're
talking
about
the
internet
here,
where
anything
could
happen,
and
I
will
not
even
pretend
to
say
that
did
come.
Security
has
been
as
thoroughly
vetted
as
https
so
again,
taking
advantage
of
the
transport
to
augment
the
security
of
our
system
is
wise.
D
Okay,
so
thank
you
matias,
matthias.
I
might
be
pronouncing
your
name
incorrectly.
I
apologize,
but
that
was
a
good
good
point
to
call
out
there,
so
we
now
have
issued
a
credential
from
alice
to
bob
and
another
thing
that
comes
to
mind.
That
baer
is
mentioning
is
in
indian
on
non-credit
systems.
There
is
no
indication
on
any
ledger
whatsoever
that
this
credential
was
issued
from
alice
to
bob.
The
only
records
on
the
ledger
are
that
of
the
schema
and
the
credential
definition.
D
D
D
D
So
the
two
are
not
technically
synonyms.
The
schema
is
just
attributes
a
listing
of
attributes
and
the
credential
definition
contains
the
did
of
the
issuer,
who
will
be
using
that
credential
definition
and
the
public
values
of
the
keys
used
to
issue
the
credential?
Ultimately,
so
it's
it's
through
the
credit
def,
as
opposed
to
the
schema
that
we're
actually
able
to
perform
verification
later
on
using
the
ledger
as
the
source
of
truth
for
those
keys.
D
Another
question
that
has
come
up:
how
does
the
requester
view
the
credential
issuance
if
it's
not
viewable
in
the
ledger,
not
exactly
sure
which
part
you're
referring
to
when
you
say
requester,
but
I
will
say
so-
did
come
as
a
peer-to-peer.
Interaction
already
establishes
that
there
is
a
a
clean
and
secure
communication
channel
between
two
parties.
So
all
information
is
is
transmitted
over
that
channel.
D
E
So
now
that
we
have
issued
a
credential,
we
can
now
practice
verifying
it,
and
so,
whereas
the
issuer
had
to
decide
which
credentials
to
issue
whom
the
verifier
must
decide
who
and
what
to
trust,
and
so
to
do
that,
they
will
interact.
With
the
holder,
read
from
the
ledger,
perform
cryptographic
computations
to
verify
that
the
attributes
presented
were
issued
by
that
specific
issuer.
E
E
For
example,
if
an
employer
issues
an
employee
credential,
they
might
want
to
verify
that
to
identify
the
employee,
but
we
also
just
want
to
emphasize
that
the
issuer
under
verifier
can
be
different
entities
who
do
not
interact
and
cannot
gather
or
exchange
information
about
the
holder
without
the
holder's
knowledge
or
consent.
But
they
are
able
to
trust
each
other,
as
scott
mentioned
at
the
beginning
of
this
workshop,
because
they
write
and
read
from
the
ledger,
and
so
we
will
return
again
to
this
diagram,
where
we
saw
the
steps
for
issuing
a
credential.
E
But
now
we'll
move
to
the
verifier
side,
and
so
first
a
presentation
must
be
created
either
the
verifier
requests,
presentation
or
the
holder
offers
presentation
we're
going
to
focus
today
on
the
verifier
requesting
presentation
and
then
upon
receipt
of
the
presentation.
The
verifier
reads:
the
did
schema
and
credential
definition
from
the
ledger
and
verify
statisticians,
and
so
here
again
we
will
show
the
flow
of
messages
necessary
to
verify
a
credential
and
again
this
is
more
of
a
developer
friendly
language
than
the
way
that
people
would
normally
talk
about
this
interaction.
E
We
want
to
show
what
the
message
flow
looks
like
so
optionally.
The
holder
can
propose
a
presentation
which
would
trigger
a
presentation,
request
message
from
the
verifier
or
if
the
verifier
is
initiating,
they
would
start
this
interaction
with
the
presentation
request
and
then
the
message
flow
is
the
same
regardless
of
who
initiated,
and
so
if
the
holder
wants
to
approve
this
request,
they
can
do
so
and
then
send
a
presentation
back
to
the
verifier.
E
Then
the
verifier
must
verify
the
presentation
and
then
they
will
send
an
acknowledgement
back
to
the
holder,
once
they've
sent
their
acknowledgement,
their
senate
interaction
is
complete
and
the
holder
receives
the
acknowledgement
and
the
presentation.
Interaction
is
confused
and
so
to
verify
a
credential
we'll
have
the
verifier
request
a
presentation
from
the
holder
and
indicate
which
attributes
from
which
credentials
should
be
presented.
E
And
so
back
to
the
toolbox,
where
alice
is
now
acting
as
the
verifier,
we
will
navigate
to
the
verification
tab
at
the
bottom
left
of
alice's
interface,
and
we
will
choose
to
request
a
presentation
which
brings
up
a
window
where
we
can
choose
the
connection.
We
will
request
a
presentation
from
the
holder
bob.
E
We
can
add
a
name
to
the
presentation
and
optionally
add
a
comment,
and
now
we
can
add
in
the
attributes
that
we
want
to
verify
and
then
we
can
select
the
credential
definition
id
under
restrictions.
If
we
want
to
say
we
don't
want
to
verify
the
value
of
this
attribute
from
just
any
credential,
but
only
from
this
specific
credential
associated
with
this,
this
credential
definition
id
that
might
be.
E
E
So
we
can
create
that
verification
request,
and
now
we
see
that
this
presentation
was
requested
from
bob.
So
now
on
bob's
window,
we
can
navigate
to
presentations
and
we
see
that
his
this
presentation
shows
up
under
his
list
of
presentations
and
in
the
same
way
that
the
issuer
issues
credentials
from
this
credential
issuance
tab
and
then
the
holder
accesses
them
and
holds
them
in
the
my
credentials.
E
Tab
on
the
verification
side
of
that
the
verifier
uses
the
verifier
tab
to
verify,
request,
verification
and
the
then
those
show
up
as
presentations
for
the
holder
under
the
presentations
tab
and
so
before.
A
live
demo
of
verifying
a
credential.
We'll
just
talk
about
a
few
different
types
of
presentations.
So
we
have
just
shown
the
simplest
example
of
a
presentation
which
is
called
a
full
disclosure
presentation
in
which
all
the
attributes
are
revealed
from
one
verifiable
credential.
E
Another
type
of
presentation
is
the
multiple
credentials
presentation
or
the
composite
presentation
in
which
all
the
attributes
are
revealed
from
two
or
more
credentials,
because
one
single
credential
doesn't
contain
all
of
the
required
attributes.
So
this
this
might
occur
when
multiple
specific
identification
documents
are
required.
Like
a
passport
and
a
piece
of
mail
to
your
address,
let's
see
then
selective
disclosure
is
when
only
certain
required
attributes
are
revealed
from
one
or
more
verifiable
credentials.
E
E
D
Okay.
So
starting
off
again
with
our
alice
and
bob
agents,
we've
got
alice
to
reiterate
what
chara
just
described
a
moment
ago.
Alice
was
our
issuer
in
our
original
exchange,
but
we're
now
going
to
switch
roles
and
alice
will
become
a
verifier
char
already
said
all
this,
but
the
roles
of
a
particular
participant
within
an
india
non-credits
system
is
dynamic.
D
D
However,
it's
also
valid
to
call
out
that
alice
being
both
issuer
and
verifier
is
also
a
perfectly
valid
use
case
in
the
context
of,
for
example,
if
I
am
an
employer-
and
I
issue
a
proof
of
employment
credential
to
my
employees
and
then
later
when
they
come
to
the
employee
cafeteria.
If
I
want
to
offer
them
a
discount
based
on
proof
of
employment,
they
can
present
their
credential
proving
such
and
then
give
them
a
discount
on
their
sandwich
or
whatever,
and
because
I,
as
an
employer,
was
both
the
issuer
and
verifier.
D
That
was
not
instrumental
in
that
exchange.
It
actually
helps
decoupling
systems
within
an
organization.
I
don't
have
to
know
what
software
issued
that
credential.
I
just
know
how
to
need
to
know
how
to
verify
it
later,
using
the
same
decentralized
route
of
trust
in
the
form
of
the
hyperledger
and
the
distributed
ledger.
D
Let's
go
with
bob
and
we'll
put
some
name
to
this
I'll,
just
say
test
for
now,
since
I've
got
only
a
very
simple
dummy
credential
to
work
with
at
the
moment,
you
can
optionally
add
a
comment
now
I'll
ask
bob
to
reveal
some
attributes
about
himself
and
name
an
age.
I'm
cherry
picking
these,
of
course,
because
I
know
bob
has
those
attributes
in
his
in
his
wallet
as
issued
by
a
verifiable
credential.
D
D
D
Or
it
can
just
be
left
up
to
the
user
directly.
This
connection
would
like
to
see
these
attributes
about.
You
are
you,
okay,
with
that?
The
user
would
also
even
have
the
ability
to
select
which
credentials
to
supply
the
attributes
from
if
there
are
multiple
credentials
in
their
wallet
fulfilling
the
same
attributes.
D
So
we
should
be
able
to
see
evidence
of
each
of
those
steps
in
this
object.
So
we
see
our
presentation
request.
We
see
our
requested
attributes
here,
name
and
age.
I
said
those
backwards
there.
We
could
have
supplied
some
restrictions.
You
can
say
that
it
must
be
from
a
certain
credential
definition
id
or
a
certain
schema
or
a
certain
issuer.
D
D
We
see
some
occupy
specific
things.
We
see
the
actual
message
that
was
sent
as
the
presentation
request
here.
So
this
is
the
format
that
it
takes
not
quite
over
the
wire,
since
this
would
be
encrypted,
but
as
delivered
from
alice
to
bob
at
least,
and
it
is
a
present
proof.
1.0
request
presentation
with
an
attached
request,
presentations,
object,
and
this
is
a
generic
way
of
stuffing
credential
system,
specific
data
from
verifier
to
holder
in
order
to
communicate
the
credential
system
relevant
pieces.
D
D
Then
we
can
also
see
the
presentation
that
was
sent
back
from
bob.
I
see
the
raw
value
of
the
revealed
attribute,
as
well
as
the
encoded
value.
This
was
the
value
that
was
actually
used
in
the
cryptographic,
verification
process
and
the
age
with
its
encoded
value,
since
it
was
an
integer
value
already,
it
remained
an
integer
value
and
then
there's
also
opportunities
for
doing
cells
with
tested
attributes
and
occupies
support
for
credentialing
and
predicates.
D
We
also
have
some
unique
identifiers
here.
This
is
not
the
complete
set
of
the
presentation,
there's
some
incredibly
large
arrays
of
numbers
that
are
actually
omitted
from
this
data
structure.
So
this
is
not
perfectly
representative
of
what
data
is
sent
back
between
the
two,
but
for
peru's
perusability.
D
To
briefly
call
out
a
question
that
was
answered
in
chat
already,
which
cryptographic
solution
is
being
used
so
indie
a
non-creds
takes
advantage
of
the
let's
see
if
I
can
get
the
name
right,
comminish
the
I
forgot,
the
l
already
sorry,
whoever
l
that
was
and
who
came
up
with
that
signature
scheme.
But
there
are
more
details
in
the
handout
on
the
specifics
of
that
cl
signature
suite.
D
There
is
a
push
on
going
for
the
ability
to
use
different
signatures
within
a
non-creds.
That's
pretty
early
on.
It's
just
a
twinkle
in
somebody's
eye
at
this
point
honestly,
but
we
anticipate
that
bbs
plus
signatures
should
be
able
to
support
the
same
level
of
functionality
that
cl
signatures
are
supporting.
D
Yes,
I
should
call
that
out,
so
I
described
the
process
where
bob
would
approve
which
attributes
were
revealed
to
the
requester
for
the
sake
of
simplicity
within
the
toolbox
and
within
this
demonstration.
That
part
has
been
automated
out,
so
it
just
took
place
in
the
background
without
any
intervention
on
our
part.
D
But
within
the
admin
protocols
used
by
the
toolbox,
there
is
actually
a
mechanism
for
determining
which
credentials
we
would
like
to
use
and
sending
it
on
to
the
plugin.
So
the
toolbox
itself
is
just
assisting
and
automating
that
process.
I
believe,
even
if
we
check
our
message
list,
I
apologize
for
the
background
noise.
There's
a
yard
work
going
on
out
right
outside
my
window.
So
hopefully
that's
not
picking
up
too
clearly
on
my
mic.
C
D
I
might
have
clicked
away
too
frequently
for
it
to
be
visible
here,
but
on
receipt
of
a
presentation
request,
the
toolbox
plugin
will
send
a
message
to
the
toolbox,
saying
a
presentation
request
was
sent
in
it's
requesting
these
attributes.
These
are
the
credentials
that
would
fulfill
these
attributes
and
gives
them
the
opportunity
to
select
which
ones
so,
but,
as
I
said,
the
toolbox
does
not
currently
have
a
ui
to
expose
that
functionality.
Right
now,.
D
D
So
I'm
going
to
add
another
schema
and
credential
definition
to
the
mix
here
so
going
off.
Of
my
employee
cafeteria
example
from
before
I'm
going
to
go
with
employment
credentialing
and
at
the
same
time
as
I'm
typing,
this
out
I'll
also
call
out
that
schemas
are
separated
objects
from
credential
definitions
for
more
than
one
reason,
but
one
of
those
is
reusability
of
schemas.
So
within
a
governance
framework,
it
might
already
be
well
defined.
What
attributes
we
expect
to
be
presented
in
certain
contexts.
D
So
a
a
machine,
readable
governance
framework
might
include
the
schemas
that
we
are
willing
to
accept
credentials
from
and
accept
presentations
from
man.
That's
really
noisy,
I'm
sorry!
So,
while
I'm
coming
up
with
a
new
schema
for
employment,
it
is
certainly
possible
and
maybe
even
likely,
that
within
a
certain
legal
jurisdiction,
there's
already
a
well-defined
set
and
instead
of
creating
a
new
one,
I
should
go
and
reuse
one
that's
already
available
on
the
ledger.
D
D
It
also
writes
to
the
ledger,
which
is
a
not
instantaneous
process,
I
suppose
and
there's
our
credential
definition,
and
we
see
the
attribute
state
of
higher
and
access
level,
so
we'll
now
go
ahead
and
issue
the
credential
to
bob
using
that
employment
credit
id.
This
form
is
automatically
populated
with
the
attributes
that
we
need
to
give.
As
part
of
that
credential
definition
add
a
comment
here
of
proof
of
employment,
for
the
heck
of
it
and
say
date
of
fire
is,
I
don't
know,
20
20
january
1st.
D
Good
question
in
the
chat:
can
you
edit
schemas
or
just
create
new
ones
with
another
version,
and
the
answer
that
came
back
is
correct.
You
would
just
create
a
new
schema
with
a
new
version,
so
the
schema
will
remain
on
the
ledger
and
remain
in
use
and
it
kind
of
becomes
a
business
policy
decision
to
say
whether
you
should
be
using
one
versus
another
or
a
governance
decision
as
well
and
I'll
continue
with
my
credential
issuance
here
saying.
Access
level
is
basic.
D
If
I
go
to
my
credentials
on
bob,
I
see
the
new
credential
has
been
received
from
alice
and
see
those
same
attributes
I
realize
now.
I
didn't
explore
at
all
previously
what
values
are
returned
in
this
json
structure
here,
so
that
might
be
of
interest
you
can
see
in
the
raw
credential
attribute.
We
see
the
schema
id
and
cred
fid.
We
see
the
values
with
their
encoded
representations.
D
D
D
D
D
D
And
sam
has
clarified
in
the
chat
that
pbs
plus
allows
for
selective
attribute
disclosure,
but
does
not
have
built
into
it.
Predicate
the
ability
to
do
predicate
proofs
using
zero
knowledge
proofs,
blinded
holder,
binding,
I'm
not
sure
if
that's
actually
accurate
or
not
sam
but
I'll,
defer
to
sam
on
that
one
and
say
that
he's
probably
right.
D
Okay,
so
we're
going
to
request
a
predicate
proof
from
bob
for
his
age
greater
than
or
equal
to
21,
so
that
bob
can
buy
some
age-restricted
product.
I
like
that
terminology
that
scott
was
using
earlier,
so
I'm
going
to
steal
that
and
we're
going
to
say
that
it's
going
to
be
a
requirement
to
be
from
this
credential
as
a
stand-in
for
being,
perhaps
a
government-issued
id
from
you
know,
dmv
as
a
driver's
license
or
some
other
issuer
that
we're
willing
to
trust
to
have
verified
that
age
accurately.
D
D
I
feel
like
I've
repeated
those
same
words
multiple
times.
So
if
that
didn't
come
out,
any
more
clearly
feel
free
to
ask
more
clarifying
questions
in
the
chat
and
I'll
give
somebody
else
an
opportunity
to
do
a
better
job.
If
alice
weren't
the
issue
or
two
could
restrictions,
show
the
credential
definitions.
D
That's
a
good
question
in
the
ui,
so
if
alice
was
not
the
original
issuer
of
the
credential,
the
ui
is
currently
structured,
such
that.
If
we
want
to
impose
one
of
those
restrictions,
we
need
to
know
about
the
credit
id
already
so
in
the
credential
issuance
tab,
and
this
is
something
we
haven't
used
yet
here.
D
D
It
did
okay
good
to
know
so
we
see
that
it
has
the
level
and
date
and
then,
within
the
verification,
tab
we
can
oops
on
requesting
an
attribute.
We
can
use
that
credit
id
so
that
process
that
I
just
went
through
is
more
or
less
a
manual
discovery
process
for
already
out
there,
credential
definition
ids.
D
D
Another
question
that
came
in
here
is
mediation,
part
working
in
the
toolbox.
That's
an
excellent
question,
so
mediation
this
was
added
to
the
toolbox
at
the
same
time
as
it
was
being
developed
for
the
aries
cloud
agent
python
code
base.
So
these
two
sections
allow
us
to
request
mediation
from
one
of
our
connections
from
both
the
toolbox
and
the
connected
agent's
perspective.
D
D
D
C
D
Cool
yeah,
that's
that's
my
understanding
as
well.
The
transaction
and
the
credential
definition
itself
are
closely
tied
as
identifiers
for
that
transaction.
So
that
appears
to
be
the
case,
but
I
can't
say
that
I've
got
that
knowledge
in
the
forefront
of
my
mind,
to
say
for
sure.
Let's
see
other
questions,
can
you
give
us
some
info
about?
The
mediator
might
come
back
to
that.
I
did
allude
to
some
more
resources
there.
Hopefully,
that
is
a
good
location
to
get
some
more
until
there
can
you
walk
through
the
parameters
in
the
indie
scan.
D
Please
I'm
again
not
the
expert
on
indie
scan
so
I'll.
Let
lynn
correct
me
at
any
point
here,
but
these
filters
at
the
top
here
correspond
to
the
transaction
types
that
are
possible
on
an
nd
network.
So
nim
corresponds
to
the
writing.
Of
a
did
to
the
indie
network.
Name
is
kind
of
an
antiquated
term.
Originally
meant
was
short
for
verinem,
so
at
hyperledger
indy
has
a
decentralized
identity
solution
that
actually
predates
the
w3c.
Did
specification
uses
some
different
terminology
in
a
few
different
places,
so
nim
is
did
rights.
D
A
trib
are
more
or
less
arbitrary
metadata
that
you
can
associate
with
a
nim.
This
was
a
precursor
to
the
document
again,
given
the
historical
background
there
as
a
as
it
predated.
The
did.
Spec
schema,
of
course,
corresponds
to
schema
transactions,
claim
death
this
again
a
bit
of
a
historical
context
thing
here,
too,
claims
used
to
be
referred
to
or
excuse
me
credentials
used
to
be
referred
to
as
claims
that
was
even
persistent
in
the
w3c
space
for
a
while
before
they
switched
to
the
term
credential.
D
D
D
So,
by
taking
the
original
tales
file
and
replaying
all
the
revocation
registry
entries,
we
get
an
updated
list
of
what
credential
identifiers
are
within
the
set
and
whether
they've
been
revoked
or
not
again,
that
kind
of
gets
into
the
weeds
a
little
bit
on.
Revocation
some
more
details
can
be
found
in
the
handout
for
links
to
info.
There
set
context,
I'm
not
actually
sure
what
that
one
is.
So
I
couldn't
tell
you.
C
I'm
not
actually
sure
what
that
one
is
either,
but
I
will
add
a
little
bit
here
over
the
course
of
our
training
today.
The
updates
to
indie
scan
have
been
as
much
as
15
minutes
behind
and
the
reason
for
that
is
because
indie
scan
has
some
settings
in
it
that
make
it
so
that
it
it
doesn't
cause
a
ddos
or
a
lot
of
traffic
on
the
ledger.
C
It
just
pulls
a
couple
of
transactions
at
a
time,
and
so
it's
been
regularly
updating
throughout
the
course
of
people
adding
a
bunch
on,
but
it
it
does
get
behind.
I
think
it's
about
four
minutes
behind
right
now
it
just
kind
of
gradually
updates
itself
and
just
a
few
transactions
at
a
time,
so
apologies
for
it
not
being
so
quick,
but
that's
because
it
doesn't
because
we
don't
want
it
to
have
an
impact
on
the
response.
Time
of
the
ledger.
So.
D
Cool
thanks
lynn,
there's
been
a
little
bit
of
back
and
forth
in
the
chat.
I
think
sam's
done
a
good
job
of
addressing
that.
One
and
again,
I
think
we're
at
a
point
where
we
should
just
be
linking
to
some
more
resources
for
you,
as
we
wrap
up
here
on
the
topic
of
mediators,
indicio
does
run
a
public
mediator
that
you
can
use
for
development
purposes
kind
of,
as
a
you
know,
reduced
barrier
to
entry
for
developing
a
mobile
agent.
D
A
Okay,
the
for
the
last
section
here
we
want
to
talk
about
community
engagement
and
how
to
how
to
get
involved
in
the
community
or
both
receive
help
and
and
contribute
effort
to
the
to
the
things
that
are
available.
And
so
that's
what
that's
what
I'm
talking
about
in
this
final
segment.
I
realized
that
we're
within
20
minutes
of
the
end
of
the
training.
A
I
will
try
to
make
this
useful
and
brief,
as
as
part
of
that,
I'm
talking
about
this
because
I've
got
a
bunch
of
experience
doing
this
daniel
and
I
were
both
around
before
ares
was
aries
and
so
we've
been
involved
there.
I'm
still
a
co-chair
of
the
hyperledger
aries
working
group
here
within
hyperledger,
I'm
also
the
co-chair
of
the
diff
did
come
working
group
and
I'll
talk
that
about
that
in
a
minute.
A
This
right
here
is
the
avatar
that
you'll
see
on
all
the
places
and
that
and
I'm
telegram
salmon
most
of
them,
and
so,
if
you
see
me
on
github
or
or
on
twitter
or
something
else,
please
reach
out,
I'm
an
I'm
an
architect
for
in
dco,
and
so
I'm
involved
in
addition
to
the
community.
I'm
involved
with
lots
of
of
customers
and
helping
guide
them
to
appropriately
apply
the
the
solutions
that
this
space
offers
so
reasons
to
engage.
A
There's
a
lot
of
there's
a
lot
of
reasons
to
engage
and,
and
the
I'm
not
going
to
read
the
slide
here.
But
the
the
point
that
I
want
to
to
mention
is
that
there's
various
levels
of
engagement
here,
you
can
jump
into
help.
You
can
jump
in
there's
lots
of
people
who
who
join
the
community
to
to
kind
of
lurk
and
listen
and,
and
sometimes
it's
a
long
time
or
never
before
they
they
either.
You
know
mention
something
in
a
meeting
or
comment
on
an
issue
and
that's
okay.
A
There's
a
handful
of
different
organizations
that
relate
to
aries
the
most
obvious.
One,
of
course,
is
the
hyperledger
foundation.
That's
where
the
aries
project
is.
We've
also
talked
a
lot
about
indy
and
and
and
we've
engaged
that
in
our
examples
today,
aries
works
with
lots
of
ledgers
and
and
strives
to
work
with
even
more,
but
india
is
one
of
them
and
and
that's
sort
of
historically.
What
ares
was
born
out
of
the
other
project.
A
A
It's
very
similar,
but
some
important
changes
that
both
improve
the
protocol
generally
and
make
it
more
usable
by
a
larger
community.
There's
other
working
groups
there
there's
an
identify,
identifiers
and
discovery
working
group
and
claims
and
credentials
those
those
all
sound
like
very
similar
things.
A
side
tree
is
a
technology
that
was
that
was
organized
there,
and
this
can
all
be
found
at
identity.foundation
is,
is
where
their
site
is
and
where
you
can
find
additional
information.
A
Another
useful
organization
in
the
space
is
is
the
trust
over
ip
foundation.
Here
is
their
logo
and
their
in
their
their
uri
they've
been
done,
some
really
cool
things.
They
focus
on
governance
and
one
of
the
thing
projects
they've
been
involved
with.
Is
the
good
health
pass
initiative
linked
here
and
we'll
have
these
slides
later?
Is
they
have
a
really
cool
layer
model
of
the
trust
layer
that
showed
up
in
an
earlier
slide
at
the
very
beginning
of
our
training
today,
and
so
that's
worth
exploring
as
well?
A
A
Well,
I
hope
we
can
find
a
resolution
to
that.
Now
you
can
see.
Okay,
the
the
the
ccg
has
been
involved
in
two
important
things.
One
is
the
w3c
credential
format
and
the
other
one
is
the
is
the
did
core
spec
that,
of
course
we
rely
on
so
the
the
the
ccg
is
available
there
as
well.
So
these
are
communities
that
you
may
want
to
get
involved
with,
or
that
relate
peripherally
to
the
aries
work
and
and
where
you
can
find
them.
A
So
when
you
engage
with
a
with
the
community,
often
a
bunch
of
the
work
is
done
in
in
in
working
groups.
Working
groups
communicate
typically
via
some
sort
of
chat,
like
slack
or
rocket
chat.
There's
almost
always
an
email
list,
and
there
are
regular
working
group,
calls
that
you
can
join
or
listen
to
the
recordings
for
the
calls
within
this
is
very
true
of
hyperledger
and
also
true
of
most
other
organizations.
There's
an
anti-trust
policy
and
a
code
of
conduct.
A
I
don't
mean
to
imply
that
they
only
apply
to
the
calls
they
apply
to
all
of
the
interactions
of
the
working
group.
These
these
groups
are
formed
of
people,
typically
that
represent
companies,
although
sometimes
individuals
that
are
in
competition
with
each
other
and
and
find
that
that
it
is
worth
engaging
in
in
standardizing
and
working
together
on
some
aspects
of
their
business.
So
we
call
that
co-op
petition.
A
So
here's
the
basic
rules,
we
don't
we
don't
discuss
business
deals,
we
don't
discuss
any
sort
of
pricing
in
those
calls
and
just
focus
on
the
technology
projects
itself.
The
code
of
conduct
is
also
very
important.
Bill
and
ted
said
it
really
well,
we
need
to
be
excellent
to
each
other.
There's.
The
code
of
conduct
also
contains
policies
and
procedures
to
resolve
any
issues
that
do
come
up
and
I'll
have
more
to
say
about
that
in
a
minute,
but
calls
are
really
common
ways
of
doing
that.
A
They
almost
always
have
meeting
agendas.
Topics
are
being
the
the
chair
of
several
of
these
working
groups.
Topics
are
almost
always
welcome,
even
if
they're,
even
if
they
can't
be
put
on
the
schedule
for
the
next
week
or
they'll
they'll,
almost
always
accept
it.
Meetings
have
different
ways
of
sort
of
volunteering,
sometimes
the
zoom
hands
feature
or
just
speaking
up
is
good,
sometimes
with
larger
meetings.
You
need
some
more
formal
interactions,
and
so
sometimes
they
use
the
chat
as
a
formal
cue.
A
So
you
can
sort
of
get
in
line
to
speak,
and
it's
a
great
way
to
ask
a
comment.
If
you
don't
understand
like
how
you
you
know
ask
permission
to
speak
up
than
than
dropping
a
note
in
the
chat
is
is
an
easy
way
to
do
that
during
a
live
meeting.
The
calendars
are
usually
published
by
the
organizations
that
host
them,
so
hyperledger
has
a
calendar,
for
example,
and
and
the
diff
also
has
a
calendar.
A
A
It's
also
really
handy
when
you
wanna
watch
if
you're
watching
a
player
vlc
is,
is
one
that
usually
will
play
the
the
format
that
they're
recorded
in
and
you
can
watch
them
in
faster
than
real
time,
which
is
helpful
to
when
you
need
to
catch
up
on
meetings.
They're
usually
posted.
If
you
don't
see
where
they
are,
then
go
ahead
and
ask,
and
and
they'll
help
you
with
that.
A
Github
repositories
are
very
commonly
involved,
whether
they're
code
or
whether
there's
other
sorts
of
documents
that
are
created,
there's
almost
always
a
readme
that
contains
useful
information.
It's
also
worth
being
familiar
with
the
issues
in
the
repository
active
pull
requests,
and
you
can
also,
of
course,
browse
the
commit
history,
because
it
is
a
github
repository
to
see
kind
of
what
kinds
of
actions
and
who
in
the
communities
involved.
A
You
can
contribute
your
code
there's
a
couple
of
quick
tips
here.
You
need
to
mind
the
code
license.
That
is
in
the
repository
to
make
sure
that
you
understand
it
and
that
you
are
capable
of
committing
that.
You
typically
work
on
a
fork
of
the
repository
and
then
submit
a
a
pull
request
for
that
and
the
developer
certificate
of
origin
dco.
A
You
can
google
that
up
for
specifics,
as
well
as
commonly
required
for
these
repositories
and
that
helps
with
some
legal
issues
surrounding
the
code
I
this
is.
This
is
important
and-
and
I
want
to
spend
a
minute
on
this-
we
need
you
in
the
community.
We
realize
that
everyone
is
busy,
but
if
there's
time
or
this
lines
up
with
the
with
the
the
goals
of
your
employer
or
personally,
we
would
welcome
your
contribution
here.
A
A
Please
be
persistent
with
your
contributions.
Sometimes
there's
rules
that
are
that
are
a
little
bit
frustrating
to
you
know
about
different
types
of
reviews
that
are
required
or
other
things,
but
please
be
persistent
with
that.
The
the
general
request
here
is
that
we're
all
human
you
know
the
this
is
the
focus
is
on
software,
but
we're
all
humans
making
it
happen,
and
we
all
have
different
stresses
in
life
and
not
everyone
is,
is,
is
in
a
perfect
place
all
the
time.
A
If
someone
is
a
little
bit
short
with
you
or
or
a
little
bit
impatient
or
something,
then
then,
please
be
a
little
bit
patient
with
them
in
the
stresses
that
they
have,
but
here's
the
big
but
don't
put
up
with
bad
behavior
if
there
are,
if
there
are
things
that
are
unacceptable,
particularly
because
of
the
the
code
of
conduct
of
the
community.
That's
not
the
type
of
thing
that
we
that
we
ought
to
put
up
with.
A
A
The
I
these
sorts
of
issues
I
are
seem
to
be
relatively
rare,
and
I'm
glad
for
that.
But
I
want
to
make
sure
that
anytime,
something
does
actually
come
up,
that
we
improve
our
community
rather
than
then
drive
people
away.
We
need
you
and
we
we
hope
that
you
will
find
the
time
professionally
or
personally,
to
engage
in
the
products
or
the
projects
that
are
important.
A
A
If
I
can
help
you
with
anything
as
it
relates
to
the
community
or
anything
that
we've
talked
about
today,
please
do
reach
out
there's
my
email
address
at
indicio,
where
you
can
reach
out
on
on
any
of
the
other
platforms
that
I'm
engaged
in
the
same
goes
for
all
of
the
indicio
team.
If
there
is
a
way
that
we
can
help
point
you
to
resources,
help
you
get
past
something
or
know
who
to
ask.
Please
do
reach
out
and
we
would
love
to
help.
A
You
we've
heard
from
a
bunch
of
really
knowledgeable
people
today,
with
with
all
the
things
they
presented.
Daniel
and
shar
took
a
huge
chunk
of
the
technical
presentation.
Lynn
did
a
fantastic
job
with
the
networks
and
scott,
with
the
the
introduction
and
and
the
terms
and
the
overview
and
the
orientation
to
the
concept,
and
so
we
are
all
available.