[policy-charter] Authorization API Proposal

[Steve Venema]

Hi Atul,

Can you add me to the repo as a collaborator? github username: "scvenema"

Thanks!
-Steve
--
[image: ForgeRock] <https://www.forgerock.com/> *Steve Venema*
Distinguished Engineer  |  ForgeRock
*t* +1 (425) 825-0855  |  *e* steve.venema at forgerock.com
*web* www.forgerock.com
------------------------------
ForgeRock values your *privacy* <https://www.forgerock.com/your-privacy>.


On Wed, Jun 28, 2023 at 4:35 PM Omri Gazitt via policy-charter <
policy-charter at lists.openid.net> wrote:

> Added my comments to the issues Alex opened (thanks!) and also put in a
> couple of PRs on things that I hope are not controversial.
>
>
> On Wed, Jun 28, 2023 at 2:42 PM Omri Gazitt <omri at aserto.com> wrote:
>
>> ogazitt
>>
>> Thanks!
>>
>> On Wed, Jun 28, 2023 at 9:50 AM Atul Tulshibagwale <atul at sgnl.ai> 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> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/policy-charter/attachments/20230711/901004e3/attachment.html>