Subject: [Txauth] A model with a User Consent Element

From: Denis <[email-masked]>
Date: Thu, 9 Jul 2020 12:19:59 +0200

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: Denis <[email-masked]>
Date: Thu, 9 Jul 2020 12:26:02 +0200

This is a new thread.

Some observations:

Denis

---

From: Daniel Fett <[email-masked]>
Date: Thu, 9 Jul 2020 13:57:41 +0200

Am 09.07.20 um 12:26 schrieb Denis:
>
> 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
What prevents a non-compliant client from retrieving data about (or
access tokens for) arbitrary users from arbitrary authorization servers?

-Daniel

-- 
https://danielfett.de

---

From: Denis <[email-masked]>
Date: Thu, 9 Jul 2020 14:34:10 +0200

Hi Daniel,

The response is pretty obvious. The user must have an account with the 
AS, e.g.  logging using FIDO.

Denis

---

From: David Pyke <[email-masked]>
Date: Thu, 9 Jul 2020 11:24:48 -0400

This is frequently done in healthcare, with the User Consent Element 
holding a URI to a fetchable document or OID that outlines consent 
requirements or provisions.  If the URI points to a (I)ACP, it can be 
computable (XACML or other) consent that can be ingested automagically.

On 2020-07-09 6:19 a.m., Denis wrote:
> 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 multiple ASs while keeping all ASs ignorant about the choices of 
> the user
> 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.
> The presentation of that information is up to the man machine 
> interface supported by the "User Consent element" from the Client.
>
> by RS2 for performing the requested operation and from which 
> Attributes Servers they may be obtained. RS1 forwards that information 
> to the Client.
>
> locally by the "User Consent element" from the Client. (i.e. there is 
> no dialogue with any AS, nor RS1, nor RS2).
>
> able to get access tokens from the AS of the Bank of Missouri. The AS 
> of Bank of America
-- 

*David Pyke*

Manager, Strategic Consulting

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Logo <http://www.readycomputing.com/>

LinkedIn icon <https://www.linkedin.com/company/ready-computing> Twitter 
icon <https://twitter.com/ready_computing?lang=en> Youtbue icon 
<https://www.youtube.com/channel/UCtA7SflMXNTkY0MWL-79LDQ>

Office: +1 212 877 3307 x5001

[email-masked] <mailto:[email-masked]>_

_www.readycomputing.com <http://www.readycomputing.com/>_

150 Beekman Street, Floor 3, New York, NY 10038

The information in this e-mail communication together with any 
attachments is intended only for the person or entity to which it is 
addressed and may contain confidential and/or privileged material. If 
you are not the intended recipient of this communication, please notify 
us immediately. Any views expressed in this communication are those of 
the sender, unless otherwise specifically stated. Ready Computing does 
not represent, warrant or guarantee that the integrity of this 
communication has been maintained or the communication is free of 
errors, virus or interference.

-- 
This is not a secure transmission. The information contained in this 

transmission is highly prohibited from containing privileged and 

confidential information, including patient information protected by 

federal and state privacy laws. It is intended only for the use of the 

person(s) named above. If you are not the intended recipient, you are 

hereby notified that any review, dissemination, distribution, or 

duplication of this communication is strictly prohibited. If you are not
 
the intended recipient, please contact the sender by reply email and 

destroy all copies of the original message.

---

From: Tom Jones <[email-masked]>
Date: Thu, 9 Jul 2020 08:50:02 -0700

David: Kantara has been working on standardizing the health care model you
describe. Where clients are known, this model works. I would suggest that
the model requires federation of some sort to assess the parties to a
transaction, and so is fundamentally different from the more typical oauth
model where the client must be considered to be an adversary.

I doubt that a common protocol can be enabled for both models. But I am
open to hearing that both models can share message formats. That would be a
good start.

thx ..Tom (mobile)

On Thu, Jul 9, 2020, 8:25 AM David Pyke <david.pyke=
[email-masked]> wrote:

> 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.
>
>  <http://www.readycomputing.com/>
>
>  <https://www.linkedin.com/company/ready-computing> [image:
> Twitter icon] <https://twitter.com/ready_computing?lang=en> [image:
> Youtbue icon] <https://www.youtube.com/channel/UCtA7SflMXNTkY0MWL-79LDQ>
>
> * [email-masked] <[email-masked]>*
>
> * www.readycomputing.com <http://www.readycomputing.com/>*
>
> The information in this e-mail communication together with any attachments
> is intended only for the person or entity to which it is addressed and may
> contain confidential and/or privileged material. If you are not the
> intended recipient of this communication, please notify us immediately. Any
> views expressed in this communication are those of the sender, unless
> otherwise specifically stated. Ready Computing does not represent, warrant
> or guarantee that the integrity of this communication has been maintained
> or the communication is free of errors, virus or interference.
>
> destroy all copies of the original message. --
> Txauth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth
>

---

From: Dick Hardt <[email-masked]>
Date: Thu, 9 Jul 2020 10:58:00 -0700

Hi Denis, thanks for sharing the model. I don't fully understand what is
going on, questions inserted:

FWIW: having paragraphs start with the step number (1), (2) etc. would make
it easier to map between the description and the diagram.

> made for accessing a particular RS.
Which party has the client authenticated to? The client authenticating with
FIDO is confusing to me. FIDO is usually how a user authenticates.

> contacts the RS and after some dialogue with the RS selects an operation
How does the client know which RS to contact?

> needed by the RS for performing the requested operation and from which

(1a) and (1b) are not labeled. There is only (1)

> handled by the "User Consent element" from the Client.
Why? What is the significance of this? Which information is marked?

> supported by the "User Consent element" from the Client.

Which information?

> appropriate Authorization Servers (2a).
>
How does the client know which AS(s) to contact?

> The user consent is hence captured locally by the Client (i.e. there is no
> dialogue with any AS nor any RS).
>

No dialogue with who? The client is calling the AS is it not?

> (2b), it sends all of them in a single request to the RS (3a).

So the RS must trust the AS that issued the tokens. And the AS must trust
the Client to have gathered consent. And the AS must have a relationship
with the user. It is unclear what role the RO is playing in this though.
The RO and RS look to be the same entity from all the other parties.

>From my current understanding, at a high level, this looks like it is
supported by GNAP with the addition of the discovery step (1). There have
been a number of proposals for doing this discovery, and perhaps now there
are enough use cases to look at standardizing something.  No interaction is
needed between the AS and the  User as the Client is providing enough
"information" in the user object of the Grant Request to satisfy the AS
releasing the access tokens.

Perhaps as I understand the model in more detail I will understand what is
missing from GNAP (besides the discovery step).

/Dick

(I've skipped reviewing the delegation use case below until I understand
the simple use case)

> This model has been constructed following a "Privacy by Design" approach.
ᐧ

---

From: Denis <[email-masked]>
Date: Fri, 10 Jul 2020 15:06:23 +0200

Hi Dick,

> Hi Denis, thanks for sharing the model. I don't fully understand what 
> is going on, questions inserted:
Responses are inserted.
>
> FWIW: having paragraphs start with the step number (1), (2) etc. would 
> make it easier to map between the description and the diagram.
>
> On Thu, Jul 9, 2020 at 3:26 AM Denis <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     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.
>
>     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
> Which party has the client authenticated to? The client authenticating 
> with FIDO is confusing to me. FIDO is usually how a user authenticates.

If the user has previously opened a user account with the RS using FIDO, 
then the client may be authenticated by the RS using FIDO.
In such a case, the user is already known to the RS under a pseudonym 
specific to the RS. It may (or may not) have previously presented access 
tokens
to that RS.

