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

[Atul Tulshibagwale]

Hi Alex,

Re: why we need SSF:
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.

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.

Atul


On Tue, Sep 5, 2023 at 10:30 AM Alex Babeanu <alex at 3edges.com> wrote:

> 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/9665f04c/attachment-0001.html>