# AuthZEN Interop Scenarios

## Historical background
From the XACML interop in 2008:

* [Press release](https://xml.coverpages.org/XACML-HealthCareInterop.html)
* [Walkthrough](https://xml.coverpages.org/RSA-UseCasesGuideV7-20081020.pdf)
* There were **7 participants**, all vendors
* The interop used an **industry-specific** scenario (healthcare)
* Interop requirements came from **partners** in that industry (Health Information Technologies Standards Panel, US Dept of VA)
* The interop **assumed the value** of externalized authorization rather than making a case

From the ongoing Shared Signals CAEP interop in 2023-4:

* [Call for participation](https://openid.net/call-for-participation-demonstrate-interoperability-of-your-caep-implementations/)
* [Benefits statement](https://openid.net/importance-of-shared-signals-framework/) with major implementer proof points

## Proposal
* Ask **Mike L at OIDF** for support and advice
* Identify a **non-vendor partner** and ask them to contribute **requirements**
* Is Sean O'Dell on the WG interested to play this role?
* Could have an industry-specific flavor to it but audiences should be able to substitute their own needs mentally
* Pick a popular proprietary or open API?
* Produce deliverables such as:
* Draft **press release** — coordinate with Mike L at OIDF
* **Interop instructions** for participants
* Friendlier **interop/WG explainer** for the public - can leverage:
* [WG overview](https://openid.net/wg/authzen/)
* [PAD intro/problem statement](https://hackmd.io/H2a8WW2vTjOc5xy4Tm85oQ)
* Be clear on the **call-to-action** for app devs and any other target stakeholders:
* Engage in WG
* Engage in interop testing
* Help us answer key questions (through a survey?) - e.g.:
* Priorities/needs among the PDP-PEP use cases (protocol level)
* Pattern preferences and use cases (deployment level)
* Insights into why they’re not externalizing now

## Use Cases from the XACML Interop
> five general categories:
> - enterprise permissions,
> - consent directives,
> - security business rules,
> - emergency access, and
> - data filtering based on patient election.

2.1.1 HL7 Role/Permissions
2.1.2 HL7 Patient Consent Directives
2.1.3 Security Business Rule
2.1.4 Emergency Access
2.1.5 Fine Grain Access Control (Data Filtering)

Note that the data filtering example is more a data masking example where there is a finite set of fields to be protected (rather than a large or unknown number of items)

# The Use Cases we want to focus on

The use cases for AuthZEN are more technical. Generally, there is a consensus that there are enough standards, languages, graphs, and other approaches that tackle expressing authorization (MAC, DAC, enterprise, exceptions...) The goal of AuthZEN is to focus on the querying for an authorization decision. There are 3 ways this can be done:

1. Single Binary authorization request: _Can Alice view document #1?_
2. Batch Binary authorization request: _Can Alice view document #1, #2, #3?_
3. Open-ended authorization request (sometimes known as partial evaluation, reverse query, or search): _What can Alice do?_

There are variations of these 3 approaches. For instance, we could ask:

1. _Can Alice print?_ (generally, not specific to any item)
2. _What can happen?_
3. _What can Alice do on document #123 at 3pm from an office location?_

These are just variations and not new patterns.