[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