►
From YouTube: IETF109-GNAP-20201117-0500
Description
GNAP meeting session at IETF109
2020/11/17 0500
https://datatracker.ietf.org/meeting/109/proceedings/
A
Let's
see
if
somebody
said
that
I
have
a
lot
of
noise
in
my
mic
setup.
Does
that
do
you
have
a
lot
of
noise
from
me.
A
B
B
A
B
B
I
live.
This
is
the
note
12.
It
applies
to
virtual
meetings
just
as
much
as
it
applies
to
face-to-face
meetings.
If
you
have
not
read
it
yet,
please
take
a
minute
to
read
it
in
the
meeting
materials
and
a
few
things
that
may
be
new
if
it's
the
first
virtual
idea,
if
you're
joining
so
we're
now
doing
video
at
the
itf
unless
are
presenting
or
even
if
you
are
making
a
comment
to
the
mic,
please
turn
on
your
video.
B
Otherwise,
please
have
your
video
off,
obviously
mute
your
microphone
and
use
reasonable
audio
equipment,
we're
now
doing
blue
sheets.
These
are
taken
automatically
and
there's
no
special
need
to
use
jabra
clients
and
those
are
the
the
same
chat
rooms
as
you
see
in
mexico,
and
here
you
can
see
where
to
go
to.
If
there
are
technical
issues
so
now
blue
sheets,
there
will
be
minutes
on
kodi
md,
the
collaborative
markdown
solution
that
itf
is
using.
B
A
Feel
free
to
just
mention
it
in
chat
if
you're.
A
B
B
B
The
agenda
for
today
and
please
let
us
know
if
you
have
any
comments
and
we
will
start
with
a
process
discussion
which
we're
going
to
camp
in
by
20
minutes.
Then
we
will
spend
the
bulk
of
the
meeting
on
the
core
protocol.
B
The
editors
will
present
the
progress
so
far
and
will
present
specific
issues
that
either
need
more
discussion
and
or
can
be
closed
today,
obviously,
with
with
follow-up
on
the
mailing
list,
and
then
we
will
say
a
few
words
about
next
steps,
all
in
the
next
two
hours,
any
comments
or
questions
to
the.
B
B
B
All
right
so,
where
we're
coming
from
all
decisions
about
the
protocol
and
all
decisions
about
process
are
the
responsibility
of
the
working
group
as
a
whole.
The
chairs
are
only
there
to
call
consensus
on
on
the
working
group
and
the
main
tool
that
the
working
group
uses
to
to
make
decisions
and
to
come
to
consensus
is
the
mailing
list.
However,
many
people
prefer
to
use
github
it's
a
very
efficient
tool
for
threading
issues,
for
example,
and
for
for
tracking
progress
on
different
things
and
obviously
for
managing
the
document
itself.
B
So
there
are
two
rfcs
about
the
use
of
of
github
in
the
itf
and
those
will
be
guiding
us
with
the
goal
being
to
have
maximum
transparency
or,
in
other
words,
more
discussion.
That's
available
for
everybody
to
look
at
and
less
discussion
privately
between
the
editors
and
the
editors
and
the
chills.
B
For
for
many
years,
we
have
managed
documents
on
github,
so
I
think
most
itf
participants
are
used
to
it.
Issue
management
is
more
interesting,
more
recent
and
needs
a
bit
more
clarification,
and
that's
what
we're
going
to
do
here.
B
D
B
On
github,
so
here's
the
proposal
and
starting
from
the
document
itself
today,
we
we
have
only
one
document,
the
core
protocol
over
time
we
will
have
more.
So
if
you
have
small
editorial
edits,
small
comments
that
do
not
change
the
meaning
of
the
document.
B
You're
welcome
to
just
open
a
pull
request
for
that,
and
the
editors
will
pull.
It
will
merge
it
into
the
document,
either.
Editors
or
maybe
other
people
over
time,
but
starting
with
editors
now
will
be
opening
pull
requests
for
all
bigger
changes
and
those
pull
requests
should
reference
a
github
issue
that
the
resolving-
and
this
means
that
we
have
a
review
process
again.
It's
the
primary
responsibility
of
the
editors,
but
the
editors
are
welcome
to
publicize
pull
requests
on
the
list
and
ask
for
additional
reviewers
for
for
pull
requests.
B
We
are
asking
the
editors
to
publish
at
least
once
per
idf
period
so
per
four
months,
but
it's
easy
enough
to
publish
a
new
revision
of
an
internet
draft.
So
please
also
republish
when
you've
gone
through
meaningful,
larger
changes
to
the
document.
We
have
additional
there's
a
wiki
on
github
there's
something
called
github
discussions.
B
Those
are
not
permanent
records
as
far
as
itf
is
concerned.
If,
for
example,
you
want
a
record
of
well
use
cases
which
we
have
not
decided
to
publish,
but
if
you
think
it
needs
to
be
published,
the
only
the
only
way
things
are
published
at
the
ietf
is
as
internet
drafts
and
eventually
rfcs.
B
So,
if
you
think
something
needs
to
be
preserved
for
posterity,
wiki
is
not
the
place
and
it
needs
to
be
published
as
an
internet
draft.
B
Having
said
that,
if
there
are
things
like
use,
cases
that
are
only
needed
while
the
protocol
is
developed
but
over
time
will
not
be
very
interesting,
it's
fine
to
have
them
on
the
wiki
and
the
wiki
actually
enables
tracking
of
revisions
and
so
on.
B
So
this
is
for
documents
for
issues.
What
we
propose
to
do
is
to
go
all
into
the
most
extensive
mode
proposed
by
rfc
8874
issue.
Discussion
mode
were
all
issues
are
in
fact
managed
and
discussed
on
github,
for
if,
if
you
sit
down,
read
the
document
and
have
a
long
review,
please
publish
it
on
the
mailing
list
and
then
the
there
will
be
some
discussion
on
the
mailing
list
and
it's
the
reviewer
who's
tasked
with
opening
issues
on
github.
B
B
The
editors
are
responsible
to
label
issues,
to
tag
issues
as
a
design,
issues
that
are
more
substantial
in
the
editorial
issues
that
are
less
and
we
might
have
more
detailed
labeling
later
on.
We
will
start
with
design
and
editorial
and
and
move
forward
from
that.
It's
for
the
editorial
team.
It's
on
the
editorial
team
to
close
issues
that
are
clearly
resolved.
B
And
this
judgment
call
is
actually
according
to
how
controversial
an
issue
is
things
that
are
more
difficult
should
be
taken
to
the
least
possibly
into
into
meetings
like
this
one
things
that
are
small
and
everybody
discussing
the
issues
have
reached
an
agreement.
B
In
that
case,
it's
it's
okay
for
the
editorial
team
to
close
the
issue,
and
it's
better
to
inform
the
list
that
an
issue
has
been
closed
and
then
again
issue
closed.
There
should
be
a
pr
specific
to
that
issue,
to
implement
it
in
the
internet
draft
and
allow
people
to
review
the
the
final
text.
B
We
ask
that
issues
not
be
reopened
unless
there
was
a
working
group
concern
discussion
and
consensus
to
reopen
the
issue.
Reopening
issues
can
lead
to
too
much
process
churn.
So
please
don't
do
it
if
something
is
important
enough
to
you
that
you
think
it
warrants
reopening
the
issue,
please
bring
it
to
the
mailing
list.
Let's
discuss
it
and
decide
whether
an
issue
needs
to
be
reopened
at
any
time
for
any
issue
either
the
editors
or
the
chose
can
call
for
consensus,
discussion
and
consensus
on
the
mailing
list.
B
B
A
And
please
raise
your
hands
to
get
on
thecube.
D
Yes,
hello,
everyone.
We
had
a
specific
question
for
the
timing
of
the
part.
So
it's
a
bit
specific
because
here
there's
a
more
long-term
view
of
what
we
need
to
do,
and
so
there
was.
D
D
D
A
I'm
seeing
justin
do
you
want
to
speak
to
that
justin?
You
have
a
suggestion.
F
All
right
thanks,
so
I've
actually
got
a
little
bit
of
space
in
the
in
the
editor's
issue.
Discussion
for
exactly
that.
F
The
core
of
fabian's
question,
though,
is
really
about
what
kinds
of
tools
we
use
and
what
we
use
them
for,
and
there
is
this
open
issue
of
terminology
where
a
specific
set
of
tools
has
been
brought
up,
that
we
are
looking
for
feedback
on
what
kind
of
tools
people
are
comfortable
with
using
for
for
the
specific
issue
of
gathering
terminology,
so
I
did
see
wikis
in
the
list
of
available
tools,
but
I
think,
if
I'm
understanding
fabian's
question
is
you
know,
does
that
make
sense
for
gathering
the
the
sort
of
discussion
and
feedback
and
options
and
things
like
that
in
the
wiki
for
the
terminology
itself?
F
So
we
can
talk
about
that
a
bit
now.
I
do
have
some
some
space
in
the
editor's
presentation
of
the
issues
list
for
that
as
well.
A
B
B
C
Yeah,
can
you
hear
me
yes,
yeah,
just
a
quick
clarification,
our
issues
only
to
be
opened
after
you
know,
email
on
on
the
list.
I
saw
the
long
form
discussion.
You
know.
Long
form
review
should
be
an
email
on
the
list
and
then
after
discussion
issues
opened.
Is
that
the
only
time
issues
can
be
opened,
or
you
know
if
you're
just
reviewing
the
draft
piece?
Milk
and
issues
be
open
directly
on
github.
B
I
would
encourage
a
new
issues,
obviously
substantial
issues,
not
editorial
issues
to
first
be
sent
to
the
list,
and
then
you
can
immediately
open
an
issue,
but
it's
important
for
for
people
to
be
aware
of
like
important
things
going
into
github.
A
A
A
Oh,
it's
here,
oh
yeah,
all
right
there
lucy
seems
to
be
having
some
issue
with
mute,
echo.
So
lucy
do
you
wanna?
You
wanna
come
back
if
you
might
have
to
reload
meet
echo
and
come
back.
A
I
we
have
seen
miteko
act
up
at
the
beginning
of
this
itf
meeting
for
for
a
number
of
people,
so
you
know
you're
not
alone,
probably
all
right.
A
Right,
I'm
concerned
about
substantial
work
being
stored
on
git
alone.
Lucy
says,
and
you
know
that
that
is
our
concern
as
well.
It
is
you
know,
it's
a
it's
a
fine
line,
we're
walking
when
we're
using
like
dual
streams:
dual
tools
like
this
all
working
groups
who
try
this
to
have
some
manner
of
issues,
but
you
know
we
hope
that
the
benefits
outweigh
the
the
the
problems
here,
because
we
we
do
expect-
and
we
can
already
see
that
there
is.
A
There-
are
113
issues
right
now,
open
on
github,
there's
a
lot
of
stuff
to
track
without
having
the
benefit
of
tooling
but
yeah
that
that's
a
concern
of
the
chairs
as
well
jaron.
Would
you
do
you
want
to
say
anything
about
this.
B
A
G
I
was
wondering
how
we're
going
to
link
discussions
on
the
mail
list
with
issues
in
github
right.
If
you've
got
a
big
review,
it
might
actually
be
better
to
open
all
the
issues
and
then
post
something
to
the
mail
list
where
you
have
a
link
to
each
of
the
issues
at
each
point,
you're
making.
So
people
can
sort
of
see
holistically
your
whole
review,
but
they
know
which
issue
in
the
in
github
is
related
to
the
point
you
made
in
the
mailing
list.
B
G
A
Looks
like
right
exactly
and
when
you
as
sierra
said
when
we
close
issues.
We
expect
that
to
happen
right
in
conjunction
with
like
an
update
to
the
to
the
text,
so
the
review
team
could
can
mirror
back
right.
The
conclusion
of
a
discussion:
okay,.
A
Or
I
should
say
the
editor
team,
not
the
review
team,
all
right
too
early
in
the
morning
for
me
all
right,
you're
on.
Should
we
move
ahead,
I'm
not
seeing
anyone
anyone
else
in
the
queue
I
do
see.
Braun.
A
On
so
roman,
pointing
out
that
consensus
must
be
on
the
main
list,
which
is
absolutely
true
and
bron.
I
I
don't
know
if
you
want
to
say
people
who
haven't
had
audio
issues.
Can
you
speak
up
at
the
list?
I'm
not
going
to
mirror
everything
too
or
speak
up
at
the
queue
I'm
not
going
to.
B
Otherwise,
let's
move
on
so
justin
you're
next.
F
F
Yeah,
I'm
just
getting
meat
echo
to
play
nice
here.
I
will
also
go
on
video,
sorry
about
the
infinite
windows
there.
We
go.
Okay,
all
right.
F
All
right,
I
think,
we're
good.
Can
you
guys
see
the
slide
back?
This
is
also
uploaded
to
the
meeting
materials
page,
all
right,
so
hello,
everybody
good
evening
and
good
morning
and
good
middle
of
the
night.
In
my
case,
this
is
the
editor's
update
for
gnapp
for
ietf,
109
virtual,
so
yeah
welcome
to
gnapp.
Let's,
let's
get
moving
here
a
little
bit
of
background.
First,
I
want
to
remind
everybody
that,
even
though
we're
working
in
a
similar
space,
we
are
not
working
on
extensions
to
oauth
2.
F
So
this
is
a
philosophy
that
should
be
guiding
our
decisions
just
because
we
did
something
one
way
in
oauth.
2
does
not
mean
we
need
to
do
it
the
same
way
here
we
really
need
to
be
taking
a
step
back
from
what
oauth
2
does
and
asking
ourselves.
Is
this
the
same
way
that
we
want
to
do
it
now?
But
that
also
doesn't
mean
that
we're
going
to
ignore
everything
that
we've
learned
over
the
last
decade
of
oauth
2.,
also
because
this
has
come
up
a
bit
recently.
F
People
have
been
talking
about
this
work
as
oauth
3..
I
want
to
remind
everybody.
This
is
not
oauth
3.
oauth
3
is
not
real,
at
least
not
yet.
If,
at
some
point
the
oauth
working
group
decides
to
start
oauth
three,
it
could
start
it
based
on
app,
could
start
it
based
on
something
else,
and
but
right
now
this
is
gonna
happen.
F
Gap
is
gonna,
happen
no
office
off
and
they
are
separate
things
also
keep
in
mind
that
everything
that
we
do
here
you
know
we
are
not
supplanting
oauth
2.,
it's
not
really
going
anywhere.
It
solves
a
lot
of
use
cases
and
it's
been
around
for
a
decade,
but
it
has
its
limits
because
it's
been
around
for
a
decade,
and
this
is
our
opportunity
to
take
a
look
at
moving
beyond
what
oauth2
has
really
enabled
us
to
do.
F
There
are
some
core
design
considerations
about
everything
that
we're
working
on
in
this
protocol.
Fundamentally,
this
is
a
protocol
for
negotiating
access
between
multiple
parties
in
multiple
roles
we
need.
We
have
decided-
and
a
lot
of
this
comes
from.
You
can
dig
into
the
charter
text
that
we
we
debated
and
came
to
consensus
on.
A
lot
of
our
work
is
going
to
be
around
making
the
interaction
methods,
for
you
know
getting
humans
in
the
security
process,
validating
the
client's
software.
F
That's
going
to
be
talking
to
all
of
these
things
and
sort
of
transferring
trust
into
them,
methods
for
tying
keys
into
the
various
messages
which
can
authenticate
the
client
software,
but
also
do
general
key
presentation
for
a
lot
of
different
things.
I
mean
we
really
want
to
bring
the
cryptic
the
cryptographic
trust
up
to
the
four
here
and
also
we
really
need
to
look
at
the
underlying
data
models,
particularly
of
the
things
that
are
being
requested.
F
So,
as
the
working
group
knows
between
the
last
meeting
and
now,
a
design
team
was
formed
by
the
chairs.
We
met
a
number
of
times
over
a
few
months
and
created
a
draft
that
has
been
accepted
as
the
working
group
starting
point.
F
There
are
three
editors
I
believe
all
three
of
us
are
on
the
call
I
saw
aaron
and
fabian
in
the
in
the
list
there,
and
you
guys
heard
robbie
in
a
minute
ago
and
myself
as
well
will
be
serving
as
editors
of
the
document,
which
means
it
is
our
job
to
express
and
codify
the
working
group
consensus
and
and
sort
of
help
move
that
forward
and
in
the
current
document
there
are
lots
of
notes
and
sort
of
decision
points,
because
one
of
the
things
with
the
working
group
is
we
knew
that
it
wasn't
final
now.
F
Those
issues
as
yarn
was
just
talking
about
are
going
to
be
tracked
in
github
going
forward,
and
I
do
think
that
that
is
the
right
tool.
It
is
a
really
good
tool
for
managing
this
kind
of
stuff.
There's
also
a
couple
of
test
implementations
already
in
the
work
for
for
the
current
draft.
I
have
an
implementation.
I
know
a
number
of
other
people
who
are
starting
to
implement
various
parts
of
this
because
remember
this
is
the
ietf.
F
F
So
the
design
team
output,
a
single
document
which
was
the
direction
of
the
chairs
and
really
to
give
us
a
starting
point.
This
is
something
that
combines
functional
aspects
of
what
was
known
as
x,
y
z
and
x
off
the
two
individual
drafts
that
both
myself
and
dick
hart
had
authored
as
inputs
into
the
working
group
and
the
goal
of
the
design
team
was
to
create
a
single
cohesive
protocol,
but
not
something
that
was
final
output.
F
Lots
of
work
ahead
of
us
and
even
though
what
was
in
draft
zero
kind
of
makes
sense
as
it
is,
that
doesn't
mean
that
that's
the
best
that
we
can
do
well,
we
don't
think
it
is
which
is
what
our
job
as
a
working
group
is
going
to
be,
is
to
now
take
this
single
protocol
and
you
know,
move
things
forward
and
if
you
had
implemented
either
xyz
or
x
off
previously
you'll
notice
that
the
nap
core
protocol
isn't
directly
compatible
with
either
of
those.
F
It
pulls
things
from
both
of
those
and
there's
still
there's
still
a
lot
that
we
need
to
sort
out
in
both
draft
zero
and
one.
So
currently,
the
draft
is
at
version
version,
one
which
is
still
very
close
to
the
design
team's
output.
There
are
a
number
of
editors
notes
peppered
throughout
the
document
92.
F
Now
these
are
only
for
the
editors
notes
that
were
doing
this,
because
the
idea
of
the
editor's
note
was
to
provide
sort
of
a
record
of
a
decision
point
for
the
group
to
talk
to
talk
about
at
least
start
the
conversation
about.
We
don't
plan
on
peppering
the
draft
document
with
links
into
github
going
forward,
although
we
can
definitely
do
that
when
there
is
a
long-standing
issue
or
a
number
of
different
options,
or
something
that
the
group
is
still
in
the
process
of
discussing.
F
So
that's
something
that
the
editors
are
going
to
be
able
to
leverage
going
forward.
But
right
now
we
wanted
to
pull
all
of
the
editor's
notes
out
of
the
document,
because
having
them
in
the
document
means
that
they're
kind
of
static
and
we
can't
really
have
an
ongoing
reflected
discussion
on
them.
F
So
those
are
all
in
github
issues.
Now
the
editor's
process
yarn
was
talking
about,
so
the
editors
have
met
now
and
everything.
Every
single
change
to
the
document
is
going
to
be
going
through.
Pull
requests
so
you'll
be
able
to
see
individual
change
sets
over
time
and
the
editors
are
doing
a
a
self-imposed
requirement
of
review
from
at
least
one
other
editor,
even
for
simple
editorial
changes
like
typo
fixes
and
things
like
that,
because
it's
better
to
have
more
eyes
on
it.
F
Even
for
something
simple
like
that
to
make
sure
that
we're
not
you
know
doing
something
that
we
don't
intend
here,
all
substantial
changes
which
includes
any
substantial
pull
requests
that
change
normative
text
and
things
like
that
need
to
be
verified
on
the
list
and
finally,
we're
going
to
be
tagging
every
single
document
release
in
the
repository
so
that
you'll
be
able
to
diff
the
source
between
multiple
things.
Now,
speaking
of
the
source,
currently
it
is
markdown
using
the
cram
down
rfc
2629
project.
F
We
are
going
to
be
checking
in
the
markdown,
but
we
will
not
be
checking
in
the
xml
html
and
text
files
into
into
github.
Those
will
be
part
of
the
normal
ietf
draft
release
cycle,
so
we
will
be
generating
the
xml
and
data
tracker
will
handle
all
of
those
archival
and
human
readable
versions
of
that
the
repository
has
a
docker
file
and
a
build
script.
For
you
guys
to
be
able
to
build
this
on
your
own.
It
currently
will
generate
the
html
file,
and
you
know
if
you
are,
if
you
are.
F
You'll
be
able
to
do
that
without
having
to
install
all
of
the
ruby
and
python
libraries
to
actually
make
this
run.
Okay,
also
heads-up
chairs.
With
this
with
this
up
on
my
screen,
I
can't
actually
see
the
cue
or
anything
so
feel
free
to
chime
in,
if
I
need
to,
if
I
need
to
shut
up
for
a
minute,
and
we
need
more
discussion,
all
right,
awesome.
Thank
you,
life,
okay,
so
the
editors
wanted
to
talk
about
a
couple
of
different
specific
issues.
F
F
So
if
there's
something
that
needs
to
needs
to
change
or
there's
something
that
needs
to
be
discussed,
you
know
please
open
an
issue,
and
so,
but
as
as
for
what
yarn
said
a
few
minutes
ago,
if
it
is
a
substantive
discussion
of
like
hey
this
is
this
is
a
decision
point.
We
really
need
to
make
like
that
decision.
That
discussion
has
to
at
least
have
an
artifact
on
the
list
to
make
the
list
aware
of
it
that
there
is
a
substantive
issue.
F
F
You
know
our
internal
review
with
the
three
of
us,
but
also
sending
it
to
the
list
for
confirmation
and
and
whatnot
one
thing
to
keep
in
mind
for
all
of
these
issues
and
pull
requests
is
that
the
goal
here
for
each
of
these
is
never
necessarily
to
come
up
with
the
perfect
answer
and
the
perfect
phrasing,
but
it's
always
to
make
it
better,
because
at
the
end
of
the
day,
issues
and
pull
requests
and
changes
are
relatively
cheap
and
they
are
all
in
the
open.
F
So
if
something
especially
for
a
potentially
controversial
issue,
if
something
moves
us
forward,
if
something
actually,
you
know,
helps
drive
the
discussion
forward,
you
may
see
things
that
are
accepted
and
and
merged
and
even
potentially
published
that
are
not
final
yet
like
that
there's.
This
is
still
a
work
in
progress
in
cases
like
that.
We
may,
if
it's
an
ongoing
discussion.
F
The
editors
may
embed
a
new
link
to
that
discussion
issue
in
the
document
itself
to
have
that
kind
of
cross-linking
record,
but
over
time
we
expect
those
to
be
removed
from
the
document
all
right
with
that
the
editors
have
gone
and
hand-picked
a
couple
of
issues
that
we
thought
would
be
best
for
discussion
here
at
this
meeting
and
we'll
start
off
with
a
doozy
the
terminology
we
are
coming
at
this
protocol
from
a
world
that
already
has
things
like
oauth
and
open
id
connect,
but
there's
also
a
lot
of
other
stuff
out
there.
F
That's
working
in
similar
spaces
there's
a
lot
of
work
in
the
ssi
world.
There's
all
of
the
work
on
you
know,
siba
and
user
managed
access
that
are
sort
of
you
know
around
the
oauth
space.
F
So
we've
got
a
chance
to
ask
ourselves
what
we
mean
when
we
call
things
certain
things,
and
you
know
we
get
to
decide
what
things
are
named
and
what
things
are
defined,
as
so
per
fabian's
question
earlier.
How
do
we
avoid
endless
months
of
bike
shedding
and
arguing
about
what
exactly
we
call
something?
You
know
what
is
what
is
a
specific
term,
and
one
of
the
ways
that
we
can
do
that
is
to
that's
been
proposed
is
to
collect
terms
on
github
issues.
F
The
editors
would
like
feedback
on
what
the
working
group
has
for
an
appetite
for
doing
all
of
these
things,
and
you
know
I
can-
I
can
provide
my
own
take
on
what
works,
what
I've
seen
work
and
what
I've
seen
not
work,
but
we
would
like
input
from
the
group.
G
Yeah,
I
made
the
suggestion
of
the
wiki
not
to
have
the
wiki
be
where
we
had
a
discussion,
but
just
as
a
wiki
to
be
able
to
summarize
what
are
all
the
terms.
What
are
the
proposed
definitions?
What
are
different
names
for
the
same
kind
of
things
so
that
we
have
one
place
to
undersea
at
all
where
right
now,
it's
scattered
through
the
rfc
and
having
it
scattered
across
a
bunch
of
issues,
seems
a
lot
harder
for
people
to
look
at
and
understand
how
they
all
fit
together.
A
Do
yes,
that's
a
as
a
chairs
commentator
would
would
do
you
dick
do
you
or
or
you
know,
I
guess
this
is
for
anyone
in
the
group.
You
guys
see
this
as
a
permanent
thing.
Are
we
publishing
this
as
an
appendix
or
as
a
as
a
section
in
the
in
the
core
document
at
some
point,
or
what
do
we
do
with
this.
F
So
from
so
from
my
perspective,
we
should
have
a
terminology
section
and
something
that
actually
collects
all
of
these
there's
the
start
of
it
in
the
introduction.
It's
it's.
It's
not
comprehensive
and
it's
a
lot
looser
than
it
needs
to
be
in
the
current
in
the
current
draft
document,
but
in
in
my
view
we
should
be
moving
towards
a
terminology
section
whether
or
not
that's
the
exact
content
of
the
wiki.
B
Yeah,
no
not
as
a
chair
but-
and
I
don't
like
terminology
discussions
all
that
much,
but
I
think
we
should
get
it
over
as
soon
as
possible
and
maybe
have
a
goal
of
concluding
the
discussion
about
terminology
by
the
next
idf,
because
it's
really
really
costly
to
go
through
global
global
changes.
Afterwards
and
people
will
just
be
confused
so,
whether
it's
wiki
or
not
whatever,
let's,
let's
get
it
over
with.
F
A
D
D
A
All
right,
I'm
not
hearing
a
lot
of
voices
in
support
of
of
either
solution
here,
but
it
doesn't
sound
like
people
are
opposed
to
using
a
wiki
for
for
this
yeah.
Maybe
that's
a
good
starting
point,
and
maybe
you
know
if
we
were
going
to
talk
about
the
interims
at
some
point
here
and
it
might
be
a
good
goal
for
maybe
the
first
interim
to
sort
of
spend
a
little
time
closing
this.
A
So
you
know
have
a
user
get
up
with
the
github
wiki
gather
all
of
the
various
terms
and
then
use
some
time
on
the
first
interim
to
just
sort
of
well
polish.
This
off
this
you
know.
Does
that
make
sense
to
people.
A
A
Scoping
is
more
important
on
the
and
I
you
know
this
is
not
we're
not
talking
about
terminology,
as
opposed
to
other
things
right
we're.
You
know
we
we
want
to
get
it
out
of
the
way
as
quickly
as
possible.
That's
my
sense.
A
Yeah-
and
you
want
to
say
something
about
that:
justin,
otherwise,
I'm
gonna,
then
I'm
gonna,
let
aaron
speak
and.
F
Yeah
I
was,
I
was
just
going
to
agree.
I
think
that
you
know
a
wiki
when
used
as
this
is
something
that
I've
commented
on
the
issue,
it's
terrible
for
discussion,
but
it's
good
for
sort
of
collecting.
F
This
sort
of
you
know
current
state,
so
you
know
discussion
either
on
on
issue
29
or
you
know,
if
you
create
a
new
issue
for
a
specific
term,
or
something
like
that,
if
you
want
to
make
sure
you
link
it
back
to
this
one
and
then
let's
pull
all
of
that
into
the
wiki.
I
I
think
that's
something
that
the
editors
can
can
leave.
Favan's
already
started
a
page
that
we
can
start
to
use
for
that.
E
E
Yeah,
I
was
just
gonna
say
the
wiki
idea,
I'm
in
support
of
that
as
long
as
it's
within
the
context
of
that's
the
sort
of
quick
place
to
to
capture
the
current
state
of
the
discussions
which
eventually
ends
up
back
in
the
actual
draft.
I
don't
think
it's
a
good
long-term
plan
for
anything
to
live
there,
but
it
is
faster
to
make
edits
to
that
than
it
is
to
publish
new
drafts.
A
All
right
and
lucy
made
a
note
in
in
the
chat
about
sort
of
make
being
able
to
defend
terminology,
which
you
know
is
great
advice.
I
I
suggest
we
call
time
on
this
and.
F
All
right
thanks,
there's
one
specific
thing
that
I
wanted
to
bring
to
people's
attention,
because
this
was
a
discussion
from
the
design
team
on
a
particular
term
that
I
don't
think
necessarily
came
through
clearly
in
the
draft,
because
it
was
relatively
late
in
the
design
team
process.
F
The
proposal
here
is
that
we
specifically
replace,
what's
now
called
the
resource,
client
or
client
within
the
document
and
specifically
talk
about
something
called
a
client
instance
and
whether
we
you
know
workshop,
that
name
or
whatever
the
idea
here
being
that
a
distinct
instance
is
a
cryptographic
identity,
which
means
that
it
always
means
it
has
access
to
a
specific
key,
and
I
went
through
the
document
and
almost
every
single
place
where
we
talk
about
the
rc
or
the
client.
F
F
So
you
know
that
is
my
first
proposal
into
changing
the
terminology,
because
this
reflects
where
you
know
the
discussion
on
the
design
team
had
already
been
going,
and
we've
already
got
a
few
places
in
the
document
that
use
this
term.
But
I
I
think
that
we
can.
We
can
actually
make
this
more
universal,
which
leads
us
into
the
next
set
of
issues.
F
F
All
right,
not
hearing
pitchforks,
one
of
the
things
that
we
really
want
to
do
with
this
work,
where
we
can
move
beyond
2
or
sort
of
the
assumptions
that
oauth2
made
all
those
years
ago
is
separating
this
notion
of
a
client
instance
from
the
software
that
is
running
that
instance.
This
is
something
that
oauth2
is
really.
If
you
look
at
the
oauth
2.1
work
that
is
going
on
in
the
oauth
working
group.
This
is
something
that
oauth2
is
continuing
to
struggle
with
and
trying
to
make
new
definitions
for.
F
There's
now
a
thing
called
a
credentialed
client
which
isn't
in
the
original
oauth2
draft.
But
it's
trying
to
capture
a
notion
that
oauth2
didn't
didn't
quite
get
right
in
the
current
protocol.
The
client
instance
can
send
either
an
instance
identifier.
So
this
is
basically
a
reference
like
a
client
id
that
the
as
can
use
to
figure
out.
You
know
all
of
the
information
about
it
or
it
can
send
a
client
information
block
much
like
dynamic
registration
but
inlined
and
there's
there's
some
other
hooks
and
tools
and
stuff
like
that.
F
So
far,
this
seems
to
be
a
a
pretty
robust
system
to
allow
us
to
do
this,
so
the
questions
are
sort
of
how
it
allows
us
to
address
these.
You
know
wide
set
of
use
cases,
so
we've
got
static,
clients,
we've
got
ephemeral,
clients,
we've
got
mobile
clients,
which
is,
you
know,
static
software
over
long-term
instances
on
a
bunch
of
devices
versus
spas,
which
is
software
on
a
bunch
of
short-lived
instances
on
a
bunch
of
different
devices.
F
So
you
know,
there's
lots
of
different
notions
of
what
a
client
instance
could
be
and
how
it
can
be
represented,
which
brings
us
to
the
first
question
of
since
we're
talking
about
individual
instances,
especially
from
the
as
side
we're
going
to
want
to
rope
those
together
somehow
now
in
oauth,
2,
dynamic
registration.
F
We
have
this
thing
called
a
software
statement
and
the
use
of
that
concept
goes
way
way
back
long
before
oauth
2
even
had
a
dynamic
registration
step,
but
it's
also
been
one
of
the
things
we
discussed
on
the
design
team
was
that
one
of
the
way
that
oauth
2
uses
client
id
is
as
a
class
identifier.
If
you
look
at
mobile
applications
and
spas,
that's
what
the
client
id
kind
of
does
in
that
case,
but
here
we
want
to
in
ganap.
F
We
can
do
other
mechanisms
that
we
can
provide
and
can
have
to
tie
a
bunch
of
instances
together
and
how
are
those
expressed-
and
you
know
how
are
those
carried
by
the
client
and
presented
to
the
afs?
F
The
reason
for
tying
these
together
is
so
that
you
can
set
a
bunch
of
policies
to
a
set
of
instances
and
say
that
I
want
to
treat
all
these
the
same.
So
if
the
user
says,
for
example,
like
I
want
to
you,
know,
stop
using
this
spa,
then
any
outstanding
tokens
on
any
instances
of
that
spa
is
probably
what
the
user
meant
to
to
get
rid
of,
or,
for
example,
you're
managing
it
based
on
software
version
or
platform
or
stuff
like
that.
You
can
see
here.
F
F
So
we
we
need
to
come
up.
We've
got
a
couple
of
ways
to
do
things
like
this
in
in
the
core
draft.
Now
this
is
something
that
we
need
to
move
forward
and
sort
of
solidify,
but
there's
also
additional
cases
around
sending
information
about
the
client
software
and
the
client
instance
as
part
of
the
protocol.
F
So
one
of
the
problems
with
oauth,
dynamic
registration
is
that
I
can
just
show
up,
and
my
display
name
is
google,
and
I
can
just
say
this:
is
google
docs?
I
mean
we
saw
an
attack
like
this
in
the
real
world
a
few
years
ago,
and
so,
if
I
could
send,
you
know
a
way
for
the
as
to
verify
that
the
presenter
of
this
display
information
is
allowed
to
present
that
specific
display
information.
F
We
could
move
that
that
trust
forward
in
the
oauth
world
we've
seen
this
done
with
software
statements
through
third
party
pre-registration
services,
open
banking
uk
has
that,
for
example,
moderna
has
that
in
the
mobile
connect
space,
but
there
are
probably
a
lot
of
other
things.
We
can
do
as
well
one
of
the
most
promising
ones
that
I
think
we
can
bring
forward,
and
people
have
proprietary
versions
of
this
out.
F
This
is
one
of
the
biggest
questions,
and
this
is
one
of
the
three
issues
that
that
I've
tagged
here
with
this
is
we
need
to
understand
the
difference
between
information
that
might
be
sent
every
single
request,
so
in
that
case
you
know
it
might
vary
over
a
specific
instance
over
time
versus
stuff
that
you
would
only
send
in
a
first
request,
so
a
registration
type.
You
know
posture
information.
F
A
I'm
going
to
join
the
queue
as
myself,
because
nobody
else
is
there
and
say
that
software
statements
or
the
kind
of
things
that
software
statements
are.
You
know
authorials
use
for
federation,
and
you
know
collating
things
together
can
be
based
on
other
things
than
just
posture
and
and
software
it
could
be.
You
know
whether
the
organization
running
it
has
some
certain
property
right,
so
that
kind
of
I
think
that
kind
of
stuff
is
important
to
preserve,
not
sure
whether
it's
software
or
poster
related,
though.
F
Yeah,
no,
I
agree,
there's
there's
a
lot
of
other
dimensions
that
we've
seen
people
try
to
cram
in
in
the
real
world.
So
if
you
look
at
the
you
know
some
of
the
stuff
in
the
financial
industry,
it's
not
it's
not
talking
about
the
nature
of
the
software
itself.
It's
actually
talking
about
the
nature
of
the
organization.
F
That's
publishing
the
software
they
and
sort
of
the
assertion
that
you're
sending
is
that
I
have
the
right
to
even
start
talking
to
you,
so
that
would
be
kind
of
a
first,
a
first
request
kind
of
thing.
F
You
know
this
first
introduction,
but
we
have
also
seen,
like
I
said
it's
largely
been
in
proprietary
systems
in
my
experience,
but
we've
also
seen
people
saying,
like
you
know,
hey:
this
is
the
device
signature
of
this
application,
which
I
can
tie
back
to
our
you
know
internal
key
to
show
you
that
I'm
running
unmodified
software,
for
example.
So
you
know
there's
this
whole
bag
of
things
and
there's
there's
a
lot
of
feeling
that
this
is
the
kind
of
stuff
that
we
want.
F
I
think
that
we
need
to
start
making
this
concrete
and
and
finding
places
for
this
kind
of
stuff,
so
that
I
can
app,
even
if
it
doesn't
define
all
of
these
different
bits
and
pieces
at
least
gives
us
places
to
put
all
of
these
pieces
in
the
protocol.
This
is
something
that
really
needs
to
be
brought
to
the
fore.
A
Right
and
lucy
made
the
point
on
on
chat
that
as
soon
as
you
bring
granting
things
into
into
the
play,
then
you
have
to
think
about
revocation
as
well.
Yes,
yes,.
A
F
Nobody
else
is
standing
up,
so
you
know
all
right,
let's
move
on
then,
and
so
continuation.
So
this
is
something,
and
continuation
is,
is
one
of
the
terms
we
need
to
potentially
workshop,
but
currently
in
the
protocol.
This
is
you
know
you,
you
start
the
request
and
then
you
potentially
interact
and
then
then
you
do
something
to
further
that
request.
F
F
right
now,
the
continuation
process
in
the
draft
it
contains
a
mandatory
url,
that's
sent
back
to
the
client,
for
you
know
where
it
goes
sort
of
the
the
base
of
the
api
for
it
to
make
its
next
request,
and
it
currently
has
an
optional
access
token
for
continuing
and
managing
that
request
over
time.
That
access
token
it's
important
to
point
out
is
not
a
bearer
token.
F
It
is
defined
as
being
bound
to
the
same
key
that
the
client
used
to
make
the
initial
request,
or
its
subsequent
rotation
and
key
rotation
is
a
whole
other
issue,
we're
not
going
to
dive
into
that
tonight,
but
in
any
event,
the
the
questions
here
are
you
know
what
is
the
value
of
having
those
different
options?
F
We
could
keep
it
as
it
is
with
an
optional
access,
token
and
semantics
about
what
the
client
is
supposed
to
do
when
it's
present
and
when
it's
not,
we
could
require
the
token
to
be
mandatory
and
sort
of
define
this
continuation
api
in
terms
of
that
access
token,
or
we
could
remove
the
access
token
entirely,
in
which
case
we
also
have
to
ask
ourselves:
does
the
continuation
uri
need
to
have
constraints
on
it
in
terms
of
its
uniqueness
and
whatnot?
F
So
the
current
design
reflects
a
sort
of
compromise
of
different
design
patterns
that
the
design
team
came
up
with,
and
this
is
what
they
look
like.
So
the
first
continuation
response,
you
get
an
internal
access
token
as
long
as
well
as
a
uri
to
use
it
at.
F
In
addition
to
there,
there
are
some
other
flags
that
you
can
get
as
part
of
that,
but
this
is
giving
the
client
all
of
the
information
it
needs
in
order
to
make
the
next
step
now
this
is,
I
will
say
that,
in
general,
this
pattern
is
very
key
to
gnapp
in
terms
of
the
client
starts
everything
with
one
message
and
then
is
told
where
to
go
next,
and
this
is,
this
is
a
really
important
aspect
to
the
design
in
terms
of
its
security
and
simplicity
of
the
clients,
because
it
makes
things
much
more
deterministic
so
anyway,
in
this
case,
the
client
is
given
the
access
token
in
the
uri.
F
F
This
is
the
first
example
we're
using
the
exact
same
syntax
for
that's
currently
defined
for
an
access
token
that
comes
back
for
accessing
a
resource
server
externally,
so
the
value,
the
key
all
of
those
fields
are
allowed
to
show
up
inside
there.
It's
it's
the
same
access,
token
kind
of
structure.
F
This
is
actually
also
currently
allowed
by
the
current
spec,
where
what
you're
doing
is
you're
getting
back
a
continuation
uri,
but
without
additional
stuff.
You
know
this
is
non.
This
is
a
non-unique
continuation,
uri
and
the
idea
here
being
that
the
as
would
limit
a
client
instance
to
one
ongoing
request,
whether
it,
whether
that's
okay
or
not,
you
know
this
is
this
is
a
design
pattern
that
is
currently
enabled
by
the
current
text.
F
So
a
bit
of
comparison
to
say
something
in
the
queue.
Do
you
wanna?
Okay,
yeah
go
ahead.
I
was
just
gonna.
Go
between
the
two
approaches.
F
Go
ahead,
then,
okay,
so
let's,
let's
do
this
so
so
this
is
a
design
decision
that
the
working
group
needs
to
make.
So
the
access
token
approach
really
treats
authorization
as
an
api,
and
this
was
one
of
the
the
core
design
patterns
of
the
ex-off
draft.
That's
gone
into
can
app.
Now
the
use
of
an
access
token
here
treats
that
api.
The
same
way
that
we
would
be
treating
a
resource
server
api
and
we're,
assuming
that
the
client
already
knows
how
to
do
this.
F
F
So
you're
handed
the
uri
to
manage
your
client
and
the
access
token
to
do
that
in
a
response
without
the
client
having
to
go-
and
you
know,
fetch
a
separate
access-
token
you're,
just
you're,
given
that
sort
of
as
a
bundle,
but
it's
a
separable
bundle
and
the
importance
of
that
separability
in
this
design
pattern
is
that
allows
lots
of
different
deployment
patterns
for
the,
as
you
could
even
have
a
fully
stateless
as
by
packing
everything
that
you
need
to
about
the
ongoing
request
into
the
access
token.
F
There
are
trade-offs
of
doing
that,
of
course,
and
this
both
approaches,
I
will
say,
also
allow
us
to
separate
the
sort
of
the
ongoing
request
from
the
start
of
the
request,
which
allows
us
for
some
really
interesting
distributed.
Authorization
server
models
that
a
lot
of
people
that
I've
been
talking
to
over
the
last
couple
of
years
are
really
interested
in
bringing
forward
so
benefits
of
a
token-free
approach.
Is
that
there's
there's
fewer
moving
parts.
F
So
if
we
never
get
back
an
access
token
here,
you
are
just
given
a
url
and
you're
making
a
request
to
that
url
and
and
not
having
to
worry
about
presenting
this
additional
artifact,
and
this
means
we
are
defining
different
behaviors
for
talking
to
the
auth
server
versus
a
resource
server,
which
means
that
the
auth
server
doesn't
have
to
manage
special
tokens
for
for
limiting
access
to
sort
of
its
own
internal
processes.
F
G
So,
like
my
understanding
is,
the
client
is
still
going
to
authenticate
in
every
call
to
the
right.
It's
not
just
getting
an
access
token,
it's
presenting
as
a
bearer
token
correct.
F
F
G
G
G
G
F
That's
the
part,
I'm
reusing,
we're
not
saying
that
the
access
tokens
that
you
get
for
calling
the
rs
have
to
be
bound.
That's,
that
is
a
separate
discussion,
but
the
ones
talking
to
the
as
would
have
to
be
bound.
That
would
be
a
a
limitation.
A
G
I
think
the
access
token
doesn't
give
us
it's
a
convenience
for
the
server
this.
If
the
server
wants
to
put
state,
they
can
put
the
state
into
a
url
and
it's
a
bunch
of
extra
overhead
for
a
client
to
figure
this
out,
and
so
I
was
going
at
that.
It
isn't
something
that
the
client
already
has
it's
going
to
be
some
potential
new
thing
for
the
client.
F
E
Yeah,
I
just
want
to
turn
in
here
and
say
that
between
these
two
options,
I'm
hesitant
to
recommend
an
option
that
puts
more
things
into
urls.
E
E
E
If
you
imagine
that
thing
on
the
end
might
end
up
containing
some
sort
of
encoded
data,
the
client's
not
aware
of
where
it's
a
json
web
token,
for
example,
that
contains
data,
then
that
is
now
being
sent
in
a
url
which
then
has
all
the
possibilities
of
of
being
exposed
or
logged
in
all
the
reasons
that
we're
trying
to
avoid
putting
things
in
urls.
Now,
so
that's
that's
my
take
on
it.
I'd
rather
avoid
cramming
more
things
than.
A
Urls
all
right
anyone
else,
anyone
else
on
this
issue.
Jaron
did
you
want
to
walk
back
to
the
previous
issue
and
then
we.
B
F
B
B
F
Okay,
thank
you.
That's
that's
great!
So
for
the
for
the
client
information,
I
think
we've
got
a
a
reasonable,
a
reasonable
first
step
on
the
first
issue,
which
was
terminology
for
the
client
information.
We've
got
three
issues
here.
One
of
the
issues
I
believe
it's
46
is
more
of
you
know
just
sort
of
contextual
information,
and
there
are
a
lot
of
those
that
came
from
the
editorial
notes
that
I
think
the
editorial
team
can
kind
of.
F
We
can
just
kind
of
scrape
through
the
issues
list
and
say
like
yeah.
We
believe
this
is
just
commentary
and
we
can
just
close
these
and
move
on
for
the
other
two
there's
the
question
of
device
posture
which
we
would
like
to
see.
I
think
we,
as
a
group
need
to
see
concrete
examples
of
this
is
the
information
that
I'm
sending
so
far.
We've
seen
a
lot
of
sort
of
notional
examples
of.
F
Type
of
attestation,
I
think
we
need
to
get
concrete
here
with
this
kind
of
stuff,
and
so
the
the
editors
do
not
have
specific
direction
for
this
right
now,
but
we
would
like
feedback
on
on
these
issues,
in
particular,
to
help
sort
of
hone
this
client
model
and
how
this
gets
presented,
especially
in
the
initial
request.
F
This
will
have
follow
follow-on
effects
to
a
number
of
other
issues
that
have
been
opened
in
the
protocol,
but
I
think
that
once
we
really
start
to
make
this
notion
of
what
the
client
instance
is
really
concrete
and
sort
of
what
this
request
structure
can
look
like
we
can.
We
can
start
to
solidify
our
decisions
on
these
others.
So,
yes,
please
comment
on
the
issues.
Please
give
us
real
examples,
really
use
cases
of
this
kind
of
stuff.
F
If
we
don't
get
any,
maybe
we
just
don't
leave
a
spot
for
it
right
now
and
we
can
kind
of
close
that
and
move
on
until
we
get
something
concrete
for
continuation
issue
67
I
would
like
you
know.
The
editors
would
like
to
hear
from
the
group
what
what
direction
we
should
take
like.
Should
we
make
the
token
mandatory
should
we
remove
the
token
like
and
whether
that
url
needs
to
be
required
to
be
unique?
You
know
I
have
a
stance
on
it.
I
think
the
token
should
be
mandatory.
F
You
know,
aaron
stated
if
I'm
summarizing
correctly,
I
believe
he's
in
that
camp
as
well.
We
would
like
to
hear
from
the
rest
of
the
working
group
what
direction
this
should
take.
I
don't
think
anybody's
particularly
happy
with
it
being
optional.
A
I
got
dave
about
the
queue
so
yeah,
okay,.
C
Yeah
hi,
can
you
hear
me?
Yes,
yes,
yeah,
so
look
I
I
you
know.
I
know
you
don't
want
to
always
compete
or
too,
but
you
know
with
the
various
extensions.
There
are
two
essentially
you
know:
there's
been
a
bit
of
background
forwards,
some
have
required
kind
of
client
authentication
at
the
at
the
ais
and
just
repeating
the
client
the
same
as
a
token
endpoint
and
others
have
gone
the
access
token
approach.
C
I
suppose
my
my
my
input
would
be
that
I
think
we
should
try
and
avoid
the
optionality,
and
it
seems
to
me
the
benefit
of
potentially
having
distributed,
as
you
know,
would
lean
very
heavily
in
favor
of
the
access
token
approach,
but
my
request
would
be
that
whatever
one
we
agree
on,
there
is
just
one
way
because-
and
I
think
that's
maybe
a
general
thing
in
the
draft
where
possible.
C
I
really
think
we
need
to
try
and
cut
down
the
optionality,
because
it
is
just
going
to
make
it
a
nightmare
with
the
current
amount
of
optionality
there.
F
Yep
all
right,
thank
you
and
to
be
clear.
What
we're
talking
about-
and
this
this
was
in.
The
previous
thing,
is
that
bearer
tokens
would
be
forbidden
as
an
option
here
like
the
client,
is
always
going
to
be
presenting
its
key,
which
means
in
this
context
it
is,
in
most
cases
going
to
be
authenticating
to
the
as,
although
we
have
to
keep
in
mind
the
dynamic,
the
dynamic
and
ephemeral
use
cases
we
have,
where
authentication
really
just
means,
it's
the
same
key
that
I
saw
the
first
time.
F
All
right,
so
please
provide
feedback
of
that
on
the
issue
and
hopefully
we
can
close
on
on
a
direction
for
that
in
the
editors
we'll
bring
that
to
the
list
for
consensus.
I'm
here
right
now,
I'm
hearing
a
a
as
you
know,
a
slight.
A
Tilt
towards
the
current
text,
but
we'll
we'll
see
where
we
are
so
should
we
move
on
to
the
next
issue.
F
Sounds
good
to
me
all
right,
interaction,
bundles
and
so
the
current
document.
It
gives
you
multiple
interaction,
methods
for
starting
interaction
and
one
post
interaction,
method,
they're
all
kind
of
lumped
in
there,
and
I
will
note
in
case
people
didn't
get
to
see
this
so
just
before
I
logged
onto
this
call,
I
saw
that
aaron
actually
made
a
really
good
comment
to
that.
So
aaron
once
I'm
done
presenting
kind
of
the
current
state,
if
you
could
jump
on
the
queue
to
talk
about
that,
that
would
be
wonderful.
F
So
the
thing
about
these
interaction,
bundles,
is
that
it
gives
you
well
in
the
current
document.
You've
got
a
few
different
ways
to
get
the
user
over
there
that
the
client
can
choose
from,
but
only
one
thing
that
they're
allowed
to
do:
post
interaction-
and
there
are
some
proposed
use
cases
that
people
would
like
to
be
able
to
do
that.
This
doesn't
allow
expression
of
so
alternative.
One
is
would
be
to
couple
the
post
interaction
with
each
single
interaction
method.
F
An
alternative
two
is
to
allow
multiple
interaction,
bundles
so
to
get
concrete.
What
this
looks
like
right
now
is
that
the
redirect
and
user
code
portions
say
how
you
get
the
user
over
there
and
then
the
the
callback
is
the
post
interaction.
You
know
again,
these
might
not
all
be
the
best
names
for
each
of
these
fields.
We'll
bike
show
that
later
callback
is
the
post
interaction
action
set,
so
the
first
proposed
alternative
is
to
bundle
the
post
interaction
with
the
method
of
getting
over
there,
so
this.
F
So
what
this
is
saying
is
that
either
I
can
send
you
to
an
arbitrary
url
or
give
you
a
user
code,
but
in
both
cases,
however,
that
works
send
a
call
back
to
this
url
that
I'm
going
to
be
listening
on
in
a
in
a
browser
redirect
alternative
one
is
to
say
okay
for
the
arbitrary
url.
F
I
want
you
to
call
back
to
this
url,
so
this
is
closer
to
the
the
oauth
2
grant
type,
where
everything
is
kind
of
tied
together
and
I'll
also
point
out
that
this
is
how
early
versions
of
the
xyz
project
implemented
this
before
we
move
to
something
that's
more
like.
What's
in
the
current
draft.
F
The
second
alternative
is
to
optionally
allow
for
having
bundles,
so
you
know
just
throwing
so
just
pulling
some
names
out
of
the
air.
We
could
say
that
each
of
these
individual
pieces
would
be
an
interaction
method,
and
then
you
combine
those
into
an
interaction
mode
which
means
that
if
you
are
doing
a
single
request,
so
just
like
a
single
host
interaction
option,
you
would
bundle
that
into
a
single
mode
and
you
would
send
that
as
the
interact
value.
F
If
you
have
multiple
bundles,
you
would
explicitly
separate
them
into
different
objects
and
pass
all
of
that
as
an
array,
and
each
of
these
individual
pieces
in
that
array
is
going
to
be
the
same
syntax
that
the
that
a
single
object
would
be.
This
follows
similar
patterns
that
we've
had
elsewhere
in
the
protocol.
Aaron.
Did
you
want
to
talk
about
your
you
know?
Your
start
finish
idea,
because
I
think
that's
got
some
legs.
E
Sure
yeah,
it
took
me
a
second
to
remember
what
you
were
talking
about,
because
I
went
and
filed
a
whole
bunch
of
issues
which
now
I'm
going
to
go
ahead
and
summarize
and
post
as
a
threaded
discussion
as
a
discussion
on
the
mailing
list
linking
to
these
issues.
But
yes,
the
alternative
three.
I
guess
the
way
I
was
thinking
about
it
was
that
this
interaction
there
are
there's
a
start
and
a
finish
operation.
The
the
client's
saying:
here's
different
ways.
E
E
So
and
the
third
option-
which
I
don't
think
is
in
your
slide
here,
but
is
the
ui
locales
hint
to
localize
the
interface,
which
is
a
really
good
suggestion
and
that's
a
completely
different
class
of
sort
of
thing,
it's
thriving
compared
to
how
it's
going
to
start
the
flow
and
how
it's
going
to
finish
the
flow.
E
So
I
guess
you
probably
can't
pull
up
my
my
little
sample
gaitheon,
but
the
essentially,
what
I
had
done
suggested
adding
top
level
properties
for
start
and
finish,
which
are
arrays
of
the
the
different
ways
that
that
each
of
those
things
could
happen.
It's
122.,
oh
122..
Thank
you.
Yeah.
E
Oh,
thank
you
so
the
yeah,
so
the
idea
would
be
taking
all
the
existing
values
that
are
in
there
that
are
currently
described,
but
then
grouping
them
so
that
it's
like
a
lot
more
clear
about
what
each
thing
is
doing.
F
And
so
I
think
going
along
the
lines
of
this,
and
the
proposed
second
alternative
would
be
that
if
you
had
different
ways
you
wanted
to
bundle
this,
then
you
would
allow
the
client
to
send
an
array
of
these
and
then,
of
course,
we
can
figure
out
what
the
response
looks
like
and
how
to
tie
them
together,
and
you
know
stuff
like
that.
If
we
go
down
that
route
but
but
yeah
this
th,
this
is
all
tied
together.
F
All
right
so
is.
A
F
Okay,
okay,
then
I'm
gonna
pull
this
back.
Did
I
do
I
hate
that
hang
on
gotta,
fighting
with
powerpoint
is
always
fun,
okay,
so
what
we'd?
What
the
editors
would
like
is
feedback
on
issues
59
and
122,
and
you
know,
let's,
let's
I
think
we
can
nail
down
what
exactly
we
want
and
it
needs
to
be
use
case
driven
a
lot
of
this
discussion
up
into
this
point
has
been:
it's
really
been
driven
by
this
notion
of
how
we
deal
with
post
interaction.
F
There
doesn't
seem
to
be
a
lot
of
controversy
about
having
multiple
ways
to
start
the
interaction,
giving
the
client
lots
of
different
options,
and
you
know
there
have
been
conversations
that
I've
had
outside
of
sort
of
the
itf
space
where
people
want
to
use
new
protocols
like
the
w3c
has
the
chappie
protocol.
Diff
has
the
did
com
protocol.
There's
there's
a
lot
of
you
know,
there's
also
the
whole
fido
family
of
protocols.
F
People
want
to
use
different
ways
to
kind
of
kick
things
off,
but
the
sticking
point
seems
to
be
this
notion
of
what
we
do:
post
interaction
and
how
we
tie
that
in
to
the
rest.
F
So
so
that's
what
the
editors
would
like
feedback
on,
so
that
we
can
hopefully
nail
this
down
and
move
forward.
B
F
Yeah
and
it's
and
it's
some
of
those
use
cases
that
are
driving
this
question
of
whether
or
not
the
current
syntax
is
expressive
enough
and
so
the
so.
The
question
is
then
really
does
the
are.
Are
the
changes
warranted
in
order
to
support
the
use
cases
that
need
that
additional
expression?
F
So
I
mean
this:
is
this?
Is
security
it's
gonna
be
complex,
but
we
always
need
to
balance
between
doing
things
that
are,
you
know,
fully
and
beautifully
expressive
versus
things
that
people
will
actually
get
right,
and
this
is
something,
though,
that
I
think
that
we
can.
F
F
My
current,
my
current
feeling,
seeing
what's
been
proposed,
would
be
a
combination
of
alternative
two
and
aaron's
syntax,
so
basically
allow
an
array,
but
each
member
of
the
array
is
based
on
aaron's
proposed
syntax
or
you
know
an
iteration
thereon.
F
That's
my
current
thought.
I
would
love
to
hear
other
people's
takes
on
what
we
can
do
there.
So
all
right.
E
F
All
right,
let's
move
on
all
right,
sounds
good,
so
token
request
syntax.
This
is
another
thing
that
we
kind
of
bounced
around
a
little
bit
in
the
design
team
and
I
don't
think
we're
quite
there
yet
so
the
current
method,
when
you're
requesting
access
tokens,
either
single
or
multiple
access
tokens.
It's
it's
pretty
simple
for
clients,
because
it's
it's
analogous
to
oauth
scope,
there's
a
list
of
things
which
added
together
describe
the
token
that
you
want
right.
But
that
means
just
like
with
oal
scopes.
F
It's
really
kind
of
awkward
to
send
in
additional
flags
or
fields,
or
things
like
that.
So
right
now,
we've
got
this
whole
section
on
token
flags
for
sort
of
signaling,
token
token,
behavior
or
requested
token
behavior.
F
So
the
proposal
in
issue
40,
which
is
going
to
spider
out
to
a
number
of
sort
of
token
syntax,
related
issues.
If
we,
if
we
go
in
this
direction,
is
to
take
what
we
have
right
now,
which
is
just
the
resources
array,
and
so
it's
the
resources
array.
That's
in
the
request.
Everything
in
here
is
what
manages
what
what
happens
with
the
access
token.
F
The
proposal
is
that,
instead
of
just
sending
this
array,
we
actually
have
an
access,
token
request
portion
of
the
object,
which
includes
the
resources
array,
which
we
can
still
describe
and
still
use
all
of
the
same.
You
know
rich
semantics
and
flexible
syntax
that
we've
got
now
but
put
sort
of
hang
other
stuff
about
the
access
token
up
at
that
higher
level.
So,
whether
or
not
it's
bound
to
a
sort
of
the
client's
key,
whether
we're
allowed
to
split
it,
that's
a
separate
issue.
F
F
So
the
idea
here
being
that
the
access
token,
if
it's
an
array
it
would
contain
each
of
these
individual
objects.
Now
this
does
get
us
away
from
what
I've
always
felt
was
a
really
elegant
solution
to
dealing
with
multiple
tokens
and
that's
requiring
labels
and
the
current
multiple
access.
Token
syntax
forces
you
to
create
a
unique
label,
because
it's
that's
enforced
just
in
the
json,
without
any
json
schema
or
anything
else.
Json
syntax
enforces
that,
because
we
use
the
left
hand
value
for
the
label.
I
really
like
that.
F
However,
it's
limiting
because
it
allows
it
doesn't
allow
us
to
sort
of
hang
extra
stuff
on
it
in
a
way
that
is
detectable
at
a
type
level
right.
You
would
have
to
do
sort
of
deep
object,
inspection
to
figure
out
what
kind
of
thing
is
there
and
we'll
get
more
into?
Why
that's
a
bad
idea
when
we
talk
about
the
next
issue,
but
we
could
pull
this
off
using
this
sort
of
object?
F
Syntax
if
we
had
an
internal
label
for
the
access
token,
and
the
response
would
be
very
similar
as
well
so
right
now
we
have
resources
in
the
request
and
then
access
token
in
the
response,
which
has
a
whole
bunch
of
stuff
tied
to
it
would
we
would
be
moving
towards
access
token
in
the
request,
an
access
token
in
the
response
and
with
internal
labeling
we
would,
we
would
be
able
to
mirror
those
two
that
is
nice
in
terms
of
simplicity.
F
It
makes
it
a
little
bit
harder
in
dealing
with
the
potential
error
cases,
because
now
nothing
in
the
in
the
syntax
enforces
uniqueness
of
the
labels,
and
so
that's
something
that
would
have
to
be
checked
at
the
application
layer.
On
top
of
that,
for
example,.
B
F
Yeah
yeah,
I
get
that
and
I
I
I
I
like
the
idea
of
labeling
this
access.
What
I
was
trying
to
do
with
this
straw,
man
was
to
parallelize
the
the
request
and
response.
I
may
have
gone
too
far
in
that
direction,
but
yeah
that's
a
great
comment,
but
so
yarn
this
does.
F
F
Oh
and
one
one
other
thing
I
want
to
point
out:
there
was
something
that
got
brought
up
a
few
times
about
allowing
a
client
to
specify
a
different
key
to
bind
a
token
to,
or
at
least
allowing
a
client
to
signal.
Like
hey,
you
know
this
access
token.
I
actually
want
bound
to
maybe
it's
this
derived
key
or
whatever,
which
is
separate
from
the
key.
F
The
client
is
using
to
talk
to
the,
as
the
syntax
would
actually
give
us
a
relatively
clean
way
to
do
that,
because
this
we
could
have
you
know
in
as
in
the
straw,
man
a
key
field
and
send
a
public
key
value,
as
just
as
part
of
the
request.
There's
a
really
clean
way
to
to
express
that,
and
this
this
again
is
the
key
that
would
be
bound
to
presentation
of
that
access
token.
F
So
it
would
allow
us
to
reuse
a
lot
of
that
same
structure
but
anyway,
what
what
the
editors
would
like
is
that,
since
this
is
this
would
be
a
larger
bit
of
surgery
to
the
protocol
that
would
have
effects
on
both
the
requests
and
the
responses
throughout
the
protocol.
We'd
really
like
feedback.
F
If
this
is
moving
in
the
right
in
the
right
direction,
if
we
should
maybe
just
try
to
put
a
stake
in
the
ground
and
and
see
how
this
feels
in
the
course
of
the
spec
or
if
we're
going
way
off
into
the
woods
here
and
again,.
F
G
Yep,
I
think
it's
a
good
idea
to
have
a
bunch
of
other
metadata.
Besides
the
resources
right,
there's
all
kinds
of
examples
you
can,
even
think
of
you
know
here's
how
here's
the
proof
of
possession
mechanism.
I
understand
right
for
how
it
wants
to
talk
to
the
resource.
G
D
G
So
I
agree
with
that:
I
don't
think
you
could
still
have
the
label,
be
the
l
value
and
have
it
be
an
object
that
has
the
metadata
with
resources
in
it.
So
I
don't
think
that's
an
either
or
and
I'd
second
euron's
comment
about
access
token,
because
you
could
call
it
access
and
the
thing
coming
back
can
be
accessed
that
contains
the
access
tokens.
F
So
a
quick
note
about
the
l
value
the
reason
for
not
doing
that
is
actually
related
to
our
our
next
topic
and
what
that
would
effectively
mean.
Is
that
the
l
value?
So
if
this
is
an
object
in
both?
If
this
is
a
json
object
for
both
the
single
and
multiple
access
token
cases,
then
then
we're
running
into
a
very
sort
of
error-prone
and
potentially
dangerous
mode
of
using
polymorphism
in
the
protocol.
F
Okay,
that's
that's
totally
fine.
This
is
this
is
a
bigger
design
issue.
One
of
the
things
that
the
editors
want
to
be
clear
here
is
that
we're
using
a
very
specific
kind
of
json
polymorphism
in
the
design
of
the
current
protocol,
so
json
has
no
internet
inherent
type
restrictions,
which
is
why
json
schema
and
json
ld
and
cddl,
and
all
of
these
other
things
exist.
F
It
allows
you
to
define
that,
because
protocols,
and
especially
security
protocols,
you
want
to
have
sort
of
strict
expectations
of
what
you're
going
to
find
within
an
array
or
in
a
given
field
or
whatever
polymorphism
as
we
are
using.
It
allows
each
field
to
have
expressions
for
different
use
cases
so,
like
I
was
just
talking
about.
F
Right,
that's
where
this
value
really
comes
in.
So
this
is
one
example
of
sort
of
string
versus
object,
polymorphism
that
we
have
today,
where
you
can
send
this
rich
multi-dimensional
object
or
you
can
send
a
string,
and
the
idea
is
that
it
references
that
now,
here's
the
question:
what
do
we
do
with
it
if
we're
going
to
keep
using
it
within
the
protocol?
This
has
been
brought
up
a
number
of
times,
use
it
only
where
it
makes
the
most
sense
absolutely
agree.
We
shouldn't
just
be
peppering
this
everywhere,
just
because
we
can.
F
It
needs
to
be
very
clearly
and
very
sort
of
strictly
defined
and
there's
been
some
great
discussion
on
using
an
informative
validation
language,
so
json
schema
cdl,
there's,
there's
a
bunch
of
others
out
there
and
providing
a
test
suite
for
people
to
run
their
messages
against
those
schemas
to
figure
out.
You
know
whether
or
not
what
they're
doing
actually
complies
wherever
possible.
F
We
need
to
make
sure
that
we
are
optimizing
complexity
away
from
the
client
software,
but
if
that
means
that
the,
as
has
to
has
to
bear
more
of
the
complexity
burden,
it's
not
necessarily
a
bad
thing,
and
then,
of
course,
if
we
decide
that
we
don't
want
to
use
json
polymorphism
at
all,
we
need
to
answer
the
question
of.
How
are
we
going
to
express
this?
Instead,
there
are,
of
course,
lots
of
ways
that
we
could
express
all
of
these
different
bits
of
syntax.
F
Generally,
though,
we're
going
to
end
up
doing
things
like
mutual
exclusivity
of
fields
that
has
to
get
enforced,
like
you
know,
at
the
application
level.
So
if
I
see
these
two
fields
together,
then
that's
an
error
or
we
have
a
type
field
within
the
object
which,
ironically,
we
have
in
the
resources
array.
F
F
We've
got
that
in
at
least
one
place
in
the
protocol
right
now
as
an
option,
and
we
need
to
ask
ourselves
is
that
the
direction
we
want
to
go
because
each
of
these
different
approaches
has
different
kinds
of
complexity,
and
we
have
to
be
aware
of
who
pays
for
the
complexity.
F
So
this
is
a
core
design
issue.
I
think
there's
a
lot
more
discussion
that
we
need
to
have,
and
especially,
if
we're
going
to
be
moving
away.
If
we
decide
to
move
away
from
polymorphism,
we
need
to
have
something
to
replace
it
with,
and
it
needs
to
be
something
that
actually
improves
things
that
you
know
we
need
to.
We
need
to
know
what
the
trade-offs
are.
That's
all
I
have
for
slides.
So
I
think
we're
good.
Please
comment
on
the
issues.
F
B
No,
we
don't
have
any
slides
for
for
this
part
of
the
discussion,
so
the
next
few
minutes
we're
going
to
talk
about
next
steps
and
lief,
and
I
discussed
it
and
we
would
like
to
have
a
multiple,
probably
two
interview
meetings
between
now
and
the
next
full
ietf.
B
But
this
is
a
question
to
the
group
and
especially
a
question
to
the
editorial
team.
Interims
will
help
us
to
close
issues
and
move
work
forward
at
a
faster
pace,
but
they
have
they
impose
a
load
on
the
editorial
team.
So
is
the
number
two
interims
too
much
too
little?
What
do
people
think,
or
are
we
good
enough
with
not
having
any
any
interest
and
just
doing
the
work
on
the
mailing
list?
B
E
F
There
we
are
I'm
also
in
favor
of
in
terms
for
the
reasons
that
aaron
is
talking
about.
I
think
that
they
can
be
really
good,
for
you
know,
moving
discussion
forward
rapidly,
with
the
caveat
that
any
interim
meetings
needs
to
be
very,
very
clearly
scoped
by
the
chairs
to
say
this
is
what
we're
talking
about
today
and
make
sure
people
don't
rat
hole
on
things.
F
I'm
you
know
I
I
think
we
did
really
well
as
a
working
group
tonight
in
in
this
format,
in
not
rat
holding
on
things
and
time,
boxing
things,
so
I
that
gives
me
some
hope
for
us
being
able
to
continue
to
move
forward
in
a
positive
way.
So
I'm
in
I'm
in
favor.
I
think
I
think
at
least
two
makes
sense.
F
Maybe
more
and
one
thing
that
I've
seen
the
oauth
working
group
do
is
have
it
be
topically
driven
like
if
there
are
a
lot
of
discrete
topics
to
talk
about
schedule,
a
bunch
of
different
meetings.
B
B
B
F
Are
we
there?
Yes,
okay,
sorry,
so
the
editors
have
made
a
a
handful
of
changes
to
the
document
already
mostly
pulling
out
the
the
editor's
notes
and
sort
of
collapsing
that
would
it
be
beneficial
you
know
especially
chairs.
Do
you
think
it
would
be
beneficial
for
us
to
publish
a
draft
o2
with
that
change
set
going?
You
know
forward
because
we've
got
that
plus.
F
You
know
a
couple
of
typos
fixed
and
dangling
statements
fixed,
that's
easy
enough
for
me
to
publish
this
week
and
it
doesn't
really
have
normative
or
substantive
changes.
F
Okay,
I
will,
I
will
take
an
action
to
do
that
at
some
point
this
week.
Thank
you
not
right
now,
because
it's
2
a.m.
A
Five
minutes
left
to
go.
We
may
maybe
we'll
just
call
this
a
little
bit
early.
B
One
more
thing
for
those
of
us:
well,
it's
not
two
a.m.
Does
the
gather
thing?
I
honestly
don't
remember
what
room
we
were
supposed
to
be
in,
but
if
you
want
to
meet
the
for
more
informal
discussion,
that
would
be
appreciated.
D
B
All
right,
so
with
that
we
are
done.
Thank
you,
everyone
and
we
will
let
you
know
once
we
have
the
interim
meeting
scheduled
and
in
the
meantime,
please
make
best
use
of
github,
and
we
would
like
to
know
what
you
think
about
the
various
issues
we
discussed
today.