►
From YouTube: What Does BBS+ Mean For Verifiable Credentials?
Description
A virtual meetup hosted by Evernym and Hyperledger Denver on April 1, 2021 featuring Drummond Reed and Brent Zundel discussing why BBS+ LD-Proofs are the privacy-preserving VC format that everyone should implement and what convergence on this new flavor of verifiable credentials means for interoperability. Their presentation covers a brief history of verifiable credential formats, and how a lack of convergence makes scale and interoperability an ongoing challenge, how BBS+ Signatures are the breakthrough that combine the best of the JSON-LD and ZKP formats while still allowing for selective disclosure and non-trackability, and the path forward: What remains to be done to fully converge on the BBS+ format.
More about Evernym and Hyperledger Denver are at:
https://www.evernym.com/
https://www.meetup.com/Hyperledger-Denver/events/277178728/
----
Hyperledger – Open Source Blockchain Technologies
Hyperledger is an open source community focused on developing a suite of stable frameworks, tools and libraries for enterprise-grade blockchain deployments.
It serves as a neutral home for various distributed ledger frameworks including Hyperledger Besu, Fabric, Sawtooth, Indy, as well as tools like Hyperledger Avalon, Cactus and libraries like Hyperledger Aries, Ursa. Learn more about Hyperledger projects: https://www.hyperledger.org/use
Case Studies: https://www.hyperledger.org/learn/case-studies
Training & Certification: https://www.hyperledger.org/learn/training
Tutorials: https://www.hyperledger.org/use/tutorials
Webinars: https://www.hyperledger.org/learn/webinars
Events: https://www.hyperledger.org/events
Vendor Directory: https://www.hyperledger.org/use/vendor-directory
Subscribe to the Hyperledger Newsletter: https://www.hyperledger.org/newsletter
Follow-us on Twitter @Hyperledger
Learn about Hyperledger Membership: https://www.hyperledger.org/about/join
#Hyperledger #HyperledgerMeetups #Blockchain
A
Yeah
good
morning,
good
afternoon,
good
evening
to
you
all
from
here
in
the
uk
and
we've
got
my
colleagues
coming
in
from
the
us
as
well
shortly
welcome
to
another
web
evident
webinar.
My
name
is
andy
tobin.
I
look
after
our
business
here
in
europe,
as
you
probably
know,
there's
a
lot
of
regular
faces
on
here,
but
these
webinars
are
focused
on
self-sovereign
identity
and
digital
credentials,
and
we
run
these
webinars
regularly
to
help
you
learn
faster
and
build
more
efficiently.
A
On
our
last
webinar
we
had
a
stellar
panel
with
us
who
talked
about
health
credentials,
which
is
a
topic.
That's
all
over
the
news
at
the
moment,
and
just
prior
to
that
as
well.
We
had
alan
murray
hayden
from
iata
talking
about
the
to
travel,
past
initiative,
which
I
think
goes
down
as
the
most
well
attended.
Webinar
we've
done
so
far,
which
is
obvious.
A
Why
really
isn't
it
and
it's
fair
to
say
that
digital
credentials
are
attracting
mainstream
interest
around
the
world
at
the
moment,
catalysed
by
the
kobud
crisis,
and
rightly
the
issue
of
privacy
and
confidentiality
comes
to
the
fore.
So
if
you
just
joined,
you
didn't
see
the
trailer
there.
On
april
the
14th
we
have
our
next
webinar,
which
is
one
not
to
be
missed.
A
Many
of
the
previous
webinars
we've
had,
if
you've
been
nominated,
you'll
know
we
have
many
many
more
questions
that
we
can
ever
handle.
I've
been
lots
of
questions
about
the
underlying
technology.
We've
not
had
really
the
time
to
do
them.
Justice
and
we've
had
lots
of
requests
to
go
deeper,
so
so
you
asked
for
it
and
you're
gonna
get
it
here.
It
is
today
we're
talking
about
bbs
plus.
A
What
is
it
and
what
does
it
mean
for
verifiable
credentials?
I'm
I'm
joined
today
by
cryptographic.
Royalty.
If
you,
dr
next
slide.
Thanks
alex
my
own
experience
in
cryptography,
stopped
at
triple
des
and
brent
is
in
a
different
league.
Altogether
brent
wrote
a
blog
post
recently
on
everything.com
blogs,
slash
blog,
describing
why
the
verifiable
credential
community
should
converge
on
bbs
plus
it's
well
worth
a
read,
and
it
really
the
interest
in
that
catalyzed
the
need
to
put
this
webinar
on
so
brent.
B
Yeah
hi
folks,
my
name
is
brent
zundell.
I
been
working
at
evernote
for
nearly
four
years
now
and
been
knee-deep
in
crypto
and
verifiable
credentials
and
anonymous
things
in
privacy
and
standards
and
all
sorts
of
stuff
since
that
time.
So
it's
been,
it's
been
a
lot
of
fun
and
we're
gonna
have
a
lot
of
fun
today.
A
C
A
Cool,
thank
you
very
much
so
on
the
agenda
today,
really
pretty
simple
agenda.
Actually
we're
just
going
to
give
you
a
quick
primer
into
three,
really
simple
concepts
that
are
really
important
to
understand.
We
attend
a
lot
of
webinars.
Other
people
give
them.
You
know
we
read
things,
you
know
blog
posts
and
opinion
pieces
and
all
that
kind
of
thing,
and
it's
often
the
case
where
people
don't
get
some
of
this
stuff
right.
A
So
what
we
want
to
do
is
just
make
sure
we
all
are
up
to
speed
on
three
basic
concepts,
because
we're
going
to
be
referring
back
to
them
a
lot
in
this
session,
so
we'll
be
doing
that
and
then
brenton
is
going
to
be
quizzed
intently
by
drummond
and
then
we're
going
to
open
up
to
audience
q
a
so
that's
the
agenda
simple.
As
that.
A
Really,
if
you've
got
any
questions,
please
put
them
in
the
zoom
q,
a
okay
there's,
a
zoom
chat,
but
the
questions
we
normally
like
to
take
them
in
the
zoom
q.
A
if
you
can
do
that.
Please
alex
in
the
background
our
webinar
wizard.
I
will
pull
those
together
and
we'll
go
through
as
many
of
them
as
we
can
do
after
the
the
session
with
withdrawing
the
brain.
So
you,
if
you
can
ask
your
question
in
the
zoom
q,
a
that'd
be
great.
Please
note.
A
A
So
without
further
ado,
let's,
let's
crack
on
a
quick
primer
for
you
on
verifiable
credentials
and
privacy
on
three
specific
areas:
selected:
disclosure
compound
proofs
and
zero
knowledge,
proof
signatures.
So
let's
crack
into
those.
This
is
a
really
significant
capability
that
these
three
components-
I've
just
described-
that
underpin
a
lot
of
the
principles
around
privacy
that
are
built
into
the
way
that
we've
implemented
verifiable
credentials.
A
So
the
first
one
we
want
to
talk
about
is:
what's
called
selective
disclosure.
What
do
we
mean
by
that?
Well,
it's
a
it's!
A
superpower
that
you
get
with
digital
credentials
that
you
don't
get
with
paper
ones.
Selective
disclosure
simply
means
you
can
take
selected
elements
from
a
credential,
so
selective
attributes
and
only
reveal
those
without
revealing
the
other
data
in
the
credential.
So
in
this
example
with
a
driving
license,
you
might
have
what
have
you
got
on
there?
A
Maybe
15
attributes,
but
in
order
to
do
a
particular
transaction,
you
only
need
to
reveal
two
of
them.
So
that's
what
we
call
selective
disclosure,
and
in
order
to
do
this,
you
need
to
have
a
lot
of
the
stuff
that
drummond
and
brent
are
going
to
be
talking
about
in
a
minute
you,
you
can't
really
do
this
with
paper
credentials
or
you
know
passport.
You
show
it
to
somebody
and
they
can
see
everything
if
it's
a
driving
license
say
seeing
your
address
when
all
you
want
to
do.
Is
you
know
it's?
A
The
second
concept
is
compound
proofs,
so
a
compound
proof
is
where
you're
taking
attributes
from
multiple
credentials
and
bringing
them
together
into
a
single
proof.
Okay,
so
in
this
example
here
you've
got
some
information
from
the
driving
license
and
you've
got
some
information
from
the
concert
ticket
two
different
credentials,
but
you're
taking
elements
of
information
from
each
using
selective
disclosure,
but
you're
compounding
you're
bringing
these
attributes
from
different
credentials
from
completely
different
credential
issues
together
to
create
what
we
call
a
compound
proof.
A
You
can
do
this
without
ever
having
to
go
back
to
the
issuer
right.
You
can
do
it
on
the
fly
when
the
when
you're
asked
to
prove
something
your
app
will
compute.
All
of
this
for
you
automatically
and
provide
a
compound
proof
without
revealing
all
of
the
other
data
on
those
credentials
so
really
really
powerful.
That's
what
a
compound
proof
is
so
selective
disclosure
compound
proofs,
vitally
important
and
also
demonstrates
the
flexibility
of
verifiable
credentials
done
right.
A
You're
only
sharing
the
minimal
information
you
need
to
share,
but
you
can
combine
different
sources
of
information,
which
is
often
what
happens
like
if
you're
on
board
into
a
bank.
You've
got
two
proofs
of
address
from
different
utility
companies
and
a
proof
of
citizenship
and
so
on.
That's
naturally
what
we
all
do
so
compound
proofs
allows
you
to
do
that,
and
the
third
piece
is
getting
deeper
into
the
tech
correlating
signatures.
A
Okay,
if,
when
you
prove
something
to
a
verifier,
if
you
share
the
issuer's
signature,
then
your
providing
them
all
with
a
perfect
correlator
that
allows
everything
you
do
to
be
correlated
across
those
different
verifiers
you're,
sharing
that
information
with
so
when
the
issuer
signs
a
credential
if
they
sign
it
with
their
signature
that
signature
they've,
signed
it
with,
is
unique
to
that.
Put
that
credential
pertaining
to
you.
A
So
if
you
have
to
share
that
signature
in
order
for
the
verifiers
to
check
that
that
credential
is
authentic,
you're
sharing
like
a
unique
global
super
cookie
and
all
of
those
third
parties
that
you're
sharing
with
they
could
collude
behind
your
back.
It's
like
a
super
version
of
a
google
ad
identifier
right
so
correlating
signatures.
You
don't
want
to
have
the
way
you
want
to
do.
It
is
instead
of
sharing
the
issue,
a
signature
and
go
to
the
next
slide.
Please
alex
instead
of
sharing
the
issue
with
signature.
A
What
you
do
is
you
share
a
zero
knowledge
proof
that
you
have
the
issue
of
signature
without
sharing
the
signature
itself,
so
every
verifier
that
you're
sharing
information
with
when
you're,
providing
a
proof
you're,
not
sharing
the
issue
of
signature
now
to
do
that
is
as
we'll
find
out
in
a
minute.
Drummond
will
ask
ask
brent
how
this
works.
This
is
vitally
important.
A
The
the
last
thing
we
want
to
do
with
this
whole
new
world
of
verifiable
credentials
is
create
some
new
global
tracking
economy,
so
the
ability
to
share
information
that
can
be
verified
as
authentic
without
sharing
the
issues.
Signature
stops
you
being
correlated,
and
it
also
means
the
verifiers
don't
have
to
contact
the
issuer
to
verify
anything
and
therefore
the
issuer
is
blinded
to
to
what
you're
actually
doing
and
who
you're
sharing
your
information
with,
which
is
how
it
should
be.
C
Absolutely
andy,
that's
that's!
I.
First
of
all,
you
did
a
great
great
job
of
describing
why
why
it's
important
and
and
brent
in
his
blog
post
goes
into
sort
of
the
origin
story.
So
I'd
like
to
start
with
my
questions
to
brent
about
that
and
and
brent,
would
you
back
up
and
give
us
a
little
history?
What
was
zero
knowledge
proof
crypto,
always
part
of
the
picture
for
w3c,
verifiable
credentials
or
or
how
did
it
come
into
the
picture.
B
Well,
those
those
who've
read
the
blog
post
know
that
my
my
beginnings
with
the
verifiable
credential
community
were
rather
abrupt.
So
I
was,
you
know,
thrust
into
the
group,
not
sure
what
standards
were
or
how
how
the
process
worked,
or
any
of
that.
I
just
knew
that
in
order
for
us
to
be
able
to
use
the
resulting
standard
that
that
the
group
was
building,
we
needed
to
have
a
zero
knowledge
proof
story.
B
I
found
ready
support
from
the
chairs
of
the
group.
They
had
wanted
a
good
privacy
story
for
verifiable
credentials
and
had
heard
of
zero
knowledge
proofs.
So
I
got
a
lot
of
encouragement
from
them
and
shout
out
to
mono
sporney
the
edit
one
of
the
primary
editors
of
the
verifiable
credentials.
Spec,
I
would
you
know,
write
a
pr
and
mona
would
come
back
and
go
now.
If
you
want
this
pr
to
actually
get
into
the
spec,
I
suggest
you
word
it
this
way.
B
C
B
Yeah
they're,
this
is
one
of
the
flavors.
The
the
chairs
of
the
group
were
really
hoping
to
get
some
some
diversity
of
possible
implementations,
and
so
I
recommend
everybody
to
read
a
report
from
kalia
about
the
different
flavors
of
your
credentials.
If
you
haven't
read
that
yet
it's
a
really
really
good
primer
on
on
what
we're
talking
about
right
now
there
was
this
in
the
group.
There
was
this.
B
This
kind
of
dichotomy
between
this
highly
interoperable
ld
signatures
on
one
side
using
jason
ld,
which
is
really
powerful,
provides
good
semantic,
meaning
for
for
what
the
credential
attributes
actually
what
they
mean.
On
the
other
side,
we
had
our
commenda
licianskia,
zero
knowledge
proof
capable
signatures.
You
know
very
capable
in
reducing
this
unwanted
correlation.
That
andy
was
talking
about
not
only
signature
correlation,
but
correlation
of
the
holder.
You
know
the
zkp
credentials
don't
require
that
the
holder
be
given
an
identifier,
that's
shared.
B
C
Okay,
so
so,
basically,
as
as
cleo's
report
describes,
there
have
been
these
three
major
flavors
jwt
and
jason
ld
and
then
the
ckp
format.
So,
let's,
let's
now
zero
in
on
that
zkp
format,
you've,
I
think
you've
hit
most
of
what
are
the
reasons
that
evernum
originally
proposed,
that
and
and
that
that's
been
what
we
have
focused
our
our
implementation
on
and
that
the
hyperledger
indian
aries
stack
explicitly
supports
what
are
the
main
reasons
for
for
for
what
I
think
it's
been
called
anonymous
credentials.
B
So
the
the
original
goal
of
anonymous
credentials
and
of
and
all
of
the
tech
that
evernote
has
has
built
and
tried
to
promote.
We
want
power
to
be
in
the
hands
of
the
people
who
own
the
data.
You
know.
If
the
data
is
about
me,
I
should
be
able
to
control
who
sees
it,
how
much
they
see
and
when
and
so
we
we
looked
for
credential
signatures
that
had
the
capabilities.
B
You
know
that
andy
mentioned
selective
disclosures
is
vitally
important
if
I
have
a
credential
and
I,
and
that
the
verifier
really
only
needs
two
attributes
on
that
credential
then
I
shouldn't
have
to
share
all
25
and
the
verifier
most
verifiers
that
we
work
with.
They
don't
want
to
see
those
extra
23
anyway,
that's
they're,
recognizing
more
and
more
that
this
additional
data
doesn't
really
benefit
them.
B
Additionally,
signature
blinding
is
really
important.
Andy
pointed
out,
it's
a
you
know,
revealing
the
signature
is
a
perfectly
correlating
identifier,
any
verifier
that
sees
that
can
say.
Oh
yep,
this
is
the
signature.
Hey
did
you
get
this
thing
yeah,
I
got
it.
What
information
did
you
get?
Well,
let's
share.
Let's,
let's
build
up
a
better
profile,
let's
collaborate,
it
also
prevents
one
of
my
favorite
aspects
of
anonymous
credentials.
B
The
only
knowledge
that
was
passed
back
was
is
this
individual
authorized
to
be
here?
Yes
or
no?
Okay?
Yes,
they're
authorized
to
be
very
good
and
we
don't
have
to
know
you
know
precisely
who
they
are,
and
all
of
that
we
can.
We
can
let
them
in,
and
we've
been
able
to
expand
on
that
cl
signatures
also
provide
link
secrets
for
holder
binding.
This
is
a
really
important
concept
because
it
many
of
the
ld
signatures
and
even
the
jwt
credentials.
They
rely
on
a
decentralized
identifier
for
the
holder.
B
Now
decentralized
identifiers
are
fantastic,
but
as
a
holder,
I
don't
want
the
same
decentralized
identifier
to
be
presented
to
a
bunch
of
different
verifiers.
I
don't
want
to
provide
another
correlating
factor
I
want.
I
want
the
power
to
correlate
myself
as
much
as
I
need
to,
and
no
more
the
other
thing
that
cl
signatures
had
that
we
really
really
liked
was
the
ability
to
do
predicate
proofs
so
rather
than
if
I
have
a
credential
from
my
bank
of
my
you
know,
my
current
bank
account
status.
B
C
C
B
A
link
secret
is
just
it's
a
secret:
let's
bring
it
back
to
the
ids.
If
I'm
the
holder
of
a
did.
How
do
I
prove
that
it's
mine?
How
do
I
prove
that?
I
control
it.
Well,
I
have
a
private
key
and
I
can
sign
something
with
that
private
key
and
it
can
be
verified,
so
the
the
security
that
dids
are
based
on
is
based
on
the
holder,
knowing
some
secret,
and
I
can
demonstrate
that.
B
I
know
that
secret,
based
on
the
architecture
of
the
decentralized
identifiers
link
secrets,
is
exactly
the
same
thing,
but
I
don't
have
to
share
and
identify.
I
don't
have
to
share
anything
that
correlates
me.
I
can
still
prove
I
know
the
secret,
but
I
can
do
it
in
a
way
that
doesn't
allow
that
if
I,
if
I
prove
to
two
different
verifiers,
I
can
do
it
in
two
different
ways
so
that
those
verifiers
can't
get
together
and
and
know
that
they've
talked
to
the
same
person.
C
So
what
you're
saying
is
what
andy
was
talking
about
was
not
the
ability
to
avoid
correlation
on
the
issuer
signature,
which,
of
course
the
the
verifier
has
to
be
able
to
verify
that
the
issuer
actually
issued
the
credential.
But
what
you're
saying
is
that
link
secrets?
Allow
you
to
avoid
correlation
on
the
holder
signature
to
prove
they
have
the
credentials
that
right.
B
Right
right,
just
as
on
the
issuer
side,
you
know
yeah,
the
verifier
needs
to
know
who
the
issuer
is,
but
an
issuer
signing
credentials.
Every
single
credential
signature,
especially
with
lv
signatures.
It's
going
to
be
a
unique
value
and
the
verifier
just
takes
that
value.
Does
a
little
bit
of
math
and
goes
yes.
Okay,
this
this
this
works
with
ours.
We
can
reveal
a
different
signature
every
time
the
verifier
still
does
a
little
bit
of
math
and
goes
yup.
It
works
out.
It
checks
out.
C
Right
so
so
it
seems
that,
since
what
we
need
to
avoid
is
to
avoid
this
correlation,
we
need
to
avoid
issuer
signature,
correlation
and
holder
signal
signature.
Correlation
is
this
is
the
ultimate
conclusion
here
that
to
avoid
both
of
those
things
and
avoid
either
one
being
a
tracking
beacon
in
your
credential,
the
only
option
for
privacy-preserving
credentials
is
to
use
a
zkp
and
link
secrets.
B
Yeah,
I
I
think
a
lot
of
people
are
concerned
about
zero
knowledge
proofs.
What
zero
knowledge
proof
really
means
it
doesn't
mean,
I'm
not
showing
anything.
It
means
no
information
is
shared
beyond
what
I
want
to
share.
The
verifier
gets
zero
knowledge
about
anything
other
than
what
I'm
proving.
So
they
don't
get
the
signature
value.
They
don't
get
an
identifier
for
me
as
a
holder.
They
zero
knowledge
proofs.
B
C
B
C
Without
the
the
privacy,
you
know
disrespecting
implications,
okay,
so
so,
basically
they
support
a
super
set
of
what
you
can
do
with
with
non
zkp
credentials
in
terms
of
what
a
verifier
can
get
correct
right,
gotcha,
all
right.
So
so
so
I
think
we've
established
why
you
know
evernum
and
other
supporters
of
zkp
credentials
made
sure
they
were
there
and
why
we've
implemented
that
way
and
and
and
why
we
chose
anonymous
credentials,
which
is
brent.
That's
that's
based
on
crypto
that
originally
started
where
ibm
zurich
research
labs.
B
C
So
it's
it's
pretty
mature
technology,
which
leads
me
to
my
next
question
and
and
the
subject
of
this
webinar.
If
so,
if
we've
already,
you
know
if
it's,
if
it's
specified,
if
it's
been
implemented
and
avernum
customers
have
these
zkb
cl
based
credentials
in
production.
Why
now
this
interest
in
a
new
zkp
format.
B
Well,
if
you
want
to
make
a
cryptographer
wince
start
talking
about
rsa
rsa
is,
is
a
really
widespread
famous
algorithm
for
for
signing
and
for
encryption
and
over
the
years
it
has
been
attacked
a
lot
and
in
order
to
to
maintain
security
levels
within
rsa,
the
keys
have
gotten
bigger
and
bigger
and
bigger
over
time.
So
cl
signatures
are
based
on
rsa,
which
has
served
us
well,
it's
you
know.
B
So
we've
we
implemented
a
pairing
space
signature
from
the
start.
We
use
one
with
our
revocation
scheme
in
indy.
It's
a
that's
a
pairings-based
signature
scheme.
It
we
were
working
on
rich
schemas
or
schema
2.0.
We
were
working
on
anonymous
credentials,
2.0,
trying
to
figure
out
a
way
to
bring
our
technology
into
better
conformance
with
the
w3
spec,
w3c
spec,
and
better
interoperability
with
with
ld
signature
stuff,
and
so
we
we
went
searching
for
a
good
pairing
space
signature
at
the
time.
Bbs
plus
it
was
the
clear
choice.
B
It
was
better
than
the
one
we
had
already
implemented.
We
had
pretty
close
interactions
with
jan
kamenich
at
the
time
and
and
other
cryptographers,
and
they
said
yeah
yeah.
We
we
don't
use
that
one
either
we're
using
bbs
plus.
So
we
we
decided
to
implement
it,
we
being
evernum
and
the
sovereign
foundation
and
members
of
the
community.
You
know
everyone
was
primarily
in
a
support
role
for
that
one,
but
bbs,
plus
the
signature
scheme
was
implemented
in
hyperledger
ursa
and
we
planned
to
adopt
it.
B
We
just
said:
okay,
bbs
plus,
is
there
now
we
need
to
figure
out.
How
do
we
do
predicates
with
it?
How
do
we
do
better,
revocation
with
it
and
okay
there's
this
whole
rich
schema
side
that
touches
on
interoperability?
How
are
we
going
to
do
all
of
these
things?
As
folks,
who've
read
the
blog
know,
this
didn't
quite
go
the
way.
I'd
hoped
you
know,
anytime.
You
spend
a
year
of
your
life
on
a
project.
You
want
it
to
go
somewhere
it
rick
schemas
was
just
too
complicated,
it
was.
B
The
breakthrough
came
from
somebody
else:
the
loving
the
open
source
community
that
we
have
at
iiw
matter,
global,
said
hey
if
we
take
bbs
plus
signatures
and
do
things
in
this
way
we
can
use
bbs
plus
ld
proofs,
which
is
an
ld
signature,
and
so
they,
they
tweaked
bbs,
plus
to
make
it
more
compatible
with
ld
signatures,
which
was
the
original
goals
of
rich
schemas
and
non-credits
2.0
anyway,
they're,
like
I
said,
they're
compatible
with
ld
signatures.
They
support
selective
disclosure,
they
do
signature
blinding.
B
There's
also
this
ability
to
do
you
know
linking
of
any
two
attribute
values
from
different
credentials,
which
is
which
is
pretty
fantastic,
which
means
even
beyond
the
link
secret.
If
I
have
a
passport
and
a
health
credential,
I
can
prove
that
the
same
first
and
last
name
are
included
in
both
credentials,
but
I
don't
have
to
share
my
first
and
last
name
with
you:
it's
pretty
powerful
capability,
the
one
thing
they
didn't
give
us
was
predicates,
and
so
we
had
to
it.
Would
we
forced
us
to
to
do
some?
C
B
Well,
we're
we're
getting
we're
giving
up
predicates
we're
getting
compatibility
with
ld
signatures,
we're
we're
getting
smaller,
faster
signatures,
we're
we're
getting
all
of
the
goodness
of
the
original
anonymous
credentials
minus
predicate
proofs.
For
now.
I
think
that
it's
going
to
be
possible
to
introduce
predicate
proofs
as
a
capability-
that's
compatible
with
bbs
plus,
but
we're
not
going
to
have
that
out
of
the
gate.
C
B
I
I'm
confident
that
we
will
will
probably
focus
on
revocation.
First,
you
know,
revocation
as
it's
implemented
in
hyperledger
indie
is,
is
pretty
tied
up
with
the
way
that
cl
signatures
are
implemented
and
porting
that
same
revocation
scheme
over
to
bbs
plus
doesn't
really
make
sense
when
there
are
more
efficient
and
better
ways
to
do,
revocation
that
would
be
a
little
bit
more
compatible
with
bbs
plus.
So
the
first
thing
we're
going
to
try
to
figure
out
probably
is
revocation
but
yeah
predicates
is
on
the
roadmap.
C
C
Okay,
all
right!
So
so
I
think
it's
you
know.
Hopefully
this
makes
it
clear
again.
You
want
to
go
deeper
in
the
details.
Brent's
blog
post
does
that
so,
let's,
let's
turn
to
sort
of
the
practical
implications
and
and
folks
are
already
asking
questions
here
in
the
chat,
what
what
what
remains
to
be
done
brent,
to
put
bbs
plus
credentials
into
full
production.
B
B
I
think
it's
close,
but
the
the
work
there
still
needs
to
be
done.
It's
done
enough
that
folks
have
implemented
against
it
and
shown
that
they
can
be
interoperable
with
it,
which
means
it's.
It's
really
close,
but
it's
not
quite
there
yet
another
aspect,
because
because
bbs
plus
ld
proofs
enable
bvs,
plus
privacy
preserving
safe
credentials
to
be
used
alongside
other
ld
signature
credentials,
we
need
to
look
at
the
ramifications
of
that.
B
You
know
it
doesn't
make
sense
to
use
this
privacy
preserving
safe,
credential
alongside
a
credential.
That's
perfectly
revealing-
or
at
least
we
need
to
make
people
aware
that
that's
happening
at
the
very
least.
So
those
are.
Those
are
two
of
the
things
that
I
think
we
really
need
to
to
hammer
out
before
we
can
use
them.
Then,
like
I
said,
we
also
want
to
figure
out,
revocation
and
predicate
proofs.
Those
are,
those
are
big
musts
from,
from
my
perspective,.
C
Yep
this
sounds
again.
I
know
your
blog
post
goes
into
more
detail
about
about
sort
of
the
road
map
from
here
to
to
full
production.
So
what
I
see
we,
I
have
it
on
my
question
list.
That's
already
being
asked
by
our
audience
what
differences
will
end
users
see
in
in
the
move,
from
zkpcl
to
bbs,
plus.
B
Well,
the
holders
I'm
hoping-
and
they
shouldn't
notice
much
of
anything,
they're
they're,
getting
a
credential
they've
gotten
credentials
before
we
intend
them
to
be
able
to
use
all
of
their
credentials
moving
forward
so
holders
shouldn't
notice.
Much
of
anything
verifiers,
hopefully,
will
notice
that
things
are
a
bit
smaller,
that
they
can
do
things
more
quickly
that
they
have
access
to
this
greater
semantic
meaning.
You
know
right
now,
when
you
share
a
cl
signature,
anonymous
credential,
the
verifier,
essentially
kind
of,
has
to
know
what
the
issuer
was
thinking.
B
C
So
so
so
we'll
be
adding
support
for
bbs
plus
credentials,
but
not
taking
away
support
before
and
then
so
that
means
issuers
can
pretty
much
seamlessly
just
just
transition
across
and
their
holders
shouldn't
notice
anything
and
provide
verifiers
have
the
software
to
verify
that
format.
They
too
should
have
a
pretty
seamless
transition.
Is
that
right?
That's
the
plan.
Okay,
so
last
question
before
we
jump
into
the
audience
questions.
So
what
if
others
in
the
audience
are
agreeing
yeah?
It
sounds
like
bbs
plus
a
pretty
good
idea.
B
B
If
you
have
funding
for
some
cryptography
work,
send
somebody
to
ursa
to
hammer
at
the
bbs
plus
implementation
there.
I
have
faith
that
it's
a
pretty
darn
good
implementation,
it's
very
faithful
to
the
specification,
but
the
more
eyes
that
you
can
have
on
a
cryptographic
key
component,
the
better
we
want
to
know
we
want
to
know
its
flaws.
We
want
to
know
where
it's
going
to
break
and
look
at
in
your
own
organizations
what
it
would
take
to
what
it
would
take
to
move
to
bbs
plus
and
support
it
yourselves.
C
A
A
There
is
quite
an
important
difference
lurking
in
there,
which
is
at
the
moment,
if
you
use
some
evidence,
connect
me
app,
for
example,
there's
no
control
over
the
order
of
the
attributes
that
are
listed
right
and
you're,
seeing
the
attribute
names
which
could
be
quite
obscure,
and
you
know
the
verifier
doesn't
know
if
a
date
is
going
to
be
year
month,
day
or
day
month
year.
That
kind
of
thing,
so
you
are
getting
kind
of
service
decorators.
B
Yeah,
the
so
getting
a
little
technical
right
now.
The
the
list
of
attributes
for
an
anonymous
credential
is
a
json
array,
which
means
it's
just
it's
a
list
of
strings.
That's
all
it
is
using
bbs
plus
ld
proofs
will
be
able
to
take
full
advantage
of
any
json
ld
schema.
Schema.Org
has
has
hundreds
of
them
as
long
as
it
can
be
described
in
json.
We
can
use
it
issue,
a
credential
based
on
it.
A
And
I
think
yeah
we've
had
feedback
from
you
know
live
projects
like
with
the
national
health
service.
In
the
uk,
for
example,
you
know
they
want
to
see
their
name
and
their,
maybe
their
employee
id
at
the
top
of
the
credential,
not
some
strange
base64,
hex
kind
of
thing
so
being
able
to
put
a
nicer
user
interface
on
it.
I
think,
is
a
huge
leap
forward
from
just
a
flat.
You
know,
structure
where
the
actual
attribute
names
are
revealed.
A
B
A
A
B
A
Right
and
the
once
the
issuer
has
a
public
did
on
the
ledger.
What
they're
signing
the
credentials
with
is
a
different
thing,
completely,
really
isn't
it
so
they're
you
know.
What's
on
their
dicks,
you
got
a
credential
definition
with
signatures
with
verification
keys
in
it
as
well,
and
you've
got
the
peer
did
with
that
individual
person
as
well,
plus
the
link
secret
right.
B
A
Right,
interesting:
okay,
let's,
let's
crack
on
with
another
one
here
right!
Well,
this
is
a
bit
like
related
to
link
secrets
actually,
but
what
kind
of
options
are
available
to
make
sure
that
attributes
in
a
compound
proof
are
talking
about
the
same
person
versus
just
the
same
holder,
for
example,
proof
of
age
from
a
driving
licence
and
proof
of
education
from
a
college
certificate.
A
B
A
B
A
A
B
So
so
the
simple
way
to
do,
revocation
is
for
an
issuer
to
go
here.
Are
the
identifiers
of
all
the
credentials
that
I've
issued
that
I
have
revoked
and
as
a
holder,
I
would
have
to
take
that
unique
number
share
it
with
the
verifier
and
the
verifier
goes
and
looks
at
this
revocation
list
and
goes
okay,
good
you're,
not
on
the
list.
A
B
A
Yeah
yeah-
and
I
actually
just
see
this
andreas
in
in
the
chat
to
avoid
track
and
trace
yeah,
absolutely
right.
If
the
issuer
can
see
everything
you're
doing,
then
it's
not
very
private.
So
so
you
need
to
be
able
to
have
the
issue
a
revoke,
a
credential
without
the
verifier
having
to
speak
to
the
issuer,
because
also
the
issue
may
disappear
as
well.
That's
another
thing:
isn't
it
maybe
drummond
on
this
one?
A
C
Well,
yeah,
there's
you've
hit
the
two
key
points:
andy
there's
the
privacy
issue
of
what's
broadly
called
the
phone
home
problem
right,
yeah
and-
and
I
have
heard
you
know
for
for
issuers
that
are
that
are
or
for
formats
that
require
issuing
to
a
public.
Did
the
assumption
is
you're
issuing
the
public
the
id,
and
then
it's
brought
up.
Well,
that's
the
you
know.
Now:
you're
gonna
have
the
correlation
of
that
did
everywhere.
It's
used,
the
answer's
been
oh
well,
we
can.
C
We
can
issue
a
new
version
of
the
credential
each
time
you
need
to
use
it
and
now
you've
just
inverted
the
problem
now
you're
phoning
home
every
time,
you're
issuing
the
credentials.
So
I
I
you
know
neither
one
of
those
I
think
is
adequate,
but
you
also
bring
up
the
second
point
of
when
there
is
a
a
fully
verifiable
signature
that
doesn't
depend
on
having
to
go
back
to
the
issuer.
You've
got
a
lifetime
credential
right,
you're,
not
limiting
it
to
to
the
the
issue
we're
still
being
around.
A
Yeah
and
that's
what
you
have
with
your
birth
certificate
right,
you
have
a
printed
birth
certificate
as
long
as
you
don't
lose
it
right.
You
carry
it
with
you
and
you
can
always
verify
you
would
you
show
it
in,
albeit
it
could
be
photocopied
et
cetera,
but
you
know
we
all
have
these
things
and
we
carry
them
with
us
and
even
if
the
whoever
it
was
issued,
the
birth
certificate
is
destroyed
in
a
war
or
disappears.
You
still
have
the
physical
things.
This
is
the
digital
equivalent
of
that
all
right.
A
B
They
would
be
created
by
the
holder
in
response
to
a
proof,
request
or
a
presentation
request
from
a
verify,
so
the
verifier
composes
a
a
set
of
basically
a
set
of
acceptable
credentials
or
or
attributes.
They
want
to
see
from
specific
credentials
and
they
say
okay,
this
issuer,
this
type
of
credential
would
be
acceptable.
Show
me
these
five
attributes,
plus
from
this
other
issue
or
these
attributes.
If
you
show
me
all
of
those
things,
then
I
have
what
I
need.
B
A
Yeah,
so
in
with
connect
me
that
supports
compound
proofs
already
and
the
evident
mobile
app
that
it
does
create
a
compound
proof,
you
know
in
under
a
second
and
send
it
off.
I
think
the
more
attributes
you
get
for
the
more
credentials
it
takes
longer
to
do
all
the
calculations
right
so
generally
asking
for
fewer
fewer
attributes.
You
asked
for
the
quickest,
the
quicker
it's
going
to
be
here's
one
from
swapnap.
I
hope
I've
got
that
name
right.
Is
it
possible
to
choose
the
type
of
signature?
B
As
yeah
as
an
issuer
you
need
to,
there
are
some
pre-set
up
things
that
you
need
to
do
with
anonymous
credentials.
You
need
to
generate
a
credential
definition,
which
is
a
whole
bunch
of
randomly
selected
prime
numbers
with
bbs.
Plus
you
need
to
choose
the
you
know
the
initial
value
for
those
deterministically
hierarchically
deterministic
key
generation
there.
So
there
is
a
bit
of
setup,
and
so
the
issuer
does
need
to
choose
in
advance
what
signature
they're
going
to
use
before
they
issue
a
credential.
B
A
A
A
Cool
okay,
here's
one
from
timo
glastro
hi
timo.
What's
the
role
of
indy
going
to
be
with
bbs
plus
support
for
evan
m
bbs,
plus
signatures
are
broader
than
the
indie
ecosystems.
I'm
curious
what
the
role
of
india
is
going
to
be
when
we
have
json
ld,
bbs
plus
credentials
is
indie
just
going
to
be
doing,
revocation
and
digs.
B
I'll
I'll
take
a
stab
at
it,
the
the
primary
function
of
indy.
As
I
see
it,
is
to
support
a
distributed
ledger
that
has
some.
You
know
some
good
oversight,
that's
it's,
but
it's
all
ledger
stuff.
So
bvs
plus
removes
some
of
this
reliance
on
the
ledger.
Our
initial
round
of
bbs
plus
signatures
we're
not
going
to
have
a
revocation
story
built
in
we
don't
have
predicates
and
and
the
signatures
don't
require
a
credential
definition
on
the
ledger,
and
so
beyond
the
issuer
being
known
by
a
did.
B
There
isn't
much
that
the
ledger
needs
to
be
involved
with
for
bbs
plus,
so
what
I
anticipate
is
there
will
probably
be
an
indie
hype
that
says
this
generic
bbs
plus
ld
proof.
So
you
can
sign
anything
with
that.
How
are
we
going
to
use
them
safely
in
a
way
that's
compatible
with
you
know
the
the
priorities
and
and
things
that
indy
the
indie
community
cares
about.
A
Yeah
I
got
it
so
so
the
in
fact
drummond-
I
don't
know
if
you
can
chip
in
here
on
the
you're,
reducing
the
dependence
on
or
opening
up
to
allow
for
multiple
ledger
support.
I
I
guess,
because
we're
seeing
ledgers
popping
up
for
all
sorts
of
things
at
the
moment
aren't
we
and
people
shouldn't,
have
to
worry
about
that.
C
Exactly,
I
think,
that's
the
point.
Andy
is
we've.
We've
there
has
been
in
the
evolution
of
you,
know:
verifiable
parental
space,
a
pretty
close.
It
called
dependency
of
wallet
and
agent
implementations
on
specific
ledgers
and
formats,
and
so
I
believe-
and
I
want
brent
to
to
to
validate
this-
that
moving
to
a
format
like
bbs
plus
and
knowing
you
know
what
we've
learned
so
far.
Is
this
going
to
brent?
Take
us
in
a
step
of
greater
ledger
independence,
the
bbs
plus
credential
format.
B
I
I
believe
that
it
will
right
now
anonymous
credentials
depend
pretty
strongly
on
indy,
because
india
has
the
you
know
this.
The
transaction
types
that
can
be
stored
there
or
credential
definitions
and
the
revocation
registries
moving
forward
bbs
plus
requires
requires
less
reliance
on
a
ledger
and
the
things
that
it
does
require
of
a
ledger
can
be
done
a
little
bit
more
generically.
B
C
So
does
that,
would
you
say
that
would
apply
to
non-indie
ledgers
as
well?
You
know
ethereum
or
ion
or,
or
you
know,
new
ledgers
that
are
our
new
did
methods
that
are
occurring
we're
now.
As
you
know,
as
co-chair
of
the
did
working
group,
I
think
we're
going
to
pass
90
registered
did
methods.
We
have
passed
90.,
okay,
wow
yeah,
as
as
that
spec
has
gone
to
a
candidate
recommendation.
Folks
are
like
hey.
C
C
Weapon,
I
think
that's
another
webinar,
I
I
wanna
say
I'm
going
to
be
say,
I'm
going
to
channel
sam
smith
here
and
say
of
course,
any
key
format
you
want
to
use.
Carrie
can
also
support.
Carry
is
not
a
it's,
not
a
specific
cryptographic,
algorithm
or
signature
algorithm.
It's
a
whole
architecture
for,
but
that's
that
is
another
webinar.
A
C
C
Self-Certifying
identifiers
and
the
corresponding
key
management,
which
makes
it
the
most
decentralized
of
to
my
knowledge,
of
all
of
that
I'll,
put
in
a
blog
that
plug
that
the
the
book
on
self-sovereign
identity
that
I'm
a
co-author
of
the
last
two
years.
Work
is
going
to
come
out
in
april
and
and
sam
smith
has
written
an
entire
chapter
on
carrying
there.
So
lots
more
to
come
on
that.
A
C
A
Webinar
I
was
going
for
rotation,
but
anyway
anyone
else
who
wants
to
invent
some
more
acronyms.
Please
feel
free
and
chuck
them
all
away.
We'll
just
do
another
couple
of
questions
before
we
close
off
and
there's
two
actually
on
link
secrets
one's
from
oliver
hi
oliver,
another
one
is
anonymous,
but
what
happens
to
link
secrets
with
bbs
plus
signatures?
Is
I
mean,
link
secrets
are
mysterious
enough.
They
get
more
mysterious,
what's
happening
right.
B
B
The
there's
a
key
feature
about
bls
keys
is
that
once
I
have
my
private
key,
I
can
reveal
any
number
of
different
public
keys
for
that
private
key,
which
is
what
a
link
secret
is
and
does
so
it's
an
identical
mechanism,
cryptographically
and
mathematically.
It's
it's
got
a
little
bit
different
terminology
around
it
which
actually
helps
us
when
we're
trying
to
explain
these
things
to
you
know
to
folks
who
know
what
bbs
plus
ld
proofs
does
is
it.
B
It
describes,
holder
binding
that
is
either
privacy
respecting
or
not,
and
so
you
know
one
of
the
aspects
in
my
opinion
that
we
need
to
you
know
to
make
sure
of,
as
we
move
indi
into
a
position
to
use.
Bbs
plus,
is
to
you
know,
state
rather
emphatically
that
we're
going
to
use
the
privacy
preserving
mechanism
rather
than
the
the
non.
A
Okay,
let's
do
maybe
one
last
one,
okay,
so
timeline,
so
timo
glacier
is
saying:
what's
the
expected
timeline
for
bbs
plus
support
in
evening
products?
Well,
first
of
all,
I
just
want
to
say
that
evident
products
were
all
in
on
bbs,
plus
and
adjusting
road
maps
and
all
that
kind
of
thing,
as
you
might
expect,
but
I
think
the
the
there's
probably
a
question
before
that,
which
is
what's
the
timeline
for
bbs
plus
and
this
kind
of
standardization
stuff
you
described
brent,
it
feels
like
it
could
be.
A
B
It's
it's
happening
pretty
quickly.
I
know
from
from
everyone's
perspective,
I
I'm
not
a
product
guy
and
every
time
I
invent
timelines
for
things,
people
wince
and
cringe,
because
I'm
terrible
at
it.
I
know
that
we
want
this.
We
want
these
capabilities
as
soon
as
we
can
get
them
as
soon
as
we
can
figure
out
how
to
do
it
safely.
B
B
Like
I
said,
the
the
ld
proof's
draft
spec
is
is
in
a
really
good
state
right
now
there
are
still
some
a
few
answers
here
and
there,
the
more
folks
who
are
able
to
give
it
to
give
it
a
read
through
and
raise
questions
about
it,
the
the
faster
that
can
go
the
faster.
We
can
end
up
with
something
that
a
lot
of
people
can
agree
on
yeah.
C
B
C
Just
to
clarify
there
andy,
the
part
of
the
benefit
of
bbs
plus,
is
that
the
the
format
will
be
compatible
with
the
w3c
standard
right.
The
verifiable
credential
specification.
So
what
we're
needing
to
standardize
is
okay,
let's
agree
on
the
signatures,
how
they're
applied
to
ld
so
that
you
know
so
that
it's
actually
interoperable
it's
not
just
compliant
with
the
w3c
spec.
Is
that
right,
brent.
B
A
Yeah
so
there's
a
few
steps
to
go,
but
I
think
what
we're
seeing
is
is
a
meeting
of
mines
right,
isn't
it
because
if
it
feels
from
my
kind
of
layman's
perspective
that
we've
got
a
sweet
spot
here,
we've
got
a
lot
of
the
beauty
of
things
like
selective
disclosure,
zero
knowledge
proof.
You
know
not
revealing
issues.
Signatures
compound
proofs
plus
we've
got
the
service
decorator
side
of
things
that
makes
it
easier
to
use
and
put
context
and
structure
around
it.
So
that's
that's
my
kind
of
reading
of
the
non-technical
side
of
things.
A
B
B
C
A
We're
seeing
that
we're
seeing
that
again
and
again
as
people
get
into
the
detail,
they
go.
Oh
yeah,
we've
got
to
make
sure
this
is,
is,
you
know,
has
privacy
built
in
and
and
on
that
topic
I
think
we're
wrapped.
Now,
I'm
just
amazed
so
many
people
well,
I
should
be
amazed
because
awesome
content,
but
so
we
still
got
a
whole
bunch
of
people
on
there's
a
whole
bunch
of
questions
we
as
you
we
couldn't
get
to,
but
thank
you
for
asking
them
anyway.
Your
contributions
are
great.
A
It
really
helps
us
to
see
what
people
are
thinking
about
when
they
ask
these
questions
as
well.
A
couple
of
things
just
to
let
you
know
about
so
the
internet,
identity,
workshop,
number,
32
and
drummond
will
tell
us
he's
been
at
all.
32
of
them
is,
is
on
april
20th
to
22nd,
so
20th
to
22nd
of
april
iiw,
there's
a
session
there,
convergence
on
bbs
plus
verifiable
credentials
who
would
have
thought
that
was
happening
so
please
go
and
attend
that
one
and
you
get
a
lot
more
detail
on
it.
A
Also,
we've
got
our
next
webinar
coming
up,
that's
that
is
on
the
14th
of
april,
on
previously
by
design
with
doctor
and
kabuki,
which
should
be
a
cracker.
So
please
come
along
for
that
as
well,
thanks
for
everyone,
who's
attended,
special
thanks
to
brent
for
being
awesome
as
usual
and
drummond
for
being
equally
as
awesome,
perfect
stuff,
thanks
very
much
have
a
great
weekend
for
those
who
are
have
the
day
off
tomorrow
for
easter
friday
and
enjoy
ourselves
and
see
you
later.
Thank
you
very.