►
From YouTube: OAUTH WG Interim Meeting, 2021-04-26
Description
OAUTH WG Interim Meeting, 2021-04-26
A
Okay,
welcome
everyone
to
yet
one
more
meeting,
and
this
is
the
not
well
as
a
reminder.
This
applies
here
and
today
we
will
be
talking
about
a
tmi
bff
vittorio
entertaining
us
today.
A
B
B
In
short,
that's
a
mechanism
for
a
javascript
app
which
happens
to
have
a
back-end.
Not
all
of
them
have
one
for
delegating
to
that
back
end.
The
acquisition
and
management
of
access
tokens
and
but
retain
the
ability
to
make
calls
from
javascript
directly-
and
this
is
something
that
lots
of
people
already
do.
It's
just
an
attempt
to
give
some
guidance
so
that
some
of
the
most
obvious
security
issues
can
be
prevented
and
the
interoperability
can
be
achieved.
B
I
don't
have
a
lot
of
slides,
but
I
suspect
that
some
of
the
questions
will
be
answered
by
the
slides.
So
my
suggestion
is,
let
me
blubber
for
as
much
as
I
need
to
blubber
and
then
we
can
open
it
to
a
discussion
unless
there
is
something
like
a
burning
question,
then
by
all
means,
don't
burn
interrupt
me.
B
Okay,
so
we
presented
these
number
of
times.
We
already
discussed
these
on
the
on
the
mailing
list
and
there
was
one
point
that
was
hard
for
people
to
understand.
So
I'm
clarifying
it
upfront
in
literature.
When
you
talk
about
bff,
a
lot
of
people
will
interpret
it
as
the
backend
does
absolutely
everything
so
acquiring
tokens
and
acting
as
a
reverse
proxy
for
the
calls.
B
B
What
is
in
here
we
say:
okay,
you
have
a
bff
when
you
have
a
back
end,
because
again
it's
not
obvious
that
you
have
a
backup.
You
might
be
a
pure
single
page
up
that
just
orchestrates
call
to
apis
on
other
domains,
and
you
delegate
some
capability,
some
function
to
the
backend.
That's
the
sense
in
which
we
use
the
term
here,
and
this
spec
does
not
describe
a
full
bff.
B
So
here
we
are
gonna
talk
a
bit
about
like
why
we're
gonna
do
this
and
then
we're
going
to
examine
the
main
flow,
which
is
ultra
simple
and
then
we'll
discuss
so
reason.
One
whenever
you
can.
You
should
not
get
tokens
in
the
user
agent.
We
know
it's
a,
not
a
good
idea.
The
thing
is
that
you
only
you
are
not
always
in
a
position
of
being
able
to.
B
Let's
say
that
that
switch
topology,
which
you
have
every
user
agent,
that
performs
a
call
to
the
api
versus
all
the
calls
going
through
your
back
end
has
implications
like
is
security,
is
not
the
only
consideration
you
should
have
in
here
like
if
you
have
a
back
end,
which
basically
just
serves
you
a
page
and
then
it
gets
out
of
the
way.
B
So
there
are
a
number
of
considerations
that
go
beyond
sheer
security
that
can
make
people
use
a
different
approach
than
reverse
proxy
full
bff,
even
when
they
do
have
a
back
end.
And
here
those
are
just
a
couple
of
possible
reasons,
but
you
just
need
to
look
at
the
market.
People
do
that.
It's
just
the
way
in
which
people
solve
this
particular
topology.
B
The
other
side
is
okay.
We
have
code
plus
fixes,
so
why
bothering
about
this?
And
the
thing
is
cod
plus
pxe
is
very
nice.
I
think,
then
our
community
did
an
excellent
job
in
proposing
that
as
an
alternative
to
implicit
flow,
but
it
still
remains
pretty
complicated.
Let's
say
that
the
typical
experience
of
a
front-end
developer
is
not
exactly
to
understand
all
the
moving
parts
and
we
can
tone
down
the
surface
to
the
absolute
minimum.
B
Like
just
give
me,
the
client
id
you
already
direct
uri,
the
address
of
your
provider
like
just
those
free
strings,
but
people
still
manage
to
screw
it
up,
and
there
are
many
moving
parts
and
some
things
we
simply
cannot
hide
from
a
developer
like
if
you
are
doing
a
refresh
token
rotation
and
you
fail
to
get
back
a
token.
You
find
yourself
stranded
in
no
man's
land
and
no
amount
of
sdk
can
help
you
and
the
other
is
that
we
rely
on
capabilities
that
are
not
universally
available.
Now
I
won't
name
names
but
out
there.
B
There
are
extraordinarily
popular
and
adopted
sdks
that
use
codepluspixie
and
they
use
normal
refresh
tokens
without
any
rotation.
So
it's
great
and
if
you
don't
have
a
back
end,
it's
pretty
much
your
only
choice,
but
there
are
like
aspects
that
can
be
improved.
B
So
one
typical
way
that
we
see
like
one
natural
grassroot
approach
for
people
similar
to
people
are
using
eddy
tokens
for
calling
apis
like
natural
finds
a
way,
and
so
you
see
people
doing
classic
confidential
flow,
which
are
well
understood
that
are
on
the
back
and
side
so
less
problems,
and
they
just
really
nearly
take
the
access
token
and
make
it
available
for
their
front-end.
B
They
find
their
own
way
of
sharing
tokens
between
rebecca
and
the
front
end,
and
it's
not
entirely
trivial,
so
they
have
no,
they
don't
have
a
benefit
of
a
classic
thing
in
which,
when
we
tell
them
here
is
how
you
do
x.
That
thing
is
typically
polished
by
multiple
eyes
and
security
experts
that
give
advice
instead
of
they
just
invent
it
on
their
own.
There
is
no
threat
model
that
the
people
can
refer
to,
and
there
is
no
interrupt.
B
Let's
say
that
every
time
you
do
this
approach
and
you
are
not
following
any
syntax
any
particular
guidance
and
similar.
The
call
you
produced
cannot
be
just
reused
across
the
board,
so
if
every
time
I
build
a
new
app,
I
have
to
build
this
thing
again
or,
if
I
have,
if
I
want
to
mix
and
match
things
like
reactor
and
node
or
react
as
an
asp.net,
there
is
no
way
of
just
reusing
this
stuff.
B
So
what
we're
trying
to
do
here
is
to
provide
some
guidance
for
solving
this
particular
issue
in
which
we
describe
how
to
do
this
exactly
this
pattern,
but
with
a
bit
more
of
like
that,
we
can
establish
so
that
we
can
we'll
be
able
to
achieve
misaka,
say
a
mutant
so
that
we
can
achieve
some
interoperability,
and
we
can
also
enshrine
some
security
principles
so
that
people
are
not
completely
on
their
own
as
they
are
today,
and
so
we
do
this
by
adding
a
couple
of
endpoints
that
the
application
is
supposed
to
expose
specific
messages
and
security
considerations
and
also
a
way
of
getting
sasha
I'll
get
to
that
in
a
second.
B
B
If
here
you
want
to
have
a
debug
stuff,
if
here
you
want
to
give
back
api
keys
instead
of
tokens
for
users
for
us,
it
doesn't
matter.
Just
have
your
stuff
ready
on
the
back
end
and
the
main
flaw
here
is:
you
can
see
my
front
end
with
the
cookie.
You
can
see
the
back
end,
which
exposes
this
well
known,
endpoint
for
tokens,
and
we
do
our
request.
Our
request
will
carry
the
session
because
we
established
that,
and
it
will
just
ask
for
a
token,
with
the
scope
that
we
want.
B
We
have
optionally
a
resource
if
we
need
a
research
and
the
cookie
which
we
have
in
here
and
note
that
the
front
end
is
not
declaring
any
client
id
is
not
using
like
it's
not
using
any
configuration
like
the
code,
which
is
running
on
the
front
end
is
a
pure
boilerplate.
There
is
nothing
customized
for
this.
The
javascript
developer
can
just
bring
it
down
and
use
it
without
configuring.
Anything
apart
from
the
scopes
that
they
want,
of
course,
and
here
actually
sorry,
let
me
go
back
now.
The
backend
decides
the
backend
will
see.
B
The
session
will
see
whatever
they
have
if
they
have
an
access
token,
which
is
still
valid
and
cached
can
return
it.
If
they
don't
have
it
and
if
they
have
a
fresh
talker,
they
can
use
this
refresh
token.
The
front
end
knows
nothing
about
it.
The
backend
just
decides
whether
they
can
send
something
back
and
if
they
do,
they
send
it
back
with
a
bunch
of
extra
headers,
which
we
added
thanks
to
the
feedback
we
got
from
neil.
Thank
you,
neil,
very
useful,
and
here
you
go.
B
B
We
just
failed
with
a
specific
set
of
errors
that
we
defined,
but
there's
a
lot
of
discussion
about
whether
we
should
do
something
about
it
and
we
could
do
something
about
it.
But
given
it's
an
initial
proposal,
we
didn't
want
to
go
too
far
and
then,
of
course,
once
you
have
a
token,
you
can
call
the
api
and
note
that
here
we
don't
make
anything
prescriptive
about
the
front
end
if
the
front
end
wants
to
have
a
service
worker
that
does
all
these
up
to
them
exactly
completely
up
to
the
specific
implementation.
B
Now
one
problem
you
have
in
this
process
like
in
this
typical
approach,
is
the
cookie
which
contains.
Presumably
the
session
information
is
opaque
to
the
front
end,
but
the
front
end
very
often
needs
to
show
stuff
about
the
about
the
end
user
or
like
about
the
session.
So
we
add
a
session
endpoint
where,
in
the
same
way,
which
I
can
just
make
boilerplate
request,
and
here
this
then
backend
can
just
send
you
back
whatever
it
thinks.
Is
information
about
the
session.
B
So
here
the
back
end
like
the
classic
thing
that
we
probably
are
all
thinking
of,
because
we
are
identity.
People
is
an
id
token
or
the
counterpart
of
the
user
info.
But
in
fact
the
backend
can
give
its
point
of
view
about
what
attributes
are
important,
including,
for
example,
mix
and
matching
with
local
stuff.
So
here
it's
just
a
mechanism
for
formalizing
what
endpoint
to
hit
in
order
to
get
back
this
information
once
again
for
interoperability
purposes
and
similar.
B
Okay,
so
why
do
I
why
doing
this?
The
javascript
is
really
really
simple.
It's
like
absolutely
trivial.
There
is
no
configuration
like
a
lot
of
the
issues
that
we
have,
that
people
stumble
upon,
go
away,
adding
the
the
behaviors
that
I've
shown
in
that
flows
in
existing
middlewares,
like,
for
example,
stuff
that
already
support
openly
connect
sign-in.
It's
super
simple,
like
those
are
just
two
basic
endpoints
that
just
expose
things
that
they
are
already
done
by
that
middleware.
B
The
advantage
of
maintaining
tokens
on
this
on
the
user
agent
is
that
you
can
make
calls
directly
in
there.
So
if
you
have
a
very
chatty
scenarios
or
if
you
have
a
really
large
number
of
users
or
if
the
location
of
a
user
in
respective
api
is
important,
you
retain
that
capability
and
by
the
fact
that
we
are
using
all
this
flow
on
the
service
side,
and
we
don't
expose
the
refresh
token
to
the
front
end.
B
We
don't
need
to
use
the
same
advanced
measures
that
we
devised
for
code
plus
pxe,
and
so
you
can
just
connect
to
old
stuff
which
don't
have
these
advanced
stuff
like.
Ideally,
you
don't
even
need
cores
for
the
for
those
endpoints
and
you
can
still
provide
those
capabilities
and,
in
terms
of
interoperability,
visa
can
be
super
powerful
because,
again,
two
very
simple
endpoints
to
add
on
the
middleware,
so
any
middleware
on
any
backend
platform.
You
know
the
speed.net
java
and
similar
and
ultra
easy
javascript
code
for
consuming
those
endpoints.
B
So
react
angular
view
whatever
it's
it's
monday.
I'm
sure
there
is
a
new
platform
for
this
and
again,
like
imagine,
adding
this
code
to
a
brand
new
javascript
platform
versus
adding
code
plus
pixel.
It's
a
different
development
effort,
and
the
thing
here
is
that
it's
decoupled
from
the
specifics
of
the
how
you
authenticate
and
even
how
you
get
your
tokens.
So
you
can
use
it
with
pretty
much
anything
like
if
you're
already
signing
in
and
using
your
own
proprietary
approach
or,
if
you're
getting
tokens,
not
using
the
code
flow
on
the
server
side.
B
But
you
simply
want,
for
example,
to
send
back
code
that
you
got
from
the
client,
client
credential
flow
or,
like
any
other
flow
like
again
api
keys
or
test
scenarios
in
which
you
want
to
test
your
app
to
call
it
the
eyes.
But
you
don't
want
to
mock
the
authorization
server,
which
is
often
painful,
but
instead
with
this
mechanism,
you
just
mock
everything
very,
very
simply,
and
so
I
have
a
continuous
integration.
An
interactive
test,
like
all
sorts
of
development
practices,
become
very
easy.
B
For
the
ones
among
you
who
participated
in
the
discussion,
we
made
some
changes
on
the
new
draft.
In
particular,
we
added
the
security
measures
in
the
http
headers.
When
we
returned
the
access
token,
we
I'll
take
responsibility.
I
went
overboard
the
first
time
and
I
made
claims
that
perhaps
I
shouldn't
have
made
in
terms
of
security,
so
all
voice
has
been
yanked.
We
clarified
the
point
of
bff
versus
full
bff.
B
We
clarified
that
we'd
like
people
to
keep
using
full
bffs
whenever
the
yama
chance,
because
it's
more
secure
we
expanded
on
the
prerequisites
because
people
didn't
understand
at
first
and
we
clarify
the
relationship
with
browser
bcp,
which
is
we
are
not
aiming
at
substituting
anything.
We
are
just
adding
details
to
one
scenario
that
the
browser
bcp
hints
at,
but
doesn't
expand
almost
done
so
here.
I'm
gonna
take
a
very
strong
stance,
that's
for
the
purposes
of
stimulating
discussion.
So
I
know
this
is
pretty
pretty
far
far
out.
B
People
are
already
doing
this
today
and
they
are
doing
it
in
a
very
cottage
industry,
style
garden
variety.
So
we
have
really
two
possibilities.
One
is
we
look
at
this
and
we
say
oh
wow,
this
is
horrible.
Super
dangerous
people
should
never
do
this.
Then
we
articulate
it
in
a
way
that
people
understand
it
like
not
arcane,
but
actually
giving
scenarios
like
giving
concrete
examples
and
then
just
like
we
are
campaigning
against
rob.
We
can
start
campaigning
against
this
and
again
we
need
to
find
really
solid
reasons
here.
B
The
other
is
if,
instead,
we
find
that
this
thing
is
not
blasphemy,
but
there
is
a
like.
It
is
something
that
can
be
done
with
some
reasonable
expectation
of
security.
Then
I
think
that
today,
just
leaving
the
fermat
style,
this
margin
is
small
to
contain
the
wonderful
proof
that
I
found
for
this
theorem.
B
It's
like
leaving
it
as
an
exercise
to
the
reader
is
not
great,
because
again
people
will
do
bad
things
like
sending
tokens
with
bigger
scopes,
or
I
don't
know
a
number
of
things
which
we
would
find
unsavory
and,
of
course
there
is
also
interoperability
matter
and
then
finally,
like
my
main
open
issue,
is
whether
we
should
handle
the
token
acquisition
case.
But
I
think
that
the
discussion
about
this
point
is
more
foundational,
and
that
said,
I
am
done.
A
Okay,
thanks
victoria
one
second
here
I
just
posted
the
link.
So
please,
if
you
haven't
added
your
name,
please
add
your
name
to
the
list
and
let's
go
to
the
queue
here.
A
C
Hey
victoria
great
work,
I
love
the
idea
of
standardizing
this
approach,
a
couple
pieces
of
feedback.
I
did
a
quick
google
arm
bff,
which
of
course
is
best
friends
forever
is
the
top
link,
but
then
bff
for
development
does
hit.
You
know
the
design
pattern.
C
My
other
feedback
I
was
surprised
to
see
dot
well
known,
being
an
api
endpoint
as
opposed
to
a
discovery,
endpoint
and
wondering
if
that's
becoming
a
common
practice
of
using
it
as
an
api
endpoint.
Instead
of
for
discovery
and
then
another
thing
on
the
dot
well
known.
If
we
are
going
to
do
that,
do
we
want
to
add
more
of
a
hierarchy
that
it's
a
dot
well
known?
C
Slash,
oh
slash,
bff,
or
something
like
that
to
make
it
clear
that
it's
sort
of
part
of
the
whole
oauth
space,
if
we
start
to
add
other
apis,
be
easier
to
have
them
all
in
one
namespace
of
oauth,
as
opposed
to
everything,
effectively
being
a
big
flat.
Namespace
of
all
the
other
things
using
well
known.
B
Thank
you.
Those
are
all
very
those
are
all
very
good
points.
The
the
bff
has
been
something
that
we
we
suffered
for,
and
I
have
to
admit
that
brian
was
exactly
the
same
advice.
So
it's
entirely
my
fault,
and
now
it's
like
it's
as
aaron
noted
very
recently,
we
are
like,
if
you
search
for
tmi
bff,
which
are
both
a
very
common
acronym
outside
of
our
world.
B
We
gain
the
top
spot
on
google,
so
we
should
think
about
renaming,
but
it's
going
to
be
painful
because
we
are
in
such
a
good
place.
Only
well
don't
well
known
honestly.
I
I
have
no
preference
at
all
so
I'll
I'll
leave
on
brian
to
comment
because
he's
deeper
than
me
on
this.
D
D
It
just
seems
to
be
a
stylistic
thing
that
folks
don't
like-
and
I
I
kind
of
went
back
and
forth
on
exactly
that,
but
ultimately
it
seemed
kind
of
silly
to
have
a
discovery
document
for
two
endpoints
versus
just
having
two
individual
endpoints.
That
said,
it's
sort
of
it
was
like
I,
I
didn't
have
a
super
strong
feeling,
one
way
or
the
other
it's
just
sort
of
where
we
landed,
and
certainly
up
for
up
for
change
going
forward.
D
If,
if
we
adopt
this
as
far
as
name
spacing
it,
I
I'm
under
this
understanding
that
you
can't
that
you
not
allow
paths
in
the
well-known
registry,
but
I
may
very
well
be
wrong
on
that
some
sort
of
name
prefix,
I
I
suppose,
could
be
used
to
to
try
to
group
things
together.
C
D
C
Think
if
we
maybe
want
to
go
and
provide
a
rationale
section,
if
we're
doing
some
things
that
are
new,
I
do
worry
about
sort
of
this,
the
well-known
being
a
place
that
most
places
think
is
static
or
essentially
configuration
discovery,
information
and
not
an
api
endpoint
yeah.
I
do
too.
D
Do
you
are
you
aware
offhand,
whether
that's
an
actual
requirement
or
just
sort
of
common
expectation
and
convention?
I.
C
Did
a
quick
skim
through
the
well-known
rfcs
and
I
didn't
see
anything
that
said
that
it
said
that
how
it's
used
is
up
to
the
application,
but-
and
so
I
don't
see
it
being
forbidden.
I
just
think
that
many
people
are
viewing
that
that's
a
discovery
area
and
you're,
potentially
changing
how
somebody
has
set
up
their
infrastructure
that
suddenly
now
part
of
that
space
is
an
api.
C
D
Yeah
the
the
thing
is
that
really
like
this
is
this
method
is
about
an
app
itself,
not
an
existing
oauth
component.
So
I
I
think
it
really
would
deserve
its
own
space
or
or
distinct
treatment.
But
I
I
think
the
point
you
made
about
you
know
potentially
running
afoul
of
other
infrastructure
or
making
it
difficult
to
configure
based
on
other
content
and
things
people
are
expecting
in
that
location
is
a
very
salient
one
and
one
we
ought
to
consider
which
might
push
us
back
towards
just
just
a
simple
discovery
mechanism.
B
The
thing
about
the
discovery
is
that
it's,
of
course,
more
flexible,
but
in
my
concrete
experience,
a
lot
of
people
use
defaults
as
in
every
different
library
like
no
the
spl
net
and
similar
have
a
default
for
something.
So
I
can
direct
your
eyes
and
similar
and
then
all
the
guidance
ends
up
relying
on
those
defaults
and
the
intent
in
giving
like
an
I'm
not
married
on
the
syntax
like
well-known
or
anything
else
doesn't
matter.
B
But
I
really
like
the
simplicity
of
having
something
that
comes
out
of
the
box
so
that
you
remove
one
of
the
classic
error
points
that
people
stumbles
upon
and,
of
course,
a
are
like
a
if
there's
a
possibility
of
collision.
It's
a
problem.
We
thought
directive
just
by
adding
the
dot
well
known.
The
problem
with
the
collision
on
an
application
would
be
lower,
but,
like
any
system
would
work,
then
if
we
wanted
to
also
add
a
mechanism
for
overriding
the
defaults
fine.
D
I
I
think
the
the
potential
for
conflict
is
avoided
by
using
well-known,
because
there's
an
actual
registry
for
that
content,
so
you
have
to
you're
either
in
violation
of
it
or
you
have
to
register
your
stuff
to
avoid
any
sort
of
collision.
D
D
So
we
we
sort
of
we
sort
of
need
to
do
something
either
say
you
know
it's
out
of
band
and
shared
which
is
awful
or
publish
the
information
somehow
and
well
known
such
that
it's
either
the
applications
themselves
or
a
pointer
to
them,
and
I,
I
think
next
point
about
using
well-known
other
things
using
well-known,
wasn't
about
collision
so
much
as
just
the
infrastructure
that
likely
sits
behind
it
is
you
might
have
your
whole
website
running
on
the
same
domain
as
this
app
and
have
to
have
other
information
and
well-known.
D
Any
kind
of
well-known
crap
that
might
apply
to
your
your
whole
domain
and
then
suddenly
needing
to
be
able
to
also
have
content
in
that
path.
Respond
to
api
requests
and
generate
dynamic
content
might
might
very
well
make
routing
and
deployment
of
that
stuff
really
difficult
where
it
would
otherwise
be
serving
a
static
directory
of
files
from
that
particular
directory.
D
C
Well
and
then
the
library
can,
you
know
fetch
that
it
knows
where
the
discovery
is
fetches
it,
and
then
that
gives
deployments
a
lot
more
flexibility
on
where
the
end
points
actually
are
exactly
yeah.
I
mean
it
amps
on
doing
some
of
the
supporting
some
of
the
things
in
dot.
Well
known
was
super
hard
to
make
happen
because
you
know
you're
trying
to
go
and
get
a
new
directory.
You
know
a
domain,
that's
controlled
by
a
completely
different
group,
and
you
know
you
know
they
get
very
cranky
around
things
like
that.
B
Yeah,
ultimately,
if
the
default
is
the
discovery,
as
opposed
to
the
actual
endpoints
from
a
point
of
view
of
the
front-end
developer,
it
remains
a
no-touch
thing
like
they
don't
need
to
do
anything
is
where
the
library
itself,
but
upon
waking
up,
find
stuff
up
so
yeah
fine
with
that
as
well.
C
Yeah
yeah
and
I
think
that's
a
great
approach
you
guys
have
as
opposed
to
it
being
yet
another
out
of
band
configuration
that
it
it'll
just
work
and
that
discovery
point
is
going
to
it's
just
going
to
be
called
once
and
then
the
back
end.
The
library
is
going
to
have
it.
E
Yeah
hi
aaron
here
that
was
enjoyable
watching
that
discussion
play
out,
mirroring
my
exact
train
of
thoughts,
so
not
being
able
to
speak
since
I
wasn't
yet
called
on.
I'm
happy
that
resolved
itself.
The
way
I
was
going
to
suggest.
E
I
completely
agree
with
dick
that
that
dot
well
known
while
it's
not
technically
required
that
it
is
static,
is
very
often
deployed
in
a
static
way,
and
on
top
of
that
another
example
of
a
t
of
a
place
where
that
would
not
work
would
be
if
an
application
is
running
at
a
subdirectory
where
the
team
that
manages
the
app
only
controls
what's
in
that
subdirectory
and
doesn't
actually
control
the
root
of
the
domain,
because
the
root
of
the
domain
would
be
managed
by
a
totally
different
team
at
the
company,
and
it
would
be
significantly
difficult
to
route
a
particular
path
of
under.well
known
over
to
that
app.
E
So
it's
a
much
easier
ask
of
the
of
the
application
team
to
say
to
the
web
team.
Hey!
Please,
host
this
one
value
at
this
url,
rather
than
do
fancy
tricks
with
routing
through
proxies
so
yeah.
The
conclusion
you
came
up
with
of
metadata
at
the
dot
well
known,
which
allows
flexible
routing
of
the
actual
api
endpoint
solves
all
of
that
all
those
concerns.
E
I
do
have
a
couple
other
things
I
wanted
to
ask
as
well,
though.
First
of
all
your
mention
about
pixie,
I
wanted
to
give
you
a
shortcut
for
just
the
justification
that
you
described,
which
is
pixie,
never
intends
to
claim
that
it
protects
tokens
at
rest.
It
protects
the
delivery
of
tokens
to
the
application,
and
that
alone
is
enough
justification
that
pixie
does
not
solve
what
you're
trying
to
do
here
at
all.
E
So
I
don't
even
think
you
need
to
get
into
the
the
details
of
the
fact
that
pixie
is
quote,
unquote,
complicated
or
has
more
moving
parts.
It
just
doesn't
claim
to
solve
the
story
soaring
tokens
at
rest,
so
it's
not
not
even
a
thing
that
would
be
considered
as
a
alternative
to
this
pattern,
but
two
questions
one:
the
session
info
endpoint.
E
E
I
just
questioned:
why
bother
you
even
specifying
it
at
that
point?
It
seems
like
apps
can
just
do
that
on
their
own.
B
Then
so
that's
a
good
point.
Let's
say
that
if
you
were
to
go
farther
than
what
we
are
aiming
at
here,
which
is
calling
apis
but
you'd
say,
for
example,
I
want
the
javascript
on
the
front
end
to
already
have
ui
elements
which
represents
users
and
similar,
and
so
I
want
to
know
the
attributes
in
advance.
So
I
can
interrupt
with
this
thing.
Then
yeah
you
would
having
a
fixed
schema
would
would
help.
But,
as
we
were
thinking
about
this,
we
thought
that
these
would
not
necessarily
be
okay.
It
might
be
too
restrictive.
B
Let's
say
that
here
you
can
literally
have
any
website
like
here.
Let
me
make
an
example
from
the
past.
Have
you
ever
heard
about
clout
which
is
now
dead.
E
B
Yeah,
okay,
so
it
clouded
like
if
it's
on
signing,
which
was
like
entirely
proprietary,
and
then
it
had
all
these
other
apps
that
it
was
calling
through
off
just
for
integrating
all
the
various
social
scores
and
similar.
So
it
was
a
classic
I
signed
in
using
whatever
I
want,
and
then
I
just
happened
to
do
off
on
top
of
it
and
off
not
openly
connect.
So
if
we
were
to
give
these
to
cloud
and
if
we
were
to
constrain
them
into
a
schema,
then
they
would
they
would
have
a
problem.
B
Let's
say
that
the
things
that
are
in
the
schema-
they
don't
have
it,
but
they
might
have
something
completely
different
like,
for
example,
their
scores
and
stuff
like
that.
So
we
felt
that
leaving
to
the
developer,
what
is
a
user
for
them
was
a
part
of
the
power
of
his
approach,
in
which
I
can
again
you
can
mix
and
match
what
you
have
locally
versus
what
you
got
from
identity
provider.
If
you
have
an
any
provider
you
might
sign
in
using
local
database
as
it
was
the
case
for
cloud.
B
So
I
do
see
the
value,
and
maybe
we
can
have
something
like
in
this
in
the
notes
or
somewhere
saying
hey.
If
you
happen
to
use
open
id
here,
there
is
a
way
in
which
you
might
do
this,
which
basically
is
a
send
back
the
content
of
user
info
or
id
token
with
attributes.
But
I
think
that
if
you
would
force
everyone
to
follow
a
schema,
then
we
would
be
too
restrictive,
like
we
would
limit
the
range
of
places
where
this
approach
can
be
useful.
E
Yeah,
that
makes
some
sense.
I
think
that
maybe
maybe
your
suggestion
of,
if
you
are
using
openid
connect,
then
you
should
do
it.
This
way
is
a
good
balance
between
that,
because
it
seems
like
if
people
already
are
coming
at
this
with
a
common
schema
or
at
least
a
minimum
set
of
properties,
which
is
what
90
token
is,
then
that
would
be
a
good
idea
to
just
have
more
interop
at
that
layer
and
yeah.
B
B
This
endpoint
becomes
useful
also
besides
basic
iterations,
when
you
are
actually
having
a
scenario
where
you
are
not
calling
apis
outside
of
your
domain,
but
you
are
only
calling
apis
on
your
back
end
is
this
is
the
classic
scenario
in
which
in
the
bcp
we
tell
people
don't
use
or
because
there's
no
access,
token
involved.
You
only
use
cookies,
but
one
big
problem
that
we
have
at
rank
like
when,
when
my
customers
do,
that
is
like
okay,
but
normally
when
I
actually
do
use
all
the
plastics
that
are
implicit
or
similar.
B
I
have
user
information
in
the
javascript,
whereas,
if
I'm
just
using
cookies,
I
don't
formalizing.
This
particular
endpoint
is
a
way
of
giving
to
them
what
they
need.
Also
in
that
particular
scenario
in
which,
if
you
are
only
using
cookies-
and
you
need
to
extract
info
from
the
back
end,
you
can
do
it
in
a
way
which
is
standardized
and
without
the
discovery
of
the
endpoint,
all
the
things
that
we
said
earlier.
So
it's
one
additional
value
of
having
a
session
in
for
endpoint.
E
Okay,
that
makes
sense.
I
have
one
last
question:
you
mentioned,
that
one
of
the
benefits
of
having
this
document
is
to
have
a
consistent
or
have
a
have
a
sort
of
shared
knowledge
around
the
security
of
this
type
of
deployment.
E
So,
along
those
lines,
do
you
have
a
list
in
here
of
explicitly
things
developers
should
not
do
that
this
instead
is
recommending.
You
know
an
alternative
to
since
you
were
worried
about.
Oh,
if
we
don't
have
this
document,
people
are
going
to
do
x,
y
and
z,
things
that
are
terrible,
so
are
those
things
spelled
out
anywhere.
B
Some
of
them
are
obvious
for
us,
but
less
obvious,
for
others
like
the
up
scoping,
for
example,
as
in
your
backend,
they
should
not
return
the
tokens
that
have
more
scopes
than
the
ones
that
they
were
asked
for,
which
might
not
be
something
that
people
would
naturally
do,
but
mostly
things
like
the
bunch
of
headers
that
is
here
which
were
added
after
we
got
feedback
from
the
list,
as
in
like
you
needed
to
put
this
stuff
in
there,
so
that
you
cover
yourself
from
a
cross
cross,
a
request,
forgery
and
similar,
which
I
would
personally
not
have
added
until
neil
brought
this
up.
B
So
this
is
an
example
of
things
that
can
actually
help
people
be
more
secure
than
by
when
they
develop
on
their
own
brian.
You
don't
have
to
do
a
queue
you
can
interact
with
at
any
time.
D
I'm
not
sure
what
the
protocol
is
here,
pun
intended.
I
I
wanted
to
just
jump
in
quickly
on
aaron's
point
about
the
session
info
that
I
I
think
you
you
both
have
really
valid
points
about
the
benefit
of
sort
of
tightening
up.
What's
there
versus
the
benefit
of
keeping
it
completely
open,
I'm
not
sure
I
necessarily
want
to
dismiss
either
yet
at
least
stay
open
to
the
possibility
of
maybe
a
middle
ground,
where
potentially,
we
identify
a
very
small
subset
of
claims
that
would
be
highly
recommended
or
required.
D
Such
that
the
front
end
could
could
reasonably
count
on
them
being
there
in
all
cases,
without
any
kind
of
customization
or
configuration
so
as
to
fill
facilitate
things
like.
You
know,
log
out
button
where
there's
a
you
are
now
logged
in
as
and
maybe
that's
a
display
name
or
a
username,
or
something
that
that
an
app
could
always
count
on
coming
back
from
the
the
session
info
to
fill
out
those
kinds
of
basic
ui
components
without
any
kind
of
configuration
and
without
any
sort
of
concern
for
what
the
actual
backing
mechanism
is
like.
B
So
here
is
the
middle
ground
proposal,
instead
of
just
having
a
super
basic
bff
session
in
forget
what
if
we
have
a
strict
get
and
lose
get
in
the
street,
you
get
the
schema
that
you
just
described
in
the
loser
you
get
whatever
the
developer
wants
the
back-end
developer
wants
and
then
at
that
point,
if
you
have
one
of
those
components,
you
just
go
through
the
strict
one
and
you
have
all
the
guarantees
you
want.
But
if
people
don't
want
to
support
it,
they
don't
support.
It
are.
E
You
concerned
about:
are
you
concerned
about
conflicts
in
the
property
names
if
we
were
to
combine
the
two,
because
I
think.
E
You
know
you
have
a
you,
have
a
minimum
set
that
the
app
can
rely
on
like
display
name
is
a
good
example
where
that's
not
an
open
connect
claim,
but.
B
Yeah
the
thing
I'm
thinking
is
that,
like
twofold
one
is,
I
had
so
many
problems
just
to
map
the
the
values
providers,
like,
I
remember,
sp.net
developers
which
were
moving
from
ldfs
to
azure
id
to
identity
server
and
they
had
like
the
same
concepts
with
slightly
different
names
or
sometimes
one
was
there.
Some
other
wasn't
there
so
finding
that
core
that
works
with
everyone,
I
think,
is
gonna,
be
challenging
on
one
side.
B
On
the
other,
I'm
worried
about
the
deadness
of
the
words
which
are
concerned
about
privacy
and
so
say
that
one
particular
backend
decides
that
the
only
thing
you
get
is
in
a
unique
identifier
which
you
can
use
for.
I
don't
know
your
favorite
color,
which
you
have
in
local
storage,
but
so
again
I
see
the
value
of
having
that
schema.
B
I'm
not
confident
that
we
can
get
it
with
schema,
which
is
truly
universal
and
doesn't
burden
people
into
doing
things
that
are
unnatural
for
rob,
which
is
why
to
me
supporting
both
would
be
a
good
way
out
without
like
getting
the
advantages
of
both
without
taking
a
hit.
A
F
Here
thousand
yes.com
couple
of
questions,
so,
first
of
all,
I
I
would
like
to
understand
what
what
attacks
the
proposed
service
would
prevent
and
which
it
does
not.
As
far
as
I
understand
leave,
or
you.
F
The
refresh
token
is
no
longer
stored
in
and
then
the
browser
is
instead
kept
bind
to
a
cookie
in
the
in
the
back
end.
So
you
you
keep
the
refresh
token
out
of
the
browser,
but
the
access
token
is
still
accessible
in
the
browser,
which
means
all
kinds
of
attacks
around
excess,
token
leakage,
replay
and
so
on
are
still
not
covered.
Is
that
a
fair
assessment
or
please
please,
comment
on
that.
B
It
is
a
fair
assessment.
Let's
say
that
now
the
access
token
is
one
of
the
things
that
you
can
access
when
you
can
use
the
session.
So
arguably
here
you
can
extract
the
access
token.
If
you
manage
to
attack
the
system.
If
you
were
to
do
in
a
system
in
which
you
don't
make
the
access
token
available
to
the
front
end,
but
you
are
a
facading
all
the
costs
of
apis.
B
You
could
technically
use
the
same
attack
to
call
the
apis
directly,
so
you
don't
need
to
have
the
access
token
to
make
that
call.
So
this
thing
does
cannot
prevent
on
its
own
the
cross
side
like
a
v
all
the
attacks
that
normally
leverage
your
cookie,
but
it
relies
on
the
same,
attracts
that
you
would
do
in
visa
in
this
situation,
so
it
doesn't
prevent
those
attacks
in
itself.
You
need
to
have
whatever
measures
you
are
normally
using
for
mitigating
those
attacks
in
place.
F
Yeah
I
mean
you
could
extract
the
access
token
replace
some
someplace
else.
That's
that's,
I
think,
is
the
difference.
Okay,
second
question:
how
do
you
detect
and
handle
revoked
access
tokens?
F
F
B
Let's
say
that
it's
the
back
end
that
is
responsible
for
making
those
tracks,
although,
like
imagine
that
this
is
all
done
by
a
weber
anyway,
imagine
that
the
calls
are
happening
from
the
web
app
all
the
same
scenario
apply
if
we
just
happen
to
be
making
visa
available
for
a
different
com
mode
of
code.
So
imagine
that
the
front
end
is
like
the
component
that
normally
you'd
be
using
for
making
api
calls
in
your
back
end.
This
just
happened
to
be
executing
elsewhere.
B
So
all
the
considerations
apply
for
the
confidential
clients
that
you
would
apply
normally
here.
F
Sorry,
I
understand,
I
mean
the
front
uses
an
access
token
and
receives
a
four
or
three,
for
example,
or
for
one
from
the
from
the
api
that
the
access
token
is
no
longer
valid.
Does
it
have
some
way
to
communicate
it
to
the
back
end,
because
the
back
end
does
not
call
and
a
resource.
So
how?
How
is
the
background
as
supposed
to
determine
that
an
access
token
is
no
longer
valid.
B
Right
yeah,
no,
we
don't.
We
don't
address
that
particular
scenario.
Right
now
like
there
is
nothing
that
we
do
from
then
from
the
front
end
to
signal
to
the
to
the
back
end.
Please
give
me
and
like
this
one
is
not
good.
Give
me
another
access
token
or
here
there
is
the
challenge
that
I
got
from
the
api.
Do
something
about
it.
We
don't
have
anything.
F
Okay,
then
I
I
think
that's
it.
It
makes
a
lot
of
sense
to
to
spend
some
time
to
think
about
that,
because
otherwise,
I
think
the
front
end
is
running
in
a
loop.
I
mean
if
it's
got
the
401,
it
will
most
likely
request
a
new
access
token
from
the
back
end,
but
if
the
back
end
just
provides
the
same
access
token
again,
then
it's
looping.
So
I
think
that
that's
that's
worth
a
consideration.
B
That's
an
excellent
point.
Let
me
ask
you
in
a
follow-up
question:
would
you
want
to
do
the
api
returned
and
send
it
back
to
the
end,
or
would
you
rather
have
a
flag
of
some
kind
so
that
when
the
front
end
asks
for
the
token
it
can
say
and
give
me
a
fresh
one
as
opposed
to
refresh
one?
That's.
F
An
excellent
question
we
told
you
I
tend
towards
providing
the
back
end
with
with
the
response
from
the
resource
server,
but
that's
just
intuition.
I
think
we
should
discuss
that
on
the
list.
What's
the
best.
B
F
Basically,
the
simplest,
the
simplest
solution
would
to
would
have
another
parameter,
a
fresh
access
token,
something
like
that
right
or
reset
access
token,
but
that
yeah,
that
would
be
the
simple
solution
and
but
the
more
sophisticated
would
would
allow
the
back
end
to
to
apply
some
logic
on
the
response.
So
yeah.
C
G
Thank
you,
phillips,
coconut,
zero
I'll.
Try
to
make
this
really
quick,
because
I
don't
want
to
beat
a
dead
horse
on
well
known,
but
adding
to
to
aaron's
point.
It
sometimes
is
not
possible
in
certain
you
know,
multi-tenant
environments
to
control
what
is
written
by
well-known
at
all.
So
in
that
case,
would
you
consider
a
fallback
where,
when
well-known
is
not
available,
the
location
for
those
endpoints
is
returned
in
the
main
body
of
the
html,
such
as
in
a
head
tag
in
a
head
meta
tech?
G
Sometimes
you
know
something
which
is
used
commonly
to
to
tell
javascript
hey.
Here
is
a
csrf
token.
For
instance,
we
could
put
the
location
of
of
those
endpoints
into
metatech.
G
E
G
G
That's
right,
that's
right
and
I
considered
all
the
possibilities
of
you
know
somebody
maliciously
writing
the
head
tag,
but
at
the
same
time
I
could
just
you
know
through
javascript
overwrite
the
xhr
prototype
and
make
an
interceptor
for
well-known
as
well.
So
I
don't
think
there
is,
you
know,
benefits
to
one
or
the
other,
but
for
scenarios
where
I
can't
control
well-known
fallback
would
be
great.
A
G
C
B
To
me,
any
mechanism
works,
the
main
constraints
are
which
should
be
easy
to
package
into
sdks.
If
we
were
to
say
place,
these
meta
tags
in
a
page
we'd
have
to
say
specifically
what
is
the
page
and
similar
or
if
we
can
inject
it
from
the
sdk,
even
better.
B
I'm
not
familiar
with
this
particular
method,
so
we
can
discuss
it
in
the
list
as
long
as
the
package
ability
remains
and
as
long
as
there
is
no
ambiguity
so
that
we
don't
risk
that
one
implementer
choose
one
way
and
of
one
back
end
and
if
another
implementer
of
a
front-end
sdk
choose
a
different
way
and
then
they
don't
talk
to
each
other.
Then,
as
long
as
we
can
prevent
that
scenario,
I'm
happy
with
any
mechanism.
I
have
no
opinion
taken
to
the
list.
Then.
A
Okay,
I
think
we're
almost
done
here
so
great
discussions
and
we
see
a
lot
of
interest
in
this
document,
so
I
I
want
to
get
the
feeling
here
of
of
this
of
the
people
here.