[Openid-specs-authzen] The PEP-PDP API

[David Brossard]

Hi Omri,

Thanks for the feedback and thanks for the additional feedback on the call.
I think we are on the same page.


   1. Regarding binding, yes we definitely need one but I just want to make
   sure we keep message format/schema cleanly separate from transport so
   anyone can plug in their favorite transport layer. For the interop, we
   definitely need HTTP as a basic binding.
   2. the request format: I think key-value pairs in a loosely structured
   way (based on SARE or PARC) is good enough. You can send in your ID that
   makes sense in the Zanzibar way. I don't think it precludes non-ABAC
   models. Thoughts?
   3. On the topic of arrays... I have a little story to tell. When I wrote
   the first version of the XACML/JSON spec, I decided to allow a Subject
   field to either be an object (of type category) or an array. That led to
   really weird SDKs that had to test whether the field was an array or not.
   For the first interop, we can make it an object but quickly after, I'd
   recommend we make it an array and that would be the first official version
   of the AuthZEN standard. If we do that, we're giving us an easy way to
   achieve batch


Thanks,
David

On Tue, Jan 23, 2024 at 11:18 AM Omri Gazitt <omri at aserto.com> wrote:

> David, thanks for writing this all down!
>
> On Mon, Jan 22, 2024 at 9:25 PM David Brossard via Openid-specs-authzen <
> openid-specs-authzen at lists.openid.net> wrote:
>
>> Dear all,
>>
>> Last week, it became apparent we need to start simple and low for the
>> PEP-PDP API if we want to ship anything out and I'd like to propose a few
>> principles:
>>
>>    1. Keep transport and message separate
>>       1. The spec for what a request/response should look like should be
>>       decoupled from the underlying transport (HTTP or anything else)
>>       2. As a result, nothing in the transport layer conveys any authZ
>>       meaning whatsoever
>>          1. For instance, 401/403 are indications you cannot use the
>>          authorization service. They don't convey anything about the request you
>>          sent or what the PDP (in the broad sense) would have said
>>
>> For practical interop, I do think we need an HTTP (REST) binding.
>
>>
>>    1. Propose a first iteration of request/response that focuses
>>    exclusively on the easy "binary" yes/no use case
>>       1. No additional statements/obligations/advice
>>       2. No batch
>>       3. No search
>>
>>
> +100.  That was definitely where I landed after last week's conversations.
> We can layer other things once we've declared success on the simple cast.
>
>>
>>    1. Propose a model that is largely attribute-based (where an
>>    attribute is a key-value pair)
>>
>> I would like to see this be generalized - otherwise you'll preclude all
> non-attribute-based systems, which seems like a big miss.
>
> Specifically, the minimum amount of information that is needed to define a
> subject is a type and ID. Likewise an object/resource. Likewise an action.
>
>>
>>    1. Propose a model that follows the ALFA
>>    Subject/Action/Resource/Environment or the Cedar
>>    Principal/Action/Resource/Context
>>
>> Terminology is important but the most important thing is to be consistent
> throughout.
>
>>
>>    1. Publish the results using a standardized schema
>>       1. In the WS-* days of yore, it would have been WSDL
>>       2. For us, would OpenAPI be good enough?
>>
>> OpenAPI is perfect. But it DOES imply that you need to specify an HTTP
> binding (and specifically, HTTP status codes).
>
>
>> So with that being said, should we have a request that looks like the
>> following:
>>
>>    - Made up of 4 objects of the same type (e.g. Category to use ALFA
>>    parlance):
>>       - Subject, Action, Resource, Context
>>       - If these objects are arrays of the said type, then we are paving
>>       the way for batch requests
>>
>> I thought we were eliminating arrays from the simple case?
>
>>
>>    - Each of these objects contains an array of attributes e.g.
>>    key-value pairs
>>       - The attributes could be primitive types e.g. string, double,
>>       boolean
>>       - The attributes could be complex e.g. a JSON payload
>>
>> The response should simply be the decision itself:
>>
>>    - Permit/Deny
>>       - Again, if we want to plan ahead and think of batch requests then
>>       the response should be an array rather than an object.
>>    - Optionally the list of identifiers of things (policies) used in the
>>    decision-making process
>>
>> Thoughts?
>> --
>> Openid-specs-authzen mailing list
>> Openid-specs-authzen at lists.openid.net
>> https://lists.openid.net/mailman/listinfo/openid-specs-authzen
>>
>

-- 
---
David Brossard
http://www.linkedin.com/in/davidbrossard
http://twitter.com/davidjbrossard
http://about.me/brossard
---
Stay safe on the Internet: IC3 Prevention Tips
<https://www.capefearnetworks.com/wp-content/uploads/2017/05/Internet-Fraud-Prevention-Tips-IC3.pdf>
Prenez vos précautions sur Internet:
http://www.securite-informatique.gouv.fr/gp_rubrique34.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-authzen/attachments/20240124/9ca111b6/attachment.html>