# Meeting Notes 2024-04-23

## Attendees
👉 Add your names here
@gerryatstrata
@omri
Allan Foster
Elizabeth Garber
@xmlgrrl
Granville Schmidt
Steve Venema
Jason Garbis
Roland Baum
Jeffrey Broberg
@zirotrust (Atul)
David Hyland
Bjorn Hjelm
Adam Rusbridge

## Agenda
- Adding a co-chair
- Interop status update
- Meeting time: David is out this week, so we'll get the final survey results next week. So far, it looks like we will remain with one call per week and alternate the times every other week
- Continue the discussion of Advice and Obligation statements?
- Any further updates to the design patterns document (Alex)
- Next steps on boxcarring (one subject, multiple authorizations in a single request)

## Notes
- Omri has been voted as our 5th co-chair!
- Interop status
- Axiomatics is close to complete. An endpoint is running, but without a policy
- Hexa/OPA integration is underway, passing all the tests and we just need to register a URL
- Omri/Atul gave update to OpenID workshop - comment was "wow, you've made a lot of progress in 6 months!"
- Heather Flannigan asked if we are focused on human ids, our answer was that we are looking at things more broadly to include machine ids
- also att IIW, gave overview of AuthZEN and hosted happy hour
- Steve did a authZ 101
- Phil Windley gave a preso on Verifiable Credentials and Authorization crossing streams in some use cases. Posing notion of limited disclosure via VCs vs. prevailing wisdom of authZ systems where developers are encouraged to send all the subject info they have on hand to the PDP during an authZ request.

### Advice/obligations
- From last week, we started with Eve's suggestion to have a framework for how components would communicate
- There are a small number of use cases that are generic enough that we can use as examples to create a profile/template for.
- Step up authN
- make the workload as low as possible on the PEP
- Open banking scenarios could have different modes of user flow, so we shouldn't be too restrictive
- Allan suggests the general framework is generic enough and profiles for open banking could be created
- Omri asking where redirects fit in, since PEP is typically operating after that user flow happens
- AF: the response to PEP could be to go and do some authN step, like MFA or refresh a token
- JG: Might be useful to define concrete use cases as part of the design patterns docu
- AT: responding to OG, actions could be some other step rather than just do some authN step
- OG: Agreed, he mentions the google doc example: If I don't have access, there is a dialogue for requesting access - which may or may not be answered
- EM: PDP is saying to PEP - more context needed! Could be front or back channel comms. PDP should not be in the business of handling all this. The process to manage the session aspects is onerous, from UMA experience.
- AF: Challenge with sending reason codes to PEPs is that they have to know what to do with the reason code and PEPs will have to be updated if/when reason codes change in future.
- AT: Asking Eve if what the current spec has the framework is close to what she suggested. EM: 2 layers of semantics - should stay out of. Should be profiles of semantics of data structure. We should have to spec the semantics of the negotiation between PEP and PDP. We probably don't have the understanding to capture 80% of use cases.
- DH:In the context of RAR, the PDP plays a role behind the AS in the providing the what-can-i (in an empty bracketed request - Section 7.1 RFC9396) for an authorization_details on token request. Note also that the GM API also performs a what-can-i capability that would also be supported by the PDP . So when we look at PDP standardization we're going to need to consider more than just the requirement of the PEP.
- AT: For discouvering resources that user has access to, we have the search mechanism in the spec
- OM: things that were missing to complete a v1 of the PDP-PEP spec
- advice / obligations
- box carring (sending multi requests)
- subject / resource search
- GG: perhaps it's time to spin off small group to come up with spec updates and bring back to larger group. The other two topics could be discussed more with the larger group to get everyones' opinions on the table before spinning off similar sub groups.
- JG: If we are able to move authZ out of app code, it's a big step forward.If the PEP is doing more of the work, that is not necessarily a bad thing because it is policy based rather than code based.
- OM: Obviously the PEP is an important component but one could make the argument that the PEP should be limited in its functionality.
- RB: If a person is on a VPN, it's part of the context but it can be added to the request because the PEP would add this info and would do so if it is part of the policy. Anyone setting up the policy has to be certain that the info is available - so the policy author and infra do need to coordinate.
- SV: Important that we don't assume PEP is an applicance, could take many differnt forms. There is a variation in the complexity of what a PEP needs to do.

### Sub group ONE
Steve, Eve, David H, Roland