[Openid-specs-authzen] This week's meeting notes
Omri Gazitt
omri at aserto.com
Fri Jun 28 00:48:25 UTC 2024
I agree with Alex that this seems like an edge case - in the DID world as I
understand it, the decision has typically already been made by the
authentication system.
On Thu, Jun 27, 2024 at 2:26 PM Alex Babeanu via Openid-specs-authzen <
openid-specs-authzen at lists.openid.net> wrote:
> Thanks David !
>
> One extra note on the Distributed ID use-case that Patrick brought forward:
>
> > "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."
>
> This is a valid use-case. The W3C Verifiable Credentials data model v2.0 (
> https://www.w3.org/TR/vc-data-model-2.0/#identifiers) states:
>
> "Where privacy is a strong consideration, it is permissible to omit the id
> property. Some use cases do not need, or explicitly need to omit, the id
> property." (...) "The id property is OPTIONAL.".
>
> So even though the spec. requires a VC to have a `credentialSubject`
> property, that property itself doesn't have to have an id.
> Here we thus have 2 choices (afaik):
>
> 1. State that VCs with no `id` property are out of scope of AuthZen
> (which I think would make sense in most cases, like in this Age
> verification case where a PDP is not necessary: the VC validation by the
> issuer itself is sufficient to grant access).
>
> 2. We assume it is possible to use generic placeholder Subject entities
> for anonymous claims, in which case the AuthZ question becomes: can anyone
> (or anything) with this VC do action A on Resource R. In essence, this is
> making the Subject ID a) optional, or b) * (star) as in "substitute with
> any ID, doesn't change the rule".
>
> My take is that this is really an edge case where a PDP wouldn't really be
> required. I'd vote to scope it out for now and see if there's requests for
> it for V2 of the AuthZen spec. My $0.02 ...
>
> Cheers,
>
> ./\.
>
> On Thu, Jun 27, 2024 at 12:23 PM David Brossard via Openid-specs-authzen <
> openid-specs-authzen at lists.openid.net> wrote:
>
>> 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/>
>>
>> --
>> Openid-specs-authzen mailing list
>> Openid-specs-authzen at lists.openid.net
>> https://lists.openid.net/mailman/listinfo/openid-specs-authzen
>>
>
>
> --
> [image: This is Alexandre Babeanu's card. Their email is alex at 3edges.com.
> Their phone number is +1 604 728 8130.]
> <https://hihello.me/p/cda689b1-0378-4b9c-88cf-33a9bc8ef0c5>
>
> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments
> hereto, is for the sole use of the intended recipient(s) and may contain
> confidential and/or proprietary information.
> --
> Openid-specs-authzen mailing list
> Openid-specs-authzen at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-authzen
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-authzen/attachments/20240627/255cd9c2/attachment.html>
More information about the Openid-specs-authzen
mailing list