[Openid-specs-authzen] Boxcarring proposal

Andrew Clymer andy at rocksolidknowledge.com
Fri Jun 14 05:14:58 UTC 2024


The same is true for max message size, but I guess that is something that may vary based on the implementation. SCIM has an endpoint that defines what features are available and limits etc

https://developer.4me.com/v1/scim/service_provider_config/
Service Provider Config | SCIM | 4me API<https://developer.4me.com/v1/scim/service_provider_config/>
4me API for Developers
developer.4me.com
Might be something worth considering once we have the wire protocol defined.

All the best

Andy





​We are the first IdentityServer partner to become a Certified B Corporation™.
​Head to our mission statement to read more about the ways we’re using business as a force for good.
​
​Rock Solid Knowledge Ltd is a company registered in England and Wales under number 6811209.
Registered office: C2, Vantage Office Park, Old Gloucester Road, Bristol, BS16 1GW, United Kingdom
​Vat registered: GB948 1966 72
________________________________
From: Openid-specs-authzen <openid-specs-authzen-bounces at lists.openid.net> on behalf of Alex Babeanu via Openid-specs-authzen <openid-specs-authzen at lists.openid.net>
Sent: 13 June 2024 22:12
To: AuthZEN Working Group List <openid-specs-authzen at lists.openid.net>
Cc: Alex Babeanu <alex at 3edges.com>
Subject: Re: [Openid-specs-authzen] Boxcarring proposal

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<mailto: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<mailto: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<mailto: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<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<mailto: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.

[https://raw.githubusercontent.com/aserto-dev/artwork/main/logo/horizontal/color/aserto-horizontal-color.png]<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:



  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<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



[Image removed by sender.] [Image removed by sender.]  [Image removed by sender.]  [Image removed by sender.]

[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<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.



--

[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<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


--
[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<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


--
[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>


--
[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/20240614/fa97612e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image743882.png
Type: image/png
Size: 67887 bytes
Desc: image743882.png
URL: <http://lists.openid.net/pipermail/openid-specs-authzen/attachments/20240614/fa97612e/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image627366.png
Type: image/png
Size: 31014 bytes
Desc: image627366.png
URL: <http://lists.openid.net/pipermail/openid-specs-authzen/attachments/20240614/fa97612e/attachment-0003.png>


More information about the Openid-specs-authzen mailing list