►
Description
AnonCreds was accepted as an Incubated project at Hyperledger in late 2022. This is the first workshop developed by this community and it is intended for anyone interested in using Zero Knowledge Proofs (ZKPs) in a wide variety of contexts.
This workshop will be livestreamed and recorded. The planned agenda:
Part 1:
Online Identity With Verifiable Credentials
Introduction to Hyperledger AnonCreds
AnonCreds Data and Processes (Hands On)
Setup
Issuing
Presenting
Revocation
Part 2:
Zero Knowledge Proofs: The High School Math Edition (time permitting)
Ledger-Agnostic AnonCreds
AnonCreds in the W3C VC Data Model Format
AnonCreds Exchange using CHAPI
Making Credentials Beautiful — OCA
Futures: AnonCreds v2.0
Presenters
Stephen Curran, Cloud Compass Computing Inc./BC Gov
Rodolfo Miranda, RootsID
Patrick St-Louis, Digital Identity Lab of Canada/Laboratoire d'identité numérique du Canada
More about Hyperledger AnonCreds is at:
https://wiki.hyperledger.org/display/ANONCREDS/
Slides, labs and other resources used in the workshop are at:
https://wiki.hyperledger.org/display/events/Hyperledger+AnonCreds%3A+Using+ZKP+Verifiable+Credentials+Everywhere
----
Hyperledger – Open Source Blockchain Technologies
Hyperledger is an open source community focused on developing a suite of stable frameworks, tools and libraries for enterprise-grade blockchain deployments.
It serves as a neutral home for various distributed ledger frameworks including Hyperledger Besu, Fabric, Sawtooth, Indy, as well as tools like Hyperledger Avalon, Cactus and libraries like Hyperledger Aries, Ursa. Learn more about Hyperledger projects: https://www.hyperledger.org/use
Discord: https://discord.gg/rVCn4j7UFd
Case Studies: https://www.hyperledger.org/learn/case-studies
Training & Certification: https://www.hyperledger.org/learn/training
Tutorials: https://www.hyperledger.org/use/tutorials
Webinars: https://www.hyperledger.org/learn/webinars
Events: https://www.hyperledger.org/events
Vendor Directory: https://www.hyperledger.org/use/vendor-directory
Subscribe to the Hyperledger Newsletter: https://www.hyperledger.org/newsletter
Follow-us on Twitter @Hyperledger
Learn about Hyperledger Membership: https://www.hyperledger.org/about/join
#Hyperledger #Blockchain
License
Creative Commons Attribution license (reuse allowed)
A
And
with
that,
we
are
good
to
go
all
right.
Welcome
everybody
to
the
hyperledger,
a
non-creds
workshop
using
zkp,
verifiable
credentials
everywhere.
We'd,
like
on
behalf
of
hyperledger
we'd,
like
to
thank
the
creators
and
organizers
of
the
workshop
Stephen
Koran,
Rodolfo
Miranda
and
Patrick
son
Louis.
A
We
host
these
software
projects
and
the
communities
that
build
things
like
a
hyperledger
or
non-creds
Indie
Aries
fabric
Sawtooth,
as
well
as
projects
bezoo,
as
well
as
other
projects
like
cacti
for
blockchain,
interoperability,
bevel
and
others.
So,
we'd
like
to
thank
everyone
for
joining
us.
We
are
live
streaming,
this
I'm
going
to
post
the
link
to
the
live
stream.
If
you
want
to
share
it
with
your
colleagues,
this
meeting
is
being
held
under
the
Linux
Foundation
antitrust
policy.
A
If
you
have
any
questions
about
these
matters,
please
contact
your
company
Council
or,
if
you're,
a
member
of
the
Linux
Foundation,
feel
free
to
contact
Andrew
optigrav
of
the
firm
gesmer
up
to
grab
LLP,
which
provides
legal
counsel
to
the
Linux
foundation,
and
this
meeting
is
also
under
the
Linux
Foundation
hyperledger
Community
Community
standards.
Everyone's
welcome
here
and
as
our
as
the
chairperson
of
our
technical
oversight
committee,
says,
be
excellent
to
each
other.
I
am
going
to
stop,
sharing
and
turn
it
over
to
Steven,
Roto
and
Patrick.
You
guys
have
it.
C
And
so
we'll
we'll
get
started
pretty
quickly,
I
think
Sean's,
giving
us
a
good
introduction
covered
the
question
of
who
Andrew
up
to
Grove
is
and
whether
he
is
actually
just
a
chat
bot.
But
you
know
he
could
exist
the
goals
of
this.
Of
that
we
came
up
with
as
we
started
with
this
was
to
is,
is
listed
here.
C
You
know
understanding
verifiable
credentials
in
general,
so
we'll
put
that
we'll
do
that
quickly
at
the
beginning,
because
I
think
a
lot
of
people
here
will
will
know
that
go
into
the
unique
capabilities
of
an
on-preads
and
what
makes
them
different
from
other
verifiable
credentials.
We're
gonna
use
a
thing
called
traction
to
experience,
using
and
on
credits
and
and
we
set
out
some
prep
information
and
and
prep
information
is
available.
C
And
so
we
want
to
you
to
come
away
with
this.
To
be
able
to
say
how
can
you
use
it
on
credits
in
your
app
build
Frameworks
that
use
it
either
open
source
ones
that
that
we
also
participate
in
or
proprietary
ones,
that
your
organization
builds
and
makes
available
to
others
use
of
an
on
creds
in
all
sorts
of
other
contexts?
C
B
B
C
In
huge
numbers
of
business
use
cases,
business
relies
on
being
able
to
get
trusted
information
shared
between
between
many
parties,
so
you've
got
things
like
personal
identification
issued
by
the
government
passports.
Birth
certificates
driver's
licenses
using
those
in
a
variety
of
locations,
including
when
you
copper,
speeding
or
other
such
nasty
things
that
this
police
officer
is
so
angry
about.
C
Other
things,
like
you
know,
travel
even
you
know
being
certified
to
work
being
an
engineer
being
a
doctor
being
a
a
lawyer
and
being
able
to
prove
that
and
then
this
other
one
certificate
of
incorporation
organizations
are
people
too,
and
so
organizations
need
identity
and
they
need
to
share
verifiable
data.
So
that's
the
context
we're
talking
about
the
paper.
Credential
model
has
been
around
about
2
000
years.
It
works
like
this.
C
Some
issuer
provides
a
piece
of
paper
that
has
identify
identifier,
information,
identity,
information,
some
sort
of
information,
and
they
give
it
to
a
holder.
That's
one
transaction
that
occurs
the
holder
holds
on
to
it.
They
might
put
it
in
their
wallet,
they
might
put
it
in
a
filing
cabinet.
They
just
like
put
it
on
their
desk,
but
they
keep
it
sometime
later,
the
verifier
a
verifier
and
could
be
many
but
wants
to
see
that
piece
of
paper
because
they
want
to
do
some.
Some
interaction
with
the
holder
so.
D
C
B
C
C
Is
used
to
prove
that,
oh,
that
name
is
the
same
as
this
name
of
this
person
and
that
the
claims
are
unchanged,
that
it's
not
a
forged
piece
of
paper
and
and
so
mostly
in
that
the
verifier
knows
who
they
want
to
have
issued
the
credential,
but
they
want
to
look
at
the
person
in
the
paper
and
sort
of
see.
You
know.
Is
this
forged
in
any
way
trust
comes
from?
Do
they
you
know
mostly
from
do
they
trust
the
holder?
C
Does
it
really
look
like
a
legitimate
document,
but
they
also
are
making
sure
that
they
know
who
issued
it?
Who
issued
that
credential
or
that
piece
of
paper
I'm
going
to
underline
here
that
these
are
there's
two
parts
to
this
credentials
and
protocols
credentials.
We
don't
really
think
of
protocols
when
we
talk
about
a
paper
credential
model,
but
it
really
is
included,
which
is
somehow
the
issue.
D
B
A
C
I'll
jump
to
that
quick
question
that
I
had
asked
and
on
creds
does.
It
is
usable
in
the
hyperledger
identity
stack
Aries
in
India,
that's
where
it
started,
but
the
extraction
of
an
oncreates
into
its
own
project
allows
it
to
be
used
in
many
other
places.
So
that's
what
that's
partially,
what
we're
talking
about
and
introducing
today?
C
Okay,
when
you
present
a
paper
credential,
the
verifier
is
making
trust
decisions,
they're
they're,
looking
at
the
technology,
the
paper,
the
the
words
on
you
know,
does
it
look
forged?
Does
it
look
like
a
legitimate
representation
of
the
credential?
They
ask
for
the
piece
of
paper
they
ask
for,
but
they're
also
looking
at
governance.
C
That
tends
to
be
obvious
when
it's
things
like
Banks,
you
know
Bank
of
Canada
or
or
the
government
of
British
Columbia,
but
there's
tons
of
use
cases
where
the
paper
comes
from
some
other
source
and
and
you've
got
to
decide
the
verifier
has
to
decide.
Do
they
trust
the
issue
or
do
they
trust
the
processes?
The
issuers
have
so
paper
credentials
in
the
digital
world
are
just
generally
credentials
in
the
in
the
digital
world.
Right
today
are
scanned
scanned
and
emailed.
C
So
that's
the
normal
way
to
do
it,
so
you
take
a
picture
of
it.
These
are
actual
instructions
from
Google
of
how
to
send
your
ID
to
Google.
You
take
a
picture
of
yourself.
Holding
your
driver's
license
looks
like
you
cover
some
of
the
information.
It
only
showed
a
photo
I,
don't
know,
and
and
there
you
go
so
this
is
obviously
not
a
sustainably
useful
approach.
So
this
is
where
verifiable
credentials
come
in.
Basically,
we
have
more
or
less
the
same
actors,
the
issuer,
the
holder
and
the
verifier.
C
The
claims
are
unchanged
again
through
cryptography
that
there
is,
you
know,
a
a
signature
to
use
the
the
term.
A
signature
on
the
credential
that
the
verifier
can
verify
who
holds
the
credential
is
sometimes
proven
and
we'll
talk
about
that
in
the
in
terms
of
and
on
preds
and
other
credential
models,
and
that
the
claims
have
not
been
revoked.
C
This
is
a
new
one
that
is
added
by
the
ability
to
use
digital
credentials
that
that
you
can
check
revocation
of
a
credential
in
real
time
as
a
verifier
remember.
These
are
two
transactions
issued
to
a
holder,
and
then
the
holder
holds
on
to
it,
holder
to
verify
or
sometime
later
or
as
often
as
they
want,
as
a
separate
transaction
still
required
is.
C
Do
you
trust
the
issuer
you
and
not
necessarily
required
as
a
holder,
because
of
these
things
that
are
built
in
it's
almost
impossible
for
the
holder
to
forward
the
credential,
so
the
holder
is
of
less
concern.
Now
the
verifiers
focus
goes
over.
Do
you
trust
the
issuer?
So
you
got
to
know
who
the
issuer
is
and
whether
you
trust
them
credentials.
Presentations
and
Protocols
are
all
involved.
So,
in
this
case,
the
credential
and
the
presentation
may
be
different,
so
a
credential
comes
to
the
holder.
C
In
some
cases
the
holder
presents
a
derivation
of
the
credential
called
a
presentation
to
the
verifier,
and
that's
so
we
add
that
to
this,
but
Protocols
are
completely
involved
how
the
issuer
gets
the
credential
to
the
holder,
how
the
holder
gets
it
to
the
verifier.
All
of
that
is
is
there
okay
I
do
want
to
point
out
that
VCS
are
different
from
open,
ID
connect,
so
open
ID
connect
is
the
login
with
Facebook
model
you
have
the
same
parties
user
in
the
open.
C
C
The
user
asks
the
issuer
contacts,
the
issuer
and
the
data
is
passed
directly
from
the
issue
or
to
the
relying
party.
This
is
all
done
in
a
single
transaction,
and
the
issuer
is
involved
in
every
interaction
and
that's
one
of
the
things
we
we
want
to
get
past.
We
don't
want
the
issuer
to
know
when
the
reli,
when
the
user
is
interacting
with
any
given
relying
party,
and
so
you
can
think
of
that.
Obviously,
in
government
terms,
it's
bad
enough.
C
C
I
always
like
to
underline
this.
Over
and
over
when
a
credential
is
issued.
It
goes
from
the
issuer
to
the
holder.
No
part
of
the
credential
goes
on
to
the
verifiable
data
registry.
No
transaction
occurs
when
the
issuer
issues
to
the
holder.
The
only
thing
that
happens
is
that
is
done
as
part
of
a
setup
as
we
will
see,
and
then
the
issuer
issues
to
the
holder.
C
The
credential
wanted
to
talk
briefly
about
verifiable
credential
ecosystems
in
2023,
basically,
there's
coming
down
to
four
and
perhaps
a
a
few
others
that
are
four
major
communities
that
are
coming
together
on
verifiable
credentials,
and
these
are
starting
to
merge.
These
are
sort
of
forming
and
over
various
times
the
initial
two
were
primarily
in
this
area:
the
w3c
verifiable
credential
data
model,
the
standard
w3c,
verifiable
credential
model
signed
using
data
Integrity
proof.
C
So
that's
the
verifiable
credential
type
The
Exchange
protocols
that
you'll
hear
about
are
chappy
and
VC
API
in
that
Community
hyperledger,
where
you
are
today,
has
primarily
focused
for
the
last
seven
six,
seven
years
on
and
on
threads
with
zero
knowledge
proof,
as
well
as
VCS
with
Json
LD.
So
again,
the
same
credentials
that
are
here
so
hyperledger
things
like
Aries
supports
both
of
these
things.
The
primary
exchange
Protocols
are,
are
called
VidCon,
VidCon
messaging
and
then
Aries
data
exchange
protocol.
C
So
that's
the
the
protocol
there
relatively
new
in
in
the
VC
field,
is
openid
foundation,
which
has
been
using
jots
and
selective
disclosure
drops
we're
going
to
talk
about
that.
A
little
bit
later
and
possibly
other
formats
they're
they're
again
open
ID
is
the
is,
is
attempting
to
be
agnostic
to
the
protocol
type.
C
The
protocols
they
use
are
called
open
ID
for
VCS.
This
is
not
the
same
as
open
ID
connect,
so
they
they
aren't
using
openid
connect,
but
they
are
using
the
foundations
that
underlie
openid
connect
for
these
and
then
there's
the
iso
working
group
and
in
particular
the
mobile
driver's
license
working
group.
C
The
first
one
is
selective
disclosure,
and
this
is
one
that
is
now
appearing
in
all
of
the
other
communities
and
the
one
that
that
that
you'll
see
more
and
more
this.
This
will
become
the
you
know,
absolute
minimum,
that
a
verifiable,
verifiable,
credential
format
type
will
be
have
to
support
So.
This
means
that
when
I
present
something
I
get
a
credential
that
has
all
of
the
data
on
it,
but
when
I
present
it
I
only
want
to
present
some
of
it.
C
So
in
this
case,
I
present
that
it
was
I
have
a
credential
that
was
issued
by
British
Columbia,
but
I'm
only
going
to
show
you
my
picture,
so
selective
disclosure
is
absolutely
crucial
for
minimizing
how
much
data
you're,
sharing
and
increasing
the
privacy,
because
the
data
is
now
cryptographically
signed
and
and
the
verifier
can
do
more
with
it.
They
need
less
data.
They
just
need
the
minimum
data
for
the
actual
transaction
not
dated
to
collect
for
other
purposes.
C
C
So
in
this
case
I'm
walking
into
a
bar
I
present,
my
credential
I
show
that
it
came
from
British,
Columbia
and
I
show
that
I
am
old
enough
based
on
my
date
of
birth,
to
purchase
alcohol,
but
I
don't
actually
give
you
my
date
of
birth
and
again
this
is
a
data
minimization
approach.
It
allows
you
to
do
not
share
more
than
is
necessary
for
the
transaction
needed,
so
those
are
called
predicates
predicates
have
limited
usage,
they
have
to
be
based
on
numbers,
and
things
like
that.
C
So
we'll
get
into
a
bit
on
that.
As
we
talk
more
about
a
non-price
predicate
proofs,
third
one
is
derived
presentations
with
unlinkable
identifiers.
This
is
a
that's
a
handful,
but
what
that
means
is
basically,
when
I
present
this
credential
to
a
verifier
there's
no
in
the
presentation,
the
the
rapper
of
the
of
the
presentation.
There
is
no
unique
identifier
for
either
the
credential
or
the
person
presenting
there
may
be
a
and,
and
if
and
if
the
verifier
asks
again
for
the
same
data,
they
get
a
completely
different
credential.
C
C
You
can
present
multiple
credentials
at
the
same
time
and
show
that
they
were
all
issued
to
the
same
holder
to
the
same.
What's
called
Link
Secret
and
we'll
talk
about
that
a
little
later,
but
there's
a
proof
that
all
of
the
credentials
were
issued
to
the
same
holder,
the
same
wallet
if
you
will
so
those
are
the
unique
capabilities
of
an
on-preads
that
we're
going
to
get
into
what
is
a
non
creds.
It's
a
project
at
the
hyperledger
foundation,
as
as
mentioned
it
was.
C
It
is
the
same
technology
that
was
previously
in
the
indie
project
and
then
extracted
out
and
moved
into
a
specification
into
its
own
own
hyperledger
project.
It
consists
of
a
specification
of
the
1.0
specification
of
the
non-preds
sort
of
mixture,
of
data
models
and
protocols
in
a
working
group
to
evolve
that
there
is
a
full
open
source
implementation
in
Rust
of
the
inocrite
specification.
C
It's
basically
the
give
or
take
fourth
implementation
of
an
on
creds
derived
from
hyperledger
and
indy,
and
a
thing
called
ID
mix
from
IBM
that
had
been
around
for
a
number
of
years,
heavily
used
for
the
past
seven
years
in
the
hyperledges
self-sovereign
identity
stack.
So
that's
the
the
Indie
Aries
Ursa
stack
that
we've
talked
about
that.
That
was
mentioned
in
chat
already.
C
The
new
implementation
is
verifiable
data
registry
agnostic.
This
is
the
new
thing
that
that
we
wanted
to
accomplish
in
doing
in.
In
doing
the
specification,
which
is
previously,
it
was
very
tightly
tied
to
use
of
Indie
and
hyperledger
Indie
ledgers.
It
now,
as
we'll
show
later
in
the
in
the
presentation
or
in
the
workshop,
that
it
can
be
used
with
a
variety
of
data
registries
and
then
finally,
there's
a
working
group
defining
a
non-preads
v
2.0.
C
So
that's
the
Next,
Generation
and
and
we'll
talk
about
what
that
means.
Basically,
it
means
that
we
want
to
retain
or
expand
on
the
capabilities,
and
so
it's
the
capabilities
of
a
non-pregs,
those
things
that
I
mentioned
on
the
previous
slide,
that
matter
and
not
so
and
and
in
doing
that
we
will
adjust
and
modernize,
for
example,
the
underlying
crypto
signatures
that
can
be
used
and
things
like
that.
C
C
I
would
add
this
no
correlatable
identifier
is
very
helpful
for
governments,
because
it
means
that
there
is
no
new
identifier
introduced
for
people
and
for
those
who
have
experience
in
government,
adding
new
identifiers
and
and
the
rules
around
using
it.
If
you
think
about
in
the
US
the
SSN
or
the
sin
in
Canada
or
national
identifiers,
there's
all
sorts
of
legislation,
rules,
and
so
on
about
how
to
use
that
identifier
and
and
how
it
can
be
shared
without
introducing
any
identifiers,
correlatable
identifiers,
we
avoid
that
problem.
C
Is
selective
disclosure
the
rest
of
these
are
and
on
creds
only
features
if
you
will
I'm
going
to
talk
about
a
lot
of
these
things
over
the
course
of
the
workshop,
where
we
are
overall
basis
is
of
a
non-crest.
B1
is
CL
signature.
So
there's
a
link
here
to
that
an
rsa-based
cryptographic,
Suite
canonicalization,
is
describes
how
you
convert
a
a
credentialed,
a
bunch
of
Json
that
is
a
credential
into
a
signed
object
that
can
be
presented,
that's
known
as
canonicalization,
it's
very
simple,
and
then
on
credits.
C
Basically,
signatures
are
applied
to
32,
byte
integers,
so,
basically
everything
every
piece
of
data
every
attribute
in
your
credential
gets
converted
into
an
integer
and
signed
and,
and
basically
the
rules
are,
if
it's
an
integer
in
the
data
in
the
Raw
data.
It
remains
at
that,
if
it's
not,
it
gets
stringified
and
converted
into
a
hash
which
is
an
integer.
C
So
if
you've
got
a
picture,
if
you've
got
a
date
in
text
format,
those
types
of
things
those
gets
converted
into
hash,
hashes,
basically
and
get
signed
integers
remain
integers
throughout
and
and
that
is
why
predicates
work
only
on
integers.
They
don't
work
on,
for
example,
string
values,
predicate
use
a
thing
called
bulletproofs,
which
I
will
leave
to
others
to
figure
out
and
understand.
C
B
C
C
Idea
we're
going
for
a
non-uh,
Ledger,
agnostic
and
on-prez,
which
is
you,
can
still
use
an
on
creds,
as
defined
in
the
specification
exchange
them
with
others,
but
resolve
the
objects
resolve
the
data
you
need
onto
other
ledgers,
including
I,
think
ethereum
would
be
a
great
use
case.
I,
don't
think
it's
been
done
yet
it
has
been
done
to
fabric
cardano
chat.
C
So
what
happens?
There's
basically
four
parts
to
using
an
oncreate
setup,
which
is
where
data
gets
published
from
the
issuer
to
the
verifiable
data
registry
publishes
the
public
information.
They
want
everyone
to
be
able
to
get
to
to
be
able
to
see
it
commonly.
We
use
the
term.
We
say.
Oh,
it
gets
published
to
The
Ledger,
but
the
correct
term
is
verifiable
data
registry.
So
you'll
see
me
cross
that
out
and
put
in
vdr
there,
because
it
can
be
a
lot
of
things.
It
does
not
have
to
be
a
ledger.
C
The
holder
creates
a
Link
Secret,
we'll
talk
about
that
in
the
setup
section
during
issuance
there's
a
back
and
forth
between
the
issuer
and
the
holder.
There's
actually
three
steps:
an
offer
from
the
issuer
to
the
holder,
a
request
from
the
holder
to
the
issuer,
and
then
the
issuer
creates
and
signs
the
credential
and
passes
it
to
the
holder
presentation.
C
This
can
once
a
holder
has
the
credential
in
their
wallet
in
their
in
their
secure
storage
facility.
Whatever
that
might
be,
the
holder
may
present
it
to
any
number
of
verifiers
through
any
number.
You
know
through
transactions
with
each
verifier.
During
that
it's
a
two-step
process.
The
verifier
requests
a
presentation
from
the
holder.
C
The
holder
constructs
a
presentation
with
revocation,
if
necessary,
with
proving
my
credential
has
not
been
revocated
if
necessary
and
provides
that
to
the
verifier
and
then
the
verifier
verifies
the
presentation
by
pulling
the
public
data
that
the
issue
were
published
during
setup
and
uses
that
to
verify
what
the
folder
provided
and
finally,
there's
revocation
and
that
sort
of
happens
in
a
couple
of
ways
and
we'll
talk
about
that.
But
basically,
when
necessary,
the
issuer
publishes
a
list
of
of
credentials
that
are
being
revoked
in
a
way.
C
Okay,
so
publishing
objects
involves
the
issuer.
Writing
things
to
the
verifiable
data
registry.
So
holders
not
involved
verifier
is
not
involved,
no
verifiable
credentials.
No
proofs
we're
just
writing
some
things,
including
public
keys
to
the
verifiable
data
registry,
that
we
want
everyone
in
the
world
to
see
no
private
data
at
all.
C
That's
got
to
be
super
clear,
no
private
data.
It
involves
two
step.
Two
objects:
we're
publishing
a
schema
object,
so
the
schema
object
is
a
list
of
attributes
and
I've
got
an
example
and
I'll
jump
over
to
it.
Hopefully,
that'll
work,
okay,
good,
so
this
is
I'm.
Looking
at
a
a
ledger
browser
on
the
sovereign
mainnet,
and
here
I've
got
I
just
randomly
found
a
link
to
a
transaction
that
is
a
that
is
a
schema
for
a
credential
and
those
are
the
list
of
attributes
in
this
schema.
C
C
It's
technically
not
needed
for
the
cryptography
to
work.
So
what
you'll
see
is
the
next
object
called
the
credential
definition
that
gets
created
actually
is
based
on
a
schema
object
and
imports
into
that
object.
All
of
the
attributes,
the
list
of
attributes
and
and
the
reference
to
the
schema
object
so
for
the
cryptography
for
the
actual
signatures.
C
C
We
want
to
have
the
verifier
able
to
able
to
accept
the
credential
say
from
any
University
and
it
be
in
the
same
format,
almost
no
prescribed
metadata
in
in
the
schema.
So,
for
example,
in
the
w3cbc
beta
model,
you
must
have
the
issuance
date
as
a
field
in
it,
but
there's
no
prescribed
metadata
in
in
a
a
non-pread
schema
object
in
2.0.
We
may
adjust
that
we
may
make
changes,
but
in
in
1.0
there's
no
prescribed
attributes.
C
Right
now
and
and
implementation
so
far,
there
is,
it
is
a
simple
list:
there's
no
complex
Json,
not
even
you
know,
nested
data
structures
and
so
on.
Nested
data
structures
could
be
supported
by
flattening
the
data
structure,
so
that
is
possible.
It's
not
been
done,
but
certainly
would
be
possible.
However,
Dynamic
arrays
cannot
be
supported,
and
so
that
is
something
to
understand.
C
If
you
do
need
to
support
Dynamic
arrays,
there
is
a
way
to
do
it,
which
is
you
you
basically
stringify
the
Json
array.
You
convert
it
into
a
single
element
and
use
a
data
URL
for
the
data
in
each
credential.
So
those
that
need
to
worry
about
this.
The
key
thing
is,
you
can't
have
Dynamic
arrays
in
in
a
a
non-credit
scheme
of
objects,
but
there
is
a
way
to
pass
such
data
if
that's
totally
necessary
and
if
you
need
it,
ask
ask
the
non-credits
community
and
you'll
get
help
on
them.
C
C
They,
the
credential
definition
inhales
this
the
attributes
from
the
schema
as
mentioned
it
could
be
the
issuer
that
publishes
the
same
object
or
it
could
be
someone
else
entirely
and
the
issuer
is
simply
creating
their
credential
definition
based
on
somebody
else's
schema,
and
that
would
be
a
good
thing
because
it
shows
that
people
are
sharing
schemas
and
reducing
the
effort
of
verifiers
so
list
of
attributes
yeah.
Let's
go
to
a
quick
example
again.
This
is
that
same.
C
C
This
is
the
actual
public
information
that
the
verifier
will
need
to
pull
in,
to
be
able
to
to
be
able
to
verify
the
credentials.
So
they
will
actually
pull
this
credential
definition
in
when
they
receive
a
presentation.
They
will
use
this
data
in
here
data
associated
with
each
each
element
and
cryptographic
specific
cryptographic,
values
pass
that
into
in
a
non-prez
algorithm,
and
they
will
get
back
a
verified,
not
verified
answer.
C
So
this
is
the
actual
meet
of
of
what
will
be
used
to
verify
a
credential
for
those
with
eagle
eyes,
you'll
notice
that
these
fields
are
mostly
the
same,
but
there's
an
extra
one
in
here
that
we're
going
to
talk
about
in
a
moment
called
Master
secret
everywhere
else.
It's
called
Link
Secret
because
we
wanted
to
get
rid
of
that,
but
it
has
not
been
eliminated
yet
in
the
actual
published
data
structure,
but
the
Link
Secret
is
added
to
the
credentials.
C
C
There
this
example
actually
had
revocation
supported,
so
this
is
some
information
related
to
proving,
revocation
so
there's
some
extra
data
on
there.
So
there's
Keys
public
Keys
involved
for
the
issuer
and
involved
as
well
for
revocation
with
a
published
credential
definitions,
millions
of
credentials
can
be
issued
again.
Nothing
goes
on
The
Ledger
at
issue.
Time
hope
that's
clear.
C
C
C
It
is
handled
as
a
blinded
identifier,
and
this
is
what
allows
us
to
have
no
correlatable
identifiers,
so
we
have
an
identifier
but
we're
blinding
it,
which
is
a
cryptographic
term.
That
makes
it
so
that
it
is
not
presented
to
the
verifier
as
as
the
identifier
itself,
but
rather
it's
blinded,
but
the
folder
can
prove
that
they
know
what
the
identifier
is,
that
they
uniquely
hold
the
knowledge
to
know
what
that
what
that
Link
Secret
is,
and
so
that's
how
this
occurs.
So
it
is
unlinkable
both
for
issuers
and
folders.
C
C
We're
talking
about
setup,
we're
talking
about
the
thing
called
The,
Link,
Secret,
and-
and
it
is
this
piece
of
of
data
that
is
known
that
is
known
by
the
that
is
put
into
the
credential
from
given
to
the
from
the
holder,
to
the
to
the
issuer
and
then
put
into
the
credential
and
used
to
identify
who
the
holder
is
so
hold
their
binding
issues.
Some
basics
excuse
me.
C
So
if
you
have
a
driver's
license
and
you're
presenting
a
driver's
license,
it's
obvious
to
everyone
that
the
verifier
is
expecting
that
the
subject
of
the
driver's
license
is
the
one
presenting
it,
and
so
there
needs
to
be
some
way
to
bind
the
credential
being
presented
with
the
person
or
the
entity
that
is
presenting
it
in
in
in
w3c
terms.
They
talk
about
a
subject.
The
credential
is
about
a
subject.
The
credential
is
held
by
a
holder.
So
what
is
the
relationship
between
the
subject
and
the
holder?
C
That's
known
frequently
as
the
whole
or
binding
issue
I
talked
about
it
earlier?
Is
you
want
to
prove
that
the
credential
was
issued
to
the
holder,
so
one
of
the
things
that
on
credits
does
is
it's
very
deliberate
to
say
that
a
credential
is
issued
to
a
holder
and
only
that
holder
can
present
it
in
the
w3c
BC
data
model,
holder,
binding,
is
currently
out
of
scope.
C
The
issuer
makes
temper
evident
attestations
about
the
subject
and
that's
it.
So
we
know
who
the
issuer
is.
We
know
that
the
attestations
have
not
been
tampered
with
when
they're
presented.
We
know
the
subject
identifier,
but
we
don't
know
the
relationship
between
the
holder,
the
subject
and
the
credential
and
that's
the
bigger
issue.
C
It's
up
to
the
verifier
to
do
that
binding
to
do
that.
Extra
verification.
If
it's
needed
there
are
cases
where
holder,
binding
is
not
even
needed.
Just
possession
of
a
credential
is
good
enough.
Money
is
an
example
of
that.
If
you
present
money,
you
don't
need
any
binding
to
you.
You
just
need
to
present
money.
So
it's
proof
of
possession
is
all
you
need
to
show
in
presenting
it.
C
C
The
holder
provides
that
did
and
proof
that
they
control
that
did
to
the
issuer
and
when
the
issuer
verifies
that
signature
and
inserts
that
did
into
the
credential,
so
they
they
basically
request
proof
of
control
of
some
identifier,
and
then
they
use
that
and
then
on
presentation.
The
holder
adds
a
proof
that
they
control
the
subject.
Id
did
that
is
in
the
credential,
and
that
way
the
holder
proves
that
they
control
the
bid.
It
is
in
the
dead
signed
by
the
issuer
and
on
presentation
they
prove
binding
to
that.
C
There
are
other
ways
that
it
could
be
done
as
well.
Some
mechanism
that
the
issuer
creates
some.
You
know
you
might
call
back
to
the
issue
or
to
prove
it.
You
might
have
to
present
another
piece
of
ID,
so
this
was
commonly
done
with
the
covet
credentials,
which
is
you
would
present
your
covet
credential
that
would
get
verified.
It
would
show
what
your
name
is
and
show
your
ID
your
paper
ID
as
a
way
to
prove
that
you
are
are
the
same.
C
The
subject
as
as
the
identifier
as
identified
in
the
credential,
the
VC,
could
include
a
picture
of
the
subject
it
gets
presented
and
then
that
could
be
compared
on
an
in-person
event.
So
that's
another
approach
to
doing
that,
but
there's
got
to
be
in
in
often
again
I
underline
often
and
again,
I
think
it's
a
very,
very
high
prior
percent
of
cases.
Often
the
verifier
does
need
to
know
the
holders
relationship
they're
binding
to
the
credential
they're
presenting.
C
C
Data
model
there,
where
there
is
no
formally
defined
way
to
do
holder
binding
all
folder,
all
in
on
credits,
are
issue
to
the
holder's
Link
Secret,
and
only
a
holder
that
knows
that
link
secret
can
present
the
VC
secret
for
all
credentials
they
receive
in
theory.
They
could
have
multiple
linked
Secrets,
but
whenever
they
create
wherever
they
present
credentials,
multiple
credentials
together,
they
must
use
the
same
Link
Secret.
So
if
you
get
a
credential
from
two
different
link
secrets
and
try
to
present
them
together,
it
will
be
rejected.
C
So
there
is
a
verification
that
the
any
credentials
presented
together
will
be
must
have
used
the
same
Link
Secret.
If
you
go
through
it
think
about
how
the
Link
Secret
works.
It
is
pretty
much
exactly
the
same
as
what
we
talk
about
here,
but
instead
of
it
being
a
dent
with
a
public
key
Associated
and
you
prove
a
signature
on
issuance
and
presentation.
C
Basically,
you
blind
the
the
Link
Secret
from
the
issuer,
and
then
you
present
proof
to
the
from
the
holder
to
the
issuer
that
you
know
what
the
Link
Secret
is
without
sharing
the
Link
Secret
classic
zero
knowledge
proof.
You
prove
that
you
know
the
lean
secret
without
sharing
the
Link
Secret
itself
and
then
the
issuer
inserts
the
blinded
identifier
into
the
credential
when
the
zkp,
when
the
holders
present
that
a
presentation
based
on
that
credential
they
do
the
same
thing.
C
C
Lab
one
now
we're
going
to
take
a
break
from
slides
and
we're
going
to
go
into
lab
one
and
sort
of
walk
through
that
we're
going
to
use
traction
as
I
mentioned.
Hopefully
those
that
are
joining
did
some
sort
of
preparation
break.
So
all
of
the
links
in
here
are
https
bitly
bi
b
I
t
dot,
l
y
slash
and
non-creds.
There's
a
prep
one,
there's
a
Labs
one
and
then
the
other
labs
are
like
that.
C
So
that's
what
we're
going
to
do
now,
I'm
going
to
I'm
going
to
do
this,
so
those
who
didn't
do
the
prep
or
anything
can
just
follow
along,
but
I'm
going
to
walk
through
the
steps.
Hopefully,
I
don't
often
use
a
wallet
on
my
on
my
device,
but
hopefully
that's
there.
So
I
am
yeah
good.
So
this
is
the
traction
product.
So
traction
we
didn't
want
to
bury
people
down
and
using
a
CLI.
C
You
know
a
command
line
interface
for
doing
this
or
or
getting
spinning
up
their
own
indie
or
Aries
agent,
or
anything
like
that.
So
this
traction
is
a
multi-tenant
instance
of
an
Aries
agent
that
provides
a
user
interface
and
an
API
for
managing
multiple
agents
within
a
single
instance.
So
everyone
is
using
the
same
instance
subtraction
to
this
URL
and
then
everyone
has
a
tenant
and
everyone
that's
done.
C
The
setup
has
a
10
within
it
and
that
gives
them
this
interface
that
allows
them
to
do
a
bunch
of
things
related
to
issuing
setting
up
issuing
and
verifying
presentations.
So
that's
what
we're
going
to
use
for
this
over
here
I
have
my
wallet.
I,
have
my
machine
or
my
my
smartphone
and
I've
got
the
BC
wallet?
C
I've
got
orbit
wallet
installed
as
well,
and
so
I'm
going
to
go
through
and
do
this
now
in
this
case,
I
don't
need
the
wallet
because
we're
not
going
to
get
involved
in
that
because
we're
just
doing
setup
right
now,
so
I,
don't
know
why
I
just
activated
that,
but
I
did
okay.
So
the
way
we
do
this
is
so
we
have
a
setup
by
the
way
I
have
connections
created.
C
So
I've
got
my
BC
wallet
connection
and
my
Orbit
connection
and
I'm
going
to
do
a
configuration
I'm
going
to
set
up
a
new
schema
and
so
there's
instructions
in
the
lab.
What
to
do
I
recommend
following
along
for
the
first
one,
using
exactly
what
we
provide,
because
it
makes
doing
the
presentation
easier
but
feel
free
to
make
whatever
schemas
you
want.
C
And,
however,
you
want
to
do
it
so
I'm
going
to
do
a
schema
name
called
student
ID
I'm
going
to
use
1006,
because
I
can't
remember
how
many
times
I've
tried
in
the
past
just
to
make
sure
and
I'm
going
to
use
a
handful
of
of
fields.
I'm
just
going
to
create
four
Fields,
so
I'm
going
to
have
a
given
names,
family
name.
C
C
So
when
we
present
I'll
be
showing
the
format
of
that
expiry
is
the
same
sort
of
thing
so
I'm
going
to
create
that
schema
and
that
schema
is
out
there
106..
So
I
can
look
at
the
details
of
that.
So
I
expand
down
here
and
view
the
raw
content
and
I
can
see
when
it
was
created.
The
schema
ID.
This
is
the
did
of
the
issuer
me
here.
I've
got
my
student
ID
name
and
the
version
again
I've
got
the
same
sort
of
information
in
here.
C
C
So
I've
now
created
that
the
thing
I
need
to
do
now
is
so
that's
step.
One
I've
created
the
object.
I've
published
it
step
two
is
to
create
the
credential
definition.
That's
kind
of
funky,
but
I'll
click
on
that
to
create
the
credential
definition
here,
I'm
going
to
use
the
student
ID
schema,
so
it's
referencing,
the
particular
schema,
and
here
I'm
going
to
call
it.
C
You
have
Steven
three,
because
I
think
I've
used
one
and
two
just
to
be
sure
I'm
not
going
to
invoke
ad
revocation,
but
this
is
how
you
would
do
it
add.
Revocation.
You
would
also
be
asked
the
number
of
credentials
we'll
talk
about
that
per
revocation
registry,
we'll
talk
about
that
in
the
replication
section,
so
for
now
we'll
create
without
revocation
and
we'll
hit
create.
C
This
is
actually
the
most
intense
part
of
the
the
definition
we're
generating
a
bunch
of
large
data,
so
that
credential
definition
has
been
created
by
the
Inon
credits,
library
and
now
it
is
being
published
to
in
this
case,
in
Indie
Network,
and
if
I
look
over
here
now,
I
have
it
published
on
it
and
I've
got
a
link
and
an
identifier
for
it.
So
I've
published
my
credential
definition.
I
can
actually
look
over
here
and
see.
I've
got
that
credential
definition
I
created
it
at
nine
o'clock
today.
C
C
C
Okay,
that's
it
for
this!
That's
all
we're
gonna
do
for
now.
That
is
what
it
takes
to
prepare
to
issue
a
verifiable
credential,
there's
a
bunch
of
of
stuff
going
on
here.
The
biggest
thing
here
is:
you
need
a
an
interface
to
whatever
vdr
you're
using
and
we're
gonna
you've.
Seen
now
an
example
of
using
Indie
for
that
later,
on,
Rodolfo
is
going
to
present
using
cardano
after
that,
Patrick
is
going
to
show
using
did
web
so
using
just
a
web
server
to
do
that.
C
C
Of
it,
I
will
leave,
say
two
minutes
or
any
questions
that
we
might
want
to
go
over
and
let
people
run
the
lab
themselves,
walk
through
those
simple
steps
and
ideally
create
a
second
one.
A
second
schema
so
that
when
you
comes
time
to
do
a
presentation
request,
you
can
build
your
own.
That
has
multiple
credentials
involved.
C
A
C
Okay,
Ed
in
answer
to
your
question,
I
think
the
decision
to
separate
Prudential
and
schema
was
in
this
idea
that
a
schema
can
be
shared
and
the
idea
is.
You
want
communities
to
coalesce
around
a
particular
schema
and
then
all
of
them
issue
the
same
schema
they,
but
they
would
have
their
own
data.
They
would
use
the
schema
in
the
way
they
they
found
needed,
but
they
would
use
a
common
one
to
make
it
easier
for
verifying
credentials
that
come
from
all
of
the
issuers
in
a
community.
C
So,
for
example,
in
Canada
we
did
a
lot
of
work
as
actually
Dave
bixby's
on
this
call
I've
seen
him
comment:
did
a
ton
of
work
with
the
folks
from
Quebec
and
Ontario,
and
some
people
there
that
came
up
with
a
common
person
schema
with
the
idea
that
it
would
be
used
across
Canada.
All
of
the
provinces
would
issue
a
person
credential
and
then,
and
so
there's
a
set
of
rules
on.
C
C
C
A
schema
must
have
an
Associated
publisher,
ID,
which
is
usually
a
did
certainly
on
Indie.
Yes,
it
did,
and-
and
that
is
usually
checked
so
again-
the
permissioned
writing
rules
of
Indy
requires
that
the
the
the
publisher
have
be
allowed
to
write
to
The
Ledger,
and
so
there
has
to
be
a
data
associated
with
the
schema.
There
must
also
be
an
ID
associated
with
the
credential
definition,
and
this
is
how
you
know
who
the
issuer
is.
The
ID
associated
with
the
credential
definition
used
for
the
credential.
C
C
So
it
is
actually
a
three-step
process
in
in
the
non-creds,
which
is
slightly
different
from
things
like
open
ID
for
VCS,
which
is
it's
a
two-step
process
here
it
is
a
three-step
process
so
for
those
that
are
jumping
into
you,
you
know
we
are
going
to
be
having
parts
of
the
community
to
develop
open
ID
for
VCS
using
and
on
creds.
That
will
be
an
interesting
component
of
it
is
getting
that
three-step
process
so
three-step.
C
Called
an
offer,
it
goes
from
the
issuer
to
the
holder
and
it
says:
here's
the
type
of
credential
I'm
going
to
issue,
here's
a
key
correctness:
proof
on
that
and
here's
a
nonce
a
a
thing
to
prevent
a
replay
attack
for
the
issuer,
so
that
and
and
that
can
be
used
for
non-correlatability.
So
an
offer
provides
some
cryptographic
material
from
the
issuer
to
the
holder
to
say:
here's
what
I'm
going
to
present
for
you,
then
the
holder
does
a
request
to
the
issuer.
C
This,
in
is
where
the
blinded
Link
Secret
is
passed
and
they
keep
correctness
proof
about
the
Link
Secret
has
passed
so
that
the
whole
issuer
knows
that
the
holder
knows
the
Link
Secret
that
the
blinded
Link
Secret
was
derived
from
the
lane
secret.
But
the
holder
doesn't
tell
the
Link
Secret
to
the
issuer.
They
keep
it
secret.
No,
One,
Ever
Knows,
the
Link
Secret,
is
the
holder
needs
to
keep
that
secret.
C
C
Protocol
so
obviously
there's
a
three-step
process
and
non-pres
itself
defines
how
to
generate
an
offer,
how
to
process
a
request
or
to
generate
and
process
a
request
and
how
to
issue
the
credentials.
So
the
Anon
credits
code
simply
executes
these
steps.
When
asked
given
the
proper
inputs,
there
has
to
be
a
way
for
the
various
inputs
to
be
passed
between
the
issuer
and
the
holder,
the
holder
to
the
issuer
and
the
issuer
to
the
holder.
That's
the
protocol.
Step
of
this
Aries
uses
a
specific
issue,
credential
protocol,
which
encapsulates
all
of
these
steps.
C
C
I
did
come,
so
it
is
built
on
top
of
didcom.
So
it's
using
a
message.
A
messaging
protocol
called
VidCon.
Hopefully
most
many
are
aware
of
that.
But
again,
that's
not
the
focus
of
this
of
this
Workshop,
so
we
won't
go
deeply
into
that,
but
divcon
basically
allows
two
parties
to
send
messages
back
to
each
other
back
and
forth,
so
similar
to
Signal
or
or
telegram.
It
is
a
messaging
protocol.
It
is
a
dent
based
messaging
protocol.
Hence
the
name
did
come
and
it
provides
end-to-end
encryption.
C
C
The
RFC
453
has
some
additions
to
it
that
aren't
that
go
beyond
the
three-step
process
for
an
on-preads.
There
can
be
a
proposal
that
allows
the
holder
to
initiate
the
process,
so
the
holder
sends
a
proposal
which
is
followed
by
an
offer
request.
An
issue
also
allows
for
negotiation.
The
issuer
sends
the
holder
an
offer,
and
the
holder
says:
that's.
B
C
Interesting
but
I'd,
rather
you
issued
me
this,
and
so
it
sends
back
to
the
issuer
a
proposal
and
then
the
the
holder
goes
forward
with
that
and
then
the
offer
also
includes
other
things.
So
the
offer
may
include
the
actual
data
that
will
be
issued.
So
if
the
holder,
if
prior
to
issuance
the
issuer,
wants
the
holder
to
see
the
data,
they
can
pass
that
in
the
offer
and
that's
not
needed
by
an
odd
creds.
But
it's
useful.
It's
part
of
the
user
experience
in
doing
that.
C
C
C
So
that's
what
a
credential
looks
like
I'm,
going
to
show
you
a
transition
of
this
information
into
a
w3c
formatted
later,
so
we're
actually
going
to
take
this
data
model
and
convert
it
to
match
exactly
the
w3c
data
model.
But
this
is
what
was
defined
seven
eight
years
ago
in
the
and
on
credits
initial
and
on
credits.
Work
of
what
a
credential
would
look
like
in
Enon
crits
data
model.
So
that's
out
of
for
interest
notice.
C
C
So
remember
what
I
said
that
what
actually
gets
signed
in
a
verifiable
in
a
non-credits
credential
is
encoded
is
the
encoded
value
is
a
number,
and
so
what
we've
got
to
do
is
represent
the
raw
value
as
a
number
and
that's
what
gets
signed
so
Alice
Jones
never
gets
signed.
It's
the
encoded
value
that
gets
signed.
The
rules
are
dead,
simple.
If
it's
an
unsigned
integer
or
an
integer
string,
it's
left,
as
is
so.
If,
if
it's
a
number
it's
left,
as
is
everything
else,
is
stringified
and
Shaw
256
hash
into
an
integer.
C
C
C
It
allowed
the
issuer
to
define
the
canonicalization
method
they
used,
so
they
could
use
other
rules
here
and
that's
not
ideal,
because
the
verifiers
have
to
know
what
rules
they're
following
to
be
able
to
use
the
credential
and
the
verifier
must
check
that
the
encoding,
the
coded
values
are
properly
encoded.
So
this
actually
is
a
an
issue
that
the
folder
could
exploit.
C
A
folder
could
put
Dave
Jones
in
here
and
if
the
verifier
doesn't
check
that
the
encoding
has
been
done
properly,
they
might
see
that
the
signature
is
correct
on
the
encoded
value,
but
not
might
not
notice
that
the
raw
value
is
different
from
what
was
encoded.
So
there
is
a
verification
that
the
encoding
is
done
properly
in
the
future.
C
B
C
And
let
me
get
back
to
seeing
my
wallet
and
seeing
my
traction
so
I've
got
my
instant
subtraction
I'm,
going
to
go
to
the
issuance
and
I'm
going
to
offer
a
credential,
so
the
offer
credential
in
this
case
is
I.
I
have
I
have
a
connection.
So
actually
let
me
jump
back
to
that.
So
I've
established
connections
previously
to
my
BC
wallet
into
my
Orbit
wallet
I
could
use
either
of
them
orbit
is
from
northern
block.
There's
a
link
in
there.
That's
how
to
get
it.
C
So
I've
got
a
connection
previously
I
established
that
by
creating
an
invitation
giving
it
Alias
to
it
and
then
generating
a
a
QR
code
that
can
be
used
to
connect
to
it
so
that
established
the
connection
between
the
wallet
and
traction.
So
I
now
have
a
relationship.
I've
used
VidCon
to
establish
a
relationship
between
this
Enterprise
application
and
a
particular
wallet.
My
particular
wallet,
so
I've
got
that
connection.
C
C
C
So
again,
I'm
using
this
format,
I'm
a
Young
University
student
I'm,
going
to
put
in
my
name
and
my
family
name
now.
Obviously
this
is
not
how
you
would
normally
issue
credentials
so
traction
or
any
other
application.
Enterprise
application
you
use
has
an
API
that
allows
you
to
interface
with
back-end
systems
that
contain
the
information
you
want
convey.
C
So
you
know
you
establish
a
connection,
you
do
some
verification
of
who
the
person
is,
and
then
you
issue
a
credential
and
that's
going
to
be
done
through
some
program
that
uses
an
API
to
send
out
this
data.
It's
not
gonna
you're,
not
gonna
type
it
in
yourself,
but
you
can
so
I'm
now
going
to
look
at
that,
so
my
data
values
are
entered.
They
look
like
that.
I
can
adjust
them
if
needed
and
then
I'm
going
to
send
the
offer
I'm
going
to
jump
over
and
I've
got
a
new
credential.
C
C
Also,
look
these
fields
are
pretty
ugly
dob
capitalize
date,
int,
not
nice,
but
we're
going
to
show
a
way
to
make
that
much
better
but
we'll
get
to
that
later.
But
the
data
is
what
I
suggested
I
would
be
offering
I
keep
wanting
to
use
the
most
to
move
that,
but
I've
got
to
do
this
on
on
screen,
so
I
have
the
option
of
accepting
or
declining
so
I
accept,
and
now
I've
got
my
credential
in
my
wallet.
So
there's
my
list
of
credentials,
I
can
look
at
it.
C
C
Got
my
credential
and
that
is
issuing
so
what
happened
as
I
mentioned
was
there
was
a
back
and
forth
the
offer,
went
that
triggered
the
pop-up
and
the
decision
to
be
made
in
the
wallet
of
what
I
want
to
do
with
it
once
I
said,
accept
it
fired
over
the
request
for
the
credential
traction.
This
traction
instance
signed
the
credential
prepared
and
signed
the
credential
using
the
private
key
associated
with
the
credential
definition,
so
they
use
the
private
information
to
sign
it.
C
C
C
C
So
how
many
DBS
and
networks
are
you
using
for
this?
So
everyone
is
sharing
the
same
instance
of
traction
whoops,
that's
not
gonna,
do
it.
So
this
everyone
has
everyone
that's
running.
This
is
using
the
a
single
instance
of
it's
running,
Aries,
Cloud
agent,
python
underneath
and
this
traction
UI
and
API
on
top
and
then
we're
using
a
single
ledger
to
be
Sovereign.
Ledger.
C
C
C
All
right,
we've
got
two
more
brief
parts
to
go
and
then
we'll
have
a
break
I'd
like
to
get
going
on
that.
So
we've
done
issuing
so
now,
we've
taken
care
of
writing
we've
taken
care
of
issuing.
We
have
a
verifiable
credential,
as
noted
when
we
did
that
it
was
strictly
an
issuer
to
folder
interaction.
There
was
no
nothing
written
to
The
Ledger
as
as
a
result
of
issuing
that
credential,
and
that
is
definitely
what
we
want.
We
want
no
data
associated
with
holders
to
go
on
the
verifiable
data
registry.
C
We
only
want
public
information,
non-correlatable
public
information
that
you
want
everyone
to
see
to
be
able
to
do
it.
There
is
correlatable
data
about
the
issuer
and
that
gets
into
some
interesting
things
like
what.
If
this
issuer
is
a
person
that
does
get
into
the
potential
of
of
how
you
would
do
that
and
where
you
would
want
to
do
that.
That
would
give
correlatable
identifier
if
this
issuer
is
a
person
or
sorry
it
gives
correlatable
identifier,
regardless
of
who
the
issuer
is.
C
So
now
we
get
into
the
next
step
of
presentation
again
fairly
straightforward.
Now
we're
we've
eliminated
the
issuer
from
the
picture.
Don't
care,
we've
got
the
holder,
approver
and
we've
got
the
verifier
involved
in
this.
The
verifier
is
going
to
read
off
the
verifiable
data
registry
in
order
to
verify
the
credential,
but
they
are
not
going
to
contact
the
issuer.
They
may
trust
the
issuer,
but
they're
not
going
to
contact
or
or
have
any
interaction
with
the
issuer.
C
C
C
It
just
is
some
sort
of
we
want
to
convey
from
the
verifier
to
the
holder
what
data
is
needed.
Ideally,
the
verifier
is
respecting
privacy
and
requesting
only
the
absolute
minimum
they
need,
and,
and
so
and
and
again,
because
they're
receiving
verifiable
data
they're
motivated
not
to
collect
toxic
private
data,
they
don't
want
to
collect
any
more
than
they
need
to
in
this
back
and
forth
that
I
show
here,
the
red
are
sort
of
outside
the
realm
of
anon
creds.
C
C
Holder
constructs
a
presentation
based
on
what
credentials
they
have
and
the
cryptography
is
verified,
looks
like
I
screwed
up
in
adjusting
this
and-
and
you
can't
see
all
the
words
I'll
fix
that,
but
the
holder
constructs
the
presentation
based
on
the
credentials
that
satisfy
what
the
verifier
is
asking
for
and
then
after
it,
the
cryptography
is
verified
in
the
presentation
by
the
verifier
note
that
the
verified
credentials
are
not
given.
The
presentation
is
derived
from
the
source
credential.
C
This
is
different
from
other
some
other
credential
methods
in
in
in
the
basic
and
up
until
Monday.
In
the
data
Integrity
proofs
that
are
used
by
the
w3c
community,
the
actual
credential
is
passed
from
the
holder
to
the
verifier,
along
with
some
extra
information
in
in
the
case
of
an
on
creds.
That
is
not
the
case.
The
verifiable
credentials
are
held
by
the
holder
and
not
given
to
the
verifier.
C
C
The
request
is
centered
via
some
protocol.
Some
interaction
to
the
holder,
the
holder,
uses
the
presentation
request
to
search
through
their
wallet
to
find
the
credentials
that
satisfy
that
proof.
Once
they
have
those
credentials,
they
pass
the
credentials
plus
the
presentation
request
to
an
on-preads
which
generates
the
proof
it
does
all
of
the
math
and
so
on.
C
That
presentation
is
then
sent
over
to
the
verifier.
The
verifier
present
processes
that
using
it
on
credits
code.
So
again
it
passes
the
presentation
plus
the
request
over
to
to
the
inocrates
library
which
processes
it
and
verifies
it,
and
then
the
verifier
should
do
business
rule
validation
after
so
there
might
be
some
additional.
So
this
all
this
does
is
says
that
a
cryptographic
verification
checked
out
the
the
cryptography
that
was
included
in
the
presentation
worked.
C
C
Res
request,
presentation
components:
this
is
the
trickiest
part
of
the
lab.
I
may
We've
the
folks
that
that
Implement
traction
made
it
easy
for
us.
If
you
use
the
same
credential
that
I
used
and
suggested
use
in
lab
one,
it
would
be
easy
to
do
a
presentation
request,
but
we
don't
have
a
builder
a
presentation,
request
builder
at
this
point,
so
you
got
to
be
playing
with
Json,
so
requested
data.
You
can
request
attributes
which
are
groups
of
attributes
from
a
single
Source
credential.
C
So
you
can
request
multiple
sets
of
attributes
and
each
set
must
come
from
a
single
Source
credential
as
well.
You
can
request
predicates
in
each
predicate.
Is
a
True
Value,
true
false
numeric
expression
on
a
single
attribute
so
built
from
a
combination
of
an
attribute,
a
value
and
an
operator
that
checks
the
relationship
between
them.
The
only
operators
that
can
be
used
are
these
ones,
so
predicates,
I'm,
now
sort
of
lowering
the
bar
of
what
you
can
do
with
predicates
must
be
an
integer
and
must
use
relationships
like
this.
C
So
there
are
relatively
limited
use
cases
for
them,
but
the
big
one
is
a
crucially
important
one,
which
is
older
than
dates,
expiry
amount
of
say,
amount
of
money
in
a
bank
account.
So
there
are
a
bunch
of
ones.
The
date
ones
are
are
crucial
because
dates
become
quickly
become
correlatable
identifiers.
If
you
can
combine
a
date
of
birth
with
any
almost
any
other
personally
identifiable
data,
you
wind
up
getting
a
unique
identifier
for
a
person,
and
so
that's
why
these
predicates,
while
Limited
in
function
are,
are
pretty
important.
C
So
you
can
put
revocation
on
a
certain
credential
or
a
certain
set
of
attributes
that
will
be
satisfied
by
a
credential
or
across
all
of
them
and
and
you
can
use
a
time
period
for
those.
So
you
can
say:
hey
was
your
credential
valid
on
June
26th
when
the
accident
occurred?
So
this
is
a
back
in
time
proof
that
your
your
credential
was
valid
I'm
offline.
C
C
C
Those
not
familiar
announced
is
for
preventing
replay
attacks
so
that
somebody
listening
in
on
a
conversation
between
a
holder
and
a
verifier
could
grab
the
presentation
request
and
then
use
it
as
their
own.
By
doing
by
putting
in
knots
in
the
request,
it
makes
the
presentation
from
the
folder
completely
unique
and
can't
be
reused,
requested
attributes.
These
are
the
arrays,
so
I'm
saying
I
want
student
information
to
the
given
name
and
family
name.
C
I
could
have
multiple
of
these
when
I'm
requesting
multiple
credentials
and
then
the
Restriction
is
where
I
specify
what
credential
I'm
permitting
it
to
come
from,
and
then
a
predicate
here,
I'm
saying
I
want
to
check
on
expiry
and
I
want
I'm
using
today,
essentially
a
few
days
ago
when
I
wrote
this
and
the
and
the
relationship
is
greater
than
so
and
again,
I'm
going
to
use
this
same
restriction.
So
I'm
going
to
pull
an
expiry
date
and
I'm
going
to
check
that
as
of
today,
it
is
not
expired.
C
C
It
could
have
a
certain
schema
name
and
you
can
have
a
certain
schema
version,
so
you
can
use
any
combination
of
these
and
then
likewise.
So
that's
all
based
on
the
schema,
you
can
restrict
it
to
a
specific
identify
issuer,
a
specific
credential
definition,
so
you
can
restrict
it
to
the
certain
issuer
of
a
certain
schema,
and
then
you
can
also
say
this.
The
Prudential
must
have
a
given
attribute
name
and
a
the
credential
must
have
a
given
attribute
name,
and
it
must
have
this
particular
value
in
it.
C
So
you
could
do
something
like
saying.
Oh,
you
know
a
a
passport
that
has
a
a
credential
attribute,
Province
and
value
British
Columbia.
So
you
can
say:
oh
I
only
want
to
allow
people
to
prove
using
their
passport
and
and
that
are
from
British
Columbia,
for
example.
So
the
ands
and
the
ORS
are
here.
You've
got
ands
across
the
group
and
you've
got
an
or
here
so
you
can
use
that
for
reference.
If
you
need
it
later,
data
predicates,
as
mentioned
I've
gone
through
this
a
few
times
either
date.
C
Int
is
the
common
way
to
do
dates.
So
this
and
there's
your
comma
representation
of
that
or
you
can
use
Unix
time
is
a
good
way
to
do
this
as
well.
So
this
is
the
Unix.
Time
is
the
number
of
seconds
that
have
passed
since
January
1st
1970.,
so
that
is
when
this
Workshop
started
this.
This
was
the
value
of
Unix
time
at
that
this
is
what
it
actually
looks
like
and
again.
Example.
C
Here's
an
example
of
not
expired.
Here's
an
example
of
older
than-
and
it
just
shows
you
which,
which
expression
to
use
so
both
of
these
represent
this
represents
19
years
ago
today.
This
represents
today,
and
then
this
tells
you
what
which
p-value,
which
P
type,
which
expression
which
logical
expression
do
you
use,
does
not
work
with
a
string
date.
I
think
I've
said
that
enough.
C
They
search
in
their
Secure
Storage
their
wallet
for
credentials
to
satisfy
the
request
so
there's
basically
a
mechanism
that
is
not
officially
part
of
an
on-preads
that
can
be
used,
but
basically
it's
up
to
the
implementation
to
find
all
of
the
source
credentials
that
satisfy
each
attribute
group
and
predicate
they
may
come
from
the
same
credentials,
so
you
may
have
multiples
coming
from
the
same
credential.
That's
perfectly
valid.
C
If
you
have
not
found
if
there's
none
found
or
if
multiple
credentials
are
found,
business
logic
would
dictate
what
to
do
so.
You
could
automatically
send
the
latest,
so
you've
got
two
credentials
that
satisfy
send
the
latest
one
or
you
could
pop
up
a
message
to
the
user.
Saying
hey,
you've
got
two
credentials
that
satisfy
this,
which
one
do
you
want
to
use
in
this
case,
so
business
logic
would
dictate
how
you
deal
with
multiple
credentials
that
deal
with
it.
C
You
may
need
to
get
credential
definition
and
revocation
registry
data.
In
case
the
presentation
has
to
prove
non-revocation
and
then,
with
all
of
that
data
in
hand,
you
pass
it
to
an
on-credits
library
and
you
generate
a
presentation
from
the
request
and
Source
credentials.
Basically,
it
creates
one
proof
for
every
Source
Prudential
one
presentation
for
every
Source
credential
and
then
after
it
does
that
it
would.
It
includes
that
includes
a
proof
across
all
the
encoded
attributes.
C
It
shares
the
raw
values
that
are
being
revealed,
the
to
the
verifier,
a
not
a
proof
of
non-revocation
is
generated,
and
then
a
proof
per
predicate
is
produced
from
The
Source
credentials.
So
if
I
have
a
a
date
of
birth
and
an
expiry
one,
both
of
those
would
be
generated
and
attached.
So
you
may
have
up
to
four
proofs-
or
you
know
up
to.
C
You-
may
have
many
presentations
across
this
one
for
all
of
the
attributes,
one
for
the
non-revocation
proof
and
then
one
for
as
many
predicates
that
have
as
are
being
asked
for
and
that's
each
Source
credential
and
then.
Finally,
there
is
an
aggregate
proof
across
all
the
credentials
that
verifies
that
the
same
Link
Secret
is
used
for
all
of
the
source
credentials
that
have
been
provided.
So
that's
one
extra
proof
that
is
included
in
the
presentation.
C
C
Next,
we
had
we
verify
again
in
and
on
credits
was
the
presentation
request
satisfied
so
cryptographically
they
may
have
given
us
a
totally
different
presentation
unrelated
to
the
presentation
request,
so
we
want
to
make
sure
that
all
of
the
groups
were
satisfied.
The
revocation
intervals
were
satisfied
and
so
on.
So
this
is
more
a
logic
check.
The
cryptography
has
been
checked
now.
We're
checking
that
the
presentation
request
was
adhered
to.
C
Next,
we
may
have
more
verification
done,
in
particular,
in
the
agent
framework,
verification
of
the
presentation
against
the
request,
unrevealed
attributes
raw
values,
other
things
there
and
then.
Finally,
the
thing
I
wanted
to
underline
most
importantly,
business
logic.
I've
done
cryptographic,
verification,
but
is
the
presentation
sufficient
for
the
business
purpose
and
the
most
common
one?
There
is.
C
If
we
specify
if
we
want
to
get
a
education
credential
from
any
University
in
the
world,
we're
going
to
request
certain
a
certain
schema
or
certain
attributes
be
included,
but
we
are,
we
won't
know
until
we
get
the
presentation
to
the
actual
issuer
is
and
as
a
result,
we
may
then
want
to
find
out.
Oh
have
I
ever
heard
of
this
University
and
do
I
trust
this
University,
and
so
that's
where
we
wind
up
with
a
business
logic
decision.
Do
we
accept
this
presentation
for
the
purpose
of
the
business.
C
Press
the
issuer
handling,
oops
I
just
did
all
this
pre-verification
by
putting
it
into
the
presentation,
request
or
post
verification,
and
that
may
be
done
through
a
local
list
built
into
the
application.
It
may
be
based
on
a
trust
registry
you're,
going
to
contact
a
service
that
says:
oh
here's,
the
issuers,
you
can
trust
and
here's
the
identifiers
and
the
issuers
you
can
trust
or.
C
C
C
Let's
get
my
things
up
here
so
this
time
in
we're
going
to
the
verification,
we're
going
to
create
a
presentation
request.
I
have
made
it
so
that
this
default,
one
that
it
shows
here
it
matches
exactly
my
example.
So
I've
I've
got
a
proof
request
I'm
going
to
put
a
non-sanal
change
yet
put
a
bunch
of
numbers
in
I
want
it's
version.
C
One
of
this
proof
request
again:
that's
just
a
user
setting
I'm
going
to
want
student
info
attributes
called
this,
and
it's
got
to
come
from
a
schema
with
a
schema
name,
student
ID
and
then
I'm
going
to
check
an
expiry
date,
I'm
going
to
make
sure
that
the
credential
has
not
expired.
As
of
today.
So
I'm
going
to
change
this
value
to
yeah,
oh
531,
and
again
it's
going
to
come
from
the
same
credential
I'm.
C
Connection
to
send
it
to
I'm
going
to
send
it
to
the
BC
wallet
I.
Don't
think
this
does
anything.
Yet
this
is
being
worked
on
right
now
and
by
the
bcgov
team,
but
I'm
going
to
add
a
comment
to
it:
Workshop
ER
presentation,
request
and
now
I'm
going
to
submit
that
and
over
here
up
Pops
a
notification
that
I
have
a
presentation,
a
proof
request.
C
C
B
C
B
C
C
C
C
C
C
So
the
question
from
Stefan
about:
why
does
the
presentation
include
the
not
shared
data
that
is
to
show
that
is
a
blinded
verifier?
So
there's
no
way
to
to
derive
the
data
from
that,
but
it
shows
that
the
signature
is
valid,
so
it
is
used
to
verify
you
basically
are
sending
enough
information
to
verify
the
entire
credential,
but
you're
only
revealing
certain
attributes.
C
There
is
actually
a
feature
in
an
oncrets
where
the
holder
can
choose
to
not
share
a
piece
of
data,
so
the
presentation
request
comes
across
the
verify
or
the
a
holder
generates
a
presentation
and
says:
I
don't
want
to
or
sorry
gets
the
offer
says.
I
don't
want
to
reveal
my
last
name
generation
is
done
and
that's
not
revealed,
but
it's
still
verified
so
that
data
still
goes
back
to
be
verified.
A
Also,
we
are
live
streaming
this
and
it
will
be
on
the
hyperledger
YouTube
If,
like
Dave
Bixby,
has
to
split.
He
can
catch
up
with
what
happened
after
he
leaves
it'll,
be
on
YouTube
a
little
bit
later
today
and
all
the
decks.
The
lab
documents
are
on
the
Wiki
page
and
I'm,
going
to
post
links
again
in
a
second.
B
A
C
Yep,
so
that
is
to
enable
verification
of
the
full
credentials
so
make
sure
you're
sharing
the
proper
credential,
but
it's
the
signature
can
be
verified
across
the
entire
Prudential,
even
though
you
are
not
revealing
the
actual
value.
There's
no
way
to
use
the
information
to
share
to
to
derive
the
value,
so
that
is
not
a
hash
of
the
date
of
birth
or
something
like
that.
It
cannot
be
derived
from
it.
A
We
don't
want
to
lose
these
questions
and
the
answers
are
fantastic
and
thanks
again
to
all
the
the
folks
on
the
workshop
who've
been
pitching
in
and
helping
out
answering
some
questions
for
folks
who
are
new
or
or
getting
up
to
speed
on
on
a
non-creds.
This
has
been
great,
so
Marco
try
I
can't
do
it
right
now.
Live
we're
not
using
the
webinar
features
to
zoom
today,
but
we
will
get
that
posted
to
the
Wiki
page
and
the
link
to
the
Wiki
page
is
right
above
your
comment.
C
Let's
go
okay,
I'm
going
to
talk
about
revocation
Break,
briefly,
first
as
the
next
topic,
so
there's
no
lab
associated
with
this,
but
we'll
just
go
through
it.
So
revocation
involves
a
couple
of
things:
one
is
the
issuer
deciding
it
needs
to
revoke
the
credential,
so
it's
issued
a
credential.
It
decides
hey
I
need
to
revoke
it
for
some
reason
and
it
writes
revocation
data
to
the
registry
and
then
during
the
holder,
verifier
holder,
verifier
event,
the
presentation
request
and
the
presentation,
a
proof
of
non-orification
is
generated.
C
C
So
why
would
an
issuer
decide
to
revoke
a
credential
main
thing?
A
very
common
use
case
is
the
data
is
no
longer
accurate,
so
automatically
you
think.
The
easiest
and
most
obvious,
is
something
like
you've
got
an
address
in
the
data
and
that
you
change
the
address
anything
in
the
credential
has
changed.
Any
material
data
has
changed
according
to
the
issuer.
They
decide
they
want
to
revoke
and
possibly
reissue
the
credentials.
So
that's
one,
the
holder's
authorization
to
use
the
credential
has
changed.
C
This
is
the
one
people
automatically
think
of
because
they
think
of
revocation
as
somebody's
done
something
bad
and
they
need
to
take
things
away
from
them.
So
if
it's
a
driver's
license
and
the
driver
is
no
longer
allowed
to
Drive
they've
lost
their
driver
privileges,
the
the
issuer
would
revoke
it.
That
actually
is
just
an
example
of
the
data
of
data
change.
C
So
it's
a
much
broader
category
than
you've
done
something
bad
and
we
need
to
take
it
away
and
then
the
other
one
that
is
interesting.
That
people
forget
is
we're
not
always
perfect.
We
don't
always
issue
the
a
credential
correctly,
and
so
this
is
one
I
I
got
made
aware
of
this
by
a
government
person.
That
basically
said
well,
sometimes
mistakes
happen
and
we
always
need
a
way
to
correct
them,
and
so
that
makes
it
almost
any
credential
needs
this
ability
to
be
revoked.
C
C
Replication
is
a
unilateral
action
by
the
issuer.
There's
no,
there
need
not
be
any
involvement
of
the
holder.
The
issuer
just
says:
I'm
revoking
this
end
of
story
and
they
revoke
it.
They
take
the
action.
There
may
be
a
notification
to
the
holder.
There
may
be
even
a
notification
that
says:
hey
you
can
get
a
new
credential
and,
and
then
you
go
through
that
process
to
issue
a
new
credential
to
the
holder.
C
C
Nobody
is
going
to
trust
that
nobody
trusts
email
and
SMS
for
those
types
of
things
with
VidCon.
You
actually
have
a
trusted
channel
for
messaging
between
an
Enterprise
and
their
customers,
and
we
think
that's
a
really
important
part
of
VidCon
separate
from
the
non-creds
in
the
topic,
but
that
is
this
is
one
really
good
example
of
why
having
a
lasting
connection,
a
relationship
between
the
issuer
and
the
holder
can
be
helpful.
C
In
some
cases
the
verifier
can
revocate
verifier
can
detect
revocation
in
subsequent
presentations.
So
the
revocation
is
published
by
the
issuer
and
then
the
verifier
goes
to
present
a
credential
in
the
future
they
can
detect.
The
the
verifier
can
detect
can
see
that
the
revocation
has
been
made,
that
the
credential
is
no
longer
a
valid
credential.
C
The
verifier,
the
holder,
can
still
produce
a
presentation
and
can
pass
it
along,
but
the
verifier
will
know
it's
been
revoked.
That's
the
key,
depending
on
the
revocation
scheme
and
I'm
talking
in
general,
across
an
on
creds
and
other
verifiable
credential
formats,
a
verifier
may
be
able
to
Monitor
revocations,
and
this
is
a
bad
thing.
We
think
we
think
this
is
a
bad
thing.
Some
it
can
be
a
feature
in
some
use
cases,
but
in
general
it's
a
bad
thing
which
is
I.
Give
you
my
identifier
for
my
credential.
C
C
C
C
That's
what
we
want
to
avoid,
and
so
what
is
done
is
a
an
accumulator
based
non-revocation,
zero
knowledge.
Proof
is
generated.
So,
there's
a
little
bit
here
about
how
that
happens:
I'm
not
going
to
get
into
that.
I.
Don't
think
in
this
in
this
situation
glad
to
go
over
this
in.
If
people
want
to
ask
me
questions
later
and
want
to
have
a
follow-up
or
something
on
revocation
and
then
one
other
topic
that
I'm
going
to
mention,
we
can
get
into
it.
C
If
you
were
revocation
activities
for
issuers,
the
Frameworks
are
crucial
in
simplifying
the
activities
in
in
areas
Cloud
engine
python,
for
example,
the
one
bcgov
uses
a
lot
and
and
did
a
lot
of
of
the
initial
creation
when
a
lot
of
the
complexity
of
managing
this
from
a
issuer
perspective
is
handled
within
the
library,
and
so
it's
not
a
big
deal
to
use
what
a
credential
def
when
creating
a
credential
definition.
Member
in
the
setup
we
did,
we
created
a
credential
definition.
C
We
clicked
the
we
use
the
flag
use,
revocation
and
we
specify
a
REV
registry,
a
revocation
registry
size,
that's
going
to
be
a
number
between
a
thousand
and
ten
thousand.
Something
like
that
on
issuing
credentials.
Every
time
we
issue
a
credential,
we
have
to
record
the
revocation
ID
of
the
credential
and
Associate
it
with
who
we
issued
it
to
when
needed.
We
revoke
a
specific
holder's
credential
by
using
the
revocation
ID.
We
invoke
a
routine,
it
says,
revoke,
credential
17296.
C
and
then
at
some
point
we
publish
those
revocations
either
as
they
happen.
So
as
soon
as
we
announce
we're
revoking
it,
we
immediately
publish
them
or
we
do
it
periodically.
If
the
use
case
allows
for
it,
we
might
only
do
it
periodically.
So
a
a
particular
you
know,
DMV
Driver's,
License
manager,
might
say
I'm
going
to
publish
all
the
the
revocations
of
driver's
license
once
a
day.
So
anytime,
an
address
changes,
it'll
it'll
be
triggered
the
day
you
know
within
24
hours,
so
that
may
be
enough.
C
C
So
those
are
the
steps
the
issuer
does
for
holders
when
they
Retreat
when
they
receive
a
credential.
They
retrieve.
What's
called
a
Tails
file
in
a
non-credits,
so
that
is
related
to
the
revocation
registry.
Their
credential
exists
in
when
they
create
a
presentation.
They
retrieve
the
state
of
the
Rev
of
the
revocation
registry
from
the
vdr.
So
basically
the
state
simply
says
here's
the
list
of
credentials
that
have
been
revoked
out
of
all
of
the
credentials
that
have
been
issued
here
are
the
ones
that
have
been
revoked
and
it's
just
an
index.
C
It
doesn't
say
whose
it
is
it's
just
simply
an
index.
The
7th,
9th
12th
and
3
000.
credential
in
a
registry
have
been
revoked
and
all
the
other
ones
are
still
valid
once
they
have
those
two
pieces
of
information
and
on
Chris
does
the
rest
and
generates
and
non-revocation
proof
to
include
in
the
presentation.
C
C
Finally,
for
the
verifiers,
the
holder
retrieved
a
particularly
particular
entry,
the
particular
State,
usually
the
state
as
it
exists.
When
the
presentation
was
created,
the
verifiers
would
retrieve
that
the
one
the
holder
used
they
would
retrieve
that
from
the
vdr
and
then
an
on
credit
and
just
handles
the
rest.
They
pass
in
the
proof
they
have
pass
in
the
River
Edge
entry
and
the
verification
is
done.
They
get
no
correlatable
identifier
and
they
have
no
way
in
the
future
to
monitor.
If
that
credential
happens,
to
be
revoked
sometime
in
the
future.
C
C
C
C
The
Tails
file
per
replication
registry
must
be
published
for
the
folder
to
download,
so
acupai
handles
make
putting
it
to
the
place
specified
by
the
issuer,
usually
some
using
something
called
a
tail
service
and
then
finally
occupy
when
you
publish
a
revocation
batch
for
a
type
of
credential.
So,
given
a
you
know,
student
ID
credential,
you
say:
Okay
I
want
to
publish
the
batch
and
publish
the
replications.
C
You
might
have
10
revocation
registers,
because
you've
issued
a
hundred
thousand
credentials
occupy,
takes
care
of
walking
through
all
of
them
and
Publishing
all
of
the
transactions
necessary
to
publish
those
revocations.
So
all
of
that,
when
we
first
implemented
this,
the
the
end
user,
the
the
issuer
that
had
to
do
all
of
that
work
that
now
is
all
embedded
in
the
framework,
and
so
that's
a
crucial
piece
of
Simplicity
in
using
it
yeah.
The
tail
server
is
kind
of
interesting.
C
The
tail
server
would
would
could
be
either
hosted
by
the
issuer
or
could
be
hosted
on
a
shared
service.
The
there's
no
correlation.
So
the
issue
where
it's
not
it's
not
what
you
would
call
a
call
home
Factor
where
the
the
holder
has
to
call
back
to
the
issuer
to
get
something
because
they
were
the
whole.
The
issuer
already
knows:
they've
issued
it
to
the
holder,
so
there's
no
extra
knowledge
gained.
So
the
issue
we're
holding
it
is
fine.
C
Why
not
simply
update
a
record
with
expired
or
revoked
so
the
the
question,
so
you
can't
update
the
credential
itself.
The
credential
has
been
signed
held
by
the
holder,
the
holder
keeps
it
and
and
so
on,
so
you
can't
simply
update
the
credential
itself.
If
you,
you
could
update
a
record
and
make
it
available,
but
then
that
has
to
be
queried
somehow
and
and
so
that
gets
back
to
a
call
home
that
verifier
has
to
call
the
issuer.
Hey.
C
C
Limitations
of
an
on
cred,
1.0,
revocation,
the
Tails
file,
basically
holds
a
set
of
prime
numbers
for
the
revocation
registry,
one
for
every
entry.
The
problem
is:
is
that
the
size
of
that
increases
linearly
with
the
number
of
credentials
so
with
a
thousand
credentials,
it's
a
250k
file
with
10
000
credentials.
It's
a
2.5
Meg
file
that
becomes
too
large
for
a
mobile.
You
know
your
limitation.
Is
your
your
your
mobile
wallet,
commonly
your
your
app
that's
on
your
phone.
C
Obviously,
if
it's
a
Enterprise
holder,
a
a
business
that
has
its
own
business
wallet,
that's
on
a
server!
Well,
that
doesn't
matter,
but
if
you're
dealing
with
a
you
know,
a
phone
2.5
make
file
is
getting
large.
You
don't
want
anything
larger
than
that,
and
so
that
constrains
the
size
of
it.
So
practical
limit
is
about
five
to
ten
thousand
credentials
per
revocation
registering
now
you
can
have
many
revocation
Registries
for
credential
type,
so
it's
still
unlimited
number
of
credentials.
It's
just
they
have
to.
You
have
to
have
a
new
registry.
C
Every
time
you
hit
the
limit
of
the
registration
size,
and
so
that's
that's
where
that
limit
comes
from
additional
details,
handling
of
the
presentation,
so
I'm
I'm,
just
gonna
highlight
these
and
request
that
if
you
want
more
details
of
these
note
this
slide
and
ask
me
what
you
need
to
know.
Revocation
interval
is
provided
there
are
semantics
about
it
and
there's
best
practices
that
should
be
followed.
C
C
Then
there's
one
other
thing
which
is
when
you
have
revocation
you,
you
request,
revocation,
but
the
source
credential
doesn't
support,
revocation
or
you,
you
don't
request
verification
issue
and
it
does
support
it.
How
is
that
handled?
And
the
basic
answer
is
that
the
presentation
should
always
work.
So
if,
if
you're
requesting
two
credentials,
sorry,
you
request,
revocation
for
both
of
them,
but
only
one
supports
revocation.
That
presentation
should
still
work
and
that's
the
way
it
is
designed
to
work.
C
C
This
is
where
I
plan
to
take
the
Break,
we're
going
to
jump
into
this
I'm,
going
to
jump
ahead
and
drop
off.
Oh
you're,
coming
up
very
soon.
I
am
not
going
to
do
this
section,
so
this
is
another
really
fun
section
and
I
really
wish
I
could
have
done
it
because
it
could
have
added
some
interest
and
maybe,
at
the
end,
if
people
are
interested,
we
could
do
it
or
I'm
happy
to
do
another
session.
C
There's
a
link
here
to
slides
for
this
and
I
recently
did
this
at
a
conference
on
the
open
source
Summit
for
Linux
Foundation.
Basically,
what
this
does
is
it
uses
high
school
math
to
do
to
explain
how
zero
knowledge
proof
works
and
it
quite
you
know,
a
very
accessible
way
as
long
as
you've
completed
high
school
math
and
you
did
reasonably
well
and
you
sort
of
remember
it
how
zero
knowledge
proofs
work
and
why
they
are
valuable
to
you.
So
it's
it
is
a.
I
I
quite
like
this.
C
A
C
C
Indy
was
an
all-in-one,
it
included
The
Ledger,
it
included
the
VC
format
and
on
credits
and
included
agents.
The
agents
were
extracted
out
essentially
in
2018,
and
that
became
the
hyperledger
Aries
project
in
2022
and
on
credits
was
extracted
out
of
of
Indy
and
made
into
the
hyperledger
and
non-crest
project.
So
Indie
is
The
Ledger
and
an
interface
to
talk
to
The
Ledger
permission
to
write
open
to
all
public
to
read.
C
C
It
was
more
a
that
it
was
convenient
to
put
it
in
there.
The
library
has
used
it
and
in
fact,
what
what
I
was
really
surprised
to
discover
was
people
would
come
to
me
and
say
hey
by
the
way,
we're
using
an
arm
press
but
we're
using
it
with
fabric
and
we're
using
an
on-preads
but
we're
just
using
a
database.
So
all
sorts
of
people
already
had
just
taken
a
non-crest
as
it
existed
and
put
some
shims
around
it
to
make
it
independent
of
Indie
to
use
it
with
different
ones.
B
C
C
Registering
this
is
writing
publishing
to
the
vdr
you
pass
in
the
data
with
where
you
want
it
to
go
with
an
identifier
for
or
an
indicator
where
you
want
it
published
and
it
gets
published
to
the
PDR.
So
that's
the
architecture
and
with
that
the
legendary
Rodolfo
is
going
to
take
over
and
lead
you
through.
A
demonstration
of
that
and
the
use
of
it.
A
A
D
D
Yeah
I'm
ready
to
go
yeah,
so
my
name
is:
can
you
hear
me
yeah,
oh
good,
so
my
name
is
Robert
from
Miranda
from
Roots
ID,
so
I've
been
in
that
self-sovereign
space
for
around
two
years
and
I
come
from
a
blockchain
community
in
my
case,
is
the
cardano
blockchain
community?
That's
why
I'm
gonna
talk
a
little
bit
about
how
you
can
use
anoncrates
in
a
different
blockchain
than
tanindi,
so
I
said
blockchain,
but
actually
I
should
say
bdr,
because
you
can
use
any
anything,
any
storage
as
a
video.
A
D
Spec
good
great,
so
this
is
the
main
document.
I
think
everything
that
is
Steven
mentioned
is
reading
here,
all
the
technical
details,
how
the
animal
crates
work.
How
you
should
Implement
is
is
here,
is
a
huge
document
and
one
go
over
that,
but
I
gonna
point
to
the
introduction,
whereas
this
is
this
nice
plot
here
this
graph,
because
I'm
I
will
try
to
explain
why
we
need
a
video.
E
D
D
Really
simplistic,
we
can
say
that
in
the
issuers
and
holder
we
store
the
private
information
and
on
the
vdr
we
store
the
public
information.
So
since
we
are
dealing
with
with
cryptography,
you
know
that
every
time
we
talk
about
a
key
we're
talking
about
a
key
pair
is
composed
by
the
private
part
of
the
key
plus
the
public
part
of
the
of
the
key.
So
in
this.
D
B
D
Lot
of
information
and
and
posting
in
a
specific
format,
go
to
the
bdr
right.
You
have
the
the
private
and
the
video,
so
we
know
that
the
private
part
is
really
critical.
So
if
you
lose,
if
you
lose
your
keys
or
if
your
keys
are
compromised,
you
know
that
you,
maybe
the
holder,
lose
the
keys.
They
lose
their
identity.
Maybe
the
insurer
lose
their
or
compromise
the
keys.
D
We
need
two
things
right:
we
need
the
signature
and
we
need
to
the
the
public
part
of
the
key.
So
if
one
of
those
are
missing
or
incorrect,
the
proof
is
not
going
to
be
valid.
So,
in
order
to
that,
one
of
the
key
features
of
the
video
is
that
the
the
public
key
should
be
always
available
right
and
also
should
be
the
correct
public
key.
D
So
these
are
the
two
main
characteristics
that
the
bdr
need
to
have
like
to
be
to
to
have
all
the
objects
or
the
the
public
information
always
available
until
the
the
this
information
cannot
be
modified
in
time,
so
always
have
to
be
the
same.
So
I.
If
you
see
the
the
the
video
having
a
critical,
is
a
critical
component
as
well
right
and
you
need
to
to
decide
which
PDR
you
want
to
use.
For
example,
if
we.
D
The
bdr
is
like
a
trust
storage
right,
because
the
members
of
the
of
the
user
of
that
system
need
to
trust
that
that
storage.
So,
for
example,
if
you
wanna
I,
think
on
the
on
the
chat
today,
someone
mentioned
the
ethereum
blockchain.
So
if
you
wanna
build
a
system
for
the
ethereum
community
and
make
totally
sense
to
to
use
that
blockchain,
the
ethereum
blockchain
as
a
as
a
video,
because
the
member
of
that
Community
already
trusts
that
blockchain.
D
D
So
that's
why
selecting
a
vdr
was
or
making
a
video
as
an
option
on
this
aspect
was
one
of
the
the
principal
goals,
instead
of
using
only
using
the
the
in
the
option
right
how
this
spec
deals
with
different
bdrs
I
think
they
in
the
spec.
There
are
three
things
to
deal
with:
to
make
the
expect
agnostic
to
Hindi.
Maybe
are
agnostic
to
any
vdr
specific
bdr,
it's
defined
three
things.
The
first
one
is
a
video
I
need
to
implement
to
to
operations.
D
D
D
D
So
if
you
go
to
the
spec,
we
can
see,
for
example,
for
the
schema
that
the
schema
need
to
have
this
specific
format
and
to
have
an
issued
ID,
a
name,
a
version
and
all
the
attributes
that
the
scheme
is
going
to
have
and
if
you
go
to
them,
maybe
the
The
Collection
definition.
You're
gonna
have
also
all
sort
of
different
properties
that
the
schema
have
to
have
that.
D
And
and
so
forth,
so
there
is
a
specific
details
of
how
you
need
to
format
a
credential
definition
and
each
of
those
options
and
the
third
things
that
is
defined
on
them
on
the
spec
is
a
registry.
It's
a
registry
of
anong
greats
method.
A
nanograph
method
is
a
definition
of
how
to
use
a
specific
bdr
with
anong
currency,
so,
for
example,
in
this
in
the
recipe
currently,
we
have
several
methods
defined.
One
is,
for
example,
the
DD
is
how
you
use
Indie
without
any
cracks.
That's
how
have
been
forever
and
implement.
D
D
We
also
have,
for
example,
in
the
check
the
check
team.
Implement
a
check
is
a
platform
identity
platform
that
use
the
cosmod
blockchain,
so
they
Implement
I
think
it
was
the
first
implement
the
Anon
cred
method
in
a
different
lecture,
so
they
they
build
a
full
spec.
You
want
to
point
to
that
I'll
link
in
that,
so
the
bill
full
spec
of
how
to
use
check
d
as
an
Asana.
D
You
can
go
like
you're
gonna,
find
all
the
links
on
the
on
the
slides
and
on
the
wiki
after
the
the
worship,
and
we
also
have
the
cardano
that
is
I'm.
Gonna,
explain
a
little
bit
how
it
works
for
us
to
build
the
cardano
Anon
Quest,
and
but
if
you
want
to
build
a
new
method,
you
just
need
to
to
Define
how
it's
going
to
work
for
your
video.
D
D
B
D
Cardano
you're
gonna
find
a
link
to
our
method,
at
least
here.
What
we
did
in
our
case
is
we
meet
with
several
players
on
that
community
that
works
with
identity
Solutions,
and
we
try
to
meet
periodically
to
Define
this
specification.
That
is
how
we
should
write
objects
into
the
cardinal
blockchain,
so
we
meet
and
try
to
build
this
spec
and
things
that
we
need
to
Define
is
how
we're
gonna
explore
the
office
on
blockchain
I.
D
That
is
going
to
be
public
available
and
also
can
be
verified.
That
is
mutable
right.
There
cannot
be
changed,
so
we
decided
to
use
that
that
option
to
choose
to
store
them
the
the
option,
the
anong
correct
object.
We
also
need
to
Define
how
you're
going
to
reference
that
object.
We
we
use
one
spec.
One
format
that
is
called
did:
link
resources.
That
is
a
way
to
link
some
resources
to
a
did
in
that
case,
takes
the
form
of
of
this
one
that
says
you
know
to.
D
D
Since
we
are
using
a
transaction
to
to
store
the
object
itself,
we
decide
to
use
the
transaction
ID
as
a
object
ID.
So
that's
going
to
be
really
easy,
then
for
query.
For
those,
after
that,
we
we
Define
how
the
object
is
going
to
be
composed,
we're
actually
going
to
use
the
the
unknown
correct
object
that
is
defined
on
the
spec,
but
also
we
are
adding
extra
information,
such
as
the
type
of
the
object.
D
Who
is
the
issue-
and
this
is
that
is
very
important-
is
that
the
publisher
signature,
so
we
have
an
extra
step
of
validating
that
whoever's
submit.
The
transaction
is
also
the
owner
or
the
controller
of
the
issue.
Id
we
did.
We
did
that
for
all
the
objects,
the
schema,
the
credential
definitions,
the
revocation
registry
and
and
also
we
have
to
deal
with
some
nuances
of
the
blockchain,
because
you
know
in
the
blockchain
you
have
to
deal
with
relatencies.
You
have
to
deal
with
transactions
with
fees
with
them
how
they,
the
consensus
of
protocol
works.
D
So
we
Define
everything
on
the
on
this
document
and
then
we
we
put
the
heart
of
developers
and
Implement
some
reference
implementations
in
code.
We
did
that
on
python
on
typescript
what
we
wanted
to
go
further
that
and
have
a
real
implementations.
So
we
pick
one
of
the
Frameworks
80s
Frameworks
that
allows
us
to
use
the
the
new
one
on
credits
specification
that
is
a
natural
agnostic,
so
we
we
went
through
them
and
using
the
Aries
framework
service
and
I'm
gonna
show
you
right
now
a
piece
of
code.
D
D
D
D
It's
also
created
the
ID
for
the
initial,
so
everything
is
mixed
here.
It's
just
a
sample
and
create
and
publish
the
schema,
and
the
publishes
mean
it's
going
to
be
published
into
the
real
blockchain,
create
some
parts,
credential
definition
into
the
blockchain,
and
then
it's
gonna
wait
for
some
blockchain
confirmations
that
are
needed
and
it's
gonna
resolve
those
I'm
gonna
go
and
read
those
objects
from
the
blockchain.
D
The
example-
maybe
a
little
bit
silly,
but
when
I
show
you
what
it
does
is
greater
you
see
creating
the
the
secret
creating
the
initial
drd
and
then
creating
an
registering
the
schema
and
the
credential
definition.
If
you
see
the
idea
of
the
credential
definition
have
this
format,
that
is
the
idea
of
the
Israel
flash
resources
and
this
long
identifier
that
actually
say
I
did
identifier
of
the
transaction
that
we
used
to
to
Anchor
the
data
on
the
blockchain.
D
So
you
see
the
noun
that
is
waiting
for
the
blockchain
confirmations.
That's
need
to
be
done
because
I
don't
know
if
you
some
blockchain
the
way
it
works
is
they
mean
several
blocks
periodically
in
that
case
is
every
20
seconds.
So
you
need
to
learn
to
wait
for
some
blocks
after
the
the
one
that
you
mean
to
make
sure
that
the
the
this
this
one
is
really
validated
by
all
of
the
nodes
of
the
cardano
blockchain
that
are
doing
this
consensus
protocol.
D
D
So
today
you
can
see
all
the
details
of
the
options
like
this
number
of
big
numbers.
This
is
actually
a
weight
of
recording
all
the
public
keys
of
of
the
presidential
definition
and
the
credential
itself.
So
if
you
go
to
to
that
to
this,
this
is
the
the
scheme.
Id.
Let
me
show
I'm
gonna
show
you
credential
definition
ID
and
as
I
mentioned
this
identifier,
this
string
is
actually
then
the
ID
of
the
transaction
that
was
ported
into
the
blockchain.
D
So
if
we
grab
that
I'm
gonna
copy
that,
if
I
go
to
a
blockchain,
Explorer
blockchain
Explorer
is
actually
a
service
run
by
any
party
that
go
on
query
the
blockchain
to
see.
What's,
what's
there
right,
you
may
find
blockchain
Explorer
for
ethereum
for
cardano
from
Bitcoin
for
any
blockchain.
So
if
I
paste
them
this
ID
here
and
I'm
gonna
search,
I'm
gonna
find
all
the
details
on
the
blockchain.
This
is
a
real
blockchain.
It's
a
test
net,
it's
free,
but
it's
a
real
blockchain
that
is
over
there.
E
D
A
C
I
am
all
right:
let's
keep
going
we're
going
well,
we've
got
a
few
things
left
to
go.
I
should
highlight
I,
didn't
really
introduce
Roto
legendary
in
the
community.
He
does
awesome
work
and
Patrick
same
thing.
Patrick
just
keeps
coming
up
the
two
of
them
just
keep
coming
up
with
new
and
interesting
things
that
just
others,
hadn't
even
thought
of
and
boom
were
were
able
to
use
them.
We're
demonstrating
both
of
them
today
and
I'm
super
excited
about
that.
Okay,
let
me
get
to
my
presentation:
where
did
it
go?
B
B
C
Is
it's
in
full
screen
mode?
Okay,
we're
gonna
jump
to
a
topic
that
for
insiders
in
the
community
is
quite
interesting
and
and
controversial
for
a
long
time
and
yeah
pretty
weird
a
non
credits
in
w3cp
VC
data
model
format,
so
long
controversy
controversial
in
the
verifiable
credentials
community
and
our
credits
does
not
use
the
w3cb
VC
data
model.
C
C
That's
where
we
were
back
in
October
and
what
was
discovered
at
rebooting
web
of
trust
and
I
am
happy
to
say.
I
had
some
some
things
to
do
with
it
is
we
found
out
that
they
actually
work
really
nicely
together
and
in
fact
there
isn't
a
lot
of
Need
for
this
controversy,
because
presumably
you
could
use
W
and
on
credits
and
wqc
credential.
So.
C
What
that
allows
is
you
can
issue
a
credential
in
the
VC
data
model
format
for
processing
it
within
an
on-pread?
You
simply
move
them,
swap
the
model
back
process
it
and
and
do
what
you
need
with
it
and
and
when
you
want
to
you
know,
and
that's
all
you
need
to
do
basically
and
and
the
way
we
did
this
was
simply
by
moving
around
Json.
We
took
the
signature
on
the
VC
and
VP
made.
It
contain
identical
data
in
the
current
in
the
in
on
credits,
presentation.
C
All
features
of
an
on-crit
are
supported,
so
kind
of
cool
I'm
going
to
quickly
go
over
this
and
then
pass
this
over
to
Passover
to
Patrick
who's,
going
to
show
some
cool
stuff
he's
done
with
this
idea,
but
basically
the
correct
FID
becomes
the
issuer
ID,
the
schema
becomes
the
schema,
so
it's
referenced
in
the
credential
schema
type.
There's
a
type
of
an
on
creds
we've
got
the
idea
of
the
schema
in
here.
C
Our
credential
subject,
our
raw
data
goes
into
here.
The
encoded
data
does
not
go
into
here.
Remember
I
mentioned
that
it
would
be
better
if
the
encoded
data
wasn't
actually
in
the
various
and
on
credits,
objects
shared
in
this
case.
We
don't
put
it
in.
We
use
the
canonicalization
approach,
so
that's
and
I'm
not
encoding
Auto,
meaning,
oh
just
generate
it
yourself.
You
don't
need
me
to
pass
it
to
you.
You
can
figure
it
out
yourself.
C
C
We
have
a
Json
LD
context
which
defines
everything
like
CL
signature,
2022
and
things
like
that,
and
then
we
have
a
second
component,
and
this
is
those
for
those
who
need
to
know
about
Json
LD.
This
allows
the
definition
of
all
of
the
fields
within
here
generically
so
that
we
get
generically
a
way
to
specify
in
a
Json
LD
what
these
items
are,
and
this
could
be
replaced
by
an
issue
or
specific
context.
Again.
This
is
Json
LD
Insider
info.
C
C
This
can
be
a
basically
a
list
of
proofs,
so
you
have
the
anoncrest
proof,
but
you
could
also
have
a
data
Integrity
proof,
a
a
traditional
w3c
proof.
Both
of
them
would
be
on
this.
If
you
use
the
data
Integrity
proof,
you
would
basically
share
with
the
verifier
the
entire
credential.
But
if
you
use
the
CL
signature,
you
would
that
the
non-credits
credential,
you
would
have
all
the
features
of
a
non-prince.
C
C
So
with
that
introduction,
I'm
going
to
turn
it
over
to
Patrick
sway
who's
from
the
digital
identity,
lab
of
Canada,
who
is
doing
some
phenomenal
work
at
crossing
over
the
communities.
Remember
that
communities
that
I
showed
you
early
on
that
slide
with
the
four
different
communities
that
are
happening.
This
guy
is
doing
a
fantastic
job
at
jumping
across
them
and
figuring
out
stuff,
that's
happening
across
them
and
trying
to
find
synergies
between
them
and
doing
a
really
great
job.
So
with
that,
I
will
turn
it
over
to
you.
Patrick.
E
E
So
a
little
overview
of
the
Technologies
used
in
this
presentation.
So
there's
a
few
links
here.
I
can
share
this
presentation
after
no
problem,
so
so
this
is
sort
of
the
way
I
see
it
is
a
kind
of
mix
and
matching
different
specification.
I
did
not
directly
like
create
any
of
these
I
participated
in
the
did
web
and
on
creds
method
with
Ariel,
which
is
another
member
of
the
community,
where
I
stand
where
I
come
from
is
at
the
lab.
E
E
So
the
first
question
is
why
why
would
would
I
bother
using
Champion
the
VC
API
to
issue
it
on
cred?
So
the
the
key
here
is
interoperability,
so
Integrity
is
always
at
the
the
core
of
a
good
ecosystem,
especially
with
digital
ID,
and
when
you
can
demonstrate
interoperability,
which
is
a
whole
different
thing.
Well,
it
attests
how
Frameworks
are
built
with
a
solid
foundation
right
and
they
meet
their
goals,
because
you
don't
want
to
pigeonhole
your
solution
and
lock
it
in
a
specific
space
right.
E
You
want
to
be
able
to
move
around
and
create
a
great
ecosystem,
so
this
demonstration
will
show
two
things:
we'll
show
how,
by
design
that
what
you
see
the
other
model
is
is
very
adaptive,
and
that
was
one
of
their
core
principle
and
the
second
way
is
to
address
of
the
modularity
portability
or
their
Ledger
agnostic
side
of
the
new
and
on
creates
Library
before
I
started.
I
just
want
to
put
a
special
notice
to
this
page
here,
so
this
is
their
country,
Distributors
page
for
the
anacred
rust
Library.
E
So,
as
you
will
see,
my
name
is
not
on
there.
I
am
not
I
did
not
contribute
anything
there
I'm
very
much
an
enjoyer
of
the
final
product,
but
a
lot
of
the
sorry
my
webcam
froze,
but
that's
okay.
A
lot
of
the
credits
will
go
to
most
of
these
individuals
and
many
other.
You
know
with
open
source.
It
always
Builds
on
precedence
and
always
build
on
other
code.
But
I
just
wanted
to
to
make
that
very
clear
here.
E
So
just
four
words:
I
want
to
just
Define
make
sure
we
understand.
So
when
we
talk
about
issuing
the
action
of
the
issuing,
a
credential
is
really
the
issue,
embedding
a
cryptographic
proof
in
a
credential
before
it
sends
it
to
the
the
holder.
When
we
talk
about
the
arriving,
it's
the
action
where
a
holder
will
select
planes
from
different
credentials
and
join
them
together
in
a
presentation
in
order
to
match
a
presentation
request.
E
The
act
of
presenting
is
when
the
holder
responds
to
a
presentation
request
with
this
derived
presentations
and
then,
finally,
the
verification
is
when
the
verifier
will
validate
the
proofs
from
that
derived
presentation
to
make
sure
they're
authentic
and
they
have
been
issued
by
the
issuer.
This
touch,
in
our
case,
mostly
the
credential
definition.
E
So
what
is
chappie
so
chappie
is
a
WGC
credential
community
group
initiative.
It's
a
credential,
Handler
API.
So
it's
a
browser.
Api
meant
to
interact
between
your
browser
and
a
browser
wallet,
so
it
will
send
a
it
will,
allow
you
to
select
a
wallet
and
it
will
actually
send
the
information
to
that
wallet.
So
we
will
use
chappie
here
to
carry
two
action,
we'll
use
it
to
store
our
credential
and
to
present
our
presentations
or
our
credential.
E
And
then
the
other
component
is
the
VC
API,
which
is
also
an
initiative
from
the
the
WTC
credential
community
group,
which
just
is
more
meant
to
manage
the
life
cycle
of
the
credentials.
So
here
we're
talking
about
actions
such
as
issuing
so
embedding
the
proof,
deriving
presentation
and
verifying
the
presentation
so,
depending
on
the
action
you're
taking
the
these
endpoint
would
live
either
on
an
issuer
system,
a
holder
or
a
verifier,
and
in
our
case,
of
course,
we'll
use
the
Anand
credit
rust
library
to
sign
the
the
objects
and
yeah.
E
E
E
So
we're
going
to
use
this
as
our
sort
of
UI
to
understand
a
bit.
What's
going
on,
we
have
this
API,
it's
another
thing:
I've
been
working
on,
so
it's
a
sort
of
a
DC
API
implementation
of
the
Anon
credits,
rust
Library.
So
we
have
a
a
few
endpoints
here.
We
have
the
issue,
derive,
verify
and
I've
also
added
some
mapping
capabilities.
So
we
can
see
easily
see
the
Json
LD
to
add
on
creds
object
representation
here
for
the
wallet
component,
I'm
going
to
use
this
web
wallet,
it's
called
vetres.
E
You
can
sign
up
for
their
demo.
It's
a
browser
wallet.
You
just
need
to
go
at
demo.veruswallet.dev,
it's
going
to
ask
you
for
your
email,
you
make
your
account
and
then
you
install
the
wallet
and
finally,
the
universal
resolver.
So,
like
I
said,
I
use
the
didweb
method,
it's
up
to
spec,
so
how
I
managed
to
publish
my
schema
in
my
credential
definition.
E
So
when
you
have
this
spec,
you
need
to
add,
what's
called
a
did
document
and
according
to
the
did
core
spec,
you
can
Define
services
so
for
this
proof
of
concept,
I've
defined
a
service
for
my
schema
and
a
service
for
my
credential
definition.
So
when
someone
gets
this,
did
they
can
simply
go
fetch?
The
document
go
access.
The
service
find
the
ID
of
the
service
that
corresponds
with
what
they
they
want
to
fetch
as
a
resource,
and
each
service
is
compromised
of
an
ID,
a
type
of
service
and
a
service
endpoint.
E
So
if
I
want
the,
if
I
have
this
Shima
ID,
for
example,
I
would
simply
go
fetchy
ID
go
fetch
the
the
corresponding
endpoint
and
I
have
here
my
my
schema
same
thing
for
the
credential
definition
ID.
So,
as
you
can
see
the
credential
definition
ID,
so
I'm
gonna,
maybe
my
font
is
a
bit
smaller.
Sorry
I
have
a
large
screen,
so
you
can
see
the
it's
quite
different
so
since
their
credential
definition
contains
some
cryptographic
material.
E
What
we
have
included
in
the
spec
that
did
web
spec
is
the
ID
is
actually
a
checksum
of
the
content
of
the
credential
definition.
So
when
people
go
fetch
when
the
the
verifier
goes
to
fetch
this
credential
definition,
they
can
actually
verify
that
it's
it's
not
been
modified
by
compressing
this.
They
do
it's
a
simple
formula.
So
it's
a
minified
version
of
this
information
and
then
you
generate
a
shot
256
of
the
information
and
you
base
58
encode
it,
and
then
you
get
this
little
hash
here.
E
So
this
can
be
also
calculated
as
an
extra
step
from
the
verifier.
Obviously,
when,
when
you
use
blockchain,
you
have
this
sort
of
data
Integrity
built
in
as
a
feature
of
blockchain
Technology,
but
with
this
web
you
need
to
find
find
other
creative
way
to
ensure
these
mechanisms
that
are
taken
for
granted
from
a
ledger.
So
this
is
all
I'm
gonna
manage
my
IDs
for
the
different
objects.
E
So
first
part
we're
going
to
issue
and
store
a
credential.
So
if
we
look
here,
this
is
the
type
of
payload
that
we
would
send
to
the
VC
API.
So
we
have
first,
we
have
our
credential
okay,
so
we
want
to
issue
a
credential
for
the
schema
that
I
just
presented.
So
we
have
my
five
attributes
in
our
email.
The
organization
expression
give
a
name
family
name.
E
This
is
taken
care
of
it's
an
oncorrect
credential
there.
It's
properly
defined
I
have
here
my
credential
definition
ID
and
my
Shimmer
ID
the
values
that
are
inputted,
and
then
here
we
have.
The
component
is
the
credential
request
that
the
holder
sent.
This
is
where
the
Link
Secret
has
been
leveraged
to
generate
this
presentation
request
and
what
the
VC
API
will
do
is
it
will
take
this
credential
request
and
bake
it
in
this
credential?
So
this
is
where
we
see
this.
E
This
is
what
we're
seeing
here
so
we're
seeing
the
credential
and
the
credential
request.
These
are
the
two
that
we
see
so
how
it
would
work.
I
would
take
this
payload
and
then
go
over
to
my
VC
API.
Here.
I
would
simply
put
this
in
executed
and
there
you
go.
I
get
an
output
it
baked
into
proof.
So
now
I
have
my
credential
that's
been
issued,
but
once
it's
been
issued
after
this,
it
needs
to
be
stored
in
the
wallet.
So
that's
where
chappie
comes
in.
E
So
as
the
second
option
I
can
hear
well,
this
is
in
the
way
I
want
to
remove
this.
There
we
go
so
as
we
can
see
here.
So
this
interacts
with
my
browser.
So
chappie
is
going
to
prompt
me
to
select
which
wallet
I
want
to
store
this
in
I
hope
I'm
sharing
my
screen
properly,
there's
a
pop-up
that
just
appeared
here
so
I
have
a
few
few
wallets.
I
can
choose.
E
Can
see
it
all
right
perfect,
because
sometimes
you
only
share
a
window
and
it
created
some
problems,
absolutely
yeah,
I'm
glad
you
can
see
it
so
there's
a
few
wallet
these.
It
works
on
all
of
these,
but
I
find
that
various
wallet
is
interesting
option.
So
I
will
choose
the
various
wallet
and
then
it's
going
to
prompt
me.
E
It's
going
to
say
the
dtt
playground
wants
to
issue
me
an
on
shreds,
Workshop
pass,
which
is
a
conceptual
credential
and
it's
a
digital
pass
to
access
playground,
features
so
I'm
going
to
go
ahead
and
store
this
and
then
once
it's
stored,
I
can
go
see
if
I
refresh
this
page
I
have
a
stored,
credential,
so
it's
stored.
It
doesn't
show
on
this
page
the
content
of
the
credential,
but
we
is
the
credential
that
we've
issued
here
as
we
see
this
section
and
furthermore
we
can
then
go
see
for
the
the
Curious
mind.
B
E
Execute
this
and
then
I
have
the
Anon
creds
representation
of
that
credential.
So
this
is
the
this
sort
of
back
and
forth
between
two
models.
So
this
is
very
interesting
because
the
the
VC
it's
not
really
a
VC
anymore.
It
more
becomes
like
a
medium
to
carry
all
the
cryptographic
information
that
I
need
to
process,
whatever
I
need
to
process,
whether
it's
to
create
a
presentation
or
so
on
and
so
forth.
Second
part
I'm
going
to
derive
a
presentation,
and
this
is
where
we're
going
to
Showcase
selected
disclosure
and
zero
knowledge
proof.
E
So,
as
we
can
see,
we
have
this
credential.
So
this
is
the
credential
that
I've
stored
in
my
wallet-
and
this
is
my
presentation
request.
So
we
we
request
some
information.
So,
as
we
can
see
here,
we
have
five
attributes.
I'm
gonna
choose
to
share
my
email
and
my
organization.
Only
so
I'm
not
going
to
share
my
family
name:
I'm
gonna
they're,
not
gonna
share
my
my
name.
E
I'm
just
gonna
share
the
email
in
the
organization,
which
is
what
the
system
would
hypothetically
need
to
identify
me
to
send
me
into
the
right
resource
and
I'm,
also
going
to
make
sure
that
the
credential
is
not
expired.
So
I'm
going
to
do
a
lower
or
equal
on
the
this
date
that
I
want
to
make
sure
it's
not
expired.
E
And
then
there
we
go
so
this
is
very
interesting
here.
We
can
see
now
in
my
credentials.
Subject:
I
no
longer
have
five
attributes:
I
have
the
two
attributes,
I've
requested
the
organization
and
the
email
and
I
also
have
a
proof
that
shows
that
I
match
this
predicate
that
the
value
that
was
in
my
credential
subject
and
the
expiration
date
is
smaller
or
equal
to
this
value.
That
I
want
to
check
against,
and
all
this
can
be
verified
thanks
to
the
proof
and
then,
once
again
we
can
take
this.
E
E
So
if
you
look
here,
I
now
have
my
credential
and
my
presentation.
So
we
can
see
here
we
have
the
pass
and
then
we
have
the
the
presentation
which
is
a
derived
from
this
pass,
but
with
only
the
values
that
I
want
to
share
and
then
finally,
so
we
have
this
presentation
that
we
have
in
the
wallet
I'm
going
to
be
asked
to
present
it.
E
So
the
display
would
like
some
information
and
automatically
it
knows
to
select
my
presentation.
This
is
a
query
by
example:
it's
a
verifiable
presentation.
We
we
can
see
in
the
spec
there's
the
the
VP
request
specification
here
that
you
can
have
a
look.
So
it's
a
query
by
example.
So
I'm
querying
on
the
type
which
is
an
on
creds.
E
Presentation
in
this
here
and
then
I
can
share
my
presentation,
so
I'm
not
shown
visual
feedback
of
what's
being
shared
or
I
did
print
it
in
the
console.
So
if
you
put
a
more
Curious
here,
you
can
see
the
information
that
the
website
would
have
access
to
when
I
share
this
you
know,
so
they
would
have
access
to
this
presentation
and
then
they
can.
They
would
have
these
sort
of
endpoints,
so
they
could
map
it
or
they
could
simply
verify
it.
E
E
And
it
should
returns
me
True
Value,
you
know
so
this
all
this
verification
is
done
with
the
add-on
credits,
rust,
Library
I'm
using
the
python
wrapper.
So
it's
a
very
python
implementation.
This
is
a
fast
API
server
and
this
is
a
flask
web
server
for
the
the
developers
Among
Us
and
we
can
see
if
I
just
change
any
of
these
values.
You
know
if
I
want
to
pretend
that
I'm.
E
Some
other
user,
for
example,
I
check
it,
and
now
it's
been
falsely
it's
not
true
anymore,
so
this
guy
is
kind
of
working.
You
know
and
I'm,
not
I'm,
not
a
cryptographer,
so
I
very
much
trust
the
work
that
that's
been
done.
It's
and
you
know
this
is
a
good
way
to
test.
Also
what
has
been
done.
So
this
is
the
the
the
main
part
of
my
presentation.
E
So
we
went
over
the
did
web
method
for
add-on
creds
how
we
can
share
this
information
with
a
browser
wallet
which
is
an
interesting
alternative
and
yeah.
We
went
over
a
bit
the
VC
API,
but
it
could
be
done.
I
have
other
means
to
create
schemas
and
credential
definition,
but
I've
kept
this
out
of
this
presentation
for
time,
but
you
would
simply
make
these
schemas.
You
would
create
them
store
them.
I
use
a
redis
database
for
this
and
expose
them
to
my
API
and
then,
according
to
the
you
know,
the
did
well
spec.
E
You
just
simply
need
to
go
resolve
your
well-known
did.json
document
and
then
you
would
add
Services,
depending
on
your
different
schema
or
credential
definitions.
This
is
one
way
to
do.
It
is
the
way
that
I've
chosen
a
respect,
both
the
didway
and
the
didcore
specification
and
seems
to
work
very
well.
That
will
be
it
for
my
presentation.
C
B
E
E
E
C
So
we'll
wrap
up
there's
a
few
more
a
couple,
more
topics
that
I
want
to
touch
on
won't
take
long.
We
won't
go
past
11,
30,
Pacific
time.
We
won't
go
past
the
half
hour,
but
I
did
want
to
hit
on
two
more
topics
just
to
cover
this.
These
won't
take
long
and
on
preds
and
what
is
called
overlays
capture,
architecture
or
OCA.
C
This
is
the
making
credentials
beautiful
section
and
as
we've
evolved
and
on
creds
and
the
use
of
it
on
credits
and
Aries,
and
and
using
these
different
capabilities
more
and
more
we're
getting
these
out
into
the
real
world.
You
know
the
BC
wallet
is
has
been
published.
The
orbit
is
out
there.
Different
wallets
are
out
there
and
user
experience
becomes
a
huge
issue,
we're
dealing
with
people
that
we
really
want
to
demonstrate
this
to
that
need
to
see
this
is
a
credential.
C
This
isn't
just
a
bit
of
Json
that
we're
dealing
with
the
the
problem
we
had
was
that
the
verifiable
there's
minimal,
verifiable
credential
metadata
about
it
and
on
credits,
provides
very
little.
Data.
I
tried
to
show
this
early
on
there's
an
issue
or
did
but
no
standardized
way
to
get
more
information
about
the
issue
or
like
their
name
or
description.
C
C
Those
are
the
things
we
put
in
the
schema,
credential
definition
doesn't
have
anything
remotely
anything
useful
from
it
for
helping
to
display
it,
and
then
things
like
issue
or
branding
being
able
to
have
the
colors
match
have
a
an
image
that
reflects
the
brand
of
the
issuer.
None
of
that
is
available.
So
that's
what
we
were
trying
to
overcome
as
we
thought
about
that
one
thing:
I
didn't
even
mention
there
was
multilingual.
C
How
can
we
present
beautiful,
multilingual
credentials
with
so
little
data?
They
just
don't
have
anything
we
can
use.
We
then
began
to
look
at
overlay
capture
specification.
Another
slide:
that's
slightly
out
of
whack
I'll.
Get
that
fixed,
so
overlay
capture
architecture
is
something
that
started
in
the
pharmaceutical
area
and
was
now
is
now
under
the
under
the
caretaker,
the
care
of
the
human
Colossus
foundation.
So
the
idea
here
is
you
have
a
data
structure.
It
can
be
anything
but
for
our
purpose,
the
base.
C
The
capture
base,
that
data
structure
is
the
attributes
in
a
credential,
the
credential
plus
the
list
of
attributes
within
it.
So
that's
our
base
and
then
what
you
have
are
overlays
that
link
back
to
the
base
and
that
allow
you
to
specify
different
components
that
that
overlay
on
top
of
that
base.
So,
for
example,
you
can
have
a
label
overlay
that
over
that
goes
on
top
of
the
capture
base,
a
list
of
attributes
in
that
data
structure
and
contain
all
the
labels
for
the
attributes
within
it,
and
that
label
can
be
language
specific.
C
So
now,
suddenly
I've
gone
from
having
just
a
list
of
attributes
given
underscore
name
to
an
overlay
with
specific
labels
and
one
over
one
label.
Overlay
per
language,
I
can
add
character,
encodings
data
format,
the
standards
that
are
applied
in
using
that
data
I
can
have
units
of
measure.
This
is
millimeters.
C
C
C
C
C
That's
what
OCA
brings
us
and
why
it
actually
turned
out
to
be
really
useful.
So
here's
what
that
credential
I
showed
you
looked
like
earlier.
I
have
an
issue
date
that
looks
pretty
good,
but
only
because
the
the
wallet
put
that
in
and
it
knew
what
moment
in
time
it
was
issued
to
it.
So
it
gathered
that
information,
but
this
is
the
issuer.
This
is
the
credential
there's
our
schema
name
and
schema
version.
We've
got
our
underscores
and
our
names
we've
got
the
expiration
date
in
that
format.
C
C
The
logo
stays
the
same.
There's
only
one
logo,
but
the
labels
are
all
fixed.
The
the
items
in
the
in
the
wild
themselves
are
our
multilingual.
So
that's
the
idea
of
what
what
OCA
does
pretty
much
everything
you
see
here
outside
of
this
issued
and
and
these
High
dolls,
which
are
wallet
specific
everything
else
you
see
that's
different
across
these
is
because
OCA
has
been
applied.
C
C
When
you
get
the
credential
go,
get
the
bundle
and
then
you
can
use
it
to
display
the
credential
in
a
beautiful
way.
We
decided
to
go
with
the
use
of
a
GitHub
repository
for
the
bundle.
Then
we've
got
an
initial
cut,
Linked
In
Here
of
what
that
looks
like
the
GitHub
repo
contains
some
governance
around
it.
Much
like
those
who
are
familiar
with
open
source
software.
You've
got
a
set
of
maintainers.
C
The
maintainers
have
rules
to
make
sure
that
the
validity
of
the
data
is
accurate
and
useful,
but
but
the
content
is
up
to
whoever
the
issuer
is,
so
anyone
can
submit
an
OCA
bundle
into
this
repo.
We
will
accept
it
if
we
verify
that
it
is
actually
an
OCA
bundle
that
you
represent
the
issuer,
that
the
bundle
has
a
schema
that
is
published
somewhere
and
you've
identified.
So
there's.
C
Data
Integrity
rules
around
that
that
are
currently
manually
defined,
but
once
that's
accepted,
the
bundle
gets
published
into
this
repository
and
a
wallet
can
pull
it
from
the
repository.
The
wallets
are
being
built
to
know
about
this
reposit
story
and
when
they
get
a
credential,
they
look
up
in
their
list
to
find
out
if
the
OCA
bundle
is
available
in
this
repository
and
Pull
It
in
so
that's
our
short-term
way
of
doing
that,
we've
got.
Oh
excuse
me
a
little
demo
for
a
little
Explorer
to
show.
C
Any
bundles
that
are
in
the
repository
are
available,
and
so
I
can
click
on
them
and
see
what
they're
going
to
look
like
inside
a
wallet
I
can
switch
between
the
languages
if
I
want
I
can
play
with
things
like
the
colors
on
it
to
see
if
I
want
to
change
how
it's
presented
and
as
I
adjust
I
can
see
that
so
as
I
change.
These
settings
I
can
also
download
The
Branding
overlay.
This
information-
that's
in
this
overlay
that
allows
me
to
Brand
it
to
my
specific
needs.
C
C
Sorry
about
that
and
on
credits
too,
a
non-quest
2
has
a
began
with
a
working
group
that
started
in
early
2023,
defining
and
on
credits.
Next,
the
goal
is,
and
not,
creds
is
not
particularly
tied
to
the
CL
signature
or
the
particular
signature
being
used,
but
rather
is
about
the
set
of
features.
The
Privacy
preservative
features
that
are
in
a
Democrats,
and
so
the
goal
of
B2
is
to
retain,
retain
and
extend
the
features
of
an
encres
one,
while
improving
capabilities,
performance,
accent,
stability
and
security.
C
So
that's
the
goal
of
an
on
grads,
too.
Here's
highlights
a
few
of
the
things
that
are
being
offered
are
being
suggested
in
2.0
and
that
we're
working
on
as
to
how
to
do
this.
Basically,
all
of
these
capabilities,
we
know
how
to
do
it,
we're
just
trying
to
nail
down
what
will
go
in
the
spec.
How
do
we
balance
the
new
capabilities
with
not
with
a
reasonable
adjustment
to
the
interfaces
that
are
used
for
non-creds?
C
How
do
we
make
this
easy
for
evolving
for
been
on
grids
one
to
two
for
those
knowledgeable
of
underlying
cryptographic?
Signatures
in
most
likely,
BBS,
Plus
or
Ps?
Signatures
will
be
used
as
I
mentioned.
Scalable
replication
is
a
key.
We've
got
a
number
of
candidate
approaches
to
that.
If
anyone
is
interested
in
revocation,
if
anyone
has
a
cryptographic
background
that
would
like
to
contribute
to
that,
we've
got
some
really
good
things
happening
there.
C
We
would
use
the
dip
presentation
exchange
and
then
relatively
small
changes
in
the
data
objects
and
data
models.
Basically
same
objects
would
be
there
different
data,
possibly
one
other
object,
same
relationship.
So
that's
the
idea.
The
cool
thing
here
is
exposing
more
predicate
like
capabilities
to
give
you
more
flexibility.
This
is
a
big
one.
The
ckp
attribute
equality
prove
that
two
attributes
in
two
different
credentials
have
the
same
value
without
exposing
them.
C
So
something
like
proving
that
your
name
is
the
same
in
two
credentials
without
exposing
what
your
name
is
even
more
verification
that
the
credentials
belong
together
without
sharing
further
information
timelines,
not
too
much
available.
It
really
depends
on
how
engaged
the
community
gets
in
doing
this,
we've
made
a
bunch
of
progress,
but
we
really
have
to
get
the
community
engaged
in
building
components
of
this.
C
C
You
can
build
Frameworks
that
embed
them
and
you
can
contribute
to
the
community
around
and-
and
you
know
how
to
do
that-
a
pile
of
links
here
of
things
you
can
use.
We
will
be
sharing
links
to
the
these
links
and
links
to
the
slides
in
a
follow-up,
email
building,
Frameworks
that
embed
it
work
with
the
Aries
community
and
using
it
on
credits,
build
it
into
your
own
proprietary
framework.
You
do
it
in
a
way
that
interacts
with
others.
C
We'd
love
that
add
support
for
an
oncorrect
besides
in
beside
other
credential
formats,
use
an
archives,
for
example,
in
an
open
ID
for
VC
exchange.
That
could
be
very
interesting
got
a
pile
of
of
things
that
we've
talked
about
already.
The
one
I
wanted
to
highlight
here
is
nimlab,
and
what
they're
doing
they
actually
have
in
a
non-credits
verifier
built
into
a
smart
contract,
an
on-chain
smart
contract
on
the
Juno
Network?
C
What
that
allows
is
for
doing
D5,
decentralized,
Finance
things
that
by
executing
a
on-chain
smart
contract,
a
off-chain,
verifiable
credential
can
get
verified
a
presentation
provided
and
verified,
and
then
the
transaction
can
continue.
So
information
is
collected
and
verified
as
part
of
an
on-chain
smart
contract,
but
you're
using
verifiable
credentials
super
interesting,
a
link
to
Nim
lab
is
there
recommend
people
interested
in
a
blockchain
merging
of
verifiable
credentials?
C
Take
a
look
at
that
if
you
want
to
contribute
to
an
on
creds
a
bunch
of
links
here
of
the
meeting
calendar
where
the
specs
are
and
when
the
meetings
are
the
next
and
on
credits
again
meetings,
the
spec
is
there
early
days,
but
we're
really
looking
for
moving
forward
very
quickly
within
on
credits
and
w3c
format
and
scalable
verification.
If
you
have
any
interest
in
that,
please
join
us
and
that's
it
three
minutes
over.
C
A
Worries,
thank
you.
Stephen
Patrick
Rodolfo,
for
putting
on
such
a
great
Workshop
in
the
chat
I
have
included
some
links
to
places
like
the
anacreds
Wiki
page,
the
Wiki
page
for
this
Workshop,
which
is
going
to
include
all
the
slide
decks
and
the
Labs
documents,
as
well
as
the
video.
Once
it's
done,
encoding
thanks
to
YouTube.
A
As
Stephen
said,
this
is
an
open
source.
Community
anyone
can
work
with
this
code.
Anyone
can
use
it
in
their
projects.
We
would
love
it.
If
you
participated,
we
would
love
it
if
you
became
a
contributor
and
and
moved
into
the
maintainer
status.
That
would
be
awesome,
but
we
are
powered
by
our
community
this.
This
software
doesn't
write
itself.
It's
the
awesome.
People
like
the
three
presenters
here
today
who
make
it
on
credits
happen,
and
we
hope
this
was
valuable.
You
got
a
lot
out
of
it.