Subject: Re: [Txauth] Use Case: Directed Tokens

From: Dick Hardt <[email-masked]>
Date: Thu, 2 Jul 2020 10:43:32 -0700

Apologies for the delayed response:

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

> 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.
>

Where do you see that the RS can have a relationship with only one AS?

>
> 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*.
>

OAuth 2.0 works this way now.

>
> 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.
>

I am still confused why you think the AS knows anything abou the
interactions a given use has with all the RSs. The AS knows which clients
the user is using, but does not need to have any knowledge of which RSs a
client is accessing.

The AS does not need to know anything about the RS. The RS clearly needs to
trust the AS, as it is trusting the access granted by the AS to the client,
but it is unidirectional trust between the RS and the AS.

/Dick

---

From: Tom Jones <[email-masked]>
Date: Thu, 2 Jul 2020 10:55:55 -0700

Dick, the statement about the AS and RS is not always true. In federations
we are always concerned that information is not leaked outside the approved
parties and the AS messages will likely be encrypted for the sole use of
the RS.
Peace ..tom

On Thu, Jul 2, 2020 at 10:44 AM Dick Hardt <[email-masked]> wrote:

> The AS does not need to know anything about the RS. The RS clearly needs
> to trust the AS, as it is trusting the access granted by the AS to the
> client, but it is unidirectional trust between the RS and the AS.
>
> /Dick
>

---

From: Dick Hardt <[email-masked]>
Date: Thu, 2 Jul 2020 11:01:05 -0700

I agree it is not always true, sorry I did not make that clear.

My statement is that OAuth 2.0 does not require the AS to have knowledge of
the RS.

On Thu, Jul 2, 2020 at 10:56 AM Tom Jones <[email-masked]>
wrote:

>>> For privacy reasons, every AS should know as little as possible about
>>> the interactions between a client and multiple RSs.

---

From: Denis <[email-masked]>
Date: Fri, 3 Jul 2020 11:09:39 +0200

Hello Dick,

> On Fri, Jun 26, 2020 at 9:04 AM Denis <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     The principle where a RS would only have relationships with one AS
>     would make the model non scalable.

In general, a RS can trust one or more AS, but this does not necessarily 
means that a RS and an AS have a (bi-)lateral relationship.
The current text of the charter is vague enough so that no one can 
really know. The text of the charter should be made more explicit.

>     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/.
>
>

I don't think so. Today, the only way to request specific attributes in 
OAuth 2.0. is to use the scope/RS pair which means that:

  * the AS knows to which RS the access token is intended, and
  * the AS and the RS have a bi-lateral relationship to know what the
    scope means.

>  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
> I am still confused why you think the AS knows anything about the 
> interactions a given user has with all the RSs.
> The AS knows which clients the user is using, but does not need to 
> have any knowledge of which RSs a client is accessing.

In OAuth 2.0, as soon as, for security reasons, an access token is 
targeted then the AS is able to know who the target is.
In GNAP, while not preventing this, we should have the ability to hide 
to the AS who the RS target is.

>  The AS does not need to know anything about the RS. The RS clearly 
> needs to trust the AS, as it is trusting the access granted by the AS 
> to the client,
> but it is /unidirectional trust/ between the RS and the AS.

"unidirectional trust" is not an appropriate wording. Since trust is 
between an entity A and an entity B for some kind of operation C
it does not presume what may happen in terms of trust between entity B 
and entity A. Nevertheless, it looks like that we are in agreement on 
that point.

Denis

---

From: Denis <[email-masked]>
Date: Fri, 3 Jul 2020 11:19:31 +0200

Hello  Dick,
> My statement is that OAuth 2.0 does not require the AS to have 
> knowledge of the RS.

As soon as the scope parameter is being used, then the AS has a prior 
knowledge of the RS.
When the scope parameter is not used, then the client has no ability to 
modulate the attributes.

Even when the AS has a no prior knowledge of the RS, when the access 
token is targeted to a given RS,
then the AS has the knowledge of which RS is likely to be accessed by 
the client.

