<div dir="ltr">Thanks David !<br><div><br></div><div>One extra note on the Distributed ID use-case that Patrick brought forward:<br><br>> <font color="#0b5394">"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."</font><br><br>This is a valid use-case. The W3C Verifiable Credentials data model v2.0 (<a href="https://www.w3.org/TR/vc-data-model-2.0/#identifiers">https://www.w3.org/TR/vc-data-model-2.0/#identifiers</a>) states:</div><div><br></div><div>"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.".</div><div><br></div><div>So even though the spec. requires a VC to have a `<font face="monospace">credentialSubject</font>` property, that property itself doesn't have to have an id. </div><div>Here we thus have 2 choices (afaik):</div><div><br></div><div>1. State that VCs with no `<font face="monospace">id</font>` 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).</div><div><br></div><div>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".</div><div><br></div><div>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 ...</div><div><br></div><div>Cheers,</div><div><br></div><div>./\.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 27, 2024 at 12:23 PM David Brossard via Openid-specs-authzen <<a href="mailto:openid-specs-authzen@lists.openid.net">openid-specs-authzen@lists.openid.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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" target="_blank">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/" target="_blank">WG homepage</a></li><li><a href="https://hackmd.io/@oidf-wg-authzen" target="_blank">HackMD site</a></li><ul><li><a href="https://hackmd.io/@oidf-wg-authzen?tags=%5B%22meeting-notes%22%5D" target="_blank">Meeting notes</a></li></ul><li><a href="https://github.com/openid/authzen" target="_blank">Github repository</a></li><ul><li>The <a href="https://github.com/openid/authzen/blob/main/api/authorization-api-1_0.md" target="_blank">latest spec</a> (MD doc) and the <a href="https://openid.github.io/authzen/" target="_blank">published version</a></li><li><a href="https://github.com/openid/authzen/wiki" target="_blank">Wiki site</a></li></ul><li><a href="https://lists.openid.net/pipermail/openid-specs-authzen/" target="_blank">Mailing list archive</a></li></ul></div></div>
-- <br>
Openid-specs-authzen mailing list<br>
<a href="mailto:Openid-specs-authzen@lists.openid.net" target="_blank">Openid-specs-authzen@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-authzen" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-authzen</a><br>
</blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><a href="https://hihello.me/p/cda689b1-0378-4b9c-88cf-33a9bc8ef0c5" rel="noopener" style="display:inline-block" target="_blank"><img alt="This is Alexandre Babeanu's card. Their email is alex@3edges.com. Their phone number is +1 604 728 8130." src="https://cdn.hihello.me/cards/cda689b1-0378-4b9c-88cf-33a9bc8ef0c5/signature_logo.png?generated=1653502150176" width="360" style="display: inline-block; min-height: 100px;"></a><br></div></div>

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