[Openid-specs-authzen] This week's meeting notes
David Brossard
david.brossard at gmail.com
Thu Jun 27 19:22:55 UTC 2024
Dear all,
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.
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?).
We also reviewed the boxcarring proposal and we also have consensus. Full
notes below.
*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)
*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
We have consensus on the overall spec
Let's aim for an interop by IIW or Authenticate.
*Conclusion*
And just as a reminder, here are the useful links for our WG:
- WG homepage <https://openid.net/wg/authzen/>
- HackMD site <https://hackmd.io/@oidf-wg-authzen>
- Meeting notes
<https://hackmd.io/@oidf-wg-authzen?tags=%5B%22meeting-notes%22%5D>
- Github repository <https://github.com/openid/authzen>
- The latest spec
<https://github.com/openid/authzen/blob/main/api/authorization-api-1_0.md>
(MD
doc) and the published version <https://openid.github.io/authzen/>
- Wiki site <https://github.com/openid/authzen/wiki>
- Mailing list archive
<https://lists.openid.net/pipermail/openid-specs-authzen/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-authzen/attachments/20240627/787e5833/attachment.html>
More information about the Openid-specs-authzen
mailing list