Should we use "Subject" and "Resource" rather than "Principal" and "Asset" ?

[tulshi]

Discussed in #22

^{Originally posted by baboulebou June 28, 2023}
"Subject" and "Resource" have been used in the industry since XACML, should we just stick to those terms?

[tulshi]

I have a minor concern about changing "asset" to "resource": In my mind a "resource" indicates a passive entity such as a database, whereas an "asset" can include active entities such as methods or services. So I have a slight bias toward asset over resource.

I have a similar, if not stronger concern about the word "subject" (over "principal"), in that a subject to me feels like a passive entity and not an initiator of the request.

This might just be due to my not being active in any XACML discussions, but I would like us to choose terms that we all think are best suited going forward and not necessarily be bound by XACML, especially because it is not very popular in the industry today.

[baboulebou]

Interesting, In my own mind, a "subject" is an active actor that needs to be authorized (human or not), and a "Resource" is anything which access needs to be protected, not only DBs: could be IoT devices too for example. So exactly the semantics you have for "principal" and "asset"...

Actually, just had a look at the xacml spec, and even there the meanings of the terms are not constrained to Humans and DBs, Subjects are actors:

"Resource : Data, service or system component"
"Subject: An actor whose attributes may be referenced by a predicate"

Anyway, not really defending xacml here (sorry @davidjbrossard ), but at least these terms provide some continuity and carry the same semantics.

[tulshi]

Happy to go with the proposed change from "Principal" to "Subject" and from "Asset" to "Resource". Let's see if anyone else has any comments on this topic.

[davidjbrossard]

In XACML, as Alex mentioned, we have the concept of categories. They typically map to grammatical functions. XACML also lets you define custom categories (but I've seldom seen anyone do so). The default categories in XACML are subject, resource, action, and environment. They actually have longer urn-style names and subject actually has different kinds (recipient, access, etc...) Lately the team at Axiomatics has been thinking that adding a category is superfluous. OPA doesn't define categories at all. All we really need is just key-value pairs e.g. acme.user.name and acme.action. We also noticed that using namespace-style naming conventions is really helpful.

…

On Wed, Jul 5, 2023 at 11:05 AM Atul Tulshibagwale ***@***.***> wrote: Happy to go with the proposed change from "Principal" to "Subject" and from "Asset" to "Resource". Let's see if anyone else has any comments on this topic. — Reply to this email directly, view it on GitHub <#34 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABPRFP546AOZ432ZBIDUOGDXOWUEZANCNFSM6AAAAAAZXY73WQ> . You are receiving this because you were mentioned.

[davidjbrossard]

Let me clarify my thoughts: I think we should keep things simple. I also think we should start from the existing standards. Let's compare a XACML request to an OPA request to a Cedar request to others (Oso?) and see what they share in common. And this is just to describe the 'attributes' part.

[PieterKas]

The definitions for resource and subject used in XACML that @baboulebou pointed to is consistent with my expectations. My sense is that there is no good reason to break with these terms and it may be better to build on them than try and redefine them, unless we think we will use them in a way that is inconsistent with how they are used in other standards.

Taking a look at OAuth related standards:

1. RFC7519 JSON Web Tokens (JWT) defines that the "sub" claim identifies the principal that is the subject of the JWT (commonly used in OAuth).
2. RFC7523 JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants specifies how to use the sub claim in an access token (to identify the authorized accessor for which the access token is being requested)
3. RFC6749 The OAuth 2.0 Authorization Framework refers to an access-restricted resource as a "protected resource", which has affinity with the resource definition for XACML.

My sense is the use of Resource and Subject would be familiar to folks using OAuth and XACML, so retaining them should help folks consuming this work.

[tulshi]

Thanks all, for your responses. I've created a PR to change the nomenclature. Please review. Pull Request #37

[baboulebou]

Would gladly approve but only SGNL-ai/authzapi-moderators can do that apparently... ./\.

…

On Tue, Jul 11, 2023 at 11:21 AM Atul Tulshibagwale < ***@***.***> wrote: Thanks all, for your responses. I've created a PR to change the nomenclature. Please review. Pull Request #37 <#37> — Reply to this email directly, view it on GitHub <#34 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABCDAWWS7MDQL2IBSFVNKTLXPWKS7ANCNFSM6AAAAAAZXY73WQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- [image: This is Alexandre Babeanu's card. Their email is ***@***.*** Their phone number is +1 604 728 8130.] <https://hihello.me/p/cda689b1-0378-4b9c-88cf-33a9bc8ef0c5>

-- CONFIDENTIALITY NOTICE: This e-mail message, including any attachments hereto, is for the sole use of the intended recipient(s) and may contain confidential and/or proprietary information.

[tulshi]

I've added you as an approver. I'm not sure how to change this setting globally. I'll look into it later. On Tue, Jul 11, 2023 at 11:39 AM Alex Babeanu ***@***.***> wrote:

…

Would gladly approve but only SGNL-ai/authzapi-moderators can do that apparently... ./\. On Tue, Jul 11, 2023 at 11:21 AM Atul Tulshibagwale < ***@***.***> wrote: > Thanks all, for your responses. I've created a PR to change the > nomenclature. Please review. Pull Request #37 > <#37> > > — > Reply to this email directly, view it on GitHub > <#34 (comment)>, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/ABCDAWWS7MDQL2IBSFVNKTLXPWKS7ANCNFSM6AAAAAAZXY73WQ> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> > -- [image: This is Alexandre Babeanu's card. Their email is ***@***.*** Their phone number is +1 604 728 8130.] <https://hihello.me/p/cda689b1-0378-4b9c-88cf-33a9bc8ef0c5> -- CONFIDENTIALITY NOTICE: This e-mail message, including any attachments hereto, is for the sole use of the intended recipient(s) and may contain confidential and/or proprietary information. — Reply to this email directly, view it on GitHub <#34 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB55UGYWKIQU3I5SRT2PKRLXPWMXBANCNFSM6AAAAAAZXY73WQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[scvenema]

Great discussion and (FWIW) I agree with the conclusions. IMO, selecting terminology and applying crisp definitions is critical to this endeavor.

[davidjbrossard]

Would gladly approve but only SGNL-ai/authzapi-moderators can do that apparently... ./.
…

Are you saying we have authorization issues @baboulebou ?