Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11

[Dick Hardt <[e-mail]>]

Hi Denis

The Client / Server concept in GNAP (which it inherits from OAuth) is that
the Client is the thing that wants a resource, and the Server is the thing
that has the resource. Access to the resource is managed by the GS/AS.

So a web server that wants data from another server, is a Client.

*I* would solve the use case as I described (details on the RS / GS are
vague in the problem, so are vague in my solution)



On Tue, Jul 28, 2020 at 10:09 AM Denis <[e-mail]> wrote:

> Hi Dick,
>
> OK. I should have written that in my example: the student connects to the
> University server (i.e. a RS) *using* a client.
>
> A client is a piece of software (supported by some hardware) that the user
> uses to interact with RS(s) and AS(s).
>
> In a Client / Server model, the University Server cannot be a client: it
> is a server.
>
> Nevertheless, my first question still remains: Would you explain how *you*
> would handle the use case of a student registering to a new University ?
>
> Denis
>
> Hi Denis
>
> I did answer your question. The student is the User. The student is not
> the Client.
>
> ᐧ
>
> On Tue, Jul 28, 2020 at 7:12 AM Denis <[e-mail]> wrote:
>
>> Hi Dick,
>>
>> I am puzzled by your response. Your are the editor and a co-editor of the
>> two following RFCs which state:
>>
>> RFC 6749:    In the traditional client-server authentication model, the
>> client requests an access-restricted resource
>>                      (protected resource) on the server by authenticating
>> with the server (...)
>>
>> RFC 6750 : The client uses the access token to access the protected
>> resources hosted by the resource server.
>>
>>                     The following two steps are specified within this
>> document:
>>
>>                                (E)  The client requests the protected
>> resource from the resource server and authenticates
>>                                        by presenting the access token.
>>
>>                               (F)  The resource server validates the
>> access token, and if valid, serves the request.
>>
>> In my use case, the student connects to the University server (i.e. a RS)
>> as a client. The University server cannot be a Client.
>> If you change/twist that basic vocabulary, we will not be able to
>> understand each other any more.
>>
>> BTW, my first question still remains: Would you explain how you would
>> handle the use case of a student registering to a new University ?
>>
>> Denis
>>
>>
>> Hi Denis
>>
>> The student (User) goes to the registration page of the University (the
>> Client)
>>
>> Similar to your example, the Client has a list of GS that it are
>> acceptable, or RS that may be acceptable.
>>
>> If the User selects a GS, then the Client starts a GNAP flow with the GS.
>>
>> If the User selects an RS, then the Client can call the RS to determine
>> which GSes to offer the User to use to get access to the RS.
>>
>> In summary, the University wants to consume Claims about the User, so it
>> is the Client.
>>
>> /Dick
>>
>>
>>
>> On Mon, Jul 27, 2020 at 12:49 AM Denis <[e-mail]> wrote:
>>
>>> Hi Dick,
>>>
>>> The floor is yours.
>>>
>>> Would you explain how you would handle the use case of a student
>>> registering to a new University ?
>>>
>>> Would you also elaborate why in my explanations below, you think that
>>> "the University's registration system is the Client, not a Resource Server"
>>> ?
>>>
>>> Denis
>>>
>>> Hi Denis
>>>
>>> I would think in your example below, that the University's registration
>>> system is the Client, not a Resource Server.
>>>
>>> Have a good night's sleep!
>>>
>>>
>>>
>>> On Fri, Jul 24, 2020 at 12:04 PM Denis <[e-mail]> wrote:
>>>
>>>> Hi Dick,
>>>>
>>>> In order to send back a quick reply tonight, I will only respond to one
>>>> of your questions:
>>>>
>>>> [Denis] How would be the data flow when access tokens from two GSs are
>>>> needed by a RS ?
>>>>
>>>> [Dick] I don't know of a use case where two tokens would be needed by
>>>> an RS. Would you elaborate?
>>>>
>>>> I already described on the list the case of a student registering to a
>>>> new University.
>>>>
>>>> First, the student connects to the RS from the new University and opens
>>>> an account
>>>> (at this time the student is using a pseudo and a private key to
>>>> authenticate). He fills some forms
>>>> and indicate its citizenship, his home address and his graduation in
>>>> his current university.
>>>>
>>>> When he is finished, he indicates that he wants to perform a
>>>> Registration operation.
>>>>
>>>> From the information gathered in the forms, the RS informs the client
>>>> that it needs two access tokens:
>>>>
>>>>    - one to demonstrate that his name and current home address are
>>>>    correct,and
>>>>    - another one to demonstrate that he got a graduation from its
>>>>    current University.
>>>>
>>>> Depending upon the information captured in the forms, the RS also
>>>> indicates which ASs/GSs are acceptable
>>>> and which kind of attributes are requested.
>>>>
>>>> The user consent and choice is performed by the client and once
>>>> approved by the student, two access tokens are separately requested.
>>>> Finally, two access tokens are presented to the RS while invoking a
>>>> Registration operation.
>>>>
>>>> Note that the start of the story is to open an account, e.g. using
>>>> FIDO. The needs of the RS are only disclosed to the student once he has
>>>> filled some forms
>>>> and indicated that he wanted to perform a Registration operation. Thus,
>>>> the needs that are revealed by the RS are dependant both upon the operation
>>>> that the student is willing to perform and the information collected in
>>>> the forms.
>>>>
>>>> Denis
>>>>
>>>> Hi Denis, comments inserted ...
>>>>
>>>> On Fri, Jul 24, 2020 at 9:08 AM Denis <[e-mail]> wrote:
>>>>
>>>>> Hi Dick,
>>>>>
>>>>> draft-hardt-xauth-protocol-13 describes a solution without clearly
>>>>> stating what the problem(s) to be solved is/are.
>>>>>
>>>>
>>>> I agree that the problem description is not as crisp as I would like it
>>>> to be. A challenge is that there is a broad spectrum of use cases solved by
>>>> OAuth 2, and OpenID Connect, as well as the new use cases that are solved
>>>> by GNAP.
>>>>
>>>> That is why I am suggesting we gather some use cases so we have a
>>>> common understanding of the problems that are in scope.
>>>>
>>>>
>>>>>
>>>>> At the moment, draft-hardt-xauth-protocol-13 includes a single figure
>>>>> on page 4 and from previous discussions I understood that
>>>>> it is no more up-to-date since the first data flow is now a contact
>>>>> with a RS. The reason(s) for the GS to contact a RO has still not
>>>>> been explained (since the inputs and outputs are not described). The
>>>>> discovery information made available at various steps at the RS
>>>>> is not described.
>>>>>
>>>>
>>>> I have made no updates as we are in a quiet period prior to the WG
>>>> meeting next week when documents cannot be updated.
>>>>
>>>>
>>>>>
>>>>> Figure 4 shows only a single RS. Is the relaying of one operation by
>>>>> that RS to a second RS in the scope of this document ?
>>>>> If yes, how is it handled ?
>>>>>
>>>>
>>>> I view that as an advanced use case that would be covered in a separate
>>>> document.
>>>>
>>>>
>>>>>
>>>>> Figure 4 shows only a single GS. How would be the data flow when
>>>>> access tokens from two GSs are needed by a RS ?
>>>>>
>>>>
>>>> I don't know of a use case where two tokens would be needed by an RS.
>>>> Would you elaborate?
>>>> The RS being able to accept tokens from two different GSes is covered,
>>>> but the Client is only using a token from one GS at a time.
>>>>
>>>>
>>>>
>>>>>
>>>>> What we need first is not a set of "use cases" but a clear model with
>>>>> a data flows and a list of its properties/characteristics.
>>>>>
>>>>
>>>> I disagree. The use cases describe the problems we are looking to
>>>> solve. The data flows are part of the solution. For example, from my
>>>> understanding of your use case, you don't want the GS to have visibility
>>>> into the User's activity. Am I correct that this is one of your
>>>> requirements for your use case?
>>>>
>>>>
>>>>
>>>>> Then after, we can understand much better which use cases can/will be
>>>>> supported. For example, shall a RS (or its RO) have
>>>>> prior relationships with the GS ? What is the difference/implications
>>>>> when it has or it hasn't ?
>>>>>
>>>>> In order to have a fair comparison, we should try to list model
>>>>> properties/characteristics.
>>>>>
>>>>> At the moment, the model I have described including the data flows is
>>>>> clear. The discovery information made available by a RS is clear.
>>>>> I have not listed all its properties/characteristics of that model,
>>>>> but I am pretty sure that you already have a flavour of it.
>>>>>
>>>>> In the mean time, it would be nice if you could show using two figures:
>>>>>
>>>>>    - the case of the relaying of one operation by one RS to a second
>>>>>    RS (if it is in the scope of your document),
>>>>>    - the case where access tokens from two GSs are needed by one RS
>>>>>    (if it is in the scope of your document).
>>>>>
>>>>>
>>>> See above
>>>>
>>>>
>>>>>
>>>>>    -
>>>>>
>>>>> Denis
>>>>>
>>>>> Hi Denis
>>>>>
>>>>> I think it would be useful to take a step back and for you to describe
>>>>> your use case.
>>>>> After that, we can explore the different ways that your use case can
>>>>> be addressed.
>>>>>
>>>>> Looking at your previous communication, it describes the solution, and
>>>>> the justification,
>>>>> but it is not clear what use cases you are needing to solve.
>>>>>
>>>>> /Dick
>>>>>
>>>>>
>>>>> ᐧ
>>>>>
>>>>> On Wed, Jul 22, 2020 at 9:34 AM Denis <[e-mail]> wrote:
>>>>>
>>>>>> Hello Dick,
>>>>>>
>>>>>> I have identified the reason of the major difference between our two
>>>>>> approaches.
>>>>>>
>>>>>> Access control may be performed using either ACLs (Access Control
>>>>>> Lists) or Capabilities.
>>>>>>
>>>>>> *Note *: a capability identifies a resource and an allowed operation
>>>>>> that can be performed on that resource.
>>>>>>
>>>>>> You are advocating a Capabilities approach while I am advocating an
>>>>>> ACL approach.
>>>>>>
>>>>>> The capabilities approach allows the GS to trace every operation
>>>>>> performed by the users on any RS known by a GS.
>>>>>> The management of these capabilities is made via the GS or at the GS
>>>>>> by the various ROs. If the management is made
>>>>>> via the GS, then a trusted communication channel needs to be
>>>>>> established with every RO. If the management is made
>>>>>> at the GS, then an authentication mechanism needs to be established
>>>>>> with every RO. In the last case, the GS has the
>>>>>> ability to know all the capabilities of the users whether they are
>>>>>> used or not. The less that can be said is that this model
>>>>>> is not privacy friendly.
>>>>>>
>>>>>> With the ACL approach, a RO directly manages an ACL placed in front
>>>>>> of each RS. The Access Control Decision Function
>>>>>> (ADF) at the RS is able to keep track from prior decisions. The GS
>>>>>> is kept ignorant of the content of these ACLs and only
>>>>>> delivers to its clients attributes that are placed into access
>>>>>> tokens. Such a model may be privacy friendly.
>>>>>>
>>>>>> Other comments are between the lines prefixed with [Denis].
>>>>>>
>>>>>>
>>>>>> On Tue, Jul 21, 2020 at 11:26 AM Denis <[e-mail]> wrote:
>>>>>>
>>>>>>> Hello Dick,
>>>>>>>
>>>>>>> Thank you for your feedback. Comments are between the lines.
>>>>>>>
>>>>>>> comments inserted ...
>>>>>>>
>>>>>>> On Tue, Jul 21, 2020 at 6:03 AM Denis <[e-mail]> wrote:
>>>>>>>
>>>>>>>> Hello Dick,
>>>>>>>>
>>>>>>>> I duplicate the most important comment at the beginning of this
>>>>>>>> email:
>>>>>>>>
>>>>>>>> You are considering using an access control model to build a workflow
>>>>>>>> model.
>>>>>>>>
>>>>>>>> While it may be interesting to define a workflow model, this should
>>>>>>>> be considered
>>>>>>>> as a separate and different work item.
>>>>>>>>
>>>>>>>> See the other comments between the lines.
>>>>>>>>
>>>>>>>> On Mon, Jul 20, 2020 at 2:05 AM Denis <[e-mail]> wrote:
>>>>>>>>
>>>>>>>>> Hi Dick,
>>>>>>>>>
>>>>>>>>> On Fri, Jul 17, 2020 at 9:21 AM Denis <[e-mail]> wrote:
>>>>>>>>>
>>>>>>>>>> Hello Francis and Dick,
>>>>>>>>>>
>>>>>>>>>> The good news first: we are making some progress. We are now
>>>>>>>>>> close to an agreement with steps (1) up to (3),
>>>>>>>>>> ... except that the place where the user consent is captured is
>>>>>>>>>> not mentioned/indicated.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This major question which is currently left unanswered is where,
>>>>>>>>> when and how the user consent is captured.
>>>>>>>>>
>>>>>>>>
>>>>>>>> When is covered, per the sequence. How and where are out of scope
>>>>>>>> of what I drafted.
>>>>>>>>
>>>>>>>> It is clear that the "User consent and choice" is not currently
>>>>>>>> addressed in the draft, but it should.
>>>>>>>> The support of the "User consent and choice" has strong
>>>>>>>> implications not only in the sequences of the exchanges
>>>>>>>> but also by which entity it should be performed.
>>>>>>>>
>>>>>>> "consent" is in the latest draft 7 times.
>>>>>>>
>>>>>>> "Consent" is present 5 times. The User consent is different from the
>>>>>>> RO consent (when/if it is required).
>>>>>>>
>>>>>>> The server acquires consent and authorization from the user *and/**or
>>>>>>> resource owner **if required.*
>>>>>>>
>>>>>>> User consent is *often required* at the GS. GNAP enables a Client
>>>>>>> and  GS to negotiate the interaction mode for the GS to obtain consent.
>>>>>>>
>>>>>>> The GS *may *require explicit consent from the RO or User to
>>>>>>> provide these to the Client.
>>>>>>>
>>>>>>> The User consent is not an alternative to the RO consent. So using
>>>>>>> "and/or" in the first sentence is incorrect.
>>>>>>>
>>>>>>
>>>>>> My language is sloppy there. Consent is always from the RO. The User
>>>>>> may be the RO.
>>>>>>
>>>>>> [Denis] No. Once again: The "*User consent*" is different from what
>>>>>> you call the "*RO consent*" (when/if it is required).
>>>>>> The "RO consent" is not in fact a consent but the release of a
>>>>>> capability to a client by one of the many R0s with which
>>>>>> the GS has relationships.
>>>>>>
>>>>>> Since the second sentence is using the wording "often required" there
>>>>>>> is no requirement to get the User consent.
>>>>>>>
>>>>>> User consent may not be required. There may not be a User. The
>>>>>> consent may have been gathered previously.
>>>>>>
>>>>>> [Denis] In order to follow the privacy principles, a "User consent"
>>>>>> phase is required. The User is a natural person.
>>>>>> A Client is called either by a User (i.e. a natural person) or by a
>>>>>> Client application.
>>>>>>
>>>>>> The second sentence does not consider the possibility to get the User
>>>>>>> consent in a place different from the GS.
>>>>>>>
>>>>>> Agreed. But we do agree that the GS gets the consent, either directly
>>>>>> from the RO, or from the Client (in your example).
>>>>>>
>>>>>> [Denis] No. I disagree. In an ACL based systems, the GS does not need
>>>>>> to ask or receive any consent.
>>>>>> The client selects the set of attributes that it wants to be inserted
>>>>>> into an access token.
>>>>>> If the GS has the requested attributes, then it provides them,
>>>>>> otherwise it returns an error to the Client.
>>>>>>
>>>>>> IMO, the User consent should be captured by the Client, i.e. not by
>>>>>>> the GS.
>>>>>>> The information used to obtain the User consent should be
>>>>>>> standardized (... and it can be standardized).
>>>>>>>
>>>>>>> I think the abstract sequence as proposed by Francis is a great
>>>>>>> addition, and would clarify where consent is in the sequence.
>>>>>>>
>>>>>>> The current sketch does not illustrate the place the User Consent is
>>>>>>> captured, in particular by the Client.
>>>>>>>
>>>>>> It is an abstraction. The GS receives the consent. How consent is
>>>>>> gathered is a detail that is dependent on the use case.
>>>>>>
>>>>>> [Denis] I really wonder whether there is really a "consent" to be
>>>>>> received by the GS in both cases (i.e. ACLs or Capabilities).
>>>>>>
>>>>>>    - For ACLs, the consent needs to be done by the Client.
>>>>>>    - For Capabilities, the current description is not clear since
>>>>>>    the inputs and the outputs for this "consent" phase
>>>>>>    are not currently described in the draft.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Another important point to consider and to explain is related to
>>>>>>>>> the assurances that the user can obtain about
>>>>>>>>> the respect of his choices. This point is currently left
>>>>>>>>> unanswered in draft-hardt-xauth-protocol-13.
>>>>>>>>>
>>>>>>>> This point is equally important: such assurance can only be
>>>>>>>> obtained if the access token returned to the client
>>>>>>>> is not considered to be opaque to the client. This is a necessary
>>>>>>>> condition but not the single condition:
>>>>>>>> the Client must also be in a position to capture/memorize the "User
>>>>>>>> consent and choice" of the user in order to be able
>>>>>>>> to verify it afterwards using the content of the access token(s).
>>>>>>>>
>>>>>>>
>>>>>>> We disagree on this being a requirement for all use cases. It may be
>>>>>>> in some.
>>>>>>>
>>>>>>> OK. Then this means that there will be no sentence in the draft such
>>>>>>> as :
>>>>>>> "access tokens returned to the client are not considered to be
>>>>>>> opaque to the client".
>>>>>>>
>>>>>>
>>>>>> For OAuth use cases, which GNAP supports, the access token is opaque
>>>>>> to the Client. As you have noted, there are use cases where the access
>>>>>> token is NOT opaque.
>>>>>>
>>>>>> [Denis] Wait a second. There is no requirement to support all OAuth
>>>>>> use cases.
>>>>>> I believe that there is a requirement to support OAuth 2.0 ASs, while
>>>>>> the clients may be different
>>>>>> and hence GNAP clients do not need to inherit of the limitations of
>>>>>> OAuth 2.0 clients.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>> If a RO needs to be involved and since a RO is directly associated
>>>>>>>>>> with a RS, why can't it be directly queried
>>>>>>>>>> by the appropriate RS after step (2) or later on ?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Good question. Perhaps you can expand on a use case where that
>>>>>>>>> would be useful?
>>>>>>>>>
>>>>>>>>> Before I expand, would you be able to explain first under which
>>>>>>>>> circumstances a RO needs to be queried by a GS ?
>>>>>>>>> How can the GS identify which RO to query ?
>>>>>>>>>
>>>>>>>> If the User is the RO, then the GS knows who to query.
>>>>>>>>
>>>>>>>> I still have difficulties to understand what you mean here.
>>>>>>>> How could a GS know that "the User is the RO" ?  If "the User is
>>>>>>>> the RO", why does the GS needs to query the User ?
>>>>>>>>
>>>>>>>
>>>>>>> To get consent?
>>>>>>>
>>>>>>> To get a "RO consent" to himself ???
>>>>>>>
>>>>>>
>>>>>> The GS needs consent from the RO. If the RO is the User, then consent
>>>>>> from the RO is equivalent to consent from the User.
>>>>>>
>>>>>> [Denis] See above.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> If the RO is a separate entity, then the GS knows the RO from the
>>>>>>>> RS being queried.
>>>>>>>>
>>>>>>>>  ... and this gives the ability for the GS to log/trace all the RSs
>>>>>>>> accessed by a given User and at which instant of time the access token has
>>>>>>>> been granted.
>>>>>>>>
>>>>>>>> An example is a user would like access to an enterprise asset where
>>>>>>>> a workflow is started to gain approval, and an administrator or manager
>>>>>>>> provides consent.
>>>>>>>>
>>>>>>>> Thanks for this example. I finally understand what you have in
>>>>>>>> mind: you are considering using an access control model to build a *workflow
>>>>>>>> model*.
>>>>>>>> While it may be interesting to define a workflow model, this should
>>>>>>>> be considered as a *separate and different work item*.
>>>>>>>>
>>>>>>>
>>>>>>> The actual workflow is out of scope.
>>>>>>>
>>>>>>> I am glad you agree with this. But this means that your example was
>>>>>>> not appropriate to illustrate your point.
>>>>>>>
>>>>>>
>>>>>> It illustrates a use case where the RO and User are not the same
>>>>>> party, and why the GS needs to query the RO, which was your question if I
>>>>>> understood it correctly.
>>>>>>
>>>>>> [Denis] Since the inputs and the outputs for this "RO consent" phase
>>>>>> are not currently described in the draft, the point is still unsolved.
>>>>>>
>>>>>> As soon as there is a RO consent obtained at the GS, the major
>>>>>>> problem is that the GS is able to act as Big Brother.
>>>>>>> If a RO consent is performed at the RS, then the GS will not know
>>>>>>> who the RS is: it is then unable to act as Big Brother,
>>>>>>> even if it would enjoy to play that role.
>>>>>>>
>>>>>> In an enterprise use case, the GS's knowledge of who is accessing
>>>>>> which RS is a feature.
>>>>>>
>>>>>> Do you mean that it is "normal" in an enterprise that a single point
>>>>>> of control is able to trace all their actions ?
>>>>>> From a security point of view, a single point of failure will have
>>>>>> dramatic consequences.
>>>>>>
>>>>>> In your use cases, it seems that the RO is the User.
>>>>>>
>>>>>> I do hope that you have finally understood that, in my use case, the
>>>>>> RO is **not** the User.
>>>>>>
>>>>>> The GS knows the User is wanting to let a Client access something. If
>>>>>> the access token is generic, and could be presented to any RS that provides
>>>>>> a standardized function,
>>>>>> then the GS does not know which RS is being accessed by a Client for
>>>>>> the User. This seems to meet your privacy objectives. If not, what is wrong?
>>>>>>
>>>>>> For security reasons, an access token needs to be targeted (which
>>>>>> does not necessarily mean that an identifier of the RS shall be included
>>>>>> into the access token).
>>>>>>
>>>>>> if the admin grants access, then the access granted to the client
>>>>>>> changes.
>>>>>>>
>>>>>>>> The model you propose may be suited for an enterprise environment
>>>>>>>> but is not scalable over the Internet.
>>>>>>>>
>>>>>>> It is one of the use cases we are working to address.
>>>>>>>
>>>>>>>> What is needed is an access control model usable over the Internet
>>>>>>>> with millions of RSs and thousands of ASs/GSs.
>>>>>>>>
>>>>>>> I agree the model should also scale to internet scale.
>>>>>>>
>>>>>>> Fine. Another point on which we are in agreement.
>>>>>>>
>>>>>>> The model can scale to the Internet based on the following
>>>>>>> assumptions:
>>>>>>>
>>>>>>> The flow starts with the steps (1) to (4) as illustrated by Francis,
>>>>>>> i.e. the flow starts with a contact with a RS.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *+----+  +------+  +---+  +---+  +---+ |User|  |Client|  |RS |  |GS
>>>>>>> |  |RO | +----+  +------+  +---+  +-+-+  +-+-+   |(1) Service Request     |
>>>>>>>      |   |-------->|       |      |      |   |         |(2) Service Intent
>>>>>>>   |   |         |------>|      |      |   |         |(3) AuthZ Challenge  |
>>>>>>>   |         |<------|      |      |   |         |(4) AuthZ Request    |   |
>>>>>>>         |------------->|      |*
>>>>>>>
>>>>>>> The GS/AS does not need to have any prior relationship with ROs
>>>>>>> and/or RSs.
>>>>>>>
>>>>>>> Furthermore, it is possible to prevent the GS to act as Big Brother
>>>>>>> when the identity of the RS is not disclosed to the GS.
>>>>>>>
>>>>>>
>>>>>> What happens after (4) above?
>>>>>>
>>>>>> [Denis] The key point is that we first need to agree on the first
>>>>>> four exchanges. Do we ?
>>>>>>
>>>>>> The fifth exchange is different whether ACLs or Capabilities are
>>>>>> being used.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Which information is supposed to be presented to the RO ?
>>>>>>>>>> Which information is supposed to be returned by the RO ?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Just like how the user authenticates to an AS, how the AS and RO
>>>>>>>>> communicate is out of scope.
>>>>>>>>>
>>>>>>>>> At the moment, the usefulness of a dialogue between a GS and a RO
>>>>>>>>> has not been explained, nor demonstrated.
>>>>>>>>> The question is about the functionality of that dialogue in terms
>>>>>>>>> of input and output information (and not about
>>>>>>>>> the design of a protocol or of a user interface). Anyway, AFAIU a
>>>>>>>>> dialogue between a GS and a RO is optional.
>>>>>>>>>
>>>>>>>>
>>>>>>>> See enterprise example above.
>>>>>>>>
>>>>>>>> It is not an access control example, but a workflow example.
>>>>>>>>
>>>>>>>> Access  control has been defined a long time ago and the last
>>>>>>>> edition of the model has been confirmed in year 1996: ISO/IEC 10181-3:
>>>>>>>> 1996.
>>>>>>>> "Information technology — Open Systems Interconnection — Security
>>>>>>>> frameworks for open systems: Access control framework — Part 3".
>>>>>>>>
>>>>>>>> Two major functions have ben defined: an Access Control Enforcement Function
>>>>>>>> (AEF) and an Access Control Decision Function(ADF).
>>>>>>>>
>>>>>>>> Access Control Enforcement Function (AEF):
>>>>>>>> A specialized function that is part of the access path between an
>>>>>>>> initiator and a target on each access request and enforces the decision
>>>>>>>> made by the ADF.
>>>>>>>> Access Control Decision Function (ADF) :
>>>>>>>> A specialized function that makes access control decisions by
>>>>>>>> applying access control policy rules to an access request, ADI (of
>>>>>>>> initiators, targets, access requests,
>>>>>>>> or that retained from prior decisions), and the context in which
>>>>>>>> the access request is made.
>>>>>>>>
>>>>>>>> The role of the RO is to define the "access control policy rules"
>>>>>>>> at the RS according to the context in which the access request is
>>>>>>>> made.
>>>>>>>>
>>>>>>> I'm pretty familiar with access control systems. :)
>>>>>>>
>>>>>>> I would say that the access control is happening at the RS. The
>>>>>>> client presents a token when accessing an API.
>>>>>>> The RS uses the token, and any policy required, to make an access
>>>>>>> decision.
>>>>>>>
>>>>>>> Fine. It looks like we are in agreement. Unfortunately, this is not
>>>>>>> the case just below.
>>>>>>>
>>>>>>> Here is flow:
>>>>>>>
>>>>>>> 1) The Client requests access to an RS from the GS.
>>>>>>>
>>>>>>> No. We are no more in agreement. This is different from the flow
>>>>>>> drawn by Francis.
>>>>>>>
>>>>>> My bad. Typo. I meant RO.
>>>>>>
>>>>>>
>>>>>>> 2) The GS queries the RS if access should be granted.
>>>>>>>
>>>>>>>  No. The GS should not be forced to have a flow with the RS.
>>>>>>>
>>>>>> Same mistake as above, I meant RO.
>>>>>>
>>>>>>> 3) If access is granted, the GS creates an access token representing
>>>>>>> the granted access, and returns it to the Client.
>>>>>>>
>>>>>>> This model is by no way conformant to ISO/IEC 10181-3: 1996
>>>>>>>
>>>>>> I'm unclear on why, or why it is even relevant.
>>>>>>
>>>>>>> 4) The Client presents the access token to the RS to show it has
>>>>>>> been granted access.
>>>>>>>
>>>>>>> No. The client presents a token when accessing an API. The RS uses
>>>>>>> the token, and any policy required, to make an access decision.
>>>>>>> The token never contains an information like "Please grant an access
>>>>>>> to the holder of this token".
>>>>>>>
>>>>>> Let me provide more clarity in the sentence:
>>>>>>
>>>>>> The Client presents the access token to the RS, to show the RS that
>>>>>> the Client has been granted access to a resource at the RS by the GS.
>>>>>>
>>>>>> [Denis] This time, please consider both the ACLs approach and the
>>>>>> Capabilities approach.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> A couple advantages of this model:
>>>>>>> - that the RS does not need to know much, if anything about the
>>>>>>> Client.
>>>>>>> - the access token MAY be self contained so that the Client does not
>>>>>>> need to query the GS on each access.
>>>>>>>
>>>>>>> There are so many disadvantages that I will not list them.
>>>>>>>
>>>>>> Darn: I clearly was not firing on all cylinders when I typed this
>>>>>> out. Let me correct:
>>>>>>
>>>>>> - the access token MAY be self contained so that the RS does not need
>>>>>> to query the GS on each access to the RS by the Client.
>>>>>>
>>>>>> [Denis] A few comments in the case of a capability approach:
>>>>>>
>>>>>> - for each GS, the RS needs to locally manage which operation(s)
>>>>>> is/are allowed to it.
>>>>>>
>>>>>> - the GS needs to establish a trusted communication channel or an
>>>>>> authentication mechanism with each RO
>>>>>>    (which is associated with an explicit RS identifier).
>>>>>>
>>>>>> - the GS could play the role of the RO and hence be in a position to
>>>>>> issue any capability for any RS (without a "RO consent").
>>>>>>
>>>>>>    The target of an attack will clearly be the GS.
>>>>>>
>>>>>> I would not say that GNAP is an access control protocol, as how the
>>>>>>> RS uses the token to determine access is out of scope.
>>>>>>>
>>>>>>> This is where we have a major discrepancy: how the RS uses the
>>>>>>> token to determine access is *within* the scope.
>>>>>>>
>>>>>> [Denis] Do you agree or disagree ?
>>>>>>
>>>>>> The RS announces in advance to the client what it needs so that the
>>>>>>> client can perform a a given operation and if the client supplies the
>>>>>>> requested attributes
>>>>>>> obtained from some GS/AS(s) trusted by the RS, then access to that
>>>>>>> RS is granted by the RS. If the RS cannot perform the requested operation
>>>>>>> on its own,
>>>>>>> then the client should be informed about some requested attributes
>>>>>>> that need to be obtained from some GS/AS(s) trusted by the next RS(s) in a
>>>>>>> chain
>>>>>>> for subsequent operations. The User consent should also be obtained
>>>>>>> before performing the chaining operation.
>>>>>>>
>>>>>>> Chaining operations between RSs over the Internet is within the
>>>>>>> scope (... and may be achieved).
>>>>>>>
>>>>>> [Denis] Do you agree or disagree ?
>>>>>>
>>>>>> Denis
>>>>>>
>>>>>>
>>>>>>>>
>>>>>>>>> For many use cases, the User is the RO, and the interaction is
>>>>>>>>> through a user interface, not a machine protocol.
>>>>>>>>>
>>>>>>>>> Wait a second. You wrote "the User is the RO". The User is
>>>>>>>>> attempting to make an access to a RS by using a Client.
>>>>>>>>> *That* User is not the RO of the RS.
>>>>>>>>>
>>>>>>>> The user being the RO is the initial use case for OAuth.
>>>>>>>>
>>>>>>>> OAuth 2.0 is no more mandating such a case.
>>>>>>>>
>>>>>>>
>>>>>>> I don't know what you mean by that.
>>>>>>>
>>>>>>> Copy and paste from draft-ietf-oauth-security-topics:
>>>>>>>
>>>>>>> OAuth initially assumed a static relationship between client,
>>>>>>> authorization server and resource servers.  (...)
>>>>>>> With the increasing adoption of OAuth, this simple model dissolved
>>>>>>> and, in several scenarios, was replaced
>>>>>>> by a dynamic establishment of the relationship between clients on
>>>>>>> one side and the authorization and
>>>>>>> resource servers of a particular deployment on the other side.
>>>>>>>
>>>>>>> This way, the same client could be used to access services of
>>>>>>> different providers (in case of standard APIs,
>>>>>>> such as e-mail or OpenID Connect) or serve as a frontend to a
>>>>>>> particular tenant in a multi-tenancy environment.
>>>>>>>
>>>>>>>
>>>>>> This sentence does not mention the RO or the Client. I'm confused
>>>>>> what we are talking about
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> A client application would like access to the user's photos at a
>>>>>>>> photo sharing site. The resource is the user's photos. The user is the
>>>>>>>> owner of that resource.
>>>>>>>>
>>>>>>>> If the user has already pre established the access control policy
>>>>>>>> rules so that it can access to his own photos
>>>>>>>> then he does not need to grant in real time any additional
>>>>>>>> authorization.
>>>>>>>>
>>>>>>> I don't understand what you are trying to say. The photo sharing
>>>>>>> example was a driving use case for the creation of OAuth.
>>>>>>>
>>>>>>> We would need to revisit the original scenario and consider if it
>>>>>>> can be addressed in a different way than the original way.
>>>>>>>
>>>>>> The use case is the same. Is there a different solution you are
>>>>>> proposing?
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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
>>
>
>