[Openid-specs-authzen] Boxcarring proposal

Alex Babeanu alex at 3edges.com
Thu Jun 13 15:32:32 UTC 2024


Hello there,

just a couple of comments.
- As Steve suggest, should this boxcarring API be available at a different
endpoint ( /access/v1/authorizations )? The draft doesn't mention the
endpoint...
- Error processing would need a bit more detail I think. E.g.,

   -  Are we going to standardize on error messages ? I.e., do HTTP status
   codes make sense here?  Or should these be left to be up to the
   implementations ?
   - Could "boxcarred" evaluations be treated as a transaction (i.e., fail
   the whole on any failure or keep processing)? In which case  1 single
   response may be sufficient (grant/deny the whole thing).

Still struggling with the necessity of this btw, others might too... It
would be good to maybe illustrate this with a use case in the intro maybe?
Looks good otherwise.

Cheers,

./\.

On Tue, Jun 11, 2024 at 12:12 PM Omri Gazitt via Openid-specs-authzen <
openid-specs-authzen at lists.openid.net> wrote:

> Hi Roland,
>
> The intent of the drafted proposal is to have the "evaluations" key, if
> present, supersede the main request.
>
> Any keys in the main request that are specified are treated as default
> values for the requests in the "evaluations" key.
>
> The values in each of the "evaluations" requests supersede any of these
> default values.
>
> In the example you mentioned, the context for eval-1 would be
> *      "context": {*
>
> *	"time": "2024-06-01"
>       },*
>
> If none of the other requests (eval-2, eval-3, etc) provided a context,
> then they would default to
>
> *"context":{
>     "time": "2024-05-31"
>   }*,
>
>
> I hope this clarifies!
> Omri.
>
> On Tue, Jun 11, 2024 at 11:59 AM Roland Baum via Openid-specs-authzen <
> openid-specs-authzen at lists.openid.net> wrote:
>
>> Hey here,
>>
>> thanks for creating an initial draft for discussion!
>>
>> From how I understand the current scheme, the carried requests in
>> "evaluations" can be mixed with the main request.
>>
>> so the following request could be legal, or ?
>>
>> {
>>   "subject": {
>> 		...
>>   },*  "context":{
>>     "time": "2024-05-31"
>>   }*,
>>   "action": {
>> 		...
>>   },
>>   "evaluations": {
>>     "eval-1": {
>>       "resource": {
>>       },*      "context": {
>> 	"time": "2024-06-01"
>>       },*
>>     },
>> 	....
>>     }
>>   ]
>> }
>>
>> The different context elements can contradict each other, which should be
>> avoided?
>>
>> Similar case with other combinations, where parts of the tuple are part
>> of the main request an others are only present in evaluations.
>>
>> I've the guts feeling that this could make implementations rather
>> complex, since all the combinations need to be considered and canonized
>> into [subject+action+resource] tuples for processing.
>>
>> how about just reusing the same scheme as in the current request in the
>> "evaluations" element?
>>
>> So if a request should carry 1+n questions, the 1st goes into the main
>> tuple, the others into "evaluations" and contain a full
>> subject-action-resource(-context) tuple ? 🤷‍
>>
>>
>> hope this makes sense
>>
>>
>> Roland Baum
>> umbrella.associates GmbH
>> Dipl.Kfm.(FH), Dipl.Wirt.-Inf.(FH), CISA, CISSP, CIDPRO
>>
>> Am 09.06.24 um 23:36 schrieb Omri Gazitt via Openid-specs-authzen:
>>
>> 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/authorization
>>> s  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
>>>
>>
>> --
>> 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
>


-- 
[image: This is Alexandre Babeanu's card. Their email is alex at 3edges.com.
Their phone number is +1 604 728 8130.]
<https://hihello.me/p/cda689b1-0378-4b9c-88cf-33a9bc8ef0c5>

-- 
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments 
hereto, is for the sole use of the intended recipient(s) and may contain 
confidential and/or proprietary information.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-authzen/attachments/20240613/c51c6b23/attachment-0001.html>


More information about the Openid-specs-authzen mailing list