AuthZEN Working Group - Charter
AuthZEN will focus on specific areas of interoperability by documenting common authorization patterns, define standard mechanisms, protocols and formats for communication between authorization components, and recommend best practices for developing secure applications.
AuthZEN Working Group Charter
1) Working Group name
Authorization Exchange WG (AuthZEN WG)
The purpose of the AuthZEN WG is to provide standard mechanisms, protocols and formats to communicate authorization related information between components within one organization or across organizations, which may have been developed or sourced from different entities.
Centralized authentication services have revolutionized identity management and security best practices by removing the burden of repeatedly implementing identity lifecycle management within individual applications and by giving users a more seamless and consistent authentication experience. Protocols such as SAML and OIDC facilitate this approach to single sign-on and federated environments.
Authorization capabilities are in need of a similar paradigm shift to enable applications to better support more fine-grained, dynamic authorization than what is afforded by today’s commonly used pattern of embedding entitlements into OAuth2 bearer tokens after user authentication. This is not a new idea and we already have various approaches to implementing externalized authorization – commonly called “P*P” architectures (PIP, PDP, PEP, etc.). Examples include architectures based on IDQL, OPA/Rego, XACML and Zanzibar. Deploying any of these authorization architectures can be challenging from implementation complexity, granularity, and scalability perspectives; interoperability between different architectures and between different implementations are particularly challenging.
The purpose of this WG is to explore how to improve the deployability, scalability and interoperability of dynamic, fine-grained authorization schemes to better meet the needs of modern information security best practices. In particular, we need to make authorization easy for an organization to deploy and operate authorization capabilities across their entire application estate, including both SaaS services and internally developed applications (whether they be on-prem or in the Cloud).
Note that this is not necessarily an effort to define yet another authorization architecture or runtime policy language. Instead, the WG will develop OpenID Foundation Final Specifications which leverage existing architectures and protocols as much as possible. Where appropriate, the WG intends to collaborate with international standards development organizations, such as ISO/IEC JTC 1, ITU-T, and IETF, for recognition of these OpenID Foundation specifications.
3) Scope & Objectives
“Be the OAuth2/OIDC/SAML of authZ” by:
- Increase interoperability between existing standards and approaches to authorization – examples include ALFA, Cedar, OPA, IDQL, Graph-based and Zanzibar-inspired systems such as OpenFGA, Topaz, SpiceDB.
- interop from a policy management perspective
- Define and formalize interoperable communication patterns between major authZ components, for example PAP, PDP, PEP, and PIP.
- use cases
- integration patterns
- interop from a runtime request/response perspective
- Establish and promote the use of externalized authZ as the preferred pattern.
- Single pane of glass for management and auditability for those who manage application portfolios.
- Software developers/owners/SaaS are relieved of this burden and don’t have to reinvent the “authorization wheel” by making authZ a utility so that it is easy to plug into an application
- Compliance requirements are more easily and cost-effectively met with provable controls that foster more transparency
Out of scope
- Providing higher abstraction level of technical policies for an executive audience
4) Proposed specifications
- Description of standard authorization patterns, use cases, communications patterns, and integration patterns.
- An API to communicate authorization requests and decisions between Policy Decision Points (PDPs) and Policy Enforcement Points (PEPs) (which may be implemented by different parties).
- An API to communicate authorization policy and data from PAP to PDPs (which are implemented by different parties).
5) Anticipated audience or users
- Authorization developers and architects
- SaaS vendors (Multi client hosting)
- Cloud platforms
- Application vendors
- Enterprise implementers/practitioners who integrate authorization products.
7) Method of work
E-mail discussions on the working group mailing list, working group conference calls, and face-to-face meetings from time to time.
8) Basis for determining when the work is completed
When 3 independently-developed implementations that are proven to interoperate exist!
- OASIS XACML: https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml
- XACML ALFA: https://en.wikipedia.org/wiki/ALFA_(XACML)
- NIST ABAC: Guide to Attribute Based Access Control (ABAC) Definition and Considerations: NiST SP 800-162
- ANSI / NIST Next Generation Access Control (NGAC): INCITS 565-2020
- Google Zanzibar: https://research.google/pubs/pub48190/
- OpenID Connect Advanced Syntax for Claims: https://openid.bitbucket.io/ekyc/openid-connect-advanced-syntax-for-claims.html
- RFC 3198 Terminology for Policy-Based Management
- RFC 2753 A Framework for Policy-based Admission Control
- RFC 2904 AAA Authorization Framework
- IDQL/Hexa project
- Open Policy Agent: https://openpolicyagent.org
- Atul Tulshibagwale, SGNL
- Gerry Gebel, Strata Identity
- Steve Venema, ForgeRock
- Omri Gazitt, Aserto
- Pieter Kasselman, Microsoft
- Alex Babeneau, 3Edges
- David Brossard, Axiomatics
- Allan Foster
- Andrew Hughes, Ping Identity
- Mike Kiser, SailPoint