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

Dick Hardt <dick.hardt@gmail.com> Fri, 24 July 2020 17:45 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 4E3053A109A for <txauth@ietfa.amsl.com>; Fri, 24 Jul 2020 10:45:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 m83D0SC3RDF9 for <txauth@ietfa.amsl.com>; Fri, 24 Jul 2020 10:45:38 -0700 (PDT)
Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 8C2633A1099 for <txauth@ietf.org>; Fri, 24 Jul 2020 10:45:37 -0700 (PDT)
Received: by mail-lj1-x231.google.com with SMTP id q7so10828050ljm.1 for <txauth@ietf.org>; Fri, 24 Jul 2020 10:45:37 -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=XjSi3Hve6OmQX0M8rkrhW9Q5XHZ4zzicNGYBvUwB9ko=; b=mzCnKzJcSFmtLQVAMqIuzRDN7AuazUHpQLEkSSAVVJzH8q+t7IY8NexbYlFbh/RlYE ym+lcQbxgIYfxjIcsPheMRW3lVkY/wIBQXVMPmlUZI+/pwHnNu6rKWZ+welfGvq+N1jS jkk/lv9Z5xhccLrkzTwGvUKm6iWoMwxtJFp0JmSajYMy/9lXEXl6X5KlomXpEhvVMSWr KTwv3t9Lg0jWtgg6hjyMfSMezMGFZ/88GT7SshiibkONH4jXyrwR+dUXKVuWNqcfNsKu CVl2G3+IyqAY6RB2EcuTWEoj2HiRtb9Y2GohYE78mFmcSQnt4rlLo68GcvguQhcdRH8g 59Eg==
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=XjSi3Hve6OmQX0M8rkrhW9Q5XHZ4zzicNGYBvUwB9ko=; b=ZHM3d8LqXvNhRQTll8kCv41Iw+zVOBVd/c60cjHDd8w17Bmudi9DREHSHnZ05GN+rp sktZMWHgRyunCpr2Q7hSjirjLiUZxcC4esY5L2XrUXzFcn/BcNGL3bbGO0ujm8aMBHhn h6BTuw0Qw0w6+DnGzGaOjnaKkyQixZrw0GVTyMBnK0J0qNQCrW/djFBPaH9GnRxiax8x lc+zev1u9rju+cSs5ykWHyG1XXbKI/nM2ySv04JXaWRrkfnZwPI4N9MZf5hho5cvUE9S XaDDboY/Ejg/RM7ByzlUwcCTKaXprY2RTHfLXed9glWqBz2Fq+1LlJV20msOqik5RDOe zvdQ==
X-Gm-Message-State: AOAM532Tke5l3943jP97HsrYSeTrKA63k5wQyVEfebBeccFdlxLl3l73 Pf4rEohv4el0nIYFME+N9LrghOJqJ44A8qnJCacUZAIC
X-Google-Smtp-Source: ABdhPJzoXl0eDHNG+nYFER02laiPkrbIRQfWzT50OpsZBJ9yOOktJwse/0s8NiiNIU+zLZmQbN6lWJPi84cd2io670o=
X-Received: by 2002:a2e:9611:: with SMTP id v17mr5061728ljh.110.1595612735439; Fri, 24 Jul 2020 10:45:35 -0700 (PDT)
MIME-Version: 1.0
References: <CAOW4vyPqjcWz7njW9cVb6wejY+KaASnskefSpwMqCPs+3WPmfg@mail.gmail.com> <f00c75a5-f930-81a6-a50e-2eeffedac691@free.fr> <CAOW4vyOHO1We4UpCPJBKYvj22rsFd1EN6fAXw8w6YOYTUDhF=g@mail.gmail.com> <aa1381a2-5b11-f7c7-a547-cddb36732c0b@free.fr> <CAD9ie-t7ZFrODeXy=Xzvsv-6gvUY=KjW0ETf8vJYkW2p=G4boQ@mail.gmail.com> <CAOW4vyN26rnOFb+vsaxgaMzeBOsyeSUBougvjHuhQkHyYhnn2w@mail.gmail.com> <b8a83294-771f-c1d7-0956-d0a50accbbb3@free.fr> <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>
In-Reply-To: <d983678a-4f32-b4ad-ba2b-f7e563819356@free.fr>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Fri, 24 Jul 2020 10:44:58 -0700
Message-ID: <CAD9ie-sbEZ6VVoc80mORnU2bWd1yf4J81GfA2eGtvKThL15jJQ@mail.gmail.com>
To: Denis <denis.ietf@free.fr>
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000004b87f505ab338a85"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/ef3er4NjRGLN1rMvkEc90hLUOWE>
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: Fri, 24 Jul 2020 17:45:44 -0000

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