►
From YouTube: IETF115-OAUTH-20221109-1300
Description
OAUTH meeting session at IETF115
2022/11/09 1300
https://datatracker.ietf.org/meeting/115/proceedings/
A
B
B
Tips
for
joining
so
please,
if
you
are
local,
use
the
meteco,
light
client
and
make
sure
to
log
in
because
we
don't
have
blue
sheets
anymore.
So
that's
the
power
blue
sheets
that
helps
you
also
get
into
the
queue
and
please
wear
masks.
Unless
you
are
speaking
for
remotes
people
make
sure
your
audio
and
video
is
off,
and
unless
you
want
to
speak
up
and
please
use
a
headset.
B
B
I've
done
those
updates,
this
is
Monday's
agenda
and
this
is
today's
agenda.
I'll
be
talking
about
jot,
embedded
tokens,
a
tool
we'll
be
talking
about
fine-grained
transactional
authorization,
hey
Peter
will
be
talking
about
cross
device
flows
and
Christina
will
finish
it
up
with
the
client
ID
for
anonymous
clients
and
on
the
side
meeting
tomorrow,
we'll
dig
deep
into
fine
grain
transactional
authorization.
C
B
B
D
B
So
what
we've
decided
to
do
is
focus
on
one
use
case
or
one
category
of
use,
cases
which
is
multiple
tokens
from
multiple
issuers
and
we'll
look
into
the
other
one.
In
the
future,
maybe
in
a
completely
different
document,
can
you
hear
me
clearly
guys
next
slide
please,
so
the
goal
is
to
be
able
to
bind
one
or
more
tokens
that
are
issued
from
a
multiple
issuers
into
a
new
token
and
show
the
relationship
between
those
tokens
next
slide.
Please.
B
In
some
cases,
also,
it's
useful
to
use
the
information
in
those
tokens
to
display
information
to
the
end
user,
and
this
is
a
I'll
talk
about
an
example
of
a
telephone
example
that
that
is
useful
in
that
case
and
the
third
one
is
obviously
evaluation.
Authorization
next
slide,
please
so
in
in
those
use
cases
the
multiple
issuers
use
cases
the
the
tokens
that
that
could
be
issued.
It
could
be
an
access
token
or
an
ID
token.
B
B
So
a
calls
B
and
the
chord
from
B
is
directed
to
C.
So
when
the
call
is
redirected
from
B
to
C,
B
will
create
a
new
token
embed.
The
original
token
that
was
talking
about
a
column
B
and
and
send
that
the
new
token
embedded
into
the
new
issue
token
into
C
so
c,
will,
when
C
receives
that,
we'll
be
able
to
see
that
the
original
call
was
between
a
and
b
and
now
the
call
from
a
to
c
was
redirected
so
that
that's
that's
the
use
case
right.
B
The
other
use
case,
for
the
ID
token,
is
that
hello
use
use
case
that
a
dick
is
working
on
and
in
the
idea
there
is.
You
want
to
be
able
to
link
multiple
claims
from
from
multiple
or
different
issuers.
For
example,
you
could
you
can
get
the
date
of
birth
from
one
issuer
and
Education
certification
for,
for
example,
from
a
completely
different
issue.
B
Next
slide,
please.
So
the
current
thinking
is
that
what
we
want
to
utilize
the
token
exchange
mechanism,
which
it
has
all
the
the
tools
that
we
need
with
with
just
a
little
bit
of
a
tweak.
So
in
this
case,
we
want
to
send
a
request
to
to
the,
as
with
that
original
token
and
ask
for
a
new
token,
but
indicate
to
the
as
to
embed
the
token
that
we
sent
you
in
the
new
issue.
B
B
In
this
case,
we
defined
a
token's
claim,
that
is
a
list
of
objects,
and
each
object
will
have
a
information
about
the
new
token,
in
this
case,
we're
talking
about
a
type
to
indicate
the
type
of
token
and
the
token
itself.
So
this
is
kind
of
a
generic
means
or
genetic
structure
that
will
allow
us
to
address
multiple
or
different
use
cases
next
slide,
please!
B
So
that's!
That's
all
all
we
have
a
again.
We
haven't
had
a
chance
to
update
the
draft
with
all
those
details
that
are
still
more
details:
technical
details
that
we're
gonna
dig
deeper
into
and
and
Define
and
make
it
clear,
but
just
wanted
to
give
you
a
quick
update
on
our
current
thinking.
And
if
anybody
has
any
comments
question
they
happen
to
hear
it
right
now
got
your
own.
E
I
think
over
time
there
will
be
multiple
different
semantics
for
embedded
tokens,
and
it
makes
sense
to
embed
so
to
to
include
the
the
semantics
so
something
signifying
whether
it's
something
trusting
something
else
or
just
a
combination
of
two
things
and
probably
many
other
things.
I'm
not
saying
we
should
standardize
semantics
I'm
saying
we
should
have
it
explicit
in
the
token
because
you're
signing
it
and
you
want
to
minimize.
B
E
B
F
B
H
G
I
mean
I,
think
experience
in
this
whole
area
over
the
last
10
or
15
years
tells
us
that
you
can't
you
can't
tell
relying
parties
what
to
rely
on
so
I
mean
my
instinctive
reaction
is
to
that
is:
don't
worry
about
even
trying
to
define
the
semantics,
because
relying
party's
going
to
rely
and
I
mean
you
know.
The
canonical
example
is
U.S
Social
Security
numbers
strict
rules
about
what
they
may
or
may
not
be
used
for
have
no
effect
on
who
insists
on
having
them
and
what
they
rely
on
them.
For
so
don't
sweat.
B
I
H
I
I
So
yeah
the
the
motivation
is
we
want
to
secure
communication
between
microservices,
both
with
inside
a
single
trust
domain
or
a
single,
a
single
VPC
if
you
will
and
across
trust
domains
right.
So
this
is
so
that
if
there
is
a
software
supply
chain,
attack
or
other
way
in
which
a
sort
of
VPC
is
compromised,
you
cannot
have
a
elevation
of
privileges
or
you
cannot
have
a
impersonation
of
users
within
those.
You
know
within
that
trust
domain,
and
this
essentially
has
to
be
based
on
standards
because
organizations
are
going
to
have.
I
You
know
vpcs
in
different
Cloud
platforms
between
on-premise
and
Cloud
platforms
and
stuff,
like
that.
So
unless
we
solve
this
in
a
standards,
you
know
Open
Standards
kind
of
way
we
are
going
to
be
stuck
with.
You
know,
crummy
solutions
that
cannot
easily
cross
boundaries
of
these
Cloud
platforms.
Next,
please.
I
But
this
of
course,
Works
within
just
one
trust
domain,
and
it
also
as
far
as
I
know,
does
not
protect
the
call
chain
itself.
So
you
can
actually
take
that
token
and
use
it
somewhere
else
and
it'll
it'll
just
work.
Athens
is
a
sort
of
a
Yahoo.
You
know
Verizon
open
source
project
and
that
it
has
these
centralized
and
decentralized
authorization
capabilities.
It
is
meant
for
the
same
application,
but
from
the
website
it
wasn't
very
clear
exactly
how
these
things
worked.
I
I
So
he
presented
an
identity,
identity,
Wars
2020,
a
short-lived
transaction
tokens
idea,
which
is
jwt-based
tokens
that
last
a
very
short
period
of
time,
and
you
know
that
can
embed
the
identity
and
authorization
information
so
that
any
service
using
that
within
that
period
of
time
can
can
rely
on
that
to
identify
the
user
and
the
authorization
scope.
It
does
not
again
bind
the
call
chain
to
those
tokens.
I
So
that's
a
potential
limitation.
If
we
are
interested
in
fixing
that
rifat
just
talked
about
multi-subject
tokens
or
I
guess
now
it's
called
multi-assure
tokens
so
and
then
Kelly
has
just
put
in
a
proposal.
I
I
saw
a
draft
being
submitted
just
today,
I
think,
but
we
talked
at
I.
Kelly
talked
at
ietf,
one
in
film
Philadelphia
about
token
chaining.
Basically,
the
idea
is:
how
do
you
cross
boundaries
between,
let's
say
trust
boundaries
like
between
two
different
organizations
or
two
different?
I
You
know
Cloud
platform,
instances
of
the
same
organization,
so
you
have
an
authorization
server
on
one
end
and
an
authorization
server
on
the
other
end
and
you
mint
a
token
from
the
second
authorization
server
for
the
outbound
call
to
use
so
that
it
can
actually
cross
the
boundary
and
be
accepted
in
the
next.
You
know
trust
domain,
and
then
you
know
I
just
presented
in
ietf114
as
well
about
the
generic
problem,
architecture
and
I.
Can
we
can
go
into
that
a
little
bit?
So
this
is
in
general.
I
What
we
were
thinking
about
as
the
problem
architecture-
and
the
idea
here
is
that
there
are
multiple
vpcs
as
you
can
see,
and
it
could
be.
The
the
vpcs
belong
to
the
same
organization
like
in
this
case.
The
vpc1
and
vpc2
belong
to
the
same
organization,
or
it
could
be
that
you're
calling
a
third
party
API-
and
you
know
that
belongs
to
a
different
organization,
but
it
could
be
that
the
data
in
there
is
of
your
own
organization.
I
So
you
want
to
make
sure
that
none
of
these
call
chains
essentially
can
result
in
a
privileged
escalation
or
a
user
impersonation.
Within
that
sequence
of
events
and
the
different
colored
services,
like
the
you
know,
the
Blues
Blue
bubbles
represent
external
externally
facing
rest
apis
that
can
be
called
by.
I
I
They
need
not
necessarily
need
to
know
the
identity
of
the
user,
but
they
they
can
just
pass
that
token
through
to
a
resource
microservice
which
actually
needs
the
identity
of
the
user
right.
So
if,
let's
say
I'm,
writing
a
microservice
that
just
Aggregates
information
from
different
other
microservices
I,
don't
need
to
know
who
the
user
is
right.
I
can
just
pass
that
information
to
the
resource,
microservice
and
then
get
back
the
data
and
then
aggregate
that
and
send
my
response
back
and
yeah.
I
So
we
we
had
a
couple
of
workshops
or
actually
one
workshop
and
a
one
one
call
after
that
we
had
all
these
companies
attend
and
we've
now
got
certain
proposals
to
the
existing
Charter.
You
can
download
the
charter.
I
just
put
it
up
on
our
website
and
you
know
you
can
download
it
from
there,
but
you
know
other
attendees
May
later
add
themselves.
So
next
slide,
please!
So,
let's,
let's
go
into
the
you
know
what
what
is
in
sorry.
I
I
So
these
are
like
things
like
you
know,
an
on-prem
on-premise
installation
that
is
then
talking
to
a
cloud
service,
or
you
know,
services
within
one
Cloud
platform,
maybe
it's
the
same
organization's
tenant
and
just
as
an
example
AWS
talking
to
a
tenant
in
Azure
belonging
to
the
same
organization.
So
it's
you
know.
I
Those
are
the
trust
boundaries
that
we
are
talking
about
and
we're
just
defining
our
PCS
as
something
that
is
the
actual
call
made
between
microservices
and
the
call
chain
is
the
sequence
of
events
that
result
from
an
invocation
at
the
top
level,
which
could
be
a
user
like
an
interactive
invocation
or
a
batch
invocation
right
next
slide.
Please.
I
Right
so
I'm
not
going
to
read
this
a
lot,
but
this
is
the
purpose
of
the
group
right.
We
want
to
make
sure
that
it
provides
it
can
convey,
authentication
without
modification.
It
can
provide
least
privilege
fine-grained
authorization,
so
the
Scopes
that
are
defined
for
the
call
chain
can
be
very
fine
grained
and
it
can
provide
the
context
information
required
to
you
know
in
an
immutable
sort
of
way,
so
that
you
cannot
do
things
like.
I
I
Yeah,
so
we
want
to
limit
the
scope
to
basically
just
you
know,
providing
the
framework
to
communicate
identities.
That's
one
part
of
it,
which
is
you
know.
How
do
you
identify
the
same
user
when
you're
crossing
a
trust
boundary
right
when
you're,
let's
say
in
you're
in
a
VPC
that
is
an
AWS,
and
now
you
want
to
go
to
a
VPC
that
is
in
in
azure.
I
What
information
are
we
talking
about
right?
So
this
is.
These
are
all
the
things
that
we
want
to
make
sure
that
the
identity
of
the
principal
you
know
invoking
the
call
is
preserved.
We
also
want
to
make
sure
that
the
identity
of
the
services
that
are
in
the
call
chain
is
preserved
and
the
authorization
scope
you
know,
as
defined
at
the
top
level,
but
also
if
it
was
downscoped
or
modified
along
the
call
chain.
I
B
I
So
we're
going
to
have
a
little
more
discussion
tomorrow,
so
I
think
there's
just
one
more
slide
that
I
want
to
okay,
let's,
let's
skip
this
one,
let's
skip
this
one
as
well:
let's
skip
this
one
as
well
yeah,
so
these
are
the
things
that
we
would
like
to
discuss
right.
So
we
want
to.
We
want
to
discuss
things
like
you
know
the
short-lived
tokens
or
the
efficiency
considerations,
because
this
is
something
that
that
is
going
to
have
to
go
with
every
RPC
between
microservices.
I
You
know
how
do
we
verify
the
call
chain
and
I
think
we've
had
some
good
discussions
in
the
last
few
days
over
here,
and
so
we
there
is
some
clarity
on
some
of
this,
but
I
think
it'll
be
good
to
get
opinions
from
everyone
about.
You
know
how
whether
this
is
important
or
not
important,
and
so
on.
So
that's
kind
of
we'll
be
discussing
some
of
those
tomorrow
would
love
to
encourage
people
to
participate.
B
J
J
There
we
go
even
better
all
right:
okay,
so
I'm
going
to
talk
about
cross
device
flows.
I
think
this
is
a
topic
that
we've
discussed
at
a
number
of
venues
and
I'm,
going
to
give
a
little
bit
of
an
update
on
the
progress
that
we've
made,
and
also
just
a
recap
for
folks
who
may
be
new
to
the
topic
as
well:
okay,
okay,
here.
J
Didn't
need
to
look
back.
Thank
you,
she's
unblind,
all
right,
so
there
was
a
challenge
right.
You
have
to
take
a
picture
locally,
and
this
is
mine,
mind
the
gap
and
it's
actually
kind
of
topical
for
this
presentation,
because
it
turns
out
there's
a
couple
of
gaps
that
we
need
to
pay
attention
to,
and
and
maybe
we
just
need
to
put
a
label
up
or
maybe
we
we
also
need
to
do
a
little
bit
more.
J
So,
first
of
all,
right,
I'm
gonna
talk
very
quickly
just
about
the
problem,
as
a
recap
a
little
bit
about
our
journey
so
far,
you
know
how
we're
thinking
about
managing
this
risk.
Some
proposals
I'll
I'm,
going
to
talk
a
little
bit
about
the
draft
proposal
that
was
circulated.
Maybe
two
two
and
a
half
weeks
ago,
and
then
I
think
a
question
for
this
room
and
for
this
audience
is
what
do
we
do
next
right?
J
We
think-
and
we
spend
a
lot
of
time,
thinking
about
how
an
attacker
could
exploit
the
protocol
from
a
technical
perspective.
However,
I
think
one
of
the
things
that
we've
been
learning
over
the
last
two
years
or
so
is
that
attackers
are
because
of
the
really
good
work
that
people
in
this
room
and
elsewhere
have
done.
Attackers
are
actually
sort
of
not
going
for
the
difficult
problem
of
attacking
the
protocol.
As
such.
J
Oh
come
on
they're,
focusing
here
right,
they're,
focusing
on
the
social
engineering
side-
and
this
is
kind
of
you
know,
part
of
that
mind
the
gap
right.
All
our
retention
is
going
into
making
sure
the
technology
and
the
protocols
are
secure
and
I.
Think
that's
great,
but
it's
it's
leaving
some
of
these
social
engineering
gaps
and-
and
some
of
them
are
you
know,
implementation
issues,
but
it's
also
sometimes
I.
Think
we've
observed
some
of
these
as
sort
of
unintended
or
unexpected
right.
J
It
continues
to
be
surprising
that
people
are
surprised
that
this
is
a
problem
and
so
an
area
or
a
gap
that
we
we're.
We
might
want
to
focus
on
a
little
bit
more
so
very
specifically,
I
think
one
of
the
flows
that
we've
been
looking
at
is
the
device,
authorization,
Grant
or
device
code
flow,
and
so
typically
how
that
works
is
on
the
one
end
right.
You
have
an
attacker
who
controls
a
device
or
is
able
to
connect
to
the
authorization
server
and
they
can
initiate
a
session.
J
It
is
things
like
click
to
win,
or
you
know
sign
in
or
we're
going
to
delete
your
SharePoint
site,
or
you
know
any
other
number
of
things
that
creates
anxiety,
a
sense
of
urgency
and
get
the
user
to
say.
Yes,
there's
other
variations
of
this,
where
it
actually
gets,
coupled
with
timing
or
just
spamming
people
right
just
giving
people.
You
know
you
get.
J
J
You
know
they're
going
to
click
to
win
because
today's
the
day
right
and
they
scan
and
they
enter
that
code,
they
perform
their
authentication
authorization
and
this
can
be
strong,
auth
right
or
it
can
be
multi-factor
or
Fido
doesn't
matter
because,
with
this
attack,
it's
the
attacker
I,
don't
I'm,
not
after
your
credentials
right.
It's
not
a
traditional
phishing
attack.
I
just
want
you
to
say
yes,
because
what
I
really
want
is
for
you
to
say
yes
that
I
can
access
your
tokens.
J
Your
access
token,
your
refresh
token
and
then
I
can
leverage
those
sometimes
to
do
a
lateral
attack
to
a
different.
You
know
I
can
sort
of
move
across
or
even
just
if
I
have
access
to
your
your
mailbox
right.
That's
already
plenty,
because
now
I
can
start
sending
mail
on
behalf
of
you.
I
can
request
additional
access
right,
I,
think
we're
seeing
attackers
being
really
really
clever
and
not
really
attacking
the
technical
aspects
of
the
protocol,
but
but
using
this
sort
of
soft
entry
point
with
users
so
really
to
to
to.
J
To
recap:
you
know
start
off
by
initiating
the
session
some
social
engineering
technique
to
rephrase.
What's
happening
for
the
user
and
you
end
up
bypassing
strong
authentication,
multi-factor,
authentication
and
and
you're
in
you
know,
I
think
one
of
the
things
that
we
do
do
and
I've
I'm
sort
of
laying
a
challenge
down
to
people
on
this
one,
especially
folks,
working
on
formal
analysis,
Etc.
We
we
model
the
user
right
when
we
design
these
protocols.
J
We
sort
of
expect
Perfection
from
the
end
user
they're
going
to
make
good
judgments
they're
going
to
be
smart
about
when
they
say
yes
or
no
do
things,
but
the
reality
is
it
doesn't
work
right
and
I.
Think
some
of
the
recent
attacks
where
I
believe
you
know
a
large
company
suffered
an
attack
and
and
the
attack
ended
up
being
I,
think
against
part
of
their
security
organization
right.
So
even
people
who
are
Security
Professionals
end
up
being
caught
out
by
these
attacks,
and
so
the
reality
is
right.
J
I
think
we
need
to
find
a
way,
and
we
need
to
accept
that
this
is
happening,
that
there
is
a
person,
a
human
on
the
other
end,
that's
going
to
make
bad
decisions
visions,
and
we
should
just
be
thinking
more
about
how
we
design
for
that
as
well,
and
so
this
this
work
is
really
sort
of
been
teasing
out
about.
What
could
we
do
in
that
space
as
well?
So
you
know
just
in
summary,
really.
These
are
attacks
in
the
cross-device
sense
that
we're
seeing
that's
about
exploiting
this
unauthenticated
channel.
J
J
I
think
the
other
thing
that's
come
out
as
I
started.
Looking
at
this
is
that
this
is
not
just
device.
Authorization,
ground
or
device
code
flow
was
the
first
place.
We
started
seeing
these
attacks,
but
as
we
sort
of
dug
in
right,
there's
plenty
of
other
cross-device
flows,
and
so
the
question
is
also:
how
do
we
take
some
of
this
learning
and
apply
it,
and
and
how
do
we
think
about
those
other
protocols
and
how?
How
would
that?
J
So
so
far,
it's
about
a
just
over
maybe
12
months
ago
that
we've
sort
of
started
digging
into
these
attacks.
Last
December
at
osw
we
sort
of
brought
this
to
the
community.
For
the
first
time
we
described
the
issues
we
were
seeing
and
sort
of
tried
to
get
a
sense
of
other
people
are
seeing
it
in
Vienna.
We
had
a
similar
presentation.
J
Really
just
getting
a
gauge
is
their
interest
at
the
time
there
was
quite
a
bit
of
interest
from
people,
and
a
few
folks
came
up
and
said:
yes,
they
want
to
sort
of
help
explore
this
problem
at
osw
2022,
an
identiverse
we
really
spent.
In
fact,
osw
in
particular
was
an
extremely
productive
set
of
discussions
around
the
problem
and
it
really
helped
me
and
everybody
else
understand
more
around
the
challenges:
the
potential
mitigations
and
the
breadth
of
the
problem.
J
So
I
really
want
to
thank
everybody
for
their
contributions
there
and
then
I.
Think
the
previous
IDF
I
gave
an
update
and
I
think
one
of
the
questions
was
well:
okay,
so
where's
the
write-up,
and
so
actually
we
went
off
and
did
that
so
with
Daniel
and
Philip.
We
ended
up
creating
this
framework,
so
sort
of
thinking
about
our
approach
in
terms
of
practical
mitigations,
looking
at
Alternatives
and
okay.
J
What
do
we
need
to
do
in
terms
of
some
of
the
foundational
underpinnings
and
we
ended
up
writing
this
proposal?
So
so,
what's
in
the
draft
proposal,
right
I
think
to
start
with,
we,
we
actually
took
some
time
to
describe
some
of
the
concepts
behind
the
cross
device
flows,
as
well
as
the
scenarios.
Where
are
they
getting
used?
There's
quite
a
few
of
them.
We
we
sort
of
picked
six.
J
You
know
I
think
one
of
the
things
that
I
wanted
to
be
thoughtful
about
and
from
providing
examples.
We
don't
want
to
provide
too
many,
but
also
not
too
few,
because
one
of
the
things
I've
discovered
working
with
Engineers.
Is
they
often
only
read
the
examples
right?
They
read
the
example
to
figure
out.
Does
this
apply
to
them
and
so
there's
sort
of
a
number
of
these
in
there
to
try
and
sort
of
give
an
idea
of
the
breadth
right.
So
if
somebody
reads
this,
they
can
see.
Yes,
I
have
the
scenario.
J
No
I,
don't
or
I
have
something
like
that
right.
So
that's
kind
of
the
intent
we've
actually
since
publishing,
there's
been
two
additional
use
cases
that
folks
have
brought
to
us
after
reading
the
documents
so
I
think
one
of
them's
already
been
added
in
the
next
iterative
duration
and
there's
another
one
that
we
we
need
to
discuss
a
little
bit
more.
J
So
so
that's
kind
of
the
the
T
up
in
the
document.
We've
also
ended
up
sort
of
coming
up
with
a
list
of
mitigation,
so
I
think
we're
at
what
trying
to
quickly
I
forget
now.
I
accounted
them
last
night,
I
think
12
10.
we've
got
a
quite
a
good
number
of
mitigations
that
are
all
described
in
terms
of
whether
they're
preventative
you
know
do
they
disrupt
the
attack.
J
Do
they
help
you
recover
right,
because
I
think
that
was
the
other
thing
that
we
looked
at
if
we
only
try
and
prevent
the
attack,
it
sort
of
ignores
the
fact
that
the
user
is
ultimately
going
to
make
a
bad
decision.
So
how
can
we
disrupt
it
once
it's
in
in
flight
and
even
when
it's
completed
right?
What
can
we
do
in
terms
of
recovery?
So
we
got
these?
J
J
The
other
piece
is
just
looking
at
alternative
in
terms
of
protocols
and
so
giving
guidance.
So
the
the
guidance
that
we're
trying
to
give
is.
You
know
there
are
alternatives
out
there
right
to
the
device,
authorization
Grant
and
there
are
different
sort
of
trade-offs
right.
Some
of
these
are
more
susceptible
than
others.
J
Some
of
the
mitigations
are
more
relevant
than
others,
and
some
of
them
are
putting
some
requirements
on
the
devices
involved
right.
So
if
we
look
at
the
502
web
or
then
which,
in
my
view,
is
one
of
the
you
know,
that's
just
one
of
the
the
best
mitigations
that
you
can
have
for
across
device
flow
because
of
how
it's
it's
pretty.
It
comes
across
pretty
secure,
but
for
that
you
need
fairly
high-spec
devices
that
support
the
protocol.
J
The
purpose
of
this
document
and
I
I
should
have
said
that
earlier
on,
the
purpose
of
the
document
is
really
to
provide
guidance
to
implementers
to
system
Architects
even
to
Security
Professionals,
so
that
when
they're
faced
with
a
scenario,
they
have
a
little
bit
more
information
and
they
can
make
better
decisions
about
how
to
how
to
how
to
think
about
the
protocols
how
to
think
about
the
problem
space
and
how
to
think
about
managing
their
risk.
Even
though
we
cannot
fully
retire
it
and
then
the
other
part
is
just
maybe
offering
Alternatives
right.
J
Sometimes
these
cross-device
flows
are
better
served
by
a
different
product
protocol
than
the
device
authorization
Grant
or,
in
some
cases,
I
think
one
of
the
the
the
the
notes
or
feedback
that
we
got
when
we
when
I
first
sent
this
out
was
you
know.
Maybe
we
should
also
call
out
that,
if
you're,
if
you're
on
you
shouldn't,
do
cross-device
protocols
on
the
same
device
right,
that's
also
not
a
great
practice
right
there.
J
You
should
avoid
those
kind
of
things,
so
it's
kind
of
obvious
stuff
sometimes,
but
it's
calling
calling
that
all
out,
yeah
and
so
I
think
the
the
question
that
I
have
for
this
group
and
for
for
folks
online
like
what
next
right
so
we've
we've
we've
written
this
document
up,
we
can
continue
to
evolve.
It
I
also
want
to
get
a
sense
of
whether
this
is
actually
useful
to
people
right.
Is
this
a
a
part
of
the
problem
space
that
is
worth
paying
attention
to?
J
K
Justin
Richard
I
just
wanted
to
say
first
off
I
think
this
is
really
important.
Work
I
think
that
this
is
a
space
in
the
security
of
these
protocols
that
often
gets
overlooked,
because
we
just
kind
of
say
the
user
needs
to
make
good
decisions
and
if
they
don't
we're
kind
of
stuck,
but
a
lot
of
what
we
deploy
is
about
helping
the
user,
make
the
right
decisions
or
removing
those
decisions
in
cases
when
the
user
shouldn't
have
those
decisions,
I
mean
that's,
that's
practically.
K
That's
that's
a
lot
of
what
we,
what
we're
building
out
in
that
experience
in
that
space,
do
you
think
that
part
of
this
work
from
the
BCP
we
might
start
getting
close
to
I
hesitate
to
say
it,
but
standardizing
the
ux
for
user
involved
decisions?
This
would
be
important
for
both
cross
device
and
same
device
type
of
situations.
So
in
a
same
device
situation,
I'm
being
asked
to
you
know,
I'm
being
fished
to
click
on
a
link,
and
it
just
goes
back
to
my
browser
and
then
like
it.
D
J
Think
we
want
a
very
consistent
user
experiences
around
this
okay,
I
I,
think
about
and
I
you
know,
John
your
John
Bradley
can
probably
comment
about
this,
but
I
I
think
some
of
the
things
that's
really
attractive
about
the
Web
author
and
502.
You
know
cross
device
flow.
Is
it's
a
pretty
consistent
user
experience
right
almost
independent
of
device
Etc
right?
J
You
know
turning
that
guidance
into
and
I
I
at
least
have
this
expectation
in
terms
of
the
user
experience
rather
than
trying
to
say
well,
the
pixels
need
to
be
rendered
in
a
certain
way
in
a
certain
color
and
the
buttons
need
to
be
in
a
certain
place.
Maybe
we
I
don't
know
if
we
can
I
didn't
right.
I
have
low
expectation
of
success
going
that
far
no.
K
K
So
I'm
thinking
of
the
lab
at
Carnegie,
Mellon
cups,
I
think
is
the
lab
is
the
first
one
that
comes
to
mind.
I
know,
Bentley's
got
a
big
ux
Department
as
well
that
they've
done
a
lot
of
a
lot
of
work
in
the
past.
I
am
whatever
the
internet
2
group
that
was
doing
it
that,
like
there
was
a
whole
multi-year
thing
about
about
specifically
about
authorization
ux
in
that
case
I
mean
so
that
there's
a
lot
it's
in
the
academic
space.
J
Idea,
yeah
I
had
to
pay
for
that,
and
you
know
I
think
there's
plenty
of
us
here
who
work
with
teams
that
have
user
experience
capability
as
well
and
I
think
having
a
proposal
that
they
can
react
to
and
interact
with
would
be
fantastic.
I
would
really
welcome
that
so
Justin.
If
we
can
talk
about
how
we
do
that,
but
I'd
love
to
bring
that
and
maybe
use
this
document
to
Anchor
that,
and
maybe
that
you
know
it
turns
into
additions
to
this
document
or
another
document.
But
let's
start
doing
that
that.
K
J
K
B
D
Joseph
Heinen,
author
late
I,
don't
think
I
have
anything
terribly
insightful
to
say.
But
I've
read
this
document,
it's
a
good
document
provided
a
bit
of
feedback.
I've
referred
people
to
the
document
and
I
believe
they've.
Read
it
and
found
it
helpful.
I've
seen
other
people
refer.
People
to
this
document,
so
I
think
there's
interest.
L
You
know
I
think
they're
often
they
might
not
have
the
understanding.
You
know
they're
looking
at
it
purely
from
a
user
experience
right
and
to
have
some
guidance.
We
can
give
that
says.
Here's
the
implications
of
of
making
these
kinds
of
choices
would
be
super
helpful
to
those
teams
and
I
think
they
would
really
appreciate
it.
A
The
thing
that
the
web
authen
thing
that
you
describe
is
the
cross
device
flow
currently
called
hybrid,
formerly
called
cable,
is
not
a
thing
like
the
others
it.
It
really
is
a
different
beast
in
that
what
you're
doing
is
it's
analogous
to
you
wouldn't
say
that
plugging
a
security
key
into
a
Windows
computer
and
using
web
often
to
do
oauth
from
the
Windows
computer,
was
across
the
vice
flow
and
cable
hybrid
really
is
just
a
transport
piece
that
replaces
the
USB,
so
it
may
confuse
people
to
describe
it
as
cross
device.
J
I,
yes,
I
take
the
point
John.
Maybe
you
can
system
Capelli,
actually
authored,
that
that
part
of
the
document
I,
think
I,
I
kind
of
took
a
step
back.
I
know
as
a
technologist.
We
understand
that.
What's
really
happening
is
we.
We
actually
establish
proximity
through
and
through
that
hybrid
protocol
and.
J
A
J
I
appreciate
and
understand
and
and
I
think,
if
there's
a
I,
think
here's
my
other
motivation
here.
John
is
one
I
really
want
to
steer
people
towards.
If
you
have
a
scenario
that
can
be
met
by
the
by
Fido
and
with
the
web
of
then
flow,
please
use
that
rather
than
one
of
these
other
flows
right
and
I
think
that's
kind
of.
E
A
So
when
phone
companies
distribute
a
app
to
the
SIM
card
so
that
they
can
remotely
authenticate
the
user
over
over
the
phone,
they
wanted
a
way
to
oh
now
and
and
do
oauth
or
do
open
ID
connect
to
relying
parties
based
on
a
push
notification,
the
regular
sort
of
flow.
They
also
said,
okay.
Well
now,
when
people
call
into
a
call
center,
we
want
to
use
the
same
mechanism,
but
clearly
you
can't
do
oh
off
easily
over
the
telephone
in
a
voice
call
so
that's
kind
of
the
origin
of
it.
A
J
Mean
yeah,
so
a
couple
of
so
I
couldn't
possibly
comment
on
Xbox
and
your
other
point
that
you're
making
I
think
these
protocols
get
designed,
and
we
have
very
specific
use
cases
in
mind
for
them,
and
but
once
you
open,
Pandora's
box
right,
I've
been
reflecting
on
this
a
lot
right.
It
is
it's
like
telling
people
not
to
covet
their
neighbor
right.
B
A
I
think
it's
a
useful
word,
but
there
are
some
subtleties
in
how
we
explain
this
okay,
so
so
we
people
ought
not
to
think
yes,
because
hybrid
or
because
cable
hybrid
is
secure,
that
that
immediately
can
be
transitioned
over
to
that's
a
different
doing.
Web
authen
over
that
kind
of
Transport
is
a
different
thing
than
trying
to
do
Multi-Device,
oauth,
okay
and.
J
A
M
I'll
just
be
really
quick,
since
we're
like
out
of
time.
I
just
want
to
say
I
also
think
this
is
important
work.
This
is
great.
A
good
start
on
the
document
and
I
also
agree
that
the
user
experience
side
of
it
is
worth
pursuing
and
documenting
I
think
that's
something
that
is
been
very
much
missing
from
a
lot
of
the
work
that
we've
published
and
interestingly,
it
has
come
out
mostly
the
same
when
people
do
implement
it,
both
the
device
flow
and
just
traditional
oauth
consent
screens.
M
M
I,
don't
know,
but
I
do
think,
there's
something
there
too,
because
it
is
also
a
question
that
is
very
commonly
asked
of
someone
who's
starting
to
build.
These
is
what
do
I
put
on
the
screen.
How
should
it
work,
and
then
it's
kind
of
they
kind
of
just
have
to
figure
it
out
or
go
read
someone's
book
so.
J
N
N
If
the
protocols
you're
picking
up
in
the
document
are,
you
know,
can
only
be
usable
with
cross
device
flows,
but
the
protocols
I'm
working
on,
for
example,
the
cross
device
mechanism
can
also
be
applied
in
a
same
device
environment,
and
we
are
observing
people
doing
that
like,
for
example,
as
a
request,
encoded
in
the
QR
code
is
also
in
a
deep
link.
So
user
has
an
option
to
actually
click
it
on
the
same
device,
for
example
right
so
I,
don't
know
exactly
how
relevant
it
is,
and
I've
read.
N
The
document
I
haven't
seen
anything
around
that,
so
probably
adding
a
text
or
clarifications
or
having
a
discussion
is
would
be
useful
because
for
again
like
initially
in
at
least
in
our
protocols,
the
guidance
was
absolutely
not
used
cross
device
for
the
same
device.
People
are
doing
it
and
people
are
doing
it
also
for
some
legitimate
reasons.
Some
deployment
models
do
not
allowed
to
have
token
endpoint
whatnot.
Some,
you
know
like
divide.
The
response
is
too
big
and,
like
you
know,
they
want
to
benefit
from
cross-device
HTTP
post
requests.
J
All
right
now,
thanks
for
that,
Christina
I,
think
that
comment
was
actually
added
Joseph
based
on
feedback
that
you
gave,
and
so
it's
in
the
next
draft
I'll.
Actually,
if
you
want
to
review
that,
but
I
want
to
know
about
those
use
cases
and
you're
right
right,
we
can
say:
don't
do
it,
people
it's
not
going
to
prevent
them,
so
we
need
to
have
mitigations
or
we
need
to
give
people
options
or
at
least
highlight
the
risks.
Thank.
L
C
Are
you
aware
of
any
like
there
are
specific
Solutions
in
the
western?
So
are
you
aware
of
any
iprs
on
those
because
a
check
that
document-
it
didn't
say
anything,
but
that
would
be
important
to
file.
If
you
are
it's
like
these
are
the
types
of
documents
I
would
normally
have
assumed.
Everything
could
be
impacted.
I'm.
B
J
B
G
N
Wow
yeah
it
works.
This
is
great
all
right,
hi
everyone.
So
the
point
of
the
presentation
is
to
draw
the
working
group's
attention
on
how
the
client
ID
is
being
used.
And
what
can
we?
You
know,
note
some
emerging
data
points
of
emerging
patterns
and,
hopefully
to
start
a
conversation.
What
can
we
do
about
it?
N
So
if
you
look
at
section
2.2
in
RC
6749,
it
clearly
says
authorization
server.
It
is
authorization
server
who
issues
the
client
ID
and
also,
if
you
go
back
to
section
two,
it
says
the
client
has
to
register
with
authorization
server
before
initiating
the
protocol.
So
they're
clearly
two
requirements
that
we
have
that
are
probably
not
always
exactly
followed
in
some
of
the
deployments
we
are
seeing.
N
So
just
a
couple
of
limitations,
use
cases,
I'm,
familiar
of
and
I've
heard
from
the
rooms
that
they're
actually
other
use
cases
that
are
not
exactly
follow
these
two
requirements.
So
one
is
open.
Id
for
fiber
credential
issues,
protocol
we've
been
working
on
and
I
should
say
I'm
here
presenting
it,
but
this
is
kind
of
a
result
of
a
long
discussions
with
Torsten
and
Tobias
who
are
not
in
the
room
but
yeah
against
a
huge
kudos
to
both
of
them
to
contributing
so
in
the
protocol.
N
N
So
this
is
a
use
case
where
the
large
number
of
ruling
parties
they
close
on
wallets
a
large
number
of
these
credential
issuers,
who
have
built
this
additional
resource
server
that
want
to
interact
with
each
other
and
we've
received
a
lot
of
feedback
that
it's
unrealistic
and
also
impractical
for
the
easterling
party,
slash
wallets
to
sample
and
register
with
every
single
credential
issuer
and
manage
client
IDs
for
each
of
those
issuers
so
and
that's
kind
of
one
extreme.
Is
this
completely
open
ecosystem?
N
So
this
is
partially
what
we
started,
calling
Anonymous
clients,
maybe
not
the
best
term.
But
you
know
that's
what
we
mean
when
the
client,
the
rank
party
is
coming
in
previously
on
known,
toasterization
server.
So
it's
it's
bringing
in
the
client
ID
which
authorization
service
has
not
issued
itself,
and
maybe
it's
not
pre-issued
per
section
two,
so
yeah
I
think
I
covered
both
kinds,
completely
open
ecosystem
a
bit.
You
know
more
close
ecosystem,
but
still
two
groups
of
parties
interacting.
N
And
it's
interesting
because
first,
the
specification
absolutely
breaks
section
two
and
section
2.2
of
RC
47
6749,
and
this
is
where
a
third
party
so
there's
no
pre-registration
as
per
section
two,
so
the
client
does
not
have
to
pre-register
and
it
is
a
client
who
is
determining
its
own
client
ID.
It's
literally
the
client
saying
here's
my
client
ID,
it's
a
URI,
a
panda
dot,
well
known,
slash
openly,
Federation
config,
you
find
a
Json
file,
use
it
as
a
client
metadata
or
you
can
go
up
the
trust
chain.
N
N
N
We
still
call
it
open
ID,
because
again
it's
about
client
identifier
and
it's
really
close
to
the
issuance
extension.
So
this
is
where
we
actually
allowed
three
different
options
to
counters
the
limitations.
We
faced
so
honest
with
that.
It's
okay
for
client
ID
to
Eco,
redirect
URI.
If
you
don't
know
what
client
they
need
to
use,
but
not
many
people,
it's
the
simplest,
but
not
many
people
do
it
because
of
you
know:
where
do
you
get
the
metadata
from
and
the
answer
to
that
question?
N
Is
we
Define
the
new
parameter
called
client
metadata,
where
you
can
so
in
openly
Federation
example:
the
client
metadata
was
hosted
somewhere
externally,
but
it
also
enabled
an
option
to
actually
pass
the
actual
client
metadata
in
the
authorization
request
right.
As
long
as
that
request
is
signed-
or
you
have
some
additional
mechanisms
to
trust
that
request
or
Origins
coming
from
it's
okay
to
take
out
the
metadata
from
the
actual
authorization
request
right,
so
those
are
the
three
options
we
have
right
now
and
I.
N
But
we
I'm
kind
of
running
ahead
of
myself,
but
I
think
if
we
can
find
a
mechanism
to
combine
this
client
metadata
in
those
authorization
request
idea
with
a
powerful
mechanism
up
in
the
refrigeration
spec
is
giving
us
we're
actually
creating
something
really
powerful,
but
obviously
I
just
just
to
comment
on
the
asterisk.
Obviously
we
are
enabling
pre-registration
to
just
you
know,
so
people
are
not
having
heart
attacks
so
and
recently
what
happened
was
so
I'm
going
back
to
the
credential
issuance
draft.
N
So
that's
where
we
actually
have
to
find
a
new
Grant
type
where
which
is
really
similar
to
job
Fairground
type,
but
there's
no
civilization,
endpoint
and
you
can
take.
You
know
the
token
directly
to
the
Token
endpoint
and
that's
where
I
talked
to
Brian
Campbell,
so
we're
not
doing
something
completely
crazy.
We
said
it's
okay,
not
to
pass
client
ID
in
the
token
request,
so
the
client
is
pretty
much
Anonymous.
So
obviously
it
was
the
association
server
wants
to
identify
the
client.
N
You
don't
have
to
send
the
client
ID
to
the
Token
request,
if
you're
not
even
doing
authorization
request
right
and
I
can't
put
it
on
the
slide,
but
my
actual
motivation
to
bringing
it
up,
because
there's
some
really
interesting
but
might
be
dangerous,
workarounds
happening.
And
what
I
mean
is
all
those
data
points
I've
given
are
great,
but
the
limitation
is
that
existing
authorization
service
existing
ones
right,
probably
can't
do
it
because
they've
implemented
RFC
6749.
N
So
authorization
servers
are
encouraging
the
clients
to
impersonate
each
other
or
what's
happening,
it's
a
pretty
bad
way.
To
put
it.
But
that's
what's
happening
because
there
is
this
limitations
that
I
described
this
relation
servers
are
have
to
spit
out
the
client
they
right
now
what
they
do
they
spit
out
and
allow
multiple
vendors
to
use
it.
So
that's,
my
actual,
you
know
motivation
to
bring
it
here
because
you
know
I'm
a
bit.
N
You
know
I
understand
why
it's
happening
but
I'm
a
bit
scared
that
it's
happening
so
right
so
kind
of
going
back
to
two
questions:
I
posted
in
the
beginning,
you
might
disagree
or
maybe
am
I
missing
something
but
probably
four
ways.
The
main
reasons
why
client
ID
is
actually
needed.
Why
I
was
in
you
know:
47
67,
49
I,
don't
know,
I
keep
saying
47
today,
so
time,
client
ID
to
the
list
of
allowed
redirect
Uris
to
prevent
open
redirects.
N
M
M
So
I
think
we
should
I
think
we
should
go
even
go
even
farther
with
that,
which
also
brings
up
an
interesting
point
that
the
security
BCP
also
says
that
clients
should
not
influence
their
own
client
ID
and
that's
for
a
particular
reason
that
has
nothing
to
do
with
this.
But
that
was
for
the
case
where
a
resource
server
might
be
confusing.
This
subclaim
for
a
client
authentication
issued
token
versus
a
delegated
token.
M
M
Okay,
the
other
I
also
wanted
it
back
to
the
beginning
of
your
presentation.
The
another
example
use
case
of
a
scenario
that
leverages
this
is
the
whole
world
of
completely
open
web,
where
there
is
no
trust
chain
available
or
desired,
and
that
would
be
things
like
random
random
person,
spins
up
their
own
WordPress
website.
It's
open
source
software,
they
install
it
themselves.
The
developer
of
Wordpress
has
no
idea
that
it's
happened.
Obviously,
another
random
developer
makes
an
iPhone
app
that
they
publish
in
the
store
to
edit
your
WordPress
site.
M
Obviously,
the
developer
of
the
iPhone
app
has
no
prior
knowledge
of
every
place.
Wordpress
is
installed,
nor
is
that
desirable,
and
vice
versa.
So
in
that
case
you
actually
want
the
WordPress
iPhone
app
to
be
able
to
present
itself
to
an
individual's
own
WordPress
website
and
say
please
I
need
a
token
I
need
to
log
in
and
I
think.
This
is
again
it's
the
same
scenario
where
you
want
information
about
the
client.
M
So,
and
along
those
lines,
there
is
also
a
community
that
I
am
involved
in.
That
has
been
doing
exactly
that
since
about
2014..
So
it's
not
even
new,
so
it's
like
eight
years
of
client
IDs
as
URLs
and
it
has
been
working
and
it's
actually
kind
of
widely
deployed.
There's
a
lot
of
systems
that
use
it.
M
The
the
spec
was
published
as
a
w3c
note
in
2018
it's
called
indiath
and
it
is
essentially
a
way
of
using
oauth
in
that
sort
of
open
web
ecosystem.
I
have
a
blog
post
that
talks
about
it
as
well
kind
of
in
terms
of
looking
at
it
from
the
oauth
side.
I
can
link
that
into
the
jabber
chat
or
whatever,
but
it's
it's
decently
widely
implemented,
and
it
does
exactly
that
client
IDs
are
URLs.
Client
metadata
is
found
from
that
URL.
F
Well,
just
for
context,
I
think
it
was
what
is
what
is
client
ID
used
for
needed
for
I?
Think
one
one
piece
that
was
missing
from
that
list
is:
it's
often
used
for
part
of
the
record
of
the
of
the
granted
authorization
at
the
authorization
server?
That's
how
it
keeps
track
of.
You
know
what
an
individual
user
granted
certain
access
to
a
particular
client,
and
so.
N
B
N
B
F
N
If
we
can
identify
why
client
ID
is
needed
and
kind
of
use
the
list
to
analyze,
you
know
to
say
that,
even
if
they
allow
this
client
ID
as
a
URI
or
bring
your
own
client
ID
model,
you
can
still
use
cliently
for
these
reasons,
so
it's
okay,
like
that,
was
kind
of
why
I
actually
wanted
this
checklist
to
be
here,
because
if
we
can
check
all
that
like
why
not
right
so
yeah
thanks,
like
I,
think
yeah.
No,
this
list
definitely
has
to
be
revised.
N
O
Daryl
Miller-
forgive
apologies
to
the
rest
of
the
room,
as
one
team
at
Microsoft
talks
to
another
team
that
Microsoft
I
think
this
would
be
absolutely
wonderful.
We
have
so
many
issues
in
developer
experience
around
that
initial
app
registration,
and
this
would
allow
us
to
significantly
simplify
onboarding
of
people
using
apis.
It
also
has
an
interesting
effect.
We
get.
We
have
a
lot
of
concerns
around
garbage
collection,
around
app
IDs
that
have
been
created
and
then
never
deleted
and
around
the
consent
issue.
O
C
O
O
K
That
actually
further
goes
to
what
Brian
was
just
saying
and
why
I
was
shaking
my
head
about
it
is
that
you
don't
need
a
client
ID
in
order
to
tie
to
auto
records,
you
need
to
link
to
some
database
row
number
somewhere,
and
that
is
not
a
value
that
needs
to
be
exposed
externally
to
the
protocol.
Generally
speaking,
however,
in
the
oauth
world,
the
entire
oauth
protocol
is
basically
you
start
with
the
authorization
code
flow
right.
K
Everything
else
is
just
kind
of
bolted
on
in
strange
angles,
from
there
and
in
the
authorization
code
flow
as
it
was
classically
defined,
you
had
to
start
with
a
redirect,
as
you
were,
do
going
through
the
fun
Channel
when
you're
going
through
the
fun
Channel,
you
cannot
make
an
authenticated
call
to
the
authorization
endpoint,
but
least
he
couldn't
at
the
time.
I
know.
K
K
We
ended
up
looming
on
the
client
ID
so
hard
that
we
had
to
invent
a
whole
other
set
of
specifications
to
get
a
client
ID
when
you
didn't
have
one,
that's
the
dynamic
registration
side
of
things
right
and,
as
you've
pointed
out
very
very
rightfully
here,
there's
a
whole
bunch
of
use
cases
where
you
start
collecting
all
of
these
client
IDs
that
maybe
you'll
never
see
them
again.
Because
are
you
going
to
really
dynamically
register
every
time
your
spa
reloads
or
you
drop
the
cookie
jar?
K
I
know
people
have
tried
to
do
that
back
in
the
day,
because
that
was
the
only
way
they
could
get
around
things.
It
makes
absolutely
no
sense.
There
are
other
ways
that
we
should
be
able
to
bootstrap
this
trust
environment
into
the
registration
record,
ephemeral
or
otherwise
at
the
As
and
client
ID
is
not
the
way
that
we
should
have
done
it.
All
of
that
said.
K
I
will
also
add,
though,
that
if
you
add,
pushed
authorization
requests
into
the
mix
of
possible
things,
a
lot
of
those
ones
go
away
too,
because
you
now
can
start
talking
about
an
external
identifier
to
that
ongoing
request.
That
is
not
necessarily
tied
to
a
specific
client
external
client
identifier.
K
Within
the
scope
of
the
protocol
itself.
You
are
simply
saying:
I
am
doing
the
next
bit
of
this
part
of
the
protocol
here.
So
if
you're
doing
par,
if
you
are
doing
you
know,
you
know
key
based,
authentication
and
stuff
like
that,
you
don't
actually
technically
need
client
ID
at
all
in
oauth,
except
that
oauth
requires
it.
That's
not
a
requirement.
K
We're
going
to
get
away
from
in
in
oauth
2
anytime,
soon,
I
think
that
the
new
language
in
2.1
is
a
good
step
in
that
direction,
but
anyway
this
is
a
very
long
way
to
say.
This
is
I,
think
good
and
interesting
work.
I
do
think.
However,
we
need
to
really
think
about
this
in
terms
of
the
client
record,
as
opposed
to
or
the
client
registration
or
the
client,
something
as
opposed
to
the
client
ID,
because
we're
using
client
ID
as
the
stand-in
for
all
of
those
different
things,
can.
N
I
quickly,
react
yeah,
yeah,
so
great
points
just
to
react.
So
that's
why
the
question
I
had
both
client.
They
didn't
client
metadata
universe,
but
just
declarified.
The
reason
why
I
didn't
put
the
term
registration
per
set
is
because
I
don't
think
when
the
client
is
bringing
in
its
own
metadata.
It's
actually
registration,
it's
more
of
it.
It
just.
It
didn't
feel
like
the
right
terminology
like
so.
N
K
N
P
P
P
On
top
of
that,
whether
that
be
you
know
limiting
me
based
on
the
policy
you
have
as
an
as
or
proceeding
with
the
transaction,
based
on
what
you
know
me
as
the
client,
so
I
I
would
would
like
to
get
further
feedback
on
at
least
the
draft
that
we
have
started
today,
which
is
all
with
client
discovery
that
was
published
to
the
list.
That
is
conceptually
similar
to
things
like
open,
ID,
Federation
and
all
it
really
does.
P
A
Okay,
I'll
be
short,
so
Christina,
you're,
you're
lobbying
has
been
noted
by
the
open,
ID
Federation
editors.
I
I
will
point
out
that
I
think
there
may
be
a
misperception
that
open
ID
Federation
requires
some
monolithic,
Global
routes,
there's
nothing
that
stops
a
a
client
from
being
its
own
route.
I
mean
that's
a
policy
decision,
so
you
could
have
an
infinite
number
of
roots
and
everybody
could
just
be
their
own
route.
If
that
was
the
kind
of
federation
you
wanted,
so
nothing
actually
stops
you
from
doing
that.