[policy-charter] call notes for Aug 22

[Gerry Gebel]

Attendance:

Omri G

Aaron C

Victor L

Alex B

Shayne

Steve V

George F

Mike K

Gerry G


We had an abbreviated session today due to some overlapping schedule
conflicts. The discussion focused on the Scope section, where we made some
minor edits. We also added links to some external documents (Authorization
Design Patterns and Proposed standard for an authorization API)


If possible, we’d like to get acknowledgment and consensus on the draft for
our next call so that we can move to submittal to OIDF for an official
working group.


For the next call, please review the scope and the newly added external
documents for further discussion, link provided here for your convenience:
https://docs.google.com/document/d/1ijAaymAapYyeV_3qMVjuLtNzoskKsh7R/edit


Here are some additional notes to capture the discussion:


- Omri suggested that we make point 2 stronger in the scope section
(updated text)



- Steve V: Will the scope include the definition of higher levels of
abstraction for a management audience? (No, moved that to the “out of
scope” section


- Aaron: Why are we starting first with a charter and not a problem
statement (following OIDF conventions, charter is needed to create official
working group and gain OIDF IPR protection)


- Aaron - discussion of how to promote interoperability in scope #1
statement. Access in authN flows for example are different than some
authorization flows. AuthN requirements could be represented as parameters
(MFA requirements, etc). Also have policies for users if their device is
out of date - “we would like you to update to latest security
updates/patches”. We don’t look at this like typical access for
permit/deny, could have settings like to quarantine a device. We are
thinking that an implementation is more like a decision engine

Omri - couple layers. 1 is managing policies for particular layer. We
talked about creating profiles to describe payload - similar to OIDC claims
profile (flexible).

One architecture pattern is sending PDP a request and getting a response -
might have been too specific for exact format, but this is an important
aspect

Second was moving policy in a payload from a management system to a
decision system

Aaron - IDQL has action, but this can be an abstraction that is interpreted
in different ways

Alex - can be done in interoperable way if kept generic enough

Gerry - In response to Aaron’s use cases, There is likely a builtin bias
among the majority in this group that authN has already been completed and
now we have moved on to exclusively address access control




- Steve: What is the process to submit a charter?

> at least 5 proposers

> 1 or more chairs

> 1 or more editors

> submit to Specifications Council for review/approval



Omri - IIW: propose meeting on Tue or Wed for anyone who is attending. We
should try to make some plans soon so people can organize their schedules
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/policy-charter/attachments/20230822/4b0b604f/attachment-0001.html>