[Openid-specs-authzen] This week's meeting notes

Thu Jun 27 21:25:54 UTC 2024

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-authzen/attachments/20240627/d348b65c/attachment-0001.html>