While it may be interesting to list some of the limitations of OAuth 
2.0, it is much more important
to focus on the characteristics we would like to support with GNAP ...  
and to mention them in the charter.

Denis

>
> On Thu, Jul 2, 2020 at 10:56 AM Tom Jones 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
>
>     Dick, the statement about the AS and RS is not always true. In
>     federations we are always concerned that information is not leaked
>     outside the approved parties and the AS messages will likely be
>     encrypted for the sole use of the RS.
>     Peace ..tom
>
>
>     On Thu, Jul 2, 2020 at 10:44 AM Dick Hardt <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>             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.
>             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
>         I am still confused why you think the AS knows anything abou
>         the interactions a given use has with all the RSs. The AS
>         knows which clients the user is using, but does not need to
>         The AS does not need to know anything about the RS. The RS
>         clearly needs to trust the AS, as it is trusting the access
>         granted by the AS to the client, but it is unidirectional
>         trust between the RS and the AS.
>
>         /Dick
>

---

From: Dick Hardt <[email-masked]>
Date: Fri, 3 Jul 2020 18:50:36 -0700

While the scopes used in some implementations imply the RS, there is
nothing in OAuth 2.0 that requires the scope to imply the RS.

When you use your driver's license to prove your age at a liquor store, it
is unidirectional trust. The issuer likely has no relationship with the
audience.

I think you are contemplating claims rather than tokens if the driver's
license example is what you are contemplating.

On Fri, Jul 3, 2020 at 2:19 AM Denis <[email-masked]> wrote:

> Even when the AS has a no prior knowledge of the RS, when the access token
> is targeted to a given RS,
> then the AS has the knowledge of which RS is likely to be accessed by the
> client.
>
> While it may be interesting to list some of the limitations of OAuth 2.0,
> it is much more important
>> federations we are always concerned that information is not leaked outside
>> the approved parties and the AS messages will likely be encrypted for the
>> sole use of the RS.
>> Peace ..tom
>>
>>

---

From: Justin Richer <[email-masked]>
Date: Tue, 7 Jul 2020 16:39:28 -0400

I’ve been thinking more about these use cases, and it might help us to think of GNAP’s access tokens as capabilities in the computer security sense — but more specifically, capabilities that are delivered with their own context for use. In that way, an otherwise naive client can be handed an access token and simply know exactly what to do with it. This context would be delivered alongside the token, so the token material itself remains opaque to the client.

I wanted to bring up a W3C spec for a capabilities model based on linked data:

https://w3c-ccg.github.io/zcap-ld/ <https://w3c-ccg.github.io/zcap-ld/>

Building a fully featured capabilities context is difficult, at the very least. And unfortunately, I don’t think this spec actually gives us any viable solutions to work with. In particular the “actions” section is effectively blank, offloading the work to an external JSONLD process (side note, this is one of the problems I have with specs based on JSONLD, they externalize the important parts into local contexts and break interoperability — but I digress). But at least it’s another way of looking at the problem space that might be outside the familiar zone of many of the OAuth world.

 — Justin

> On Jun 26, 2020, at 9:23 AM, Justin Richer <[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 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. 
> 
> 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.
> 
>> 
>> > here are some worked out samples of this:
>> 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>
>> 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] <mailto:[email-masked]>> wrote:
>> 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,
>>>> 
>>>> A few comments between the lines.
>>>> 
>>>>> 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. 
>>>> 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.
>>>>> 
>>>>> 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 <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.
>>>> 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
>>>> 
>>>>> 
>>>>>  — 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] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
>> 
>> 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] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>

---

From: Tobias Looker <[email-masked]>
Date: Wed, 8 Jul 2020 12:01:10 +1200

I've also been thinking about the parallels between ZCAP's and OAuth2.0
access tokens. To me a ZCAP is a less opaque, semantically richer
capability format, whereas an access_token is traditionally much simpler.
The key here though is I still see an access_token as a form of capability.
It appears in general one of the trade offs we will be faced with is either:

