Subject: Re: [Txauth] Framework vs Protocol

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Fri, 3 Jan 2020 00:18:32 +0000

OAuth 2.0’s design resulted in wildly different protocol messages and communication sequences for different use cases. I strongly agree that this is something we should avoid with TxAuth. I like the idea of including this as a tenet within the charter. (+1 for more tenets and less mechanics/methodology in the charter in general)

The current document seems to do a better job of laying out a core message and communication pattern, but it doesn’t align well with the implicit grant. We will want to dig into persistent use cases for implicit (e.g., Brian Campbell’s use case in this OAuth mailing list thread<https://mailarchive.ietf.org/arch/msg/oauth/RucZHKuRf6HCsWUyJDK0XRwub3w>) to see if the TxAuth pattern can serve them, or if there are gaps that need to be filled.

–
Annabelle Richard Backman
AWS Identity

From: Txauth <[email-masked]> on behalf of Justin Richer <[email-masked]>
Date: Tuesday, December 31, 2019 at 11:13 AM
To: Dick Hardt <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Txauth] Framework vs Protocol

Answers inline.

On Dec 31, 2019, at 2:00 PM, Dick Hardt <[email-masked]<mailto:[email-masked]>> wrote:

A couple questions inserted to understand what you are suggesting ....

On Tue, Dec 31, 2019 at 5:06 AM Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:
I agree with this. I think that with OAuth2 the extension mechanism of grant types was a decent idea, and I’ve argued that it leads to significant amounts of code-reuse from very different systems that function in very different ways.

But I also think that what I’d like to see here, and what I’ve tried to do with XYZ, is to have one protocol that lets you branch off for different use cases where necessary but still brings you back to the same process in the end.

"... brings you back to the same process in the end." -- implies something different than below where the process may branch off and end up in a different place. Would you clarify what you mean?

I didn’t mean to imply that you’d end up somewhere else, but rather that you’d potentially take a detour through some other mechanism and come back to the same thing that you started. So I start by making an HTTP call, and then maybe I blip out a number over my speaker, or I send a DIDComm message to an agent on my device, or I redirect the user off in some browser thing — but then eventually I go back to making an HTTP call. The variability is in the middle part, where the user interaction is involved. The variability should not be in how the clients talk to other systems.

This is one of the things I like about having the AS defined as the transaction endpoint — everyone goes to one place and sends one kind of message to start things off, and then you have everything you need to figure out where to go from there, even if it’s off-HTTP and out-of-band.

A way to start the transaction in COAP would likely be interesting to the constrained environment people. Would you not agree?

I totally agree. And they’d also want to continue and finish the transaction in COAP. And be able to do redirects using COAP principles instead of HTTP principles. And generally do things that are similar but not the same. So it turns into a different protocol with the same ideas, and I’m all for that happening — but I don’t think it’s a good idea to put it all in the same document, or to have an abstract document that everyone tries to inherit from.

We know we need and want HTTP, so to me that’s firmly in-scope. Other protocols are “wouldn’t it be nice if it did this” right now, and abstracting for something that “would be nice” leads to bad system design.

I’m not against COAP, but like with OAuth and ACE, I don’t think it’s good to try and cram them together this early.

 — Justin

> On Dec 30, 2019, at 7:20 PM, Dick Hardt <[email-masked]<mailto:[email-masked]>> wrote:
>
> I would propose that the resulting work is a protocol, and not a framework.
>
> What is the difference? Here are my thoughts:
>
> A framework defines a variety of ways to do each capability. A framework usually needs a profile for two systems to interoperate. For example, OIDC provides a number of ways to get identity data from an OP, and OAuth 2 grant types have overlap. A framework is like Perl. Lots of ways to do the same thing, many of which are unreadable.
>
> A protocol provides one way to do each capability.  A protocol is like Python, there is a right way to do something.
>
> At times a standards group will get "consensus" by not being decisive, and including everyone's favored mechanism. In my opinion, this makes deployments more complicated for average developers, and increases the surface area to secure.
>
> Do others agree with adding this as a tenet to the charter?
>
> /Dick
>
> Note: I'm a fan of both Perl and Python. =)
>
> --
> Txauth mailing list
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/txauth

