►
From YouTube: IETF107-PRIVACYPASS-20200326-1946
Description
PRIVACYPASS meeting session at IETF 107
2020/03/26 1946
https://datatracker.ietf.org/meeting/107/proceedings
A
A
Also,
please
make
sure
your
video
is
off
to
kind
of
conserve
bandwidth.
You
should
meet
your
microphone
unless
you're
speaking,
to
prevent
background
noise
for
cue
management,
we're
going
to
use
the
WebEx
chat
window.
You
can
use
plus
Q
to
add
yourself
to
the
chat
queue
to
the
microphone
Q
and
minus
Q
to
remove
yourself
from
the
queue,
so
that
should
be
primarily
what
we're
using
the
chat
window
for
in
WebEx.
Other
kind
of
conversation
should
be
used
in
the
jabber
room.
A
We
may
also
use
the
chat,
maybe
for
a
couple
other
purposes,
but
what
chairs
will
let
you
know
when
it's
appropriate
to
use
to
chat
outside
of
the
plus
Q
minus
Q,
as
I
mentioned
before,
the
virtual
blue
sheets
are
in
the
ether
pad
also
when,
where
the
notes
are
being
taken,
so
you
just
may
need
to
scroll
down
or
up
to
to
find
the
section
where
you
can
log
your
name
in
and
finally,
we
do
have
a
jabber
room.
Please
join
I
think
you
have
a
couple
folks,
monitoring
that
room
so
to
get
started.
A
B
A
A
Ok,
so
here
we
are
we're
going
to
start
out
with
we've
gone
through
the
administrivia,
we'll
start
out
with
a
description
of
kind
of
problem
statement
in
use
cases
from
Alex
Davidson
of
what
privacy
pass
is
to
give
everybody
an
idea.
After
that,
we
will
want
to
get
a
sense
of
the
call
if
people
understand
what
what
this
is
all
about,
and
then
we
can
kind
of
go
and
on
and
see
what
the
status
of
implementations
and
the
status
of
the
drafts
are
and
Stephen
Valdez
will
will
present
on
that.
A
So
there'll
be
time
after
each
presentation
to
kind
of
ask
clarifying
questions
to
understand
more
and
then
finally,
we'll
continue
on
and
look
at
a
possible
charter.
So
are
there
any
questions
or
comments
at
this
point?
Not
we'll
just
jump
in
I'll
display
the
slides
Alex
and
you
can
unmute
yourself
and
look.
C
I
works:
can
you
hear
me?
Okay,
yes,
okay,
cool,
so
yeah,
I'm,
Alex,
I'm,
a
cryptography
researcher
at
CloudFlare,
and
so,
as
Jay
mentioned,
I
can
be
walking
through
some
of
the
the
problem
that
we're
looking
to
solve
with
post
pass
and
some
of
the
applications
and
use
cases
that
currently
exist.
So
in
next
slide,
please
cool!
C
Google
chrome
in
firefox,
which
is
quite
widely
used,
but
more
recently
we're
also
seeing
a
usage
in
development
by
other
organizations
such
as
the
chromium
and
brave
browsers.
Next
slide,
please
so
the
problem
that
we're
looking
to
solve
with
privacy
class
and
is
quite
common
one.
So
we
have
a
client
and
the
client
makes
a
request
to
the
server,
and
so
that
has
to
decide
whether
to
accept
our
request
and
process
it
or
not.
C
C
So
to
do
this,
and
typically
what
we
do
is
issue
some
sort
of
challenge
to
the
client
and
the
client
will
have
to
solve
this
challenge
before
it's
a
request
is
processed,
so
in
the
intercept
setting.
This
can
be
something
like
a
cheering
test
and
essentially
what
the
server
is
trying
to
do
here
is
access
air.
It's
to
determine
whether
the
client
is
human
or
not.
C
Jesus
had
like
humans
more
likely
to
be
honest
when
they're
accessing
web
sites,
and
once
the
client
has
provided
a
solution
to
this
challenge,
the
server
will
accept
the
request
and
process
it,
and
here
we
can
think
of
the
server
either
as
just
a
standard
server
providing
resources
or
a
server
as
some
sort
of
gateway
that
provides
access
to
a
number
of
disparate
services
that
the
client
can
access.
So
next
slide,
please.
C
So
the
problem
here
is
when
it
comes
to
propagating
nitrous.
So
in
the
situation
previously,
the
client
would
have
to
solve
a
challenge
every
time
it
needs
to
prove
to
the
server
that
it's
honest,
but
something
that
would
be
really
valuable
is
for
their
and
client
to
be
able
to
propagate
that
trista
future
request,
so
they
doesn't
have
to
keep
solving
these
challenges.
C
So
what
this
would
look
like
is
the
server
provides
some
sort
of
tryst
attestation
token
and
the
client
would
use
this
token
in
future
requests
when
interacting
with
that
server,
so
that
the
server
could
accept
the
request
without
having
to
process
it.
Another
challenge
from
the
client-
and
it's
the
next
slide,
please
so.
C
So
this
is
to
substantially
help
the
clients
privacy,
when
browsing
so
with
a
lack
of
alternatives,
and
the
next
best
thing
is
just
a
client
solving
a
challenge
on
each
request.
But
the
problem
is:
is
these
challenges
can
be
quite
expensive
and
it
can
also
be
harmful
to
accessibility
for
clients
and
in
some
situations
that
can
also
be
infeasible.
If
the
client
is
that
is
trying
to
provide
some
proof
ownership
of
an
attribute
that
they
doesn't
want
to
reveal
what
HP
exactly
is,
so
we
need
a
different
solution.
So
next
slide
please.
C
So
how
does
this
fit
into
the
workflow
that
I
bought
earlier?
So
we
have
the
challenge
solution
that
the
client
provided
previously,
but
it
also
provides
an
extra
message
which
is
sort
of
quest
tokens.
So
this
requests
some
privacy
task
tokens
from
the
privacy
of
that
server
and
then,
when
the
server
decides
to
accept
the
challenge
solution,
it
also
issues
some
tokens
to
the
claim-
and
this
is
known
as
the
token
issuance
phase
and
next
slide,
please
so
in
a
future
request.
C
The
server
may
issue
a
challenge
or
the
client
may
just
send
a
redeem
token
message
itself
and
this
redeem
take
a
message
entitles
a
client
to
bypass
whatever
challenge
the
server
wants
to
provide
to
the
client.
So
the
key
thing
here
is
that
the
client
no
longer
has
to
provide
a
solution
to
the
challenge
and
these
Redemption
tokens,
as
I
mentioned
before
I'm
linkable
by
design.
So
the
client
can
use
these
across
our
agents
and
the
server,
and
it
does
not
reveal
to
the
server
when
they
were
issued
and
the
clients
have
two
approaches.
C
C
What
is
known
as
a
verifiable,
oblivious
pseudo-random
function,
I'm
not
going
to
go
into
the
exact
details
of
what
one
of
these
constructions
is,
but
there
was
a
draft
specification,
that's
currently
being
worked
on
by
the
CFR
G,
so
you
can
read
that
and
in
the
protocol
document
for
price
pass,
which
Stephen
will
talk
about
in
his
session
just
after
this
one
and
we
we
implement
the
price
pass
API
using
this
functionality.
Next
slide
this
in
terms
of
the
additional
cost.
C
So
we'll
just
talk
about
the
additional
cryptographic
data
we
have
to
send
in
order
to
instantiate
a
price
plus
protocol.
So
we
for
the
issuance
phase.
We
have
the
request,
tokens
and
issue
tokens
message,
and
these
messages
are
proportional
to
the
number
of
tokens
that
are
being
issued
to
the
client
multiplied
by
essentially
the
size
of
the
size
sweet
we
using
so
here.
The
65
bytes
corresponds
to
the
largest
size
of
sweets
being
used
in
the
MV
opieop
f
job.
C
So
these
messages
are
going
to
be
less
than
or
equal
to
at
55
price
per
token
in
terms
of
the
redemption
phase.
That
would
be
in
token
is
much
smaller,
as
a
constant
size
is
actually
corresponding
to
an
authentication
tag
which
will
be
around
64
bytes
for
the
computation
and
just
really
focusing
on
the
public
key
cryptography
operations,
because
these
ones
are
going
to
be
the
most
expensive.
Cities
especially
correspond
to
the
same
operations
in
the
TLS
handshake.
C
So
in
the
issuance
phase
we
have
a
slightly
more
expensive
set
of
computations
for
the
client
server
performed
three
or
four
of
these
public
key
operations
per
token.
When
the
redemption
phase,
you
have
a
much
less
expensive
computation,
so
the
client
has
to
perform
any
of
these,
and
the
server
just
performs
one
to
validate.
At
the
token.
C
So
next
slide
is
so
moving
on
to
the
applications,
as
I
mentioned
before,
post
pass
came
out
in
collaboration
with
the
CloudFlare
CDN,
so
the
club's
less
CDN
uses
post
passes
and
abuse
prevention
mechanism
in
order
to
improve
accessibility
to
clients
that
interact
with
cloud
layers,
internet
captures,
which
they
use
to
protect
their
customer
websites.
So
essentially,
what
happens
is
when
the
customer,
when
a
CloudFlare,
when.
D
C
Client
interacts
with
cloud
plan
has
to
perform
a
capture
if
they
have
the
privacy
pass.
Browser
extension
installed.
The
CloudFlare
CDN
will
also
provide
the
user
with
post
as
tokens
and
when
a
user
then
navigates
to
other
origins
that
are
behind
the
CloudFlare
CDN,
they
can
provide
these
tokens
and
they
work
and
they
don't
have
to
complete
the
captures
and
the
unthinkable
property
means
that
CloudFlare
can't
map
the
user's
browser
pattern,
browsing
patterns
and
a
second
que
use
case,
which
also
corresponds
to
these
prevention.
C
Application
is
related,
mostly
online
ad
platform
space
so
essentially,
and
the
ad
space
providers
can
use
private
path
tokens
to
ensure
that
ad
clicks
are
being
made
by
non-fraudulent
actors.
So
what
this
means
is,
as
Facebook
values
need
to
be
able
to
ensure
that
clicks
on
specific
ads
made
by
by
clients
that
aren't
BOTS
and
they
can
use
the
price
path
tokens
to
propagate
risk,
and
there
are
two
applications
which
highlight
this
use
case.
C
So
it's
called
slightly
different
cryptographic
and
implementation,
essentially
for
the
same
application
as
a
next
slide,
and
the
second
application,
which
we've
seen
quite
recently,
is
one
based
on
the
anonymous
currency.
So
the
brave
browser
and
allows
brave
clients
to
use
these
at
this
form.
Casinos,
basically
tokens
or
bats,
to
purchase
services
internally
in
the
browser
and
brave
uses.
C
Secondly,
we
have
an
application
based
on
providing
anonymous
receipts
for
prepaid
services,
so
at
least
Authority
security,
consultancy
use
private
paths
as
a
mechanism
for
providing
proof
of
purchase
and
for
an
access
control
mechanism
mechanism
link
to
their
private
storage
API,
and
this
is
also
an
application
highlighted
by
open
privacy
group.
So
next
slide,
please
so
you
just
finish
up
and
just
to
conclude
so
pipes
pass
and
is
intended.
Lea
intercepts
I,
think
and
we
think
it.
C
It
provides
quite
unique
properties
as
a
trust-based
attestation
mechanism
at
propagation
of
trust
on
the
Internet,
and
we
want
we
hoped
for
working
groups
that
were
sometimes
used
to
the
protocol
and
the
specific
implementation
considerations
around
creating
an
ecosystem
around
that.
That
includes
multiple
groups
of
issuing
issuing
servers
and
washable
clients,
and
there
were
many
open
questions
around
this
and
again
these
will
be
covered
in
another
in
Stephens
presentation
and
but
yeah
happy
to
answer
any
clarifying
questions
around
the
problem
in
use
cases.
Thank
you.
E
E
One
is:
do
you
see
the
scope
of
this
as
and
I
guess
this
presentation
is
protocol
this
bath
as
being
where
context-specific
or
more
general
than
just
web
as
the
first
a
few
questions,
and
my
second
question
is
what
what
do
we
think
the
relationship
is
between
this
problem
and
again,
my
questions
are
on
the
problem
space
right
now:
the
solution
on
the
problem
space.
What's
our
relationship?
E
What
do
we
think
the
relationship
is
between
this
problem
and
the
problem
at
the
rest
work
will
group
is
try
to
solve,
given
that
was
about
attestation
to
now.
I
will
give
a
partial
answer
to
that
myself,
which
is
the
rest
group,
is
charter
to
do
architecture,
and
so,
if
you
look
at
the
diagrams
here,
they
match
almost
identical
to
what
the
rest
group
has.
E
But
the
rest
group
is
not
charter
to
do
protocol,
and
so
it
could
be
that
the
relationship
is
rest
of
the
architecture
and
some
of
the
format's,
but
not
the
protocol,
and
maybe
that's
what
you're
trying
to
do
here,
but
I'm,
not
sure
if
that's
is,
do
that's
consistent
with
what
you
think
so
again.
First
question
was:
if
this
web
only
you're
more
than
just
web,
when
question
you
is
what
relationship
you're
at
it's.
C
Like
yes,
so
it
so
that
I
think
the
scope
of
this
working
group
is
when
only
in
the
sense
that
and
I
think
privacy
pass
itself
is
a
protocol
could
be
used
in
different
situations,
but
if
I
think
the
scope
of
the
proposal
working
group
would
just
be
in
the
web
context
and
on
rats,
that's
not
something
I
know
so
much
about,
but
I'm
happy
to
have
more
discussion
on
that.
I
yeah
I
have
to
admit.
I,
don't
actually
know
too
much
about
that
working
group.
Okay,
it's
okay!.
E
F
Just
to
jump
in
quick
as
ad
this
has
been
Caidic.
My
understanding
is
that
rats
is
interested
in
providing
verifiable
information
about
the
client
or
the
entity
itself,
and
that
many
of
the
use
cases
here
in
privacy
paths
are
not
as
much
about
the
entity
as
opposed
to
something
like
something
that
has
done
roughly
like
a
proof
of
work
and.
E
All
things
both
diagrams
match
exactly
the
diagrams
is
in
the
rats
architecture.
Right
now,
and
so,
for
example,
you're
trying
to
the
server
is
asking
the
client
to
attest
that
the
client
is
a
human
and
not
a
bot,
for
example,
and
so
you
have
a
capture
or
something
like
at.
The
thing
that
comes
back
is
the
equivalent
to
what
rats
would
call
evidence
and
then
the
token
that's
issued
is
equivalent
to
what
rats
calls
meta,
Station
result
and
the
back-and-forth
flows
on
these
slides
match
exactly
what's
in
the
rats
architecture.
Yes,.
F
C
So
the
tokens
are
transferable
and
give
me
what
is
the
protocol
for
or
like
what
is
the
transferability
for
I
mean
the
protocol
and
is
a
mechanism
for
propagates
interest.
So
the
tokens
are
used
to
provide
that
risk
and
the
fact
that
it's
variable
is
related
to
the
fact
that
they
don't
provide
any
motive
on
how
they
were
issued
or
when
they
were
issued.
G
C
G
C
So
I
think
this
is
a
good
question
and
I
think
essentially
like
them.
Intelligence
is
finite,
is
also
not
intent.
You're
not
intended
to
get
them
on
my
huge
scale,
I
think
it's
a
trade-off
between
wanting
to
maintain
privacy
as
much
as
possible,
I
think
and
looking
at
the
use
case
where
you
would
potentially
link
the
tokens
to
some
sort
like
entity
is
something
that
we
could
consider,
but
again
this.
This
is
the
outline
we
have
so
far.
H
Martin
Thompson,
so
my
question
has
to
do
with
the
amount
of
information
that
is
propagated
across
the
transfer
of
information.
So
you
talk
to
an
issuer
of
tokens
and
then
you
talk
to
a
another
entity.
Presumably,
although
your
diagrams
of
option,
the
one
entity
involved,
you
talk
to
another
entity
who
redeems
the
token,
how
much
information
traverses
this
this
path
and
is
there
any
intention
to
allow
the
client
to
add
information
to
this
attestation
that
I
generate.
C
So
in
in
the
in
the
protocol
document
we
talk
more
about
like
so
the
different
like
access.
You
have
to
the
server
so
like
I
guess,
you're
talking
about
like
you
would
redeem.
The
client
would
redeem
a
token
with
someone
who
would
then
forward
that
one
to
some
the
server
actually
check
that
so
in
terms
of
extra
information
and
I
think
this
is
something
that
would
be
handled
in
what
will
become
the
hitch
like
the
HTTP
API
document.
I
On
Facebook
I
just
want
Adam
to
the
UC
Alex
mentioned,
imprisoned
and
I.
Think
somebody
brought
up
whether
it
is
for
a
little
mini.
Perhaps
the
place
or
we're
applying
this
to
actually
at
the
moment
is
more
on
the
applicant
apps
side
of
things
been
on
the
web
and-
and
somebody
brought
up
like
about
like
the
fraud
use
case,
are
actually
thinking
of
this.
It's
like
an
additional
signal
to
be
used
when
you're
doing
things
like
anonymously,
logging
analytics
or
things
like
that.
I
D
In
particular,
I
have
a
theory
about
the
photography,
this
muscle,
it's
more
for
assessing,
where
these
tokens
are
the
position
of
the
clients
and
it's
kind
of
the
responsibility
of
the
client
to
guard
them
because
they
will
be
used
by
the
client
this
one
time
use
authentication
token.
So
I
think
this
protocol
works
in
this
model.
If
somebody
steals
the
token,
then
yeah
they
can
use
it,
and
this
is
kind
of
in
tandem
with
you.
L
C
Yeah
speaking
of
add,
that's
a
good
question,
so
this
and
it's
going
to
be
covered,
but
essentially
the
idea
that
we
have
in
mind
currently
is
that
there
will
be
some
central
authority
that
monitors
the
issue
is
the
valid
at
any
one
time.
So
there
will
be
some
sort
of
registry
of
issuers.
The
Commission
is
tokens
and
they'll
have
to
register
in
order
to
be
able
to
do
that,
I
might
put
that
they
they
have
to
publish
some
sort
of
like
and
public
cryptographic
a
day
to
in
order
to
be
able
to
issue
tokens
successfully.
C
D
M
Steven
Valdez
Google
I'm
going
to
go
over
quickly
the
drafts,
key
management,
ideas
and
implementations
that
we
have
so
far.
This
does
a
like
idea
of
what
the
current
state
of
the
ecosystem
is
say.
Us
next
slide
next
slide.
So
the
first
stress
we
have
is
the
privacy
past
protocol
draft,
which
is
a
lot
like
the
previous
presentation.
M
The
second
draft
that
we
have
is
the
architecture
draft,
which
goes
more
into
the
sorts
of
requirements
on
client
servers
and
the
considerations
we
need
to
worry
about,
particularly
it
exposes
interfaces
that
can
be
used
by
different
applications,
use
cases
on
top
of
privacy
paths
in
order
to
call
into
the
protocol
itself.
Things
like
how
the
issuer
would
store,
keys,
retrieve
keys
and
do
the
actual
messages
that
communicate
with
the
client.
M
A
large
portion
of
this
draft
is
also
about
how
key
management
works,
which
we'll
discuss
a
few
of
the
options,
including,
what's
currently
written
the
privacy
considerations
since
well.
This
does
limit
the
amount
of
information
that
can
be
transferred
between
the
issuer
firm,
the
issuance
time
to
redemption.
There
is
still
at
least
the
one
bit
of
information
that
is
neat
between
issuance
and
retention
and
there's
concerns
about
user
segregation.
M
If
you
allow
a
bunch
of
different
keys
for
one
issuer
and
other
forms
of
try
and
identify
leakage,
and
as
we
think
of
this
document,
we'll
need
to
discuss
more
about
the
privacy
trade-offs
that
are
necessary
to
support
having
these
like
key
rotations,
even
though
having
additional
keys
might
allow
you
to
do
additional
bits
of
data
leakage.
There
are
so
security
considerations
in
a
malicious
client
might
ask
for
500
privacy
pass
tokens
and
then
on
a
malicious
website
or
a
malicious
endpoint.
M
It
would
redeem
all
of
them
forcing
the
client
to
lose
all
their
tokens
immediately.
We
also
discuss
extension
policies
on
the
wider
architecture
side
of
things,
how
other
application
can
be
build
on
top
of
this
instead
of
how,
in
the
previous
draft,
it's
mostly
about
the
core
protocol
itself.
Next
slide
as
an
example,
one
of
the
drafts
we
have
initially
is
the
HP
API
draft,
which
talks
about
how
to
build
on
top
of
the
previous
architecture,
draft
for
a
HTTP
use
case.
M
The
sorts
of
key
management
requirements
that
HP
clients,
notably
browsers
and
websites
that
use
these
APS,
would
have
to
abide
by
and
there's
a
sample
of
a
potential
extension
called
delegated
Redemption,
which
is
a
way
for
at
least
in
the
web
ecosystem
world.
The
ability
to
given
a
press
privacy
past
Redemption
send
it
around
to
other
parties
without
leaking
an
information
that
way
every
website
isn't
talking
to
the
issuer
every
single
time
and
the
extent
of
how
much
we
want
in
this
HP
API
is
also
a
thing
that
we
need
to
discuss.
M
As
a
working
group
see
what
is
valuable
here.
There
is
a
interaction
between
this
and
w3c
in
terms
of
also
kind
of
a
native
KPI
is
the
sorts
of
like
JavaScript
API,
fetch
API.
So
you
might
need
to
support
the
use
of
privacy
paths
in
the
web
ecosystem,
and
some
of
that
might
need
to
be
discussed
here,
and
other
parts
may
need
to
be
a
liaison
with
the
w3c
next
slide.
B
M
Slide
so
one
of
the
big
things
that
need
to
be
determined
for
privacy
paths
is
how
issuers
manage
their
keys
in
an
optimal
world
and
it
sure
would
have
a
single
key
that
they
use
to
sign
every
single
privacy
pass
token,
and
that
means
that
that
one
key
is
the
one
that's
always
used.
Unfortunately,
we're
not
in
an
ideal
world,
so
we
need
to
support
key
rotation
in
case
and
I
sure
loses
our
keys
or
other
keys
are
compromised.
M
But
we
need
to
balance
that
with
the
problem
that
multiple
keys
being
in
use
can
allow
for
user
segregation
or
even
on
Friday.
The
issuer
may
sign
privacy
past
tokens
for
one
bit
of
information
on
Tuesday.
They
use
a
different
key
to
sign
for
a
different
bit
of
information,
and
we
also
need
to
somehow
have
a
way
that
you
can
audit
that
a
privacy
pass
issue,
or
has
it
been
changing
their
keys
and
presenting
different
keys
to
different
users.
M
M
You
would
have
to
trust
this
proxy
so
that
they're
not
prevent
presenting
different
viewpoints
of
the
world,
but
if
you
do
have
some
sort
of
trusted
party,
be
it
your
you
pay
for
a
a
third
party
like
university,
that
is
doing
all
the
edging
and
then
storing
of
the
key
comments
locally.
You
wouldn't
have
to
be
worried
about
the
issue
itself,
presenting
different
key
commitments.
M
The
third
option
and
the
one
we
currently
have
written
on
the
8
KPI
document,
is
a
commitment
registry,
some
sort
of
append-only
log,
where
all
issuers
would
append
their
key
commitments
to
this
log
and
all
times
will
be
fetching
the
key
minutes,
either
from
this
log
or
from
issuer
directly.
As
long
as
the
issuer
presented
some
sort
of
inclusion
proof,
this
does
require
a
slightly
bigger
ecosystem
where
you
have
this
sort
of
panel
log,
but
it
does
allow
for
a
cryptographically
assured
assurance
that
the
key
commitment
has
been
reported
to
this
log.
M
Auditors
could
then
keep
track
of
what
commitments
have
been
reported
and
take
note
of
their.
We
rotating
key
commitments
to
frequently
clients
could
have
policy
for
the
rate
of
rotation
allowed,
and
the
log
itself
could
just
say
that
if
you're
receiving
a
new
key
commitment
every
five
minutes,
then
that's
probably
not
a
valid
key
rotation
policy.
It.
We
need
to
figure
out
what
some
recommended
policies
would
be
for
like
how
often
an
issuer
would
be
allowed
to
rotate
their
keys
next
slide.
M
Throughout
all
the
documents,
there's
a
number
of
open
questions.
These
are
a
few
of
them,
there's
the
issue
of
malicious
clients,
getting
tokens
and
then
spending
the
multiple
times.
In
the
case
that
an
issuer
has
different
endpoints.
You
need
some
sort
of
eventual
consistency,
otherwise
a
single
token
can
be
reading
five
times
for
the
five
different
data
centers
in
issue
or
might
be
running.
M
Another
problem
is
how
a
client
and
the
ecosystem
as
a
whole
would
be
detecting
malicious
servers.
You
clients
would
need
to
have
some
way
to
talk
with
other
clients
to
say
that
they've
seen
a
different
viewpoint
of
what
the
key
has,
what
keys
the
issuer
has
presented.
This
is
somewhat
solved
if
you
do
something
like
a
log
approach
to
key
management.
M
But
if
you
do
a
simpler
approach,
which
is
just
the
issuer,
gives
you
keys
directly,
you
need
some
sort
of
way
to
determine
that
the
issuers
been
acting
poorly
there's
the
question
of
key
rotation
windows
that
have
balance
between
how
often
you
want
to
rotate
for
security
versus
the
privacy
implications
rotating
your
keys
too
frequently,
and
that
there's
the
question
of.
If
you
allow
five
million
issuers,
then
you
get
five
million
different
tokens
in
each
of
those
represent
one
bit.
M
So
there
are
some
privacy
considerations
for
having
a
massive
collection
of
issuers,
but
you
also
want
to
avoid
consolidation
and
limiting
problems
with
limiting
the
number
of
issuers
that
exist
in
the
ecosystem.
There's
possible
solutions
for
this,
where,
instead
of
limiting
the
number
of
issuers
you
might
limit,
the
number
of
redemptions
at
a
particular
site
or
endpoint
would
do
at
a
time.
But
these
are
considerations,
no
questions.
We
need
to
go
over
next
slide
and
then,
in
terms
of
current
implementations
may
P
eyes
that
exists.
M
Tyler
has
ergo
JavaScript
challenge
bypass
extension,
which
was
one
of
the
original
reasons
behind
privacy.
Pass
Bray
has
a
rough
JavaScript
application
for
their
bats.
That
Alex
mentioned
earlier
and
chrome
is
beginning
to
implement
a
variant
of
this
or
HTTP
based
on
the
HTTP
API
in
C
and
JavaScript
next,
but
I
guess,
let's
like.
Lastly,.
B
M
I
M
There
is
a
lot
of
use
cases
that
won't
need
this
double
spending
requirement.
I
think
it
would
be
useful
to
detail
like
how
you
would
maintain
this
double
spinning
or
what
the
cost
of
not
having
this
double
spending
protection
is
in
terms
of,
like
a
single
token,
can
then
be
turned
into
n
different
tokens.
I,
don't
think
we
need
a
likes
to
require
all
applications
to
be
double
spending
secured.
L
A
Those
Richard
Barnes
I
just
wanted
to
raise
the
question
of
whether
this
part
of
the
how
critical
this
part
of
the
work
is.
It
seems
like
the
whole
point
of
this
worked,
is
the
issuer
websites
using
privacy
pass
or
trying
to
do
better
than
earlier
private,
more
privacy
hostile
mechanisms?
So
it
seems
like
if
you
had
a
malicious
issue
where
they
could
just
revert
back.
B
M
Sorry
go
ahead,
I
think
there's
some
hope
that,
like
alone,
this
protocol
is
fairly
privacy
tight.
It's
true
that
a
lot
of
issues
could
just
not
do
this
protocol
and
revert
to
other
less
privacy,
positive
means
of
transferring
information.
I
know
some
browsers
have
been
working
on
reducing
the
like
privacy,
negative
abilities
of
malicious
actors,
yeah.
A
And
I
just
to
be
clear
in
terms
of
kind
of
deliverables
for
this
work,
I
think
I
would
be
tempted
to
view
it
as
acceptable
to
simply
clearly
describe
the
privacy
properties
of
the
protocol
itself
and
kind
of
deliver
an
initial
protocol
with
just
a
clear
description.
Even
if
there
are
some
of
these.
Some
of
these
questions
remain
unaddressed.
In
the
first
version.
M
Think
even
they
mate
I
think
it's
still
valuable
too
yeah
at
least
like
talk
about
what
these
privacy
issues
is.
Even
if
we
can't
like
completely
solve
them,
but
I
think
it's
worth
attempting
to
solve
at
least
the
ones
we
can
with
a
protocol
itself
and
I.
Guess
that's
the
somewhat
of
the
split
between
the
core
protocol
dog
and
the
architecture
dog
yeah.
E
This
is
Dave,
so
it
asked
this
question
that
jabber
room
and
I
haven't
gotten
that
answer
as
I
understand.
Yet
so
I'll
ask
it
here:
why
is
a
double
spend
and
issue
I
understand
why
your
token
might
want
to
have
some
notion
of
an
expiration
time,
but
how
does
it
matter?
Why
does
it
matter
how
many
uses
it
has
before
it
expires
so.
M
For
some
use
cases,
it's
possible
that
the
issuer,
like
knows
that
this
user
has
been
active
on
this
website
for
like
two
weeks
and
only
wants
to
give
them
like
twelve
tokens,
because,
like
a
user
that
has
been
active
for
that
long
that
how
much
they
trust
that
user.
If
you
allow
double
spend,
then
that
means
one
token
can
just
be
sent
to
like
5,000,000,
malicious
people
so
like.
M
E
You're
only
partly
answered
by
question
because
you
start
off
saying:
well,
let's
assume
that
you
only
want
to
give
out
twelve
uses.
That's
the
part
that
I'm
questioning!
Why,
since
you'd
only
want
to
give
out
twelve
uses
which
might
take
you
know
12
milliseconds
might
last
for
12
milliseconds
or
might
last
for
12
months.
Why
would
you
not
say
you
can
use
it
for
the
next
12
minutes,
regardless
of
whether
it's
12
attempts,
20
attempts
or
1
attempt
with
the
net
12
minutes.
M
This
personally,
it
goes
back
to
the
transferability
question
and
these
tokens
aren't
bound
to
specific
user.
So
if
there's
a
malicious
user
that
is
able
to
get
one
token,
you
don't
want
that
one
token
to
be
used
arbitrarily
many
times
across
arbitrarily
many
clients,
so
they
sure
wants
to
choose
some
number
of
tokens
that
they
give
out
that
they're
willing
to
play
the
trade-off
of
they
may
be
passed
on
to
box
or
other
malicious
actors.
E
M
E
M
C
Just
camp
in
his
eye,
Alex
dated
so
also
the
client
may
not
want
to
use
the
same
token
over
and
over
again,
because
that
will
leak.
Decker
will
link
all
the
sessions
together.
Their
users
are
taking
in
so
it's
in
their
best
interests,
in
some
cases
to
be
issued
a
fine,
a
number
of
tokens
and
they
can
use
each
of
those
without
a
server
being
answering
each
one.
Well,.
E
I
understand
that,
but
that
can
be
done
by
issuing
one
token
per
session
or
something
that
the
client
wants.
So
the
client
wants
to
preserve
it's
not
anonymity.
You
can
always
ask
for
more
tokens.
One
per
session
ever
use
it
within
a
session
saying
there
are
other
solutions
to
that.
I
think
the
main
answer
is
what
we
what
I
heard
before
so
you.
B
D
And
so
it
was
again
a
comment
about
the
scope.
I
think
somebody
mentioned
that
maybe
it
would
be
good
to
have
the
proper
codified
and
probably
postpone
these
discussions
on
the
different
security
I.
Just
wanted
to
mention
that
there
is
a
protocol.
The
protocol
satisfies
man's
property,
so
I
think
the
purpose
of
this
working
group
should
really
kind
of
go
beyond
this
set
of
property,
that's
already
achieved
by
practice
and
look
into
what
possible
extensions
would
bring
up
additional.
M
I
think
yes,
the
more
point
to
the
working
group
is
to
make
the
privacy
protocol
a
real
protocol,
given
that
as
part
of
like
the
ITF
but
I
do
think
it
is
valuable
to
maybe
scope
a
little
bit
beyond
that,
since
otherwise
it's
limited
to
taking
the
existing
draft
and
publishing
it
and
I
think
there's
a
lot
of
more
interesting
work
in
the
space,
the
architecture
that
is
worth
pursuing.
But
I
guess
that's
a
question
for
the
both
in
the
working
group
as
whole.
M
So
it's
not
possible
to
generate
a
new
token
from
an
existing
token.
This
is
somewhat
intentional
and
to
prevent,
like
one
token,
from
return
to
2000,
it's
possible.
That
thing
is
built
on
top
of
privacy
pass.
The
HP
API,
maybe
would
allow
you
to
submit
a
token
to
then
get
a
new
batch
of
tokens
from
the
issuer,
but
in
general
you'd
have
to
do
the
whole
protocol
again.
If
you
want
more
tokens.
A
I
think
before
we
go
into
charter
I'd
like
to
make
sure
that
people
have
a
chance
to
let
us
know
if
they're
still,
you
know
kind
of
unclear
about
the
problem
in
use
cases
that
have
been
presented
here.
So
if
you,
if
you
still
have
you
know
big
questions
about
that,
now
would
be
the
time
to
ask
those.
F
N
F
H
Start
listening
anyway.
Ok,
thank
you.
So
one
of
the
things
that
I've
not
gotten
from
the
discussion
thus
far
and
I
think
it's
part
of
the
problem
of
people
in
the
in
the
chatter.
Having
as
well
is
the
relationship
between
the
different
actors
in
this
situation
and
how
much
trust
each
one
is
required
to
confer
on
the
others
with
respect
to
what
their
motives
are
and
incentives,
and
that
sort
of
thing
so
as
a
client.
H
How
much
do
I
rely
on
the
fact
that
the
issuer
is
not
playing
hooky,
so
we
have
in
Steve's
thing
the
transparency
thing
that
sort
of
covered
off
the
question
of
issue
is
having
multiple
keys,
but
we
also
have
the
potential
if
the
issuer
and
the
party
that
remains
to
be
the
token
in
the
end,
being
different
parties.
The
redeeming
party
could
have
multiple
issuers
and
use
the
selection
of
issuer
to
also
segregate
clients,
and
so
I'd,
like
a
little
bit
more
clarity
about
what
the
goals
are.
With
respect
to
that
I.
M
Think
part
of
this
is
the
clients
going
to
need
to
have
some
policy
and
allowing
only
like
a
website
or
a
party
that
is
requesting
a
token
to
be
issued
to
pre
commit
to
what
issuer
they
want
to
use.
I,
don't
think
we
can
support
case
Orlick,
you
choose
an
issue
or,
after
you
know,
the
users
eye
intensity,
because
otherwise,
I
have
50
different
issuers
for
like
50,
different
users
and
part
of
the
idea
of
having
like
a
registry
of
the
issuers
that
are
registered.
M
Is
that
you
don't
have
the
ability
to
spin
up
a
brand
new
issuer
as
a
issue
as
a
client
attempts
to
get
a
token.
So
the
client
for
the
most
part
has
to
trust
that
the
list
of
issuers
is
reasonable,
but
otherwise
doesn't
need
to
trust
that
a
particular
issuer
is
presenting
different
like
identities
to
them
and.
H
A
A
A
A
N
I
just
wanted
to
check
this
is
Nick
Doty
in
terms
of,
should
we
work
on
this
like
do
we
have
a
sense
of
diversity
of
interested
implementers
as
a
user
on
the
front
page
get
I,
think
there's
a
lot
of
value
to
this
I
would
be
happy
to
provide
reviews.
If
it's
just
going
to
be
a
couple
of
the
largest
companies
that
are
going
to
implement
it,
then
it
might
not
need
as
much
standardization
work.
C
Yeah
so
and
Alex
speaking
so
I
think
we
so
as
I
mentioned
in
verse,
8
for
like
we
have
a
lot
of
applications
that
couldn't
be
used
so
and
we
tend
to
keep
exploring
them
and
introducing
new
applications
as
well.
But
equally
we're
also
looking
for
white
participation
from
the
community
and,
as
you
mentioned
like
like
the
current,
the
current
applications
are
limited
to
a
few
organizations
and
institutions
but
like
it
would
obviously
be
preferable
for
us
as
well
to
introduce
more
diversity
to
that
process.
O
You
please
state
your
full
name.
Yes,
so
this
is
you
like
Tori
from
intuition
machines?
We
actually
have
a
service
called
H
CAPTCHA,
which
is
one
of
the
current
users
of
privacy
as
as
well
we're
using
it
for
more
or
less
a
standard,
inaccessibility
use
case,
and
so
we're
not
one
of
the
largest
companies
on
the
internet,
but
I
think
we
are
quite
interested
in
privacy
and
there
are
certainly
others
out
there
like
us.
I
would
expect
there
to
be
more
adoption,
as
the
tenants
process
continues
and
people
become
more
aware
of
the
options.
E
E
I
don't
have
enough
information,
for
example,
I
think
it
would
be
useful
for
the
IETF
to
or
add
value
RTF
I'm,
not
sure,
both
to
look
at
the
question
of.
Can
you
get
non-transfer
ability
and
anonymity
and
the
same
algorithm?
If
so,
that
would
be
a
better
thing
to
build
the
solution.
On
top
of
you
still
need
protocol
work
either
way,
and
so
overall,
the
answer
is
yes,
but
that's
what
I
would
want
to
keep
in
mind
thanks.
P
B
Q
Hi,
this
is
Tommy
Pali
from
Apple
I
just
want
to
say
that
we
are
also
very
interested
in
this
general
problem.
Space
and
I
think
that
this
is
something
that
the
IETF
should
work
on
similar
to
the
other
comments,
the
specific
problem
solution-
space,
that's
been
explored,
I
think
is
a
good
starting
point,
but
not
necessarily
where
things
need
to
land,
but
the
confident
I'm
having
our
I
think
is
the
right
conversation
to
start
from
I'd
like
to
see
this
go
forward.
R
Hutson
I'm
from
CloudFlare
in
fact,
I'm
a
co-worker
of
Alex's
I,
think
this
is
an
IDF.
You
work
on
I'd,
just
like
to
clarify
that
this
is
solving
a
very
different
problem
than
rats.
It's
for.
You
prove,
as
the
other
assistant
came
out,
Microsoft
research
that
one
would
look
at
this
is
really
about
anonymity.
R
The
goal
here
is
to
be
able
to
issue
a
token
and
redeem
it
later
without
being
able
to
link
those
two
transactions
and
the
token
is
not
really
carrying
any
information
behind
it.
Existence
like
a
coin,
it
doesn't
matter
which
penny
you
gave
me
gave
me
a
penny,
get
admission,
so
I,
don't
think
it
makes
sense
to
put
in
rats
which
is
really
focus
which
is
not
really
concerned
yet
with
anonymity
and
wants
to
express
a
much
richer
actually
faces
a
very
different
problem.
R
I
Vanguard
yeah
we're
I
think
that
idea
of
should
work
on
this.
We
should
our
interest
in
this
by
10:00
it's
having
some
private
implementations
of
these,
like
it's
closed
source
at
the
moment
that
we
also
have
some
implementations
of
these
as
well
I'm
excited
to
see
the
an
ecosystem
evolving
around
this
as
a
result
of
like
the
ITF
process
and
standardizing
and
anything
that's
like
more
and
more
use
cases
as
as
we
go
through
this
process.
I
L
Yes,
Tony
Nedley
I
believe
is
something
that
the
ietf
should
work
on.
I
do
have
a
concern
over
the
sign
redemption
records
that
come
back,
possibly
being
used
as
a
form
of
authentication
if
these
records
wind
up
getting
cashed
and
that
so
I
do
think,
there
has
to
be
a
little
bit
more
security
considerations
that
hunted
into
this
protocol.
A
So
I
think
you
know,
it
seems,
there's
general
feeling
is
consensus.
Is
that
the
IETF
should
work
on
this
I'd
like
to
try
to
see
if
we
can
get
a
feeling
for
who
would
be
interested
in
contributing
an
effort
either
as
a
reviewer
or
contributing
text
or
for
implementing
just
to
get
an
idea.
What
we
did
into
seeing
in
some
of
the
previous
box
is
to
use
the
chat
window
to
put
a
plus
one.
If
you
were
willing
to
contribute
some
effort
towards
this
problem,
either
reviewing
or
contributing.
A
A
A
C
Sure
and
cool
ready
to
go
and
yeah.
So
thank
you
for
your
questions
and
comments
has
been
really
helpful.
I'm
just
going
to
present
a
few
slides
that
will
introduce
and
sort
of
the
key
point
in
the
Charter
and
then
I
think
we're
going
to
move
to
github
and
we'll
go
through
it
line
by
line
from
there
and
but
yes,
so,
let's
go
to
the
next
slide.
Please
you
cool,
hi
blink
got.
C
So
yeah,
so
the
Charter
that
we
currently
have
lives
on
get
her
a
bit.
I
thought
I've
also
posted
it
to
the
mailing
list,
so
you
can
read
alert
pupae
fur
and
this
version
of
the
Charter
was
previously
discussed
and
written
a
mostly
outside
meeting
that
took
place
in
January
and
within
the
course
with
a
number
of
individuals.
C
C
The
tokens
are
quickly
graphically
and
linkable
and
to
deserve
the
clients,
privacy
and
just
on
this
point
and
we've
had
some
good
feedback
about
how
this
interactive
transferability
and
whether
these
and
then,
whether
these
two
concepts
possible
to
align
and
this
this
might
be
coming
as
well
as
consider
in
the
charts
as
well.
Maybe
just
as
a
discussion
point
of
the
documents.
So
next
slide.
Please,
and
so
the
scope
of
the
working
group
as
we'll
see,
is
the
three
core
documents
of
Stephen
laid
out.
C
So
we
have
the
protocol
document,
which
essentially
describes
the
1
to
1
and
X
message
exchange
between
a
client
and
a
server
and
the
API
that's
required,
and
implementation
of
that
API
based
on
the
Kitab
codes,
graphic
implementation,
that
we
use
the
architecture
document
which
lays
out
the
wider
ecosystem
that
we
could
construct
around.
That
protocol
with
the
clients
and
servers
that
interact
together
in
that
ecosystem
and
how
key
management
and
works
and
the
analysis
of
the
session
privacy
concerns
around
that.
C
And
then
the
HTTP
integration
witnessed
even
touched
upon
may
be
something
that
we
coordinate
with
the
b3c
further
down
the
lines
and
I
think
currently
we're
thinking
that
we'll
write
these
document
to
get
version
of
them
and
then
coordinated
WCC
after
bowing.
Maybe
it
would
be
good
to
the
areas
from
it
earlier
and
point
and
and
then
the
other
commitments
in
terms
of
the
scope
guards.
C
C
Four
four:
we
jump
into
the
Charter
some
of
the
open
questions
that
I
just
want
to
raise,
and
so
the
milestones
for
the
group
are
essentially
going
to
be
these
core.
If
we
called
documents-
and
we
currently
don't
have
any
exact
timeframes
for
those-
but
maybe
this
is
something
that
we'd
want
to
agree
either
now
or
on
the
mailing
list.
Afterwards,
and
in
terms
of
milestones,
that
may
also
be
extensions
that
we
might
want
to
coordinate
and
deciding
a
policy
on
accepting.
C
Those
extensions
might
be
something
that
we
want
in
the
Charter
in
in
terms
of
how
the
working
group
would
review
and
edit
and
accept
these
extensions
and
obviously,
if
there's
any
other
feedback,
that
would
be
very
useful
for
is
so
I
think
I'm
at
the
end
of
my
side
service.
There's
any
questions
before
I
want
to
jump
in
these
dachshund
Venkata.
B
F
F
You
had
mentioned
that
you
are
seeing
these
existing
three
documents
as
being
sort
of
key
milestones
for
the
group
mom,
but
I
wanted
to
sort
of
ask
how
how
strongly
we
really
are
tied
to
that
breakdown,
as
opposed
to
potential
other
ways
to
divvy
up
the
work
in
this
space
and
also
to
ask
whether
the
new
security
and
privacy
analysis
would
be
bundled
into
those
three
documents
or
a
separate
milestone,
obviously,
would
be
a
deliverable
of
the
group
regardless.
So
how?
How
strongly
tied
are
used
to
those
three
existing
documents,
as
the
milestones.
C
If
people
that
some
of
this
work
could
be
incorporated
into
and
a
difference
into
a
condensed
into
fewer
documents
or
made
out
into
more
documents
and
that's
something
we
can
definitely
discuss,
and
maybe
this
maybe
that
would
be
the
best
thing
to
get
forward
and
then
in
terms
of
the
security
and
privacy
concerns
I,
either
thing
so
I've
highlighted
them
here
is
there
I,
think
I
believe
they're
very
important
to
be
and
insatiably
the
ecosystem.
But
there
are
things
that
are
covered
in
the
architecture
document
specifically
I'm.
F
Very
good,
and
then
my
second
question
I
think:
can
we
go
back
one
for
their
slide?
We
were
talking
about
how
the
issuer
is
through.
Providing
the
validity
of
some
attribute
being
held
by
a
client
and
I
was
sort
of
wondering
if
we
see
it
as
pretty
fundamental
that
any
single
token
gives
indication
of
one
single
attribute
and
as
a
corollary,
that
any
single
issuer
only
issues
tokens
about
that
single
attribute,
I
know,
we've
talked
about
sort
of
there
is.
F
C
So
I,
this
is
maybe
something
that
Stephen
may
also
want
to
comment
on,
but
I
think
and
personally.
The
the
base
and
one-to-one
relationship
between
the
issue
is
key,
and
the
attribute
that's
being
considered
in
the
sense
of
any
one
issue
is,
should
no
need
to
be
checking
for
that.
Actually
getting
that
key
should
and
the
key
that
you
use
essentially
corresponds
to
whether
the
HV
is
open
or
not
so
V
yeah.
H
Okay,
Martin
Johnson
Thompson.
We
are
not
on
the
same
page,
I,
suspect,
I,
understand
this
is
a
property
of
the
system
as
described
to
us,
but
what
the
one
that
we
have
an
existence
proof
for,
but
I
don't
think
this
is
a
necessary
property
of
a
system
of
this
shape,
necessarily
and
so
I'm
aware
of
techniques
such
as
those
in
digi
cache
where
clients
and
servers
or
sorry,
clients
and
issuers
can
agree
on
information
that
is
that
carries
across
with
tokens
and
that
potentially
offers
a
different
different
way
out.
H
But
for
some
of
these
problems,
when
we
get
into
saying
that
clients
and
servers
have
to
bit
and
issuers
have
to
have
a
single
purpose,
then
we
introduce
some
interesting
privacy
implications
in
the
sense
that
now,
if
the
any
party
involved
can
decide
on
what
property
they
want
to
carry
across
and
what
combination
of
properties
they
want
to
carry
across,
then
you
have
lose
control
or
could
lose
control
over
the
information.
That's
transferred
across
I
I
think
a
little
uncomfortable
with
that.
H
I
would
like
to
see
a
little
more
discussion
about
the
relationship
between
the
different
entities
involved
before
we
get
into
concretely
putting
those
those
things
down
in
the
Charter.
I
see
that
be
the
Charter.
This
up
online
doesn't
explicitly
list
those
documents.
So
I
would
like
to
talk
through
that
stuff,
first
and
I'm,
more
or
less
okay
with
the
Charter,
but
I'm
not
sure
about
some
of
the
specific
details
again
so.
F
Mt
just
to
jump
in
real
quick.
This
has
been
key
Rock
as
ad
when
you
said
that
you
wanted
to
see
further
discussion
about
through
the
relationship
between
the
entities.
Would
you
be
proposing
that
we
specifically
charter
just
to
do
that
discussion
and
plan
to
reach
harder
before
taking
on
the
specific
protocol
or
radii
bindings
work?.
H
Probably
more
along
the
lines
of
specifically
set
out
to
to
address
those
those
questions.
First,
before
talking
about
adoption
of
any
documents,
presentation
here
suggested
those
documents
were
essentially
it,
whereas
I
think
we
have
a
little
more
flexibility
in
terms
of
where
whether
the
group
ends
up
sure.
C
S
C
So
and
centralization
in
the
sense
that
all
the
issue
is
coalesce
around
the
single
entity,
yes
or
smoke
very
small
number
of
entities-
yes-
and
that
is
not
something
that
we
currently
consider
and
I-
think
I
appreciate
the
point.
I
think
that
is
something
that
could
that
could
be
a
problem
going
forward.
I
think
one
of
the
things
one
of
the
open
questions
we
have
is
kind
of
how
this
ecosystem
is
developing
and
there
were,
it
may
be.
The
way
we
construct
it
currently
is
not
how
it
would
continue,
but
I
think
partially.
C
E
Guess
today,
if
a
couple
of
points,
I
may
only
cover
some
of
them
right
now
and
wait
until
you
get
down
other
parts,
but
since
you
open
it
up
here,
just
to
repeat
some
of
the
previous
ones,
like
I,
think
part
of
the
question
is
whether
the
Charter
should
constrain
the
work
to
talk
about
the
case
where
the
information
is
about
human
test
versus
some
other
attribute.
Currently,
the
first
line
implies.
The
answer
is
yes.
If
that
is
the
intent,
then
that
sentence
is
good.
If
you
want
to
widen
it,
that
sentence
is
bad.
E
E
Think,
as
I
did
a
search
yeah
right
there
right
below
the
cursor,
where
it
says
responses
for
web-based
applications
and
so
right
now
the
the
document
for
one
an
ACP
is
web-based,
but
the
rest
of
the
work
is
not
web-based
and
so
I
don't
know
whether
that's
the
intent
here
so
right
now,
it
looks
like
the
entire
intent
is
to
scope
it
to
human,
but
only
that
one
particular
item
was
meant
to
scope
it
to
a
web
and
I.
Don't
know
if
that
was
what
was
desired.
C
Alec
speaking
so
I
think-
and
this
is
potentially
just
initiated
text
I-
think
I
agree
with
your
point
about
human
I
think
we
could
probably
extend
beyond
human
to
client,
and
there
was
a
reason
that
we
chose
were
human
initially
that
I
can't
remember.
So
maybe
if,
if
someone
wants
to
jump
in
and
remind
me
of
that,
but
I
think-
and
it
said,
the
crucial
thing
here
is
that
we're
scoping
to
the
web
context
and
okay,
then
so.
E
So
layer
is
like
the
very
first
paragraph
or
something
like
that,
may
need
to
be
updated
to
talk
about
the
school,
but
specifically
down
to
the
web
context.
I
I
agree
with
the
notion
of
hey,
let's
scope
stuff
as
narrowly
as
makes
sense
to
fit
the
current
demands
and
things,
and
so
the
thing
that
this
one
is
scoop
to
the
web
is
okay
with
me.
K
T
K
B
C
P
I
Three
points
on
so
there's
some
assessments
and
Jabbar,
but
I
think
there
needs
to
you
some
material
in
here
about
like
have
it
have
II
know
somebody
named
Ben
done
I'll
say
it
again,
arrows
o'clock
on
anyway
on
their
identities
of
some
text
in
here
about
the
ability
of
the
client
to
verify
it
decided
something
emphasized.
The
enemy
said
they're
in
right,
just
a
lot
of
stuff
about.
You
know
what
happened
its
use,
a
separate
key
for
each.
I
You
know
for
prepping,
you
issue
right,
so
I'm,
not
something
I've
got
a
problem
solved
now,
but
I
think
that
it's
gonna
work
about
the
class
way
verifying
that
it
is
not
basically
being
cheated
by
the
by
the
server,
which
is
presently
really
presently
be
the
case
again.
The
problems
is
almost
why
they're
working
group
on
the
second
point,
as
MT
sort
of
pointed
out,
this
seems
very
oriented
towards
turn.
There's
one
bit
of
information.
I
I
Sorry
this
this
is
the
paragraph
said,
as
we
hope
to
have
a
number
of
interoperable
particular
clear
analysis
secured
in
privacy
considerations.
I,
really
think
that
a
clear
analysis
of
survivorship
considerations,
along
with
formal
proof,
I,
really
ought
to
be
a
requirement
for
doing
any
work
in
this
space.
Oh,
not
not
a
nice
to
have.
C
Alex
speaking,
thank
you,
Eric
and
so
on.
Your
first
point,
I
agree
that
should
be
in
the
chart.
I
think
that,
maybe
is
something
we've
missed
out,
and
so
currently
we
do
have
the
functionality
for
the
client
to
be
able
to
verify.
They
are
certain
anonymity
set
because
they
they
can
verify
in
zero
knowledge
that
the
server
has
used.
C
The
key
is
already
committed
to
you,
so
that's
that
is
something
that
we
should
include
in
there
if
it's
not
already
specified
and
on
your
second
point,
I
didn't
actually
catch
it,
but
on
your
third
point
and
I
agree:
I
think
that
needs
to
be
worded
as
a
requirement,
and
so
we
do
have.
We
have
a
formal
database,
cryptographically
proof
of
the
primitives
and
we
might
want
to
get
a
little
further
further
down
the
line,
but
yet
that
that
should
be
words
of
the
quadrants
chancellor.
So
thank
you,
sir.
I
Of
information,
namely
this
authenticated
and
there's
a
discussion
of
like
a
bunch
of
clunky
mechanisms
for
having
more
than
one
bit
I
like
you
know,
high
multiple
keys,
but
as
empty
pointed
out,
there
are
techniques
which
are
known
for
on
carrying
substantially
more
bits
in
the
same
kind
of
anonymous
token,
and
you
know,
maybe
we
don't
need
to
have
those
on
and
be
one,
but
it
should
be
nice
not
have
to
ruled
out
by
the
design.
Hey
I
could
I
tell
us
in
a.
A
E
A
F
A
I
I
B
I
Abode
I,
agree
and
I
think
the
bits
question
one
of
the
use
cases
has
seen
previous
in
the
past
for
for
additional
bits
of
information
is
more
like
binding
public
information
to
these
tokens
as
well
as
so
classically.
What
are
the
use
cases
that
is
not
enabled
as
protocol
is
to
find
some
public
information.
So,
for
example,
I
can
add
one
of
the
use
cases
we
had
was
like
in
an
ad
ecosystem.
I
You
want
to
be
able
to
bind
the
campaign
to
an
anonymous
tokens
that,
like
you,
can
that's
additional
conference
that
this
token
was
issued
for
this
particular
campaign.
Why?
If
you've
got
it,
you
could
make
it
work
with
like
multiple
keys
per
campaign
attribution,
but
it
it
makes
the
ecosystem
problems
more
complicated.
So
I
guess
the
question
is
more
about
like
I
think
it.
A
C
I
I
B
T
Thanks,
one
of
my
concerns,
fear
is,
is
this
potential
for
a
very
narrow
band
of
issuers
right?
It
basically
is
sort
of
almost
prompt
and
consolidation.
What
I
don't
see
in
the
Charter
is
a
mechanism
to
a
mechanism
to
prevent
that,
in
fact,
I
think
about
the
three
documents
it
certainly
it
doesn't
seem
to
me
like
it
could
be
a
feature
of
the
protocol
document.
C
Think
but
again,
this
is.
This
is
definitely
something
that's
intended
to
the
architects
document,
but
is
not
necessary.
Don't
necessarily
have
a
great
underscore
right
now
and-
and
it
is
one
of
the
two
dues
that
is
the
official
to
dues
and
that
we
currently
have
so
I-
think
it's
it's
a
very
important
point
and,
and
it's
something
that
we
all
have
to
solve
in
order
to
achieve
this
milestone,
there's
also
long
video.
T
Yeah
I
mean
that's
helpful.
I
think
the
that
that
that
auditing
mechanism
is
something
that
is
very
difficult
for
me
to
imagine,
because
I
I
can't
think
of
a
parallel
that
we
have
to
a
model
to
work
from
so
I
agree
with.
You
I
think
that
that
is
a
really
thorny,
open
problem.
It
makes
me
it
makes
me
worried
about
the
whole
enterprise.
Let's
be
honest,
Thanks.
D
Mariana
recover
Google
I
wanted
to
make
a
comment
about
this
edition
of
this
I
think
whether
they're
public
defined
by
the
client
or
by
the
issuer
I
think.
In
both
cases
there
is
the
kind
of
partitioning
of
the
anonymity
set
and
I
think.
Both
of
these
extensions
are
valid,
interesting
extensions
that
Steven
mentioned.
D
C
Hi
Alex
speaking
and
yeah
I
think
this
is
something
that
we
should
that
we
should
discuss
in
the
document,
because
I
think
it's
clear
that
they
were
going
to
be
used
cases
the
kind
of
one
this
functionality
and
we're
going
to
I
think
so.
It
is
something
we
should
consider
in
be
in
decor
deliverables
and
I.
C
Think
you're,
probably
like
ill,
probably
span
both
the
protocol
and
the
architecture
documents
depending
on
whether
it
requires
changes
to
functionality,
but
yeah
I,
agree,
I,
think
if
something
we
should
do
in
this
I
think
its
height
is
probably
closely
related
to
the
number
of
the
number
of
issues
that
we
haven't
also
the
number
of
rotations
that
they
do.
But
again
it's
something
we
can
consider.
B
G
C
So
I,
Alex
speaking
and
so
I
agree,
I
think
so
it
is
clear
that
consolidation
here
is
something
that's
missing
from
the
Charter
and
it's
something
that
we
will
have
to
consider
the
length
in
the
architecture
and
we
and
again
this
comes
into
sort
of
like
auditing.
This
centralized
repository
of
issue
is
which
are
deed,
to
be
trusted
by
the
clients,
and
we
will
need
a
good
solution
for
that.
H
H
Steven
Farrell
points
out
this.
So
if
the
browser's
are
going
to
make
this
decision
for
users
and
when
you
talk
about
things
beyond
the
is
a
human,
which
is
something
that
maybe
a
browser
might
assume
someone
using
a
browser
is
willing
to
to
advertise,
it
gets
a
little
tricky
and
knowing
what
that
information
is
so
that
you
can
make
a
decision
about
whether
to
propagate
it
is
is
something
that
I
think
we
becomes
very
difficult
to
reason
about.
Now,
whether
the
protocol
needs
to
transfer
that
information
or
not,
is
something
that
we
should
debate.
C
Alex
agency
things,
thank
you
that
point
I,
think
that
is
days
an
interesting
point
because
I
think,
and
so
where
I
mean
the
third
document.
Http
document
is
essentially
with
the
aim
of
May
now
and
API
would
be
a
natively
available
in
browsers
and
I.
Think
you
raise
an
interesting
point
about
what
whether
the
browser
or
the
human
or
wherever
is,
is
making
the
decision
on
who
to
trust,
I,
think
and.
C
Yeah,
that's
not
that
study
something
I've
considered,
but
I
could
see
the
value
in
doing
that.
I
think.
Maybe
what
we
go
forward
from
practical
spectacles,
maybe
the
browser
could
offer
the
human
the
chance
to
unsubscribe
from
certain
issue
is:
if
they
didn't
feel
like
it,
if
they,
if
they
felt
like
that
and
I.
H
Don't
think
I,
don't
think
asking
for
forgiveness
is
really
the
right.
The
right
approach
to
take
in
this
case
I
think
it's
just
a
question
that
we
need
to
need
to
think
about
a
lot
more.
It's
not
only
who
is
issuing,
but
it
is
what
for
and
the
scope
of
the
information
is
being
transferred
and
I
just
see.
Wendy's
pointed
out
p3p
again
we
talked
about
pizza
at
people
once
already
this
week
and
I
would
not
like
to
be
talking
about
that
again.
B
A
So
it
seems
like
we
have
had
a
decent
discussion
on
the
Charter
and
there's
definitely
work
to
be
done.
I
encourage
people
to
join
the
privacy
pass
list,
so
we
can
work
on
that
in
between
well
after
this
meeting
is
done,
I
guess
a
question
for
for
Ben
and
Roman.
Are
there
things
that
you
would
like
to
see
from
this
meeting?
That
would
would
help
you
questions
that
we
haven't
asked.
F
So
I
don't
think
that
there's
a
whole
lot
more
I
would
like
to
get
out
of
this
meeting
specifically
I.
Think
we've
already
gotten
quite
a
bit
of
value.
We
have
a
large
body
of
interest
in
this
topic
and
we've
sort
of
agreed
upon
several
areas
or
topics
that
we
want
to
get
or
their
discussion
on
and
further
text
into
the
Charter.
E
Yes,
one
last
question
when
talking
about
this
scoping
is
because
a
lot
of
the
discussion
has
been
around
the
notion
of
transferability
or
the
lack
thereof
or
non
transferability,
the
lack
thereof,
and
so
the
question
is
really
should
the
Charter
spoke
this
to
this
discussion.
Essay
2,
assuming
that
transferability
cannot
be
prevented.
Should
it
say
that
such
work
should
be
investigated
by
this
working
group?
We
should
say
nothing
just
leave
that
to
discuss
of
the
architecture.
That's
done
by
the
working
group,
I.
B
E
So,
for
example,
that
current
proposed
protocol
is
designed
in
a
way
that
assumes
that
transferability
cannot
be
prevented.
Okay,
and
so
the
question
is:
should
this:
should
the
Charter
scope
the
working
group
to
work
on
cases
that
are
designed
for
cases
where
transferability
cannot
be
prevented
or
B?
Should
it
say
that
the
working
group
will
also
discuss
any
other
ways
to
deal
with
preventing
transferability,
or
should
it
say
nothing
and
leave
that
discussion
to
the
actual
work
inside
of
say
the
architecture
document.
C
So
my
personal
feeling
is
maybe
either
and
I.
Think
transferability
is
definitely
something
we
have
to
discuss.
I,
don't
necessarily
think
it
belongs
in
the
Charter.
But
maybe
what
we
could
say
is
something
like
we.
We,
the
tokens,
must
be
in
linkable
with
some
providers
based
on
additional
metadata
and
it
it
ends
on
the
sort
of
mechanisms
that,
if
their
future
mechanisms
just
investigating
discus
that
may
make
transferability
and
not
possible
intimating.
O
P
O
O
B
M
U
So
this
is
Stu
card
here
sitting
with
Adam
Whittaker,
so
the
issue
of
non
transferability
relates
to
the
nature
of
the
authorization.
One
of
the
slides
said
that
the
the
first
goal
was,
for
the
token,
to
show
that
the
client
holds
a
certain
attribute
and
I
want
to
draw
a
distinction
between
two
subtly
different
things.
The
client
having
an
attribute
and
the
token
attesting
to
that
fact,
is
completely
different
from
the
client
having
a
right
that
the
issuer
granted
him,
because
at
some
time
he
proved
that
he
held
some
attribute.
U
If
the
token
represents
the
right
granted
by
the
issuer,
because
the
client
proved
that
at
some
point
in
time
he
had
this
attribute,
then
it
doesn't
need
to
be
non-transferable.
Transferability
is
no
problem,
but
if
the
token
supposedly
represents
that
the
holder
of
the
token
actually
still
now
is
the
same
guy
that
at
some
point
in
the
past,
held
that
attribute,
then
by
god
it
it
better,
be
non-transferable.
U
A
I
was
going
to
touch
on
this
question
of
transferability.
You
know
I
actually
think
Alex's
was
about
the
right.
Notify
goes
as
an
issue
for
study
and
we
should
try
and
get
some
precision
on,
but
I
don't
think
I
would
be
comfortable
at
this
stage,
putting
some
real
hard
requirements
in
turn
around
this.
It's
not.
I
I
Course,
Carla
yeah
I
can
curvature
I'm
in
particular
I'm
we
up
I'm,
not
entirely
sure
I
know
how
to
define
not
transferability
in
facebook.
Arbitrary
collision
between
the
person
of
the
token
was
issued.
That
person
is
redeeming
it
then
they
might
as
well
be
the
same
person.
So
it's
like,
like
that.
Actually
a
financing
is
quite
not
so
forward
so
I'm
about
to
station,
but
not
necessarily
help
so
AUSA's
I.
Think,
like
we
had
to
put
I,
think
I.
Look
this
season.
One
proposed
a
strict
definition.
Certainly
before
you
put
the
Charter.
F
T
C
Alex
Davidson
speaking
I
think
this
is
something
that
we
think
I
mean.
We
have
the
protocol
now
the
core
protocol
that
we
plan
to
use
there
might
be
some
minor
changes
to
that.
But
I,
don't
think
the
API
that
we're
going
to
use
this
going
to
change
substantially,
and
this
is
something
the
weakest
but
again
I
mean
it
would
be
it'd,
be
good
to
get
some
consensus
on
that
I
think.
F
A
Okay,
I,
don't
think
that
we
have
I,
think
we've
kind
of
covered
what
we
came
here
to
cover
and
now
it's
a
matter
of
working
at
the
charter
details
on
the
list,
so
yeah
I
think
Ben's,
suggestion
of
proponents
going
off
and
reworking
the
Charter
based
on
today's
discussion
and
then
having
that
discussion
on
the
privacy
pass
list.
It's
a
good
one.
So.