> How does the client know which RS to contact?

For a private usage, the user may use DuckDuckGo, while for business he 
may use an application from his company which lists various services
available in the context of his job or his position. Some services may 
be freely available to all the employees of the company with any 
authentication,
e.g. the phone book of the employees may be freely available on the 
intranet of the company, while some other services may require the user
to authenticate to the AS from the company.

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

(1a) is the first exchange for (1) with the arrow from left to right, 
while (1b) is the response with the arrow from right to left.
The same applies to the other exchanges i.e. (2) , (3) and (4).

>
>     This information is specifically marked to indicate that it shall
>     be handled by the "User Consent element" from the Client.
>

In the response, a specific identifier or a magic number is used to 
indicate the start and the length of the information block
to be sent to the "User Consent element" supported by the Client.

> interface supported by the "User Consent element" from the Client.

The attributes that are needed by the RS for performing a requested 
operation and from which Attributes Servers they may be obtained.

> How does the client know which AS(s) to contact?

For each AS trusted by the RS to perfom a given operation, the RS should 
indicate a user-friendly name and a URL of the AS.

>     The user consent is hence captured locally by the Client (i.e.
>     there is no dialogue with any AS nor any RS).
>
>

For the user consent, there is no external call since it is handled 
locally. Afterwards, there is a call to the AS(s) selected by the user.

>
>     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).
>
>
> So the RS must trust the AS that issued the tokens. And the AS must 
> trust the Client to have gathered consent.
Theses two assertions are correct.
> And the AS must have a relationship with the user.

Only when the user chooses one AS while giving its consent, then the 
user must have a relationship with the selected AS.

> It is unclear what role the RO is playing in this though. The RO and 
> RS look to be the same entity from all the other parties.

A RO, as indicated on the figure, has only a relationship with one RS: 
it has no relationship with any AS.
The RS trusts the AS but the AS does not know which RSs are trusting it.

> supported by GNAP with the addition of the discovery step (1).

Well, it is fairly different :

    1) The first major difference is that there is no arrow between the
    RO and the AS. No protocol or "out-of-bands" means are necessary.

    2) The second major difference is that there is no arrow between the
    AS and the RS. No protocol is necessary.

    3) The third major difference is that the AS does not know any RS.
    Note: for backward compatibility reasons, an exception might exist
    for "old" Auth 2.0 ASs.

    4) The fourth major difference is that the XAuth spec. is rather
    vague to describe when and by who the user consent is captured:
         XAuth states on page 4: "User consent is /often /required at
    the GS". In that case, the GS is able to act as Big Brother. No
    other case is described.

    5) The fifth major difference is that the data that is transferred
    to a "User Consent Element" to capture the user consent. That data
    can be standardized.
         Moreover, it will also be possible to standardize the dialogue
    between the RO and the RS. The RO will then be able to manage
    remotely the authorization tables.
         See my email sent on June 6, with the following subject:
    "Support of FIDO and data minimization by RSs".

    6) Another difference is the following: since there is no
    interaction between the RO and the AS, "authorizations from the RO"
    as described in XAuth do not exist. 

> There have been a number of proposals for doing this discovery, and 
> perhaps now there are enough use cases to look at standardizing 
> something.
> No interaction is needed between the AS and the User as the Client is 
> providing enough "information" in the user object of the Grant Request
> to satisfy the AS releasing the access tokens.
Not sure I understand correctly this last sentence.
>
> Perhaps as I understand the model in more detail I will understand 
> what is missing from GNAP (besides the discovery step).

It would be hard to say "what is missing" from XAuth since the 
foundations are not the same.

In order to compare different architectures, there is the need to start 
with the trust relationships.
Unfortunately, the word "trust" is absent in the main body of 
draft-hardt-xauth-protocol-12. Hence,
the description of the trust relationships is missing.

Denis

>
> /Dick
>
> (I've skipped reviewing the delegation use case below until I 
> understand the simple use 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
>     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.
>
>     [email-masked] <mailto:[email-masked]>

---

From: Dick Hardt <[email-masked]>
Date: Fri, 10 Jul 2020 11:48:14 -0700

>From https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-1.1

1.1 <https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-1.1>.
Parties

   The parties and their relationships to each other:

       +--------+                           +------------+
       |  User  |                           |  Resource  |
       |        |                           | Owner (RO) |
       +--------+                           +------------+
           |      \                       /      |
           |       \                     /       |
           |        \                   /        |
           |         \                 /         |
       +--------+     +---------------+     +------------+
       | Client |---->|     Grant     |     |  Resource  |
       |        | (1) |  Server (GS)  | _ _ |   Server   |
       |        |<----|               |     |    (RS)    |
       |        |     +---------------+     |            |
       |        |-------------------------->|            |
       |        |           (2)             |            |
       |        |<--------------------------|            |
       +--------+                           +------------+

The lines without arrows represent relationships.
The User trusts the Client
The User trusts the GS
The RO trusts the GS to issue access tokens for the RS
The RS trusts the tokens issued by the RS
The RO controls the RS

The Client makes calls to the GS (1)
The Client makes calls to the RS (2)

This looks pretty similar to your protocol drawing.

What looks to be missing from your proposal is:

A) The Client making a call to the RS to discover what it needs from a GS,
and which GS to ask, prior to (1).
B) A mechanism for the Client to prove to the GS that it has gathered
consent from the User.

The current protocol does not require the GS to interact with either the
User, the RO, or the RS -- which looks to me to meet your privacy goals.

ᐧ

On Fri, Jul 10, 2020 at 6:06 AM Denis <[email-masked]> wrote:

> available in the context of his job or his position. Some services may be
> freely available to all the employees of the company with any
> authentication,
> the Client to have gathered consent.
>
> Only when the user chooses one AS while giving its consent, then the user
> must have a relationship with the selected AS.
>
> It is unclear what role the RO is playing in this though. The RO and RS
> look to be the same entity from all the other parties.
>
> A RO, as indicated on the figure, has only a relationship with one RS: it
> has no relationship with any AS.
> 1) The first major difference is that there is no arrow between the RO and
> the AS. No protocol or "out-of-bands" means are necessary.
>
> 2) The second major difference is that there is no arrow between the AS
> and the RS. No protocol is necessary.
>
> 3) The third major difference is that the AS does not know any RS. Note:
> for backward compatibility reasons, an exception might exist for "old" Auth
> 2.0 ASs.
>
> 4) The fourth major difference is that the XAuth spec. is rather vague to
> describe when and by who the user consent is captured:
>     XAuth states on page 4: "User consent is *often *required at the GS".
> In that case, the GS is able to act as Big Brother. No other case is
> described.
> 5) The fifth major difference is that the data that is transferred to a
> "User Consent Element" to capture the user consent. That data can be
> standardized.
>     Moreover, it will also be possible to standardize the dialogue between
> the RO and the RS. The RO will then be able to manage remotely the
> authorization tables.
>     See my email sent on June 6, with the following subject: "Support of
> FIDO and data minimization by RSs".
>
> 6) Another difference is the following: since there is no interaction
> between the RO and the AS, "authorizations from the RO" as described in
> XAuth do not exist.
>
> perhaps now there are enough use cases to look at standardizing something.
> It would be hard to say "what is missing" from XAuth since the foundations
> are not the same.
>

---

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

Hello Dick,

You wrote: "This looks pretty similar to your protocol drawing".

No. There is a fundamental difference with the sequencing of the flow of 
the exchanges where the (1) and (2) flows are inverted.

