<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.gmailsignatureprefix
{mso-style-name:gmail_signature_prefix;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">I simply wanted to +1 Eve’s suggestion to pull in more stakeholder voices if application vendors are expected to do work for any new interoperability standard, and to offer AWS’s perspective as one application provider. If other vendors
give similar feedback as AWS, that’s worth taking into account.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">From: </span></b><span style="font-size:12.0pt;color:black">Alex Babeanu <alex@3edges.com><br>
<b>Date: </b>Monday, December 18, 2023 at 11:36 AM<br>
<b>To: </b>AuthZEN Working Group List <openid-specs-authzen@lists.openid.net><br>
<b>Cc: </b>"McAdams, Darin" <darinm@amazon.com><br>
<b>Subject: </b>RE: [EXTERNAL] [Openid-specs-authzen] Initial thoughts on interop scenario planning<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<table class="MsoNormalTable" border="0" cellspacing="0" cellpadding="0" style="border-collapse:collapse">
<tbody>
<tr style="height:15.25pt">
<td width="1123" valign="top" style="width:842.35pt;border:solid #ED7D31 1.5pt;padding:0in 5.4pt 0in 5.4pt;height:15.25pt">
<p><strong><span style="font-family:"Calibri",sans-serif;color:black;background:#FFFF99">CAUTION</span></strong><span style="color:black;background:#FFFF99">: This email originated from outside of the organization. Do not click links or open attachments unless
you can confirm the sender and know the content is safe.</span><o:p></o:p></p>
</td>
</tr>
</tbody>
</table>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">Hi Darin, <o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Thanks for your input. This is interesting... I read it a bit like: "what we're doing now is not useful because nobody will use it". Did I misread? Additionally you propose focusing only on the side-car pattern, which is only 1 of the patterns
we identify in the Patterns doc ("PAD" in Eve's note). You also state you'd see some value in having a common way to express access policies... and you suggest Cedar.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I personally don't agree with your statements...<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">First, there's been a standard way to represent policies since 2003 (XACML). Not sure we want to revisit this here. There are also many other ways to represent policies, and I think we purposely wanted to stay away from this can of worms
(see rego, Graphs, IDQL, ALFA,OSO,etc).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Secondly, you see things from an AWS lens, which is fine and great input given your size and the volumes you tackle, but a lot of organizations out there have hybrid deployments, their own data centers, or simply don't run on AWS. And various
things in between, which is why discussing patterns is important. See for example the discussion about the "clash" between the P*P (to quote Eve again) and OAuth* world views, which are broader than just policy representation or just focusing on 1 pattern
(side-car). <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Given these, let's see if there's a way to build some interoperability between various vendors, one that could cater to most (or all) defined patterns, and truly help organizations implement proper authorization.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">My $0.02. And thanks again for your input!<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Cheers,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">./\lex.<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Fri, Dec 15, 2023 at 5:27 PM McAdams, Darin via Openid-specs-authzen <<a href="mailto:openid-specs-authzen@lists.openid.net">openid-specs-authzen@lists.openid.net</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt">(My contribution agreement was completed this morning, so I can contribute at last.)<br>
<br>
Eve, thank you for the write-up. I wanted to +1 the callout for more input from non-authz vendor partners.
<br>
<br>
In this vein, I can share a brief perspective from AWS (wearing the hat of a web service provider). Many of the interesting proposals under discussion so far are not necessarily easy to align with the priorities we’re hearing from our customers, or that would
be pragmatically implementable. To give an example, we would be unlikely to make a callout to an external authorization endpoint from within our services for various operational reasons. If we flip that around and consider an approach where others upload authorization
rules to AWS, we do have several partners who do so already. While a standard representation of a policy might be nice-to-have for this audience (and we’re not adverse to that), I’m not sure if there’s critical mass amongst other application vendors to implement
such standardization. <br>
<br>
One approach that I do see gaining traction is in exporting rules from various online services and normalizing them to a common representation for analysis and auditing purposes. For example, one party built a translation layer from AWS IAM policies into Cedar
policies, which they found more efficient to analyze. However, I’m not sure if there’s an interop story, except to the degree that it would be nice if application providers natively exposed policies in a standard representation. But, that circles us back to
the question of why providers would be motived to do this work.<br>
<br>
If there’s an area in need of interop, the one I’ve personally noted has been between open-source components. For example, solutions such as Envoy and Kubernetes both support authorization plugins via a sidecar. However, they each define different plugin mechanisms,
leading authorization toolchains to build adapters for each one. An example is the OPA plugin for Envoy. (<a href="https://www.openpolicyagent.org/docs/latest/envoy-introduction/" target="_blank">https://www.openpolicyagent.org/docs/latest/envoy-introduction/</a>)<br>
<br>
This raises a question of whether it’s possible to “flip the script” and define a standard authorization API for sidecars that the next generation of Envoy-like solutions would conform to. I haven’t had the time to deep-dive into whether sufficient commonalities
exist across these toolchains to make such a thing practical, but it is an area where we’d have interest in exploring further.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">Openid-specs-authzen <<a href="mailto:openid-specs-authzen-bounces@lists.openid.net" target="_blank">openid-specs-authzen-bounces@lists.openid.net</a>> on behalf of eve--- via Openid-specs-authzen <<a href="mailto:openid-specs-authzen@lists.openid.net" target="_blank">openid-specs-authzen@lists.openid.net</a>><br>
<b>Reply-To: </b>AuthZEN Working Group List <<a href="mailto:openid-specs-authzen@lists.openid.net" target="_blank">openid-specs-authzen@lists.openid.net</a>><br>
<b>Date: </b>Friday, December 15, 2023 at 3:04 PM<br>
<b>To: </b>David Brossard via Openid-specs-authzen <<a href="mailto:openid-specs-authzen@lists.openid.net" target="_blank">openid-specs-authzen@lists.openid.net</a>><br>
<b>Cc: </b>"<a href="mailto:eve@xmlgrrl.com" target="_blank">eve@xmlgrrl.com</a>" <<a href="mailto:eve@xmlgrrl.com" target="_blank">eve@xmlgrrl.com</a>><br>
<b>Subject: </b>[EXTERNAL] [Openid-specs-authzen] Initial thoughts on interop scenario planning</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<table class="MsoNormalTable" border="0" cellspacing="0" cellpadding="0" style="border-collapse:collapse">
<tbody>
<tr style="height:15.25pt">
<td width="1123" valign="top" style="width:842.35pt;border:solid #ED7D31 1.5pt;padding:0in 5.4pt 0in 5.4pt;height:15.25pt">
<p><strong><span style="font-family:"Calibri",sans-serif;color:black;background:#FFFF99">CAUTION</span></strong><span style="color:black;background:#FFFF99">: This email originated from outside of the organization. Do not click links or open attachments unless
you can confirm the sender and know the content is safe.</span><o:p></o:p></p>
</td>
</tr>
</tbody>
</table>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I reviewed all of the extant materials, including historical ones, and put together a <a href="https://hackmd.io/4IaZmp2lSHaWXphriXiVOg" target="_blank">"meta-interop-scenario"
document</a> in HackMD. It proposes a way forward. <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I also did a very crude sketch to get some observations out of my head – I didn’t see a way to embed it, but it’s attached here. This diagram is helping me to articulate some of
the questions I have about standards prioritization, design principles, and community engagement. For example, how important are the various “Clarify Access” scenarios vs. basic “Enforce Access” ones? Is there a way to categorize, and maybe prioritize, coverage
of by-value inputs into policy decision requests? When SAML decided to solve only IdP-initiated SSO in its V1, it had a useful MVP that gave us runway to get to V2 and start doing SP-initiated SSO; what’s our most powerful MVP?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">The API spec doc and the PDP-PEP Use Cases doc align with a “protocol” view of the world, I believe, and the “PAD” (design patterns) doc adds real-world deployment considerations.
There is some overlap; PAD includes both “architecture” and “model” patterns, and architecture somewhat relates to protocol design. Note that the “Alternate” block on the right is trying to hint at ways OAuth is fundamentally different, though you could see
how to make its version of such a diagram consonant with this one.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">My diagram blocks are meant to be functional and descriptive and are not prescriptive in any way! If you think this is on the way to being helpful but want to revise, feel free.
If it’s wrong-headed, let me know. :)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Have a great weekend, all!<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><img border="0" width="1280" height="894" style="width:13.3333in;height:9.3125in" id="m_-2476998118606205807_x005f_x0000_i1025" src="cid:image001.jpg@01DA31C0.63987A70"><o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><br>
Eve Maler | cell and Signal +1 425.345.6756<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
</div>
</div>
</div>
<p class="MsoNormal">-- <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" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-authzen</a><o:p></o:p></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><br clear="all">
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><span class="gmailsignatureprefix">-- </span><o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><a href="https://hihello.me/p/cda689b1-0378-4b9c-88cf-33a9bc8ef0c5" target="_blank"><span style="color:windowtext;text-decoration:none"><span style="color:blue;border:solid windowtext 1.0pt;padding:0in"><img border="0" width="360" height="360" style="width:3.75in;height:3.75in" id="_x0000_i1025" src="cid:~WRD0000.jpg" alt="Image removed by sender. This is Alexandre Babeanu's card. Their email is alex@3edges.com. Their phone number is +1 604 728 8130."></span></span></a><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><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.<o:p></o:p></p>
</div>
</div>
</body>
</html>