# Meeting Notes 2024-06-25 ## Attendees 👉 Add your names here Granville Schmidt Omri Gazitt (@omri) @davidbrossard Alex Olivier Jahan Moreh Phillip Messerschmidt Roland Baum Don Coltrain Victor Lu (Atul) Bjorn Hjelm David Hyland ## Agenda - Update on Authenticate conference - David had a talk accepted - Alex Olivier also submitted a talk - they are potentially open to having an authZ workshop - Draft spec process check - Review feedback on draft spec - making resource ID type mandatory - Decentralized Id use cases and subject id resolution - Review Boxcar proposal (time permitting) ## Actions ## Open issues ## Notes - Gerry is working on the process to make the implementer's draft a spec. He is liaising with the right folks at OpenID. - Björn from OpenID is on the call - He will check with Elizabeth Garner on next steps to get the site updated ### Spec Updates - Should we make resource ID mandatory? - Can Alice read books? - Can Alice read book #123? - Alex O. and Atul have no objections to making the resource ID mandatory. - We should probably make the yes/no API more strict and therefore introduce resource ID. - Jahan points out that reading books as a whole is a form of coarse-grained access. - Omri brings up an example "give me the actions the user can do on a given resource type" - We have consensus to make resource ID mandatory - Question from Patrick P.: can we cater to "anonymous" use cases e.g. "Can a user drink beer?" where all we know is the user's age. This fits into a DID world. - In this case, maybe the user ID can bear the DID identifier, not really the end-user's identity. #### Boxcarring Proposal - https://hackmd.io/ri7odOQkQ6yztBQGlXnnKg?both - Error processing and stopping behavior (Alex B.) - Should we have "stop on error"? - As a client app, I want to dictate the behavior - Should we have "stop on deny"? - As a client app, I want to dictate the behavior - DB: this is similar to XACML's CombinedDecision - This is useful for cases where, to get access, one must have access to all the parts - Introduce a section in the spec around safeguards and DoS - Alex: should we limit the # of requests? Avoid crashing the PDP - add a note to the spec: highlight the issue and recommend to implement limiting in the PDP implementation / its the responsibilty of the PDP to handle & enforce internal limits & sanity checks - See [UMA](https://kantara.atlassian.net/wiki/spaces/uma/pages/4849800/UMA+Implementer+s+Guide#UMAImplementer'sGuide-authz-responsesUnderstandingAuthorizationServerResponseOptionsFromtheTokenEndpoint) - We have consensus on the overall spec - Let's aim for an interop by IIW or Authenticate.