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

[Dick Hardt <[e-mail]>]

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 <[e-mail]> wrote:

> 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.
>
> 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 <[e-mail]> 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
>> 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 <[e-mail]> 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
>>
>> DIAGRAM 1 (steps start at 0)
>>
>>        +--------+                           +------------+
>>        |  User  |                           |  Resource  |
>>        |        |                           | Owner (RO) |
>>        +--------+                           +------------+
>>            |      \                       /      |
>>            |       \                     /       |
>>            |        \                   /        |
>>            |         \                 /         |
>>        +--------+     +---------------+     +------------+
>>        | Client |---->|     Grant     |     |  Resource  |
>>        |        | (1) |  Server (GS)  | _ _ |   Server   |
>>        |        |<----|               |     |    (RS)    |
>>        |        |     +---------------+     |            |
>>        |        |-------------------------->|            |
>>        |        |           (2)             |            |
>>        |        |<--------------------------|            |
>>        |        |-------------------------->|            |
>>        |        |           (0)             |            |
>>        |        |<--------------------------|            |
>>        +--------+                           +------------+
>>
>> DIAGRAM 2 (steps start at 1)
>>
>>        +--------+                           +------------+
>>        |  User  |                           |  Resource  |
>>        |        |                           | Owner (RO) |
>>        +--------+                           +------------+
>>            |      \                       /      |
>>            |       \                     /       |
>>            |        \                   /        |
>>            |         \                 /         |
>>        +--------+     +---------------+     +------------+
>>        | Client |---->|     Grant     |     |  Resource  |
>>        |        | (2) |  Server (GS)  | _ _ |   Server   |
>>        |        |<----|               |     |    (RS)    |
>>        |        |     +---------------+     |            |
>>        |        |-------------------------->|            |
>>        |        |           (3)             |            |
>>        |        |<--------------------------|            |
>>        |        |-------------------------->|            |
>>        |        |           (1)             |            |
>>        |        |<--------------------------|            |
>>        +--------+                           +------------+
>>
>> ᐧ
>>
>> On Mon, Jul 13, 2020 at 7:08 AM Denis <[e-mail]> wrote:
>>
>>> 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:
>>>
>>> The Client makes calls to the GS (1)
>>> The Client makes calls to the RS (2)
>>>
>>> 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
>>>
>>>    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 <[e-mail]> 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 <[e-mail]> wrote:
>>>>
>>>>> 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)
>>>>>
>>>> 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.
>>>>
>>>>  contacts the RS and after some dialogue with the RS selects an
>>>> operation
>>>> 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.
>>>>
>>>>  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) and (1b) are not labeled. There is only (1)
>>>>
>>>> (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.
>>>>>
>>>> Why? What is the significance of this? Which information is marked?
>>>>
>>>> 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.
>>>>
>>>> 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
>>>>> appropriate Authorization Servers (2a).
>>>>>
>>>> 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).
>>>>>
>>>>
>>>> No dialogue with who? The client is calling the AS is it not?
>>>>
>>>> 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.
>>>>
>>>>
>>>> From my current understanding, at a high level, this looks like it is
>>>> 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)
>>>>
>>>>
>>>>> End of the story for a simple access
>>>>>
>>>>>
>>>>> Start of a subsequent story for a delegation case
>>>>>
>>>>> Let us now suppose that the RS is unable to fulfil the request by its
>>>>> own and that it needs to contact another RS. RS1 contacts RS2 (4a) and
>>>>> indicates the operation
>>>>> that it wants to perform on RS2 (that operation may not be the same as
>>>>> the original operation). In return (4b), RS2 informs RS1 about which
>>>>> attributes are needed
>>>>> by RS2 for performing the requested operation and from which
>>>>> Attributes Servers they may be obtained. RS1 forwards that information to
>>>>> the Client.
>>>>>
>>>>> This information is marked to indicate that it shall be handled by the
>>>>> "User Consent element" from the Client. The presentation of that
>>>>> information is up to the man machine
>>>>> interface from the Client. The user can see which attributes are
>>>>> requested by RS2 for performing the new requested operation and, if it
>>>>> consents, the Client contacts one or more
>>>>> appropriate Authorization Servers. The user consent is hence captured
>>>>> locally by the "User Consent element" from the Client. (i.e. there is no
>>>>> dialogue with any AS, nor RS1, nor RS2).
>>>>>
>>>>> When the Client got the access token(s) from the authorization
>>>>> server(s), it sends all of them in a single request to RS1. RS1 then
>>>>> forwards the additional access token(s) to RS2.
>>>>>
>>>>>
>>>>> Some observations:
>>>>>
>>>>> The user nor the Client are linked with any particular AS. A user may
>>>>> use today an AS of the Bank of America and may change tomorrow to the Bank
>>>>> of Missouri.
>>>>> As soon as he will be registered with the Bank of Missouri, he will be
>>>>> able to get access tokens from the AS of the Bank of Missouri. The AS of
>>>>> Bank of America
>>>>> has not been able to know where its access tokens have been used. This
>>>>> will be the same for AS of the Bank of Missouri. There is no need for any
>>>>> direct dialogue
>>>>> between any AS and any RS at the time a client is making an access.
>>>>> There is no need for any RO to contact any AS.
>>>>>
>>>>> This model has been constructed following a "Privacy by Design"
>>>>> approach.
>>>>> Denis
>>>>>
>>>>> --
>>>>> Txauth mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>>
>>>> ᐧ
>>>>
>>>>
>>>>
>>> --
>>> Txauth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/txauth
>>>
>> --
>> Txauth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/txauth
>>
>>
>>
>> --
>> Txauth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/txauth
>>
>
> --
> Txauth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>