1. Keeping the capability received from a GNAP flow (e.g an access_token)
opaque to the client and externalizing any greater information about how to
use the capability (such as in your proposal in the first email of this
thread).
2. Internalizing information about the capabilities utility and any greater
context about it which means the capability is no longer opaque.

With that aside, the notable features in general I would like GNAP to
consider from ZCAP's, are the following.

- Delegatable capabilities (bonus if this mechanism includes the ability to
attenuate during delegation) - Consider the example where a client or RP
(RP1) receives some form of access_token (capability) from an AS and would
like to delegate this to another RP (RP2) so they can access the same
resources. If including attenuation this would mean that during this
delegation (RP1->RP2), RP1 could narrow the scope of the original access it
received so that RP2 only gets a subset of the original scope.
- Bound capabilities - Similar in some ways to dPop, essentially
establishing the ability to bind an access_token (capability) to the party
that should be able to use it (invoker). I see this as a must have in order
to be able to do attenuated delegation as described above.

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, Jul 8, 2020 at 8:39 AM Justin Richer <[email-masked]> wrote:

> I’ve been thinking more about these use cases, and it might help us to
> think of GNAP’s access tokens as capabilities in the computer security
> sense — but more specifically, capabilities that are delivered with their
> own context for use. In that way, an otherwise naive client can be handed
> an access token and simply know exactly what to do with it. This context
> would be delivered alongside the token, so the token material itself
> remains opaque to the client.
>
> https://w3c-ccg.github.io/zcap-ld/
>
> Building a fully featured capabilities context is difficult, at the very
> least. And unfortunately, I don’t think this spec actually gives us any
> viable solutions to work with. In particular the “actions” section is
> effectively blank, offloading the work to an external JSONLD process (side
> note, this is one of the problems I have with specs based on JSONLD, they
> externalize the important parts into local contexts and break
> interoperability — but I digress). But at least it’s another way of looking
> at the problem space that might be outside the familiar zone of many of the
> OAuth world.
>
>  — Justin
>
> 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...
>
> > 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?
>
> 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://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.
>
>
> *Tobias Looker*
> [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:
>
>> 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
>> 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
>>
>> On Jun 22, 2020, at 3:55 AM, Denis <[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".
>> 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,
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> “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.
>>
>> 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]
>> https://www.ietf.org/mailman/listinfo/txauth
>>
>>
>>
>> --
>> Txauth mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/txauth
>>
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth
>
>
>

-- 
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: Denis <[email-masked]>
Date: Wed, 8 Jul 2020 09:26:10 +0200

Justin and Tobias,

A capability would include an identifier of both the granted 
operation(s) and the RS:
it allows the AS to know which operation(s) may be performed by the 
client and on which resource.
Since the AS knows who the client is, it is able to trace all its 
operations.
This would be a perfect "Big Brother by design" construction.

At the moment ZCAP-LD (Authorization Capabilities for Linked Data) is a 
"/draft /community group report" published in May 2020.
It is not a W3C Standard nor it is on the W3C Standards Track.

Tobias you believe that "establishing the ability to bind an 
access_token (capability) to the party that should be able to use it 
(invoker)" is a "must have".
This is indeed very important and this point is mentioned in the very 
last sentence of the above draft in section B : Handling abuse.

    Alice realizes that the abuse is coming from the invocation of a
    capability granted to some of Mallet's authentication *material*,
    and Alyssa revokes that capability.

While revoking a capability does not really make sense, checking that 
the access_token is indeed presented by the right invoker is necessary.
One way or another, a secure element needs to be used by the invoker.

Coming back to the topic of this thread which is about "Directed 
Tokens", my belief is that supporting delegation using "AS-based 
directed tokens"
would allow ASs to act as Big Brother. If there is another solution to 
support delegation (and there is one candidate) then it should be used.

Denis

> I've also been thinking about the parallels between ZCAP's and 
> OAuth2.0 access tokens. To me a ZCAP is a less opaque, semantically 
> richer capability format, whereas an access_token is traditionally 
> much simpler. The key here though is I still see an access_token as a 
> form of capability. It appears in general one of the trade offs we 
> will be faced with is either:
>
> 1. Keeping the capability received from a GNAP flow (e.g an 
> access_token) opaque to the client and externalizing any greater 
> information about how to use the capability (such as in your proposal 
> in the first email of this thread).
> 2. Internalizing information about the capabilities utility and any 
> greater context about it which means the capability is no longer opaque.
>
> - Delegatable capabilities (bonus if this mechanism includes the 
> ability to attenuate during delegation) - Consider the example where a 
> client or RP (RP1) receives some form of access_token (capability) 
> from an AS and would like to delegate this to another RP (RP2) so they 
> can access the same resources. If including attenuation this would 
> mean that during this delegation (RP1->RP2), RP1 could narrow the 
> scope of the original access it received so that RP2 only gets a 
> subset of the original scope.
> establishing the ability to bind an access_token (capability) to the 
> party that should be able to use it (invoker). I see this as a must 
> have in order to be able to do attenuated delegation as described above.
>
> Thanks,
> 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.
>
>
> On Wed, Jul 8, 2020 at 8:39 AM Justin Richer <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     I’ve been thinking more about these use cases, and it might help
>     us to think of GNAP’s access tokens as capabilities in the
>     computer security sense — but more specifically, capabilities that
>     are delivered with their own context for use. In that way, an
>     otherwise naive client can be handed an access token and simply
>     know exactly what to do with it. This context would be delivered
>     alongside the token, so the token material itself remains opaque
>     to the client.
>
>     Building a fully featured capabilities context is difficult, at
>     the very least. And unfortunately, I don’t think this spec
>     actually gives us any viable solutions to work with. In particular
>     the “actions” section is effectively blank, offloading the work to
>     an external JSONLD process (side note, this is one of the problems
>     I have with specs based on JSONLD, they externalize the important
>     parts into local contexts and break interoperability — but I
>     digress). But at least it’s another way of looking at the problem
>     space that might be outside the familiar zone of many of the OAuth
>     world.
>
>      — Justin
>
>>     On Jun 26, 2020, at 9: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 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.
>>
>>     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>
>>>     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
>>>>>         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"
>>>>>         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.
>>>>>
>>>>>>         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: Justin Richer <[email-masked]>
Date: Wed, 8 Jul 2020 10:32:44 -0400

I think there are two interesting layers here: 

 - Information that the client needs to know. This is what started the thread, the whole “how and where am I allowed to use this token” question. This is stuff that would be put alongside the token in the response from the AS, not inside the token.

 - Information that the RS needs to know. This is I think where the attenuation, proofing, and the actual rights associated with the token would go. This is stuff that would either be in the token itself or in a  return from an introspection style call.

Both of these fit into the “consistent token model” part of GNAP, but different aspects need to be communicated in different ways. 

 — Justin

> On Jul 7, 2020, at 8:01 PM, Tobias Looker <[email-masked]> wrote:
> 
> I've also been thinking about the parallels between ZCAP's and OAuth2.0 access tokens. To me a ZCAP is a less opaque, semantically richer capability format, whereas an access_token is traditionally much simpler. The key here though is I still see an access_token as a form of capability. It appears in general one of the trade offs we will be faced with is either:
> 
> 1. Keeping the capability received from a GNAP flow (e.g an access_token) opaque to the client and externalizing any greater information about how to use the capability (such as in your proposal in the first email of this thread).
> 2. Internalizing information about the capabilities utility and any greater context about it which means the capability is no longer opaque.
> 
> With that aside, the notable features in general I would like GNAP to consider from ZCAP's, are the following.
> 
> - Delegatable capabilities (bonus if this mechanism includes the ability to attenuate during delegation) - Consider the example where a client or RP (RP1) receives some form of access_token (capability) from an AS and would like to delegate this to another RP (RP2) so they can access the same resources. If including attenuation this would mean that during this delegation (RP1->RP2), RP1 could narrow the scope of the original access it received so that RP2 only gets a subset of the original scope.
> - Bound capabilities - Similar in some ways to dPop, essentially establishing the ability to bind an access_token (capability) to the party that should be able to use it (invoker). I see this as a must have in order to be able to do attenuated delegation as described above.
> 
> Thanks,
>  <https://mattr.global/>	 	
> Tobias Looker
> Mattr
> +64 (0) 27 378 0461
> On Wed, Jul 8, 2020 at 8:39 AM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>> On Jun 26, 2020, at 9:23 AM, Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Denis <[email-masked]>
Date: Wed, 8 Jul 2020 19:11:52 +0200

Hi Justin,
>  - Information that the client needs to know. This is what started the 
> thread, the whole “how and where am I allowed to use this token” 
> question.
> This is stuff that would be put alongside the token in the response 
> from the AS, not inside the token.

If the "how and where am I allowed to use this token” is sent alongside 
the token in the response from the AS, then you are allowing the AS
to know which RS(s) will be able to consume the access token. This 
should be prevented for privacy reasons (i.e. the AS would be able to 
act as Big Brother).

>
>  - Information that the RS needs to know. This is I think where the 
> attenuation, proofing, and the actual rights associated with the token 
> would go.
> This is stuff that would either be in the token itself or in a  return 
> from an introspection style call.

With an introspection style call you are allowing the AS to know to 
which RS(s) the access token has arrived. This should be prevented for 
privacy reasons
(i.e. the AS would be able to act as Big Brother).

Denis

>
> Both of these fit into the “consistent token model” part of GNAP, but 
> different aspects need to be communicated in different ways.
>
>  — Justin
>
>> On Jul 7, 2020, at 8:01 PM, Tobias Looker <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> ability to attenuate during delegation) - Consider the example where 
>> a client or RP (RP1) receives some form of access_token (capability) 
>> from an AS and would like to delegate this to another RP (RP2) so 
>> they can access the same resources. If including 
>> attenuation this would mean that during this delegation (RP1->RP2), 
>> RP1 could narrow the scope of the original access it received so that 
>> RP2 only gets a subset of the original scope.
>> 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.
>>
>>
>>     computer security sense — but more specifically, capabilities
>>     that are delivered with their own context for use. In that way,
>>     an otherwise naive client can be handed an access token and
>>     simply know exactly what to do with it. This context would be
>>     delivered alongside the token, so the token material itself
>>     actually gives us any viable solutions to work with. In
>>     particular the “actions” section is effectively blank, offloading
>>     the work to an external JSONLD process (side note, this is one of
>>     the problems I have with specs based on JSONLD, they externalize
>>     the important parts into local contexts and break
>>     interoperability — but I digress). But at least it’s another way
>>     of looking at the problem space that might be outside the
>>     familiar zone of many of the OAuth world.
>>
>>      — Justin
>>
>>>>     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?
>>>
>>>     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.
>>>
>>>     something. So we need to make sure that whatever system we
>>>     design will fail on the safe side as much as possible, and keep
>>>>     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
>>>>         Tom Jones is saying " I am getting tired of the
>>>>         whack-a-mole approach ...."
>>>>
>>>>         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
>>>>         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
>>>>         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.
>>>>
>>>>>         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.
>>>>>
>>>>>         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
>>>>>
>>>>>>>         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.
>>>>>>
>>>>>>>         different places, or a cloud deployment that the AS
>>>>>>>         wants to be able to dispatch the client to.
>>>>>>
>>>>>>>         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.
>>>>>>>
>>>>>>>         doesn’t know where it’s hosted. Everything is in a
>>>>>>>         single security domain controlled by the AS,
>>>>>>
>>>>>>         the bank does not "/need to know"/what are the diplomas
>>>>>>         of the user.
>>>>>>
>>>>>>>         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.
>>>>>>
>>>>>>         service provider" which has the knowledge of the
>>>>>>         different RSs affiliated to it.
>>>>>>
>>>>>>>         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?
>>>>>>>
>>>>>>>         client getting a single access token to call APIs that
>>>>>>>         it already knows about. Anything we add on top of that

