►
From YouTube: OAUTH WG Interim Meeting, 2021-03-29
Description
OAUTH WG Interim Meeting, 2021-03-29
A
Okay,
welcome
everyone
for
the
wealth
internet
meeting,
so
this
is
the
not
well
as
a
reminder.
This
applies
here
too.
A
So
today
we
have
two
topics:
the
apply
intermediary
metadata
that
aaron
will
talk
about,
and
the
multi-subject
jot
that
I
will
be
talking
about
later
on
next
week.
Torsten
will
be
talking
about
rar
and
I
still
have
to
schedule
a
meeting
for
all
2.1
to
continue
that
discussion.
So
aaron
would
may
third
work
for
you
guys
and
dick.
A
B
B
B
Right,
yeah,
sorry
getting
my
window
in
order:
okay,
so
yeah
the
client
intermediary
metadata.
This
is
a
draft.
I've
been
working
on
with
some
other
other
folks,
I'll
mention
them
shortly,
but
I
want
to
give
a
quick
summary
of
what
the
spec
does.
What
the
idea
behind
spec
is
and
then
talk
about
the
use
cases
for
it
as
well.
B
It
is
not
a
lot
there's,
not
a
lot
going
on
here.
It
is
basically
extending
the
dynamic
client
registration
spec
to
provide
additional
information
about
additional
parties
involved
in
an
oauth
transaction.
So
this
is
basically
all
it's
adding
it's
adding
a
section
called
intermediaries
to
that
registration
request,
describing
a
list
of
additional
parties,
whether
that's
going
to
be
a
company
of
some
sort
that
would
get
access
to
data
after
the
oauth
flow
is
complete,
that'll,
be
accessing
that
data
in
some
way.
B
The
other
end
of
this
is
that
the
authorization
server
is
expected
to
actually
display
this
on
the
consent
screen
as
well,
so
where
we
have
normally,
we
would
have
the
consent
screen
show
just
the
client
id
of
the
application.
That's
getting
access
to
someone's
data.
We
we
need
to
also
be
able
to
list
out
additional
parties
that
would
be
getting
that
access
as
well.
B
So
that's
the
mechanism
again,
it's
not
a
very
complicated
addition
to
the
spec,
but
I
want
to
talk
about
some
of
the
motivation
for
having
this
in
the
first
place.
So
in
the
traditional
oauth
model,
the
oauth
client
is
the
one
that's
getting
registered
at
the
at
the
authorization
server.
It's
getting
the
client
id,
possibly
client
secret
and
that's
used
in
the
consent
process,
as
well
as
for
the
authorization
server
to
make
internal
policy
decisions
about
token
lifetimes
or
whatever
it
is.
B
That
is
that's
a
traditional
model
in
the
financial
world.
What
ends
up
happening
is
you
have
an
app
like
a
budget
tracker
app
or
your
your
tax
software
or
your
accounting
software?
That's
going
to
go
and
pull
transaction
data
from
multiple
different
banks.
Now
each
of
those
banks,
of
course,
will
have
their
own
authorization
servers.
So
we
have
this
one
client
talking
to
many
different
apis
and
in
practice,
what
ended
up
happening
is
that
these
applications
actually
don't
talk
to
each
bank's
api
directly.
They
actually
go
through
these.
B
This
new
sort
of
layer
of
infrastructure,
these
aggregator
apis
and
those
aggregate
aggregator
apis,
will
end
up
with
the
the
actual
contract
and
the
relationship
with
the
banking
apis
and
that
layer's,
the
only
one
that
the
team
apis
actually
know
about,
and
then
the
application
will
go
and
register
at
the
aggregator
to
get
credentials
to
talk
to
all
the
different
banks.
So
in
practice
it
ends
up.
Looking
like
this,
we've
got
a
whole
bunch
of
different
applications
talking
to
different
aggregators
that
all
talk
to
different
banks.
B
So
the
question
then
here
is
what
is
the
client
id
and
how
does
that
involve?
How
does
that
influence
the
consent
process?
So
is
it
the?
Is
it
the
application
the
end
user
is
using?
Is
it
the
aggregator?
Is
it
some
combination
of
of
the
chain
and
why
this
starts
to
involve
actually
needing
a
spec
around
it?
Is
you
know
the
banks
do
want
to
ensure
that
the
user
has
is
informed
and
has
agreed
to
share
their
data
with
the
application,
as
well
as
any
of
the
intermediary
companies
that
are
processing
that
data.
B
So
video
with
the
the
idea
with
the
intermediate
area,
metadata
spec,
is
that
the
dynamic
client
registration
request
establishes
the
whole
chain
of
of
entities,
so
it
establishes
the
the
application,
the
name
that
the
end
user
is
using
and
as
well
as
the
list
of
intermediaries
that
will
have
access
to
that
user's
data
when
they
are
using
this
application.
B
So
this
work
has
been
actually
going
on
for
a
while.
I
I
brought
this
up
last
year
after
the
after
doing
the
first
iteration
of
it.
Since
that
draft
it's
actually
been
simplified,
a
bit
and
really
minor
changes
but
overall,
simpler
and
it
is
being
used
in
the
financial
data
exchange,
which
is
a
it's
the
it's
a
non-profit
organization
around.
You
know
dealing
with
financial
apis
and
it's
got
a
whole
bunch
of
u.s
and
canada-based
institutions
that
are
adopting
these
that
are
trying
to.
B
You
know
now
adopt
oauth
for
their
financial
industry.
So
this
group,
this
is
a
group.
I've
been
working
with,
and
you
know,
they're
taking
oauth
and
now
with
happy,
as
well
as
the
foundation
for
the
the
financial
apis
and
adding
their
own
customizations
and
extensions
where
needed.
B
So
this
is
one
of
the
one
of
the
pieces
that
fits
into
the
puzzle
of
what
fdx
is
doing,
and
I
wanted
to
bring
this
up
to
the
group,
because
I
I
felt
like
this
problem,
that
of
establishing
these
additional
parties
is
not
actually
unique
to
the
financial
space
and
that's
the
reason
I
thought
it
was
relevant
to
bring
up
here,
because
otherwise,
if
it
was,
if
it's,
if
it's
extensions
that
are
only
going
to
be
relevant
to
the
financial
industry,
fine
you
know
fdx
can
can
go
and
create
an
extension
on
their
own.
B
But
the
I
felt
like
this
idea,
this
concept
of
these
intermediaries
would
apply
to
industries
other
than
the
financial
industry,
so
that
is
why
I'm
bringing
it
here
to
the
group.
So
that's
really
the
background.
I
have
on
this
happy
to
take
any
questions.
Otherwise
I
would
yeah
to
talk
about
adopting
this
in
our
group
here.
B
B
D
Yeah,
so
thanks
aaron,
a
thousand
thousand
years
that
come,
does
knowledge
that
yes.com,
I'm
forgetting
I'm
standing
in
a
queue
in
an
itf
meeting
candy.
Can
you
go
back
please
to
the
overview
chart
showing
the
aggregators
and
your
clients?
D
D
Thank
you
so
I'm
assuming
that
the
application
would
still
be
the
ultimate
client
and
had
the
client
id
and
the
aggregator
aggregators
or
the
intermediaries
would
then
be
listed
in
the
clients
metadata.
Is
that
correct.
B
Yeah
exactly
so,
the
end
user
wants
to
see
the
name
of
the
app
they're
using
as
the
primary
thing
on
the
consent
screen
so
budget
bunny
in
this
example,
or
whatever
their
yeah.
Whatever
that
app
is
and
then
the
the
intermediaries
would
be
the
just.
You
know
fine
print
of
who's
processing.
This
data.
D
D
What
typically
happens,
you've
got
a
policy
privacy
policy
for,
for
example,
budget
bunny,
and
that
policy
would
typically
list
all
the
intermediaries
that
are
used
in
processing
the
data.
So
I
mean
from
my
perspective,
this
is
a
legal
problem.
Another
technical,
because
typically
you've
got
one
ultimate
party
that
that
is
the
I
think
on
the
gdpr
called
the
data
controller,
so
the
ultimate
responsible
party-
and
there
are
other
other
parties
that
contribute
to
that
process.
But
typically,
what
you
do
is
you
assign
a
data
processing
to
remember
of
those?
D
And
then
you
take
them
into
your
policy
document,
so
the
user
can
inspect
and
and
review
the
document
they
can
decide
whether
this
is
okay.
So
my
question
is:
why
do
we
need
this
data
at
all
in
the
in
the
user
content
process?
If
that
can
be
handled
in
the
policy
and
that's
the
way
we
do
it
today,
for
example,
in
our
ecosystem.
B
E
Sure,
there's
so
clear
reasons,
a
couple
reasons
why
part
of
it's
you
know
pending
privacy,.
E
Hey
I'm
don
cardinal
managing
director
of
financial
data
exchange
thanks
part
of
it
has
to
do
with
in
north
america,
federal
state
and
provincial
privacy
rights
coming
out.
It's
not
just
enough
to
disclose
the
chain
at
the
app
that
level,
but
remember
we're
handing
this
session
all
the
way
through
and
every
party
in
the
chain
needs
to
see
the
chain
end
to
end,
because,
god
forbid,
you
have
a
breach
or
some
other
thing.
E
You
want
to
know
with
the
other
nodes
in
the
chain
plus,
when
you
disclose
at
the
data
source,
the
bank
or
the
brokerage
being
able
to
say
hey,
you
just
got
a
request
from
budget
bundling
through
alligator,
it's
very
important,
so
the
end
user
is
fully
consented
to
not
just
the
data
elements,
but
the
chain
used
to
get
there.
It's
again,
full
transparency
end
to
end
plus
it
supports
fraud,
use
cases.
That's
primarily,
why
we're
wanting
to
do
that.
E
F
And
this
is
anil
mahala,
also
part
of
ftx.
I
work
for
claire.
I
run
a
few
co-chair,
a
few
committees
and
and
working
groups
in
ftx
tarzan,
so
as
you're
familiar
right.
The
client
in
this
case
does
not
have
a
relationship
with
the
data
provider
at
all.
Only
the
aggregator
does
right,
so
there
is
no
bilateral
that
is
being
signed
offline
to
keep
that
in
check.
So
the
reason
for
this
is
to
have
transparency.
F
Yes,
the
client
id
is
being
provided
to
budget
bunny
in
this
case,
but
the
aggregator
is
the
mediator.
Who
has
the
relationship
with
the
provider
and
therefore
the
provider
would
get
full
visibility
into
where
all
the
data
is
going?
In
addition
to
that,
a
budget
bunnies
end
user
would
then,
when
they
are
on
the
provider,
can
also
be
the
provider
can
also
show
them
where
they
are
coming
from
and
and
make
sure
that
they
understand
where
all
the
data
is
going.
D
E
D
Then
the
question
directly
pops
up,
how
does
fox
bunny
is
able
or
how
does
it
work
in
the
end
I
mean
aaron
just
pointed
out
or
explained
that
the
client
id
the
ultimate
client
id
is
is
assigned
to
box
funny.
That's
the
only
chance
that
the
data
provider
is
able
to
determine
okay.
This
is
the
client
id.
This
is
box
bunny
or
this
is
budget
money.
I'm
gonna
show
a
user
content
screen
for
budget
funny.
It's
not
sorry,
so
I
mean
I
I
don't
understand
how
this
is
gonna
work
from
a
technical
perspective.
D
If,
if
alligator
has
the
contract,
then
alligator
would
need
to
have
it
or
would
have
the
client
id
so
budget
bunny
basically
would
be
unable
to
even
start
an
oauth
dialogue
with
the
data
provider.
So
I'm
I'm
confused
yeah.
F
Yeah,
so
the
client
id
that
is
issued
is
is
held
by
the
aggregator
in
the
previous
slide.
The
bugs
money
does
not
get
that
client
id
or
secret
it
is.
It
is
issued
to
the
aggregator
on
behalf
of
bugs
bunny
and
the
relationship
is
between
the
aggregate
and
the
data
provider
and
and
therefore
that's
how
the
auth
is
initiated.
F
And
that's
the
reason
why,
when
you
brought
up
privacy-
and
you
know
the
bilateral
bugs,
but
a
budget
bond
is
not
even
in
the
picture
with
these,
you
know
the
bilateral
agreements
that
that
are
in
place
now.
This
may
be
unique
to
the
financial
industry,
but
that's
how
it's
set
up.
D
I
am
fully
understood,
so
I
can't
really
assess
whether
this
is
unique,
but,
according
to
what
you
said
now,
I
would
assume
alligator
would
be
the
ultimate
client,
so
a
normal
over
authorization
so
would
display
alligator
in
the
in
the
top
line
of
the
of
the
user
content
screen
and
allegation
would
authenticate
towards
the
data
provider,
which
means
in
the
end
alligator
would
be
the
client,
and
that
would
also
mean
that
if
the
information
that
the
ultimate
rp
is
or
the
ultimate
client
is
budget
money,
then
we
would
need
to
turn
it
around.
D
B
No,
that's
that's
you're
right,
but
doing
it
that
way
ends
up
that's
actually
closer
to
how
we
had
it
and
in
the
first
draft
of
this,
with
an
additional
concept
of
the
end
user
application,
which
was
more
along
those
lines
of
the
this
intermediary
alligator
being
the
primary
entity
register
at
the
data
provider
and
then
adding
an
extension
to
display
the
brand
name
and
the
one
of
the
one
of
the
iterations
we
went
through
was,
let's
reduce
the
number
of
things
being
added
here
and
instead
make
the
client
name
property
and
the
registration
request,
the
user
recognizable
name,
adding
only
the
intermediary
information
into
the
into
the
chain.
B
Yeah,
I
was
actually
jumping
on
to
to
make
a
similar
observation.
This
effectively
is
utilizing
dynamic
registration
to
register,
not
a
single
client
in
the
way
that
we
tend
to
think
about
it
in
oauth,
usually,
but
where
client
is
representative
of
a
particular
instantiation
of
that
chain
right,
and
so,
if
the
budget
bunny
talks
to
a
different
aggregator,
it
would
necessitate
a
whole
new
registration
in
a
whole
new
chain.
So
my
question
to
the
presenters
and
apologies-
I
haven't
had
a
chance
to
re-read
this
recently.
B
Are
there
any
considerations
given
to
authenticating
the
average,
the
aggregator
during
its
registration
request?
This
is
something
that,
as
you
know,
dynamics
registration
allows
but
leaves
very,
very
wide
open
to
interpretation
and
that's
yeah,
so
the
yeah
for
sure
the
this
draft
doesn't
talk
about
it
at
all,
because
it
is
similarly
not
really
relevant
to
the
concept
of
intermediaries.
B
The
app
specific
application
of
the
collection
of
these
oauth
documents,
this
being
one
of
them,
that's
being
done
in
the
fdx
group.
That
spec,
which
is
an
fdx
spec,
lists
out
all
those
additional
requirements
of
here's.
How
this
registration
request
is
authenticated.
Here's
how
these
entities
are
going
to
set
up
these
relationships,
but
that
part
I
didn't
feel
like
was
relevant
to
the
rest
of
the
rest
of
the
industry,
because
it
is
something
that
is
specific
to
how
it's
being
applied.
B
A
B
B
So
I
yes,
I
we
should
probably
add
a
privacy
consideration
section,
but
it's
going
to
basically
say
that
it
is
the
whole
goal
of
this
is
to
allow
users
to
see
who
is
getting
access
to
their
data.
B
Yeah
I
just
wanted
to
follow
up
with
with
that
notion
about
privacy.
Both
the
privacy
and
security
of
this,
as
it's
been
described
so
far,
seem
to
assume
good
intentions
on
behalf
of
the
various
parties,
and
I
think
if
this
spec
is
going
to
go
forward,
it's
going
to
need
some
very
serious
discussion
about
what
happens
when
an
aggregator
lies
about
the
client
that
it's
representing
or
a
client
tries
to
lie
about
being
part
of
an
aggregator
or
any
of
these
various
chains.
B
Right
says
this
is
this
is
all
well
and
good
if
you
can
actually
trust
that
the
registration
that
took
place
actually
references,
the
the
the
parties
that
are
being
identified
right,
and
so
this
this
is
part
of
what
I
was
getting
back
to
the
last
point
that
I
tried
to
make
about.
You
know
it's
sort
of
when
you
allow
registration
where
that
trust
route
really
comes
from,
and
I
think
that
to
me
that
that
really
sits
at
the
root
of
the
potential
privacy
and
security
considerations.
You'd
have
here.
B
That's
a
great
point,
and
I
think
unfortunately
like
mo
like
many
things
in
the
oauth
world,
it
is,
it
is
out
of
out
of
band
information
that
gets
where
that
that
that
stuff
gets
locked
down
and
takes
place.
But
I
agree
that
it's
worth
pointing
it
out,
specifically
in
in
a
section
in
the
draft
of
the
fact
that
whoever's
off
doing
the
authenticated
registration
call
is
the
one
that
is
being
trusted
to
provide
the
information
and
the
that
information
is
only
as
valid
as
the
as
that
registration
request.
B
Authentication
was
right
exactly
even
if
the
information
is
coming
out
of
band
it,
it
needs
to
be
spelled
out.
Now,
I'm
not
faulting
you
for
not
having
that
laid
out
in
an
id.
Heaven
knows
that's
the
last
section
I
tend
to
write
and
in
any
detail
in
specs
that
I've
worked
on
as
well.
B
So
I
get
that,
but
this
is
going
to
be
really
important
because
for
this
spec
in
particular,
because
this
is
changing
the
it's
not
changing,
but
it's
challenging
the
assumptions
that
oauth
makes
yeah
in
terms
of
the
understanding
of
what
a
client
id
means.
A
Okay,
thurston.
D
Yeah,
along
the
same
lines,
I
mean
in
the
end
I'm
starting
to
understand
that
in
the
end,
the
data
provider
or
the
ias
relies
on
the
on
the
aggregator
regarding
the
identity
of
the
application
that
it
acts
on
behalf
of.
But
I
mean
that
reminds
me
of
use
cases
that
we
also
have
in
the
pc2
world,
where
a
an
aggregator
is
used
to
initiate
a
payment.
D
Instead,
I
would
because
they
are
very
expensive
and
complicated
to
obtain
either
certificate
involved
in
the
underclient
authentication,
and
I
would
assume
that
I
would
like
to
or
would
try
to
solve
that
problem
using
trans
transaction,
specific
parameters
just
to
inform
the
the
content
flow.
So
I
am,
I
am
agriculture,
alligator
corp,
and
now
I'm
acting
on
the
off
of
budget
bunny.
So
could
you
envision
to
solve
that
problem?
D
Also,
on
a
transaction
basis,
I
mean,
I
think,
dynamic
registration
is
just
one
way
to
solve
it,
but
since
there
is
any
way,
a
trust
relationship
between
the
aggregator
and
the
data
provider,
those
data
could
come
with
every
authorization
request.
Basically.
B
That
is
an
interesting
point.
I
don't
think
we've
talked
about
that
with
the
fdx
group.
I
I
could
bring
it
up
in
the
in
the
api
group,
but
that
would
be
a
much
bigger
change
compared
to
what
they
are
currently
planning
on
doing
there.
B
I
I
know
that
there's
a
lot
of
thought
being
done
to
keeping
track
of
the
of
the
trust
chains
and
and
for
auditing,
and
things
like
that,
so
we
would
have
to
go
back
to
the
list
of
those
use
cases
in
order
to
see
if
we're
doing
a
runtime
would
yeah.
I.
D
Mean
from
my
experience
in
regulated
environments,
you
will
need
to
anyway
keep
track
of
those
interactions
on
a
pair
transaction
basis,
because
in
the
end,
if
you,
if
you're
seeing
a
dispute
or
a
something
like
that,
you
will
need
to
have
an
audit
or
a
trail
of
of
a
specific
transaction,
not
just
the
static,
how
to
say
image
of.
What's
what
what's
happened
with
a
certain
client.
So
I
think
I.
B
D
Would
I
would
tie
that
to
the
grant
to
the
particular
grant,
for
example,
refresh
token
or
access
token,
but
just
just
an
idea
right.
Just
thinking
about.
F
Well,
this
is
an
if
I
could,
chime
in
the
sfdx
is
looking
into
the
console
api
person
to
see
how
we
can
provide
consent
information,
what
data
clusters,
because
the
end
user
is
agreeing
to
the
time
frame.
We
have
also
looked
into
the
rar
to
see
if
that
might
be
a
way,
but
we
are
definitely
looking
at
the
fine
grain
consent
on
and
on
on
with
every
authorization
that
would
have
to
be.
You
know
or
played
on
the
on
the
bunny
budget,
bunny
site
and
then
replayed
on
the
data
provider
side.
F
So
then
it
could
be
recorded.
But
yes,
we
are
looking
into
that,
but
this
one
for
intermediary
is
just
laying
down
the
rails
for
registration,
and
then
all
of
the
consent
is
going
to
write
on
those
rails
to
make
sure
yep.
This
is
the
client.
This
is
the
intermediary.
We
have
actually
gone
further
into
the
fdx
one
where
we
have
sub-intermediaries
as
well,
but
this
was
just
only
during
registration
once
the
registration
is
done,
there's
a
lot
more
going
on
for
authentication
authorization.
H
Not
sure
many
people
know
how
plaid
and
others
work
today,
but
they
don't
use
oauth
at
all
right.
The
user
is
typing
in
the
credentials
for
their
financial
institution
into
the
app
in
a
window
that
plaid
puts
up.
So
plaid
gets
the
username
password
directly
of
your
financial
institution,
takes
that
calls
the
bank
it's
back
something
and
manages
all
so.
H
B
I
should
have,
I
should
have
started.
I
should
have
opened
with
that.
Sorry.
The
whole
goal
of
any
of
this
work
being
done
in
fdx
is
to
exactly
stop
that
behavior
of
let's
stop
users
entering
credentials.
We
need
a
solution
to
it.
Well,
if
there's
a
it
turns
out,
there
is
a
solution.
It's
oauth,
it's
been
around
for
a
while.
I
don't
know
if
you've
heard
about
it
and
let's
see
if
we
can
actually
get
banks
to
adopt
it.
So
that
is
that
is
the
work
that's
going
on
in
in
fdx
right
now,.
H
Yeah,
so
the
pushback
arm
that
platt
has
provided
and
is
argued
in
a
number
of
their
discussions
with
regulators-
is
that
apps
don't
want
to
have
to
do
the
redirect,
and
so
you
know
it's
a
cleaner
experience
and
a
simpler
experience
and,
of
course,
the
app
people
are
happy
to
do
that
and
stuff
like
that.
So,
while
I
think
we
can
argue
about
the
oauth,
I
think
it's
actually
going
to
get
driven
more
in
a
regulatory
framework
as
opposed
to.
E
Yeah
now
we've
got
12
and
that
number
is
going
to
go
up
a
lot:
bigger
million
consumers
in
north
america.
That's
why
fdx
has
almost
200
member
organizations.
That's
the
difference.
What's
the
heck?
What's
the
use
of
a
spec?
If
no
one
can
support
it,
so
we're
seeing
a
lot
more
enabled.
Endpoints,
you
see
firms
like
akoya
and
we
do
have
plat
on
record,
saying:
hey.
E
A
Me,
okay,
so
so
like
what
are
you
looking
for
aaron
right
now?
Are
you
are
you
expecting
that
like
are
you?
Are
you
looking
for
the
work
group
to
decide
if
they
want
to
adopt
it
right
now,
or
is
it
like
what
what's
that.
B
Yeah,
I
guess
the
the
the
fdx
is
moving
forward
with
this.
With
this
work,
you
know
they're
progressing
with
their
own
compiling
various
building
blocks,
so
it
sounds
like
we
yeah
I.
As
far
as
my
immediate
feedback
or
task
on
this,
I
definitely
will
work
on
adding
a
privacy
consideration
section
to
this,
but,
assuming
that
that
exists,
my
question
to
the
group
is
more.
Is
there
something
that
other
people
would
benefit
from
being
a
ietf
standard?
B
B
Yeah,
just
real
quick
to
the
fdx
folks.
If
this
work
is
picked
up
by
the
oauth.
C
B
Group
and
the
oauth
working
group
decides
to
slice
it
into
tiny
pieces
chop
it
up,
put
some
ribbons
on
it
and
then
publish
it
as
something
that's
almost
unrecognizable
which,
as
we
all
know,.
B
When
that
happens,
what
is
what
is
fdx's
plan
for,
for,
following
that
kind
of
fork,
like
is?
Is
there
actually
a
formal
engagement
plan
for
following
in
a
standard
through
its
development
cycle,.
F
So
I
don't
know
what
I'm
I'm
not
familiar
with
how
atf
works.
So
if
you
want
to
chop
it
up
and
it's
minced
meat
we'll
have
to
see
if
you
can
still
make
a
burger
out
of
it.
So
I'm
not.
D
F
Sure
it's
a
hypothetical
question,
but
I'll
let
you
know
if,
if
this
goes
through,
which
we've
been
working
on
quite
a
bit,
we
can
you
know
as
you
you
know,
break
it
up.
We
can
have
conversations
then,
and
what
you
plan
on
doing.
B
Neil
is,
if
you
know
if
there's
changes,
breaking
changes
as
it
goes
through
the
process
is,
you
know,
is
fdx
willing
to
incorporate
those
back
into
the
into
the
fdx
work.
E
Mind
as
long
as
it's
fit
for
purpose,
we
don't
have
a
lot
built
on
it
yet,
but
we
are
planning
on
building
to
what
version
three's
got
out
here.
That
being
said,
you
know
the
market
need
for
this
for
a
white
pages,
yellow
pages,
if
you
will
and
that
transparency
for
privacy
stuff
to
yeah,
we
certainly
want
to
where
we
can
reuse,
ietf,
fido,
w3c
nist,
you
know
fappy.
We
don't
want
to
reinvent
the
wheel,
but
to
the
extent
we
can
support
it.
B
B
E
Right
granted,
we
can
deal
with
that,
whether
we
have
a
legacy
term
or
historical
versions,
5.0
or
higher.
We
can
deal
with
that.
It's
now
called
this.
We
can
make
it
port
stuff,
like
that
backward
portable,
that's
not
an
issue
if
it
becomes
where
the
business
purpose,
the
regulatory
purpose
behind
it
isn't
usable,
that's
an
issue,
but
as
long
as
it's
fit
for
purpose
I
think
arose
by
any
other
team.
We
can
make
that
work.
B
Right,
yes,
so
the
I
phrased
my
question
a
bit
glib
and
I
apologize
for
that,
but
the
the
reason
I'm
asking
is
that,
because
this
is
an
external
group
that
do
you
guys
have
you
know,
requirements
to
ship
something
and
that
absolutely
makes
sense.
B
B
That
said,
people
do
balance
this
kind
of
situation
all
the
time
I
the
itf
is
made
up
of
companies
that
bring
existing
technology
into
the
group,
and
then
you
know
work
with
it
and
and
tweak
things
as
it
changes.
And
these
specific,
a
specific
precedent
you
might
be
interested
in
is
when
open
banking
uk
first
got
aligned
with
the
fappy
working
group.
B
B
F
Right,
yeah
yeah,
I
think
what
I'm
getting
out
of
it.
This
is
that
we
have
to.
If
we
come.
If
we
are
okay
with
this,
then
we
have
to
commit
to
participate
in
in
future
conversations
as
things
are
being
shaped,
so
that
we
can
ask
the
right
questions
and
make
sure
that
it
is
backwards
compatible
and
if
not,
that
there's
a
plan
for
us
to
inform
our
members
that
a
breaking
change
is
going
to
come
and
here's
the
reasons
why
it's
breaking.
F
B
Sorry,
I
don't,
I
don't
have
anything
else
to
add
here,
but
I
also
don't
know
exactly
what
to
do
for
the
next
step.
A
A
It
seems
that
that
like,
as
as
justin
mentioned
like
this
like
when
you
go
through
that
the
whole
process
of
idea,
this
could
completely
change
right
and
it
could
could
be
that
the
change
could
be
dramatic
right
and
and-
and
you
guys
have
to
understand
that
that
could
happen
right.
So
it's
it
is
something
that
happens
all
the
time
at
the
itf
right,
so
maybe
quickly.
A
I
I
want
to
ask
that
the
team
that
the
group
here
it's
a
small
list
of
people,
but
I
just
want
to
get
the
feeling
of
of
the
team
here-
are
people
interested
in
working
on
this
problem
here
at
that
at
the
author
group,
if
you
are
in
favor
of
kind
of
and
I'm
not
calling
for
adoption
right
now,
I
just
want
to
get
the
feeling
of
that
of
the
group
here.
A
A
A
Okay,
I
don't
see
anybody
charming
in
here,
so
it's
so,
let's,
let's
do
this
aaron,
so
I
think
we
we
need
to
probably
continue
that
discussion
on
the
on
the
mailing
list
and
and
see
if
we
can
get
more
people
kind
of
excited
about
this
and
interested
in
this
and
and
take
it
from
there
like,
if,
if
we
need
to
later
schedule
another
meeting
for
this,
that
would
be
fine,
but
let's
continue
that
discussion
on
the
mailing
list:
right,
yep,
okay,
okay,
thank
you!
Okay,
let's
switch.
C
C
C
A
Okay,
can
you
see
my
slides
looks
good?
Yes,
okay,
thank
you
and
okay,
so
I
would
like
to
talk
about
that
a
multi
subject,
so
that
the
job
document
defines
the
concept
of
a
nested
jot
where
one
job
contains
another
jot.
A
So
there
are
a
number
of
use
cases
that
require
the
token
to
include
multiple
subjects,
and
the
goal
of
this
document
is
to
define
a
jot
that
can
represent
those
multiple
subjects
and
relation
the
relationship
between
these
these
subjects,
using
that
the
nested
jobs
concept.
A
A
A
another
example
is.
The
second
example
is
where
you
have
two
primary
subjects.
An
example
is
a
married
couple
right
if
we
continue
that
to
a
pharmacy
example,
and
in
this
case
the,
as
would
be
set
up
to
provide
one
subject
with
permission
to
access
the
other
subject:
resources.
A
A
third
use
case
that
delegation
authority
is
that,
in
this
case
the
primary
subject
delegates
authority
over
a
resource
to
a
secondary
subject
to
acts
on
behalf
of
that
primary
subject.
An
example
is
a
user,
an
admin
relationship.
A
Like
a
fourth
use
case
is
what
we
call
what
I'm
calling
it
replaced
a
primary
subject,
and
there
are
two
different
use
cases
and
one
is
first,
example
is
used
by
stir,
which
is
a
telephony
use
case,
where
a
calls
b,
but
the
call
gets
redirected
to
c
the
redirection.
A
A
service
needs
to
provide
c
with
the
details
of
the
call,
including
the
original
called
number
or
person
b,
and
the
second
example
of
of
of
this
is
that
an
nsm
project,
which
is
a
mechanism
that
maps
the
the
service
mesh
concept
in
kubernetes
to
layer,
two
and
layer.
Three,
a
payload
in
this
case
messages
pass
through
multiple
intermediaries
and
each.
A
Will
create
a
new
token
to
pass
to
the
next
intermediary,
but
include
the
original
token.
So
these
are
the
number
of
kind
of
use
cases
that
would
require
or
need
such
a
such
a
a
job
or
a
concept
right.
So
in
this
case,
what
I'm
suggesting
here
is
they
define
a
new
claim
in
this
case
I'm
calling
it
r
sub
or
for
related
subject
to
hold
the
secondary
subject
and
its
relationship
to
to
the
primary
subject,
and
I'm
showing
example
here.
A
So
you
have
a
subject,
obviously
a
typical
subject,
which
is
stays
the
same,
a
an
r
subject,
which
is
a
related
subject,
which
has
two
claims,
one
relationship
or
rel
for
relationship
and
jot
for
the
the
enclosed
jot
that
would
be
carried
in
in
this
in
this
in
this
chart
right.
So
so
that
that's
what
what
I
I
have
in
mind.
A
A
I
A
Yeah,
in
this
case,
I'm
I'm
just
using
a
a
specific
urn
here
to
to
talk
about
the
relationship
between
the
the
related
subject
and
the
primary
subjects
right.
I
A
I
A
Maybe
the
syntax
is
not
there
like
a,
and
at
least
at
this
stage,
I'm
just
talking
a
at
the
concept
level,
whether
that
syntax
is
exactly
like
this
or
something
else.
I
I
don't
have
a
strong
opinion,
but
but
in
my
in
my
mind
what
I
have
in
mind
in
this
case,
you
will
have
either
authority,
for
example,
to
indicate
the
relationship
between
this
subject
and
the
primary
subject
or
primary
or
act
or
whatever
right.
A
A
A
I
believe
they
included
a
specific,
a
specific,
a
claim.
I
think
they
called
it
original
right,
but
yes,
yeah,
but
they
did
not.
I
don't
think
they.
They
provided
any
relationship,
because
it's
one
kind
of
use
case.
While
I
there
are,
as
you
can
see,
there
are
multiple
diffuse
use
cases.
So
what
I'm
trying
to
do
is
kind
of
make
it
more
generic
that
you
could
include
that
the
relationship
between
the
primary
and
the
secondary
jobs
right
the
subject.
A
I
D
A
J
Pitch
as
well
and
hotness
isn't
here-
and
I
I
think
we
have
this
a
little
bit
of
the
same
situation
as
we
had
in
the
previous
conversation
that
we
need
to
go
back
to
the
list
here
and
better
describe
the
dimensionality
of
what
what's
good,
what's
what's
being
kind
of
pitched
here
to
to
accomplish,
to
see
what
the
next
step
might
be.
Okay,.
A
Yeah
that
off
stop
shooting
here.
Okay,
okay,
I
think
that's
that's
all
we
have
then
for
today
and
just
before
you
guys
go
make
sure
to.
If
you
haven't
added
your
name
to
the
list,
let
me
paste
it
again
for
people
that
haven't
added
the
name.
Please
add
your
name
to
the
to
the
link
there
and
that's
all
we're
done
here.
Any
any
questions.
Comments
from
anybody
before
we
drop
here.