[Openid-specs-authzen] Boxcarring proposal

Alex Olivier alex at cerbos.dev
Mon Jun 3 09:38:37 UTC 2024


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.
>
> --
>
> <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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-authzen/attachments/20240603/16da7f7c/attachment.html>


More information about the Openid-specs-authzen mailing list