►
From YouTube: OpenActive W3C Community Call / 2020-03-11
Description
Customer authentication continued;
* Use case 1: User account is with broker only
* Use case 2: User account is with seller only
* User account has both broker and seller accounts
A
A
This
is
annoying
there
we
go
yeah,
so
this
is
really
about
customer
authentication
and
how
this
relates
to
the
booking
specification
and
what
kinds
of
user
experience
it
allows
or
for
bids
as
a
technical
proposal
and
the
easiest
way,
I
think,
to
get
your
head
wrapped
around.
This
is
to
click
on
the
link
there,
the
to
the
to
the
github
issue,
120,
there's
a
very
extended
thread
there
in
terms
of
the
spec
itself,.
B
A
A
A
The
really
extensive
documentation
is
all
issue
120
connected
to
the
booking
spec,
quite
a
long
thread
there,
almost
entirely
written
by
nick
who's,
been
refining
and
refining
this
over
the
last
couple
of
calls
to
do
with
this,
and
I
think
the
aim
of
today's
call
is
really
to
finalize
this
and
move
forward
with
the
specifications
we
can
all
get
get
on.
Implementing.
A
The
concrete
proposal
would
be
to
add
an
access,
token
property
which
would
allow
access
tokens
to
be
shared,
obviously,
an
authenticated
person
subclass
of
person,
which
would
be
identical
in
most
respects,
except
that,
of
course,
it
would
indicate
that
a
person
had
authenticated
using
the
access
token
and
then
a
couple
of
properties
allowing
transmission
of
the
fact
that
authentication
was
possible
and
commute
and
allowing
definition
of
the
user
journey
from
there.
So,
as
the
specification
goes,
it's
not
terribly
terribly
dramatic,
but
there
are.
A
A
So
in
the
case
of
concretely
mcr
active
that
would
be
mcr
active
itself
use
case.
Two
is
where
the
user
account
is
with
the
seller
only
and
there
is
no
account
with
the
broker.
So
in
this
case
it
would
be
the
leisure
center,
for
example.
So
if
the
user
had
an
account
with
the
ledger
center,
but
not
an
mcr
active
account,
how
would
that
be
mediated?
A
A
So
that's
the
general
picture
in
previous
calls
use
case.
One
has
found,
has
been
found
to
be
generally
speaking,
unproblematic.
There
are
certain
limitations
on
the
complexity
of
the
offer
structure
that
can
be
offered
under
use
case
one,
but
I
think,
for
practical
purposes.
This
isn't
really
an
issue.
The
difficulty
has
sorry.
The
difficulty
has
really
been
with
use
cases
two
and
three.
A
If
a
booking
has
been
made
via
the
broker
interface,
then
a
cancellation
could
also
be
made
via
the
broker
interface,
and
that
seems
fairly
clear.
But
what
happens
if
the
user
goes
directly
to
the
seller
interface
or
the
seller
system
and
cancels
there?
Is
there
some
kind
of
mismatching
user
journey
there?
I
think
this
was
been
solved
fairly
neatly
simply
by
saying
follow
the
spec,
really,
even
in
the
event
of
a
seller
system
cancellation.
A
B
Could
I
just
add
that
little
the
just
to
kind
of
really
make
clear,
because
I
think
this
is
one
of
wayne's
points
of
concern
and
wayne's,
not
on
the
call,
but
just
to
really
really
flag
what
the
thing
that
was
the
challenge
that
was
presented,
I
think
two
calls
ago
and
how
this
hopefully
solves
that
and
to
everyone's
satisfaction.
So
challenge
was,
if
I
go
into,
let's
make
it
really
really
tangible.
B
If
I
log
into
gll-
and
I
make
a
booking
in
there,
I
expect
to
be
able
to
manage
my
booking
in
gll
right.
That's
that's
how
things
currently
work
everyone's
happy
with
that.
If
I
make
a
booking
through
mcr
active
and
I've,
I've
not
got
a
gll
account.
So
if
there's
no
there's
no
existing
membership,
no
monthly
membership,
nothing
like
that,
but
make
a
booking
through
mcr
active.
B
However,
in
the
case
where
here,
you
have
a
monthly
membership
and
you've
connected
that
monthly
membership
to
your
mcr
active
account,
then
if
you
make
a
booking
through
mcr
active
in
that
case,
then,
when
you're
in
your
gll
account
you'll
see
that
booking
appear
because
you're
working
under
the
same
membership
id
and
therefore
it
will
be
an
account
like
any
other
booking
would
be,
which
makes
sense
because
you're
booking
it
under
your
monthly
membership.
So
you
know
if
there
was
any
type
of
like
limitation.
B
For
example,
I
can
only
book
five
classes
a
month
or
something
for
that
particular
book.
I
mean
systems
vary,
but
you'd
want
to
see
that
registered
there
against
the
membership,
so
that
you
could
understand
why
you've
only
got
two
classes
left
to
book
or
whatever
it
makes
sense
that
it's
in
there.
I
think
everyone
was
was
expecting
it
to
be
in
there.
The
question
is,
though,
what
what
happens
if
you
cancel
the
thing
that
you've
booked
so
and
then
what
are
the
two
routes
to
do
that?
B
Well,
the
two
weeks
are
the
first
three
is
I
go
back
to
mcr
active
and
I
cancel
it.
That's
easy
because
you'd
expect
to
get
notifications
from
mcr
active
in
that
case,
how
about,
though,
if
you
go
to
gll
and
cancel
it
so
I
go
into
my
gll
account
and
cancel
something
that
was
booked
through
mcr
active.
B
What
happens
then
does
does?
How
does
the
notification
come
to
the
user?
Is
it
the
gll
sends
the
notification
through
legend
as
the
booking
system,
or
is
it
that
you
get
the
notification
terms,
you're
active
and
so
taking
an
analogy
to
how
this
works
in
in
the
travel
industry
and
the
way
the
systems
work
there?
If
you
book
something
through
a
travel
agent
like
a
flight,
let's
say
you
book
a
easyjet
flight
or
something
you
can't
then
change
that
flight.
B
By
going
direct
to
easyjet,
you
have
to
go
to
the
travel
agent
to
change
the
flight,
that's
how
they
do
it.
So,
if
you,
if
you
call
up
like
I
did
recently
and
asked
to
change
a
flight
direct
they'll,
just
tell
you
to
go
to
the
travel
agent,
even
if
the
travel
agent
isn't
open
at
that
time
and
the
time
zone
is
different,
it's
gonna
be
quite
frustrating.
So
that's
that's.
What
they
do,
however,
the
proposal
here
is
actually
because
we've
got
a
bit
more
flexibility
than
that.
B
It's
a
bit
of
a
middle
middle
ground
that
we're
proposing.
So
actually
you
could
cancel
or
even
reschedule
the
appointment
within
gll
and
front
desk
could
do
that
as
well.
They
could
cancel
a
reschedule
and
whatever
action
you
take.
The
proposal
here
is
that
that
action
is
reflected
with
an
email
from
the
broker.
B
So
what
that
means
is
if
you've
booked
something
through
mcr
and
you
log
into
your
gll
account
and
your
monthly
member.
You
can
cancel
or
reschedule
the
thing
within
legend
as
you'd
expect
to
do
usually
and
the
notifications
would
come
through
mcr
because
it
was
originally
booked
through
mcr,
and
that
means
that
any
refunds
or
cancel
or
payment
processing,
which
is
all
through
mcr,
would
be
handled
as
well.
Everything
handles
basically,
as
tim
says,
everything
is
as
normal.
It's
just
that
you
can
trigger
it
through
legend.
B
If
you
want
to-
and
of
course
legend
don't
have
to
implement
that
feature
or
any
booking
system
doesn't
have
to
implement
that
feature.
You
can
just,
but
it's
an
option:
that's
there.
Should
they
desire
to
have
give
their
customers
that
level
of
control?
That's
the
detailed
version,
that's
helpful
tim.
I
don't
know.
A
E
I
remember
discussing
this
some
time
ago
and
I
I
thought
we
had
agreed
quite
some
time
ago.
So
maybe
it's
of
the
I
think
it's
evolved
since
then,
but
I
don't
recall
that
that
you
would
that
we
would
force
customers
to
cancel
via
the
channel
in
which
they
booked,
because
that's
by
far
the
simplest
solution
for
the
customer,
it
doesn't
add
any
variables
that
might
cause
a
bit
of
confusion.
Well,
can
I
book?
Can
I
cancel
here?
Can
I
cancel
it
there?
What
happens
if?
E
B
Conversation
and
yeah,
yes,
and
I
think
I
think
I
think
the
last
the
last
call
wayne
kind
of
challenged
that
and
said
I
I
don't
know
if
that
makes
sense
for
it
that
their
challenge
was.
I
don't
know
if
that
makes
sense
for
the
case
where
you'd
expect
to
look
in
your
gll
account
and
see
the
thing
you've
booked.
B
So
I
guess
this
was
a
kind
of
a
suggested
middle
ground
that
covered
both
of
those,
but
I
mean
potentially,
as
you
say
well,
I
suppose,
with
the
proposal
as
it
stands,
like
the
the.
As
you
say
there,
it's
an
optional
feature
for
legend
to
be
able
to
implement
that,
so
they
could
easily
not
do
that
and
therefore
it
would
be
a
simple
case
of
the
channel
through
which
you
worked
soon.
Also
it
could
be
configurable
so
that
you
know
certain
operators
that
use
legend
if
they
really
wanted
to
implement
this
feature.
E
Yeah,
I
suppose
I
suppose
the
counter
argument
to
the
point
I
just
put
across
is
the
fact
that
I
mean.
Ultimately,
we
could
argue
that
it's
actually
easy
for
customers
to
be
able
to
book
to
cancel
to
any
channel
regardless
how
they're
booked
if
they've
connected
their
membership,
legend
online
or
services
account
to
a
msr,
active
or
msr
active
equivalent.
If
there
were
one
which
case,
then
it
just
makes
it
easy
for
them
to
do
so.
E
But,
but
I
I
can't
I
kind
of
view
on
this-
is
that
if,
if
you're,
a
regular
booker,
then
you're
not
booking
through
interactive
you're
booking
through
gll's
legend
online
services
account
or
you're
booking
through
the
app?
In
which
case,
then
cancellation
is
straightforward.
We're
talking
about
the
people
who
are
finding
out
about
activities
via
the
msr
active
website
and
are
by
nature,
because,
if
they're
occasional
bookers,
then
my
view
is
that
they'll
be
canceling
through
msr
active
and
not.
B
B
B
So
if
legend
or
other
booking
systems
want
to
allow
for
cancellation
direct,
as
you
say,
for
the
benefit
of
the
user
journey
or
make
it
easier
for
the
customer
or
for
anyone,
and
they
can
do
that,
but
obviously
the
booking
system
doesn't
have
to
implement
that.
Therefore
yeah,
it's
like
a.
If,
basically,
if
legends
really
want
to
do
it,
they
can
do
it.
B
E
Yeah,
okay,
so
again,
I'm
just
trying
to
think
of
I
mean
I.
I
agree
with
what
you
said
nick
and
I
think
these
the
user
case
is
going
to
be
exceptions
rather
than
the
norm,
because,
again
thinking
through
how
the
msr
active
thing
is
going
to
work,
is
that
presumably
you'll
have
glr
customers
who
connect
to
their
msr
active
account
because
they
want
to
make
bookings
outside
of
gll
in
which
kcm
activity
fund
is
going
to
help
them
find
those
locations
and
activities
and
they're
going
to
book
them.
C
E
Only
way
of
canceling
those
is
through
msr
active,
not
through
gll,
so
anybody
who's
booking
regularly
but
is
connected.
Will
I'm
almost
certain
continue
to
use
the
gll,
app
or
jll
booking
online
services
platform,
so
so,
therefore,
making
it
optional,
I
think,
is
probably
a
reasonable
compromise
and
if
legend,
as
you
said,
want
to
do
it,
then
it's
up
to
them,
but
at
least
they're
not
compelled
to
do
it.
A
E
C
C
Hey
nisha
yeah.
I
actually
wholeheartedly
agree
with
what
you
said
stephen,
which
is
that,
from
a
spec
point
of
view,
as
long
as
it's
in
there
and
is
defined
and
the
user
use
cases
can
be
catered
for
if
the
chosen
duplicated
for
then
we
kind
of
have
some
flexibility
to
figure
out
how
how
we're
gonna
you
know
for
mcl,
specifically
how
we're
gonna
work
with
legend
to
make
that
happen,
and
also
in
the
future.
When
there
is,
you
know
another
council
that
wants
to
do
something
different.
C
F
B
If
you
said
I
mean
so
effectively,
not
implementing
it
and
implementing
it
and
never
using
it
from
the
perspective
of
implementers
is
going
to
look
the
same,
and
the
mechanisms
for
cancellation
are
the
same
as
they
were
for
people
who
have
booked
without
customer
authentication,
so
you're
you've
already,
if
you've
built
your
system
to
to
handle
cancellation
anyway,
you've
already
built
all
the
bits
you
need
as
a
broker
to
deal
with
this.
It's
just
a
case
of
whether
those
updates
from
the
orders
feed
that
come
back,
saying
you've
got
a
cancellation.
B
B
Is
you
as
a
as
a
broker,
you
would
say
to
legends
to
gll
I
want
I
want
to
trigger
a
my
customer,
has
asked
to
trigger
cancellation
for
that
symbol,
class
and
then
gll
says
okay,
I
confirmed
and
then
when
it's
confirmed
the
pro,
the
broker
must
process
that
cancellation,
so
what's
happening,
is
that
first
step
is
just
being
triggered
by
the
by
gll
directly.
So
instead
of
the
trigger
coming
from
the
the
broker,
it's
just
spontaneously
coming
from
the
the
booking
system.
B
A
A
A
If
you've
got
a
service
that
gathers
together,
multiple
providers
like
mcr
active
one
of
them
decides
to
implement
one
of
them.
Doesn't
then
you've
got
these
sort
of
slightly
different
flows
for
possibility
of
cancellation,
but
I
don't
think
that's
particular
you
know
for
any
for
any
one
booking
you've
made
it's
going
to
be
fine,
so
yeah,
it's
going
to
be
somewhat
disjointed
experience
if
you
make
lots
of
bookings
from
multiple
different
providers
and
then
try
to
cancel
a
bunch
of
them,
but
I
think
that's.
B
Well
into
education
right
there
yeah,
I
think
I
agree
with
steven
like
it's.
It's
most
people
will
be
canceling
through
the
channel
I
booked,
because
that
just
makes
sense.
Doesn't
it
that's
what
you'd
expect,
but
this
is
just
in
that
strange
scenario
where
you
might
have
the
gll
app
or
something
and
go
in
and
cancel
there
or
go
into
a
call
up
center.
That's
another
thing
you
could
do.
Can
you
do
the
same?
If
you
call
up
center
and
say
I'd
like
to
cancel
this,
they
can
press
a
button
on
their
screen.
B
B
So
the
sensor
calls
up
and
says
you
know
as
they
go,
maybe
have
their
phone
number
that
we
don't
have
whatever
today
or
something.
You
know
the
instructors,
different
structures
coming
in
or
whatever
and
the
customer
says.
Can
I
cancel
them,
please
that
the
center
is
unable
to
initiate
that
cancellation
or
the
customer
says.
Well,
I
actually
would
that
squash
court
with
the
lights
broken
is
really
inconvenient
for
me
and
they
could
just
move
the
they
can
reschedule
it
there
and
then
they
want
to.
B
This
is
it
yeah.
Really,
it
really
is
that's
the
thing
with
it
and
I
think
that's
where
kind
of
wait.
I
think
wayne's
challenge
was
a
fair
one,
which
is
we
need
to
make
sure
it's
consistent
and
like
it
covers
all
the
cases
so
that
the
people
who
are
building
the
software
can
make
their
software
consistent,
and
I
guess
what
I
I
mean
again
without
oh
yeah.
We
should
check
this
with
wayne,
but
like
I'm
guessing
what
he
was
thinking,
there
was
well
either.
They
can
just
have
no
buttons
available
right.
B
B
A
D
E
So
if
we
cancel
a
booking,
if
you
were
to
reschedule
it
technically
to
move
it
from
one
space
to
another
space,
then
that
attracts
a
cost
because
legend
doesn't
record
doesn't
recognize
the
fact
you're
moving
a
booking,
that's
already
pre-paid,
to
a
slot
that
doesn't
require
payment
because
it's
been
pre-paid,
oh,
so
you'd
have
to
cancel
and
rebook.
You
have
to
constantly
book
yeah
yeah
great,
I
mean
just
as
an
fyi.
It's
one
of
the
limitations
that
we
we've
never
sort
of
really
planned.
E
B
And
so
I
know
that
gladstone
and
book
when
both
support
rescheduling
so
that
yeah,
but
it's
but
again
the
good
thing
about
rescheduling
is
it
is,
as
it's
expect
an
optional
feature.
So
all
the
legends
would
would
have
to
do
is
just
not
do
anything
for
it
to
not
be
implemented.
If
you
said,
I
mean
yeah,
yeah
agreed
yeah
yeah.
If
anything
is
that
simple,
though
we
could
just
reschedule
yes
right,
okay,
well
and
good,
to
know
that
it's
an
aspirational
goal,
at
least
so
having
it
in
a
spec,
is
future
proofing.
A
Okay,
moving
on
to
the
other
user
journey
issues
that
use
use
cases
two
and
three
bring
up.
It's
mostly
about
the
fact
that
at
step,
one
in
the
booking
process,
you
are
still
not
authenticated
into
the
system,
so
it
and
you're
not
authenticated
onto
the
seller
system.
So
it's
very
hard
to
communicate
user
specific
information
from
the
beginning
of
the
user
journey
so
because
originally
you're,
essentially
an
anonymous
person
looking
at
prices
and
so
on
and
so
forth.
A
Essentially,
the
solution
proposed
with
two
and
three
is
essentially
to
describe
these
problems
as
being
out
of
scope
that
trying
to
trying
to
solve
this
by
having
absolutely
accurate
information
all
the
way
through
the
user
journey
from
step.
One
isn't
particularly
the
current
concern
of
the
specification,
particularly
given
that
one
frequent
use
case
is
going
to
be
aggregation
of
a
lot
of
opportunities
from
a
lot
of
different
providers
anyway.
A
B
Yeah,
I
guess
on
the
last
call
we
talked
about
this,
I
think
at
length,
and
it
was
basically
the
idea
that,
if
you're,
if
you're
booking
things
that
have
got
discounts
like
a
discount
card,
then
you
see
those
prices
on
the
search
screen,
but
because
of
the
crazy
number,
I
think
when
guy
was
on
the
call
before
you
know
they
talk
about
combinations
of
membership.
There's
just
incredible
number
of
those.
B
The
idea
that
you
would
be
able
to
get
completely
accurate
pricing
from
from
a
search
across
all
providers
in
the
city
is
just
yeah.
Everyone's
everyone's
heads
are
kind
of
exploding,
thinking
about
the
ways
of
that
happening,
and
it
it's
such
a
technically
complex
thing
that
potentially
this
stage
just
putting
that
out
of
scope
and
saying
you
know
what,
when
you
get
to
check
out,
you'll
get
your
discount
if
you're
eligible
for
one,
because
that
way,
you're
getting
the
accurate
price.
That's
very
that's!
No!
A
E
Yeah
yeah,
I
think
well,
I
think
we're
comfortable
with
that.
I
think,
on
the
basis
that
that
we
recognize
that
if
anybody
has
a
membership
with
gll
which
entitles
them
to
a
discount,
it
means
they've,
already
gone
through
gll
signing
up
process
which
signposts
them
to
a
better
site,
our
app
our
online
online
booking
platform,
which
then
automatically
delivers
the
right
price
for
their
membership
type.
E
If
somebody's
coming
through
mcr
active
or
an
aggregator
website,
then
the
price
that
is
displayed
on
that
particular
website
is
the
price
they
pay
and
if
you
have
a,
if
you
have
a
member
who
happens
to
go
for
whatever
reason
for
an
aggregated
website
to
make
a
booking,
I'm
kind
of
thinking
well
we're
going
to
display
a
price
that
is
the
headline
price
activity,
they've,
obviously
for
some
reason
or
other
got
to
that
via
a
different
route
than
the
routes
that
we
signed
post
them
to.
So
do
I
really
worry
about
that?
E
I'm
not
sure
I
do
actually,
I'm
not
sure
gll's
really
bothered
about
that.
You
know
we.
We
we
deliver
discounted
price
for
members
while
our
web
journeys.
If
you
want
to
go
somewhere
else,
then
that's
fine.
I
can
make
a
booking
through
booking.com
and
get
a
cheaper
hotel
than
I
can.
If
I
go
straight
to
somebody
else's
website,
but
I
choose
not
to
because
I
know
I
can
get
a
cheaper
price
through
booking.com.
E
C
Yeah,
so
I
think,
unless
I
think,
mcr
have
the
ambition
for
those
users
that
have
authenticated
with
the
membership
that
when
they
get
to
the
to
the
checkout
for
their,
you
know
their
squash
court.
If
they've
got
a
rackets,
membership
they'll
they'll
be
asked
to
pay
the
price
according
to
their
membership
for
that
activity
and
that
that
price
won't
be
displayed
until
they
get
to
the
actual
payment
step.
So
it's
not
about,
including
all
the
offers
up
front.
A
E
Okay,
yeah.
Sorry,
sorry,
nish!
Let
me
just
pick
up
on
that
point.
So
are
you
suggesting,
then,
that
somebody
who
has
a
rackets
membership
or
has
a
standard
membership
with
gll
that
entitles
you
to
a
racket
per
day?
You're
going
to
know
that
information
because
you're
putting
it
from
legend?
In
which
case,
then
you
will
be
able
to
give
that
member
their
first
racket
booking
of
the
day
free
because
it's
included
and
then
the
second
racket
caught
a
book.
The
same
day
is
a
paid
for
booking
question
mark.
C
That's
right,
I
think,
essentially
the
way
I
see
it,
and
maybe
nick
or
tim
can
tell
me
if
I'm
wrong
is
that
when
the
when
the
member,
when
the
person
on
mcr
activists
has
authenticated
their
membership,
so
they've
connected
the
gl
membership
to
their
msr
account
when
they
get
to
the
point
of
checkout
on
the
checkout
saying:
okay,
this
person,
who
has
glr
membership
34567,
is
trying
to
book
this
activity
type
when
that
when
the
checkout
speaks
the
legend
through
the
booking
appearances,
okay,
this
person,
this
activity.
What
do
we
charge
them?
C
B
Well,
and
so
you
sorry
even
more
sim,
the
request
is
part
of
the
booking.
Spec
is
literally
in
there.
The
request
is,
this
is
the
customer.
This
is
the
item.
What
is
the
price
and
that's
the
price
that
comes
back,
and
so
it's
not
even
a
question
of
prompting
the
question.
It's
not
even
a
question
of
asking
legends
specifically
for
something.
That's
literally
saying,
I'm
creating
a
basket.
These
are
the
items
in
it.
Sorry
tell
me
they're
telling
the
price
of
it.
B
So
sorry,
I'm
just
yes,
sorry,
I
wasn't
trying
to
contradict
yet
that's
right,
just
in
terms
of
it
being
very
straightforward,
it's
not
anything
that
the
booking
system
doesn't
already
do
so
we're
not
doing
it's,
not.
There's
no
clever
interrogation
of
the
pricing
structure
to
figure
out
anything.
It's
literally
saying
add
these
items
to
my
basket
and
the
membership
processing
in
the
system
will
produce
the
total
at
the
bottom.
E
If
that's
the
way
it
works
to
the
api,
then
that's
fine.
You
know
great,
I
didn't
realize
it
was
that
clever,
but
if
it's,
if
legend
is
going
to
be
able
to
tell
you
who's
entitled
to
the
price
of
an
activity,
but
it
includes
what
we
would
term
as
loyalty
voucher
discount
against
a
particular
activity
price.
B
Surprised
if
you
it
just
so
I
understand
if
in
I
mean
this
is
a
very
legend
specific
point,
but
if
you
add
stuff
to
a
basket
in
legend,
do
you
need
to
explicitly
tell
it
there's
a
voucher
in
use
or
as
a
user,
or
does
it
generally
get
added
automatically
yeah?
You
get
a
choice
to
say
whether
you
want
to
use
your
voucher.
E
Oh
right,
so
it's
it's!
It's
a
confirmation
at
the
point
of
checkout,
yes,
apply
my
voucher,
zero
price
zeros
down
to
zero.
Now,
listen!
We
I!
I
don't
anticipate!
That's
gonna
happen
a
lot
in
mcr
because
I
don't
think
we've
got
many
rackets,
racket,
members
or
whatever,
but
but
nevertheless
there
are,
there
will
be
occasionally
that
happens.
But
again
I
would
expect
those
members
to
come
via
legend.
You
know
our
online
booking
rather
than
so
active
because
it
kind
of
almost
said
what
what's
the
point
in
3m
so
active.
B
B
C
B
E
Oh
no,
I
know
I
understand
I
understand,
but
this
is
legend
but
but
I
think
for
the
the
the
few
exceptional
cases
where
that
may
occur
now.
I
think
I
think
we've
got
to
be
practical
here
about
what's
reasonable
for
us
to
be
able
to
develop
and
make
available,
and
I
think
I
think
anybody
who's
got
an
entitlement
voucher.
That
means
they
get
a
discount
at
the
checkout
or
it
zeros
the
cost
down.
B
B
And
in
the
future,
if
someone
wants
to
influence
such
thing,
you
could
automatically
apply
the
discount
and
that
would
that
would
still
work
within
the
api,
because
you
wouldn't
be
there's,
there's
no
mechanism
for
prompting.
Do
you
want
to
use
the
voucher,
but
of
course,
if
that
was
just
automatically
applied,
but
then
there's
no
way
of
it
telling
the
user
that
it's
done,
that
if
the
voucher
application
is
something
you
need
to
know.
E
About
so
yeah
we
also,
we
also
like
to
use
it
as
it's
a
little
bit
of
a
tool
as
well,
because
we
like
to
remind
customers
that
they've
got
a
voucher
and
they
can
use
one
court
per
day
and
therefore
you're
now
using
it
and
it's
it's
implied
use
rather
than
just
assumed
use.
You
know,
otherwise,
people
just
assume.
Well,
I've
got
one
automatically
I've
just
booked
today
and
it
comes
up
zero
cost.
E
B
E
A
B
Well,
yeah
I
mean
yeah,
or
even
not
I
mean,
if
we
even
need
to
I
mean
vouchers
is
very
seems
very
edge.
Casey,
I
don't
know
I
I
don't
think
I've
seen
any
other
systems
do
something
like
that.
Well,
discount
codes
we've
talked
about
before.
In
fairness,
I
don't
know.
Yes,
we
should
just
yeah
you're
right.
We
should
out
of
scope
discount
codes-
probably
that's
probably
the
thing
rather
than
vouchers,
because
if
that's
not
already
written
in
there
might
be.
A
B
Actually,
we
could
use
you,
you
can
use
additional
yeah,
you
could
you
could
you
could
use
additional
attendee
details
to
do
that.
You
could
add
a
question
to
additional
attendee
details
so
at
the
point
where
you're
at
see
c2,
because
this
is
the
way
that
participants
get
around
that
some
of
their
questions.
B
If
you,
if
you
have
any
questions,
you
need
to
ask
the
user,
you
can
ask
them
at
c1
where
you
know
who
the
person
is,
get
the
answers
at
c2
which
produces
the
correct
price
and
then
that's
the
output.
So
if
you
wanted
to
have
a
question,
do
you
want
to
use
your
discount
voucher?
Yes,
no,
you
can
add
a
boolean
value
to
the
additional
10d
capture,
using
your
intake
form.
Boolean
value.
Put
your
question
in
that's.
B
That's
free
text
put
a
required
value
of
true
to
get
that
back
and
then,
when,
depending
on
the
answer,
you
can
then
vary
the
price
and
then
price
is
calculated
in
c2
taken
forward
through
the
rest
of
the
process,
so
actually
mechanisms
there
you
could
use.
If
you
wanted
to
do
that
to
for
this
particular
voucher
case,
you
could
do
it
and
you
could
even
capture
a
discount
code
using
the
exact
same
mechanism.
A
A
A
E
E
A
Yeah
situations
in
which
opportunities
yeah,
as
it
says,
they're
only
available
to
members
point
blank
or
to
only
certain
kinds
of
members
and
again
that
has
just
been
declared
out
of
scope.
So
it
could
be-
and
I
don't
know
how
frequent
an
occurrence
this
would
be,
that
opportunities
that
that
say
in
mcr
active
person
without
a
gll
membership
was
not
eligible
for
could
be
displayed
to
them.
But
then
they
would
be
unable
to
actually
book
that
because
it's
just
not
available
to
them.
B
Yeah,
so,
okay
to
add
a
bit
more
to
that
again.
The
original
conversations,
I
think
I
think,
debbie
from
everyone
active,
actually
kind
of
had
quite
a
bit
of
input
onto
this.
There
was
this
question
of
well.
If
you
have
memberships
that
you
need
to
have
certain
memberships
to
book
certain
things,
so
should
we
put
a
sign
against
each
of
the
things
in
the
aggregator
that
says
this?
Climbing
wall
is
only
bookable
if
you
have
a
climbing
membership
or
whatever
and
there's
a
huge
complexity
about
what
memberships
get
you.
B
What
actually
that's,
not
quite
the
problem
that
this
is
trying
to
solve.
Here's
the
theory
from
the
proposal
and
the
main
question
is
at
a
really
basic
level.
Do
you
need
to
log
into
gll
to
book
the
thing
and
to
to
make
it
like
super
practical?
Do
you
need
to
have
gone
through
the
join
journey
of
gll
to
book
the
thing
and
therefore
have
a
membership
that
does
that
some
things
will
be
available
to
the
book
as
effectively
as
guest,
which
means
as
a
casual
booker
without
having
a
monthly
membership?
B
Those
people
don't
need
to
go
through
the
joint
journey.
Some
things
will
require
monthly
membership,
which
therefore
means
you
have
to
go
through
the
joint
journey
and
require
authentication.
So
rather
than
splitting
into,
I
need
a
membership
or
I
don't
need
a
membership,
because
memberships
themselves
are
so
complicated
and
named
differently
and
all
the
rest
of
it.
The
proposal
here
is
to
have
to
imagine
two
buttons
on
the
screen
against
the
booking,
so
you've
got
your
you've
got
your
booker.
B
You've
got
your
thing
that
you've
got
your
opportunity
and
then
two
buttons
are
book
now
or
log
in
to
gll
to
book
or
whatever.
You
know
that
type
of
thing,
and
if
you
log
into
jl
to
book
then
the
next
screen
that
comes
up
is
the
box
that
says
top
username
and
password
for
gll,
and
then
the
next
screen
gives
you
the
price,
as
you
would
have
it
within
legend,
so
you
haven't
pushed
them
through
the
crazy
journey
of
go
to
gll's
website,
all
the
stuff,
deep
linking
etc.
B
What
you've
done
is
just
kept
them
in
the
same
experience,
giving
them
the
correct
price,
but
you've
asked
them
to
log
in
because
they
need
two,
because
without
a
membership
they
wouldn't
be
able
to
book
the
thing
so
yeah.
We
basically
got
rid
of
the
id.
Well,
the
the
idea
of
membership.
Not
membership
is
still
in
beta,
so
you
could
still
do
that,
but
the
actual
mechanism
for
the
spec
for
booking
is
actually
not
that
it's
do.
I
need
to
authenticate
or
not,
and
just
just
leaving
it.
There
is
a
scope.
E
A
B
Yeah
and
also
a
point
that
yeah
debbie
brought
up
that
I've
mentioned
in
the
issue.
Is
that
how
on
earth
would
you
even
display
that
information?
You
know,
because
if
you,
you
think
some
of
these
things,
you've
got
15
different
membership
types
that
could
apply
to
that
particular
thing.
If
I
want
to
book
it
and
it
requires
membership.
So
if
I
want
to
book
my
climbing
wall,
I'm
I
can't
book
it
as
a
casual
booker.
B
I
need
either
a
climbing
membership
or
an
all-inclusive
membership
or
a
weekend-only
membership,
or
a
whatever
65-plus
membership
or
you've
got
like
15
membership
types.
And
how
are
you
displaying
that
in
a
in
a
useful
way,
so
that
I
think,
probably
just
in
case
anyone
watching
this
thinks
you
know?
Actually
I
really
need
that,
and
my
question
would
be
great.
B
There
is
what
you
actually
want,
the
information
to
be
so
that
you
can
display
it
to
the
user
so
that
you
can
create
that
experience,
because
I
think,
until
we
have
a
very
clear
user
journey,
for
what
exactly
we
do
with
the
member
information
and
what
that
looks
like
it
becomes
very
difficult
to
try
and
define
the
memberships
upfront
in
the
kind
of
search
experience.
If
you
like,
so
that
you've
got
that
in
the
results.
E
E
So
this
is
actually
going
to
be
a
real
live
user
case
soon.
Actually,
because
there
are
thousands
of
lessons
and
courses
opportunities
which
we
are
going
to
want
to
make
available,
but
the
precondition
is,
you
have
to
have
a
membership,
but
I
guess
the
question
is:
which
membership?
Is
it
any
membership
or
not?
Well,
it
could
be
one
of
several
depending
on
the
circumstances,
so.
B
E
Yes,
in
its
simplest
format,
yeah,
I
think
that
might
be
the
best
way
forward,
but
anyway
it's
it's
out
of
scope,
and
I
don't
disagree
with
that.
I'm
just
suggesting
that
that's
something
we
need
to
think
about
the
future,
because
that,
because
the
mcr
active
client
have
been
asking
for
it,
you
know
they.
They
want
the
lessons
and
courses
data
to
be
available
through
the
open
feed
and
it's
and
it's
slightly
out
of
scope
for
the
initial
project,
delivery
yeah.
But
it's
going
to
come
back
into
scope
pretty
soon.
B
Great
well,
so
I
guess
again
to
be
clear
to
future
us
when,
if
you
want
to
use
the
beta
field
to
include
to
indicate
membership
required,
you
can
still
do
that
and
then
that
would
then
flag
membership
required
to
book
this
thing
you
could
use
that
in
combination
with
login
required,
so
you
could
say
membership
required
and
then
then
you
could
have
a
little.
You
know
log
into
gl
button,
so
those
two
things
are
separate
functionally
and
the
only
thing
that
affects
the
booking
spec
is
the
login
required
bit.
B
A
And
then,
actually
sorry
we're
near
the
end
of
the
call,
but
the
the
final
point
on
there
identifying
relevant
offers
through
identifier
convention.
So
that's
sort
of
a
slight
workaround
where
the
idea
might
be,
and
one
proposal
that's
made
on
the
thread-
is
standardizing
some
kind
of
identifiers
to
indicate
certain
kinds
of
membership
and
certain
kinds
of
eligibility,
but
as
we've
just
discussed
that
becomes
incredibly
complicated,
particularly
if
we're
trying
to
coordinate
it
centrally
through
something
in
specification.
A
A
So
I
tend
to
circulate
well,
I
try
to
circulate
through
a
week
in
advance.
Usually
they
end
up
getting
circulated
two
days
in
advance,
so
I
send
them
around
then.
If
there's
something
that
you
want
to
discuss
more
generally
and
have
put
on
the
agenda
in
future,
I
would
say
the
w3c
mailing
list
is
the
best
place
to
voice
those.
B
The
mailing
list,
then
yeah
unless
anyone's
got
anything
else.
I
was
gonna
say
if
you
just
have
a
quick
look
at
the
customer
issue
there
just
at
the
bottom
in
the
in
the
issue.
Would
you
just
mind
flipping
to
github
and
going
to
the
bottom
of
that
I
just
want
to
check.
We've
got
all
of
those
covered,
so
if
you
go
yes,
there's
one
at
the
very
bottom
error
conditions.
A
B
You
know
because
you're
barred
or
banned
or
whatever
so
there'll
be
a
few
cases
like
this
and
so
probably
worthless,
just
enumerating
those
in
in
the
spec
or
at
least
a
mechanism
for
a
general
membership
authentication
error
with
it,
which
can
be
displayed
with
some
text
so
that
people
can
so
that
the
system
can
give
useful
information
to
the
user
about
what's
gone
wrong.
If
there's
a
fail
case.
A
E
B
Somebody's
defaulted!
No!
It's!
If
you're,
if
you,
if
you
go
through
the
booking
process
in
legend,
normally
as
booker
as
a
normal
customer
and
you
were,
you
were
not
allowed
to
continue
the
process
because
either
you've
been,
if
there's
a
fine
on
the
account
or
there's
a
problem,
it's
it's
being
able
to
just
tell
the
broker.
Sorry
tell
the
customer
to
give
the
broker
the
information
to
tell
the
customer
yeah.
Okay
so
like,
for
example,
you've
got
a
credit
or
you've
got
a
fine
on
your
account.
You
haven't
yet
paid.
B
Please
contact
the
center
to
pay.
It
could
be
the
sentence.
It
says
right,
yeah,
okay,
okay,
so
without
without
adding
that
in
for
context,
the
feature
all
you'd
have
is
an
error
has
occurred,
which
it's
like
well
doesn't
help
yeah.
Is
the
system
broken
yeah
yeah?
What
if
it's
just,
I
need
to
pay
them
2,
pound,
50
or
whatever
then
yeah,
okay,
okay,.
A
B
Thing
to
implement
yeah
yeah.
Definitely
I
I
agree
with
that
and
then
yeah,
that's
that's
it.
I
think.
Could
you
just
quickly
scroll
up
and
check?
We've
covered
all
the
headings
there.
Yes,
updates.
We've
done
discount
cards,
yes,
it's
tricky
because
I'm
not
doing
it
backwards
here,
but
communication
we've
talked
about
the
buttons
we've
talked
about
yet
and
membership
pricing.
B
We
talked
about
great,
so
it
sounds
like
from
the
people
in
the
corners
broad
agreement
across
all
of
this,
and
does
that
mean,
therefore,
that
we
are
good
to
well?
I
guess
this
is
my
question
now.
What
is
this
now?
Is
this
going
into
cr2
into
the
spec?
Is
that
is
that
what
we're
saying
are
we
comfortable
with
that
or
is
it
going
somewhere
else.