<div dir="ltr">Thanks for sharing this! <div>And really sorry to have missed this... I watched the whole recording, great discussion!<div><br></div><div>So some late comments (sorry for the length):</div><div><br></div><div>- The SSE framework, as I understand it (please correct me if I'm wrong anywhere in what follows) has 2 components:</div><div>  1. The Event Streaming Framework: essentially specs for a REST-based Transmitter/Receiver system.</div><div>  2. Specs for actual Events, of which we have 2 right now: RISC and CAEP (and I understand a SCIM one in the works)</div><div><br></div><div>--> Some comments:</div><div>- 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 <a href="https://kafka.apache.org/intro">Kafka</a>). 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 t<a href="https://learn.microsoft.com/en-us/azure/architecture/data-guide/technology-choices/stream-processing">heir own Streaming platform</a> 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.</div><div><br></div><div>- 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. </div><div><br></div><div>- A proper Streaming platform + the new/enhanced AuthZ event, would give us an "<b>Authorization </b><b>Mesh</b>". 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...</div><div><div><br></div></div><div><div>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... </div><div><br></div><div>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 ? </div><div><br></div><div>Cheers,</div><div><br></div><div>./\.</div><div><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 31, 2023 at 3:50 PM David Brossard via policy-charter <<a href="mailto:policy-charter@lists.openid.net" target="_blank">policy-charter@lists.openid.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi all,<div><br></div><div>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 <a href="https://drive.google.com/file/d/1CYQOC-yKgF25DQvL8_D8duE_wmK7pnXc/view?usp=sharing" target="_blank">call was recorded</a> so that others can catch up.</div><div><br></div><div>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.</div><div><br></div><div>Cheers,</div><div>David<br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">---<br>David Brossard<br><a href="http://www.linkedin.com/in/davidbrossard" target="_blank">http://www.linkedin.com/in/davidbrossard</a><br><a href="http://twitter.com/davidjbrossard" target="_blank">http://twitter.com/davidjbrossard</a><br><a href="http://about.me/brossard" target="_blank">http://about.me/brossard</a><br>---<br>Stay safe on the Internet: <a href="https://www.capefearnetworks.com/wp-content/uploads/2017/05/Internet-Fraud-Prevention-Tips-IC3.pdf" target="_blank">IC3 Prevention Tips</a><br>Prenez vos précautions sur Internet: <a href="http://www.securite-informatique.gouv.fr/gp_rubrique34.html" target="_blank">http://www.securite-informatique.gouv.fr/gp_rubrique34.html</a></div></div></div></div>
-- <br>
policy-charter mailing list<br>
<a href="mailto:policy-charter@lists.openid.net" target="_blank">policy-charter@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/policy-charter" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/policy-charter</a><br>
</blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><a href="https://hihello.me/p/cda689b1-0378-4b9c-88cf-33a9bc8ef0c5" rel="noopener" style="display:inline-block" target="_blank"><img alt="This is Alexandre Babeanu's card. Their email is alex@3edges.com. Their phone number is +1 604 728 8130." src="https://cdn.hihello.me/cards/cda689b1-0378-4b9c-88cf-33a9bc8ef0c5/signature_logo.png?generated=1653502150176" width="360" style="display: inline-block; min-height: 100px;"></a><br></div></div>

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