<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
Uhmm, not the “DADA” book club but the “DADE” book club. We did not review this book...
<div style="display: block;">
<div style="-webkit-user-select: all; -webkit-user-drag: element; display: inline-block;" class="apple-rich-link" draggable="true" role="link" data-url="https://www.goodreads.com/book/show/500612.Dada">
<a style="border-radius:10px;font-family:-apple-system, Helvetica, Arial, sans-serif;display:block;-webkit-user-select:none;width:228px;user-select:none;-webkit-user-modify:read-only;user-modify:read-only;overflow:hidden;text-decoration:none;" class="lp-rich-link" rel="nofollow" href="https://www.goodreads.com/book/show/500612.Dada" dir="ltr" role="button" draggable="false" width="228">
<table style="table-layout:fixed;border-collapse:collapse;width:228px;background-color:#E4E4E4;font-family:-apple-system, Helvetica, Arial, sans-serif;" class="lp-rich-link-emailBaseTable" cellpadding="0" cellspacing="0" border="0" width="228">
<tbody>
<tr>
<td vertical-align="center" align="center"><img style="width:228px;filter:brightness(0.97);height:318px;" width="228" height="318" draggable="false" class="lp-rich-link-mediaImage" alt="500612.jpg" src="cid:B70FD188-204E-4C63-BD4E-5474AF4D5428"></td>
</tr>
<tr>
<td vertical-align="center">
<table bgcolor="#E4E4E4" cellpadding="0" cellspacing="0" width="228" style="table-layout:fixed;font-family:-apple-system, Helvetica, Arial, sans-serif;background-color:rgba(228, 228, 228, 1);-apple-color-filter:initial;" class="lp-rich-link-captionBar">
<tbody>
<tr>
<td style="padding:8px 0px 8px 0px;" class="lp-rich-link-captionBar-textStackItem">
<div style="max-width:100%;margin:0px 16px 0px 16px;overflow:hidden;" class="lp-rich-link-captionBar-textStack">
<div style="word-wrap:break-word;font-weight:500;font-size:12px;overflow:hidden;text-overflow:ellipsis;text-align:left;" class="lp-rich-link-captionBar-textStack-topCaption-leading">
<a rel="nofollow" href="https://www.goodreads.com/book/show/500612.Dada" style="text-decoration: none" draggable="false"><font color="#272727" style="color: rgba(0, 0, 0, 0.847059);">Dada: Art and Anti-Art</font></a></div>
<div style="word-wrap:break-word;font-weight:400;font-size:11px;overflow:hidden;text-overflow:ellipsis;text-align:left;" class="lp-rich-link-captionBar-textStack-bottomCaption-leading">
<a rel="nofollow" href="https://www.goodreads.com/book/show/500612.Dada" style="text-decoration: none" draggable="false"><font color="#808080" style="color: rgba(0, 0, 0, 0.498039);">goodreads.com</font></a></div>
</div>
</td>
</tr>
</tbody>
</table>
</td>
</tr>
</tbody>
</table>
</a></div>
</div>
<br>
<div><br id="lineBreakAtBeginningOfMessage">
<div><span><img alt="VF Logo Light Green Mix (on Dark BG) for email sig.png" src="cid:75CC2157-1404-423A-A687-9358F740A694"></span><br class="Apple-interchange-newline" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">
<br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">
<div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; color: rgb(0, 0, 0); caret-color: rgb(0, 0, 0);">
<span style="color: rgb(71, 100, 88); font-family: SpaceGrotesk-Medium;">Eve Maler, president and founder</span></div>
<div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; color: rgb(0, 0, 0); caret-color: rgb(0, 0, 0);">
<font color="#476458" face="SpaceGrotesk-Medium">Cell and Signal <a href="tel:+1-425-345-6756">+1 (425) 345-6756</a><br>
</font></div>
</div>
<div><br>
<blockquote type="cite">
<div>On Feb 27, 2025, at 10:08 AM, Eve Maler <eve@vennfactory.com> wrote:</div>
<br class="Apple-interchange-newline">
<div>
<div style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
<div>Mark Haine and I held a “DADA Book Club” meeting a couple of weeks ago, and one of the specs that’s on our radar comes from Mark himself: <a href="https://openid.bitbucket.io/ekyc/openid-authority.html">a proposal for a claims extension</a> to support
OpenID Connect Authority use cases (namely, “get authority of natural person over {legal entity | another natural person}”). This is related to a variety of DADE concerns, of course!</div>
<div><br>
</div>
<div>He suggested I share my comments more widely, so I’m sending them here. Happy to discuss in a DADE call if there’s an interest.</div>
<div><br>
</div>
<div>Eve</div>
<div><br>
</div>
<div>====</div>
<div><br>
</div>
<div>
<div>The spec’s subject matter is obviously timely! Hopefully this feedback is coherent.</div>
<div><br>
</div>
<div>(I hope any of my UMA-inflected bits of feedback below aren’t too boring; the UMA work was my main channel for delegation-related work for a long time, and we did a lot of it... I’ll provide those touchpoints where there <i>might possibly</i> be some modern
lesson worth drawing from the previous work.)</div>
<div><br>
</div>
<div>The scope (natural person’s authority over another natural person or a legal entity) seems reasonable, given the OIDC basis. The next step, a legal entity’s authority over one or the other, seems tantalizingly in reach though, and since this spec is just
a claims library rather than a mechanism for assigning or validating authority, I wonder if there’s any actual constraint here in practice.</div>
<div><br>
</div>
<div>The terminology approach in section 1.1 seems overall fair. FWIW, in the old <a href="https://datatracker.ietf.org/doc/html/draft-maler-oauth-umatrust-03">UMA Binding Obligations spec</a> (unfortunately from the UMA1 era, though the “UMA Legal” stuff I’ve
already shared with you is fully updated to UMA2), we carefully distinguished between “parties that have the capacity to take on contractual obligations” vs. hardware, software, etc. There’s been some link rot in that spec, but this is the <a href="https://higherlogicdownload.s3.amazonaws.com/UNIFORMLAWS/21c366b3-b11c-d774-f34d-7901ab76e9a5_file.pdf?X-Amz-Expires=3600&X-Amz-Security-Token=IQoJb3JpZ2luX2VjECsaCXVzLWVhc3QtMSJIMEYCIQDMYdQUwBtVmOMuBzuWBVb9p/n6156JTseDJw9hKmBZvgIhAJQ9Jji12/ZxUREiB8WXzy163sphwO3eU/vaILwAYjyrKrEFCGMQABoMMzgwMzM3MzQwNzA2IgzxVebk3gmbT/OGG20qjgXmGksmvqxuc++ht1mI92V+efnQ4VmK9BSt+ZrQTFECK8GCI7eP4JgeCG1YWfY0F8Rh8jg6dU4hzDBF5MTi/fWbwr5uWLr95Oo19ahrZ+njP4y3NdHr7OAurJZEIU3wTU33DqHjL7SMpGvBqpIpr99+B1FcZPqLLpZK/2MeoYpoVg5XI5oeWbrt2jqrTMOe1znLmaHmgCQK252nDqc4ree8JmJHkZx05LyFi7D4an9DgAilYdbqhN9MCuXPhHpuRnfyFu5thsSa+n0JLVESSZrWbGC6cHbUOcZ/L1LQCNBSh+m4fSVPTC86PhSjQR1d9/o1FbCQ1wPmtc1vc/SLLOVFawma2kX+FUhW3cPDc/fmPLzAdYebepsU3dxsgLcnkYXrj+Wr4kaEF5plW2Y0hqHBeWwwxoCcKlaozSVdkxInvf0Cl019vxpKVGh+syp5tJ7Ai3q7lPqNEuAT8ra6Mg5FEERvTCsKXDqMycVlp0oFdh53vUOBcpz9FPlpofZN6X1x1lq8QpU4pFZbRyffeFhrrTT9XEexB9dhJMRYvS9Lso0eNNMciCF++/BNWSGV4ryHqeLWCcFamuX2APzJqkZxhXLVWR7Z94MGZBPIE1xGXKK6p9beC10T3Is9WtidLqCH9J9+3CG/eI8Vqec7JOyUc6BDi29YV3Lb2daL26RCIFhvtKZ1h9aM0RweZwwMmGdTGFTWRgIxMu6GFhEjaHoLFwprDt7UaIk/Ijpsrxa8+A2sRMFk9BGqdYp1F28r3MeclOmNHGabMrG/bg+z+dJb9LCCeiUgPBT1mAqdR3yZc/SUM1qibl/+maODbKRiT7/BcJjUcuogE2/ITx17dh44hgzroNoS5EyxQXxG43Iw3rL9vQY6sAGko0kQ6LaIP3ZP8jGN40AslVLiEGdgJ1+lyEm0HTm8VcCKhKMS6L4iLGNCvmQVciwGrEDsFQ9BIthiqEHSx4g7PG43DG5cSiVz0+ESq79oXdZZ2Jp0vhYIckvJc+D+nyXUsTrCDO74LxKe+buKZ3HoLgKis+KErQ0lSsu/JJGoAIdCRW9fZgzOcpj5s8UIbLkTNflxC6fAPL04myaOBUlp6We+fIW6raDamdW1eAmy6A==&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=ASIAVRDO7IERMY2K2HM6/20250226/us-east-1/s3/aws4_request&X-Amz-Date=20250226T181633Z&X-Amz-SignedHeaders=host&X-Amz-Signature=80bb620f80fb5aa3382154a1754d2b8483abc2d470a320cc80a4d1d6d8fd2264">UETA
model law</a> referred to. I do think it's worthwhile distinguishing between the persons/entities in your scope and the clients/servers used to apply their relationships. — or at least pondering where trust relationships are implied between them! This could
also be valuable as we fully enter the AI agent era and ask what it means to grant an agent “authority” to do things for us.</div>
<div><br>
</div>
<div>I do have a fundamental question about the definition of “authority”: I think a lot more needs to be said here to pick apart, and/or give examples of, different kinds of authority. The <a href="https://sovrin.org/wp-content/uploads/Guardianship-Whitepaper-V2.0.pdf">Sovrin
paper on guardianship</a> treats a particular kind of authority (and does so thoughtfully), but there are many other kinds. Is the common thread the <a href="https://en.wikipedia.org/wiki/Fiduciary">fiduciary</a> duty (basically, “act in the other entity’s
best interest”)? Or is that only in the case of “consented” or “wished for” authority vs. (let’s call it) adversarial authority, such as a prison guard (or warden or prison itself) has over a prisoner? Does this authority always come with an “on behalf of”/“act_as”
semantic, or not? Your empty headings with authority examples in the back of the spec is suggestive but doesn’t fully answer the question either.</div>
<div><br>
</div>
<div>Regarding the use cases “Get authority of natural person over *” in sections 2.1.1 and 2.1.2: There’s a potential mixing of concerns in the sets of attributes proposed in these sections, each represented by its own bullet list. There are:</div>
<div><br>
</div>
<div>
<ul class="MailOutline">
<li>Two types of entity description attributes (“key attributes relating to the natural person” in several places and “key attributes relating to the legal entity”)</li><li>Relationship description attributes (“nature of the relationship” in multiple places)</li><li>Contextual attributes about the state change representing the establishment of the relationship (“how the authority was granted” in multiple places)</li><li>What could be seen as policy-oriented attributes about the authority that may govern further relationship state changes or changes of specific permissions (“any limitations of the authority”) — perhaps this is two categories?</li></ul>
<div><br>
</div>
</div>
<div>I feel like all this would be clearer if <i>relationships and their state changes</i> were acknowledged as an underlying mechanism. As well, with such a framework, the user stories could be modularized so that sets of attributes don’t get listed twice.
(And you can see why I’m tempted to add “legal entity’s authority” to the scope — it’s a hop, skip, and jump away, and maybe a non-OIDC binding of such claims could support that use case! E.g., UMA might support it...)</div>
<div><br>
</div>
<div>Perhaps it’s worth observing that you haven't explicitly put <i>non-authority</i> relationships out of scope for the spec, and in fact the language in your user stories — “…I require specific attributes about <i>the relationship</i>…” — hints at being
able to handle non-authority relationships just as easily as authority ones.</div>
<div><br>
</div>
<div>My suspicion is that the “on behalf of” semantic is on a separate axis from other relationship/authority descriptors. It impacts how you audit online activity and how you implement various front-end (e.g., remote desktop control) types of considerations.</div>
<div><br>
</div>
<div>Finally, there was an <a href="https://www.rsaconference.com/library/presentation/usa/2017/designing-a-new-consent-strategy-for-digital-transformation">RSA talk I delivered in 2017</a> (there’s video and you can download the <a href="https://static.rainfocus.com/rsa/presentations/USA17/2017_USA17_idy-r03_01_designing-a-new-consent-strategy-for-digital-transformation.pdf">slides</a>)
that talked about “directed consent” (basically, delegation — obviously I had UMA in mind first and foremost, though as you’ll see in the preso, it doesn’t cover 100% of the needs). It may be helpful as you build out what I called “policy-oriented attributes”
above. The “controls” in the screenshot below are what I’m thinking of for ways to configure these types of permission grants:</div>
<div><br>
</div>
<div><span id="cid:A0FA72D0-9926-42C2-8C30-9CE8E4CEE53B"><PastedGraphic-1.png></span></div>
<div><br>
</div>
<div><b>Scope</b> is, well, scope of actions permitted. <b>Grantee</b> is the one who’s getting authority (to coin a phrase!). <b>Environment</b> is any other contextual attributes that govern establishing the relationship (could be phase of the moon, or expiration
timing, or…). <b>Usage</b> is like “purpose of consent” requirements in privacy/consent laws. <b>Downstream</b> is whether the grantee has transitive rights to give someone else authority. These are all pretty orthogonal to each other.</div>
</div>
<br>
<div><span><span id="cid:75CC2157-1404-423A-A687-9358F740A694"><VF Logo Light Green Mix (on Dark BG) for email sig.png></span></span><br class="Apple-interchange-newline" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; caret-color: rgb(0, 0, 0);">
<br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; caret-color: rgb(0, 0, 0);">
<div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; caret-color: rgb(0, 0, 0);">
<span style="color: rgb(71, 100, 88); font-family: SpaceGrotesk-Medium;">Eve Maler, president and founder</span></div>
<div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; caret-color: rgb(0, 0, 0);">
<font color="#476458" face="SpaceGrotesk-Medium">Cell and Signal <a href="tel:+1-425-345-6756">+1 (425) 345-6756</a><br>
</font></div>
</div>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</body>
</html>