Subject: [Txauth] Use Case: Directed Tokens

From: Justin Richer <[email-masked]>
Date: Fri, 19 Jun 2020 16:49:31 -0400

One of the most important aspects to GNAP is going to be an ability to address things that OAuth 2 can’t, or at least can’t do without significant gymnastics. So with that, I wanted to bring back a use case discussion that originally came up while we were talking about the possibility of multiple access tokens, a few months back. I don’t know if this concept has a regular term, so I’m going to call it “directed access tokens” until we come up with something better — assuming we decide this is worthwhile. 

In OAuth, the client’s supposed to always know where to send its access token, and that knowledge is completely outside the protocol. This makes a lot of sense for many (if not most) deployments, as OAuth is really there to enable the API access that the client already knows about.

But we’re now in a world where a client could be talking to a generic API that could be deployed at a number of different places, or a cloud deployment that the AS wants to be able to dispatch the client to. In order to do this, the AS needs to be able to communicate to the client not only the token information (and any related key and presentation information), but also a set of directions about what that specific token is good for. This needs to be information outside the token itself, since I believe we want to keep OAuth 2’s feature of having the token be opaque to the client. Note: while we could map all of these to different resource requests (in XYZ parlance) or scopes (in OAuth 2 legacy parlance) on the request side, this isn’t enough to tell the client what to do with the token if it doesn’t know already. 

I know of two use cases already in the wild, where people are addressing things using a mix of existing standards and some proprietary extensions to address things within their silos. I’ll try to summarize here, but I know the folks I’ve been talking to about this are also on the list so hopefully they can chime in with more detail or any corrections for something I’ve missed. 

(1) The client knows what resource it’s calling, but it doesn’t know where it’s hosted. Everything is in a single security domain controlled by the AS, but the AS needs to decide at runtime which specific instance of the API to direct the client to. Since things are closely tied together, the client just needs to effectively known an identifier for the RS, and this is currently implemented as a URI. Once the client has that identifier, it knows how to dispatch that token to that instance of the RS.

(2) The client knows what kind of thing it’s looking for, but doesn’t know who to ask it from. There’s a cross-domain trust that’s bridged by the AS, and the AS needs to dispatch to different resources depending on which user logged in (and possibly what the user consented to). To make things more concrete, the client needs to get driver’s license information, but doesn’t know ahead of time which of the many state/provincial bureaus to call to get that information because it doesn’t know yet who the user is. The AS will know who the user is once they log in and approve things, and so it can direct the client to call the correct RS. Since this is a relatively simple API with a pre-negotiated cross-domain trust, the AS returns a URL that the client presents the token at. 

As far as I know, in both of these cases, the token is only good for that API and not others — but more on that later.

A simple thing to do is just give back a URL with the access token, which tells the client where to go. 

	{
		“access_token”: {
			“value”: “87yui843yfer”,
			“resource_uri”: “https://example/foo"
		}
	}

This is good for some kinds of APIs, but it’s limiting because not all APIs dispatch based on the URL. An AS might want to divvy up access tokens to an API that’s keyed on headers, or verbs, or any number of things. And it doesn’t tell us immediately what to do about non-exact URL matches. Can the client add query parameters and still use the token? What about path segments? I like that this simple approach addresses some common deployments that we already see today (see above), it’s not universal. Do we want or need a universal description language for directing where tokens go?

This also opens up a whole new set of security questions. If the AS can now direct the client where to use the token, could a rogue AS convince a legit client to use a stolen token at the wrong RS? And what if the client ignores the directions from the AS entirely? Could this open up new avenues of attack?

This is just the start, too. Things get even more complex if the client can ask for multiple different kinds of resources at once. What if the AS decides that the client needs a hyper-focused directed token for one part of the API, but can use a general token for other stuff? Can it signal that to the client? And if it can, does that mean that all clients need to be prepared for that kind of thing?

I firmly believe that whatever we build in GNAP, we need to optimize for the overwhelmingly common use case of a client getting a single access token to call APIs that it already knows about. Anything we add on top of that really can’t get in the way of this, because if it does, there’s very small chance that people will try to use this for everyday things. Keep the simple things simple, and the complex things possible, after all.

I’m really looking forward to hearing what the community thinks about these use cases, and hopefully the people I’ve chatted with offline about this can join the conversation and provide more light than I was able to.

 — Justin

---

From: Tom Jones <[email-masked]>
Date: Fri, 19 Jun 2020 13:57:59 -0700

here are some worked out samples of this:
https://wiki.idesg.org/wiki/index.php/High_Assurance_AZ_Token
https://mattrglobal.github.io/oidc-client-bound-assertions-spec/
Peace ..tom

On Fri, Jun 19, 2020 at 1:49 PM Justin Richer <[email-masked]> wrote:

> One of the most important aspects to GNAP is going to be an ability to
> address things that OAuth 2 can’t, or at least can’t do without significant
> gymnastics. So with that, I wanted to bring back a use case discussion that
> originally came up while we were talking about the possibility of multiple
> access tokens, a few months back. I don’t know if this concept has a
> regular term, so I’m going to call it “directed access tokens” until we
> come up with something better — assuming we decide this is worthwhile.
>
> In OAuth, the client’s supposed to always know where to send its access
> token, and that knowledge is completely outside the protocol. This makes a
> lot of sense for many (if not most) deployments, as OAuth is really there
> to enable the API access that the client already knows about.
>
> But we’re now in a world where a client could be talking to a generic API
> that could be deployed at a number of different places, or a cloud
> deployment that the AS wants to be able to dispatch the client to. In order
> to do this, the AS needs to be able to communicate to the client not only
> the token information (and any related key and presentation information),
> but also a set of *directions* about what that specific token is good
> for. This needs to be information outside the token itself, since I believe
> we want to keep OAuth 2’s feature of having the token be opaque to the
> client. Note: while we could map all of these to different resource
> requests (in XYZ parlance) or scopes (in OAuth 2 legacy parlance) on the
> request side, this isn’t enough to tell the client what to do with the
> token *if it doesn’t know already*.
>
> I know of two use cases already in the wild, where people are addressing
> things using a mix of existing standards and some proprietary extensions to
> address things within their silos. I’ll try to summarize here, but I know
> the folks I’ve been talking to about this are also on the list so hopefully
> they can chime in with more detail or any corrections for something I’ve
> missed.
>
> (1) The client knows what resource it’s calling, but it doesn’t know where
> it’s hosted. Everything is in a single security domain controlled by the
> AS, but the AS needs to decide at runtime which specific instance of the
> API to direct the client to. Since things are closely tied together, the
> client just needs to effectively known an identifier for the RS, and this
> is currently implemented as a URI. Once the client has that identifier, it
> knows how to dispatch that token to that instance of the RS.
>
> (2) The client knows what kind of thing it’s looking for, but doesn’t know
> who to ask it from. There’s a cross-domain trust that’s bridged by the AS,
> and the AS needs to dispatch to different resources depending on which user
> logged in (and possibly what the user consented to). To make things more
> concrete, the client needs to get driver’s license information, but doesn’t
> know ahead of time which of the many state/provincial bureaus to call to
> get that information because it doesn’t know yet who the user is. The AS
> will know who the user is once they log in and approve things, and so it
> can direct the client to call the correct RS. Since this is a relatively
> simple API with a pre-negotiated cross-domain trust, the AS returns a URL
> that the client presents the token at.
>
> As far as I know, in both of these cases, the token is only good for that
> API and not others — but more on that later.
>
> This is good for some kinds of APIs, but it’s limiting because not all
> APIs dispatch based on the URL. An AS might want to divvy up access tokens
> to an API that’s keyed on headers, or verbs, or any number of things. And
> it doesn’t tell us immediately what to do about non-exact URL matches. Can
> the client add query parameters and still use the token? What about path
> segments? I like that this simple approach addresses some common
> deployments that we already see today (see above), it’s not universal. Do
> we want or need a universal description language for directing where tokens
> go?
>
> This also opens up a whole new set of security questions. If the AS can
> now direct the client where to use the token, could a rogue AS convince a
> legit client to use a stolen token at the wrong RS? And what if the client
> ignores the directions from the AS entirely? Could this open up new avenues
> of attack?
>
> This is just the start, too. Things get even more complex if the client
> can ask for multiple different kinds of resources at once. What if the AS
> decides that the client needs a hyper-focused directed token for one part
> of the API, but can use a general token for other stuff? Can it signal that
> to the client? And if it can, does that mean that all clients need to be
> prepared for that kind of thing?
>
> I firmly believe that whatever we build in GNAP, we need to optimize for
> the overwhelmingly common use case of a client getting a single access
> token to call APIs that it already knows about. Anything we add on top of
> that really can’t get in the way of this, because if it does, there’s very
> small chance that people will try to use this for everyday things. Keep the
> simple things simple, and the complex things possible, after all.
>
> I’m really looking forward to hearing what the community thinks about
> these use cases, and hopefully the people I’ve chatted with offline about
> this can join the conversation and provide more light than I was able to.
>
>  — Justin
> --
> Txauth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth
>

---

From: Denis <[email-masked]>
Date: Mon, 22 Jun 2020 09:55:29 +0200

Hello Justin,

A few comments between the lines.

> address things that OAuth 2 can’t, or at least can’t do without 
> significant gymnastics. So with that, I wanted to bring back a use 
> case discussion that originally came up while we were talking about 
> the possibility of multiple access tokens, a few months back. I don’t 
> know if this concept has a regular term, so I’m going to call it 
> “directed access tokens” until we come up with something better — 
> assuming we decide this is worthwhile.

I don't understand what may mean "directed access tokens” but I 
understand what means "multiple access tokens".
When speaking of "multiple access tokens", these access tokens may come 
from one or more ASs.

> In OAuth, the client’s supposed to always know where to send its 
> access token, and that knowledge is completely outside the protocol. 
> This makes a lot of sense for many (if not most) deployments, as OAuth 
> is really there to enable the API access that the client already knows 
> about.
>
> But we’re now in a world where a client could be talking to a generic 
> API that could be deployed at a number of different places, or a cloud 
> deployment that the AS wants to be able to dispatch the client to.

As soon the AS is placed (again) at the centre of the model, the AS will 
have the ability to act as "Big Brother".
OAuth 2.0 has not taken care of privacy issues. On the contrary, GNAP 
should take care of them.

> In order to do this, the AS needs to be able to communicate to the 
> client not only the token information (and any related key and 
> presentation information), but also a set of /directions/ about what 
> that specific token is good for. This needs to be information outside 
> the token itself, since I believe we want to keep OAuth 2’s feature of 
> having the token be opaque to the client. Note: while we could map all 
> of these to different resource requests (in XYZ parlance) or scopes 
> (in OAuth 2 legacy parlance) on the request side, this isn’t enough to 
> tell the client what to do with the token /if it doesn’t know already/.
>
> I know of two use cases already in the wild, where people are 
> addressing things using a mix of existing standards and some 
> proprietary extensions to address things within their silos. I’ll try 
> to summarize here, but I know the folks I’ve been talking to about 
> this are also on the list so hopefully they can chime in with more 
> detail or any corrections for something I’ve missed.
>
> (1) The client knows what resource it’s calling, but it doesn’t know 
> where it’s hosted. Everything is in a single security domain 
> controlled by the AS,

Speaking of "multiple access tokens" is in contradiction with single 
security domain "controlled" by an AS.
A user may need to demonstrate some of his identity attributes granted 
e.g. by his bank but may also
need to demonstrate one or more diplomas granted by one or more 
universities. The bank cannot be
the "primary issuer" of a university diploma. It should not be either a 
"secondary issuer", because
the bank does not "/need to know"/ what are the diplomas of the user.

> but the AS needs to decide at runtime which specific instance of the 
> API to direct the client to. Since things are closely tied together, 
> the client just needs to effectively known an identifier for the RS, 
> and this is currently implemented as a URI. Once the client has that 
> identifier, it knows how to dispatch that token to that instance of 
> the RS.

There is no good reason why the AS should be involved in that step.
OAuth 2.0 is/was implicitly mandating a strong relationship between ASs 
and RSs which makes it non scalable.
GNAP should be based on a simple trust relationship : a given RS trusts 
some ASs for access tokens that contains some types of attributes.
An AS should not need to know in advance (or even at the time of an 
access token request) the RSs that are trusting it.

A client could first talk to a "global service provider" which has the 
knowledge of the different RSs affiliated to it.

> (2) The client knows what kind of thing it’s looking for, but doesn’t 
> know who to ask it from.

Once again, the client could first talk to a "global service provider" 
which has the knowledge of the different RSs affiliated to it.

