►
From YouTube: IETF111-PRIVACYPASS-20210730-2130
Description
PRIVACYPASS meeting session at IETF111
2021/07/30 2130
https://datatracker.ietf.org/meeting/111/proceedings/
A
We
should
get
started
since
it's
time
this
is
privacy
pass.
Your
chairs
are
joe
salloway
and
ben
schwartz.
I
can
get
my
slides
to
advance
here
by
this
time.
On
friday,
you
should
probably
all
be
familiar
with
the
no
well,
which
kind
of
describes
your
obligations
with
respect
to
contribution
and
participation
within
ietf
I'll
leave
it
up
here.
For
a
brief
second,
more,
if
you're
not
familiar
with
it,
you
can
always
go
to
the
ietf
website
and
look
at
it.
A
Okay,
we
have
a
minute
taker.
We
can
monitor
jabber,
but
if
somebody
there's
important
points
raised
in
jabber,
somebody
can
bring
those
to
the
mic
if
shares
don't
get
to
it.
We
have
no
blue
sheets
to
sign,
because
this
is
a
virtual
meeting
when
you're
speaking,
please
state
your
name,
so
the
notetaker
can
easily
capture
that
information
and
always
keep
the
discussions
professional
on
the
agenda.
A
Today
we
have
a
present
presentation
on
the
document
update
a
summary
from
the
second
anonymous
credentials
meeting
and
then
a
section
on
adding
public
metadata
to
the
privacy
pass.
Does
anybody
have
anything
that
they
would
like
to
add
or
update
on
this
agenda?.
A
B
Yeah,
if,
if
possible,
could
we
swap
the
last
two?
I
think
the
public
metadata
is
more
important
than
the
meeting
update
and
I
in
the
in
the
rare
case
that
we
run
out
of
time,
be
better.
I
think
if
we
spent
the
time
on
that.
A
Okay,
we'll
switch
those
too
all
right
so
for
the
presenters
I'm
happy
to
run
the
slides.
I
have
it
set
up
here,
but
then
you
have
to
kind
of
tell
me
to
advance
the
slides.
I
don't
charge
for
that
service,
but
if
you
would
prefer
to
run
your
slides
yourself,
then
we
can
do
that
as
well.
So
I
think
steven
your
first
up.
Do
you?
Would
you
like
me
to
run
the
slides
for
you.
C
Okay,
we're
ready
for
the
first
one,
so
I'm
stephen
well,
I'm
going
to
quickly
go
over
the
current
statements
of
the
various
privacy,
past
documents,
open
issues
and
what
the
next
steps
are
based
on
our
charter.
As
a
reminder,
the
privacy
pass
drafts
are
split
up
into
three
major
drafts.
There's
the
protocol
trap,
which
talks
about
the
cryptographic
primitives
and
the
methods
that
we
expose.
C
There's
an
architecture
dock
that
talks
more
about
the
ecosystem
and
is
built
on
top
of
the
protocol
draft
and
then
there's
a
sample
http
api
draft,
which
is
the
http
implementation
of
the
architecture,
and
all
of
these
is,
is
built
on
top
of
various
crypto
primitives.
Currently,
the
vo
prf
draft
is
the
main
one.
We
support,
though,
there's
been
some
discussion
about
other
constructions
that
could
possibly
fit
into
this
hole.
C
So,
since
last
meeting
we've
had
a
couple
of
closed
issues,
the
major
one
was
adding
redemption
context
with
based
on
the
presentation
at
f110,
which
basically
adds
to
the
architecture
dock
some
discussion
of
how
to
view
privacy
boundaries
during
redemption
time
to
allow
for
more
issuers
to
be
in
the
ecosystem
and
then
there's
also
been
a
minor
fix
to
some
of
the
tls
syntax
in
the
protocol
draft.
C
C
There's
some
information
about
what
to
expose
in
terms
of
a
service
configuration
in
the
key
commandment
server
configurations
and
there's
a
balance
between
how
much
we
specify
in
the
architecture,
draft
versus
leaving
it
up
to
each
individual
use
case
and
each
individual
application.
That's
built
on
top
of
this
there's
an
open
issue
about
centralization.
C
There's
a
draft
by
creden
that
I
think
might
be
currently
expired.
That
discusses
the
centralization
issue.
We
should
see
whether
we
want
to
bring
that
into
the
into
privacy
pass
or
include
as
part
of
the
architecture
draft.
I
think
mark's
in
the
queue.
E
Thanks
for
noting
that
that
document
has
been
updated
and
the
update
was
an
attempt
to
try
to
describe
what
goes
on
in
a
redemption
context
in
the
context
of
centralization,
I
think
it'll
be
useful
to
work
with
stephen
to
sort
of
talk
that
out.
I
think
it
needs
to
be
the
better
section,
but
it
it
has
been
updated
to
reflect
the
the
conversation
we
had
at
the
last
meeting.
C
Cool,
so
I
think
one
question
here
is
what
what
we
want
to
do
to
update
the
architecture
draft
to
point
at
that
dock
or
what
they
like
relative
status
of
these
stocks
should
be,
and
then
there's
an
open
issue,
an
open
issue
about
what
we
expose
to
proxied
verifiers,
which
is
one
of
the
modes
that
runs
in
the
architecture
draft.
I
think
just
coming
up
with
like
some
like
threat
model
of
what
a
proxy
verifier
should
see
versus
the
other
constructions,
and
I
think
that's
fairly
straightforward.
C
C
There's
private
metadata
variants,
which
I
think
is
going
to
be
talking
about
the
various
metadata
constructions
as
part
of
that
discussion,
and
then
there
is
the
larger
overhaul
of
how
we
should
reformat
the
protocol
to
either
abstract
away
the
cryptoschemes
beneath
it
that
chris
woods
has
been
writing
up.
This
is
pr
number
79
and
the
general
concept
is
adding
an
additional
abstraction
layer
so
that
the
protocol
exposed
by
privacy
pass
is
very
generic
and
treats
all
the
messages
as
arbitrary
blobs
and
any
new
construction.
C
We
want
to
support,
defines
its
own
internal
functions
and
structures,
and
this
should
hopefully
simplify
some
of
the
changes
necessary
on
the
like
high
level
protocol
and
makes
adding
these
new
constructions
easier.
It
is
a
fairly
radical
shift
from
what
is
currently
in
the
docs,
so
we
probably
want
to
see
what
people's
thoughts
on
that
are
other
updates.
Are
we
have
a
charter
timeline
that
we
came
up
with
about
a
year
ago,
which
is
very
out
of
date
and
has
deadlines
that
we've
missed.
C
C
One
proposal
is
based
on
the
current
status
of
the
core
protocol
dock,
trying
to
aim
for
ietf112
to
get
that
cut
with
the
vo
perf
construction,
then
updating
the
architecture
draft
based
on
the
open
issues
that
are
currently
there
and
assuming
there's
not
too
many
more
open
issues
that
show
up,
hopefully,
ietf
113,
would
be
a
good
timeline
and
then
the
other
two
charter
items
pushed
an
ietf
beyond
that.
D
Presentation,
thank
you,
stephen.
Let's
go
to
comments
on
those
first
two
topics
and
also
on
the
status
of
mcfadden
virtualization
draft
ben.
F
Thanks
so
I
taped
this
in
the
chat,
but
I
figured
it
might
be
worth
asking
since
it's
either
one
of
the
open
questions,
but
when
we're,
whenever
we're
thinking
about
adding
this
abstraction
layer
to
cover
up,
you
know
many
possible
constructions
that
we
could
use
to
achieve
the
properties
we
want,
there's
always
the
risk
that
we
get
the
abstraction
wrong,
and
so
I
know
we
have
quite
a
few
things
that
were
listed.
Actually,
we've
got
the
prf
and
we've
got
the
blinding
and
bls.
What
not.
B
Yeah,
I
can
just
reply
yeah.
Basically,
the
the
pr
came
from
the
observation
that
the
abstraction
was
wrong,
as
is
trying
to
add
a
construction
that
supports
public
verifiability,
specifically
based
on
the
blind,
bls
or
blind
rsa
signature
scheme.
It
was.
It
was
incredibly
difficult
to
take
basically
the
wire
format
of
that
protocol
and
and
wrap
it
in
the
wire
format
for
privacy
pass,
and
so,
rather
than
try
to
have
you
know
some
generic.
B
You
know
some
generic
wire
format
that
somehow
magically
works
for
all
the
constructions
that
we
might
potentially
see
in
the
future,
be
it
bls,
be
it
some
schnorr
based
thing
that
potentially
requires
multiple
rounds.
What
have
you
it
just
seemed
cleaner
to
to
sort
of
wrap
all
of
it
and
sort
of
delegate
the
the
bits
that
are
specific
to
the
crypto
construction
to
the
crypto
construction
and
just
have
you
know?
Privacy
pass
be
this
very
thin
layer.
On
top
of
those
particular
cryptographic
protocols.
B
Yeah-
and
I
think
that's
that's
the
the
role
sort
of
the
wrapper
that
is
privacy
pass
to
to
to
be
able
to
like
deal
with
things
that
are
multiple
round
trips
or
deal
with
things
that
have
perhaps
different
contents
there,
and
so
the
the
the
specific
challenge
with
rsa
versus
the
opr
is
that
the
opr
and
the
response
from
the
server
during
issuance
you
get
back
a
bunch
of
evaluated
elements
and
then
approve
depending
on
whether
or
not
it's
a
like
a
batch
proof
or
or
it's
just
like
a
single
proof
or
a
single
evaluated
element,
but
basically
there's
two
things
in
that
response,
whereas
in
the
rsa
case
it's
just
like
a
single
blinded,
signed
message
right
and
yeah,
so
I
I
I,
I
think
I
think
the
proposal
sort
of
captures
the
right
abstraction,
but
it's
currently
just
a
draft.
B
Certainly
people
who
have
thoughts
on
you
know
what
the
abstraction
should
be
should
take
a
look.
But
I
found
that
with
this
particular
like
rsa,
like
bls,
was
a
lot
easier.
So
it's
promising.
B
That,
I
hope
is
the
just
or
is
the
sufficient
rationale,
reasoning
as
to
why
the
pr
exists.
B
D
Ben
schwartz,
no,
no
chair
hat,
I
have
a
question,
is
this?
Does
this
propose
to
add
a
document
anywhere?
Does
this
create
a
new
document?
Chris.
D
I
mean
this,
this
refactor,
which
defines
a
uniform
abstraction
here.
Does
this
add
a
document
to
our
set?
No.
B
D
Okay,
and
does
it
rely
on
a
cfrg
document
to
provide
that
abstraction.
B
D
Okay,
is
there
anyone
who
wants
to
to
to
make
a
comment
proposing
an
alternative
or
supporting
an
alternative
to
chris
wood's
proposal.
D
So
as
chair,
I
would
say
it's
not
clear
to
me
that
this
is
something
that
needs
working
group
consensus
for
for
for
this
change.
It
seems
to
me
that
this
is
in
the
hands
of
the
editors
and
as
long
as
they
you
know,
as
long
as
there's
no
conflicting
input,
I
think
the
editors
can
can
proceed
as
they
wish.
D
To
be
honest,
I'm
not
sure
what
the
procedure
is
for
updating
a
charter
timeline,
but
I
will
ask
my
co-chair,
and
maybe
our
ad
and
we'll
think
about
that
seems
like.
If
there's
no
other
comments,
we
should
move
to
the
next.
G
D
G
Okay,
there's
no
slides
available
here.
Could
you
share
the
slides
yourself
and
I
ask
you
to
move
them.
I
G
Okay,
so
hi
everyone,
my
name
is
sophia
selly
and
I'm
a
cryptography
researcher
at
clavley,
and
I
will
today
I
was
going
to
talk
about
how
to
add
public,
how
a
proposal
on
how
to
add
public
metadata
to
privacy
pass,
and
if
you
want
to
actually
take
a
more
in-depth
look
at
this
proposal,
there's
already
a
pr
against
the
base
drops.
So
if
you
want
to
check
it
out,
please
do
so
in
that
link.
G
Next
slide,
please,
okay!
So
basically
what
is
the
proposal,
as
I
said
in
the
title
of
the
presentation,
is
to
add
public
metadata
into
the
current,
as
it
is
right
now
currently
defined
previously
pass,
and
this
proposal
is
built
up
in
a
paper
that
we
published
recently
to
the
eprint.
My
co-authors
are
listed
in
this
slide
and
you
can
find
it
in
that
link
if
you're
interested
in
reading
more
about
it.
Of
course,
there
have
been
already
other
proposals
that
have
been
either
proposed
on
these
sessions
or
can
be
found
in
the
regular
places.
G
There
has
been
one
proposal
about
how
to
a
private
metadata
that
can
be
find
a
place.
Another
one
that
came
from
from
facebook
on
how
to
add
public
metadata
by
using
a
different
construction
that
is
called
an
attribute-based
vip
arrives.
Just
to
note
again,
this
construction
that
I'm
going
to
be
presenting
today
deals
with
public
metadata,
not
with
private
metadata.
G
G
The
reason
is
because,
at
least
in
this,
the
specificities
of
this
construction
that
are
presenting
is
because
it
is
useful
against
certain
attacks,
something
that
has
been
noted
early
on,
since
the
early
paper
previously
passed.
Is
this
idea
that
one
can
execute
a
holding
attack
against
the
protocol
in
the
first
paper
previously
passed
by
goldberg
at
r
is
actually
defined
as
a
forming
attack,
and
I
think
it
is
defined
on
section
eight
if
I'm
not
wrong,
but
it's
basically
the
same
attack
that
I'm
talking
about
in
this
slide.
G
The
idea
that
individual
users,
individual
clients
or
a
group
of
clients
can
gather
tokens
over
a
long
period
of
time,
and
then
they
try
to
redeem
them
all
at
once,
and
the
reason
why
attackers
might
want
a
malicious
client,
a
malicious
user.
An
attacker
would
like
to
do
this
is
because
they
want
to
render
the
service
unavailable.
G
So
the
idea
is-
and
so
one
of
the
things
that
in
the
pa
in
the
original
privacy
paper
say,
is
that
there's
ways
to
actually
preventing
this
the
mechanism
into
preventing
these
several
one
of
them
is
to
only
have
an
x
amount
of
tokens
that
can
be
issued
at
certain
amount
of
times.
G
Another
prevention
that
they
listed
is
to
add
this
idea
of
a
key
rotation
in
which
that,
even
if
an
attacker
is
able
to
gather
a
lot
of
tokens
for
an
x
amount
of
time,
they
will
not
be
able
to
redeem
them
all
at
once
in
a
different
time,
because
the
key
under
which
those
tokens
were
issued
has
been
rotated.
G
But
of
course,
it
has
also
these
problems,
because
if
you
are
rotating
the
key
all
of
the
time
in
a
with
a
specificity
that
is
too
short,
then
you
will
be
diminishing
the
anonymity
of
those
tokens.
G
So
we
thought
of
a
new
construction
that
will
be
much
easier
to
implement
than
just
having
this
key
rotation
mechanism,
and
that
has
the
idea
of
adding
public
metadata
and
the
way
to
solve
the
holding
attacks.
Problems
is
by
adding
certain
metadata
that
prevents
against
these.
G
The
metadata
that
you
can
be
adding
is,
for
example,
an
expiration
times
to
the
token,
or
you
can
also
be
adding
a
geographic
location
to
the
tokens
and,
in
the
last
slides
I'm
going
to
be
talking
about
specifically
what
the
specific
metadata
you
could
be,
adding,
because
adding
metadata
to
the
construction
as
privacy
pass
has
to
be
always
carefully
considered
because
you
could
be
diminishing
the
anonymity
set.
That's
a
slide
please!
G
So,
as
we
know
right
now,
as
it
is
right
now
written
the
privacy
pass
document
underlying
primitive
that
is
used
is
a
boprf.
G
That
is
the
one
defined
here
that
we
all
know
a
lot
of,
and
that
is
basically
that
two
parties
want
to
compute
a
pseudorandom
function
that
has
the
obliviousness
property
and
with
us,
and
what
does
this
obliviousness
property
means
is
that
the
secret
key
of
the
server
remains
secrets
and
the
input
that
the
client
inputs
in
the
function
also
remains
secret,
but
both
can
compute
the
output
of
the
pseudorandom
function.
G
The
idea
of
adding
public
metadata
is
really
simple.
As
you
see,
the
construction
only
get
added
one
parameter
that
is
well
known
by
the
client
and
the
server,
and
most
of
the
operations
at
that
line
are
really
a
change,
but
are
just
the
changes
are
really
little,
and
if
you
want
to
know
more
about
what
changes
it
requires
to
the
bopr
reconstruction
there's
also
already
a
pr
open
against
the
cfr.
G
G
And
here,
as
you
see
in
the
construction
itself,
the
only
thing
that
needs
to
get
added
is
the
client
metadata
and
the
server
metadata,
and
in
this
case
these
are
values
that
are
publicly
known
by
both
and
that
can
be
actually
defined
prior
to
the
execution
of
the
protocol
or
can
also
be
sent
during
execution
by
the
client
on
the
server
and
that's
a
decision
that
is
kind
of
outside
of
the
protocol
is
how
applications
want
to
define
what
metadata
will
be
that
relations
of
the
cnuishings
is
not
really
part
of
any
of
the
commitment
phase,
but
actually
in
the
issuance
phase
of
the
each
one
phase
next
is
live.
G
Please
for
a
redemption.
Is
the
same
you're
going
to
be
assuming
that
the
client
and
the
server
know
what
metadata
they
are
going
to
be,
adding
that
is
publicly
known
and
they
will
be
adding
to
all
of
the
apib
or
prf
functionality
that
needs
it
next
slide.
Please,
okay,
as
I
said,
also
metadata,
even
though
this
construction
allows
you
to
add
a
public
metadata
that
is
known
by
the
client
and
the
server
or
both
it's
always
carefully.
G
It
has
to
be
carefully
considered
because
any
kind
of
metadata
that
you're
going
to
be
adding
it
will
be
diminishing
the
anonymity
set.
So,
for
example,
in
the
case
of
actually
going
trying
to
prevent
this
coding
attacks,
you
can
be
adding
expiration
time
of
the
tokens.
But
this
expiration
time
should
not
be
explicit,
because,
if
you're
actually
saying
that
this
talking
is
only
valid
was
issued
during
this
time
and
is
valid
until
this
time
you
will
be
diminishing
quite
heavily.
The
anonymity
set
right
now
in
the
current
pr.
G
You
will
see
that
we
are
not
using
exclusive
timestamp,
but
we're
actually
using
epoch
numbers,
meaning,
for
example,
the
server
defines
that
the
epoch
is
since
today
until
two
months
and
calls
the
setback
a
number.
Let's
say
one,
and
then
they
add
this
one
one
to
the
to
the
token
and
that's
the
public
metadata
that
is
known
and
therefore
the
anonymity
set
gets
diminished,
but
not
as
heavily
as
it
will
be
if
you're,
using
explicit
time
stamp
yeah.
G
Another
note
to
have
is,
of
course,
is
that
this
metadata
you're,
adding
to
the
tokens,
is
not
bounded
by
length.
You
can
add
as
much
bits
of
metadata
that
you
want
as
possible,
but
it
has
to
be
carefully
considered
by
the
application
itself,
because,
obviously
other
metadata
is
really
really
big
will
not
be
really
useful
for
applications.
G
So
this
is
application
dependence
to
balance
privacy
and
utility
and,
as
I
said,
if
you
want
to
check
how
this
construction
impacts,
the
vopr
construction
there's
already
a
dpr
that
you
combine
here
and
also
you
want
to
see
how
it
has
been
added
or
what
thinking
there
has
been
to
be
added
to
the
privacy
fast
draft.
That's
the
pia-
and
I
think
that's
my
last
slide.
So
next
is
like
this
okay.
Yes,
thank
you
and
I'm
hoping
for
questions.
I
see
that
there's
already
java
discussion.
H
What
it
was
the
name
of
the
second
paper,
you
said
you
listed
some
alternatives,
there
was
the
facebook
paper
and
then
there
was
one
other
paper.
So.
G
G
Yes,
second
slide:
I
think
it
is.
G
A
Any
other
comments
on
the
public,
adding
public
metadata
or
you
know
what,
whether
it's
good
idea
in
general.
B
Yeah,
I
I
think
it's
a
good
idea,
but
I
think
the
larger
question
is
whether
or
not
it's
something
that
constrains
all
instantiations
of
privacy
paths
or
only
applies
to
certain
constructions.
B
So
would
it
be
desirable
to
be
to
ship
privacy
pass
such
that
you
could
use
just
the
vo
prf
version
without
any
metadata
support,
or
must
it
be
the
case
that
any
version
of
privacy
pass
supports
metadata
that
drastically
changes
what's
possible?
Underneath
the
hood
right
now
we
only
know
of
one
sort
of
construction
that
works
for
partially
oblivious
prf
support
the
one
that's
listed
here
on
the
slide
and
we
have
sort
of
ideas
as
to
how
to
clutch
things.
Together.
B
I
glue
things
together
for
publicly
verifiable
or
partially
blind
signatures,
but
that's
still
very
much
sort
of
an
open
research
question
and
if
requiring
metadata
for
all
instantiations
was
going
to
be
the
way
we
went
that
might
delay
sort
of
that
public
verifiability
extension.
So
I'm
curious
to
hear
what
people
think
about
that.
G
We
only
define
geography,
localization
and
the
timing
and
it's
kind
of
open
if
someone
else
wants
to
add
anything
else,
but
might
be
worth
revisiting
that
against
the
optionality
of
adding
or
not
adding
pre
public
metadata
as
right
now
how
we're
writing
for
the
cfrg
draft,
which
I
didn't
cover
today,
and
if
you
want
to
see
that
talk
that's
coming
later
today,
there's
the
possibility
of
you're
adding
an
empty
string
and
it
will
still
be
working
but
yeah
there
could
be
other
construction
besides
the
ppr
one
that
allow
you
to
use
metadata
and
that's
like
a
big
api
discussion
as
well.
A
Yeah,
so
thinking
about
whether
to
you
know
make
that
metadata
mandatory,
I
think
you
know
making
arbitrary
metadata
mandatory
would
certainly
be.
I
think
that
would
be
a
high
bar.
Maybe
you
know
these
specific
cases
that
you
have
listed
could
be
accommodated,
but
I
I
kind
of
think
I
think
we
might
have
to
dig
in
and
see
how
critical
those
features
are.
But
if
they're
not
super
critical,
then
I
would
say
it'd
be
better
not
to
have
that.
A
B
My
my
take
regarding
the
sort
of
generality
of
the
metadata
is
that,
if
we're
going
to
sort
of
support
it,
I
don't
think
it
should
be
bound
at
the
protocol
layer.
B
J
Hi
I
was
wondering
if
this
partially
oblivious
prf
supports
like
no
metadata
bits
and
the
the
reason
I
ask
that
is
kind
of
wondering
whether
this
construction
could
just
be
used
instead
of
the
original
vap
rf.
Because,
as
far
as
I
know,
the
performance
seems
pretty
similar.
G
Yes,
thank
you
very
much
for
the
question
alex
so
right
now,
for
example
in
the
pr
that
we
have
for
cfrg,
there's
the
possibility
of
you
not
adding
any
metadata
at
all,
and
in
that
case,
what
happens
is
that
they,
you
just
add
a
contest
string
plus
some
empty
string
and
that's
all
because
the
underlying
the
underlying
operations
of
the
pov
execute
us
almost
as
efficiently
as
a
regular
viewer,
prf,
so
yeah.
So
it's
completely
fine.
If
you
pass
an
empty
string
yeah
or
if
you
pass
an
actual.
D
Hi,
this
is
ben
schwartz
as
individual.
G
D
Rotations
necessarily,
but
so
there's
a
sort
of
a
trivial
way
of
adding
metadata
where
we
we
simply
assign
each
metadata
value
to
a
distinct
issue
or
key.
G
Yeah,
I
think
that
was
more
like
the
ab
or
abp
a
b
pr
po
prf,
maybe
ppf
construction.
I
think
it
was
that
one.
The
problem
with
that
construction
is
that
it's
not
as
efficient.
Actually
as
the
pip
rf
one,
you
need
to
add
a
serial
knowledge
proof
that
executes
much
less
efficiently
and
that's
what
was
most
much
more
likely
the
problem
with
that
construction.
So
actually
adding
the
pop-r1
is
kind
of
better
in
comparison
which,
how
you
will
add
public
metadata,
because
it's
much
more
efficient.
G
Time,
yeah
on
yeah,
specifically
in
the
abpr
construction.
It's
because
the
serial
knowledge
group
that
you
happy
have
to
be
adding
for
the
verification
part,
is
less
efficient.
D
Okay,
thank
you.
Chris.
B
Wood
yeah
ben.
I
just
want
to
ask
a
clarifying
question
to
you.
Actually,
what's
your
question
about
the
naive
metadata
approach,
where
you
have
like
yeah,
a
single
signing
key
for
each
value
of
metadata,
or
were
you
asking
specifically
in
the
context
of
the
attribute-based
voprf
construction?
Yes,.
D
B
Gotcha,
so
I
think
sophie's
answer
was
great
for
the
attribute-based
one
and
she
probably
has
thoughts
on
the
other
one
as
well
so
I'll.
Let
her
take
that.
G
No,
I
haven't
had
much
thoughts,
but
I
think
that
we
need
a
little
bit
more
careful
analysis.
That
will
be
my
answer
that
maybe
that's
something
that
I
can
start
looking
at
for
later.
Yes,.
C
Kind
of
are
doing
that
in
the
like
trust,
token,
experiments,
and
I
think
the
big
issue
is
like
it
works.
Fine
for,
like
small
amount
of
metadata
like
two
or
three,
but,
like
all,
clients
are
gonna
need
to
know
like
the
full
set
of
like
applicable
keys,
which
then,
like
balloons
up
to
like
hundreds
of
points.
If
you're
like
doing
any
like
significant
amount
of
metadata-
and
it
also
means
you
can't
like
do
arbitrary
named
metadata
and
have
to
know
a
priority
like
what
it
is.
G
G
G
I
don't
think
we
should
recommend
doing
that,
but
you
can
use
it,
but
what
I
personally
think
is
that
the
metadata
that
gets
out
is
publicly
should
also
be
small
enough,
because
that
will
also
what
I
think
is
that
you
that
will
not
be
diminishing
the
anonymity
set
so
heavily,
because
if
you
are
things
that
are
more
explicit
and
maybe
bigger,
then
maybe
you
will
be
harming
the
unanimity
set
further,
it
kind
of
more
depends
on.
G
Yes,
you
can
add
as
much
as
metadata
as
you
want,
but
the
biggest
concern
with
adding
metadata
is
the
anonymity
set
rather
than
more
like
if
it's
okay
to
a
lot
of.
D
So,
sophia,
I
wonder
what
your
recommendation
is
to
the
working
group.
Would
you
recommend
that
we
add
a
public
metadata
element
to
the
to
the
privacy
pass
api.
G
Yes,
I
do
recommend
that,
but
I
would
really
like
to
know
also
the
thoughts
of
the
cfrg
happening
later
today,
of
adding
up
easily
adding
the
the
papf
construction
into
the
vo
pf1,
because
the
privacy
pass
builds
on
top
of
that
draft.
So
I
will
also
would
like
to
know
if
you
needed
something
to
support
it,
then
there,
because
then
it's
much
more
easy
to
also
modify
the
draft
to
do
recommendation
of
the
draft
if
the
other
line
primitive
is
also
part
of
the
cfrg
one.
A
Segment
are
you
presenting
again.
C
Again,
really
briefly,
there
was
an
anonymous
credential
meeting
that
happened
a
few
weeks
ago
at
pets,
2021
and
we'll
go
over
some
of
the
privacy
past
relevant
things
that
came
out
of
that
meeting
yeah.
C
So
one
of
the
main
things
that
came
up
there
were
a
couple
of
presentations
about
various
anonymous
credential
constructions.
There
was
one
by
alex
about
post
quantum
construction,
which
is
an
extension
of
the
video
pref
scheme
to
use
a
lattice-based
approach,
and
this
might
be
interesting
if
privacy
pass
is
concerned
about
more
post-quantum
proof-ness.
C
There
are
also
a
lot
of
discussion
about
various
use
cases.
Some
of
them,
which
might
be
applicable
to
privacy,
pass
the
ones
that
came
up
were
contact,
tracing
and
anonymous
credentials,
and
notably,
the
one
thing
that
those
use
cases
sort
of
require
that
is
only
like
partially
supported
in
current
privacy
pass,
but
would
maybe
be
more
supported
with
the
addition
of
metadata
is
having
some
having
non-identifying
information
in
these
tokens.
C
Well,
so
that,
like
you,
can
limit
like
the
domain
they're
used
in
in
a
way
that,
like
the
client,
is
like
aware
of
what
the
metadata
is,
and
it
can
like
make
a
informed
choice
that
it's
not
like
your
username
or
your
real
name
or
anything,
identifying,
there's
also
the
requirement
for
some
sort
of
time-bounded
or
one-time
use.
Toke
time-bounded
tokens
that,
like
expire
at
a
certain
amount
of
time,
after
being
used,
which
you
can
sort
of
use
in
privacy,
pass
by
having
very
short
key
rotations.
C
But
that
adds
logistical
complexity
and
the
additional
key
rotations
also
have
some
amount
of
privacy
implications
in
terms
of
different
users
having
different
expired
tokens
and
having
a
like
nicer
way
of
supporting
that
might
support
those
sorts
of
use
cases
more
generally.
These
anonymous
credential
meetings
been
happening
about
twice
a
year
and
is
been
a
good
place
to
get
these
sorts
of
use,
cases
and
discussion
about
additional
constructions
and
they'll,
hopefully
keep
on
providing
some
useful
fodder
for
privacy
pass
to
think
about
and
for
constructions
to
happen
here.
C
C
So
I
think
the
addition
of
metadata
could
solve
somewhere,
like
the
information
required
isn't
identifying
like,
but
I
think,
like
we'd
need
some
sort
of
brand
new
construction
for
anything.
That's
like
a
time-bounded
token,
where,
like
the
time
bound,
is
based
on
when
the
token
was
issued,
but
in
a
way
that,
like
isn't
like
you,
can
now
split
it
by
like
the
exact
issuance
time.
C
There
might
be
ideas
of
like
splitting
up
the
like
chunking
time
to
do
something
similar
to
the
epoch
stuff
that
sophia
mentioned.
So
I
do
think
like
adding
metadata,
does
add
support
for
some
of
these
cases.
There
are
some
that
I
think
will
still
be
beyond
privacy
pass
with
metadata
without
additional
work.
A
A
Thanks
any
other
comments
on
that
particular
presentation.
A
If
not,
I
think
we
have
run
through
our
scheduled
agenda.
Are
there?
I
know,
there's
been
some
discussion
in
the
chat
on.
A
Whether
to
add
on
the
abstraction
layer
that's
been
proposed,
I
don't
know
if
any.
We
have
some
time
that
that
we
can
continue
that
discussion
here
or
if
not,
we
can
all
get
ready
for
cfrg.
F
So
I
think
that
one
part
that
came
up
in
the
chat
that
I
think
martin
thompson
raised
was
sort
of
the
question
of
do.
We
need
to
support
the
vo
prf
style
at
all
versus
going
straight
to
publicly
verifiable
blind
signatures
type
thing,
because
the
charter
is
treating
the
public
verification
as
an
extension
that
we'll
do
as
a
follow-on,
but
in
some
ways
the
protocol
is
actually
simpler.
F
B
B
What
is
the
difference,
then,
between
you
know,
a
protocol
that
is
a
partially
blind
signature
and
privacy
pass
like
what?
What
is
the?
What
is
the
thing
that
privacy
pass
adds
on
top
of
that?
That
is
not
already
provided
by
the
underlying
protocol.
It's
not
clear
to
me
that
there
is
anything
sort
of
noteworthy
there.
So
if
we
just
if
we
just
sort
of
reduce
this
all
down
to
one
primitive.
B
Sorry,
I
I'm
clearly
holding
this
wrong
if
we
reduce
this
all
down
to
one
primitive.
It's
not
clear
to
me
that
we
have
sort
of
a
useful
protocol
at
the
end,
but
there
are
other
people
on
the
queue.
D
J
Davidson,
I
guess
my
thoughts
on
the
matter
that
I
think
that
there
are
applications
where
the
efficiency
advantages
of
using
like
the
symmetric
vopof
will
become
apparent.
But
I
think,
on
that
note,
as
as
much
as
finding
applications
where
like
public
metadata
is
useful,
is
going
to
be
useful,
for
is,
I
think,
also
finding
applications
where
using
like
a
symmetric,
vo
prf
with
no
metadata
would
also
be
useful
in
order
to
ascertain
whether
we
really
do
need
like
that
strip.
Back
construction.
I
Because
it
seemed
to
me,
like
the
vo
prf,
wasn't
adding
anything,
but
someone
just
said
optimization,
and
that
creates
a
visceral
reaction
in
me
that
says
well.
Well,
maybe
you
just
need
a
better
whatever
the
primitive
is.
At
the
same
time,
I
think
I'm
coming
around
to
the
view
that
we
probably
have
some
value
to
weight
in
terms
of
tying
down
parameters
and
defining
maybe
formats.
D
As
individual
ben
schwartz
I
I
was
under
the
impression
that
that
the
that
the
vo
prf
schemes
that
lack
public
verifiability
are
have
have
stronger
cryptographic,
security
proofs
or
are
proven
secure
under
stronger
assumptions.
I
wonder
if
one
of
the
crypto
experts
could
shed
some
light
on
that.
J
Yeah
like
in
a
sense,
that's
true,
but
the
I
think
the
main
points
are
that
the
publicly
verifiable
schemes
that
we
know
of
are
currently
based
on
either
pairings
or
rsa,
and
I
think
the
main.
The
main
point
is
that
choosing
parameters
in
such
a
way
that
the
like
security
assumptions
remain
secure
in
those
settings
is
slightly
more
difficult
in
the
rsa
setting.
Obviously,
you
have
to
you
know,
choose
things
so
that
the
rsa
assumption
is
secure
and
in
the
pairing
setting.
J
I
think
security
is
just
a
little
bit
less
known,
because
it's
slightly
newer
cryptography
and
you,
you
do
see
generally
more
quick
analysis
in
that
area.
So
you
could
security
parameters
can
change.
J
H
J
So
the
the
vop,
the
original
via
prf,
like
the
two
dh
gopf,
that
we
used,
is
based
on
like
a
one,
more
gap,
different
helmet
assumption,
oblivious
pseudorandom
function,
I
believe,
is
based
on
a
variant
of
like
a
cue,
strong,
diffie-hellman
assumption
and
then
I'm
less
well-versed
at
blind
rsa.
I
guess,
is
based
on
the
isa
assumption
and
the
pairing
based
assumptions.
I'm
I'm
not
actually
very
well
versed
on
what
assumptions
they're
based
on,
but
I
assume
it's
some
bilinear
variant
of,
like
a
discrete
log
type
assumption.
H
I
Basically,
with
can
chicken
what
I'm
hearing
here
is
that
we
have
a
bunch
of
primitives
and
each
one
of
them
has
some
sort
of
subset
of
the
various
capabilities
that
we're
looking
for,
whether
it
contains
public
metadata,
private,
metadata
or
and
public
verifiability
or
not,
and
none
of
them
seem
to
provide
all
of
those
capabilities.
Yet
each
one
of
them
has
different
performance
characteristics.
Each
one
of
them
relies
on
different
security
assumptions
and
we're
sort
of
in
a
cfrg
mode
where
we're
going
to
be
trying
to
pick
the
right
primitive.
I
B
Just
to
react
to
that,
I
it's
definitely
true
that
the
different
primitives
have
different
feature
sets
like
some
of
them
are
publicly
verifiable.
Some
are
not.
I
I'm
not
sure,
like.
One
of
the
assumptions
I
have
been
making,
perhaps
implicitly
is
like
all
the
constructions
that
we're
considering.
B
We
consider
them
to
be
at
least
as
secure
as
one
another
for
some
definition
of
secure,
that
is
to
say,
people
who
are
deciding
to
choose
one
variant,
the
privacy
pass
or
the
next
or
the
other
one
variant
over.
The
other
should
not
have
to
make
a
determination
in
terms
of
like
what
type
of
security
they
want.
That
just
seems
kind
of
terrible
like
the
ts.
B
1.3
did
a
very
good
thing
in
that,
like
okay,
well
for
aed's,
we're
just
going
to
pick
three
aeds
that
we
know
have
basically
the
same
properties
and
the
choice
doesn't
really
matter.
It
comes
down
to
performance.
You
do
you
do
you
whatever
you
want,
ideally
we'd,
be
in
a
similar
posture
here,
wherein
the
the
differences
and
the
primitives
or
the
instantiations
rather
vary
only
in
what
features
they
provide
and
possibly
also
performance.
B
G
Okay,
yes,
I
want
to
agree
with
chris
wood
in
the
sense
that
all
of
the
constructions
that
have
been
proposed
are
targeting
almost
the
same
security
properties.
It
is
true
that
they
are
based
on
different
underlying
assumptions,
but
at
least
also
when
you
are
trying
to
add
an
extra
feature
most
of
the
times
when
adding
this
extra
feature
you're
starting
already
into
one
onto
the
well-known
primitives.
G
So,
for
example,
in
the
peer
preps
case,
one
of
the
things
one
of
the
big
focus
of
the
research
was
to
actually
provide
the
same
properties
that
the
bpf
was.
So
I
don't
think
that
the
bopr
has.
G
I
My
point
for
me:
I
don't
think
it
matters
what
what
what
security
assumptions
we're
basing
these
things
on,
as
as
both
of
you
have
established,
but
that's
not
the
focus
of
the
comment
when
we
do
engineering.
Typically,
we
try
to
choose
the
one
tool.
That's
going
to
work
for
the
use
cases
that
we
have.
I
What
it
sounds
like
we're
doing
here
is
we're
trying
to
get
all
the
tools
for
all
the
use
cases,
and
that
makes
me
very
nervous
because
I
don't
want
to
get
into
some
sort
of
open-ended
thing
that
says
well
we're
just
going
to
do
something
and
everyone's
going
to
do
their
own
thing.
That's
not
actually
seeking
interoperability.
I
I
D
Okay,
well,
I
hope
our
document
authors
are
inspired
by
these
comments
to
to
update
the
documents
and
bring
back
to
the
working
group
new
new
revisions
that
that
address
these.
These
inputs
from
the.
D
Group,
joe
over
to
you
for
any
last
comments.
A
That's
all
I
have
yeah,
hopefully
see
a
bunch
of
activity
in
the
drafts
and
on
the
list
and
we'll
see
you
next
time
or
in
cfrg.
If
you're
going.