---

From: Stephen Moore <[email-masked]>
Date: Wed, 8 Jul 2020 14:01:11 -0400

Hi Denis, I want to point out that not all use cases care or want the AS to
not know who is using the tokens.

So while we should enable the case you are talking about, where the AS
knows absolutely nothing about where the tokens are going, we should not
prevent that ability.
After all the AS is providing 'authorization' to access a resource, it
seems very limiting to say that the AS can't know what those resources are.
I imagine that in the healthcare
and financial fields, the AS is the point of logging and auditing who was
given authorization to access various systems and resources, and I can't
see that working in your case.

Also, as Justin points out, there are two ways to look at the rights in the
token, one is introspection, which does leave a paper trail (again, might
be needed for auditing reasons), or
have the resource server decode the token itself, which wouldn't tie the
token to that RS at the AS. We can't limit to just one path here. Again in
my (currently hypothetical) use case, the RS are IoT devices that
may not have the power to decode the tokens, and in fact will want to check
against the AS due to making sure tokens were not revoked.

I'll see if I can write up what I'm thinking in terms of use case,
partially because it splits up the authorisation and the authentication
parts of things. (I don't care who does the authentication, but my local AS
will do all the policy setting and authorization.)

-Steve

On Wed, Jul 8, 2020 at 1:13 PM Denis <[email-masked]> wrote:

