►
From YouTube: IETF113-OAUTH-20220324-1330
Description
OAUTH meeting session at IETF113
2022/03/24 1330
https://datatracker.ietf.org/meeting/113/proceedings/
A
Okay,
welcome
everyone
let's
get
going,
so
this
is
a
second
official
session
for
oauth
web
group.
Let's
get
going.
The
no
well
obviously
applies
here,
hopefully
you're
familiar
with
this
already,
hopefully
you're
already
familiar
with
those
tips
too.
So
I'm
gonna
skip
those
let's
see
with
these
are
the
sessions
that
we've
talked
about.
A
This
is
the
update,
the
monday
agenda
and
the
thursday
agenda.
So
we
have
a
number
of
topics
that
peter,
with
the
help
of
philip
and
daniel.
Maybe
we'll
talk
about
device
code
flow
vittorio
with
the
brian
in
supporting
mode,
we'll
talk
about
step
up,
authentication,
hey
daniel,
then
they
will
talk
about
libraries
and
daniel
will
finish
with
the
pixie
security
bcp.
This
is
a
discussion
that
we
had
yesterday
in
a
side
meeting.
B
Okay,
everybody
can
hear
me
all
right.
I'm
gonna
take
the
the
microphone
so,
first
of
all,
maybe
while
everything
gets
ready,
my
name
is
pedro
castleman.
I
am
really
delighted
to
be
here.
This
is
my
first
ietf,
so
it's
sort
of
a
really
momentous
moment
for
me.
B
I
actually
want
to
thank
everybody
in
this
room
and
in
this
working
group
for
the
welcome
that
you've
extended
and
how
how
how
welcome
you've
made
me
to
feel
over
the
last
couple
of
days,
thanks
for
entertaining
my
many
questions,
and
I
really
appreciate
it
and
that
and
I've
so
enjoyed
it
so
much
just
working
and
collaborating
with
all
of
you
so
far.
B
Okay
next
slide,
please
so
maybe
to
start
with,
so
I'm
going
to
talk
about
device
code
flow
and
some
of
the
exploits
that
we've
seen
that
uses
social
engineering
techniques
that
allows
adversaries
to
really
abuse
the
protocol
and
gain
access
to
resources
when
they
really
shouldn't
and
on
the
one
hand,
right
it's
very
easy
to
look
at
social
engineering
attacks
and
to
say:
well,
that's
just
social
engineering.
What
can
we
do
about
it,
but
I
actually
want
to
challenge
us
a
little
bit.
I
read
this
quote
recently.
B
There
may
be
more
that
we
can
do,
and
so
what
I
want
to
ask
folks,
as
we
talk
about
this
today,
is
maybe
just
stretch
a
little
bit
beyond
what,
where
we
may
have
traditionally
thought
about,
where
the
boundaries
might
be
and
how
we
can
go
a
little
bit
further.
Perhaps
next
next
slide
thanks
for
watching
so
we'll
talk
about
I'm
going
to
just
briefly
talk
about
device.
B
Grant
some
people
may
not
be
familiar
with
it.
I'll
talk
about
the
exploit
patterns
that
we've
seen
and
we'll
we'll
talk
about
that,
and
also
just
look
at
it.
It's
not
like
the
that
rfc
8682
doesn't
have
any
security
considerations.
It's
not
like
it
wasn't
for
seen,
but
maybe
we
can
do
a
little
bit
more
and
give
more
guidance
on
this
topic
and
then
what
I'd
love
to
do
is
maybe
talk
a
little
bit
about
what
we
could
do
and
what
we
should
do.
B
Also,
while
we've
been
here,
philip
has
also
offered
he's,
come
up
with
some
some
additional
ideas.
Around
social
engineering
attacks
related
to
device
code
flow,
so
he'll
share
some
of
those
insights
and
daniel
has
a
demo
in
case
folks
thinks
this
is
not
real.
He'll
show
a
little
bit
about
how
this
this
actually
works.
So
next
slide.
Please.
B
Now
right
so
next
slide,
so
what
is
device
authorization
ground?
So
it's
really
a
protocol
that
allows
device
devices
that
lack
a
browser
or
input
constraint
right
where
it's
difficult
to
input
text
to
be
part
of
the
oauth
ecosystem
and
to
participate
in
the
and
obtain
access,
tokens
and
refresh
tokens
next
slide
and
they're
really
for
devices
like
this
right.
This
picture
is
something
they're
for
smart
tvs
or
that
was
the
original
intent
for
smart
tvs,
picture
frames,
printers
right
devices
like
that,
and
so
next
slide
please.
B
B
You
know
you
get
your
display
user
code,
you
also
get
a
device
code.
You
get
the
verification
uri
the
next
slide,
please
the
the
user
on
their
authorization
device
scan
or
enter
the
code
next
slide.
B
They
then
authenticate
and
authorize
right,
and
that
can
be
a
multi-factor
authentication,
which
is
great.
So
you
can
have
really
strong
authentication
on
this
flow
next
slide
and
then
the
the
consumption
device
ends
up
retrieving
the
tokens,
the
access
token
and
the
the
refresh
token
next
slide.
B
So
really
in
a
nutshell,
right,
you
have
this
flow
where
you
start
a
session
on
one
device,
and
then
you
authorize
on
the
second
device
and
the
next
slide
and
the
benefits.
So
you
can
do
authorization
for
devices
with
limited
input
capabilities.
It's
really
handy.
It's
really
easy
in
some
ways,
and
you
can
also
do
this
with
strong
authentication
using
a
personally
trusted
device
next
slide.
B
B
There
is
no
protocol
between
the
you
between
the
users,
authorization
device
and
the
consumption
device
and
there's
no
way
to
establish
that
trust
relationship,
and
so
and
it's
not
a
back
and
forth
it's
a
one
way
right
and
really
our
defense
here
is.
We
are
relying
on
the
user
to
make
an
informed
decision
and
that
doesn't
always
work
right.
We
as
individuals,
people
in
this
room
of
course,
do
not
have
this
problem.
B
We
are
very
good
at
spotting
these
these
attacks,
but
not
really
or
or
maybe
not,
but
but
but
there
are
great
many
people
out
there
where
this
this
little
this
gap
is
being
exploited,
and
so
next
slide
please.
B
B
So
now
we
have
our
I'm
not
sure
if
that
is
a
that's
our
adversary
and
they
get
control
of
a
device,
let's
call
it
the
attacker
control
device
and
they
can
access
and
they
can
get
a
code.
These
are
an
attack
pattern
that
we've
seen
in
in
the
wild.
It's
been
documented.
I
shared
some
of
the
attacks
that
that's
in
the
public
domain.
B
So
it's
a
it's
a
real
thing
that
happens
so
the
attacker
ends
up.
They
get
a
code
and
the
next
next
slide
next
one's
one
more
and
what
they
then
do.
Is
they
end
up
step
number
two?
They
change
the
context
and
they
do
this
in
very
clever
ways.
Right
they
may
obtain
a
device
and
then
they
may
send
you
an
email
or
a
text
message
and
the
text
message
will
say
something
like
hey.
If
you
want
to
continue
watching
netflix,
please
enter
you
need
to
re-authenticate
right
and
of
course,
these
things
happen.
B
Occasionally,
so
people
do
it.
Some
of
them
are
even
more
devious
right.
They
they'd
say
something
like
hey.
You
can
get
six
months
free
of
netflix.
If
you
go
and
enter
your
promo
code
right,
they
don't
even
call
it
a
user
code
sneaky
very
sneaky
right.
So
there's
all
sorts
of
ways
in
which
the
user
can
be
tricked
into
entering
these
things
and
they
scan
and
to
enter
the
code.
I
have
a
bus
stop
up
there
and
it's
not
a
the.
There
has
even
been
attacks.
B
I
think
in
new
york
city
that
sort
of
follows
the
same
pattern
with
bikes,
rental
bikes,
where
somebody
took
a
qr
code
on
a
bike
copied
it
put
it
on
another
bike.
When
the
customer
came
along
scanned
it
it
didn't
unlock
the
bike,
but
it
unlocked
the
original
bike
for
which
the
qr
code
was
printed
and
the
thief
made
off
with
the
bat
with
the
with
the
bicycle
daniel.
B
Actually,
when
we
talked
about
this
share
this
this
attack
with
me
and
it
sort
of
just
emphasized
how
how
tricky
it
is
when
when
there
is
no
authentication
or
no
trust
relationship
right,
when
you
have
this
this
gap,
when
you're
transferring
a
session,
so
now
the
user
scans,
the
the
code
next
slide,
please
and
they
end
up.
They
authenticate,
they'll,
authorize
and,
and
and
the
sort
of
the
tragedy
of
this
is,
if
even
if
you
had
multi-factor
authentication
deployed,
the
user
would
still
complete
the
authentication
right.
B
B
They
end
up
retrieving
the
tokens,
the
attack
retrieves,
the
tokens,
and
now
they
have
an
access
token
and
a
refresh
token,
and
depending
on
what's
in
the
access
and
refresh
token,
they
may
have
access
for
a
very
long
time,
maybe
to
something
as
simple
as
a
consumer
service
or
a
bicycle,
but
it
may
you
know
that
extends
to
other
services
that
uses
the
protocol
as
well
and
next
slide.
Please
rafat!
B
You
know
some
of
the
work
we're
doing
with
things
like
psyop
and
openid.
Connect
may
also
be
subject
to
this.
In
fact,
whenever
you're
scanning
a
qr
code,
this
is
something
to
to
think
about
next
slide.
Please-
and
here
are
some
examples.
I
thought
I'd
just
to
sort
of
give
people
a
flavor
right.
Would
you
say
yes
to
any
of
these
things
right,
hey
here's!
The
document
just
enter
your
access
code
or
you
know,
hey
you're
about
to
be
logged
out.
B
Do
you
just
want
to
just
make
sure
that
you
keep
having
service
right
or
hey
your
security
department
or
your
company
has
made
a
change
and
you
need
to
take
action.
Otherwise,
you
won't
be
able
to
do
your
job
and
these
techniques
are
you
know,
and
then
there's
the
bicycles
right.
So
these
are
all
ways
in
which
you
can
change
the
context
and
and
there's
many
more
I'm
sure,
rafat
next,
thank
you
and
and
in
all
of
this
right,
our
defense
right
now
is
this
mythical
creature.
B
I
call
a
homosecuritist
who
is
a
security
expert.
He
understands
how
the
protocol
should
work.
He
can
detect
these
attempts.
He
is
so
focused
on
the
current
context.
He
knows
exactly
what's
going
on
around
him,
but
they're
a
rare
species
right
instead
next
slide.
This
is
really
homo
sapiens
right.
We
need
to
help
homo
sapiens
here,
they're,
really
expertise
elsewhere,
right,
they're,
very
smart,
but
this
is
not
their
area.
They're
busy
they're
in
a
rush.
C
B
B
How
do
we
help
them
to
make
better
decisions
and
when
they
make
a
bad
decision
right?
How
do
we
protect
them,
and
how
do
we
provide
guidance
to
implementers
of
these
protocols
to
not
just
implement
the
protocol
but
actually
take
into
account
this
attack
attack
vector
so
that
we
have
safer
implementations,
rafat?
B
B
So
this
is
the
entire
section
on
remote
phishing
and
really
I'm
gonna
sort
of
summarize
right,
two
recommendations
around
better
ui
right,
so
that
there
is
some
acknowledgement
there
and
then
there
is
something
that
says:
okay,
if
you
made
a
bad
decision
to
limit
the
risk,
just
limit
the
lifetime
of
the
tokens
right,
so
that
it's
not
a
forever
problem,
and
so
that's
the
extent
of
what
we're
recommending
for
protecting
against
phishing
right
now.
Next
slide,
please,
but
it's
not
all
there's
some
others
right.
B
That's
also
relevant,
so
there's
a
section
on
non-visual
code
transmission
and
it
really
sort
of
talks
about
proximity,
but
really
proximity
in
the
context
of
a
non-visual
co-transmission
and
it's
not
in
the
context
of
fishing,
and
I
think
this
is
actually
a
valuable
and
useful
one
in
the
context
of
fishing
and
putting
some
more
emphasis
on
that
might
be
good
next
slide,
please
the
other
thing
in
the
security
consideration
section
is:
it
does
talk
about
trust,
there's
a
topic
called
device
trustworthiness,
so
so
another
thing
to
think
about
is
what,
if
you
only
allow
trusted
devices
to
participate
in
this
flow,
which
may
not
always
be
practical,
but
if
we
could
do
that,
that
could
be
another
solution.
B
But
again
the
guidance
that
we
have
today
is
really
more
about.
Considerations
of
malicious
authorization,
servers,
there's
a
sort
of
a
comment
that
says:
there's
two
devices,
but
it's
all
and
then
it
says:
well,
you
need
to
trust
the
device
provider
which
is
good
right.
We
should,
but
it
doesn't
really
tell
us
more
about
what
that
mechanism
should
be,
and
that
may
well
be
out
of
scope
of
the
protocol,
but
maybe
that's
a
consideration
that
we
want
to
provide
more
guidance
on
as
well.
B
So
what
else
could
we
do
right?
So
there's
some
ideas.
That's
come
up
in
discussions
with
daniel
and
philip
and
many
others
in
this
room.
Even
so
next
slide,
please!
So
one
is
looking
at
proximity
right,
christina.
I
think
you're
familiar
with
this
stuff
as
well.
You
would
have
seen
versions
of
this
and
some
of
your
work
too.
B
So
you
know.
Could
we
could
we
look
at
introducing
more
guidance
and
mitigations
on
how
to
use
proximity
not
just
pointing
out
proximity
but
but
how
we
might
accomplish
that
both
for
user
for
the
user
experience,
but
also
in
terms
of
mitigating
some
risk
on
the
back
end,
do
we
need
to
give
con
guidance
on
content
filtering
right
if
you're
deploying
device
code
flow
or
device
authorization
grant,
should
we
give
guidance
about
the
need
for
having
content
filtering
solutions
in
place?
B
Additional
metadata
token
binding,
writes
who,
if
somebody
manages
to
obtain
access
and
refresh
tokens,
do
we
want
to
at
least
make
it
so
that
they
cannot
exfiltrate
the
tokens
and
use
them
in
lateral
attacks
on
other
devices
right?
Is
there
some
additional
hardening
that
we
want
to
do
there
trusted
devices
I
already
sort
of
alluded
to
and
then
there's
even
work.
That's
happening
work
in
a
way
system
that
may
be
relevant
right.
So
do
we
need
to
think
about
things
like
secure,
qr
codes
right?
Is
there
a
solution
that
can
help
there?
B
So
these
are
some
of
the
examples
there
might
be
more.
I
I
fully
expect
that
people
in
this
working
group
have
many
more
ideas
that
we
can
add
to
this.
These
are
just
some
some
early
beginnings,
aerofog
excite
these.
B
So
another
thing
to
think
about
is
you
know
one
of
the
comments
when
you
and
sort
of
it's
on
the
the
mailing
thread
at
the
moment
is
well.
B
You
really
shouldn't
use
device
code
flow
in
certain
settings
right,
but
just
like
our
customer
or
the
end
user
is
busy.
The
engineer
sometimes
also
is
busy
and
is
not
an
expert
in
the
field
either
and
so
giving
some
guidance
about.
You
know
when
you
need
to
have
these
cross
device
type
flows,
giving
some
guidance
about
which
protocols
to
use
then
a
kind
of
a
protocol
selection
guide.
That
might
be
something
else
that
helps
and
it's
true
right.
B
The
engineers
can
just
read
all
the
different
protocols
and
decide,
or
they
can
employ
an
expert
but
again
right
if
we,
if
we
as
a
community,
can
make
some
recommendations
that
that
could
be
another
potential
solution.
B
So
what
should
we
do
right
if
we
go
to
the
next
slide,
so
you
know
there's
some
options
here
right
one
we
could
say
we'll.
Do
nothing
I'll
remind
you
about
the
first
slide
I
put
up,
which
is
you
know?
Maybe
we
should
do
or
could
do
more.
B
You
know,
a
simple
thing
is
just
more
implementation,
guidance,
threat
models,
risk
assessment
frameworks,
even
user
experience,
guidance,
right
profiles,
recommendations
and
so
on.
You
know
maybe
there's
new
protocols
that
we
need
to
look
at
cbs.
One
of
those
that's
interesting,
but
you
know,
may
actually
be
subject
or
actually
be
vulnerable
to
similar
exploits,
and
then
you
know
I
you
know
any
other
options
right.
I
think
that's
part
of
why
we're
bringing
it
to
this
audience
is
to
see
if
there
is
some
other
ideas
that
people
might
have
so
rafael.
B
I
think
we
can
come
back
to
this
slide
later.
I
do
want
to
give
philip
an
opportunity
to
maybe
come
and
talk
so
when
philip
and
I
spoke
earlier
today,
he
mentioned
that
he
sort
of
came.
You
know
he
saw
another
kind
of
social
engineering
attack
and
related
to
this
protocol,
so
I'm
going
to
hand
it
over
to
philip
to
talk
about
his
insights
as
well.
Thanks,
philip,
thank
you.
D
D
Okay,
thank
you
peter
for
making
us
giving
us
a
good
summary
on
how
device
flow
and
device
authorization
ground
works.
In
general,
there
was
one
very
important
piece
that
you
mentioned
and
that's
the
use
of
qr
codes
and
there
is
a
class
or
there
is
a
certain
attack
that
is,
that
is
ongoing.
That
is,
that
is
possible
to
exploit
at
the
moment
which
abuses
the
fact
that
not
everybody
uses
those
qr
codes.
D
Let's
have
a
look,
so
I
want
to
point
out
the
textual
versus
non-textual
nature
of
of
the
protocol
on
the
left
side.
D
We're
asking
the
user
to
go
to
his
other
device,
enter
a
string
and
then
enter
another
one
on
the
right
side,
I'm
asking
the
user
to
to
pick
up
his
phone
scan,
something
which
gets
translated
into
the
exact
same
url
and
the
code
already
embedded
and
the
user
only
has
to
compare
at
the
end
when,
when
he
opens
up
the
qr
code
with
his
browser,
they
only
need
to
compare
that
the
code
that
he
sees
on
the
phone
matches,
the
one
that
is
over
here-
and
why
is
this
important?
D
We
can
go
to
the
next
slide
before
I
go
right.
That
is
important.
This
non-textual
thing
was
brought
up
into
the
rfc
as
an
optimization
and
we
have
a
text
there.
That
says
that,
with
the
optimization
that
the
user
does
not
need
to
type
in
the
user
code,
the
bigger
optimization
actually
is
that
they
don't
need
to
type
in
the
actual
url
and
let's
have
a
walk
through.
Why?
D
Because,
let's
imagine
that
the
end
user
mistypes,
the
verification
uri.
So
that's
the
url
that
I
was
told
to
go
to
or
I
just
entered
it
into
a
search
engine,
because
that's
the
thing
now
where
the
url
bar
is
overloaded
with
multiple
functions,
meaning
that
I
will
either
land
on
a
phishing
site
directly.
D
I
will
enter
my
user
code,
as
I'm
told
by
my
tv,
for
instance,
and
instead
of
being
presented
with
hey,
you
know,
confirm
the
code
and
being
able
to
log
in
it
tells
me
I
should
phone
a
phone.
I
should
call
a
number
where
a
scripted
scenario
will
take
place.
An
agent
on
the
phone
will
first
ask
me
for
an
email
address
and
because
I'm
on
the
phone
with
him,
it's
really
easy
to
make
me
distracted,
as
he
walks
me
through
a
password
reset
flow,
where
he
asks
me
to
confirm
a
code.
D
As
I
do
that
the
agent
is
now
authenticated,
they
can
run
the
rest
of
their
scam.
They
can
buy
digital
products,
they
can
attempt
to
upsell
fake
services
to
me
so
to
directly
extract
money
out
of
me,
and
the
ridiculous
thing
is
that
at
the
end
of
this
all,
when
they're
done
they're
still
going
to
log
me
onto
my
tv,
I'm
very
happy
because
I
can
finally
watch
the
tv
show
that
I
was
about
to
log
in
and
the
detection
of
all
of
this
is
delayed.
D
Let's
move
on,
thank
you.
So
the
key
point
here
that
the
end
user
actually
did
initiate
the
authorization
flow.
It
is,
you
know
their
target
to
login
onto
the
tv.
It
was
not
the
attacker.
The
user
has
a
legitimate
stake
in
completing
the
flow,
improving
consent.
Confirmation
screen
on
the
other
device
does
absolutely
nothing
because
I
will
never
see
it.
D
Yes,
this
is
an
end
user
problem.
There
are
post
signs
along
the
way
that
I
choose
to
ignore,
but
we
can
still
do
better
because
if
we
prefer
non-textual
code
transmission,
if
we
did
not
offer
the
a
enter
url
in
the
first
place,
this
would
not
have
happened
likewise
if
there
were
actual
password
reset
links
and
then
password
reset
codes.
D
C
D
With
his
demo
is
other
than
the
qr
codes,
is
there
anything
else
that
is
readily
available
and
usable
that
we
can
offer?
F
G
H
E
Okay,
so
this
is
just
a
quick
demo
to
visualize
what
we're
talking
about
here,
because
usually
a
screencast
says
more
than
a
thousand
screenshots.
So
what
we
have
here
is,
on
the
right
hand,
side
wallet
that
we're
working
together
with
a
project
in
the
id
union
project
and
in
the
middle
you
see
a
phishing
site.
So
essentially
you
have
to
imagine
that
you
only
see
this
part
as
a
normal
user.
You
go
to
a
website
and
you
want
to
use
your
wallet
at
that
website.
E
That
website
is,
in
this
case
called
attacker.example.com
button
practice
might
have
a
name
that
is
less
suspicious,
so
you
have
that
website.
You
want
to
log
in
you
see
a
qr
code.
Everything
looks
completely
normal
to
you.
You
want
to
log
in
at
that
website.
E
So
what
you
don't
see
is
that
this
is
an
attack
uncontrolled
website.
Maybe
it's
a
compromise
website.
Maybe
it's
just
set
up
specifically
for
that
purpose,
and
the
attacker
is
not
showing
you
a
qr
code
that
will
lock
you
in
at
attacker.example.com,
but
instead
the
attacker
has
taken
that
qr
code
from
another
website.
In
this
case,
it's
a
it's
an
xcloud
login
that
also
works
with
the
with
the
wallet
login
and
the
attacker
has
just
stolen
that
qr
code
from
there.
You
don't
see
that
website.
E
E
So
you
see
that
qr
code
you
want
to
log
in
you
open
your
wallet
app
on
your
device
that
would
be
on
your
mobile
device.
You
click
on
scan,
qr
code
and
stop
here.
Please
you
click
on
scan,
qr
code
and
on
your
mobile
device.
You
see,
do
you
want
to
log
in?
Do
you
want
to
provide
some
data
to
that
website
for
the
login
process?
And,
yes,
you
want
to
log
in
at
attacker.example.com,
so
you
click
on
yes
and
send
and
do
and
whatever.
E
E
B
Daniel
rafat,
can
you
show
the
last
slide
of
my
presentation
again
so
so
back
to
the
question
about
what
we
can
do
about
this.
Hopefully
this
is
sort
of
a
bit
of
an
overview.
I
think
you've
heard
from
a
couple
of
people
who
have
come
across
this
social
engineering
angle
and
some
of
the
challenges
that
we
run
into
with
it
and
and
so
yeah.
I
mean
I'd
love
to
hear
back
from
folks
in
this
room
right.
A
reasonable
thing
that
we
can
do
right
is
it
is
it?
B
Is
it
worthwhile
right
to
provide
some
additional
implementation
guidance
on
top
of
the
device
authorization
grant
to
highlight
some
of
these
topics?
Would
it
help
or
you
know,
is
there
other
things
that
we
should
do?
Should
we
really
be
thinking
about
other
types
of
protocols
or
other
types
of
solutions
and
yeah?
That's
my
question
for
for
folks,
in
this
room
or
or
online.
J
Tim
quality,
microsoft.
I
just
didn't
like,
as
you
said,.
B
J
Yeah,
so
so
I
think,
there's
two.
I
think
we
have
to
up
level
the
discussion
to
the
use
case
to
solve
the
use
case
moving
forward.
In
my
opinion,
the
solution
is
web
authent
and
cross
device
flow,
and
that
is
an
important
distinction,
because
we
have
to
start
that
message
now,
because
these
tvs
that
are
sitting
here
stay
in
people's
houses
for
seven
to
ten
years.
J
J
I
agree.
Everything
about
trying
to
reduce
the
risk
with.
What's
there
today
has
to
continue
that
discussion
has
to
continue,
but
in
parallel
we
have
to
start
the
conversation
about
getting
rid
of
device
code
flow
and
I
think
they
intersect
at
a
point
where
you
can
start
to
reduce
the
attack
surface
by
reducing
the
scopes
you're
granted
when
you
use
the
vice
code
flow
and
those
will
drastically
intersect,
hopefully
in
the
near
term.
K
E
I
A
J
H
Hi
victoria
octa,
I
think
that
the
web
often
future,
is
beautiful
and
bright
and
very
powerful,
but
I
think
that
there
are
stepping
stones
that
we
can
use
to
get
there
and
in
particular
right
now
we
have
this
section
in
which
we
say
use
whatever
you
have
to
transfer
context
between
the
requesting
and
the
authorizing
device,
and
I
think
of
it.
We
have
an
opportunity
to
be
a
bit
more
prescriptive,
so
their
bluetooth
is
mentioned,
and
bluetooth
is
also
the
thing
that
fuels.
H
This
is
the
thing
that
the
team
described
if
we
were
to
be
more
specific
and
say:
okay,
here
is
a
how,
in
practical
terms,
to
use
bluetooth,
we
can
transfer
context
from
a
requesting
device
to
a
collocated
authorization
device,
and
once
you
have
that
entrained
and
without
mandating
web
often,
but,
for
example,
just
saying
when
this
happens,
you
open
the
system
browser
and
you
go
to
his
url
plus
code.
At
that
point,
you
would
mitigate
the
number
of
the
challenges
that
you
highlighted
and
if
it's
standard
now,
you
can
reasonably
expect
the
hero.
H
Apps,
like
your
authenticator
or
google
authenticator
or
the
oculus
authenticator
or
even
operating
systems,
can
start
doing
this.
Of
course,
other
challenges.
You
still
need
the
interstitial
dialogue
saying
this
is
happening,
but
I
think
it
will
be
a
significant
improvement
not
just
from
the
security
perspective,
but
also
from
the
user
for
user
experience.
A
C
L
L
M
Hi
justin
richard
so
the
composed
uri
is
something
that
I
always
hated
about
the
device
flow
and
I
helped
write
that
paragraph
with
all
of
the
considerations
of
don't
just
auto
post
the
form
and
all
of
that
other
stuff,
because
I
always
felt
that
that
was
a
bad
idea,
because
I
think
I
think
fundamentally
here.
What
we're
realizing
is
that
these
are
two
very
different
interaction
modalities
in
one
we're
communicating
something
that
a
user
needs
to
like
be
able
to
type
whether
it's
you
know
the
pair
of
uri
and
the
code.
M
Or
you
know
just
the
code
itself.
Would
they
get
the
uri
from
documentation
or
whatever?
That
is
very
separate
from
being
able
to
have
a
uri
with
a
whole
bunch
of
stuff
packed
into
it
or
like
even
like.
We
saw
in
daniel's
demo
being
able
to
send
a
long,
arbitrary,
untypable
chunk
of
information
to
the
user,
where
we're
not
expecting
them
to
copy
and
paste
or
to
remember
or
to
transcribe,
or
anything
like
that,
and
I
think
our
first
step
at
this
needs
to
be
separating
these
and
not
treating
these
solutions.
N
Hunt
hi:
this
is
santiago.
I
have
a
more
general
remark,
I'm
not
even
sure
it's
in
scope,
but
I'll
try
anyway.
N
So
there
was
something
that
rang
my
bell
in
in
a
previous
talk,
which
was
basically
this
observation
that
many
developers
don't
really
know
what
they
do
or
might
be.
You
know
puzzled
by
what's
available
in
the
standards,
and
my
experience
actually
from
developer
using
encryption
standards
is
that
many
of
the
stuff
doing
by
crypto
researchers
is
very
much
low
level
and
it's
very
hard
to
grasp
actually
how
to
apply
that
and
what
errors
can
be
made.
C
N
Like
to
have,
if
you
and
I
read
that
a
little
bit
in
user
experience,
guidance
is
maybe
something
like
you
know
about
design
patterns
in
programming,
like
you
know,
standardized
label,
descriptions
of
certain
cases
or
error
cases
which
are
interlinked
and
help
me
navigate
and
relate
a
little
bit
different,
how
different
things
can
be
put
together
and
which
errors
might
occur.
If
I
choose
a
certain
solution,
that
was
that
direction.
I
J
I'm
not
gonna
let
the
room
leave
with
what
you
said:
that's
not
correct,
so
there
are
at
about
we're
guessing
two
billion
devices
that
now
have
this
capability
over
the
next
over
the
past
three
to
four
months,
and
you
are
correct,
though,
that
that
was
not
the
the
communication
to
the
phone
was
not
web
authentic.
My
point
is,
I
didn't
actually
say
verbally.
Was
that
from
an
idp
standpoint,
you
don't
need
to
implement
anything
special.
It's
just
web
authentic,
okay,.
A
Thanks:
okay,
hey
thanks
tim!
Do
you
have
any
just
last
minute
comments,
or
I
wanna
just
summarize
this
after
that
and
see
what
we're
gonna
have
together.
B
Again,
some
great
points
thanks,
everybody
justin,
I
I
think
your
point
is
spot
on.
I
do
think
these
are
separate
things.
I
think
that
the
points
been
made.
We
have
to
secure
what
we
have
and
then
we
have
to
look
for
ways
in
which
we
can
minimize
the
use
of
that
and
provide
better
alternatives.
That's
kind
of
my
my
summary
of
that.
I
think
that
the
point
around
either
way
when
I
think
about
engineers
right
they've,
got
expertise
elsewhere.
B
They
may
not
be
security
experts
and
the
rate
with
which
oauth
is
just
expanding
in
the
world
and
being
adopted
expecting
more
people
to
become
experts
at
this
is
not
not
right
and
so
giving.
I
feel
like
I'm
hearing
yeah,
we
need
to
give
more
guidance
and
we
need
to
help
the
developers
with
that
and
yeah.
I
think
that's.
A
B
So,
if
folks
are
interested
in
this
topic,
reach
out
to
me,
let's
start
working
and
figuring
out
how
we,
how
we
shape
a
response
here
as
a
as
a
group
in
the
community.
Thank
you.
Everybody
thank.
A
G
F
H
H
H
Step-Up
authentication
is
a
pretty
well-known
problem
which
emerges
in
various
circumstances
and
for
which
we
have
no
standard
solution,
and
we
don't
have
interoperability
and
that's
the
reason
for
which
we
decided
to
try
to
analyze
our
problem
and
see
whether
we
can
suggest
a
very
essential
way
of
dealing
with
that.
So
we're
going
to
spend
a
few
moments
on
the
problem
which
is
well
known,
but
still
by
due
diligence,
then
few
moments
of
your
proposal,
which
is
a
really
really
bare
bone.
So
it
shouldn't
take
long
and
then
we'll
discuss.
H
All
right,
so
we
know
that
there
are
organic
ways
of
witnessing
a
step
up
of
education,
so
a
client
might
ask
for
an
initial
set
of
scopes
and
then
knows
that
it
needs
to
call
another
method
of
api
and
that
api
might
require
requesting
a
different
scope
which
in
itself
might
require
to
do
a
step-up
authentication.
So
those
are
the
cases
in
which
the
problem
solves
itself.
Let's
say
that
the
step-up
authentication
just
occurs.
H
It
might
say
you're
trying
to
buy
an
item
which
exceeds
your
spending
limit
and
the
item
that
you're
trying
to
buy
is
not
available
at
the
moment
in
which
you
are
asking
for
the
token,
and
so
the
authorization
server
cannot
do
anything
to
reflect
these
height
and
requirement,
or
we
know
that
it's
fashionable
nowadays
if
to
do
continuous
authentication,
and
so
you
might
have
risk
engines
or
any
other
black
box
logic
which
might
decide
that
the
token
that
you
send
is
not
enough,
and
today,
unless
you
have
some
proprietary
way
of
dealing
with
that
particular
scenario,
you're
stuck
because
the
client
is
just
going
to
repeat
the
request
for
research
server
get
the
same
token
that
he
requested
before
and
the
refuse
service
just
in
the
same
way,
so
not
great
okay.
H
So
what
we
are
suggesting
is
very,
very
simple.
We
are
just
introducing
a
new
error
code,
which
basically
says
authentication
level
was
not
sufficient,
and
then
we
are
borrowing
a
couple
of
parameters
that
are
already
in
use
in
open
id
for
id
token
requirements
and
we're
basically
saying
okay,
a
resource
server.
H
You
can
specify
in
your
challenge,
sending
back
this
error
code,
also,
the
acr
that
you
would
like,
or
the
list
of
acrs,
that
you
are
okay
with
for
for
the
client,
so
that
the
client
can
turn
around
repeat
the
request
of
the
refrigeration
server
and
include
voice
parameters.
H
Now,
in
the
case
of
open
id,
when
you
use
those
parameters
again
affecting
the
token
in
this
particular
case,
we
would
extend
your
semantics
to
apply
to
the
access
token
and
also
open
id
is
lux.
Let's
say
it
says:
well
authorization
server!
If
you
want
to
do
it,
do
it,
but
you
are
not
forced
to.
Instead
in
here
we
would
add
something
in
the
metadata
which,
for
the
foundation
server
to
comply
to
this
particular
flow,
it
would
commit
to
actually
do
its
best
to
comply
with
a
requested
acr.
H
This
system
would
be
compatible
with
existing
mechanisms
we
have
today,
such
as
the
scopes
like
today.
We
have
insufficient
scopes,
and
so
we
would
be
perfectly
fine
if
you
happen
to
be
in
the
circumstance
in
which
you
need
both
to
elevate
your
acr
and
to
request
new
scopes
to
ask
above
things
at
the
same
time,
and
basically
now
that
we
have
a
vehiclet
profile,
we
can
actually
describe
how
to
report
the
outcome
of
these
different
authentication
in
the
form
of
the
acr
claim.
H
Another
real
power
of
this
thing
will
come
into
play
because
I
can
show
you
a
fantastic
animation,
so
here
you
have
a
client
that
you
have
your
resource
server
and
your
authorization
server
business
as
usual.
I
just
try
again,
I
include
my
better
token
but
as
it
turns
out
actually
here
sorry,
not
very
big.
H
There
is
no
acr,
it's
just
like
standard
token
and
again,
I'm
using
jwt
just
for
simplicity,
but
you
can
perfectly
have
an
opaque
token
that
uses
introspection
and
there
is
of
server
deems
that
the
level
of
authentication
reflected
is
insufficient,
and
so
now
it
returns
insufficient
user
authentication
and
in
this
particular
place
it
includes
only
one
acr
value.
Of
course
it
could
also
include
the
max
age
if
necessary.
H
It
could
also
include
scopes
if
scopes
are
also
missing
and
then
at
that
point
the
client
turns
around
goes
back
to
authorization
server,
and
it
includes
the
information
about
the
acr,
which
would
not
normally
have
been
available,
which
could
be
contextual
to
the
particular
request
and
the
characteristics
in
there
then
for
the
server
we
do,
whatever
it
deems
necessary,
hopefully
trying
to
comply
with
my
acr
and
assuming
that
the
user
successfully
authenticates.
We
get
our
usual
response,
and
this
time
we
got
reflected
in
our
settings
that
we
did
comply
with
acr.
H
We
presented
this
problem
in
a
similar
proposal
at
the
off
security
workshop
last
year,
and
this
session
was
the
most
voted
by
the
people,
despite
the
fact
that
we
did
it
at
the
very
last
moment
and
the
comments
and
the
tweets,
like
the
various
reactions
were
all
like.
Oh
wow,
are
you
saying
that
this
is
not
standardized
yet
like
it
looks
like
it's
a
problem
which
is
fairly
common
and
also,
I
know
that
some
platforms
already
have
their
own
proprietary
solution,
but
it
seems
like
whether
it's
solved
this
way
or
in
some
other
way.
H
This
type
of
problem
is
a
problem
that
people
have
so
one
advantage
would
be.
We
now
have
an
interoperable
way
of
doing
this.
The
other
is
that
it
is
a
relatively
small
step.
We
are
not
asking
anyone
to
start
implementing
eventing,
seven
buses
event,
syncs
asynchronous
stuff,
stateful
stuff.
This
is
a
ultra
basic,
sending
back
parameters
in
the
context
of
transactions
that
are
already
occurring,
so
we
are
not
creating
new
messages
or
anything,
and
we
are
staying
squarely
within
the
extensibility
mechanisms
that
respect
offer
and
yeah
brian
am
I
forgetting
something.
O
A
P
M
So
my
question
is
really
around
why
the
resource
server
is
the
one:
that's
caring
about
authentication
levels
as
opposed
to
the
authorization
levels
applied
to
the
access
token,
because
there's
this
great
blog
post
that
says
how
the
resource
server
is
not
the
service
that
you're
actually
logging
into
it.
Has
this
whole
metaphor
with
chocolate
and
chocolate
cake?
You
may
have
read
this
one:
it's
vitoria's
blog!
If
no,
but
if
people
didn't
get.
Q
H
M
M
Just
trying
to
see
what
what
the
use
case
is
here,
where
that's
driving
the
the
rs
needing
or
even
caring
about
that
information
about
the
authentication
level
of
the
user
at
the
as
because
you
know
traditionally,
once
you
get
the
access
token
it's
just
whatever
the
access
token
is
good
for
and
so
can
you
can.
You
help
me
understand.
What's
driving
to
this
particular
solution,
absolutely.
H
And
thank
you
for
every
question
because
it's
a
it
gives
the
opportunity
for
a
useful
clarification,
which
is
we
still
care
about
the
authorization
in
this
case
and
we
are
not
trying
to
mess
with
what
open
id
already
does.
This
is
similar
to
the
use
cases
that
we
explored
when
we
did
the
generality
profile,
which
led
to
adding
the
acs
of
the
acr
claim
in
the
layout,
and
basically
there
are
a
number
of
scenarios
in
which
the
resource
in
itself
has
requirements
about
the
authentication
level
of
a
user
still
for
authorization
purposes.
H
So
it's
not
like
that
they
want
to
mess
with
anything
it's
more
of
like
if
I
am
reading
nails,
I'm
okay
with
this
password,
but
as
soon
as
you
want
to
send
mail,
I
would
like
to
know
that
a
user
performed
mfa.
Now
personally,
I
agree
that
it
would
be
best
if
a
resource
server
would
somehow
translate
these
in
some
other
form
like,
for
example,
scopes
that
reflect
a
different
authentication
level.
But
the
thing
is
we
already
have
acr,
which
already
have
a
semantic
with
maps
to
mfa
and
for
people
that
build
the
policies.
H
Mfa
is
an
easy
to
grasp
concept
and
so
requiring
it
somehow
is
something
that
happens
very
very
frequently,
like
you
know,
in
real
life
back
here
in
the
microsoft
days.
I
had
to
do
this
all
the
time,
but
actually
here
I
would
personally
want
to
place
in
here
also
amr
so
going
to
the
level
of
method,
but
the
guy
with
the
pink
mask
is
very
much
against
and
he
raised
a
good
point
that
it
would
be
brittle,
because
if
you
ask
for
something
specific,
then
it's
easier
for
break
it.
H
M
H
So
for
scopes,
as
we
mentioned,
basically,
you
can
just
return
here
the
list
of
scopes
that
you
want.
Alongside
with
this
so
imagine,
it
emerged
within
sufficient
scopes
on
that
source
of
trust.
I
let.
C
C
You
know
authorization
server
issues,
an
access,
token
that
works
for
multiple
resource
servers.
You
know
that,
maybe
not
within
the
same
domain.
I
worry
that
we
don't
have
standards
around
acrs.
I
have
seen
people
use
justin
vectors
of
trust
tags
as
their
acr
values.
You
know
aal1
aal2,
as
the
value
that's
being
requested.
We
also
have
the
eap
stuff
in
the
openid
foundation
that
allows
you
to
request
a
hardware
backed
phishing
resistant
authentication.
C
So
there
is
some
stuff
here,
but
I
think
there's
you
know
some
more
guidance
from
a
larger
interoperability
perspective
that
we're
going
to
want,
but
within
a
single
domain,
where
the
resource
servers
and
the
authorization
server
are
sort
of
all
run
by
the
same
company.
I
think
you
know
this
would
work
fine,
and
I
do
think
there
are
lots
of
cases
whether
it's
time,
based
or
otherwise,
where
apis
that
are
being
invoked
need
to
have
some
level
of
addition,
additional
authentication
right.
C
I
want
to
know
that
you
entered
your
rsa
code,
I
mean
this
happens.
This
used
to
be
on
ebay.
You
know
e-trade
all
the
time
right,
you
got
to
do
a
trade
and
it
pops
up
the
thing
for
your
rsa
token
enter
your
code
right,
and
I
think
we
sort
of
have
to
include
that
as
sort
of
an
authorization
mechanism
to
justin
questions
thanks.
S
Good
point
to
mull
over,
I
think,
for
for
the
meeting
minutes.
I
I
captured
that
the
same
domain
issue,
but
I
wasn't
quite
sure
what
the
cross-domain
use
case.
George
was
like
you're
saying
this
is
not
enough
for
across
the
main
use
case
or.
C
Sure
I
want
to
take
you
know
a
token
issued
by
you
know.
I
you
know
by
a
company
that
is,
you
know,
issuing
tokens
and
use
them
at
some
completely.
Other
reason,
like
think
about
a
resource
server
that
works
with
multiple
email
providers
right.
The
each
email
provider
is
issuing
its
tokens
right
and
it
may
support
multiple
issuers
right
and,
and
those
tokens
are
coming
into
its
api.
C
Now
it
needs
to
know
what
are
all
the
different
specific
acr
values
that
each
of
those
issuers
and
figure
out
which
one
to
send
right.
I'm
just
saying:
there's
complexity
there,
so
we
could
we
could
frame
this
in
the
context
of
you
know.
This
makes
that
this
makes
straightforward
sense
in
the
context
for
the
resource
server
and
the
authorization
server
in
the
same
domain
right
when
they're
not
is
sort
of
out
of
scope
of
the
spec.
H
By
all
means
great
great
point,
interesting
thing
to
think
about.
I
think
that
the
fact
that
acr
is
by
reference-
and
it's
just
a
string
and
both
parties
need
to
know
what
that
means
is
a
natural
scoping
mechanism.
H
Let's
say
that
a
resource
server
will
say:
I
need
these
acr
and
that
acr
connect
can
have
been
acquired
only
out
of
band
while
talking
with
a
particular
authorization
server,
and
I
think
that
that
might
be
enough
of
a
scoping
mechanism
because,
like
they
are
more
than
one
authorization
server
and
they
share
the
myhcr,
like
imagine
that
the
gain
faults
actually
succeed
and
save
at
the
gain
profile
as
identity
providers
and
authorization
servers
that
follow
the
same
model
and
they
share
like
acr
values
which
have
semantic
in
the
context
of
that
particular
system.
H
At
that
point,
it
looks
like
you
might
have
more
than
one
domain,
but
you
might
have
a
good
reasons
to
use
the
same
stuff,
so
I
I
take
them
at
a
point
that
people
need
to
think
about
this
and
they
need
to
be
probably
mindful
and
explicit
about
how
to
scope
it,
whether
that
results
in
being
in
the
same
domain.
I
think
that
we
need
to.
I
approve
the
thing
like
study
it
and
see
whether
there
is
a
conclusion
or
not,
but
in
general
I
agree
with
with
the
premise.
T
Yeah
it
was,
it
was
exactly
that
the
there
is
some
agreement
on
what
the
meaning
and
levels
of
acr
that's
necessary.
It
might
be
on
a
pairwise
basis.
It
might
be
on
an
ecosystem
type
basis,
but
there's
nothing
inherent
about
that.
That
would
limit
it
to
a
single
domain
so
that
I
don't.
I
guess
I
do
disagree
with
that.
Characterization.
The
general
idea
that
there's
something
needed
to
to
work
and
unders
a
shared
agreement
about
acr,
yes
but
limited
to
the
same
domain
is
not
not
the
right
scoping.
D
Phillips
here
I'm
sorry,
so
very
quick
thing
that
very
quick
thought
that
came
into
my
head
is
that
the
client
and
the
resource
server
will
probably
need
to
share
some
level
of
trust,
or
there
needs
to
be
some
level
of
trust
established,
because
otherwise
the
resource
server
can
now
turn
and
make
the
client
do
something
that
maybe
it
didn't
want
to
do
in
the
first
place.
This
is
just
something
you
know
that
that
came
to
me.
D
If
there's
a
rogue
rs
that
the
client
is
made
to
talk
to,
it
can
now
turn
back
to
the
client
and
tell
him.
Listen,
just
add
these
parameters,
I'm
not
sure,
if
there's
anything
in
it,
but
it's
just
a
thing
to
consider
whenever
we
write
up
security
privacy,
whatever
considerations,
the
other
thing
is
it's
great,
that
there
will
be
something
else
than
6750
that
actually
uses
www
authenticate,
because
it
will
force
clients
to
implement
parsing
it
correctly.
Thank
you.
H
Thanks
philip,
I
really
like
the
observation,
mostly
because
of
visa,
validates
using
a
specific
semantic
for
those
parameters,
as
opposed
to
just
say:
let's
have
a
generic
property
bug
that
we
sent
back
to
the
client
and
that
the
client
might
mindlessly
just
send
out
so
that
at
this
point,
like
the
the
semantic
of
acr
values
and
max
age
and
scopes
is
very
well
defined,
and
now,
of
course,
the
requisition
server
might
still
abuse
it
and
sure
the
the
resource
server
can
ask
for
an
absurdly
high
level
of
authentication.
H
But
the
point
is
they
can
do
this
already?
Let's
say
that
if
they
are
getting
a
token
from
a
fourization
server,
potentially
they
could
say
when
you
call
this
method.
When
you
ask
for
this
scope,
I
want
you
to
use
visa
authentication
level.
So
your
point
in
general
is
well
taken
that
we
need
to
make
sure
that
we
don't
enable
all
the
extensions
in
which
we
play
stuff
that
allows
things
that
are
unexpected
to
occur.
But
I
think
that
we
can
define
the
semantic
of
those
parameters
narrowly
enough
that
the
vets
should
be
content.
P
All
right
I'll
leave
you
once
again
so
I'll.
Take
this
opportunity
to
remind
about
the
there
is
an
iana
registry
for
access
or
authentication
context.
Last
rest,
it
actually
covers
across
as
well
based
on
rfc
6711.
I
set
it
up
years
ago.
It
has
like
all
of
the
globally
recognized
context
classes
like
the
e
e
I
dash
level
so
sure
and
stuff
like
that
in
it,
and
you
know
and
and
a
suspicious
number
of
swedish
stuff
as
well,
but
that
could
be
used.
P
I
mean
there
are
certain
things
that
or
shouldn't
really
should
have
global
wrecking
recognizability
right
and
you
dump
stuff
in
there,
and
I
think,
maybe
it's
time
to
go
and
revise
that
rfc
and
maybe
update
the
iana
registry
to
make
it
a
little
bit
more
like
applicable
to
oauth
and
oidc
anyway.
Thank
you.
O
O
U
Go
ahead
as
dave
robin
representing
backnet
the
building,
automation
control,
so
I've
been
evangelizing,
oauth,
2,
bacnet
people,
educating
them
the
whole
thing
collect
token
binding,
client
ids,
you
know
scopes
everything
now
with
it
seems
that
we're
throwing
in
an
additional
thing
here
that
I
have
not
been
evangelizing
to
them.
And
the
question
is,
you
said:
oh,
I
could
use
a
different
scope
here.
I
have
a
read
token
now.
I
want
to
write
scope
as
well
right.
U
Why
or
I
could
have
this
generic
email
scope
and
get
this
different,
a
acr
value,
so
it
seems,
like
the
permissions,
are
no
longer
scope,
based
they're,
a
combination
of
scope
based
and
acr
based,
it's
sort
of
this
weird
cross
product
or
something-
and
I
find
that
confusing.
I
understand
your
answer
was
well.
We
have
this
acr
mechanism,
so
we'll
use
it
as
opposed
to
new
scopes.
So
I'm
not
saying
that
this
is
a
bad
thing.
I
was
just
questioning.
Why
not
use
scopes?
H
So
there
are
two
various
levels,
so
first
scopes
are
not
necessarily
only
for
missions,
but
they
could
be
used
as
permission
in
this
particular
case.
Scopes
are
typically
something
that
you
have
at
request
time,
and
there
are
things
that
are.
You
are
typically
have
in
a
third
party
scenario.
If
you
are
a
first
party,
potentially
people
use
all
this
flow
with
no
scopes
at
all.
H
So
at
that
point
you
would
be
asking
them
to
include
scopes
in
a
scenario
in
which,
potentially,
there
is
really
no
delegated
flow,
so
technically
in
term
of
a
universal
turing
machine
scopes
have
the
enough
expressive
power
to
do
all
these.
Okay,
it's
just
that
now,
I'd
have
to
introduce
them
and
basically
have
the
same
semantic.
I
already
have
with
my
acr
with
implementation
that
already
react
to
this,
because
open
id
connect
already.
H
This
mechanism,
in
which
you
can
ask
for
these,
even
if
you
have
no
scopes
at
all
and
the
circumstance
in
which
you
needed
to
elevate
do
not
include
the
scopes
because
they
configuration
the
consideration
is
not
statically.
Calling
to
this
particular
subset
of
a
resource
is
more
situation
happened,
and
so
I
needed
to
ask
for
this.
So
in
terms
of
clarity
and
in
terms
of
distance
from
the
implementation,
this
finger,
we
believe,
would
be
clearer
and
also.
H
The
other
point
is
scopes,
as
a
mechanism
of
a
challenge
has
been
in
there
since
the
very
beginning
and
very
few
people
use
it,
because
it's
so
generic
that,
in
the
end,
what
makes
a
difference
is
the
scopes
that
you
are
asking
for,
and
the
particular
semantic
for
your
particular
system.
So
just
having
the
mechanism
that
sends
the
scope
around
doesn't
make
much
of
a
difference,
and
despite
our
years
in
which
we
tell
developers,
do
incremental
consent,
don't
ask
for
everything
upfront.
Just
at
lunch.
H
We
were
discussing
the
fact
that
in
practice,
the
developers
wanted
to
avoid
these
as
much
as
possible,
and
so
rather
than
asking
for
scopes
when
they
need
it,
they
ask
as
much
as
possible
upfront
right
so
that
they
reduce
the
number
of
prompts
and
the
opportunities
for
developers
to
do
something
wrong.
So
sorry,
through
the
user,
to
do
something
wrong.
H
U
T
Just
one
more
thing
that
use
case
is
kind
of
near
and
dear
to
my
heart
that
this
fits
better
with
is
on
the
resource,
server
side,
some
kind
of
anomaly,
detection
or
ai,
or
whatever
black
box
indicator
or
even
signaling,
that
it's
receiving
that
suddenly
decides.
The
token
is
invalid
and
wanting
to
be
able
to
take
the
user.
Tell
the
client
to
take
user
through
a
re-authentication
flow
to
remediate
that
situation
is
something
that
is
even
harder
to
model
with
scopes.
T
I
think
you
probably
could,
but
it's
even
more
difficult
than
the
kinds
of
static
scope
to
authentication
levels,
so
just
one
one
more
driver
for
being
able
to
sort
of
independently
express
hey.
I
need
this
user
to
authenticate
again
at
this
level
and
do
it
in
this
time
frame
to
to
get
access.
F
V
Mike
jones
microsoft
reinforcing
my
friend
life's
comment
when
we
defined
acr
in
open
id
connect,
we
already
suggested
that
people
should
use
the
level
of
assurance
profiles
registry
for
the
values-
and
I
also
agree
with
brian's
comment-
that
the
fact
that
there's
mutually
understood
values
doesn't
imply
that
things
are
necessarily
in
the
same
domain.
F
H
Well,
as
you
have
seen,
the
scope
of
this
thing
is
pretty
small.
If
you
think
that
this
is
a
a
problem
worth
solving,
then
the
draft
is
out
there.
So
if
we
want
visa
to
be
adopted
and
work
in
it
reluctantly,
but
bryan
and
myself
are
willing
to
move
this
thing
forward.
A
Yeah,
I
get
the
feeling
from
the
room
that
there
is
interest
and
there
is
still
some
maybe
confusion
or
still
some
something
to
clarify.
So
I
would
encourage
you
guys,
victoria
and
brian,
to
maybe
update
the
documentary.
Take
that
input
into
consideration,
maybe
clarify
those
points
and
submit
a
new
version,
and
let's
see
if
how
we
can
move
it
forward.
The
next
time.
H
S
Okay
for
for
reviewers
of
the
document,
I
think
that's
always
good.
Since
now,
people
are
aware
of
the
of
the
document
like.
Maybe
maybe
you
have
a
show
of
hands
and
I
can
scribble
down
a
few
robin.
W
H
E
Thank
you
so
today
I
want
to
talk
about
the
sorry
state
of
the
clients
regarding
war
clients.
Obviously,
next
slide,
please.
E
O
E
There
we
go
excellent.
This
is
great
yeah,
fantastic,
okay.
So
what
is
a
good,
modern,
universal
client
library?
So
what
could
it
be?
Let's
say.
E
K
E
As
a
modern
library,
I
would
say,
library
should
support
at
least
a
certain
set
of
security
features
like
pxe.
It
should
support
methods
for
asymmetric
client,
authentication,
maybe
mtls,
and
maybe
maybe
maybe
a
big
question
mark.
It
should
support
things
like
auth,
2.1
or
floppy.
This
could
so,
even
if,
if
we
don't
say
okay,
this
all
libraries
need
to
support
happy.
That
would
be
a
bit
strange.
E
Obviously,
but
maybe
these
kind
of
profiles
can
give
you
give
us
a
direction
in
which
which
way
to
go
what
a
good
library
could
support
and
universal
means
that
it
is
not
tailored
towards
a
specific
use
case
or
specific
vendor
specific
api,
because
many
of
the
oauth
clients
that
you
find
out
there
are
written
for
sign
in
with
google.
Maybe
they
support
google
facebook
and
I
don't
know
amazon
whatever.
E
So
that's,
not
a
good
library.
If
you
want
to
use
the
library
something
completely
different,
it
should
not
be
limited
to
certain
use
cases
as
far
as
possible.
Obviously,
a
library
on
a
mobile
device
would
be
different
from
one
with
a
web
interface.
Maybe
maybe
it
could
be
the
same
library,
but
apart
from
that,
it
should
not
only
cover
very
narrow
use
case
yeah.
It
should
be
very
configurable
for
various
feature
sets
ideally,
so
it
should
not
assume
the
same
feature
set
in
all
the
use
cases.
E
For
example,
I
saw
that
many
libraries
claim
to
support
authentic
id
connect
where
in
reality,
they
just
implement
openmd
connect,
so
you
sometimes
cannot
even
switch
it
off.
That's
not
a
good
thing.
Ideally,
you
just
throw
some
issuer
url
at
the
library
and
the
library
configures
itself,
because
it
can
read
and
understand
server
metadata.
E
Okay,
okay,
yeah
yeah.
Maybe
we
take
the
comments
afterwards?
Okay,
okay,
so
what's
the
experience
in
practice?
When
I
say
experience
in
practice,
I
mean
my
personal
experience
and
that
is
at
yes.com,
where
I
help
customers
to
implement
yes.com,
which
is
more
or
less
frp2
profile,
so
all
standard
features
but
yeah
in
practice.
This
means
that
there
are
some
libraries
that
you
can
use
to
implement
what
we
are
doing
like
philips,
node.js
library
works.
Well,
we
have
a
demo
for
that
on
our
website.
E
You
can
just
use
that
it's
a
few
lines
of
code
works
really
well.
There
are
some
other
libraries
like
in
java,
the
nimbus
library,
but
apart
from
that,
there's
not
much
else
most
of
the
time.
That
means
that
our
customers
end
up
with
custom
implementations.
So
we
have
a
developer
guide.
We
tell
them
how
to
make
certain
requests,
how
to
process
responses
and
they
have
to
implement
this
step
by
step.
E
The
experience
is
for
me
personally
that
I
cannot
point
developers
to
good
libraries,
because
maybe
I
just
don't
know
where
the
good
libraries
hide,
but
my
impression
is
that
it's
really
really
hard
to
find
out.
What
are
the
features
that
the
library
supports?
Is
it
even
a
client
or
server
library?
Some
just
say:
okay,
we
implement
auth.
Okay.
What
exactly
do
you
do?
E
What
are
the
specifications
that
it
supports?
Is
it
just
rc,
6749
and
6750,
or
is
there
also
pixie?
Is
there
anything
else,
not
so
clear,
often
that
the
authors
have
a
look
at
the
latest
security
recommendations
or
not?
E
This
in
particular,
is
often
just
not
documented,
so
you
have
to
dig
into
the
code
and
figure
out
whether
they
I
don't
know
would
even
handle
things
like
an
issue
in
the
authorization
response
and
stuff
like
that.
Many
of
them
are
incomplete,
so
it
works
for
sign
in
with
google
and
a
few
others.
But
apart
from
that,
nothing
else-
and
there
are
dozens
of
unmaintained
implementations.
E
So
if
you
go
on
oauth.net,
where
erin
has
listed
all
the
libraries
for
different
languages,
if
you
click
on
them
like
every
second
of
them
last
update
four
years
ago
or
something
yeah
and
interestingly,
this
lack
of
good
libraries
is
like
a
self.
What's
it
called
so
so
so
fulfilling
prophecy.
Thank
you
the
because,
because
we
have
this
lack
of
libraries,
we
as
an
offer
of
an
api,
we
have
to
document
every
single
request,
every
single
response
how
to
process
it.
E
So
we
have
to
write
a
complete
documentation
on
the
http
level
and
this
leads
developers
to
just
implement
it
this
way
because
they
have
this
this
implementation.
They
see.
Okay,
it's
just
a
few
requesting
responses.
What
could
go
wrong
so
they
just
go
and
implement
it
themselves,
so
there's
no
real
incentive
for
them
to
learn
how
to
use
a
library
with
that.
E
Okay,
why
do
I
keep
hiding
my
phone
in
my
pocket
when
I
need
to
switch
slides
and
then
there's
what
I
call
the
auth
configuration
help
assuming
you
don't
have
server
metadata,
then
you
need
to
figure
out
a
few
things
until
you
can
use
the
library
yeah.
I
know,
but
I
need
to
I
need.
I
need
to
have
a
hand,
so
maybe
I
have
an
italian
somewhere
in
my
ancestry.
I
don't
know,
but.
E
The
auth
configuration
help
so
just
to
set
up
a
library
without
server
metadata
to
to
use
oauth.
You
need
to
figure
out,
like
the
dozens
of
dozens
and
dozens
of
things
like
what
are
the
endpoint
urls
authorization
endpoint
token
endpoint.
If
you
use
open
id
connect
user
for
endpoint,
what
are
the
supported
grant
types?
What's
what
method
of
client
authentication
is
used?
What
are
the
security
mechanisms
you
should
use
or
can
use
or
must
use?
E
Sometimes
you
want
to
use
a
security
mechanism,
you
don't
even
know
if
you
can,
you
can
use
it,
and
this
is
not
even
talking
about
the
specifics
of
the
api
itself,
so
you
still
have
to
figure
out
what
are
the
scopes
claims
and
so
on
yeah,
so
without
server
metadata.
This
is
a
really
tedious
process
and
this
also
reduces
the
value
in
using
libraries,
because
if
you
have
to
figure
out
all
of
this
yourself,
then
maybe
it's
just
easier
to
implement
the
http
requests.
E
What
are
the
consequences
from
this?
Well,
there
are
plenty,
first
of
all,
there's
an
unnecessary
fragmentation,
so
the
libraries
only
support
a
specific
subset
would
be
great
if
they
could
just
support
a
larger
feature
set,
and
maybe
then
we
don't
need
that
many
libraries.
E
This
also
leads
to
a
slow
adaption
of
new
specs,
so
we
have
recently
standardized
the
issuer
parameter
and
the
authorization
response.
This
is
a
really
really
small
change,
but
I
don't
expect
to
see
that
in
any
of
the
libraries
soon,
except
for
phillips
library.
Thank
you,
philip,
and
this
can
lead
to
developer
frustration,
except
for
those
who
is
in
phillips
library.
So
to
quote
hans
jackie.
If
I
may
quote
you,
he
just
was
it
yesterday.
I
know
the
day
before
yesterday.
E
He
said
that
when
they
implement
an
auth
client,
they
usually
count
several
hours
of
research
or
do
several
hours
of
research
before
actually
implementing
something,
and
this
is
not
a
good
situation.
If
you,
this
is
completely
unscientific.
But
if
you
take
a
look
at
twitter-
and
this
is
only
from
one
day-
so
I
just
opened
twitter
search
for
auth,
and
if
you
do
that,
you
find
many
many
voices
from
developers
who
seemingly
spend
hours
and
hours
of
configuring
auth.
E
So
part
of
this
is
the
auth
configuration,
and
I
really
wish
that
for
developer.
Only
the
only
thing
that
they
had
to
do
was
to
throw
an
issuer
url
into
a
library
and
then
off.
They
go,
of
course,
so
having
to
implement
some
specifics
for
the
api,
but
we
are
far
from
that
when,
when
you
count
the
voices
on
twitter.
E
E
Api
providers
also
have
to
spend
a
lot
of
time
just
explaining
what
they
are
doing.
It's
standard
auth,
so
they
they
have
to
explain
it
over
and
over
again
and
they
have
to
support
developers
who
don't
understand
or
off,
but
maybe
they
they
shouldn't
be
required
to
understand
the
auth.
They
should
just
be
able
to
use
auth,
yeah
and
then,
of
course,
the
developers
they
have
to
do.
Trying
errors,
trial
and
error
to
figure
out
what
is
supported
in
a
certain
api.
E
I
here
used
twitter
as
an
example
because
twitter
just
recently
created
an
auth
2
api,
and
this
is
very
interesting
because
this
is
not
a
legacy
api.
This
is
new,
they
support
pixi
and
so
on.
So
it's
it's
it's
from
so
it's
okay
from
the
security
profile
perfectly
fine.
But
if
you
read
the
documentation,
it's
interesting
that
you
see
that
they
expect
all
developers
to
essentially
implement
this
from
scratch.
E
So
they
they
talk
about.
They
have
a
glossary
with
auth
terms,
they
explain
the
or
flows,
and
they
also
have
an
explanation
for
every
single
parameter
that
you
use,
and
one
thing
in
particular
struck
me.
So
they
give
an
example
for
an
authorized
url
and
they
even
say
you
will
need
to
have
the
proper
encoding
for
this
url
to
work
be
sure
to
check
out
our
documentation
on
the
percent
encoding.
E
Why
do
we
have
to
do
that?
Yeah
I
mean
this.
Is
I
mean
we're
not
explaining
tcp
to
them
either,
so
this
should
not
be
required,
but
I
know
that
this
is
a
problem.
So
I
understand
why
could
I
put
it
there
because
we
have
the
same
problem
with
customers
implementing?
Yes,
so
yeah
there
you
go
yeah
and
obviously
my
favorite
topic
security.
Customer
implementation
is
obviously
also
bad
for
security,
so
there
are
many
many
opportunities
for
hidden
security
problems.
E
So
when
I
see
customers
implementing
our
apis,
I
sometimes
have
the
feeling
that
they
probably
don't
do
all
the
security
checks.
They
should
be
doing.
But
it's
hard
for
me
to
check
that,
because
I
cannot
look
into
their
code.
I
don't
have
the
time
to
check
their
code,
but
you
can
just
hide
a
lot
of
security
problems
in
a
custom
implementation.
E
The
if
there
come
new
security
recommendations,
it's
unlikely
that
custom
implementations
will
follow
them
and,
of
course,
we
have
known
anti-patterns
that
are
still
being
used,
like
state
being
filled
with
a
static
pattern,
also
pixi
being
used
with
a
static
code,
verify
code
challenge
yeah,
so
there's
some
research.
I
took
that
from
an
older
presentation,
but
I
guess
this
is
still
more
or
less
current
researcher
researchers
have
spent
some
time
to
look
at
actual
oauth
implementations
and
they
found
security
problems
in
almost
all
of
them.
It's
like.
E
E
So
let's
discuss
some
solutions
and
when
I
say
let's
discuss,
let's
discuss
that,
but
I'm
going
to
make
some
proposals,
maybe
as
the
basis
for
the
discussion
proposal
number
one
would
be
to
define
a
goal
because
currently,
when
somebody
starts
implementing
a
library
or
when
somebody
has
a
library
and
asks
themselves,
what
could
be?
The
next
feature
that
I
implement,
there's
no
guidance
that
we
provide.
E
Maybe
we
can
provide
like
defined
levels
of
support,
defined
feature
sets
something
like
that,
something
with
a
label
on
it.
Just
saying
hey:
this
is,
I
don't
know
super
duper
confined
whatever
this
can
be
based
on
existing
profiles
and
specifications.
So
maybe
we
can
reuse
or
attach
this
somehow
to
auth
2.1.
E
Maybe
you
can
use
poppy
as
a
guideline,
something
like
that
or
we
could
just
say
within
a
very
narrow
context,
with
the
core,
oauth
plus
pixie
plus
something
else
and
just
say:
okay,
they're,
sorry
that
they're
mandatory
to
implement
features
for
a
certain
profile-
and
I
like
that-
maybe
connect
does
the
same
thing.
E
So
you
have
mandatory
to
implement
features
for
all
the
id
providers
and
you
have
mandatory
to
implement
features
for
dynamic,
open
id
providers
and
and
more
places
like
this
in
the
spec,
and
this
is
of
course,
then
the
basis
for
conformance
testing,
but
I
think,
before
conformance
testing.
Even
it
would
be
important
to
say
what
we
expect
from
a
modern,
good
and
universal
awards.
E
Library
number
two
is
to
make
metadata
mandatory
or
mandatory
in
the
sense
that
we
expect
it
from
any
modern
implementation,
because
all
of
metadata
enables
libraries
to
automatically
configure
themselves
to
figure
out
what
are
the
security
mechanisms
endpoints
and
so
on,
and
this
can
greatly
reduce
the
friction
that
you
have
in
implement
oauth,
and
I
hope
that
this
also
does
away
with
the
auth
configuration
hell,
so
that
reduces
development
time
and
costs
increase,
and
it
also
increases
the
value
in
using
libraries,
because
if
you
have
that-
and
you
can
just
throw
a
library
on
it-
there's
no
incentive
to
write
the
oauth
flow
yourself
and
yeah.
E
Hopefully,
the
libraries
can
then
also
adapt
to
just
using
automatically
some
new
or
or
security
features.
Yeah.
Therefore,
I
propose
that
this
is
becomes
mandatory
in
auth
2.1
and
also
generally,
that
we
expect
this
from
modern
fourth
implementations.
E
Then
there's
number
three:
maybe
the
elephant
in
the
room.
It
would
be
great
to
have
something
like
conformance
tests
based
upon
the
profiles
that
we
define
or
profiles
that
are
there
already.
We
or
somebody
else
could
provide
conformance
tests.
This
is
a
great
thing
of
the
openid
universe.
E
E
We
really
should
yeah,
so
there
are
many
open
questions.
Obviously,
when
we
want
to
go
in
that
direction,
that's
something
where
I
hope
to
get
input
from
you
and
yeah
where
we
need
to
think
about.
E
H
Vittorio,
so
I
have
to
apologize
for
the
huge
around
that
is
about
to
flow
from
this
microphone,
but
I've
owned
sdks
for
identity
and
developers
for
a
few
years.
So
I
have
a
very
strong
opinion
about
some
of
these
and
I'll
start
with
sheet
sandwich
with
good
things.
As
in.
I
think
that
the
the
conformance
test
is
a
fantastic
idea
would
be
interesting
to
see
what
it
looks
like,
because
off
is
so
protein.
H
Talking
about
off
libraries
is
a
bit
misleading.
Normally,
the
libraries
are
there
to
help
people
to
perform
some
kind
of
goal,
and
that
goal
is
usually
removed
from
the
protocol
level
like
when
we
operate
at
the
practical
level.
We
are
doing
something
which
is
pretty
fine-grained
and
it
doesn't
usually
map
with
the
jobs
to
be
done
like,
for
example,
people
do
sign
up
all
the
time
using
those
flows,
but
we
don't
ever
talk
about
sign
up.
H
If
there
is
intel,
but
the
library,
you
should
expect
that
a
lot
of
libraries
will
operate
at
high
level,
then
there
are
like,
when
you
say
off,
we
mean
so
many
different
things
and
in
general,
if
you
look
in
terms
of
jobs
to
be
done,
there
are
resources,
as
in
when
you
say
people
say
off.
Instead,
they
are
doing
open
idea.
That's
because
they're
trying
to
do
something
and
then
at
the
point,
the
highest
repeat,
is
signing
as
the
resource
or
the
api
versus
the
requesters.
H
Those
are
vastly
different
animals,
and
although,
when
you
do
resources,
you
can
approximate
some
of
the
things
that
you're
describing
as
soon
as
your
client.
There
are
huge
individual
differences
that
every
provider
do
which
have
a
big
impact
on
the
quality
of
life
of
a
developer.
The
microsoft
people
have
a
resource
or
refresh
tokens
that
can
be
used
with
multiple
resources.
H
Others
don't
have
that
or
they
have
a
mechanism
for
the
metadata
in
which
you
can
express
multiple
tenants,
and
there
is
a
proprietary
mechanism
for
selecting
between
votes
from
a
developer
point
of
view.
That
wants
to
get
the
job
done.
The
fact
that
this
thing
is
not
strictly
conformed
doesn't
matter
for
the
person
that
tries
to
sell
the
service,
which
is
required
for
that.
The
fact
that
it's
not
conformance
doesn't
matter
the
metadata
mandatory
stuff.
H
We
are
lucky
that
apple
decided
to
more
or
less
use
open
connect,
but
despite
we
pleaded
and
prayed
and
threatened,
they
are
not
supporting
the
discovery.
Endpoint
and
probably
there
are
strong
reasons
to
do
so
in
the
market.
People
want
to
do
something
with
apple,
so
the
fact
that
we
don't
support
it
is
it's
just
the
way
it
is
in
term
of
the
library
I
I
didn't
understand.
If
you
were
suggesting
that
we
would,
for
example,
start
the
process
of
building
libraries
ourselves
somehow
or
bless
them.
H
I
think
that
the
up
off
example
is
a
good
example
of
when
you
try
that
initiative.
It's
difficult
to
sustain
it
over
time
and
it
also
shows
an
interesting
drifting
toward
the
proprietary,
because
google
was
the
main
proponent.
But
we
still
had
a
special
flavor
of
the
library
for
the
reasons
that
I
said
earlier,
because
people
want
to
be
productive
with
google,
and
so
they
add
layers
on
top
of
it.
That
are
not
strictly
for
the
spec
and.
E
That's
it.
Thank
you
so
two
things.
So,
regarding
the
lay
the
last
point,
I
don't
think
we
should
ourselves
be
producing
libraries.
I
I
don't
think
that
will
bring
us
somewhere
so.
O
E
The
other
thing
that
you
race
and,
I
think
that's
a
very
important
point-
there's
not
always
the
one
use
case,
maybe
there's
a
use
case
where,
like
or
yeah,
there's
a
use
case
that
is
quite
common
to
many
of
the
libraries
like
a
sign-in
or
just
getting
an
access
token,
the
easy
case,
but
I
imagine
that
any
library
can
also
be
created
in
a
way
that
you
can
dig
deep,
dig
deeper.
E
So
when
I
compare
to
http
libraries,
for
example,
there's
usually
a
very
easy
way
to
send
a
get
request
and
I
get
the
response
buddy
and
that's
it
right.
Maybe
there's
a
way
to
do
the
same
with
with
a
cookie,
so
maintain
a
session
with
the
server.
When
I
say
when
I'm
sending
two
or
more
requests,
but
usually
I
can
also
say:
okay,
please
add
a
header
to
that
specific
request.
E
Please
change
the
encoding
of
that
specific
request,
or
here
I
want
to
use.
I
don't
know
I
put
some
json
into
this.
Please
handle
this
for
me,
so
I
think
there's
a
way
to
to
write
libraries
where
you
can
dig
into
all
the
details
which
you
can
then
use
to
to
send
very
specific
requests,
maybe
also
stuff
that
is
far
from
the
core
of
auth,
but
I
think
developers
shouldn't
have
to
do
that.
E
So,
just
as
an
http
library,
I
so
I'm
not
sure
when
I
last
wrote
something
where
I
sent
their
http
headers
over
a
tcp
connection
that
should
just
not
be
required
from
the
developers
so
and
in
the
same
in
the
same
spirit
manner,
users
should
not
be
forced
to
implement
http
requests
themselves,
and
just
they
shouldn't
be
thinking
about
encoding
if
they
don't
have
to
okay.
A
M
Justin
richards,
so
a
couple
of
things
here,
one
I
want
to
echo
victoria's
point
that
the
the
use
of
an
oauth
library
is
always
always
contextual
and
while
technically
you
could
also
say
that
http
use
is
also
contextual.
It's
not
contextual
in
really
the
same
way,
because
the
applications
that
you're
building
on
top
of
http
kind
of
mostly
don't
care
about
the
http
itself.
M
The
oauth
stuff
is
a
really
brilliant
abstraction
of
the
security
properties
of
apis.
But
it
is
not
a
complete
layer.
Separation
of
those
properties
and.
M
Two
direct
examples
of
this
that
that
I
think
inform
this.
I
will
start
by
saying
that
I
absolutely
hear
where
you're
coming
from,
and
I
also
wish
the
world
were
better.
I
think
that
there
are
a
few
things
that
are
stopping
the
world
from
being
better,
though
the
first
problem
is
oauth
itself.
M
So
writing,
especially
a
client
library
for
oauth
means
at
least
six
different
things,
depending
on
which
flows
you're
doing
I
for
a
while
maintained
a
a
java
implementation
of
a
client
library,
they
could
do
all
of
the
oauth
stuff
for
the
auth
code
flow
and
we
routinely
have
people
coming
in
saying
like
make
it
do
the
implicit
flow
and
we
were
like.
No,
it's
a
web
server.
M
Just
the
use
of
it
is
going
to
be
drastically
different,
depending
on
which
flows
you're
doing.
The
second
thing
is
that
ultimately
developers
really
want
to
have
they
want
to
get
to
that
end.
State
of
doing
the
thing
that
oauth
is
protecting
and
we
saw
that
well
antonio
sanso,
and
I
saw
that
when
we
were
putting
our
book
together.
Originally
a
few
is
a
few
years
ago
now,
one
we
went
out
of
our
way
to
make
sure
all
of
our
examples
were
not
provider
specific.
M
We
were
not
talking
about
google
or
facebook
or
github,
or
anything
like
that.
The
first
review
that
we
got
back
in
during
during
the
like
the
copy
review
phase
with
our
publisher.
Somebody
said
this
is
useless.
It
doesn't
tell
me
how
to
connect
to
github,
so
you
need
to
throw
out
all
of
the
examples
and
write.
How
do
I
connect
write,
a
client
to
connect
to
github?
That
would
be
a
useful
book.
This
is
garbage.
M
No,
no,
they
they.
It
actually
had
nothing
to
do
with
the
specific
specifics
of
that,
they
were
mad,
that
we
were
that
all
of
our
examples
were
not
pointing
to
github.com,
specifically
right.
It
actually
had
nothing
to
do
with
like
hands-on
implementation,
that
the
quirks
of
things
like
that
totally
a
different
thing
and
and
vittorio
covered
that.
M
But
the
the
point
of
this
here,
though,
is
that,
is
that
the
end
users
of
libraries
of
this
developers
ultimately
want
to
just
go
and
do
the
thing,
and
so,
in
my
view,
this
good
general
purpose
library
suite
that
you're
describing
the
actual
end
users
of
that
would
be
people
who
are
more
sdk
developers
than
anything
right.
This
is
the
stuff
we
would
want
to
be
included
in
a
package
that
speaks
a
protocol,
and
that
is
a
very
different
type
of
thing
to
architect.
For.
A
V
As
a
practical
matter,
for
instance,
in
the
connect
world,
because
we
have
a
certification
program,
then
we
can
host
a
list
of
certified
implementations
which
perhaps
joseph
will
speak
to
when
he
hits
the
queue.
And
so
we
have
a
quality
bar.
V
I
do
note
that
a
prominent
member
of
our
community
aaron
pirecki
out
of
the
goodness
of
his
heart
hosts
oauth.net,
which,
among
other
things,
has
oauth.net
slash
code
with
a
whole
bunch
of
implementations
on
it
and
I'll
just
ask
aaron
to
speak
to
that
and
what
is
already
happening
for
the
community.
Thank
you.
N
Yes,
this
is
santiago
from
rodriguez.
I
just
want
to
make
three
short
points.
First,
one
appreciate
this.
This
discussion
here
taking
place.
I
think
it's
not
so
usual
for
any
working
group.
Second
point
is,
I
think
issues
raised
here
are
kind
of
generic
to
some
other
itf
groups
as
well
right.
So
it's
about
a
very
general
thing
about
an
rfc
being
out
of
context
when
you
google
it
so
this
might
be
something
like
a
sidebar,
referencing,
libraries
or
whatever
kind
of
stuff.
N
Maybe
that's
versus
one
idea
and
thirdpoint
is
basically
adding
to
some
of
your
examples.
Basically,
so
I
think
there
is
one
more
point.
It
was
discussed
that
os
libraries
might
be
included
in
sdks.
Yes,
probably
point
is
it's
already
right
now
to
a
certain
extent?
N
It
also
makes
the
handling
less
generic
in
a
way,
and
there
is,
for
instance,
security
problems.
I
mean
most
of
the
security
problems
seem
to
relate
to
cross-site,
scripting
and
so
on,
but,
for
instance,
there's
also
problem
of
maintaining
os
credentials
on
the
server,
for
instance,
which
gets
much
more
problematic.
If
you
have
different
ways
of
you
know
how
libraries
read
the
secrets
and
so
on,
and
also
there
is
stuff
like
you
know
what
you,
what
what
do
we
do
about
refreshing
tokens
and
this
kind
of
stuff
yeah?
N
So
it's
operational
stuff,
you
need
to
do
logging,
that
kind
of
stuff
that
gets
also
quite
difficult.
When
you
have
you
know
multiple
libraries,
you
need
to
support,
so
maybe
it
would
be
even
nice
if
sdk
developers
would
think
about
offering
a
way
besides
what
they
have
included
by
themselves.
You
know
to
probably
get
a
token
from
a
third-party
library
included,
so
there
is
some
interoperability.
B
Peter
castleman,
microsoft.
So
I
think
a
couple
of
things
as
we've
been
looking
at
implementations.
One
of
the
challenges
that
we
see
is
that
there's
a
lot
of
mistakes
being
made
again
and
again
in
terms
of
implementation
to
mike's
point
around
the
quality
bar.
A
Thank
you
peter.
I
think
joseph.
Q
Sorry,
I
don't
think
the
prompts
pop
up
yeah,
so
I
mean
I
agree
very
strongly
with
everything
daniel
has
said-
and
I
could
talk
about
this
for
a
long
time.
There's
some
weird
stuff
out
there.
I've
seen
vendor
documentation
that
really
strongly
encourages
people
to
just
generate
one
pixie
challenge
and
code
verifier
and
to
use
that
always
I've
done
a
lot
of
work
in
open
banking.
Q
I'm
sorry,
I
forgot
to
say
my
affiliation,
I'm
either
ortholite
or
open
id
foundation,
or
both
yeah,
even
in
open
banking,
a
highly
regulated
industry
where
there's
quite
a
regulation.
That
applies
to
the
clients
securities
like
eight
or
nine
on
the
list
when
people
are
implementing
clients
and
they
just
don't
get
to
it.
Some
of
the
checks
just
don't
get
put
there.
We've
seen
that
across
multiple
ecosystems
I
mean,
I
think,
that
the
profiles
and
insisting
on
metadata
absolutely
makes
things
a
lot
easier.
Q
Fappy
insists
on
metadata
and
that's
made
such
a
difference
to
everything.
As
you
know,
I'm
heavily
some
people
know
I'm
heavily
involved
with
the
open
id
conformance
program.
That's
a
great
program,
but
getting
a
library
through
that
program
is
definitely
not
a
non-zero
effort.
It
does
require
some
determination
from
the
the
developer.
Q
So
it's
not
just
about
providing
the
tooling
there's
more
of
a
problem
here
and
I
think,
as
a
few
people
made
the
point
about
these
sdks
yeah,
a
lot
of
the
earthquakes
do
get
incorporated
into
the
sdks.
There
are
an
awful
lot
of
sdks
that
have
very
poor,
oauth
client
implementations
in
them
and
that
they
have
filtered
through
that's
one
of
the
reasons
for
the
horrendous
stats
of
our
apps.
That
daniel
showed
is
that
there's
a
lot
of
apps
that
are
all
using
the
same
sdk,
that's
very
bad.
Q
So
I
mean,
I
think
one
of
the
ways
forward
here
has
to
be
a
kind
of
collaboration,
collaborative
effort
of
all
the
authorization
server
vendors,
where
we
agree
that
this
is
a
direction
to
go,
and
we
each
individually
put
effort
into
tackling
one
piece
of
the
problem
and
making
sure
all
our
documentation
says
consistent
things
that
look
go
here,
don't
implement
protocol
from
first
principles,
because
everybody's
documentation,
like
daniel
says
it
goes
right
back
to
first
principles
and
often
doesn't
mention
libraries
even
for
the
places
that
there
are
actually
good
libraries.
Q
X
Yeah
hi
so
yeah
just
to
agree
with
what
joseph's
saying
what
daniel
saying
I
disagree
with
what
justin
was
saying
about
kind
of
there's
too
much.
You
know
different
context
and
this
needs
to
you
know-
and
this
is
just
for
maybe
sdk
authors
yeah.
Definitely
the
big
providers
who
make
sdks
if
they
can
use
these
libraries,
that's
excellent,
but
I
actually
think
this.
The
normal
thing
should
be
like
daniel
said
you
don't
re-implement
an
http
library.
Hopefully
you
don't
re-implement
a
jot
library.
If
the.
X
If
the
scope
is
restricted
enough,
you
should
be
able
to
just
use
an
or2
library.
So
I
I've
yet
to
hear
a
convincing
argument.
Why?
Why
that's
not
the
case
and
sorry
yeah,
my
affiliation
is
money
hub
and
with
our
own,
our
own
sdk
yeah.
We
just
use
phillips
library
and
it's
it's
very,
very
easy,
so
yeah
very
strongly
in
support
of
daniel's
suggestions.
E
Just
really
quick
adding
to
that
this
question
here,
maybe
there's
an
eighty
percent
use
case,
so
maybe
twenty
percent-
you
can't
cover
with
the
library-
and
maybe
that's
fine,
but
I
feel
that
there's
like
an
eighty
percent
use
case
here,
where
we
need
to
think
about.
Okay,.
Y
Yeah
I
just
wanted
to
thanks
for
teaming
me
up
for
that
mike.
Y
I
just
wanted
to
say
I'm
happy
to
do
to
put
some
more
work
into
the
oauth.net
site
code,
in
particular
to
better
highlight
the
libraries
that
are
there
right
now,
it's
pretty
much
a
list
that
I've
chopped
up
and
encouraged
people
to
contribute
to,
but
I
haven't
done
a
lot
of,
I
would
say:
maintenance
myself
on
in
terms
of
like
auditing
existing
existing
code,
and
I
do
think
one
of
the
challenges
of
that
is
that
there
well,
you
know,
there's
a
lot
of
options
available
for
any
particular
oauth
implementation.
Y
So
it's
hard
to
sort
of
say
here's,
the
stuff
that
you
have
to
do
and
here's
when
you're
done
so
I
definitely
a
conformance
test,
would
help
with
that.
But
that
is
a
whole
a
whole
topic
by
itself
but
yeah.
I
just
want
to
say
I'm
happy
to
to
take
suggestions
or
do
some
more
work
on
maintaining
that
list.
M
Super
quick
just
I
wanted
to
appreciate
that
dave
came
on
to
disagree
with
me
and
then
proceeded
to
basically
make
all
of
the
same
points
that
I
just
made,
because
really
what
I
was
talking
about
is
that,
when
we're
talking
about
these
generic
things,
the
target
of
this
is
not
the
same,
as
you
know
like
like
a
lot
of
general
libraries
you're,
building
this
to
be
embedded
into
something,
and
that
is
a
different
kind
of
architecture
and
set
of
considerations
that
you
are
evaluating
for
and
that
you're
designing
for,
and
that
was
really
the
main
point,
because
by
building
into
an
sdk
like
even
it
doesn't
have
to
be
like
a
large
provider
like
hey,
here's,
google,
here's
how
to
talk
to
google,
it's
oh
there's
an
api
that
I
need
to
talk
to,
and
I'm
going
to
build
a
module
in
my
code
that
talks
to
that
api.
M
M
I
just
don't
think
it's
quite
as
universal
as
we
would
like
it
to
be,
and
that's
the
point
I
was
trying
to
make,
not
that
this
is
a
bad
idea.
A
Thank
you,
sorry
vittorio.
We
we
need
to
move
on
daniel,
do
you
wanna
just
wrap
it
up,
and
then
we
wanna
switch
the
other
one.
Okay,.
E
Yeah
to
wrap
it
up,
I
do
have
one
more
slide,
so
thank
you
all.
I
think
this
was
a
great
discussion
and
I'm
looking
forward
to
following
up
when
I'm
eating
this
there's
a
threat
already.
So
it
would
be
great
if
you
could
put
your
ideas
into
an
email
yeah
so
that
we
can.
A
F
I'm
gonna
boot
you
off
first
and
which
one
is
this.
E
E
F
E
F
This
is
essentially
a
repetition.
E
E
Control,
so
yesterday
we
had
yesterday
in
the
depart.
Yesterday
we
had
a
discussion
in
the
info
meetings
here
at
the
itf
meeting
regarding
the
role
of
pixie
and
the
security
vcp.
E
So
yesterday
I
created
this
slide,
so
I'm
going
to
go
over
this
really
quickly.
Pixi
is
in
your
security
bcp
and
I
recommend,
or
must
in
many
cases,
and
the
reason
is
that
pixi
is
a
really
really
good
tool.
Pixi
provides
csf
protection,
so
it
can
be
used
instead
of
state
to
protect
clients
against
csf.
E
Pxe
is
also
a
protection
layer
for
authorization
codes
and
that's
the
main
reason
we
made
it
a
must
in
many
cases,
in
the
security
bcp,
with
the
alternative
of
using
the
nonce
in
some
cases,
if
you're
using
operating
connect,
there
are
essentially
two
different
attacks
that
we're
talking
about
here.
The
first
one
is
an
attacker
sees
an
authorization
response
sees
the
code
that
is
in
the
authorization
response
takes.
E
This
is
bad,
but
the
attacker
can
only
do
that
if
we
are
talking
about
a
public
client
because
with
a
public
client,
there's
no
client
authentication
at
the
token
endpoint,
okay,
so
for
confidential
clients
for
a
long
time,
the
belief
was
that
if
an
attacker
steals
the
access,
the
authorization
code
that
the
attacker
cannot
do
anything
with
that.
However,
the
attacker
can
do
what
I
call
authorization
code
injection
that
is,
the
attacker,
can
take
the
authorization
code
and,
on
his
own
device,
start
a
new
session
with
the
same
client.
E
The
client
will
then
use
that
code
on
the
attacker's
behalf
at
the
token
endpoint,
providing
the
authorization,
client
authentication
and
the
attacker
will
therefore
have
control
over
session
with
the
original
client
in
which
the
code
was
used
that
was
stolen
from
another
device
from
a
victim.
E
E
If
you
have
a
public
client,
no
client,
authentication
and
the
attacker
can
go
directly
to
the
token
endpoint,
then
only
pixie
can
prevent
this
attack,
because
the
attacker
would
have
to
write
a
code
verifier,
which
you
cannot
know.
E
Therefore,
we
created
a
nice
table
or
aaron
created
a
nice
table.
Thank
you,
aaron,
showing
what
you
see
here,
not
going
through
all
the
details
here.
The
thing
is
csf
can
be
parented
by
both
pixie
and
nonce.
That's
fine!
But
if
you
have
a
public
client
that
use
a
response
type
code,
then
only
pixie
can
provide
protection
if
the
code
is
stolen.
E
Therefore
we
say
in
the
security
bcp
that
for
public
clients,
pxe
is
a
must,
because
it's
the
only
layer
of
defense
that
we
have
in
case
the
code
gets
though
okay
and
yesterday
we
agreed
that
we
keep
this
in
the.
So
this
is
the
wording
not
going
through
all
the
details,
but
that
we
essentially
want
to
keep
this
wording
that
we
have
in
this
security
bcp.
That's
not
the
slide
next
one
hello,
it's
this
little
slide
set.
I
think
maybe.
E
So
we
agreed
to
essentially
keep
the
wording.
What
we'll
be
doing
is
we
are
going
to
explain
what
I
just
explained
and
what?
What
is
on
the
slides
better
in
the
security
vcp,
because
it
took
us
a
while
to
figure
out
why
we
why
we
wrote
this
in
the
security
recipe?
That's
not
a
good
sign,
yeah
and
also
some
changes
on
the
wording
in
the
details,
because
the
attack
is
not
described
at
the
right
place.
Mike
mike
has
a
comment
on
this.
V
V
I
believe
there
are
cases
where
you're
correct
that
code
injection
is
not
prevented.
I
have
thought
about
some
of
the
openid
connect
flows
such
as
id
token
token,
where
you
send
a
nonce.
You
get
back
an
id
token
in
the
front
channel.
You
get
back
the
code
in
the
front
channel
and
the
token
and
you
use,
are
you
yeah?
They
said
id
token
token.
V
And
also
id
token
code.
Yes,
I
said
the
wrong
thing:
if
you're
using
id
token
code,
you
get
the
id
token
with
the
non-senate
to
check
you
have
a
c
hash
in
it
to
check,
and
so
the
attack
is
prevented,
not
for
the
code
flow,
and
I
agree
with
you
and
I'll.
V
Just
repeat
for
the
minutes
here
I
am
volunteering
to
work
with
daniel
and
the
other
authors
on
language
trying
to
help
developers
understand
exactly
when
this
is
essential
and
when
there's
other
mitigations,
I'm
not
changing
the
basic
conclusion,
but
like
much
of
this,
it's
subtle
and
it
depends
upon
when
you're
getting
the
cryptographic
hashes
of
the
things.
E
V
Y
I
just
I
just
wanted
to
say
that
to
mike's
point:
there
are
two
different
attacks
being
talked
about
here,
so
the
code
injection
is
the
attack
that
is
prevented
by
the
c
hash,
but
stealing
a
code
and
using
at
the
token
endpoint
is
not
prevented
by
the
c
hash.
Because
that's,
I
think
that
the
client
is
using
to
protect
itself.