[policy-charter] July 27 call notes

[Atul Tulshibagwale]

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> 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 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
> 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/9590839a/attachment-0001.html>