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

[Fabien Imbault <[e-mail]>]

Thanks Denis. I think that's clear.

By "we", I meant myself and a few colleagues. So far it's just a bunch of
quick MVPs and it's expected to grow overtime as an independant opensource
implementation. I think it's important we take the specs and try to
implement them to make sure it's easily understandable by external devs.

Fabien

Le ven. 17 juil. 2020 à 18:16, Denis <[e-mail]> a écrit :

> Hi Fabien,
>
> Thanks Denis for your answers.
>
> I think what you call delegation is a slightly different requirement than
> how the term is generally used in our context.
> Instead of delegation, I would rather suggest to call it a "resource
> chain" (and as in any supply chain, those could come from different
> parties).
>
> Whatever you call it, I believe that the model should be able to support
> it.
>
> I think the privacy concern is important, and it would be interesting to
> get back to prior art on the issue.
> for instance, https://github.com/samuelgoto/WebID provides an interesting
> analysis on RP or IdP collusion
> (here more focused on the ID part), a similar vein of work may enable
> richer discussions whether/when the GS
> is the right place for user consent, or not.
>
> The way and the place the user consent is captured is indeed critical.
>
> Then on user consent : implementations of XYZ do handle user consent. In
> our case, we've also decoupled the consent part (as a separate project).
>
> You are using the word "we". Do you mean that you are part of the design
> team or of the implementers team of XYZ ?
>
> Initially we did that to simplify the implementation of the AS core flow
> (between client and AS), while covering the UX requirements in a
> separate project.
> But the nice thing about that is that it doesn't change the core flow, and
> depending on the use case, one may either place it on the AS part (as we've
> implemented so far,
> and as most people would do today) or on the client part (as you think it
> should be). This demonstrates that depending how we assemble parts, we may
> end up
> with a solution that may fit various requirements.
>
> In addition to the place where the user consent is captured, there is the
> need to consider the assurances that the user can obtain about the respect
> of his choices.
>
> I have explained that such assurance can be obtained when the choice is
> made by the client and when the returned access tokens are not considered
> to be opaque to the client.
> It is also obvious that the GS/AS is kept ignorant of the proposed choices
> and is only informed about which user attributes should be inserted into
> the access token.
>
> At this time, no equivalent explanations have been provided when/if the
> user consent interface is handled by the GS/AS.
>
> Denis
>
>
> Fabien
>
> On Mon, Jul 13, 2020 at 10:40 AM Denis <[e-mail]> wrote:
>
>> Hi Fabien,
>>
>> Thank you for your responses. Rather than responding in the text, I will
>> pick up two of your comments:
>>
>> 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.
>>
>> In XYZ/Xauth there is a protocol needed between the GS and many ROs. This
>> protocol is "out of the scope" of these drafts and this is where the
>> complexity is hidden.
>> So it looks simpler for the client but it is much more complicated for
>> the management of the delegation at the GS. This also makes the assumption
>> that a single GS
>> will be able to handle the delegation case because all the RSs are
>> supposed to be in the same domain which is a very restrictive case. My
>> proposal is able to handle
>> the multi-domain case.
>>
>> Every RS is best placed to know where to forward an operation when it
>> can't respond to it of its own. A RO should not need to inform a GS to tell
>> what its relationships
>> with other RSs are. A GS should not be in a position to know everything
>> about the relationships between RSs and to be informed in real time of any
>> change about these
>> relationships.
>>
>> In term of trust, I mentioned:
>>
>>    - 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.
>>
>> This is it. There is no other trust relationship. The user does not trust
>> or rely on any collaboration between a RO and a GS.
>>
>>
>> A second of your comments:
>>
>> FI: if we can't do it with maximum privacy, then we won't do it; which is
>> a design choice,
>>
>> I would rather say: If we can do it with maximum privacy, let us do it.
>> At this time :
>>
>>    - in draft-hardt-xauth-protocol-12, the word "privacy" does not even
>>    exist.
>>    - in draft-richer-transactional-authz-06, there is a single sentence
>>    in the privacy considerations section:
>>
>>          Handles are passed between parties and therefore should be
>> stateful and not contain any internal structure or information,
>>          which could leak private data.
>>
>> About the user consent. At this time :
>>
>>    - in draft-richer-transactional-authz-06, the user consent is never
>>    addressed.
>>    - in draft-hardt-xauth-protocol-12, the user consent is captured by
>>    the GS whereas it should be captured by the Client.
>>
>>          The client has no way to verify that the user consent has indeed
>> been followed by the GS because the client
>>          cannot verify that what happens "behind the scenery" at the GS
>> is conformant with what the user has consented.
>>
>> Denis
>>
>> Hi Denis,
>>
>> Thanks for your answer.
>>
>> My comments are embedded in the text, marked with FI.
>>
>> Fabien
>>
>>
>> Le ven. 10 juil. 2020 à 17:53, Denis <[e-mail]> 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 tokens.
>>
>>> => 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.
>>>
>> Denis
>>>
>>> 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
>>>
>>
>> --
>> Txauth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/txauth
>>
>
>