> There’s a cross-domain trust that’s bridged by the AS, and the AS 
> needs to dispatch to different resources depending on which user 
> logged in (and possibly what the user consented to). To make things 
> more concrete, the client needs to get driver’s license information, 
> but doesn’t know ahead of time which of the many state/provincial 
> bureaus to call to get that information because it doesn’t know yet 
> who the user is.

When a user has a driving license, he knows its issuer. The user can 
then provide some hint to the client.

> The AS will know who the user is once they log in and approve things, 
> and so it can direct the client to call the correct RS. Since this is 
> a relatively simple API with a pre-negotiated cross-domain trust, the 
> AS returns a URL that the client presents the token at.

  A single AS should not be aware of all the attributes a user has.

>
> As far as I know, in both of these cases, the token is only good for 
> that API and not others — but more on that later.
>
> APIs dispatch based on the URL. An AS might want to divvy up access 
> tokens to an API that’s keyed on headers, or verbs, or any number of 
> things. And it doesn’t tell us immediately what to do about non-exact 
> URL matches. Can the client add query parameters and still use the 
> token? What about path segments? I like that this simple approach 
> addresses some common deployments that we already see today (see 
> above), it’s not universal. Do we want or need a universal description 
> language for directing where tokens go?
>
> This also opens up a whole new set of security questions. If the AS 
> can now direct the client where to use the token, could a rogue AS 
> convince a legit client to use a stolen token at the wrong RS? And 
> what if the client ignores the directions from the AS entirely? Could 
> this open up new avenues of attack?
>
> This is just the start, too. Things get even more complex if the 
> client can ask for multiple different kinds of resources at once. What 
> if the AS decides that the client needs a hyper-focused directed token 
> for one part of the API, but can use a general token for other stuff? 
> Can it signal that to the client? And if it can, does that mean that 
> all clients need to be prepared for that kind of thing?
>
> I firmly believe that whatever we build in GNAP, we need to optimize 
> for the overwhelmingly common use case of a client getting a single 
> access token to call APIs that it already knows about. Anything we add 
> on top of that really can’t get in the way of this, because if it 
> does, there’s very small chance that people will try to use this for 
> everyday things. Keep the simple things simple, and the complex things 
> possible, after all.
>
> these use cases, and hopefully the people I’ve chatted with offline 
> about this can join the conversation and provide more light than I was 
> able to.

The two use cases which are considered above are:

    (1) The client knows what resource it’s calling, but it doesn’t know
    where it’s hosted.
    (2) The client knows what kind of thing it’s looking for, but
    doesn’t know who to ask it from.

That does not mean in any way that these two use cases should be solved 
by placing the AS at the centre of the solution.

Denis

---

From: Tom Jones <[email-masked]>
Date: Mon, 22 Jun 2020 06:37:09 -0700

In a perfect world the AS is controlled by the user as resource owner or
agent. In my designs the AS is on the user's phone.

I like the term "Bound Token" better. It can contain many sub tokens as
data or by reference.

Of course other use cases are supported.

thx ..Tom (mobile)

On Mon, Jun 22, 2020, 12:55 AM Denis <[email-masked]> wrote:

> I don't understand what may mean "directed access tokens” but I understand
> what means "multiple access tokens".
> In order to do this, the AS needs to be able to communicate to the client
> not only the token information (and any related key and presentation
> information), but also a set of *directions* about what that specific
> token is good for. This needs to be information outside the token itself,
> since I believe we want to keep OAuth 2’s feature of having the token be
> opaque to the client. Note: while we could map all of these to different
> resource requests (in XYZ parlance) or scopes (in OAuth 2 legacy parlance)
> on the request side, this isn’t enough to tell the client what to do with
> the token *if it doesn’t know already*.
>
> AS,
> the bank does not "*need to know"* what are the diplomas of the user.
>
> but the AS needs to decide at runtime which specific instance of the API
> to direct the client to. Since things are closely tied together, the client
> just needs to effectively known an identifier for the RS, and this is
> currently implemented as a URI. Once the client has that identifier, it
> An AS should not need to know in advance (or even at the time of an access
> token request) the RSs that are trusting it.
>
> who to ask it from.
> There’s a cross-domain trust that’s bridged by the AS, and the AS needs to
> dispatch to different resources depending on which user logged in (and
> possibly what the user consented to). To make things more concrete, the
> client needs to get driver’s license information, but doesn’t know ahead of
> time which of the many state/provincial bureaus to call to get that
> information because it doesn’t know yet who the user is.
>
> When a user has a driving license, he knows its issuer. The user can then
> provide some hint to the client.
>
> The AS will know who the user is once they log in and approve things, and
> so it can direct the client to call the correct RS. Since this is a
> relatively simple API with a pre-negotiated cross-domain trust, the AS
> returns a URL that the client presents the token at.
>
> it’s hosted.
> who to ask it from.
> That does not mean in any way that these two use cases should be solved by
> placing the AS at the centre of the solution.
>
> Denis
>
>
>  — Justin
>
>
> --
> Txauth mailing list
> [email-masked]

---

From: Justin Richer <[email-masked]>
Date: Tue, 23 Jun 2020 13:51:09 -0400

I think an on-device AS is an important use case, and we’ve seen work in the DID and SIOP space that there are plenty of smart agents out there that can help this. There’s a lot of interesting investigation in the app2app space right now as well, and I think that uncoupling the interaction method from the browser is a good step towards supporting that — but we should probably start a separate thread on that topic. 

Of course, a server-based AS is still a hugely important use case, so we can’t ignore that while looking at different kinds of deployment patterns as well. 

 — Justin

> On Jun 22, 2020, at 9:37 AM, Tom Jones <[email-masked]> wrote:
> 
> In a perfect world the AS is controlled by the user as resource owner or agent. In my designs the AS is on the user's phone.
> 
> I like the term "Bound Token" better. It can contain many sub tokens as data or by reference.
> 
> On Mon, Jun 22, 2020, 12:55 AM Denis <[email-masked] <mailto:[email-masked]>> wrote:
> Hello Justin,
> 
>> One of the most important aspects to GNAP is going to be an ability to address things that OAuth 2 can’t, or at least can’t do without significant gymnastics. So with that, I wanted to bring back a use case discussion that originally came up while we were talking about the possibility of multiple access tokens, a few months back. I don’t know if this concept has a regular term, so I’m going to call it “directed access tokens” until we come up with something better — assuming we decide this is worthwhile.. 
> I don't understand what may mean "directed access tokens” but I understand what means "multiple access tokens". 
> When speaking of "multiple access tokens", these access tokens may come from one or more ASs.
> 
>> But we’re now in a world where a client could be talking to a generic API that could be deployed at a number of different places, or a cloud deployment that the AS wants to be able to dispatch the client to.
> As soon the AS is placed (again) at the centre of the model, the AS will have the ability to act as "Big Brother".
> OAuth 2.0 has not taken care of privacy issues. On the contrary, GNAP should take care of them.
> 
>> In order to do this, the AS needs to be able to communicate to the client not only the token information (and any related key and presentation information), but also a set of directions about what that specific token is good for. This needs to be information outside the token itself, since I believe we want to keep OAuth 2’s feature of having the token be opaque to the client. Note: while we could map all of these to different resource requests (in XYZ parlance) or scopes (in OAuth 2 legacy parlance) on the request side, this isn’t enough to tell the client what to do with the token if it doesn’t know already. 
>> 
>> (1) The client knows what resource it’s calling, but it doesn’t know where it’s hosted. Everything is in a single security domain controlled by the AS,
> Speaking of "multiple access tokens" is in contradiction with single security domain "controlled" by an AS. 
> A user may need to demonstrate some of his identity attributes granted e.g. by his bank but may also 
> need to demonstrate one or more diplomas granted by one or more universities. The bank cannot be 
> the "primary issuer" of a university diploma. It should not be either a "secondary issuer", because 
> the bank does not "need to know" what are the diplomas of the user.
> 
>> but the AS needs to decide at runtime which specific instance of the API to direct the client to. Since things are closely tied together, the client just needs to effectively known an identifier for the RS, and this is currently implemented as a URI. Once the client has that identifier, it knows how to dispatch that token to that instance of the RS.
> OAuth 2.0 is/was implicitly mandating a strong relationship between ASs and RSs which makes it non scalable.
> GNAP should be based on a simple trust relationship : a given RS trusts some ASs for access tokens that contains some types of attributes.
> An AS should not need to know in advance (or even at the time of an access token request) the RSs that are trusting it.
> 
> A client could first talk to a "global service provider" which has the knowledge of the different RSs affiliated to it. 
> 
>> (2) The client knows what kind of thing it’s looking for, but doesn’t know who to ask it from.
> Once again, the client could first talk to a "global service provider" which has the knowledge of the different RSs affiliated to it.
> 
>> There’s a cross-domain trust that’s bridged by the AS, and the AS needs to dispatch to different resources depending on which user logged in (and possibly what the user consented to). To make things more concrete, the client needs to get driver’s license information, but doesn’t know ahead of time which of the many state/provincial bureaus to call to get that information because it doesn’t know yet who the user is.
> When a user has a driving license, he knows its issuer. The user can then provide some hint to the client.
> 
>> The AS will know who the user is once they log in and approve things, and so it can direct the client to call the correct RS. Since this is a relatively simple API with a pre-negotiated cross-domain trust, the AS returns a URL that the client presents the token at. 
>> 			“resource_uri”: “https://example/foo <https://example/foo>"
>> 		}
>> 	}
>> 
> (1) The client knows what resource it’s calling, but it doesn’t know where it’s hosted.
> (2) The client knows what kind of thing it’s looking for, but doesn’t know who to ask it from. 
> 
> That does not mean in any way that these two use cases should be solved by placing the AS at the centre of the solution.
> 
> Denis
> 
>> 
>>  — Justin
>> 
>> 
> 
> -- 
> Txauth mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
> -- 
> Txauth mailing list
> [email-masked]

---

From: Justin Richer <[email-masked]>
Date: Tue, 23 Jun 2020 15:25:52 -0400

Denis, thanks for the great comments. I think that your trust model is pretty different from what I’d laid out initially, and while it’s an interesting and important one, it is not what I meant by “multiple access tokens” in my discussion below. I think that might be the cause of some disconnect here, but that doesn’t mean it’s out of reach for what the WG is after.

When I refer to multiple access tokens, and what the charter calls out as multiple access tokens, is the ability for the client to get several access tokens to get different resources from one request. I personally see this as an optimization of a specific set of use cases, some of which I discussed in my original email. There are others, I’m sure, but all the ones I’ve seen are around the client needing to get several different kinds of access through an AS. 

I think it’s going to be overwhelmingly common that a given RS is going to trust exactly one AS that it knows about ahead of time. But for RS’s that can trust multiple AS’s, then we should have a model that can accommodate that as well. That’s why the charter calls out methods for the AS and RS to communicate what the token’s good for. I think the basis of those methods is going to start with a common token model, and likely incorporate into things like token formats and introspection-style token APIs. 

 — Justin

> On Jun 22, 2020, at 3:55 AM, Denis <[email-masked]> wrote:
> 
> Hello Justin,
>

---

From: Tom Jones <[email-masked]>
Date: Tue, 23 Jun 2020 13:54:59 -0700

I am getting tired of the whack-a-mole approach of JAR this and RAR that,
what's next BAR, FAR, STAR ad infinitum? Can't we just define a bound token
type as a high order spec and then just riff on it instead of a full
standard for each and every iteration each with their own security and
privacy considerations? If we don't the number of id/az tokens will expand
in the same manner.
Peace ..tom

On Tue, Jun 23, 2020 at 10:51 AM Justin Richer <[email-masked]> wrote:

