[policy-charter] Authorization API Proposal

Wed Jun 28 17:32:10 UTC 2023

Thanks for sharing this Atul. If you add me to the repository I will open issues there.

One question I had was whether the Search API could also return a policy in a “native” format. I.e. instead of returning the detailed “decisions” array, could it return an array containing policies expressed in a format the PEP already understands?

Cheers

Pieter

From: policy-charter <policy-charter-bounces at lists.openid.net> On Behalf Of Alex Babeanu via policy-charter
Sent: Wednesday, June 28, 2023 5:52 PM
To: Policy Charter Mail List <policy-charter at lists.openid.net>
Cc: Alex Babeanu <alex at 3edges.com>; Erik Gustavson <erik at sgnl.ai>; Marc Jordan <marc at sgnl.ai>; Gert Drapers <gert at aserto.com>
Subject: Re: [policy-charter] Authorization API Proposal

Hi Atul, I'm crafting some feedback on this now, please add me too: GitHub ID = "baboulebou"

Many thanks,

./\.

On Wed, Jun 28, 2023 at 9:50 AM Atul Tulshibagwale via policy-charter <policy-charter at lists.openid.net<mailto:policy-charter at lists.openid.net>> wrote:
Hi Omri,
Thanks for your feedback here. I think GitHub issues are a good way to provide feedback. I'll be happy to add you as a collaborator in the repo (and anyone else who would like to collaborate in updating / editing the draft). Please send me your GitHub ID.

Thanks,
Atul

On Tue, Jun 27, 2023 at 10:47 PM Omri Gazitt <omri at aserto.com<mailto:omri at aserto.com>> 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<mailto: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

--

[Image removed by sender.]<https://sgnl.ai/>

Atul Tulshibagwale

CTO

[Image removed by sender.]<https://linkedin.com/in/tulshi>[Image removed by sender.]<https://twitter.com/zirotrust>[Image removed by sender.]<mailto:atul at sgnl.ai>
--
policy-charter mailing list
policy-charter at lists.openid.net<mailto:policy-charter at lists.openid.net>
https://lists.openid.net/mailman/listinfo/policy-charter
--
policy-charter mailing list
policy-charter at lists.openid.net<mailto:policy-charter at lists.openid.net>
https://lists.openid.net/mailman/listinfo/policy-charter

--
[Image removed by sender. 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/42e178b0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ~WRD0180.jpg
Type: image/jpeg
Size: 823 bytes
Desc: ~WRD0180.jpg
URL: <http://lists.openid.net/pipermail/policy-charter/attachments/20230628/42e178b0/attachment-0001.jpg>