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

[David Brossard]

Hi Scott,

Thanks for the input. I moved my email to a HackMD document so you (and
others) can add your comments directly there:
https://hackmd.io/@oidf-wg-authzen/pep-pdp-api-design-suggestions

On Tue, Jan 23, 2024 at 10:55 AM Scott Guyer <scott.guyer at capitalone.com>
wrote:

> My thoughts ...
>
> 1.2.1 agreed ... I believe this is how envoy proxy ext-authz filter (
> https://www.envoyproxy.io/docs/envoy/latest/api-v3/service/auth/v3/external_auth.proto#envoy-v3-api-msg-service-auth-v3-checkrequest)
> works.  Though, I can't speak exhaustively on how other PEPs work.  Still
> the right call, IMO.
>
> On 2 ... no opposition.  I have questions from an operational perspective
> how to do "search" anyway.  In my environment, I wouldn't want to burden
> the runtime cluster with what feels like an audit capability.  But that
> likely would go in the patterns discussion.  It's the kind of thing that
> could potentially be serviced by a PAP as well.
>
> 5.2 ... works for me.
>
> Re: 3 and 4 ... not quite following yet.
>
> Best,
> -Scott
>
>
>
>
> On Tue, Jan 23, 2024 at 12:27 AM 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
>>       2. 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
>>    3. Propose a model that is largely attribute-based (where an
>>    attribute is a key-value pair)
>>    4. Propose a model that follows the ALFA
>>    Subject/Action/Resource/Environment or the Cedar
>>    Principal/Action/Resource/Context
>>    5. 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?
>>
>> 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
>>    - 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://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-authzen__;!!FrPt2g6CO4Wadw!ML4h4ehzGsQ3xEXYD5Tv_-tGL7lUYg6oL_4dF8MPfw3FwXlzsleLr5tfe5WMer1zqYmvhpZ-jOZsohjifn2Vi7rLzBXk5FkUga4aVg$
>>
> ------------------------------
>
> The information contained in this e-mail may be confidential and/or
> proprietary to Capital One and/or its affiliates and may only be used
> solely in performance of work or services for Capital One. The information
> transmitted herewith is intended only for use by the individual or entity
> to which it is addressed. If the reader of this message is not the intended
> recipient, you are hereby notified that any review, retransmission,
> dissemination, distribution, copying or other use of, or taking of any
> action in reliance upon this information is strictly prohibited. If you
> have received this communication in error, please contact the sender and
> delete the material from your computer.
>
>
>
>
>

-- 
---
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/20240123/c294dd04/attachment.html>