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

Dick Hardt <dick.hardt@gmail.com> Tue, 28 July 2020 17:00 UTC

Return-Path: <dick.hardt@gmail.com>
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 84A313A0E0F for <txauth@ietfa.amsl.com>; Tue, 28 Jul 2020 10:00:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.085
X-Spam-Level:
X-Spam-Status: No, score=-2.085 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 D_IWd10M5TaB for <txauth@ietfa.amsl.com>; Tue, 28 Jul 2020 10:00:32 -0700 (PDT)
Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E48D53A0CF4 for <txauth@ietf.org>; Tue, 28 Jul 2020 10:00:31 -0700 (PDT)
Received: by mail-lj1-x22e.google.com with SMTP id q4so21959676lji.2 for <txauth@ietf.org>; Tue, 28 Jul 2020 10:00:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tgzDYSUzJXfJmfxCEhEGSaAv/26uS2WdTwVsven8tVE=; b=HIbIuf88FQ5nH2F5hakDxuTLkCr+mitgeQNwzQgCzcQsrxJ5aT4u9zkd3n/lSsBjqo ka98/9mt1d35G/Z4fFFbysq2iirNtg7Z55V/h4CbodYmYohr0v1DzjBXGkuyvzVjruDP CNHm+Ea7vl/pqpbV7ykdEMNm3FBxbe9giJrW108NyzuoCu7pHCJJjn1bAkJKnkIp8+C4 HW166Qz+zvsixxwqiYPIUOWIxkSLisfbT7by+k0njGALwDyUfGA2vutLv5mrtFJyTG9L MJR3gs4Ijg/reZqaZQkfRDE2no4ffNDXtzeiLG9Fwu0LqRzPjFEkpZfpEnMEfEGFxLmm oSew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tgzDYSUzJXfJmfxCEhEGSaAv/26uS2WdTwVsven8tVE=; b=oukPAk5wrqiFoG9bN489O/9DCtyOWZrmjt919FmWAEKMeJh0yXVKGWO9Wx9s7nayV9 oc9KztmSjRXceXG19qBPwRA+t2GC6XJjQZ76OgOcGebphn+Qv9g9DeeE8dPUJqDTy/oc xP56gCc+AZtbo0r9yEzzJXLd+J61Ndji/yx7uEobEUwmdo8GGarI8hvfgbXu9VcHY4AV ITScV/Rw03iJdPPlfvjZeMPP0+XVc04b+JV2TfF0i5txs5IAS0kZn314oS4CPYmI3t5l uT/iO41f3cu2qPOdwCeSYUa1XP7Qk8Ar/6d+/PgyfR9I/NZ7QSzWt+OfAj0EU3J4igDm 9u8A==
X-Gm-Message-State: AOAM530D8q57pfkIuTCvTPqkc71KQgQX+RPIiJXaimE1tbfedId7gROV o7PVfRSh7zHrA8EAuWUb9+OhrFsY4GoNyKuYV780JoIk
X-Google-Smtp-Source: ABdhPJwFKi9CReNMORMCKOR6A1+aVo6orb0MNnyYL8xhsSRJBUpU+YPDU+ZjmHKO5Gmu6W+MEtVmnzNYn07lOhUcOhc=
X-Received: by 2002:a2e:999a:: with SMTP id w26mr7900319lji.242.1595955629772; Tue, 28 Jul 2020 10:00:29 -0700 (PDT)
MIME-Version: 1.0
References: <CAOW4vyPqjcWz7njW9cVb6wejY+KaASnskefSpwMqCPs+3WPmfg@mail.gmail.com> <CAD9ie-soUmghr-qxWFRhHkX3rx3qaf3wBqxkwRZ=ZfQaSoDwbw@mail.gmail.com> <df110f7d-7928-4dd2-9c09-4b169860623a@free.fr> <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>
In-Reply-To: <18b6aa1e-49bf-a7bc-c1a6-5f2b77355434@free.fr>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Tue, 28 Jul 2020 09:59:51 -0700
Message-ID: <CAD9ie-upHAL22m3ttYQgSzYov_2wTRNShpEnxDXttTbByWaQdw@mail.gmail.com>
To: Denis <denis.ietf@free.fr>
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="00000000000063d42905ab8360be"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/ET0paZrg95cxUk6bwjWhxfh9AMI>
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:00:40 -0000

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> 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> 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> 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> 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> 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 <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> 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> wrote:
>>>>>>>
>>>>>>>> Hi Dick,
>>>>>>>>
>>>>>>>> On Fri, Jul 17, 2020 at 9:21 AM Denis <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 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
>>>>> Txauth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>>
>>>>
>>>> --
>>>> Txauth mailing list
>>>> Txauth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>
>>> ᐧ
>>>
>>>
>>>
>> --
>> Txauth mailing list
>> Txauth@ietf.org
>> https://www.ietf.org/mailman/listinfo/txauth
>>
>
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>