►
From YouTube: IETF100-OAUTH-20171115-1520
Description
OAUTH meeting session at IETF100
2017/11/15 1520
https://datatracker.ietf.org/meeting/100/proceedings/
A
B
Hi
everybody,
my
name,
is
los
loros
dead
working
with
yes,
calm
I've
got
a
pleasure
to
all
over
the
security
topics,
draft
together
with
Andre
lab
and
Ed
from
Facebook
and
John.
Bradley
I
would
like
to
talk
about
the
current
status
of
this
draft,
but
let
me
start
with
the
objective,
so
why
did
we
start
to
work
on
this
draft
just
to
recapture?
B
There
are
three
main
reasons.
First
of
all,
since
we
published
ooofff,
and
that
means
RFC,
67,
49
and
15.
All
of
us
gotten
a
massive
traction
and
what
we
have
seen
in
the
market
is
that
people
just
don't
get
it
right
sometimes.
So
there
are
some
issues
out
there
that
we
never
thought
about
that.
There
are
some
things
in
the
spec
that
are
not
precise
enough,
or
at
least
not
actionable
enough
for
a
rich
developer
and
I
wouldn't
blame
the
development
for
that.
B
So
I
think
it's
our
task
to
to
be
more
clear
and
to
come
up
with
recommendations,
how
to
do
it
right
and
how
to
do
is
secure.
Secondly,
the
original
trust
model
of
oo-ahh
for
the
regional
way-o
of
was
used
was
rather
simple.
There
was
a
service
provider
with
a
API
and
an
O
of
server
and
a
lonely
developer
that
developed
an
application
toe
boards
is
API
and
the
particular
authorization
server.
So
everything
everything
had
set
up.
B
B
Development
time
so
now
things
change.
There
are
communities
publishing
api's,
there
are
communities
in
the
financial
area
or
in
the
mobile
network
operations
area
that
build
whole
ecosystems
based
on
off
and
open
ID
connect,
and
in
this
situation
the
trust
relationship
is
established
dynamically
and
we
have
to
cope
with
these
situations
as
well
and
third,
all
of
is
used
all
over
the
place
and
also
in
areas
which
are
much
more
security
sensitive
than
we
thought
about
previously,
for
example
in
the
financial
industry,
for
health
data
and
a
lot
of
other
cases.
B
B
So
the
structure
of
the
document
is
as
follows:
there
is
a
readable
number
threat,
analysis
and
discussion
of
the
different
countermeasures
and,
as
you
can
see,
there
is
a
variety
of
different
of
different
attacks,
angles
that
we
that
we
cover
in
the
document.
B
We
had
a
discussion
in
Prague
about
exactly
on
this
access
to
leakage
thing
we
discussed
all
the
different
countermeasures
that
were
available
and
also
came
up
with
an
kind
of
assessment
okay,
so
this
is
more
or
less
that's,
that's!
That's
where
we
a
document
the
results
of
our
work.
Basically,
and
then
we
we
distill
recommendations
and
those
are
intended
to
be
actionable
for
the
average
developer
next
slide.
Please.
B
Sorry,
no
problem,
that's
the
that's
the
full
list
of
recommendations
that
we
have
put
into
the
document
so
far.
I
just
want
to
briefly
go
through
it.
Just
to
make
you
aware
of
what
we
are
gonna
recommend.
The
first
of
all
there's
been
a
long
discussion
about
redirect
UI
validation
at
the
resource.
They
are
authorization
server
and,
in
our
opinion,
are
the
only
reasonable
way
forward
is
to
to
to
recommend
to
use
exact
your
I
redirect
matching,
because
that's
that's
that's
one
of
the
easiest
to
implement
countermeasures
against
token
leakage
and
also
mix-up.
B
But
it's
it's
it's
an
incredible
over
a
protection
concept.
Open
redirection,
I
think
it's
it's
straightforward.
Access
for
F
I
mean
it's
already
there
and
our
C
67
49,
but
it's
not
as
precise
and
specific.
We
make
it
more
specific
and
say:
please
use
X
or
F.
One
time
used
tokens
in
the
state
parameters
period.
B
A
specific
redirect,
URIs
use
of
that
had
already
been
documented
in
the
in
the
respective
draft
by
Mike.
I.
Think
one
potentially
very
interesting,
interesting
recommendation
is
we.
We
did
a
lot
of
analysis
around
code
injection
and
there
are
different
countermeasures
available,
ranging
from
concepts
in
the
open,
ID
Connect
space
like
nuns
or
the
hybrid
pro
and
others.
But
in
the
end
we
wanted
to
come
up
recommendation
that
is
implementable
on
top
of
OAuth
and
does
not
require
open,
ID
Connect.
B
That's
why
we
recommend
to
use
pixie
for
that
purpose,
which
might
sound
a
bit
surprisingly
on
first
side,
but
in
the
end,
what
pixie
gives
us
is
a
nuns
that
helps
the
client
on
a
s
to
tie
together
the
whole
transaction
following
the
redirect
and
the
interaction
with
the
token
end
point
so
I
think
that
that's
that's
why
we
think
using
pixie
or
for
that
purpose
is,
is
a
very
reasonable
way
forward,
based
on
the
discussions
in
Prague
and
also
on
the
security,
our
workshop
in
Zurich,
and
also
the
feedback,
especially
in
Prague,
we
decided
to
recommend,
as
a
best
practice,
to
to
implementers
to
use
TLS
based
sender,
constraint,
access,
token
methods
over
all
the
ins
restriction
or
other
other
methods
for
for
pop
tokens.
B
B
D
D
B
Okay,
we
published
two
versions
since
prac,
and
the
most
significant
change
was
that
we
added
added
to
the
text
around
token
leakage
at
the
resource
server
I
already
talked
about
when
we
did
so.
We
discuss
extensively
the
use
of
more
metadata
to
to
prevent
that
threat.
Also,
all
the
answers
diction
is
being
discussed
and
the
different
mechanisms
that
exist
today
for
central
constraints,
access
tokens
and
we
restructured
the
BCP
in
order
to
improve
the
readability
of
the
whole
arm
specification.
B
The
most
important
point
for
my
perspective
and
that's
why
I
really
try
to
to
talk
you
through
the
whole,
the
whole
document
and
how
its
kind
of
organized
and
and
what
the
objective
is.
Please
review
the
document
to
give
us
feedback.
We
need
your
contributions
right
so
far,
I
think
three
or
four
working
group
members
have
actively
given
as
feedback,
but
I
think
this
is
essential
for
somehow
coming
up
with
a
BCP,
a
best
current
practice
document
that
you
can
put
developers
in
their
hands
to
implement
off
correctly
yeah.
That's
it
thank.
F
G
F
Here's
what
you
can
expect
if
you're
the
problems
that
you're
sort
of
you
space
now
they
can
go.
They
can
go
to
the
mutual
TLS
document
and
read
some
of
that,
but
that
when
I
saw
the
original
title
going
back
to
the
very
first
slide,
it's
security
topics
right
where
the
document
is
absolutely
dominated
by
threats
and
mitigations
I
mean
90%
of
the
document.
Is
that
so
I
have
two
comments
or
two
suggestions,
and
maybe
this
is
a
question
for
the
working
group
chairs
as
well.
F
Is
that
if
we
go
ahead
and
take
this
document,
push
it
through
last
call
and
publish
it
all
right?
What
happens
when
a
workshop
next
year
or
the
year
after
finds
other
vulnerabilities?
Are
we
in
a
position
where
we
have
to
keep
revising
the
document?
Not
that
that's
a
bad
thing,
but
that's
a
an
onerous
task
for
a
working
group,
I
think
over
time.
You
wouldn't
want
to
keep
this
as
just
an
internet
draft.
F
I
think
one
of
the
things
that
needs
to
be
thought
about
here
is
thinking
about
the
audience,
and
one
of
the
suggestions
might
be
is
to
separate
the
threats
and
mitigations
part
of
it
into
a
separate
document
that
then
easily
revisable
and
the
other
security
topics
perhaps
add
to
those
security
topics,
particular
particular
features
of
ways
that
we've
extended
OAuth
right
and
what
what
their
features
are.
So
that's
a
want
to
start
by
saying
I
think
this
is
outstanding.
Work!
F
B
Thank
you
some
thoughts
from
from
my
side,
yeah
right
now,
it's
a
working
document
for
for
the
working
group,
so
the
intention
is
to
serve
as
a
working
document
for
the
working
group
in
the
end.
I
fully
agree
with
you.
We
should
somehow
split
that
because
in
the
end,
the
recommendations
are
that,
what's
what
suited
for
the
for
the
average
developer,
we
had
a
lot.
We
had
several
discussions
about
that
and
we
decided
to
first
of
all
go
with
this
single
document,
but
the
question
is
absolutely
correct.
H
So
one
of
the
aspects
is
and
I
believe
this
is
a
discussion
that
actually
concerned.
The
number
of
the
documents
is:
if
we
have
this
issue
of,
how
do
we
make
sure
that
when
we
update
the
documents,
we
actually
then
keep
track
of
the
latest
date
or
data
involving
documents?
A
little
bit
like
that,
we
had
that
debate
in
the
native
apps
documents
as
well,
because
things
are
changing,
operating
systems
are
changing
and
the
same
is
here
and
like
threads
change.
H
The
priorities
are
changed
so
in
what
we
found
out
is
that
this
whole
pcp
idea
is
actually
pretty
good,
because
we
can
still
refer
in
other
documents
and
and
in
other
publications
as
to
a
PCB
but
keep
updating
the
RFC.
So
every
time
you
you
don't
need
to
externally,
don't
need
to
update
your
references
either.
It
always
points
to
the
latest
version
of
the
document
and
I
think
that
in
ensure
some
consistency
and
durability,
if
you
will,
of
course
it
still
requires
us
to
actually
produce
text
from
time
to
time.
H
But
my
hope
is
that
once
we
so
we
produce
the
initial
strength
document
and
a
while
ago,
and
then
we
piled
on
threats
afterwards.
So
maybe
the
time
frame
between
the
publication
of
the
initial
document-
and
this
one
was
maybe
a
little
bit
too
long,
but
it
doesn't
need
to
be
honor,
let's
say
a
yearly
cyclic
eater.
So
hopefully
we
are
not
going
to
see
a
tremendous
amount
of
attacks
every
year.
D
H
I
I
J
H
F
So
I'll
just
follow
up
an
answer
to
your
question.
I
think
it
is
a
BCP
is
a
good
model,
certainly
better.
For
instance,
DNS
op
has
a
terminology
draft
right
that
they
leave
an
internet
draft
status,
oh
and
they
revised
it
over
and
over
and
over
again,
that's
not
a
very
effective
model,
because
no
one
can
see
it's
very
hard
to
find
that
document.
H
Yeah,
that's
a
good
point
and
obviously
keeping
the
target
audience
of
a
document
in
mind
is
crucially
important.
We
had
this
Owens
thought
net
website
to
actually
reach
out
to
a
different
type
of
community
and
more
the
guys
who
typically
may
not
read
the
RFC's.
So
that's
why
we
wrote
separate
blog
posts
in
a
very
simplistic
way,
in
some
sense
who.
H
H
I
would
make
a
difference
between
the
person
who
actually
writes
and
an
identity
management,
server
authorization
server
from
the
person
who
actually
just
uses
it.
I
can
download
quartz
rock
and
configure
it's
still
a
hard
with
my
own
OS
implementation.
I
think
this
makes
a
huge
difference
for
you
I'm
a
son.
It
may
not
make
a
difference
because
you're
big
shop,
you
write
everything
on
your
own
I.
D
D
Why
should
I
do
that
and
then
there's
links
to
why
later
in
the
documents
of
they
don't
think
well,
I
know
better
that
the
backing
and
the
threat-
and
they
really
understand
why
you're
doing
in
a
certain
way,
I
think
that's
very
important
in
security
things,
it's
supposed
to
say,
here's
how
to
do
it
and
in
people
like
well,
okay
and
they
wiggle
around,
but
they
don't
really
understand
why
and
having
the.
Why
I
think
is
super
valuable
and
once
again
kudos
for
a
great
job
doing
this.
Thank.
B
D
B
K
Brian
Campbell
from
ping
it's
nice
to
meet
you
Torsten,
a
couple
things
that
I
appreciate
the
doc
I
think
it's
it's
really
good.
I
did
have
one
sort
of
meta
comment
as
I
was
reading
through
it,
you
discuss
in
some
places
a
variety
of
different
techniques
that
could
be
used
to
mitigate
something
and
I.
Think
for
someone.
K
That's
not
intimately
familiar
with
some
of
the
history
of
what
goes
on
in
this
group
that
it
could
be
a
little
bit
potentially
confusing
and
I
think
it
might
be
helpful
to
clearly
delineate
between
things
that
are
sort
of
have
been
discussed
as
options,
but
aren't
necessarily
viable
solutions
versus
the
recommended
approach
and
there's
a
few.
Those
I
can
think
of
two
offhand.
One
would
be
audience
restricting
access
tokens
conceptually.
It
works,
there's
not
a
great
way
to
do
it.
K
B
K
Qualified
because
a
client
couldn't
send
the
odd
parameter
and
expect
to
receive
a
audience
bound
token,
because
it's
not
it's
not
standard.
Similarly,
with
with
the
mix-up
mitigation,
there's
that
draft
out
there
that
we
sort
of
abandon
that
has
recommends
issuer
and
and
but
a
client
couldn't
depend
on
that,
because
it's
not
standard
is
not
out
there.
It's
useful
for
discussion,
but
I
think
saying
you
know
a
little
qualification
around.
That
would
be
useful.
Yeah.
E
B
Think
I
think
that's
fine,
that's
fine!
It
did
the
reason
why
we
don't
have
the
read
that
clear
recommendation
in
the
main
and
the
main
body
if
the
document
is
because
we
didn't
have
the
recommendation
section
earlier,
so
we
just
have
this.
Oh,
let's,
let's
first
gather
everything
together
and
have
a
discussion
and
then
we
decide.
Oh,
we
need
this
recommendation
section.
So,
in
the
end,
it's
more
for
historical
reasons
that
we
do
not
really
clearly
speak
out.
What
okay
and
we
haven't
had
to
good
enough
discussion,
a
working
group
for
some
of
those
topics.
K
Just
wanted
to
say,
I
follow
all
your
reasoning
and
I
actually
agree
with
the
reasoning
behind
dropping
the
redirect
URI
sent
to
the
token
endpoint
and
why
it
doesn't
work
well
in
practice.
But
I
am
less
keen
on
actually
changing
the
underlying
protocol.
Cuz
I
think
there's
just
because
the
reasoning
sound,
there's
ramifications
of
actually
doing
that
reven
or
updating
the
core
document
and
then
trying
to
gauge.
B
K
K
L
As
one
of
the
co-authors,
we
agree
with
Torsten
that
you
know
this
was
originally
a
bunch
of
different
documents,
a
bunch
of
different
ideas,
and
we
tried
to
pull
all
of
the
options
together
so
that
the
workgroup
could
make
decisions.
Now
us
not
making
arbitrary
decisions
on
behalf
of
the
work
group
was
actually
perhaps
difficult
for
us.
L
So
we've
we've
made
recommendations,
but
it's
still
up
to
the
workgroup
to
decide
which
of
those
recommendations
to
to
actually
follow
up
on,
and
at
that
point
we
can
say
yes,
reconstitute
Brian's
expired
draft
or
do
this
or
that
so
that
we
can
actually
make
final
concrete
recommendations.
So
the
recommendations
aren't
meant
is
we've
decided.
The
working
group
must
do
this.
This
is
what
we
think
is
the
best
way
forward,
but
the
work
work
still
has
to
make
the
decision
so.
H
I
guess
maybe
it
would
be
good
to
take
what,
if
you
guys
could
tell
us
when
it
would
be
a
good
time
to
do
sort
of
a
consensus
on
some
of
the
recommendations,
because
the
problem
that
we
had
back
then
was
that
many
of
the
issues
were
not
naturally
orthogonal
to
each
other.
So
you
couldn't
make
a
decision
on
one
thing,
because
they
were
also
in
the
dependencies.
So
yeah.
H
B
H
B
H
D
Okay,
how's
that
okay
I'm,
showing
the
pink
square
I,
think
it's
been
about
eight
years
since
I've
stood
in
the
pink
square
last
time.
I
was
up
here.
I
got
a
lot
of
arrows
in
me,
so
hopefully
that
doesn't
happen
this
time
next
slide
so
mutual.
Oh,
this
is
a
problem
that
we've
encountered.
I
work,
hard,
I
work
in
Amazon,
one
of
the
groups
I
work
heavily
with
is
Alexa.
D
One
of
those
Nero's
we
have
is
there's
two
different
parties.
One
of
the
parties
that
is
public
is
you
know
the
Alexa,
and
so
knows
we
want
to
enable
the
user
to
authorize
each
of
those
parties
to
call
the
other
one
and
so
in
the
document,
I
call
them
party
a
and
party
B,
since
both
party,
a
and
party
B,
are
both
clients,
authorization,
servers
and
protected
resources.
D
Does
anyone
have
questions
about
what
the
problem
is?
Is
this
pretty
clear?
Okay,
so
I'm
just
walked
through
the
current
flow
around
what
we
have
to
do
today.
Essentially,
we
have
to
go
through
to
full
o
auth
flows,
which
is
even
clunkier
than
just
two
different
flows,
because
your
end
up
in
the
wrong
place
after
the
first
flow.
So
you
have
to
go
bounce
over
and
stuff
like
that.
D
We
find
if
you've
got
an
Alexa
device
used
to
also
knows
it
seems
like
it's
probably
a
50
step
process
to
get
it
up
and
running
by
the
time
you're
done
so
in
the
first
flow
year.
Since
you
go
through
click,
the
ad
Sonos
go
to
Sonos,
you
authenticate,
you
authorize
Alexa
bill,
you
so
knows
the
user
gets
back,
sent
back
over
to
Alexa
behind
the
scenes.
D
Alexa
goes
and
gets
its
its
access
token
and
then
Alexa
then
redirects
over
to
Sonos
to
get
the
thing
kicked
off
again,
go
to
the
next
slide
and
then
sono
redirects
back
over
to
login,
with
Amazon
for
the
user
to
login,
which
is
confusing
because
yeah
well,
your
own,
like.
Why
am
I
login
with
Amazon
I
was
already
in
Amazon
but
of
course,
there's
no
active
web
session,
and
so
then
user
authenticates
at
Amazon
and
then
authorizes
so
knows
that
Amazon
music,
it's
right
check
back
to
Sonos,
selects
Oscillation
code.
D
We
exchanges
it
and
then,
at
the
end
the
user
gets
redirected
back
over
to
Amazon.
So,
as
you
can
see,
this
is
a
fairly
cumbersome
process,
so
the
flow
that
we
recommend,
essentially
you
go
through
the
first
flow
and
when
you're
done,
because
we
already
have
the
context
of
the
user,
both
in
Alexa
and
Amazon
is
Alexa
calls
a
Sonos
endpoint,
sometimes
I
get
these
backwards
in
my
head.
I
think
this
is
right.
Calls
the
Sonos
endpoint
with
the
access
token
that
they
got
from
so
know
so
Sonos
knows
the
context.
N
N
D
E
D
D
D
Now
we
need
Sonos
to
be
able
to
get
an
access
token
to
call
Alexa
and
so
Alexa
calls
Sonos
with
Alexis
authorization
code
right
and
then
Sonos
calls
back
up
to
Alexa
with
that
authorization,
code,
ins,
client,
ID
and
secret
to
exchange
it
for
an
access
token,
which
then
lets
it
so
knows
have
an
access
token
for
Alexa.
So.
E
E
D
D
The
scope
had
to
be
predestined
beforehand,
but
since
you
know
the
transaction
you're
in
you
would
know
that
in
this
particular
handshake,
I
know
what
scope
you're
going
to
get
so
you've
skipped
all
the
steps
that
came
up
to
getting
the
authorization
code,
you're
passing
that
back
channel
in
set
a
front
channel
and
then
so
that's
the
different
part,
and
then,
after
that,
so
nose
just
operates
the
way
they
before
I've
exchanged
that
authorization
code
for
an
access.
Token.
Refresh
token.
P
D
So
one
the
second,
the
first
one
of
course
happens
when
you
bounce
over.
To
so
knows,
and
someone
is
this,
granting
access,
you
could
do
it
either
what
either
before
you
even
start
bouncing
over
to
Sonos
or
you
could
do
it
after
you
get
back
because
you're
in
the
Amazon
context,
and-
and
so
it's
you
know,
you're
on
Alexa,
so
at
some
point
in
there,
Alexa
connects
ask
for
that
consent,
but
you
make
a
good
point.
I
should
highlight
that
it
should
happen,
but
it
could
happen
at
either
time
when.
L
L
D
Thought
a
little
bit
about
that.
We
went
with
this
flow
because
you
got
a
lot
of
the
you
minimize,
the
change
and
so
the
whole
granting
of
the
access
token
is
the
same
process:
okay,
right
and
so
right
you,
your
Sonos,
is
enabled
to
go
and
get
a
access
token
the
same
way
because
there
may
be
other.
The
reverse
flow
happens
as
well
right
where
you're
starting
in-
and
you
start.
D
L
D
Recall
security
work
there
may
have
been
something:
okay,
I'm,
always
a
little
squeamish
I'm,
just
randomly
handing
out
access
tokens
well
yeah,
so
that
just
didn't
feel
good
and
I.
L
D
Yawning
on
my
answer
to
your
question:
okay:
I
think
that's.
So
the
question
would
be:
is
this
something
that
the
working
groups
interested
in
I
turn
it
over
the
chairs
to
see
whether
yeah,
whether
there's
interest
in
that
and
if
I,
don't
you
know,
look
I
doubt
if
anyone's
had
a
time
to
read
the
draft,
so
I
don't
know.
H
R
R
T
H
K
H
Well,
I
think
in
before
you
answer,
I
think
my
question
was
more
about.
Do
we
want
to
have
a
description
of
that
problem,
and
so
people
know
how
do
there
may
be
multiple
different
ways
of
sorting
it
and
obviously,
as
you
can
judge
from
these
details,
there's
obviously
a
lot
of
work
to
do
and
also
you
are
document.
D
K
D
H
D
Distributed
there's
something
called
distributed
already,
but
my
my
putting
the
stake
in
on
that
word
to
begin
with
this
one's
a
little
more
complicated
last
one
last
one
wasn't
as
complicated.
So
as
there's
a
couple
of
things,
I'm
working
on
where
it's
much
more
distributed
the
whole
system,
and
so
in
the
original
oweth
it
was
very
it
was.
There
was
an
authorization
server,
it
had,
maybe
one
or
maybe
a
few
resource
servers,
and
you
know
there
was
the
client
and
it
was
a
fairly
closed.
D
You
know
you
were
going
to
flick
her
to
go
and
get
photos,
and
so
you
knew
who
the
authorization
server
and
the
resource
and
those
things
were
fairly
related,
that
separating
the
authorization
server
for
the
resource.
Server
was
a
good
architectural
approach,
and
now
people
have
been
taking
advantage
of
that
and
the
seperation
is
you
come
even
more
acute
in
a
number
of
situations
where
the
same
client
maybe
may
have
similar
resources,
but
have
different
authorization
servers,
because
those
resources
are
in
different
geopolitical
or
different
security
rounds.
D
But
the
client
has
access
across
all
of
those,
and
so
you
just
start
to
scale
up
and
have
a
more
distributed
system.
It
becomes
brittle
where
you
know
you
don't
have
this
once
we
had
a
great
word.
You
know
a
priori
knowledge
of.
Where
is
the
a
s
by
the
client
that
the
client
doesn't
know
where
that
is,
and
if
it
does
know
where
it
is,
then
you
can't
change
it
because
you
got
thousands
of
clients
deployed
that
are
using
that
and
so
in
a
big
distributed
system.
D
It's
advantageous
at
times
to
make
a
change
and
so
having
a
discovery
process
for
the
client
learns
where
the
a
is
is
for
a
given
protected
resource
and
that
a
s
could
change,
provides
a
lot
more
flexibility
in
distributed
system
and
so
really
what
we're
trying
that's
the
problem
and
so
that
what
we're
trying
to
do
is
how
do
we
enable
discovery
of
the
a
s
and
as
soon
as
you
do
discovery
of
a
s
and
you
get
a
bunch
of
threats,
so
first
we'll
go.
How
do
we
solve
it?
D
I
think
my
next
slide
here
shows
you
know
kind
of
a
picture
to
give
an
idea
around
sort
of
the
problem.
So
it
was
a
bunch
of
geopolitical
domains.
Each
of
them
has
their
own
authorization
server
and
you
got
a
couple
resources
in
it,
but
that
one
client
wants
to
talk
across
all
of
those,
and
so
it
needs
to
go
and
get
access
tokens
across
all
of
those.
You
know
you
don't
want
the
access
tokens
that
one
to
be
able
to
be
used
at
another
one.
D
So
you
don't
want
the
s3
server
and
China
to
be
able
to
call
the
s3
server
in
the
US
or
you,
for
example.
Anybody
have
questions,
aren't
I
just
want
to
make
sure
everyone
understands
the
problem.
We're
trying
to
solve.
You
understand
the
problem.
Tony
Tony.
Are
you
still
having
breakfast
with
me
tomorrow?.
N
D
So
the
proposed
solution
is
the
plant
discovers
the
authorization
server
as
it
hits
the
authorized
hits
the
resource
and
in
the
401
response
it's
told.
Where
does
it?
You
know,
there's
an
issuer
in
that
response,
as
described
here
next
slide,
so
there's
a
number
of
threats
that
come
up
as
soon
as
you
do
this
that
you
know
people
have
talked
about
a
few
times
and
I'm
keen
to
learn
if
there's
threats
that
we
haven't
thought
of
and
how
could
we
could
mitigate
and
making
sure
that
we
have
mitigated
all
the
threats?
D
D
The
next
one
is,
you
could
ping
a
resource
server
and
you
could
send
information
essentially
for
a
different
resource
server,
and
then
you
use
the
access
token
at
that
first
resource
server,
but
that
resource
server
then
can
go
and
use
it
at
the
resource
server
it's
impersonating.
So
we
want
to
mitigate
that
and
then
the
third
is
you
know.
D
D
The
resource
server
can't
make
up
some
other
statement
as
to
which
post
it
is,
and
so
the
host
that
you
get
from
a
TLS
is
saved
in
from
calling
the
resource
server
and
used
when
you
call
the
authorization
server
and
then
that
host
is
put
into
the
access
token
and
then,
when
you're,
presenting
that
access
token
to
the
resource
server.
The
resource
server
checks
to
make
sure
that
it's
an
access
token
for
yet
essentially
audience
restriction.
But
that's
how
we
get
the
signal
for
audience.
I.
L
H
L
H
D
L
Phil
objected
and
was
there
was
generally
angry
words
about
resource
metadata
and
how
how
the
problem
should
be
solved.
Brian
and
I
proposed
that
there
was
another
proposal
from
Phil
and
Tony
about
trying
to
get
discovery
to
do
it
and
the
work
group
decided
effectively
wound
up
doing
nothing
at
the
time.
L
Hi
Justin
so
in
any
case
a
couple
of
things
here,
one
obviously
you
could
have
multiple
resources
at
a
given
host,
so
this
may
not
be
the
right
granularity
for
certain
setups.
You
know
shared
server
hosting
things
like
that.
You
could
also
have
resources
that
bounce
around
with
you
know,
dynamic,
DNS
and
all
this
other
fun
stuff
so
but
I
think
going
to
a
going
to
a
slightly
different
layer
and
because
John
brought
up
using
discovery
at
the
resource
in
order
to
start
discovering
stuff.
L
Once
you
start
doing
discovery
at
the
resource
server,
you
start
running
smack
into
some
very
real
privacy
issues
in
your
design.
It
doesn't
come
up
as
much
at
something
the
scale
of
Amazon,
but
if
you
take
the
same
concept
and
scale
it
down
to
a
personal
authorization,
server
and
personal,
you
know
resources
that
you
may
be
protecting.
You
go
talk
to
a
random
server
on
the
web
and
it's
not
going
to
give
you
the
data.
It's
not
gonna.
Tell
you
who
it's
about,
but
it's
gonna
tell
you.
I
am
John,
go
talk
to
John
Bradley's.
L
You
know
personal
use
authorization
server
to
get
information
about
whose
server
this
is.
Oh,
you
just
kind
of
leaked
a
whole
lot
of
information
about
that,
and
this
is
particularly
sensitive
if
you're
looking
at
things
like
personal
medical
records
and
data
stores
for
things
like
that
as
well.
So
if
things
do
go
in
that
direction,
with
resource
based
discovery,
even
just
handing
back,
the
issuer
could
be
very
sensitive
agree.
D
There's
you
are
handing
out
information
about
the
resources
sharing
information
about
itself
and
you
want
to
make
sure
the
resource
can't
impersonate
that
information
and
potentially
in
the
draft
we'd
call
out
call
out
that
privacy
issue
so
that
people
don't
use
it
in
a
way
where
they're
leaking
stuff
without
realizing
they're
leaking.
Yet,
okay,
yeah
yeah
yeah.
It's
not
a
solution
for
everything
in
solution
for
ones
where
this
essentially
is
public
data.
Yeah.
C
A
camera
and
all
right,
just
like
those
dr.
john
surratt,
does
expect
this
expired
raft
call
off
matter
as
well.
It's
actually
tackling
same
exactly
same
kind
of
thing.
The
solutions
was
very
similar
and
you
know
just
the
fact
that
something
like
this
is
coming
up.
Multiple
time,
I
think
it's
the
kind
of
problem
that
working
group
probably
won't
work
on
Michael.
L
G
L
C
B
Is
awesome?
Can
you
go
to
the
next
slide?
Please.
Next,
one
yeah
I,
like
the
concept
of
audience
restriction,
I'm
a
big
fan
of
audience
instructions,
as
Anabella
pointed
out
in
Prague.
If
you
go
for
audience
restricted,
also,
access
tokens
means
means
we
need
to
extend
the
protocol
and
clients
need
to
be
aware
of
that.
They
need
to
ask
for
different
access
tokens
for
different
resource
servers.
B
So
far
is
one
of
the
of
the
reasons
why
we
recommend
send
the
constraint
access
tokens
in
the
security
BCP
yeah.
We
have
worked
on
an
extensive
document
regarding
audience,
restriction,
discovery
and
stuff.
We
haven't
chatted
with
the
working
group
so
far,
so
we
can
do
that,
but
there
there's
a
lot
there's
a
lot
of
work
to
do.
I
would
be
very,
very
happy
to
contribute
that
work
and
I
really
like
that
idea.
Yeah.
D
I
didn't
call
that
out,
but
yeah
we
are,
you
are
well
I,
say
it
at
the
bottom
right.
An
implication
of
this
is
it
requires
an
access
token
for
each
protected
resource
and
so
the
clients
managing
that
which
our
clients
managing
if
they
had
a
bunch
of
different
authorization,
servers
and
access
tokens
right.
If,
if
you
have
a
client,
that's
calling
Google,
Flickr
and
Facebook,
it's
got
an
access
token
for
each
one
of
those
and
as
a
separate
AAS.
What
this
enables
is
a
potentially
the
same
as
maybe
issuing
the
same
access
tokens
here.
B
Is
true-
and
it's
very,
very
well
Metris,
with
all
this
on
token,
pointing
stuff
and
so
on?
We
have
done
that
for
years
at
Deutsche
Telekom,
but
the
client
needs
to
know
how
to
ask
for
different
access
tokens.
We
did
it
with
different
scope,
values
right.
So
this
is
a
different
or
a
profile
of
OAuth
that
we
use
to
distinguish
the
difference
also,
so
we
have
to
agree
on
a
way
on
the
way
to
do
it.
Yes,.
D
L
V
D
The
problem
we're
solving
here
is
a
subset
of
that.
Okay
and
the
challenge
would
be
is
like
we
didn't
need
most
of
all
of
that,
and
so
we
didn't
see
that
as
being
a
solution,
but
I
want
to
make
sure.
We
also
take
lessons
from
that
and
if
it's
possible
to
just
reuse
it
possible,
but
when
I
sort
of
looked
at
an
older
thing
and
when
I
talked
to
people
at
iw
about
it,
it
seemed
like
there
was
an
awful
lot
more
stuff
in
the
Raymond
I
have.
L
D
I
didn't
read
the
doc
but
whose
AOL
guy
George.
L
C
L
K
Wanted
to
reiterate
that,
comparing
this
to
other
graphs
that
are
very
similar
previously,
one
of
the
difficulties
we
had
was
defining
the
granularity
of
the
protected
resource
and
you've
kind
of
taken
the
easy
way
out
going
with
host,
which
is
maybe
okay.
But
everyone
seemed
to
have
a
different
opinion
on
how
granular
that
had
to
be
previously,
and
that
may
well
need
to
be
looked
at.
It.
K
K
I'm
resentful,
if
you
get
oh,
if
you
get
to
do
something
simple,
where
I
was
that's,
it
may
come
up,
I,
don't
know
it
just,
but
it's
it's
a
it's
a
specifics.
It's
saying
that
a
resource
server
audiences
is
at
the
host
level
period
and
that
that
may
or
may
not
be
okay
with
folks.
I
did
actually
try
to
read
the
draft.
It
reads
as
though
it's
specifically,
and
only
for
the
client
credentials
grant
type,
is
that,
but
then
you
haven't
talked
about
it
here
in
the
slides.
D
Yes,
we
I
think
this
problem
Maps
well
for
two
legged
solutions,
because
many
of
the
things
you're
trying
to
do
are
very
where
the
distributed
natures
come
up
as
two-legged
like
you
know,
because
soon,
as
you
have
a
user
involved
that
you
know,
the
flows
are
radically
different
than
you
know
what
the
authorization
server
I.
That's
it's
it's
quite
a
different
use
case.
Okay,.
D
K
D
D
Essentially,
that
the
protected
resource
is
able
to
look
at
the
access
token
and
and
there's
an
authentication
when
the
client
is
calling
the
protected
resource
and
then
the
pressure
resource
as
well
I
got
an
access
token.
That
was
for
you
and
was
it
you
that
called
me.
So
you're
essentially
checking
to
see
this
access
token
this
client
and
then
this
is
the
client.
That's
calling
me
and
I
know
those
are
the
same
so
we're
you
know.
Well
this
one.
D
And
so
you,
this
maps,
better
cuz,
you
don't
have
any.
It
doesn't
really
make
sense.
I
have
different
access
tokens
for
different
parties,
because
it's
all
the
same
resource
and
by
the
nature
of
it.
You
want
the
client
to
be
able
to
be
authenticating
anyway,
when
they
call.
So
you
know
who
is
calling
you,
it's
not
just
an
authorization.
You
want
to
know
which
party's
saying
it.
D
So
you
already
have
that
piece,
and
so
this
Maps
better
for
them
sort
of
an
alternative
mitigation
on
replay
next
slide,
and
so
the
resource
server
impersonation,
really
that
all
the
things
that
solve
access
token
itself
by
that
next
slide
and
then
the
malicious
a/s.
So
at
a
high
level.
It's
really
you
don't
want
bare
tokens.
You
want
to
have
some
proof
of
possession,
so
the
authorization
server
can't
replay
the
credentials
to
a
different
authorization,
server.
E
L
One
comment:
I
mean
this
sort
of
encapsulates
a
number
of
independent
drafts
that
we
have
from
the
draft
that
Brian
and
I
are
working
on
on
mutual
TLS,
which
is
one
of
the
mitigations
and
was
called
out
by
in
the
security
issues.
Work
the
resource
indicators
in
some
of
the
other
stuff
I
mean
we
should,
while
I
agree
with
having
an
overall
document,
we
shouldn't
lose
track
of
actually
having
generic
solutions
for
the
broader
issues.
D
L
H
Components
where
Johnny
I
see
I
personally
see
the
different
sort
of
threat
mitigation
things
as
references
to
other
documents
rather
than
and
the
main
focus
of
this
work
and
I
think
what
you
got
into
the
security
aspects,
because
that's
obviously
a
big
concern
with
that
sort
of
the
the
parties
so
I
think
this
is
this
is
the
type
of
thing
I
believe
is
right.
That
should
be
focused
on
right.
L
But
what
I
said
with
threat
mitigations
pointed
back
to
Brian's
draft,
etc.
So
so
Torsten
and
I
have
identified
this
as
a
generic
issue
that
we
have
to
solve
and
have
two
different
mechanisms
that
we've
proposed.
So
we
should
attempt
to
if
we're
going
to
solve
some
of
these
issues,
we
should
try
and
solve
it
across
both
oo
auth
and
this,
as
opposed
to
necessarily
coming
up
with.
L
B
Comment
so
I
mean
you,
your
proposal
underlies
what
what
I
said
previously
so
office,
getting
dynamic
more
than
I,
think
more
than
I
make
and
so
on
so
more
less.
But
what
what
you
presented
is
along
the
line
of
the
threat
analysis.
We
did
for
the
token
leakage
so,
and
he
also
came
up
with
more
or
less
the
same
recommendation,
so
I
think
we
should
should
somehow
align
that
and
and
and
prevent
replicating
the
work.
D
E
D
W
Temporary
friend
I
think
you're
asking
whether
there
was
interest
in
this
topic
or
this
document
I
would
have
interested
in
the
topic,
but
not
necessarily
I,
think
with
John
and
the
rest.
There's
other
ways
to
solve
this,
and
you
know
so
I
wouldn't
necessarily
say
suggest,
adopting
this
document,
but
adopting
the
idea
and
looking
at
all
the
other
things
that
have
been
done
in
this
space.
Okay,.
E
E
X
X
First
and
foremost,
the
acknowledgement
of
course
mentioned
that
this
work
is
highly
inspired
by
another
draft,
and
Brian
has
also
reviewed
this
very
document.
So
thanks
for
that,
so
essentially,
this
document
proposed
two
new
calling
credentials
to
be
used
for
authenticating
the
client
to
the
authorization
server
either
based
on
Republic
am
pretty
sure
key
to
be
used
for
establishing
TLS
or
D
TLS
session,
with
the
authorization
server
in
the
respective
a
key
establishment,
mod
and
according
to,
of
course,
the
respective
specification
to
authenticate
the
client
in
the
end.
X
If
you
go
further
Republican
mode,
yes-
and
this
document
made
particular
reference
on
the
Clyde
one
credential
per
client
software
per
diem,
which
is
particularly
common
in
constrained
environments,
where
this
document
was
initially
proposed
before
considering
this
working
group
that
makes
particular
sense
cause
devices
in
such
use
case
are
pre
provision
with
a
symmetric
key
that
can
be
used
in
case
of
dynamic
registration.
These
documents
also
specifies
sorry
new
registers
for
new
attributes
enabling
registration
for
both
cases
of
Fisher
key
base
are
a
public
key
based
and
I.
Think
it's
the
last
light.
Yeah.
L
G
Mike
Mike
coming
go
ahead.
Yeah
I
have
a
clarifying
question:
Mike
Jones
from
Microsoft
R
that
Keys
represented
in
discovery
document
or
in
the
registration
document
as
JW
Kay's
or
references
to
janab-u
K
sets
or
references
to
JW
k
documents.
Are
they
something
else
entirely
I?
Don't
remember
this
detail
I.
G
B
O
O
O
Mean
there
are
better
systems
than
these,
but
if
you
take
the
average
Internet
user
today,
most
of
them
just
have
a
hundred
or
two
hundreds
of
usernames
and
passwords,
which
in
theory
of
different
but
in
practice,
are
being
used
constantly
in.
This
creates
all
sort
of
security
and
privacy
problems,
and
there
are
some
single
sign-on
systems
that
are
gaining
ground.
O
Websites,
you
see
people
being
able
to
login
with
the
Google
or
Facebook
or
whatever
credentials,
which
is
fine
and
very
convenient,
but
at
the
same
point
that
in
our
opinion,
this
is
giving
way
to
too
much
of
fragmentation
and
lack
of
interoperability.
So
I
mean
on
some
websites.
You
get
the
list
of
15
different
sources
of
credentials.
You
can
you
have
to
pick
one
from
them
from
other
websites.
O
Only
give
you
one
of
them,
so
you
need
to
have
a
Google
account
to
access
the
websites
that
only
accept
Google
credentials
and
then
a
Facebook
account
to
access
their
websites.
That
only
accepts
I
spoke
with
an
shells
and
so
on.
So
we
don't
think
this
makes
sense,
and
so
we've
been
thinking
whether
there's
another
way
of
doing
it,
so
that
implementers
that
websites
online
resources
that
want
to
accept
single
sign-on
credentials
only
implement
one
system
and
it
works
with
any
identity
provider,
and
also
users
can
choose
their
provider.
So
if
they.
O
Particular
provider,
they
can
get
an
account
from
someone
else
and
they
are
not
forced
by
I
mean
to
use
one
specific.
So
next
time
so
I
mean
we've.
We
are
an
image
company
by
the
way,
so
we
just
were
wondering
why
can't
it
work
like
email?
So
why
can't
you
have
a
public,
open
and
federated
infrastructure
in
which
you
get
your
identity,
your
identifier,
from
whatever
provider
you
want
and
it
works
on
a
website
and
your
online
source
and
and
you
can
actually
get
get
or
than
to
choose
it
to
change
it.
O
If
you're
not
happy,
you
could
even
host
it
yourself
and
if
you're,
using
a
your
own
domain
name
exactly
like
it
happens
with
email,
you
could
even
port
your
identifier
to
a
different
provider.
So
you
keep
the
identifier
and
have
it
managed
by
someone
else,
and
then
we
think
there's
really
a
long
list
of
advantages
in
the
system
like
this.
For.
C
O
An
easy
way
not
having
to
retype
it
each
and
every
time
and
update
it,
each
in
each
and
every
website
separately,
and
so,
but
in
the
end,
so
it
should
just
work
like
you
do
in
the
real
world.
So
in
the
real
world
you
don't
have
to
register.
Whenever
you
need
to
keep
informational,
you
just
show
your
ID,
you
just
identify
yourself,
so
we
started
from
requirements.
O
We
wanted
to
reduce
the
implementation
effort
so
to
make
it
easy
I
mean
to
make
it
easy
for
people
that
already
provide
identities
so
that
can
easily
make
their
systems
and
their
existing
identities
compatible
with
this
infrastructure
and
in
some
way
in
his
for
everyone.
So
we
this
is
why
we
chose
to
build
and
in
Deauville
the
DNS.
O
So
we
chose
to
wet
the
DNS
into
the
mix,
and
this
is
also
for
I
mean
this
is
for
several
reasons,
but
one
of
them
is
also
the
fact
that
users
are
a
customer
to
dns-based
identifiers,
to
host
names
or
to
email
addresses.
Actually,
the
email
address
is
often
used
by
people
as
their
username,
so
we
think
that
this
would
be
a
natural
extension
and
so
identifiers
should
work
within
the
DNS
infrastructure.
O
And
finally,
one
thing
we
decided
is
that
we
did
not
want
to
work
with
real
world
identification,
so
this
is
not
really
meant
to
be
a
system
in
which
you
have
to
prove
identity.
I
mean
you
could
build
some
kind
of
third-party
certification
over
it.
So
you
could
address
the
issue
of
certifying
the
identity
of
the
user,
but
in
it
I
mean
itself.
The
system
is
just
meant
to
replace
what
you
get
today,
username
and
password
or
by
a
simpler
term.
So
you
could
have
multiple
identities.
O
O
Y
You
Victoria
Marcus
and
I
work
for
the
day.
Nick
German
domain
name
registry
next
slide,
please
so
I'm
working
with
Vittorio
together
on
this,
and
we
were
trying
to
build
this
up,
and
the
first
thing
we
realize
is
we
needed
some
things
that
were
missing.
For
instance,
the
issue
of
issue,
a
discovery
we
have
it
already
there.
So
the
draft
of
discovery
just
nonchalantly
says
no.
This
is
not
part,
it's
out
of
scope
so,
and
so
we
didn't,
we
didn't
have
a
way.
Y
L
C
Y
At
it
and
well
then,
we
yes
I,
did
mention
that.
Okay,
we
went
back
to
the
to
the
world
to
the
one
of
the
open
ID
from
the
open,
ID
financial
foundation,
and
it
uses
webfinger
for
that
absolutely
yeah.
But
this
the
draft
of
this
working
group-
yes,
doesn't
doesn't
talk
about
it,
but
we
have
a
problem
with
webfinger,
and
this
is
this.
This
has
incredible
operational
challenges
if
you
have
to
run
a
web
finger
at
each
and
every
one
of
the
issue
of
the
identifiers
that
you
want
to
use
in
the
system.
Y
So
if
I
want
to
use,
email
addresses
or
I
want
to
use
domain
name
such
as
identifiers
I
would
have
to
have
a
wet
finger
for
each
one
of
those
and
that
didn't
make
much
sense.
So
we
came
up
with
with
an
easy
solution,
is
to
do
this
in
the
DNS.
We
use
the
DNS
for
for
easier
discovery
and
well
since
we
are
a
DNS
company,
email
company,
when
you
work
at
the
DNS
companies
and
everything
looks
like
a
DNS
Fernandez.
Y
This
really
is
a
DNS
problem
and
well
we
combine
that
with
DNS
SEC
so
that
you
get
authorized
source
of
information
and
integrity
in
the
answers.
So
there
are
different
ways
to
do
this
in
the
DNS.
There
are
very,
very
trivial
ways
to
do.
Is
a
savvy
wreck
or
not
the
records
command
SRP
with
a
nap
Wreckers
use,
something
like
WebDAV
does
and
we
what
we
do.
This
is
a
kind
of
d
mark
approaches
very
easy,
txt
record.
That
just
says.
Ok,
this
is
the
place.
Y
D
D
D
We
realized
we
needed
to
go
to
an
email
based
mechanism,
but
there
had
already
been
a
little
too
much
momentum
in
the
older
mechanism,
and
so
there
was
a
reluctance
to
do
that
and
then
facebooking
came
out
and
a
number
other
things
came
out
and
so
the
motivation
for
a
number
of
relying
parties
to
get
a
solution
for
how
did
it?
You
know
solving
their
problem
on?
How
did
you
enable
people
to
easily
log
in
you
know
the
problem
went
away
for
those
people,
and
so
today
what
motivates
anybody
to
adopt
the
system?
D
So
that's
one
point.
The
other
point
is,
you
know:
I
humor
I
always
laugh
whenever
someone
uses
the
word
off
in
a
discussion
around
identity,
because
it's
like
which
off
off
then
or
I'll,
see
my
understanding
that
this
working
group
is
an
authorization
working
group
as
opposed
to
an
authentication,
and
my
as
this
looks
like
this
is
much
more
of
an
authentication
oriented
solution
but
I'm
happy
to
let
you
continue
on
with
your
story
here.
Y
Thank
you
that
no
absolutely
yeah
you
put
it.
You
are
putting
the
the
finger
in
the
in
the
wound.
It's
absolutely
yeah.
It
is
it's
a
challenge
to
try
to
convince
somebody
else
to
use
this
discovery
mechanism,
and
it
will
be
a
challenge
to
try
to
you
convince
the
users
to
use
this
system
of
single
sign-on,
but
nevertheless
we
think
it
has
advantages
towards
the
situation
that
it's
out
there.
As
Vittorio
has
just
said,
there
is
a
fragmentation.
Y
We
observe
a
fragmentation
and
we
observe
and
a
problem
of
the
identity
of
the
users
being
owned
by
some
companies
and
not
being
able
to
move
easily
their
digital
identity
from
company
a
to
Company
B.
So
we
really
believe
in
the
system
that
will
even
allow
for
self
hosting
your
identity
hold
on
I
have
more
slides.
Y
Coming
up
when
one
slide
back
just
wanted
to
take
a
look
at
the
other
points.
Okay,
so
we
are
using,
we
are
we
are
separating.
We
are
separating
concerns.
We
are
separating
the
concern
of
the
AES
from
the
protective
resources
they,
yes
is
there,
the
identity
provider.
The
resource
is
the
identity
of
the
user.
We
are
using
distributed
claims
for
opera
to
do
this,
but
you
are
not
very
interested
in
open
ID,
so
I
will
skip
this.
Y
We
are
at
the
adding
additional
mechanisms
to
the
open
ad
standard
to
be
able
to
complain
to
be
complainant
with
European
general
data
protection
regulation
like
being
able
for
the
relying
parties
to
communicate,
to
reasons
why
they
would
like
to
access
to
access
some
of
the
claims
of
the
user
for
the
user
to
be
able
to
make
an
informed
consent
about
allowing
or
not
allowing
access
to
this
data
next
slide
and
well.
What
we
have
at
the
moment
is
this
joint
project
between
our
companies.
Y
We
have
a
prototype
of
the
system
up
and
running
and
we
are
presenting
it
to
different
parties
trying
to
socialize
the
ideas
we
have
TLD
registers
that
are
interested
in
this.
We
have
domain
name
registers
that
host
is
domains
and
and
are
interested
to
participate
on
this
we
have
interest
of
telcos
and
I
a
space
to
be
able
to
deliver.
I
am
identities
to
their
users.
We
have
two
drafts
next
slide,
presenting
one
the
discovery
mechanism.
Y
Second,
the
overall
architecture
of
the
system-
and
this
is
exactly
what
we
would
like
so
so
so
feedback
from
the
people
why?
This
is
a
good
idea
or
why
this
is
a
bad
idea
review,
and
maybe
some
guidance
where
to
deal
with
this
is
the
idea
of
the
proper
venue.
No,
let
us
alone
go
to
the
open,
ID
foundation
or
whatever.
So,
please,
all.
L
L
But
so
could
webfinger
if
everybody
ran
webfinger
or
open,
Yolo
or
or
you
know
whatever
stuff
dick
invented
for
you
know,
open
ID,
there's
mobile
connects
there's
a
lot
of
great
things
that
could
unify
it.
If
people
did
this-
and
this
is
not
the
first
DNS
based
ones
which
I'm
sure
you
know
that
if
you've
done
your
research,
so
why
this
one.
C
That's
a
chimera
line
all
right,
so
when
we
were
doing
webfinger,
we
also
considered
seriously
considered
solution
and
there
were
a
bunch
of
constraints
that
didn't
allow
us
to
actually
use
DNA,
so
you
probably
want
to
look
at
it.
The
other
one
is
that
for
the
privacy
notices
and
things
like
that,
open
ID
connect
already
has
this
facility
to
do
that.
Third,
one,
like
somebody
else
has
pointed
out,
this
is
authorization
kind
of
working
group.
E
Q
Y
Q
This
is
not
a
question
of
getting
it
to
work,
and
it's
obviously
you
can
do
that,
but
the
problem,
when
you
sort
of
scale
out
scale
stuff
like
this
up,
there
are
trust
issues
and
the
and
the
the
you
you
cannot
use
the
DNS
to
establish
trust
because
DLS
and
DNS
SEC
is
based
on
a
single
root
hierarchy
which
does
not
map
to
to
practical
Federation,
where
you
actually
want
to
have
overlapping
circles
of
trust.
A
much
more
control
over
where
you
get
your
keys
from
how
you
trust
those
keys
and
how
you
exchange
them.
Q
So
actually
DNS
is
actually
a
poor
model
for
you
to
build
a
trust
infrastructure
on
this
is
not
just
about
exactly
if
you're
a
dinner,
leonesse,
radish
or
then
you're.
You
think
this
is
great,
but-
and
this
is
not
a
crime
in
this-
is
not
a
criticism.
We've
had
similar
thoughts
in
salmon
space
and
decided
not
to
do
to
do
the
same.
Do
do
it
because
of
because
of
those
reasons
I've
heard
it
I'm,
not
I,
don't
know
whether
you've
thought
of
Federation
and
Trust
establishments
as
part
of
your
problem
space.
Z
AA
K
AA
AA
AA
H
Poster
dementia
PDA:
okay:
do
you
guys
know.