Subject: [Txauth] TxAuth Proposed Charter

From: Justin Richer <[email-masked]>
Date: Fri, 20 Dec 2019 17:34:09 -0500

Hi all,

As discussed in Singapore, no matter what forum TxAuth takes, its work will require a new charter. With that in mind, I’ve taken a bit of time to put together a proposed charter text for the TxAuth work:

This group is chartered to develop a next-generation transactional authorization and delegation protocol for HTTP-based APIs and their clients. These transactions will allow an authorizing party to delegate a right of access for an API or set of APIs through an authorization server to a software client acting on behalf of an authorizing party. 

The group will deliver a protocol specification detailing how a client can request and obtain delegated access, how an authorization server can provide delegated access, how an authorized party can authorize delegated access, and how that authorized access can be communicated to the resources being protected. These actions will be connected through an explicit transaction between the client and authorization server, resulting in an artifact that will allow the client to undertake the delegated action. 

Additionally, the delegation process will allow for:
- Fine-grained specification of resource access
- Delegation between multiple users
- Web, mobile, single-page, and other client applications

The group will define extension points for this protocol to allow for flexibility in areas including:

- Cryptographic agility for keys, message signatures, and proof of possession 
- User interaction mechanisms including web and non-web methods
- Token presentation mechanisms and key bindings

The artifacts for this work are not intended or expected to be backwards-compatible with OAuth 2.0 and its extensions. 

While this work could be done in within the OAuth working group, I now believe that it should be done in a new working group, and that we should try to get that working group up and running prior to the Vancouver meeting in March. I think this group should stay here on the TxAuth list, and it’s my suggestion that the resulting work be called OAuth 3.0. 

Why a new group? I think that the OAuth working group should remain focused on extending, patching, and adapting OAuth 2.0 to a changing world. I plan to be engaged in both groups, and I know most of you are as well, but that’s not universal. Since OAuth 2.0 is so established already, there are a LOT of people who aren’t going to be interested in something new any time soon. But on the other hand, there are a number of people for whom OAuth 2.0 does not work, or is at the very least a poor fit, and we’ll want to bring them in at this early stage. So even with significant overlap, I think there’s enough disconnect in the community from both sides that warrants a new group. In addition, I think this is a big enough piece of work that it’s simply too much for the OAuth working group to be able to focus on. We wouldn’t be able to get additional meeting time, and OAuth already has trouble fitting into its two meeting slots as it is.

I’ve published a blog post detailing more of my rationale:

https://medium.com/@justinsecurity/the-case-for-oauth-3-0-why-a-new-working-group-d6229ba8e36?

Please suggest changes to the proposed charter text above. It’s my hope that we can get the chartering process started.

 — Justin

---

From: Eve Maler <[email-masked]>
Date: Fri, 20 Dec 2019 17:27:29 -0600

Re “to a software client _acting on behalf of an authorizing party_”: There is a whole lot of philosophy behind whom the delegated access is performed on behalf of, unless the scenario is single-user or some "act as" semantic is spelled out on the wire. Does it need to be stated here? What's the consequence if the highlighted phrase were removed? 

Eve Maler (sent from my iPad) | cell +1 425 345 6756

> On Dec 20, 2019, at 4:34 PM, Justin Richer <[email-masked]> wrote:
> 
> Hi all,
> 
> -- 
> Txauth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth

---

From: Dick Hardt <[email-masked]>
Date: Fri, 20 Dec 2019 16:13:04 -0800

Eve: do you not think the software client is acting on behalf of some
party? Or do you think that software always is acting on behalf of some
party, and the mentioned phrase is redundant?

Justin: a couple questions

1. What is meant by "Delegation between multiple users" ?

2. Why do you restrict this to HTTP?

3. Why is authentication not in scope?

4. When you say "not backwards compatible with OAuth 2.0 and its
extensions", do you expect to define a new standard to replace RFC 6750?
Developers will have to have a new method to call APIs?

On Fri, Dec 20, 2019 at 3:27 PM Eve Maler <[email-masked]> wrote:

> Re “to a software client _acting on behalf of an authorizing party_”:
> There is a whole lot of philosophy behind whom the delegated access is
> performed on behalf of, unless the scenario is single-user or some "act as"
> semantic is spelled out on the wire. Does it need to be stated here? What's
> the consequence if the highlighted phrase were removed?
>
> As discussed in Singapore, no matter what forum TxAuth takes, its work
> will require a new charter. With that in mind, I’ve taken a bit of time to
> put together a proposed charter text for the TxAuth work:
>
> This group is chartered to develop a next-generation transactional
> authorization and delegation protocol for HTTP-based APIs and their
> clients. These transactions will allow an authorizing party to delegate a
> right of access for an API or set of APIs through an authorization server
> to a software client acting on behalf of an authorizing party.
>
> The group will deliver a protocol specification detailing how a client can
> request and obtain delegated access, how an authorization server can
> provide delegated access, how an authorized party can authorize delegated
> access, and how that authorized access can be communicated to the resources
> being protected. These actions will be connected through an explicit
> transaction between the client and authorization server, resulting in an
> artifact that will allow the client to undertake the delegated action.
>
> The artifacts for this work are not intended or expected to be
> backwards-compatible with OAuth 2.0 and its extensions.
>
>
> While this work could be done in within the OAuth working group, I now
> believe that it should be done in a new working group, and that we should
> try to get that working group up and running prior to the Vancouver meeting
> in March.. I think this group should stay here on the TxAuth list, and it’s
> my suggestion that the resulting work be called OAuth 3.0.
>
> Why a new group? I think that the OAuth working group should remain
> focused on extending, patching, and adapting OAuth 2.0 to a changing world.
> I plan to be engaged in both groups, and I know most of you are as well,
> but that’s not universal. Since OAuth 2.0 is so established already, there
> are a LOT of people who aren’t going to be interested in something new any
> time soon. But on the other hand, there are a number of people for whom
> OAuth 2.0 does not work, or is at the very least a poor fit, and we’ll want
> to bring them in at this early stage. So even with significant overlap, I
> think there’s enough disconnect in the community from both sides that
> warrants a new group. In addition, I think this is a big enough piece of
> work that it’s simply too much for the OAuth working group to be able to
> focus on. We wouldn’t be able to get additional meeting time, and OAuth
> already has trouble fitting into its two meeting slots as it is.
>
> Please suggest changes to the proposed charter text above. It’s my hope
> that we can get the chartering process started.
>
>  — Justin
> --
> Txauth mailing list
> [email-masked]

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Sat, 21 Dec 2019 01:08:19 +0000

I’m not sure if this is what Eve had in mind, but consider an automated system in an enterprise context that has been authorized by an administrator. The automated system isn’t acting as or on behalf of the administrator, and the administrator hasn’t “delegated access”; they’ve granted access, just as they do when they assign permissions to users/groups/roles/etc.
Maybe I’m being too literal, but “through an authorization server” in paragraph 1 implies a specific context/information/request flow to me. Given that one of TxAuth’s features is decoupling the different communication channels, we should not suggest that the client or authorizing party is directly interacting with the AS.

–
Annabelle Richard Backman
AWS Identity

From: Txauth <[email-masked]> on behalf of Dick Hardt <[email-masked]>
Date: Friday, December 20, 2019 at 4:14 PM
To: Eve Maler <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Justin Richer <[email-masked]>, Benjamin Kaduk <[email-masked]>
Subject: Re: [Txauth] TxAuth Proposed Charter

Eve: do you not think the software client is acting on behalf of some party? Or do you think that software always is acting on behalf of some party, and the mentioned phrase is redundant?

4. When you say "not backwards compatible with OAuth 2.0 and its extensions", do you expect to define a new standard to replace RFC 6750? Developers will have to have a new method to call APIs?

On Fri, Dec 20, 2019 at 3:27 PM Eve Maler <[email-masked]<mailto:[email-masked]>> wrote:
Re “to a software client _acting on behalf of an authorizing party_”: There is a whole lot of philosophy behind whom the delegated access is performed on behalf of, unless the scenario is single-user or some "act as" semantic is spelled out on the wire. Does it need to be stated here? What's the consequence if the highlighted phrase were removed?
Eve Maler (sent from my iPad) | cell +1 425 345 6756

On Dec 20, 2019, at 4:34 PM, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

While this work could be done in within the OAuth working group, I now believe that it should be done in a new working group, and that we should try to get that working group up and running prior to the Vancouver meeting in March.. I think this group should stay here on the TxAuth list, and it’s my suggestion that the resulting work be called OAuth 3.0.

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

---

From: Dick Hardt <[email-masked]>
Date: Fri, 20 Dec 2019 17:34:51 -0800

Would an automated system as you describe not be acting on behalf of the
enterprise? A party does not need to be a person. But perhaps I am not
understanding your point.

Perhaps you mistyped, but I'm confused with

we should not suggest that the client or authorizing party is directly
interacting with the AS.

We are stating the software client IS interacting with the AS.

ᐧ

On Fri, Dec 20, 2019 at 5:08 PM Richard Backman, Annabelle <
[email-masked]> wrote:

> I’m not sure if this is what Eve had in mind, but consider an automated
> system in an enterprise context that has been authorized by an
> administrator. The automated system isn’t acting as or on behalf of the
> administrator, and the administrator hasn’t “delegated access”; they’ve
> *granted* access, just as they do when they assign permissions to
> users/groups/roles/etc.
>
> Maybe I’m being too literal, but “through an authorization server” in
> paragraph 1 implies a specific context/information/request flow to me.
> Given that one of TxAuth’s features is decoupling the different
> communication channels, we should not suggest that the client or
> authorizing party is directly interacting with the AS.
>
>
>
> –
>
> *From: *Txauth <[email-masked]> on behalf of Dick Hardt <
> [email-masked]>
> *Date: *Friday, December 20, 2019 at 4:14 PM
> *To: *Eve Maler <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>,
> Justin Richer <[email-masked]>, Benjamin Kaduk <[email-masked]>
> *Subject: *Re: [Txauth] TxAuth Proposed Charter
>
>
>

---

From: David Waite <[email-masked]>
Date: Fri, 20 Dec 2019 19:03:46 -0700

> On Dec 20, 2019, at 3:34 PM, Justin Richer <[email-masked]> wrote:

> transactional authorization and delegation protocol for HTTP-based APIs and their clients.

Its far past time for me to ask this without seeing like an annoying pedant, but here goes anyway (maybe I _am_ an annoying pedant?):

What does “transactional authorization” mean in this context?

In this sense, are we saying this is a transaction for gaining authorization? If that is the case, are we talking about transaction in the sense of an “exchange” (such as token exchange or the process of trading client credentials for an access token under client credentials grant today?) Or perhaps that the process of getting authorization is an atomic action?

If we are saying it is a protocol for setting up authorizations which are transactional, are we specifically talking about authorizations to preform atomic actions, such as a money transfer?

Or is there another definition that I’m missing?

The process of gaining proof of authorization does not seem to fit the definition of being ’transactional’ in the atomic sense. In particular, requests for authorization may be continued with additional information such as the result of the user hitting an interaction endpoint, or an attempt to get new proof of authorization (possibly with different access) off of a previous handle.

To me, the two most significant differences between TXAuth and the existing OAuth 2.x body of work are that:

1. The process of requesting authorization is exclusively made via direct communication between the client and authorization server, rather than sometimes through an indirect channel. This comes from the realizations both that there are plenty of use-cases for delegated authorization that won’t allow for a simple browser redirect, and that the optimization of sometimes making a request indirectly - through insecure parameters in the user channel - isn’t worth the security consequences.

2. the authorization process itself is made a reified first-class citizen - today with a transaction handle, perhaps in the future (if I can make a convincing argument) as a specific authorization resource at a particular URL. The closest OAuth 2 has to this is the optional refresh token, which doesn’t have the power to perform additional client challenges or to make further requests for user interaction.

However, it wouldn’t normally occur to me to use the word “transaction” to describe either of these.

-DW