In your figure:

while in my figure:

    The Client makes calls to the RS (1)
    The Client makes calls to the AS (2)

In your figure, the first flow is with the GS, whereas in my figure the 
first flow is with the RS and there is a good reason for that:
the client first contacts the RS to know what the RS expects. The client 
indicates in its first exchange to the RS whether it wants to authenticate
or to perform another operation.  In the case of an authentication 
operation, the RS may respond to the client that is supports FIDO U2F
or that it is willing the client to present some attribute(s) from one 
or more AS.

Then after the client has to figure out whether the user is using FIDO 
and if not whether the user has an account with one of the AS.
In the later case, if there is a match then the client,/*after having 
received the user consent*/, may contact the appropriate AS to ask
for some attribute(s).

The same fundamental difference applies with 
draft-richer-transactional-authz-06 (XYZ) where the first exchange is 
done with the AS:
"The RC creates a transaction request and sends it to the AS".

This answers also in details to one of your comments:

    What looks to be missing from your proposal is:
    A) The Client making a call to the RS to discover what it needs from
    a GS, and which GS to ask, prior to (1).

This is not missing since this is the foundation of the architecture. 
The discovery mechanism at the RS has been described
in details in an earlier email with the following title: "Support of 
FIDO and data minimization by RSs".

The main figures are copied below (using ASCII):**

*+-----------------------------------+---------------------------------+
+Operation+Mathematical expression+
+-----------------------------------+---------------------------------+
+ Authentication+ Condition 1 OR Condition 2+
+-----------------------------------+---------------------------------+
+ Operation A OR Operation Z+ Condition 3 AND Condition 4+
+-----------------------------------+---------------------------------+

**Conditions table: **

+-------------+--------------+-----------------------------+----------+
+ Condition 1 + FIDO U2F 1.2 +++
+-------------+--------------+-----------------------------+----------+
+ Condition 2 + AS 1+ set 1 of a attributes types + +
+-------------+--------------+-----------------------------+----------+
+ Condition 3 + AS 2+ set 2 of a attributes types + Scope 21 +
   +-------------+--------------+-----------------------------+----------+
+ Condition 4 + AS 9+ set 3 of a attributes types-+ +
+-------------+--------------+-----------------------------+----------+
*
According to the operation announced by the Client, the RS returns to 
the Client both the mathematical expression
associated with that operation and the conditions included in that 
mathematical expression. The Client may then
present that information to the user in order to obtain the user consent 
in a standardized manner.

Another comment you made is:

    What looks to be missing from your proposal is:
    B) A mechanism for the Client to prove to the GS that it has
    gathered consent from the User.

The user consent should not be captured *by the GS*, since the GS would 
be in a position to apply a different consent decision
without letting it know to the user (or to the client).

The user consent must be captured *by the Client* and the Client must be 
able to verify that this consent has indeed been followed by the AS.

The authorization data managed at the RS by the RO is used by the Client 
to query the consent of the user in a standardized manner.
When, later on, the access token is returned to the Client by the AS, 
the Client (not the user) using that authorization data as well as
the decision of the user is able to verify that the requested attributes 
(and no more) are indeed present into the access token.

This is why access tokens may *not* be considered to be opaque to the 
Clients.

In my earlier email copied below, six major differences with XAuth from 
1) to 6) are listed.

Denis

> From 
> https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-1.1
>
>
>       1.1
>       <https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-1.1>.
>       Parties
>
>
>
> A) The Client making a call to the RS to discover what it needs from a 
> GS, and which GS to ask, prior to (1).
> The current protocol does not require the GS to interact with either 
> the User, the RO, or the RS -- which looks to me to meet your 
> privacy goals.
>
> ᐧ
>
> On Fri, Jul 10, 2020 at 6:06 AM Denis <[email-masked] 
>>     Hi Denis, thanks for sharing the model. I don't fully understand
>>     what is going on, questions inserted:
>     Responses are inserted.
>>
>>     FWIW: having paragraphs start with the step number (1), (2) etc.
>>     would make it easier to map between the description and the diagram.
>>
>>         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
>>     Which party has the client authenticated to? The client
>>     authenticating with FIDO is confusing to me. FIDO is usually how
>>     a user authenticates.
>
>     If the user has previously opened a user account with the RS using
>     FIDO, then the client may be authenticated by the RS using FIDO.
>     In such a case, the user is already known to the RS under a
>     pseudonym specific to the RS. It may (or may not) have previously
>     presented access tokens
>     to that RS.
>
>     For a private usage, the user may use DuckDuckGo, while for
>     business he may use an application from his company which lists
>     various services
>     available in the context of his job or his position. Some services
>     may be freely available to all the employees of the company with
>     any authentication,
>     e.g. the phone book of the employees may be freely available on
>     the intranet of the company, while some other services may require
>     the user
>>     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
>     (1a) is the first exchange for (1) with the arrow from left to
>     right, while (1b) is the response with the arrow from right to left.
>>         This information is specifically marked to indicate that it
>>         shall be handled by the "User Consent element" from the Client.
>>
>     In the response, a specific identifier or a magic number is used
>     to indicate the start and the length of the information block
>     The attributes that are needed by the RS for performing a
>     requested operation and from which Attributes Servers they may be
>     obtained.
>
>>
>>         performing the requested operation and, if it consents, the
>     For each AS trusted by the RS to perfom a given operation, the RS
>     should indicate a user-friendly name and a URL of the AS.
>
>>         The user consent is hence captured locally by the Client
>>         (i.e. there is no dialogue with any AS nor any RS).
>>
>>
>     For the user consent, there is no external call since it is
>     handled locally. Afterwards, there is a call to the AS(s) selected
>     by the user.
>
>>
>>         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).
>>
>>
>>     So the RS must trust the AS that issued the tokens. And the AS
>>     must trust the Client to have gathered consent.
>     Only when the user chooses one AS while giving its consent, then
>     the user must have a relationship with the selected AS.
>
>>     It is unclear what role the RO is playing in this though. The RO
>>     and RS look to be the same entity from all the other parties.
>
>     A RO, as indicated on the figure, has only a relationship with one
>     RS: it has no relationship with any AS.
>>     From my current understanding, at a high level, this looks like
>>     it is supported by GNAP with the addition of the discovery step (1).
>
>         1) The first major difference is that there is no arrow
>         between the RO and the AS. No protocol or "out-of-bands" means
>         are necessary.
>
>         2) The second major difference is that there is no arrow
>         between the AS and the RS. No protocol is necessary.
>
>         3) The third major difference is that the AS does not know any
>         RS. Note: for backward compatibility reasons, an exception
>         might exist for "old" Auth 2.0 ASs.
>
>         4) The fourth major difference is that the XAuth spec. is
>         rather vague to describe when and by who the user consent is
>         captured:
>             XAuth states on page 4: "User consent is /often /required
>         at the GS". In that case, the GS is able to act as Big
>         Brother. No other case is described.
>
>         5) The fifth major difference is that the data that is
>         transferred to a "User Consent Element" to capture the user
>         consent. That data can be standardized.
>             Moreover, it will also be possible to standardize the
>         dialogue between the RO and the RS. The RO will then be able
>         to manage remotely the authorization tables.
>         interaction between the RO and the AS, "authorizations from
>         the RO" as described in XAuth do not exist. 
>
>>     There have been a number of proposals for doing this discovery,
>>     and perhaps now there are enough use cases to look at
>>     standardizing something.
>>     No interaction is needed between the AS and the User as the
>>     Client is providing enough "information" in the user object of
>>     the Grant Request
>>     Perhaps as I understand the model in more detail I will
>>     understand what is missing from GNAP (besides the discovery step).
>
>     In order to compare different architectures, there is the need to
>     start with the trust relationships.
>>         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