---

From: David Waite <[email-masked]>
Date: Fri, 3 Jan 2020 01:27:31 -0700

> On Jan 2, 2020, at 5:18 PM, Richard Backman, Annabelle <richanna=[email-masked]> wrote:
> The current document seems to do a better job of laying out a core message and communication pattern, but it doesn’t align well with the implicit grant. We will want to dig into persistent use cases for implicit (e.g., Brian Campbell’s use case in this OAuth mailing list thread <https://mailarchive.ietf.org/arch/msg/oauth/RucZHKuRf6HCsWUyJDK0XRwub3w>) to see if the TxAuth pattern can serve them, or if there are gaps that need to be filled.

My understanding is that most complications are due to the compatibility and migration that comes from the WG recommending against front-channel/implicit patterns in the front channel for OAuth 2. I don’t think these use cases would have been precluded in a world where only code flow had been standardized, and where technologies to make code flow viable at initial OAuth 2 standardization had been available (such as CORS). Since we now live in that world and are talking about an incompatible protocol, I don’t believe these sorts of compatibility or migration considerations apply.

The only use case I know of indirectly pushing for implicit is OIDC self-issued use case. I would instead describe this as pushing to solve several new use cases at once:

1. Use of a local (e.g. non-globally reachable) OP
2. Communication when the client and the OP cannot establish direct network communication, such as when both exist sandboxed on a local device
3. Defining and mandating client and OP security policy to fit into the model of the above two points, 

I personally don’t think the mechanics self-issued OIDC leverages (custom URL redirects and/or localhost listeners) has appropriate security or privacy considerations. There are actually zero security or privacy considerations regarding self-issued, which I find somewhat disappointing.

I also know that one mobile OS vendor has explicitly recommended against developers using custom URL schemes to solve new use cases, strongly recommending mechanisms such as claimed HTTPS URLs be used instead. This vendor has has also gradually increased the complexity and restrictions for custom URL use by application developers. In my opinion, there is risk in new use of custom URL schemes for local IPC. It is likely not a coincidence that custom URL schemes are chosen as they are historically the only cross-platform local IPC mechanism without privacy controls, user consent, and and other usability restrictions placed upon them.

It is also worth mentioning that OIDC self-issued does not have provisions to gain authorization, which might make it difficult to consider it in scope for this group’s charter.

-DW

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Fri, 3 Jan 2020 18:58:44 +0000

I haven’t seen a detailed analysis of how implicit use cases would map onto TxAuth, so while I think you are correct I’m not yet confident that the only challenges are migration related, and that there aren’t still some important edge cases lurking in the implicit space that aren’t well served by the TxAuth approach.

I generally agree that OIDC self-issued OP is conflating several different problems that would be better addressed on an individual basis. Though it does demonstrate how TxAuth’s dependency on a transaction endpoint reachable by the client favors external identity solutions over those under the direct control of the end user.

–

From: David Waite <[email-masked]>
Date: Friday, January 3, 2020 at 12:27 AM
To: "Richard Backman, Annabelle" <[email-masked]>
Cc: Justin Richer <[email-masked]>, Dick Hardt <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [UNVERIFIED SENDER] Re: [Txauth] Framework vs Protocol

On Jan 2, 2020, at 5:18 PM, Richard Backman, Annabelle <richanna=[email-masked]<mailto:richanna=[email-masked]>> wrote:
The current document seems to do a better job of laying out a core message and communication pattern, but it doesn’t align well with the implicit grant. We will want to dig into persistent use cases for implicit (e.g., Brian Campbell’s use case in this OAuth mailing list thread<https://mailarchive.ietf.org/arch/msg/oauth/RucZHKuRf6HCsWUyJDK0XRwub3w>) to see if the TxAuth pattern can serve them, or if there are gaps that need to be filled.

-DW

---

From: Justin Richer <[email-masked]>
Date: Mon, 6 Jan 2020 11:08:12 -0500

I don’t think “alignment with the implicit grant” should be a goal here. I think addressing the same use cases as the implicit grant is good, but for that we’ve got a lot better tools today than we did a decade ago, and we don’t need to make the same mistakes in new work just for the sake of aligning it. 

The self-issued OP model does a decent enough job of using what tools were there at the time to get around OIDC’s limitations, but I think there’s a much better approach available to us here. 

And in all truth, the answer might be “something else entirely”. We can’t solve every problem and use case, and I don’t think it does this work any favors to over-generalize it at the expense of a set of things we do understand. Grounding us like that is one of the reasons that I put the “transactional” language in the proposed charter text. I am proposing that we approach not just a certain set of problems but do so in a particular way, without necessarily presuming the solution. I think we would all want this new work to be focused on something tractable.

 — Justin

> On Jan 3, 2020, at 1:58 PM, Richard Backman, Annabelle <[email-masked]> wrote:
> 
>> On Jan 2, 2020, at 5:18 PM, Richard Backman, Annabelle <richanna=[email-masked] <mailto:richanna=[email-masked]>> wrote:

---

From: Dick Hardt <[email-masked]>
Date: Mon, 6 Jan 2020 13:33:53 -0800

On Mon, Jan 6, 2020 at 8:08 AM Justin Richer <[email-masked]> wrote:

> <snip>
> And in all truth, the answer might be “something else entirely”. We can’t
> solve every problem and use case, and I don’t think it does this work any
> favors to over-generalize it at the expense of a set of things we do
> understand. Grounding us like that is one of the reasons that I put the
> “transactional” language in the proposed charter text. I am proposing that
> we approach not just a certain set of problems but do so in a particular
> way, without necessarily presuming the solution. I think we would all want
> this new work to be focused on something tractable.
>

I completely agree we don't want to solve every problem and use case, and
we need to scope the problem space in some way.

As I've thought about the term "transaction", it seems to be a misnomer,
particularly when database semantics are applied, where a transaction is
all or nothing.

As I understand it, we would like the client to request scoped access to
multiple resources. Not all of the request is required, which is not
aligned with the definition of transaction above.

Additionally, in the XYZ draft, the transaction handle is used to refresh
tokens. I would consider this a new interaction, as the AS will be running
policy again, and the refresh may be denied.

I don't have a better suggestion at this time, but "transaction" does not
quite seem right.

/Dick
ᐧ

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Tue, 7 Jan 2020 00:13:06 +0000

It’s not about aligning with implicit grant (I agree that should not be a goal), it’s about ensuring that the use cases being served by implicit grant today can be met by TxAuth or can be dismissed as out of scope, and being intentional about any decisions toward the latter.

–

From: Justin Richer <[email-masked]>
Date: Monday, January 6, 2020 at 8:09 AM
To: "Richard Backman, Annabelle" <[email-masked]>
Cc: David Waite <[email-masked]>, Dick Hardt <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [UNVERIFIED SENDER] [Txauth] Framework vs Protocol

 — Justin

On Jan 3, 2020, at 1:58 PM, Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>> wrote:

–

From: David Waite <[email-masked]<mailto:[email-masked]>>
Date: Friday, January 3, 2020 at 12:27 AM
To: "Richard Backman, Annabelle" <[email-masked]<mailto:[email-masked]>>
Cc: Justin Richer <[email-masked]<mailto:[email-masked]>>, Dick Hardt <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [UNVERIFIED SENDER] Re: [Txauth] Framework vs Protocol

-DW

---

From: Justin Richer <[email-masked]>
Date: Wed, 8 Jan 2020 13:23:25 -0500

I’m definitely in line with that approach. SPA’s are arguably much bigger today than they were when the implicit grant started, but as a consequence we’ve also got much better tooling to manage them. I would recommend that we as a group don’t talk about them in terms of “the implicit grant” but rather the aspects of the use cases we’re looking to solve. 

 -  Justin

> On Jan 6, 2020, at 7:13 PM, Richard Backman, Annabelle <[email-masked]> wrote:
> 
>> On Jan 3, 2020, at 1:58 PM, Richard Backman, Annabelle <[email-masked] <mailto:[email-masked]>> wrote:
>>  
>> From: David Waite <[email-masked] <mailto:[email-masked]>>
>> To: "Richard Backman, Annabelle" <[email-masked] <mailto:[email-masked]>>
>> Cc: Justin Richer <[email-masked] <mailto:[email-masked]>>, Dick Hardt <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>

---

From: Justin Richer <[email-masked]>
Date: Wed, 8 Jan 2020 13:23:33 -0500

> On Jan 6, 2020, at 4:33 PM, Dick Hardt <[email-masked]> wrote:
> 
> 
> On Mon, Jan 6, 2020 at 8:08 AM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
> <snip>
> I completely agree we don't want to solve every problem and use case, and we need to scope the problem space in some way.
> 
> As I've thought about the term "transaction", it seems to be a misnomer, particularly when database semantics are applied, where a transaction is all or nothing. 
> 
> As I understand it, we would like the client to request scoped access to multiple resources. Not all of the request is required, which is not aligned with the definition of transaction above. 
> 
> Additionally, in the XYZ draft, the transaction handle is used to refresh tokens. I would consider this a new interaction, as the AS will be running policy again, and the refresh may be denied. 
> 
> I don't have a better suggestion at this time, but "transaction" does not quite seem right.
> 

As I’ve said before, naming things is hard. I think “transactional” has many aspects that fit, and some connotations that don’t. 

I stuck to the word “transaction” because for me it captured an aspect that I hadn’t seen reified in this work before: that there is an ongoing process between parties who are exchanging things, passing information back and forth over time. The RO and client both provide information to the AS to modify the request over time, and the AS can respond with what it thinks is needed next. So it’s like a commercial transaction in some ways: “I want to buy that gum”, “that’ll be $0.50”, “here’s the money”, “here’s your change”, etc. It’s a conversation between parties, but a specific one in that one party (the client) is trying to get something (a token) from another party (the AS). This doesn’t mean that I think this only fits financial APIs — you’ll notice that the API didn’t come into the conversation at all here. 

But in a way the “transactions” in XYZ are all or nothing, in the end. You get a token or you don’t, at the end of things. But more importantly, there’s an explicit “I’m starting now” step with the transaction request, and the explicit “I’m continuing something that I already started” with the transaction handle. In XYZ, the request creates something, what I’m calling a transaction, and that ultimately results in something else, what I’m calling a token. If something goes amiss, like the user denies the request or the client asks for more than it’s allowed to, then the transaction stops. The fact that the client doesn’t get everything it asked for doesn’t mean the transaction failed, it just means the results were modified by something within the process. 

So it’s not just the database sense, and it’s not just the commerce sense either. Neither is a perfect fit, though, I totally admit. If we had a better name for it I’d be all for picking something that’s more descriptive, but nothing I’ve heard or thought of matches the process better than “transaction” for me. 

 — Justin

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Wed, 8 Jan 2020 18:34:05 +0000

I agree. I’m not overly concerned about SPAs fitting into the TxAuth model, as I think we have a pretty solid path for that, as illustrated by the push for SPAs to adopt authorization code grant. I suspect in most cases, SPAs and other clients that are still doing implicit grant are doing so because that’s what they built 3 years ago and they don’t have a compelling reason to change. It’s not clear to me that this is the case for all uses of implicit grant today, and I think it’s worth poking around in this space a bit to understand if there are any use cases lurking there that we think should be covered by TxAuth, or if we’re comfortable saying they are unsupported.

Deciding how to support those use cases (if any) is another matter. The answer shouldn’t be “add an implicit style flow to TxAuth.” :-/

–

Date: Wednesday, January 8, 2020 at 10:24 AM

 -  Justin

On Jan 6, 2020, at 7:13 PM, Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>> wrote:

–

From: Justin Richer <[email-masked]<mailto:[email-masked]>>
Date: Monday, January 6, 2020 at 8:09 AM
To: "Richard Backman, Annabelle" <[email-masked]<mailto:[email-masked]>>
Cc: David Waite <[email-masked]<mailto:[email-masked]>>, Dick Hardt <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [UNVERIFIED SENDER] [Txauth] Framework vs Protocol

 — Justin

–

-DW

---

From: Aaron Parecki <[email-masked]>
Date: Wed, 8 Jan 2020 12:39:14 -0600

This is a very good description of the motivation for using the term,
and it would be great to include this description in the abstract or
elsewhere in the spec!

----
Aaron Parecki
aaronparecki.com

On Wed, Jan 8, 2020 at 12:24 PM Justin Richer <[email-masked]> wrote:
> [email-masked]

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Wed, 8 Jan 2020 19:10:18 +0000

Transaction is still a heavily overloaded term and there’s a lot of room for confusion, as illustrated by the naming conversation. The fact that RAR has use cases for authorizing distinct (e.g., financial) transactions as opposed to more traditional general access to a resource does not help. I don’t have a better alternative though. The one word that comes to mind that I think better captures what you’re describing is “session”, but that’s arguably just as overloaded as transaction. 🤷🏻‍♀️

The conversation around implicit grant has me thinking though… The value of TxAuth comes from the isolation of the core protocol from the external communication channels. A lot of OAuth 2.0's problems arise from tight coupling between the protocol and the communication channel between the user agent and the AS, which is ironic considering the UA/AS interaction is explicitly outside the scope of the protocol! Shoving authorization requests into redirect URLs constrains us in terms of request structure and size, and forces us to protect requests as they go through untrusted channels. Likewise with authorization responses.

In contrast, TxAuth always runs everything over the connection between the client and AS, bridging into other channels in minimal ways, only as needed.  This gives rise to the "handle" as the minimum piece of information needed to be transmitted across other channels, which in turn leads to the "transaction" concept. Also, since we're no longer constrained by more limited channels, we can start making complex structured requests, which enables all the other fun things TxAuth supports, such as inline client registration and key establishment, rich authorization requests, etc. But again, all of this comes from the consistent use of the client-AS channel, and the decoupling of the protocol from other channels.

I don't know if there is a way to capture this in a name (and don't really want to get back into the naming conversation), but I think it's a useful perspective for the "framework" vs "protocol" discussion. A lot of OAuth 2.0's "frameworkness" comes from its coupling with various channels. OAuth 2.0 plus Device Flow plus PAR starts to resemble SAML, with a variety of "bindings" for authentication requests and responses. We can and should avoid that with TxAuth by emphasizing channel decoupling: protocol messages only go between the client and the AS, and other channels are only used in an "artifact binding" style.

– 

On 1/8/20, 10:39 AM, "Aaron Parecki" <[email-masked]> wrote:

    ----
    Aaron Parecki
    aaronparecki.com

---

From: Brian Campbell <[email-masked]>
Date: Thu, 9 Jan 2020 16:26:34 -0700

On Thu, Jan 2, 2020 at 5:18 PM Richard Backman, Annabelle <richanna=
[email-masked]> wrote:

> The current document seems to do a better job of laying out a core message
> and communication pattern, but it doesn’t align well with the implicit
> grant. We will want to dig into persistent use cases for implicit (e.g.,
> Brian Campbell’s use case in this OAuth mailing list thread
> <https://mailarchive.ietf.org/arch/msg/oauth/RucZHKuRf6HCsWUyJDK0XRwub3w>)
> to see if the TxAuth pattern can serve them, or if there are gaps that need
> to be filled.
>

I guess takeaway I'd point to from that is less about the implicit grant
per se and more to suggest/remind that this space has had variations on
front channel pass everything by value and pass by reference in the front
channel with backchannel resolution approaches and swings between
preferences for one or the other for a long time. The approach in XZY leans
heavily towards the latter but both have their benefits and drawbacks.

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