Subject: Re: [Txauth] Multiple Access Tokens in XYZ

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 14 Mar 2020 11:04:28 +0100

Hi Justin,

I have always been a fan of multiple access tokens support :-) So thanks you for bringing this forward.

Some questions:

Do you assume the client can freely allocated resources to access tokens? How would that work with audience-restricted/specific access tokens?

I think a further element „token“ element within the resource structure could also be used to denote the assignment of a certain resource object to this token. Advantage: no need to change the syntax. What do you think about this approach?

best regards,
Torsten.

>> Am 13.03.2020 um 23:13 schrieb Justin Richer <[email-masked]>:
> I took some time to implement an idea that was tossed out on the list here recently, and that’s how we might support requests and responses for multiple access tokens. I’ve got a method that I think works pretty well without getting in the way of the common, simple case of requesting a single access token. I’ve implemented this in our Java implementation of XYZ and I’ve updated the https://oauth.xyz/ website with more details. I’ll update my ID spec text when I get a chance to reflect this, but I wanted to start this discussion first. Everything in here is based on the XYZ protocol.
> 
> Normally, the “resources” element of a tx request is an array of items:
> 
> resources: [
> 	{
>             actions: ["read", "write", "dolphin"],
>             locations: ["https://server.example.net/", "https://resource.local/other"],
>             datatypes: ["metadata", "images"]
>         },
> 	{
>             actions: ["foo", "bar", "dolphin"],
>             locations: ["https://resource.other/"],
>             datatypes: ["data", "pictures"]
>         }
> ]
> 
> This tells the AS that the client is asking for a single access token with multiple, perhaps orthogonal sets of access. This is in parallel to RAR being developed in OAuth 2. However, if we allow the “resources” item to be an object instead of an array, we can let the client signal to the AS that it wants multiple access tokens. The client picks “labels” for these access tokens, in this case “token1” and “token2”, and sends a request like this.
> 
> resources: {
>     token1: [{
>             actions: ["read", "write", "dolphin"],
>             locations: ["https://server.example.net/", "https://resource.local/other"],
>             datatypes: ["metadata", "images"]
>      }],
>      token2: [{
>             actions: ["foo", "bar", "dolphin"],
>             locations: ["https://resource.other/"],
>             datatypes: ["data", "pictures"]
>      }]
> }
> 
> The client could request multiple kinds of access within each sub-object’s array (the value of the “token1” and “token2” fields), but I wanted to keep it simple here. This example is the same total set of resources that the client is asking for in the first case, but here the client’s saying it wants them as two different access tokens instead of a single one. The AS can tell the difference in the request because the first type is an array at the top and the second type is an object at the top. So that means that the AS can send back a single access token in a tx response like this:
> 
> {
>         access_token: {
>             value: "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",
>             type: "bearer"
>         }
> }
> 
> Or multiple access tokens in a tx response like this:
> 
> {
>     multiple_access_tokens: {
>           token1: {
>             value: "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",
>             type: "bearer"
>           },
>           token2: {
>             value: "UFGLO2FDAFG7VGZZPJ3IZEMN21EVU71FHCARP4J1",
>             type: "bearer"
>           }
>     }
> }
> 
> These fields are mutually exclusive, so you either get a single unnamed token or a set of named tokens. Since the client pics the labels for the access tokens, it’s clear which part of the request maps to which part of the response. It’s more complexity for the client to track, but that complexity is only seen and borne by clients that need it. Simple clients get to stay simple while letting a complex problem get solved. 
> 
> A note about the polymorphic JSON that’s in user here, though it’s already a key part of XYZ’s protocol design. For those unfamiliar with the concept, this is when a given field can have a value that takes multiple different types: a string, a boolean, an object, an array, etc. This is pretty simple to deal with in dynamically typed languages, you just check the type of the resulting object and it will tell you what you’re dealing with. It’s trickier in statically typed languages, but I’ve found that pretty much every platform and library has hooks for custom serialization and deserialization that will let you dispatch to different types during the process, so you can still call your top-level parser and toString methods and things will work as expected. This is one of the reasons that I did an implementation in Java, to prove that we could do this kind of thing in a strongly typed language that’s not very flexible about what goes in objects, and I’ve done it without resorting to generic collections for the dynamic fields. Previously, I’ve used this feature in XYZ to allow a single string to stand in as a reference for an object — something XYZ calls “handles”. These let you have constructs akin to a client_id, a scope, a refresh token, and a few other items without having to create explicit elements for these, since they always stand in for the object they replace there’s no ambiguity. So for things like a resource request, each of these can be replaced by a string using resource handles and polymorphic JSON (see note below) to act like a scope in OAuth2.
> 
> resources: [ “metadata-readwrite”, “foobar-pictures” ]
> 
> Polymorphic JSON is great for things like this because it means you don’t have to have multiple fields and normative rules for mutual exclusivity, like we’d have to have otherwise. The type switching only works when the base type is significantly different, though — that’s why I have “access_token” and “multiple_access_tokens” above, since both are objects at the top level and you can’t cleanly switch at the parser level, and you don’t want to have to dig down into the object to see what to do with it.
> 
> 
> 
> People have been asking for a good way to do multiple access tokens with OAuth for years, but we’ve never had a good or clean way to pull it off because of OAuth’s model and the assumptions that it makes. I think TxAuth gives us the opportunity to solve this in a way that’s consistent with the rest of the protocol, and do so in a way that doesn’t make the simple cases we know and love too complicated for average developers.
> 
>  — Justin
> 
> -- 
> Txauth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth

---

From: Justin Richer <[email-masked]>
Date: Sat, 14 Mar 2020 09:07:43 -0400

> I have always been a fan of multiple access tokens support :-) So thanks you for bringing this forward.

Yes! It’s only taken us another 10 years to get back here again. :)

> Do you assume the client can freely allocated resources to access tokens? How would that work with audience-restricted/specific access tokens?

In the syntax I’m proposing, the client can take any set of resources and ask for it to go with one token. Basically, each named element of the resources object in the multi-token request syntax is exactly the same as a single token request would be, an array of resource requests. So yes, the client can mix and match as it sees fit, and the AS can reject a request for combining two different audiences in the same token. The AS would need to do that anyway for a single token request, so I don’t see that as a greater burden — it’s just that now the client can fulfill the requirements without making multiple transaction requests. 

This syntax doesn’t allow the AS to assign multiple tokens to a client’s simple request, but I actually like that feature. If the client is capable of dealing with multiple tokens simultaneously, it can ask for them. The single token case turns into a single unnamed access token with the same semantics. 

> I think a further element „token“ element within the resource structure could also be used to denote the assignment of a certain resource object to this token. Advantage: no need to change the synt…

That’s an interesting idea, and I can see the advantage of a simpler syntax on the surface … but at first shake I see a couple problems with it. First, this presumes you’d always be sending a full resource object. If you’re sending a scope string (or a resource handle in XYZ terms), then you don’t have anywhere to put the name of the token since it’s no longer an object. Second, there’s no clear way to combine multiple resource facets into a single token. And third, you now have to handle a whole bunch of new error cases: what if some of the resource request objects have names, and others don’t? What if you use the same name on multiple resource request objects? If that means you combine them into a single token, you’re back at the question above about audience restrictions. And finally, it changes the semantics of the resource object in a way that a simple client would have to at least know about, and be able to deal with the AS’s different error conditions.

Your thoughts on these points? I might be missing something obvious with what you’re suggesting.

Thanks for the feedback!

 — Justin

>> I took some time to implement an idea that was tossed out on the list here recently, and that’s how we might support requests and responses for multiple access tokens. I’ve got a method that I think works pretty well without getting in the way of the common, simple case of requesting a single access token. I’ve implemented this in our Java implementation of XYZ and I’ve updated the https://oauth.xyz/ <https://oauth.xyz/> website with more details. I’ll update my ID spec text when I get a chance to reflect this, but I wanted to start this discussion first. Everything in here is based on the XYZ protocol.
>> 
>>             locations: ["https://server.example.net/ <https://server.example.net/>", "https://resource.local/other <https://resource.local/other>"],
>>             locations: ["https://resource.other/ <https://resource.other/>"],
>>             locations: ["https://server.example.net/ <https://server.example.net/>", "https://resource.local/other <https://resource.local/other>"],
>>             locations: ["https://resource.other/ <https://resource.other/>"],

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 14 Mar 2020 17:32:52 +0100

Hi Justin,

> On 14. Mar 2020, at 14:07, Justin Richer <[email-masked]> wrote:
> 

yep. Just an example ;-): https://mailarchive.ietf.org/arch/msg/oauth/JcKGhoKy2S_2gAQ2ilMxCPWbgPw/

> In the syntax I’m proposing, the client can take any set of resources and ask for it to go with one token. Basically, each named element of the resources object in the multi-token request syntax is…

What would be the client’s motivation to split resources to different access tokens? 
What information would the client use to allocate the resources to the appropriate access tokens? 

In my experience, it is the AS (or the security policy of the deployment) that determines what can go into a single access token. 

One policy is to allow everything to go into a single access token. That might work in a single RS deployment. In a multi RS deployment, one would either end up with tokens containing the set union of all data needed by all RSs. Encryptions of those tokens might be complex, I don’t know whether this is privacy preserving. The other option is to use token introspection or other callbacks to the AS to obtain the real data needed for access control per RS, not very performant. 

Another possible policy is to have access tokens that at most contain data for a certain resource server. This helps privacy (no implicit data sharing among resource servers) and security (single audience, encryption is straightforward, simple token replay prevention). But someone needs to know the boundaries. 

If the client knows the boundaries, all it would need to ask the AS for is to issue access tokens for a set of recipients. This could be done in parallel to the resources structure. 

Something like this: 

{
   "resources":[
      {
         "actions":[
            "read",
            "write",
            "dolphin"
         ],
         "locations":[
            "https://server.example.net/",
            "https://resource.local/other"
         ],
         "datatypes":[
            "metadata",
            "images"
         ]
      },
      {
         "actions":[
            "read"
         ],
         "locations":[
            "https://server1.example.net/"
         ],
         "datatypes":[
            "contacts"
         ]
      }
   ],
   "tokens":[
      "https://server.example.net/",
      "https://server1.example.net/"
   ]
}

The default could be that the AS issues an access token good for all granted resources. 

One could also go one step further and let the AS decide what access tokens it would issue and add metadata about the recipients to the response. 

{
   "access_tokens":[
      {
         "destination":"https://server.example.net/"",
         "value":"OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",
         "type":"bearer"
      },
      {
         "destination":"https://server1.example.net/",
         "value":"OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT1",
         "type":"bearer"
      }
   ],
   "handle":{
      "value":"80UPRY5NM33OMUKMKSKU",
      "type":"bearer"
   },
   "claims":{
      "subject":"UR64TB8N6BW7OZB8CDFONP-MHKUR6",
      "email":"[email-masked]"
   }
}

I personally think this would even better fit the transactional character of the new protocol.

> 
> This syntax doesn’t allow the AS to assign multiple tokens to a client’s simple request, but I actually like that feature. If the client is capable of dealing with multiple tokens simultaneously, it can ask for them.

I think that’s the important aspect! In my opinion, the AS basically decides whether different tokens are required for different resources. I therefore think all client must be prepared to use different tokens to use the privileges granted in a certain transaction (in the same way OAuth 2 clients must be prepared for refresh tokens rotation). Whether the client asks for more all or just a specific token (to start with), is a different question. 

> The single token case turns into a single unnamed access token with the same semantics. 

> That’s an interesting idea, and I can see the advantage of a simpler syntax on the surface … but at first shake I see a couple problems with it. First, this presumes you’d always be sending a full resource object. If you’re sending a scope string (or a resource handle in XYZ terms), then you don’t have anywhere to put the name of the token since it’s no longer an object.

That’s certainly true. 

> Second, there’s no clear way to combine multiple resource facets into a single token.

Why, just use the same label.

> And third, you now have to handle a whole bunch of new error cases: what if some of the resource request objects have names, and others don’t? What if you use the same name on multiple resource request objects? If that means you combine them into a single token, you’re back at the question above about audience restrictions.

You need to solve that anyway. I feel my proposal above is more suitable. 

> And finally, it changes the semantics of the resource object in a way that a simple client would have to at least know about, and be able to deal with the AS’s different error conditions.
> 

I’m still struggling to understand why a client should ask for a certain assignment of resources. I think it’s basically the AS in enforcing a certain security policy. The client (on top of that) might ask for less powerful access tokens within the boundaries defined by the AS. 

> Thanks for the feedback!

Happy to do so. It’s an important topic waiting for an interoperable solution. I think we need to introduce a clear indication of boundaries between resource servers (or security domains or whatever you want to call it) in oder to solve that. 

best regards,
Torsten.

---

From: David Skaife <[email-masked]>
Date: Sat, 14 Mar 2020 21:56:40 +0000

Hi,

This is an interesting idea, and one which I think would be a useful
addition to the protocol. As you've mentioned, it will be incredibly
important to define it in a way that enables the simpler use cases to
remain simple, and not be complicated by this additional optional feature.

With regards to Torsten's question: "*What would be the client’s motivation
to split resources to different access tokens?*"
I'm involved in the implementation of Open Banking within the United
Kingdom and I can certainly think of scenarios in Open Banking where the
client app would be able to provide a better user experience if they could
offer the ability to revoke permissions at a fine-grained level, rather
than the user having to revoke "all or nothing". For example, if a user has
provided a third-party provider with access to their current account
balance, account name, and account transactions, at a later point they may
want to revoke third-party provider access to their transactions but keep
the other permissions active - enabling the client app to split the
resources to between different access tokens would provide that ability.

Related to the above example, within the context of Open Banking in the UK,
we also have the scenario where a user is able to select which of their
bank accounts they want to be included within the scope of an authorisation
at the point when the user is interacting directly with the Authorization
Server (i.e. after the client has already sent the initial back-channel
request to the AS containing details of the requested resources, and with
this new feature we're discussing here, the details of the access token
split) - it would be very desirable (for similar reasons to above example)
to have one access token per bank account rather than one access token
covering all of their bank accounts, to enable the user to revoke access to
each account individually. This might be out of scope of this particular
discussion, but within the context of XYZ and within the context of this
multiple access token proposal, would there be any way to assign different
access tokens to elements of the authorisation that are selected by the
user AFTER the initial back-channel request between the client and the AS?

One final question from me on this: I'm assuming that it would be optional
for Authorization Servers to support multiple access tokens and so what
would be the mechanism for the client to determine if the AS supports it,
and what would be the response back if a client tries to utilise a feature
such as this that the AS doesn't support?

Many Thanks,
David Skaife

On Sat, Mar 14, 2020 at 4:33 PM Torsten Lodderstedt <torsten=
[email-masked]> wrote:

