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

From: Fabien Imbault <[email-masked]>
Date: Thu, 9 Jul 2020 17:11:32 +0200

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

---

From: Denis <[email-masked]>
Date: Fri, 10 Jul 2020 17:45:50 +0200

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.

Comments are between the lines.

> Hi Denis,
>
> I think it's interesting, but also very different to XYZ/XAuth so it 
> raises many questions ;-)

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:
>
> 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.

> 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.
>
> 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, ...

:-)

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".

> *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./
/

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.

> The client gets the access tokens and uses the services for which 
> access was granted.
>

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.

> 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.

> 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).

> 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 ?

> 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.

> 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.

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.

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

> 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

---

From: Fabien Imbault <[email-masked]>
Date: Fri, 10 Jul 2020 23:19:09 +0200

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 <[email-masked]> 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.

> Use a PC. Copy and paste and then use the Courier font. On my PC (with the
> clear figure) it was perfect.
>
> needed, maybe some verified credential from NeedMoney Holding that John is
> indeed CFO).
>
> *Dear John, *
> 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.

> 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
> consent is *often *required at the GS".
>
FI : in the context of xauth, this seems pretty clear I think.

> *- we'll pass that data to the credit agency, which will return your
> credit score *
> *Do you agree ?*
>
> 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.

> 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.
>
> each of the appropriate AS from the banks and will get the requested access
> tokens
FI : yes.

> BTW, no access token is necessarily needed by the user to be able to use
FI : maybe, maybe not. As soon as I want to fetch api calls, I need access
tokens.

> them.
> How do you enable a federated experience? (especially as there could be
> many)
>
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.

> 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
> 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.

> 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.
>
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.

> 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?
>
> 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).

> 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.

> draft-hardt-xauth-protocol-12.
FI : sorry but I don't need the word trust to do threat modeling...

>    - The user trusts its client.
>    - If a user has an account opened with an AS, then he trusts that AS
>    - 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
Denis
> 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
> *       +--------+                           +------------+        |
> User  |                           |  Resource  |        |
> |                           | Owner (RO) |        +--------+
>                   +------------+            |
> \                              |            |
> \                             |            |
> \                            |            |
> \                           |     +-----------+     +---------------+
> +------------+     |           |---->| Authorization |     |            |
>     |           | (2) |  Server (AS)  |     |            |     |
> |<----|               |     |            |     |  Client   |
> +---------------+     |            |     |
> |-------------------------->|  Resource  |     |   User    |
> (1)             |   Server   |     |  Consent
> |<--------------------------|    (RS)    |     |  element
> |                           |            |     |
> |-------------------------->|            |------>     |
> |           (3)             |            |  (4)     |
> |<--------------------------|            |<------
> +-----------+                           +------------+ *
> directly the operation that it wants to perform on the RS without any prior
> dialogue.
> 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).
>
> 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
> 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
> 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.
> 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.
>

---

From: Denis <[email-masked]>
Date: Mon, 13 Jul 2020 10:40:25 +0200

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:

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

> Le ven. 10 juil. 2020 à 17:53, Denis <[email-masked] 
> <mailto:[email-masked]>> 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.
>
>
>>     I think it's interesting, but also very different to XYZ/XAuth so
>>     it raises many questions ;-)
>     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:
>>
>>     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, /
>     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.
>     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".
>
>>     RS1 aggregates the list of attributes required (from all RS) and
>>     sends it to finapp.
>>     /Dear John, /
>>     /- 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 ?/
>>
>>     (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).
>
>     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.
>
> 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
>>     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.
>
>>     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.
>>     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
>     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).
>
> 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.
>
> 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
>>     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.
>
> 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.
>
>       * 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.
>     _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.
>
>
>     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
>     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
>     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).
>
>     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
>     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).
>
>     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.
>

---

From: Fabien Imbault <[email-masked]>
Date: Thu, 16 Jul 2020 10:20:34 +0200

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).

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.

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).
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.

Fabien

On Mon, Jul 13, 2020 at 10:40 AM Denis <[email-masked]> wrote:

> Your view seems to be that it is simpler because AS are way less central,
> but it seems to me
> 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
> can't respond to it of its own. A RO should not need to inform a GS to tell
> what its relationships
> about the relationships between RSs and to be informed in real time of any
> change about these
> relationships.
>
> 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.
>
>
> 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 draft-richer-transactional-authz-06, the user consent is never
>    addressed.
>    - in draft-hardt-xauth-protocol-12, the user consent is captured by
>          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.
>
> 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.
>
>> access to his finapp account to his external auditor, Ann (who is not a
>> direct user
> 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
>> captured locally by the Client (i.e. there is no dialogue with any AS nor
>> any RS).
>>
> --
> Txauth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth
>

---

From: Denis <[email-masked]>
Date: Fri, 17 Jul 2020 18:16:31 +0200

Hi Fabien,

> 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 <[email-masked] 
> <mailto:[email-masked]>> 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
>     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
>     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.
>
>     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.
>
>
>         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,
>       * 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.
>
>              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.
>>
>>         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.
>>
>>
>>>         I think it's interesting, but also very different to
>>>         XYZ/XAuth so it raises many questions ;-)
>>         Use a PC. Copy and paste and then use the Courier font. On my
>>         PC (with the clear figure) it was perfect.
>>
>>>         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.
>>>         Op2 : get your list of banks, RS2 (as registered within
>>>         finapp), through openbanking AS0 and retrieve the bank
>>>         statements :
>>>         Op3b : same from a second bank account, RS2b (say a local
>>     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".
>>
>>>         RS1 aggregates the list of attributes required (from all RS)
>>>         and sends it to finapp.
>>>         /Dear John, /
>>>         /- 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
>>>         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"
>>     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:
>>         corresponds to an API for each bank and then to send these
>>         access tokens to RS1.
>>
>>         transparently to each of the appropriate AS from the banks
>>         and will get the requested access tokens
>>>         The client gets the access tokens and uses the services for
>>>         which access was granted.
>>>
>>>         The trust model is focused around the relationship between
>>>         the enduser (John) and his application (finapp), which seems
>>>         fine.
>>
>>         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.
>>
>>>         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
>>         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.
>>
>>>         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.
>>
>>     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.
>>>         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.
>>
>>     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.
>>
>>           * 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.
>>         _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.
>>
>>
>>         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
>>         consent for multiple ASs while keeping all ASs ignorant about
>>         the choices of the user
>>         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.
>>         performing the requested operation and, if it consents, the
>>         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).
>>
>>         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
>>         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
>>         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
>     [email-masked] <mailto:[email-masked]>

---

From: Fabien Imbault <[email-masked]>
Date: Sat, 18 Jul 2020 08:14:57 +0200

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 <[email-masked]> a écrit :

> analysis on RP or IdP collusion
> 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
> 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.
>
> 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.
>
>> the management of the delegation at the GS. This also makes the assumption
>> that a single GS
>>> *to access to your finapp, please identify yourself through your
>>> prefered openbanking account.*
>>> *Thanks*
>>>
>>> and AS1 are, why they're different, and why he needs to authenticate to
>>> each of them.
>>> use today an AS of the Bank of America and may change tomorrow to the Bank
>>> of Missouri.