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

Thu Sep 7 16:37:03 UTC 2023

Thanks Phil and Atul for the clarifications, it does really help!

These:
- " we all fully expected that message buses of differing types would be
connected to “SSF”-like relays or gateways"
- "I believe the primary role for SSF is to act as a boundary mechanism."
 are also what I had in mind with the "Rest Wrappers" I mentioned, I guess
we're on the same page there.

The cross-domain use case is interesting, assuming it's for Federated
environments? In any case this makes more sense now.

That said, I feel we could still use enhance messages for AuthZ to convey
authz request / responses, policies themselves, etc...

Cheers,

./\.

On Tue, Sep 5, 2023 at 12:32 PM Phillip Hunt <phil.hunt at independentid.com>
wrote:

> Hey Alex,
>
> I was involved in the early days before SSF was started.  When we wrote
> the Security Event Token spec, the original goal was just some guidance
> around using JWT for events.
>
> The beauty of SETs are precisely that they can be transferred by almost
> any mechanism as they are url safe (just as with Oauth tokens).
>
> Existing message buses came up in early discussions but almost none
> describe passing messages across boundaries or even regions.  For example
> Kafka has a special message bus interconnect system to handle this.
>
> What we determined in SECEVENTS WG was we needed a way to provide
> “acknowledged” SET transfer between servers with a targeted “simple”
> transfer mechanism.  This was important as many publishers were unwilling
> to provide indefinite recovery.  The idea of acknowledgement was that once
> acknowledged an event may be “forgotten” by the transmitter.  These
> qualities are unique (or were at the time) to the SET PUSH and POLL specs.
>
> At the time, we all fullly expected that message buses of differing types
> would be connected to “SSF”-like relays or gateways.  Like RISC and CAEP
> and the nature of SETS, using this method avoided the need to get everyone
> to agree to use a single message bus like Kafka.  Also as mentioned above,
> Confluent was already saying Kafka isn’t meant for cross-domain scenarios.
>
> I believe the primary role for SSF is to act as a boundary mechanism.  In
> my case, I have a Kafka bus being used for replication between SCIM
> servers.  I now have support to use SSF as a replication hub where each
> node pushes changes to the SSF server and the server routes the events back
> to other nodes in the cluster.  The scenario also works cross-domain.
>
> The next step I have planned is to have the server relay between kafka
> buses and across domains.  Hence the need for an inter-op message bus
> neutral system.
>
> Phillip Hunt
> phil.hunt at independentid.com
>
>
>
>
>
> On Sep 5, 2023, at 11:54 AM, Atul Tulshibagwale via policy-charter <
> policy-charter at lists.openid.net> wrote:
>
> 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.
>>
> --
> 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/20230907/c0804f09/attachment-0001.html>