►
From YouTube: DIDComm and the Self-Sovereign Internet - Phillip J. Windley, Ph.D., Brigham Young University
Description
DIDComm and the Self-Sovereign Internet - Phillip J. Windley, Ph.D., Brigham Young University
DIDComm is the messaging protocol implemented in Hyperledger Aries that provides utility for DID-based relationships. Many may think DIDComm is just a way to exchange credentials, but it's more than that. DIDComm is a protocol layer capable of supporting specialized application protocols for specific workflows. Because of its general nature and inherent support for self-sovereign relationships, DIDComm provides a basis for a self-sovereign internet much more private, enabling, and flexible than the one we've built using Web 2.0 technologies. This talk introduces DIDComm, discusses its protocological nature, and presents use cases in the Internet of Things. Demonstrations of DIDComm protocol interactions will be shown on the Pico platform, which implements the Aries Cloud Agent (ACA) specification.
Sessions Details & Slides (if available)- https://sched.co/j3bd
Access All Sessions: https://events.linuxfoundation.org/hyperledger-global-forum/program/schedule/
----
Hyperledger – Open Source Blockchain Technologies
Hyperledger is an open source community focused on developing a suite of stable frameworks, tools and libraries for enterprise-grade blockchain deployments.
It serves as a neutral home for various distributed ledger frameworks including Hyperledger Besu, Fabric, Sawtooth, Indy, as well as tools like Hyperledger Avalon, Cactus and libraries like Hyperledger Aries, Ursa. Learn more about Hyperledger projects: https://www.hyperledger.org/use
Case Studies: https://www.hyperledger.org/learn/case-studies
Training & Certification: https://www.hyperledger.org/learn/training
Tutorials: https://www.hyperledger.org/use/tutorials
Webinars: https://www.hyperledger.org/learn/webinars
Events: https://www.hyperledger.org/events
Vendor Directory: https://www.hyperledger.org/use/vendor-directory
Subscribe to the Hyperledger Newsletter: https://www.hyperledger.org/newsletter
Follow-us on Twitter @Hyperledger
Learn about Hyperledger Membership: https://www.hyperledger.org/about/join
#Hyperledger #HyperledgerGlobalForum2021 #Blockchain
A
Well,
thanks
for
coming
everyone,
I'm
going
to
get
started
because
half
an
hour
is
not
very
much
time
today,
I'm
going
to
talk
about
something
called
did
com
and
the
self-sovereign
internet
to
get
started.
I
just
want
to
make
the
point
that
when
I
talk
about
this,
I'm
not
I
don't
want
to
debate
the
relative
merits
of
different
autonomic
identifiers
like
pure
dids
and
kerry
and
adi.
I
think
all
of
them
can
apply
to
what
I'm
going
to
say
and
if
you
don't
know
what
an
autonomic
identifier
is.
A
A
So
when
this
card
is
didn't,
say,
I
have
a
birth
certificate.
Therefore
I
am
we
don't
spring
into
existence,
because
some
administrative
system
provisions
an
identifier
for
us
and
no
single
administrative
regime,
be
it
a
birth
certificate
or
a
driver's
license
or
whatever
or
even
a
collection
of
them,
really
defines
us.
And
so,
when
I
talk
about
self-sovereign
internet,
what
I
mean
by
that
is
that
sovereignty
is
the
source
of
our
authority.
To
act
represents
a
a
root
of
trust.
A
A
The
controller
could
be
a
person,
an
organization,
a
software
system
of
some
kind,
and
it
might
be
the
subject
that
the
identifier
refers
to,
but
that
doesn't
have
to
be
the
case.
Okay,
authentication
factors
can
be
things
like
passwords
or
key
fobs
or
cryptographic
keys,
or
almost
anything
else.
But
really
one
of
the
things
we
care
most
about
is
the
strength
of
the
bindings
between
these
three
things
and
the
architecture
of
the
identity
system
has
a
great
deal
to
do
with
the
strength
of
those
bindings.
A
So
in
an
administrative
identity
system
like
the
ones
that
we
use
for
almost
everything,
some
administrator
is
asserting
the
binding
between
an
identifier
and
the
password
and
the
administrator
owns
or
verifies
the
identifier.
Even
if
it's
your
email
they're
still
when
it's
used
as
an
identifier
in
their
system,
they
are
essentially
asserting
the
binding
between
that
and
and
they're
assigning
it
to
a
particular
controller.
A
Now
in
a
ledger
based
system,
which
I
think
of
as
algorithmic,
we
have
a
ledger
which
is
essentially
registering
the
bindings
between
the
identifier
and
the
public
key,
and
usually
the
identifier
is
derived
from
the
public
key
in
some
way.
So
we
get
strong
bindings
between
all
of
these,
the
binding
between
the
controller
and
the
identifier
is
strong,
because
the
the
identifier
is
derived
from
public
keys
that
the
controller
has
generated,
and
then
finally,
the
primary
thing
we
want
to
talk
about
today
is
this
idea
of
autonomic
identifiers.
A
So
in
this
case
the
the
identifier
is
and
the
keys
are
self-certifying
and
the
person
is
their
own
root
of
trust,
and
I
don't
have
time
today
to
go
into
the
details
of
why
that
works
and
why
it's
so
we'll
talk
a
little
bit
about
it.
But
nevertheless
the
idea
here
is
that
the
identifier
is
derived
from
the
key,
but
the
source
of
truth
about
what
that
identifier
means
is
held
in
some
cryptographic
structure,
which
I've
labeled
here
as
a
key
event
log.
A
A
These
agents
are
speaking,
a
protocol
called
did
com,
and
that
is
really
the
basis
of
what
we're
going
to
talk
about
today.
Is
this
idea
of
a
protocol.
A
messaging
protocol
called
didcom
that
a
series
of
interoperable
agents,
whether
they
be
edge,
agents
or
cloud
agents,
can
use
to
communicate
with
each
other.
A
A
This
whole
idea
of
how
this
works,
the
indirection
of
the
did,
was
brought
home.
The
importance
of
the
indirection
was
brought
home
to
me
this
past
week,
when
someone
sent
me
an
email
and
it
happened
to
be
encrypted,
and
I
sent
him
back
a
note,
and
I
said
sorry,
I
can't
read
this
and
he
says:
oh,
don't
you
use
this
key
anymore
turns
out.
It
was
a
key
that
I
had
exchanged
with
him
in
2011..
A
Of
course,
I
had
no
idea
what
it
was
didn't,
remember
anything
about
it.
Nevertheless,
he
still
had
it
in
his
in
his
system
and
so
a
better
distributed.
Key
management
system
is
clearly
going
to
benefit
a
lot
of
people
and
and
that's
really
the
basis
of
did
com
did.
Com
is
a
messaging
system
based
on
these
dead
relationships.
A
Alice
can
have
as
many
did
relationships
as
you
want.
Bob
can
have
as
many
as
he
wants,
because
they're
based
on
deads
and
those
dids
are
linked
to
public
keys.
They
can
sign
messages
to
each
other,
they
can
encrypt
messages
to
each
other
and
even
if
they
rotate
the
keys,
because
they've
been
lost
or
or
whatever
the
dead
relationship
can
remain,
and
the
key
event
logs
will
sync
up
the
keys
between
alice
and
bob
so
that
they
can
maintain
their
relationship.
A
A
It's
important
to
note
that
alice
in
this
diagram
has
five
different
peer
dead
relationships.
She
has
created
a
different
peer
did
for
each
one
of
those
relationships:
she's,
not
reusing.
The
same
peer
did
in
each
relationship
she's
using
a
new
one.
Now
because
of
the
secure
and
interoperable
nature
of
this
did.
Com
represents
a
secure
network
overlay,
very
different
than
say
tls,
which
is
another
example
of
a
secure
network
overlay.
But
tls
is
very
specific
to
a
spec
to
a
certain
application,
namely
https.
A
A
A
So
in
my
lab
at
byu,
bruce
conrad,
who
works
with
me,
put
together
a
version
of
this
inside
our
pico
system,
which
is
a
system
that
speaks
agents,
and
so
I
have
here
a
agent
for
alice,
and
I
have
an
agent
for
bob
and
you
can
see
that
bob
doesn't
have
any
connections.
Alice
has
a
connection
to
agent
book
for
historical
purposes
and
we're
going
to
create
a
a
connection
between
them.
So
this
is
an
invitation.
A
A
A
It
turns
out
that
if
I
were
to
go
into
this,
if
we
were
going
to
bob
you
would
see
this
is
a
system
of
called
picos
krl,
not
nearly
enough
time
to
go
into
it,
but
you
can
see
that
he
has
rule
sets
for
a
sovereign
agent
and
for
the
did
comp
plug-in
and
one
for
tic-tac-toe,
and
all
of
these
are
what's
allowing
this
game
to
go
forward.
But
it's
all
happening
over.
Did
com
using
a
protocol,
that's
been
defined
by
bob.
A
A
This
is
our
the
diagram
I
showed
you
earlier,
but
now
alice
has
this
coffee
grinder
out
to
the
right,
and
if
we
ignore
everything
else,
we
just
see
this
so
instead
of
baratza
intermediating
alice's
relationship
with
her
coffee
grinder,
she
instead
has
a
pure
dis
relationship
with
her
coffee
grinder
and
she
has
one
with
baratza
and,
interestingly
enough,
the
coffee
grinder
itself
has
a
pure
dead
relationship
with
baratza.
So
what
might
we
do
with
that?
So
one
of
the
most
obvious
things
that
you
might
do
with
that
is
bharatsin
might
issue
firmware
updates.
A
So,
since
the
coffee
grinder
has
a
period
relationship
with
baratza,
they
can
offer
a
firmware
update
over
the
did
com
messaging
system
that
the
peer
did
relationship
gives
them
and
baratza.
I'm
sorry,
the
coffee
grinder
can
use
virat
says
public
did
to
to
look
up
the
current
key.
That
bharata
is
using
to
sign
things
and
validate
the
signature
of
the
firmware
update
all
by
itself,
and
alice
can
now
be
confident
that
she
can
tell
her
coffee
grinder.
Yes,
as
long
as
you
can
validate
the
firmware
comes
from
baratza.
A
Please
go
ahead
and
update
your
firmware
whenever
it
comes
along.
So
that's
kind
of
the
obvious
kind
of
thing
you
might
imagine
that
alice
needs
to
prove
ownership,
maybe
not
of
a
coffee
grinder,
but
of
something
right.
I
just
made
a
customer
service
request.
Yesterday
I
had
to
prove
that
I
had
bought
something.
So
we
could
imagine
the
coffee
grinder
issuing
an
ownership
credential
to
alice
and
alice,
using
that
to
prove
to
bharat
so
that
she
actually
owns
the
coffee
grinder.
A
Of
course,
she
could
use
it
to
prove
to
anyone
that
she
owns
the
coffee
grinder.
If
that
were
important
and
there's
all
kinds
of
interesting
sub
scenarios
here
about
what
happens,
if
phallus
you
know,
sells
the
coffee
grinder
lots
of
interesting
scenarios
in
this
one,
one
of
the
most
interesting
to
me
is
the
idea
that
the
coffee
grinder
itself
could
be
at
the
intermediary
in
a
customer
support
relationship
so
alice.
A
If
the
coffee
grinder
has
some
kind
of
problem,
alice
would
tell
it
to
initiate
a
customer
support
contact
and
it
would
connect
with
baratza
and
of
course
it
knows
a
lot
more
about
itself
and
the
problems
it's
having
than
alice
does,
and
so
it
could
just
communicate
with
baratza.
Bharata
knows
that
it
is
one
of
their
products
because
of
the
you
know
the
the
credentials
that
the
coffee
grinder
might
be
able
to
prove
to
baratza.
A
So
lots
of
interesting
scenarios
with
that
there's
a
company
called
hero,
h-e-a-r-o
that
is
pursuing
this.
Actually,
with
did
com
and
verifiable
credentials,
one
of
the
most
interesting
ecosystems
is
vehicles.
I
had
a
company
several
years
ago
that
did
that
used
this
exact
model,
not
not
with
did
com
because
it
didn't
exist
yet,
but
but
you
know,
modulo,
the
actual.
Did
com
used
this
exact
self-sovereign
model
in
vehicle
connections.
You
know
vehicles
have
lots
of
relationships,
owners,
manufacturers,
financers,
manufacturing
dealers,
insurance
companies,
other
vehicles,
traffic,
signals
lots
of
interesting
things.
A
They
could
have
one
to
the
dmv
to
insurance
companies,
and
you
know,
then
there
would
be
a
protocol
for
actually
transferring
ownership
of
the
truck
from
alice
to
doug.
One
of
the
interesting
things
about
that,
at
least
from
a
pico
standpoint.
Is
that
alice
when
she
transfers
the
truck
the
truck's
going
to
know
a
lot
of
things
about
alice
so
from
an
information
hiding
perspective,
she
may
wish
to
transfer
the
maintenance
records.
A
In
fact,
doug
may
insist
on
that,
but
but
not
the
trips
that
she's
taken,
but
she
could
keep
all
of
those
in
a
shadow
truck
kind
of
a
device
shadow
that
would
that
would
keep
all
of
the
things
that
alice
knew
about.
Her
truck
can
be
fully
functional,
at
least
from
a
data
standpoint
as
alice
completes,
this
transaction.
A
So
picos
we're
experimenting
with
the
self-sovereign
internet
of
things.
As
we've
seen,
picos
can
be
agents,
we
recently
updated
the
engine
and
you
know
aries
has
gone
through
a
lot
of
transitions,
so
the
demo
I
showed
you
is
actually
based
on
the
the
old
aries
profile,
not
the
new
one,
so
we're
working
on
incorporating
that
making
didcom
the
primary
messaging
method
as
opposed
to
http,
which
you
know
pico's
have
been
around
since
2008,
so
some
transitions
there
and
exploring
the
use
of
did
com
protocols
between
picos
for
various
things.
A
So,
if
you're
interested
in
any
of
that,
you
can
go
to
picolabs.io
there's
code
and
quickstarts
and
lessons
it's
all
open
source
and
we
have
some
interesting
projects
that
we
would
welcome.
People
helping
us
with
so
I've
uploaded
these
slides
to
hyperledger.
So
you
can
get
them
follow
through
all
of
these
links.
A
A
A
We
call
ours
akapiko,
naturally,
because
you
know
who
wouldn't
want
to
go
to
acapeco,
and
there
are.
There
are
other
implementations
of
that.
But
yeah
yeah
occupy
is
not
just
did
com,
it
is,
but
it
is,
did
come
in
the
sense
that
what
it's
doing
is
it's
implementing.
Did.
Com
based
protocols,
so,
like
I
said,
credential
issuance,
is
a
protocol
on
top
of
did
com.
So
so
the
whole
aries
system
is
did
com
based.
A
Yeah
and
I've
uploaded
the
slides
to
hyperledger,
so
so
that
should
be
available
on
the
hyperledger
system.
If
not
send
me
a
note,
and
I
can
drop
you
something
yeah.
So
how
can
we
use
self-sovereign
identity
on
resource
constrained
device?
That's
a
really
interesting
question
and
that's
why
picos
exists
right,
so
the
coffee
grinder
may
not
have
all
of
the
resources.
It
needs
to
be
a
fully
functioning
system.
A
A
A
There
are
aries
code
that
implements
all
of
this,
but,
for
example,
the
pico
stuff
is
not
part
of
the
aries
project.
It
just
uses
the
aries
specifications
to
be
interoperable
and
yes,
picos
are
all
open
source.
So
we
are
at
time.
I
probably
ought
to
end
so
that
you
can
get
to
the
next
session,
but
I
appreciate
your
time
today,
please
feel
free
to
ask
additional
questions
by
sending
me
an
email
or
on
twitter
or
whatever.
So
thanks
a
lot
guys.