Re: [Txauth] A model with a User Consent Element (with a clean figure)

[Fabien Imbault <[e-mail]>]

Hi Denis,

I think it's interesting, but also very different to XYZ/XAuth so it raises
many questions ;-)
The figure is impossible to read.

So let me try to summarize the suggested approach, with a concrete example,
to make sure we understand well:

*0. The client authN to the AS (in whatever way is supported)*
Ex : client is a corporate financing called "finapp". finapp contacts AS0
for authentication (say an openbanking service).
User is John Doe, CFO at NeedMoney Inc. (+ other identity claims if needed,
maybe some verified credential from NeedMoney Holding that John is indeed
CFO).

*Dear John, *
*to access to your finapp, please identify yourself through your prefered
openbanking account.*
*Thanks*

*1. The client contacts a RS in a discovery phase, which includes the
selection of (at least) an operation, for which the RS returns the required
authZ attributes *
Ex : finapp needs to use NeedMoney's data to evaluate how much credit it
can offer.

Op1 : compute the credit rating, from RS1 (this is outsourced to an
external credit analyst), through the external service's own AS1.
But to do that, RS needs your historic bank statements.

Op2 : get your list of banks, RS2 (as registered within finapp),
through openbanking AS0

and retrieve the bank statements :
Op3a : get historic data from his main bank, RS2a (say an international
bank), through openbanking AS0
Op3b : same from a second bank account, RS2b (say a local bank), through
openbanking AS0

*2. User consent *
RS1 aggregates the list of attributes required (from all RS) and sends it
to finapp.

*Dear John, *
*To evaluate your credit request, we need the following information: *
*- your list of bank accounts (retrieved from your finapp account)*
*- the associated banking statements over the past 12 months (from each
bank)*
*- we'll pass that data to the credit agency, which will return your credit
score *
*Do you agree ?*

John approves (or not..., maybe he'll agree only for one specific bank),
via finapp directly (I like that, albeit in a more traditional flow, I'm
also separating the UI from the rest of the protocol of XYZ, and it works
too).

*3. Requests to the protected resources *
The client gets the access tokens and uses the services for which access
was granted.


*Analysis: (maybe I didn't get everything right, if so let me know) *
The trust model is focused around the relationship between the enduser
(John) and his application (finapp), which seems fine.

=> I see some potential issues :

a. it will be really difficult for an end user to understand what AS0 and
AS1 are, why they're different, and why he needs to authenticate to each of
them. How do you enable a federated experience? (especially as there could
be many)

b. deciding what is the main RS (here RS1) to be called by the client seems
very critical, as it is the one that needs to orchestrate everything. This
seems a very hierarchical and imperative model which seems somewhat counter
intuitive in terms of developer experience (as least as it is made today,
we clearly don't go into so much details). The call hierarchy may quickly
become very complex, which may also become a problem when separate services
evolve.

c. RS1 gets all the information required to access all sub-resources, and
therefore gets also a lot of responsibility (and power). But from finapp's
point of view, it is the one that has the relationship with the user and is
providing the core value proposition, while RS1 is just an external service.

d. multi-user (common B2B scenario): John wants to authorize a read access
to his finapp account to his external auditor, Ann (who is not a direct
user of finapp herself, but might already be registered by openbanking
AS0). How do you do that? Does it require the access token itself to be
able to delegate rights?

e. more generally, a threat model would be required, as there are many more
interactions now.

Cheers,
Fabien