[policy-charter] Link to the recording for yesterday's call on CAEP, shared signals, and PDPs

[Alex Babeanu]

Thanks for sharing this!
And really sorry to have missed this... I watched the whole recording,
great discussion!

So some late comments (sorry for the length):

- The SSE framework, as I understand it (please correct me if I'm wrong
anywhere in what follows) has 2 components:
  1. The Event Streaming Framework: essentially specs for a REST-based
Transmitter/Receiver system.
  2. Specs for actual Events, of which we have 2 right now: RISC and CAEP
(and I understand a SCIM one in the works)

--> Some comments:
- I have (some rather grave) concerns about 1: the fwk itself. Basically, I
feel that this reinvents the wheel. Proven, performant streaming platforms
already exist and are widely used throughout the industry (see Kafka
<https://kafka.apache.org/intro>). I think we could/should focus on the
Events themselves and leave the streaming part to those existing platforms.
Note: Atul mentions during this call that MSFT did exactly that: just use
CAEP (while using their own Streaming platform
<https://learn.microsoft.com/en-us/azure/architecture/data-guide/technology-choices/stream-processing>
maybe?).
Streaming platforms will always outperform whatever we, AuthZ vendors, can
come-up with: it's not our core business. Honestly, I don't want to have to
do that, I would rather integrate 3Edges with smthg like Redis-streams for
example, and maybe provide a thin REST wrapper. But that's just me... But
even that thin wrapper seems like too much work, we just need to agree on
the event formats imho.

- I think we could enhance the events, or create an AuthZ specific Event,
to also support AuthZ Decision requests/Responses, including search
requests. So there is a SCIM Event, for the PIP-PDP communication I
assume?  AuthZ Decision request/response events would be a great addition
for the PEP-PDP communication.

- A proper Streaming platform + the new/enhanced AuthZ event, would give us
an "*Authorization **Mesh*". A streaming platform would loosely-couple all
actors. We could then integrate as many IdPs, PDPs, Resources, PEPs as we
wanted. PDPs/PEPs would just publish request/responses to a topic,
PDPs/PEPs would also just subscribe to those topics. All new Apps could
subscribe or publish to those same topics. It's much simpler. I could
talk at length about the benefits of the approach...

If you read all this, thx for your time! It's a bit out there, but meshes
are what is currently happening in the industry. We might as well build our
own...

My $0.02.. that said I would be glad to talk about it some more, but is
this rather a discussion for the openid-specs-risc group ?

Cheers,

./\.


On Thu, Aug 31, 2023 at 3:50 PM David Brossard via policy-charter <
policy-charter at lists.openid.net> wrote:

> Hi all,
>
> Some of us (the ones not vacationing 🏝️) got together to chat about CAEP
> & shared signals and how it can apply to a "traditional" ABAC PEP-PDP
> architecture. The call was recorded
> <https://drive.google.com/file/d/1CYQOC-yKgF25DQvL8_D8duE_wmK7pnXc/view?usp=sharing>
> so that others can catch up.
>
> Both Omri and I see the use of CAEP as relevant for the PDP-PIP
> interaction. Alex, we'd love to understand more your thoughts on the
> PEP-PDP side of things.
>
> Cheers,
> David
>
> --
> ---
> David Brossard
> http://www.linkedin.com/in/davidbrossard
> http://twitter.com/davidjbrossard
> http://about.me/brossard
> ---
> Stay safe on the Internet: IC3 Prevention Tips
> <https://www.capefearnetworks.com/wp-content/uploads/2017/05/Internet-Fraud-Prevention-Tips-IC3.pdf>
> Prenez vos précautions sur Internet:
> http://www.securite-informatique.gouv.fr/gp_rubrique34.html
> --
> policy-charter mailing list
> policy-charter at lists.openid.net
> https://lists.openid.net/mailman/listinfo/policy-charter
>


-- 
[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/policy-charter/attachments/20230905/4b07cf74/attachment.html>