> I think an on-device AS is an important use case, and we’ve seen work in
> the DID and SIOP space that there are plenty of smart agents out there that
> can help this. There’s a lot of interesting investigation in the app2app
> space right now as well, and I think that uncoupling the interaction method
> from the browser is a good step towards supporting that — but we should
> probably start a separate thread on that topic.
>
> Of course, a server-based AS is still a hugely important use case, so we
> can’t ignore that while looking at different kinds of deployment patterns
> as well.
>
>  — Justin
>
>> come up with something better — assuming we decide this is worthwhile..
>>
>> where it’s hosted. Everything is in a single security domain controlled by
>> the AS,
>>
>> There’s a cross-domain trust that’s bridged by the AS, and the AS needs
>> to dispatch to different resources depending on which user logged in (and

---

From: Justin Richer <[email-masked]>
Date: Tue, 23 Jun 2020 17:11:27 -0400

Well that’s one of the biggest reasons I wanted to start this WG — to take all the extensions to the OAuth model and pull them together in a consistent way, instead of the ad-hoc duct-tape-over-time method that’s evolved in the OAuth world. This is also why I think it’s important to break from the OAuth 2 space in a few key ways, so we don’t drag that mess with us.

It’s my hope and goal that we can build a true next phase of evolution here, and not just paint over the hacks of the past and call it good. 

 — Justin

> On Jun 23, 2020, at 4:54 PM, Tom Jones <[email-masked]> wrote:
> 
> I am getting tired of the whack-a-mole approach of JAR this and RAR that, what's next BAR, FAR, STAR ad infinitum? Can't we just define a bound token type as a high order spec and then just riff on it instead of a full standard for each and every iteration each with their own security and privacy considerations? If we don't the number of id/az tokens will expand in the same manner.
> Peace ..tom
> 
> 
> On Tue, Jun 23, 2020 at 10:51 AM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>> On Jun 22, 2020, at 9:37 AM, Tom Jones <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Denis <[email-masked]>
Date: Wed, 24 Jun 2020 12:14:14 +0200

Justin, I fear we are still far away from an agreement about what this 
BoF should do.

Tom Jones is saying " I am getting tired of the whack-a-mole approach ..."

I don't agree with you when you write: "I think it’s going to be 
overwhelmingly common that a given RS is going to trust exactly one AS
that it knows about ahead of time". Such an architecture would have 
exactly the same limitations as OAuth 2.0. and would not be scalable.

Before we start, we should have a clear view of the whole picture rather 
than starting from one scenario and expanding it in many different 
directions.
For building an architecture, a pre-requirement is to define ALL the 
trust relationships. I don't believe that we have an agreement at this 
time on what
these trust relationships are.

You are also using the following wording: "methods for the AS and RS to 
communicate what the token’s good for".
With such a paradigm, it would be impossible to protect the user's privacy.

A key question is : Will GNAP take care of the user's privacy or will 
GNAP *prevent *to take care of the user's privacy ?

About "the ability for the client to get several access tokens to get 
different resources from one request" is indeed a complex case.

No one (including ASs) is able to predict in advance which access tokens 
will be needed, since they depend upon the kind of operation(s)
the client will be willing to perform. For privacy reasons, ASs should 
be kept ignorant of all the operations that a client is going to perform
on one or more resource servers. I believe that every effort should be 
made to avoid the AS to be in a position to be able to trace the operations
performed by its clients on various RSs.

To handle the complex case you envision, the full workflow of operations 
needs to be considered with a detailed focus on the time
at which the user's *consent and choice* happens (/consent and choice/ 
is the first privacy principle from ISO 29100).

First of all, an access token could be targeted to a service rather than 
to a server. This would already solve many cases.

When a RS needs to call another RS (which does not support the same 
service) then the client should be informed by the first RS.
His "consent and choice" should then be obtained by the first RS and, 
when the user agrees, the client should then ask an access token
to one of the ASs trusted by the second RS in order to perform the 
subsequent operation.

Denis

PS.  In an email sent on June 23 you wrote: " I think an on-device AS is 
an important use case".  I am sorry, but I don't understand.
        However, I do understand what "a server-based AS" is.

> Denis, thanks for the great comments. I think that your trust model is 
> pretty different from what I’d laid out initially, and while it’s an 
> interesting and important one, it is not what I meant by “multiple 
> access tokens” in my discussion below. I think that might be the cause 
> of some disconnect here, but that doesn’t mean it’s out of reach for 
> what the WG is after.
>
> When I refer to multiple access tokens, and what the charter calls out 
> as multiple access tokens, is the ability for the client to get 
> several access tokens to get different resources from one request. I 
> personally see this as an optimization of a specific set of use cases, 
> some of which I discussed in my original email. There are others, I’m 
> sure, but all the ones I’ve seen are around the client needing to get 
> several different kinds of access through an AS.
>
> I think it’s going to be overwhelmingly common that a given RS is 
> going to trust exactly one AS that it knows about ahead of time. But 
> for RS’s that can trust multiple AS’s, then we should have a model 
> that can accommodate that as well. That’s why the charter calls out 
> methods for the AS and RS to communicate what the token’s good for. I 
> think the basis of those methods is going to start with a common token 
> model, and likely incorporate into things like token formats and 
> introspection-style token APIs.
>
>  — Justin
>
>> On Jun 22, 2020, at 3:55 AM, Denis <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Hello Justin,
>>
>>> One of the most important aspects to GNAP is going to be an ability 
>>> to address things that OAuth 2 can’t, or at least can’t do without 
>>> the possibility of multiple access tokens, a few months back. I 
>>> don’t know if this concept has a regular term, so I’m going to call 
>>> it “directed access tokens” until we come up with something better — 
>>> This makes a lot of sense for many (if not most) deployments, as 
>>> OAuth is really there to enable the API access that the client 
>>> already knows about.
>>>
>>> But we’re now in a world where a client could be talking to a 
>>> generic API that could be deployed at a number of different places, 
>>> or a cloud deployment that the AS wants to be able to dispatch the 
>>> client to.
>>
>> As soon the AS is placed (again) at the centre of the model, the AS 
>> will have the ability to act as "Big Brother".
>>> presentation information), but also a set of/directions/ about what 
>>> that specific token is good for. This needs to be information 
>>> outside the token itself, since I believe we want to keep OAuth 2’s 
>>> feature of having the token be opaque to the client. Note: while we 
>>> could map all of these to different resource requests (in XYZ 
>>> parlance) or scopes (in OAuth 2 legacy parlance) on the request 
>>> side, this isn’t enough to tell the client what to do with the 
>>> token/if it doesn’t know already/.
>>>
>>> proprietary extensions to address things within their silos. I’ll 
>>> try to summarize here, but I know the folks I’ve been talking to 
>>> about this are also on the list so hopefully they can chime in with 
>>> more detail or any corrections for something I’ve missed.
>>>
>> the bank does not "/need to know"/what are the diplomas of the user.
>>
>> GNAP should be based on a simple trust relationship : a given RS 
>> trusts some ASs for access tokens that contains some types of attributes.
>> A client could first talk to a "global service provider" which has 
>> the knowledge of the different RSs affiliated to it.
>>
>> Once again, the client could first talk to a "global service 
>> provider" which has the knowledge of the different RSs affiliated to it.
>>
>>> The AS will know who the user is once they log in and approve 
>>> things, and so it can direct the client to call the correct RS. 
>>> Since this is a relatively simple API with a pre-negotiated 
>>> cross-domain trust, the AS returns a URL that the client presents 
>>> the token at.
>>
>>> This is good for some kinds of APIs, but it’s limiting because not 
>>> all APIs dispatch based on the URL. An AS might want to divvy up 
>>> access tokens to an API that’s keyed on headers, or verbs, or any 
>>> number of things. And it doesn’t tell us immediately what to do 
>>> about non-exact URL matches. Can the client add query parameters and 
>>> still use the token? What about path segments? I like that this 
>>> simple approach addresses some common deployments that we already 
>>> see today (see above), it’s not universal. Do we want or need a 
>>> universal description language for directing where tokens go?
>>>
>>> what if the client ignores the directions from the AS entirely? 
>>> Could this open up new avenues of attack?
>>>
>>> client can ask for multiple different kinds of resources at once. 
>>> What if the AS decides that the client needs a hyper-focused 
>>> directed token for one part of the API, but can use a general token 
>>> for other stuff? Can it signal that to the client? And if it can, 
>>> does that mean that all clients need to be prepared for that kind of 
>>> thing?
>>>
>>> access token to call APIs that it already knows about. Anything we 
>>> add on top of that really can’t get in the way of this, because if 
>>> it does, there’s very small chance that people will try to use this 
>>> for everyday things. Keep the simple things simple, and the complex 
>>> things possible, after all.
>>>
>>> I’m really looking forward to hearing what the community thinks 
>>> about these use cases, and hopefully the people I’ve chatted with 
>>> offline about this can join the conversation and provide more light 
>>> than I was able to.
>>
>> That does not mean in any way that these two use cases should be 
>> solved by placing the AS at the centre of the solution.
>>
>> Denis
>>
>>>
>>>  — Justin
>>>
>>
>> --
>> Txauth mailing list

---

From: Tobias Looker <[email-masked]>
Date: Fri, 26 Jun 2020 13:07:56 +1200

I find this feature interesting and think it could be an important pattern
going forward to enable an AS to be able to describe the utility of a token
to the client, however as already pointed out in the thread I think there
is some potential hidden complexity that would need to be ironed out such
that it does not make the simple things complicated.

Justin, do you see this feature as something the client has to explicitly
request, i.e "please give me access and instructions on how to use my
access" or rather that the AS would just return this information in
conjunction with the access token if it had it available?

Would a potential default be that if a client did for any reason not
support processing the additional information returned with the
access_token, just to ignore it? I think in the spirit of keeping the
simple things simple, this potentially makes sense?

As one of the authors of those mentioned drafts, I am interested in
discussing that, but perhaps on a seperate thread? As at least the bound
assertion spec is primarily concerned with binding mechanisms for the
artifacts produced from an authorization flow (specifically identity
claims), whereas I think directed access tokens is just more generally
talking about whether GNAP should support an AS conveying how to use an
access_token it produces during a flow with a client.

Thanks,
 <https://mattr.global>
*Tobias Looker*
Mattr
+64 (0) 27 378 0461
[email-masked]
 <https://mattr.global> 
<https://www.linkedin.com/company/mattrglobal> 
<https://twitter.com/mattrglobal> 
<https://github.com/mattrglobal>
This communication, including any attachments, is confidential. If you are
not the intended recipient, you should not read it - please contact me
immediately, destroy it, and do not copy or use any part of this
communication or disclose anything about it. Thank you. Please note that
this communication does not designate an information system for the
purposes of the Electronic Transactions Act 2002.

On Wed, Jun 24, 2020 at 10:14 PM Denis <[email-masked]> wrote:

> Justin, I fear we are still far away from an agreement about what this BoF
> should do.
>
> For building an architecture, a pre-requirement is to define ALL the trust
> relationships. I don't believe that we have an agreement at this time on
> what
> A key question is : Will GNAP take care of the user's privacy or will GNAP *prevent
> *to take care of the user's privacy ?
>
> the client will be willing to perform. For privacy reasons, ASs should be
> kept ignorant of all the operations that a client is going to perform
> at which the user's *consent and choice* happens (*consent and choice* is
> the first privacy principle from ISO 29100).
>
> His "consent and choice" should then be obtained by the first RS and, when
> the user agrees, the client should then ask an access token
> interesting and important one, it is not what I meant by “multiple access
> tokens” in my discussion below. I think that might be the cause of some
> disconnect here, but that doesn’t mean it’s out of reach for what the WG is
> after.
>
> When I refer to multiple access tokens, and what the charter calls out as
> multiple access tokens, is the ability for the client to get several access
> tokens to get different resources from one request. I personally see this
> as an optimization of a specific set of use cases, some of which I
> discussed in my original email. There are others, I’m sure, but all the
> ones I’ve seen are around the client needing to get several different kinds
> of access through an AS.
>
> I think it’s going to be overwhelmingly common that a given RS is going to
> trust exactly one AS that it knows about ahead of time. But for RS’s that
> can trust multiple AS’s, then we should have a model that can accommodate
> that as well. That’s why the charter calls out methods for the AS and RS to
> communicate what the token’s good for. I think the basis of those methods
> is going to start with a common token model, and likely incorporate into
> things like token formats and introspection-style token APIs.
>
>  — Justin
>
> it’s hosted. Everything is in a single security domain controlled by the AS,
>
>

-- 
This communication, including any attachments, is confidential. If you are 
not the intended recipient, you should not read it - please contact me 
immediately, destroy it, and do not copy or use any part of this 
communication or disclose anything about it. Thank you. Please note that 
this communication does not designate an information system for the 
purposes of the Electronic Transactions Act 2002.

---

From: Tom Jones <[email-masked]>
Date: Thu, 25 Jun 2020 21:38:31 -0700

I think Tobias & I have converged to a single request for a "bound" token.
I really don't care much what it is called. I do have some input on the
continents of the claims.
Peace ..tom

On Thu, Jun 25, 2020 at 6:08 PM Tobias Looker <[email-masked]>
wrote:

>> trust relationships. I don't believe that we have an agreement at this time
>> on what
>> at which the user's *consent and choice* happens (*consent and choice*
>> I think it’s going to be overwhelmingly common that a given RS is going
>> to trust exactly one AS that it knows about ahead of time. But for RS’s
>> that can trust multiple AS’s, then we should have a model that can
>> accommodate that as well. That’s why the charter calls out methods for the
>> AS and RS to communicate what the token’s good for. I think the basis of
>> those methods is going to start with a common token model, and likely
>> incorporate into things like token formats and introspection-style token
>> APIs.
>>
>>  — Justin
>>
>> Txauth@ietf..org <[email-masked]>
> This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.
>
> --
> Txauth mailing list
> [email-masked]