---

From: Dick Hardt <[email-masked]>
Date: Mon, 13 Jul 2020 11:02:49 -0700

I'm going to just address the first part of your response so that we can
get clarity on that before diving into your later comments.

The calls between your proposal and XAuth are not inverted, your proposal
has a prior step. Step 1 in XAuth maps to Step 2 in your proposal, and Step
2 in XAuth is Step 3 in your proposal.

Below are 2 diagrams showing the same steps, the first keeping the existing
step labels for XAuth, the latter renaming the steps to correspond to your
proposal. This looks pretty similar to your diagram. What am I missing?

/Dick

DIAGRAM 1 (steps start at 0)

       |        |           (0)             |            |

DIAGRAM 2 (steps start at 1)

       |        | (2) |  Server (GS)  | _ _ |   Server   |
       |        |           (3)             |            |
       |        |           (1)             |            |

ᐧ

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

> or that it is willing the client to present some attribute(s) from one or
> more AS.
>
> Then after the client has to figure out whether the user is using FIDO and
> if not whether the user has an account with one of the AS.
> In the later case, if there is a match then the client,* *after having
> received the user consent**, may contact the appropriate AS to ask
> for some attribute(s).
>
> draft-richer-transactional-authz-06 (XYZ) where the first exchange is done
> with the AS:
> This is not missing since this is the foundation of the architecture. The
> discovery mechanism at the RS has been described
> in details in an earlier email with the following title: "Support of FIDO
> and data minimization by RSs".
>
> The main figures are copied below (using ASCII):
>
>
>
>
>
>
>
>
>
> *  +-----------------------------------+---------------------------------+
>   +           Operation               +      Mathematical expression    +
> +-----------------------------------+---------------------------------+   +
> Authentication                    + Condition 1 OR Condition 2      +
> +-----------------------------------+---------------------------------+   +
> Operation A OR Operation Z        + Condition 3 AND Condition 4     +
> +-----------------------------------+---------------------------------+ **Conditions
> table: *
>
>
>
>
>
>
>
>
>
>
> *
> +-------------+--------------+-----------------------------+----------+   +
> Condition 1 + FIDO U2F 1.2 +                             +          +
> +-------------+--------------+-----------------------------+----------+   +
> Condition 2 + AS 1         + set 1 of a attributes types +          +
> +-------------+--------------+-----------------------------+----------+   +
> Condition 3 + AS 2         + set 2 of a attributes types + Scope 21 +
> +-------------+--------------+-----------------------------+----------+   +
> Condition 4 + AS 9         + set 3 of a attributes types-+          +
> +-------------+--------------+-----------------------------+----------+ *
> According to the operation announced by the Client, the RS returns to the
> Client both the mathematical expression
> The user consent should not be captured *by the GS*, since the GS would be
> in a position to apply a different consent decision
> When, later on, the access token is returned to the Client by the AS, the
> Client (not the user) using that authorization data as well as
> In my earlier email copied below, six major differences with XAuth from 1)
> to 6) are listed.
>
> Denis
>
> 1.1 <https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-1.1>.  Parties
>
>> The user consent is hence captured locally by the Client (i.e. there is
>>> no dialogue with any AS nor any RS).
>>>
>>
>> 1) The first major difference is that there is no arrow between the RO
>> and the AS. No protocol or "out-of-bands" means are necessary.
>>
>>     XAuth states on page 4: "User consent is *often *required at the
>> GS". In that case, the GS is able to act as Big Brother. No other case is
>> described.
>> between the RO and the RS. The RO will then be able to manage remotely the
>> authorization tables.
>> Perhaps as I understand the model in more detail I will understand what
>> is missing from GNAP (besides the discovery step).
>>
>>> use today an AS of the Bank of America and may change tomorrow to the Bank
>>> of Missouri.

---

From: Justin Richer <[email-masked]>
Date: Mon, 13 Jul 2020 14:57:32 -0400

If I’m understanding Denis’s proposal, he’s saying that that “prior step” is the lynchpin of the whole model, since interaction between the client and the RS (and the user and the RS) is key to Denis’s privacy model. Additionally, what happens *at* each step is different. Consent is gathered at the client, not the GS in this diagram, for example. The GS simply mints a token as specified by the client and the RS.

It’s for these reasons that, as long as I’ve been understanding correctly, I’ve been saying that Denis’s model as proposed is pretty different. But what I think isn’t that different is the different steps if you’re willing to look at the boundaries around the boxes differently. For example, what OAuth would call “the AS” might end up being a few different boxes in GNAP that do different things. I had started down that route with XYZ’s design allowing the interaction to be managed separately. 

I think that the disconnect we’re seeing here might be caused by vocabulary mismatches. If we aren’t meaning the same thing when we say the same terms, it’s easy to get things mixed up with each other. Since GNAP is just barely forming its vocabulary out of the legacy of OAuth and kin, we have a chance to maybe draw the lines better and see if that’s how we can get things to fit.

 — Justin

