►
From YouTube: OAuth WG Virtual Interim Meeting, 2020-02-10
Description
OAuth WG Virtual Interim Meeting, 2020-02-10
A
So
I
have
a
list
of
a
couple
of
possible
goals
that
could
address
with
this
kind
of
work.
I'd
be
curious
to
hear
from
others
about
why
what
they
see
is
needed
in
terms
of
like
what
are
the.
What
are
the
current
issues
that
you
are
facing
with
the
existing
state
of
things?
As
you
are,
you
know
talking
to
people
and
working
with
with
people
who
are
using
the
specs.
B
A
So
the
challenges
that
I'm,
seeing
when
I'm
talking
to
people
working
people
who
are
building
building
systems,
I'm
primarily
working
with
people
who
are
building
applications
as
well
as
like
client
applications
as
well
as
resource
servers.
Obviously,
as
as
you
know,
I
work
at
Ogden
and
octave
provides
an
authorization
servers.
So
we
don't
typically
work
with
people
who
are
building
authorization,
servers,
we're
building
we're
working
with
people
who
are
building
resource
servers
and
client
applications.
So
they're
really
looking
for
understanding
how
to
architect
the
different
parts
of
their
system
and
how
that
maps
to
OAuth.
A
D
Here
with
these
people,
are
they
really
going
and
look
I'm
just
wondering
how
many
of
them
are
actually
going
out?
Looking
at
the
specs
versus
reading,
you
know
any
of
the
great
write-ups
are.
What
to
do.
You
know
you
guys
have
some
great
write-ups
on
your
site
as
to
other
vendors
in
the
space
yeah.
A
D
D
A
So
what
I
typically
see
is
that
people
definitely
start
with
that
more
easily
discoverable
higher
level.
Summary
version
of
the
documents
of
you
know
whether
that's
the
books
or
blog
posts
or
whatever
it
is,
but
then,
as
people
start
to
get
into
the
specifics
of
it
and
when
there's
when
they
start
making
decisions
about
like
their
own
architecture
in
terms
of
the
different
token
validation
methods
or
things
like
that,
that's
where
people
start
then
diving
in
like
finding
the
specs
and
then
pointing
to
paragraphs
and
being
like
well.
This
says
this:
why?
A
Why
does
it
work
this
way
or
why
don't
you
do
this,
and
that
kind
of
thing,
because
also,
frankly
like
because
there's
so
many
different
ways,
you
can
build
an
authorization
server
and
still
be
technically
oauth2.
A
lot
of
the
things
that
are
in
the
specs,
don't
necessarily
reflect
the
way
that
any
given
authorization
server
works.
So
there's
that
sort
of
that
disconnect
of
people
are
finding
are
referencing
the
specs,
because
they
are
looking
for
the
sort
of
source
of
truth
and
then
wondering
well.
Why
doesn't
that
match?
What's
you
know
in
the
real
world.
E
Well,
this
problem
won't
really
be
solved
by
piling
on
another
layer
to
say
that
people
will
still
like
the
thing
that
you
just
said,
which
does
not
guarantee
Interop
is
absolutely
true
will
remain
true,
even
if
you
aggregate
and
you
put
together
the
latest
and
greatest
okay.
Unless
you
start
producing
profiles,
these
problem
will
not
go
away.
D
Just
listen
to
that
Aaron.
Those
there's
some
choices,
but
you
know
potentially
part
of
the
challenges
as
there's
choices
that
you
guys
have
made
it
octa.
That
makes
sense
for
you
and
what
I'm
hearing
is
that
a
customer
goes
and
read
something
in
the
spec
and
said,
but
I
want
to
go
and
do
X
and
you
guys
say:
well,
we
don't
do
it
and
they
like
what,
but
that's
how
I
want
to
do
X,
and
so
it's
actually
maybe
a
valid
path.
D
F
Guess
it's
good
I
was
just
gonna
jump
in
because
that's
that's
not
really.
What
I'm
hearing
is
that
this
would
be
like
anything
provider
specific
this-
and
this
was
a
big
part
of
the
side.
Conversation-
is
that
this
would
be
trying
to
capture
what
the
group
is
largely
considered
to
be
best
practice,
because
you've
already
we've
already
got
documents
like
you
know
persons,
security
document,
the
new
one
that
are
saying
to
do
things
in
a
certain
way
in
to
do
things
that
are
technically
allowed,
but
cause
problems
and
to
not
do
them
for
specific
reasons.
D
Know
I
wasn't
wasn't
trying
to
insinuate.
The
doctor
was
trying
to
say
that
the
standard
should
be
something
to
talk
to
specific
I
was
digging
more
into
what
the
problem
is
of
going
from
what
the
customer
confusion
is,
and
it
seemed,
and
maybe
I
misheard.
What
you're
saying
here
in
part
it
was
as
they
look
at
what
you're
offering
and
then
they
see
things
in
the
spec
that
are
different
than
what
you're
offering
and
they're
confused,
and
so
the
the
difference
could
be.
D
Those
are
some
choices
around
how
to
implement,
which
I
think
as
part
of
what
Victoria
was
getting
at
is
that
there
are
choices
around
what
to
do
and
since
it's
a
framework,
there
was
a
number
of
different
choices,
and
so
one
area
of
confusion
is
choices
that
octa
made
about
what
to
implement
and
the
other
area
confusion.
It
can
be
choices
that
octaves
made
because
that's
the
best
security
practice,
which
would
be
common
for
everybody.
So
of.
G
A
D
I'm
not
trying
to
do
that
I'm,
just
I
find
it
useful
to
dig
into
you
have
customers
that
have
a
problem.
So
let's
really
understand
what
the
problem
is
to
make
sure
that
what
we
deliver
solves
that
problem
right
and
so
it
it
could
be
that
it's
better
octa
documentation
or
it
could
be
that
there's
I
understand
the
proposal
I'm
just
wanting
to
make
sure
that
it
actually
solves
what
the
problem
is.
Yeah.
A
Well
and
I
think
there's
there's
a
couple
of
different
problems
here
that
are
sort
of
all
bubbling
up
at
the
same
time.
So
there's
a
couple
different
angles
to
it
and
the
other
part
of
it
is
when
someone
you
know
when
someone
picks
up
a
library
or
looks
or
looks
at
a
different
observation
server.
You
know
evaluating
three
different
open-source
authorization
servers
and
they're
all
labeled
Oh
auth.
A
It
turns
out
that
that's
actually
like
almost
meaningless
at
this
point,
because
there's
so
many
different
ways
it
could
work
when
in
reality,
what
this
group
is
doing
is
actually
especially
with
latest
security.
Bcp
is
actually
documenting
a
relatively
restricted
profile
of
what
was
published
in
2012,
so
I
think
that's
also.
A
The
one
of
my
other
goals
here
is
that
we
in
reality,
if
this
group
is
saying
here,
is
a
more
secure
way
to
be
doing
this
overall,
and
it
would
be
nice
if
there
was
a
label
for
that,
so
that
when
there
is
code
published
either,
you
know
anything
from
a
product.
That's
a
company
sells
to
an
open-source
library
to
an
open-source
product
or
whatever.
We
can
capture
that
and
say
like
yeah.
This
does
actually
follow
the
latest
recommendations
that
this
group
has
published
so.
E
B
E
A
D
A
Exactly
so,
and
one
of
the
examples
of
this
I'm
seeing
already
happening
is
people
are
updating,
servers
or
client
libraries
to
support
OAuth
2
with
pixee
for
single
page
apps
like
that
and
that's
a
whole
long
label
that
there
are
now
like
documenting
as
pull
requests
or
opening
issues
against
few
requests.
People
you
know,
support
authorization
code
plus
pixie
for
this
use
case,
which
is
something
that's
in
the
security
BCD
right,
I.
H
H
What
I
have
observed
in
the
market
is
that
people
are
not
really
aware
of
the
PCP
if
they
are
searched
for
specification
and
they
will
end
up
with
RC
67
49,
and
what
I
would
like
to
ensure
is
that
anyone
that
is
searching
4000
of
specification
will
somehow
come
across
this
new
rule.
Is
this
new
profile?
So,
from
my
perspective,
the
best
way
would
be
to
come
up
with
an
update
for
RFC
67
49,
or
at
least
some
annotation
in
the
RFC.
That
tells
here
are
new
rules.
H
You
should
follow
those
rules,
because
that's
what
the.oh
of
our
working
group
came
up
with.
That's
that's
my
my
primary
my
primary
interest,
because
what
I
have
seen
in
the
in
the
last
couple
of
years,
when
I
was
working
with
open
making
initiatives,
they
do
not
know
any
other
specification.
Beside
RFC
67
49,
that's
that's
a
real
big
problem.
From
my
perspective,
I
said
in
D
and
the
in
the
site
meeting
in
Singapore.
For
my
perspective,
I
am
really
satisfied
and
happy
once
we
do
not
need
security
BGP
any
longer.
H
A
E
Change
with
spec
vary
any.
Let's
say
that
we
know
it's
gonna,
be
very,
very
expensive
to
change
the
car
I
think
about
Thorson
suggested
something
that
might
be
a
great
compromise,
which
is
to
have
references
to
the
BCP
directly
from
there
from
the
course
back,
so
that
the
discoverability
problem
is
solved.
E
But
if
we
were
to
try
to
actually
update
this
back,
I
think
that
they
will
take
quite
a
long
time
because
the
restrictions,
what
we
are
doing
for
security
reasons,
are
valid,
but
at
the
same
time
I
think
that
there
might
be
situations
in
which
people
have
a
mitigating
circumstances,
which
cannot
be
generalized,
but
they
do
apply
to
that
specific
case
and
making
that
choice
away
from
them.
It's
gonna
be
hard,
I
think
it's
possible,
but
it
will
lead
to
a
lot
of
discussion.
So
I
think
about
that.
C
Like
from
my
time,
we've
been
spending
a
lot
of
time,
profiling,
the
use
of
box
for
large
enterprise
environments,
writing
down
what
requirements
we'd
expect
yeah.
So
some
clients
and
resource
servers
to
the
right,
sir,
obviously
pointing
at
RFC
67
49,
isn't
sufficient
and
I
think
the
working
groups
already
done
most
all
of
the
hard
work
of
writing
down.
What's
expected,
it's
just
littered
across
a
whole
bunch
of
documents,
and
certainly
a
lot
could
be
updated
to
it.
2.1
that
incorporates
all
that
and
we
can
go
out
there
and
say
hey.
C
G
C
B
C
Whatever
of
what
products
expected
to
me,
obviously
Oh
a
few
dot
o
at
as
it
is
in
the
RFC
67
49,
isn't
sufficient
I'm
trying
to
point
out
all
these
other
working
group
documents
word
for
what
to
do.
It
makes
things
very
complicated
so
right
if
there
were
one,
preferably
ITF,
bless
documents
that
was
conveyed
all
these
conveyed
the
most
up-to-date
consensus
on
what
to
do
on
both
for
those
procurement
reasons.
C
D
I
think
what
he's
saying
is
that
he
doesn't
want
a
list.
Oh
it's
a
ought
to
with
the
BCP
and
pixie
and
JWT
like
there's
a
whole
large
list
of
things
which
makes
it
hard
for
people
to
understand,
and
so
I
think
that
you
know
what
feel
free
to
correct
me.
If
I'm
wrong
Michael
is
it
you
want
a
crisp
answer
saying
we
would
like
something:
that's
aa,
2.1
compliant,
and
everybody
knows
what
that
means,
because
there's
a
document
about
that.
C
Yeah
I
think
I'd
still
be
a
debate
to
have
of
how
much
text
would
be
duplicated
and
that
document
versus
that
one
document
just
pointing
at
other
things,
son,
it's
a
very
least,
could
be
nice
if
it
removes
all
the
things
in
the
law
to
datos
that
we
don't
think
are
acceptable
to
do
anymore.
It
referred
to
other
documents,
but
you
should
do
pixie,
it's
the
stretch
here,
etc.
That's
that,
especially
that
would
be
fine
versus
just
duplicating
alt
text.
D
C
Right
yeah
and
we're
trying
to
write
that
down
for
enterprise
use
it's
one
thing
for
us
to
put
it
in
a
document
like
a
miter
label
on
it
or
some
government
label
on
it
or
whatever
and
share
it.
This
message
certainly
comes
across
much
nicer
if
it
has
a
ITF,
a
label
on
it
and
I.
Think
the,
although
I
think
pretty
much
the
hard
work
has
been
done
by
the
working
group
already
is
just
a
matter
of
putting
it
all
together
into
one
place.
So.
D
If
I
read
between
the
lines,
it
sounds
like
you're
thinking
that
well,
those
might
be
best
practices
most
of
the
time,
but
some
of
the
time
some
of
these
other
things
are
what's
right
in
a
particular
situation,
and
so
maybe
you
have
some
concerns
that
that
2.1
document
might
be
too
restrictive
and
then
not
allow
people
or
cause
confusion
for
people
that
are
trying
to
do
something
and
saying
well,
like
you
want
me
to
do
X,
but
it's
not
in
2.1.
So
why
are
you
suggesting
I?
Do
that
so.
F
I
want
to
point
out
not
to
jump
on
vittorio
here,
but
I
want
to
point
out
that
anything
we
do
with.
If
you
don't,
one
does
not
dotto
as
an
option
either
from
the
marketplace
that
were
from
the
standards
world.
So
it's
me
that
is
the
obvious
answer.
Is
you
want
to
do
something
that
is
allowed
in
2.0
and
not
in
2.1?
Well,
say:
you're
doing
2.0
and
not
2.1.
D
Yeah
but
I
think
part
of
you
know
and
I'm
reading
between
these
lanes.
What
Victoria
is
saying
is
that
it
causes
confusion,
similar
confusion
on
the
click
that
that
the
2.1
solves
by
saying.
Well,
here's
what
to
do,
but
then
this
confusion
to
other
people
where
if
the
Tory
is
saying
well,
go
ahead
and
do
this
and
then
he's
arguing
with
customers
and
saying,
but
but
that's
not
in
2.1,
but
I'm
gonna.
Let
vittorio
chime
in
here
now.
E
Thanks
so
the
main
thing
that
I'm
concerned
about
is
there
is
ReWalk.
That's
to
say
that
to
me,
the
the
bar
for
changing
the
car
and
I
know
that
there
is
version,
so
one
might
say,
I'm
seeking
but
yeah.
In
my
experience.
In
reality,
it
usually
doesn't
work.
Let's
say
that
especially
people
that
don't
really
know
about
lis
space
they'll
just
go
for
the
latest
because,
like
that's
a
safe
way
of
thinking
about
it,
so
we
love
a
discussion
anyway.
But
to
me
the
main
challenge
is
I
suspect
the
vector
we'd
get
a
similar
effect.
E
If
we
just
have
this
day
helping
people
to
navigate
the
various
options
and
I
think
that
a
lot
of
the
work
that
has
been
done
for
security
and
for
enterprise
are
for
a
fleshing
out
specific
cases
that
are
very
important.
But
the
bringing
this
back
to
the
car
would
be
shoving
down
the
fruit
of
everyone.
They
characteristics
of
us
cases,
that's
really
I'm
partial
to
the
enterprise
cases.
So
it
would
work
well
for
me,
but
I
don't
know
if
it
would
be
serving
well.
E
The
community
by
I'd,
say
generalizing,
most
particular
cases
to
everyone
and
the
other
challenge
with
a
Yowie
is
when
it's
mostly
vector.
These
will
take
a
lot
of
work
for
basically
somehow
redoing
things
that
we
are
already
done
rather
than
working
on
new
stuff.
Okay,
in
the
end,
everyone
as
someone
to
limited
bandwidth,
and
so
given
that
we
already
like,
if
we
have
a
goal
of
helping
people
to
adopt
the
specific
things
that
we
need
for
Mississippi
and
others.
E
A
So
those
specifics
I
think
we
can
leave
the
specifics
of
that
up
to
like
when
we
actually
would
start
this
work.
Because,
that's
you
know
just
a
matter
of
documenting
what
goes
where
but
I.
Think
overall,
yeah
I
agree
with
the
goal
that
we're
not
I,
don't
want
to
try
to
I,
don't
want
to
make
things
more
burdensome
for
people
who
don't
need
to
implement
something,
because
it's
not
relevant
to
the
implementation.
That
makes
sense.
I.
I
Think
it's
going
to
be
those
types
of
specifics,
though,
that
that
become
difficult
to
reach
agreement
on
when
we
actually
get
into
the
work.
If
we
were
trying
to
do
something
like
a
2.1
where
you
could
say
so
what's
been
expressed
by
somewhere,
you
could
stamp
it
as
2.1
compliant
and
some
sort
of
perceived
guaranteed
interoperability
about
that
I
think
those
specifics
will
actually
turn
out
to
be
very,
very
difficult
to
come
to
agreement
on
and
I
guess
I
would
echo
Vittorio
said
about
you
know
what
what's
maybe
most
useful.
I
That
would
that
would
help
somebody
navigate
them
and
understand
what
they
need
to
do
and
why
it
may
not
achieve
all
the
ends
that
that
people
are
looking
for
here,
but
I
think
it
might
be
the
most
obtainable
output
work
and
one
that
has
the
most
value
relative
to
the
amount
of
work
that
would
be
required
to
go
into
something.
To
think
about.
H
I
H
Don't
think
it's
gonna
be
easy:
okay,
I
think
we
do
is
gonna
be
easier,
and
once
we
open
that
for
a
new
version
of
the
publicity
new
RC,
a
lot
of
desire
will
pop
up,
but
I
would
intentionally
keep
first
of
all.
I
would
differentiate
different
types
of
documents,
so
my
first
goal
is
to
really
clean
up
date.
The
confusion
that
might
might
be
caused
by
the
fact
that
the
RFC
and
then
the
BCP.
H
H
Our
office
is
very
flexible
when
it
comes
to
implementation,
because
we
focused
on
only
getting
the
stuff
in
the
RFC
that
is
required
for
in
rabaa
polity
from
a
client
to
a
s
perspective
perfect
under
the
hood.
You
can
have
tremendously
different
implementations
and
would
really
object
against
limiting
the
flexibility
so
I'm
not
looking
for
a
2.1
that
really
incorporates
all
those
different
bits
and
pieces
because
they
have
they
all
are
required
in
different
circumstances
and
regarding
interoperability.
H
Rfc
67,
49
is
is,
is
not
really
interoperable
on
an
on
a
on
a
on
a
bit
level,
with
the
things
that
we
have
specified
in
the
security
PCP
become
weakened.
We
are
getting
a
bit
closer
to
interoperability,
because
we,
for
example,
have
a
more
precise
world's
round
redirect
uija
matching,
which
was
impossible
to
implement
in
a
noble
profession
previously,
so
a
bit
more,
the
interoperability
is
possible.
H
A
Thanks
I
agree
with
that
and
I
think
that
also
addresses
some
of
the
concerns
from
others
as
well,
because
yeah
we,
the
flexibility,
is
good
in
that
it
lets
people
build.
You
know
you
repurpose
it
for
different
things
in
interesting
ways
and
build
onto
it,
but
it's
just
there's
too
much
flexibility
in
the
core
and
and
I
think
the
security
BCP
gets
it
right
where
there's
flexibility
in
the
right
places,
but
still
locks
down
enough
of
the
sort
of
basic
stuff
to
make
it
secure.
J
H
H
That's
my
basic
and
fundamental
problem,
and
the
second
thing
is
even
if
they
know
it
exists,
they
potentially
don't
understand
what
the
relationship
is
between
RFC
67
49
and
the
security
PCP,
and
they
potentially
don't
understand
the
felt
conflicts
between
those
documents.
So
that's
why
I
want
to
want
to
clean
it
up
and
by
the
way
you're
really
not
really
loud.
So
can
you
speak
up
a
bit?
Sorry.
J
H
Don't
know
whether
the
label
to
that
one
is
critical.
I
think
I
said
that
in
the
beginning,
what
I
would
like
to
achieve
is
that
if
someone
looks
up
a
wall
and
lands
at
and
RC
67
49,
there
should
be
a
something
telling
this
person
hey,
here's
something
you'd
take
you
need
to
take
into
consideration
could
be
another
RC
could
be,
could
be
linked
to
the
security
BCP
I'm
I'm,
really
open
right
deep
into
it
within
within
within
my
heart.
H
A
Would
I
would
like
to
find
out?
One
of
the
other
concerns
I
have
about
any
sort
of
guide.
Is
that
it
looks.
It
looks
optional.
It
looks
informal
and
I'm
even
seeing
this
with
a
security
BCP
right
now,
which
is
that
people
look
at
it
and
then
they
say:
oh
well,
it's
just
a
BCP
and
so
I
don't
have
to
do
it
and
then
they
like
ignore
significant
parts
of
it
when
in
reality,
the
message
we're
trying
to
send
with
that
is.
E
Busy
being
itself
something
in
which
we
say:
okay,
this
one
would
be
the
ideal
situation,
but
that
if
there
is
someone
whatever
I
okay,
unless
we
override
the
core
I
think
we
are
saying
okay.
Now
we
would
like
everyone
to
do
what
the
Mississippi
does
in
all
cases,
in
all
scenarios,
regardless
of
their
particular
scenario,
that
it
seems
better
that
would
be
forcing
math
on
them.
I
think.
A
E
So
I
think
the
difference
is
right
there,
if
like
putting
a
master
in
the
BCP
or
putting
a
mass
in
the
car,
there
kind
of
discussion
that
occurs
I
would
expect
it
to
be
different
same
a
DCP
as
this
kind
of
flexibility,
whereas
if
he
said
you
bring
it
back
to
the
carvanha,
it's
a
true
master,
then,
at
that
point,
I
think
with
the
number
of
things
that
we
are
a
BCP
might
end
up
being
a
really
discussed.
So.
A
Am
I
misunderstanding,
the
purpose
of
a
PCP,
then
cuz
I
thought
this
was
meant
to
be.
This
is
what
both
2.0
should
be
now,
and
this
is
a
mechanism
to
accomplish
that
in
that,
in
this
document
format
is
this:
how
we
accomplish
that,
and-
and
we
really
are
saying-
if
there's
a
must
in
here-
it's
it's
equivalent
to
a
must
in
the
core
assuming
you're
following
both
documents.
That's.
H
Also
my
perception
and
I
I'm
remembering
the
discussions
we
had
around
some
of
the
statements
in
the
BCP
and
we
had.
We
had
longer
and
harder
discussions.
Then
I
can
remember
when
we
did
RFC
67
49,
so
from
the
working
groups,
behavior
I
would
accused
everybody
was
assuming
hey.
We
are
updating
the
RC.
E
G
E
My
understanding
was
maybe
CP
is
a
different
type
of
document
than
the
core
in
itself,
then
I'm
sure
that
everyone
is
a
different
perception
on
this,
and
also
they
remember
that
there
were
discussions
about
like
the
deprecation
of
their
Apogee
and
things
like
people
were
saying:
yeah,
it's
okay
to
do
it,
and
maybe
CP,
because
we
are
not
really
doing
these
in
the
car.
So
I
think
there
might
be
some
some
clarification
to
be
made
here,
not
just
among
ourselves,
but
also
for
the
community.
As
in
what
BCP
means
I
mean.
H
In
the
end,
I
would
not
assume
that
everyone
that
is
and
is
in
the
Security
VCB
would
all
would
automatically
go
into
an
ER
RFC.
We
would
go
through
dinner,
the
whole
working
group
process
again,
so
we
could
have
all
the
discussions
that
are
needed.
Just
having
said
that
in
the
beginning,
the
security
PCP
are
didn't
have
the
objective
that
it
ended
up
having
now.
H
There
is
a
reason
why
this
document
still
is
titled
security
topics
and
not
security
PCP,
because
when
we
started
in
2015
it
was
exactly
that
a
laundry
list
of
things
that
we
need
to
do
cup
with,
and
we
already
at
that
time,
had
a
discussion
whether
we
should
update
the
RC
or
do
a
BCP
and
then
over
time.
This
thing
evolved
into
a
PCP.
So
there
is
a
lot
of
history
that
one
need
to
take
into
consideration
to
understand
why
we
came
up
with
the
BCP
and
not
updated
RC.
E
Like
I
keep
hearing,
people
are
saying
that
the
big
problem
is
discoverability
and
I
really
think
that
by
embodying
references
in
the
car
and
language
that
says,
you've
got
to
read
that
these
are
the
things
might
actually
solve
a
discoverability
problem.
Then
we
might
still
like,
of
course,
there
will
be
more
confusion
than
if
we'd
actually
horn
down
a
document
and
they're
selectively
bring
things
in
and
have
a
new
version
of
a
car.
I.
E
A
A
D
Well,
it
sounds
like
one
of
the
problems
that
I've
heard
a
couple
people
say
is
having
a
crisp
prints
of
saying.
You
know:
here's
what
we
want
to
have
built
for
us,
or
you
know,
here's
what
I
want
to
buy
and
someone
else
beyond,
say:
well,
here's
what
I
deliver
and
in
a
way
that
clearly
communicates
what's
happening
as
opposed
to
what's.
D
What's
there
now,
Aaron
I
was
wondering
whether
sort
of
a
wrapper
document
that
maybe,
if
it's
called
say
it's
called
2.1
but
doesn't
replicate
much
if
any
text,
but
really
said
you
know
in
the
67
49
it
would
be
pointed
to-
and
this
new
RFC
would
say
here
is
2.1,
which
is
these
parts
of
67
49.
These
best
practice
is
this
and
this
and
this,
and
so
it's
more
of
a
collection
of
we're
all
to
go
as
a
starting
point.
D
A
But
I
do
want
to
settle
on
like
what
are
the
problems
that
we
would
be
addressing
with
whatever
formats
that
would
take
and
I
think
you've
just
described
a
totally
valid
option.
As
you
know,
a
format,
something
that
the
like.
The
important
thing
is
that
I
think
the
two
key
problems
that
were
we're
consolidating
on
our
discoverability
and
the
definition
of
functionality
right
so
having
a
label
that
describes
a
set
of
functionality.
A
E
Example,
Emma
TLS
super
useful
necessary
for
certain
scenarios,
probably
not
part
of
the
call.
So
if
you'd
have
a
nice
discoverable
guide,
aggregator
like
I,
like
the
thing
with
geek
said
but
like
adding
on
top
of
it
like
these
aspect
of
those,
are
the
other
specs
with
a
relevant
for
these
particular
scenario,
and
those
are
the
parts
that
you'd
want
to
do.
That's
something
useful,
but
not
necessarily
something
about
these
are
actually
called
so
I,
don't
know
how
it
will
be
positioned
or
labeled.
B
D
G
D
H
Go
one
step
further
I
mean
we
are
at
least
talking
about
two
different
documents
and
I
strongly
agree
with
Vittorio
I,
wouldn't
really
Archon
flight
updated
core
whatever,
with
this
kind
of
umbrella
document.
That
gives
you
an
overview
on
all
the
bits
and
pieces
that
you
could
use
for
the
various
use
cases.
D
H
So
the
December
document
is
kind
of
a
meta
ECT
right
you're,
not
only
describing
a
best
practice
for
a
certain
use
case,
but
you
would
also
have
some
conditions
if
you
want
to
do
that,
you
want
to
do
that.
That's
more
like
it,
like
writing
a
blog
post
or
writing
a
book
about
OAuth
or
a
given
an
architectural
overview.
That's
fine!
Having
that!
That's
really
fine!
H
That
could
be
useful,
but
that's
not
what
I'm
looking
for
I'm
looking
to
to
clean,
update
the
course
back
and
to
align
it
realign
it
with
the
changes
that
we
agreed
on
in
a
security
PCP
to
Mike
people's
life
easier
with
the
core.
So
both
can
both
can
can
can
go
sort
of
side
by
side,
but
I,
don't
not
like
to
conflate
those
okay.
D
G
B
Was
document
didn't
and
maybe
it
would
be
on
you
to
make
it
proposal
if
you
have
time
on
how
such
a
rough
draft
looks
like
based
on
a
discussion
so
because
in
any
case,
have
to
confirm
decisions
on
the
mailing
lists.
As
you
all
know,
and
so
it
would
be
a
little
bit
more
visible
on
where
this
could
be
heading.
Read
I.
A
At
a
draft,
maybe
I
can
work
with
person
on
that
I.
Don't
know
if
Nick
wants
to
volunteer
himself
for
that,
but
I'm
I'm,
happy
to
and
I
think
the
first
draft
would
be
starting
from
6-7
49
and
essentially
applying
the
diffs
in
the
Security
BCP
to
it
that's
what
I
would
do
as
a
first
draft.
That
sounds
reasonable
to
you
Torsten
at
least
it's.
F
D
J
J
B
Of
course,
Leah
and
I
are
always
happy
if
you
guys
do
some
work,
so
that's
that's
excellent.
We'll
obviously
have
to
hash
out
the
details
and
get
an
agreement.
One
question
that
we
at
some
point
in
time
then
need
to
make
on
is
whether
this
would
be
sort
of
like
in
a
classical
form
of
update.
This
would
be
just
a
new
RFC.
H
B
H
B
That
was
a
useful
discussion.
I
took
some
notes,
some
unfortunate
on
paper
because
I,
don't
like
the
typing
well,
when
everyone
is
talking
and
so
will
transcribe
them,
I
enabled
a
recording
if
you-
and
hopefully
that
worked,
and
so
we
could
share
that
with
the
rest
of
the
group,
because
I
see
a
couple
of
the
folks
we're
missing
so
I
vishna,
of
course,
as
always,
lively
mailing
this
discussion
on
any
of
those
topics
so
but
I
would
like
to
thank
you
guys
again
for
joining
and
for
sharing
your
thoughts
on
this
belief.
Interesting
topic.