<div dir="ltr">Dear all,<div><br></div><div>Thanks to everyone who attended this week's call and special thanks to Alex for lending me his backyard so I could pretend I have a Weber grill at home.</div><div><br></div><div>On Tuesday, we agreed to make resource ID mandatory in the spec. This aligns better to the spirit of the API which is to ask discrete Yes/No questions (Can Alice view document #123?) rather than what would be perceived as a search query (Can Alice view documents?).</div><div><br></div><div>We also reviewed the boxcarring proposal and we also have consensus. Full notes below.</div><div><br></div><div><b>Agenda</b><br><ul><li>Update on Authenticate conference</li><ul><li>David had a talk accepted</li><li>Alex Olivier also submitted a talk</li><li>they are potentially open to having an authZ workshop</li></ul><li>Draft spec process check</li><ul><li>Review feedback on draft spec</li><li>making resource ID type mandatory</li><li>Decentralized Id use cases and subject id resolution</li><li>Review Boxcar proposal (time permitting)</li></ul></ul><b>Notes</b><br>Gerry is working on the process to make the implementer's draft a spec. He is liaising with the right folks at OpenID.<br>Björn from OpenID is on the call<br>He will check with Elizabeth Garner on next steps to get the site updated<br>Spec Updates<br>Should we make resource ID mandatory?<br>Can Alice read books?<br>Can Alice read book #123?<br>Alex O. and Atul have no objections to making the resource ID mandatory.<br>We should probably make the yes/no API more strict and therefore introduce resource ID.<br>Jahan points out that reading books as a whole is a form of coarse-grained access.<br>Omri brings up an example "give me the actions the user can do on a given resource type"<br>We have consensus to make resource ID mandatory<br>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.<br>In this case, maybe the user ID can bear the DID identifier, not really the end-user's identity.<br>Boxcarring Proposal<br><a href="https://hackmd.io/ri7odOQkQ6yztBQGlXnnKg?both">https://hackmd.io/ri7odOQkQ6yztBQGlXnnKg?both</a><br>Error processing and stopping behavior (Alex B.)<br>Should we have "stop on error"?<br>As a client app, I want to dictate the behavior<br>Should we have "stop on deny"?<br>As a client app, I want to dictate the behavior<br>DB: this is similar to XACML's CombinedDecision<br>This is useful for cases where, to get access, one must have access to all the parts<br>Introduce a section in the spec around safeguards and DoS<br>Alex: should we limit the # of requests? Avoid crashing the PDP<br>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<br>See UMA<br>We have consensus on the overall spec<br>Let's aim for an interop by IIW or Authenticate.<br></div><div><br></div><div><b>Conclusion</b></div><div>And just as a reminder, here are the useful links for our WG:</div><div><ul><li><a href="https://openid.net/wg/authzen/">WG homepage</a></li><li><a href="https://hackmd.io/@oidf-wg-authzen">HackMD site</a></li><ul><li><a href="https://hackmd.io/@oidf-wg-authzen?tags=%5B%22meeting-notes%22%5D">Meeting notes</a></li></ul><li><a href="https://github.com/openid/authzen">Github repository</a></li><ul><li>The <a href="https://github.com/openid/authzen/blob/main/api/authorization-api-1_0.md">latest spec</a> (MD doc) and the <a href="https://openid.github.io/authzen/">published version</a></li><li><a href="https://github.com/openid/authzen/wiki">Wiki site</a></li></ul><li><a href="https://lists.openid.net/pipermail/openid-specs-authzen/">Mailing list archive</a></li></ul></div></div>