---

From: Eve Maler <[email-masked]>
Date: Fri, 20 Dec 2019 21:15:19 -0600

I was thinking of Dick's second construction: Software always acts on behalf of some party because it can't be a ''party" itself, so the phrase may just raise more questions than it answers. In business-legal terms, a client is very probably acting only as a limited agent or fiduciary for the resource owner, for starters, given that it has some third-party publisher/operator and imposes T's and C's.

The UMA group has done significant business-legal modeling work around multi-party delegation of access rights. If there's interest I can provide a summary. There are certainly scenarios, maybe like Annabelle's?, where a party on either end might be a "legal person" (enterprise) rather than a human.

> On Dec 20, 2019, at 7:08 PM, Richard Backman, Annabelle <[email-masked]> wrote:
> 
>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Sat, 21 Dec 2019 07:09:31 +0000

On Dec 20, 2019, at 5:35 PM, Dick Hardt <[email-masked]> wrote:

Would an automated system as you describe not be acting on behalf of the enterprise? A party does not need to be a person. But perhaps I am not understanding your point.

Yes, in the same sense that any employee of the enterprise acts on its behalf. The important thing is that we recognize that the automated system isn’t acting In behalf of “Bob, the administrator who set it up.” The authorizing actor (Bob) may be authorizing the client on behalf of the authorizing party (the enterprise). From an auditing and governance standpoint, the client’s actions should be attributed to the client (and the enterprise, if it’s acting in a multi tenant environment), not Bob.

we should not suggest that the client or authorizing party is directly interacting with the AS.

 The key word is “directly.” Are we assuming the client will always directly communicate with the AS? Could transactions start with a client calling an RS, which calls the AS? I’m only just starting to explore this  idea but it seems interesting. There’s still an AS involved, and a transaction between AS and client, but not necessarily direct interaction.

As I said, maybe I’m being too literal.

[https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=81127a9d-0641-423c-be77-812070241103]ᐧ
On Fri, Dec 20, 2019 at 5:08 PM Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>> wrote:
I’m not sure if this is what Eve had in mind, but consider an automated system in an enterprise context that has been authorized by an administrator. The automated system isn’t acting as or on behalf of the administrator, and the administrator hasn’t “delegated access”; they’ve granted access, just as they do when they assign permissions to users/groups/roles/etc.
Maybe I’m being too literal, but “through an authorization server” in paragraph 1 implies a specific context/information/request flow to me. Given that one of TxAuth’s features is decoupling the different communication channels, we should not suggest that the client or authorizing party is directly interacting with the AS.

–

From: Txauth <[email-masked]<mailto:[email-masked]>> on behalf of Dick Hardt <[email-masked]<mailto:[email-masked]>>
Date: Friday, December 20, 2019 at 4:14 PM
To: Eve Maler <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Justin Richer <[email-masked]<mailto:[email-masked]>>, Benjamin Kaduk <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Txauth] TxAuth Proposed Charter

 — Justin

---

From: Justin Richer <[email-masked]>
Date: Sat, 21 Dec 2019 07:37:19 -0500

First, naming things is hard. 

But second, the two key points that you pull our below are important, and both of those led me to the “transactional” name. What I realized is that the process of authorization is, itself, a transaction between multiple parties.  The whole idea with a transaction is that you have multiple actions that get bound together into one result. By reifying that transaction, you can start to think of the process in these terms:

1. Client starts a transaction with the AS
2. User modifies the transaction’s state at the AS with their authorization
3. Client continues the transaction with the AS
4. AS creates a token representing the end result of the transaction (access)

So it’s stateful, multi-step, and multi-party.There’s also a common thread binding each step to the next, which is at least in line with your notion of atomicity. If any part of the process fails, you can stop the whole thing and throw it out. When it’s finished, you commit it into an artifact (the token). 

We are not saying that it’s authorization for transactional APIs, though it obviously could be used for that. 

 — Justin

> On Dec 20, 2019, at 9:03 PM, David Waite <[email-masked]> wrote:
> 
>> On Dec 20, 2019, at 3:34 PM, Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: Justin Richer <[email-masked]>
Date: Sat, 21 Dec 2019 07:40:54 -0500

> Yes, in the same sense that any employee of the enterprise acts on its behalf. The important thing is that we recognize that the automated system isn’t acting In behalf of “Bob, the administrator w…

All these parties would need to be represented in the transaction, yes.

>  The key word is “directly.” Are we assuming the client will always directly communicate with the AS? Could transactions start with a client calling an RS, which calls the AS? I’m only just startin…

Even if the client starts at the RS, the client still has to go talk to the AS. I haven’t built this out, but I see it working somewhat like UMA. In XYZ’s terms:

1. Client calls the RS trying to Do A Thing
2. RS calls the AS requesting a Resource Handle (because that’s what the RS represents, resources) — at least good enough to cover what the client tried to do, could be more
3. RS gives the Resource Handle and AS Transaction Endpoint back to the client
4. Client calls the AS Transaction Endpoint to start a transaction, includes the Resource Handle as part of its request (note: doesn’t have to be the whole resource section, client can add stuff)
5. Process continues as normal

 — Justin

