[Openid-specs-authzen] Boxcarring proposal

Steven Venema steve.venema at gmail.com
Sun Jun 9 20:25:13 UTC 2024


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<mailto: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 removed by sender.] [Image removed by sender.]  [Image removed by sender.]  [Image removed by sender.]
[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<mailto: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<mailto: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 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<mailto: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<mailto: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<mailto: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/e9dcfb06/attachment-0001.html>


More information about the Openid-specs-authzen mailing list