[policy-charter] Authorization API Proposal

Wed Jun 28 18:39:47 UTC 2023

You can also use the "discussion" feature if you just want to discuss
something, and not call it an issue (yet)

On Wed, Jun 28, 2023 at 11:39 AM Atul Tulshibagwale <atul at sgnl.ai> wrote:

> Hi Alex,
> When you select a line in the file, three dots (ellipses) appear in a
> column to the left of the line numbers. If you click there, you see a
> "Reference this line in a new issue". You can use that to reference code in
> a new issue you create, or you can just create a new issue by going to the
> "issues" tab.
>
> Atul
>
> On Wed, Jun 28, 2023 at 11:33 AM Alex Babeanu <alex at 3edges.com> wrote:
>
>> So Atul, what's the process there?All comments become "Issues" in
>> BitBucket?
>> Or create branches with suggested edits?
>> Or... ?
>>
>> Cheers,
>>
>> ./\.
>>
>> On Wed, Jun 28, 2023 at 11:19 AM Atul Tulshibagwale <atul at sgnl.ai> wrote:
>>
>>> Thanks all for your feedback and willingness to contribute. I've added
>>> Gert, Alex and Pieter as collaborators (based on the requests so far).
>>>
>>> On Wed, Jun 28, 2023 at 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/fd680ba0/attachment-0001.html>