►
Description
A virtual workshop run on November 10, 2022. This workshop is a four hour online course that introduces 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.
Topics include:
* Decentralized identity concepts and principles
* The verifiable credential data model
* Decentralized identity ecosystem
* Network tools indyscan and SelfServe
* Intro to Indy CLI
* What Hyperledger Aries is
* Install and run Aries Toolbox
* Create connections and issue a credential
* How to verify credential
To learn more about Hyperledger Aries, visit: https://wiki.hyperledger.org/display/ARIES/
And to ask any questions about Aries, please join the #aries channel on Hyperledger's Discord server: https://chat.hyperledger.org/
----
Hyperledger – Open Source Blockchain Technologies
Hyperledger is an open source community focused on developing a suite of stable frameworks, tools and libraries for enterprise-grade blockchain deployments.
It serves as a neutral home for various distributed ledger frameworks including Hyperledger Besu, Fabric, Sawtooth, Indy, as well as tools like Hyperledger Avalon, Cactus and libraries like Hyperledger Aries, Ursa. Learn more about Hyperledger projects: https://www.hyperledger.org/use
Discord: https://discord.gg/rVCn4j7UFd
Case Studies: https://www.hyperledger.org/learn/case-studies
Training & Certification: https://www.hyperledger.org/learn/training
Tutorials: https://www.hyperledger.org/use/tutorials
Webinars: https://www.hyperledger.org/learn/webinars
Events: https://www.hyperledger.org/events
Vendor Directory: https://www.hyperledger.org/use/vendor-directory
Subscribe to the Hyperledger Newsletter: https://www.hyperledger.org/newsletter
Follow-us on Twitter @Hyperledger
Learn about Hyperledger Membership: https://www.hyperledger.org/about/join
#Hyperledger #Blockchain
License
Creative Commons Attribution license (reuse allowed)
B
Hi
I'll
kick
off,
my
name
is
Trevor
Butterworth
I'm,
just
going
to
be
very
quick
and
in
in
to
get
things
started,
we're
very
excited
to
bring
you
this
Workshop
today.
Thank
you
to
everyone
for
joining.
We
have
a
great
group
of
instructors
to
talk
you
through
the
hyperledger
projects
that
are
currently
being
used
all
across
the
globe
to
build
decentralized
identity.
Solutions.
B
Today
we
or
being
joined
by
some
of
the
people,
who've
built
who've,
been
there
from
the
very
beginning
to
build
these
open
source
code
bases,
so
you'll
get
the
insight
and
their
experience
and
I
encourage
you
to
use
the
Discord
channel
to
ask
questions.
As
David
has
already
indicated.
You
can
also
ask
them
in
Zoom,
but
the
zoom
chat
panel
isn't
going
to
be
permanent,
whereas
Discord
is
forever
so
to
speak.
B
Prior
to
today's
Workshop,
you
should
have
received
some
instructions.
If
you
haven't
done
that
or
you
haven't
got
them,
don't
worry
you
can
follow
along
and,
as
our
instructors
run,
the
demonstrations.
Today's
Workshop
will
be
recorded
and
available
on
the
hyper
Ledger
Foundation
website
and
the
training
section,
along
with
instructions
and
links
to
all
of
today's
materials,
so
feel
free
to
access
this
at
your
convenience.
C
Thank
you,
Trevor
I'm
I'm
apologizing
for
a
little
bit
of
screen,
sharing
Tech
issues
there,
so
we're
gonna
just
look
at
it.
This
way.
Let
me
make
sure
everybody's
seeing
our
title
slide
here,
Build
Your
solution.
We
can
see
it
excellent,
so
we'll
just
move
through
it.
This
way
that
is
James
Schulte,
who
was
here
last
time
and
Director
of
Business
Development
and
someone
you
can
reach
out
to
for
for
questions,
amongst
others
on
our
staff.
C
Here
we
have
a
link
to
the
workshop
materials
that
we
will
share
in
the
in
the
chat
as
well
and
at
the
end
of
the
session.
Also.
So,
if
you
would
like
to
review
the
materials
presented
that
will
be
available
to
you
as
well
and
Trevor
do
you
you
may
know
is
our
chat
is
active
here
on
hyperledger
during
the
doing
the
workshop.
C
Yes,
it
is
excellent.
Okay,
so
feel
free
to
jump
in
there.
My
role
today
is
to
talk
at
a
very
high
level
about
what
decentralized
identity
is,
how
we
approach
some
of
the
concepts
and
do
a
level
set
on
how
we
think
about
things
and
some
of
the
terms
and
definitions
that
we
use
and
that
you'll
hear
throughout
the
day.
C
So
for
those
of
you
that
are
intimately
familiar,
we
hope
it's
refreshing
and
perhaps
a
slightly
different
look
at
things
and,
if
you're
just
coming
into
this
sector
in
this
industry,
we'd
like
to
get
you
started
down
the
right
path
and
thinking
about
this
in
a
way
that's
useful
and
productive.
So
I
am
the
VP
of
Business
operations
here
at
indicio.
I
do
many
many
things.
C
C
This
is
a
very,
very
old
cartoon
that
describes
some
of
the
problems
we
have
with
the
interactions
and
relationships
that
are
digital
that
happen
across
the
distance
via
the
Internet
and
the
anonymity
of
the
internet
can
be
a
great
thing.
It's
a
can
be
a
great
way
to
protect
privacy
and
and
do
things
without
revealing
a
whole
lot
about
yourself.
C
So
you'd
like
to
know
for
certain
that
when
you
send
a
payment
or
you
submit
some
pii
somewhere,
that
you're
submitting
it
to
the
the
place
that
you
think
you're
submitting
it
to
so
anonymity
is
a
double-edged
sword
and
we
need
a
tool
or
a
technology
to
solve
for
both
things,
something
that
can
positively
identify
the
participants
in
a
transaction
or
verify
some
data
points,
but
also
protect
privacy,
where
applicable
and
we're
needed
to
help
protect
everyone's
individual
data
rights.
That's
what
this
technology
is
really
intended
and
evolved
to
do.
C
We
have
identity
systems
to
establish
trust
between
parties,
and
if
you
have
a
LinkedIn
profile,
you
might
have
signed
up
for
it
using
a
Gmail
address
and
you
signed
up
for
that.
Gmail
address
doing
absolutely
nothing
to
prove
who
you
were
and
therefore
we
we
are
in
a
system
here
where,
despite
all
the
two
FAS
and
three
FAS
and
things
of
that
nature,
the
the
original
root
of
our
entry
into
a
system
such
as
this
is
not
supported
by
really
anything
whatsoever.
C
D
C
There
so
what
is
identity
anyway?
We'll
try
to
talk
about
the
the
second
part
of
our
technology,
decentralized,
identity
and,
typically,
when
you
ask
someone
what
identity
is,
they
will
give
you
these
sorts
of
answers,
a
person's
name
or
a
date
of
birth,
perhaps
something
about
their
life
or
their
educational
credentials
or
or
something
like
that.
So
biographic
and
demographic
data
is
typically
how
folks
Define
it,
and
that
is
a
very,
very
useful
set
of
information
for
transacting
things
digitally.
C
However,
it's
not
the
be-all
end,
all
of
what
decentralized
identity
is,
and
we've
started
to
refer
to
this
type
of
identity,
the
biographic
and
demographic
with
lowercase
I,
and
certainly
the
a
bulk
of
the
use
cases
that
have
been
built
out
on
this
technology
to
date
have
dealt
with
these
very
things.
Biographic
and
demographic
data
points.
C
So
where
do
these
data
points
come
from
the
lowercase
I
identities?
Well,
they
can
come
from
anywhere,
not
just
your
typical
driver's
license
or
passport
type
of
things
or
your
employer.
Even
they
can
come
from
interactions
that
you
have
anywhere
you've
established
some
footprint
or
digital
trail
of
yourself
and
any
given
data
point
that
can
be
used
to
prove
something
about
yourself
can
constitute
part
of
your
identity.
C
C
So
when
we
look
at
identity
as
being
everything,
we
can
widen
our
view
a
little
bit
further
away
from
individuals
and
out
to
things
like
businesses
or
governments
or
operational
entities.
Devices
and
iot
things
and
physical
objects
have
identities
as
well.
So
if
you
think
about
a
vehicle
with
the
VIN
number
or
license
number
or
registration
maintenance
records
business
with
all
of
their
their
financial
reports
and
business
records
and
employment
records,
all
of
those
are
simply
subsets
of
this
potential
identity.
C
Circle
any
data
point
that
might
be
valuable
to
someone
that
receives
it
can
constitute
an
identity
and
then,
once
we
use
this
technology,
we'll
talk
about
today
to
package
it
up
as
a
verifiable
credential
and
send
it
on
its
way.
It
can
smooth
business
processes
and
operations
to
a
point
where
it
becomes
very,
very
valuable.
C
C
The
other
big
problem
for
business
here
is
that
integration
of
systems
that's
required
to
do
this,
centralized
centralized
model
or
very,
very
costly
and
they're
difficult,
and
they
sometimes
compromise
privacy.
And
of
course
there
are
security
issues.
So
you
know
when
someone
gets
into
one
system,
they
may
be
linked
to
to
dozens
of
others
and
and
gain
access.
So
centralization
has
a
lot
of
issues
that
could
be
solved
for
with
some
some
appropriate
technology.
C
What
we're
striving
for
with
a
decentralized
model
is
essentially
a
digital
model
of
the
analog
world,
wherein
you
might
be
given
some
set
of
data
data
about
you
in
this
case.
We'll
look
at
a
driver's
license
because
it's
an
easy
to
conceive
of
example,
you're,
given
a
set
of
data,
and
you
hold
on
to
it
and
when
it's
time
to
show
that
to
someone
you
take
it
out
of
your
pocket
so
to
speak,
and
you
show
it
with
consent.
C
So
we'll
take
a
second
for
history,
lesson
here
and
look
at
trusts
in
the
past
and
Trust
now,
because
we've
talked
about
Trust,
Systems
and
identification
systems
in
the
analog
world.
From
the
time
of
the
first
recorded
writing
to
about
1964,
we
had
physical
objects
and
physical
objects
have
a
means
of
determining
whether
they're
trustworthy.
If
you
think
about
a
driver's
license
or
a
passport
a
birth
certificate,
even
a
registered
or
notarized
letter
they've
got
some
means
whereby,
when
someone
receives
them,
they
can
look
at
this
thing
and
decide
whether
it's
trustworthy.
C
That
is
not
the
real
thing.
It's
well,
it's
a
facsimile
of
the
real
thing,
and
yet
the
receiver
of
that
treats
it
as
if
it's
real
and
in
doing
so
they
assume
a
lot
of
risk
or
some
risk,
and
even
some
risk
is
more
than
they
assumed
before
when
they
saw
the
real
object
and
if
they
don't
want
to
assume
the
risk.
C
They've
got
to
do
a
lot
of
work
to
mitigate
that
risk,
to
go
and
actually
talk
to
the
source
of
that
original
document
and
find
out
if
it's
real
and
so
in
the
hybrid
World,
we've
actually
reduced
the
amount
of
trust
in
an
exchange
of
information
or
identity
credentials.
If
you
will,
it
is
more
efficient,
certainly
at
least
in
some
aspects
of
the
exchange,
and
it's
definitely
a
sacrifice
in
privacy
and
control
for
the
individual
that
holds
those
things
in
the
decentralized
world.
C
We
are
able
to
maximize
trust,
maximize
efficiency
and
privacy
by
using
the
tools
and
technology
that
you'll
hear
about
a
little
bit
later
on
today.
So
why
does
it
work
in
analog
life?
Well
much
much
in
the
way
I
described.
We
have
trusted
issuers
who
give
you
a
physical
credential,
and
then
you
hold
them,
and
the
verifier
of
that
can
visually
check
whether
the
thing
is
real
or
whether
it's
been
altered,
and
then
they
can
make
a
decision
about
whether
or
not
to
trust
that
document.
C
So
what
is
trust
in
data?
Well,
trust
comes
really
in
three
parts.
One
is
authenticity.
So
if
you
receive
some
data,
you
need
to
determine
whether
it's
authentic,
in
other
words,
where
did
it
come
from
and
does
it
come
from
the
place
it
claims
to
be
from
so
we
can
use
the
ledger
to
support
claims
of
authenticity
and
verify
that
something
did
come
from
the
place
it
comes
claims
to
have
come
from.
C
In
other
words,
you
didn't
make
it
in
your
basement
and
we
have
also
data
Integrity,
which
is
about
whether
or
not
that
data
has
been
altered.
So
if
you
have
a
driver's
license,
for
example,
and
the
physical
thing
has
some
lamination
and
if
it's
delaminated
and
has
cut
marks
in
it,
it's
probably
evidence
that
you've
tampered
with
it
in
some
way
or
another.
The
the
PDF
upload
of
your
driver's
license
doesn't
have
easily
identifiable
Integrity
marks
in
that
way.
C
So
we
can
provide
data
Integrity
with
this
technology
as
well
in
evidence
that
something
has
arrived
intact
as
issued,
and
then
the
third
part
is
usefulness.
So
this
is
more
of
a
governance
and
and
decision
making
and
business
logic
question.
However,
it's
really
the
essential
part
of
it.
So
for
someone
who
receives
some
credentialed
data,
they
need
to
have
a
contractual
and
conceptual
understanding
about
the
issuer
of
that
credential
and
understand
whether
or
not
they
want
to
trust
it.
C
So
that's
one
of
the
things
we
we
really
focus
on
here
is
usefulness
and
Trust
decisions,
and,
and
those
are
governance,
things
and
and
we'll
talk
a
bit
about
how
we
execute
those
things.
From
from
the
tech
point
of
view,
the
trust
model
consists
of
two
parts.
It's
the
cryptographic,
trust
so
much
of
the
the
stuff
that
you'll
hear
about
today
is
cryptographic,
trust
it's
talking
about
how
we
use
The,
Ledger
and
use
the
the
hyperledger
tools
to
support
claims
of
authenticity
and
integrity,
and
that's
pretty
straightforward.
C
For
for
giving
you,
the
keys,
we'll
talk
quite
a
bit
about
credentials
in
this
format,
and
it's
a
very
simple
look
at
it,
but
at
ndco
we
approach
all
of
our
problem
solving.
In
this
way
we
look
at
issuers
of
credentials,
holders
of
credentials
and
verifiers
of
credentials
and
then,
of
course,
their
relationship
to
The
Ledger
and
the
and
the
networks
that
that
support
these
and
they're
a
lot
more
on
that
of
course
later
today.
C
The
key
to
this,
though,
is
that
we
write
things
to
The
Ledger,
to
support
data,
authenticity
and
integrity,
but
we
don't
write
pii
to
The
Ledger,
but
we
only
use
these
ledger-based
items
or
objects
to
support
those
those
claims
and
those
proofs.
The
data
itself
goes
from
the
issuer,
who
has
it
normally
and
directly
to
the
credential
holder,
who
has
a
legal
right
to
have
it
and
then
with
consent
goes
to
the
data
verifier.
C
I'm
going
to
skip
through
these
use
case
examples
a
little
bit
in
the
interest
of
time.
I've
talked
a
little
bit
about
it,
but
the
building
blocks
here
that
we
will
speak
of
today.
The
vocabulary
uses
one
of
Agents,
so
we'll
have
an
issuer
agent
and
verifier
agent
that
can
be
stood
up
in
a
number
of
different
ways
as
as
Cloud
hosted
or
even
on
premises.
C
It
might
be
a
government,
it
could
even
be
a
custodial
holder
where,
by
you're,
the
business
that
holds
the
credential
that
actually
belongs
to
a
car
that
your
business
owns
or
something
of
that
nature,
and
then
we'll
talk
about
verifiers
verifiers
are
those
that
receive
the
credential
data
or
the
credential
itself,
and
then
check
Against,
The
Ledger
for
its
authenticity
and
integrity
and
then
make
trust
decisions.
We'll
use
the
sort
of
typical
Bob
and
Alice
names
that
you'll
see
over
and
over.
C
So
in
most
of
our
conventions
here
today,
Bob
is
an
issuer
and
Alice
is
a
verifier
and
then
the
the
thing
that's
often
overlooked
is
that
these
roles
are
not
mutually
exclusive.
We
need
not
have
issuers
holders
and
verifiers
as
three
separate
parties.
Many
of
the
use
cases
we
both
in
the
dco,
have
been
closed.
Ecosystem
use
cases
where
an
issuer
is
also
the
verifier
of
their
own
credential
and
can
be
the
credential
can
be
used
by
a
holder
to
gain
access.
C
It
can
be
used
in
in
identity
access
management,
things,
physical
plant,
access,
proof
that
you
need
to
go,
get
a
pay
stub
or
get
some
service
from
your
own
employer.
It
can
be
a
situation
where,
let's
say
a
bank
issues,
an
account
holder,
credential
to
you,
and
then
you
use
that
to
get
back
into
the
bank
to
access
your
account,
so
just
keep
in
mind
that
the
roles,
although
we'll
talk
about
them
mostly,
is
three
separate.
C
Things
are
not
always
mutually
exclusive
and
then,
of
course,
to
bring
it
back
to
where
we
started
the
code
architecture.
So
we
have
hyperledger
Indie,
Aries
and
Ursa
work
here
for
you
today
and
that's
not
my
role
to
talk
about
how
these
play
out
that'll
be
coming
up
shortly.
But
this
is
why
we're
doing
this
here
with
hyperledger
they're
a
great
partner,
and
we
have
a
lot
of
great
resources
to
help.
You
navigate
all
this.
So
that
is
my
level
set
on
where
all
this
comes
from
and
I'm
going
to
now.
E
Thanks
Scott
appreciate
that
me
get
the
share
button
to
behave
all
right,
I'm
talking
about
Community
engagement,
we're
going
to
talk
about
some
tech,
the
the
technical
stuff
for
the
and
start
with
Indie,
and
then
in
Aries,
and
and
talk
about
how
it
ties
together.
But
first
we
want
to
talk
about
engaging
in
the
community.
E
Hyperledger
is
a
is
an
open
source
Foundation
as
part
of
the
Linux
foundation
and
and
we
our
community,
that
that
that
gathers
together
and
works
together
to
make
these
things
work,
and
so
I'll
talk
a
little
bit
about
that.
I
am
Sam
Curran
I'm,
an
architect
within
dco
and
I
work
with
the
Aries
working
group
very
heavily,
and
also
the
diff
income
working
group
as
well
for
the
spec
development
there
there's
my
email
address
and
I
am
telegram
Sam
on
all
the
socials.
E
E
That's
not
the
only
reason,
of
course,
but
that's
a
really
useful
one.
There's
oftentimes,
you
know
communities
benefit
from
people
coming
and
and
sharing
how
they're
using
the
the
technology
and
and
that's
a
learning
experience
for
the
developers
and
other
maintainers
and
and
can
help
the
project
improve
and
be
substantially
better.
E
The
there's
there's
other
reasons,
of
course,
in
contributing
and
everything
else.
The
other
thing
that
I
really
want
to
highlight
here
is
that
this
is,
we
think
about
open
source
as
as
developers
and
that's
true,
we
developers
are
really
useful,
but
there's
so
much
more
to
be
done
and
user
experience,
design,
documentation,
project
managers,
people
to
organize
efforts,
there's
all
sorts
of
folks
needed
in
the
in
all
of
the
the
projects
that
we'll
be
talking
about
today,
and
that
is-
and
so
we
need
you.
E
Even
if
you're
you
don't
fit
a
strict
developer
mode.
We
we
hope
that
you
will
come
and
and
join
us
in
our
efforts.
There's
three
three
plus
projects
that
we're
gonna
be
talking
about
today.
The
the
hyperledger
areas,
of
course,
is
is
a
little
bit
of
the
main
focus,
but
that's
supported
by
by
hyperledger
Indie
as
a
as
a
verifiable
data
registry
underneath
also
a
hyperledger
Ursa
is
the
cryptographic
portions
of
what
we're
talking
about
today
and
just
verily.
We
have
the
new
hyperledger
on
non-creds
project.
E
There's
the
decentralized
identity.
Foundation
is
is
another
organization
that
has
some
good
stuff
going
on.
They
have
interoperability
working
groups,
I
mentioned
the
VidCon
working
group
that
I'm
a
part
of
also
identifiers
and
Discovery
and
claims
and
credentials
Etc,
and
they
can
be
available.
They
can
be
found
at
identity
foundation
and
they're
doing
lots
of
good
work
there.
Trust
over
IP
is
another
organization
that
that
has
been
involved
in
a
handful
of
different
different
aspects.
E
So
there's
all
sorts
of
different
working
groups,
all
over
I
just
highlighted,
of
course,
I'm,
not
just
hyperledger.
But
three
of
these
other
organizations
and
there's
a
few
others
and
all
of
those
have
multiple
working
groups.
And
so
each
of
those
working
groups
communicate
I'm,
going
to
talk
a
little
bit
generally
about
how
these
groups
tend
to
work,
to
help
you
get
familiar
with
them
and
and
and
find
it
easier
to
to
get
involved.
E
That's
present
in
calls
and
a
code
of
conduct,
and
the
reason
these
exist
is
to
help
us
collaborate
with
each
other
and
and
not
cause
any
legal
issues
with
what's
going
on
and,
of
course,
to
be
excellent
to
each
other
and
to
to
make
sure
that
that
all
are
welcome
and
and
represented,
and
these
policies
do
contain
typically
information
about
how
to
resolve
issues
that
may
come
up
in
in
many
calls.
These
are
highlighted
or
they're
linked
to
in
the
agendas
to
make
them
very
easy
to
find.
E
Meeting
agendas
are
a
powerful
thing
that
help
Drive
calls,
but
also
help
you
be
available
or
know
what's
going
on.
If
you
happen
to
be
a
miss,
a
call
so
to
be
aware,
topics
are
almost
always
welcome
in
any
of
these
calls,
if
there's
something
that
you
would
like
to
bring
up
to
ask
or
to
share
or
to
present,
or
even
if
you
don't
have
the
answers,
but
you
want
to
bring
up
a
a
scenario
and
learn
more
about
it.
E
There's
various
forms
of
interaction
in
meetings,
sometimes
there's
a
formal
cue
where
you
use
a
command
in
the
chat
like
Q,
Plus
or
something
to
add
yourself
to
the
queue.
Sometimes
you
know
they'll
utilize,
the
zoom
raise
hands
feature
in
order
to
to
manage
that,
and
sometimes
it's
just
to
speak
up
the
larger
the
meeting,
the
the
more
formal
the
interaction
tends
to
be
it's
different.
E
If
there's,
you
know
11
of
you
there
than
if
there's
like
you
know,
150
of
you
there,
and
so
that
will
vary
depending
on
the
size
of
the
meeting
and
sort
of
the
culture
of
the
of
the
group
that
is
organizing
it.
They'll
almost
always
mention
what
the
the
form
of
interaction
is
preferred
to
be,
and
you
can
always
ask
in
the
chat
and
someone
will
let
you
know.
E
The
chat
itself
is
almost
always
active
in
the
meetings
and
it's
a
great
way
to
ask
a
commenter
or
or
or
ask
a
question
or
or
make
a
comment
on
something
that's
going
on,
and
that
could
be
a
really
useful
way
if
you're,
unsure
of
something
and
don't
really
want
to
verbally,
speak
up.
But
you
want
to
ask
a
question:
that's
a
great
way
to
ask
a
question
and
you'll
find
that
people
are
are
pretty
friendly
about
answering
those
calendars
will
help.
E
You
know
when
the
meetings
exist,
they're
generally
run
by
the
organization.
That's
at
the
top,
so
hyperledger
has
a
calendar
that
highlights
all
of
the
of
the
different
meetings
that
that
are
there.
The
decentralized
identity
Foundation
runs
one
separately.
Etc
links
to
the
to
the
calendars
can
often
be
found
in
the
repository
or
the
agenda
that
that's
running
it.
Those
are
often
on
a
Wiki
to
help.
E
You
understand
this,
so
once
you
sort
of
find
one
of
these
things,
it's
relatively
easy
to
to
look
a
little
bit
and
find
all
the
information
that
you'll
need.
One
thing
I'll
mention
on
calendars
to
be
aware
of
we're
in
Daylight
Savings
Time
shift
season
around
the
world.
Most
meetings
are
anchored
in
one
time
zone
and
they
will
follow
the
time
zone.
Shifting
the
daylight
savings
time
zone
shifting
of
the
time
zone.
E
It's
anchored
in
so
let's
say
that's
U.S
Pacific,
so
the
the
time
zone
shift
will
happen
when
that
happens,
and
so,
if
you're,
somewhere
else
around
the
world
that
either
does
daylight
savings
time
or
not.
Be
aware
of
that
generally,
if
you
use
a
countering
system,
Google
Calendar.
Does
this
relatively
well?
If
you
copy,
you
know
a
calendar
event
from
from
a
source
calendar
onto
your
own,
it
usually
brings
the
home
time
zone
along
with
it
so
that
it
will
automatically
update
as
the
Daylight
Savings
Time
stuff
changes
around
the
world.
E
E
Most
video
players
will
allow
you
to
play
a
video
or
or
the
audio
back
in
faster
than
real
time,
which
can
be
really
helpful.
When
you're
trying
to
be
aware
of
of
what's
of
what's
going
on
in
meetings
that
you
you
doubled
up
on
or
if
you
are
on
vacation
and
you
want
to
catch
up
later,
then
that's
a
that's
a
great
place
to
do
that
recordings
usually
posted
on
the
agenda,
sometimes
in
another
place.
E
The
diff,
for
example,
has
a
channel
that
all
the
reporting,
the
recordings
get
posted
into.
Please
ask
and
people
will
tell
you
where
the
recordings
are
or
I
occasionally
I
forget
to
post
recordings.
If
you
ask
about
a
missing
recording,
then
they
can
usually
get
that
uploaded
for
you,
and
so
that
way
you
can.
You
can
follow
up
and
be
more
aware
of
of
the
things
that
are
going
on.
E
E
That's
particularly
true
for
spec
work,
it'll,
often
point
to
the
rendered
version
of
the
spec
and
that's
often
easier
to
read
than
than
navigating
the
files
in
the
GitHub
repository
itself
on
the
issues.
Tab
you'll
find
open
issues,
and
these
are
really
useful
ways
to
help
you
Orient
with
the
with
the
community
and
to
contribute
or
be
involved
as
well.
You
want
to
read
open
issues
or
you
can
look
at
recently
closed
issues.
E
E
Any
errors
made
in
the
pull
request
before
it's
committed
and
that's
useful
being
aware
of
the
of
the
pull
requests
in
a
community
can
help.
You
understand
the
movement,
that's
going
on
in
the
work,
that's
being
done
and,
of
course,
I'll
talk
in
a
minute
about
how
to
to
commit
your
own.
Your
own
changes
or
suggested
changes
to
the
Repository.
E
The
commit
history
inside
of
GitHub
is
also
incredibly
useful,
so
that
you
can
see
what
has
changed
recently
and
it'll.
Tell
you
you
know
who
submitted
the
the
pull
request
and
the
time
that
it
was
and,
of
course
you
can
see
what
the
what
the
changes
were
as
part
of
that
and
so
becoming
sort
of
familiar
with
the
recent
history
can
help.
E
You
understand
more
of
how
the
communities
going
like,
where
it's
going
to
and
who's
contributing
and
the
types
of
changes
that
are
that
are
being
contributed
and
that's
helpful
to
understand,
but
not
the
only
the
state
of
the
community.
We
can
help
you
understand
where
help
might
be
needed
or
or
ways
that
you
might
be
able
to
contribute.
E
So,
if
you're
going
to
contribute
your
code,
there's
a
there's,
a
a
pattern
here
that
will
help
you
a
little
bit.
The
first
thing
that
I
need
to
mention
is
to
mine
the
code
mind
the
code
license
Associated,
it's
often
Apache
2
or
similar,
and
you
can
find
that
often
in
the
readme
or
in
a
license
file
in
the
repository
itself,
and
that
will
tell
you
which
license
it's
under
and
you
want
to
make
sure
that
you
understand
the
license
and
particularly
the
organization
that
you
might
be
working
for.
E
You
want
to
work
on
a
repository.
Fork
git
has
the
ability
to
create
a
Forks
for
temporary
sort
of
a
manipulation
and
comparison,
and
so
what
you
want
to
do
is
Fork
the
repository
into
your
own
GitHub
account
and
then
create
a
branch
on
your
GitHub
account
for
your
contribution.
You
want
to
be
aware
of
the
developer
certificate
of
origin
requirements
on
commits.
E
That's,
usually
a
setting
that
you
can
change
in
the
software
that
you
use
or
that
you
can
manually
add,
and
so,
if
you
Google
up
developer
certificate
of
origin,
you'll
find
more
information.
There
and
then
once
you've
made
the
change.
You
want
to
put
push
your
Branch
from
probably
your
local
system
to
your
GitHub
fork,
and
then
it
makes
it
easy
to
create
a
PR
to
the
main
branch
of
the
original
repo
from
the
fork
in
your
in
the
branch
of
your
fork.
This
makes
it
easier
to
update
your
pull
request.
E
If
there
are
suggested
changes,
you
can
just
change
and
commit
it
on
your
fork.
Push
it
to
your
own,
your
own
Fork
of
the
of
the
repository,
and
then
it
makes
it
easy
to
compare
and
then
accept
to
pull
requests
and
and
so
pushing
back
to
the
open
source
code
base
is
sort
of
the
foundational
way
to
support
the
community.
I
want
to
highlight
that
you
don't
always
need
to
have
very
substantial
changes
for
them
to
be
useful.
E
Some
of
the
most
useful
pull
requests
that
that
I
have
reviewed
and
received
are
in
the
forms
of
of
a
clarification
or
of
a
typo
or
a
grammatical
error.
That's
made
that
might
trip
someone
up,
particularly
if
they're,
not
a
native
English,
speaker
and
and
the
and
the
text
happens
to
be
in
English
fixing.
Those
things
can
be
really
helpful
to
help.
E
E
We
have
to
understand
the
types
of
problems
that
need
to
be
solved
by
the
software
that
we're
engaged
in
for
us
to
do
it
effectively
and
please
speak
up,
particularly
if
you
don't
feel
like
you
fit
in
the
the
diversity
of
of
our
contributors,
contributes
to
the
to
the
success
of
the
project
in
solving
problems
in
a
universal
way
that
that
fits
all
of
our
needs
and-
and
we
need
you
particularly
if
you
don't
feel
like
you
fit
in
please
stay.
Please
speak
up,
be
persistent
with
your
contributions.
E
Most
open
source
maintainers
have
jobs;
sometimes
they
do
it
in
the
weekend.
Sometimes
it's
part
of
their
job,
but
everyone
is
busy
if
you
submit
something
like
an
issue
or
a
pull
request
and
you
and
it's
not
being
acknowledged,
then
please
like
make
a
comment
or
raise
it
again
and
be
patient
with
the
the
busyness
of
others.
We
all
have
stresses
in
life,
sometimes
we're
busy.
E
Then
Engage
The,
the
code
of
conduct,
seek
help
from
leaders
and
other
members
of
the
community
in
order
to
to
to
push
back
against
bad
behavior
and
and
not
allow
that
within
our
community.
Again,
it's
it's
rare,
but
this
is
something
that
is
unacceptable
and
that
we
need
to.
We
need
to
make
sure
that
we
we
do
not
allow
to
to
persist.
E
We
are
we're
grateful
that
you're
here
at
this
training
and
we're
grateful
that
that
this
community
is,
is
one
that
you
have
interest
in,
and
we
hope
that
that
you
feel
welcome
here
again.
I'm
I'm
Sam,
please
reach
out.
If
you
have
any
any
questions
or
any
other
things
that
I
can
that
we
can
help
you
with,
and
we
would
love
to
help
you
get
engaged.
I
will
be
monitoring
for
the
rest
of
the
of
the
training
here.
E
I
will
be
monitoring
the
Aries
Channel
on
on
the
hyperledger
Discord,
and
so
please
reach
out.
If
you
have
a
question
the
questions
you
ask,
there
are
great
because
they'll
last
past
this
training
and
you
can
pull
it
back
up
and
see
what
the
answers
were.
Of
course,
you
you're
we're
welcome
to
ask
questions
here
as
well,
particularly
as
it
relates
to
you
know
something
immediately
on
the
slides
or
or
or
something
specific
to
the
presentation.
E
F
F
We
feel
free
to
if
someone
sees
this
question
in
the
chat
that
that
I
can
answer
during
my
part
here
feel
free
to
speak
up,
so
I'm
going
to
be
moving
a
little
bit
more
technical,
now,
we've
kind
of
been
doing
some
high
level
overview
stuff
and
with
the
Scott
talking
about
identity
and
Sam.
Talking
about
the
community
I'm
going
to
talk
a
little
bit
about
the
tools,
there's
still
kind
of
Baseline
stuff.
F
Where
we're
you
know
not
really
in
depth
yet
and
that'll,
be
after
I
talk,
there'll,
be
a
break
for
15
minutes
and
then
we'll
get
more
in
depth
after
that
and
there's
a
an
opportunity
to
to
kind
of
do
some
Hands-On
stuff
during
my
part
here,
but
I
won't
be
specifically
doing
that
you'll.
If
you
want
to
bring
up
your
ndcli
you'll,
be
able
to
type
in
some
of
the
commands
as
I
show
them
and
talk
about
them,
but
we
won't
be
taking
a
lot
of
time
out
to
to
do
that.
F
So
I
am
Lynn
bendixen,
the
director
of
network
operations
in
indicio
I've
been
working
with
in
hyperledger
Indie
networks
for
about
four
and
a
half
years
now
so
I'm,
one
of
the
experts
in
the
community.
On
that
you
can,
you
can
see
my
email
address
here,
feel
free
to
send
me
an
email
with
any
questions
and
then
on
Discord
and
GitHub,
and
a
few
other
Community
to
get
type
places
you
can
reach
me
at
Lynn.
F
I
know
again
we're
just
going
to
quickly
go
over
this.
If
you
have
more
in-depth
questions
about
it
feel
free
to
ask.
This
is
just
kind
of
a
to
let
you
know
that.
There's
a
tool
out
there
available
for
you
to
use
the
tools
that
I
will
be
sharing
today.
Are
the
indicio
specific
in
dco
implementations
of
the
tools?
F
The
pool
transactions
are
just
adding
and
subtracting
nodes
from
The
Ledger.
The
config
transactions
are
the
auth
rules,
so
most
of
what
you'll
be
looking
at
is
a
developer.
This
is
kind
of
a
developer
tool,
you'll
be
looking
at
the
Domain
transactions
and
trying
to
see
you
know
what
it
looked
like
when
you
tried
to
write
your
transaction
to
The
Ledger
and
to
get
more
details
on
that.
F
You
can
click
up
here
on
the
thing
that
says
domain
and
then
you
can
search
for
your
the
kind
of
transaction
that
you
just
wrote,
I
just
clicked
on
Nim
up
here
to
highlight
that
one,
and
so
now
it
shows
all
name
transactions.
You
could
highlight
your
your
did
and
put
that
into
the
search
thing
here
and
search
for
your
just
your
dead
and
whatever
names
you're
dead
has
written
to
The
Ledger
Etc.
F
So
that's
pretty
much
the
maybe
scan
tool
and
a
little
introduction
is
to
what
you
can
do
as
a
developer,
to
use
that
tool
just
to
see
how
things
are
going
with
your
code
that
you're
writing
to
try
and
write
to
a
ledger
and
I
I
forgot
to
mention
that
was
written
by
Patrick
Stars.
He
donated
that
to
the
community
several
years
ago
and
I
just
took
his
code
and
made
a
few
config
changes
to
make
it.
F
There
used
to
be
kind
of
a
hierarchy
of
rules
where
you
know
the
trustee
was
at
the
top
and
he
could
do
everything
and
it
kind
of
went
down
from
there.
But
that's
not
the
case
anymore.
Each
role,
kind
of
has
its
own
separate
things
that
it
does
and
there's
not
really
a
big
role.
That
can
do.
Oh
sorry,
about
that.
F
That
can
do
everything
so,
since
you're
just
going
to
talk
about
some
of
the
roles
here,
the
the
ones
that
that
we
care
the
most
about
are
a
trustee
for
this
training
today
and
right
trustee
is
the
one
that
writes
admin
transactions
to
The
Ledger,
and
they
also
have
the
privilege
to
write
endorser
digs
to
The
Ledger.
So
when
an
endorser.
F
Joins
a
ledger:
it
has
to
have
the
approval
of
the
trustee
and
the
endorser.
The
thing
that
they
can
do
is
they
can
write
credential
transactions
to
The
Ledger.
They
write
schemas
Financial
definitions.
You
can
also
write
author
Nims
to
The
Ledger
or
author
Giggs
to
help
with
the
making
it
so
that
the
authors
can
send
their
transactions
to
the
ledgers.
F
G
F
Good
question
so
one
example
is
adding
a
node
to
a
ledger:
ledgers
start
off
with
a
certain
number
of
nodes
and
then,
as
node
operators
join
the
group,
they
need
to
be
added
and
removed,
and
that's
one
thing
that
a
trustee
can
do.
Trustees
can
also
add
other
trustees
to
The
Ledger,
and
so
that's
kind
of
what
we
mean
by
an
administrative
transaction,
anything
to
do
with
the
the
running
of
the
network,
so
to
speak.
They
can
also
add
auth
rules,
Etc,
so
I'd
answer
the
question.
F
Awesome:
okay,
let's
see
if
I
can
move
this
chat,
similar
I
can
keep
seeing
that
there
we
go.
Okay.
The
next
tool
I
want
to
introduce
is
one
that
I
think
that
now
Daniel
I'm
sure
we'll
we'll
talk
a
little
bit
more
about
later
about
the
actual
place
where
you
would
use
this
Tool
during
our
Hands-On
portion
of
our
area
step
today.
The
self-serve
tool
is
for
demonstration
or
test
networks
to
help
to
add
an
endorser,
or
it
says
a
privileged
Meme
here,
but
essentially
an
endorser
to
the
test.
F
But
this
helps
to
to
test
things
out
before
you
get
to
production.
The
production
networks
will
regularly
require
fees
and
other
things
to
be
able
to
get
an
endorser
did
on
them,
but
for
the
test
Nets,
it's
all
free
for
most
test
steps,
so
at
least
for
a
certain
period
of
time,
and
so
this
is
the
tool.
Essentially,
all
you
have
to
do
is
put
the
network
in
and
then
it
did
a
number
key
and
you
can
create
that
didn't
work
in
a
number
of
different
ways.
F
We're
not
going
to
go
into
those
details
here
and
there's
some
instructions
here
at
the
bottom,
a
link
to
some
instructions
to
help.
You
figure
that
out,
but
just
put
your
data
inverkey
in
here
and
click
submit,
and
it
puts
there's
a
wallet
on
the
back
end
of
this.
It
has
the
permissions
to
be
able
to
write
your
did
to
the
network
as
an
endorser
Nim.
F
F
H
F
Tools
that
do
this,
this
is
kind
of
a
a
baseline
tool
that
that
can
can
be
used
to
to
do
some
of
those
things
in
you
and
managed
networks.
It's
kind
of
an
administrative
tool,
I
use
it
most
when
I'm
watching
my
networks
for
creating
a
new
bid,
but
the
creating
a
new
did
can
can
happen
in
the
Aries
toolbox
that
banana
shark
and
introduces
well.
F
So
as
a
network
admin,
I
I
do
things
just
a
little
bit
differently,
but
here's
a
little
bit
of
intro
to
Indy
CLI
and
during
the
rest
of
the
presentation,
you
probably
won't
be
using
the
nuclei,
it'll
be
different
tools
and
so
I'm
just
going
to
show
you
this
really
quick.
This
is
a
part
where
you
can.
F
You
can
try
these
commands
if
you
want
to
and
if
you've
gone
through
the
the
workshop
prerequisites
that
had
you
install
these
things,
the
install
the
ndclin,
so
you
could
try
it
out
and
we'll
leave
that
to
you
to
to
do
either
during
the
during
the
break
or
in
another
time.
But
essentially,
when
you
get
started
you
you
can
it
kind
of
goes
in
a
in
an
order
here,
the
you
need
to
create
a
pool
and
essentially
you're,
not
really
creating
a
pool.
F
The
pool
really
represents
the
network
you're
creating
a
cool
handle.
So
this
is
for
clarity
here,
so
you
create
a
pool
handle
based
on
a
Genesis
file,
so
we're
showing
here
and
then
you
connect
to
that
cool
that
she
just
created.
And
then
you
create
a
wallet.
The
wallet
holds
all
of
your
keys
and
it
holds
your
dids
and
other
things.
F
You
can
create
multiple
wallets
yeah,
but
so
I
do
that
and
if
I
since
I
manage
multiple
networks,
I
create
multiple
wallets
to
manage
the
dits
for
each
Network
to
keep
them
organized
them.
Is
that
print?
So
you
just
create
a
wallet
and
add
a
key.
The
key
is
like
just
like
the
password
and
keep
your
wallet
secure,
and
then
you
open
your
wallet
and
then
you
can
edit
it
to
it.
Sorry,
the
metadata
part
of
this-
if
you
just
do,
did
new
it
works,
it
creates
a
new
did.
F
But
then
your
did
is
in
your
wallet
and
you
do
a
did
list.
You
just
show
it.
Then
you
don't
know
what
it
was
for.
The
metadata
helps
to
make
it.
So
when
you
do
a
did
list,
you
can
see
what
each
of
your
digs
is
in
your
wallet
and
for
a
guy
like
me
with
you,
know,
100
or
so
different
dids
that
I
use
for
different
purposes.
This
is
required.
They
only
have
one
or
two.
F
The
did
this
does
not
put
your
did
on
The
Ledger.
This
just
adds
it
to
the
wallet
and
then
someone
with
privileges
will
need
to
add
that
did
to
The
Ledger.
If
you
want
to
do
some
things
on
The
Ledger
and
then
to
do
things
with
that,
new
did
on
The
Ledger,
you
do,
it
did
use
and
then
and
you'll
be
able
to
do
things
on
The
Ledger
as
soon
as
you
did
has
been
added
to
it,
and
you
do
this
did
use
command
so
that
sets
you
up.
F
F
Sorry
I
touched
my
mouse
funniest,
which
is
on
there
sorry
about
that
this,
the
tab
tab
here
shows
some
command
hints
and
stuff.
If
you
do
a
help,
then
it
shows
more
details.
It
helps
so
you
type
in
Ledger
and
then
hit
tab
tab
and
it
shows
a
bunch
of
stuff
that
you
can
do
with
the
you
know,
starting
with
a
ledger
command
if
you
just
type
in
help
by
itself.
That
shows
the
main
commands,
which
is
these
ones
here.
F
Cool
wallet
did
and
list
types
to
help
demand
appear,
and
then
you
can
get
specific
help
as
it
goes
down
as
you
see
here
and
then,
if
you
want
to
go
and
check
out
something
on
The
Ledger,
you
can
do
a
get
Nim
or
a
git
schema,
get
those
kinds
of
things,
and
in
this
case,
since
your
nin
wasn't
put
on
the
lizard,
yet
it
would.
If
you
ran
this
command,
it
would
show
that
your
date
is
not
yet
on
The
Ledger.
F
I
J
F
A
F
F
F
E
I
E
So
we've
had
some
Community
meetups
that
have
discussed
the
integration
between
areas
and
fabric
I.
Think
just
the
previous
one
and
I
can
find
the
link
for
that
the
you
can
absolutely
do
that.
So
it's
worth
noting
just
from
a
terminology
perspective
that
we
don't
typically
issue
dids
to
individuals.
They
create
their
own.
That's
one
of
the
inversions
in
decentralized
identity
that
have
that
happens,
but
you
can
still.
E
D
H
E
Other
than
Indie
of
of
what
now
Ledger
yes
so
well,
there's
a
variety.
For
example.
There
are
did
methods
that
lean
on
ethereum
or
on
bitcoin,
for
example,
as
a
verifiable
data
registry
for
those
they're,
they
don't
all
have
the
same
features
as
Indie
Indie
is
relatively
unique
in
what
it
provides,
and
so
it
because
it's
purpose
built
for
identity
and
doesn't
have
some
of
these
other
features.
It
doesn't
do
smart
contracts,
it
doesn't
do,
there's
not
a
financial
trans.
E
E
K
K
This
is
Suma,
I
have
a
really
bad
throat.
Sorry,
if
I
sound,
terrible
I'm
trying
to
understand
more
about
the
Anon
thread
separation
and
whether
ran
on
threads,
can
today
be
implemented
separate
of
Indie
Aries
or,
if
that's
the
direction
we
are
going.
So
what's
the
timeline
I'd
like
to
understand
more
about?
What's,
what's
around
that
separation,
what
it
means
to
the
broader
identity
stays
yes.
E
E
In
the
subject
you
don't
strictly
need
Indy,
you
can
use
other
things
underneath
it
besides
nd2
as
a
vdr,
it's
worth
noting
that
you
you'll
need
to
be
prepared
to
provide
a
vdr
that
has
a
sufficient
number
of
features
in
order
to
to
make
it
useful.
Just
because
India
is
optional.
Indie
still
turns
out
to
be
an
excellent
choice
for
anyone
implementing
it
on
credits
and
and
so
I.
E
Don't
I
I
don't
want
to
convey
the
idea
that
you'll
simply
be
able
to
walk
away
and
not
use
anything
underneath
it
in
order
to
and
get
the
same
features
that
you
would,
if
you
were
basing
it
on
on
on
top
of
an
indie
ledger.
So
it's
a
little
hard
to
predict
the
timeline
which
I
believe
was
your
the
main
part
of
your
question
about
how
that
long?
E
That's
going
to
take
the
work
has
been
underway
for
a
little
bit
and
then
is
has
just
recently
moved
into
the
hyperledger
umbrella
as
the
Anon
creds
project,
and
so
those
those
meetings
are
ongoing.
It's
a
little
hard
to
Hazard
a
guess,
but
I'm
I'm,
assuming
that
at
some
point
next
year
that
spec
will
be
more
fixed.
There
are
folks
that
have
done
implementations
of
a
non-creds
that
are
separate.
The
checked
network
is
one
of
them
that
does
that,
but
they
did
so
sort
of
in
a
pre-standard's
way.
I.
E
The
Czech
folks
are
great
they're
involved
in
the
in
the
process
and
and
they
to
my
knowledge,
anticipate
you
know,
making
any
corrections
necessary
to
their
implementation
to
make
it
abide
the
the
future,
a
non-cred
spec
of
which
isn't
done
yet,
of
course.
So
it's
not
going
to
be
weeks.
It'll
it'll
be.
E
It'll
be
more
in
the
timeline
of
months
before
that's
ready,
but
that
that
that
is
a
direction
that
it
is
going.
I
do,
though,
want
to
highlight-
and
there's
not
enough
written
about
this-
we're
working
on
that
to
highlight
the
fact
that,
even
if
you
don't
have
to
use
Indie
Indie
turns
out
to
be
a
a
great
answer
in
a
in
a
a
very
large
number
of
of
cases,
and
so
the
use
of
use
of
a
non-cuts
without
Indie
is
generally
going
to
be
useful.
K
K
E
So
the
w3c,
the
w3c
data
model
spec,
has
opinions
about
how
the
the
data
ought
to
be
oriented.
Part
of
the
effort,
the
Anon
credits
effort
is
a
is
making
standard
a
representation
of
a
non-creds
in
the
w3c
compliant
format,
so
on
creds
isn't
yet
today,
mostly
for
historical
reasons,
non-creds
was
a
thing.
You
know
the
the
current
version
of
an
on
cred,
that's
running.
It
has
been
a
thing
before
the
w3c
data
model
was
was
created.
E
That
was
a
community
Meetup
that
in
DC
did
where
we
had
some
some
folks
talk
about
an
integration
that
they
did.
It
may
not
perfectly
answer
your
question
about
Fabric
in
any
integration,
but
I
thought
it
was
definitely
worth
mentioning
giving
given
the
combination
of
the
two
technologies
thanks
thanks
Lynn
for
grabbing
that
link,
Daniel
and
I
apologize
if
I
butcher
anyone's
name
is,
is
there
a
way
to
transfer
somehow
the
holder
right
of
a
verifiable
credential
to
another
holder?
E
So
there's
a
couple
of
things
you
might
mean
by
that
one
is:
is
that
can
I
maliciously
transfer
that
to
another
person
and
I
can't
without
revealing
keys?
That
would
compromise
all
of
the
credentials
that
I
held
so
so
there's
not
so
there
are
Protections
in
place
that
make
it.
You
know
a
severe
disadvantage
to
do
so
for
high
I.
E
If
there's
a
legitimate
way,
meaning
you
want
to
be
able
to
transfer
credential
from
one
person
to
another
person,
the
word
typically
used.
There
is
delegation,
so
you
would
delegate
a
credential
to
another
and
then
it's
up
to
the
verifier
of
the
credential,
whether
they
accept
that
delegation
or
not,
and
so
there's
a
there's,
a
handful
of
of
complicated
bits
in
there.
There
are
some
policy
ways
of
doing
that
in
some
cryptographic,
ways
of
doing
that,
but
in
general
the
cryptographic
or
the
verifiable
credential
Community
has
not
really
standardized
delegation
in
that
way.
E
F
L
L
Yeah
because
I
raised
my
hands,
so
no
one
answered
I'm
a
new
here
and
I
really
don't
know
like
about
the
tools
and
stuff,
but
is
it
close
to
each
team
up
that
we
use
it
at
the
background
of
websites
and
is
there
any
reference
that
I
can't
start
with
to
complete
with
you
guys
like
I,
can
like
study
or
see
it
in
YouTube
to
like
I
can
complete
with
you
and
about
the
tools
on
these?
So
there.
E
E
Most
of
these
things
are
based
on
on
Json,
not
HTML,
so
the
the
JavaScript
object
notation,
and
so
this
is
more
of
a.
This
is
more
of
a
way
to
communicate
between
systems
rather
than
than
present
stuff
directly
for
for
user
viewing.
The
way
HTML
typically
is
so
it's
a
little
different,
but
the
next
section,
Daniel
and
Char
will
be
talking
about
tools
that
exist
within
the
areas
ecosystem
to
help
to
to
get
in
and
started
in
some
of
these
things.
E
D
D
D
G
Indeed,
welcome
back
from
intermission,
we
had
a
lot
of
great
questions
going
on
there.
Please
feel
free
to
continue
to
put
your
questions
in
the
chat,
especially
as
we
continue
throughout
our
presentation
today
and
Sam
will
help
to
moderate
those
raise
them
as
needed
and
redirect
you
to
other
resources.
If
that's
helpful,
so
we
are
going
to
come
back
together
again.
Another
reminder
we
have
a
handout
accompanying
accompanying
our
presentation.
G
G
It
also
links
to
the
prerequisites
that
we
sent
out
as
part
of
the
workshop.
If
you
haven't
had
a
chance
to
go
through
those
go
through
those
prerequisites
yet,
but
would
like
to
try
to
get
on
top
of
those
before
we
get
into
the
Hands-On
portion
later
on
yeah.
So
let's
go
ahead
and
jump
into
it,
so
we
will
be
talking,
of
course,
about
hyperledger
Aries
I
am
Daniel
Bloom
I
am
a
software
engineer
at
ndco.
G
Also,
a
team
lead
I
guess
I
should
mention
that
you
can
reach
me
at
Daniel
dco.tech,
my
GitHub
handle
is
D
Bloom
and
wherever
I
can
get
that
handle
I
use
that
on
my
social
media,
but
might
not
be
the
same
across
all
of
them,
but
yeah
definitely
reach
out
on
over
email.
If
you
need
to
contact
me
or
or
get
up
that
will
work
as
well.
I
am
a
co-chair
on
the
diff
interop
working
group.
M
Thank
you
Danielle.
My
name
is
Char
Howland
and
I'm,
a
software
engineer
at
indicio,
there's
my
contact
information
as
well
I'm,
an
active
contributor
on
the
Aries
Cloud
engine,
python
ecosystem,
developing
plugins
and
other
purpose-built
agents
and
protocols.
I
also
co-chaired
the
identity,
implementers
working
group
and
the
Indie
contributors
working
group
I'll
just
take
a
brief
moment
to
plug
those
and
encourage
you
to
join
the
Indie
contributors.
Working
group
is
a
great
place
to
start
getting
involved
in
the
community.
M
We
take
a
high
level
View
and
track
progress
across
the
different
working
groups
and
the
community
and
the
foundations
that
Sam
mentioned
earlier.
We
invite
speakers
each
call
to
give
a
presentation
on
a
relevant
topic,
and
the
Indian
contributors
call,
of
course
focuses
on
the
hyperledger
indie
project
that
Lynn
mentioned
earlier.
G
G
I
also
encourage
you
to
ask
your
questions
in
the
Aries
channel
on
Discord,
we
have
Colton
Wilkins
from
the
indicio
team
and
others
who
are
monitoring
that
channel.
So
if
you
have
any
deeper
technical
questions
that
you'd
like
to
ask
or
are
having
technical
difficulties,
they
are
there
to
help
out
as
they
can.
We
even
had
last
time
the
bcgov
team
was
getting
involved
in
answering
the
questions,
and
it
was
a
really
good
Synergy
that
we
had
going
on
so
I
highly
recommend
getting
plugged
in
there
on
the
Discord
channels.
F
G
Yes,
let's
see
so
Sam
may
actually
redirect
some
of
your
questions
to
Discord
I.
Bring
that
up
just
so
you're,
not
offended
that
the
question
isn't
being
answered,
live
or
anything
I
think
there
are
just
some
questions
that
live
better
in
Discord,
first
of
all,
because
it's
excellent
to
get
input
from
other
members
of
the
community,
but
it's
also
a
public
record
of
the
questions
and
their
answers.
G
If
you
have
a
question,
it's
likely
that
somebody
else
has
a
very
similar
or
the
same
question
that
you
do
so
sharing
that
question
and
answering
process
is
helpful
for
the
whole
community.
After
all,
we
are
a
community
and
we'd
love
to
have.
You
join
us
on
Discord
so
with
that
jumping
in
on
our
first
conceptual
topic
here,
which
is
Agents
what
even
our
agents
so
agents
are
the
pieces
of
software
that
we
as
humans
use
to
help
us
interact
in
a
decentralized
identity.
G
G
So
when
we
talk
about
agents,
we
generally
mean
identity
agents
within
the
context
of
hyperledger
areas.
The
the
term
agent
is
quite
overloaded
in
the
general
Tech
space,
so
we
are
talking
about
identity
agents.
Specifically,
these
agents
are
again
in
the
software
that
helps
us
as
individuals
as
people
to
interact
in
a
decentralized
identity
world,
and
it
will
generally
act
on
behalf
of
a
single
identity
owner
and
by
identity.
Owner
I
mean
either
us
as
individuals,
or
it
could
be
an
organization
like
a
college
or
business
or
Bank
whatever.
G
Even
though
there
are
multiple
individuals
with
identities
behind
the
organization
as
a
unified
organization,
they
they
have
the
ability
to
issue
and
receive
credentials
that
identify
them.
So
a
organization
can
be
an
identity
owner.
It's
also
possible
for
Internet
of
Things
devices
to
be
considered
an
identity
owner.
Anything
that
makes
sense
to
assign
an
identity
in
these
verifiable
attributes
can
be
represented
by
an
identity
agent.
G
There's
an
excellent
question
in
the
chat
that
I
just
noticed
is
an
agent
a
wallet
and
that
kind
of
leads
into
the
next
Point
here,
so
agents
hold
and
use
cryptographic
keys
to
securely
perform
their
responsibilities,
so
the
term
wallet
as
we
tend
to
use
it,
at
least
within
the
hyperledger
area.
Space
refers
to
that
component.
The
Secure
Storage
element
backing
your
agent
that
helps
us
to
keep
our
keys
private
and
keep
our
verifiable
credentials
in
a
safe
location.
G
So
in
that
sense,
yes,
an
agent
has
a
wallet
and
we
will
often
refer
to
or
sometimes
I
guess
refer
to
agents
as
well,
it's
especially
in
the
mobile
wallet
since
when
we
have
a
an
application
on
your
mobile
phone
that
helps
you
achieve
all
these
goals,
but
I
would
narrow
the
scope
of
the
definition
of
a
wallet
to
that
Secure
Storage
element
and
then
the
agent
layers
on
top
of
that
Secure
Storage.
All
the
other
interactions
that
make
the
didcom
ecosystem
a
rich
and
secure
and
mutually
authenticated
mechanism
for
communication.
G
G
So
when
we
talk
about
identity
agents,
we
tend
to
have
these
terms
that
we
use
to
categorize
these
agents.
One
you'll
hear
a
lot
today,
for
instance,
is
a
cloud
agent,
since
we
are
using
the
Aries
Cloud
agent
python
project
and
the
the
term
Cloud
agent
generally
just
refers
to
an
agent
in
the
cloud.
It
does
not,
strictly
speaking,
imply
trust
or
the
lack
thereof
or
or
imply
that
it
will
be
one
particular
transport
mechanism
or
another
or
ownership.
It's
merely
a
the
location
of
the
agent.
G
G
These
are,
are
just
devices
at
the
edge,
some
other
examples
of
agent
categories
that
you
might
hear.
Mobile
agent
workstation
server
embedded
browser
blockchain,
as
might
be
embodied
by
a
smart
contract,
iot
or
mesh,
and
in
theory
there
could
also
be
paper
wallets
or
excuse
me,
paper
agents,
but
those
would
need
to
be
accompanied
by
Associated
infrastructure
to
help
us
actually
do
communication.
So
there's
a
lot
of
different
ways
to
categorize
and
group.
These
agents
together
and
not
all
of
these.
These
categories
are
mutually
exclusive
either.
G
The
Gin
most
general
advice,
I
think
that
I
can
give
on
the
spot,
for
that
would
be
to
make
it
as
close
as
possible
to
the
individual,
the
identity
owner
directly
owning
the
agent
and
the
the
hardware
that
it's
running
on
it's
possible
to
have
custodial
devices
custodial
agents
which
are
are
agents
that
are
hosted
on
behalf
of
an
identity
owner
by
another
party,
and
there
are
clever
ways
to
make
it
possible.
So
only
the
the
user
at
the
edge
has
access
to
the
data
stored
by
that
wallet.
G
G
G
So
I'll
start
off
on
the
least
complex
side
of
the
spectrum
with
a
static
agent,
and
these
are
agents
that
have
pre-configured
or,
in
other
words,
static,
key
configurations
and
endpoint
configurations
for
a
single
connection.
So
using
that
static
configuration,
they
have
the
ability
to
send
a
message
or
receive
a
message
from
exactly
one
other
agent.
G
But
these
are
an
important
role
in
especially
extending
out
to
Legacy
systems,
so
you
might
have,
for
instance,
a
a
static
agent
that
gets
triggered
by
a
web
hook,
whether
that's
from
GitHub
Shopify,
wherever
web
hooks
are
coming
into
your
system.
A
static
agent
could
be
used
to
take
that
data
received
by
the
web
hook
and
then
bootstrap
it
into
a
didcom
context
and
deliver
that
to
another
agent.
G
Another
example
of
a
static
agent
might
be
a
Cron
job
running
on
a
server
somewhere.
If
you
just
have
a
regular,
you
know,
update
on
statistics
on
I,
don't
know
number
of
verified
credentials
or
something,
and
you
want
that
to
be
admitted
to
another
external
agent.
A
static
agent
could
serve
that
purpose,
layering
on
complexity
from
there
we
have
what
you
might
term
as
a
thin
agent.
This
is
an
agent
that
looks
very
similar
to
a
static
agent,
except
that
it's
single
connection
is
updatable.
G
You
might
be
able
to
rotate
keys
or
update
endpoints
as
received
from
a
dipcom.
You
know
protocol
that
updated
those
values
within
the
agent.
However,
similar
to
these
static
agents,
these
are
generally
again
very
narrowly
focused
on
a
specific
use
case
within
the
context
of
a
single
relationship,
a
single
connection.
G
The
next
layer
up
from
there
would
be
a
thick
agent
and
I
mean
that
neon
ironic
sense,
I
suppose.
So.
This
is
multiple
updatable
connections
held
by
a
single
agent.
However,
the
use
case
for
that
agent
remains
narrow.
The
a
common
example
that
you
might
see
in
the
community
of
a
thick
agent
is
a
mediator,
which
is
an
agent
that
assists
agents
at
the
edge
who
have
inconsistent
connectivity
to
the
internet
to
receive
messages
in
a
consistent
manner.
So
mediators
have
many
connections
they're.
G
Generally
speaking,
you
could
have
a
mediator
that
is
only
willing
to
talk
to
a
single
connection,
but
they
have
many
connections
and
they're
willing
to
mediate
messages.
On
behalf
of
all
these
connections,
it's
you
could
conceive
that
a
mediator
would
want
to
be
able
to
issue
and
verify
credentials.
However,
that's
not
usually
something
that
a
mediator
agent
takes
on,
so
it
tends
to
be
a
little
bit
more
narrow.
In
that
sense,.
G
Let's
see
layering
on
from
there,
we
have
what
you
might
call
a
rich
agent,
and
this
actually
ends
up
to
being
the
best
descriptor.
Excuse
me
for
most
of
the
agents
that
will
be
that
we
see
in
the
Aries
ecosystem,
Aries
Cloud
agent,
python,
Aries
framework
JavaScript
Aries
framework
go
all
of
these
are
intended
to
be
a
rich
agent,
so
they
have
many
connections
and
they
are
designed
and
and
intended
to
fulfill
many
roles
on
behalf
of
a
single
identity
owner
yeah.
G
G
So,
identity
agents,
while
we
have
these
categories
and
and
these
terms
to
describe
their
complexity,
there
is
not
really
a
hard
and
fast
definition
of
an
agent
or
a
category
of
an
agent.
These
are
just
words
that
we
use
to
help
us
describe
the
interoperability
goals,
especially
of
these
agents.
So
we
can
say
that
if
something
is
characterized
as
a
cloud
agent,
we
don't
necessarily
expect
it
to
be
able
to
run
in
a
mobile
context
or
if
it's
a
cloud
agent.
G
All
right,
so
that
leads
us
into
the
specific
agents
that
we
will
be
using
today,
so
we
will
be
using
the
Aries
Cloud
agent
python
project,
which
and
I
pulled
this
directly
from
the
GitHub
description
for
the
project.
It
is
a
foundation
for
building
decentralized
identity,
applications
and
services
running
in
a
non-mobile
environment.
So
again,
coming
back
to
that
cloud
agent
category.
G
So
Aries
Cloud
agent
python
is
a
server
agent.
It
is
intended
for
use
on
a
server
and
therefore
does
not
really
have
all
the
infrastructure
or
architecture
that
is
generally
fitting
to
running
on
a
mobile
device
or
in
a
browser
you
might
be
able
to
include
it.
There
are
some
very
creative
and
inventive
people
out
there
that
I'm
sure
could
make
it
happen,
but
it's
just
generally
not
intended
for
that
use
case,
and
so
you
might
find
support
for
some
of
these
more
niche.
G
Environments,
I
suppose
within
the
ACT
Pi
code
base.
Another
project
is
likely
more
suitable
for
your
needs.
In
that
case,
acupai,
being
a
excuse
me,
but
act
by
being
a
server
agent
is
designed
for
horizontal
scalability
so
being
able
to
spin
it
up
in
a
kubernetes
cluster
and
dynamically
expand
and
Shrink
as
Demand
on
the
agent
grows
and
shrinks
is
an
explicit
goal
of
acupai.
G
G
Acupai
is
also
capable
of
using
the
verification
that
comes
bundled
with
a
lot
of
the
functionality
of
the
non-creds.
We
won't
be
getting
into
the
specifics
of
verification
today.
That
could
be
its
whole
other
separate,
Workshop,
truthfully
speaking,
but
yeah
it
does
have
support
for
that.
The
support
is
quite
mature
and
if
you
are
looking
into
revocation
support
for
anonymous
credentials,
acupai
is
an
excellent
option.
G
Aquify
also
supports
multi-tenancy,
which
coming
back
a
little
bit
to
that
question
that
was
raised
earlier.
Multi-Tenancy,
is
the
ability
for
the
same
agent
to
host
multiple
wallets.
This
is
useful.
You
know
just
for
the
sake
of
efficiency.
We
don't
want
to
necessarily
spin
up
an
individual
server
for
every
organization
that
needs
to
be
represented
in
an
identity
ecosystem,
so
using
multi-tenancy
we
can
double
up
resources
a
little
bit.
It's
still
an
a
secure
and
privacy
preserving
way,
but
again
that
that
is
a
use
case.
G
G
G
So
the
Aries
toolbox
is
a
development
and
testing
Tool.
It
is
not
generally
intended
as
an
end
user
product.
We
think
it's
great.
We
use
it
quite
frequently
as
at
in
dco,
especially
for
the
purposes
of
training,
debugging
and
testing,
but
it
is
not
geared
towards
an
end
user,
which
means
that
we
have
a
bit
of
a
guts
exposed
mentality
to
the
interface.
G
We
want
to
give
developers
as
much
information
as
they
need
as
conveniently
as
possible,
and
so
a
lot
of
the
the
debug
values
or
the
raw
values
of
credentials
for,
for
instance,
are
visible
to
the
user
of
the
toolbox,
which
again
is
generally
not
something
that
I
would
encourage
at
the
end
user
level.
Once
again,
there
are
other
projects
and
tools
out
there
that
are
far
more
appropriate
to
that
that
use
case
and
we'll
discuss
a
a
couple
of
those.
Briefly
as
we
go
along.
G
G
The
toolbox
itself
is
actually
an
agent,
which
is
something
that
I
hope
is
not
too
hard
to
wrap.
Our
heads
around
I'll
come
back
to
that
point
and
describe
in
more
detail
a
few
times
throughout
our
presentation
to
help
clarify
that
distinction,
but
the
toolbox
is
again
itself
an
agent
and
it
matches
the
thick
category
of
agent
in
the
sense
that
it
has
multiple
connections
but
still
has
a
pretty
directed
use
case.
It's
intended
to
act
as
a
UI
for
any
agent,
that's
running
somewhere
else
that
is
generally
headless.
G
The
toolbox
has
protocol
implementations
just
like
any
other
agent,
and
these
are
encapsulated
in
their
own
components.
They're
generally
quite
modular,
which
enables
us
to
dynamically
determine
which
UI
elements
to
show
on
the
screen,
as
the
connected
agent
supports
that
feature
or
does
not
support
a
feature
and
the
protocol
supported
by
the
toolbox
are
kind
of
split
by
a
couple
of
different.
G
Let's
see
it's
there's
a
set
of
direct
protocols
which
are
our
Communications
occurring
directly
between
the
toolbox
and
the
connected
agent,
and
then
there
is
indirect,
indirect
protocols
which
is
in
a
sense,
remote,
controlling
or
puppet
stringing.
The
connected
agent
to
trigger
interactions
between
that
agent
and
another
agent
and
again,
if
there's
any
confusion
here,
I
will
hopefully
continue
to
elucidate
this.
This
particular
problem
as
we
go
along.
G
G
G
Okay,
so
I
wanted
to
briefly
cover
a
high
level
description
of
the
architecture
of
an
agent.
I,
purposely
layered
things
out
here
in
such
a
way
that
it
looks
familiar
to
those
of
you
who
are
familiar
with
web
server,
development
and
I'll
kind
of
layer.
On
top
of
this
and
and
draw
some
analogies
here
so,
first
and
foremost,
we
have
the
transport
of
an
agent.
This
is
how
the
agent
actually
receives
and
sends
messages
with
other
agents,
since
that
is
by
definition,
a
significant
portion
of
the
responsibilities
of
Agents.
G
So,
just
like
a
web
server
where
it
receives
requests
over
HTTP,
an
agent
also
receives
messages
over
a
transport
could
be
HTTP
could
be
another
after
being
received
on
the
transport.
We
conceptually
have
this
middleware,
which
reads
the
bites
off
then
off
the
transport
adds
context
to
it
and
then
sends
it
off
to
a
Handler
for
processing.
G
In
a
very
similar
vein
agents
will
receive
bites
off
the
transport
those
bytes
are
encrypted,
so
we
first
need
to
pass
those
bytes
into
our
middleware
which
handles
decrypting
the
message.
Then
the
message
might
be
a
part
of
an
existing
exchange
of
messages,
in
which
case
the
the
context
of
the
message
needs
to
be
populated
with
the
state
of
the
protocol,
and
then
that
message
is
handed
off
to
a
Handler
in
order
for
the
next
step
in
the
protocol
exchange
to
be
engaged
in,
so
we
kind
of
have
a
flow
through
our
software.
G
G
All
right
so
occupy,
while
containing
those
basic
components
that
we
just
discussed,
also
has
a
number
of
other
components
which
help
us
to
control
it
and
extend
functionality,
interact
with
the
Ledger
and
other
agents.
So
we
of
course,
have
that
transport
and
and
our
handlers
for
messages,
but
in
addition
to
that,
aquify
exposes
an
admin,
API
interface,
which
enables
a
controller
component
to
exist
in
the
ecosystem,
and
the
controller
is
responsible
for
all
the
application
business
logic
of
the
agent.
G
The
didcom
protocol
exchanges
themselves
are
a
very
discrete
and
stateful
interaction
taking
place
between
agents.
We
don't
want
to
mix
in
business
logic
into
that
process.
However,
it
is,
of
course
necessary
to
have
some
control
of
the
business
logic
at
some
layer
of
the
stack.
We
need
something
that
says
what
values
go
in
the
credentials
that
get
issued
to
these
other
agents
and
that's
where
the
controller
comes
into
play.
It
can
also
help
you
control
under
what
conditions
credentials
are
issued,
help
you
navigate
governance,
Frameworks
and
so
on.
G
So
the
admin
API
provided
by
Aries
Cloud
agent
python
is
again
an
http
generally
Json
body
based
admin
API.
It's
a
restful
interface,
so
you
can
write
your
controller
and
whatever
software
stack
of
your
choice
generally,
whatever
fits
your
needs
best,
it's
also
I
guess
important
to
acknowledge
that
it's
not
a
one-directional
communication
between
the
controller
and
the
admin
API.
The
aquify
agent
will
also
send
web
books
back
to
the
controller
to
inform
it
of
asynchronous
events
taking
place
on
the
agent.
G
G
G
G
But
it's
not
the
only
way
to
do
it,
so
I
wouldn't
get
too
hung
up
on
whether
the
inclusion
or
exclusion
of
a
controller
makes
an
agent
as
long
as
the
agent
is
helping
us
to
represent
the
identity
owner
and
exchanging
VidCon
messages
as
an
example
of
something
else
that
could
or
could
not
be
considered
a
controller.
A
a
mobile
agent
has
a
UI
that
sits
directly
on
top
of
it
and
that
UI
is
controlled
directly
by
the
user.
G
So,
in
addition
to
the
controller
and
the
admin
API,
we
also
have
a
plugin
interface,
we'll
be
taking
advantage
of
that
plugin
interface.
Today,
I'll
get
a
little
bit
more
to
that
in
a
moment,
but
then,
of
course,
acupai
interacts
with
agents
over
the
Internet.
So
we
again
use
that
transport
to
send
and
receive
messages
from
these
other
agents
and
then
occupy
will
also
interact
with
distributed
ledgers,
especially
to
Anchor
publicdids,
so
that
it
can
issue
credentials
to
holders.
G
So
this
is
a
bit
of
a
reiteration
of
our
our
conceptual
discussion
that
we
had
a
moment
ago
about
the
responsibilities
of
an
agent
but
occupy
again
is
responsible
for
securely
storing
the
secrets
in
the
agent,
such
as
the
keys
associated
with
their
dids,
the
keys
associated
with
our
credential
definitions
and
are
verifiable
credentials
themselves.
It
also
holds
those
other
cryptographic
values,
crucial
to
helping
us
in
an
anonymous
credentials,
ecosystem
prove
non-revocation
and
that
disparate
credentials
were
received
by
the
same
individual
and
so
on.
G
So
acai
has
an
increasingly
mature
plug-in
system,
as
is
something
that
I've
been
really
involved
in
from
the
start,
so
I'm
quite
proud
of
this
fact.
The
plug-in
system
enables
us
to
do
things
like
plug
in
a
protocol
implementation.
We
have
a
generally
standardized
set
of
protocols
that
occupy
supports
and
it's
got
a
very
batteries
included
mindset.
G
So
it's
possible
that
you
won't
need
any
plugged
in
protocol
implementations
very
possible,
in
fact,
but
having
the
ability
to
bootstrap
your
own
custom
protocol
for
a
use
case
or
model
out
a
a
protocol
before
pursuing
standardization
of
that
protocol.
If
you
so
choose,
that's
something
that
we
can
accomplish
with
plugins
and
it's
something
that
we've
had
opportunity
to
do
at
ndco
quite
regularly
to
help
us
meet
new
and
interesting
use
cases
for
our
clients.
G
In
addition
to
protocol
implementations,
we
can
also
tack
on
additional
admin.
Api
endpoints
often
these
might
be
associated
with
these
additional
protocol
implementations
in
order
to
trigger
the
the
messages
being
sent
or
or
whatever
actions
are
necessary
to
proceed
with
the
protocol.
It
could
also
just
be
adding
functionality
to
acupai
just
period.
G
For
instance,
the
acropy
might
not
right
now
support
just
directly
signing
an
arbitrary
message
string
with
a
key
associated
with
the
did.
If
you
wanted
to
expose
that
as
an
API
admin
API
available
to
the
controller,
you
could
write
a
plugin
that
took
care
of
that.
For
you,
you
can
also
add
custom
event
handlers
within
a
plugin
again,
closely
related
with
the
protocol
implementations
in
the
admin
API
endpoints,
but
acupai
has
an
event.
G
Bus,
Which
fires,
key
events
as
triggered
by
other
protocols,
other
exchanges
taking
place,
and
if
we
wanted
to
tack
on
some
additional
functionality,
you
could,
for
instance,
have
a
monitoring
plug-in,
which
had
some
basic
statistics
that
it
was
monitoring
like
how
many
credentials
have
been
issued
or
what
have
you
that
could
be
a
plug-in.
That's
just
listening
to
events
and
then
just
pushing
to
your
your
logging
system
and
that
could
be
modeled
as
a
plugin.
G
Additionally,
we
have
an
ecosystem
that
did
resolve
that
did
resolvers.
These
are
components
that
help
us
to
resolve
metadata
about
dids
and
the
did
documents
which
contain
Keys
service,
endpoints,
things
that
are
critical
for
us
to
be
able
to
communicate
over
didcom,
but
also
critical
for
being
able
to
verify
credentials
of
the
w3c
Json
LD
variety,
especially
yeah.
It's
also
possible
to
plug
in
a
separate
message.
Queuing
systems
so
occupied
by
default
has
HTTP
transports.
G
So
yeah
hacked
by
plugins
highly
recommend
the
functionality
again
really
proud
of
this.
The
system
within
acupai.
We
will
be
using
this
plugin
system
today
for
the
indirect
protocol
implementation
that
we
mentioned
as
part
of
the
toolbox
and
this
this
indirect
protocol
implementation
allows
us
to
remotely
control
Aries
Cloud
agent
python
through
the
toolbox,
UI.
G
G
This
is
the
UI
that
we'll
be
looking
at
and
then
we
will
have
an
act
by
agent
with
the
toolbox
plug-in
installed,
and
this
is
what
will
be
remote
controlled
by
the
Aries
toolbox
and
we'll
have
two
instances
of
this
full
setup,
one
for
Alice
and
one
for
Bob
and
we'll
have
two
different
Aries
toolbox
Windows,
which
represent
our
view
into
Alice.
In
our
view
into
Bob.
G
So
these
are
just
a
couple
of
the
projects
within
the
hyperledger
areas
project.
There
are
many
other
agents
and
Frameworks
and
other
tools
available,
underneath
the
hyperledger
areas
umbrella,
as
well
as,
of
course,
within
the
other
hyperledger
projects,
but
I
wanted
to
call
out
a
few
of
them
here.
Just
so
you're
aware
of
the
the
others,
the
big
players
I
say
that
casually
I
guess,
but
it's
you
know
whatever
meets
your
needs,
is
the
big
player
for
you,
of
course,
so,
first
of
all
the
Aries
framework
JavaScript
project.
G
So
this
is
a
very
similar
project
to
acpi
there's
a
lot
of
shared
thought
space.
In
that
sense,
it's
it's
merely
just
an
implementation
within
JavaScript.
They
have
slightly
different
approaches
and
it's
a
it's
a
typescript
project.
So
if
strong
typing
is
your
thing,
Aries
framework
JavaScript
is
definitely
for
you,
but
it
also
serves
as
the
base
for
another
project
within
the
ecosystem,
which
is
Aries
bifold,
and
this
is
kind
of
right
now.
The
open
source,
mobile
agent
implementation.
G
It's
it's
been
around
for
a
while
now
and
it's
continuing
to
gain
momentum.
We
use
it
quite
heavily.
At
indicio
there
are
I
think
there's
a
team
at
the
government
of
British
Columbia.
That's
also
really
involved
in
the
development
of
bifold,
and
there
are
many
other
players
who
are
actively
working
on
bifold
as
a
mobile
agent
implementation.
G
There
is
also
Aries
framework
go
which
is
a
go
native,
Aries
framework
Aries
framework
go
just
to
briefly
call
out.
If
you
go
and
you
look
at
act
by
and
then
you
go
and
you
look
at
afj
and
then
you
go
and
look
at
AF
go
you'll
notice
that
there's
a
bit
of
a
different
approach
taken
within
Aries
framework,
there's,
not
a
better
approach,
one
way
or
the
other
they've
just
chosen
to
go
with
a
more
go
native
approach.
G
So
all
their
components
up
and
down
the
stack
are
written
directly
and
go,
which
could
be
a
huge
benefit
for
you.
You
might
be
interested
in
using
some
of
the
shared
libraries
such
as
Aries
asgar,
which
I'll
talk
about
in
a
moment,
but
it
is
a
very
mature
and
very
well
supported.
Go
alternative
for
did
communication
using
an
Aries
framework.
G
Also
notable
is
the
Aries
framework.net.
So,
if
you're
in
the.net
ecosystem,
there's
a
Code
out
there
for
you
as
well,
and
the
areas
framework.net
I'll
call
out
is
much
more
in
a
similar
vein
to
the
Aries
framework
JavaScript
and
neck
Pi,
taking
advantage
of
some
shared
libraries
as
opposed
to
going
hardcore,
full
spec
everything.net
or
anything
like
that.
G
Okay,
another
critical
project
to
make
you
aware
of
within
the
Aries
ecosystem
is
the
Aries
agent
test
harness,
and
this
is
a
code
base
that
enables
us
to
validate
the
compatibility
of
our
protocol
implementations
across
these
different
Frameworks.
So
the
Aries
agent
test
harness
can
spin
up
occupy
and
spin
up
in
areas
framework,
JavaScript
agent
and
then
using
back
channels
that
have
been
developed
for
this
purpose.
Trigger
interactions
between
acpi
and
afj,
observe
the
results
and
see
if
it
met
the
expected
end
criteria.
G
This
helps
us
to
construct
the
compatibility
Matrix
between
all
the
different
agents
and
Frameworks,
as
well
as
determining
the
compatibility
of
specific
protocols
between
these
different
Frameworks.
It's
a
really
valuable
tool
for
helping
us
to
validate
that.
We
are
all
on
the
same
page
as
a
community,
and
the
results
of
the
of
those
tests
are
run
regularly
and
and
there's
a
website
where
you
can
view
the
results
of
those
regular
runs.
G
Let's
see
other
areas,
agents
and
services,
we
have
the
aesthetic
agent
python.
This
is
a
library
that's
intended
for
developing
static
agents,
as
I
described
previously.
I
have
to
plug
this
one
because
I'm
actually
the
the
core
maintainer
on
that
project.
It's
a
good
code
base,
I
highly
recommend
it.
If
a
static
agent
fits
your
needs,
go
for
it,
and
then
we
also
have
an
Aries
mediator
service.
G
This
will
include
like
a
starter
controller,
which
you
can
then
customize
to
your
needs
for
your
your
mediator
service,
and
then
we
also
have
Aries
asgar,
which
I'm
kind
of
using
to
represent
a
wider
category
of
projects
within
the
areas
ecosystem.
We
have
shared
libraries
that
we
depend
on
to
do
some.
Some
critical
pieces
of
the
agent
stack
Aries
ascar,
for
instance,
is
a
Secure
Storage.
G
Implementation,
which
is
used
by
actpie,
will
be
used
by
afj
in
the
near
future
yeah,
and
it's
just
generally
helpful
for
having
a
a
clean,
well-vetted
interface
for
pluggable
storage.
It
supports
multiple
back-ends.
So
if
you
are
running
on
any
mobile
context,
for
instance,
you're
not
going
to
have
a
remote
postgres
database
that
you're
connecting
to
generally
speaking,
you
you'd
rather
probably
prefer
having
a
local
sqlite
database,
which
Ares
ask
our
makes
possible
to
use
either
one.
G
It's
also
possible
to
support
other
databases,
but
I
believe
the
only
database
is
currently
directly
supported
by
ask
our
SQL,
Lite
and
postgres
you'll
also
see
throughout
several
of
these
Aries
projects.
The
ndsdk
mentioned
we
are
in
the
process
of
phasing
out
usage
of
the
ndsdk
within
the
Aries
stack
in
favor
of
Aries
asgar,
and
a
couple
of
other
shared
components
and
the
the
hyperledger
and
on
creds
project
kind
of
plays
into
that
as
well.
G
Okay,
then,
finally,
one
other
code
base
to
call
out
here
one
other
project
I
should
say-
is
the
hyperledger
Aries
rfcs
repository
in
RFC,
if
you're
unfamiliar
is
a
request
for
comments,
and
this
is
where
actually
a
lot
of
the
content
for
our
Workshop
today
was
sourced.
This
is
where
we
as
a
community
gather
to
answer
some
of
the
difficult
questions
and
then
document
the
some
of
those
answers
in
a
way
that
helps
us
to
standardize
across
the
ecosystem.
G
This
is
where
the
ditcom
V1
specification
was
incubated
and
we'll
get
into
more
of
those
details
in
a
moment,
but
it
also
serves
as
a
really
good
knowledge
base
for
developing
your
own
agent
or
learning
about
the
ecosystem
of
agents
and
did
come
in
general
and
with
that.
That
concludes
my
portion
of
the
conceptual
stuff
and
I
will
hand
it
off
to
char
to
talk
about
protocols
and
messaging.
M
Okay
with
all
these
windows,
it
took
me
a
moment
to
find
my
mute
button,
but
here
we
go
thanks,
Daniel
I'm
about
to
talk
about
protocols
and
messaging.
So
we'll
start
with
talking
about
didcom.
What
is
did
come
did
come
is
commonly
a
little
bit.
The
long
version
is
the
communication
we
will
heretofore
refer
to
it,
as
did
com.
It
is
secure,
peer-to-peer
messaging,
whereas
verifiable
credentials
are
they
contain
information
about
the
subject.
Didcom
is
communication
with
the
subject,
and
so
why
is
this
important
did?
Come?
M
Is
the
way
for
entities
that
use
dids
and
verifiable
credentials
to
communicate
securely
and
privately,
so
didcom
provides
the
lower
layer
that
enables
other
Aries
protocols
that
we'll
talk
about
in
this
Workshop.
It
is
the
communication
protocol
used
for
sending
and
receiving
credentials
and
presentations,
but
it
can
also
be
used
for
much
more
than
verifiable
credentials,
including
instant
messaging
relationship-based
user
authentication,
which
refers
to
your
user
authentication.
That
uses
verifiable
credentials
to
verify
the
person
logging
in
as
well
as
buying
and
selling,
and
so
we
will
talk
about
some
of
the
properties
of
didcom.
M
M
What
makes
did
come
unique
in
these
respects
is
that
it
achieves
the
security
and
privacy
without
using
some
sort
of
third-party
or
centralized
service
to
secure
this
communication,
so
it
is
decentralized.
There's
no
centralized
identity
provider
holding
your
information
didcom
is
interoperable.
This
relates
well
with
the
decentralization
piece
you
are
not
locked
into
a
specific
app
or
operating
system
or
blockchain
in
order
to
use
didcom.
So
it
operates
well.
Between
existing
systems
did
come.
Is
transport
agnostic?
M
It
is
not
dependent
on
the
transport
to
make
sure
that
the
message
is
secure
and
private,
so
discount
can
use
HTTP,
websockets,
Bluetooth
email,
even
carrier
pigeon,
as
the
the
running
joke
in
the
community
goes
and
did
come
is
extensible,
so
you
can
add
messages
to
existing
protocols.
You
can
even
add
additional
protocols
all
together.
M
M
M
We
often
see
this
in
the
case
of
a
mediator,
which
Daniel
mentioned
earlier,
the
agent
that
Ralph's
message
is
to
another
agent
and
can
hold
messages
when
that
agent
is
offline
and
so
relating
back
to
the
transport
agnostic
property
of
didcom.
The
transports
can
be
different
during
different
segments
of
the
route.
M
And
I'd
like
to
touch
briefly
on
the
interactions
between
these,
these
properties
between
the
Transport,
Security
and
interoperability
properties.
So
the
security
of
didcom
is
not
dependent
on
a
given
transport.
The
security
is
taken
care
of
by
the
data
message
itself
and
does
not
rely
on
the
transports
for
security.
M
However,
transports
and
routing
can
augment
security
and
usability,
so,
for
example,
using
https
many
agent,
many
current
agent
implements
can
benefit
from
using
perfect
forward
secrecy.
This
is
a
method
that
ensures
that,
even
in
the
event
that
a
private
key
is
compromised,
an
attacker
could
only
decrypt
messages.
Information
from
that
single
session,
rather
than
the
entire
history,
so
removes
Reliance
on
a
single
private
key,
and
it
is
a
long-term
goal
to
implement
perfect
forward
secrecy
within.com
itself.
M
It's
also
important
to
note
that
requiring
specific
transports
can
damage
interoperability.
So
even
if
you
have
a
favorite
transport
that
you
like
to
use
requiring
one
means
that
your
your
Solutions
can't
integrate
well
with
the
rest
of
the
system,
and
so
people
are
encouraged
to
take
advantage
of
Technologies
through
protocols
using
protocols
rather
than
transports,
to
make
these
interactions
more
efficient.
M
So
to
step
back
just
a
bit
and
look
at
the
the
big
picture,
we'll
look
at
the
layers
of
didcom,
so
at
the
lowest
layer
we
have
the
transport.
As
we've
said,
this
can
be
any
transport
moving.
One
layer
up
bids
are
very
important
to
securing
Communications
in
particular.
Peer
dids
are
essential
for
didcom
peerdids
are
exchanged
directly
between
parties
and
are
not
on
The
Ledger,
unlike
public
dids,
which
are
published
to
The
Ledger,
and
so
participants
exchanged
dids
and
using
the
signing
and
encryption
keys
and
service
endpoints
information
resolved
from
their
did
docs.
M
M
Many
of
the
layers
below
did
come
have
their
own
protocols,
including
TCP
HTTP,
managing
did
stiffy
Hellman
Etc,
but
income
Protocols
are
are
different
from
those
lower
lower
layer.
Protocols
did
come.
Protocols
build
on
top
of
those
lower
layers
to
Define
protocols
with
real
world
social
value.
Allow
you
to
do
things
like
forming
connections
requesting
and
issuing
credentials,
proving
things
buying
and
selling
Etc.
M
M
Rest
uses
a
client
server
model
where
there's
a
hierarchy
between
the
server
and
the
client's
server
is
generally
considered
to
be
the
source
of
truth
and
the
client
is
dependent
on
the
server,
whereas
in
didcom
the
participants
in
the
exchange
are
peers
by
default
with
roles
that
are
defined
by
a
protocol.
So
in
a
particular
scenario
of
a
protocol,
one
particular
participant
might
take
on
a
role.
That
means
they
are
trusted
to
be
the
source
of
Truth.
For
that
particular
aspect,
but
at
a
basic
level,
didcom
doesn't
have
that
same
hierarchy.
M
Rest
has
the
one
request.
One
response
system,
whereas
did
come,
you
can
exchange
as
many
messages
back
and
forth.
That's
necessary
to
complete
the
interaction.
Rest
uses,
HTTP
methods
to
indicate
which
action
should
be
taken,
whereas
did
come
as
we've
said,
transport
agnostic,
so
it
could
not
be
dependent
on
HTTP
methods.
The
action
is
determined
by
message.
Type
rest
uses
paths
to
indicate
action
did
come,
uses
message,
types
which
we'll
talk
about
more
for
an
indication
of
what
action
should
be
taken
and
finally
rescues
its
pads
routed
to
handlers.
M
So
now
we
will
get
into
ingredients
for
this
recipe
for
stateful
interaction.
These
are
the
components
for
a
didcom
protocol,
so
we
have,
of
course,
the
name
and
version.
We
have
a
unique
URI
that
identifies
the
protocol,
a
the
message,
type
name,
which
refers
to
the
the
messages
included
in
this
protocol.
We
have
roles
that
the
sender
and
receiver
can
take
on
in
the
protocol.
M
State
and
sequencing
rules
can
be
thought
of
as
a
state
machine
of
how
these
messages
and
roles
are
expected
to
proceed.
We
have
the
events
and
constraints
that
provide
trust
and
incentives.
So,
for
example,
maybe
in
the
specific
protocol
you
require
that
parties
have
exchanged
credentials
to
verify
their
organization.
This
gets
more
into
the
business
logic
side
of
things
than
than
the
VidCon
protocols
themselves.
M
M
So
we
have
name
basic
message
and
version
is
1.0
version.
Roughly
follows
the
semantic
versioning
specification
here.
We
only
include
the
major
and
minor
version,
though
those
first
two
numbers
since
the
third
number.
Here's
the
patch
a
version
that
does
not
impact
the
external
API
and
since
did
come,
can
be
thought
of
as
an
external
API.
We
can
leave
it
off.
M
M
M
M
M
Now
that
we've
unpacked
type,
we
can
look
at
the
other
attributes
in
the
message.
The
message
type
determines
what
attributes
are
expected
to
be
present
in
the
message.
The
ID
is
a
universal,
unique
identifier
for
the
message
in
basic
message.
We
also
expect
to
see
a
localization
decorator,
send
time
attribute
and
a
Content
attribute.
M
So
now
we'll
look
at
a
more
complex
example
from
the
issue
credential
V1
protocol.
This
is
the
offer
credential
message
in
particular,
so
we
can
recognize
pieces
of
the
type
attribute.
It
has
the
same
document
URI.
It
did
come
dot,
org
issue.
Credential
is
the
protocol
name,
it's
version
1.0
and
then
offer
credential
is
the
message
type
name,
and
then
we
can
see
the
attributes
expected
for
this
message
include
comment.
Credential
preview
offers
attach.
M
M
So
agent
messages
are
sent
between
identities
to
accomplish
some
shared
goal.
This
could
be
establishing
connections
between
identities,
issuing
and
presenting
verifiable
credentials,
instant
messaging.
The
examples
we've
looked
at
so
far
of
basic
message
and
offer
credential
messages.
Those
are
agent
messages,
foreign
and
then
a
packed
message
is
a
wrapper
around
an
agent
enabling
messages
to
be
securely
sealed,
while
in
transport
from
One
agent
to
another.
So
you
can
see
how
this
could
easily
be
referred
to
as
an
envelope
or
encryption
envelope.
M
M
Packed
messages
are
end-to-end
encrypted,
as
we
have
mentioned,
even
if
a
message
is
routed
through
one
or
more
other
agents
on
its
way
to
to
the
Final
Destination,
whatever
agents
in
intermediate
steps
cannot
access
the
contents
of
that
message.
All
they
see
is
the
the
outside
rapper
encrypted
packed
message,
and
this
encryption
envelope
is
a
derivative
of
the
Json
web
encryption
specification.
M
So
back
to
our
example,
agent
message:
we
will
see
what
it
looks
like
to
transform
it
into
a
packed
message,
so
we
will
pass
it
along
into
a
pack
method
that
takes
this.
The
plain
text
agent
message
as
the
message
parameter,
along
with
their
verification
key
and
my
signing
key,
and
so
the
verification
key
refers
to
the
public
key
in
an
ed
25519
public
private
key
pair.
The
signing
key
is
the
private
pair
and
so
from
this
operation
results
impact
message
that
looks
something
like
this.
M
M
M
A
few
require
modifications,
but
mostly
they
are
interchangeable,
and
so
again
they
work
fundamentally
in
the
same
way,
that's
why
it's
been
relevant
to
still
talk
about
V1,
but
V2
does
have
some
significant
improvements
on
V1
in
that
modifications
have
been
made
to
allow
it
to
be
more
widely
applicable
outside
of
the
original
hyperledger
areas.
Community,
where
did
come,
V1
originated
just
a
few
distinctions
to
call
out
one
is
the
message
structure
split
between
headers
and
body.
These
next
two
go
hand
in
hand.
M
M
M
E
Correct
VidCon
V2
was
designed
so
that
you
could
detect
an
inbound
message
whether
it's
version
one
or
version
two.
So
we,
the
Aries
adoption
of
VidCon
V2,
is
underway
and,
and
we
expect
most
projects
all
projects
that
I
know
of
that
are
that
are
going
on,
will
will
have
a
period
where
they
accept
did
both
did
come
V1
and
did
conv2.
Of
course,
after
some
period
of
of
transfer,
then
then
did
comfy
one
will
be
deprecated
and,
and
did
come.
V2
will
will
remain
in
in
production
thanks.
G
It's
a
interesting
question
in
the
chat.
What
are
best
practices
for
storing
vids
as
a
holder,
I
think
a
lot
of
the
same
recommendations
around
storing
Keys,
just
private
Keys
apply
as
well
to
storing
up
bids
and
their
private
key
material
within
the
hyper-ledger
Aries
ecosystem.
We
are
fond
of
the
usage
of
Aries
asgar
as
a
Secure
Storage
implementation.
G
However,
there
are,
of
course,
other
Secure
Storage
Solutions
out
there,
and
the
SDK
is
still
pretty
widely
used,
and
it
even
has
a
slightly
more
strict
key
interface
that
it
that
means
that
you're
not
even
able
to
pull
the
private
key
material
out
of
your
own
wallet
it.
It
is
acting
more
as
a
software.
Secure
Enclave
is
the
term
that's
been
used
for
it.
We
are
in
the
process
of
phasing
out
ndsdk,
though,
but
it's
still
definitely
a
valid
mechanism
for
storing
those
secure
values.
G
I
think
we
also
see
hsms
as
a
highly
recommendable
piece
of
Hardware
to
be
using
in
the
future,
especially
for
the
cloud
context
where
hsms
are
already
a
you
know:
a
frequent
fixture
of
security
in
those
contexts.
The
primary
issue
we
have
in
that
sense
is
that
a
lot
of
the
protocols,
sorry
protocols,
is
an
overloaded
term.
A
lot
of
the
cryptography
that
we're
currently
using
is
has
not
yet
bubbled
all
the
way
down
to
the
HSM
layer.
G
There
are
some
notable
exceptions
and
I'm
aware
of
more
than
one
effort
within
the
community
to
enable
HSM
support
within
the
context
that
did
come
and
Aries
more
generally
and
and
Anonymous
credentials,
but
yeah
best
practices
store
them
as
securely
as
possible.
If
you
do
not
have
experience
in
that
in
that
area,
I
highly
recommend
relying
on
a
solution
like
Aries
ask
car.
M
Another
question
that
came
up
in
the
chat
is
a
direct
message,
but
I
feel
like
it's
worth.
Many
people
could
benefit
it's
a
good
question.
So
do
we
need
blockchain
to
implement?
This
did
come
itself.
I
I
talked
earlier
about
how
we
use
peerdids
to
communicate.
So
it's
peer-to-peer
Communications.
Those
dids
are
not
going
on
The
Ledger.
We
are
not
interacting
with
The
Ledger.
When
we
I
usually
did
come
you'll
see
in
the
next
sections
when
we
get
into
the
ways
that
we
use
verifiable
credentials.
M
G
D
D
G
So
we're
going
to
be
doing
a
bit
of
a
tag
team
between
myself
and
Char.
I'll.
Take
us
through
some
of
the
Hands-On
portions
and
you
can
follow
along
at
home
for
that
and
then
I'll
pass
back
to
char
to
discuss
a
little
bit
more
of
what
we
just
examined
or
or
discussing
the
next
portion
that
will
be
coming
up.
G
G
G
G
We
are
going
to
start
off
by
getting
the
Aries
toolbox
running,
so
first,
we
need
to
navigate,
to
you,
know,
open
up
a
terminal
navigate
to
the
directory
where
we
have
cloned
down
the
Aries
toolbox
repository
in
my
case,
this
is
in
the
Aries
toolbox,
folder
that
is
likely
different
for
you
and
then
let's
do
a
few
things
just
to
make
sure
that
we've
got
the
most
recent
code
available
to
us.
So
we'll
start
off
with
a
quick
get
pull
if
you're
already
up
to
date.
Excellent.
G
G
G
G
So
now
that
we've
got
the
toolbox
window
open,
we
are
ready
to
open
up
another
terminal
window.
I've
got
a
separate
one
here
for
the
Aries
Cloud
agent,
python
agents
that
we
will
be
pulling
up
to
accompany
our
our
toolbox
instance
here.
So
first,
we
start
off
by
changing
directory
into
the
location
where
you've
cloned
the
xpi
plugin
toolbox.
Repo
again,
this
is
likely
to
be
different
from
my
location,
but
this
is
where
I've
got
it.
G
Inside
of
this
folder
there's
going
to
be
a
demo
folder,
we
need
to
change
directory
into
that
and
then
from
here
we
are
ready
for
our
next
command,
which
is
pulling
up.
The
docker
compose
in
my
case
on
my
machine
I
have
to
use
sudo
good
chance.
You
don't
need
to
use
that,
depending
on
your
environment,
but
I
will
be
including
it
here.
G
So
we
do
Docker
compose
Dash
F,
which
allows
us
to
specify
the
file
that
we'll
be
running
in
this
case
we're
doing
the
docker
Dash
compose
dot,
Alice,
Dash
bob.emlfile
and
then
we'll
do
an
up
Dash
Dash
build
on
the
end
of
that
again,
these
commands
are
inside
of
the
handout.
If
you
would
rather
just
copy
paste
those
values.
G
All
right
I'll
give
that
just
a
second
to
pull
up.
If
you're
running
this
for
the
first
time,
you
will
have
to
wait
through
an
image
build
for
the
toolbox
image
shouldn't
take
too
long
and
then
before
long,
you
should
see
several
containers
started
up
here
and
some
really
large
QR
codes.
These
are
convenient
if
you're,
connecting
to
a
mobile
agent
first,
for
instance,
through
a
automatically
generated
connections
invitation.
G
We
use
this
quite
regularly
when
we're
testing
out
Aries
bifold,
for
example,
there's
also
other
ways
to
get
a
QR
code,
representation
of
our
invitation,
urls,
so
I
think
it's
through.
Excuse
me
a
quick
explainer
on
the
containers
that
we're
looking
at
here.
We
see
an
agent
Alice
and
an
agent
Bob,
and
these
are
the
actual
AC
Pi
containers,
the
ones
that
are
critically
performing
the
functions
of
an
agent.
We
also
have
a
couple
of
tunnel
agents.
G
These
are
just
a
supporting
feature
for
this
Docker
compose
script
by
including
the
tunnels.
We
make
it
really
easy
for
us
to
be
able
to
connect
from
a
mobile
agent
which
isn't
going
to
be
on
the
same
machine,
and
it's
certainly
not
going
to
be
within
the
same
Docker
networking
namespace
so
by
including
the
tunnels
we
are
able
to
it,
connects
to
external
devices
and
can
even
connect
across
the
internet.
So
that
is
something
to
bear
in
mind.
G
G
G
G
We
now
need
to
repeat
that
step
with
Bob
here,
so
I'll
copy
that
paste
into
the
new
agent
connection
hit
connects,
and
now
we
see
both
Alice
and
Bob
admin
connections
available
to
us
within
the
toolbox
for
the
rest
of
our
our
Hands-On
portion,
we'll
be
using
the
toolbox
windows
that
are
opened
by
clicking
the
open
text.
Underneath
each
of
these
agent
cards,
then
I'll
try
to
arrange
my
windows
in
such
a
way
that
you
can
see
some
of
the
values
at
the
same
time
at
least
make
that
a
little
bigger.
G
Okay,
so
these
are
our
Alice
and
Bob
windows
and,
as
we
were
discussing
earlier,
these
are
more
or
less
a
window
into
the
agents
that
are
running
within
the
docker
containers.
Acupai
doesn't
generally
provide
a
UI
on
top
of
the
agent.
That
is
something
that
we
are
providing
from
the
toolbox
in
order
to
help
us
click
around
the
interface
a
little
bit
more
easily
and
be
able
to
go
through
these.
G
So
these
are
the
windows
that
we
will
be
using.
Let's
take
you
through
a
brief
walkthrough
of
the
UI
just
so
you
can
have
a
little
bit
better
orientation
before
we
move
on
to
the
next
steps,
so
first
the
nav
menu
on
the
left.
This
is
where
we
access
most
of
the
functionality
here,
so
this
first
section
where
it
says
toolbox
to
agent.
These
represent
the
direct
protocol
implementations
that
we
referenced
earlier.
G
So
we
see
there's
a
couple
of
legacy
iterations
of
these
protocols,
but
we
also
see
the
didcom.org
version
of
those
protocol
identifiers.
So,
by
looking
at
this
list,
we
can
see
that
the
connected
agent
supports
coordinateation
1.0.
That
also
supports
the
introduction
service
also
supports,
discover,
features,
2.0,
routing
issue,
credential
2.,
it's
a
comprehensive
list
of
all
the
features
that
are
implemented
by
Mac
by
where
you
will
see
repeats
between
the
Legacy
protocol
identifier
and
the
current
protocol.
Identifier,
these
are
are
representing
the
same
protocol
implementation.
G
So
there's
toolbox
the
clients,
these
protocols,
that
that
allow
us
to
remote
control
agents
that
are
connected
to
it.
So
the
admin
basic
message
allows
us
to
control
the
basic
message:
functionality.
The
admin
routing
allows
us
to
control
the
routing
admin
transaction
author
agreement
allows
us
to
do
stuff
with
the
transaction
after
agreement
and
so
on.
G
Thank
you.
All
right,
so
there
is
that
that's
the
the
discovery
features.
We
also
have
the
ability
to
send
a
basic
message
directly
to
the
agent
from
the
toolbox.
This
is
really
quite
helpful,
often
when
you're
creating
an
agent
for
the
first
time.
Basic
message
is
the
first
protocol
that
you
might
Implement
just
because
it's
basic
and
easy,
so
this
is
a
useful
way
for
us
to
trigger
a
message
being
sent
to
an
agent
and
see
if
it
was
able
to
be
correctly
decrypted
on
the
other
side.
G
We
also
have
a
compose
window
which
allows
us
to
manually
construct
or
copy
paste
in
the
plain
text
of
an
agent
message
to
be
sent
to
the
message
in
the
background
or
to
the
agent.
In
the
background,
sorry,
this
is
actually
arguably
one
of
the
most
useful
features
of
the
toolbox.
In
my
opinion,
all
these
functions
are
great
and
help
us
do
things
quicker,
but
this
is
one
that's
like
very
unique
to
the
toolbox.
G
We
actually
have
the
ability
to
directly
construct
a
message
and
send
it
with
the
proper
encryption
and
all
that
stuff
to
the
agent.
In
the
background,
since
vidcom
operates
at
this
generally
at
the
agent
message
level,
but
then
must
be
in
transport
encrypted,
it
can
be
difficult
to
get
to
that
encryption
step
quickly.
G
This
was
received
from
the
agent
in
the
background,
and
then
we
can
also
view
the
full
message
history
here.
If
we
choose-
and
this
get
this
more
gives
you
a
view
of
the
internals
to
how
the
toolbox
and
the
agent
are
interacting,
as
opposed
to
what's
going
on
between
Alice
and
Bob,
as
we
will
go
on
to
connect
and
Trigger
some
interactions
there.
G
So
this
is
just
between
the
toolbox
and
the
agent.
By
analyzing
these
messages,
we
can
get
a
sense
for
what
messages
are
being
exchanged
between
Alice
and
Bob,
but
we
do
not
have
a
direct
log
of
those
here.
That's
a
feature
that
would
be
good
to
add.
We
still
haven't
gotten
to
that
point
yet
with
the
toolbox
but
yeah.
So
that's
a
quick
walk
through
of
the
toolbox
UI,
just
as
a
quick
review.
M
M
Alice
and
Bob
both
have
their
Edge
agents,
their
mobile
devices
and
then
their
media
mediator
agents
that
are
acting
on
their
behalf.
We've
mentioned
mediators
a
few
times
before
in
in
this
example
scenario
where
Alice
and
Bob
are
using
mobile
agents
and
meteor
actually
is
required
for
them
to
receive
messages,
since
the
edge
agent
itself
will
not
have
an
end
point
and
we're
also
dividing
between
Alice's
domain
versus
Bob's
domain.
M
What
we
mean
by
domain
here
is
that
these
are
the
devices
owned
by
and
under
the
control
of
Alice
versus
Bob,
and
so
for
Simplicity.
We
can
abstract
away
the
multiple
agents
in
each
domain
and
just
consider
Alice
and
Bob.
So
here
Alice
is
going
to
create
an
invitation.
As
Daniel
said,
this
can
be
a
QR
code,
an
invitation
URL.
This
invitation
is
out
of
band,
which
means
that
it's
not
communicated
directly
through
didcom,
because
that
connection
channel
has
not
yet
been
established.
M
This
invitation
that
Alice
sends
to
Bob
has
an
initial
connection:
key
endpoint
info
routing
keys
and
a
label,
so
the
initial
connection
key
is
used
exactly
once
just
for
sending
that
connection.
Request
message
back
after
receiving
this
invitation,
the
endpoint
information
and
routing
keys
are
sent
to
make
sure
that
that
the
that
Bob
can
send
a
message
back
to
Alice.
The
label
is
who
Alice
says
she
is.
This
is
not
a
verifiable
attribute
more
of
a
suggestion
and
a
convenient
way
to
identify
this
invitation.
We
can't
absolutely
trust
it.
M
An
identity
verification
should
happen
after
the
connection
is
formed,
and
so
here's
what
this
invitation
looks
like
as
an
agent
message.
We
might
recognize
some
of
these
pieces
from
earlier.
The
message
type
URI
shows
that
this
is
an
invitation
message
within
the
connections
V1
protocol,
and
then
it
has
that
information
that
I
mentioned
the
label,
Keys
service,
endpoints
and
so
after
Bob
receives
this
invitation.
If
he
wants
to
connect
with
Alice,
he
sends
a
connection
request
message
back
to
Alice's
agent.
M
The
language
here
might
seem
a
little
bit
unusual.
That
Alice
sent
the
invitation
and
Bob
is
sending
a
request
to
connect
in
response,
it's
important
to
know
that
they
are
peers
in
this
interaction
and
there
are
no
imposed
requirements.
So
Alice
can
send
an
invitation
to
you
guys
with
Bob
and
give
information
on
how
to
reach
her,
but
Bob
can
choose
to
send
or
not
send
a
request
to
actually
connect
with
Alice.
M
But
even
if
it's
automated,
this
is
what's
going
on
in
the
background,
and
so
this
connection
request
contains
labels
and
similarly
the
suggestion
of
identity
Bob's
did,
which
you
will
use
in
the
future
to
secure
his
Communications
with
Alice
and
his
did
document
or
did
Doc
for
short,
which
contains
relationship,
Keys,
routing,
Keys
service,
endpoints.
All
the
cryptographic
information
required
to
secure
future
communications
and
allow
Bob
to
receive
messages
from
Alice
here
is
what
the
agent
message
of
the
connection
request
looks
like,
and
here
we
see
that
it
includes
the
did
and
did
Doc
now.
M
So
this
is
what
the
connection
response
agent
message
looks
like.
There
are
additional
identifiers
to
make
sure
that
Bob
can
correlate
the
request
he
sent
out
with
this
response
and
the
connection
data
that
Alice
sent
to
Bob
is
signed
using
the
key
Alice
used
in
the
initial
invitation.
So
Bob
knows
that
the
this
response
came
from
the
original
creator
of
the
invitation.
M
So
now
that's
the
dids
and
did
docs
have
been
exchanged.
This
connection
is
established
and
a
quick
note
on
forming
connections
using
did
come
as
we've
talked
about
before
these
are
peer-to-peer
connections,
but
they
are
not
necessarily
direct.
We
can
use
a
third
party
like
a
mediator,
whatever
third
party
again
cannot
see
the
contents
of
that
message,
because
it
is
end-to-end
encrypted
between
Alice
and
Bob.
M
The
connection
is
not
a
transport
layer
connection
like
socket
or
open
HTTP
request
Etc,
it
is
a
VidCon
connection
and
then
the
the
agents
are
connected
and
the
interaction
is
considered
complete
when
Alice
and
Bob
have
exchanged
dids
keys
and
service
endpoints.
That
information
held
in
the
did
Doc
for
future
communication.
M
G
Indeed,
all
right,
so
up
to
this
point,
we've
talked
about
the
direct
protocol,
implementations,
the
Discover
features
and
these
over
here,
and
we
have
not
yet
touched
the
agent
to
agent
interactions.
So
once
again,
this
is
the
toolbox
telling
Alice
the
remote
agent
to
do
something
with
another
agent
potentially
or
to
trigger
some
other
action
directly
on
the
agent.
So
we
will
start
off
by
taking
a
look
at
the
invitations
tab
here
on
the
left,
so
the
invitations
tab
allows
us
to
create
a
new
invitation
which
should
hopefully
be
pretty
self-explanatory.
G
There
is
a
perhaps
rather
complicated,
looking
form
here.
A
lot
of
these
values
are
of
Interest
primarily
to
developers
and
and
those
who
are
working
on
agents
for
our
purposes
today.
We
do
not
actually
need
to
modify
any
of
these
values,
so
the
default
values
of
the
form
are
perfectly
acceptable,
but
we
do
have
the
ability
to
instruct
the
agent
to
assign
an
alias
to
the
connection
in
terms
of
our
internal
representation
of
this
connection,
so
we
can
easily
identify
it
later.
G
We
can
specify
what
the
label
should
be
in
in
the
invitation
assign
some
other
metadata
to
it
and
optionally
selecting
whether
the
connection
should
be
formed
through
a
mediator.
Again,
we
won't
be
modifying
any
of
these
values.
We
do
want
to
make
sure
that
the
auto
accept
is
flagged
as
true.
So
it'll
be
the
blue
background
on
that
one,
and
then
we
are
ready
to
create
a
new
invitation.
G
G
If
you
do
not
see
the
list,
it's
it's
possible
that
you've
got
a
connection
timed
out
or
something
you
can
refresh
the
list
by
pressing
the
refresh
button
manually
by
clicking
on
the
list
item,
we
get
a
little
bit
more
detail
on,
what's
included
in
the
invitation,
we
see
some
of
the
properties
of
the
invitation
that
were
assigned
on
creation.
We
say
when
it
was
created.
We
also
have
the
ability
to
create
a
helpful
QR
code
that
allows
us
to
scan
this
from
a
mobile
agent.
G
You
can
also
expand
these
curly
braces
here
to
see
a
little
bit
more
of
the
raw
values
that
are
being
passed
back
and
forth
between
the
toolbox
and
the
agent
in
order
to
represent
this
invitation.
If
that's
of
interest
to
you
so
in
connections
on
The
Bob
agent,
now
we
see
a
list
of
active
connections.
G
We
can
actually
do
the
same
on
Alice
as
well,
and
we
see
that
both
of
them
have
a
connection
to
the
toolbox,
and
that
represents
our
window
here
actually
connecting
to
the
agent
and
it's
communicating
over
a
did.
There's
a
reciprocating
did
on
the
other
end
of
the
connection,
which
is
the
toolbox,
it's
a
little
confusing,
since
we
are
both
observing
from
the
toolbox,
but
we're
observing
ourselves
in
third
person
so
to
speak.
We
do
not
need
to
worry
too
much
about
the
details
of
that
connection.
G
At
this
point,
though,
so
we'll
we'll
go
ahead
and
just
accept
that
as
it
is,
and
then
we
will
copy
the
invitation
URL
into
this
box
here
on
the
connections,
tab
within
Bob
and
then
click
the
add
button
that
was
rather
rapid
transition
from
pending
to
active
state.
But
there
was
a
period
of
time
where
it
was
in
the
pending
State
there.
G
It
then
automatically
Advanced
to
an
active
connection,
as
the
two
agents
exchanged
messages
asynchronously
in
the
background,
it's
possible
that,
if
you're
connecting
to
a
mobile
agent,
for
instance,
where
it's
not
scripted
to
automatically
accept
the
connection
after
scanning
the
QR
code,
it'll
wait
for
user
input
before
it
sends
the
connection.
And
then
at
that
stage
you
would
see
a
pending
connection
for
a
little
bit
longer
as
we
waited
for
the
other
end
of
the
connection
to
accept
the
invitation.
G
We
can
then
see
our
connections
on
either
end.
So
Alice
has
a
connection
for
Bob.
You
can
see
his
did,
or
is
that
invited,
and
we
see
that
the
state
is
active.
We
can
again
inspect
the
the
raw
details
of
that
connection
record
if
we
choose
and
then
likewise,
on
the
other
end
for
Bob,
so
we'll
see,
the
two
rules
are,
you
know,
inverted
to
represent
the
other
end
of
the
connection
and
again
you
can
expand
and
view
those
connection
details.
G
So
Alice
and
Bob
are
now
connected.
I
will
repeat
those
steps
just
again
briefly
in
case
you're,
following
along
at
home,
so
I'm
going
to
go
ahead
and
delete
both
of
these
connections.
Just
so
I
don't
get
confused
later
on,
and
then
we
will
go
to
invitations.
You
can
see
that
the
original
invitation
disappeared.
That's
because
it
was
consumed
along
the
way
by
default.
These
are
single
use
invitations.
We
can
specify
a
multi-use
invitation
if
we'd
like
to
and
then
that
enables
multiple
connections
to
be
formed
with
the
same
invitation.
G
Multi-Use
invitations
are
especially
useful
for
say
your
a
mediator
and
you'd
like
to
enable
multiple
connections
to
connect
to
the
same
invitation
without
having
to
regenerate
one
for
each
client
that
connects
to
us.
So
you
can
take
that
multi-use
invitation
post
it
on
a
web
page
and
then
anybody
who
would
like
to
use
your
mediator
after
going
through
your
your
paywall
or
whatever
you
have
in
place,
they
can
access
that
invitation
and
then
form
a
connection
with
your
mediator.
G
I'll
go
ahead
and
make
a
single
use.
Invitation,
though,
and
same
process
will
expand.
The
list
item
copy.
The
URL
should
see
a
little
notification
that
tells
you
it's
hit
the
kit,
the
clipboard,
and
then
we
can
paste
that
value
into
the
invitation.
Url
box
on
Bob's
side
in
the
connections,
tab,
click,
add
and
again
went
from
pending
to
active.
Let
me
check
out
the
Allison
we
see.
Bob
has
been
restored
in
our
connections
here.
G
So
now
that
Alice
and
Bob
are
connected.
We
have
the
ability
to
exchange
messages,
we'll
we'll
get
into
more
interesting
messages
as
we
go
along
here.
But
let's
take
a
quick
look
at
just
a
basic
message:
example
being
sent
between
Alice
and
Bob.
So
if
you
click
on
the
messages
tab
here
in
the
agent
to
agent
section
pulls
up
a
very
rudimentary
kind
of
chat
window
between
Alice
and
Bob.
G
Well,
first,
you
have
to
select
which
connection
you're
you're
talking
to
so
now,
I'll
collect
or
excuse
me,
I'll,
select,
Bob
and
now
it
represents
a
chat
window
tuba.
So
I
can
type
out
a
message
for
Bob
hit
send
and
we
see
that
the
message
was
sent.
We
can
see
the
timestamp
and
we
see
a
little
notification
popped
up
on
the
other
end.
That
indicates
that
if
a
message
was
received
from
Alice,
so
if
we
go
to
our
messages
on
Bob's
end
as
well,
we
select
the
Alice
conversation.
G
So
these
are
our
basic
messages
being
sent
back
and
forth
between
Alice
and
Bob.
Basic
message
is
itself
a
protocol.
As
we've
looked
at
previously,
when
Char
was
going
through
our
VidCon
conceptual
section
and
it's
a
protocol
that
represents
a
basic
messaging,
instant
messaging
protocol
between
Alice
and
Bob.
These
are
not
particularly
sophisticated
messages.
It's
just
basically
the
content
itself
and
the
the
sent
time.
G
G
G
So
we've
gone
through
connecting
Alice
and
Bob
we've
gone
through
a
quick
example
of
sending
basic
messages.
These
were
all
taking
place
using
admin
protocols
in
the
background
here
which
enable
these
interactions
through
the
toolbox,
and
you
can
look
at
the
message
history
in
more
detail.
If
you'd
like
to
see
some
of
the
internals
of
what's
going
on
but
yeah
there
we
go
so
I'll
pass
it
back
to
Shar
to
talk
about
our
next
steps.
M
So
now
that
we
have
connected
the
agents,
we
can
practice
issuing
and
verifying
credentials
between
them
as
we
jump
into
credentials
at
this
point
in
the
workshop,
I
want
to
mention
that
we
are
focusing
on
the
Indie
and
non-codes
credentialing
system
in
this
demo,
which,
as
Sam
mentioned
earlier,
is
a
hyperledger
project.
With
this
nice
new
logo,
a
non-creds
enables
your
knowledge,
proofs
and
selected
disclosure
and
revocation
these
are
important
privacy.
Preserving
properties
that
we
will
describe
and
demonstrate
in
this
in
this
next
section
occupy,
is
also
capable
of
w3c
credentials.
M
M
So
the
issuer
is
the
entity
that
decides
which
credentials
to
issue
to
whom
you
might
think
of
how
a
university
issues
a
diploma
to
a
graduating
student
or
how
a
business
might
issue
a
credential
to
an
employee
to
give
access
to
facilities.
For
example,
in
order
to
issue
credentials,
the
issuer
interacts
with
the
holder,
who's
the
person
or
entity
receiving
the
credential,
the
graduated
student
or
the
new
employee.
M
In
our
examples,
the
issuer
writes
to
The
Ledger,
so
they
put
certain
public
information
related
to
the
credential
on
The
Ledger,
so
that
when
the
holder
wants
to
prove
information
that
they
have,
this
credential
a
verifier
can
read
this
information
from
The
Ledger
and
make
sure
that
the
credential
was
actually
issued
by
this.
This
issuer,
as
Scott
talked
about
earlier,
but
just
to
really
emphasize
it.
A
common
misunderstanding
is
that
personally,
identifiable
information
is
put
on
The
Ledger
pii
does
not
go
on
The
Ledger.
M
This
is
explicitly
against
the
agreement
that
anybody
who
writes
to
The
Ledger
must
agree
to
it's.
Only
the
public
cryptographic
information
necessary
for
verification
that
goes
on
The
Ledger
and
will
go
into
depth
more
on.
We'll
show
the
steps
and
and
exactly
what's
happening
there
so
we'll
talk
about
the
issuer
in
context.
This
diagram,
we
will
build
it
up
as
we
demonstrate
issuing
and
verifying
credentials.
It
should
look
a
bit
familiar
from
Scott's
present
Scott's
section
earlier
today,
and
so
we
are
using
these
three
entities.
M
The
names
are
intuitive,
but
just
to
be
super
explicit,
since
the
rules
are
very
important,
the
issue
or
issues
the
credential,
that's
DMV
or
university,
an
employer
Etc
the
holder
holds
the
credential.
This
is
the
subject
associated
with
the
credential
and
the
verifier
verifies
the
credential
when
the
holder
presents
it.
M
So
these
are
the
the
same
steps
broken
down
because
we're
going
to
look
at
each
of
them
more
closely
and
demonstrate
them.
So,
in
order
to
complete
the
issuers
first
step,
we
need
to
Anchor
a
public
did
to
The
Ledger
write
a
new
schema
to
The
Ledger,
or
we
could
retrieve
a
pre-existing
schema
from
The
Ledger
and
then
create
a
credential
definition,
write
that
to
The
Ledger,
and
then
we
are
able
to
actually
issue
that
verifiable
credential.
M
So
looking
at
that
first
step,
a
few
things
to
call
out
before
we
can
anchor
it
did.
This
is
calling
back
to
what
Lynn
said
earlier.
There
are
multiple
rules
when
interacting
with
The
Ledger,
there's
an
author
who
can
create
transactions
and
issue
credentials,
but
they
need
an
endorser
to
endorse
their
transaction
for
it
to
actually
be
written
to
The
Ledger,
and
they
must
have
their
data
on
The
Ledger.
The
endorser
can
endorse
transactions
to
to
put
them
on
the
Ledger,
and
there
did
must
have
endorser
status
on
The
Ledger.
In
this
demo.
M
Our
issuer
will
have
both
the
endorser
and
author
privileges
so
we'll
create
the
transaction
and
also
endorse
it.
Have
it
written
to
the
to
The
Ledger
and
before
anchoring
it
did.
We
need
to
have
signed
the
transaction
author
agreement.
We
are
agreeing
like
I,
said
to
never
put
private
personally
identifying
information
on
The,
Ledger
and
so
with
that
I
will
pass
it
over
to
Daniel
for
a
demo
of
those
steps.
G
Cool,
thank
you.
Char.
There
were
a
couple
of
questions
in
the
chat
that
I
want
to
briefly
address
before
we
go
on
to
talking
about
the
dids,
just
to
kind
of
raise
them
up
into
the
call
and
talk
about
them
a
little
bit
more.
So
first
one
here
Brands
asked
what
is
the
limit
and
cause
of
the
limit
on
the
number
of
messages
that
can
be
received
per
second.
G
G
G
So
raw
messages
per
second
isn't
really
a
common
metric.
That
I
think
we
throw
around
within
the
hyperledger
Aries
ecosystem,
but
it
is
certainly
an
interesting
metric
to
have
I
I
Sam
also
kind
of
addressed
this
question
already,
but
again
just
to
raise
it
to
the
recorded
video
just
for
the
benefit
of
others.
How
would
we
go
about
going
Beyond
one-to-one
communication,
so
this
is
a
subject
of
ongoing
conversation
within
the
ditcon
working
group
about
the
the
right
way
to
handle
group
communication.
G
The
VidCon
V1
specification
technically
allows
for
us
to
send
messages
that
are
encrypted
to
multiple
parties,
but
that's
a
a
I
think
generally
sub-optimal
in
The
Wider
context
of
group
communication.
We
only
have
I
Think,
Mutual
authentication
from
one
point
to
the
next
and
when
we
go
to
group
authentic
group
messaging,
there's
some
cryptographic
breakdowns
in
that
certain
group
exchange,
so
there's
ongoing
conversations
there.
This
is
actually
quite
a
recent
thing.
G
Yes,
one
other
thing:
I
I
will
briefly
discuss
as
well.
Using
did
come.
You
have
the
you,
have
a
a
very
multi-purpose
useful,
secure,
mutually
authenticated
Communication
channel,
which
means
that
we
have
pretty
strong
assurances
that
the
person
on
the
other
end
of
the
line
is
the
person
that
we
think
they
are,
which
is
something
that
isn't
the
case
with
a
traditional
client
server
model.
G
We
only
have
strong
authentication
on
the
server
side
and
not
on
the
client
side,
unless
you
have
client
certificates,
which
is
a
whole
other
thing,
I
guess
so,
making
taking
advantage
of
this
really
valuable
cryptographic,
pairwise
connection
that
we
have,
we
can
negotiate
Communications
through
other
existing
communication
channels,
so
an
analogy
that
I
recently
explored
on
the
subject.
It's
like
you
have
messages
being
sent
by
mail
going
back
and
forth
between
Alice
and
Bob
as
an
example
and
say,
Alex
and
Bob
are
stealing
their
envelopes
with
their.
G
You
know
their
special
Wax
Seal
or
whatever,
so
they
know
that
it
came
from
Alice,
because
that
seal
is
is,
as
expected,
analogy
breaks
down.
If
you
look
at
it
too
closely,
but
it
holds
for
a
you
know:
High
conceptual
level,
it's
basically
the
equivalent
to
then
negotiating
a
separate
Communication
channel.
It's
basically
the
equivalent
of
saying
in
a
letter
from
Alice
to
Bob.
Here
call
me
at
this
time
at
this
number
and
we'll
have
a
live
communication
over
the
phone.
G
A
similar
process
can
be
used
within
the
didcom
world,
bootstrap
communication
through
another
mechanism,
and
then
you
can
also
negotiate
using
did
come.
You
know,
whatever
security
or
other
secrets
that
you
need
in
order
to
make
sure
that
you're
actually
talking
to
the
person,
you
think
you
are
once
you
switch
communication
channels
to
that
other
negotiated
system.
G
G
It's
not
strictly
required
that
any
particular
kind
of
agent
fulfills
a
role.
It
is
a
little
weird
that
we
have
somebody
that
we
are
talking
about
as
an
individual
being
an
issuer.
That's
not
typically
how
it
works,
usually
it'll
be
a
public
organization
who
has
good
reason
to
put
public
values
on
the
network,
but
in
our
for
our
purposes,
we'll
use
Allison
Bob
as
issuer
and
bear
and
holder
rather
just
for
Simplicity
in
our
our
demonstration
and
setup
here
today.
G
So
Alice
will
be
needing
to
create
a
did
and
then
submit
it
to
the
network
that
we
are
using
for
our
demonstration
today.
So
in
order
to
create
a
new,
did
we'll
go
to
the
bids
Tab
and
before
I
click
on
this
I'm
going
to
briefly
Prime
you
for
what
comes
next
so
dids
require
that
we
sign
the
transaction
author
agreement
required
by
the
network.
G
So
since
the
dids
tab
has
some
operations
that
result
in
transactions
being
submitted
to
the
network
before
we
are
able
to
submit
any
values
to
the
network,
we
must
first
accept
the
transaction
author
agreement
and
make
sure
that
that
acceptance
and
a
representation
of
that
acceptance
is
included
in
all
subsequent
transactions
act.
By
handles
most
of
the
details
for
that
of
that,
for
you,
it's
just
a
matter
of
you
know
hitting
the
right
endpoints
to
store
our
acceptance
within
the
wallet
and
then
equify
ensures
that
those
are
all
included
on
transactions
thereafter.
G
So
when
I
click
on
the
dids
tab,
it
will
pull
up
a
pop-up
here
that
says
transaction
author
agreement
using
this
module
requires
signing
the
transaction
author
agreement.
So
if
we
click
through
hit
continue,
we
can
then
see
the
text
of
the
transaction
author
agreement.
I
can
have
fun
reading
through
the
agreement
there.
G
I
shouldn't
mock
too
much.
It
is
an
important
agreement.
You
should
read
these
and
understand
what
you
are
agreeing
to
and
writing
these
values
to
the
network.
Basically,
it
boils
down
to
that.
You
will
not
put
anything
that's
inappropriate
to
put
on
The
Ledger
on
The
Ledger,
such
as
personally
identifying
information
and
such
so
when
we've
read
through
that,
we
can
accept
the
terms
of
the
transaction
author
agreement
and
hit
submit,
and
now
we
are
ready
to
interact
with
the
dids
tab
in
the
toolbox.
G
So
there
are
three
dids
that
already
exist
within
our
agent.
These
dids
represent
a
pairwise
connection.
These
are
the
dids
that
were
created
in
order
to
represent
the
connection
with
the
toolbox,
our
first
connection
with
Bob
and
then
our
second
connection
with
Bob.
We
actually
deleted
the
the
connection
value
itself,
but
the
did
it
still,
pure
and
available
in
case
we
used
it
for
other
purposes,
but
yeah
these
are
our
did.
Values
in
the
future
of
these
will
be
explicitly
perioded
values.
At
the
moment.
These
are
something
resembling
periods.
G
There
are
values
that
are
not
written
to
a
ledger
anywhere
and
there's
a
deeper
discussion
on
that
that
I
won't
get
into
at
the
moment.
That's
why
we
have
three
dids
available
here
within
my
view.
We
will
then
create
a
new
did
I'm
going
to
assign
a
label
to
the
did
just
so
we
can
easily
identify
it
as
the
one
that
we've
written
to
The
Ledger
later
on
so
I'll
say
that
this
is
labeled
as
public.
G
You
can
explicitly
set
a
date
value.
This
is
generally
not
an
encouraged
practice.
This
will
actually
be
explicitly
prohibited
in
future
iterations
of
the
did
method
specification,
especially
as
we
transition
to
the
end
needed
method
as
a
community,
but
that
is
possible.
You
can
also
specify
the
seed
similar
to
how
Lynn
was
talking
earlier
about
when
using
the
ndcli.
You
can
create
a
did
and
specify
a
seed.
You
might
not
have
talked
about
that.
G
Actually
I
might
be
remembering
wrong,
but
you
can
specify
a
seed,
and
this
allows
us
to
recreate
the
did
in
a
separate
wallet
later
on.
If
we
need
to
which
is
sometimes
a
useful
feature,
especially
a
sweet
bootstrap
new
issuers
on
a
network
I
will
leave
the
seed
empty.
However,
we
do
not
need
to
deterministically
generate
this,
then
using
a
seed
value,
so
next
I
will
hit
create,
did
and
then
our
did
pops
up
in
the
list
and
we
can
expand
these
list
items.
G
Okay,
so
from
here
we've
created
a
did,
but
it
currently
exists
only
within
the
wallet
it
has
not
been
written
to
the
network.
Yet
so,
in
order
to
get
it
onto
the
network,
we
require
the
assistance
of
another
entity
that
already
has
permissions
to
write
to
the
network,
which
in
this
case
will
be
the
ndco
self-serve
application.
G
G
G
G
Thanks
for
the
heads
up
on
that,
one
then
yeah.
So
here
is
the
self-serve
page
yep
yep,
trying
to
hit
that
corner
there.
We
go.
I
just
did
this
on
my
other
window,
which
isn't
showing
up
for
whatever
reason,
but
I
will
mime,
as
though
I
was
submitting
it
a
new
just
kind
of
clean
up
my
windows
here,
a
little
bit.
Okay,
there
we
go
so
what
I
did
was
I
took.
G
This
did
value
and
pasted
it
into
the
field
in
this
very
key
value
and
pasted
it
in
there
and
there
we
go
I
already
hit
submit
in
my
other
window.
It
was
submitted
I
think
if
I
hit
it
again.
It
would
tell
me
that
the
verkey
was
already
found
on
the
network,
so
probably
wouldn't
be
too
happy
with
me.
So
I'll
refrain
from
hitting
the
submit
button,
but
we
now
have
successfully
written
our
did
to
the
ndco
test
network
using
the
self-serve
tool.
G
So
now
that
we've
written
that
did
to
the
network,
and
since
we
did
it
out
of
band
using
the
self-serve
tool,
we
don't
actually
have
any
explicit
indication
back
on
the
agent
that
it's
ready
for
us
to
activate
it.
So
we
need
to
trigger
it
to
activate
the
did,
so
it
will
use
that
did
for
our
future
Ledger
rights
that
are
going
to
take
place.
G
We
see
that
the
there's
also
a
drop
down
here,
that
we
can
use
to
select
the
did
to
use
as
the
public
did.
It
would
have
been
helpful
if
it
used
the
label
instead
of
the
actual
did
value.
I,
guess
that's
a
feature
request
for
the
toolbox,
but
I
know
that
it
was
the
7
a
f
one.
So
I'll
make
sure
that
is
selected
as
our
active
did.
M
Great,
thank
you
Daniel,
so
the
next
step
is
to
write
or
retrieve
a
schema.
A
schema
is
the
data
organization
structure
that
defines
the
attributes
in
a
credential.
So
for
an
employee
credential,
for
example,
the
attributes
in
the
schema
might
include
last
name.
First
name
address
security
clearance,
level
date
of
hire
things
like
that
and
on
the
right.
This
shows
what
ischema
actually
looks
like
it
has
a
schema
name
version
ID
and
shows
the
attributes.
In
this
simple
example:
we
just
have
first
name
last
name
age.
M
The
schema
ID
includes
the
did
under
which
it
was
created.
The
two
identifies
it
as
a
schema,
and
then
it
has
the
the
schema
name,
Ed
version
included
in
that
and
then
after
we've
written
a
schema
to
The
Ledger,
we
can
see
it
on
The
Ledger,
using
the
Indie
scan
tool
that
Lynn
talked
about
earlier,
and
if
you
are
retrieving
a
schema,
this
is
where
you'd
go
to
retrieve
a
schema
ID
in
order
to
use
it
to
issue
a
credential
so
from
the
schema
step
the
next.
M
The
next
step
is
to
use
that
schema
to
create
a
credential
definition.
A
credential
definition
creates
the
issuer
specific
cryptographic
Keys
necessary
for
issuing
a
credential.
So
the
schema
is
a
collection
of
attributes
in
a
credential,
but
it's
not
associated
with
any
entity.
The
credential
definition
is
what
binds
a
schema
to
a
specific
issuer
so
that
when
the
holder
is
presenting
their
credential,
the
verifier
can
see
that
this
credential
was
issued
by
this
specific
issuer.
M
Creating
the
credential
definition
generates
cryptographic
keys
for
each
attribute
with
a
public
and
private
portion,
the
public
portion
is
stored
on
The
Ledger
with
the
schema.
This
is
what
allows
the
verifier
to
verify
that
the
issuer
issued
this
credential.
The
private
key
is
maintained
by
the
issuer,
and
the
issuer
uses
these
private
keys
to
sign,
decide
each
attribute.
You
might
wonder
why
we
need
a
key
pair
for
each
attribute,
rather
than
one
key
pair
for
the
credential
as
a
whole.
M
A
little
earlier
I
mentioned
that
we
we
are
talking
about
it
on
credits
here
in
a
non-correct
support,
selective
disclosure,
which
is
when
I
present
only
some,
but
not
all,
of
the
credentials
in
an
attribute,
and
so
we
need
to
have
keys
for
each
attribute
because-
and
we
will
demonstrate
this
I
might
choose
to
only
reveal
a
subset
instead
of
all
of
the
attributes
in
a
credential.
So
that's
why
each
attribute
needs
its
own
individual
pair.
M
We
can
see
on
the
left
what
the
credential
definition
looks
like.
We
see
that
it
has
a
credential
definition
ID.
It
shows
the
schema
ID
of
the
schema
that
it
was
created
from
the
attributes
that
we
entered
in
when
creating
this
schema.
The
credential
definition
ID
includes
the
did
the
issuer.
The
three
identifies
it
as
a
credential
definition.
The
CL
refers
to
caminiskia
the
creators
of
this
digital
signature,
and
then
it
also
includes
the
schema
name
and
version
here.
M
The
did
with
within
the
schema
ID
and
the
credential
ID
is
the
same
because
it
was
the
the
same
entity
under
the
same.
Did
that
created
both
the
schema
and
credential
definition.
If
we
retrieved
a
schema
from
The
Ledger
created
by
another
issuer,
we
would
see
that
the
credential
definition
ID
begins
with
our
did
the
did
of
the
agent
that
retrieved
the
schema
and
made
it
into
a
credential
definition,
but
that
the
schema
ID
included
in
that
credential
definition
will
still
include
the
did
of
the
creator
of
the
schema
and
yeah.
M
This
goes
just
to
to
Really
emphasize
what
I
said.
What
we've
said
earlier
about
how
no
pii
goes
on
The
Ledger.
This
is
the
information
that
the
issuer
writes
publicly
to
the
legend.
Issuers
did
schema
and
credential
ID
are
essential
to
issuing
a
credential,
but
what
they
provide
is
can
be
more
thought
of
as
a
blank
template,
and
that
is
what
is
publicly
available.
So
the
actual
values,
your
personal
information
that
you
would
fill
into
that
template
is
never
available
on
The
Ledger.
G
G
G
Let's
see,
we
then
have
the
ability,
from
this
view,
to
create
schemas
and
credential
definitions
so
starting
off,
we
first
need
the
schemas
which
are
just
described.
We
create
schema
with
a
any
name
that
we
choose
for
our
schema.
Let's
go
for
an
example
today,
as
an
employment
schema
and
we'll
say
it's
version
1.0,
and
then
we
can
click
on
the
add
attribute
button
to
add
additional
attributes
to
the
schema
so
from
here.
This
is
where
we
Define
what
attributes
we
expect
to
find
within
credentials
issued
from
the
schema
with
the
schema.
G
Of
higher
sure
and
we'll
go
with,
let's
say
that
you
need
a
clearance
level
in
order
to
access
some
building
on
this
organization's
campus,
so
we'll
have
a
clearance
level
as
well
included
in
this
employment,
Prudential
cool.
So
with
these
values,
we'll
have
four
separate
attributes.
These
names
are
significant
in
the
context
of
the
Anon
creds
credentialing
ecosystem.
These
are
the
values
that
the
verifier
will
request
from
a
holder
in
order
for
them
to
prove
these
attributes.
So
it's
important
that
we
do
our
best
to
reuse
schemas.
G
So
we
don't
have
you
know
a
million
different
iterations
of
first
name,
first
name,
maybe
a
value
first,
that
represents
the
same
thing
and
kind
of
localizing
around
schemas
that
fulfill
the
use
case
that
we
need
and
then
allowing
reputation
to
be
developed
around
these
schemas
helps
us
to
to
know
what
attributes
to
request
as
a
verifier.
It's
also
possible,
though,
not
presented
within
this
UI,
to
specify
multiple
name
attributes
that
we're
expecting
so
if
it
was,
if
we
did
know
of
several
credential
values
that
had
multiple
acceptable
attributes
for
the
same
information.
G
Essentially,
we
could
say
that
this
could
be
represented
as
first
name
without
the
underscore
first
underscore
name
or
given
name
or
whatever
it
is,
and
then
we
can
further
restrict
those
values
based
on
specifying
which
credential
definition
ID
we
expect
these
to
be
from.
This
is
less
of
a
problem
in
an
ecosystem
where
you
are
both
an
issuer
and
a
verifier.
You
know
what
attributes
you've
issued.
So
you
know
what
attributes
to
ask
for
when
you're
verifying,
but
again
this
also
kind
of
gets
into
the
concept
of
having
an
established
governance
framework.
G
You
know
what
attributes
are
out
there
for
your
use
case
and
and
have
made
use
of
existing
schemas
on
the
network
to
help
you
accomplish
your
goals.
Okay,
that's
enough
rambling
about
the
schema.
I
will
go
ahead
and
hit
confirm
which
will
cause
a
schema
to
be
created,
schema
transaction,
be
created
and
then
submitted
to
The
Ledger,
and
then
we
see
a
record
of
that
schema
that
we've
created
available
to
us
here.
G
So
now
that
we
have
a
schema,
we
can
now
create
a
credential
definition.
So
if
we
click
on
the
create
button
on
the
credential
definition
section
here
now,
we
can
select
an
employment
1.0.
That's
the
schema
that
we
just
created.
We
have
the
option
to
do
revocable
credentials.
I
won't
click
through
those.
This
time
around
again,
revocation
is
a
whole
other
discussion
that
we
could
have
so
I'll
I'll
Reserve,
that
for
future
opportunities
to
meet
and
discuss
these
this
functionality
of
an
entreprints
verification.
G
This
one
takes
a
significantly
longer
time
than
the
schema
in
order
to
write
and
there's
a
couple
of
reasons
for
that,
as
Char
mentions,
there's
an
individual
key
pair
for
each
attribute
within
the
credential
being
created
and
in
the
CL
signature
scheme.
These
are
RSA
Keys,
which,
for
those
who
are
not
cursed
with
this
knowledge,
RSA
keys
are
prime
numbers.
Large
prime
number
values
that
just
take
more
effort
to
generate
than
elliptic
curve.
Cryptography
does
so.
G
Those
are
our
large
random
numbers
generated
representing
our
RSA
key
pairs
for
each
of
those
attributes
within
the
credentials.
I
should
clarify
I've
gotten
into
the
lead,
so
I
apologize,
but
I
should
clarify
that
the
signature
is
used
for
these
credentials
when
they
are
actually
issued
are
not
RSA
signatures.
They
are
the
CL
signatures
that
are
critical
for
the
abilities
to
do
selective
disclosure-
and
you
know
private
holder
bindings
with
Anonymous
credentials,.
D
G
We
use
RSA
key
values
that
are
say
like
keys,
but
using
a
different
signature
scheme
Okay,
so
we've
walked
through
creating
our
own
schema.
I
will
briefly
take
a
look
at
what
it
looks
like
to
retrieve
a
schema
from
a
network
as
well,
so
we're
using
the
indicio
testnet
so
I'm
going
to
click
on
that
click
on
the
domain,
Ledger,
subledger
and
then
I'm
going
to
filter
by
schema
and
I
can
see
the
schema
site
schema,
I
just
created.
G
Somebody
else
must
have
created
one
following
on
I'm
going
to
come
and
grab
a
random
schema.
Trend
schema
ID
here
so
I
just
selected
one
no
idea
who's
written
this,
but
then,
if
I
scroll
down,
there's
a
transaction
ID
section
this
might
be
somewhere
else
in
the
in
the
text.
I
just
I
know
that
I
can
find
it
there.
That
again
could
have
been
up
here
somewhere
and
it
was.
It
was
right
there
anyways,
so
we
we
select
transaction
ID
and
then
from
the
toolbox.
We
can
put
that
into
this
text
box
here.
G
G
These
are
just
local
representations
that
are
useful
for
being
able
to
quickly
recall
the
attributes
associated
with
the
schema
when
we're
doing
the
actual
credential
issuance
making
sure
that
we
populated
all
those
attributes
and
such
but
yeah.
This
is
a
local
representation
of
the
value
that
was
published
to
The
Ledger
by
some
other
party.
G
G
Again
takes
a
second
as
it
creates
those
keys,
sometimes
if
it
doesn't
show
up
even
after
a
sufficiently
long
time
you
can
hit
that
refresh
button
and
most
of
the
time
it'll
show
up
on
that
list.
If
not,
then
there
might
be
some
Ledger
permissioning
issues
you
might
have
forgotten
to
write
or
did
to
the
network,
for
instance.
So
that's
a
important
step
to
remember.
G
G
G
G
Should
show
up
here
any
second
okay
had
to
hit
refresh
that
time:
that's
cool!
Okay,
and
now
we
have
a
credit
available
for
that
table.
Tournament
table
tennis
tournament
when
inadvertently
made
a
tongue
twist
today,
okay,
so
we
are
now
ready
to
move
on
to
our
next
steps.
So
I'll
pass
it
back
to
Sharp
for
walking
us
through
those.
M
Great,
thank
you.
If
I
want
a
table
tennis
tournament
I
would
certainly
want
to
verifiable
credential
to
be
able
to
prove
it.
Okay.
Now
we
are
ready
to
actually
issue
a
credential
so
to
orient
ourselves
back
in
the
diagram
that
we're
building
up
now
that
we've
written
a
did
schema
and
credential
definition
to
The
Ledger
we've
done
everything
we
need
to
do
with
respect
to
the
Ledger.
Now
we
can
actually
issue
the
verified
credential
to
the
holder,
so
just
to
review
what
a
credential
definition
or
excuse
me,
a
verifiable
credential
is.
M
It
is
a
signed
statement
with
attributes
about
a
subject.
It
contains
metadata
about
the
credential
attributes
about
the
subject
and
proof
the
signature
from
the
issuer,
and
so
we
will
now
look
at
the
message
flow
that
occurs
between
the
issuer
and
the
holder
in
order
to
issue
a
credential,
a
quick
note
that
the
language
here
is
a
bit
awkward
and
not
how
people
would
naturally
talk
about
this
interaction,
but
this
is
the
language
used
in
the
messages
that
are
sent
back
and
forth.
So
we
were
wanting
to
show
the
the
developer
language
on
this
flow.
M
Like
Daniel
mentioned,
we
want
to
leave
the
the
guts
exposed
a
bit
to
demonstrate
what's
going
on,
so
this
interaction
can
be
initiated
by
either
the
holder
or
the
the
issuer.
If
the
holder
is
initiating,
they
can
propose
a
credential.
The
issuer
in
response
would
send
it
and
offer
credential
message
back.
Alternatively,
the
offer
credential
message
could
be
the
start
of
the
interaction
either
way.
M
G
G
So
usually
when
we
issue
a
credential
we've
kind
of,
especially
as
we
go
through
our
demonstration
today,
we've
we've
omitted
a
few
of
the
key
steps
in
the
issuance
of
a
credential
that
most
issuing
bodies
would
be
going
through
in
order
to
actually
validate
that.
The
the
information
that
they're
sticking
into
that
credential
is
authentic
and
real.
G
However,
it
is
also
valid
to
point
out
that
any
issuer
does
have
the
ability
to
issue
any
attribute.
So
it's
important
when
you
are
requesting
verification
from
from
your
your
approvers
in
your
ecosystem,
that
you
make
sure
that
you
are
validating
that
the
credential
was
issued
by
an
organization
that
you
trust
and
we
can
get
into
a
little
bit
more
detail
on
that.
As
we
start
talking
about
the
verification
steps.
G
Okay
cool,
so
we
have
all
the
necessary
pieces
in
order
to
start
issuing
credentials
from
Alice
to
Bob
we're
connected.
We've
got
that
schema
encrypta,
so
it's
just
a
matter
of
pushing
a
few
more
buttons
here
before
I.
Do
that?
Let's
do
a
quick
introduction
to
the
my
credentials
tab
in
Bob's
window
here.
So
this
is
the
the
receiving
end
of
the
credential
issuance
section
from
asked
Bob
so
Bob.
When
he
receives
that
credential,
you
should
see
that
it
shows
up
in
his
list
of
credentials
here.
G
We
also
have
a
credential
definition,
retrieval
mechanism
here
this
looks
similar
to
the
schema
cred
or
schema
retrieval
on
the
credential
relation
side.
This
enables
the
holder
to
send
a
credential
proposal
to
the
issuer
having
strictly
resolved
the
credential
definitions
is
not
necessarily
a
requirement.
What
it's
doing
is
just
getting
the
values
associated
with
a
credential
definition
into
the
wallet
into
a
place
where
the
toolbox,
UI
can
say
in
a
credentialed
proposal.
G
These
are
the
values
that
I
would
like
in
this
credential
and
have
it
be
from
this
credential
definition,
so
that
was
the
the
beginning
of
the
flow
where
the
holder
starts.
It
that
shower
went
through.
We
won't
be
demoing
that
today,
but
it
is
possible
for
the
holder
to
start
the
interaction
using
that
proposal.
G
G
G
In
this
optional
comment
on
the
issued
credential
message,
so
we
could
say:
Bob
state
of
hire
was
today
I'm
representing
this
value
as
a
string
value.
This
has
significance
when
it
when
it
comes
to
the
usage
of
predicate
proofs
and
I'll
talk
about
that
a
little
bit
more
and
why
this
format
for
the
string
actually
isn't
ideal
I'm
just
doing
it
so
I
can
easily
put
a
value
down
here
for
the
clearance
for
this
one
I
will
make
this
a
little
bit
more
prepared
for
doing
predicate
proofs.
G
So
this
one
will
say
that
clearance
level,
there's
say
four
different
levels
and
each
of
those
levels
are
represented
with
integer
values,
starting
from
zero.
Going
to
three.
So
we'll
say
that
Bob
has
a
clearance
level
of
one
which
means
he's,
got
basic
clearance,
One
Step
Up
from
no
clearance,
so
I'll
go
ahead
and
issue
that
credential
I.
Think
I'm
done.
Yeah
hit
confirm
we'll
see
a
value
pop
up
here
on
Alice
we'll
hit
the
refresh
button
on
Bob,
and
we
see
the
issued
credential
on
either
end
of
The
Exchange
here.
G
So
if
we
inspect
the
credential
value,
this
helps
us
see
a
little
bit
more
of
what
actually
took
place
between
Alice
and
Bob.
If
you'd
like
to
dig
a
little
bit
more
into
the
protocols
that
take
place
here,
we
see,
for
instance,
that
the
final
state
of
this
record
of
this
issued
credential
is
credential
act.
This
is
the
completing
state
for
this
credential
and
represents
that
we
received
acknowledgment
back
from
Bob
at
the
end
of
the
full
exchange
of
the
message
that
he
has
received
that
credential.
G
We
have
a
record
of
the
cred
deaf
ID
and
scheme
ID
that
was
used
to
issue
the
credential.
We
can
see
the
attributes
that
were
issued
and
we
can
also
dig
into
the
raw
developer
values
as
well.
Here,
for
instance,
you
can
see
like
the
credential
offer
message
that
was
sent
to
Bob
from
Alice,
which
includes
the
credential
preview,
which
is
where
the
attributes
are
actually
located.
G
We
also
see
an
additional
value
in
here
in
the
record,
which
is
interesting,
so
I'll
bring
it
up,
which
is
the
actual
raw
credential
value.
This
is
what
gets
stored
into
the
wallet
so
that
we
can
later
fulfill
presentation
requests
with
this
credential.
This
credential
storage
is
separate
from
the
record
that
represents
the
exchange
between
Alice
and
Bob.
Just
as
a
side
note,
so
the
The
Exchange
record
the
values
that
track
what
our
state
is
in
the
protocol
can
be
thrown
out
by
either
side
of
the
exchange.
G
G
All
right,
let's
see
I,
will
issue
one
more
credential
just
to
walk
through
this
process.
One
more
time
so
from
Alice
to
Bob.
I
will
now
again
select
Bob
as
the
connection
this
time.
Let's
go
with
a
table.
Tournament
table
tennis,
tournament
win
and
we'll
say
this
was
in
the
I.
Don't
even
know
what
division
represents
in
this
case,
so
I'll
just
come
up
with
something
we'll
say
it
was
a
division
within
a
company.
Let's
go
with
that.
G
G
M
Great,
thank
you
Danielle.
So
now
we
are
moving
on
to
verifying
a
credential,
so
whereas
the
issuer
had
to
decide
which
credentials
to
issue
to
whom
the
verifier
must
decide
who
and
what
to
trust
so
to
decide
this,
they
interact
with
the
holder.
They
read
from
The
Ledger.
They
perform
cryptographic
computations
to
verify
that
the
attributes
presented
were
issued
by
the
specific
issuer,
an
example
of
a
verifier
might
be
the
airport
or
the
bank,
or
a
store
anywhere
where
you
need
to
prove
information
about
yourself.
M
The
verifier
is
only
able
to
read
the
information
written
on
The
Ledger
by
the
issuer,
so
there's
that
indirect
interaction
that
provides
that
trust
for
the
sake
of
Simplicity
we're
having
Alice
play
the
role
of
both
the
issuer
and
the
verifier
in
this
demo,
roles
are
not
set
permanently
between
parties.
The
world
is
unique
to
the
interaction,
so
that
works
just
fine.
It's
also
entirely
possible
that
the
issuer
is
the
verifier
If,
an
employer
issues,
an
employee
credential.
M
So,
back
to
this
diagram
that
we've
seen
before
we're
now
moving
to
the
right
side
on
the
verification
side,
so
first
credential
must
be
created
and
then
the
verifier
reads:
the
did
schema
and
credential
definition
from
The
Ledger
and
verifies
the
attestations.
Now
we
have
built
this
diagram
to
completion.
M
So
here
again,
we
will
run
through
the
flow
of
messages
necessary
to
verify
a
credential
and
again
either
side
can
can
initiate
this.
This
interaction
with
a
proposed
credential
message
from
the
holder,
request,
presentation,
request
message
from
the
verifier
and
then
the
holder
can
choose
to
approve
that
request
and
send
a
presentation
in
response.
Then
the
verifier
will
verify
that
presentation
and
send
an
acknowledgment
and
then
the
holder
will
receive
that
and
then
both
sides
of
the
interaction
are
complete
and
before
I
turn
it
back
to
Daniel.
M
For
the
demo,
I
will
talk
about
the
different
types
of
presentations,
so
the
simplest
example
is
a
full
disclosure
presentation
in
which
all
attributes
are
revealed
from
one
verifiable
credential.
So
in
the
analog
world,
the
equivalent
is
where
you
take
out
your
passport
at
the
airport
to
get
through
security
you're,
showing
all
of
your
information
on
that
passport.
M
Another
example
in
the
analog
world,
when
I
got
a
library
card
after
moving
I
I
had
to
present
a
photo
ID
and
a
piece
of
mail
proving
my
address
and
revealed
all
of
those
attributes
so
moving
along
to
more
complex
types
of
presentations.
These
show
off
the
important
privacy
features
of
non-creds.
There
aren't
really
great
examples
of
these
in
the
analog
world
because
they
are
unique
to
this
digital
interaction,
so
selective
disclosure
is
when
only
certain
required
attributes
are
revealed
from
one
or
more
credentials.
M
So,
instead
of
revealing
the
entire
contents
of
a
credential,
you
reveal
only
a
subset
of
the
attributes.
A
predicate
proof
presentation
is
when
only
a
true
false
value
is
revealed.
A
common
example
is
age.
The
verifier
doesn't
need
to
know
your
date
of
birth,
which
is
a
very
important
identifying
piece
of
information.
If
all
they
need
to
know
is
if
you
are
younger
or
older
than
whatever
threshold,
they
need
to
make
a
decision
if
you
can
enter
the
venue
or
get
a
senior
discount
or
whatever
the
the
case
may
be.
G
Okay,
before
we
get
into
it,
I
acknowledge
that
we
are
actually
at
time
so
I
apologize.
We've
run
a
little
bit
behind
schedule
to
this
point.
If
you
have
to
drop
totally
understand,
we
will
stick
around
and
continue
to
finish
the
rest
of
the
presentation,
perhaps
a
little
bit
more
accelerated.
So
those
who
would
like
to
stick
around
can
do
so
with
a
little
bit
less
burden.
G
These
again
will
be
in
the
slides.
So
if
you've
got
a
drop
in,
you
don't
want
to
watch
the
video
later.
It
decides.
We'll
have
a
walkthrough
of
these
last
few
steps
as
well
so
I'll
proceed
here
slightly
quicker
than
I
have
previously
so
from
the
Allison.
We
click
on
the
verification
Tab
and
from
here
we
can
request
a
presentation
from
one
of
our
connections.
We
will
select
Bob.
K
B
G
G
So
we
can
ask
for
a
first
name
and
say
last
name
and
we
can
ask
for
data
fired
as
well,
so
we
can
apply
restrictions
to
these.
These
values
that
we
are
requesting
in
this
presentation
request.
These
enable
us
to
say
I
want
this
attribute
from
this
specific
individual
or
rather
from
the
specific
issuer
and
then
be
able
to
cryptographically
and
require
that
as
part
of
the
verification
process.
G
So
this
is
the
scenario
in
which
we
actually
need
to
determine
who
we
trust,
so
the
ice
cream
truck
that
I
frequent
down
the
street
might
have
given
me
a
rewards
card
that
has
my
name
on
it,
but
as
an
organization
where
I'm
likely
to
trust
the
verification
processes
that
the
ice
cream
truck
went
through
in
order
to
issue
that
credential
to
me.
So
we
want
to
make
sure
that
we
are
using
issuers
trusted
issues
that
are
are
appropriate
for
our
use
case
for
our
governance
framework
and
so
on.
G
So
for
this
one
I'm
going
to
require
that
it
came
from
the
table,
tennis
tournament
credential
and
from
this
one
from
the
employment
same
with
this
one
same
with
that
one
and
hit
confirm
okay,
and
we
saw
that
it
went
from
unverified
to
verified,
as
The
Exchange
took
place
between
Alice
and
Bob.
In
the
background
here,
you
can
again
examine
these
values
in
more
detail
at
the
revealed
attributes
are
presented
to
the
controller
and
to
the
toolbox.
G
In
this
case
it
is
using
these
revealed
values
that
we
would
then
take
our
next
step
in
our
business
logic.
Operation.
Whatever
is
going
on
purely
because
the
value
is
verified
does
not
necessarily
mean
that
we're
ready
to
act
on
it.
We
might
want
to
make
sure
that
in
in
our
business
logic,
that
the
division
was
one
of
us
at
or
something
like
that.
G
So
this
isn't
necessarily
the
end.
There's
there's
more
to
do
after
that
value
has
been
passed
out
up
to
your
controller
in
order
to
trigger
the
next
step
in
some
exchange.
I
will
now
do
a
quick
predicate
proof
just
to
demonstrate
that
real
fast-
and
this
will
be
say,
Bob-
is
attempting
to
access
a
building
on
his
employer's
campus.
G
So
we'll
ask
for
a
proof
of
clearance
and
Bill
requested
predicate
on
clearance,
and
we
say
that
it
must
be
at
least
a
basic
clearance
level,
so
we'll
put
in
the
value
that
represents
the
base
clearance
level,
specify
the
Restriction
hit
confirm,
and
we
see
that
that
presentation
has
verified
successfully.
We
can
view
these
presentations
on
Bob's
side
as
well.
I
won't
get
into
the
details
on
that.
This
verify
true
statement
that
the
predicate
proof
was
met
in
that
representation
of
that
predicate
can
be
seen
there.
G
M
Great
thank
you
Danielle.
So
to
look
briefly
back
at
what
we've
covered:
we've
discussed
agents,
Aries
collection,
Python
and
the
Aries
toolbox
did
com
messaging.
We've
demonstrated
how
to
connect
agents
and
issue
and
verify
credentials
between
them.
We
also
way
back
covered
an
intro
to
decentralized
Identity
and
the
hyperledger
indie
project.
This
is
the
end
of
the
Aries
section.
Thank
you
all
for
listening
and
engaging
for
following
along
and
asking
questions.
I
will
now
pass
it
over
to
Sam
for
a
final
word
on
getting
involved.
E
Thanks
Char
I
just
want
to
encourage
everyone,
you're
hearing
from
me
again
about
Community
involvement,
but
we'd
love
to
love
you
to
be
involved
if
you're
interested
come
and
learn.
If
you're
able
to
contribute.
That's
wonderful,
ask
questions
reach
out
if
we
to
any
of
us,
if
we
can
help
and
we'd
be
happy
to
do
so,
you've
got
some.