---
# System prepended metadata

title: Meeting Notes 2024-06-25
tags: [meeting-notes]

---

# 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.




