[policy-charter] July 27 call notes

Thu Jul 27 18:36:25 UTC 2023

Hi Atul, yes, it is an IETF mailing list: Wimse Info Page (ietf.org)<https://www.ietf.org/mailman/listinfo/wimse>

From: policy-charter <policy-charter-bounces at lists.openid.net> On Behalf Of Atul Tulshibagwale via policy-charter
Sent: Thursday, July 27, 2023 11:33 AM
To: Policy Charter Mail List <policy-charter at lists.openid.net>
Cc: atul <atul at sgnl.ai>
Subject: Re: [policy-charter] July 27 call notes

Hi Gerry,
Thanks for the detailed notes. I believe the mailing list Pieter mentions is in the IETF and not in OIDF? Can you please clarify?

Thanks,
Atul

On Thu, Jul 27, 2023 at 11:26 AM Gerry Gebel via policy-charter <policy-charter at lists.openid.net<mailto:policy-charter at lists.openid.net>> wrote:
Hi all,

We had a very spirited and interesting discussion today in the currently named Admin Policy Push group.The focus was almost entirely on scope, with a short discussion of IIW and a possible charter.

Below is my attempt at capturing the conversation and a list of attendees. As usual, please make any corrections or other changes.

The conversation will continue on a weekly basis until the end of September for now, with likely in person session(s) at IIW in October. Mike from OIDF will send an invite to the email list

You are also encouraged to look at the draft charter that Andrew previously shared so that it includes needed context for the Admin work stream. https://docs.google.com/document/d/1ijAaymAapYyeV_3qMVjuLtNzoskKsh7R/edit?usp=sharing&ouid=110252403279221684258&rtpof=true&sd=true

Cheers,
Gerry

===========================

July 27 Admin Policy Push group call

Attendance

Allan F

Gerry G

David B

Andrew H

Omri G

Pieter K

S Hutch

Steve V

Shayne M

Guy P

Atul T

Aaron C

Sebastian R

Roland B

Notes:

Review of agenda

Atul - will there be one group on authZ with 2 sub groups or something else?

Allan - 2 different streams, don’t know if it needs to be separate charter or not

Andrew - there is a draft charter for PEP-PDP. If it’s going to the same people, make it one work stream.

Allan - looks like overlap is quite high

David, SteveV and Pieter concur

Scope

Discussion of relationship data and its importance

Some concern of widening the scope - could be another work stream

Some discussion of whether creating a new policy format is a good idea:

Allan - didn’t think we could take an existing one )OPA, Cedar) and force others to use it

David - if we go this path, would want to look at existing and hopefully find that one of these is the super set

Pieter - so many existing proprietary formats - thought we do this in a way that is language agnostic, rather than picking existing one and creating new one. Not worth spending time on creating new one

Allan - don’t think we want to create new one if we can, agnostic is key

Hutch - tried to solve this over last couple years, thing we are trying to get to is a policy that all PDPs could use. What Mitsubishi has built is so organizationally specific. Used our own tagging strategy and taxonomy. Maybe you could provide guidance on how others could build such a system - what’s the best way . What I see us doing is what CISO or auditor interacts with - build policy, add tags and that system uses the standardized policy language to send it to the different PDPs.

Steve - OPA, Cedar, ALFA are potential targets for us and there is an unbounded problem in that we don’t know what all is out there. How to do this without making an intractable problem.

Allan - agree that we don’t want to set up a natural language interface. While enterprises do things differently, they all have the same intent. We want to propagate a level of policy expression that achieves things like “only US employees can view these accounts”

Hutch - real world policy example, teller can only see client data if member of branch and both are citizens of the same country. This would need to be loaded into a PDP like Axiomatics but also conditional access in Azure.

Pieter - is term policy term overloaded? It’s not clear to me that we need another policy model given the complexity and chance for adoption. Is this really an effort to define another policy language?

Hutch - not concerned with transport protocol, it’s more about how I do that consistently with Axio, Azure, CyberArk, etc. Need to go back and show auditors that it is being implemented consistently.

Andrew - maybe skipping ahead 10 steps, but have a meeting in a week

1. Round trip a policy from a virtual PAP into and out of 3 authZ engines - how to confirm it got there

2. What would this look like? See what is really hard to do - let’s talk about something specific

If we have a specific thing to work on, we will learn from it - which we could not do with only talking about generalities.

Omri - Most consumers don’t control every PEP or PDP in relying parties. My hope is that if we can establish an architecture pattern where if your org has a set of policies, there is a way you can push those policies to relying parties. Question or emphasis is can we establish this pattern - haven’t thought about whether there needs to be a standard policy format.

SteveV - picking up on Andrew, pick a set of targets for acme.com<http://acme.com/> has sfdc and aws and internal service - how would we express a policy to cover this use case. Hutch thinks this is a good direction to go.

Hutch - also thinking about how to work with existing systems, ended up writing their own adapters for apps and infra pieces.It’s not just common language, but having everyone using the same taxonomy - even for attribute semantics. Just doing this for sfdc and Azure was very difficult.

Shayne - reflect on difference of Hutch and Omri. Hutch sounds complicated to send policy to existing systems because they are all different. Whereas Omri seemed to be shaping the future a future model that vendors could build to.

Hutch - have to build for tomorrow, would not try for today.

Pieter - sounds nice, but cannot escape the past

Omri - example: sfdc had its own model, but moved to OIDC over time. Coalesce a critical mass in the industry and have anchor tenants moving in the right direction - who are the killer apps here?

Aaron - extend Omri - what can we learn from the past? SQL is an example and have all these successful implementations albeit with proprietary extensions.

Allan - done this before with authN. Arguments were that we need to do this ourselves, but reached a point where centralizing is the right thing to do. Could do the same with authz

Pieter also important to know that they are very different. AuthN was easier to sell, value to customer, IT, CISO, and providers. I worry that the value prop does not exist in the same way. Pulling out years of business logic is going to be a hard sell.

Allan - posit that it is easier sell after listening to Hutch. Don’t care how they do policy, but managing how it is done is what is cared about. There will always be pushback for various reasons, but at enterprise level the problem exists.

Pieter - agrees on the problem in multi cloud and multi service environments. Concern that inventing another layer of policy language is the best way to go

David - authN and authZ have similarities, but need to standardize PEP to PDP. More important to ask request in same way, does not matter what the policy format is. If that is done correctly, we can go to sw vendors and plan for ext authZ in their platforms/services in a standard way. Hutch said policies are unique, however there are cases where there are common policies such as for export control. Some verticals, like gov, defined certain claims for SAML. Could defer policy to OPA, Cedar, or ALFA.

Allan - think we’ll have to do multi calls to further refine scope. The forward looking architecture is important, but also have to look at existing environments.

Allan - I encourage people to look at the charter that Andrew already started and see if it covers what we want.

Allan - IIW is coming up in October and we should plan on a working session there.

Pieter - there is a new mailing list on OIDF for workload identity where authZ will also be a topic over there. Anyone interested can check it out.

David - should we contact other standards groups about this activity?

Outreach: David to OASIS, Omri to OPA, cedar people already know since they were at the Identiverse meeting

Given the interest and work to be done, we will schedule weekly calls via OIDF through end of Sep

--
policy-charter mailing list
policy-charter at lists.openid.net<mailto:policy-charter at lists.openid.net>
https://lists.openid.net/mailman/listinfo/policy-charter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/policy-charter/attachments/20230727/13927a22/attachment-0001.html>