Subject: [OAUTH-WG] Transaction Authorization

From: Justin Richer <[email-masked]>
Date: Tue, 9 Jul 2019 19:47:46 +0000

I have requested time to present Transactional Authorization (the XYZ project) at the Montreal meeting in a couple weeks. Ahead of that, I’ve uploaded a new version of the spec:

https://tools.ietf.org/html/draft-richer-transactional-authz-02

Additionally, I’ve updated the writeup and examples on https://oauth.xyz/

I plan to be in Montreal for the whole week, and I’ve requested from the chairs that I present during the Tuesday session due to limited availability of some key WG members on Friday.

— Justin

---

From: Aaron Parecki <[email-masked]>
Date: Fri, 19 Jul 2019 19:02:49 -0500

Hi all, I'm looking forward to the discussion on this on Tuesday!

I wanted to add my thoughts on a potential addition to this draft,
specifically around returning some minimal user information in the
transaction response.

The summary of the suggestion is to return a new "user" key along with the
access token that contains the user ID and userinfo endpoint, such as:

    {
      "access_token": {
        "value": "UM1P9PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",
        "type": "bearer"
      },
      "user": {
        "id": "5035678642",
        "userinfo": "https://authorization-server.com/user/5035678642"
      }
    }

A more detailed analysis of the specific proposal and motivation behind
this is available on my blog:

https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz

Thanks!

----
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>

On Tue, Jul 9, 2019 at 2:48 PM Justin Richer <[email-masked]> wrote:

> I have requested time to present Transactional Authorization (the XYZ
> project) at the Montreal meeting in a couple weeks. Ahead of that, I’ve
> uploaded a new version of the spec:
>
> I plan to be in Montreal for the whole week, and I’ve requested from the
> chairs that I present during the Tuesday session due to limited
> availability of some key WG members on Friday.
>
> — Justin
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Neil Madden <[email-masked]>
Date: Sat, 20 Jul 2019 07:41:46 +0100

If we’re going to redesign OAuth, one improvement would be to allow a client to request different access tokens for different resource servers in a single request. That should include issuing a different access token for the userinfo endpoint vs other RSes. 

One of the weaknesses of combined OAuth + OIDC use now is that if you request OIDC scopes and scopes for another resource in the same request then you inadvertently give those other RSes access to the user’s profile. 

— Neil

