[policy-charter] July 27 call notes

Thu Jul 27 18:25:44 UTC 2023

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/policy-charter/attachments/20230727/63118601/attachment-0001.html>