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

Fabien Imbault <> Fri, 10 July 2020 21:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1397D3A09BC for <>; Fri, 10 Jul 2020 14:19:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id V2zsLi6mUW_R for <>; Fri, 10 Jul 2020 14:19:38 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EB7D43A09B9 for <>; Fri, 10 Jul 2020 14:19:37 -0700 (PDT)
Received: by with SMTP id s21so6270935ilk.5 for <>; Fri, 10 Jul 2020 14:19:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BBKa/pfFzI1ayCU7hRcfpgS4cD5NlVqEbaMibM7W1qk=; b=RGL6f9IrdWrhgs7FZE8J030mY13wdrhXSbi4TLoYILgh5f3SB4MDk+gSb0I0JoyIDW lHziW/TYUDZJRtHjGlFYLr50B2LVnCgtbYdFJm3KIMtPcTHMUI8aX38yDxDrAJsl/uaI CxtgvMuCD5krcEQattfLOnIy3Xon/P5ca/tv3PhBrzZjoXPo/5IjzWkaEh6j9IvMYdVO d1VS4jr/6gcItgHhRUO58/jbc1PvuIJmS0BDrJm5KqNXLn7El+nB2g5jvXm6RK5BKHt0 8wuOoo4HrO8RNKAOsCUBAscGRNoLXXpkiarOTqqebmLcIVCj1xRiKxpS/gKTmUtXhKV9 3qWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BBKa/pfFzI1ayCU7hRcfpgS4cD5NlVqEbaMibM7W1qk=; b=KdIpv9M2TI3fX6B6y9+UxWKj0V9pYCpmMKTLerjnyWkJLYy0SkLzaZDnrWdpk6Au7X AZKGmFG+d4cMHI/g+E7RJ0uD7iR0mMiW+upCyR8ywFXn5NWkGoR8I9CPN/Aki4K5yRYp CjuCRbzy/4uKoEBTo0cPN00j6SIq30g9OHNoSZdmNJjXnNllRBLUQeb5ycVG6xvW5dhA gZbzZWPJK5PedlNJhl1ezj5DYsoz3lZrflp8wsV84rxjzZ2ZQxdImsg4fPxXi1E+R5Uq rFkL3TJUe9ReSa/yXrqjcMOzl5jxRw/5qJJ7RPWQrw977OZsrIKETuqAqS0I9Y9RQdSr U8gQ==
X-Gm-Message-State: AOAM531gQxvZNvHFhKqDrDQOi5WIpdeeAkpeFLldL0uPHDpwfrCzcyGG SwpgCAj4pfF9jvCEC8PoJZX/dux+X8tPvGTq6fjJFg==
X-Google-Smtp-Source: ABdhPJyAUO3JOAowhxd9d3CJNAOGKMAw3GDo2N6G14W9Dtji7t2zLSDfuXa5tHikDoOmc8Z+WBVQV48CDQyN5cnRFJo=
X-Received: by 2002:a05:6e02:682:: with SMTP id o2mr49824504ils.188.1594415977080; Fri, 10 Jul 2020 14:19:37 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Fabien Imbault <>
Date: Fri, 10 Jul 2020 23:19:09 +0200
Message-ID: <>
To: Denis <>
Content-Type: multipart/alternative; boundary="000000000000f02d9c05aa1ce5e2"
Archived-At: <>
Subject: Re: [Txauth] A model with a User Consent Element (with a clean figure)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 10 Jul 2020 21:19:41 -0000

Hi Denis,

Thanks for your answer.

My comments are embedded in the text, marked with FI.


Le ven. 10 juil. 2020 à 17:53, Denis <> a écrit :

> Hi Fabien,
> It would have been appreciated that you kept the original message in your
> response. I have copied it again at the end of this email.

FI : sorry, not always easy on a mobile. Will make sure that's the case
next time.

> Comments are between the lines.
> 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.
> Use a PC. Copy and paste and then use the Courier font. On my PC (with the
> clear figure) it was perfect.
> 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*
> If I understand you correctly,  finapp is a local application e.g. on your
> smartphone.
FI : not necessarily, the client could be a mobile app, a web app, etc.,
making api calls to backend protected services.