> On 20 Jul 2019, at 01:02, Aaron Parecki <[email-masked]> wrote:
> 
> I wanted to add my thoughts on a potential addition to this draft, specifically around returning some minimal user information in the transaction response.
> 
> The summary of the suggestion is to return a new "user" key along with the access token that contains the user ID and userinfo endpoint, such as:
> 
>     {
>       "access_token": {
> A more detailed analysis of the specific proposal and motivation behind this is available on my blog:
> 
> @aaronpk

---

From: Dick Hardt <[email-masked]>
Date: Sun, 21 Jul 2019 14:22:19 -0700

Hi Neil, I agree that an access token that is usable across resources is
problematic.

How are you thinking multiple access tokens would be returned?

Why do you think the request needs to return multiple tokens rather than
making a separate request for each token? That would seem to simplify the
request and response as context would only need to provided for the one
access token.

On Fri, Jul 19, 2019 at 11:42 PM Neil Madden <[email-masked]>
wrote:

> If we’re going to redesign OAuth, one improvement would be to allow a
> client to request different access tokens for different resource servers in
> a single request. That should include issuing a different access token for
> the userinfo endpoint vs other RSes.
>
> One of the weaknesses of combined OAuth + OIDC use now is that if you
> request OIDC scopes and scopes for another resource in the same request
> then you inadvertently give those other RSes access to the user’s profile.
>
> — Neil
>

---

From: Dick Hardt <[email-masked]>
Date: Sun, 21 Jul 2019 14:27:46 -0700

Hey Justin

A few use cases that highlight how the world is different now than it was
when OAuth 2.0 was developed would help participants understand why changes
are needed, and also provide a reference for comparing and contrasting
different approaches.

One of my first comments is why the client is starting off making calls to
the AS. There are times when the AS is not known for a given resource. Why
not allow starting at resource?

---

From: Neil Madden <[email-masked]>
Date: Mon, 22 Jul 2019 14:41:41 +0100

> On 21 Jul 2019, at 22:22, Dick Hardt <[email-masked]> wrote:
> 
> Hi Neil, I agree that an access token that is usable across resources is problematic.
> 

Well there are lots of possible ways, e.g.:

{
"tokens": [
    { "resource": "https://res1", "access_token": "..." }, 
    { "resource": "res2", ...}, ...
]
}

I'm not particularly wedded to any format.

> Why do you think the request needs to return multiple tokens rather than making a separate request for each token? That would seem to simplify the request and response as context would only need to provided for the one access token.

Note that in Aaron's proposal we have a "user" section on (presumably) every access token response, which indicates a userinfo endpoint that itself needs an access token. So either the same access token is used to access that userinfo endpoint (which means that the RS can also access the userinfo endpoint), or else we already need to return a second access token in the same request, e.g.:

{
      "access_token": {
        "value": "UM1P9PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",
        "type": "bearer"
      },
      "user": {
        "id": "5035678642",
        "userinfo": "https://authorization-server.com/user/5035678642 <https://authorization-server.com/user/5035678642>",
        "userinfo_at": "b0Dl3KsXXOGc7tWfFLZYv7G5bXk"
      }
    }

> 
> 
> 
> On Fri, Jul 19, 2019 at 11:42 PM Neil Madden <[email-masked] <mailto:[email-masked]>> wrote:
> On 20 Jul 2019, at 01:02, Aaron Parecki <[email-masked] <mailto:[email-masked]>> wrote:
> 
>>         "userinfo": "https://authorization-server.com/user/5035678642 <https://authorization-server.com/user/5035678642>"
>>       }
>>     }
>> 
>> https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz <https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz>
>> 
>> Thanks!
>> 
>> ----
>> Aaron Parecki
>> aaronparecki.com <http://aaronparecki.com/>
>> On Tue, Jul 9, 2019 at 2:48 PM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>> https://tools.ietf.org/html/draft-richer-transactional-authz-02 <https://tools.ietf.org/html/draft-richer-transactional-authz-02>
>> 
>> Additionally, I’ve updated the writeup and examples on https://oauth.xyz/ <https://oauth.xyz/> 
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

---

From: Nat Sakimura <[email-masked]>
Date: Mon, 22 Jul 2019 12:21:37 -0400

+1

Also, if it were to include user identification in the protocol, I
would like to have the spec at least cover the following:

0. User
1. External Identity Provider
2. Resources that covers the functionality of PEP.
3. Authorization Server that act as PDP for  Resources.
4. Internal Identity Server within the resource domain.
5. Client APP component
6. Client Server component

In addition, it would be good to delineate the resource owner (an
entity that has administrative rights over the set of resources) and
the end user who is in the protocol flow.

That actually asks for the following additional entities:

7. Resource Administrator
8. PAP/PIP

It is probably a good idea to state the security target as well.

Re: Starting from Resource.

Yes. I agree that this is a valid use case. At the same time, there
can be cases where the concrete resource endpoint is not known before
the user authorization. So, the protocol needs to be able to start
both ways, I guess.

Cheers,

Nat Sakimura

On Sun, Jul 21, 2019 at 5:28 PM Dick Hardt <[email-masked]> wrote:
>
> Hey Justin
>
> A few use cases that highlight how the world is different now than it was when OAuth 2.0 was developed would help participants understand why changes are needed, and also provide a reference for comparing and contrasting different approaches.
>
> One of my first comments is why the client is starting off making calls to the AS. There are times when the AS is not known for a given resource. Why not allow starting at resource?
>
>

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: Dick Hardt <[email-masked]>
Date: Mon, 22 Jul 2019 17:46:19 -0400

