[policy-charter] Authorization API Proposal

[Atul Tulshibagwale]

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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/policy-charter/attachments/20230628/3d91d3bb/attachment.html>