[Openid-specs-authzen] Boxcarring proposal
eve at xmlgrrl.com
eve at xmlgrrl.com
Thu Jun 13 15:38:39 UTC 2024
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 <tel:+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 <mailto: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 <mailto: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 <mailto: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:
>>>>>
>>>>>
>>>>> Assume we have a PEP which implements boxcarring but a (legacy?) PDP which does not.
>>>>> When the PDP receives a boxcarred request with an evaluations object, I presume it would ignore that object as an unrecognized key, correct?
>>>>> 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 <mailto:openid-specs-authzen-bounces at lists.openid.net>> on behalf of Omri Gazitt via Openid-specs-authzen <openid-specs-authzen at lists.openid.net <mailto: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 <mailto:openid-specs-authzen at lists.openid.net>>
>>>>> Cc: Omri Gazitt <omri at aserto.com <mailto: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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> <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
>>>>>
>>>>> --
>>>>> 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
>
>
> --
> <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-authzen/attachments/20240613/264c771d/attachment-0001.html>
More information about the Openid-specs-authzen
mailing list