---

From: Justin Richer <[email-masked]>
Date: Fri, 26 Jun 2020 09:23:15 -0400

On Jun 25, 2020, at 9:07 PM, Tobias Looker <[email-masked]> wrote:
> 
> I find this feature interesting and think it could be an important pattern going forward to enable an AS to be able to describe the utility of a token to the client, however as already pointed out in the thread I think there is some potential hidden complexity that would need to be ironed out such that it does not make the simple things complicated.
> 
> Justin, do you see this feature as something the client has to explicitly request, i.e "please give me access and instructions on how to use my access" or rather that the AS would just return this information in conjunction with the access token if it had it available?
> 

This is something that I’d brought up as a possibility on the previous thread — something like a flag the client would set. This would be especially important if the AS wants to return multiple access tokens but the client requested 1, or the client requested N and the AS wants to return M in response. Basically any time there’s a mismatch, that’s extra complexity on the client that I really don’t think we want to be universal. A flag to turn that kind of direction and splitting on would be a potential start. But there are potential snags here too, and it comes down to how you manage the defaults...

> Would a potential default be that if a client did for any reason not support processing the additional information returned with the access_token, just to ignore it? I think in the spirit of keeping the simple things simple, this potentially makes sense?

That’s the real trick, if you ask me. It has to be :safe: for a client to ignore this information. Which means the AS can’t rely on the client “doing the right thing” with the information in the “token directions” portion of the response. Even setting aside the advanced and related “split tokens” idea above, we need to make sure that an AS/RS setup is built such that if the AS tells a client “only do X with your token” and the client does “Y”, then there are other protections and practices in place to prevent things from going haywire if the client does “Y” either by accident or through ignorance. 

If OAuth 2 has taught us anything, it’s that client applications are going to be the laziest participants in the security model. And that makes sense, really — security isn’t what the client apps are trying to do, they’re trying to use the RS to do something. So we need to make sure that whatever system we design will fail on the safe side as much as possible, and keep things simple for the client.

> https://wiki.idesg.org/wiki/index.php/High_Assurance_AZ_Token <https://wiki.idesg.org/wiki/index.php/High_Assurance_AZ_Token>
> https://mattrglobal.github.io/oidc-client-bound-assertions-spec/ <https://mattrglobal.github.io/oidc-client-bound-assertions-spec/>
> Peace ..tom
> 
> As one of the authors of those mentioned drafts, I am interested in discussing that, but perhaps on a seperate thread? As at least the bound assertion spec is primarily concerned with binding mechanisms for the artifacts produced from an authorization flow (specifically identity claims), whereas I think directed access tokens is just more generally talking about whether GNAP should support an AS conveying how to use an access_token it produces during a flow with a client.
> 

I think that these are separate issues as well.

 — Justin

> Thanks,
>  <https://mattr.global/>	 	
> Tobias Looker
> Mattr
> +64 (0) 27 378 0461
> [email-masked] <mailto:[email-masked]>
>  <https://mattr.global/>	 <https://www.linkedin.com/company/mattrglobal>	 <https://twitter.com/mattrglobal>	 <https://github.com/mattrglobal>
> On Wed, Jun 24, 2020 at 10:14 PM Denis <[email-masked] <mailto:[email-masked]>> wrote:
> Justin, I fear we are still far away from an agreement about what this BoF should do.
> 
> I don't agree with you when you write: "I think it’s going to be overwhelmingly common that a given RS is going to trust exactly one AS 
> that it knows about ahead of time". Such an architecture would have exactly the same limitations as OAuth 2.0. and would not be scalable.
> 
> Before we start, we should have a clear view of the whole picture rather than starting from one scenario and expanding it in many different directions.
> For building an architecture, a pre-requirement is to define ALL the trust relationships. I don't believe that we have an agreement at this time on what 
> You are also using the following wording: "methods for the AS and RS to communicate what the token’s good for". 
> A key question is : Will GNAP take care of the user's privacy or will GNAP prevent to take care of the user's privacy ?
> 
> About "the ability for the client to get several access tokens to get different resources from one request" is indeed a complex case.
> 
> No one (including ASs) is able to predict in advance which access tokens will be needed, since they depend upon the kind of operation(s) 
> the client will be willing to perform. For privacy reasons, ASs should be kept ignorant of all the operations that a client is going to perform 
> on one or more resource servers. I believe that every effort should be made to avoid the AS to be in a position to be able to trace the operations 
> To handle the complex case you envision, the full workflow of operations needs to be considered with a detailed focus on the time 
> at which the user's consent and choice happens (consent and choice is the first privacy principle from ISO 29100).
> 
> First of all, an access token could be targeted to a service rather than to a server. This would already solve many cases.
> 
> When a RS needs to call another RS (which does not support the same service) then the client should be informed by the first RS.
> His "consent and choice" should then be obtained by the first RS and, when the user agrees, the client should then ask an access token 
> to one of the ASs trusted by the second RS in order to perform the subsequent operation.  
> 
> Denis
> 
> PS.  In an email sent on June 23 you wrote: " I think an on-device AS is an important use case".  I am sorry, but I don't understand.
>>> On Jun 22, 2020, at 3:55 AM, Denis <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Hello Justin,
>>>

---

From: Tom Jones <[email-masked]>
Date: Fri, 26 Jun 2020 08:17:34 -0700

While there are multiple reasons for bound tokens, each with their own
needs, I strongly encourage an effort to create a single broad spec that
could address the common security issues. Tobias, this is the general idea
you were pushing on application level networking. As a general rule, I
believe that the current effort to base security on channel binding has
already been extended beyond its capabilities. (That is the concept that
the HTTPS key is used as the security for the messages.) So, can't we focus
on the problem of identifying the participants to an extended set of
interchanges. This would formalize the earlier statements that the as and
rs most likely have an ongoing security context on which to build
subsequent interchanges.
Peace ..tom

On Fri, Jun 26, 2020 at 6:23 AM Justin Richer <[email-masked]> wrote:

> This is something that I’d brought up as a possibility on the previous
> thread — something like a flag the client would set. This would be
> especially important if the AS wants to return multiple access tokens but
> the client requested 1, or the client requested N and the AS wants to
> return M in response. Basically any time there’s a mismatch, that’s extra
> complexity on the client that I really don’t think we want to be universal.
> A flag to turn that kind of direction and splitting on would be a potential
> start. But there are potential snags here too, and it comes down to how you
> manage the defaults...
>
> That’s the real trick, if you ask me. It has to be :safe: for a client to
> ignore this information. Which means the AS can’t rely on the client “doing
> the right thing” with the information in the “token directions” portion of
> the response. Even setting aside the advanced and related “split tokens”
> idea above, we need to make sure that an AS/RS setup is built such that if
> the AS tells a client “only do X with your token” and the client does “Y”,
> then there are other protections and practices in place to prevent things
> from going haywire if the client does “Y” either by accident or through
> ignorance.
>
> If OAuth 2 has taught us anything, it’s that client applications are going
> to be the laziest participants in the security model. And that makes sense,
> really — security isn’t what the client apps are trying to do, they’re
> trying to use the RS to do something. So we need to make sure that whatever
> system we design will fail on the safe side as much as possible, and keep
> things simple for the client.
>
>

---

From: Denis <[email-masked]>
Date: Fri, 26 Jun 2020 18:04:21 +0200

Tom and Justin,

Why do want to make things complicated when they are quite simple ?

The statement saying "the as and rs most likely have an ongoing security 
context on which to build subsequent interchanges"
would have severe limitations in terms of scalability and privacy.

The principle where a RS would only have relationships with one AS would 
make the model non scalable.
It would prevent to get attributes from two different ASs,  for example:
identity attributes from a bank and a master degree diploma from a 
university.

For privacy reasons, every AS should know as little as possible about 
the interactions between a client and multiple RSs.
It is even possible that this goes as little as knowing /nothing at all/.

The OAuth 2.0 assumption where the AS is in a position to know all the 
interactions of a given user has with all the RSs
that an AS server has a relationship with should not be re-iterated.

The relationships between RSs may change at any time and it would not be 
reasonable to inform the ASs in real time
about these interactions.

As already stated in an earlier email:

    No one (including ASs) is able to predict in advance which access
    tokens will be needed, since they depend upon the kind of operation(s)
    the client will be willing to perform. (...)

    To handle the complex case you envision, the full workflow of
    operations needs to be considered with a detailed focus on the time
    at which the user's *consent and choice* happens (/consent and
    choice/ is the first privacy principle from ISO 29100).

A RS whether the first one of a RS chain and a subsequent one, taking 
into consideration the kind of operation that will be requested by the 
client,
should be is able to inform the user about which kind of attributes are 
needed and from which AS(s) [note the plural], they may be obtained.

Denis