> *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
> Why don't you make your very first example a little bit more complicated ?
> with RS1, RS2a, RS2b, ... AS0, AS1, ...
> :-)
FI : fair point. But i believe it's important to grasp what it means on a
realistic example, especially as the proposed protocol would be very much
dependant on the way RS calls are made.

> The intent of the *first *email was to discuss a *basic *model and to
> place the highlights on the way to capture the *user's consent*
> in an interoperable manner without letting know to any RS or AS the
> choices of the user. This is a fundamental feature of the model.
> In XAuth, the user's consent is not formalized in the protocol : "User
> consent is *often *required at the GS".
FI : in the context of xauth, this seems pretty clear I think.

> *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).
> As described, the user could simply push to the RS the banking statements
> over the past 12 months (from each bank).
> The user consent is not about : "*Do you agree that*
> * we pass the data to the credit agency, which will return your credit
> score" *since no attributes nor ASs are involved in the question.
FI : this is possible of course, but pretty surprising. Today most
implementations are using oauth to delegate the implementation to some
specialized component, while here each RS would be responsible for
authentication. That is not an innocent choice from an implementation and
deployment perspective.

> I guess you want the user to get access tokens targeted for RS2x so that
> each bank will accept to disclose his banking statements over the past 12
> months.
> The consent is whether the user accepts to get access tokens from some of
> his banks targeted for RS2x for the following operation:
> "Retrieval of the past 12 months banking statements" which corresponds to
> an API for each bank and then to send these access tokens to RS1.
> In practice, the client (e.g. using FIDO) will connect transparently to
> each of the appropriate AS from the banks and will get the requested access
> tokens
> with a requested validity period of about 5 minutes.
FI : yes.

> *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.
> No. The trust model is not making a focus on that specific relationship.
> BTW, no access token is necessarily needed by the user to be able to use
> finapp.
FI : maybe, maybe not. As soon as I want to fetch api calls, I need access

> => 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)
> I fear that you have not fully captured what the user consent is about.
> See the above explanations. In addition, there is no concept of federation.
FI : your notion of consent is very specific to what you have in mind. It
would require a kind of automated system to work.
As for the concept of federation, this is required in practice in you don't
hypothesize a dependancy on FIDO. The Uma2 standard is probably the closest
to some of your ideas and focuses a lot on federation.

> 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.
> The client calls the main RS (here RS1). What may happen next is fully
> dependant upon the operation that the user is willing to perform and
> this is unpredictable (since the back end service may change at any point
> of time).
FI : OK, but is it good engineering practice to have to deal with the
internals of service calls? The reason why people delegate APIs is
precisely to avoid that complexity. Today with OAuth, and tomorrow with
XYZ/Xauth, the programming model is way simpler. Privacy may be a good
reason to change that, but we need to be very thoughtful about that.

> 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.
>  So is it really a problem ?
FI : I think so. If I'm finapp, I don't want to be this dependant on RS1
for a lot of good and bad reasons. What I hope the example conveys is that
there's no reason why RS1 would suddenly become the center of orchestration
for all queries, while all the underlying data is actually elsewhere.
The fact that the proposed protocol mandates this behaviour is surprising
and I don't see why that is.

> 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?
> The intent of the short description I sent was to describe two simple
> scenarios, so that we could start discussing about them.
> At this point, the intent is not to cover all the scenarios you may dream
> of.
FI : fair point. However, as previously discussed, this is a big concern as
we don't know whether you think this is a valid use case or whether this is
out of scope (so far, I understood it was more, if we can't do it with
maximum privacy, then we won't do it; which is a design choice, but
standards are usually about consensus with people that need to deal with
real life problems).

> e. more generally, a threat model would be required, as there are many
> more interactions now.
> There are less interactions than in XAuth: there is no protocol between
> ASs and RSs, nor between ROs and ASs.
FI : as far as I'm concerned, there are many more interactions than
Oauth/XYZ/Xauth. Your view seems to be that it is simpler because AS are
way less central, but it seems to me that RS are much more complex to
implement correctly.

> Before a threat model, a trust model is needed. Do we have a trust model
> for XAuth ?
> Unfortunately not, since the word "trust" is absent in the main body of
> draft-hardt-xauth-protocol-12.
FI : sorry but I don't need the word trust to do threat modeling...

