►
From YouTube: OAUTH WG Virtual Interim Meeting, 2020-05-11
Description
OAUTH WG Virtual Interim Meeting, 2020-05-11
A
A
A
A
This
is
a
document
that
we
brought
back
from
the
ACM
and
it
it's
now
in
last
call
because
there
were
some
significant
changes
based
on
that
IHT
review,
so
we're
it's
it's
back
in
the
workroom
and
we
are
calling
for
a
workgroup
to
review
it
and
make
sure
they're
comfortable
with
this
before
send
him
back
to
to
the
iesg
and
the
last
thing
using
a
new
email
address,
because
my
previous
email
address
was
used
by
spammers
and
all
the
stuff.
So
it's
a
I
sent
an
email
to
the
list
with
this
new
email.
A
If
you
haven't
received
that
email,
it's
probably
in
your
spam
and
a
folder,
so
you
wanna
make
sure
that
that
you
out
of
that
older
here
agenda
for
today,
hey
dick,
we'll
start
by
talking
about
reciprocal
off
and
then
Aaron
will
take
the
rest
most
of
the
rest
of
the
time.
It's
talk
about
intermediate
amid
metadata
and
and
we
wanna
reserve
ten
minutes
to
get
you
feedbacks
about
those
interims,
the
good,
the
bad
and
the
ugly.
And
if
you
have
any
suggestions.
C
C
A
C
That
it
could
apply
to
anybody
else
linking
in,
and
so
you
know,
sonís
the
times
we
would
want
to
be
able
to
go
and
call
Alexa
and
time
selects.
Atlantic
also
knows
to
do
things,
and
so
how
did
you
end
up?
But
you
know
that
the
flow,
if
you
didn't
have
this
was
super
clumsy
because
you'd
start
off
say
it
Alexa
you've
bounced
over
the
Sonos
to
get
authorization.
Then
you
bounce
back
to
Alexa,
but
then
you
need
to
go
and
get
the
reverse
flow,
so
Alexa
would
bounce
over.
C
To
so
knows
they
would
then
go
and
bounce
back
to
Alexa
to
get
permission
from
Alexa
that
would
bounce
back
over
into
Sonos
and
often
user
would
have
to
authenticate.
You
know
at
the
same
site
a
couple
times
because
they
made
it.
They
actually
started
off
in
the
but
then
we'd
have
to
authenticate
and
the
web
client,
and
so
the
goal
of
this
is
like:
how
do
we
just
simplify
this
UX
low?
C
C
C
George
and
then
you
know
that
was
lots
of
feedback,
and
so
then
I
inside
left,
Lex
I
thought.
Well.
Does
anybody
even
care
about
this
anymore,
I
posted
that
on
the
working
group
mail
list-
and
it
was
just
crickets
which
indicated
to
me
that
nobody
really
cared
and
so
we're
now
I
wanted
to
talk
about
it
at
one
of
our
meetings
to
see
if
anybody
cares
before
I
spend
a
bunch
of
time
addressing
all
the
feedback
that
I
received
on
the.
A
D
That
I
think
it's
an
interesting
use
case,
but
in
the
same
breath
it
doesn't
really
affect
anything
that
I'm
trying
to
solve
right
now.
So
I
don't
have
any
things
that
I
see
this
and
say:
hey
I
use
this
for
something
so
it'd
be
nice
if
it
existed
from
for
me
and
I
might
need
it
someday,
but
I
don't
right
now
and
so
I
don't
care
right
now.
E
C
A
A
G
E
Okay,
so
this
is
this
is
a
new
draft
that
I
haven't
yet
brought
up
on
the
list
or
anything
but
I
shared
it
with
a
few
people
at
our
last
meeting.
Just
about
the
problems
of
this
in
solving
so
I
want
to
first
go
through
the
the
use
case
and
kind
of
set
the
scene
for
what
the
goal
of
this
is
before
we
get
into
the
details
of
the
actual
document,
so
this
is
actually
primarily
driven
by
I
guess:
either
user
experience,
side
of
Roth
and
the
consent
feature.
E
So
the
idea
here
is
that
you've
got
an
application.
That's
like
a
budgeting
app
and
it's
gonna
go
try
to
pull
your
financial
data
from
your
bank,
and
in
order
to
do
that,
obviously,
we
would
like
to
use
OAuth
instead
of
just
handing
over
Bank
passwords
to
these
applications
and
when
using
OAuth,
that's
gonna
show
the
list
of
scopes
and
who's
requesting
the
data.
That's
all
fine
and
the
client
ID
typically
identifies
this.
This
application,
which
is
the
thing
that
the
user
is
logging
into.
So
you
know
the
user
is
using
this.
E
This
app
budget
bunny
they
go
and
there's
the
website.
They
click
login
with
your
bank,
get
redirected
to
the
bank's
authorization
server,
which
would
then
show
the
name
of
the
app
in
this
consent
screen.
This
works
fine.
If
the
application
that
budgeting
app
is
a
registered
client
with
the
bank's
API.
E
There
is
this
new
class
of
entity
in
the
system
which
are
which
call
themselves
aggregators,
and
they
are
the
ones
that
actually
have
like
the
legal
contracts
with
the
banks
and
they
provide
services
to
end-user
applications
that
kind
of
either
either
just
normalize
bank,
api's
or
roll
them
up
or,
at
the
very
least,
just
provide
that
that
relationship
and
they're,
the
ones
that
are
sort
of
registering
these
client
IDs
on
behalf
of
the
applications.
So
this
is
what
it
looks
like
in
practice.
E
E
That's
gonna
buy
the
application
to
the
user
in
that
consent
screen,
but
the
as
far
as
the
banks
are
concerned,
the
client
ID
is
actually
the
aggregator,
because
that's
the
one
that's
calling
the
API
is
because
they
may
be
representing
the
bank
api's
in
a
different
interface.
So
just
to
give
any
idea
of
some
real
examples
of
brands.
You
may
see
in
this
we've
got
the
end-user
applications
on
the
left,
which
are
apps
that
you
may
actually
be
familiar
with.
E
That
may
actually
be
using,
and
then
you
may
have
thanks
that
are
on
the
right
and
then
there's
this
middle
layer,
the
aggregators
that
you
probably
never
see
because
they're
just
sort
of
moving
data
around
behind
the
scenes.
The
problem
that
this
why
this
relates
to
OAuth
is
because,
in
that
consent
screen,
the
banks
want
to
make
sure
that
users
are
actually
informed
that
their
data
is
being
shared
with
these
aggregators,
these
third
parties
or
I-
guess
almost
fourth
parties
at
that
point
so
on.
E
In
practice,
this
aggregator
layer
is
acting
as
as
the
OAuth
client
to
to
the
Bank
API
and
then
maybe
providing
a
proprietary,
app
ID
to
the
end-user
application
and
they're
acting
on
behalf
of
many
end-user
applications.
So
what
that
means
is
that
the
client
ID
concept
doesn't
really
fit
into
this.
E
So
on
this
consent
screen,
we
actually
want
to
be
able
to
show
a
list
of
these
intermediaries
or
these
aggregators
in
the
consent
screen,
so
that
users
actually
know
who
their
data
is
being
shared
with
and
that's
the
part
that's
missing
from
OAuth,
because
in
oh
a
client
ID.
Is
that
thing?
That's
gonna,
you
know
the
bunch
of
money
app
is,
it
would
be
represent
by
the
client
ID,
which
then,
how
do
you?
How
do
you
add,
soliciting
intermediaries
into
this
consent
screen
which
was
presented
by
the
bank?
E
So
that's
the
problem
that
that
exists,
and
as
these
as
these
companies
and
other
standards
groups
are
looking
at
ooofff
they're,
finding
that
the
concepts
don't
quite
map
into
OAuth,
like
they're
their
reality,
doesn't
quite
map
into
it.
So
my
my
goal
with
this
draft
was
basically
to
create
the
most
minimal
edition
200
off,
to
allow
them
to
build
on
oweth
for
this
use
case,
so
the
what
I
did
is
basically
I,
just
sold
it
down
into
well.
What
what's
missing
is
this
concept
of
these
intermediaries?
E
E
It
extends
dynamic
client
registration
to
add
in
these
additional
properties
that
describe
one
or
more
intermediaries
that
are
actually
acting
on
behalf
of
the
client
and
what
that
does
is
it
lets
the
aggregators
effectively
register
unique
client
IDs
and
provide
all
the
metadata
about
which
names
and
logos
to
show
on
the
screen
at
the
bank
api's
and
the
bank
api's
then
know
how
to
use
this.
The
state
of
model
to
then
present
the
right
information
on
the
consent
screen,
so
the
in
addition
to
that
dynamic
client
registration
edition.
E
It
also
then
says
that
authorizations
servers
that
support
this
are
expected
to
display
this
information
on
the
consent
screen,
so
that
that's
basically
the
whole
the
whole
draft.
You
can
read
it
there,
that's
basically
what
the
draft
says,
and
the
idea
is
that
this
is
then
one
of
the
building
blocks
needed
in
order
for
these
financial
institutions
to
pick
up
o
auth
and
actually
use
it
for
their
applications
instead
of
kind
of
either
just
doing
their
own
thing,
on
top
of
it
or
doing
something
completely
different
from
OAuth.
E
So
my
question
for
the
group,
I
guess
is:
does
this
sound
like
a
problem?
Anybody
else
has
encountered
either
in
the
financial
space
or
in
any
other
industries.
They
might
also
benefit
from
it,
and
is
there
any
interest
in
picking
up
this
work?
The
one
of
the
one
of
the
other
goals
I
had
with
the
strap
was
making
sure
that
there's
nothing
specific
to
financial
institutions
in
the
document.
It
is
meant
to
be
a
generic
solution
for
this
problem
of
this
intermediary,
acting
between
an
OAuth
application
and
a
an
API.
H
E
What
I
will
say
is
that
this
has
been
brought
to
my
attention
as
a
as
a
demonstrated
need,
and
this
screen
here
is
they
actually
want
to
make
sure
that
the
name
that
these
names
are
included
in
this
screen
so
I
and
I
will
also
say
that
they
are
actively
working
on
this
problem
and
trying
to
make
sure
that
that
they
can
do
it
within
the
OAuth
space
instead
of
having
to
go
and
do
something
completely
on
their
up.
So
I
don't
have
an
exact
answer
for
you
on
that
I.
Just.
H
E
Okay,
I
understand
that
and
what
you,
what
you
didn't
see-
and
this
is
what
was
presented
to
me
originally
and
what
that
would
I
turn
that
into
in
this
draft.
So
the
original
draft
that
that
I
received
was
something
completely
different
and
solving
this
problem
in
a
completely
different
way,
still
trying
to
pull
some
of
the
building
blocks.
But
it
did
it
in
a
very
non
Roth
way.
E
H
But
but
the
root
of
the
problem
is
still
unclear
as
far
as
what
kinds
of
intermediaries,
why?
Why
are
we
trying
to
bring
this
party
into
the
consent
process,
but
not
other
parties,
I
think
it
unless
we
have
a
clearer
understanding
of
what
kind
of
what
an
intermediary
is
or
what
why?
What
kinds
of
parties
would
constitute
that
and
what
kinds
of
parties
you'd
want
to
surface
through
there?
It's
gonna
be
hard
to
tell
whether
or
not
you
know
we're
we're
designing
the
right
thing
or
building
the
right
thing.
I.
I
I
might
have
a
scenario
where
you
could
use
this
today.
I
have
support
ace
like
one
entity
that
provides
a
SAS
solution.
They
can
use
external
identity
providers
like
say
Google
or
Amazon,
whatever,
that
is
in
a
nossa
Nereo,
but
I
provide
a
service
that
goes
in
between
the
two
systems,
so
I
need
to
be
able
to
authenticate,
but
also
tell
the
user
that
I
will
be
accessing
the
SAS
data.
J
The
problem
arises
from
the
TSE
to
European
regulation,
because
in
Europe
in
the
PSD
to
banking
of
banking
regulation,
European
Banking
Association
require
account
information
service
provider
and
a
third
party
over
to
be
licensed,
FinTech
application.
What
what
can
be
seen
as
the
end-user
application,
a
small
company
one
which
are
not
licensed,
but
these
are
the
entity
that
are
effectively
using
those
bookings
on
the
banks,
the
aggregators
who
owned
the
software.
J
J
The
concept
doesn't
exist
yet
at
all,
and
it's
being
heavily
discussed,
because
I
aggregate
only
that
concept
to
comply
with
the
law
and
allow
the
bank
to
display
the
identity
of
the
of
their
consumer
of
the
end-user
application
to
the
end-user
that
is
providing
his
consent
to
the
bank.
We
will
list
the
data
to
the
aggregate
or
that
has
to
release
the
people
to
the
real
application.
I,
don't
know
how
to
explain
it
better.
A
C
Yeah
I
was
just
going
to
expand
on
that,
having
a
familiarity
with
these
models
so
that
a
little
more
depth
or
an
Annabelle's
question.
Often
these
aggregators
are
not
just
a
service
in
the
middle.
That's
passing
through
the
data.
The
actual
customer
data
is
stayed
at
the
at
the
service
and
so
the
meet.
You
know
many
of
the
various
privacy
and
disclosure
requirements.
C
Since
that
party
has
the
customer
data
and
is
managing
it.
You
need
to
go
and
say
that
they're
doing
so
often
and
a
number
of
these
thin
tech
companies
are
really
built
on
top
of
an
API
of
a
service,
it
has,
as
Francis
says,
has
all
the
regularity,
things
and
they're
managing
all
that
customer
data
and
the
FinTech
company
is
really
just
the
skin
and
doing
marketing
around
managing
it,
but
they
don't
actually
have
the
financial
data
of
the
customer
they're,
not
the
ones.
H
E
Yes,
which
is
also
why
you
can't
just
use
the
straight
client
ID,
because
you
actually
the
pairing,
you
need
the
user
to
agree
to
the
pairing
of
this
and
do
end
user
application
and
this
aggregator,
which
is
why
those
two
things
are
shown
on
the
consent
screen
and
that's
a
different
agreement
from
whether
they
allow
the
same
end,
user
application
and
a
different
aggregator.
Is
that
right
right
now,
I
understand
that.
H
H
H
Independent
authorizations
and
okay,
so
for
the
customers
perspective,
the
expectation
is
that
if
I
revoke
well
I
revoke
at
the
end-user
application
level,
I
say
I,
don't
want
this
into
user
application
have
access
anymore,
and
that
terminates
the
ability
for
that
intermediary
to
have
access
in
the
context
of
that
relationship,
but
it
might
still
have
access
through
another
relationship.
I
think.
E
The
answer
is
probably
yes,
and
it
also
probably
depends
on
a
lot
of
different
circumstances,
the
and
in
and
it
and
as
Francis
is
saying
in
the
chat,
it's
being
heavily
discussed
right
now.
So
the
goal
with
what
I'm
trying
to
do
here
is
put
this
piece
in
place
so
that
all
those
things
become
possible
right
now,
those
those
decisions
can't
really
be
made
it
has
you
can't
set
it
up
right.
The
right
way
right
now,
using
just.
H
C
H
H
My
driver,
my
question,
is
that
if
we,
if
we
add
something
into,
if
we
try
to
standardize
something
that
there
isn't
a
standardized
notion
of
what
it
mean
supposed
to
mean,
what
it's,
what
it's
supposed
to
be
used
for,
then
people
go
off
and
do
all
sorts
of
different
things
with
it.
And
it's
no
longer
code
leenock
much
of
a
standard
anymore,
because
you
don't
have
any
in
there
operability,
because
everybody's
interpreting
it
differently.
So
I
want
to
make
sure
that
we
have
a
clear
understanding
of
what
problem
we're
trying
to
solve.
J
Francis
here,
the
problem
being
solved
is
the
problem
of
showing
the
resource
down
with
permission,
which
would
with
notarization,
is
really
given
the
difference
between
the
end
user
application
and
the
aggregators
is
being
visibly
heavily
discussed
like
in
the
the
French
version
of
opembe.
It's
explicitly
designed
that
you
can
have
multiple
consent
for
a
single
aggregate
or
each
consent,
mapping
change
it
to
an
end-user
application.
This
is
correct
in
the
Berlin
good
and
other
initiatives
when
you
revoke
the
consent
of
the
aggregate
or
you
revoke
the
consent
of
all
agreed
application.
A
L
Just
Austin
speaking
I
think
basically
understand
the
use
case,
but
a
bit
I'm
a
bit
worried
that
we
haven't
fully
understood
the
problem.
Is
we
wanna
we
wanna
solve
so.
Basically,
the
problem
here
is
not
to
replace
online
banking
credentials
with
the
aggregator
of
an
OAuth
flow,
that's
possible
without
that
exemption.
L
As
far
as
I
understand
this
that
they
could
be,
they
self
typically
is
a
client
to
the
banking
banking
banks.
Yes,
but
the
aggregator
of
internal
provides
an
API
to
other
applications.
This
can
be
implemented
as
two
into
two
independent
or
flows
in,
in
which
case
user
would
consent
to
the
dataflow
on.
In
two
places
the
bank
say
s
and
the
aggregator
says:
that's
one
one
option:
those
combined
use
cases
that
Francis,
just
Illustrated
I
think
still
need
to
be
sorted
out.
L
I
haven't
seen
any
working
implementation
in
place
now
but
suggests
we
are
looking
for
implementations
that
exist
and
to
try
to
better
understand
what
what's
a
problem
to
solve,
how
to
solve
it
and
I've
got
one
specific
question:
Aaron
and
I
I.
Don't
fully
understand
who
the
client
is
in
your
proposal
and
for
what
party
you
want
to
provide
additional
metadata
in
the
firt
on
first
side,
I
I
had
the
impression
that
the
echo
gear
is
gonna,
be
the
ova
client
and
there
is
additional
data
about
the
end-user
application.
L
E
So
we
share
this
slide
again,
this
one,
so
the
majority
of
the
time
the
situation
is
going
to
be
that
the
aggregator
is
making
API
calls
to
the
bank's
API,
which
is
what
the
thing
that
granted
the
token
and
the
consent
and
then
presenting
a
proprietary
API
to
the
actual
end-user
application,
because
that's
just
how
they're
you
know
it's!
It's!
It's
mint.com
talking
to
an
api.
The
aggregator
made
up
to
be
able
to
go
get
transaction
data.
E
The
Bank
API
is
who
notice
what
those
look
like
and
mint
doesn't
want
to
deal
with
twelve
different
Bank
api's.
So
in
this
situation
the
aggregator
is
the
OAuth
client.
However,
what
the
user
needs
to
see
is
that
it's
the
end-user
application
that
is
the
is
the
that's.
What
they're
expecting
to
see
when
they
go
through
an
OAuth
flow
they're
expecting
to
see
mint
is
trying
to
access
your
data
from
your
bank.
E
Not
this
aggregator
is
trying
to
access
data.
So
that's
why
it's
rooted
in
this
in
this
problem
of
what
to
show
in
the
consent
screen.
So
what
I've
gotten
the
draft
is.
The
sort
of
client
meta
data
ends
up
being
the
end
user
application
and
then
you've
got
the
arrestee
intermediaries,
but
in
practice
the
thing
actually
making
the
API
calls
is
the
aggregator
I.
L
Would
like
to
know
that
what
needs
to
be
shown
in
the
console
screen
heavily
depends
on
the
jurisdiction.
So,
as
friends
has
pointed
out
in
the
piece
T
2
context,
the
aggregator
is
going
to
be
the
license
party
and
you,
you
may
bet
that
the
name
of
this
company
needs
to
turn
up
in
the
User
Content
screen.
Yes,.
D
L
E
This
window,
so
this
is
the
extension
of
the
dynamic
client
registration
step,
you'll
notice.
This
is
an
authenticated
call
because
they
are
obviously
not
doing
unauthentic
on
an
unauthenticated
client
registration,
so
the
bank
issues
a
special
token
to
the
aggregator
to
allow
it
to
register
these
clients
dynamically.
The
basic
the
information
in
the
core
dynamic
line
registration
step
like
this,
which
I've
heavily
abbreviated,
is
the
end-user
applications
data
or
sorry.
L
E
Auth
doing
things
like
this
already
by
adding
these
kinds
of
metadata
in
to
the
registration
calls
doing
it
in
a
different
way
and
I
wanted
to
avoid
getting
the
situation
where
a
particular
industry
has
gone
and
made.
An
extension,
then,
is
to
industry-specific,
and
nobody
else
can
use
for
anything
else,
because
it's
too
deeply
rooted
in
that
vertical,
so
I
wanted.
Is
it's
not
already
being
deployed
used?
E
I,
don't
remember
how
many
deployments
I
think
they're
still
in
this
stage
of
they
are
trying
to
develop
they're
trying
to
document
the
standard
so
that
they
can
deploy
it,
and
that
was
that's
the
sort
of
weird
chicken
and
egg
thing
where,
if,
if
they're,
if
they
just
go
and
deploy
something
on
their
own,
it
then
becomes
harder
to
sort
of.
You
know
back
up
and
bring
it
back
into
the
OAuth
core,
but
they
are.
This
is
like
an
active
development
situation
where
they
are
building
stuff.
E
No
so
the
way
that
these
contracts
work
is
the
bank
contracts
with
the
aggregators
and
then
gives
them
the
license
to
or
I
guess,
resell
that
access
and
the
banks
really
don't
want
anything
to
do
with
the
end-user
applications,
after
that,
they
just
sort
of
delegate
that
power
to
the
aggregators.
So
where
do
I
go
to
revoke
access
to
an
end-user
application
that
would
be
in
the
bank,
the
bank's
authorization
server,
so
the
bank's
authorization
servers
have
to
support
this,
obviously
so
the
bank,
so
the
bank
is
the
authority.
E
H
Is
that
is
that
desired
here?
Like
do
we
actually
want
that
model?
Where
I
said,
banks
have
to
push
that
consent
revocation
to
the
aggregator.
Is
that
what
happens
there
is
that
what
people
want
as
well,
where
I'm
kind
of
going
with
this
is,
if
I
this
actually
feels
like
in
a
way
the
aggregator
is
a
resource
server.
H
Under
the
hood
that
resource
you
know
that
resource
server
is
operating
on
data
that
it's
getting
from
and
the
the
bank's
resource
servers,
but
if
I
think
about
like
what
is
the
end-user
application
getting
off
being
authorized
to
access
its
being
authorized
to
access
some
kind
of
set
of
APA
resources?
Not
the
transaction
data
itself,
whatever
computed
resources
are
provided
through
these
aggregator
endpoints,
and
if
the
bank
is
managing
authorization
for
that,
the
bank
is
managing
consent
and
replication
for
that
and
the
banks,
the
authorization.
H
H
If
I,
if
I,
were
to
like
spin
this
a
totally
different
way,
I
could
imagine
where
that
Oh
F
to
rip
off
an
authorization
request
has,
you
know,
say
a
resource
indicator
that
indicates
the
aggregator
and
scopes
that
indicate
the
sort
of
you
know
kind
of
derivative
resources
that
the
end-user
application
is
going
to
access
at
these
oh
yeah.
This
makes
this.
E
H
E
K
K
E
E
H
H
K
J
Me
to
have
to
distinguish
off-topic
here.
One
of
them
is
to
metadata.
What
metadata
does
the
bank
need
to
know
about
the
end-user
application?
In
most
of
the
cases,
there
is
no
contractual
relationship
in
the
mainly
the
application
and
the
bank.
There
is
a
relationship
between
the
bank
and
aggregator,
but
for
the
sake
of
managing
the
I
will
get
our
clients
relationship
posting
user
application.
They
get
also
push
more
data
into
the
bank
application.
J
This
is,
from
my
opinion,
a
proper
specification,
like
the
one
parents
bring
it
forward.
The
next
problem
is:
how
do
you
transfer
those
informations
with
a
bearing
when
you
are
transferring
them
in
context
of
a
dynamic,
Drive
registration?
We
are
doing
it
once
because
you
are
registering
the
client
wants
unless
you
have
returned
item
for
a
news
application.
That
is
the
point.
Dawson
is
mentioning,
if
you
transfer
it
with
each
authorization
request.
J
You
have
a
more
dynamic
behaviour,
so
we
have
to
distinguish
between
the
specification
of
what
type
of
metadata
we
one
manage
the
authorization
server
side
of
any
user
application,
and
how
do
we
associate
every
single
request
with
such
with
that
data
and
I
want
to
point
out
for
awesome
specification
of
the
grants.
Management
is
very
tied
to
this
because
at
the
end
we
need
some
sort
of
grant
management
from
the
perspective
of
the
end
user.
J
A
K
A
C
C
A
way
of
thinking
about
the
model
is
that
the
client
is
a
combination
of
the
aggregator
and
in
providing
the
UX
that
the
two
of
them
that
that
that
group
is
who
the
client
is
and
who
consents
being
given
to
its
being
consent
that
the
user
is
consenting
to
both
of
them
getting
the
data
and
that
the
bank
is
the
one
that's
managing
consent
and
it
is
the
a
S
or
the
API.
The
bank
is
providing
to
the
aggregator.
C
C
We
got
a
fair
amount
down.
I
think
we
get.
Time
are
sure.
Almost
many
of
the
topics
where
we
were
doing
some
suggestion
going
forward
would
be
maybe
only
having
one
topic
or
maybe
longer
period
of
time.
I
think
it's
easy
for
everybody
to
go
and
end
early,
but
we
all
have
to
end
at
the
end
of
the
lot
of
time.
That
would
be
my
one
suggestion
to
improve
it.
C
Yep
doesn't
seem
like
we're
necessarily
is
efficient
in
the
virtual
meetings
as
we
do
are
in
a
physical
meeting,
because
we
don't
have
all
the
same
signals.
You
know,
whoever
speaking
doesn't
really
know.
I
think
I've
lost
everybody's
attention
and,
as
chairs
I'm
sure
it's
hard
for
you
to
see,
you
know
understand
whether
it's
consensus
or
not
productive,
just
short
of
time,
often.
A
E
K
E
Like
the
idea
of
either
one
topic
per
meeting-
or
maybe
ninety
minute
calls
instead
because
they
have
been
very
helpful
and
I-
think
it's
actually
even
sometimes
in
in
some
ways
it's
actually
more
helpful
having
them
virtually
eventually
pack,
everything
into
you
know
to
two-hour
sessions.
We
get
at
the
IETF
meetings.
A
So
we
wanted
to
limit
it
to
1/2
an
hour
just
because
we
don't
want
to
happen
two
hours
you
might
distracted
and-
and
it
might
be
too
much
so
that
that's
the
reason
we
wanted
to
limit
it
to
one
hour.
But
the
idea
of
limiting
the
one
hour
to
to
one
topic
I
think
it's
a
good
idea.
Unless
the
topics
are
small
and
whatever
so
but
yeah
we'll
take
that
into
consideration.
Good
feedback
just.
D
A
H
Yeah
mostly
want
to
+1
Justin's
comment.
Reiterate
like
a
one-size-fits-all
approach,
isn't
isn't
appropriate
here,
they're,
definitely
for
topics
that
have
become
little
bit
established
one
hour
for
just
that.
Topic
makes
a
lot
of
sense,
but
we
may
also
want
to
have
possibly
on
a
separate
schedule,
a
sort
of
almost
like
a
not
going
to
almost
like
a
dispatch
kind
of
meeting.