Hi Neil

I see that you are looking at how to modify Justin's proposal, and I'm
looking at what are the requirements.

Ignoring the specifics, is there a reason why multiple tokens need to be
returned in the same request?

On Mon, Jul 22, 2019 at 9:41 AM Neil Madden <[email-masked]>
wrote:

> Note that in Aaron's proposal we have a "user" section on (presumably)
> every access token response, which indicates a userinfo endpoint that
> itself needs an access token. So either the same access token is used to
> access that userinfo endpoint (which means that the RS can also access the
> userinfo endpoint), or else we already need to return a second access token
> in the same request, e.g.:
>
> {
>       "access_token": {
>         "userinfo": "https://authorization-server.com/user/5035678642",
>> The summary of the suggestion is to return a new "user" key along with
>> the access token that contains the user ID and userinfo endpoint, such as:
>>
>>     {
>>       "access_token": {

---

From: Neil Madden <[email-masked]>
Date: Tue, 23 Jul 2019 11:10:11 +0100

If we follow the principle of least authority then a token should be scoped as narrowly as possible to a particular resource server/resource/time period/transaction. The security topics BCP has already gone quite far down this path in its recommendations: https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-3.3 . Least privilege naturally leads to clients needing more tokens, so we should make obtaining (and using) multiple tokens as frictionless as possible.

For an example of this, see the work done by my colleagues to simplify juggling multiple access tokens for different resource servers - https://www.npmjs.com/package/appauthhelper . The library allows the developer to specify which scopes are used for which RS:

    resourceServers: {
        "https://login.example.com/oauth2/userinfo": "profile",
        "https://rs.example.com/": "rs_custom_scope"
    },

The library then takes care of making multiple requests to get appropriately-scoped access tokens and then attaching them to appropriate requests. But the more resource servers you need to access, the more tokens you need and the more requests you have to make. There is therefore currently a "tax" on least privilege use of access tokens as it is all on the client to juggle these requests, giving an incentive for clients to instead request Big Tokens that grant lots of authority in a single request/response.

-- Neil

> On 22 Jul 2019, at 22:46, Dick Hardt <[email-masked]> wrote:
> 
> Hi Neil
> 
> I see that you are looking at how to modify Justin's proposal, and I'm looking at what are the requirements.
> 
> Ignoring the specifics, is there a reason why multiple tokens need to be returned in the same request?
> 
> 
> On Mon, Jul 22, 2019 at 9:41 AM Neil Madden <[email-masked]> wrote:
>

---

From: Justin Richer <[email-masked]>
Date: Wed, 24 Jul 2019 13:20:18 +0000

I agree that we need to expound on the new use cases that this approach enables, and I’ll send them out here and add them to the site as I get them written down.

To your specific idea: My thinking here was that we can leverage the transaction model to make this work in a consistent fashion. This is noted in the spec and website, but to expand here:

1) Client goes to the RS and tries a request, with no token or with insufficient token.
2) RS goes to the AS and says “hey someone wants a thing but can’t get it, here’s a resource object that describes what would be sufficient access to make that work” .. this request has some signal in it that tells the AS that it’s not a client asking for a token, maybe set the “client” field to “false” or something? I’m not sure how best to signal that yet.
3) AS returns a resource_handle for the requested resource set. This can be random and dynamically generated, doesn’t have to be human readable.
4) RS returns the resource handle and a pointer to the AS’s transaction endpoint to the client in a WWW-Authenticate response header that we’d define, but would look suspiciously like UMA2’s response header with similar information.
5) Client makes its normal XYZ request to the AS but includes the resource_handle it got back from (4).

— Justin

On Jul 21, 2019, at 5:27 PM, Dick Hardt <[email-masked]<mailto:[email-masked]>> wrote:

Hey Justin

On Tue, Jul 9, 2019 at 12:48 PM Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:
I have requested time to present Transactional Authorization (the XYZ project) at the Montreal meeting in a couple weeks. Ahead of that, I’ve uploaded a new version of the spec:

