Re: [Txauth] TxAuth Charter (Take 3.5)

[Justin Richer <[e-mail]>]

> On Jan 29, 2020, at 10:40 AM, Adrian Hope-Bailie <[e-mail]> wrote:
> 
> 
> 
> > ** what new use cases would TxAuth address (that aren't in scope for OAuth)?
> 
> Identity is a big one, which is what OIDC currently layers on top of OAuth 2. We’d also be looking at user-to-user delegation (the UMA and CIBA use cases). We’re also looking at cases that involve non-web interaction with users (like the DID/VC work, or app-to-app communication on devices). All of these are listed in the proposed text, do they need to be called out as being beyond OAuth 2?
> 
> We are most interested in payments use cases. Specifically we find the use of OAuth 2.0 for delegated access to financial accounts very limited, forcing us into using things like the "Lodging Intents Pattern". I think Torsten has made the point well in his blogs on the topic (https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948 <https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948>).
> 
> I believe this can be broadened to include any use case where the authorization flow involves the user/RO giving consent to a client to perform a specific transaction (as opposed to simply get access to a resource or API) and the need for the AS to have the details of this prior to authorization so the details can be properly presented to the user.
>  


Exactly — because OAuth forces this information to go through the browser to get to the authorization page, it’s a bad fit for this type of use where you’re putting potentially sensitive information as inputs to the decision (which account to choose, for instance) that you don’t want leaked through the browser. 

TxAuth is based on the lodging intent pattern from the start. PAR does a great job of back porting this functionality to OAuth 2, but there are limitations and awkwardness to this approach that TxAuth can avoid.


 — Justin