From atul at sgnl.ai Tue Sep 5 15:00:14 2023 From: atul at sgnl.ai (Atul Tulshibagwale) Date: Tue, 5 Sep 2023 08:00:14 -0700 Subject: [policy-charter] I'll join today's call at 9:30 AM PT Message-ID: Eom -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex at 3edges.com Tue Sep 5 17:29:53 2023 From: alex at 3edges.com (Alex Babeanu) Date: Tue, 5 Sep 2023 10:29:53 -0700 Subject: [policy-charter] Link to the recording for yesterday's call on CAEP, shared signals, and PDPs In-Reply-To: References: Message-ID: 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 ). 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 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 > > 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 > > 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.] -- 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: From atul at sgnl.ai Tue Sep 5 18:54:40 2023 From: atul at sgnl.ai (Atul Tulshibagwale) Date: Tue, 5 Sep 2023 11:54:40 -0700 Subject: [policy-charter] Link to the recording for yesterday's call on CAEP, shared signals, and PDPs In-Reply-To: References: Message-ID: 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 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 ). 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 > 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 >> >> 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 >> >> 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.] > > > 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: From phil.hunt at independentid.com Tue Sep 5 19:32:33 2023 From: phil.hunt at independentid.com (Phillip Hunt) Date: Tue, 5 Sep 2023 12:32:33 -0700 Subject: [policy-charter] Link to the recording for yesterday's call on CAEP, shared signals, and PDPs In-Reply-To: References: Message-ID: <3DA6D5E1-AF89-47BF-B9D9-63F811EDC540@independentid.com> 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 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 > 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 ). 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 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 > 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 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 >>> 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 >> >> >> -- >> >> >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex at 3edges.com Thu Sep 7 16:37:03 2023 From: alex at 3edges.com (Alex Babeanu) Date: Thu, 7 Sep 2023 09:37:03 -0700 Subject: [policy-charter] Link to the recording for yesterday's call on CAEP, shared signals, and PDPs In-Reply-To: <3DA6D5E1-AF89-47BF-B9D9-63F811EDC540@independentid.com> References: <3DA6D5E1-AF89-47BF-B9D9-63F811EDC540@independentid.com> Message-ID: 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 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 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 ). 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 >> 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 >>> >>> 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 >>> >>> 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.] >> >> >> 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.] -- 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: From alex at 3edges.com Thu Sep 7 18:36:36 2023 From: alex at 3edges.com (Alex Babeanu) Date: Thu, 7 Sep 2023 11:36:36 -0700 Subject: [policy-charter] IIW 2023 - meeting Message-ID: Hi there, Quick question: there was mention of meeting in person at IIW on Oct. 9 (was it?). Trying to make travel arrangements: does anyone have details on that meeting, or has it not been decided yet? Many thanks, ./\. -- [image: This is Alexandre Babeanu's card. Their email is alex at 3edges.com. Their phone number is +1 604 728 8130.] -- 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: