►
From YouTube: IETF-SATP-20230411-1400
Description
SATP meeting session at IETF
2023/04/11 1400
https://datatracker.ietf.org/meeting//proceedings/
A
A
Happy
to
get
off
now,
if,
if
we're
comfortable
as
many
people
as
possible,
have
signed
in
we've
got
10
in
the
room,
so
that's
fairly
a
good
number
for
our
group.
So
to
start
with
I'll
just
run
through
the
agenda
quite
quickly,
I've
had
no
requests
to
update
the
agenda
from
the
template,
so
it'll
be
our
standard.
A
What's
on
who's
our
Note
Taker
and
invite
some
discussions
and
updates
from
the
authors
and
then
discussions
of
items
and
issues
and
that
have
come
up
in
the
mailing
list.
I
think
the
main
one
I
think
Rama
has
been
handling
I'm,
not
sure
he
is
brilliant,
so
Rama
I'm,
probably
going
to
invite
you
to
to
talk
for
a
moment
or
two
on
the
iso
2022
standards
that
you've
been
working
on,
as
well
as
the
other
elements
that
have
been
happening
so
without
further
Ado
can
I
nominate.
A
C
A
couple
of
things
stood
out.
There
was
a
comment
from
John
Levine
about
comparing
with
ISO
200
I
had
I
need
to
set
the
correct
way
to
20,
220,
200
or
20,
or
something
like
that
and
and
I
think.
That
would
be
a
good
idea
for
us
to
do
anyway,
because
it
is
a
a
n
ISO
standard,
that's
being
adopted
and
deployed
widely
by
the
banking,
Community
and
I.
Think
it's
it's
part
of
the
you
know
open
banking,
PSD,
sort
of
development.
C
That's
that's
been
happening,
so
I
I,
you
know
I
I
know
who's
going
to
do
that.
I
mean
I'm.
I'm,
happy
to
you
know
to
to
get
help.
I'm
happy
to
you
know,
look
at!
You
know
how
we
compare
against
that
ISO
220
standard,
but
I
would
need
assistance,
let's
just
say
and
I.
Think
I,
don't
know
where
we're
gonna
put
the
text,
but
I
believe
Clarin
was
I.
Think
we
thought
would
put
it
somewhere
in
the
architecture
document
AI.
A
Yeah
I
think
that
was
what
was
suggested
in
the
working
group
was
that
they
probably
lived
in
the
architecture
document
in
terms
of
other
protocols
that
were
out
there
that
we
were
comparing
to
and
why
we
feel
that
the
iso
2022s
or
however
you
pronounce
it,
don't
quite
cover
the
elements
needed.
I.
Think.
C
Great
great,
thank
you
thank
you.
That
was
that
I
was
hoping
that
that
we've
already
started
discussion
and
I
I
I
do
know
some
people.
You
know.
Even
you
know
on
this
call
today.
You
know
at
least
their
companies
have
people
who
are,
you
know,
participating
or
even
using
that
standard.
So
that's
it's
a
it's.
A
good
sort
of
you
know
Community
to
to
answer
the
question.
C
I
think
the
other
own.
The
only
other
thing
is
that
I
need
to
fix
a
typo
in
the
message.
Flow
diagram,
I.
Think
this,
the
misnumbering
I
think
two
point
step:
2.3
2.4
needs
to
be
relabeled,
but
but
that's
kind
of
about
it
and
I
will
do
that
today
and
upload
it.
As
version
17
of
the
message
flow
diagram.
C
D
C
A
I
know
that
a
lot
of
people
struggle
to
make
it
due
to
the
time
zone
difference.
So
so
thank
you
to
those
that
could
did
anyone
have
any
questions
about
how
the
Yokohama
working
group
went
or
anything
they
wanted
to
add
to
the
agenda.
I
know:
we've
had
something
come
through
in
the
last
20
minutes
and
which,
of
course,
we
can.
We
can
come
to
in
the
end
from
Rama,
so
we
can
absolutely
get
around
to
that.
If
we've
got
time,
anyone
else
have
any
agenda
knits
to
add.
B
B
C
So
what
that
means
is
that
you
have
a
like
a
DLP
that
actually
has
multiple.
You
know:
Fiat
backed
currency
tokens,
you
know
running,
you
know,
and
it's
a
it's
a
private
permission
network
of
course.
Needless
to
say
so
so
some
folks
in
Japan
are
looking
at.
You
know,
exploring
that
and
the
question
I
had
as
well
like
how
does
how
does
satp
work
there?
Can
you
know,
can
you
move
an
asset
from
you
know
one
network
to
another
and
what
would
be
the
use
case
for
this?
C
Because,
because
it's
now
it's
not
like
tokenized
physical
assets,
it
is
now
you
know
something
like
a
like.
A
currency,
a
government-issued
currency
and-
and
my
my
quick
answer
to
that,
was
that,
yes,
you
know
we
could
we
secretly
could
do
that
and
I
think
I
was
emailing
Rama
earlier.
That
I
would
like
to
add
a
use
case
or
sub-use
case
of
the
cbdc
section
in
the
use
cases
document
to
explain
how
this
multi-cbdc
could
be
addressed
using
satp.
B
E
Hello,
hello,
everyone,
yes,
I
mean
if
we
brought
a
bit
the
picture
of
that.
Thomas
was
just
explaining,
maybe
the
case
that
we
have
fungible
tokens,
both
sides
that
are
exchanged.
It's
something
that
probably
we
should
have
a
look
at,
because
we
assume-
or
maybe
it's
my
understanding-
that
in
the
flow
diagram
that
we
have
now
in
version
17.,
we
have
like
creating
and
destroying
assets
which
is
okay
for
a
non-fungible.
E
A
Absolutely
I
think
this
speaks
to
sort
of
the
the
overarching
scope
in
that
our
solution
should
be
agnostic
to
whichever
assets
are
being
transferred.
So
it's
definitely
worth
making
sure
that
any
solution
that
we've
come
up
with
in
the
solution
we
have
so
far
is
applicable,
and
it's
definitely
something
we
should
probably
check
off.
A
That
does
bring
me
on
to
something
else
that
was
part
of
the
agenda
in
the
working
group
and
I.
Don't
know
how
many
people
have
been
able
to
read
the
minutes
and
some
of
the
takeaways
and
one
of
those
takeaways
Wes
and
I
will
send
a
communicator
to
the
the
working
group
to
the
mailing
list.
Regardless
was
to
have
a
discussion.
We
had
a.
We
had
a
vote
in
the
room
which
came
away
positive
in
terms
of
are
the
documents,
as
is
ready
for
adoption
now.
A
So
we
will
put
that
on
the
mailing
list.
So,
if
I
could
ask
everyone
to
come
back
and
put
a
vote
on
that,
we
can
then
take
our
current
working
documents
and
have
them
as
official
working
group
documents,
which
is
part
one
of
the
process
which
is
part
of.
If
you
want
to
have
a
look.
If
you
go
on
to
the
data
tracker,
I
think
the
agenda
slides
are
still
up
there,
so
you
can
have
a
look.
A
B
Up
yeah,
so
with
the
documents
we
I
think
a
few
weeks
ago,
we
talked
about
this
vocabulary
document
that
Dennis
and
I
have
been
contributing
to,
and
also
Thomas
and
Rama.
It's
currently
just
on
GitHub.
Do
we
want
to
make
it
an
official
document
as
part
of
our
I
guess
folder,
so
we
can
upload
it
on
the
ITF
website
and
included
alongside
the
drafts,
or
are
we
okay
with
just
having
it
as
an
informal
page
on
GitHub.
F
Yeah,
so
the
working
group
does
have
an
official
repository,
which
is
a
good
place
to
store
documents,
and
we
can
have
the
repository
moved
there
and
then
once
it's
typically,
we
do
that
after
it's
accepted
as
a
as
a
working
document,
so
Claire
and
I
will
start
that
call.
You
know
if
the
official
call
after
the
meeting
ends
and
it'll
take.
You
know
two
weeks
and
we'll
ask
for
input
on
the
working
group
mainly
list.
F
Accepted
but
you
know
officially,
we
go
through
a
two-week
process
of
of
making
sure
everybody
agrees
that
this
is
the
right
direction
for
the
working
group
to
go,
and
these
are
the
right
starting
documents
and
yada
yada
and
then
yeah.
We
can
move
that
GitHub
repository
to
the
official
working
group.
One
is
definitely
the
right
thing
to
do.
A
D
D
G
G
A
A
H
So
it's
actually
going
to
be
Bishop
who's,
also
on
the
call
who
will
present,
but
just
before
we
turn
to
that
topic.
Since
you
asked
about
the
comparison
to
ISO,
2002
I
saw
that
Thomas
and
John
had
an
a
short
Email
exchange
and
I
I
do
plan
to
write
something
more
substantial
on
the
email
on
the
mailing
list.
H
Now
the
semantics
of
those
messages
don't
really
cover
the
semantics
that
we
wish
to
achieve
with
satp,
which
is
the
extinguishing
of
an
asset
from
in
one
network
and
the
recreation
of
a
of
a
basically
a
replica
another.
So
the
message
is
in
ISO:
2002
are
really
promises,
so
in
a
sense
they
they
serve
a
valuable
purpose
and
we
definitely
need
to
compare
with
them,
but
I.
Think
the
this.
H
So
from
that,
we
we
got
to
thinking
about
whether,
when
two
parties
have
a
bunch
of
different
certificates
from
different
certificate
authorities,
they
they
cannot
private
common
at
some
common
notion
of
trust
if
they
know
who
their
common
certifying
authorities
are,
their
common
certificate
authorities
are,
but
if
they
reveal
anything
more
that
might
lead
to
a
privacy
violation.
So
can
we
devise
a
cryptographic
mechanism
reveals
only
what's
the
in
the
intersection
and
nothing
outside
that'd?
H
Be
great,
so
we
think
this
can
be
applied
to
a
lot
of
different
things,
including
the
kind
of
problems
that
this
group
has
been
talking
about.
Satp
and
also
the
the
view
exchanges
that
have
brought
up,
as
you
all
know,
so,
alternative
to
bishoc
I
think
we
can.
He
can
cover
this
within
15-20
minutes.
So
we
have
a
short
version
of
the
presentation.
I
J
H
F
I
I
H
A
J
J
I
So
yeah,
hello,
everyone!
So
sorry
for
that,
so
the
paper
Rafael,
the
the
title
of
the
paper,
is
private
certified
intersection
and
this
got
published
in
ndss
conference
this
year.
So
the
idea
of
the
paper,
as
Rama
mentioned,
is
to
find
out
a
common
certified
between
two
parties
in
a
privacy
preserving
way
so
to
give
give
you
an
idea
about
how
this
can
be
useful.
I
So
looks
like
that.
The
this
can
be
a
basis
of
a
business
relationship
between
them
and
they
can
strike
a
deal.
But
the
point
is
that
what,
if
one
of
the
companies
defrauds
the
other
so
and
if
associating
with
the
other
companies
at
all
a
good
idea,
so
that
is
the
that
is
often
the
question
that
they
face.
I
So
so
the
way
this
question
can
be
answered
is
by
finding
out
if
there
is
somebody
who
trusts
one
company
and
that
that
entity
is
also
trusted
by
the
other
company,
so
is
somebody
associated
with
us
also
associated
with
them?
If
the
answer
is
yes,
then
the
deal
sounds
safe
enough.
If
no,
then
so
in.
In
such
a
scenario,
the
objective
is
to
find
a
common
entity
who
is
trusted
by
both
of
them.
I
So
here,
for
example,
in
this
case
there
there
might
be
some
common
entities
like
that,
so
suppose,
government
agency
B,
is
a
body
who
is
trusted
by
both
of
them,
but
they
need
to
find
out
that
that
indeed,
that
is,
there
is
some
entity
common
entity
and
we
call
this
common
entire
trust
anchor.
So
this
fine
after
finding
out
such
common
trust
anchors,
the
task
basis
for
the
deals
can
be
established,
but
only
if
these
common
trust
anchors
are
revealed.
I
But
while
determining
such
common
trust
anchors,
it
might
happen
that
some
other
organizations,
such
as
say
a
political
party,
aim,
who
is
trusted
by
S1
but
not
by
S2,
is
also
revealed.
So
by
revealing
such
crafted
entities
who
might
not
be
rusted
by
the
other
company
or
other
organization,
it
can
cause
a
privacy
breach.
I
So
if
a
different
certifier
will
was
revealed,
then
the
deal
may
fall
through
or
even
worse,
a
company
might
get
some
business
Advantage
by
getting
to
know
some
of
the
private
contacts
of
the
other
company.
So
we
can
see
that
finding
out
such
common
trust
tankers
in
a
privacy
Visa
being
way
is
a
really
important
objective
here.
So,
if
you
think
about
the
broader
objective
of
decentralized
identity
management
in
the
context
of
the
wave
3.,
so
the
idea
of
decentralized
identifiers
and
verifiable
credentials
are
already
getting
popular.
I
So
these
two
are
the
w3c
recommendations
and
deeds
or
decentralized
identifiers
lets.
Users
create
own
and
control
their
own
identifiers,
but
Deeds
are
not
by
default
or
by
Design
connected
to
any
real
world
identity.
Instead,
what
can
be
used
are
verifiable
credentials
which
are
digital
credentials,
which
can
be
issued
to
bits,
and
these
credentials
make
claims
about
the
deed
holder
and
these
claims
these
credential
can
be
selectively
exposed
through
a
verifiable
presentation
process.
I
So
there
are
issuers
who
issue
verifiable
credentials
and
holders
who
hold
them,
and
then
the
holders
can
selectively
present
certain
credentials
to
verifiers,
but
there
is
a
problem
in
this
entire
process,
so
suppose
S1
wants
to
present
a
readable
credential
to
S2,
so
this
particular
verifiable
credential
would
have
been
issued
by
certain
issue
right.
So
the
issuad
is
the
certifier
who
is
certifying
a
certain
Claim
about
S1
and
S1
is
presenting
that
claim
to
S2.
I
So,
while
doing
so,
S1
is
inherently
revealing
in
in
the
process.
The
processing
is
inherently
exposing
the
issue
of
this
particular
verifiable
credential,
so
the
certified
is
revealed
as
well
as
the
clay
and
vice
versa
in
the
other
way
around.
Also,
it
will
happen
so
whoever
is
presenting
a
verifiable
credential
first
ends
up
revealing
the
certified.
I
So
we
we
try
to
answer
this
question
that
can
parties
owning
certificates
can
parties
owning
certificates
efficiently,
identify
a
common
set
of
certifiers
without
leaking
anything
else.
So
there
are
two
parties
and
they
have
certain
certificate,
so
P1
and
P2
are
the
two
parties.
P1
has
some
certificates
from
different
certifiers
and
P2
has
some
other
certificates
from
other
certifieds.
I
So
the
objective
is
to
efficiently
identify
a
common
set
of
certifiers
such
that
these
certificates
issued
by
those
artifiers
attaching
to
some
Claim
about
the
party
is
valid,
so
the
certificate
has
to
be
valid,
so
PCI
or
private
certified
intersection.
We
call
the
solution
to
this
problem
as
private
certified
intersection
allows
two
or
more
parties
to
identify
a
common
set
of
certifiers
while
validating
the
certificates
without
leaking
any
information
about
the
certifiers
which
are
not
in
the
output
intersection.
I
So
there
are
existing
cryptographic,
Concepts
such
as
private,
set,
intersection
or
PSI,
which
is
something
similar
which
computes
the
intersection
of
two
input
sets
without
revealing
the
elements
which
are
not
there
in
the
intersection.
So
but
PCI
is
something
different
to
psi.
So
if
we
think,
if
you
try
to
answer
this
question,
can
PCI
use
PSI
as
a
building
block,
then
we
will
find
out
that
it
will
only
work
if
the
parties
are
semi,
honest
and
not
actually
malicious.
I
If
the
parties
are
malicious,
then
PSI
using
PSI
as
a
black
box
will
not
work
because
private
set
intersection
does
not
or
is
not
sufficient
enough
to
check
the
validity
of
the
certificates
and
one.
What
one
party
can
do
in
that
case
is
just
input.
Some
invalid
certificates
from
all
possible
certified
signals
and
certifiers
are
often
well-known
entities,
so,
even
if
it
did
not
have
certificates
from
all
those
well-known
entities,
it
can
put
invalid
certificates
and
PSIs
incapable
of
validating
those
certificates.
I
So
I
will
just
brief
over
these
terms.
So
we
came
up
with
three
variants
of
PCI
protocol
PCI,
any
PCI,
any
DC
and
PCI
all
so.
The
main
difference
is
a
certificate
can
be
on
top
of
one
claim
or
multiple
claims.
So
how
do
we
so
we
we
in
some
use
cases
we
might
want
to
validate
one
claim
in
some
use
cases
we
might
want
to
validate
all
all
the
things.
I
So
PCI
any
finds
out
common
certifiers,
which
at
least
at
least
one
Claim
about
the
parties,
whereas
PCI
all
a
test
finds
out
common
certifiers
which
attests
all
public
claims
about
the
parties
and
PCI
any
DC
is
same
as
PCI
any,
but
here
the
claims
are
actually
revealed
while
running
PCI,
so
the
values
of
this
those
claims
are
revealed,
but
the
value
of
the
but
the
identity
of
the
certifiers
which
are
not
there
in
the
intersection,
is
not
ready.
So
the
certifiers
Privacy
is
there.
I
I
So
if
you
can
think
of
any
application
which
needs
the
functionality
of
PCI,
where
two
parties
need
to
find
out
a
common
certified
without
revealing
the
identities
of
their
other
certifiers
which
are
not
in
common,
then
PCI
can
be
used
and
the
definitions
prove
that
it
it
can
be
used
in
a
secure
way,
and
then
we
propose
two
practical,
efficient
PCI
protocol
solutions
for
PCR
using
ecdsa
signature,
schema
and
bla
signal
scheme.
So
ecds
is,
of
course,
a
very
popular
standard
and
BLS
is
now
popular
in
many
blockchain
applications.
I
So,
in
order
to
achieve
these
particular
implementations,
we
had
a
major
contribution
which
is
extending
the
speeds
secret
sharing
protocol
for
elliptical
pairing
operations,
so
I
will
just
skip
these
parts.
We
implemented
two-party
protocols
for
two-party
PCR
protocols
for
ecdsa
as
well
as
BLS
certificates.
I
So
this
is
the
overall
flow
of
how
PCI
works.
So
there
are
two
parties
and
they
have
certain
claims,
claim
a
b,
and
then
the
these
claims
are
attested
by
different
certifiers.
Certified
a
certificate
B
here
and
similarly,
in
this
end,
also
certific.
So
from
the
input
State,
we
can
see
that
this
is
certified
a
is
common
between
them
and
there
there
are
multiple
claims
involved,
so
I
am
going
to
going
through
a
simplified
overview
of
the
PCI
all
protocol,
which
actually
validates
all
the
claims
from
these
two
parties.
I
So
what
happens
is
in
PCI?
All
the
first
step
is
to
aggregate
signatures
from
a
certifier
over
all
the
games,
so
this
is
only
possible
with
BLS
signature
scheme
where
we
use
bla
signature
aggregation.
So
these
input
sets
are
then
reduced
to
one
input
for
one
Unix
certifier,
and
then
this
goes
as
an
input
to
the
MPC
protocol,
which
is
an
extension
of
MP
speeds,
which
is
an
implementation
of
the
speeds
protocol.
I
So
here
what
the
MPC
protocol
does
is
it
actually
checks
the
it
validates
the
signatures,
input
signatures,
the
aggregated
input
signatures,
and
only
if
the
signatures
are
valid,
then
the
certifiers
are
matched
and
only
the
intersection
which
is
the
set
of
common
certifiers,
is
revealed
outside
the
MPC
box.
So
the
MPS
outputs,
the
common
certifiers
and
no
information
about
the
other
certified
so
in
this
case
certificate
C
from
second
party
and
certified
B
from
the
first
party
rdb
and
to
analyze
the
feasibility
of
using
PCI.
I
The
time
taken
to
compute.
The
intersection
is
actually
fairly
large
in
terms
of
second.
So
it
takes
for
a
number
of
so,
for
example,
here
the
number
of
artifacts
is
100
and
we
can
see
that
it
takes
50
seconds
or
so
so
and
if
the
latency
is
large.
So,
for
example,
in
case
of
when,
where
one
party
is
in
U.S
based
post,
one
parties
in
East
Coast,
it
takes
100
seconds,
but
still
it
is
usable
in
practice,
and
maybe
it
can
be
further
optimized
further
to
reduce
the
overall
time.
I
But
we
can
see
that
with
the
changing
number
of
claims.
So
if
the
number
of
claims
are
increased,
then
the
BLS
implementation
of
pcis
are
unaffected
by
the
number
of
change
in
a
number
of
claims
in
the
inputs.
So
if
the
number
of
claims
grows
from
1
to
100,
the
ecdsa
implementation
gets
worse,
but
for
the
BLS
pciology
stays
consistent
because
of
that
signature,
aggregation
optimized
and
that
we
did
and
similar
Trends
are
there
for
the
overhead.
I
I
So
in
context
of
the
interoperability
work
that
we
were
doing
in
Weaver,
so
if
so,
we
were
trying
to
make
two
separated.
Blockchain
networks
allowed
to
separate
blockchain
networks,
Swap
and
transfer
assets
and
share
Ledger
data
with
authenticity
proofs.
So
this
private
private
blockchain
interoperability
actually
relies
on
the
ability
to
prove
and
verify
claims
about
Ledger,
States
and
consensus,
which
then
relies
on
the
ability
to
verify
the
authenticity
of
signatures
which
are
generated
through
the
consensus
process
in
each
of
these
blockchain
Networks.
I
So
we
came
up
with
a
two
layer
architecture
where
one
layer
is
concerned
about
the
transfer
of
assets
and
data
from
one
blockchain
network
to
another
and
we're
validating
those
proofs.
But
that
depends
on
the
identity
layer
which
is
concerned
about
thinking
the
identity,
information
of
the
foreign
networks,
so
the
keys
and
certificates
on
the
basis
of
which
the
signatures
can
be
validated
and
that
then
relies
on
the
deed
and
verifiable
credential
specifications.
I
But
thinking
foreign
Network
information
requires
in
a
trusted
way
requires
the
presence
of
a
common
certifier,
and
here
the
role
of
PCI
is
evident.
So
in
the
identity
plane,
PCI
can
be
used
to
determine
that
common
certifier
in
between
the
two
blockchain
networks
in
a
privacy,
preserving
way
where
the
both
the
blockchain
networks
don't
need
to
actually
expose
this
its
entire
list
of
certifiers.
J
H
Thomas
has
a
couple
of
questions,
I
think
just
broadly
thanks,
Bishop's,
a
great
presentation.
I
was
trying
to
think
through
Thomas
questions,
but
overall,
the
the
main
role
that
at
least
we
envisioned
and
which
is
where
the
the
motivation
for
PC
actually
sprung
originally
was.
How
do
we
get
different
networks,
especially
of
the
permission
variety,
to
be
able
to
discover
and
make
first
contact
with
each
other?
H
So
we
we
feel
this
has
a
role
to
play
in
the
discovery
part
of
it
and
just
trying
to
read
through
the
question
so
who
can
be
the
best
issuers
and
Gary
owners
be
issuers
potentially
I
mean
we'll
have
to
think
about
that
I
think.
In
our
case,
the
issuers
when
you're
talking
about
issuers,
they
are
the
issues
of
certificates,
so
the
certificates
are
being
issued
by
entities
that
are
actually
external
to
the
the
the
ledgers
on
which
the
assets
are
being
maintained.
C
So
so
it's
it's
back
to
the
original
VC
model.
Oh
thanks
be
track,
that's
an
interesting
presentation,
so
so
the
the
in
the
VC
model,
an
issuer
says
that
Thomas
owns
this
this
asset
in
this
network
right
and
if
it's,
if
it's
a
private,
Network
yeah,
and
so
you
know
the
issue
could
be
a
third
party,
it
could
be
a
Gateway
owner
that
says,
based
on
my
reading
of
the
you
know,
network
data.
C
H
H
F
A
H
Yeah,
it's
more
towards
the
latter.
I
think
this
is
something
that,
because
satp
is,
you
know
we
make
a
lot.
We
lied
a
lot
of
issues
like
what
is
what
exactly
is
the
legal
status
of
the
gateways
and
so
on
right,
so
satp
is
focused
on
a
on
a
small
portion
of
the
of
the
asset
pipeline
when
it
comes
to
cross
network
interactions.
So
this
is
something
which
we
are
we
yeah.
We
just
want
to
inform
the
community
about
that.
There
is
research
here
and
we
have.
A
Yeah,
that's
that's
really
easy.
I
think
Thomas
has
put
in
the
chat
some
ideas
of
how
that
could
support
our
current
satp
goals.
So,
in
terms
of
the
the
issue
of
the
excitation
going
into
the
BC
data
structure
and
again,
we
can
obviously
use
that
to
inform
our
thinking
about
how
we
might
approach
this
moving
forward.
Would
you
say
that
the
approach
that
you
presented,
which
was
it,
was
really
in-depth?
H
No,
it
we're
trying
to
make
it
agnostic.
The
only
thing
is
I
think
they
will
have
to
yeah.
They'll
have
to
follow
the
existing
cryptographic
protocols
and
use
well-known
certificate
formats.
So
Bishop
alluded
it
to
an
extension
in
the
final
slide
about
future
work.
So
we're
trying
to
extend
this
to
see
to
fit
to
verifiable
credentials
which
are
being
standardized
in
the
WCC.
So
if
we,
if
you
achieve
that,
then
we'll
have
a
larger
range
of
credentials
that
that
can
support
this
protocol.
I
I
mean
it,
it
is
I
mean
we
should
not
think
like.
It
is
tied
to
dids
or
verifiable
credentials.
The
protocol
itself
is
applicable
wherever
digital
signature
based
credentials
are
involved
and
where
we
want
the
signer.
We
want
to
parties
to
determine
the
signal
without
revealing
the
entire
list
of
signers
of
their
credentials,
so
we
don't
need
to
actually
adopt
the
IDS
for
issuers,
but
the
if
the.
H
H
F
A
A
So
thank
you
with
that
in
mind.
We've
got
a
lot
of
minutes.
Left
left.
Sorry,
it's
the
end
of
a
long
day
after
bank
holiday
weekend
here
so
to
the
end
of
the
day,
is
there
any
to
bring
up
mention
or
feel
they
haven't
had
chance
to
cover
off
whether
in
relation
to
to
the
presentation
we've
just
had
or
anything
else
that
we've
talked
about
today?
One.
F
Quick
point
for
me:
actually
yeah,
if
you
guys
wouldn't
mind,
sending
a
link
to
the
slides
to
your
presentation
too
or
I,
don't
think
the
ndss
videos
are
recorded
yet
too,
but
or
published
yet,
but
that
would
be
fantastic
to
send
that
to
the
mailing
list
as
well.
Some
people
find
slides
easier
to
read
than
an
academic
paper.
E
That
way,
we
would
be
able
to
be
exhaustive,
also
in
our
error
cases
and
eventually,
all
they're
all
back
cases
as
well.
This
is
something
that
there
was.
You
know
trying
to
make
my
from
time
to
time.
I
come
back
to
that,
but
I
believe
that,
in
order
to
make
sure
that
we
don't
forget
any
cases,
we
should
turn
our
modeling
to
State
charts
rather
than
instance
flow
diagrams.
But
maybe
that's
just
me:
I,
don't
know
what
you
think
about
that
as
a
group.
A
E
G
E
H
Yeah,
a
quick
comment
on
that
I
mean
the
yeah
I.
Think
some
kind
of
an
analysis
would
be
very
good,
I,
don't
know.
If
you
need
to
be
too
formal
about
this,
we
have
two
sides
right
and
then
you
have,
they
can
be
in.
One
of
it
seems
three
states,
maybe
more.
If
we
take
into
account
errors,
we
just
need
to
I
think
pair
them
right
and
then
we,
if
we
can,
can
enumerate
them,
should
be
a
pretty
short
enumeration
and
then
we
can
analyze
them
I
think.
H
E
C
Yeah,
that's
that's
a
good
idea,
because
yeah
for
sad
core
yeah,
we
need
a
you
know,
list
of
possible
errors
that
error
message
numbers
to
be
shown
in
the
you
know
in
the
document,
so
yeah,
yeah
and
I
think
we
need
to
to
get
there.
I
think
we
need
to
understand.
Like
all
possible,
you
know,
States,
and
so
having
some
kind
of
a
state
picture
you
know
would
be
would
be
useful.
E
D
A
Well,
I'm
happy
to
call
it
there.
Thank
you,
everyone
for
coming
along
and
the
contribution
to
the
discussion.
It
was
a
really
good
meeting,
Alex
I'm
sure
we'll
send
the
notes
out
in
a
short
period
of
time,
and
we
will
share
with
you
and
upload
to
data
tracker
for
oh
we've
got
one
more
chat
panels
on
it.
Oh
thank
you.