> thread, the whole “how and where am I allowed to use this token” question.
> This is stuff that would be put alongside the token in the response from
> the AS, not inside the token.
>
> to know which RS(s) will be able to consume the access token. This should
> be prevented for privacy reasons (i.e. the AS would be able to act as Big
> Brother).
>
>
> With an introspection style call you are allowing the AS to know to which
> RS(s) the access token has arrived. This should be prevented for privacy
> reasons
> - Delegatable capabilities (bonus if this mechanism includes the ability
> to attenuate during delegation) - Consider the example where a client or RP
>> 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.
>>
>>
>> are not the intended recipient, you should not read it - please contact me
>>> Tom Jones is saying " I am getting tired of the whack-a-mole approach
>>> ...."
>>>
>>> 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
>>>
>>> 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
>>> 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
>>> 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
>>> 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
>>> 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.
>>>
>>> where it’s hosted.

---

From: Tom Jones <[email-masked]>
Date: Wed, 8 Jul 2020 11:03:50 -0700

I disagree with any approach that would allow the client/RP to
delegate anything that it does not own. The RP either has that
authority from the RO or AS, or not. Modifying the authority in any way
should not be permitted. New RO auth would be required.
OTOH any endpoint could be granted agency by the RO. That should not be
conflated with an AZ token. If agency is provided by a AZ token it is
unclear that it meets any of the various regulations.  Note that this
comment does not apply to :"data processors" that are disclosed to the RO.
Peace ..tom