> needs, I strongly encourage an effort to create a single broad spec 
> that could address the common security issues. Tobias, this is the 
> general idea you were pushing on application level networking. As a 
> general rule, I believe that the current effort to base security on 
> channel binding has already been extended beyond its capabilities. 
> (That is the concept that the HTTPS key is used as the security for 
> the messages.) So, can't we focus on the problem of identifying the 
> participants to an extended set of interchanges. This would formalize 
> the earlier statements that the as and rs most likely have an 
> ongoing security context on which to build subsequent interchanges.
> Peace ..tom
>
>
> On Fri, Jun 26, 2020 at 6:23 AM Justin Richer <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     On Jun 25, 2020, at 9:07 PM, Tobias Looker
>     <[email-masked] <mailto:[email-masked]>>
>     wrote:
>>
>>     I find this feature interesting and think it could be an
>>     important pattern going forward to enable an AS to be able to
>>     describe the utility of a token to the client, however as already
>>     pointed out in the thread I think there is some potential hidden
>>     complexity that would need to be ironed out such that it does not
>>     make the simple things complicated.
>>
>>     Justin, do you see this feature as something the client has to
>>     explicitly request, i.e "please give me access and instructions
>>     on how to use my access" or rather that the AS would just return
>>     this information in conjunction with the access token if it had
>>     it available?
>>
>
>     This is something that I’d brought up as a possibility on the
>     previous thread — something like a flag the client would set. This
>     would be especially important if the AS wants to return multiple
>     access tokens but the client requested 1, or the client requested
>     N and the AS wants to return M in response. Basically any time
>     there’s a mismatch, that’s extra complexity on the client that I
>     really don’t think we want to be universal. A flag to turn that
>     kind of direction and splitting on would be a potential start. But
>     there are potential snags here too, and it comes down to how you
>     manage the defaults...
>
>>     > This is just the start, too. Things get even more complex if
>>     the client can ask for multiple different kinds of resources at
>>     once. What if the AS decides that the client needs a
>>     hyper-focused directed token for one part of the API, but can use
>>     a general token for other stuff? Can it signal that to the
>>     client? And if it can, does that mean that all clients need to be
>>     Would a potential default be that if a client did for any reason
>>     not support processing the additional information returned with
>>     the access_token, just to ignore it? I think in the spirit of
>>     keeping the simple things simple, this potentially makes sense?
>
>     That’s the real trick, if you ask me. It has to be :safe: for a
>     client to ignore this information. Which means the AS can’t rely
>     on the client “doing the right thing” with the information in the
>     “token directions” portion of the response. Even setting aside the
>     advanced and related “split tokens” idea above, we need to make
>     sure that an AS/RS setup is built such that if the AS tells a
>     client “only do X with your token” and the client does “Y”, then
>     there are other protections and practices in place to prevent
>     things from going haywire if the client does “Y” either by
>     accident or through ignorance.
>
>     If OAuth 2 has taught us anything, it’s that client applications
>     are going to be the laziest participants in the security model.
>     And that makes sense, really — security isn’t what the client apps
>     are trying to do, they’re trying to use the RS to do something. So
>     we need to make sure that whatever system we design will fail on
>     the safe side as much as possible, and keep things simple for the
>     client.
>
>>
>>     As one of the authors of those mentioned drafts, I am interested
>>     in discussing that, but perhaps on a seperate thread? As at
>>     least the bound assertion spec is primarily concerned with
>>     binding mechanisms for the artifacts produced from an
>>     authorization flow (specifically identity claims), whereas I
>>     think directed access tokens is just more generally talking about
>>     whether GNAP should support an AS conveying how to use an
>>     Mattr website <https://mattr.global/> 		
>>     *Tobias Looker*
>>     Mattr
>>     +64 (0) 27 378 0461
>>     Mattr website <https://mattr.global/> 	Mattr on LinkedIn
>>     <https://www.linkedin.com/company/mattrglobal> 	Mattr on Twitter
>>     <https://twitter.com/mattrglobal> 	Mattr on Github
>>     This communication, including any attachments, is confidential.
>>     If you are not the intended recipient, you should not read it -
>>     please contact me immediately, destroy it, and do not copy or use
>>     any part of this communication or disclose anything about it.
>>     Thank you. Please note that this communication does not designate
>>     an information system for the purposes of the Electronic
>>     Transactions Act 2002.
>>
>>
>>         I don't agree with you when you write: "I think it’s going to
>>         be overwhelmingly common that a given RS is going to trust
>>         exactly one AS
>>         that it knows about ahead of time". Such an architecture
>>         would have exactly the same limitations as OAuth 2.0. and
>>         would not be scalable.
>>
>>         Before we start, we should have a clear view of the whole
>>         picture rather than starting from one scenario and expanding
>>         it in many different directions.
>>         For building an architecture, a pre-requirement is to define
>>         ALL the trust relationships. I don't believe that we have an
>>         agreement at this time on what
>>         You are also using the following wording: "methods for the AS
>>         and RS to communicate what the token’s good for".
>>         A key question is : Will GNAP take care of the user's privacy
>>         or will GNAP *prevent *to take care of the user's privacy ?
>>
>>         About "the ability for the client to get several access
>>         tokens to get different resources from one request" is indeed
>>         a complex case.
>>
>>         No one (including ASs) is able to predict in advance which
>>         access tokens will be needed, since they depend upon the kind
>>         of operation(s)
>>         the client will be willing to perform. For privacy reasons,
>>         ASs should be kept ignorant of all the operations that a
>>         client is going to perform
>>         on one or more resource servers. I believe that every effort
>>         should be made to avoid the AS to be in a position to be able
>>         to trace the operations
>>         To handle the complex case you envision, the full workflow of
>>         operations needs to be considered with a detailed focus on
>>         the time
>>         at which the user's *consent and choice* happens (/consent
>>         and choice/ is the first privacy principle from ISO 29100).
>>
>>         First of all, an access token could be targeted to a service
>>         rather than to a server. This would already solve many cases.
>>
>>         When a RS needs to call another RS (which does not support
>>         the same service) then the client should be informed by the
>>         first RS.
>>         His "consent and choice" should then be obtained by the first
>>         RS and, when the user agrees, the client should then ask an
>>         access token
>>         PS.  In an email sent on June 23 you wrote: " I think an
>>         on-device AS is an important use case".  I am sorry, but I
>>         don't understand.
>>>         Denis, thanks for the great comments. I think that your
>>>         trust model is pretty different from what I’d laid out
>>>         initially, and while it’s an interesting and important one,
>>>         it is not what I meant by “multiple access tokens” in my
>>>         discussion below. I think that might be the cause of some
>>>         disconnect here, but that doesn’t mean it’s out of reach for
>>>         what the WG is after.
>>>
>>>         When I refer to multiple access tokens, and what the charter
>>>         calls out as multiple access tokens, is the ability for the
>>>         client to get several access tokens to get different
>>>         resources from one request. I personally see this as an
>>>         optimization of a specific set of use cases, some of which I
>>>         discussed in my original email. There are others, I’m sure,
>>>         but all the ones I’ve seen are around the client needing to
>>>         get several different kinds of access through an AS.
>>>
>>>         I think it’s going to be overwhelmingly common that a given
>>>         RS is going to trust exactly one AS that it knows about
>>>         ahead of time. But for RS’s that can trust multiple AS’s,
>>>         then we should have a model that can accommodate that as
>>>         well. That’s why the charter calls out methods for the AS
>>>         and RS to communicate what the token’s good for. I think the
>>>         basis of those methods is going to start with a common token
>>>         model, and likely incorporate into things like token formats
>>>         and introspection-style token APIs.
>>>
>>>          — Justin
>>>
>>>>>         One of the most important aspects to GNAP is going to be
>>>>>         an ability to address things that OAuth 2 can’t, or at
>>>>>         least can’t do without significant gymnastics. So with
>>>>>         that, I wanted to bring back a use case discussion that
>>>>>         originally came up while we were talking about the
>>>>>         possibility of multiple access tokens, a few months back.
>>>>>         I don’t know if this concept has a regular term, so I’m
>>>>>         going to call it “directed access tokens” until we come up
>>>>>         with something better — assuming we decide this is worthwhile.
>>>>
>>>>         I don't understand what may mean "directed access tokens”
>>>>         but I understand what means "multiple access tokens".
>>>>>         In OAuth, the client’s supposed to always know where to
>>>>>         send its access token, and that knowledge is completely
>>>>>         outside the protocol. This makes a lot of sense for many
>>>>>         (if not most) deployments, as OAuth is really there to
>>>>>         enable the API access that the client already knows about.
>>>>>
>>>>>         But we’re now in a world where a client could be talking
>>>>>         to a generic API that could be deployed at a number of
>>>>>         different places, or a cloud deployment that the AS wants
>>>>>         to be able to dispatch the client to.
>>>>
>>>>         As soon the AS is placed (again) at the centre of the
>>>>         model, the AS will have the ability to act as "Big Brother".
>>>>>         In order to do this, the AS needs to be able to
>>>>>         communicate to the client not only the token information
>>>>>         (and any related key and presentation information), but
>>>>>         also a set of/directions/ about what that specific token
>>>>>         is good for. This needs to be information outside the
>>>>>         token itself, since I believe we want to keep OAuth 2’s
>>>>>         feature of having the token be opaque to the client. Note:
>>>>>         while we could map all of these to different resource
>>>>>         requests (in XYZ parlance) or scopes (in OAuth 2 legacy
>>>>>         parlance) on the request side, this isn’t enough to tell
>>>>>         the client what to do with the token/if it doesn’t know
>>>>>         already/.
>>>>>
>>>>>         I know of two use cases already in the wild, where people
>>>>>         are addressing things using a mix of existing standards
>>>>>         and some proprietary extensions to address things within
>>>>>         their silos. I’ll try to summarize here, but I know the
>>>>>         folks I’ve been talking to about this are also on the list
>>>>>         so hopefully they can chime in with more detail or any
>>>>>         corrections for something I’ve missed.
>>>>>
>>>>>         (1) The client knows what resource it’s calling, but it
>>>>>         doesn’t know where it’s hosted. Everything is in a single
>>>>>         security domain controlled by the AS,
>>>>
>>>>         Speaking of "multiple access tokens" is in contradiction
>>>>         with single security domain "controlled" by an AS.
>>>>         A user may need to demonstrate some of his identity
>>>>         attributes granted e.g. by his bank but may also
>>>>>         but the AS needs to decide at runtime which specific
>>>>>         instance of the API to direct the client to. Since things
>>>>>         are closely tied together, the client just needs to
>>>>>         effectively known an identifier for the RS, and this is
>>>>>         currently implemented as a URI. Once the client has that
>>>>>         identifier, it knows how to dispatch that token to that
>>>>>         instance of the RS.
>>>>
>>>>         OAuth 2.0 is/was implicitly mandating a strong relationship
>>>>         between ASs and RSs which makes it non scalable.
>>>>         GNAP should be based on a simple trust relationship : a
>>>>         given RS trusts some ASs for access tokens that contains
>>>>         some types of attributes.
>>>>         An AS should not need to know in advance (or even at the
>>>>         time of an access token request) the RSs that are trusting it.
>>>>
>>>>         A client could first talk to a "global service provider"
>>>>         Once again, the client could first talk to a "global
>>>>         service provider" which has the knowledge of the different
>>>>         RSs affiliated to it.
>>>>
>>>>>         There’s a cross-domain trust that’s bridged by the AS, and
>>>>>         the AS needs to dispatch to different resources depending
>>>>>         on which user logged in (and possibly what the user
>>>>>         consented to). To make things more concrete, the client
>>>>>         needs to get driver’s license information, but doesn’t
>>>>>         know ahead of time which of the many state/provincial
>>>>>         bureaus to call to get that information because it doesn’t
>>>>>         know yet who the user is.
>>>>
>>>>         When a user has a driving license, he knows its issuer. The
>>>>         user can then provide some hint to the client.
>>>>
>>>>>         The AS will know who the user is once they log in and
>>>>>         approve things, and so it can direct the client to call
>>>>>         the correct RS. Since this is a relatively simple API with
>>>>>         a pre-negotiated cross-domain trust, the AS returns a URL
>>>>>         As far as I know, in both of these cases, the token is
>>>>>         only good for that API and not others — but more on that
>>>>>         later.
>>>>>
>>>>>         A simple thing to do is just give back a URL with the
>>>>>         access token, which tells the client where to go.
>>>>>
>>>>>         {
>>>>>         “access_token”: {
>>>>>         “value”: “87yui843yfer”,
>>>>>         This is good for some kinds of APIs, but it’s limiting
>>>>>         because not all APIs dispatch based on the URL. An AS
>>>>>         might want to divvy up access tokens to an API that’s
>>>>>         keyed on headers, or verbs, or any number of things. And
>>>>>         it doesn’t tell us immediately what to do about non-exact
>>>>>         URL matches. Can the client add query parameters and still
>>>>>         use the token? What about path segments? I like that this
>>>>>         simple approach addresses some common deployments that we
>>>>>         already see today (see above), it’s not universal. Do we
>>>>>         want or need a universal description language for
>>>>>         directing where tokens go?
>>>>>
>>>>>         This also opens up a whole new set of security questions.
>>>>>         If the AS can now direct the client where to use the
>>>>>         token, could a rogue AS convince a legit client to use a
>>>>>         stolen token at the wrong RS? And what if the client
>>>>>         ignores the directions from the AS entirely? Could this
>>>>>         open up new avenues of attack?
>>>>>
>>>>>         This is just the start, too. Things get even more complex
>>>>>         if the client can ask for multiple different kinds of
>>>>>         resources at once. What if the AS decides that the client
>>>>>         needs a hyper-focused directed token for one part of the
>>>>>         API, but can use a general token for other stuff? Can it
>>>>>         signal that to the client? And if it can, does that mean
>>>>>         that all clients need to be prepared for that kind of thing?
>>>>>
>>>>>         I firmly believe that whatever we build in GNAP, we need
>>>>>         to optimize for the overwhelmingly common use case of a
>>>>>         client getting a single access token to call APIs that it
>>>>>         already knows about. Anything we add on top of that really
>>>>>         can’t get in the way of this, because if it does, there’s
>>>>>         very small chance that people will try to use this for
>>>>>         everyday things. Keep the simple things simple, and the
>>>>>         complex things possible, after all.
>>>>>
>>>>>         I’m really looking forward to hearing what the community
>>>>>         thinks about these use cases, and hopefully the people
>>>>>         I’ve chatted with offline about this can join the
>>>>>         conversation and provide more light than I was able to.
>>>>
>>>>             (2) The client knows what kind of thing it’s looking
>>>>             for, but doesn’t know who to ask it from.
>>>>
>>>>         That does not mean in any way that these two use cases
>>>>         should be solved by placing the AS at the centre of the
>>>>         solution.
>>>>
>>>>         Denis
>>>>
>>>>>
>>>>>          — Justin
>>>>>
>>>>
>>>>         --
>>>>         Txauth mailing list

---

From: Tom Jones <[email-masked]>
Date: Fri, 26 Jun 2020 09:44:05 -0700

You cannot assume that the rs is in communication with the user/resource
owner during the other interchanges. That would not be the case in my
implementation.

thx ..Tom (mobile)

On Fri, Jun 26, 2020, 9:04 AM Denis <[email-masked]> wrote:

> For privacy reasons, every AS should know as little as possible about the
> interactions between a client and multiple RSs.
> It is even possible that this goes as little as knowing *nothing at all*.
>
> A RS whether the first one of a RS chain and a subsequent one, taking into
> consideration the kind of operation that will be requested by the client,
>> important pattern going forward to enable an AS to be able to describe the
>> utility of a token to the client, however as already pointed out in the
>> thread I think there is some potential hidden complexity that would need to
>> be ironed out such that it does not make the simple things complicated.
>>
>> If OAuth 2 has taught us anything, it’s that client applications are
>> going to be the laziest participants in the security model. And that makes
>> sense, really — security isn’t what the client apps are trying to do,
>> they’re trying to use the RS to do something. So we need to make sure that
>> whatever system we design will fail on the safe side as much as possible,
>> and keep things simple for the client.
>>
>>
>> This communication, including any attachments, is confidential. If you
>> are not the intended recipient, you should not read it - please contact me
>>> as multiple access tokens, is the ability for the client to get several
>>> access tokens to get different resources from one request. I personally see
>>> this as an optimization of a specific set of use cases, some of which I
>>> client not only the token information (and any related key and presentation
>>> and so it can direct the client to call the correct RS. Since this is a

---

From: Denis <[email-masked]>
Date: Fri, 26 Jun 2020 18:51:41 +0200

Tom,

Should I understand that you are willing to rubber-stamp an existing 
implementation ?

Since we are not yet a WG, it is not my understanding that it is what a 
WG should attempt to do.

Denis

> You cannot assume that the rs is in communication with the 
> user/resource owner during the other interchanges. That would not be 
> the case in my implementation.
>
> thx ..Tom (mobile)
>
> On Fri, Jun 26, 2020, 9:04 AM Denis <[email-masked] 
>     The statement saying "the as and rs most likely have an
>     ongoing security context on which to build subsequent interchanges"
>     The principle where a RS would only have relationships with one AS
>     would make the model non scalable.
>     For privacy reasons, every AS should know as little as possible
>     about the interactions between a client and multiple RSs.
>     The OAuth 2.0 assumption where the AS is in a position to know all
>     the interactions of a given user has with all the RSs
>     The relationships between RSs may change at any time and it woauld
>     not be reasonable to inform the ASs in real time
>     A RS whether the first one of a RS chain and a subsequent one,
>     taking into consideration the kind of operation that will be
>     requested by the client,
>     should be is able to inform the user about which kind of
>     attributes are needed and from which AS(s) [note the plural], they
>     may be obtained.
>
>     Denis
>
>
>>     While there are multiple reasons for bound tokens, each with
>>     their own needs, I strongly encourage an effort to create a
>>     single broad spec that could address the common security issues.
>>     Tobias, this is the general idea you were pushing on application
>>     level networking. As a general rule, I believe that the current
>>     effort to base security on channel binding has already been
>>     extended beyond its capabilities. (That is the concept that the
>>     HTTPS key is used as the security for the messages.) So, can't we
>>     focus on the problem of identifying the participants to an
>>     extended set of interchanges. This would formalize the earlier
>>     statements that the as and rs most likely have an
>>         <[email-masked]
>>         <mailto:[email-masked]>> wrote:
>>>
>>>         important pattern going forward to enable an AS to be able
>>>         to describe the utility of a token to the client, however as
>>>         already pointed out in the thread I think there is some
>>>         potential hidden complexity that would need to be ironed out
>>>         such that it does not make the simple things complicated.
>>>
>>>         Justin, do you see this feature as something the client has
>>>         to explicitly request, i.e "please give me access and
>>>         instructions on how to use my access" or rather that the AS
>>>         would just return this information in conjunction with the
>>>         access token if it had it available?
>>>
>>
>>         previous thread — something like a flag the client would set.
>>         This would be especially important if the AS wants to return
>>         multiple access tokens but the client requested 1, or the
>>         client requested N and the AS wants to return M in response.
>>         Basically any time there’s a mismatch, that’s extra
>>         complexity on the client that I really don’t think we want to
>>         be universal. A flag to turn that kind of direction and
>>         splitting on would be a potential start. But there are
>>         potential snags here too, and it comes down to how you manage
>>         the defaults...
>>
>>>         Would a potential default be that if a client did for any
>>>         reason not support processing the additional information
>>>         returned with the access_token, just to ignore it? I think
>>>         in the spirit of keeping the simple things simple, this
>>>         potentially makes sense?
>>
>>         That’s the real trick, if you ask me. It has to be :safe: for
>>         a client to ignore this information. Which means the AS can’t
>>         rely on the client “doing the right thing” with the
>>         information in the “token directions” portion of the
>>         response. Even setting aside the advanced and related “split
>>         tokens” idea above, we need to make sure that an AS/RS setup
>>         is built such that if the AS tells a client “only do X with
>>         your token” and the client does “Y”, then there are other
>>         protections and practices in place to prevent things from
>>         going haywire if the client does “Y” either by accident or
>>         through ignorance.
>>
>>         If OAuth 2 has taught us anything, it’s that client
>>         applications are going to be the laziest participants in the
>>         security model. And that makes sense, really — security isn’t
>>         what the client apps are trying to do, they’re trying to use
>>         the RS to do something. So we need to make sure that whatever
>>         system we design will fail on the safe side as much as
>>         possible, and keep things simple for the client.
>>
>>>
>>>         As one of the authors of those mentioned drafts, I am
>>>         interested in discussing that, but perhaps on a seperate
>>>         thread? As at least the bound assertion spec
>>>         is primarily concerned with binding mechanisms for the
>>>         artifacts produced from an authorization flow (specifically
>>>         identity claims), whereas I think directed access tokens is
>>>         just more generally talking about whether GNAP should
>>>         support an AS conveying how to use an access_token it
>>>         produces during a flow with a client.
>>>
>>
>>>         <https://www.linkedin.com/company/mattrglobal> 	Mattr on
>>>         Twitter <https://twitter.com/mattrglobal> 	Mattr on Github
>>>         This communication, including any attachments, is
>>>         confidential. If you are not the intended recipient, you
>>>         should not read it - please contact me immediately, destroy
>>>         it, and do not copy or use any part of this communication or
>>>         disclose anything about it. Thank you. Please note that this
>>>         communication does not designate an information system for
>>>         the purposes of the Electronic Transactions Act 2002.
>>>
>>>
>>>             I don't agree with you when you write: "I think it’s
>>>             going to be overwhelmingly common that a given RS is
>>>             going to trust exactly one AS
>>>             would have exactly the same limitations as OAuth 2.0.
>>>             and would not be scalable.
>>>
>>>             Before we start, we should have a clear view of the
>>>             whole picture rather than starting from one scenario and
>>>             expanding it in many different directions.
>>>             For building an architecture, a pre-requirement is to
>>>             define ALL the trust relationships. I don't believe that
>>>             we have an agreement at this time on what
>>>             You are also using the following wording: "methods for
>>>             the AS and RS to communicate what the token’s good for".
>>>             A key question is : Will GNAP take care of the user's
>>>             privacy or will GNAP *prevent *to take care of the
>>>             user's privacy ?
>>>
>>>             tokens to get different resources from one request" is
>>>             indeed a complex case.
>>>
>>>             No one (including ASs) is able to predict in advance
>>>             which access tokens will be needed, since they depend
>>>             upon the kind of operation(s)
>>>             the client will be willing to perform. For privacy
>>>             reasons, ASs should be kept ignorant of all the
>>>             operations that a client is going to perform
>>>             on one or more resource servers. I believe that every
>>>             effort should be made to avoid the AS to be in a
>>>             position to be able to trace the operations
>>>             To handle the complex case you envision, the full
>>>             workflow of operations needs to be considered with a
>>>             detailed focus on the time
>>>             at which the user's *consent and choice* happens
>>>             (/consent and choice/ is the first privacy principle
>>>             from ISO 29100).
>>>
>>>             First of all, an access token could be targeted to a
>>>             service rather than to a server. This would already
>>>             solve many cases.
>>>
>>>             When a RS needs to call another RS (which does not
>>>             support the same service) then the client should be
>>>             informed by the first RS.
>>>             His "consent and choice" should then be obtained by the
>>>             first RS and, when the user agrees, the client should
>>>             then ask an access token
>>>             on-device AS is an important use case".  I am sorry, but
>>>             I don't understand.
>>>>             initially, and while it’s an interesting and important
>>>>             one, it is not what I meant by “multiple access tokens”
>>>>             in my discussion below. I think that might be the cause
>>>>             of some disconnect here, but that doesn’t mean it’s out
>>>>             of reach for what the WG is after.
>>>>
>>>>             When I refer to multiple access tokens, and what the
>>>>             charter calls out as multiple access tokens, is the
>>>>             ability for the client to get several access tokens to
>>>>             get different resources from one request. I personally
>>>>             see this as an optimization of a specific set of use
>>>>             cases, some of which I discussed in my original email.
>>>>             There are others, I’m sure, but all the ones I’ve seen
>>>>             are around the client needing to get several different
>>>>             kinds of access through an AS.
>>>>
>>>>             I think it’s going to be overwhelmingly common that a
>>>>             given RS is going to trust exactly one AS that it knows
>>>>             about ahead of time. But for RS’s that can trust
>>>>             multiple AS’s, then we should have a model that can
>>>>             accommodate that as well. That’s why the charter calls
>>>>             out methods for the AS and RS to communicate what the
>>>>             token’s good for. I think the basis of those methods is
>>>>             going to start with a common token model, and likely
>>>>             incorporate into things like token formats and
>>>>>>             One of the most important aspects to GNAP is going to
>>>>>>             be an ability to address things that OAuth 2 can’t,
>>>>>>             or at least can’t do without significant gymnastics.
>>>>>>             So with that, I wanted to bring back a use case
>>>>>>             discussion that originally came up while we were
>>>>>>             talking about the possibility of multiple access
>>>>>>             tokens, a few months back. I don’t know if this
>>>>>>             concept has a regular term, so I’m going to call it
>>>>>>             “directed access tokens” until we come up with
>>>>>>             something better — assuming we decide this is worthwhile.
>>>>>
>>>>>             I don't understand what may mean "directed access
>>>>>             tokens” but I understand what means "multiple access
>>>>>             tokens".
>>>>>             When speaking of "multiple access tokens", these
>>>>>             access tokens may come from one or more ASs.
>>>>>
>>>>>>             In OAuth, the client’s supposed to always know where
>>>>>>             to send its access token, and that knowledge is
>>>>>>             completely outside the protocol. This makes a lot of
>>>>>>             sense for many (if not most) deployments, as OAuth is
>>>>>>             really there to enable the API access that the client
>>>>>>             already knows about.
>>>>>>
>>>>>>             But we’re now in a world where a client could be
>>>>>>             talking to a generic API that could be deployed at a
>>>>>>             number of different places, or a cloud deployment
>>>>>>             that the AS wants to be able to dispatch the client to.
>>>>>
>>>>>>             communicate to the client not only the token
>>>>>>             information (and any related key and presentation
>>>>>>             information), but also a set of/directions/ about
>>>>>>             what that specific token is good for. This needs to
>>>>>>             be information outside the token itself, since
>>>>>>             I believe we want to keep OAuth 2’s feature of having
>>>>>>             the token be opaque to the client. Note: while we
>>>>>>             could map all of these to different resource requests
>>>>>>             (in XYZ parlance) or scopes (in OAuth 2 legacy
>>>>>>             parlance) on the request side, this isn’t enough to
>>>>>>             tell the client what to do with the token/if it
>>>>>>             doesn’t know already/.
>>>>>>
>>>>>>             I know of two use cases already in the wild, where
>>>>>>             people are addressing things using a mix of existing
>>>>>>             standards and some proprietary extensions to address
>>>>>>             things within their silos. I’ll try to summarize
>>>>>>             here, but I know the folks I’ve been talking to about
>>>>>>             this are also on the list so hopefully they can chime
>>>>>>             in with more detail or any corrections for something
>>>>>>             I’ve missed.
>>>>>>
>>>>>>             (1) The client knows what resource it’s calling, but
>>>>>>             it doesn’t know where it’s hosted. Everything is in a
>>>>>>             single security domain controlled by the AS,
>>>>>
>>>>>             Speaking of "multiple access tokens" is in
>>>>>             contradiction with single security domain "controlled"
>>>>>             by an AS.
>>>>>             need to demonstrate one or more diplomas granted by
>>>>>             one or more universities. The bank cannot be
>>>>>             the "primary issuer" of a university diploma. It
>>>>>             should not be either a "secondary issuer", because
>>>>>>             instance of the API to direct the client to. Since
>>>>>>             things are closely tied together, the client just
>>>>>>             needs to effectively known an identifier for the RS,
>>>>>>             and this is currently implemented as a URI. Once the
>>>>>>             client has that identifier, it knows how to dispatch
>>>>>>             that token to that instance of the RS.
>>>>>
>>>>>             OAuth 2.0 is/was implicitly mandating a strong
>>>>>             relationship between ASs and RSs which makes it non
>>>>>             scalable.
>>>>>             GNAP should be based on a simple trust relationship :
>>>>>             a given RS trusts some ASs for access tokens that
>>>>>             contains some types of attributes.
>>>>>             An AS should not need to know in advance (or even at
>>>>>             the time of an access token request) the RSs that are
>>>>>             trusting it.
>>>>>
>>>>>             A client could first talk to a "global service
>>>>>             service provider" which has the knowledge of the
>>>>>             different RSs affiliated to it.
>>>>>
>>>>>>             There’s a cross-domain trust that’s bridged by the
>>>>>>             AS, and the AS needs to dispatch to different
>>>>>>             resources depending on which user logged in (and
>>>>>>             possibly what the user consented to). To make things
>>>>>>             more concrete, the client needs to get driver’s
>>>>>>             license information, but doesn’t know ahead of time
>>>>>>             which of the many state/provincial bureaus to call to
>>>>>>             get that information because it doesn’t know yet who
>>>>>>             the user is.
>>>>>
>>>>>             When a user has a driving license, he knows its
>>>>>             issuer. The user can then provide some hint to the client.
>>>>>
>>>>>>             approve things, and so it can direct the client to
>>>>>>             call the correct RS. Since this is a relatively
>>>>>>             simple API with a pre-negotiated cross-domain trust,
>>>>>>             the AS returns a URL that the client presents the
>>>>>>             token at.
>>>>>
>>>>>>             As far as I know, in both of these cases, the token
>>>>>>             is only good for that API and not others — but more
>>>>>>             on that later.
>>>>>>
>>>>>>             This is good for some kinds of APIs, but it’s
>>>>>>             limiting because not all APIs dispatch based on the
>>>>>>             URL. An AS might want to divvy up access tokens to an
>>>>>>             API that’s keyed on headers, or verbs, or any number
>>>>>>             of things. And it doesn’t tell us immediately what to
>>>>>>             do about non-exact URL matches. Can the client add
>>>>>>             query parameters and still use the token? What about
>>>>>>             path segments? I like that this simple approach
>>>>>>             addresses some common deployments that we already see
>>>>>>             today (see above), it’s not universal. Do we want or
>>>>>>             need a universal description language for directing
>>>>>>             where tokens go?
>>>>>>
>>>>>>             This also opens up a whole new set of security
>>>>>>             questions. If the AS can now direct the client where
>>>>>>             to use the token, could a rogue AS convince a legit
>>>>>>             client to use a stolen token at the wrong RS? And
>>>>>>             what if the client ignores the directions from the AS
>>>>>>             entirely? Could this open up new avenues of attack?
>>>>>>
>>>>>>             This is just the start, too. Things get even more
>>>>>>             complex if the client can ask for multiple different
>>>>>>             kinds of resources at once. What if the AS decides
>>>>>>             that the client needs a hyper-focused directed token
>>>>>>             for one part of the API, but can use a general token
>>>>>>             for other stuff? Can it signal that to the client?
>>>>>>             And if it can, does that mean that all clients need
>>>>>>             to be prepared for that kind of thing?
>>>>>>
>>>>>>             I firmly believe that whatever we build in GNAP, we
>>>>>>             need to optimize for the overwhelmingly common use
>>>>>>             case of a client getting a single access token to
>>>>>>             call APIs that it already knows about. Anything we
>>>>>>             add on top of that really can’t get in the way of
>>>>>>             this, because if it does, there’s very small chance
>>>>>>             that people will try to use this for everyday things.
>>>>>>             Keep the simple things simple, and the complex things
>>>>>>             possible, after all.
>>>>>>
>>>>>>             I’m really looking forward to hearing what the
>>>>>>             community thinks about these use cases, and hopefully
>>>>>>             the people I’ve chatted with offline about this can
>>>>>>             join the conversation and provide more light than I
>>>>>>             was able to.
>>>>>
>>>>>                 (2) The client knows what kind of thing it’s
>>>>>                 looking for, but doesn’t know who to ask it from.
>>>>>
>>>>>             should be solved by placing the AS at the centre of
>>>>>             the solution.
>>>>>
>>>>>             Denis
>>>>>
>>>>>>
>>>>>>              — Justin
>>>>>>
>>>>>
>>>>>             --
>>>>>             Txauth mailing list

---

From: Tom Jones <[email-masked]>
Date: Fri, 26 Jun 2020 09:54:28 -0700

no you should not assume that. But if your standard demands communications
between the ro & rs for every release of data, then i could not use the
standard.
Peace ..tom

On Fri, Jun 26, 2020 at 9:51 AM Denis <[email-masked]> wrote:

> Since we are not yet a WG, it is not my understanding that it is what a WG
> should attempt to do.
>
> Denis
>
>> The relationships between RSs may change at any time and it woauld not be
>>> explicitly request, i.e "please give me access and instructions on how to
>>> use my access" or rather that the AS would just return this information in
>>> client can ask for multiple different kinds of resources at once. What if
>>> the AS decides that the client needs a hyper-focused directed token for one
>>> part of the API, but can use a general token for other stuff? Can it signal
>>> that to the client? And if it can, does that mean that all clients need to
>>> be prepared for that kind of thing?
>>>
>>> That’s the real trick, if you ask me. It has to be :safe: for a client
>>> to ignore this information. Which means the AS can’t rely on the client
>>> “doing the right thing” with the information in the “token directions”
>>> portion of the response. Even setting aside the advanced and related “split
>>> tokens” idea above, we need to make sure that an AS/RS setup is built such
>>> that if the AS tells a client “only do X with your token” and the client
>>> does “Y”, then there are other protections and practices in place to
>>> prevent things from going haywire if the client does “Y” either by accident
>>> or through ignorance.
>>>
>>>  <https://mattr.global/> [image: Mattr on
>>> LinkedIn] <https://www.linkedin.com/company/mattrglobal> [image: Mattr
>>> on Twitter] <https://twitter.com/mattrglobal> 
>>>> Before we start, we should have a clear view of the whole picture
>>>> rather than starting from one scenario and expanding it in many different
>>>> directions.
>>>> First of all, an access token could be targeted to a service rather
>>>> than to a server. This would already solve many cases.
>>>>
>>>> PS.  In an email sent on June 23 you wrote: " I think an on-device AS
>>>> is an important use case".  I am sorry, but I don't understand.
>>>> addressing things using a mix of existing standards and some proprietary
>>>> extensions to address things within their silos. I’ll try to summarize
>>>> here, but I know the folks I’ve been talking to about this are also on the
>>>> list so hopefully they can chime in with more detail or any corrections for
>>>> something I’ve missed.
>>>>
>>>> for the overwhelmingly common use case of a client getting a single access

---

From: Denis <[email-masked]>
Date: Fri, 26 Jun 2020 19:18:27 +0200

Hi Tom,

In the model I have in mind, the ro may directly communicate with the rs 
(or open a session with the rs) to tell what the rules are,
i.e. which attributes are needed for some kinds of operations and from 
which as(s) these attributes may be obtained.

The ro is not involved in anyway at the time a client attempts to 
perform an operation.

Denis

> no you should not assume that. But if your standard demands 
> communications between the ro & rs for every release of data, then i 
> could not use the standard.
> Peace ..tom
>
>
> On Fri, Jun 26, 2020 at 9:51 AM Denis <[email-masked] 
>     Should I understand that you are willing to rubber-stamp an
>     existing implementation ?
>
>     Since we are not yet a WG, it is not my understanding that it is
>     what a WG should attempt to do.
>
>     Denis
>
>>     user/resource owner during the other interchanges. That would not
>>     be the case in my implementation.
>>
>>     thx ..Tom (mobile)
>>
>>         The principle where a RS would only have relationships with
>>         one AS would make the model non scalable.
>>         identity attributes from a bank and a master degree diploma
>>         from a university.
>>
>>         For privacy reasons, every AS should know as little as
>>         possible about the interactions between a client and multiple
>>         RSs.
>>         The OAuth 2.0 assumption where the AS is in a position to
>>         know all the interactions of a given user has with all the RSs
>>         The relationships between RSs may change at any time and it
>>         woauld not be reasonable to inform the ASs in real time
>>             (/consent and choice/ is the first privacy principle from
>>             ISO 29100).
>>
>>         A RS whether the first one of a RS chain and a subsequent
>>         one, taking into consideration the kind of operation that
>>         will be requested by the client,
>>         attributes are needed and from which AS(s) [note the plural],
>>         they may be obtained.
>>
>>         Denis
>>
>>
>>>         single broad spec that could address the common security
>>>         issues. Tobias, this is the general idea you were pushing on
>>>         application level networking. As a general rule, I
>>>         believe that the current effort to base security on channel
>>>         binding has already been extended beyond its capabilities.
>>>         (That is the concept that the HTTPS key is used as the
>>>         security for the messages.) So, can't we focus on the
>>>         problem of identifying the participants to an extended set
>>>         of interchanges. This would formalize the earlier statements
>>>         that the as and rs most likely have an ongoing security
>>>         context on which to build subsequent interchanges.
>>>         Peace ..tom
>>>
>>>
>>>         On Fri, Jun 26, 2020 at 6:23 AM Justin Richer
>>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>>             I find this feature interesting and think it could be
>>>>             an important pattern going forward to enable an AS to
>>>>             be able to describe the utility of a token to the
>>>>             client, however as already pointed out in the thread I
>>>>             think there is some potential hidden complexity that
>>>>             would need to be ironed out such that it does not make
>>>>             the simple things complicated.
>>>>
>>>>             Justin, do you see this feature as something the client
>>>>             has to explicitly request, i.e "please give me access
>>>>             and instructions on how to use my access" or rather
>>>>             that the AS would just return this information in
>>>             This is something that I’d brought up as a possibility
>>>             on the previous thread — something like a flag the
>>>             client would set. This would be especially important if
>>>             the AS wants to return multiple access tokens but the
>>>             client requested 1, or the client requested N and the AS
>>>             wants to return M in response. Basically any time
>>>             there’s a mismatch, that’s extra complexity on the
>>>             client that I really don’t think we want to be
>>>             universal. A flag to turn that kind of direction and
>>>             potential snags here too, and it comes down to how you
>>>             manage the defaults...
>>>
>>>>             kinds of resources at once. What if the AS decides that
>>>>             the client needs a hyper-focused directed token for one
>>>>             part of the API, but can use a general token for other
>>>>             stuff? Can it signal that to the client? And if it can,
>>>>             does that mean that all clients need to be prepared for
>>>>             that kind of thing?
>>>>
>>>>             Would a potential default be that if a client did for
>>>>             any reason not support processing the additional
>>>>             information returned with the access_token, just to
>>>>             ignore it? I think in the spirit of keeping the simple
>>>>             things simple, this potentially makes sense?
>>>
>>>             That’s the real trick, if you ask me. It has to be
>>>             :safe: for a client to ignore this information. Which
>>>             means the AS can’t rely on the client “doing the right
>>>             thing” with the information in the “token directions”
>>>             portion of the response. Even setting aside the advanced
>>>             and related “split tokens” idea above, we need to make
>>>             sure that an AS/RS setup is built such that if the AS
>>>             tells a client “only do X with your token” and the
>>>             client does “Y”, then there are other protections and
>>>             practices in place to prevent things from going haywire
>>>             if the client does “Y” either by accident or through
>>>             ignorance.
>>>
>>>             applications are going to be the laziest participants in
>>>             the security model. And that makes sense, really —
>>>             security isn’t what the client apps are trying to do,
>>>             they’re trying to use the RS to do something. So we need
>>>             to make sure that whatever system we design will fail on
>>>             the safe side as much as possible, and keep things
>>>             simple for the client.
>>>
>>>>
>>>>             interested in discussing that, but perhaps on a
>>>>             seperate thread? As at least the bound assertion spec
>>>>             artifacts produced from an authorization flow
>>>>             (specifically identity claims), whereas I think
>>>>             directed access tokens is just more generally talking
>>>>             about whether GNAP should support an AS conveying how
>>>>             to use an access_token it produces during a flow with a
>>>>             client.
>>>>
>>>
>>>>             <mailto:[email-masked]>
>>>>             Mattr website <https://mattr.global/> 	Mattr on
>>>>             LinkedIn <https://www.linkedin.com/company/mattrglobal>
>>>>             	Mattr on Twitter <https://twitter.com/mattrglobal>
>>>>             Mattr on Github <https://github.com/mattrglobal>
>>>>
>>>>
>>>>             confidential. If you are not the intended recipient,
>>>>             you should not read it - please contact me immediately,
>>>>             destroy it, and do not copy or use any part of this
>>>>             communication or disclose anything about it. Thank you.
>>>>             Please note that this communication does not designate
>>>>             an information system for the purposes of the
>>>>             Electronic Transactions Act 2002.
>>>>
>>>>
>>>>             On Wed, Jun 24, 2020 at 10:14 PM Denis
>>>>             <[email-masked] <mailto:[email-masked]>> wrote:
>>>>
>>>>                 I don't agree with you when you write: "I think
>>>>                 it’s going to be overwhelmingly common that a given
>>>>                 RS is going to trust exactly one AS
>>>>                 that it knows about ahead of time". Such an
>>>>                 architecture would have exactly the same
>>>>                 limitations as OAuth 2.0. and would not be scalable.
>>>>
>>>>                 whole picture rather than starting from one
>>>>                 scenario and expanding it in many different directions.
>>>>                 For building an architecture, a pre-requirement is
>>>>                 to define ALL the trust relationships. I don't
>>>>                 believe that we have an agreement at this time on what
>>>>                 You are also using the following wording: "methods
>>>>                 for the AS and RS to communicate what the token’s
>>>>                 good for".
>>>>                 A key question is : Will GNAP take care of the
>>>>                 user's privacy or will GNAP *prevent *to take care
>>>>                 of the user's privacy ?
>>>>
>>>>                 About "the ability for the client to get several
>>>>                 access tokens to get different resources from one
>>>>                 request" is indeed a complex case.
>>>>
>>>>                 No one (including ASs) is able to predict in
>>>>                 advance which access tokens will be needed, since
>>>>                 they depend upon the kind of operation(s)
>>>>                 on one or more resource servers. I believe that
>>>>                 every effort should be made to avoid the AS to be
>>>>                 in a position to be able to trace the operations
>>>>                 workflow of operations needs to be considered with
>>>>                 a detailed focus on the time
>>>>                 (/consent and choice/ is the first privacy
>>>>                 principle from ISO 29100).
>>>>
>>>>                 First of all, an access token could be targeted to
>>>>                 a service rather than to a server. This would
>>>>                 already solve many cases.
>>>>
>>>>                 His "consent and choice" should then be obtained by
>>>>                 the first RS and, when the user agrees, the client
>>>>                 should then ask an access token
>>>>                 PS.  In an email sent on June 23 you wrote: " I
>>>>                 think an on-device AS is an important use case".  I
>>>>                 am sorry, but I don't understand.
>>>>>                 Denis, thanks for the great comments. I think that
>>>>>                 your trust model is pretty different from what I’d
>>>>>                 laid out initially, and while it’s an interesting
>>>>>                 and important one, it is not what I meant by
>>>>>                 “multiple access tokens” in my discussion below. I
>>>>>                 think that might be the cause of some disconnect
>>>>>                 here, but that doesn’t mean it’s out of reach for
>>>>>                 what the WG is after.
>>>>>
>>>>>                 When I refer to multiple access tokens, and what
>>>>>                 the charter calls out as multiple access tokens,
>>>>>                 is the ability for the client to get several
>>>>>                 access tokens to get different resources from one
>>>>>                 request. I personally see this as an optimization
>>>>>                 of a specific set of use cases, some of which I
>>>>>                 discussed in my original email. There are others,
>>>>>                 I’m sure, but all the ones I’ve seen are around
>>>>>                 the client needing to get several different kinds
>>>>>                 of access through an AS.
>>>>>
>>>>>                 I think it’s going to be overwhelmingly common
>>>>>                 that a given RS is going to trust exactly one AS
>>>>>                 that it knows about ahead of time. But for RS’s
>>>>>                 that can trust multiple AS’s, then we should have
>>>>>                 a model that can accommodate that as well. That’s
>>>>>                 why the charter calls out methods for the AS and
>>>>>                 RS to communicate what the token’s good for. I
>>>>>                 think the basis of those methods is going to start
>>>>>                 with a common token model, and likely incorporate
>>>>>                 into things like token formats and
>>>>>>                 On Jun 22, 2020, at 3:55 AM, Denis
>>>>>>                 <[email-masked] <mailto:[email-masked]>>
>>>>>>                 wrote:
>>>>>>
>>>>>>                 Hello Justin,
>>>>>>
>>>>>>>                 One of the most important aspects to GNAP is
>>>>>>>                 going to be an ability to address things that
>>>>>>>                 OAuth 2 can’t, or at least can’t do without
>>>>>>>                 significant gymnastics. So with that, I wanted
>>>>>>>                 to bring back a use case discussion that
>>>>>>>                 originally came up while we were talking about
>>>>>>>                 the possibility of multiple access tokens, a few
>>>>>>>                 months back. I don’t know if this concept has a
>>>>>>>                 regular term, so I’m going to call it “directed
>>>>>>>                 access tokens” until we come up with something
>>>>>>>                 better — assuming we decide this is worthwhile.
>>>>>>
>>>>>>                 tokens” but I understand what means "multiple
>>>>>>                 access tokens".
>>>>>>>                 In OAuth, the client’s supposed to always know
>>>>>>>                 where to send its access token, and that
>>>>>>>                 knowledge is completely outside the protocol.
>>>>>>>                 This makes a lot of sense for many (if not most)
>>>>>>>                 deployments, as OAuth is really there to enable
>>>>>>>                 the API access that the client already knows about.
>>>>>>>
>>>>>>>                 talking to a generic API that could be deployed
>>>>>>>                 at a number of different places, or a cloud
>>>>>>                 As soon the AS is placed (again) at the centre of
>>>>>>                 the model, the AS will have the ability to act as
>>>>>>                 "Big Brother".
>>>>>>                 OAuth 2.0 has not taken care of privacy issues.
>>>>>>                 On the contrary, GNAP should take care of them.
>>>>>>
>>>>>>>                 information (and any related key and
>>>>>>>                 presentation information), but also a set
>>>>>>>                 of/directions/ about what that specific token is
>>>>>>>                 good for. This needs to be information outside
>>>>>>>                 the token itself, since I believe we want to
>>>>>>>                 keep OAuth 2’s feature of having the token be
>>>>>>>                 opaque to the client. Note: while we could map
>>>>>>>                 all of these to different resource requests (in
>>>>>>>                 XYZ parlance) or scopes (in OAuth 2 legacy
>>>>>>>                 parlance) on the request side, this isn’t enough
>>>>>>>                 to tell the client what to do with the token/if
>>>>>>>                 it doesn’t know already/.
>>>>>>>
>>>>>>>                 I know of two use cases already in the wild,
>>>>>>>                 where people are addressing things using a mix
>>>>>>>                 of existing standards and some proprietary
>>>>>>>                 extensions to address things within their silos.
>>>>>>>                 I’ll try to summarize here, but I know the folks
>>>>>>>                 I’ve been talking to about this are also on the
>>>>>>>                 list so hopefully they can chime in with more
>>>>>>>                 Everything is in a single security domain
>>>>>>>                 controlled by the AS,
>>>>>>
>>>>>>                 contradiction with single security domain
>>>>>>                 "controlled" by an AS.
>>>>>>                 A user may need to demonstrate some of his
>>>>>>                 identity attributes granted e.g. by his bank but
>>>>>>                 may also
>>>>>>                 need to demonstrate one or more diplomas granted
>>>>>>                 by one or more universities. The bank cannot be
>>>>>>>                 but the AS needs to decide at runtime which
>>>>>>>                 specific instance of the API to direct the
>>>>>>>                 client to. Since things are closely tied
>>>>>>>                 together, the client just needs to effectively
>>>>>>>                 known an identifier for the RS, and this is
>>>>>>>                 currently implemented as a URI. Once the client
>>>>>>>                 has that identifier, it knows how to dispatch
>>>>>>                 relationship between ASs and RSs which makes it
>>>>>>                 non scalable.
>>>>>>                 GNAP should be based on a simple trust
>>>>>>                 relationship : a given RS trusts some ASs for
>>>>>>                 access tokens that contains some types of attributes.
>>>>>>                 An AS should not need to know in advance (or even
>>>>>>                 at the time of an access token request) the RSs
>>>>>>                 that are trusting it.
>>>>>>
>>>>>>                 Once again, the client could first talk to a
>>>>>>                 "global service provider" which has the knowledge
>>>>>>                 of the different RSs affiliated to it.
>>>>>>
>>>>>>>                 There’s a cross-domain trust that’s bridged by
>>>>>>>                 the AS, and the AS needs to dispatch to
>>>>>>>                 different resources depending on which user
>>>>>>>                 logged in (and possibly what the user consented
>>>>>>>                 to). To make things more concrete, the client
>>>>>>>                 needs to get driver’s license information, but
>>>>>>>                 doesn’t know ahead of time which of the many
>>>>>>>                 state/provincial bureaus to call to get that
>>>>>>>                 The AS will know who the user is once they log
>>>>>>>                 in and approve things, and so it can direct the
>>>>>>>                 client to call the correct RS. Since this is a
>>>>>>>                 relatively simple API with a pre-negotiated
>>>>>>>                 cross-domain trust, the AS returns a URL that
>>>>>>>                 the client presents the token at.
>>>>>>
>>>>>>>                 As far as I know, in both of these cases, the
>>>>>>>                 token is only good for that API and not others —
>>>>>>>                 but more on that later.
>>>>>>>
>>>>>>>                 A simple thing to do is just give back a URL
>>>>>>>                 with the access token, which tells the client
>>>>>>>                 where to go.
>>>>>>>
>>>>>>>                 {
>>>>>>>                 “access_token”: {
>>>>>>>                 “value”: “87yui843yfer”,
>>>>>>>                 limiting because not all APIs dispatch based on
>>>>>>>                 the URL. An AS might want to divvy up access
>>>>>>>                 tokens to an API that’s keyed on headers, or
>>>>>>>                 verbs, or any number of things. And it doesn’t
>>>>>>>                 tell us immediately what to do about non-exact
>>>>>>>                 URL matches. Can the client add query parameters
>>>>>>>                 and still use the token? What about path
>>>>>>>                 segments? I like that this simple approach
>>>>>>>                 addresses some common deployments that we
>>>>>>>                 already see today (see above), it’s not
>>>>>>>                 universal. Do we want or need a universal
>>>>>>>                 description language for directing where tokens go?
>>>>>>>
>>>>>>>                 questions. If the AS can now direct the client
>>>>>>>                 where to use the token, could a rogue AS
>>>>>>>                 convince a legit client to use a stolen token at
>>>>>>>                 the wrong RS? And what if the client ignores the
>>>>>>>                 directions from the AS entirely? Could this open
>>>>>>>                 up new avenues of attack?
>>>>>>>
>>>>>>>                 This is just the start, too. Things get even
>>>>>>>                 more complex if the client can ask for multiple
>>>>>>>                 different kinds of resources at once. What if
>>>>>>>                 the AS decides that the client needs a
>>>>>>>                 hyper-focused directed token for one part of the
>>>>>>>                 API, but can use a general token for other
>>>>>>>                 stuff? Can it signal that to the client? And if
>>>>>>>                 it can, does that mean that all clients need to
>>>>>>>                 I firmly believe that whatever we build in GNAP,
>>>>>>>                 we need to optimize for the overwhelmingly
>>>>>>>                 common use case of a client getting a single
>>>>>>>                 access token to call APIs that it already knows
>>>>>>>                 about. Anything we add on top of that really
>>>>>>>                 can’t get in the way of this, because if it
>>>>>>>                 does, there’s very small chance that people will
>>>>>>>                 try to use this for everyday things. Keep the
>>>>>>>                 community thinks about these use cases, and
>>>>>>>                 hopefully the people I’ve chatted with offline
>>>>>>>                 about this can join the conversation and provide
>>>>>>>                 more light than I was able to.
>>>>>>
>>>>>>                     (1) The client knows what resource it’s
>>>>>>                     calling, but it doesn’t know where it’s hosted.
>>>>>>                 That does not mean in any way that these two use
>>>>>>                 cases should be solved by placing the AS at the
>>>>>>                 centre of the solution.
>>>>>>
>>>>>>                 Denis
>>>>>>
>>>>>>>
>>>>>>>                  — Justin
>>>>>>>
>>>>>>
>>>>>>                 --
>>>>>>                 Txauth mailing list

---

From: Tom Jones <[email-masked]>
Date: Fri, 26 Jun 2020 10:36:29 -0700

that sounds useful. Do you think it should be in scope of this effort?
Peace ..tom

On Fri, Jun 26, 2020 at 10:18 AM Denis <[email-masked]> wrote:

> The ro is not involved in anyway at the time a client attempts to perform
> an operation.
>
> Denis
>
>>> The relationships between RSs may change at any time and it woauld not
>>> be reasonable to inform the ASs in real time
>>>>> You are also using the following wording: "methods for the AS and RS
>>>>> to communicate what the token’s good for".
>>>>> going to trust exactly one AS that it knows about ahead of time. But for
>>>>> RS’s that can trust multiple AS’s, then we should have a model that can
>>>>> access token, and that knowledge is completely outside the protocol. This
>>>>> makes a lot of sense for many (if not most) deployments, as OAuth is really
>>>>> there to enable the API access that the client already knows about.
>>>>>
>>>>> needs to dispatch to different resources depending on which user logged in
>>>>> (and possibly what the user consented to). To make things more concrete,
>>>>> the client needs to get driver’s license information, but doesn’t know
>>>>> ahead of time which of the many state/provincial bureaus to call to get
>>>>> that information because it doesn’t know yet who the user is.
>>>>>
>>>>> can now direct the client where to use the token, could a rogue AS convince
>>>>> a legit client to use a stolen token at the wrong RS? And what if the
>>>>> client ignores the directions from the AS entirely? Could this open up new
>>>>> avenues of attack?
>>>>>