> In this model, the trust relationships are as follows:
>    - The user trusts its client.
>    - If a user has an account opened with an AS, then he trusts that AS
>    to deliver the requested and genuine attributes into an access token.
>    - A RS may trust one or more ASs for one or more types of attributes
>    *and* for performing a given operation.
>    - A RS may be administered remotely by one or more RO.
> *Note*: for authentication, a RS may accept either FIDO or one or more
> types of attributes from one or more ASs.
> Cheers,
> Fabien
> This is a new thread.
> Preamble: This model is quite different from the XAuth model.
> In particular, a RO has no relationship with any AS and a Client does not
> need to be associated with any AS prior to any access to a RS.
> A key point of this model is that the user's consent is handled locally by
> the Client and hence no AS nor RS is handling a man machine interface
> for the user consent. This allows to support locally the user consent for
> multiple ASs while keeping all ASs ignorant about the choices of the user
> made for accessing a particular RS.
> *       +--------+                           +------------+        |
> User  |                           |  Resource  |        |
> |                           | Owner (RO) |        +--------+
>                   +------------+            |
> \                              |            |
> \                             |            |
> \                            |            |
> \                           |     +-----------+     +---------------+
> +------------+     |           |---->| Authorization |     |            |
>     |           | (2) |  Server (AS)  |     |            |     |
> |<----|               |     |            |     |  Client   |
> +---------------+     |            |     |
> |-------------------------->|  Resource  |     |   User    |
> (1)             |   Server   |     |  Consent
> |<--------------------------|    (RS)    |     |  element
> |                           |            |     |
> |-------------------------->|            |------>     |
> |           (3)             |            |  (4)     |
> |<--------------------------|            |<------
> +-----------+                           +------------+ *
> The flow of operations is as follows:
> The Client (which may have been previously authenticated using FIDO)
> contacts the RS and after some dialogue with the RS selects an operation
> that it wants to perform on the RS (1a). Note that it may also indicate
> directly the operation that it wants to perform on the RS without any prior
> dialogue.
> In return (1b), the RS informs the Client about which attributes are
> needed by the RS for performing the requested operation and from which
> Attributes Servers
> they may be obtained.
> This information is specifically marked to indicate that it shall be
> handled by the "User Consent element" from the Client.
> The presentation of that information is up to the man machine interface
> supported by the "User Consent element" from the Client.
> The user can see which attributes are requested by the RS for performing
> the requested operation and, if it consents, the Client contacts one or
> more
> appropriate Authorization Servers (2a). The user consent is hence captured
> locally by the Client (i.e. there is no dialogue with any AS nor any RS).
> When the Client got the access tokens from these authorization servers
> (2b), it sends all of them in a single request to the RS (3a).
> End of the story for a simple access
> Start of a subsequent story for a delegation case
> Let us now suppose that the RS is unable to fulfil the request by its own
> and that it needs to contact another RS. RS1 contacts RS2 (4a) and
> indicates the operation
> that it wants to perform on RS2 (that operation may not be the same as the
> original operation). In return (4b), RS2 informs RS1 about which attributes
> are needed
> by RS2 for performing the requested operation and from which Attributes
> Servers they may be obtained. RS1 forwards that information to the Client.
> This information is marked to indicate that it shall be handled by the
> "User Consent element" from the Client. The presentation of that
> information is up to the man machine
> interface from the Client. The user can see which attributes are requested
> by RS2 for performing the new requested operation and, if it consents, the
> Client contacts one or more
> appropriate Authorization Servers. The user consent is hence captured
> locally by the "User Consent element" from the Client. (i.e. there is no
> dialogue with any AS, nor RS1, nor RS2).
> When the Client got the access token(s) from the authorization server(s),
> it sends all of them in a single request to RS1. RS1 then forwards the
> additional access token(s) to RS2.
> Some observations:
> The user nor the Client are linked with any particular AS. A user may use
> today an AS of the Bank of America and may change tomorrow to the Bank of
> Missouri.
> As soon as he will be registered with the Bank of Missouri, he will be
> able to get access tokens from the AS of the Bank of Missouri. The AS of
> Bank of America
> has not been able to know where its access tokens have been used. This
> will be the same for AS of the Bank of Missouri. There is no need for any
> direct dialogue
> between any AS and any RS at the time a client is making an access. There
> is no need for any RO to contact any AS.
> This model has been constructed following a "Privacy by Design" approach.
> Denis