> yep. Just an example ;-):
> https://mailarchive.ietf.org/arch/msg/oauth/JcKGhoKy2S_2gAQ2ilMxCPWbgPw/
>
> >>
> >> Some questions:
> >>
> >> Do you assume the client can freely allocated resources to access
> tokens? How would that work with audience-restricted/specific access tokens?
> >
> > In the syntax I’m proposing, the client can take any set of resources
> and ask for it to go with one token. Basically, each named element of the
> resources object in the multi-token request syntax is exactly the same as a
> single token request would be, an array of resource requests. So yes, the
> client can mix and match as it sees fit, and the AS can reject a request
> for combining two different audiences in the same token. The AS would need
> to do that anyway for a single token request, so I don’t see that as a
> greater burden — it’s just that now the client can fulfill the requirements
> without making multiple transaction requests.
>
> In my experience, it is the AS (or the security policy of the deployment)
> that determines what can go into a single access token.
>
> One policy is to allow everything to go into a single access token. That
> might work in a single RS deployment. In a multi RS deployment, one would
> either end up with tokens containing the set union of all data needed by
> all RSs. Encryptions of those tokens might be complex, I don’t know whether
> this is privacy preserving. The other option is to use token introspection
> or other callbacks to the AS to obtain the real data needed for access
> control per RS, not very performant.
>
> Another possible policy is to have access tokens that at most contain data
> for a certain resource server. This helps privacy (no implicit data sharing
> among resource servers) and security (single audience, encryption is
> straightforward, simple token replay prevention). But someone needs to know
> the boundaries.
>
> If the client knows the boundaries, all it would need to ask the AS for is
> to issue access tokens for a set of recipients. This could be done in
> parallel to the resources structure.
>
> Something like this:
>
> {
>    "resources":[
>       {
>          "actions":[
>             "read",
>             "write",
>             "dolphin"
>          ],
>          "locations":[
> One could also go one step further and let the AS decide what access
> tokens it would issue and add metadata about the recipients to the
> response.
>
> {
>    "access_tokens":[
>       {
> > This syntax doesn’t allow the AS to assign multiple tokens to a client’s
> simple request, but I actually like that feature. If the client is capable
> of dealing with multiple tokens simultaneously, it can ask for them.
>
> I think that’s the important aspect! In my opinion, the AS basically
> decides whether different tokens are required for different resources. I
> therefore think all client must be prepared to use different tokens to use
> the privileges granted in a certain transaction (in the same way OAuth 2
> clients must be prepared for refresh tokens rotation). Whether the client
> asks for more all or just a specific token (to start with), is a different
> question.
>
> >> I think a further element „token“ element within the resource structure
> could also be used to denote the assignment of a certain resource object to
> this token. Advantage: no need to change the syntax. What do you think
> about this approach?
> >
> > That’s an interesting idea, and I can see the advantage of a simpler
> syntax on the surface … but at first shake I see a couple problems with it.
> First, this presumes you’d always be sending a full resource object. If
> you’re sending a scope string (or a resource handle in XYZ terms), then you
> don’t have anywhere to put the name of the token since it’s no longer an
> object.
>
> That’s certainly true.
>
> > And third, you now have to handle a whole bunch of new error cases: what
> if some of the resource request objects have names, and others don’t? What
> if you use the same name on multiple resource request objects? If that
> means you combine them into a single token, you’re back at the question
> above about audience restrictions.
>
> > And finally, it changes the semantics of the resource object in a way
> that a simple client would have to at least know about, and be able to deal
> with the AS’s different error conditions.
> >
> I’m still struggling to understand why a client should ask for a certain
> assignment of resources. I think it’s basically the AS in enforcing a
> certain security policy. The client (on top of that) might ask for less
> powerful access tokens within the boundaries defined by the AS.
>
> >
> > Thanks for the feedback!
>
> Happy to do so. It’s an important topic waiting for an interoperable
> solution. I think we need to introduce a clear indication of boundaries
> between resource servers (or security domains or whatever you want to call
> it) in oder to solve that.
>
> best regards,
> Torsten.
>
> >
> >  — Justin
> >
> >>
> >> best regards,
> >> Torsten.
> >>
> >>> I took some time to implement an idea that was tossed out on the list
> here recently, and that’s how we might support requests and responses for
> multiple access tokens. I’ve got a method that I think works pretty well
> without getting in the way of the common, simple case of requesting a
> single access token. I’ve implemented this in our Java implementation of
> XYZ and I’ve updated the https://oauth.xyz/ website with more details.
> I’ll update my ID spec text when I get a chance to reflect this, but I
> wanted to start this discussion first. Everything in here is based on the
> XYZ protocol.
> >>>
> >>> This tells the AS that the client is asking for a single access token
> with multiple, perhaps orthogonal sets of access. This is in parallel to
> RAR being developed in OAuth 2. However, if we allow the “resources” item
> to be an object instead of an array, we can let the client signal to the AS
> that it wants multiple access tokens. The client picks “labels” for these
> access tokens, in this case “token1” and “token2”, and sends a request like
> this.
> >>>
> >>> resources: {
> >>>     token1: [{
> >>> The client could request multiple kinds of access within each
> sub-object’s array (the value of the “token1” and “token2” fields), but I
> wanted to keep it simple here. This example is the same total set of
> resources that the client is asking for in the first case, but here the
> client’s saying it wants them as two different access tokens instead of a
> single one. The AS can tell the difference in the request because the first
> type is an array at the top and the second type is an object at the top. So
> that means that the AS can send back a single access token in a tx response
> like this:
> >>>
> >>> {
> >>>         access_token: {
> >>> These fields are mutually exclusive, so you either get a single
> unnamed token or a set of named tokens. Since the client pics the labels
> for the access tokens, it’s clear which part of the request maps to which
> part of the response. It’s more complexity for the client to track, but
> that complexity is only seen and borne by clients that need it. Simple
> clients get to stay simple while letting a complex problem get solved.
> >>>
> >>> A note about the polymorphic JSON that’s in user here, though it’s
> already a key part of XYZ’s protocol design. For those unfamiliar with the
> concept, this is when a given field can have a value that takes multiple
> different types: a string, a boolean, an object, an array, etc. This is
> pretty simple to deal with in dynamically typed languages, you just check
> the type of the resulting object and it will tell you what you’re dealing
> with. It’s trickier in statically typed languages, but I’ve found that
> pretty much every platform and library has hooks for custom serialization
> and deserialization that will let you dispatch to different types during
> the process, so you can still call your top-level parser and toString
> methods and things will work as expected. This is one of the reasons that I
> did an implementation in Java, to prove that we could do this kind of thing
> in a strongly typed language that’s not very flexible about what goes in
> objects, and I’ve done it without resorting to generic collections for the
> dynamic fields. Previously, I’ve used this feature in XYZ to allow a single
> string to stand in as a reference for an object — something XYZ calls
> “handles”. These let you have constructs akin to a client_id, a scope, a
> refresh token, and a few other items without having to create explicit
> elements for these, since they always stand in for the object they replace
> there’s no ambiguity. So for things like a resource request, each of these
> can be replaced by a string using resource handles and polymorphic JSON
> (see note below) to act like a scope in OAuth2.
> >>>
> >>> Polymorphic JSON is great for things like this because it means you
> don’t have to have multiple fields and normative rules for mutual
> exclusivity, like we’d have to have otherwise. The type switching only
> works when the base type is significantly different, though — that’s why I
> have “access_token” and “multiple_access_tokens” above, since both are
> objects at the top level and you can’t cleanly switch at the parser level,
> and you don’t want to have to dig down into the object to see what to do
> with it.
> >>>
> >>>
> >>>
> >>> People have been asking for a good way to do multiple access tokens
> with OAuth for years, but we’ve never had a good or clean way to pull it
> off because of OAuth’s model and the assumptions that it makes. I think
> TxAuth gives us the opportunity to solve this in a way that’s consistent
> with the rest of the protocol, and do so in a way that doesn’t make the
> simple cases we know and love too complicated for average developers.
> >>>
> >>>  — Justin
> >>>
> >>> --
> >>> Txauth mailing list
> >>> [email-masked]

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 14 Mar 2020 23:17:37 +0100

Hi David,

> Am 14.03.2020 um 22:57 schrieb David Skaife <[email-masked]>:
> 
> 
> Hi,
> 
> This is an interesting idea, and one which I think would be a useful addition to the protocol. As you've mentioned, it will be incredibly important to define it in a way that enables the simpler use cases to remain simple, and not be complicated by this additional optional feature.
> 
> With regards to Torsten's question: "What would be the client’s motivation to split resources to different access tokens?"
> I'm involved in the implementation of Open Banking within the United Kingdom and I can certainly think of scenarios in Open Banking where the client app would be able to provide a better user experience if they could offer the ability to revoke permissions at a fine-grained level, rather than the user having to revoke "all or nothing". For example, if a user has provided a third-party provider with access to their current account balance, account name, and account transactions, at a later point they may want to revoke third-party provider access to their transactions but keep the other permissions active - enabling the client app to split the resources to between different access tokens would provide that ability.

I see the use case, but I would solve it differently by revoking the resource object assigned to a certain transaction handle instead of the access token. The token, in my mental model, is just the credential required to execute certain privileges but not the privilege itself.

> 
> Related to the above example, within the context of Open Banking in the UK, we also have the scenario where a user is able to select which of their bank accounts they want to be included within the scope of an authorisation at the point when the user is interacting directly with the Authorization Server (i.e. after the client has already sent the initial back-channel request to the AS containing details of the requested resources, and with this new feature we're discussing here, the details of the access token split) - it would be very desirable (for similar reasons to above example) to have one access token per bank account rather than one access token covering all of their bank accounts, to enable the user to revoke access to each account individually. This might be out of scope of this particular discussion, but within the context of XYZ and within the context of this multiple access token proposal, would there be any way to assign different access tokens to elements of the authorisation that are selected by the user AFTER the initial back-channel request between the client and the AS?

I think this would require a selection over the resources assigned to a certain transaction handle. Here it is getting rather tricky if a single resource object contains all bank accounts. Sending another request to the AS with the transaction handle and a subset in the resource parameter that shall be assigned to the access token should do the job. The AS should be able to determine that the privileges were already granted in this transaction, so no further user interaction required.

> One final question from me on this: I'm assuming that it would be optional for Authorization Servers to support multiple access tokens and so what would be the mechanism for the client to determine if the AS supports it, and what would be the response back if a client tries to utilise a feature such as this that the AS doesn't support?

I think the use cases you described require an assignment of a subset of resources to a token, not necessarily multiple access tokens.

best regards,
Torsten.

> 
> Many Thanks,
> David Skaife
> 
>> On Sat, Mar 14, 2020 at 4:33 PM Torsten Lodderstedt <torsten=[email-masked]> wrote:
>> Hi Justin,
>>

---

From: Justin Richer <[email-masked]>
Date: Sat, 14 Mar 2020 22:25:06 -0400

I’m realizing something with your description below that I think gets to the differences we’re seeing in the use case driving this:

I think you are looking at the split of access tokens being based on differences in resource server domains, such that the driver is the audience restriction from the security domain of the AS/RS side. However, I’m looking at it from the perspective of the client calling an API (or set of APIs) with different capabilities. And so in that case, it’s not just about “where” the token is used, but what it’s used for. In other words, it’s the Client/RS relationship driving things. 

Let’s say, for instance, we’ve got a complex client that wants to have a long-lived read-only access token and a short-lived read-write token for an API. The client’s going to know about the API it’s requesting — even if the client library doesn’t know, the client software using it will know how the APIs that it’s been designed to call can be split up. And how that happens is really up to the API, which is of course defined by the RS and secured by the AS. So if the AS needs a client to get different access tokens to call different RS domains, it does exactly what we do in OAuth 2 today — it tells the client to get two different access tokens. Except now, the client can ask for them at the same time. So you see, it’s about a lot more than the “destination” of the token, it’s about the entire desired use of the token. In other words, the sum total of a “resources” structure, an array of objects combined together to give a whole picture.

Yes, the AS is still going to apply policy, and if the client is asking for multiple resource object sets that can’t be combined, for whatever reason, it can reject that. However, I think it’s a really bad idea to say that all clients need to be prepared to maybe get multiple access tokens, and know what to do with them. 

The thing I don’t like about your proposed syntax(es) is that it adds complexity that even the clients who never care about multiple access tokens will need to deal with. I do not want all clients to pay this cost. I think the vast majority of clients and resource servers are going to remain single access token like with OAuth2, and this general case shouldn’t be burdened with even thinking about multiple access tokens. I think that my proposal lets this happen without the two getting in the way of each other, which to me is a big win. 

As an aside: parallel data structures, like the “tokens” component idea below, are almost always a hack, a symptom of bad syntax that isn’t extensible in the right way. Considering that it’s essentially the same data and requirements on the client, I don’t see what that buys apart from avoiding polymorphic JSON, which I might add could be avoided by having mutually exclusive data structures of different types (but, as per my first email, I hope we can avoid that because it’s brittle). 

 — Justin

> On Mar 14, 2020, at 12:32 PM, Torsten Lodderstedt <[email-masked]> wrote:
> 
> Hi Justin,
>

---

From: Justin Richer <[email-masked]>
Date: Sat, 14 Mar 2020 22:35:32 -0400

Hi David,

My take on this is that in order for a client to be able to throw out sub-components of its access by using, say, token revocation, you’d need to ask for separate tokens from the start. I think the multiple bank accounts scenario you lay out below is exactly that kind of thing — you ask for three different bank accounts from one bank, so they all have the same RS but different access information. Otherwise, you’re really just talking about refreshing an existing access token with fewer rights than it started out as — at least, if I’m understating the second scenario below. That’s a bit weird but in an interesting way: So far in the OAuth world just about everything is additive, since that’s usually what people care about in practice. Stepping up AuthZ and only asking for more than you’ve already gotten the OK for. Refreshes are explicitly allowed to downscope without prompting the user, and I had that in mind with the transaction refresh. I think that there’s more we could do with this, including adoption of the per-access-token management API idea that’s been floated in the XYZ writeup (not in the spec or implementation yet, mind you).

As for discovery, I think XAuth’s idea of allowing OPTIONS is a good one, but I would restrict it to being an OPTONS call on the Transaction Endpoint instead of the matrix in the current proposal. This way, the client still only has one URL to start things with at the AS. Right now in XYZ we’ve got the “capabilities” array to communicate that kind of information as well, and that could be a factor too. I’m not sure though because I haven’t really played with it in implementation yet. As the OAuth 2 mix-up attack showed us, server discovery can be a little tricky to get right in a secure way.

 — Justin

On Mar 14, 2020, at 5:56 PM, David Skaife <[email-masked]> wrote:
> On Sat, Mar 14, 2020 at 4:33 PM Torsten Lodderstedt <torsten=[email-masked] <mailto:[email-masked]>> wrote:
> Hi Justin,
> 
> > On 14. Mar 2020, at 14:07, Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > On Mar 14, 2020, at 6:04 AM, Torsten Lodderstedt <[email-masked] <mailto:[email-masked]>> wrote:
> >> 
> >> 
> >> Hi Justin,
> >> 
> yep. Just an example ;-): https://mailarchive.ietf.org/arch/msg/oauth/JcKGhoKy2S_2gAQ2ilMxCPWbgPw/ <https://mailarchive.ietf.org/arch/msg/oauth/JcKGhoKy2S_2gAQ2ilMxCPWbgPw/>
> 
> >> 
> >> Some questions:
> >> 
>             "https://server.example.net/ <https://server.example.net/>",
>             "https://resource.local/other <https://resource.local/other>"
>          ],
>          "datatypes":[
>             "metadata",
>             "images"
>          ]
>       },
>       {
>          "actions":[
>             "read"
>          ],
>          "locations":[
>             "https://server1.example.net/ <https://server1.example.net/>"
>          ],
>          "datatypes":[
>             "contacts"
>          ]
>       }
>    ],
>    "tokens":[
>       "https://server.example.net/ <https://server.example.net/>",
>       "https://server1.example.net/ <https://server1.example.net/>"
>    ]
> }
> 
>          "destination":"https://server.example.net/ <https://server.example.net/>"",
>          "destination":"https://server1.example.net/ <https://server1.example.net/>",
>       "email":"[email-masked] <mailto:[email-masked]>"
>    }
> }
> 
> >>> Am 13.03.2020 um 23:13 schrieb Justin Richer <[email-masked] <mailto:[email-masked]>>:
> >>> 
> >>> [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>

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Sun, 15 Mar 2020 09:30:16 +0200

On 15/03/2020 04:35, Justin Richer wrote:
> Refreshes are explicitly allowed to downscope without prompting the
> user, and I had that in mind with the transaction refresh. I think
> that there’s more we could do with this, including adoption of the
> per-access-token management API idea that’s been floated in the XYZ
> writeup (not in the spec or implementation yet, mind you).

Speaking of downscoping refreshes, what we found lacking in OAuth 2.0 is
that it works only for scope values and there's no way to reduce the
OpenID claims.

Vladimir

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 15 Mar 2020 13:58:15 +0100

> On 15. Mar 2020, at 03:25, Justin Richer <[email-masked]> wrote:
> 
> So if the AS needs a client to get different access tokens to call different RS domains, it does exactly what we do in OAuth 2 today — it tells the client to get two different access tokens. 

How does this work in XYZ?

---

From: Justin Richer <[email-masked]>
Date: Sun, 15 Mar 2020 10:26:23 -0400

> How does this work in XYZ?

Without using the multi-access-token thing I’m proposing in this thread, the client would just make two separate transaction calls to get two different tokens. There’s a few ways that shakes out depending on some of the details. In the OAuth world that amounts to involving the user twice, and it might be the same in XYZ if you’re asking for different things:

1. Client: Start TX-1 (R-1)
2. User: Approve R-1
3. AS: Issue AT-1(R-1)
4. Client: Start TX-2 (R-1)
5. User: approve R-2
6. AS: Issue AT-2(R-2)

Unless you’re getting a super refresh token upfront and then calling for two downgraded access tokens later — which does work, and I’ve built out systems that do exactly that. XYZ can do that trick too.

1. Client: Start TX-1 (R-1, R-2)
2. User: Approve R-1, R-2
3. AS: Issue AT1 (R-1, R-2)
4. Client: Continue TX-1 (R-2)
5. AS: Issue AT-2 (R-2)

But we’ve got another thing we can use in XYZ to help this, the user handle. This lets a trusted client tell the AS that it believes the same user is still there and asking the question, so if the access rights are OK then you don’t need to involve the user again. We invented this construct with UMA2, where it’s called the persisted claims token (PCT).

1. Client: Start TX-1 (R-1)
2. User: Approve R-1
3. AS: Issue AT-1 (R-1), user handle U-1
4. Client Start TX-2 (R-2, U-1)
5. AS: Issue AT-2 (R-2)

Now: With the multi-token request, we can collapse this all back to a single transaction with multiple outputs:

1. Client: Start TX-2 (token1: R-1, token2: R-2)
2. User Approve R-1, R-2
3. AS: Issue AT-1 (token1: R-1), AT-2 (token2: R-2)

I haven’t liked any of the multi-access-token solutions to date because they make things weird for single access token requests. I like this idea because it’s an optimization for a complex case that doesn’t change the behavior for the simple case, and in fact doesn’t even change the expectations for the simple case. To me, that’s important.

 — Justin

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 17 Mar 2020 10:22:39 +0100

Hi Justin,

thanks for explaining the different options. I’m well aware of the super refresh token (and remember the discussions back then in Taipei :-)), I have implemented systems using this and other patterns, too.

The underlying assumption for most of those patterns is that the client upfront knows the boundaries between RS security domains, which typically means the solution is bespoken. 

TXAuth is chartered to develop a protocol and not a framework. What I’m looking for is interoperable protocol support for use of RS-specific self-contained access tokens in multi-RS deployments.

Why RS-specific self-contained access tokens? 
This is in my experience the most efficient way to empower high-volume/high-load services in a very efficient, secure, and privacy preserving fashion. 

- Every token contains exactly the data the RS needs to perform access control decisions locally. No need for further database lookups or AS callbacks, that’s really fast and keeps cost of the AS function low.
- The token itself can be encrypted to protect this data using a RS-specific key, one could even use HMACs to protect integrity and authenticity (fast as well). 
- The token can have a RS-specific lifetime.
- Since every token is restricted to a single RS audience, those tokens also have a baseline replay detection built-in. 

I think this pattern makes sense in environments with multiple RSs (e.g. different products) as well. But since every token is minted to the specific requirements of a certain RS, the AS must be able to mint different tokens. That doesn’t work properly without some support in the protocol.

Is there a need for multi access tokens support? 
Well, you implemented it, I implemented it, and I think a couple of other implementers did it with OAuth 2 in the past. So there seems to be some need. Why does the rest use the single token pattern? I think some deployments will indeed only have a single service, but I bet a lot of implementers did it because their product does not support anything else. 

I have experienced this myself when I designed the architecture of the yes ecosystem. It is a federation of authorization servers with associated services where every AS represents a certain bank. Since our partners shall be able to implement their AS using the product they like, I needed to go with the least common denominator - single access token. This has a significant consequences: our tokens are basically handles, so every service calls back to the AS to obtain its data for every service request. This degrades performance significantly and, since those tokens are good for multi audiences, it forces us to generally use sender constrained tokens, which increases complexity for clients. 

I would like to give implementers more options in the TXAuth space. That’s why I advocate to build-in support für multiple access tokens into TXAuth. 

My proposal is based on the following assumptions:
- Token format, content, encryption keys and so on are defined as part of the interface between AS and RS
- The client knows what it wants to do and where
- Every party contributes the information it has to the overall process to make it work simply and effectively for everyone. 

There is no change/addition needed to the request syntax. All it takes is your new multi token syntax (+ a small addition) in the response. 

The client uses the “resources" structure to communicate what (actions, further elements) it wants to do and where (locations).

[
    {
      “actions": ["read", "write"],
      "locations": ["https://example.com/resource"],
      “data": ["foo", "bar"]
    },
    {
      “actions": ["write"],
      "locations": ["https://other_example.com/resource"],
      “data": ["foo", "bar"]
    }
]

One deployment might use a single token for all RSs, in this case the token response remains unchanged: 

{
 "access_token":{
   "value":"08ur4kahfga09u23rnkjasdf",
   "type":"bearer"
 }
}

If the AS has the need to issue multiple access tokens, it could, for example, use the “locations" elements to determine what tokens it needs to create. Such an AS then uses the multiple_access_tokens structure augmented by corresponding "locations” entries in the token response: 

"multiple_access_tokens":{
   "token_a":{
     "value":"OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",
     "type":"bearer",
     "locations":[
       "https://example.com/resource"
     ]
   },
   "token_b":{
     "value":"UFGLO2FDAFG7VGZZPJ3IZEMN21EVU71FHCARP4J1",
     "type":"bearer",
     "locations":[
       "https://other_example.com/resource"
     ]
   }
 }

Since the client passed the locations values in the request, it is also able to determine where to use what access token. 

I think that’s pretty simple, especially from a client perspective.  

And If the client wants to split access tokens further apart, e.g. to obtain tokens with less privileges, it can do so using the request syntax you defined: 

resources: {
   token1: [{

In the simplest case, the AS would return the data as in your proposal.

If the client asks for a partitioning of privileges that goes across RS security domains like this

{
 "resources":{
   "token1":[
     {
       "actions":[ "read", "write","dolphin" ],
       "locations":[ "https://server.example.net/","https://resource.local/other"],
       "datatypes":[ "metadata","images"]
     },
     {
       "actions":["read","write"],
       "locations":["https://example.com/resource"]
     }
   ],
   "token2":[
     {
       "actions":["foo","bar", "dolphin"],
       "locations":["https://resource.other/"],
       "datatypes":["data","pictures"]
     }
   ]
 }
}

the AS would need to further partition the pre-defined tokens like this:

"multiple_access_tokens”:{
   “token1/a":{
     "value":"OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",
     "type":"bearer",
     "locations":["https://server.example.net/","https://resource.local/other"]
   },
   “token1/b":{
     "value":"OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",
     "type":"bearer",
     "locations":["https://example.com/resource"]
   },
   “token2":{
     "value":"UFGLO2FDAFG7VGZZPJ3IZEMN21EVU71FHCARP4J1",
     "type":"bearer",
     "locations":[
       "https://other_example.com/resource"
     ]
   }
 }

Naming of the tokens is a bit tricky but I think solvable.

What do you think?

best regards,
Torsten.

> On 15. Mar 2020, at 15:26, Justin Richer <[email-masked]> wrote:
>

---

From: Mike Jones <[email-masked]>
Date: Wed, 18 Mar 2020 22:03:47 +0000

I agree with many of Torsten's points below - particularly the need for supporting access tokens that are audienced to a particular resource.  That's one of the keys to preventing token replay.  This need came up when we thought that Token Binding was imminent and it is likewise probably needed for other kinds of PoP access tokens.

Another example with multiple resources:  If you're logging in and getting an access token for a UserInfo endpoint, you may also want an access token for another resource, that may be operated by a different party.  Those will have different audiences and different PoP bindings.

Finally, I agree with Torsten's point that the access tokens should be self-contained with everything that the resource needs.  For instance, no token introspection should be required (or even needed, in most cases).

				-- Mike

-----Original Message-----
From: Txauth <[email-masked]> On Behalf Of Torsten Lodderstedt
Sent: Tuesday, March 17, 2020 2:23 AM
To: Justin Richer <[email-masked]>
Cc: [email-masked]
Subject: [EXTERNAL] Re: [Txauth] Multiple Access Tokens in XYZ

Hi Justin,

[
    {

{
 "access_token":{

resources: {
   token1: [{

{
 "resources":{
   "token1":[
     {

What do you think?

best regards,
Torsten.

> 3. AS: Issue AT-1 (R-1), user handle U-1 4. Client Start TX-2 (R-2, 
> U-1) 5. AS: Issue AT-2 (R-2)
> 
> 1. Client: Start TX-2 (token1: R-1, token2: R-2) 2. User Approve R-1, 
> R-2 3. AS: Issue AT-1 (token1: R-1), AT-2 (token2: R-2)
>

---

From: Justin Richer <[email-masked]>
Date: Thu, 19 Mar 2020 09:37:36 -0400

> - The client knows what it wants to do and where

That’s knowledge is exactly why I would argue that the client would have to explicitly request multiple access tokens in order to get them. 

I’m worried about requiring all clients to be prepared to accept multiple access tokens. In a lot of big cloud deployments, it’s absolutely based on location. But that’s not the only dispatch for security domains. A client would need to know, ultimately, what a token is for and where to use it. And we’d also need to deal with cases that allow for subdomains, paths, query parameters, and other variability of an API’s URLs. After all, I’m probably going to send that same token to a bunch of different URLs in order to do a bunch of different things, even if they’re all within the same “RS” or “domain” or whatever. Which brings us to an underlying problem — I don’t think there’s a good way to reference the identity of an RS. Solid is attempting to do that using WebID’s as service identifiers, and while that’s interesting, it’s deeply tied to their system where everything knows what a WebID is and what to do with it. I think it’s a bad idea to depend on that kind of thing for a general purpose system. 

I’m hesitant to have clients depend on being told that information. I think if we go down that route we’re going to have to also tell clients things like “this is only good for GET requests” and “this is good for subdomains on this location” and “this can be used for anything except this one exception”. And it doesn’t fit well when you’re trying to mix two different APIs that have really different structures. Things like GraphQL and REST lead to pretty different URL designs, and TxAuth should be usable for all of that. It feels like too much automated configuration of a client instead of the client just “doing something”, which I think is going to be the common case. In other words, I do think that the client software is going to be bespoke for the API that it’s calling. However, the security library that speaks the TxAuth piece doesn’t have to be, and the protocol itself doesn’t need to be. But the protocols should allow the client software to express to the security layer what it knows about the API.

And speaking of common cases, I think it’s actually much more rare to have multiple security domains covered by an AS in a way that would need multiple encryptions or targets. I think many of us see it because we work with large enterprise-scale systems with multiple domains that we want to manage all at once. In my experience, it’s much more common to have a client talk to one AS to get one token for one RS. One of my goals with this is to not make it complicated for simple clients, and I think having to be prepared to get multiple access tokens is too complex for simple clients. I might be wrong, but it’s based on my experience across a lot of different kinds of APIs. The idea of splitting up tokens like below feels REALLY complex, especially when I asked for a single one. I get why you want to do it, it makes sense for the AS to be able to do something like that, but from a client’s perspective it’s a lot more complicated without a clear idea of what the identity of an RS is. I think solving that problem is a HUGE issue that we should put firmly out of scope.

The thing is, though, you’re absolutely right that there’s a need for this kind of multiple tokens. So in my view, the lift of having a client know about the domains that it’s calling is a lot less than the client having to potentially deal with more tokens than it asked for, and knowing how to correctly dispatch those. Also the semantics of what the “resources” object represents changes, since I could potentially be getting two tokens back that do parts of the one thing that I asked for, and the client now needs to know which to use for what. If the client has to name the splits itself, that implies the client knows what each “resources” sub-object represents and knows how to apply that to its “call the API” code. The security layer doesn’t know or care, but the code that knows how to manipulate the API and its data knows and cares.

As for the token content — that’s solidly an implementation decision and orthogonal to this discussion. You can do all of this multi access token stuff with introspection and reference-based tokens. Access tokens themselves need to stay opaque to the client and to the protocol at large. I don’t believe that’s up for debate.

Thanks so much for pushing this conversation, and now I’m more convinced than ever that handling multiple tokens in the response is something we need to figure out within this group. 

 — Justin

> On Mar 17, 2020, at 5:22 AM, Torsten Lodderstedt <[email-masked]> wrote:
> 
> Hi Justin,
>

---

From: Justin Richer <[email-masked]>
Date: Fri, 20 Mar 2020 10:58:16 -0400

So fundamentally, I don’t want the AS to allowed to split tokens when the client isn’t expecting it. Would a simple feature flag to allow that behavior at the AS be enough to switch both cases? 

So let’s say we  just do the simple thing and make it a boolean top-level flag. If the client sends “split_tokens: true” then the AS always returns the “multiple_access_tokens” structure and it comes up with whatever names it makes sense for the resulting tokens. The client can do either the single or multiple token request style. The client needs to be able to figure out from the token responses how to put which token in which place, and I think we can do some things with the guts of the “resources” request object, like using “locations” and maybe other fields. If the client doesn’t send “split_tokens: true” then the AS sends a single token for a single token request, and multiple tokens for a multiple token request, exactly mapped to what the client requested in each resources block. If the client asks for resources that cross domains in a way that AS can’t support, it returns an error.

The syntax needs work, but it would at least allow both modes of operation. And it collapses nicely into the single-token use case, which is one of my goals here. I don’t want a client to ask for 1 token and get 2 or ask for 2 tokens and get 3, unless it’s fully prepared for that.

Would something like that fly for you?

 — Justin

> On Mar 19, 2020, at 9:37 AM, Justin Richer <[email-masked]> wrote:
>

---

From: Dick Hardt <[email-masked]>
Date: Fri, 20 Mar 2020 11:36:18 -0700

I agree with Justin that the Client unexpectedly getting split access
tokens is undesirable.

I agree with Mike and Torsten that tokens should be self contained, and
able to be independent between resources. I would add that they should be
as fine grained as practical, which is part of the charter.

Rather then the client thinking it is getting multiple access tokens, how
about thinking of the client getting access to multiple resources?

The AS provides an access token for each resource. The access tokens may
all be the same, all be different, or a mix.

The Client does not need to know which ones are the same or different ahead
of time, but it does know which one it will use for accessing which
resource.

I don't think there is a need for a "split_tokens" flag. That sounds overly
complicated.

On Fri, Mar 20, 2020 at 7:59 AM Justin Richer <[email-masked]> wrote:

> So fundamentally, I don’t want the AS to allowed to split tokens when the
> client isn’t expecting it. Would a simple feature flag to allow that
> behavior at the AS be enough to switch both cases?
>
> So let’s say we  just do the simple thing and make it a boolean top-level
> flag. If the client sends “split_tokens: true” then the AS always returns
> the “multiple_access_tokens” structure and it comes up with whatever names
> it makes sense for the resulting tokens. The client can do either the
> single or multiple token request style. The client needs to be able to
> figure out from the token responses how to put which token in which place,
> and I think we can do some things with the guts of the “resources” request
> object, like using “locations” and maybe other fields. If the client
> doesn’t send “split_tokens: true” then the AS sends a single token for a
> single token request, and multiple tokens for a multiple token request,
> exactly mapped to what the client requested in each resources block. If the
> client asks for resources that cross domains in a way that AS can’t
> support, it returns an error.
>
> The syntax needs work, but it would at least allow both modes of
> operation. And it collapses nicely into the single-token use case, which is
> one of my goals here. I don’t want a client to ask for 1 token and get 2 or
> ask for 2 tokens and get 3, unless it’s fully prepared for that.
>
> > That’s knowledge is exactly why I would argue that the client would have
> to explicitly request multiple access tokens in order to get them.
> >
> > I’m worried about requiring all clients to be prepared to accept
> multiple access tokens. In a lot of big cloud deployments, it’s absolutely
> based on location. But that’s not the only dispatch for security domains. A
> client would need to know, ultimately, what a token is for and where to use
> it. And we’d also need to deal with cases that allow for subdomains, paths,
> query parameters, and other variability of an API’s URLs. After all, I’m
> probably going to send that same token to a bunch of different URLs in
> order to do a bunch of different things, even if they’re all within the
> same “RS” or “domain” or whatever. Which brings us to an underlying problem
> — I don’t think there’s a good way to reference the identity of an RS.
> Solid is attempting to do that using WebID’s as service identifiers, and
> while that’s interesting, it’s deeply tied to their system where everything
> knows what a WebID is and what to do with it. I think it’s a bad idea to
> depend on that kind of thing for a general purpose system.
> >
> > I’m hesitant to have clients depend on being told that information. I
> think if we go down that route we’re going to have to also tell clients
> things like “this is only good for GET requests” and “this is good for
> subdomains on this location” and “this can be used for anything except this
> one exception”. And it doesn’t fit well when you’re trying to mix two
> different APIs that have really different structures. Things like GraphQL
> and REST lead to pretty different URL designs, and TxAuth should be usable
> for all of that. It feels like too much automated configuration of a client
> instead of the client just “doing something”, which I think is going to be
> the common case. In other words, I do think that the client software is
> going to be bespoke for the API that it’s calling. However, the security
> library that speaks the TxAuth piece doesn’t have to be, and the protocol
> itself doesn’t need to be. But the protocols should allow the client
> software to express to the security layer what it knows about the API.
> >
> > And speaking of common cases, I think it’s actually much more rare to
> have multiple security domains covered by an AS in a way that would need
> multiple encryptions or targets. I think many of us see it because we work
> with large enterprise-scale systems with multiple domains that we want to
> manage all at once. In my experience, it’s much more common to have a
> client talk to one AS to get one token for one RS. One of my goals with
> this is to not make it complicated for simple clients, and I think having
> to be prepared to get multiple access tokens is too complex for simple
> clients. I might be wrong, but it’s based on my experience across a lot of
> different kinds of APIs. The idea of splitting up tokens like below feels
> REALLY complex, especially when I asked for a single one. I get why you
> want to do it, it makes sense for the AS to be able to do something like
> that, but from a client’s perspective it’s a lot more complicated without a
> clear idea of what the identity of an RS is. I think solving that problem
> is a HUGE issue that we should put firmly out of scope.
> >
> > The thing is, though, you’re absolutely right that there’s a need for
> this kind of multiple tokens. So in my view, the lift of having a client
> know about the domains that it’s calling is a lot less than the client
> having to potentially deal with more tokens than it asked for, and knowing
> how to correctly dispatch those. Also the semantics of what the “resources”
> object represents changes, since I could potentially be getting two tokens
> back that do parts of the one thing that I asked for, and the client now
> needs to know which to use for what. If the client has to name the splits
> itself, that implies the client knows what each “resources” sub-object
> represents and knows how to apply that to its “call the API” code. The
> security layer doesn’t know or care, but the code that knows how to
> manipulate the API and its data knows and cares.
> >
> > As for the token content — that’s solidly an implementation decision and
> orthogonal to this discussion. You can do all of this multi access token
> stuff with introspection and reference-based tokens. Access tokens
> themselves need to stay opaque to the client and to the protocol at large.
> I don’t believe that’s up for debate.
> >
> > Thanks so much for pushing this conversation, and now I’m more convinced
> than ever that handling multiple tokens in the response is something we
> need to figure out within this group.
> >
> > — Justin
> >
> >> thanks for explaining the different options. I’m well aware of the
> super refresh token (and remember the discussions back then in Taipei :-)),
> I have implemented systems using this and other patterns, too.
> >>
> >> The underlying assumption for most of those patterns is that the client
> upfront knows the boundaries between RS security domains, which typically
> means the solution is bespoken.
> >>
> >> TXAuth is chartered to develop a protocol and not a framework. What I’m
> looking for is interoperable protocol support for use of RS-specific
> self-contained access tokens in multi-RS deployments.
> >>
> >> This is in my experience the most efficient way to empower
> high-volume/high-load services in a very efficient, secure, and privacy
> preserving fashion.
> >>
> >> - Every token contains exactly the data the RS needs to perform access
> control decisions locally. No need for further database lookups or AS
> callbacks, that’s really fast and keeps cost of the AS function low.
> >> - The token itself can be encrypted to protect this data using a
> RS-specific key, one could even use HMACs to protect integrity and
> authenticity (fast as well).
> >> - Since every token is restricted to a single RS audience, those tokens
> also have a baseline replay detection built-in.
> >>
> >> I think this pattern makes sense in environments with multiple RSs
> (e.g. different products) as well. But since every token is minted to the
> specific requirements of a certain RS, the AS must be able to mint
> different tokens. That doesn’t work properly without some support in the
> protocol.
> >>
> >> Well, you implemented it, I implemented it, and I think a couple of
> other implementers did it with OAuth 2 in the past. So there seems to be
> some need. Why does the rest use the single token pattern? I think some
> deployments will indeed only have a single service, but I bet a lot of
> implementers did it because their product does not support anything else.
> >>
> >> I have experienced this myself when I designed the architecture of the
> yes ecosystem. It is a federation of authorization servers with associated
> services where every AS represents a certain bank. Since our partners shall
> be able to implement their AS using the product they like, I needed to go
> with the least common denominator - single access token. This has a
> significant consequences: our tokens are basically handles, so every
> service calls back to the AS to obtain its data for every service request.
> This degrades performance significantly and, since those tokens are good
> for multi audiences, it forces us to generally use sender constrained
> tokens, which increases complexity for clients.
> >>
> >> I would like to give implementers more options in the TXAuth space.
> That’s why I advocate to build-in support für multiple access tokens into
> TXAuth.
> >>
> >> - Every party contributes the information it has to the overall process
> to make it work simply and effectively for everyone.
> >>
> >> There is no change/addition needed to the request syntax. All it takes
> is your new multi token syntax (+ a small addition) in the response.
> >>
> >> The client uses the “resources" structure to communicate what (actions,
> further elements) it wants to do and where (locations).
> >>
> >> [
> >>   {
> >> If the AS has the need to issue multiple access tokens, it could, for
> example, use the “locations" elements to determine what tokens it needs to
> create. Such an AS then uses the multiple_access_tokens structure augmented
> by corresponding "locations” entries in the token response:
> >>
> >> Since the client passed the locations values in the request, it is also
> able to determine where to use what access token.
> >>
> >> And If the client wants to split access tokens further apart, e.g. to
> obtain tokens with less privileges, it can do so using the request syntax
> you defined:
> >>
> >> resources: {
> >>  token1: [{
> >>>>> So if the AS needs a client to get different access tokens to call
> different RS domains, it does exactly what we do in OAuth 2 today — it
> tells the client to get two different access tokens.
> >>>>
> >>> Without using the multi-access-token thing I’m proposing in this
> thread, the client would just make two separate transaction calls to get
> two different tokens. There’s a few ways that shakes out depending on some
> of the details. In the OAuth world that amounts to involving the user
> twice, and it might be the same in XYZ if you’re asking for different
> things:
> >>>
> >>> Unless you’re getting a super refresh token upfront and then calling
> for two downgraded access tokens later — which does work, and I’ve built
> out systems that do exactly that. XYZ can do that trick too.
> >>>
> >>> But we’ve got another thing we can use in XYZ to help this, the user
> handle. This lets a trusted client tell the AS that it believes the same
> user is still there and asking the question, so if the access rights are OK
> then you don’t need to involve the user again. We invented this construct
> with UMA2, where it’s called the persisted claims token (PCT).
> >>>
> >>> Now: With the multi-token request, we can collapse this all back to a
> single transaction with multiple outputs:
> >>>
> >>> I haven’t liked any of the multi-access-token solutions to date
> because they make things weird for single access token requests. I like
> this idea because it’s an optimization for a complex case that doesn’t
> change the behavior for the simple case, and in fact doesn’t even change
> the expectations for the simple case. To me, that’s important.
> >>>
> >>> — Justin
> >>
> >
> > --
> > Txauth mailing list
> > [email-masked]

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Fri, 20 Mar 2020 20:42:54 +0000

I am also opposed to requiring Clients to support arbitrarily split access tokens. If we are to support multiple access tokens, we need to do so in a way that does not adversely impact the many deployments for which they are an unnecessary complication. Seconding Dick’s comment that “split_tokens” is overly complex. It feels to me like the sort of option that would hurt interoperability in the long run.

I want to make sure we are not positioning multiple access tokens as a necessary requirement for ASes that support multiple RSes. There are other ways to do that, each with different pros and cons that can’t be properly evaluated outside the context of an actual protocol, and even then different deployments may weigh those pros and cons differently.

Similarly, we should not be constraining how ASes and RSes share information. Again, different deployments will call for different approaches. I do like Justin’s suggestion (perhaps on another thread?) of standardizing a schema that token claims, API results, etc. could adhere to.

–
Annabelle Backman (she/her)
AWS Identity
https://aws.amazon.com/identity/

From: Txauth <[email-masked]> on behalf of Dick Hardt <[email-masked]>
Date: Friday, March 20, 2020 at 11:37 AM
To: Justin Richer <[email-masked]>
Cc: Torsten Lodderstedt <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [EXTERNAL] [Txauth] Multiple Access Tokens in XYZ

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.

I agree with Justin that the Client unexpectedly getting split access tokens is undesirable.

I agree with Mike and Torsten that tokens should be self contained, and able to be independent between resources. I would add that they should be as fine grained as practical, which is part of the charter.

Rather then the client thinking it is getting multiple access tokens, how about thinking of the client getting access to multiple resources?

The AS provides an access token for each resource. The access tokens may all be the same, all be different, or a mix.

The Client does not need to know which ones are the same or different ahead of time, but it does know which one it will use for accessing which resource.

I don't think there is a need for a "split_tokens" flag. That sounds overly complicated.

On Fri, Mar 20, 2020 at 7:59 AM Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:
So fundamentally, I don’t want the AS to allowed to split tokens when the client isn’t expecting it. Would a simple feature flag to allow that behavior at the AS be enough to switch both cases?

 — Justin

> On Mar 19, 2020, at 9:37 AM, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:
>
>> On Mar 17, 2020, at 5:22 AM, Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> Hi Justin,
>>
>> - Every token contains exactly the data the RS needs to perform access control decisions locally. No need for further database lookups or AS callbacks, that’s really fast and keeps cost of the AS function low..
>> I would like to give implementers more options in the TXAuth space.. That’s why I advocate to build-in support für multiple access tokens into TXAuth.
>>
>>          locations: ["https://resource..other/<https://resource.other/>"],
>>      "locations":[ "https://server..example.net/<https://server.example.net/>","https://resource.local/other"],
>>    "locations":["https://server.example..net/<https://server.example.net/>","https://resource.local/other"]
>>  },
>>  “token1/b":{
>>> On 15. Mar 2020, at 15:26, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:
>>>
>>> On Mar 15, 2020, at 8:58 AM, Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>> wrote:
>>>>
>>>>> On 15. Mar 2020, at 03:25, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:
>>>>>
> [email-masked]<mailto:[email-masked]>

--
Txauth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/txauth

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 21 Mar 2020 13:46:48 +0100

> On 20. Mar 2020, at 21:42, Richard Backman, Annabelle <[email-masked]> wrote:
> 

I did not propose to make support for RS-specific access tokens a requirement for ASs, I suggested to give ASs this additional option and make that a first class citizen in the protocol. Otherwise, the “one access tokens is sufficient” statement will be a self fulfilling prophecy and will force deployments with requirements that cannot be fulfilled using single token + token introspection to go proprietary. 

>  
> Similarly, we should not be constraining how ASes and RSes share information.

The proposal is to consider this interface as it is more or less completely undefined in OAuth 2 and the current TXAuth charter. This causes lot of misconceptions and functional gaps/differences in products/libraries. I think we are able, in the same as for client, to define rails to foster interoperability while allowing for a broad range of implementation options.

> Again, different deployments will call for different approaches.

I think we should discuss exactly this different approaches (experiences) to get a sense of the size of the playing field. 

> I do like Justin’s suggestion (perhaps on another thread?) of standardizing a schema that token claims, API results, etc. could adhere to.
>  

That might be a result, I personally like Nat’s idea of writing up an architecture document first. I think the WG (and implementers) would benefit from some documented architectural assumptions. 

>> >>          locations: ["https://resource..other/"],
>> >>      "locations":[ "https://server..example.net/","https://resource.local/other"],
>> >>    "locations":["https://server.example..net/","https://resource.local/other"]
>> >>  },
>> >>  “token1/b":{

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 22 Mar 2020 10:05:03 +0100

> Am 20.03.2020 um 15:58 schrieb Justin Richer <[email-masked]>:
> 

If I understand you correctly, the addition to my proposal is to let the client indicate whether it supports multiple tokens, so the AS will respond with an error if it would need to issue multiple tokens but the client is not prepared to process multiple tokens?

I would say let’s start with it and gather implementation experience. We at yes.com would to implement a prototype for the multi RS scenario.

---

From: Justin Richer <[email-masked]>
Date: Sun, 22 Mar 2020 08:49:59 -0400

Not just multiple tokens — but specifically “more tokens than I explicitly asked for”. I think the path for a client asking for one token and getting one token is clear, as is the path for a client asking for 3 tokens and getting 3 tokens. In each case, using the syntax I proposed, the client can directly map one “resources” block (array of objects/references) to a single, specific token. But a client asking for 1 token and getting 3, a client asking for 2 tokens and getting 5, etc, is where the client-side confusion lies. As soon as you do that, you need to provide information to the client about where and how each individual token is to be used since it can’t rely on mapping it directly to a specific portion of its request. And you’ll need that if the AS is allowed to determine that a client’s request needs to be split across multiple RS’s if the client didn’t do the splitting itself. I don’t think every deployment can rely on the URL being the appropriate director for this kind of split — it’s something, and I get that it works for you, but it’s not universal enough to build the token dispatch on. I get that it works for your system, and it probably is “good enough” for a lot of systems, but I’m just not convinced that’s the only dimension that we’ll see this kind of thing in.

I am not particularly fond of a flag to solve this. It is complex, it’s a hack at best, and we shouldn’t keep it like that; but I think implementing something like this can give us some idea of what the boundaries really are on the different use cases. Basically, it’s a patch that can let us build out two different modes in the same systems without them getting wrapped up in each other so that we can see where the overlaps and differences really are on a real system. When we can figure out what these changes really look like, then we can figure out what this more advanced token-splitting is and how it can fit in the overall TxAuth protocol. Maybe it’d be something in an XYZ “capabilities” list instead? 

I also think that this is going to drive an essential conversation about how we identify an RS within this protocol. OAuth 2 has struggled with identifying components its entire lifetime. The “client_id” is almost meaningless in a  world where the ID could mean it's is shared between millions of instances of a mobile app, or re-used in ephemeral copies of an SPA, or a locked down high security web service on a single machine. I think we need to re-examine all of these components, and identifying the RS should be a part of that. Do I think we should have a “resource_id”? Not really — in XYZ, I got rid of “client_id” for the reasons above (and it’s not actually needed within the protocol anymore), but I’m not sure what the answer is.

 — Justin

> On Mar 22, 2020, at 5:05 AM, Torsten Lodderstedt <[email-masked]> wrote:
> 
> 
>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Mon, 23 Mar 2020 23:38:13 +0000

> On 3/21/20, 5:47 AM, "Torsten Lodderstedt" <[email-masked]> wrote:
>

I said I am against making this a requirement for Clients, not ASes. I am fully on board with supporting multiple access tokens, but if an AS can arbitrarily decide to split the grant into more tokens than the Client requested, then both multiple tokens and arbitrary token splitting become MTI for any Client that isn't coupled to a specific set of ASes that the Client can trust not to split tokens. Multiple token support on its own adds complexity for the Client; arbitrary token support even more so.

> The proposal is to consider this interface as it is more or less completely undefined in OAuth 2 and the current TXAuth charter. This causes lot of misconceptions and functional gaps/differences in…

My comment is a response to your statement that you want "interoperable protocol support for use of RS-specific self-contained access tokens in multi-RS deployments," and Mike's subsequent statement that he agrees "with Torsten's point that the access tokens should be self-contained with everything that the resource needs." I would support defining an optional AS/RS interface provided that it is not MTI, and that protocol features like multi-RS or multiple token support do not require it.

> That might be a result, I personally like Nat’s idea of writing up an architecture document first. I think the WG (and implementers) would benefit from some documented architectural assumptions.

Agreed.
 
–