Re: [Txauth] Is it a transaction? (was Framework vs Protocol)

["Richard Backman, Annabelle" <[e-mail]>]

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.

– 
Annabelle Richard Backman
AWS Identity
 

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

    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 <[e-mail]> wrote:
    >
    > On Jan 6, 2020, at 4:33 PM, Dick Hardt <[e-mail]> wrote:
    >
    >
    > On Mon, Jan 6, 2020 at 8:08 AM Justin Richer <[e-mail]> 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.
    >
    >
    > 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
    > --
    > Txauth mailing list
    > [e-mail]
    > https://www.ietf.org/mailman/listinfo/txauth