[Openid-specs-authzen] Boxcarring proposal
Omri Gazitt
omri at aserto.com
Sun Jun 9 21:36:52 UTC 2024
Steve, thanks for reviewing!
I agree that new PEPs and old PDPs would not interoperate without a
capability negotiation mechanism (like context, or a different endpoint as
you said).
And also that at this stage, we don’t need to worry about that kind of
back-compat, since we haven’t yet a first implementers draft.
<http://www.aserto.com/>
Omri Gazitt | CEO
Aserto <http://www.aserto.com/> Inc. | (425) 765-0079
On Sun, Jun 9, 2024 at 1:25 PM Steven Venema via Openid-specs-authzen <
openid-specs-authzen at lists.openid.net> wrote:
> Hi all,
>
>
>
> The proposal does claim backwards compatibility, but I wonder if there is
> a case where that might not be the case.
>
>
>
> Here is an example; please let me know if I’m getting something wrong here:
>
>
>
> 1. Assume we have a PEP which implements boxcarring but a (legacy?)
> PDP which does not.
> 2. When the PDP receives a boxcarred request with an evaluations
> object, I presume it would ignore that object as an unrecognized key,
> correct?
> 3. The PDP would then interpret any remaining elements (subject,
> context, etc.), as an actual single-valued evaluation request instead
> of defaults for boxcarred request, possibly returning a result which
> doesn’t make sense to the PEP? This would seem to be a break in backward
> compatibility.
>
>
>
> The converse, where the PEP is legacy and the PDP supports boxcarring
> should work just fine though.
>
>
>
> Assuming the above scenario is plausible, it does beg the question of how
> important backward compatibility is at this point in our spec development
> cycle. In the past, we’ve assumed that we MUST maintain backward
> compatibility. If so, then this would perhaps be an argument for the
> alternate endpoint approach we’ve discussed /access/v1/authorizations
> vs. /access/v1/authorization).
>
>
>
> Thoughts?
>
> -Steve
>
> *From: *Openid-specs-authzen <
> openid-specs-authzen-bounces at lists.openid.net> on behalf of Omri Gazitt
> via Openid-specs-authzen <openid-specs-authzen at lists.openid.net>
> *Date: *Wednesday, June 5, 2024 at 22:27
> *To: *AuthZEN Working Group List <openid-specs-authzen at lists.openid.net>
> *Cc: *Omri Gazitt <omri at aserto.com>
> *Subject: *Re: [Openid-specs-authzen] Boxcarring proposal
>
> Thanks Andy, Alex & Granville!
>
>
>
> I agree with the feedback to use a keyed object instead of an array. I
> made those changes in the hackmd file
> <https://hackmd.io/ri7odOQkQ6yztBQGlXnnKg?both>. I also added a brief
> section on errors.
>
>
>
> Please feel free to add comments to the hackmd file, or send them on the
> mailing list.
>
>
>
> We can discuss the proposal at our next meeting on Tuesday.
>
>
>
> Thanks,
>
> Omri.
>
>
>
>
>
> On Mon, Jun 3, 2024 at 5:48 AM Granville Schmidt via Openid-specs-authzen
> <openid-specs-authzen at lists.openid.net> wrote:
>
> Thank you for writing this first proposal, Omri!
>
>
>
> I agree with Alex on having the batched response keyed off an identifier.
> I also have some additional thoughts to share and get feedback on.
>
>
>
> Is it the team's preference to have comments added directly to the HackMD
> document or continue via email?
>
>
>
> Cheers,
>
>
> *Granville Schmidt*
>
> CISSP, CCSP, CSSLP, HCISPP, CIPT, GCPCA
>
> https://www.linkedin.com/in/granvilleschmidt/
> +1-740-701-3514
>
>
>
> [image: Image removed by sender.] [image: Image removed by sender.] [image:
> Image removed by sender.] [image: Image removed by sender.]
>
> [image: Image removed by sender. Certified Information Privacy
> Technologist (CIPT) | Intellectual Point]
>
>
>
>
>
> On Mon, Jun 3, 2024 at 3:38 AM Alex Olivier via Openid-specs-authzen <
> openid-specs-authzen at lists.openid.net> wrote:
>
> This is looking good to me.
>
>
>
> The one area I have run into with the type-array response approach is
> around ordering. I am assuming that the response array is required to be
> the same length and order as the input values. This is implicitly putting
> the responsibility of the PDP to fit that contract and so would be called
> out in the spec explicitly.
>
>
>
> From my own experience, having this batch response being keyed off
> some identifier (resource ID/action?) passed in the input makes it
> easier to handle on the client side as you can just 'pluck' the value from
> the response rather than have to iterate through the array to find the
> matching entity (though the SDK layer can do this).
>
>
>
>
>
>
>
> On Sat, 1 Jun 2024 at 02:21, Omri Gazitt via Openid-specs-authzen <
> openid-specs-authzen at lists.openid.net> wrote:
>
> Hi folks!
>
>
>
> I had a chance to write up the boxcarring proposal that we batted around
> during Identiverse. It's in HackMD
> <https://hackmd.io/ri7odOQkQ6yztBQGlXnnKg>. Comments welcome!
>
>
>
> The proposal is meant to be backwards-compatible with the current
> single-decision evaluation API, but could also be bound to the
> /access/v1/evaluations (note plural) endpoint.
>
>
>
> Thanks,
>
> Omri.
>
>
>
> --
>
> [image: Image removed by sender.] <http://www.aserto.com/>
>
> *Omri Gazitt* *| *CEO
>
> Aserto <http://www.aserto.com/> Inc. *| *(425) 765-0079
>
> --
> Openid-specs-authzen mailing list
> Openid-specs-authzen at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-authzen
>
> --
> Openid-specs-authzen mailing list
> Openid-specs-authzen at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-authzen
>
> --
> Openid-specs-authzen mailing list
> Openid-specs-authzen at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-authzen
>
> --
> Openid-specs-authzen mailing list
> Openid-specs-authzen at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-authzen
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-authzen/attachments/20240609/9103722c/attachment-0001.html>
More information about the Openid-specs-authzen
mailing list