> On Jul 13, 2020, at 2:02 PM, Dick Hardt <[email-masked]> wrote:
> 
> 
> I'm going to just address the first part of your response so that we can get clarity on that before diving into your later comments.
> 
> The calls between your proposal and XAuth are not inverted, your proposal has a prior step. Step 1 in XAuth maps to Step 2 in your proposal, and Step 2 in XAuth is Step 3 in your proposal..
> 
> Below are 2 diagrams showing the same steps, the first keeping the existing step labels for XAuth, the latter renaming the steps to correspond to your proposal. This looks pretty similar to your diagram. What am I missing?
> 
> /Dick
> 
> On Mon, Jul 13, 2020 at 7:08 AM Denis <[email-masked] <mailto:[email-masked]>> wrote:
> Hello Dick,
> 
> No. There is a fundamental difference with the sequencing of the flow of the exchanges where the (1) and (2) flows are inverted. 
> 
> In your figure:
> In your figure, the first flow is with the GS, whereas in my figure the first flow is with the RS and there is a good reason for that: 
> the client first contacts the RS to know what the RS expects. The client indicates in its first exchange to the RS whether it wants to authenticate 
> or to perform another operation.  In the case of an authentication operation, the RS may respond to the client that is supports FIDO U2F 
> or that it is willing the client to present some attribute(s) from one or more AS.
> 
> Then after the client has to figure out whether the user is using FIDO and if not whether the user has an account with one of the AS.
> In the later case, if there is a match then the client, *after having received the user consent*, may contact the appropriate AS to ask 
> for some attribute(s). 
> 
> The same fundamental difference applies with draft-richer-transactional-authz-06 (XYZ) where the first exchange is done with the AS:
> A) The Client making a call to the RS to discover what it needs from a GS, and which GS to ask, prior to (1).
> This is not missing since this is the foundation of the architecture. The discovery mechanism at the RS has been described 
> in details in an earlier email with the following title: "Support of FIDO and data minimization by RSs".
> 
>   + Authentication                    + Condition 1 OR Condition 2      +
>   + Operation A OR Operation Z        + Condition 3 AND Condition 4     +
> Conditions table: 
>   + Condition 1 + FIDO U2F 1.2 +                             +          +
>   + Condition 2 + AS 1         + set 1 of a attributes types +          +
>   + Condition 3 + AS 2         + set 2 of a attributes types + Scope 21 +
>   + Condition 4 + AS 9         + set 3 of a attributes types-+          +
> According to the operation announced by the Client, the RS returns to the Client both the mathematical expression 
> associated with that operation and the conditions included in that mathematical expression. The Client may then 
> present that information to the user in order to obtain the user consent in a standardized manner.
> 
> B) A mechanism for the Client to prove to the GS that it has gathered consent from the User.
> The user consent should not be captured *by the GS*, since the GS would be in a position to apply a different consent decision 
> The user consent must be captured *by the Client* and the Client must be able to verify that this consent has indeed been followed by the AS. 
> 
> The authorization data managed at the RS by the RO is used by the Client to query the consent of the user in a standardized manner.
> When, later on, the access token is returned to the Client by the AS, the Client (not the user) using that authorization data as well as 
> the decision of the user is able to verify that the requested attributes (and no more) are indeed present into the access token. 
> 
> This is why access tokens may *not* be considered to be opaque to the Clients.
> 
> In my earlier email copied below, six major differences with XAuth from 1) to 6) are listed.
> 
> Denis
> 
>> From https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-1.1 <https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-1.1>
>> 
>> A) The Client making a call to the RS to discover what it needs from a GS, and which GS to ask, prior to (1).
>> B) A mechanism for the Client to prove to the GS that it has gathered consent from the User.
>> 
>> The current protocol does not require the GS to interact with either the User, the RO, or the RS -- which looks to me to meet your privacy goals.
>> 
>> ᐧ
>> 
>> On Fri, Jul 10, 2020 at 6:06 AM Denis <[email-masked] <mailto:[email-masked]>> wrote:
>> Hi Dick,
>> 
>>> Hi Denis, thanks for sharing the model. I don't fully understand what is going on, questions inserted:
>> Responses are inserted.
>>> 
>>> FWIW: having paragraphs start with the step number (1), (2) etc. would make it easier to map between the description and the diagram.
>>> 
>>> On Thu, Jul 9, 2020 at 3:26 AM Denis <[email-masked] <mailto:[email-masked]>> wrote:
>>> 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 
>>>            |      \                              |
>>>            |       \                             |
>>>            |        \                            |
>>>            |         \                           |
>>>     +-----------+     +---------------+     +------------+
>>>     |           |---->| Authorization |     |            |
>>>     |           | (2) |  Server (AS)  |     |            |
>>>     |           |<----|               |     |            |
>>>     |  Client   |     +---------------+     |            |
>>>     |           |-------------------------->|  Resource  |
>>>     |   User    |           (1)             |   Server   |
>>>     |  Consent  |<--------------------------|    (RS)    |
>>>     |  element  |                           |            |
>>>     |           |-------------------------->|            |------>
>>>     |           |           (3)             |            |  (4)
>>>     |           |<--------------------------|            |<------
>>>     +-----------+                           +------------+
>>> 
>>> Which party has the client authenticated to? The client authenticating with FIDO is confusing to me. FIDO is usually how a user authenticates.
>> If the user has previously opened a user account with the RS using FIDO, then the client may be authenticated by the RS using FIDO.
>> In such a case, the user is already known to the RS under a pseudonym specific to the RS. It may (or may not) have previously presented access tokens 
>> to that RS.
>> 
>> For a private usage, the user may use DuckDuckGo, while for business he may use an application from his company which lists various services 
>> available in the context of his job or his position. Some services may be freely available to all the employees of the company with any authentication,
>> e.g. the phone book of the employees may be freely available on the intranet of the company, while some other services may require the user 
>>>  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. 
>>> 
>> (1a) is the first exchange for (1) with the arrow from left to right, while (1b) is the response with the arrow from right to left. 
>>> This information is specifically marked to indicate that it shall be handled by the "User Consent element" from the Client. 
>>> 
>> In the response, a specific identifier or a magic number is used to indicate the start and the length of the information block  
>>> The presentation of that information is up to the man machine interface supported by the "User Consent element" from the Client. 
>>> 
>>> 
>>> Which information? 
>> The attributes that are needed by the RS for performing a requested operation and from which Attributes Servers they may be obtained.
>> 
>>> 
>>> 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 
>> For each AS trusted by the RS to perfom a given operation, the RS should indicate a user-friendly name and a URL of the AS. 
>> 
>>> The user consent is hence captured locally by the Client (i.e. there is no dialogue with any AS nor any RS).
>>> 
>>> 
>> For the user consent, there is no external call since it is handled locally. Afterwards, there is a call to the AS(s) selected by the user.
>> 
>>> 
>>> 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).
>>> 
>>> 
>>> So the RS must trust the AS that issued the tokens. And the AS must trust the Client to have gathered consent.
>> Only when the user chooses one AS while giving its consent, then the user must have a relationship with the selected AS.
>> 
>>> It is unclear what role the RO is playing in this though. The RO and RS look to be the same entity from all the other parties.
>> A RO, as indicated on the figure, has only a relationship with one RS: it has no relationship with any AS. 
>>> From my current understanding, at a high level, this looks like it is supported by GNAP with the addition of the discovery step (1).
>> 1) The first major difference is that there is no arrow between the RO and the AS. No protocol or "out-of-bands" means are necessary. 
>> 
>> 2) The second major difference is that there is no arrow between the AS and the RS. No protocol is necessary.
>> 
>> 3) The third major difference is that the AS does not know any RS. Note: for backward compatibility reasons, an exception might exist for "old" Auth 2.0 ASs.
>> 
>> 4) The fourth major difference is that the XAuth spec. is rather vague to describe when and by who the user consent is captured: 
>>     XAuth states on page 4: "User consent is often required at the GS". In that case, the GS is able to act as Big Brother. No other case is described.
>> 
>> 5) The fifth major difference is that the data that is transferred to a "User Consent Element" to capture the user consent. That data can be standardized. 
>>     Moreover, it will also be possible to standardize the dialogue between the RO and the RS. The RO will then be able to manage remotely the authorization tables.
>>     See my email sent on June 6, with the following subject: "Support of FIDO and data minimization by RSs".
>> 
>> 6) Another difference is the following: since there is no interaction between the RO and the AS, "authorizations from the RO" as described in XAuth do not exist.  
>>> There have been a number of proposals for doing this discovery, and perhaps now there are enough use cases to look at standardizing something.  
>>> No interaction is needed between the AS and the User as the Client is providing enough "information" in the user object of the Grant Request 
>>> Perhaps as I understand the model in more detail I will understand what is missing from GNAP (besides the discovery step).
>> It would be hard to say "what is missing" from XAuth since the foundations are not the same.
>> 
>> In order to compare different architectures, there is the need to start with the trust relationships. 
>> Unfortunately, the word "trust" is absent in the main body of draft-hardt-xauth-protocol-12. Hence, 
>>> (I've skipped reviewing the delegation use case below until I understand the simple use 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.
>>> 
>>> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
>>> ᐧ
>> 
> 
> -- 
> Txauth mailing list
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
> -- 
> Txauth mailing list
> [email-masked]

---

From: Denis <[email-masked]>
Date: Mon, 13 Jul 2020 21:22:11 +0200

Hi Justin,

You have perfectly understood the differences. The location where the 
user consent is gathered /i//n a uniform way/ using to the information 
released by the RS
is a fundamental element of the design.

> If I’m understanding Denis’s proposal, he’s saying that that “prior 
> step” is the lynchpin of the whole model, since interaction between 
> the client and the RS (and the user and the RS) is key to Denis’s 
> privacy model. Additionally, what happens *at* each step is different. 
> Consent is gathered at the client, not the GS in this diagram, for 
> example. The GS simply mints a token as specified by the client and 
> the RS.
>
> It’s for these reasons that, as long as I’ve been understanding 
> correctly, I’ve been saying that Denis’s model as proposed is pretty 
> different.

Indeed.

Denis

> But what I think isn’t that different is the different steps if you’re 
> willing to look at the boundaries around the boxes differently. For 
> example, what OAuth would call “the AS” might end up being a few 
> different boxes in GNAP that do different things. I had started down 
> that route with XYZ’s design allowing the interaction to be managed 
> separately.
>
> I think that the disconnect we’re seeing here might be caused by 
> vocabulary mismatches. If we aren’t meaning the same thing when we say 
> the same terms, it’s easy to get things mixed up with each other. 
> Since GNAP is just barely forming its vocabulary out of the legacy of 
> OAuth and kin, we have a chance to maybe draw the lines better and see 
> if that’s how we can get things to fit.
>
>  — Justin
>
>> On Jul 13, 2020, at 2:02 PM, Dick Hardt <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>
>> I'm going to just address the first part of your response so that we 
>> can get clarity on that before diving into your later comments.
>>
>> The calls between your proposal and XAuth are not inverted, your 
>> proposal has a prior step. Step 1 in XAuth maps to Step 2 in your 
>> proposal, and Step 2 in XAuth is Step 3 in your proposal..
>>
>> Below are 2 diagrams showing the same steps, the first keeping the 
>> existing step labels for XAuth, the latter renaming the steps to 
>> correspond to your proposal. This looks pretty similar to your 
>> diagram. What am I missing?
>>
>> /Dick
>>
>>     No. There is a fundamental difference with the sequencing of the
>>     flow of the exchanges where the (1) and (2) flows are inverted.
>>
>>     In your figure:
>>
>>     In your figure, the first flow is with the GS, whereas in my
>>     figure the first flow is with the RS and there is a good reason
>>     for that:
>>     the client first contacts the RS to know what the RS expects. The
>>     client indicates in its first exchange to the RS whether it wants
>>     to authenticate
>>     or to perform another operation.  In the case of an
>>     authentication operation, the RS may respond to the client that
>>     is supports FIDO U2F
>>     Then after the client has to figure out whether the user is using
>>     FIDO and if not whether the user has an account with one of the AS.
>>     In the later case, if there is a match then the client,/*after
>>     having received the user consent*/, may contact the appropriate
>>     AS to ask
>>     for some attribute(s).
>>
>>     draft-richer-transactional-authz-06 (XYZ) where the first
>>     exchange is done with the AS:
>>         A) The Client making a call to the RS to discover what it
>>         needs from a GS, and which GS to ask, prior to (1).
>>
>>     This is not missing since this is the foundation of the
>>     architecture. The discovery mechanism at the RS has been described
>>     According to the operation announced by the Client, the RS
>>     returns to the Client both the mathematical expression
>>     associated with that operation and the conditions included in
>>     that mathematical expression. The Client may then
>>     The user consent should not be captured *by the GS*, since the GS
>>     would be in a position to apply a different consent decision
>>     The user consent must be captured *by the Client* and the Client
>>     must be able to verify that this consent has indeed been followed
>>     by the AS.
>>
>>     The authorization data managed at the RS by the RO is used by the
>>     Client to query the consent of the user in a standardized manner.
>>     When, later on, the access token is returned to the Client by the
>>     AS, the Client (not the user) using that authorization data as
>>     well as
>>     the decision of the user is able to verify that the requested
>>     attributes (and no more) are indeed present into the access token.
>>
>>>     A) The Client making a call to the RS to discover what it needs
>>>     from a GS, and which GS to ask, prior to (1).
>>>     The current protocol does not require the GS to interact with
>>>     either the User, the RO, or the RS -- which looks to me to meet
>>>     your privacy goals.
>>>
>>>     ᐧ
>>>
>>>>         Hi Denis, thanks for sharing the model. I don't fully
>>>>         understand what is going on, questions inserted:
>>>         Responses are inserted.
>>>>
>>>>         FWIW: having paragraphs start with the step number (1), (2)
>>>>         etc. would make it easier to map between the description
>>>>         and the diagram.
>>>>
>>>>             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.
>>>>
>>>>             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
>>>>         authenticating with FIDO is confusing to me. FIDO is
>>>>         usually how a user authenticates.
>>>
>>>         If the user has previously opened a user account with the RS
>>>         using FIDO, then the client may be authenticated by the RS
>>>         using FIDO.
>>>         pseudonym specific to the RS. It may (or may not) have
>>>         previously presented access tokens
>>>         to that RS.
>>>
>>>         business he may use an application from his company which
>>>         lists various services
>>>         available in the context of his job or his position. Some
>>>         services may be freely available to all the employees of the
>>>         company with any authentication,
>>>         e.g. the phone book of the employees may be freely available
>>>         on the intranet of the company, while some other services
>>>         may require the user
>>>>         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.
>>>>
>>>>             attributes are needed by the RS for performing the
>>>>             requested operation and from which Attributes Servers
>>>>             they may be obtained.
>>>>
>>>         (1a) is the first exchange for (1) with the arrow from left
>>>         to right, while (1b) is the response with the arrow from
>>>         right to left.
>>>>             This information is specifically marked to indicate
>>>>             that it shall be handled by the "User Consent element"
>>>>             from the Client.
>>>>
>>>         In the response, a specific identifier or a magic number is
>>>         used to indicate the start and the length of the information
>>>         block
>>>>         The presentation of that information is up to the man
>>>>         machine interface supported by the "User Consent element"
>>>>         from the Client.
>>>>
>>>>
>>>>         Which information?
>>>
>>>         requested operation and from which Attributes Servers they
>>>         may be obtained.
>>>
>>>>
>>>>             The user can see which attributes are requested by the
>>>>             RS for performing the requested operation and, if it
>>>         For each AS trusted by the RS to perfom a given operation,
>>>         the RS should indicate a user-friendly name and a URL of the
>>>         AS.
>>>
>>>>             The user consent is hence captured locally by the
>>>>             Client (i.e. there is no dialogue with any AS nor any RS).
>>>>
>>>>
>>>         handled locally. Afterwards, there is a call to the AS(s)
>>>         selected by the user.
>>>
>>>>
>>>>             authorization servers (2b), it sends all of them in a
>>>>             single request to the RS (3a).
>>>>
>>>>
>>>>         So the RS must trust the AS that issued the tokens. And the
>>>>         AS must trust the Client to have gathered consent.
>>>         Only when the user chooses one AS while giving its consent,
>>>         then the user must have a relationship with the selected AS.
>>>
>>>>         It is unclear what role the RO is playing in this though.
>>>         A RO, as indicated on the figure, has only a relationship
>>>         with one RS: it has no relationship with any AS.
>>>>         From my current understanding, at a high level, this looks
>>>>         like it is supported by GNAP with the addition of the
>>>>         discovery step (1).
>>>
>>>             between the RO and the AS. No protocol or "out-of-bands"
>>>             means are necessary.
>>>
>>>             3) The third major difference is that the AS does not
>>>             know any RS. Note: for backward compatibility reasons,
>>>             an exception might exist for "old" Auth 2.0 ASs.
>>>
>>>             4) The fourth major difference is that the XAuth spec.
>>>             is rather vague to describe when and by who the user
>>>             consent is captured:
>>>                 XAuth states on page 4: "User consent is /often
>>>             /required at the GS". In that case, the GS is able to
>>>             act as Big Brother. No other case is described.
>>>
>>>             transferred to a "User Consent Element" to capture the
>>>             user consent. That data can be standardized.
>>>                 Moreover, it will also be possible to standardize
>>>             the dialogue between the RO and the RS. The RO will then
>>>             be able to manage remotely the authorization tables.
>>>                 See my email sent on June 6, with the following
>>>             subject: "Support of FIDO and data minimization by RSs".
>>>
>>>             6) Another difference is the following: since there is
>>>             no interaction between the RO and the AS,
>>>             "authorizations from the RO" as described in XAuth do
>>>             not exist. 
>>>
>>>>         There have been a number of proposals for doing this
>>>>         discovery, and perhaps now there are enough use cases to
>>>>         look at standardizing something.
>>>>         Client is providing enough "information" in the user object
>>>>         of the Grant Request
>>>         In order to compare different architectures, there is the
>>>         need to start with the trust relationships.
>>>>             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.
>>>>
>>>>             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).
>>>>
>>>>             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.
>>>>