---

From: Tobias Looker <[email-masked]>
Date: Thu, 9 Jul 2020 10:06:18 +1200

Tom,

By not creating a formal mechanism for delegation beyond the
RO->AS->Client, does not mean it wont or cannot occur. For instance if I as
a client get an access token from an AS today in OAuth2.0, I can delegate
this access to another client by giving them the access_token.

Thanks,
 <https://mattr.global>
*Tobias Looker*
Mattr
+64 (0) 27 378 0461

On Thu, Jul 9, 2020 at 6:04 AM Tom Jones <[email-masked]>
wrote:

>>> ..."

---

From: Tom Jones <[email-masked]>
Date: Wed, 8 Jul 2020 16:42:28 -0700

ahh, you mean bearer tokens. Yes, of course. I would not call that
delegation, I would call it fraud. All the more reason to abandon bearer
tokens.
Peace ..tom

On Wed, Jul 8, 2020 at 3:06 PM Tobias Looker <[email-masked]>
wrote:

>>> 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 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
>>> 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.
>>>> 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)
>>>> To handle the complex case you envision, the full workflow of
>>>> operations needs to be considered with a detailed focus on the time
>>>> 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.
>>>> As soon the AS is placed (again) at the centre of the model, the AS
>>>> will have the ability to act as "Big Brother".
>>>> 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.
>>>>
>>>> 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
>>>> 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