[policy-charter] Authorization API Proposal

Wed Jun 28 20:54:38 UTC 2023

Looks like we agree on some of this stuff... So anyway I've started 8
discussions in Atul's repo, should we continue the convo there?

Re: " I did not see hasFriend as an action but as an attribute of the
user." - different world views :-D. In my world, relationships are primary
citizens, and "Has_Friend" is definitively one.
Which is why we should remain at a (high enough)  level that makes sense
for all of us here...

./\.

On Wed, Jun 28, 2023 at 11:40 AM David Brossard <david.brossard at gmail.com>
wrote:

> Please add me to the repository as well: davidjbrossard
>
> Good feedback overall. I would argue that everything can be described in
> terms of attributes. Historically, in XACML an attribute has a type,
> identifier, category, and optionally issuer. For instance, userRole of type
> string and category subject.
>
> In retrospect, we realize that specifying the category is overkill.
> Oftentimes the identifier will convey the grammatical meaning of the
> attribute therefore nulling the need for a category.
>
> Also the original core spec allows for something like 15 plus datatypes
> including URI email and so on. In reality most deployments use string,
> boolean, number, and date/time. The rest is too much.
>
> I would steer away from terms like principal. In my mind it makes the spec
> harder to understand because we do not all agree on what principal is. This
> maps nicely to XACML categories.
>
> Alex, I did not see hasFriend as an action but an attribute of the user.
>
> Regarding API authentication, I think it is totally orthogonal to this
> spec. If the customer wants to allow anonymous access, let them be. If they
> want to use OAuth, so be it...
>
> More to come
>
> On Wed, Jun 28, 2023, 10:51 AM Alex Babeanu via policy-charter <
> policy-charter at lists.openid.net> wrote:
>
>> Thanks for sharing this Atul,
>>
>> Some additional comments:
>>
>> > Re: Oauth2, I agree with Omri: I think this spec should just state that
>> authentication is required, but out of scope of the doc. We could suggest
>> Oauth2 that being said...
>>
>> > I would also prefer to stick to "Subject" and "Resource"
>>
>> 3.5 - Principals ("Subjects")
>> > An ID should indeed suffice. Now it's probably a good idea to also
>> *optionally* add some Subject claims here that the PDP can use (thinking
>> JWT claims coming into the PEP, or environmental values for example). But
>> in that case it should not be just "IP" and "DeviceID", but rather an array
>> of "key"="Value" claim pairs, which may be completely custom and
>> use-case-specific.
>>
>> > It would be good to also have a Subject Type - make it optional if not
>> needed (but we would need it for example).
>>
>> 3.6 - Assets
>> > ID should be mandatory I think.
>>
>> 3.7 - Actions
>> --> Omri, if "Action" is enough to represent relationships in your world,
>> it isn't in mine. Just think of "HAS_FRIEND" relationships for example...
>> Anyway, there's probably no point in adding any graph-modelling to this
>> doc...
>>
>> 3.12.2 - Evaluation response
>> > I don't think we need an `exp` value: we can't "predict" how long an
>> access rule would be true for: that's a business decision! Besides, in the
>> spirit of Zero Trust, a decision is just made at 1 point in time, the next
>> access request may yield a completely different response. Up to the PDP to
>> do caching or whatever to speed-up processing.
>>
>> > I don't think it's a good idea to reply with all language strings, this
>> could be a huge response and it would probably slow-down the PDP too.
>> Instead, have the client PEP request the language it wants its responses
>> in, and just return that 1 reason string.
>>
>> 3.13 - Search API
>> > We also need the reverse query, i.e., who can access this given
>> Resource ?
>> > Again, I don't think we need `exp` here.
>>
>> Regards,
>>
>> ./\.
>>
>> On Tue, Jun 27, 2023 at 10:48 PM Omri Gazitt via policy-charter <
>> policy-charter at lists.openid.net> wrote:
>>
>>> Thanks Atul - it's clear you and the SGNL team put some thought into
>>> this.
>>>
>>> I'm still looking through this but I like that you're specifying both a
>>> "check" function (Access Evaluation) and an "expand" function (Search
>>> API).  Both are important, but perhaps only the Access Evaluation API ought
>>> to be required.
>>>
>>> I'm not sure what is the best way to provide feedback. Github issues?
>>> PRs? put it in a google doc and use comments?
>>>
>>> Here are some thoughts (sorry, no particular order):
>>>
>>> > Policy Distribution Point
>>> Nit - this should be "Policy Decision Point" (which you name correctly
>>> in other places in the doc)
>>>
>>> > The Authorization API is itself authorized using OAuth 2.0 ([RFC6749
>>> <https://sgnl-ai.github.io/authzapi/#RFC6749>])
>>> I think this is overspecified. I can certainly see clients that call an
>>> Authorization API using an API key.
>>>
>>> > Terminology
>>> A bit of a quibble, but perhaps we tip the hat to XACML and use the
>>> terms "subject" and "resource" instead of "principal" and "asset". I'm not
>>> religious about these terms, but "asset" in particular seems less common
>>> than "object" or "resource".
>>>
>>> > Principals
>>> In many systems, subjects will be extracted from a JWT "sub" claim,
>>> which is a string. I'm not sure that specifying that this must be a JSON
>>> structure, and further specifying two optional fields (ipAddress and
>>> deviceId) is necessary, and feels overspecified.
>>>
>>> > Assets
>>> Having a type and id makes sense, but could these be specified in a
>>> single string?  For example, zanzibar defines these as type:id
>>>
>>> I do like having the ability to pass in properties in addition to the
>>> object identifier - but it seems like this should be a json object
>>> (key:value pairs), not just an array of attribute names.
>>>
>>> > Actions
>>> It's not clear to me that separating actions into "standard" and
>>> "custom" is useful. I think the types of actions you list (CRUD) are common
>>> examples but should not be normative.
>>>
>>> I do think it's possible to use the generic concept of "Action" to
>>> encompass permissions and relations.
>>>
>>> > Queries (as array)
>>> I think that allowing a set of decisions to be requested at once is
>>> valuable, but IMO the spec should not mandate that implementations must
>>> support more than one query at a time. Some PDPs don't support that
>>> semantic and it should be considered optional.
>>>
>>>
>>>
>>>
>>> On Tue, Jun 27, 2023 at 4:38 PM Atul Tulshibagwale via policy-charter <
>>> policy-charter at lists.openid.net> wrote:
>>>
>>>> Hi all,
>>>>
>>>> Here's a proposal of an Authorization API that we would like to
>>>> contribute to this group (in its current form or if / when we find a home
>>>> in a standards body). This is similar to at least a few vendors' current
>>>> offerings, so I hope everyone finds this helpful, and we can accelerate our
>>>> standardization efforts as a result.
>>>>
>>>> You can read the proposal in HTML format here:
>>>> https://sgnl-ai.github.io/authzapi/
>>>>
>>>> The sources (under the MIT License) are here:
>>>> https://github.com/SGNL-ai/authzapi
>>>>
>>>> - Atul Tulshibagwale, Erik Gustavson and Marc Jordan
>>>>
>>>> --
>>>>
>>>> <https://sgnl.ai>
>>>>
>>>> Atul Tulshibagwale
>>>>
>>>> CTO
>>>>
>>>> <https://linkedin.com/in/tulshi> <https://twitter.com/zirotrust>
>>>> <atul at sgnl.ai>
>>>> --
>>>> policy-charter mailing list
>>>> policy-charter at lists.openid.net
>>>> https://lists.openid.net/mailman/listinfo/policy-charter
>>>>
>>> --
>>> policy-charter mailing list
>>> policy-charter at lists.openid.net
>>> https://lists.openid.net/mailman/listinfo/policy-charter
>>>
>>
>>
>> --
>> [image: This is Alexandre Babeanu's card. Their email is alex at 3edges.com.
>> 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.
>> --
>> policy-charter mailing list
>> policy-charter at lists.openid.net
>> https://lists.openid.net/mailman/listinfo/policy-charter
>>
>

-- 
[image: This is Alexandre Babeanu's card. Their email is alex at 3edges.com.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/policy-charter/attachments/20230628/f1e5bdb4/attachment-0001.html>