— Justin

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Justin Richer <[email-masked]>
Date: Wed, 24 Jul 2019 13:45:30 +0000

I get the desire to have multiple tokens, but the real cost is the explosion in complexity for every party in the system. This is especially true if you allow the client to specify a more fine-grained and structured resource target than a scope string, but even with a scope it’s really common to have a set of different resource servers that respond to the same scope. The biggest burden is on the client which now has to map different access tokens from the same request to different resource targets, some of which it might be discovering at runtime. And then you have to figure out what to do at the AS if the user only approves one resource, or even worse, one scope that covers multiple resources. You need to have very clear logic of how you separate these into different access tokens, and how you signal that to the client. And then there’s the question of refreshing things once tokens expire (because of course they could have different lifetimes) — in OAuth that implies multiple refresh tokens, in XYZ that implies multiple transaction handles. I’m not sure this complexity in the general case is worth it to solve this specific issue, which seems like a bit of an edge condition to me. I really don’t think we should make simple clients pay this complexity cost if they don’t have to.

XYZ does make asking for several different access tokens in multiple requests potentially easier through use of the “user_handle” construct (imported from the PCT concept in UMA2). This lets you say that you as the client are saying it’s the same user and the same client for a different resource set, and that might be enough for the AS to just let you have a token with the first call to it and not have to get the user involved again. But this doesn’t really help if you need to ask the user consent a bunch of times, which seems to be what people are really after solving when they talk about getting multiple access tokens. The problem isn’t asking the AS, the problem is asking the user, and we’d really like to bother them once and only once.

So maybe the question isn’t so much about multiple access tokens, but actually about multiple simultaneous transactions in a single request. Because if you’re doing that, you have a kind of natural separation between the requests (each would get its own transaction keys and tokens), but you could combine the interaction portion when it’s needed and only bother the user once for multiple things.

— Justin

On Jul 23, 2019, at 6:10 AM, Neil Madden <[email-masked]<mailto:[email-masked]>> wrote:

   resourceServers: {

-- Neil

On 22 Jul 2019, at 22:46, Dick Hardt <[email-masked]<mailto:[email-masked]>> wrote:

Hi Neil

On Mon, Jul 22, 2019 at 9:41 AM Neil Madden <[email-masked]<mailto:[email-masked]>> wrote:

On 21 Jul 2019, at 22:22, Dick Hardt <[email-masked]<mailto:[email-masked]>> wrote:

{
"tokens": [

{
     "access_token": {

---

From: Justin Richer <[email-masked]>
Date: Wed, 24 Jul 2019 14:12:12 +0000

I’m definitely in favor of separating the “person using the client software” from the “person making the authorization decision” and allowing them to be the same person without changing the protocol. UMA has that separation, but doesn’t handle the collapsed case very well in my opinion (in spite of best efforts to allow it). OAuth assumes they’re always the same but can be tweaked to make them different sometimes (like CIBA’s call center use case), but it’s not really set up for that.

I think we have an opportunity to get this right in XYZ because we have a more flexible way of defining “how I can interact with a user” as part of the protocol, as well as “anything I know about the user already” for the client to push in. This could be used as a signal to the AS that the end user and resource owner are different parties and it should go bug someone through an asynchronous channel for approval.

As for the rest of Nat’s list below, that’s a hefty feature set. If we pick up this work, I think a few of these might fit better into a companion spec, but they are all definitely worth discussing. I would personally rather bring all the pieces together and figure out how to slice them apart than have something incomplete that needs to be bolted on to for anyone to use it.

— Justin

On Jul 22, 2019, at 12:21 PM, Nat Sakimura <[email-masked]<mailto:[email-masked]>> wrote:

+1

0. User

Cheers,

Nat Sakimura

On Sun, Jul 21, 2019 at 5:28 PM Dick Hardt <[email-masked]<mailto:[email-masked]>> wrote:

Hey Justin

— Justin