►
Description
Standards and Interoperability for Identity - Nathan George, Sovrin Foundation
Identity platforms have made significant advances leveraging blockchain technology and standards developed at Hyperledger.Come learn about the latest advances in trusted information flows and the standards being incubated to promote interoperability and create network effects across multiple blockchains and identity platforms.
This presentation will cover the advancements incubated in Hyperledger Indy, Hyperledger Aries, the W3C Credentials Community Group and at the Decentralized Identity Foundation for Verifiable Credentials, Decentralized Identifiers (DIDs), DID Communications, Identity Hubs, Authentication, and the data models that power them.
----
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 #HyperledgerGlobalForum2020 #Blockchain
A
Welcome
everybody:
we
are
a
little
after
two
o'clock,
so
we'll
go
ahead
and
get
started
and
let
anyone
who's
straggles
in
come
in
a
little
bit
later.
My
name
is
nathan,
george,
I'm
the
CTO
for
the
sovereign
foundation.
I
work
for
a
nonprofit
that
is
building
a
public
network
to
do
identity,
our
tagline
or
the
sovereign
foundation
is
identity
for
all,
so
we're
very
serious
about
making
identity
work
network
that
works
for
everyone
all
over
the
world.
For
anything
that
you
want
to
use
it,
for
we
are
not
a
for-profit
organization.
A
We
are
run
by
volunteers,
so
I
will
give
my
PBS
style
pitch.
That
I
am
here
because
folks
have
been
generous
to
donate
money
to
the
sovereign
foundation.
That's
why
I'm
able
to
do
what
I
do
and
that's
why
I'm
able
to
work
on
this
open
source
code
and
help
a
lot
of
you
who
are
in
the
audience,
coordinate
on
the
things
that
need
to
happen
next.
A
So
thank
you
to
those
organizations
that
are
helping
to
support
us
and
making
this
stuff
happen
a
little
bit
of
perspective
about
how
I'm
approaching
this
idea
of
standards
and
interoperability
is
probably
in
order,
the
sovereign
foundation.
It
runs
a
public
network
that
spans
the
globe.
We
have
82
stores,
which
are
couple
mostly
companies
that
you
will
have
heard
about,
especially
if
you've
been
participating
here
at
hyper
laser.
Some
of
them
are
companies
that
you
may
not
have
heard
about
because
there
are
smaller
organizations.
A
The
idea
here
is
that
there's
a
lot
of
diversity
in
the
network.
We
want
public
companies,
private
companies,
large
companies,
small
companies,
companies
from
all
around
the
globe,
doing
all
sorts
of
different
things
running
nodes,
so
the
network
stays
fair
stays
safe
and
continues
to
do
what
you
expect
it
to
do.
There's
about
270,
well,
I
think
we're
up
to
about
280
to
code
developers
in
github
now
across
all
the
repositories
that
go
into
building
the
sovereign
network.
Primarily
our
code
is
hosted
in
hyper,
ledger,
Ares,
hyper,
ledger,
indie
and
hyper
ledger.
Ursa.
A
Those
code
bases
are
the
edge
peer-to-peer
protocol
with
Ares.
That
does
wallet
and
signing
transaction
type
things
with
Ursa.
It's
a
shared
cryptography
library
that
it
can
be
used
by
any
of
your
blockchain
solutions
and
then
obviously
India's
the
core
of
blockchain
that
we,
both
stewards,
are
running
to
to
build
those
nodes
to
have
a
public
instance
of
an
identity
ledger
there's
in
addition
to
that,
a
whole
lot
of
volunteers
working
on
what
we
call
the
governance
framework,
which
are
the
business
and
the
legal
rules
that
make
all
that
stuff
work.
A
I
see
some
really
good
contributors
to
that
group
here
in
the
audience.
So
later,
I'll
probably
ask
any
of
you
who
are
code,
contributor
or
governments
framework
participants
to
raise
your
hands
that
way,
people
can
pick
on
you
after
my
presentation
is
done.
You
can
tell
them
why
I'm
wrong
and
then,
of
course,
we
have
a
small
staff
at
the
sovereign
foundation
and
a
large
job
is
to
help
facilitate
companies
working
together.
A
I
think
there's
last
count
I
think
there's
12
companies
that
have
commercial
solutions
that
you
can
just
go
by
on
top
of
the
sovereign
ecosystem
and
there's
a
whole
bunch
of
others
to
draw
for
consulting
services
and
other
things
that
you
can
do
to
make
this
identity
platform
stuff
work
for
you
and
I
see
a
lot
of
those
guys
in
the
audience
as
well.
So
the
staff
helps
facilitate
that
and
make
it.
A
So
the
companies
with
different
goals
can
continue
to
work
together
and
do
the
things
that
you
need
to
do
to
get
what
they
want.
There's
a
map
of
where
the
nodes
are
from
sovereign
Network
they're
everywhere.
We
have
at
least
two
contributors
from
every
continent,
except
for
Antarctica,
where
the
two
contributors
are
not
from
the
same
company.
I
really
really
proud.
When
we
were
able
to
pass
that
mark
I
thought
that
was
really
important
and
everyone
has
different
interests
in
the
network.
A
We
usually
put
this
picture
up
and
we'd
spend
a
lot
of
time
talking
about
what,
but
we
don't
spend
as
much
time
talking
about
why
from
a
technical
standpoint
as
Scott
knows,
we
talk
a
lot
about
why
from
a
philosophical
standpoint,
but
why,
from
a
technical
standpoint,
is
also
important
and
I
think
it
will
help.
You
understand
why
we
approach
the
problem,
the
way
they
did
and
maybe
hope.
Hopefully
it
will
help.
A
You
understand
why
identity
as
hard
in
most
blockchains
and
why
you
have
to
back
off
and
approach
the
problem
differently
if
you're
gonna
succeed.
So
when
we
talk
about
this
stack,
we
talk
about
a
blockchain
layer
where
we
decentralized
identifiers.
As
we
talk
about
peer
connections
and
scripted
messages,
we
talk
about
verifiable
credentials
and
we
talk
about
all
the
rules.
A
Identity
means
a
lot
of
different
things
to
a
lot
of
different
people.
In
fact,
that
is
in
part,
the
definition
of
identity.
What
context
you're
operating
in
defines
how
you're
going
to
operate.
In
that
context,
it
defines
how
that
relationships
going
to
go
what
data
you're
going
to
share
what
data
you're
not
going
to
share
what
transactions
you're
going
to
engage
in
and
how
right,
but
we're
interested
in
a
more
important
question
of
what
is
decentralized
identity.
A
We
talk
a
lot
about
decentralized
systems
in
the
blockchain
world,
but
what
we
mean
when
we
mean
decentralized
identity
is
fundamentally
different
than
what
we
mean
when
we
talk
about
a
smart
contract
based
system.
A
smart
contract
based
system
is
built
to
be
the
system
of
record
the
only
source
of
truth
that
everyone
must
collaborate
on
in
order
to
affect
change
of
state
right.
A
You
define
everything
that
needs
to
happen,
and
when
you
submit
a
transaction
you're
saying
is
this
one
of
the
state
chains
we
will
allow
if
it
is
goes
through,
if
it
won't,
you
may
not
do
that
right.
Then
we
say:
we've
made
a
decentralized
system
because
we
break
all
the
capabilities
down
into
cryptographic
keys.
We
know
only
the
person
who
possesses
the
cryptographic
key
is
able
to
affect
State
in
the
way
that
we've
defined
right.
Hurrah,
we're
decentralized.
Anyone
can
affect
the
state
that
they
have
rights
to
and
nothing
else.
A
Unfortunately,
this
means
that
all
the
information
has
to
be
on
blotching
at
any
state
that
you
want
to
change
has
to
be
enforced
by
your
smart
contracts.
Does
that
mean
you
can
believe
something
different?
Does
that
mean
you
can
say
something
different
than
what
he
says?
That
means
that
you
can
enforce
something
differently
than
someone
else
enforces
it
well
sort
of,
because
you
can
have
your
own
namespace
and
you
can
do
your
own
smart
contracts,
but
then
you've,
essentially
forked
the
semantics
to
the
system,
while
still
having
to
pile
everything
into
the
blockchain
right.
A
So
when
we're
talking
about
decentralizing
identity,
what
we're
saying
is
you
need
to
have
your
own
context?
It
needs
to
be
uniquely
yours
and
no
one
else
can
know
about
it,
because
if
you
tell
them
about
the
context
that
exists,
you've
disclosed
that
identity
right
I
want
to
have
as
many
different
contextual
identities
as
I
need
to
operate
and
I
don't
want
everyone
else
to
know
about
all
of
them.
I
want
to
be
able
to
maintain
the
information
sharing
within
the
relationship
that
I'm
trying
to
engage
in
and
when
I
want
to
share
that
information.
A
I
want
to
use
the
way
we
sign
data
in
that
relationship
to
prove
something
to
someone
else
right.
We
want
to
maintain
the
decentralization
of
those
identity
contexts.
We
want
to
be
able
to
say
what
we
need
to
say
in
a
relationship
without
having
chase
us
through
the
rest
of
the
system
and
causing
correlation
that
we
don't
intend
all
right.
So
here
we
have
Alice
Alice
wants
to
sign
stuff.
A
Anyone
have
a
pencil
and
paper.
Can
you
give
me
an
Aes
signature
for
something
all
right?
How
do
we
sign
things?
How
do
we
do
cryptography
I
haven't
I've
yet
to
meet
somebody
who's,
just
done
it
in
their
head.
If
you
want
to
work
on
that
on
pencil
and
paper
and
then
show
it
to
me
afterwards,
I
will
be
very
impressed,
but
we
use
devices
to
represent
us.
A
Here's
where
we
get
to
our
first
set
of
standards
that
we
need
to
talk
about.
How
do
we
generate
cryptographic
keys?
How
do
we
know
they
were
generated
properly?
How
do
we
know
that
they're
still
secure?
How
do
we
manage
them?
Staying
secure
over
time
right,
there's
a
whole
series
of
cryptographic,
standards
that
have
been
in
development
for
quite
some
time
and
we
actually
have
a
pretty
good
idea
of
the
shape
of
them.
We
know
that
cryptography
doesn't
last
forever.
A
This
is
one
of
the
reasons
why
identity
is
different
from
a
decentralization
standpoint
than
most
block
chains
that
are
doing
smart
contracts
because
you're
not
trying
to
be
the
system
of
record.
You
don't
want
everything
published
on
the
blockchain,
because
you
know-
and
you
expect
it
won't
last
forever
right,
disclosing
the
data
that
you
processed
in
public
is
different
than
disclosing
the
context
that
you
want
to
stay
private
all
right.
A
The
consequences
of
that
are
different,
so
it's
important,
you
think
about
the
decentralization
problem
a
little
bit
differently,
but
we
need
to
build
on
good
cryptographic
standards
and
that's
part
of
why
the
identity
community
is
really
strongly
behind
hyper
ledger
ursa,
because
if
we
have
a
shared
cryptography
library,
that's
being
used
by
a
lot
of
different
people
for
a
lot
of
different
reasons,
it
crosses
more
than
one
context.
Then
it's
more
likely
the
bugs
will
get
fixed.
A
It's
more
likely
that
people
will
notice
the
problems,
and
hopefully
the
people
who
are
using
ursa
for
different
reasons.
Then
the
identity
community's
using
her
so
we'll
find
those
problems
before
we
do
now.
Maybe
it
would
means
that
we'll
find
some
of
the
problems
before
they
do.
Oh
and
hopefully
we
can
fix
them
when
that
happens,
but
now
that
we've
said
that
we've
got
cryptographic,
keys,
right,
I'm
going
to
use
cryptographic
key
from
identity.
This
is
where
most
people
think
Oh
block.
A
Channa
did
a
great
will
substitute,
usernames
and
passwords,
and
now
will
use
the
devices
will
just
do
cryptographic
keys,
like
Bitcoin
I,
don't
have
to
login
anymore.
This
is
this
is
feeling
pretty
good
right
and
then
someone
takes
in
destroys
your
phone.
One
of
the
big
takeaways
I
hope
you
get
today.
Is
that
if
you
don't
do
key
management
right,
blockchain
doesn't
matter.
A
Ultimately,
if
you
can't
get
your
keys
to
the
edge
to
where
the
clients
that
want
to
submit
transactions,
what
you're
doing
doesn't
matter,
because
you
can't
trust
whether
it
means
what
you
think
it
means.
So
we
need
standards
to
help.
You
recover
your
identity
when
that
phones
destroyed
and
you
get
a
new
phone.
How
do
you
reclaim
that
identity?
How
do
you
know
that
that
device
works
for
you
and
only
you
and
fundamentally
the
way?
A
One
of
the
ways
you
decide
that
is:
can
you
fire
it
all
right
if
it
gets
destroyed,
can
you
still
reclaim
your
identity
and
continue
to
be
you,
and
even
if
the
software
is
malicious,
can
you
take
away
its
right
to
operate
on
your
behalf,
and
can
you
give
that
right
to
a
different
device
from
a
standardization
standpoint?
We
call
this
decentralized
key
management
systems.
Key
management
specs
have
been
around
for
quite
some
time.
We
actually
have
really
good
enterprise.
A
Key
management,
specifications
and
they're
pretty
well
developed
businesses
have
an
idea
on
how
to
do
this.
They
put
business
processes
in
place.
They
do
an
excellent
job
of
auditing
for
it.
Well,
in
some
cases
at
least
those
that
hire
good
auditors,
but
we
need
this
to
where
it
works
at
a
personal
level
and
at
the
edge
right.
This
is
something
that
not
just
enterprise
block
chains.
A
Deal
with
this
is
something
that
all
block
chain
solutions
deal
with,
and
wallets
and
key
management
systems
are
getting
better
and
that's
one
of
the
things
that
we
try
to
address
in
the
hyper
ledger:
Arius
communities.
We
try
to
package
together
all
the
things
that
are
being
built
in
ursa,
to
be
able
to
do
decentralized.
Keyman
I've
been
in
a
way
that
you
can
cobble
together
to
make
your
systems
work
right.
Ares
doesn't
provide
the
ux
to
do
decentralized,
key
management,
but
hopefully
we
provide
the
infrastructure
for
you
to
do
that.
A
But
key
management
is
it's
not
something
you
do
alone.
The
whole
reason
you
have
a
cryptographic
key
is
so
that
you
can
do
something
or
enter
act
with
someone
else
right.
In
some
cases
you
have
that
cryptographic
key
to
make
it
so
they
can't
see
your
data
all
right,
I'm,
going
to
encrypt
this
data.
To
put
it
rest,
so
that
no
one
else
can
see
it.
No
one
else
can
crack
it
open
or
I'm
trying
to
hide
the
data
from
observers.
A
I,
don't
want
them
to
be
able
to
see
and
understand
the
data
right
or
I'm,
trying
to
sign
data
and
encrypt
data,
so
only
the
partnering
partner
or
the
party
that
I'm
communicating
with
can
see
and
understand
the
data,
but
to
make
those
types
of
systems
work,
you
have
to
do
key
infrastructure.
You
have
to
do
something
to
communicate,
which
keys
are
we
gonna
use
and
for
what
right
remember
we
started
talking
about
decentralized
identity.
You
have
different
identity
context.
A
You
aren't
one
thing
to
everyone
right
when
you're
operating
with
your
employer,
that's
one
context
when
you're
do
acting
as
the
volunteer
soccer
coach
back
home,
yes,
a
different
context,
and
you
don't
necessarily
want
all
of
those
things
to
be
correlated
together
right.
How
you
vote?
Isn't
your
employer's
business,
at
least
in
the
US?
We
typically
think
that,
but
there's
a
problem
if
I
just
send
you
my
key
and
you
send
me
your
key.
How
do
I
know
that
I
actually
got
your
key
all
right
classically?
We
call
this
the
introduction
problem
problems.
A
A
In
PGP,
we
tried
to
solve
this
problem
with
key
servers
right
as
long
as
I
can
figure
out
something
about
the
person
I'm
trying
to
talk
to
from
some
public
Oracle
I
can
have
some
idea,
whether
there's
a
man
in
the
middle
or
not
right.
The
trouble
is
key.
Management
in
a
decentralized
system
is
nobody's
business,
but
yours,
which
means
it's
all
your
problem
and
you
have
to
solve.
A
It
turns
out
solving
that
problem
is
messy
right
and
when
you
change
your
key,
you
end
up
building
this
digital
wake
of
all
these
kind
of
keys
that
you've
you've
shed
off
over
time,
and
when
someone
looks
to
find
which
key
is
the
real
you
they're,
not
sure
which
one
they
should
use.
They
don't
necessarily
have
a
system
of
record
that
tells
them
which
one's
the
most
up-to-date,
which
one
works,
the
best
a
certificate
authority
style
system.
A
What
we
did
is
we
said
well,
let's
just
say
that
that
guy's
the
one
to
ask-
and
if
you
ask
him
he'll,
tell
you
which
one's
the
right
one
and
don't
believe
anything
else
so
than
what
he
says.
Right,
I
see
everyone
going.
Oh
I
see
the
blockchain
already
right,
because
I
can,
instead
of
using
a
certificate
system,
I
can
use
a
blockchain
for
that
right.
I
can
decide
which
key
is
the
most
authoritative
key,
but
that
introduces
an
interesting
new
problem.
So
let's
say
we
have
this
system.
A
That's
going
to
authenticate
my
connection
right,
so
this
shadow
system
is
gonna.
Do
something
to
let
me
know
whether
I'm
talking
to
the
real
corn
right
I
would
like
some
sort
of
credential
some
signed
piece
of
data
from
the
authority
that
I
can
use
to
present
some
proof
across
the
wire
so
that
no
one
else
can
spoof
it
all
right.
I
want
corn,
to
give
me
a
proof
that
says
I'm
talking
to
the
real
corn
such
that
only
corn
could
produce
that
proof
and
no
one
else
could
produce
that
proof
right
or
likewise.
A
A
There's
some
important
differences
in
those
two
systems
right
in
terms
of
what
correlation
exists
and
who
gets
to
know
what?
When
and
we'll
talk
about
that
as
we
get
into
the
idea
of
a
verifiable
credential
but
effectively,
the
idea
we're
talking
about
here
is
once
I
can
do
a
kin
introduction.
We
can
send
encrypted
messages
back
and
forth
and
if
I
can
use
some
Oracle
to
authenticate
that
connection,
it
actually
doesn't
matter
how
this
connection
works.
It
can
go
through
multiple
hops.
I
can
route
it
through
multiple
servers.
A
I
can
do
all
kinds
of
things
with
that
connection
right,
because
I
know
that
I've
encrypted
it
for
its
endpoint
and
no
one
except
for
the
endpoint,
can
decrypt
it.
This
points
out
some
some
interesting
things.
We
have
three
pieces
that
typically
make
up
some
sign
cryptographic
information.
This
is
oversimplified.
You'll
want
to
wait
till
I
finish
the
slide
transitions
before
I.
Take
you
to
take
a
picture
because
I'm
going
to
talk
about
them
one
at
a
time.
The
first
two
pieces
are
keys
and
identify
errs.
A
Now,
if
you
think
about
this
as
a
certificate
authority,
usually
you
ignore
that
identifier
piece
right,
because
identifier
czar
in
the
dental
to
the
protocol
I
put
a
GU
it
in
the
certificate
when
I
issue
the
certificate,
because
I
say
tell
me
what
your
key
material
is.
You
give
me
your
public
key
I
will
bind
it
to
the
attributes
and
I'll
put
the
identifier
Zin
so
that
you
can
check
the
revocation
list
to
see
if
it's
revoked
or
not
revoked
right.
A
Well,
Corin
and
vipin
could
get
together
and
decide
whether
they'd
both
talked
to
me
and
whether
it's
the
same
me
and
now
they
can
share
information
between
each
other
and
I,
have
no
idea
that
they
did
it
right,
I'm
no
longer
in
charge
of
my
information
disclosure
because
they
can
collude
without
my
participation.
Now,
let's
say
I
said
here:
dip
and
here's
my
home
address,
and
my
name
and
my
phone
number
and
I
gave
the
same
information
to
Corrin.
A
A
Just
like
you
would
off
of
a
PGP
key
server
or,
like
you
would
look
up
a
key
in
a
certificate
authority
system
and
I
can
get
information
that
I
need
in
order
to
know.
Are
you
the
owner
of
this
and
if
I
don't
have
a
way
of
talking
to
the
owner
of
this,
can
I
find
how
to
talk
to
the
owner
of
that?
The
second
piece
we
talked
about
a
little
bit
is
this
idea
of
a
certificate
when
I
bind
keys
to
the
particular
set
of
attributes?
That's
when
I'm
making
a
credential
all
right.
A
That's
what
I'm
saying
here
you
are
my
employee.
This
is
an
employment
credential.
You
are
my
customer
at
a
bank.
Here's
your
banking,
credential
right,
you're,
packaging,
up
a
setting
that
set
of
and
you're
giving
them
to
someone,
and
to
do
that,
it's
not
enough
just
to
sign
the
attributes
that
you're
handing
to
someone.
You
need
to
know
why
the?
What
intention
did
you
have
of
signing
this
thing
and
giving
it
to
them?
You
need
some
set
of
semantics
or
some
sort
of
identifiers
that
describe
all
those
attributes.
A
So
you
know
what
use
cases
you
can
trust
them
for
and
what
use
cases
you
can't
trust
them.
For
now
note
I,
didn't
say
what
use
case
is
the
issue
or
wants
you
to
trust
them
for
I
said
what
cues
case
is
that
you
want
to
trust
them
for
right,
because
in
order
to
make
this
kind
of
information
sharing
system
work,
each
person
in
the
system
has
a
unique
role,
everyone's
in
charge
of
their
own
key
management,
it's
their
own
problem
and
they
want
to
be
able
to
do
that
independently.
A
So
let's
look
a
little
bit
of
at
D
IDs,
so
here
I
have
a
D
ID,
that
is
the
sovereign
method,
D
ID.
So
this
is
a
URL.
It's
it's!
It's
a
did,
which
is
essentially
a
declaration
that
if
you
use
this
URL
and
you
resolve
it
through,
what's
called
a
did,
resolver
you're
going
to
get
back
something
we
call
a
did
dock.
The
full
name
is
a
did
document,
but
this
is
a
data
model
specification
at
the
w3c.
The
one
dato
of
this
data
model
specification
has
been
published
as
a
recommendation.
A
You
use
that
plug
it
in
to
a
did.
Resolver
you'll
get
back
a
did
document
that
says
here
are
the
keys
that
are
the
owners
of
this.
Did.
If
you
want
to
know
whether
this
object
is
from
the
owner
of
the
dead,
you
can
check
to
see
if
it
was
signed
by
one
of
these
public
keys.
It
also
establishes
some
other
semantics
about
how
the
did
works.
There's
a
bunch
of
different
attributes.
You
can
look
up
and
you
can
look
at
it
how
that
works.
A
If
you
haven't
talked
to
Daniel
Hardman,
he
has
some
really
great
sessions
that
are
going
to
be
going
on
later,
that
talk
about
the
Pierre,
did
specification
and
how
you
can
decentralize
protocols
off
chain,
or
it
can
be
a
centralized
system.
If
you
have
signal
on
your
phone,
they
centralized
this
identifier
system
by
using
your
phone
number
on
a
server
that's
encrypted
with
SGX,
to
make
it
so
that
all
the
lookups
can
only
happen
in
their
centralized
architecture,
but
you
could
easily
think
of
it
as
did
signal,
and
then
your
phone
number
right.
A
That
could
be
something
you
could
define
as
it
did
method
spec
anything
that
uses
a
cryptographic
key
to
bootstrap
a
messaging
protocol.
It
could
be
modeled
it
as
it.
It
does
have
an
interesting
property,
that's
not
the
same
thing
as
a
UUID
and
that's
not
the
same
thing
as
an
ORM
in
that
they
imply
this
construct
of
ownership,
meaning
someone
owns
and
controls
the
cryptographic
keys
behind
them
all
right.
You
can
abuse
DIDS
and
you
can
throw
them
on
everything
like
you.
A
Would
you
you
IDs,
but
when
you
do
that,
you
lose
a
lot
of
the
value
of
what
it
did
is
about
because
dudes
are
about
knowing
who's
the
owner
and
can
I
trust
that
this
came
from
the
source
and
can
they
own
and
manage
their
cryptographic
key
over
time
in
a
way
that
I
can
continue
to
use
the
data,
even
though
the
keys
rotated
and
changed.
So,
let's
have
some
fun
with
signing
encryption.
We've
got
Alice
and
Bob.
A
They've
got
a
connection
and
they're
going
to
start
sending
things
around,
but
you
know
Alice
and
Bob
have
cell
phones
in
this
model
and
I
don't
know
about
you,
but
cell
phones.
They
tend
to
move
around.
My
battery
goes
dead
all
the
time
and
you
can't
rely
on
them
always
being
online.
You
can't
he'll
rely
on
them
always
being
connected.
You
can't
rely
on
them
always
being
connected
in
the
same
place,
so
you
need
to
be
able
to
have
a
messaging
system
that
allows
routing
through
multiple
hops.
Some
of
those
hops
may
be
malicious.
A
They
may
not
be
owned
or
controlled
directly
by
the
individual.
All
right
remember:
we
established
at
the
beginning
that
you
need
to
have
cryptographic
keys
and
you
be
able
to
fire
the
device
that
owns
and
controls
those
keys
right,
because
you
don't
want
to
talk
to
Alice's
OS
provider.
You
want
to
talk
to
Alice
right,
you
don't
want.
You
know
the
the
phone
vendor
to
impersonate
Alice.
You
don't
want
the
cloud
operator
to
impersonate
Alice.
You
want
to
talk
to
Alice
right.
A
So
when
we
message
we
expect
that
it
goes
through
multiple
hops
and
we
expect
that
those
hops
might
not
be
owned
or
controlled
by
a
party.
So
we
have
a
specification.
That's
built
on
top
of
the
did
specification
we
like
to
call
it
did
communications
or
for
short,
we
call
it
did.
Comms
did
comms
was
incubated
in
hyper
ledger,
indie
that
split
off
into
the
hyper
Legere
EES
project
and
the
spec
specification
work.
A
A
A
Maybe
the
cloud
agent
forwards
it
straight
on
to
Bob's
phone
and
Bob's
phone
gets
a
pop-up
that
says
oh
hi,
from
Alice
right,
because
we've
handled
an
introduction
protocol
specification
inside
of
Aires
and
because
we
have
the
the
did
comm
specification
for
building
all
of
these
different
fundamental
message
types.
You
can
now
do
what
we
call
basic
message
and
you
can
send
all
sorts
of
just
little
encrypted
payloads
of
whatever
text
or
binary
that
you'd
like
and
that
can
be
used
to
build
all
sorts
of
different
kinds
of
things
right.
A
A
Identity
systems
typically
work
like
this.
If
you're
a
developer,
you've
probably
built
one
of
these
on
accident,
where
you
stumbled
into
a
situation
where
you
needed
to
save
data
about
your
user,
and
you
said
well,
where
am
I
going
to
put
this?
Oh
now
we
need
a
username
and
password
now
some
login
or
we
need
some
system
of
making
sure
we
have
the
same
person
last
time.
A
You
don't
even
know
it's
there.
In
many
cases
you
certainly
don't
have
any
ability
to
change
it
unless
the
developer
who's
running,
that
server
gave
you
permission
to
do
so.
It
turns
out
that
most
blockchain
identity
systems
that's
exactly
what
they
do
and
then
the
company
will
come
and
tell
you
they're
selling
you
a
decentralized
identity
system,
because
it's
on
a
blockchain
throw
them
out
of
your
office,
because
this
is
what
happens.
All
the
data
comes
off
the
blockchain,
it's
all
from
the
same
place.
A
A
And
if
I
try
to
tell
corn
about
VIP-
and
he
says
I
I,
don't
know
him
all
right.
I
need
something
more
oK.
We've
got
the
solution.
It's
called
federated
identity,
this
time
for
sure
all
right,
the
federated
identity
system.
This
is
what
we
end
up
with
it
all
still
comes
off
the
same
system
of
record.
It's
called
your
IDP
and
you
know
we
were
really
excited
about
federated
identity.
It
was
gonna
solve
this
problem.
A
If
you
look
at
sam'l
and
OAuth,
they
actually
have
provisions
for
you
to
act
as
your
own
independent
identity
provider
like
you'd,
stand
up
your
own
server
in
your
basement
and
you'd
act
as
your
own
IDP,
but
in
practice
none
of
the
developers
really
support
it.
Because
then
you
get
into
your
your
website.
You
say
login
with
anything,
and
not
only
do
you
not
remember
you
user
name
and
password,
you
don't
remember
which
IDP
you
use
to
create
the
username
and
password
right,
and
so
in
practice.
What
happened?
A
Is
everyone
consolidated
down
to
a
very,
very
few
number
of
ID
piece?
All
right,
you
use
Facebook,
you
use
github
you
use
Microsoft,
which
is
now
the
same
thing
as
github,
and
you
know,
and
those
IDPs
end
up
consolidating
into
a
natural
monopoly
is
simply
for
ease
of
use
and
ease
and
convenience
of
how
it
works.
So,
even
though
we've
we've
color-coded
all
these
attributes,
based
on
which
server
they
came
from
in
practice,
you
ended
up
exactly
back
into
the
same
model
that
you
had
before.
There
are
even
more
blockchain
identity.
A
A
He
also
has
cryptographic
keys
to
know
that
I'm,
the
real
me
right
and
because
we've
done
that
at
each
connection,
we
can
now
do
this
information
sharing
transitively
across
multiple
hops,
so
I
can
get
a
credential.
I
can
show
a
credential,
but
I
don't
have
to
do
it
with
one
peer
I
can
now
do
it
with
any
peer
right
and
that's
what
makes
the
system
decentralized
is
that
I
anyone
can
say
anything
they
want,
and
anyone
can
prove
anything
they
want
to
to
anyone
else.
Right
and
I
hope.
A
There's
two
things
that
you
just
thought
about.
When
I
said
that
two
things
that
hopefully
made
you
panic
just
a
little
bit
in
your
heart,
one
is
I,
don't
just
have
a
cryptographic
key
for
me.
I
have
a
cryptographic
key
per
context:
I
operate
in
right
cryptographic,
key
management
isn't
just
a
little
bit
important.
It's
a
lot
important.
The
second
is:
how
on
earth
am
I
going
to
know?
Who
should
what
all
right?
Because
just
because
you
get
a
license
that
says
this
person
is
allowed
to
do.
A
Brain
surgery
doesn't
mean
you
should
trust
it
right
in
the
real
world.
We
do
a
lot
of
things
to
figure
out
whether
that's
the
case
or
not.
In
a
cryptographic
system
like
this,
you
also
have
to
do
all
those
same
kinds
of
things
all
right,
so
we
talked
a
little
bit
about
the
decentralized
identifiers
specification
right
VIP
and
gave
me
a
credential,
but
in
order
for
Scott
to
know
it's
the
real
VIP
in
that
it
needs
to
have
some
public
D
ID.
A
That
says
I'm
going
to
be
issuing
the
following
kind
of
credential
right:
maybe
a
membership
credential
and
the
identity
working
group.
Hopefully
you
know
all
about
the
identity,
working
group
and
you're
doing
some
things
to
help
participate
there.
You
need
to
have
some
decentralized
key
management
stuff
right.
You
need
to
know
that
these
cryptographic
keys
are
me
and
that
I
haven't
lost
them
or
given
them
away
to
someone
else
right.
If
you
can't
count
on
the
continuity
of
those
identifiers,
zin
the
D
IDs,
you
can't
count
on
the
reliability
of
the
system.
A
This
is
what
we
do
in
the
real
world,
all
the
time
when
you
go
to
get
a
voter
registration,
you
have
present
this
or
three
of
the
following
of
these
or
two
of
the
following
of
these
right.
When
one
part
of
the
identity
system
doesn't
work,
we
usually
fall
back
to
other
pieces
of
the
identity
system.
When
you
get
locked
out
of
your
car
in
the
grocery
store
parking
lot,
they
are
not
relying
on
your
key
in
your
pocket
to
authenticate
you
as
the
owner
of
the
car.
A
The
holder
is
in
charge
of
what
data
they're
willing
to
retain
and
who
they're
willing
to
share
that
information
with
the
verifier
is
in
charge
of
what
data
they're
willing
to
rely
upon
and
what
data
they're
for
what
use
k-star
will
for
what
purpose
and
those
roles
have
to
stay
separate
for
the
stability
of
the
system
to
be
preserved.
The
verifier
has
a
trust
relationship
with
the
issuer,
but
the
verifier
doesn't
talk
to
the
issuer.
A
If
the
verifier
starts
to
do
relay
time,
API
signaling
back
to
the
issuer
and
talks
to
them,
then
what
happens
is
whoever
has
more
market
power
between
the
issuer
and
the
verifier?
Becomes
the
system
of
record
consolidates
the
data
and
stops
giving
the
data
to
the
holder?
That's
not
a
theoretical
proposition.
That
is
exactly
what
happened
in
OAuth
and
an
open
ID
connect.
So
we
want
to
maintain
the
three
party
system
of
how
the
information
is
shared
so
that
you
retain
the
ability
to
own
and
control
your
data
and
maintain
it
over
time.
A
This
doesn't
mean
that
you
have
to
have
your
own
wallet
on
your
own
infrastructure,
because
there's
certainly
lots
of
issuers
or
verifiers
who
have
motivation
to
to
manage
that
type
of
infrastructure
at
scale.
But
they
have
to
manage
it
in
a
way
that
you
own
and
control
it
and
you
can
fire
it
because
if
it
doesn't
work
for
you,
you
can't
count
on
the
continuity
of
the
IDS
and
you
can't
count
on
the
authority
of
the
key
management
system.
So
we
have
protocols
to
issue
credentials.
A
I
need
to
be
able
to
send
messages
back
and
forth
to
make
the
credentials
system
work
and
to
make
sure
that
you're
giving
you
the
data,
that's
fit
for
purpose,
for
what
you're
trying
to
do
with
it,
because
I'm
not
in
charge
of
where
you
presented
I'm,
just
in
charge
of
giving
it
to
you-
and
this
is
great
for
me,
because
I
can
use
this
to
make
it
so.
The
data
that
I've,
cleaned
and
managed
for
my
brand
can
be
used
for
you
to
pay
me
for
things
that
I
can't
anticipate
right.
A
You
can
create
credentials
that
require
payment
and
make
it
so
that
there's
a
lot
more
people
who
are
willing
to
pay
you
right.
So
we
expect
that
this
giving
someone
a
credential
is
a
negotiation.
This
allows
us
to
sign
the
credential
in
a
way
that
can
be
presented
to
multiple
parties,
but
it
also
means
that
you
get
a
marketplace
for
how
credential
is
issued
and
you
get
the
schemas
that
are
the
most
useful.
We
also
have
a
mechanism
for
presenting
proofs.
I
have
a
diagram
of
this.
That
looks
exactly
like
the
previous
slide.
A
Where
you
offer
someone
to
proof,
and
then
they
request
a
proof,
and
then
you
provide
the
proof
to
them.
It
really
is
as
simple
as
that,
but
when
you
start
writing
a
spec
down,
this
is
what
you
get,
because
you
have
to
account
for
all
the
corner
cases.
So
if
you
go
into
Ares,
this
is
actually
an
Ares
RS
tianhao
proofs
are
presented,
and
this
is
the
diagram
out
of
that.
A
Bc
gov
is
running
a
workshop
on
the
Aries
cloud
agent
Python
on
Thursday
and
the
sovereign
foundation
is
running
a
workshop
on
building
out
use
cases
and
using
kind
of
the
breadth
of
all
the
open
source
code
bases
where
we'll
be
walking
you
through
how
to
make
this
protocol
work
and
set
up
a
PLC
for
yourself.
So
when
we
get
back
to
the
layers,
remember
we
have
the
idea
of
an
Oracle,
the
sovereign
foundations.
A
Oracle
is
built
to
run
in
a
public
way
in
a
public
place
right,
so
anyone
can
verify
credentials
that
were
issued
against
this
definition.
You
never
put
the
credential
on
the
chain.
The
only
thing
you
put
on
the
chain
is
I'm
gonna
sign
stuff.
This
is
what
the
stuff
I'm
gonna
sign
is
gonna,
look
like
and
here's
how
to
tell
if
it's
revoked
or
not
I'm
not
going
to
use
any
unique
identifiers
in
that
proof.
A
I'm
gonna
use
techniques
that
don't
disclose
who
it
is
so
I'm
gonna
do
a
set
membership
proof
to
say
if
you're
revoked
or
not
revoked
without
disclosing
which
one
you
are
but
I'm,
just
gonna
put
the
definitions
here.
So
we
talked
about
it's,
not
the
source
of
truth.
It's
the
root
of
trust,
right,
you're,
gonna,
walk
a
chain
of
trust
based
on
the
domain
specific
credentials
you
want,
but
you
can
check
whether
the
revoked
or
not
based
on
what's
here
and
that
way,
I
can
have
a
medical
license.
A
Credential
I
can
have
a
banking
credential,
I
kind
of
a
government,
ID
credential
and
I
can
prove
them
all
in
aggregate
I
can
know
that
they're
revoked
are
not
revoked
in
an
atomic
way,
because
I
can
check
them
all
at
one
single
point
in
time
on
the
chain,
but
I
don't
have
to
talk
to
any
of
those
issuers.
I
can
gather
all
that
dated
and
selectively
prove
the
pieces.
I
have
the
layer
that
gives
us
connections
right.
We
talked
about
we've
done
an
introduction
protocol,
we've
traded
keys.
A
Now,
we've
routed
messages
all
over
the
place,
that's
the
cryptographic,
trust
basis
of
the
system,
and
then
once
we
have
that
cryptographic
trust
we
need
people
to
exchange
credentials
with.
We
need
to
know
what
the
purpose
of
those
credentials
are
and
we
need
to
know
whether
the
issuers
of
those
credentials
are
following
rules
that
make
them
fit
for
purpose.
For
us
write
a
certificate
authority
falls
pretty
extensive
set
of
rules
to
know
whether
or
not
that
you
should
trust
that
certificate
and
it's
similar
in
lots
of
different
domains.
A
Your
driver's
license
or
thority
follows
a
set
of
rules
of
who
they'll
issue
a
driver's
to
license
to
and
who
they
will
not.
How
do
they
double
spend
proof
a
driver's
license
so
that
they
don't
issue
two
driver's
licenses
to
two
people:
four
Vipin,
instead
of
just
the
one
vipin
that
we
all
know
right.
Those
are
the
rules
layer
of
the
system
and
the
sovereign
network
has
infrastructure
to
support
all
of
these
different
layers.
A
In
order
to
make
this
credential
ecosystem
work,
it's
not
the
identity
system,
it's
what
we
would
call
the
identity
meta
system,
it
sits
underneath
the
identity
system
and
one
of
the
things
that's
interesting
about
this
is
hyper
load.
Your
ursa
has
cryptography
to
do
multi
signature
credentials
with
threshold
signatures,
so
an
issuer
doesn't
have
to
be
a
single
party.
An
issuer
can
actually
be
an
entire
block
chain.
You
don't
have
to
build
your
identity
infrastructure
on
your
own.
A
If
you
leverage
these
specifications,
your
Genesis
transaction
block
effectively
works
like
what
we
would
call
a
credential
definition.
You
can
say
my
blockchain
state
is
backed
by
the
following
signatures
and
if
we
can
collectively
sign
it
on
our
blockchain,
anyone
can
validate
or
trust
it
based
off
anchoring
these
types
of
objects.
So
these
specs
work
not
just
to
build
the
sovereign
network,
but
this
pattern
is
a
recursive
pattern.
As
long
as
we
have
a
quorum,
the
folks
we're
willing
to
be
the
notary
or
our
public
Oracle,
we
can
repeat
this
pattern
at
every
level.
A
We
want
to
in
any
place
that
we
need
to
so
the
sovereign
foundation
runs
a
public
network.
To
do
this,
we
also
support
and
do
what
we
call
the
network
of
networks
at
the
sovereign
foundation
where
we
can
help
you
stand
up
your
own
identity
network
for
your
own
purpose-built
thing
and
all
the
code
and
all
the
specs
that
we're
working
on
are
all
open
source.
We
do
it
all.
As
apache2
like
we
do
at
hyper
ledger.
A
We
host
most
of
the
code
here
at
hyper
laser
some
of
at
the
decentralized
identity
foundation,
also
under
the
same
apache2
licenses,
and
we
work
on
the
open
specifications
at
standards.
Organizations
that
are
publishing
those
specs
for
everybody
to
see
in
use
as
part
of
what
makes
this
work
is
that
you
need
to
know
you
can
take
your
ball
and
go
home.
A
Remember
we
talked
about
when
your
device
doesn't
work
for
you,
you
need
to
be
able
to
fire
it
and
hire
a
new
device,
that's
also
true
of
the
Oracle
level
layer
and
so
to
make
the
system
work.
You
have
to
be
aggressively
open
at
every
part
of
the
system.
Otherwise
you
can't
trust
that
you
own
and
control
it.
Someone
else
could
then
say
well
we're
gonna.
Take
those
identifiers
is
over
and
we're
gonna
become
you
and
you
have
to
make
sure
the
system's
architected
so
that
that
cannot
happen
and
remember.
A
We
talked
about
messaging
and
you
can
send
any
payload
you
want.
We
spend
a
lot
of
time
talking
about
verifiable
credentials,
but
that's
just
scratching
the
surface.
If
you've
been
following
along
in
the
Aires
community,
all
sorts
of
other
interesting
protocols
are
starting
to
emerge.
We
now
have
decorators
for
payments
that
can
use
any
sort
of
cryptographic
asset
as
a
payment
as
part
of
the
messaging
infrastructure.
A
We've
always
wanted
to
do
with
package
management
with
software
discovery
and
software
management,
where
you
can
walk
the
chain
of
trust
to
build
out
all
kinds
of
cryptographic
systems,
because
you
have
a
core
of
key
management
that
you
can
build
on
top.
We
can
talk
about
schemas.
We
can
talk
about
the
new
rich
schemas.
We
can
talk
about
how
the
sovereign
network
works.
We
can
talk
about
the
software
stack
that
exists
in
hyper
ledger
and
a
few
things
on
top.
A
But
remember
standards
are
always
an
interesting
thing
because,
as
soon
as
you
start
building
a
standard
someone's
going
to
ask
for
another
standard.
So
if
you
want
to
participate
in
this
work,
please
come
and
help
us
there's
a
lot
of
work
to
do
and
there's
a
lot
of
places
to
have
fun.
In
particular,
I
recommend
showing
up
on
the
identity
working
group
calls
if
you're,
not
a
tech
person.
A
You'll,
get
to
hear
a
lot
about
the
business
case
and
about
the
diversity
of
how
identity
systems
are
work
across
all
a
little
blockchain
ecosystem
and
if
you're,
a
coder
or
if
you
want
to
get
deeper
into
the
text,
show
up
on
the
identity.
Working
group
implementers
call.
Where
will
tell
you
the
summary
of
what's
going
on
in
all
these
communities
and
we'll
help
you
get
involved.