[Openid-specs-authzen] Boxcarring proposal

Alex Babeanu alex at 3edges.com
Thu Jun 13 21:12:23 UTC 2024


Ah, yes sorry forgot to add...

Another consideration that we see in GraphQL and that applies here also: we
must introduce some kind of limit to the number of boxcarred requests... If
not as explicitly standardized, then at the very least as a security
note/paragraph to mitigate the risks of DoS attacks... What's the max # of
boxcarred requests we should allow?

(in GraphQL you have to do Query Cost analysis and more for instance).

Cheers,
./\.

On Thu, Jun 13, 2024 at 2:08 PM Alex Babeanu <alex at 3edges.com> wrote:

> Thanks Omri,
>
> For the "All vs Any semantics", which sounds complicated, would it be
> better stated this way (below)?
>
> - Add a "Stop on Error" flag (default 'false')
> - Add a "Stop on Deny" flag (default to 'false')
> to the top (default) headers.
>
> The idea is really to save on processing time if not necessary (to the
> discretion of the caller).
>
> E.g.,
> "evaluations": {
>   "stopOnError": true,
>   "stopOnDeny": false,
>   "subject" :{
>        ...
>    },
>   "eval-1": {
>       ...
>    }
>  }
>
> Thoughts?
>
> ./\.
>
>
>
> On Thu, Jun 13, 2024 at 1:50 PM Omri Gazitt via Openid-specs-authzen <
> openid-specs-authzen at lists.openid.net> wrote:
>
>> Thanks Alex and Eve!
>>
>>    - */access/v1/evaluation vs /access/v1/evaluations:* I am certainly
>>    fine with adding an endpoint (which is what our intent was back in April).
>>    In fact, the current draft of the spec has the single and multi-request
>>    evaluations API on two different endpoints.  But the proposal was written
>>    to be "reasonably" backwards-compatible with what we had before. That is
>>    not a big consideration at the moment since we are just about to create our
>>    first Implementer's Draft.
>>    - *Standardizing error messages*: the proposal doesn't go into
>>    details on the codes, because it isn't meant to be "dropped" into the spec
>>    - it just outlines the shape of what the multi-request API looks like, to
>>    get to consensus, before being incorporated. With that said, the HTTPS
>>    binding does detail some of this in the main spec. It's pretty sparse at
>>    the moment (400, 401, 403, 500 are detailed), and we may want to get more
>>    specific beyond that. But I think that's out of the scope of this proposal.
>>    - *All vs Any semantics*: each evaluation is independent, so each
>>    requires a separate decision value.
>>    - *Scenarios*: Atul, Alex O, Chris H, and David B all mentioned UI
>>    state evaluations being a primary scenario. All of their products support
>>    multi-request evaluations today. I didn't write a detailed use-case because
>>    there seemed to be alot of passion to get this into the spec :)
>>
>>
>> On Thu, Jun 13, 2024 at 8:44 AM eve--- via Openid-specs-authzen <
>> openid-specs-authzen at lists.openid.net> wrote:
>>
>>> Good point about “all” vs. “any” semantics. That could open up a can of
>>> worms around organizing and ordering the individual items / their responses
>>> (all of these OR any of those, UNLESS this one over here returns foo...).
>>> It would be good to strongly motivate any options in this direction with
>>> real-life use cases.
>>>
>>> Eve Maler | cell and Signal +1 (425) 345-6756 <+1-425-345-6756>
>>> Visit the Venn Factory <http://vennfactory.com/>
>>> Request a 15-minute consultation <https://fantastical.app/eve/15>
>>>
>>> On Jun 13, 2024, at 10:32 AM, Alex Babeanu via Openid-specs-authzen <
>>> openid-specs-authzen at lists.openid.net> wrote:
>>>
>>> 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/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
>>>>>>
>>>>>
>>>>> --
>>>>> 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.
>>> --
>>> 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>
>


-- 
[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/0ef4e598/attachment-0001.html>


More information about the Openid-specs-authzen mailing list