---

From: Dick Hardt <[email-masked]>
Date: Mon, 13 Jul 2020 12:33:36 -0700

I get that the Client<->RS step is critical to the use case, as is the User
not interacting with the GS, but there are other use cases where the User
does not interact with the GS, for example
https://tools.ietf.org/html/draft-hardt-xauth-protocol-11#section-2.3., but
Denis's use case should not be the only use case.

So it seems that GNAP can support Denis's use case by defining the
initial Client<->RS interaction, and the information in the user object of
the Grant Request to be what the GS needs to issue access tokens, which was
what I suggested earlier.

I don't understand what is missing, besides the details of the Client<->RS
interaction, and what is in the Grant Request.

On Mon, Jul 13, 2020 at 12:22 PM Denis <[email-masked]> wrote:

> Hi Justin,
>
> You have perfectly understood the differences. The location where the user
> consent is gathered *i**n a uniform way* using to the information
> released by the RS
> If I’m understanding Denis’s proposal, he’s saying that that “prior step”
> is the lynchpin of the whole model, since interaction between the client
> and the RS (and the user and the RS) is key to Denis’s privacy model.
> Additionally, what happens *at* each step is different. Consent is gathered
> at the client, not the GS in this diagram, for example. The GS simply mints
> a token as specified by the client and the RS.
>
> It’s for these reasons that, as long as I’ve been understanding correctly,
> I’ve been saying that Denis’s model as proposed is pretty different.
>
> Indeed.
>
> Denis
>
> example, what OAuth would call “the AS” might end up being a few different
> boxes in GNAP that do different things. I had started down that route with
> XYZ’s design allowing the interaction to be managed separately.
>
> vocabulary mismatches. If we aren’t meaning the same thing when we say the
> same terms, it’s easy to get things mixed up with each other. Since GNAP is
> just barely forming its vocabulary out of the legacy of OAuth and kin, we
> have a chance to maybe draw the lines better and see if that’s how we can
> get things to fit.
>
>  — Justin
>
> 2 in XAuth is Step 3 in your proposal..
>
> existing step labels for XAuth, the latter renaming the steps to correspond
> to your proposal. This looks pretty similar to your diagram. What am I
> missing?
>
> /Dick
>
>>> indicate directly the operation that it wants to perform on the RS without
>>> any prior dialogue.
>>>
>>>> performing the requested operation and, if it consents, the Client contacts
>>>> one or more
>>> 4) The fourth major difference is that the XAuth spec. is rather vague
>>> to describe when and by who the user consent is captured:

---

From: Denis <[email-masked]>
Date: Mon, 13 Jul 2020 22:06:34 +0200

Dick,

You wrote: "I don't understand what is missing". The response is in my 
previous email.
The *user consent* is always requested by the Client and hence it is 
never requested by the GS/AS.

Two other important points:

1° At the first exchange, the RS discloses the elements of an 
authorization table
      that are directly dependent upon the operation that the client is 
willing to perform.

2° I propose a way to integrate FIDO, since FIDO allows to support the 
user's authentication phase
      by disclosing only a pseudonym unique to the RS.

Denis

> I get that the Client<->RS step is critical to the use case, as is the 
> User not interacting with the GS, but there are other use cases where 
> the User does not interact with the GS, for example 
> https://tools.ietf.org/html/draft-hardt-xauth-protocol-11#section-2.3., 
> but Denis's use case should not be the only use case.
>
> initial Client<->RS interaction, and the information in the user 
> object of the Grant Request to be what the GS needs to issue access 
> tokens, which was what I suggested earlier.
>
> I don't understand what is missing, besides the details of the 
> Client<->RS interaction, and what is in the Grant Request.
>
>
> On Mon, Jul 13, 2020 at 12:22 PM Denis <[email-masked] 
>     You have perfectly understood the differences. The location where
>     the user consent is gathered /i//n a uniform way/ using to the
>     information released by the RS
>>     If I’m understanding Denis’s proposal, he’s saying that that
>>     “prior step” is the lynchpin of the whole model, since
>>     interaction between the client and the RS (and the user and the
>>     RS) is key to Denis’s privacy model. Additionally, what happens
>>     *at* each step is different. Consent is gathered at the client,
>>     not the GS in this diagram, for example. The GS simply mints a
>>     token as specified by the client and the RS.
>>
>>     correctly, I’ve been saying that Denis’s model as proposed is
>>     pretty different.
>
>     Indeed.
>
>     Denis
>
>>     But what I think isn’t that different is the different steps if
>>     you’re willing to look at the boundaries around the boxes
>>     differently. For example, what OAuth would call “the AS” might
>>     end up being a few different boxes in GNAP that do different
>>     things. I had started down that route with XYZ’s design allowing
>>     the interaction to be managed separately.
>>
>>     vocabulary mismatches. If we aren’t meaning the same thing when
>>     we say the same terms, it’s easy to get things mixed up with each
>>     other. Since GNAP is just barely forming its vocabulary out of
>>     the legacy of OAuth and kin, we have a chance to maybe draw the
>>     lines better and see if that’s how we can get things to fit.
>>
>>      — Justin
>>
>>>     I'm going to just address the first part of your response so
>>>     that we can get clarity on that before diving into your later
>>>     comments.
>>>
>>>     proposal has a prior step. Step 1 in XAuth maps to Step 2 in
>>>     your proposal, and Step 2 in XAuth is Step 3 in your proposal..
>>>
>>>     Below are 2 diagrams showing the same steps, the first keeping
>>>     the existing step labels for XAuth, the latter renaming the
>>>     steps to correspond to your proposal. This looks pretty similar
>>>     to your diagram. What am I missing?
>>>
>>>     /Dick
>>>
>>>         No. There is a fundamental difference with the sequencing of
>>>         the flow of the exchanges where the (1) and (2) flows are
>>>         inverted.
>>>
>>>         In your figure:
>>>
>>>         figure the first flow is with the RS and there is a good
>>>         reason for that:
>>>         the client first contacts the RS to know what the RS
>>>         expects. The client indicates in its first exchange to the
>>>         RS whether it wants to authenticate
>>>         authentication operation, the RS may respond to the client
>>>         that is supports FIDO U2F
>>>         Then after the client has to figure out whether the user is
>>>         using FIDO and if not whether the user has an account with
>>>         one of the AS.
>>>         In the later case, if there is a match then the
>>>         client,/*after having received the user consent*/, may
>>>         contact the appropriate AS to ask
>>>         for some attribute(s).
>>>
>>>             A) The Client making a call to the RS to discover what
>>>             it needs from a GS, and which GS to ask, prior to (1).
>>>
>>>         in details in an earlier email with the following title:
>>>         associated with that operation and the conditions included
>>>         in that mathematical expression. The Client may then
>>>         The user consent should not be captured *by the GS*, since
>>>         the GS would be in a position to apply a different consent
>>>         decision
>>>         The user consent must be captured *by the Client* and the
>>>         Client must be able to verify that this consent has indeed
>>>         been followed by the AS.
>>>
>>>         The authorization data managed at the RS by the RO is used
>>>         by the Client to query the consent of the user in a
>>>         standardized manner.
>>>         When, later on, the access token is returned to the Client
>>>         by the AS, the Client (not the user) using that
>>>         authorization data as well as
>>>         the decision of the user is able to verify that the
>>>         requested attributes (and no more) are indeed present into
>>>         the access token.
>>>
>>>>         The current protocol does not require the GS to interact
>>>>         with either the User, the RO, or the RS -- which looks to
>>>>         me to meet your privacy goals.
>>>>
>>>>         ᐧ
>>>>
>>>>>             FWIW: having paragraphs start with the step number
>>>>>             (1), (2) etc. would make it easier to map between the
>>>>>             description and the diagram.
>>>>>
>>>>>             On Thu, Jul 9, 2020 at 3:26 AM Denis
>>>>>             <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>
>>>>>                 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
>>>>>             Which party has the client authenticated to? The
>>>>>             client authenticating with FIDO is confusing to me.
>>>>>             FIDO is usually how a user authenticates.
>>>>
>>>>             If the user has previously opened a user account with
>>>>             the RS using FIDO, then the client may be authenticated
>>>>             by the RS using FIDO.
>>>>             In such a case, the user is already known to the RS
>>>>             under a pseudonym specific to the RS. It may (or may
>>>>             not) have previously presented access tokens
>>>>             to that RS.
>>>>
>>>>             For a private usage, the user may use DuckDuckGo, while
>>>>             for business he may use an application from his company
>>>>             which lists various services
>>>>             available in the context of his job or his position.
>>>>             Some services may be freely available to all the
>>>>             employees of the company with any authentication,
>>>>             e.g. the phone book of the employees may be freely
>>>>             available on the intranet of the company, while some
>>>>             other services may require the user
>>>>>             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.
>>>>>
>>>>             (1a) is the first exchange for (1) with the arrow from
>>>>             left to right, while (1b) is the response with the
>>>>             arrow from right to left.
>>>>>                 This information is specifically marked to
>>>>>                 indicate that it shall be handled by the "User
>>>>>                 Consent element" from the Client.
>>>>>
>>>>             In the response, a specific identifier or a magic
>>>>             number is used to indicate the start and the length of
>>>>             the information block
>>>>>             machine interface supported by the "User Consent
>>>>>             element" from the Client.
>>>>>
>>>>>
>>>>>             Which information?
>>>>
>>>>             The attributes that are needed by the RS for performing
>>>>             a requested operation and from which Attributes Servers
>>>>             they may be obtained.
>>>>
>>>>>
>>>>>                 The user can see which attributes are requested by
>>>>>                 the RS for performing the requested operation and,
>>>>             For each AS trusted by the RS to perfom a given
>>>>             operation, the RS should indicate a user-friendly name
>>>>             and a URL of the AS.
>>>>
>>>>             For the user consent, there is no external call since
>>>>             it is handled locally. Afterwards, there is a call to
>>>>             the AS(s) selected by the user.
>>>>
>>>>>
>>>>>                 authorization servers (2b), it sends all of them
>>>>>                 in a single request to the RS (3a).
>>>>>
>>>>>
>>>>>             So the RS must trust the AS that issued the tokens.
>>>>>             And the AS must trust the Client to have gathered consent.
>>>>             Only when the user chooses one AS while giving its
>>>>             consent, then the user must have a relationship with
>>>>             the selected AS.
>>>>
>>>>>             It is unclear what role the RO is playing in this
>>>>>             though. The RO and RS look to be the same entity from
>>>>>             all the other parties.
>>>>
>>>>             A RO, as indicated on the figure, has only a
>>>>             relationship with one RS: it has no relationship with
>>>>             any AS.
>>>>>             From my current understanding, at a high level, this
>>>>>             looks like it is supported by GNAP with the addition
>>>>>             of the discovery step (1).
>>>>
>>>>                 1) The first major difference is that there is no
>>>>                 arrow between the RO and the AS. No protocol or
>>>>                 "out-of-bands" means are necessary.
>>>>
>>>>                 2) The second major difference is that there is no
>>>>                 arrow between the AS and the RS. No protocol is
>>>>                 necessary.
>>>>
>>>>                 3) The third major difference is that the AS does
>>>>                 not know any RS. Note: for backward compatibility
>>>>                 reasons, an exception might exist for "old" Auth
>>>>                 2.0 ASs.
>>>>
>>>>                 4) The fourth major difference is that the XAuth
>>>>                 spec. is rather vague to describe when and by who
>>>>                 the user consent is captured:
>>>>                 /required at the GS". In that case, the GS is able
>>>>                 to act as Big Brother. No other case is described.
>>>>
>>>>                 5) The fifth major difference is that the data that
>>>>                 is transferred to a "User Consent Element" to
>>>>                 capture the user consent. That data can be
>>>>                 standardized.
>>>>                     Moreover, it will also be possible to
>>>>                 standardize the dialogue between the RO and the RS.
>>>>                 The RO will then be able to manage remotely the
>>>>                 authorization tables.
>>>>                 6) Another difference is the following: since there
>>>>                 is no interaction between the RO and the AS,
>>>>                 "authorizations from the RO" as described in XAuth
>>>>                 do not exist. 
>>>>
>>>>>             discovery, and perhaps now there are enough use cases
>>>>>             to look at standardizing something.
>>>>>             No interaction is needed between the AS and the User
>>>>>             as the Client is providing enough "information" in the
>>>>>             user object of the Grant Request
>>>>>             Perhaps as I understand the model in more detail I
>>>>>             will understand what is missing from GNAP (besides the
>>>>>             discovery step).
>>>>
>>>>             In order to compare different architectures, there is
>>>>             the need to start with the trust relationships.
>>>>             Unfortunately, the word "trust" is absent in the main
>>>>             body of draft-hardt-xauth-protocol-12. Hence,
>>>>>                 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
>>>>>                 attributes are requested by RS2 for performing the
>>>>>                 new requested operation and, if it consents, the
>>>>>                 appropriate Authorization Servers. The user
>>>>>                 consent is hence captured locally by the "User
>>>>>                 Consent element" from the Client. (i.e. there is
>>>>>                 single request to RS1. RS1 then forwards the
>>>>>                 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.
>>>>>                 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

---

From: Dick Hardt <[email-masked]>
Date: Mon, 13 Jul 2020 13:19:36 -0700

Denis: it looks like we are talking past each other.

Are you suggesting that GNAP *ONLY *as you have proposed?

Otherwise, it looks to me like your requirements can be added to GNAP.

ᐧ

On Mon, Jul 13, 2020 at 1:06 PM Denis <[email-masked]> wrote:

> User not interacting with the GS, but there are other use cases where the
> User does not interact with the GS, for example
>> user consent is gathered *i**n a uniform way* using to the information
>> released by the RS
>>>> Note: for backward compatibility reasons, an exception might exist for
>>>> "old" Auth 2.0 ASs.
>>>>
>>>>> Attributes Servers they may be obtained. RS1 forwards that information to
>>>>> the Client.
>>>>>