<div dir="ltr">Hi Alex,<div><br><div>Re: why we need SSF:<br><div>Kafka has come up in discussions about SSF / CAEP in many situations. I think the difference is (and I may be wrong because I'm not too familiar with Kafka), that SSF does not require any common infrastructure other than HTTP. I think if both endpoints (Transmitter and Receiver) were 3Edges or some single organization, it is conceivable that you would not need SSF and can use one of the technologies you mention.</div><div><br></div><div>We have no idea how Microsoft has implemented CAEP internally. One reason they could not have implemented SSF is that the framework did not exist when they announced their implementation. We were still working on draft-01 at that time. Microsoft was participating in that development, is a co-author of that spec and is a co-chair of the Shared Signals working group.</div><div><br></div><div>Atul<br></div><div><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 5, 2023 at 10:30 AM Alex Babeanu <<a href="mailto:alex@3edges.com">alex@3edges.com</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">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" target="_blank">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" target="_blank">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></blockquote></div>