Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11
Denis <denis.ietf@free.fr> Tue, 28 July 2020 17:09 UTC
Return-Path: <denis.ietf@free.fr>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5753A0AA2 for <txauth@ietfa.amsl.com>; Tue, 28 Jul 2020 10:09:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.618
X-Spam-Level:
X-Spam-Status: No, score=-1.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.267, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULX-58CNJH9R for <txauth@ietfa.amsl.com>; Tue, 28 Jul 2020 10:09:15 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp04.smtpout.orange.fr [80.12.242.126]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25A733A0EC9 for <txauth@ietf.org>; Tue, 28 Jul 2020 10:09:13 -0700 (PDT)
Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d51 with ME id 8h9A2300H2bcEcA03h9AZ1; Tue, 28 Jul 2020 19:09:12 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Tue, 28 Jul 2020 19:09:12 +0200
X-ME-IP: 90.79.51.120
To: Dick Hardt <dick.hardt@gmail.com>
Cc: txauth@ietf.org
References: <CAOW4vyPqjcWz7njW9cVb6wejY+KaASnskefSpwMqCPs+3WPmfg@mail.gmail.com> <CAD9ie-tLpufcTACXxzCER7t=eebnPhNN9VGbyuRgQOHzQ8=Ctg@mail.gmail.com> <37645bac-6769-a4dd-9e4f-d3f1afdb7a4e@free.fr> <CAD9ie-uXgLrkvEJ5txkR2Un9NJ-yfYy0AhE9gZaKvAF8qjqWFw@mail.gmail.com> <60671fa0-7f41-0ba2-4f44-f9db7004b7d3@free.fr> <CAD9ie-uL_rm73imCe5kMZWd_HvZPQcC_zx3HphHeNXK5JqxNwg@mail.gmail.com> <c35d8330-780c-231c-2d03-afcc4a671187@free.fr> <CAD9ie-t1YD+Dx5ssgUoJrGk-PRQF2aiF3Eqgi7Hi0Cm+sOb31Q@mail.gmail.com> <d983678a-4f32-b4ad-ba2b-f7e563819356@free.fr> <CAD9ie-sbEZ6VVoc80mORnU2bWd1yf4J81GfA2eGtvKThL15jJQ@mail.gmail.com> <f4574da3-befd-06e2-c2fa-37c150cfb420@free.fr> <CAD9ie-sKWLSnvRsrHDj6g7AKgdjWUcjC0WWe1M2QYBXnckyCcw@mail.gmail.com> <7b313658-f7f1-dad1-33aa-7d2107436856@free.fr> <CAD9ie-uri1Zc+ONL9B0WJwQSG8JUQezJ4AvVTWZ3F=J--qVvAA@mail.gmail.com> <18b6aa1e-49bf-a7bc-c1a6-5f2b77355434@free.fr> <CAD9ie-upHAL22m3ttYQgSzYov_2wTRNShpEnxDXttTbByWaQdw@mail.gmail.com>
From: Denis <denis.ietf@free.fr>
Message-ID: <bdb35d55-93a7-6432-040e-d9f5c8e0e6d2@free.fr>
Date: Tue, 28 Jul 2020 19:09:08 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <CAD9ie-upHAL22m3ttYQgSzYov_2wTRNShpEnxDXttTbByWaQdw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------CB29C92AB4BBAAEE02AA5F36"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/zzo3NgOWSEF7nuUydSfyPp0RubU>
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jul 2020 17:09:21 -0000
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 <denis.ietf@free.fr > <mailto:denis.ietf@free.fr>> 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 <denis.ietf@free.fr >> <mailto:denis.ietf@free.fr>> 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 <denis.ietf@free.fr >>> <mailto:denis.ietf@free.fr>> 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 >>>> <denis.ietf@free.fr <mailto:denis.ietf@free.fr>> 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 >>>>> <denis.ietf@free.fr <mailto:denis.ietf@free.fr>> >>>>> 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 >>>>> AccessControl 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 >>>>>> <denis.ietf@free.fr >>>>>> <mailto:denis.ietf@free.fr>> 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 >>>>>>> <denis.ietf@free.fr >>>>>>> <mailto:denis.ietf@free.fr>> 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 <denis.ietf@free.fr >>>>>>>> <mailto:denis.ietf@free.fr>> wrote: >>>>>>>> >>>>>>>> Hi Dick, >>>>>>>> >>>>>>>>> On Fri, Jul 17, 2020 at 9:21 >>>>>>>>> AM Denis <denis.ietf@free.fr >>>>>>>>> <mailto:denis.ietf@free.fr>> >>>>>>>>> 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 AccessControl >>>>>>> Enforcement Function (AEF) and an >>>>>>> AccessControl Decision Function(ADF). >>>>>>> >>>>>>> AccessControl 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. >>>>>>> >>>>>>> AccessControl 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 thecontext 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 >>>>> Txauth@ietf.org <mailto:Txauth@ietf.org> >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>> >>>> -- >>>> Txauth mailing list >>>> Txauth@ietf.org <mailto:Txauth@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>>> ᐧ >>> >>> >> >> -- >> Txauth mailing list >> Txauth@ietf.org <mailto:Txauth@ietf.org> >> https://www.ietf.org/mailman/listinfo/txauth >> > > -- > Txauth mailing list > Txauth@ietf.org <mailto:Txauth@ietf.org> > https://www.ietf.org/mailman/listinfo/txauth >
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Dick Hardt
- [Txauth] Reviewing draft-hardt-xauth-protocol-11 Francis Pouatcha
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Dick Hardt
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Tom Jones
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Francis Pouatcha
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Dick Hardt
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Francis Pouatcha
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Fabien Imbault
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Francis Pouatcha
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Denis
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Francis Pouatcha
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Denis
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Dick Hardt
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Francis Pouatcha
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Denis
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Denis
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Francis Pouatcha
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Denis
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Tom Jones
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Francis Pouatcha
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Francis Pouatcha
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Dick Hardt
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Tom Jones
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Denis
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Denis
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Dick Hardt
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Denis
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Dick Hardt
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Denis
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Fabien Imbault
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Dick Hardt
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Denis
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Dick Hardt
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Denis
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Dick Hardt
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Denis
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Dick Hardt
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Denis
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Dick Hardt
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Denis
- Re: [Txauth] Reviewing draft-hardt-xauth-protocol… Dick Hardt