[Openid-specs-authzen] Boxcarring proposal

Omri Gazitt omri at aserto.com
Thu Jun 13 20:49:55 UTC 2024


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


More information about the Openid-specs-authzen mailing list