>> On Fri, Dec 20, 2019 at 5:08 PM Richard Backman, Annabelle <[email-masked] <mailto:[email-masked]>> wrote:
>> From: Txauth <[email-masked] <mailto:[email-masked]>> on behalf of Dick Hardt <[email-masked] <mailto:[email-masked]>>
>> To: Eve Maler <[email-masked] <mailto:[email-masked]>>
>> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, Justin Richer <[email-masked] <mailto:[email-masked]>>, Benjamin Kaduk <[email-masked] <mailto:[email-masked]>>
>> On Fri, Dec 20, 2019 at 3:27 PM Eve Maler <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> On Dec 20, 2019, at 4:34 PM, Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi all,
>> 
>>  
>> 
>> https://medium.com/@justinsecurity/the-case-for-oauth-3-0-why-a-new-working-group-d6229ba8e36? <https://medium.com/@justinsecurity/the-case-for-oauth-3-0-why-a-new-working-group-d6229ba8e36?>
>>  
>> 
>> [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: Justin Richer <[email-masked]>
Date: Sat, 21 Dec 2019 07:47:32 -0500

> Eve: do you not think the software client is acting on behalf of some party? Or do you think that software always is acting on behalf of some party, and the mentioned phrase is redundant?

I think what Eve’s saying is that the authorizing party might not be interacting with the client. That’s where things get fuzzy — if the authorizing party authorizes the client but someone else is using it, the authorizing party is really authorizing the requesting party that’s using the client, too. This is where UMA’s terminology can be a better fit here. Separating the RO and RqP roles could help, but how to express that in succinct charter text.

> 1. What is meant by "Delegation between multiple users” ?

See above.

> 2. Why do you restrict this to HTTP?

Because I want us to use all of the features and benefits of HTTP instead of having to invent within-protocol functions to replicate them. I don’t want SOAP, which pretends to be transport agnostic much to its detriment. If someone wants to do OAuth 3 on not-HTTP, they can define what that looks like. This is what happened with the COAP/CORE stuff and OAuth 2.

> 3. Why is authentication not in scope?

It felt, to me, like that might be a bridge too far. If we do decide it’s in scope, then I think it should be clearly layered on top of the authorization layer. 

> 4. When you say "not backwards compatible with OAuth 2.0 and its extensions", do you expect to define a new standard to replace RFC 6750? Developers will have to have a new method to call APIs?

Kinda. First, it’s more 6749 that I want to step away from. But even then, I think keeping just the header version of 6750 is OK enough if someone wants to keep using that. The thing is, won’t someone seeing an OAuth 2 header assume the rest of OAuth 2 infrastructure? In some cases this won’t matter, but in many that could be really confusing. 

One of the problems, though, is that 6750 has already been clouded by things like the MTLS binding, where they use “bearer” tokens that have to be bound to the client’s certificate. So … not much of a bearer token anymore.

Ultimately, I don’t want anything that has an error-fallthrough compatibility process. That is to say, I try doing OAuth 2, have that fail, and then try it as OAuth 3 — or vice versa.

 — Justin

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 21 Dec 2019 23:51:41 +0200

Hi Justin,

I think the charter should mention target use cases. For example, “all use cases supported by OAuth 2 will be supported by the new protocol” or “the protocol will support at least use cases X and Y”.

And given the importance of OIDC, we could say something like: “The protocol will allow future extension to support authentication, in an analogous way to OpenID Connect. However authentication is explicitly not part of the initial scope.”

Thanks,

                Yaron

From: Txauth <[email-masked]> on behalf of Justin Richer <[email-masked]>
Date: Saturday, December 21, 2019 at 00:34
To: <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Benjamin Kaduk <[email-masked]>
Subject: [Txauth] TxAuth Proposed Charter

Hi all,

 — Justin

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

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Sun, 22 Dec 2019 06:05:58 +0000

On Dec 21, 2019, at 4:42 AM, Justin Richer <[email-masked]> wrote:

It depends on what you consider the “AS”. Consider the following hypothetical architecture:

• The RS, client, and tx endpoint are on the public Internet.
• The tx endpoint returns interaction urls that point to an IdP that is inaccessible from the public Internet.
• The user agent can reach the IdP, but none of the other systems can.
• When the UA is redirected to the IdP, the IdP calls the tx endpoint system to retrieve transaction details.
• When authorization is granted, the IdP pushes artifacts directly to an endpoint provided by the client.

In this example, the client only interacts with the RS and the tx endpoint. It seems odd to me to consider the system hosting the tx endpoint to be the AS (or at least part of the AS), as its a glorified message queue with essentially no authority in this architecture.

We could go a step further and remove the client’s interaction with the tx endpoint by having the RS return the interaction url directly (you’d need to secure the client nonce if you want to hide it from the RS, but that’s not that hard).

Is the meaning of “authorization server” (or the phrase “through an authorization server”) flexible enough to accommodate these cases? Or are they considered out of scope for TxAuth?

 — Justin

–

 — Justin

---

From: Justin Richer <[email-masked]>
Date: Sun, 22 Dec 2019 20:34:50 -0500

I think you’re conflating the roles that different components play, in regard to the other components, with the potential deployment of those components. The spec needs to be written in terms of the roles. While the roles do need to consider what potential deployments might be, it’s important that we write things in in terms of how they interact with each other and not in terms of how they might look under the covers.

So from the clients perspective, the TX Endpoint :is: the AS. The client doesn’t care that it’s a “glorified message queue” or if it’s a massive server farm. The client doesn’t care if there’s a TLS reverse proxy or if it’s talking directly to the application layer. The only thing the client cares about is if the TX Endpoint does the things that a TX Endpoint is supposed to do, and we define that to be the function of the AS. 

What’s important in your scenario below is that the client would have to talk to the RS first every time. That’s one of the problems that UMA has, and I think something we should avoid. I think RS-first is an interesting pattern but AS-first ought to drive this. 

With your hypothetical layout below, it really sounds like the TX Endpoint is a function of the IDP, which is fine. The client doesn’t care that it’s deployed using some externalized cloud service. The only weird thing going on is the push from the AS back to the client. The client would need to register that with the AS (or through the AS more specifically) as part of its transaction request. This would be part of its interaction mechanism, because “how you get messages and updates back to the client” is part of the interaction model. 

So for an RS-first transaction, the client calls the RS:

GET /foo

The RS returns a resource handle, but the client doesn’t care where that came from. The RS could talk to the AS to get it. Probably a new endpoint of some kind, can probably use the same kinds of key binding that the TX Endpoint has. Or the RS can make one up that the TX Endpoint can recognize. Or it calls the IdP to get one. The client doesn’t care, and that’s the key point. 

WWW-Authenticate tx_endpoint=“http://server//tx <http://server%EF%BF%BD/tx>” resource: “asdf1234”

The client calls the TX endpoint like a normal transaction:

POST /tx

{
  resources: [ “asdf1234” ],
  interact: {
    redirect: true,
    push: “http://client/push/9876 <http://client/push/9876>”
  }
}

The AS (which is to say the TX Endpoint) tells the client to send the user agent to the IdP

{
  interact_url: “http://idp/login <http://idp/login>”,
  handle: { value: “hjkl”, type: bearer }
}

Now the client could poll the TX Endpoint but it could also just sit and wait for an update to be pushed in. 

There are probably things that need to be tied together for this to be secure, but I think the basic pattern still fits. Importantly, the client doesn’t care whereby of that stuff came from — as far as it’s concerned, it’s talking to the AS. 

Remember, the “AS” is a logical construct, not a physical one. Just like the “client” could be a cluster of applications and the “RS” could be a suite of APIs tied behind a gateway.

 — Justin

> On Dec 22, 2019, at 1:05 AM, Richard Backman, Annabelle <[email-masked]> wrote:
> 
>

---

From: Aaron Parecki <[email-masked]>
Date: Sun, 22 Dec 2019 19:46:28 -0800

I do think authentication should be part of the charter from the outset.
Frankly the fact that authentication is intentionally left out of OAuth and
has to be bolted on to the side via OpenID Connect is one of the exact
reasons people get confused about the whole space to begin with.

It's a relatively minor addition to the existing proposed spec to make it
useful as a minimum viable authentication solution, and I'd like to see
that be addressed at the beginning of this work.

I think we can do this in a smart way and that authentication should be
included in the charter.

Aaron

On Sat, Dec 21, 2019 at 1:51 PM Yaron Sheffer <[email-masked]> wrote:

> Hi Justin,
>
>
>
> I think the charter should mention target use cases. For example, “all use
> cases supported by OAuth 2 will be supported by the new protocol” or “the
> protocol will support at least use cases X and Y”.
>
>
>
> And given the importance of OIDC, we could say something like: “The
> protocol will allow future extension to support authentication, in an
> analogous way to OpenID Connect. However authentication is explicitly not
> part of the initial scope.”
>
>
>
> Thanks,
>
>                 Yaron
>
>
>
> *From: *Txauth <[email-masked]> on behalf of Justin Richer <
> [email-masked]>
> *Date: *Saturday, December 21, 2019 at 00:34
> *To: *<[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, Benjamin Kaduk <[email-masked]>
> *Subject: *[Txauth] TxAuth Proposed Charter
>
>
>
> Hi all,
>
>
>
> in March. I think this group should stay here on the TxAuth list, and it’s
> -- Txauth mailing list [email-masked]
-- 
----
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Mon, 23 Dec 2019 04:52:45 +0000

My example demonstrates an architecture where the TX Endpoint, authentication system, and token issuer aren’t simply different micro services, they’re completely independent systems in different trust boundaries, possibly have different domains and different keys. This has implications for protocol design. For example, it would no longer be sufficient to have a single jwks_uri, as OAuth 2.0 has.

If we want to support this kind of “decomposed AS” model, then we need to make sure that’s supported by the charter and keep it in mind as we design the protocol. We can also decide it is out of scope, but we should be intentional about that decision.

To my mind, this role decomposition is the next logical step after the channel decomposition that TxAuth already does. I see a lot of potential in it and think we should at minimum avoid closing the door on it.

On Dec 22, 2019, at 5:35 PM, Justin Richer <[email-masked]> wrote:

GET /foo

WWW-Authenticate tx_endpoint=“http://server//tx<http://server%EF%BF%BD/tx>” resource: “asdf1234”

POST /tx

{
  resources: [ “asdf1234” ],
  interact: {
    redirect: true,
    push: “http://client/push/9876”
  }
}

{
  interact_url: “http://idp/login”,
  handle: { value: “hjkl”, type: bearer }
}

 — Justin

On Dec 22, 2019, at 1:05 AM, Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>> wrote:

On Dec 21, 2019, at 4:42 AM, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:

 — Justin

–

 — Justin

---

From: Justin Richer <[email-masked]>
Date: Mon, 23 Dec 2019 16:51:37 -0500

I’m fine with it being in charter but I do think it should be a clearly separate layer, much like OIDC/Facebook Connect/GitHub Login/etc are with OAuth today. In all of these the authorization is first, and I think that’s the right pattern. So if we do take it on we’ll just need to be careful how it’s structured in with everything else. Otherwise, I think the authentication side can quickly overwhelm and drag down the authorization side.

Good news: A lot of the additional stuff in OIDC is there to patch holes in core OAuth in a common fashion, and we’ll at least be in a position to not have to do that again. 

 — Justin

> On Dec 22, 2019, at 10:46 PM, Aaron Parecki <[email-masked]> wrote:
> 
> I do think authentication should be part of the charter from the outset. Frankly the fact that authentication is intentionally left out of OAuth and has to be bolted on to the side via OpenID Connect is one of the exact reasons people get confused about the whole space to begin with. 
> 
> It's a relatively minor addition to the existing proposed spec to make it useful as a minimum viable authentication solution, and I'd like to see that be addressed at the beginning of this work.
> 
> I think we can do this in a smart way and that authentication should be included in the charter.
> 
> Aaron
> 
> 
> 
> 
> On Sat, Dec 21, 2019 at 1:51 PM Yaron Sheffer <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Justin,
> 
>  
> 
> From: Txauth <[email-masked] <mailto:[email-masked]>> on behalf of Justin Richer <[email-masked] <mailto:[email-masked]>>
> To: <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, Benjamin Kaduk <[email-masked] <mailto:[email-masked]>>
> -- Txauth mailing list [email-masked] <mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>-- 
> Txauth mailing list
> aaronparecki.com <http://aaronparecki.com/>

---

From: Justin Richer <[email-masked]>
Date: Mon, 23 Dec 2019 16:57:26 -0500

So the thing is, I don’t think you need a single JWKS URI anymore anyway. You’d have one associated with the TxEndpoint, if you’ve got signed tokens that you need to validate separately. And if you’re doing signed user assertions, you’d have a different one identified in the assertion (either directly or via an issuer-discovery mechanism). Ultimately the client is going to care about one and the RS about another so it’s fine that they’re different. We get to define what that looks like. 

On the surface I’m OK with a decomposed AS, to some extent, but only if there are very, very clear boundaries about what the individual roles are. And the more roles we make, the more we have to define what the communication points are in between them. Maybe “AS” is too all-encompassing of a role now, but I’m not yet convinced that’s true in practice, and I do want someone to be able to deploy this by having all the “server” side functionalities running out of a single, simple box. That might be a case of that single box needing to play multiple roles, and that’s OK, but we need to be clear on what kinds of optimizations are allowable in cases like that.

I do think there’s precedent in asking this question though, since between OAuth 1 and 2 we split the “server” into “AS and RS”. OAuth 2 famously didn’t define a connection point between them until much later (JWT and Introspection), but that pattern seems to have mostly worked.

 — Justin

> On Dec 22, 2019, at 11:52 PM, Richard Backman, Annabelle <[email-masked]> wrote:
> 
>>> On Dec 22, 2019, at 1:05 AM, Richard Backman, Annabelle <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> 
>>>> On Dec 21, 2019, at 4:42 AM, Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>>>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Mon, 23 Dec 2019 23:22:39 +0000

The point is, I might want my tokens to be signed using keys that my TX Endpoint does not have access to. E.g., my token issuer signs tokens with key A and my TX Endpoint signs HTTP response messages with key B, neither system has access to the other key, and tokens signed by key B are rejected by RSes. This requires the working group to understand that trust boundaries may exist between the different components implementing portions of “AS” behavior. If this isn’t understood, then if/when I bring up this use case, I’m going to be told “there are no trust boundaries within an AS, so what you’re describing isn’t an AS anymore, and not in scope per the charter.”

I’m sensitive to the desire to not overcomplicate things. The scenario I’m describing is unusual, and probably not what we should optimize the protocol for (though that could always change). But we’re talking about charter, not protocol. The charter can be as detailed and nuanced as it needs to be to properly describe what we are setting out to accomplish.

–

From: Justin Richer <[email-masked]>
Date: Monday, December 23, 2019 at 1:57 PM
To: "Richard Backman, Annabelle" <[email-masked]>
Cc: Dick Hardt <[email-masked]>, Eve Maler <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Benjamin Kaduk <[email-masked]>
Subject: Re: [Txauth] TxAuth Proposed Charter

 — Justin

On Dec 22, 2019, at 11:52 PM, Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>> wrote:

On Dec 22, 2019, at 5:35 PM, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:
I think you’re conflating the roles that different components play, in regard to the other components, with the potential deployment of those components. The spec needs to be written in terms of the roles. While the roles do need to consider what potential deployments might be, it’s important that we write things in in terms of how they interact with each other and not in terms of how they might look under the covers.

GET /foo

POST /tx

{

{

 — Justin

 — Justin

–

 — Justin

---

From: Aaron Parecki <[email-masked]>
Date: Mon, 23 Dec 2019 18:39:23 -0800

I definitely am not trying to discuss specifics of *how* authentication
should be included right now, but I just want to make sure it's included in
the charter so that we can actually talk about it and it won't be "out of
scope" when we eventually do talk about the specifics.

Aaron

On Mon, Dec 23, 2019 at 1:51 PM Justin Richer <[email-masked]> wrote:

> I’m fine with it being in charter but I do think it should be a clearly
> separate layer, much like OIDC/Facebook Connect/GitHub Login/etc are with
> OAuth today. In all of these the authorization is first, and I think that’s
> the right pattern. So if we do take it on we’ll just need to be careful how
> it’s structured in with everything else. Otherwise, I think the
> authentication side can quickly overwhelm and drag down the authorization
> side.
>
> Good news: A lot of the additional stuff in OIDC is there to patch holes
> in core OAuth in a common fashion, and we’ll at least be in a position to
> not have to do that again.
>
>
>  — Justin
>
>> I think the charter should mention target use cases. For example, “all
>> use cases supported by OAuth 2 will be supported by the new protocol” or
>> “the protocol will support at least use cases X and Y”.
>>
>>
>>
>> The group will deliver a protocol specification detailing how a client
>> can request and obtain delegated access, how an authorization server can
----
Aaron Parecki
aaronparecki.com

---

From: Brian Campbell <[email-masked]>
Date: Tue, 24 Dec 2019 07:54:43 -0700

Naming any prospective resulting work here "OAuth 3.0" would significantly
exacerbate confusion in the whole space and would be a major disservice to
the broader community.

On Mon, Dec 23, 2019 at 7:39 PM Aaron Parecki <[email-masked]> wrote:

>>> https://medium..com/@justinsecurity/the-case-for-oauth-3-0-why-a-new-working-group-d6229ba8e36?
>>> <https://medium.com/@justinsecurity/the-case-for-oauth-3-0-why-a-new-working-group-d6229ba8e36?>
>>>
>>>
>>>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

---

From: Justin Richer <[email-masked]>
Date: Tue, 24 Dec 2019 19:10:51 -0500

I don’t think we should write the charter with a specific solution in mind, but instead describing the problems that we want to solve with a standard. The “with a standard” is important here as not every aspect is going to need a standard specification, only the parts where we expect communication and interoperability between implementations, right?

I would say that rather the charter should be more general in describing the purpose and not putting things :out: of scope. It might very well be that the deployment you’re describing is an optimization, but if it makes sense within the bounds of the work, even if the details are described in their own spec (or not in a spec at all, if we decide that’s one of the “under the hood” aspects), then that’s OK. I do agree that what’s really important here is having an idea of what the different moving parts are, at least to start. Any proposed ideas on how to describe this without getting into prescriptive deployment details?

 — Justin

> On Dec 23, 2019, at 6:22 PM, Richard Backman, Annabelle <[email-masked]> wrote:
> 
>> On Dec 22, 2019, at 11:52 PM, Richard Backman, Annabelle <[email-masked] <mailto:[email-masked]>> wrote:
>>  
>>> On Dec 22, 2019, at 5:35 PM, Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>>>

---

From: Justin Richer <[email-masked]>
Date: Tue, 24 Dec 2019 19:11:25 -0500

I’m personally fine with that position.

 — Justin

> On Dec 23, 2019, at 9:39 PM, Aaron Parecki <[email-masked]> wrote:
> 
> I definitely am not trying to discuss specifics of *how* authentication should be included right now, but I just want to make sure it's included in the charter so that we can actually talk about it and it won't be "out of scope" when we eventually do talk about the specifics.
> 
> Aaron
> 
> 
> 
> On Mon, Dec 23, 2019 at 1:51 PM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>> On Dec 22, 2019, at 10:46 PM, Aaron Parecki <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Justin Richer <[email-masked]>
Date: Tue, 24 Dec 2019 19:21:52 -0500

Brian, I hear what you’re saying, but I disagree completely.

Who would be confused by seeing a major revision to an existing protocol that worked in a different way and did the same things but also new things? That happens all the time.

Was there significant confusion between OAuth 1 and 2, enough to hamper adoption of either? For the people who deeply invested in OAuth 1 and didn’t need or want the OAuth 2 newness, they stuck with it (see: twitter). 

Was OpenID Connect a major disservice to OpenID 2? It was a disruption, for sure, but people transitioned where it made sense for them, and in many cases that took years of dual-deployment and transition. 

I see us walking along the same kind of path here, nearly a decade later. That’s why I think OAuth 3 makes sense as a name for the output of this work. Or at the very least, for the core delegation protocol portion of whatever we make. I think it sends the right message to implementers and developers: the community that knows and understands OAuth 2 is working on the next version of that thing, so when it’s ready, maybe you should look at it. Until it’s done, and for a long time after, OAuth 2 is still going to be there and be the right answer. 

The name isn’t a hill I’m committed to dying alone on, but I think it sends a :bad: message if we call it something new entirely. Namely, that we think people :should: abandon the entire world of OAuth, all of its ideas and implementations. That’s not what we’re doing with this design, it’s an evolution as I see things. And as an evolution, a new major revision number makes sense.

 — Justin

> On Dec 24, 2019, at 9:54 AM, Brian Campbell <[email-masked]> wrote:
> 
> Naming any prospective resulting work here "OAuth 3.0" would significantly exacerbate confusion in the whole space and would be a major disservice to the broader community. 
> 
> 
> On Mon, Dec 23, 2019 at 7:39 PM Aaron Parecki <[email-masked] <mailto:[email-masked]>> wrote:
>> https://medium..com/@justinsecurity/the-case-for-oauth-3-0-why-a-new-working-group-d6229ba8e36? <https://medium.com/@justinsecurity/the-case-for-oauth-3-0-why-a-new-working-group-d6229ba8e36?>
>>  
>> 
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

---

From: David Waite <[email-masked]>
Date: Tue, 24 Dec 2019 17:59:53 -0700

> On Dec 21, 2019, at 5:37 AM, Justin Richer <[email-masked]> wrote:
> 

So very agree!

> 4. AS creates a token representing the end result of the transaction (access)

Right, and I wouldn’t imply the name is wrong, only that there are multiple interpretations of ’transactional’ and we should be clear (both in the charter and in specifications) what is meant so we can be clear in goals and clear to the audience.

It sounds like the primary use of the adjective ’transactional’ is to describe exchanges and interactions in general - specifically that the specification aims to describe how to allow communication between what has become four parties - the AS, the client, the authorizing user agent, and the protected resource (some nomenclatures refer to the client and user agent as the accessing and authorizing agents).

And really, many of the OAuth 2 grants can be looked at handling differences in the relationship between the client and authorizing user agent:

1.  the client is able to directly control its behavior (code, native apps)
2.  the client replaces the need for an authorizing user agent (client credentials, ROPC)
3.  the client can’t interact directly but can give the user instructions on how to authorize (device)
4.  the client has a hint about the identity of the user or authorizing device and will give it to the AS to initiate authorization (CIBA)

Implicit could also be considered to have been a flow to deal with when the client is running on the authorizing user agent, without the capability to use code flow.

> So it’s stateful, multi-step, and multi-party.There’s also a common thread binding each step to the next, which is at least in line with your notion of atomicity. If any part of the process fails,…

There’s an element of representing the interaction between the client and AS as being an atomic transaction as well - you either succeed (and get tokens) or fail (and get a message why and/or instructions on how to rectify the situation). When you squint to look at it that way, the ’transaction handle’ is there so you can repeat the “authorization request”  transaction.

-DW

---

From: Thomas Hardjono <[email-masked]>
Date: Thu, 26 Dec 2019 11:42:37 -0500

I know the proposed charter is still a drafty draft, but I have a couple of high-level questions.

(i) Will there be a separate specification for the TXT core protocol and for the "authorization_details" (Torsten's draft). Is this what the proposaed Charter refers to as "Fine-grained specification of resource access".

(ii) Will there be an AS-to-AS mechanism to deliver authorization information (either in the "authorization_details" format or otherwise). This is relevant for authorization federation (for ASes in different domains) and for addressing some of the issues that Annabelle presented at IETF106 (i.e. context sharing).

-- thomas --

-----Original Message-----
From: Txauth <[email-masked]> on behalf of Justin Richer <[email-masked]>
Date: Friday, December 20, 2019 at 5:34 PM
To: <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Benjamin Kaduk <[email-masked]>
Subject: [Txauth] TxAuth Proposed Charter

Hi all,

 — Justin

---

From: Thomas Hardjono <[email-masked]>
Date: Thu, 26 Dec 2019 11:45:24 -0500

Correction: TXauth core protocol (not TXT core protocol, as TXT is Trusted Execution, and also the name of a K-Pop band).

-----Original Message-----
From: Thomas Hardjono <[email-masked]>
Date: Thursday, December 26, 2019 at 11:42 AM
To: Justin Richer <[email-masked]>, <[email-masked]>
Subject: Re: [Txauth] TxAuth Proposed Charter

-- thomas --

-----Original Message-----
From: Txauth <[email-masked]> on behalf of Justin Richer <[email-masked]>
Date: Friday, December 20, 2019 at 5:34 PM
To: <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Benjamin Kaduk <[email-masked]>
Subject: [Txauth] TxAuth Proposed Charter

Hi all,

 — Justin

---

From: Brian Campbell <[email-masked]>
Date: Thu, 26 Dec 2019 14:29:07 -0700

[doctored image credit: Nishant Kaushik]

Well, I'm already on record at the Singapore BoF (in a rambling incoherent
jetlagged kind of way but still) as not supporting progression of this
work. Concern around the confusion it'll cause in the wider community is
one of my reasons for that opposition and I personally think that using the
OAuth brand will exacerbate potential perception issues and confusion. But
with that said, while I don't necessarily agree with you, I do think your
arguments hold up for TXAuth/XYZ as an authorization protocol. However,
bringing identity/authentication into it would broaden the scope beyond the
evolution of an authorization protocol and into the realm of OIDC (and even
SAML), which is something we've been fighting to explain to the world that
OAuth isn't for years. The message that you don't ever do user
authentication with OAuth unless it's this particular version of OAuth
would be crazy confusing.

So with all that being said, I'll throw out the strawman name of MOAUTH*,
which is soft of a combination of a portmanteau and a play on word sounds.
It could be taken as "More OAuth" or "More Than OAuth" or "MOre Auth[n/z]"
or similar.. It'd maintain some link to OAuth heritage while indicating
progression/evolution and more easily allowing for a potentially a
broadening scope to include identity and user authentication.

* I cannot claim credit for MOAUTH but I don't know if the person from whom
I got the idea wants to be named so that'll be withheld for the time being

On Tue, Dec 24, 2019 at 5:21 PM Justin Richer <[email-masked]> wrote:

> Who would be confused by seeing a major revision to an existing protocol
> that worked in a different way and did the same things but also new things?
> That happens all the time.
>
> Was there significant confusion between OAuth 1 and 2, enough to hamper
> adoption of either? For the people who deeply invested in OAuth 1 and
> didn’t need or want the OAuth 2 newness, they stuck with it (see: twitter).
>
> Was OpenID Connect a major disservice to OpenID 2? It was a disruption,
> for sure, but people transitioned where it made sense for them, and in many
> cases that took years of dual-deployment and transition.
>
> I see us walking along the same kind of path here, nearly a decade later.
> That’s why I think OAuth 3 makes sense as a name for the output of this
> work. Or at the very least, for the core delegation protocol portion of
> whatever we make. I think it sends the right message to implementers and
> developers: the community that knows and understands OAuth 2 is working on
> the next version of that thing, so when it’s ready, maybe you should look
> at it. Until it’s done, and for a long time after, OAuth 2 is still going
> to be there and be the right answer.
>
> The name isn’t a hill I’m committed to dying alone on, but I think it
> sends a :bad: message if we call it something new entirely. Namely, that we
> think people :should: abandon the entire world of OAuth, all of its ideas
> and implementations. That’s not what we’re doing with this design, it’s an
> evolution as I see things. And as an evolution, a new major revision number
> makes sense.
>
>  — Justin
>
>>> It's a relatively minor addition to the existing proposed spec to make
>>> it useful as a minimum viable authentication solution, and I'd like to see
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*
>
>
>

---

From: Justin Richer <[email-masked]>
Date: Thu, 26 Dec 2019 17:53:48 -0500

What goes into what draft is, I believe, still largely up for discussion and decision by a WG. The charter doesn’t need to decide that ahead of time. What the charter can do though is decide what’s in and out of scope overall.

That said, I think the core will need to define something like XYZ’s “resources” structure and how it relates to the rest of the request. It’s possible that defining the details of what goes in that structure lives elsewhere, but given how it’s written in XYZ today I don’t think that is a necessary abstraction layer. It’s a separate draft in OAuth just because we didn’t have it in OAuth 2 to begin with, and look at the mess that’s causing with the aud, resource, scope, and other parameters.

I think the problem of sharing security policies across security domains is probably too much for this working group. Just look at everything that’s happened with XACML and its descendants — it’s a very, very difficult problem space, with confusing solutions where any exist at all. That said, I don’t see any reason the parts that we define, like the resources block, couldn’t be used as part of a separate cross-domain protocol. That’s one of the benefits of separating the concerns of the request like this — but without the over-engineering and over-abstraction of something like WS-*. 

So I’d like to put inter-domain security policies out of scope for this work. Thoughts?

 — Justin

> On Dec 26, 2019, at 11:45 AM, Thomas Hardjono <[email-masked]> wrote:
>

---

From: Justin Richer <[email-masked]>
Date: Thu, 26 Dec 2019 18:10:28 -0500

I hear you about the potential confusion, and believe me that’s something I want to avoid as well. But I disagree with you about what kind of confusion this would cause. I also believe that :not: doing the work and :not: admitting what this work really is would be a greater disservice than any temporary confusion that would come. Developers are going to reach for the libraries and tools that solve their problems, and for a while yet, that’s going to be OAuth 2. People will move to something else as it both solves what they need and also is available in their favorite platforms and libraries. Any successful standard goes through this growth cycle, regardless of what you call it. We saw some churn between OAuth 1 and 2 but nothing that was unmanageable. 

I think it’s clear that many existing vendors aren’t going to be fans of a new protocol. After all, why invest in building something new if you can keep selling what you’ve already built? In the end, some will adopt it, some won’t. Just like there were SAML vendors that implemented OIDC as well, and some that didn’t. Either of those is fine, though — nobody’s forcing anyone to follow along with new work. Those that did were sometimes dragged into it by customer demand, others were quick to dive in front of what they saw as a trend. And of course there were a lot of OIDC vendors who never wrote a SAML implementation in the first place. All of those decisions amount to managing the marketplace, and us pretending that the technology world is going to stand still for the sake of existing implementations isn’t doing anybody any favors. 

As for authentication, maybe it’s time that we, as a community, admit that we’re the source of the confusion. Yes, we’ve been explaining to people for many years that OAuth isn’t authentication. Except for when it is, and you call it by a different name like OIDC (or Facebook Connect, or Sign In With GitHub, etc….) if you think to, but most developers still call what they’re doing “authenticating with OAuth”. So why don’t we admit that maybe we did it wrong last time around? Even with that in mind, I still think that the identity/authentication layer should be separate and on top of the base delegation protocol, since they should be separable from each other. Maybe the identity layer will even get a new non-OAuth name, too. That doesn’t mean that they should be in different working groups, though, and I’d be glad to see them come together with this work.

Also, note that most of what OIDC had to invent was to patch holes in OAuth’s core that arguably shouldn’t have been there in the first place. There’s remarkably little in OIDC that is required to make the identity protocol portions work, and I think Aaron P’s pointed out some ways in which that could be slimmed down even more with this work. 

And finally, I am not at all a fan of the name “MOAuth”, and personally think it’s even more confusing than just calling this OAuth 3. 

 — Justin

> On Dec 26, 2019, at 4:29 PM, Brian Campbell <[email-masked]> wrote:
> 
> 
> Well, I'm already on record at the Singapore BoF (in a rambling incoherent jetlagged kind of way but still) as not supporting progression of this work. Concern around the confusion it'll cause in the wider community is one of my reasons for that opposition and I personally think that using the OAuth brand will exacerbate potential perception issues and confusion. But with that said, while I don't necessarily agree with you, I do think your arguments hold up for TXAuth/XYZ as an authorization protocol. However, bringing identity/authentication into it would broaden the scope beyond the evolution of an authorization protocol and into the realm of OIDC (and even SAML), which is something we've been fighting to explain to the world that OAuth isn't for years. The message that you don't ever do user authentication with OAuth unless it's this particular version of OAuth would be crazy confusing. 
> 
> So with all that being said, I'll throw out the strawman name of MOAUTH*, which is soft of a combination of a portmanteau and a play on word sounds. It could be taken as "More OAuth" or "More Than OAuth" or "MOre Auth[n/z]" or similar.. It'd maintain some link to OAuth heritage while indicating progression/evolution and more easily allowing for a potentially a broadening scope to include identity and user authentication.  
> 
> 
> * I cannot claim credit for MOAUTH but I don't know if the person from whom I got the idea wants to be named so that'll be withheld for the time being 
> 
> 
> 
> 
> On Tue, Dec 24, 2019 at 5:21 PM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>> On Dec 24, 2019, at 9:54 AM, Brian Campbell <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Thomas Hardjono <[email-masked]>
Date: Fri, 27 Dec 2019 11:29:17 -0500

Justin,

>>> So I’d like to put inter-domain security policies out of scope for this work. Thoughts?

Of course. I'm not proposing that TXauth create a new policy-expression syntax. These already exist (e.g. SAML, XACML). What I was suggesting that the authorization_details (in the PSD2 example from Torsten) needs to have standardized identification (akin to policy-oids) so that both the AS and RS are referring to the same syntax.  This is pretty easy, I think.

Re-reading your medium blog and your IETF slides, I get the impression that you are (we are) skirting around the problem or role-based access control (RBAC). So why not just express XYZ in those terms while using the OAuth2.0 nomenclature. 

If we can define "roles" attached to "permissions" (permission being expressed as scopes), then we can solve much of the ambiguities in OAuth2.0 (which UMA tried to solve to some extent (e.g. the Alice-to-Alice case)).

Example: Alice-as-RO-role is giving Alice-as-Requestor-role access to files at the RS at this location. Alice-as-Requestor-role can indicate intent (as in the XYZ proposal).

Another example:  Alice-as-RO-role gives Client-Operator permission (consent) to interact with the AS and RS on Alice's behalf.

-- thomas --

-----Original Message-----
From: Justin Richer <[email-masked]>
Date: Thursday, December 26, 2019 at 5:54 PM
To: Thomas Hardjono <[email-masked]>
Cc: <[email-masked]>
Subject: Re: [Txauth] TxAuth Proposed Charter

 — Justin

---

From: Thomas Hardjono <[email-masked]>
Date: Fri, 27 Dec 2019 11:35:03 -0500

+1 for calling it OAuth3.0.

The market will decide. It will stay on OAuth2.0 for some years still (just as with SAML2.0).

-- thomas --

-----Original Message-----
From: Txauth <[email-masked]> on behalf of Justin Richer <[email-masked]>
Date: Thursday, December 26, 2019 at 6:10 PM
To: Brian Campbell <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Yaron Sheffer <[email-masked]>, Benjamin Kaduk <[email-masked]>, Aaron Parecki <[email-masked]>, <[email-masked]>
Subject: Re: [Txauth] TxAuth Proposed Charter

 — Justin

 — Justin

Aaron

 — Justin

Aaron

Hi Justin,

 
Thanks,
                Yaron

Hi all,

 

 — Justin

---

From: Justin Richer <[email-masked]>
Date: Fri, 27 Dec 2019 12:48:20 -0500

We have an identifier field in the RAR draft right now, and I think it makes sense to have the two structures parallel to each other as much as we can. I’m not sure they can be exactly parallel though.

But please, for the love of everything, no OIDs.

 — Justin

> On Dec 27, 2019, at 11:29 AM, Thomas Hardjono <[email-masked]> wrote:
> 
> Justin,
>

---

From: Dick Hardt <[email-masked]>
Date: Fri, 27 Dec 2019 10:01:26 -0800

(changed topic as it is about Justin's proposal on having RS initiate Txx

On Sat, Dec 21, 2019 at 4:41 AM Justin Richer <[email-masked]> wrote:
<snip>

> Even if the client starts at the RS, the client still has to go talk to
> the AS. I haven’t built this out, but I see it working somewhat like UMA.
> In XYZ’s terms:
>
>
> 2. RS calls the AS requesting a Resource Handle (because that’s what the
> RS represents, resources) — at least good enough to cover what the client
> tried to do, could be more
> 4. Client calls the AS Transaction Endpoint to start a transaction,
> includes the Resource Handle as part of its request (note: doesn’t have to
> be the whole resource section, client can add stuff)

Why do you want the RS to request from the AS? This would require the RS to
have credentials known to the AS.

Why not have the RS provide information about what the Client needs to ask
the AS for, and which AS it is?

/Dick

---

From: Dick Hardt <[email-masked]>
Date: Fri, 27 Dec 2019 10:11:18 -0800

On Sat, Dec 21, 2019 at 4:47 AM Justin Richer <[email-masked]> wrote:

> I think what Eve’s saying is that the authorizing party might not be
> interacting with the client. That’s where things get fuzzy — if the
> authorizing party authorizes the client but someone else is using it, the
> authorizing party is really authorizing the requesting party that’s using
> the client, too. This is where UMA’s terminology can be a better fit here.
> Separating the RO and RqP roles could help, but how to express that in
> succinct charter text.
>

Eve clarified that her point was why the extra clarification, not your
thoughts.

> 1. What is meant by "Delegation between multiple users” ?

I still don't understand. Is one user delegating to another user? This is a
desirable use case for many, but currently not standardized. Is this what
you are proposing is in scope?

> Because I want us to use all of the features and benefits of HTTP instead
> of having to invent within-protocol functions to replicate them. I don’t
> want SOAP, which pretends to be transport agnostic much to its detriment.
> If someone wants to do OAuth 3 on not-HTTP, they can define what that looks
> like. This is what happened with the COAP/CORE stuff and OAuth 2.
>

I agree SOAP was complicated. Which features and benefits of HTTP are you
wanting to use?

If it was simple to support COAP, why would we not do that?

> It felt, to me, like that might be a bridge too far.
>

I disagree. But I also think that authentication is the wrong term.
Identity* may be a term that maps better, as the Client is wanting to get
"identity" data from the AS.

* The identity term is super confusing, but authentication implies just
knowing it is the same user, where OpenID Connect also provides claims
about the user.

> If we do decide it’s in scope, then I think it should be clearly layered
> on top of the authorization layer.
>

Being layered on top is confusing. An OpenID Connect flow where the Client
receives an ID token, has not authorization, unless you are counting the UX
as authorization -- but that does not seem like a layer. Would you
elaborate?

> Kinda. First, it’s more 6749 that I want to step away from. But even then,
> I think keeping just the header version of 6750 is OK enough if someone
> wants to keep using that. The thing is, won’t someone seeing an OAuth 2
> header assume the rest of OAuth 2 infrastructure? In some cases this won’t
> matter, but in many that could be really confusing.
>
> One of the problems, though, is that 6750 has already been clouded by
> things like the MTLS binding, where they use “bearer” tokens that have to
> be bound to the client’s certificate. So … not much of a bearer token
> anymore.
>

So, are you are you proposing that Tx have a new mechanism for API calls?

>
> Ultimately, I don’t want anything that has an error-fallthrough
> compatibility process. That is to say, I try doing OAuth 2, have that fail,
> and then try it as OAuth 3 — or vice versa.
>

Ok. I'm not even sure how that would happen, but ok.

---

From: Dick Hardt <[email-masked]>
Date: Fri, 27 Dec 2019 10:12:57 -0800

+1 for the reasons Aaron stated -- user confusion -- which is one of the
motivations of this work -- simplifying the cognitive load for developers,
and helping them get security right.

As noted in a separate message, we may want to call this "identity"

On Sun, Dec 22, 2019 at 7:46 PM Aaron Parecki <[email-masked]> wrote:

> On Sat, Dec 21, 2019 at 1:51 PM Yaron Sheffer <yaronf.ietf@gmail..com
> <[email-masked]>> wrote:
>
>> Hi Justin,
>>
>>
>>
>> *Cc: *"[email-masked] <rdd@cert..org>" <[email-masked]>, Benjamin Kaduk <
>> [email-masked]>

---

From: Dick Hardt <[email-masked]>
Date: Fri, 27 Dec 2019 10:16:40 -0800

I concur with Annabelle. Pretty much all large systems have a clear
separation between different functions to provide resiliency and improved
security (separation of duties)

Ideally we can do this without adding complexity for deployments that don't
require it.

On Sun, Dec 22, 2019 at 8:52 PM Richard Backman, Annabelle <
[email-masked]> wrote:

> My example demonstrates an architecture where the TX Endpoint,
> authentication system, and token issuer aren’t simply different micro
> services, they’re completely independent systems in different trust
> boundaries, possibly have different domains and different keys. This has
> implications for protocol design. For example, it would no longer be
> sufficient to have a single jwks_uri, as OAuth 2.0 has.
>
> If we want to support this kind of “decomposed AS” model, then we need to
> make sure that’s supported by the charter and keep it in mind as we design
> the protocol. We can also decide it is out of scope, but we should be
> intentional about that decision.
>
> To my mind, this role decomposition is the next logical step after the
> channel decomposition that TxAuth already does. I see a lot of potential in
> it and think we should at minimum avoid closing the door on it.
>
>  I think you’re conflating the *roles* that different components play,
> in regard to the other components, with the potential deployment of those
> components. The spec needs to be written in terms of the roles. While the
> roles do need to consider what potential deployments might be, it’s
> important that we write things in in terms of how they interact with each
> other and not in terms of how they might look under the covers.
>
> So from the clients perspective, the TX Endpoint :is: the AS. The client
> doesn’t care that it’s a “glorified message queue” or if it’s a massive
> server farm. The client doesn’t care if there’s a TLS reverse proxy or if
> it’s talking directly to the application layer. The only thing the client
> cares about is if the TX Endpoint does the things that a TX Endpoint is
> supposed to do, and we define that to be the function of the AS.
>
> What’s important in your scenario below is that the client would have to
> talk to the RS first every time. That’s one of the problems that UMA has,
> and I think something we should avoid. I think RS-first is an interesting
> pattern but AS-first ought to drive this.
>
> With your hypothetical layout below, it really sounds like the TX Endpoint
> is a function of the IDP, which is fine. The client doesn’t care that it’s
> deployed using some externalized cloud service. The only weird thing going
> on is the push from the AS back to the client. The client would need to
> register that with the AS (or through the AS more specifically) as part of
> its transaction request. This would be part of its interaction mechanism,
> because “how you get messages and updates back to the client” is part of
> the interaction model.
>
> The RS returns a resource handle, but the client doesn’t care where that
> came from. The RS could talk to the AS to get it. Probably a new endpoint
> of some kind, can probably use the same kinds of key binding that the TX
> Endpoint has. Or the RS can make one up that the TX Endpoint can recognize.
> Or it calls the IdP to get one. The client doesn’t care, and that’s the key
> point.
>
> WWW-Authenticate tx_endpoint=“http://server//tx
> <http://server%EF%BF%BD/tx>” resource: “asdf1234”
>
> There are probably things that need to be tied together for this to be
> secure, but I think the basic pattern still fits. Importantly, the client
> doesn’t care whereby of that stuff came from — as far as it’s concerned,
> it’s talking to the AS.
>
> Remember, the “AS” is a logical construct, not a physical one. Just like
> the “client” could be a cluster of applications and the “RS” could be a
> suite of APIs tied behind a gateway.
>
>  — Justin
>
>
> In this example, the client only interacts with the RS and the tx
> endpoint. It seems odd to me to consider the system hosting the tx endpoint
> to be the AS (or at least part of the AS), as its a glorified message queue
> with essentially no authority in this architecture.
>
> We could go a step further and remove the client’s interaction with the tx
> endpoint by having the RS return the interaction url directly (you’d need
> to secure the client nonce if you want to hide it from the RS, but that’s
> not that hard).
>
> Is the meaning of “authorization server” (or the phrase “through an
> authorization server”) flexible enough to accommodate these cases? Or are
> they considered out of scope for TxAuth?
>
>  — Justin
>
>

---

From: Dick Hardt <[email-masked]>
Date: Fri, 27 Dec 2019 10:27:31 -0800

I agree with Brian. Developers such as large enterprise customers are
going to be confused when they hear there is an OAuth 3 in the works. Some
will push pause on projects because they worry that it will be outdated
when it is released. They won't know which to deploy, even though OAuth 3
is not available.

Also, if what we are working on includes authentication / identity -- it no
longer is just delegated authorization

See inline comments below.

> That happens all the time.

And it causes market confusion all the time. Conservative organizations
stop doing things when it is not clear what the future will be.

> didn’t need or want the OAuth 2 newness, they stuck with it (see: twitter).

Twitter stuck with OAuth 1 because they did not like bearer tokens.

Yes, there was lots of confusion between OAuth 1 and 2. Erin did not want
what became OAuth 2 to be called OAuth because of the confusion. Hence it
was called WRAP early. The actual name of the WG is "Web Authorization
Protocol"

> cases that took years of dual-deployment and transition.

The work that was being done on OpenID 3 was killed because a large
platform company that starts with G did not want to confuse their customers
about a new version.

> to be there and be the right answer.

I agree that people may be confused if it is called something else that
OAuth, but if it is broader than OAuth, then that is confusing as well.

---

From: Justin Richer <[email-masked]>
Date: Sat, 28 Dec 2019 12:07:11 -0500

This is going to be the case whatever we call this new work. Progress is going to continue to happen, and if a large enterprise decides to wait for the new shiny thing 3 years from now, then that’s on them. 

In my experience, it’s more likely that a large enterprise is going to shy away from the new shiny thing and go with what they can buy in a supported package off the shelf. And I think that’s the kind of timescale that’s going to drive most of the developers decisions around whether to track the new work or use what’s out there — they need to ask “what do I need?” And “when do I need it?”

But these are :always: the questions that you need to ask when starting a project and choosing technologies. 

I still contend that the name OAuth 3 does a better job at communicating what’s going on here.

 — Justin

> On Dec 27, 2019, at 1:27 PM, Dick Hardt <[email-masked]> wrote:
> 
> I agree with Brian. Developers such as large enterprise customers are going to be confused when they hear there is an OAuth 3 in the works. Some will push pause on projects because they worry that it will be outdated when it is released. They won't know which to deploy, even though OAuth 3 is not available. 
> 
> Also, if what we are working on includes authentication / identity -- it no longer is just delegated authorization
> 
> On Tue, Dec 24, 2019 at 4:22 PM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
> And it causes market confusion all the time. Conservative organizations stop doing things when it is not clear what the future will be.
>  
> 
> Yes, there was lots of confusion between OAuth 1 and 2. Erin did not want what became OAuth 2 to be called OAuth because of the confusion. Hence it was called WRAP early. The actual name of the WG is "Web Authorization Protocol"
> 
>  
> 
> The work that was being done on OpenID 3 was killed because a large platform company that starts with G did not want to confuse their customers about a new version.
>  
> 
> I agree that people may be confused if it is called something else that OAuth, but if it is broader than OAuth, then that is confusing as well.
>  
>

---

From: Justin Richer <[email-masked]>
Date: Sat, 28 Dec 2019 12:07:39 -0500

I’d argue that it’s actually essential that the complex deployments don’t add complexity to the simple ones.

 — Justin

> On Dec 27, 2019, at 1:16 PM, Dick Hardt <[email-masked]> wrote:
> 
> I concur with Annabelle. Pretty much all large systems have a clear separation between different functions to provide resiliency and improved security (separation of duties)
> 
> Ideally we can do this without adding complexity for deployments that don't require it.
> 
> 
> On Sun, Dec 22, 2019 at 8:52 PM Richard Backman, Annabelle <[email-masked] <mailto:[email-masked]>> wrote:

---

From: Justin Richer <[email-masked]>
Date: Sat, 28 Dec 2019 12:17:08 -0500

> I still don't understand. Is one user delegating to another user? This is a desirable use case for many, but currently not standardized. Is this what you are proposing is in scope?
>  

I’m proposing that in our model, the person using the client application and the person approving the process can be different parties, depending on the nature of interaction that the client is capable of. Again, this goes into the different roles that people play. I do think that this is in scope, with the condition that in the case where they’r the same person (IE, the OAuth case), this collapses cleanly into a simpler case. UMA doesn’t do that very well, because of the nature of OAuth’s redirect-first model. We can do better here.

> I agree SOAP was complicated. Which features and benefits of HTTP are you wanting to use? 
> 

Well so far we’ve got headers, URLs, methods, data payload types, and the whole array of technologies that we can rely on working together along with HTTP.

> If it was simple to support COAP, why would we not do that?

Because it’s not just COAP — you’ve got a different set of assumptions for the lower layer protocols, and you’ve got lots of considerations about how the different components can talk to each other in the embedded space. 

In my experience, it’s much more successful to have a protocol strongly integrated with its transport mechanism and then translated out to other mechanisms, instead of trying to come up with one universal interlingua of a protocol that just get shunted along. This is why SOAP can’t use HTTP verbs to communicate things, and why the only signatures it can use are internal. When you do that kind of system, you almost always end up having people just use it with one transport anyway, like SOAP over HTTP.

> I disagree. But I also think that authentication is the wrong term. Identity* may be a term that maps better, as the Client is wanting to get "identity" data from the AS. 
> 
> * The identity term is super confusing, but authentication implies just knowing it is the same user, where OpenID Connect also provides claims about the user.

I’m coming around to this view, but I would still like it to be separate.

>  
> If we do decide it’s in scope, then I think it should be clearly layered on top of the authorization layer. 
> 
> Being layered on top is confusing. An OpenID Connect flow where the Client receives an ID token, has not authorization, unless you are counting the UX as authorization -- but that does not seem like a layer. Would you elaborate?
>  

What you’re doing in OIDC is authorizing the application to know who you are — to get your identity information. That key insight is what makes the combination of OAuth and OIDC work as well as it does. And, importantly, once you authorize identity access, you can authorize other stuff as well. And it’s the “and other stuff” that people really, really, really like about OIDC. Nobody ever wants just authorization, in practice. 

> So, are you are you proposing that Tx have a new mechanism for API calls?

Yes, I think there will be new mechanisms for different kinds of key-bound tokens.

> Ok. I'm not even sure how that would happen, but ok.

So in OAuth 2 the token parameter was originally called “oauth_token”, which is the same as in OAuth 1. But the difference is that in OAuth 2 there’s no “oauth_token_signature” field, so to support both you’d need to try to do OAuth 1, then fail, and then try to do OAuth 2. Since the nature of the tokens is completely different, I see that as a problem.

However, with this (and with how XYZ’s started things), we’ve got an opportunity to say things like “if you see this type of token response, use it with the RS according to RFC6750” or “according to this new RFC we just made up” or whatever.

---

From: Justin Richer <[email-masked]>
Date: Sat, 28 Dec 2019 12:20:05 -0500

On Dec 27, 2019, at 1:01 PM, Dick Hardt <[email-masked]> wrote:
> On Sat, Dec 21, 2019 at 4:41 AM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
> <snip>
> Why do you want the RS to request from the AS? This would require the RS to have credentials known to the AS.

Yes, I would picture the RS in this case having its own key to protect this call. It would also use that key to do introspection style calls.

> 
> Why not have the RS provide information about what the Client needs to ask the AS for, and which AS it is?
> 

If the RS can do that in a way that the AS can understand, without talking to the AS, then it can do that. It could be pre-configured (like an HTTP Auth Realm) or it could come from some internal calculation that the AS can verify. The client ultimately doesn’t care — from its perspective, it gets a resource handle that’s at least good enough to do the thing it’s trying to do at the RS, and an AS pointer (the transaction endpoint URL). Everything else flows out from those bits of information.

I think there’s a lot of value in having the RS be able to request, at runtime, a dynamic resource handle that the client can present to the AS. That’s a difference for the RS though, not the client.

 — Justin

---

From: Dick Hardt <[email-masked]>
Date: Mon, 30 Dec 2019 15:25:19 -0800

I significant difference in this case is that OAuth 3 is NOT backward
compatible with OAuth 2.

HTTP 2 was backwards compatible, as is HTTP 3 from what I understand.

This has enterprises question what they should do, and the safe answer is
do nothing. I think this is what Brian was getting at on confusion. People
are confused on what they should do. OAuth 3 not being backward compatible
implies work done with OAuth 2 may have to be thrown away.

On Sat, Dec 28, 2019 at 9:07 AM Justin Richer <[email-masked]> wrote:

> This is going to be the case whatever we call this new work. Progress is
> going to continue to happen, and if a large enterprise decides to wait for
> the new shiny thing 3 years from now, then that’s on them.
>
> In my experience, it’s more likely that a large enterprise is going to shy
> away from the new shiny thing and go with what they can buy in a supported
> package off the shelf. And I think that’s the kind of timescale that’s
> going to drive most of the developers decisions around whether to track the
> new work or use what’s out there — they need to ask “what do I need?” And
> “when do I need it?”
>
> Also, if what we are working on includes authentication / identity -- it
> no longer is just delegated authorization
>
>> Naming any prospective resulting work here "OAuth 3.0" would
>> significantly exacerbate confusion in the whole space and would be a major
>> disservice to the broader community.
>>
>>
>>>> Good news: A lot of the additional stuff in OIDC is there to patch
>>>> holes in core OAuth in a common fashion, and we’ll at least be in a
>>>> position to not have to do that again.
>>>>
>>>>
>>>>  — Justin
>>>>
>>>> I do think authentication should be part of the charter from the
>>>> outset. Frankly the fact that authentication is intentionally left out of
>>>> OAuth and has to be bolted on to the side via OpenID Connect is one of the
>>>> exact reasons people get confused about the whole space to begin with.
>>>>
>>>>> Please suggest changes to the proposed charter text above. It’s my
>>>>> hope that we can get the chartering process started.
>>>>>
>>>>>
>>>>>
>>>>>  — Justin
>>>>>

---

From: Dick Hardt <[email-masked]>
Date: Mon, 30 Dec 2019 15:25:31 -0800

I'd agree with that.

On Sat, Dec 28, 2019 at 9:07 AM Justin Richer <[email-masked]> wrote:

>> With your hypothetical layout below, it really sounds like the TX
>> Endpoint is a function of the IDP, which is fine. The client doesn’t care
>> that it’s deployed using some externalized cloud service. The only weird
>> thing going on is the push from the AS back to the client. The client would
>> need to register that with the AS (or through the AS more specifically) as
>> part of its transaction request. This would be part of its interaction
>> mechanism, because “how you get messages and updates back to the client” is
>> part of the interaction model.
>>
>> We could go a step further and remove the client’s interaction with the
>> tx endpoint by having the RS return the interaction url directly (you’d
>> need to secure the client nonce if you want to hide it from the RS, but
>> that’s not that hard).
>>

---

From: Dick Hardt <[email-masked]>
Date: Mon, 30 Dec 2019 15:36:00 -0800

On Sat, Dec 28, 2019 at 9:17 AM Justin Richer <[email-masked]> wrote:

> I still don't understand. Is one user delegating to another user? This is
> a desirable use case for many, but currently not standardized. Is this what
> I’m proposing that in our model, the person using the client application
> and the person approving the process can be different parties, depending on
> the nature of interaction that the client is capable of. Again, this goes
> into the different roles that people play. I do think that this is in
> scope, with the condition that in the case where they’r the same person
> (IE, the OAuth case), this collapses cleanly into a simpler case. UMA
> doesn’t do that very well, because of the nature of OAuth’s redirect-first
> model. We can do better here.
>

Got it. Thanks for clarifying.

> Well so far we’ve got headers, URLs, methods, data payload types, and the
> whole array of technologies that we can rely on working together along with
> HTTP.
>

But which ones do you want to use?

> Because it’s not just COAP — you’ve got a different set of assumptions for
> the lower layer protocols, and you’ve got lots of considerations about how
> the different components can talk to each other in the embedded space.
>

You are suggesting we rule out it working with COAP in the charter, before
we have even had a chance to work on it.

Perhaps it will be trivial to support COAP. We won't know if the charter
forbids it.

>
> In my experience, it’s much more successful to have a protocol strongly
> integrated with its transport mechanism and then translated out to other
> mechanisms, instead of trying to come up with one universal interlingua of
> a protocol that just get shunted along.
>

Would you provide an example besides SOAP for this?

> This is why SOAP can’t use HTTP verbs to communicate things, and why the
> only signatures it can use are internal. When you do that kind of system,
> you almost always end up having people just use it with one transport
> anyway, like SOAP over HTTP.
>
>
>
>>
>>

What does separate mean?

> What you’re doing in OIDC is authorizing the application to know who you
> are — to get your identity information. That key insight is what makes the
> combination of OAuth and OIDC work as well as it does. And, importantly,
> once you authorize identity access, you can authorize other stuff as well.
>

As I stated, there is the UX of authorizing knowing who the user is, but
there is no artifact representing that authorization as there is in OAuth
-- ie there is no access token to access a resource. (yes, an access token
may be used to read the user info endpoint, but that is all it can do.

> And it’s the “and other stuff” that people really, really, really like
> about OIDC. Nobody ever wants just authorization, in practice.
>

Did you mean to say "authentication"?

If so, then I would posit that there are more OIDC user interactions than
plain OAuth 2.0 user interactions, and that almost all of those OIDC user
interactions are just logging in with Google or Facebook -- and that there
is no "and other stuff".

>> Kinda. First, it’s more 6749 that I want to step away from. But even
>> then, I think keeping just the header version of 6750 is OK enough if
>> someone wants to keep using that. The thing is, won’t someone seeing an
>> OAuth 2 header assume the rest of OAuth 2 infrastructure? In some cases
>> this won’t matter, but in many that could be really confusing.
>>

So are you proposing that OAuth 3.0 will not support bearer tokens?

> So in OAuth 2 the token parameter was originally called “oauth_token”,
> which is the same as in OAuth 1. But the difference is that in OAuth 2
> there’s no “oauth_token_signature” field, so to support both you’d need to
> try to do OAuth 1, then fail, and then try to do OAuth 2. Since the nature
> of the tokens is completely different, I see that as a problem.
>
> However, with this (and with how XYZ’s started things), we’ve got an
> opportunity to say things like “if you see this type of token response, use
> it with the RS according to RFC6750” or “according to this new RFC we just
> made up” or whatever.
>

Got it. Agreed that we can provide a richer response that indicates how a
token (or whatever) can be used.

---

From: Justin Richer <[email-masked]>
Date: Tue, 31 Dec 2019 08:09:41 -0500

My understanding is that HTTP3 is not backwards compatible, since QUIC was built on UDP from the start and the considerations are pretty different from TCP there. 

I don’t think the safe answer is “do nothing” today because there is a large and vibrant community around OAuth 2. The safe answer is to deploy something that solves your problems.

I think that we’re going to have the imaging issue vis a vis “replacing OAuth 2” whether we call this OAuth 3 or TxAuth or whatever. Truth is for some people we will be replacing OAuth 2, and some people will be throwing out their OAuth 2 implementations (if we’re successful). But that’s the cost of tracking new technology, and it’s pretty clear to me that this work has a long ways to go.

 — Justin

> On Dec 30, 2019, at 6:25 PM, Dick Hardt <[email-masked]> wrote:
> 
> I significant difference in this case is that OAuth 3 is NOT backward compatible with OAuth 2.
> 
> This has enterprises question what they should do, and the safe answer is do nothing. I think this is what Brian was getting at on confusion. People are confused on what they should do. OAuth 3 not being backward compatible implies work done with OAuth 2 may have to be thrown away.
> 
> 
> On Sat, Dec 28, 2019 at 9:07 AM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>> On Dec 27, 2019, at 1:27 PM, Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Justin Richer <[email-masked]>
Date: Tue, 31 Dec 2019 13:36:55 -0500

And just to reiterate a previous point — as much as I want to make the case for calling this work OAuth 3, it’s not something I’m going to die for. The work is way more important than the name. 

So with that, I would propose that we basically punt on naming things until that becomes important. I say we name both the working group and the first document “TxAuth”, and keep this mailing list as its base.

If the working group decides in a couple years that this really should be renamed, we can do that. It’s happened before — and again I’m calling to the model of HTTP/3. It started as QUIC in the QUIC working group, and a year ago the QUIC working group decided to rename it to HTTP/3, with the coordination and blessing of the HTTP working group. Once QUIC group winds down, the HTTP/3 protocol will come under the stewardship of the HTTP working group. I can easily see a similar pattern happening here, where we create TxAuth and eventually it gets handed over to the OAuth WG.

 — Justin

> On Dec 31, 2019, at 8:09 AM, Justin Richer <[email-masked]> wrote:
> 
>> On Dec 30, 2019, at 6:25 PM, Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Aaron Parecki <[email-masked]>
Date: Tue, 31 Dec 2019 10:42:06 -0800

I agree with Justin's point that the name is not important right now.

That said, OAuth 2 was not backwards compatible with OAuth 1 by
design, so I would expect the same to be true for if and when OAuth 3
ends up becoming a thing, whatever form it takes.

As for the points on market confusion, this TXAuth work is going to
happen regardless of whether the OAuth WG wants it to, either at the
IETF or not, and in my opinion it would have worse effects in the
market if the OAuth WG did not acknowledge it and didn't indicate an
eventual plan that this work would subsume OAuth 2. That would just
lead to a situation where people are forced to implement and maintain
both an OAuth 2 and TXAuth system, not because of existing
deployments, but because there would be no clear indication that
TXAuth is the best path for OAuth-like systems going forward.

----
Aaron Parecki
aaronparecki.com

On Tue, Dec 31, 2019 at 10:37 AM Justin Richer <[email-masked]> wrote:
>>>>> @aaronpk
>>>> @aaronpk

---

From: Dick Hardt <[email-masked]>
Date: Tue, 31 Dec 2019 10:50:58 -0800

The name is important in that calling it OAuth 3 at this point in time will
create market uncertainty.

I agree that this work is the successor of OAuth-like systems.
I would hope that it is also the successor of OIDC-like systems.

I'm confused about Aaron's comments about the OAuth WG wrt. market
confusion.

HTTP3 is backwards compatible with HTTP2 and HTTP 1.x from the developers
point of view. The same verbs, headers etc. all work. The interface for
developers is the same. What is on the wire is different.

This work will not be compatible from a developers point of view wrt. OAuth
2.0

On Tue, Dec 31, 2019 at 10:42 AM Aaron Parecki <[email-masked]> wrote:

> > And just to reiterate a previous point — as much as I want to make the
> case for calling this work OAuth 3, it’s not something I’m going to die
> for. The work is way more important than the name.
> >
> > So with that, I would propose that we basically punt on naming things
> until that becomes important. I say we name both the working group and the
> first document “TxAuth”, and keep this mailing list as its base.
> >
> > If the working group decides in a couple years that this really should
> be renamed, we can do that. It’s happened before — and again I’m calling to
> the model of HTTP/3. It started as QUIC in the QUIC working group, and a
> year ago the QUIC working group decided to rename it to HTTP/3, with the
> coordination and blessing of the HTTP working group. Once QUIC group winds
> down, the HTTP/3 protocol will come under the stewardship of the HTTP
> working group. I can easily see a similar pattern happening here, where we
> create TxAuth and eventually it gets handed over to the OAuth WG.
> >
> >  — Justin
> >
> > My understanding is that HTTP3 is not backwards compatible, since QUIC
> was built on UDP from the start and the considerations are pretty different
> from TCP there.
> >
> > I don’t think the safe answer is “do nothing” today because there is a
> large and vibrant community around OAuth 2. The safe answer is to deploy
> something that solves your problems.
> >
> > I think that we’re going to have the imaging issue vis a vis “replacing
> OAuth 2” whether we call this OAuth 3 or TxAuth or whatever. Truth is for
> some people we will be replacing OAuth 2, and some people will be throwing
> out their OAuth 2 implementations (if we’re successful). But that’s the
> cost of tracking new technology, and it’s pretty clear to me that this work
> has a long ways to go.
> >
> >  — Justin
> >
> > This has enterprises question what they should do, and the safe answer
> is do nothing. I think this is what Brian was getting at on confusion.
> People are confused on what they should do. OAuth 3 not being backward
> compatible implies work done with OAuth 2 may have to be thrown away.
> >
> >
> >> This is going to be the case whatever we call this new work. Progress
> is going to continue to happen, and if a large enterprise decides to wait
> for the new shiny thing 3 years from now, then that’s on them.
> >>
> >> In my experience, it’s more likely that a large enterprise is going to
> shy away from the new shiny thing and go with what they can buy in a
> supported package off the shelf. And I think that’s the kind of timescale
> that’s going to drive most of the developers decisions around whether to
> track the new work or use what’s out there — they need to ask “what do I
> need?” And “when do I need it?”
> >>
> >> Also, if what we are working on includes authentication / identity --
> it no longer is just delegated authorization
> >>
> >>> Who would be confused by seeing a major revision to an existing
> protocol that worked in a different way and did the same things but also
> new things? That happens all the time.
> >>
> >>
> >>> Was there significant confusion between OAuth 1 and 2, enough to
> hamper adoption of either? For the people who deeply invested in OAuth 1
> and didn’t need or want the OAuth 2 newness, they stuck with it (see:
> twitter).
> >>
> >>
> >> Yes, there was lots of confusion between OAuth 1 and 2. Erin did not
> want what became OAuth 2 to be called OAuth because of the confusion. Hence
> it was called WRAP early. The actual name of the WG is "Web Authorization
> Protocol"
> >>
> >>
> >>>
> >>>
> >>> Was OpenID Connect a major disservice to OpenID 2? It was a
> disruption, for sure, but people transitioned where it made sense for them,
> and in many cases that took years of dual-deployment and transition.
> >>
> >>
> >>> I see us walking along the same kind of path here, nearly a decade
> later. That’s why I think OAuth 3 makes sense as a name for the output of
> this work. Or at the very least, for the core delegation protocol portion
> of whatever we make. I think it sends the right message to implementers and
> >>>> I definitely am not trying to discuss specifics of *how*
> authentication should be included right now, but I just want to make sure
> it's included in the charter so that we can actually talk about it and it
> won't be "out of scope" when we eventually do talk about the specifics.
> >>>>
> >>>> Aaron
> >>>>
> >>>>
> >>>>
> >>>>> I’m fine with it being in charter but I do think it should be a
> clearly separate layer, much like OIDC/Facebook Connect/GitHub Login/etc
> are with OAuth today. In all of these the authorization is first, and I
> think that’s the right pattern. So if we do take it on we’ll just need to
> be careful how it’s structured in with everything else. Otherwise, I think
> the authentication side can quickly overwhelm and drag down the
> authorization side.
> >>>>>
> >>>>> It's a relatively minor addition to the existing proposed spec to
> make it useful as a minimum viable authentication solution, and I'd like to
> see that be addressed at the beginning of this work.
> >>>>>
> >>>>>> I think the charter should mention target use cases. For example,
> “all use cases supported by OAuth 2 will be supported by the new protocol”
> or “the protocol will support at least use cases X and Y”.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> As discussed in Singapore, no matter what forum TxAuth takes, its
> work will require a new charter. With that in mind, I’ve taken a bit of
> time to put together a proposed charter text for the TxAuth work:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> The group will deliver a protocol specification detailing how a
> client can request and obtain delegated access, how an authorization server
> can provide delegated access, how an authorized party can authorize
> delegated access, and how that authorized access can be communicated to the
> resources being protected. These actions will be connected through an
> explicit transaction between the client and authorization server, resulting
> in an artifact that will allow the client to undertake the delegated action.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> While this work could be done in within the OAuth working group, I
> now believe that it should be done in a new working group, and that we
> should try to get that working group up and running prior to the Vancouver
> meeting in March. I think this group should stay here on the TxAuth list,
> and it’s my suggestion that the resulting work be called OAuth 3.0.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> https://medium.
> .com/@justinsecurity/the-case-for-oauth-3-0-why-a-new-working-group-d6229ba8e36?
> >>>>>>
> >>>>>>
> >>>>>>
> >>> CONFIDENTIALITY NOTICE: This email may contain confidential and
> your computer. Thank you.
> >>>
> >>>
> >>> --
> >>> Txauth mailing list
> >>> [email-masked]

---

From: Justin Richer <[email-masked]>
Date: Tue, 31 Dec 2019 14:01:22 -0500

> But which ones do you want to use?

Those things that I already listed are what I want to use. I want to use the headers for sending key proofs and probably content negotiation. I want to have content negotiation so that we can have an option to use JOSE (or COSE) as the body format instead of JSON, but that function switch should come from the transport protocol (HTTP) and not something internal to our protocol. I want to be able to use redirects to get the user to interact, and get back from the interaction. I want to (eventually) do things like token revocation using a DELETE verb instead of a separate endpoint. I want to use HTTP Message Signatures (once they exist) as a key presentation mechanism. And I want our security considerations to be able to take into account the particulars of HTTP, TLS, and the like when we write them.

> You are suggesting we rule out it working with COAP in the charter, before we have even had a chance to work on it.
> 
> Perhaps it will be trivial to support COAP. We won't know if the charter forbids it.

If it turns out to be trivial and people want to include it and do the work here, then we could always update the charter to include it. I would rather see that than us trying to enumerate all of the target carrier mechanisms. Because if we do COAP, why not MQTT? Or BluetoothLE? 

If we include COAP, then to my mind that necessitates one of two things, if not both:

1) We have a document that says “IF you’re doing HTTP do (A) if you’re doing COAP do (B)”
2) We have an “abstract” document that says “here’s this thing but for details on how to do it go read the HTTP document and/or the COAP document”, but when you read the HTTP or COAP documents, they don’t have any information about what the thing is because it’s in the abstract. 

From a developer’s perspective, I would rather have an HTTP document be self-contained, and a COAP document be self-contained. And if the two describe the same process, or one inherits from the other but says “instead of doing HTTP thing X do COAP equivalent Y”, then that’s good. 

But overly abstracting a system is both tempting and potentially disastrous. 

>  
> 
> In my experience, it’s much more successful to have a protocol strongly integrated with its transport mechanism and then translated out to other mechanisms, instead of trying to come up with one universal interlingua of a protocol that just get shunted along.
> 

It’s the most egregious example that comes to mind for me, so that’s why I keep coming back to it. I also have in mind a dozen projects that never went anywhere, and nobody’s heard of, because of an outmoded effort being put into defining abstractions ahead of time in order to allow transport-agnostic messaging. 

A similar level of overly-eager abstraction went into JOSE, with the JWA document. It makes it so that JWS, JWE, and JWK make no sense without JWA, and JWA is just a collection of content that really should have been included inline with the other documents. 

I want to avoid that kind of thing.

>  
> This is why SOAP can’t use HTTP verbs to communicate things, and why the only signatures it can use are internal. When you do that kind of system, you almost always end up having people just use it with one transport anyway, like SOAP over HTTP.
> 
>>  
>> 
>>> 

It means that the bits that say “this is how you talk about identity information in the response” are controlled by a separate spec that not everyone needs to understand. I think there are too many use cases of wanting to get API access and NOT user information for it to be a core piece. 

However, this is arguably getting into the details of how to slice up different documents, which is really a decision to be made once the WG is running and not during the charter. 

> What you’re doing in OIDC is authorizing the application to know who you are — to get your identity information. That key insight is what makes the combination of OAuth and OIDC work as well as it does. And, importantly, once you authorize identity access, you can authorize other stuff as well.
> 
> 
> As I stated, there is the UX of authorizing knowing who the user is, but there is no artifact representing that authorization as there is in OAuth -- ie there is no access token to access a resource. (yes, an access token may be used to read the user info endpoint, but that is all it can do. 
>  
> And it’s the “and other stuff” that people really, really, really like about OIDC. Nobody ever wants just authorization, in practice. 
> 
> If so, then I would posit that there are more OIDC user interactions than plain OAuth 2.0 user interactions, and that almost all of those OIDC user interactions are just logging in with Google or Facebook -- and that there is no "and other stuff".
> 

Yes, I meant authentication, thank you. 

I’m not sure it’s true, but I’ll agree that it’s more public-facing. But even if what you posit is actually true by raw numbers, it’s not universal. In particular, there are a large number of system-to-system cases that OAuth 2 covers, which have nothing to do with identity, that we don’t want to throw out.

> So are you proposing that OAuth 3.0 will not support bearer tokens?

That is not correct and I’m not sure where you got that. Bearer tokens are still useful. But they should look and behave as distinct from sender-constrained tokens. But ultimately we can tell the client how the token gets used, as below.

> Got it. Agreed that we can provide a richer response that indicates how a token (or whatever) can be used.

Exactly. I should give you all the information on how to use the artifact alongside of the artifact itself. It’ll also give us a way to do server-side provisioning of keys bound to the tokens themselves. So I can generate a public/private keypair at the AS and hand it to the client, but I only save the public portion so that the RS can eventually validate it. (Or I do key wrapping or pack it into the token so I don’t have to save anything.) This is particularly useful for disadvantaged clients, which you’ve said above you’d like to be in scope anyway. ;)

 — Justin

---

From: Dick Hardt <[email-masked]>
Date: Tue, 31 Dec 2019 12:40:59 -0800

On Tue, Dec 31, 2019 at 11:01 AM Justin Richer <[email-masked]> wrote:

>>> Because I want us to use all of the features and benefits of HTTP
>>> instead of having to invent within-protocol functions to replicate them. I
>>> don’t want SOAP, which pretends to be transport agnostic much to its
>>> detriment. If someone wants to do OAuth 3 on not-HTTP, they can define what
>>> that looks like. This is what happened with the COAP/CORE stuff and OAuth 2.
>>>
>>
> Those things that I already listed are what I want to use. I want to use
> the headers for sending key proofs and probably content negotiation. I want
> to have content negotiation so that we can have an option to use JOSE (or
> COSE) as the body format instead of JSON, but that function switch should
> come from the transport protocol (HTTP) and not something internal to our
> protocol. I want to be able to use redirects to get the user to interact,
> and get back from the interaction. I want to (eventually) do things like
> token revocation using a DELETE verb instead of a separate endpoint. I want
> to use HTTP Message Signatures (once they exist) as a key presentation
> mechanism. And I want our security considerations to be able to take into
> account the particulars of HTTP, TLS, and the like when we write them.
>

Thanks for clarifying. I agree that using the http content-type header, and
http verbs is preferable to inventing new mechanisms.

>> Because it’s not just COAP — you’ve got a different set of assumptions
>> for the lower layer protocols, and you’ve got lots of considerations about
>> how the different components can talk to each other in the embedded space.
>>
>
> If it turns out to be trivial and people want to include it and do the
> work here, then we could always update the charter to include it. I would
> rather see that than us trying to enumerate all of the target carrier
> mechanisms. Because if we do COAP, why not MQTT? Or BluetoothLE?
>
> 2) We have an “abstract” document that says “here’s this thing but for
> details on how to do it go read the HTTP document and/or the COAP
> document”, but when you read the HTTP or COAP documents, they don’t have
> any information about what the thing is because it’s in the abstract.
>
> From a developer’s perspective, I would rather have an HTTP document be
> self-contained, and a COAP document be self-contained. And if the two
> describe the same process, or one inherits from the other but says “instead
> of doing HTTP thing X do COAP equivalent Y”, then that’s good.
>

I agree completely.

> But overly abstracting a system is both tempting and potentially

I agree.

I align with the design tenet:

"Easy things should be easy, hard things should be possible" -- Larry Wall

If the WG has a choice between A and B, and they all other things are equal
for an HTTP implementation, but B is much better for COAP, then I would
suggest we choose B.

I'm not saying COAP support should be a priority, I'm saying we should not
completely ignore it.

> It’s the most egregious example that comes to mind for me, so that’s why I
> keep coming back to it. I also have in mind a dozen projects that never
> went anywhere, and nobody’s heard of, because of an outmoded effort being
> put into defining abstractions ahead of time in order to allow
> transport-agnostic messaging.
>
> A similar level of overly-eager abstraction went into JOSE, with the JWA
> document. It makes it so that JWS, JWE, and JWK make no sense without JWA,
> and JWA is just a collection of content that really should have been
> included inline with the other documents.
>

Agreed

> It means that the bits that say “this is how you talk about identity
> information in the response” are controlled by a separate spec that not
> everyone needs to understand. I think there are too many use cases of
> wanting to get API access and NOT user information for it to be a core
> piece.
>

Some developers only care about identity. Some only care about API access.
It should be easy for both.

>
> However, this is arguably getting into the details of how to slice up
> different documents, which is really a decision to be made once the WG is
> running and not during the charter.
>

Currently, identity is not in scope of the charter, which is why I am
bringing it up.

>> Being layered on top is confusing. An OpenID Connect flow where the
>> Client receives an ID token, has not authorization, unless you are counting
>> the UX as authorization -- but that does not seem like a layer. Would you
>> elaborate?
>>
>>
>>
> I’m not sure it’s true, but I’ll agree that it’s more public-facing. But
> even if what you posit is actually true by raw numbers, it’s not universal.
> In particular, there are a large number of system-to-system cases that
> OAuth 2 covers, which have nothing to do with identity, that we don’t want
> to throw out.
>

I'm not suggesting that those use cases should be thrown out, nor second
class.

> That is not correct and I’m not sure where you got that. Bearer tokens are
> still useful. But they should look and behave as distinct from
> sender-constrained tokens. But ultimately we can tell the client how the
> token gets used, as below.
>

It was not clear from your response, as a new mechanism could mean that the
old one is not used anymore.

To clarify, you expect there will be additional mechanisms.

/Dick