Subject: [GNAP] Enterprise servers and Internet servers use cases

From: Denis <[email-masked]>
Date: Tue, 18 Aug 2020 12:22:15 +0200

Hello,

I have posted a new use case (unfortunately as usual for me in the wrong 
directory) under the name: *
Enterprise servers and Internet servers use cases*.

It is available from: 
https://github.com/ietf-wg-gnap/general/wiki/Enterprise-servers-and-Internet-servers-use-cases

At the end of this paper, I have summarized the terminology used in this 
paper.

  * User : human person
  * individual client : application that requests access tokens on
    behalf of a User
  * User Agent : User Interface associated with an individual client
    that manages the User Consent and choices
  * enterprise client: application that requests access tokens on behalf
    of the application
  * attribute: characteristic of a User or of an Application
  * capability: pair of elements granted by an AS that indicates which
    method is allowed on which data object
  * Attribute-based Access Control (ABAC): access control scheme based
    on a policy that uses one or more attributes to grant or to deny an
    operation
  * User access token: access token that contains attributes related to
    the User or /and capabilities granted to the User
  * application access token: access token that contains attributes
    related to the application or /and capabilities granted to an
    enterprise client application

Denis

PS. If some one could post a message explaining how to place a use case 
in the right directory, it might be useful for a next time.  :-)

---

From: Fabien Imbault <[email-masked]>
Date: Tue, 18 Aug 2020 12:48:33 +0200

Hi Denis,

If I understand correctly, your use case is about supporting ABAC, which is
nice and should be fairly easy to do. I think you could make the use case
much simpler, however.

The description is currently very misleading. You're using the term
"capability" is a sense that is very different from the context in which it
is used by everyone else (i.e. ocaps litterature). I actually don't really
understand why you want to use that term here. RBAC vs ABAC pros and cons
are already well known (see for instance
https://www.dnsstuff.com/rbac-vs-abac-access-control), and you don't really
need to introduce capabilities into the mix.

Fabien

On Tue, Aug 18, 2020 at 12:22 PM Denis <[email-masked]> wrote:

> directory) under the name:
> * Enterprise servers and Internet servers use cases*.
>
> It is available from:
>    - User : human person
>    - individual client : application that requests access tokens on
>    behalf of a User
>    - User Agent : User Interface associated with an individual client
>    - enterprise client: application that requests access tokens on behalf
>    of the application
>    - attribute: characteristic of a User or of an Application
>    - capability: pair of elements granted by an AS that indicates which
>    - Attribute-based Access Control (ABAC): access control scheme based
>    - User access token: access token that contains attributes related to
>    - application access token: access token that contains attributes
>    related to the application or /and capabilities granted to an enterprise
>    client application
>
> Denis
>
> PS. If some one could post a message explaining how to place a use case in
> the right directory, it might be useful for a next time.  :-)
>
>
>
>
> --
> TXAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth
>

---

From: Denis <[email-masked]>
Date: Tue, 18 Aug 2020 15:52:14 +0200

Hi Fabien,

> Hi Denis,
>
> If I understand correctly, your use case is about supporting ABAC, 
> which is nice and should be fairly easy to do. I think you could make 
> the use case much simpler, however.

The most complex case is being addressed where a RS is trusting more 
than one AS and is willing, using ABAC, to obtain different attributes 
for the same user.
 From there, simplifications exist in the real world.

The most important is that I propose a single model where both 
capabilities and ABAC can be used, at the full discretion of the 
Resource Controller.

> "capability" is a sense that is very different from the context in 
> which it is used by everyone else

I am using the term "capability" since it is fully appropriate. A 
capability is a pair of elements granted by an AS that indicates "which 
method is allowed on which data object".
In another context, I would say "which operation (e.g. read or write) is 
allowed on which data".

> (i.e. ocaps litterature). I actually don't really understand why you 
> want to use that term here.

I am sorry, but I don't know what ocaps means. I used: 
https://acronyms.thefreedictionary.com/OCAPS and I got the following 
results :

    OCAPS    Office of Clinical Administrative and Program Support 
(Illinois)
    OCAPS    Ohio Coalition for Adult Protective Services (Columbus, OH)
    OCAPS    Out of Control Action Plans
    OCAPS    Ottawa Citizens against Pollution by Sewage (Canada)

I do mean capability. Please, take a look at:
https://prosuncsedu.wordpress.com/2014/08/21/comparing-object-centric-access-control-mechanisms-acl-capability-list-attribute-based-access-control/

> RBAC vs ABAC pros and cons are already well known (see for instance 
> https://www.dnsstuff.com/rbac-vs-abac-access-control), and you don't 
> really need
> to introduce capabilities into the mix.

My argumentation has nothing to do about RBAC versus ABAC.

Denis

>
> Fabien
>
> On Tue, Aug 18, 2020 at 12:22 PM Denis <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hello,
>
>     I have posted a new use case (unfortunately as usual for me in the
>     wrong directory) under the name: *
>     At the end of this paper, I have summarized the terminology used
>     in this paper.
>
>       * User : human person
>       * User Agent : User Interface associated with an individual
>         client that manages the User Consent and choices
>       * enterprise client: application that requests access tokens on
>         behalf of the application
>       * capability: pair of elements granted by an AS that indicates
>         which method is allowed on which data object
>       * Attribute-based Access Control (ABAC): access control scheme
>         based on a policy that uses one or more attributes to grant or
>         to deny an operation
>       * User access token: access token that contains attributes
>         related to the User or /and capabilities granted to the User
>       * application access token: access token that contains
>         attributes related to the application or /and capabilities
>         granted to an enterprise client application
>
>     Denis
>
>     PS. If some one could post a message explaining how to place a use
>     case in the right directory, it might be useful for a next time.  :-)
>
>
>
>
>     -- 
>     TXAuth mailing list
>     [email-masked] <mailto:[email-masked]>

---

From: Fabien Imbault <[email-masked]>
Date: Tue, 18 Aug 2020 16:11:00 +0200

Hi Denis,

You may read for instance :
http://habitatchronicles.com/2017/05/what-are-capabilities/
Defined more specifically as ocaps = object capabilities, an alternative to
ACLs.
The canonical example is the valey key for a car.

If your argument is not about RBAC vs ABAC, I haven't understood what
you're looking for. But unless you define it, the term“capabilities” itself
is quite confusing.
What's your main concern?

Fabien

On Tue, Aug 18, 2020 at 3:52 PM Denis <[email-masked]> wrote:

> Hi Fabien,
>
> Hi Denis,
>
> If I understand correctly, your use case is about supporting ABAC, which
> is nice and should be fairly easy to do. I think you could make the use
> case much simpler, however.
>
> The most complex case is being addressed where a RS is trusting more than
> one AS and is willing, using ABAC, to obtain different attributes for the
> same user.
> capabilities and ABAC can be used, at the full discretion of the Resource
> Controller.
>
> is used by everyone else
> (i.e. ocaps litterature). I actually don't really understand why you want
> to use that term here.
>
>>    - enterprise client: application that requests access tokens on