►
Description
This month’s in-depth topic: Azure AD Verifiable Credentials - how to get started with Request API. In this session, we will share the latest update around public preview of the Request Service API. Developers can start using the new Request Service API to easily build applications that can issue, verify credentials from any programming language of choice. Sequence flow diagrams and 3 demos - Verifiable Credentials, .NET sample, Using the Request API with Postman, discussed. This session was delivered by Microsoft Identity and Network Access Program Managers Matthijs Hoekstra and Rohit Gulati. Recorded on October 21, 2021. Q&A in chat and live at end of call.
Stay connected:
• Twitter https://twitter.com/microsoft365dev and @azuread
• YouTube https://aka.ms/M365DevYouTube (Developer channel) and https://aka.ms/m365pnp/videos (Community channel)
• Blogs https://aka.ms/m365pnp/community/blog
• Recurrent Invite https://aka.ms/IDDevCommunityCalendar
• Next call: November 18th at 9:00am PST
A
Yeah
good
day,
everyone
thank
you
for
dialing
in.
Let
me
start
by
introducing
myself.
Then
I
will
pass
on
the
flow
to
my
esteemed
brother.
I
am
rohit
gulati.
I
am
a
program
manager
in
identity
and
network
network
access
engineering,
I'm
based
out
of
london,
and
I
work
with
customers
and
partners
on
azure
radio,
verifiable
credentials.
B
B
A
So
just
to
set
the
agenda
and
you
will
find
us
doing
a
conversation
exchanges,
so
please
feel
free
to
also
post
your
questions
on
the
chat.
We
will
take
the
question
as
it
comes
the
whole
session.
We
have
segmented
into
four
key
sections,
we'll
start
with
the
baseline,
I'm
hoping
that
some
of
you
have
looked
and
played
with
azure
id
verifiable
credential.
It's
been
in
public
preview
since
april,
so
we'll
do
a
quick
baselining
of
that
we'll
show
a
demo
of
our
standard
set.
A
Then
we'll
move
on
to
the
request,
api
and
the
work
that
we
are
doing
with
request
api.
We
will
do
a
demo
around
the
sample.
We
will
explain
how
it
works
and
then
we'll
share
some
more
details
around
the
api
and
some
use
cases.
So
that's
the
agenda.
We
have,
as
I
said,
please
feel
free
to
drop
your
questions
on
the
chat
and
we
will
take
it
as
it
comes
so
with
that.
Let
me
pass
on
the
floor
to
mathis.
B
A
B
Yeah
cool
all
right,
so,
let's
get
started
on
what
are
verifiable
credentials
and
decentralized
identifiers.
Those
are
the
two
things
we're
going
to
talk
about
today.
Well,
fair
about
credentials.
We
just
see
this.
It's
a
data
object
and
it
consists
of
a
few
claims
and
they
are
issued
by
a
certain
entity
which
can
untested
information
so
think
about
a
university
can
issue
a
variable
cadential
diploma
or
the
dmv
can
issue
a
digital
driver's
license
based
on
the
variable
credentials,
standard,
workplace,
credential
health
passports
are
a
very
good
example
of
fair
credentials
as
well.
B
A
variable
credential
is
typically
issued
to
a
certain
user
or
subject,
and
that
subject
is
also
represented
by
a
decentralized
identifier,
and
these
are
the
identifiers
or
dids
are
usually
generated
self-owned
and
you
can
own.
You
can
prove
that
ownership
of
that
did,
which
is
matched
to
a
private
key
by
signing
messages.
B
When
you
receive
a
bit
you
can
resolve
that
did
to
a
document.
I
will
show
an
example
in
a
bit
and
inside
of
the
document
you
will
find
the
public
key.
You
resolve
this
through
the
iron
network
and
what
you'll
find
is
that
public
key,
and
that
makes
you
be
able
to
verify
messages
coming
from
that
specific,
the
id,
because
that
the
id
signs
that
message
with
a
private
key
anybody
can
verify
through
the
public
key
to
make
sure
it's
coming
from
that
entity,
either
the
issuer
or
or
the
user.
B
The
question
in
the
in
the
chat.
So
what's
the
verifiable
credentials?
How
long
are
they
valid?
That's
up
to
the
issuer,
so
the
standard
describes
that
you
can
have
like
a
validity
of
your
variable
credential.
It
could
be
forever.
It
could
be
for
a
minute
it
could
be
for
a
year.
That's
up
to
the
issuer.
B
Can
variable
credentials
only
be
used
against.
As
you
know,
so,
favorable
credentials
is
a
standard
that
we
have
a
standard
slides
in
in
in
a
bit.
Let's
just
walk
through
a
little
bit
about
how
this
works
from
the
woman
from
a
technical
perspective.
Boot
group
is
the
issuer,
they
have
a
dit
and
they
have
a
private
key.
The
public
key
is
published
on
this
distributed
ledger.
So
it's
like
a
big
distributed
pki
system
which
is
being
built
when
they
issue
a
verifiable
credential.
They
are
the
issuer
and
they
typically
issue
it
to
a
certain
user.
B
They
will
sign
that
fairva
credential
as
well
and
prose
where
can
verify
both
signatures
from
both
wood
groove
and
from
alice,
and
I
typically
also
will
check
wait
a
minute
is
that
proof
from
woodgrove
actually
issued
two
alice
so
they'll
check.
If
the
subject
matches
with
the
with
the
signature
as
well.
This
is
really
high
level
how
verifiable
credentials
technically
work,
but
it's
all
based
on
open
standards.
So
when
the
question
was,
can
variable
credentials
only
be
used
against
so
paraviral
credentials
are
on
top
of
the
id.
So
you
don't
need
the
ids.
B
To
be
honest,
you
can
actually
issue
variable
credentials
without
them
they
are
based
on
a
w3c
standard.
So
that
describes
how
the
format
of
that
federal
credential
looks
like
so
technically
speaking,
microsoft
issuing
variable
credentials.
Are
you
official
issuing
variable
connection
to
our
system?
Could
work
against
somebody
else's
system,
helping
you
validate
those
variable
credentials.
B
Dates
are
based
on
the
several
different
versions
of
this
people
can
use
different
did
methods,
we
call
them,
I
think,
there's
over
50
of
them.
In
the
end,
you
resolve
a
did
to
a
public
key,
so
you
can
verify
that
message.
There's
still
some
interrupt
work
to
be
done
to
be
honest,
but
for
a
verifiable
cadential
perspective,
it
doesn't
really
matter
what
kind
of
ditch
you
use,
so
you
don't
have
to
validate
them
against
the
microsoft
environment.
They
are
independent
of
that.
B
So,
when
you
issue
verifiable
credentials
that
has
nothing
to
do
with
this
decentralized
system.
The
digitalized
system,
just
to
be
clear,
the
digitalized
system
is
only
used
for
the
identifiers,
so
did
in123
or
did
alice
did
froze
where
those
are
like
anchored
to
that
digitalized
database.
So
you
can
actually
look
up
those
public
keys,
but
verifiable
credentials
have
nothing
to
do
with
that.
We
issue
variable
credentials.
We
sign
it
with
the
the
private
key
of
any
of
those
identifiers,
so
yeah
for
that.
In
that
case,
we
don't
need
a
lot
of
speed.
B
What
we
did
people
we
worry
about.
How
many
transactions
you
can
do
ion
is
an
site
3
implementation
on
top
of
a
digitalized
ledger
which
gives
you
you
know
tens
of
thousands
of
transactions
per
second,
so
we're
not
worried
about
the
transaction
speed
here
at
all.
But
again,
that's
only
done
when
you
are
actually
creating
new
identifiers.
So
you
don't
do
that
that
often
all
right,
you
want
to
show
a
demo
of
how
this.
A
Could
work
yeah?
Let
me
just
do
a
quick
demo
and
I'm
sure
in
the
meantime,
we
can
catch
up
on
the
remaining
questions.
So
let
me
bring
in
my
browser
screen
as
well
as
let
me
do
a
quick
phone
mirroring.
So
the
first
demo
that
we
will
do
is
just
a
baselining
demo
just
to
make
sure
that
everybody
understands
the
flow
and
yeah.
So
I'm
gonna
also
do
four
metering
and
bring
in
that
experience.
A
A
We
have
marked
this
demo
link
on
the
deck
as
well,
so
you
can
obviously
play
with
the
demo
after
we
are
done
with
the
event,
so
think
of
an
onboarding
scenario.
Think
of
if
the
way
you
were
unloaded
in
the
organization
can
we
make
that
process
simple.
Think
of
how
you
received
an
email
from
hr
hr
told
you
to
do
a
bunch
of
onboarding
tasks.
At
that
time
you
had
to
do
a
bunch
of
trainings.
A
A
So
let
me
just
open
the
authenticator
app
as
well.
So
there
are
some
logos
that
you
see
on
our
site.
These
logos
are
also
on
our
public
documentation
portal
as
well.
So
we
have
done
some
integration
with
isv
partners
who
can
help
with
identity
proofing
and
verification
activities.
So
one
of
it
could
be-
let's
say,
for
example,
true
id,
so
the
new
person
you
hire
would
be
told
to
initiate
a
verification
process
and
the
standard
flow.
A
Hey,
take
a
selfie
move,
your
head
left
and
right
so
that
we
know
who
you
are
and
upload
a
government
document.
So
this
could
be
a
driving
license
and
the
user
will
click
on
next.
To
complete
this
set
of
prerequisites,
the
idv
will
do
its
magic
verify
the
data
they
will
use.
Some
of
them
are
using
cognitive
services
as
well
as
your
cognitive
services.
Once
the
verification
is
complete,
they
can
present
a
qr
code
to
the
user,
the
q,
the
user
can
at
this
time
they
don't
have
a
employee
id
in
the
organization.
A
So
for
the
remote
sign-in
process
you
can
see,
we
have
showcased
a
pin
experience,
so
the
user
will
scan
the
qr
code
and
the
user
will
see
a
true
identity
card
user
can
specify
the
pin
and
click
on
add
to
accept
the
card.
If
I
double
click
on
the
card
and
click
on
credential
info,
you
can
see
the
bunch
of
details
that
were
captured
as
a
part
of
the
initial
onboarding
process.
Now
the
user
will
go
back
to
the
onboarding
portal
and
would
go
to
the
second
block.
A
A
The
user
will
see
that
the
application
is
asking
for
true
identity
vc,
the
user
will
hit
on
allow
the
application
would
do
the
verification
of
vc
and
then
once
it
is
done,
it
will
take
the
details
from
the
payload
and
it
says:
okay,
matthew,
hey
welcome
to
woodgrove.
Would
you
like
to
have
your
employee
card
as
well
in
digital
format,
so
matthew
can
scan
the
qr
code?
A
Specify
the
employee
id
which
could
be
used
as
pin
here
and
matthew?
Can
then
add
the
woodgrove
verified
employee
card?
Now?
What
next
math
you
can
do
think
of
your
day?
One
onboarding
task.
Maybe
I
will
go
to
it
and
order
myself
a
hardware.
The
same
experience
could
be
demonstrated
here,
so
the
user
will
click
on
prosway.com
and
this
could
be
a
non-federated
app
as
well.
A
So
user
can
see
that
there
are.
There
is
a
marketplace
available.
User
can
select
a
hardware,
but
if
the
user
wants
corporate
discounts
they
can
specify
and
present
their
woodgrove
vc.
So
you
can
see
the
experience.
The
user
user
scan
the
qr
code.
The
application
is
asking
for
the
verified
employee
card
user.
Will
click
on
allow.
A
And
application
in
this
case
prospered.com
will
do
the
verification
magic
and
you
can
see
once
the
credential
was
verified.
The
application
applied
its
business
logic
and
is
offering
now
discounts
to
the
user.
So
that's
a
quick
demo,
but
what
is
powering
this
demo?
Let's
go
into
the
weeds
of
it,
so
mathis
I'm
going
to
pass
on
the
control
back
to
you
so
just
to.
B
Come
back
to
the
demo
of
what
we
just
showed
you,
we
set
it
up
without
any
federation
right
so
pros
where
just
ask
for
a
workplace
credential
type,
and
they
have
a
partner
network
where
they
said
well,
we
can
accept
this
credential,
they
figure
out
who
it's
coming
from
and
they
decide
what
kind
of
discount
goes
with
it
in
the
past.
This
would
be
of
all
I
have
to
be
able
to
log
in
with
my
own
workplace
account
federation
had
to
be
set
up.
This
is
another
way
of
of
of
doing
that
kind
of
scenario.
B
Another
scenario
we've
seen
is
where
you
have
to
prove
certain
certifications
before
you
can
allow
access
to
a
certain
application
or
a
sign
in
well.
You
can
create
an
api
to
your
learning
system.
If
there's
one,
that's
easy,
if
there's
a
several
one,
it's
a
bit
more
work
or
you
can
ask
the
user.
Well.
Can
you
present
your
certifications,
these
ones
before
we
allow
you
access
to,
and
it's
actually
a
scenario
we've
done
a
couple
of
times
with
pilots
as
well
to
come
back
on
the
comment
on
the
on
the
chat.
B
If
you
do
id
verification,
there's
several
ways
of
doing
that,
so
this
is
nothing
to
do
with
farewell
credentials
itself.
This
is
a
way
how
different
id
verification
partners
do
id
verification.
In
some
cases
they
said
well
give
you
a
driver's
license
and
they
match
your
face.
Your
selfie
with
the
photo
on
the
driver's
license
and
the
one
stored
at
the
dmv
to
make
sure
it's
really
you
other
folks,
just
ask
you
like
five
questions:
did
you
live
on
your
file
in
your
name?
Did
you
live
on?
Any
of
these
addresses.
B
B
B
So
you
as
a
developer,
don't
have
to
worry
about
oidc,
sciop
or
presentation
exchange
or
the
different
layers
of
how
you
verify
firewall
credentials
and
check
signatures
and
all
that
kind
of
stuff.
So
that's
what
we
try
to
do.
We
don't
store
any
pai
on
the
chain.
What
we
store
on
the
chain
are
identifiers
or
files
for
the
document.
So
the
only
things
we
store
in
those
the
documents
is
the
public
key
and
maybe
a
domain
name.
B
B
B
B
B
B
B
B
And
press
this
is
verified
and
I
retrieved
the
first
name
last
name
from
this
credential.
You
can
now
see
that
it's
actually
being
used,
but
the
information
is
indeed
coming
from
from
this
verifier
credential
and
it's
a
very
rough
ui,
but
the
sample
is
about
explaining
how
the
concepts
work.
So,
let's,
let's
look
at
a
bit
of
the
code.
B
So
this
is
the
project
structure.
It's
an
asp.net
core
web
application.
We've
got
two
controllers
which
are
interesting:
the
issuer
controller
and
the
verify
controller
the
app
settings.
This
is
the
single
place
where
we
store
information
about
your
tenant,
there's
a
client
id
and
a
secret.
This
is
what
we
need
to
authenticate
against
the
api,
so
we
know
it's
coming
from
you.
We
assume
you
already
have
set
up
the
fire,
hubble
credential
issue
and
service,
and
I
think
rawit
can
share
the
link
how
to
do
it
yourself.
B
Everything
is
done
through
ditch
right.
We
either
issue,
or
did
we
issue
a
credential
and
you're
the
issuer?
You
want
to
accept
a
credential
from
a
certain
issuer,
that's
something
we
put
in
here
and
one
thing
you
have
to
do
and
we'll
show
in
a
minute
how
it
looks
like
is
you
have
to
create
your
own
credential?
B
So
in
this
case
we
have
a
fair
vowel,
credential
expert
with
a
certain
card
definition:
the
logo,
the
color.
We
have
a
first
name
last
name
we're
going
to
store,
that's
something
you
have
to
define,
and
then
you
call
it.
So
if
you
look
at
the
issuer
website,
it's
a
simple
website
and
when
you
click
on
the
button,
it
will
call
a
api
called
issuance
request.
This
is
in
the
issuer
controller
and
after
you've
done
that
it
will
start
a
timer
every
one
and
a
half
seconds
which
will
just
check.
Are
you
done
yet?
B
B
This
is
the
method
which
will
be
called.
If
you
click
the
button
and
what
it
will
do
is
it
will
read
the
issues
request
which
will
show
you
exactly
how
this
thing
looks
like
I
fill
in
the
blanks
from
the
configuration
and
that's
what
we
do
here,
I
specify
a
state
for
the
callback,
so
we
can
like
actually
figure
out.
Are
you
done
yet?
Are
you
done
yet
from
the
right
from
the
right
user
and
what
we
do
here?
We
fill
in
a
first
name
and
last
name.
So
what
we
do
support?
B
I
think
people
are
familiar.
What
we
did
with
the
sdk
there's
a
few
things
you
can
do
when
you
create
a
variable
credential
and
you
can
define
how
that
the
claims
in
the
variable
credential
are
filled.
There's
a
few
ways
of
doing
that.
You
can
ask
the
user,
what's
your
favorite
color
and
they
have
to
enter
another
indicator.
You
can
actually
ask
for
another
favorable
credential
as
input,
and
we
can
use
an
id
token.
You
can
get
the
id
token
to
two
ways.
You
ask
the
user
to
sign
in
to
an
odc
endpoint.
B
So,
for
example,
you
ask
them
to
sign
in
instead
of
authenticated
to
ad
or
b2c
or
any
other
odc
compliant
endpoint,
or
what
we
can
do
now,
and
this
is
new
with
the
api
first,
the
sdk.
We
can
actually
provide
a
payload
and
we
create
an
id
token
hint
which
you
can
map
in
that
inside
of
the
private
credential
as
well.
So
what
we
did
here
is
we
actually
have
a
payload
with
a
first
name
last
name.
B
B
B
B
B
Issuance
and
verification
have
pretty
much
the
same
flow,
the
type
of
callback
messages
you
will
see
or
might
be
a
bit
different,
but
conceptually
it's
the
same.
So
let
me
just
so.
We
got
a
website
a
web
app
which
presents
a
website.
The
website
is
asked
to
show
a
qr
code.
That's
when
you
hit
the
button,
we
call
the
api
and
the
api
will
actually
return
an
address.
You
would
build
in
a
qr
code.
B
The
javascript
on
the
page
also
see
if
the
web
app
actually
is
done.
Meanwhile,
the
web
application
will
receive
callbacks
from
our
servers,
so
whenever
a
user
scans
a
qr
code,
it
downloads
the
request
from
our
service.
We
send
you
a
call
back
when
you
are
done
with
the
issuance,
so
people
accept
the
variable
credential
or
when
you're
presenting
they
presented
the
variable
credential.
B
B
So
when
I
click
on
the
get
credential
button,
the
web
app
will
call
our
api.
It
will
get
an
access,
token
authenticate
and
we'll
send
a
specific
payload
and
inside
of
the
payload
among
things
is
the
callback
address
our
service
has
to
call
back.
We
return
the
address
of
the
issues
request.
So
what
authenticator
needs
to
download
is
a
specific
request,
while
issuing
we
created,
requests
it's
too
big
to
fit
inside
of
a
qr
code.
So
what
we
do
we
send
an
uri
to
that
request
and
that's
what
we
put
in
the
qr
code.
B
B
B
And
what
we
see
here
in
the
middle
is
the
the
public
key
and
we
also
have
a
linked
domain
and
we
use
the
link
domain
to
validate
if
the
issuer
and
multiverifier
actually
own
that
domain
to
a
standard
wave.
But
every
time
you
have
it
did
you
can
always
resolve
it
to
this
public
key,
which
you
then
can
use
to
verify
messages
and
that's
what
we
do
as
well.
B
Then,
if
that's
all
checks
out
or
you
want
to
use
a
look
that
might
not
be
secure.
Are
you
sure
you
want
to
continue?
Then
we
download
the
request
from
the
microsoft
services,
so
the
qr
code
points
to
that
address
and
if
you
download
the
request,
we
immediately
remove
it.
That's
the
reason
why
we
hide
the
qr
code.
We
can
use
it
because
you
can
only
scan
it
once
we
call
back
the
web
apps
yep
somebody
scanned
the
qr
code.
So
when
the
browser
asks
for
the
status
to
the
web
app,
are
you
done
yet?
B
Are
you
done
yet?
Oh
yeah,
somebody
read
the
qr
code.
We
get
that
result
back,
so
we
can
hide
it
from
the
screen.
That's
what
happens
when
you
saw
the
the
change
in
the
ui,
then
authenticator
has
to
download
the
credential
and
I'll
show
you
in
a
bit
how
that
looks
like
that's
the
definition
of
the
display
file.
How
does
it
look
like
what
kind
of
claims
you
want
to
collect
from
the
user,
etc?
B
The
user
accepts
the
variable
credential
in
the
wallet
post,
the
information
back
to
our
servers
and
it
will
get
issued
a
signed,
verifiable
credential.
We
do
a
call
back
to
the
web
app
to
tell
your
app
like
look.
Somebody
has
actually
finished
issuance
and
it's
completed
either
successfully
or
was
a
failure.
B
Meanwhile,
the
browser
still
checks
like
are
you
done
yet?
Are
you
done
yet
and
since
the
state
has
changed
in
the
back
at
the
back
end
and
we'll
see
oh
yeah,
somebody
is
done
and
it
will
update
the
ui
that
the
the
the
service
was
done
and
meanwhile,
the
science
variable
credential
is
returned
to
the
wallet
and
the
user
is
now
ready
to
present.
B
So
the
request
of
that,
what
was
the
qr
code,
pointing
to
it's
a
request?
Again,
everything
is
a
jot.
It's
signed.
You
can
actually
paste
this
in
jot.ms
and
you
will
see
the
contents
and
it
looks
like
this
when
you
want
to
issue
a
credential.
There
needs
to
be
there's
a
specific
format
you
have
to
have
prompt
create.
That
means
it's
issuing
it's
a
presentation
definition.
B
B
So
verification
is
the
other
way
around
again.
We
call
that
button
get
a
verified
credential,
which
calls
the
api
with
a
specific
payload.
We
return
the
address
of
the
request
you
just
saw.
The
browser
puts
that
address
in
a
qr
code.
Authenticator
can
scan
again.
We
check
the
the
did
from
the
from
the
verifier
and
the
reason
we
want
to
do.
It
is
because
we
want
to
resolve
the
debt
to
the
document.
We
can
check
the
signatures,
but
we
also
check
the
domain.
B
When
you
are
storing
personal
information
and
variable
credentials,
you
want
to
make
sure
that
users
are
comfortable
sharing
that
information
with
somebody
else.
So
what
we
do
is
we
verify
that
this
issuer
is
actually
owning
the.
In
my
case,
I
use
my
own
domain.
I
own
this
domain
and
that's
verified.
This
is
what
the
wallet
will
do
for
you.
That's
the
reason
why
we
resolve
the
did
get
that
domain
name
from
the
document
and
verify
if
it's
legit,
if
the
check's
out
the
request
is
downloaded,
callback
is
done
to
the
web
app.
B
So
look
somebody
actually
scan
the
qr
code.
You
can
hide
it
now.
That's
what
we
do
here.
The
user
is
asked
to
select
which
verify
credential.
They
want
to
share,
so
they
own
that
process
and
if
they
have
multiple
ones
they
can
check
which
one
they
want
to
use.
They
post
back
that
variable
credential
to
our
service.
We
will
do
the
validation.
Are
the
signage
is
correct.
It's
a
subject
expected
to
be
what
it
is,
etc
and
the
result
will
be
sent
back
as
a
callback
to
the
web
application
again
either.
B
Both
failure
and
success
will
be
posted.
Meanwhile,
the
browser
still
calls
like
hey.
Are
you
done
yet?
Are
you
done
yet
and
if
the
variable
credential
actually
is
presented
correctly,
it
will
return
the
payload
of
the
firewall
credential
in
our
case
and
show
that
on
the
screen
that
was
very
quickly
how
the
sample
flow
worked.
So
rory
can
you
show
some
of
the
api
payloads
and
how
it
actually
works
and
what
our
backend
is
actually
expecting
from
the
developer.
A
Sure
so,
just
to
bring
my
postman
screen,
we
will
be
posting
these
postman
collection
on
our
github
sample
repo,
but
just
to
give
you
a
quick
snapshot,
the
details
of
the
specification
are
also
on
our
documentation.
Page
now,
which
went
live
last
monday.
So,
as
you
can
see
in
my
postman,
there
is
an
http
post
request
going
to
the
request
service
api
and
the
endpoint.
I
have
a
variable
called
tenant
id
called
out
in
my
request.
Api.
A
So
I'll
do
the
demonstration,
but
let
me
just
quickly
walk
you
through
the
request
api,
as
well
as
the
payload
that
we
have
so
what
you
saw
in
the
dot
net
sample
app.
I
think
you'll
be
also
able
to
relate
to
that.
So
there
are
certain
things
that
we
have
in
the
payload.
Things
like
there
are
some
boolean
values
like
include
qr
code
authority
talks
about
the
issuers,
a
decentralized
identifier.
A
Then
we
have
registration
which
provides
information
about
the
issuer
that
can
be
displayed
when
the
user
is
interacting
with
the
authenticator
app
and
then
you
see
a
parameter
called
issuance.
This
is
for
the
issuance
request
and
then
there
is
a
callback
section.
So,
as
a
developer,
you
can
get
async
information
of
the
flow
for
the
whole
vc
issuance
process.
Like
a
call
when
the
user
has
scanned
the
qr
code,
you
can
specify
those
details
and
if
you
remember,
mathias
was
calling
out,
pin
and
the
work
that
api
will
provide
you.
A
So
you
can
use,
pin
as
a
payload
and
in
this
example
you
can
see.
There
is
a
manifest
that
I'm
using
this
manifest
is
created
on
my
subscription
and
the
credential
type
is
verifiable
credential
expert.
But
before
I
use
this
post
request,
I
will
have
to
get
an
access
token
so
that
I
can
reach
out
to
my
endpoint.
So
let
me
get
the
access
token
I'll
use
the
token,
and
I
will
now
send
out
the
issuance
request
with
the
payload.
A
So
what
we
have
done,
as
we
will
send
you
the
postman
sample.
We
have
added
a
script
code
which
will
take
the
response,
look
for
the
image
source
and
it
can
help
you
see
a
qr
code
in
the
postman
itself.
So
let
me
just
show
you
by
scanning
this
qr
code.
I
still
have
my
phone
mirroring
on
and
I'm
going
to
scan
the
qr
code,
I'll
specify
the
pin
and
I'll
accept
this
vc,
and
you
can
see
this
was
set
up
with
id
token
hint
as
the
model.
A
So
the
claims
like
first
name
last
name-
I
have
specified
that
in
the
payload.
So
as
you
build
applications
and
you
are
trying
to
use
api,
you
can
programmatically
pass
the
claim
values.
Think
of
a
scenario
where,
let's
say,
if
a
user
is
logging
to
a
website,
you
can
capture
claims
from
the
id
token
you
can
do
a
rest.
Api
call
to
another
system
combine
that
together
in
the
issuance
payload
stamp
it
as
claims
and
then
pass
it
as
a
part
of
the
issuance
payload
to
the
api.
So
that's
a
simple
demo
around
issuance.
A
Similarly,
on
presentation,
there
are
a
few
things
that
I'll
call
out.
If
you
look
at
the
payload,
the
authority
did
in
this
case
is
the
date
for
the
verifier
and
there's
another
section
that
you
see
here
called
accepted
issuer.
So
I
can
say
I'll
accept
the
credential
of
type
verifiable
credential
expert
from
the
issuer,
which
has
this
data.
As
a
number,
so
this
could
be
an
array
you
can
use
comma
separated
values.
So
let
me
just
hit
on
send
and.
A
And
that's
it
so
you
can
see
there's
another
demo.
I
can
show
you.
Let's
say
if
you
remember
in
the
previous
wood
grove
employee
demo,
I
had
received
a
vc
from
true
identity,
so
I
can
show
you
that
experience
as
well.
In
this
case,
my
accepted
issuer
is
the
dead
for
true
identity,
I'm
sure
everybody's
comfortable
with
the
postman
and
environment
variable.
So
I
need
not
go
to
the
environment
section,
but
you
can
see
when
I
scan
this
request.
A
A
So
let
me
show
you
the
payload
for
an
experience
where
I
have
to
present
two
vcs,
the
verifiable
credential
expert
and
true
identity,
as
you
can
see
in
the
payload
and
for
each
of
the
credential
type,
I
can
specify
the
purpose
like
the
verifiable
credential
expert
is
to
prove
that
I
am
an
expert
while
true
identities,
to
verify
my
real
identity.
So
I
can
submit
this
post
request.
I
can
hit
on
visualize
and
when
I
will
scan
the
qr
code
you
can
see
now
the
experience
is
asking
me
to
present
both
the
vcs.
A
B
Man
there's
so
many
good
questions
on
the
chat,
so
I
thank
you
for
all
the
interactivity
yeah.
So
if
you
can
put
up
the
the
poll
here,
so
one
question
we
have
for
you
folks
is
you
saw
that
we
do
the
callback
right
when
the
qr
code
is
scanned
and
also
when
the
firewall
credential
is
presented
or
we
issue
in
the
callback
at
the
moment
is
you
can
specify
an
api
key,
but
we
had
some
questions.
B
Maybe
we
should
do
odd
or
we
do
it
like
how
microsoft
graph
is
doing
web
hooks
where
you
create
a
subscription,
you
have
to
respond
with
that,
but
identify
you
get
back
to
proof
ownership
or
maybe
there's
another
way
of
doing
this.
What
would
be
your
preferred
way
to
protect
the
callback
api
you
are
hosting
and
to
be
transparent
for
all
the
pocs?
We
have
done
so
far.
B
So
nobody
well.
Nobody
there's
a
few
people
who
actually
like
the
microsoft
graph
web
book
way,
I'm
not
sure
if
everybody's
actually
familiar
with
that
way,
but
that's
okay,
but
a
lot
so
far.
Okay,
good!
Thank
you
all
or
no
or
yeah,
and
then
it's
all
optional
right.
So
during
development
yeah,
let's
be
honest,
nobody
cares
yeah.
So
the
one
thing
is
that
if
our
service
is
running
from
80,
we
can
only
do
80
access
tokens
right.
So
we're
not
going
to
build
something
where
you
have
to
register
an
app.
B
We
specify
client
that
ease
and
secrets
to
authenticate
and
then
another
idp.
Technically
we
could
do
it,
but
yeah
managed
identity
should
be
possible
too
yeah.
Okay,
next
slide.
Thank
you
before
we
close
off
on
futures
and
all
that
was
this
any.
What's
this
way
of
presenting
useful
that
you
find
this
helpful
to
understand
both
the
api,
but
also
variable
credentials.
B
A
B
Yeah
so
a
few
things
which
we're
doing-
and
this
is
why
I
like
the
api-
a
lot
is
that,
for
example,
there's
a
standard
way
of
asking
for
specific
parallel
credentials.
We
showed
a
very
simple
way
with
where
we're
going
to
ask
for
a
verifiable
credential
expert,
a
row
heat
the
payload,
to
ask
for
two
credentials
the
the
standard
used
for
that
is
presentation
exchange.
We
will
paste
the
link
in
the
in
the
chat.
B
What
it
means
is
that
we
can
be
more
specific
in
the
questions
we're
gonna
ask.
Show
me
a
driver's
license
from
the
dmv
or
a
passport
from
state
of
foreign
affairs.
Show
me
a
government
id
or
a
no
no
library
card
from
kane
county.
You
can
be
more
specific
in
the
questions
you're
going
to
ask
the
wallet
or
prove
that
you're
older
than
21,
by
allowing
these
three
four
credentials
from
these
three
four
issuers.
B
B
I
think
the
big
move
right
now
is
we're
gonna
put
it
behind
microsoft.
Graph,
like
people
are
probably
familiar
with
all
the
apis.
We
publish
as
microsoft
both
in
mcc
five
as
our
identity
platform.
We'll
do
that
with
our
apis
as
well.
That's
just
some
work
we
have
to
do
and
we
didn't
want
to
wait
and
we're
still
waiting
for
some
apis
for
a
developer,
to
be
able
to
create
credentials
and
manage
those
revoke
credentials.
B
We've
not
talked
about
it,
but
we
actually
have
a
ui
where
you
can
revoke
credentials
and
you
decide
how
you
can
find
those
credentials.
I
think
I
I
said
it
in
the
chat.
We
don't
store
any
information
about
variable
credentials
in
our
backend
system.
So
if
we
don't
store
anything,
how
can
you
revoke
a
credential,
so
you
can
as
a
developer,
decide
you
know
what
I
want
to
index
this
claim,
for
example,
email
and
then
you
can
search
for
that
email
address.
We
don't
store
it
like
in
clear.
B
We
hash
it
and
we
will
compare
the
hash
and
then
you
can
like.
Well,
I
want
to
revoke
this
variable
credential,
so
the
user
can't
use
it
anymore
and
that's
going
to
be
behind
an
api
as
well.
Obviously
so
yeah
those
are
the
most
urgent.
The
next
steps
we
have
to
do
so
put
it
behind
graph
with
more
apis
and
adobe
preview.
For
you
folks
hide
away
the
complexity
of
the
protocols,
that's
something
we're
already
doing
so,
while
the
wallet
and
our
back-end
service
will
be
updated,
you
as
a
developer,
don't
have
to
change
anything.
B
I
do
have
one
question,
though
I
thought
sahil
your
your
remark
about
useful
session,
but
not
enterprise
ready.
Yet
I
don't
know
if
you
can
clarify
a
bit.
What
you
think
is
missing
to
be
enterprise
ready.
We
are
still
in
preview,
so
we
are
not
ready.
Yet
we
realize
that,
but
just
curious.
What
you
think
is
is
missing,
or
we
should
should
modify
or
do,
and
we
still
have
some
time
for
some
other
scenarios
as
well.
If
you
can
type
it
or
speak
up
on
the
on
the
mic,
that's
fine
as
well.
B
B
The
guy
at
the
door
is
typically
not
interested
if
you're
still
allowed
to
drive
a
car
they're.
Only
interested
in
are
you
older
than
21,
so
an
expired
or
even
a
revoked
driver's
license
can
still
be
used.
For
that
scenario,
that's
not
different
online.
You
want
to
buy
alcohol,
prove
that
you're
older
than
21.
You
could
use
an
expired
driver's
license,
or
maybe
even
a
revoked
driver's
license
that
you
did
something
stupid
on
the
road.
B
Probably
doesn't
matter
for
folks
when
they
allow
you
to
do
that
things.
The
scenario
where
people
are
allowed
on
the
work
sites
by
having
certain
certifications,
safety,
certification,
all
that
stuff,
then
expiration,
is
actually
a
problem,
so
they
won't
allow
you
on
the
site
if
it's
expired.
So
this
is
typically
a
business
rule
on
the
verify
side
to
to
decide
that,
would
it
be
possible
to
use
this
for
offline
odd
end
scenarios?
B
Yes,
it
could,
if
you
run
your
own
iron,
node
on-prem,
and
you
resolve
the
ditch
against
that
one,
and
you
write
your
own
verification
logic,
for
if
you
use
variable
credentials,
but
you
could
just
use
it
all
then
yeah
you're
not
relying
on
any
services
at
all.
That's
actually
the
beauty,
I
think
for
the
ideas.
B
It's
a
huge
decentralized
database.
So
if
you
receive
any
message
signed
by
anybody,
you
can
always
verify
that
and
nobody.
Nobody
in
the
world
can
actually
prevent
you
from
doing
this.
If
you
follow
our
colleagues
on
twitter,
you
will
see
how
fanatic
they
can
be
about
this
topic.
We
believe
that
putting
the
user
in
control
of
their
own
identity
be
able
to
protect
privacy
them
deciding
when
and
how
to
use.
Those
identities
is
something
we
want
to
pursue.
That
doesn't
mean
that
you
cannot
be.
B
You
know,
kicked
out
of
using
a
microsoft
service
or
facebook
or
whatnot,
but
there's
no.
It
should
not
be
possible
for
a
single
authority
to
kick
you
off
and
cancel
your
entire
identity.
Your
identity
consists
of
a
lot
of
different
things
and
you
should
be
in
control.
That's
the
premise:
we
try
to
do
with
the
ideas.
That
also
means
that
you
cannot
have
a
did
which
can
be
cancelled
by
somebody.
A
So
as
as
you
take
the
question,
let
me
just
make
sure
the
last
poll
also
come
resources
and
last
poll,
so
I
think
we've
showed
a
dot-net
sample,
so
we
will
leave
the
link
on
the
chat
you
can
review
the
sample.
There
are
links
to
python
java
node.js
as
well
the
demo
that
you
saw
from
me
the
wood
groove
demo
there
we
have
a
link
for
that
too,
and
the
documentation
the
api
specs
are
also
there
and
link
to
our
sample
application.
A
C
We
haven't
covered
b2c
in
a
while,
but
thank
you
everyone
for
attending
today's
call
and
for
being
so
engaged.
We
really
loved
your
questions
and
all
your
comments
and
all
the
feedback,
like
I
said,
we're
still
in
learning
mode
in
this
space.
So
this
is
all
very
useful
to
us,
so
I
posted
a
link
also
on
where
you
can
find
the
recording
next
week,
all
right.
So
thank
you,
everyone
and
thank
you
so
much
rahid
and
matthias.