<div dir="ltr"><div dir="ltr"><div dir="ltr">Hey Andrii</div><div dir="ltr"><br></div><div dir="ltr">Thanks for the feedback and question!<br><div><br></div><div>A client can be making multiple requests of a server at the same time. This happens all the time in web servers as the client is fetching CSS and JS files references in an HTML page. </div><div><br></div><div>In HTTP/1.1 those will be over separate TCP/IP and TLS sessions. In HTTP/2 the requests use the same TCP/IP and TLS session. As SES is HTTP/1/1 only - if the client wants to make another request (send an additional OP Command) a new session would be created. </div><div><br></div><div>You do bring up an area where we should provide additional guidance to implementers when an account status is being changed mid audit as the response may or may not include the updated status. </div><div><br></div><div>I can think of three approaches: </div><div><br></div><div><div>1. The OP sends the new OP command, discards the audit_tenant response when it finishes, and then issues a new audit_tenant command. Note that the OP should wait for the first response to complete before issuing a new audit_tenant command. Multiple outstanding SSE responses could DOS an RP.</div><div><br></div></div><div>2. the OP terminates the session receiving the audit_tenant response, sends the new OP command, and then issues a new audit_tenant command. </div><div><br></div><div>3. the RP sends an additional event in the aud_tenant response for any accounts where the status changed while sending the response.</div><div><br></div><div>I think given a choice on which party takes on a complexity burden, the OP should take it. Given that, I think (2) is the preferred approach.</div><div><br></div><div>A related issue that could be a problem is during initial configuration of an RP where an OP needs to send an activate command for a very large number of accounts. This could also DOS an RP. I have heard tales of IdPs overwhelming RPs with SCIM. Perhaps we add an optional max simultaneous connections parameter to the metadata response, with a default value of 1?</div><div><br></div><div>Am I missing something? What do you think?</div><div><br></div><div>/Dick</div><div><div><br></div></div></div></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Sun, Feb 16, 2025 at 1:01 AM Andrii Deinega <<a href="mailto:andrii.deinega@gmail.com">andrii.deinega@gmail.com</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"><div dir="ltr"><div style="margin:0px;padding:0px;clear:both;overflow:visible;direction:ltr;color:rgb(0,0,0);font-family:"Segoe UI","Segoe UI Web",Arial,Verdana,sans-serif;font-size:12px"><p lang="EN-US" style="margin:0px;padding:0px;vertical-align:baseline;font-kerning:none;background-color:transparent;color:windowtext"><span lang="EN-US" style="margin:0px;padding:0px;font-size:11pt;line-height:18.3458px;font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,sans-serif;font-variant-ligatures:none"><span style="margin:0px;padding:0px">Hi Dick,</span></span></p><p lang="EN-US" style="margin:0px;padding:0px;vertical-align:baseline;font-kerning:none;background-color:transparent;color:windowtext"><span lang="EN-US" style="margin:0px;padding:0px;font-size:11pt;line-height:18.3458px;font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,sans-serif;font-variant-ligatures:none"><span style="margin:0px;padding:0px"><br></span></span></p><p lang="EN-US" style="margin:0px;padding:0px;vertical-align:baseline;font-kerning:none;background-color:transparent;color:windowtext"><span lang="EN-US" style="margin:0px;padding:0px;font-size:11pt;line-height:18.3458px;font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,sans-serif;font-variant-ligatures:none"><span style="margin:0px;padding:0px">I love this idea as it simplifies a ton of things. </span><span style="margin:0px;padding:0px">S</span><span style="margin:0px;padding:0px">tarting from the first one - having Shared Signals (RISC) and SCIM are not necessary to meet most of my requirements (I am interested in changing account statuses and account deprovisioning). </span><span style="margin:0px;padding:0px">Yes</span><span style="margin:0px;padding:0px">...</span><span style="margin:0px;padding:0px"> There is a huge overlap between OP Commands and these too, but I am not going to touch on this topic.</span></span><span style="margin:0px;padding:0px;font-size:11pt;line-height:18.3458px;font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,sans-serif"> </span></p></div><div style="margin:0px;padding:0px;clear:both;overflow:visible;direction:ltr;color:rgb(0,0,0);font-family:"Segoe UI","Segoe UI Web",Arial,Verdana,sans-serif;font-size:12px"><p lang="EN-US" style="margin:0px;padding:0px;vertical-align:baseline;font-kerning:none;background-color:transparent;color:windowtext"><span lang="EN-US" style="margin:0px;padding:0px;font-size:11pt;line-height:18.3458px;font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,sans-serif;font-variant-ligatures:none"><span style="margin:0px;padding:0px"> </span></span><span style="margin:0px;padding:0px;font-size:11pt;line-height:18.3458px;font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,sans-serif"> </span></p></div><div style="margin:0px;padding:0px;clear:both;overflow:visible;direction:ltr;color:rgb(0,0,0);font-family:"Segoe UI","Segoe UI Web",Arial,Verdana,sans-serif;font-size:12px"><p lang="EN-US" style="margin:0px;padding:0px;vertical-align:baseline;font-kerning:none;background-color:transparent;color:windowtext"><span lang="EN-US" style="margin:0px;padding:0px;font-size:11pt;line-height:18.3458px;font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,sans-serif;font-variant-ligatures:none"><span style="margin:0px;padding:0px">One thing that </span><span style="margin:0px;padding:0px">is not particularly </span><span style="margin:0px;padding:0px">clear for me is your concept of </span><span style="margin:0px;padding:0px">streaming</span><span style="margin:0px;padding:0px"> requests and responses from an OP to an RP using SSE (Server-Sent Event)</span><span style="margin:0px;padding:0px">.</span><span style="margin:0px;padding:0px"> To the best of my knowledge, o</span><span style="margin:0px;padding:0px">nce </span><span style="margin:0px;padding:0px">an HTTP client starts a</span><span style="margin:0px;padding:0px">n</span><span style="margin:0px;padding:0px"> SSE </span><span style="margin:0px;padding:0px">connection</span><span style="margin:0px;padding:0px"> and sends the very first OP Command to </span><span style="margin:0px;padding:0px">the</span><span style="margin:0px;padding:0px"> server, it </span><span style="margin:0px;padding:0px">cannot</span><span style="margin:0px;padding:0px"> send any </span><span style="margin:0px;padding:0px">additional</span><span style="margin:0px;padding:0px"> HTTP requests </span><span style="margin:0px;padding:0px">(or <span style="margin:0px;padding:0px">OP </span><span style="margin:0px;padding:0px">Commands in our case</span>)</span><span style="margin:0px;padding:0px">.</span><span style="margin:0px;padding:0px"> </span><span style="margin:0px;padding:0px">I</span><span style="margin:0px;padding:0px">t can only listen </span><span style="margin:0px;padding:0px">for </span><span style="margin:0px;padding:0px">responses from</span><span style="margin:0px;padding:0px"> or </span><span style="margin:0px;padding:0px">close </span><span style="margin:0px;padding:0px">the connection. How </span><span style="margin:0px;padding:0px">will</span><span style="margin:0px;padding:0px"> </span><span style="margin:0px;padding:0px">this </span><span style="margin:0px;padding:0px">work unless you allow sending multiple OP Commands (we know that's easily possible with x-www-fo</span><span style="margin:0px;padding:0px">rm-</span><span style="margin:0px;padding:0px;background-position:0px 100%;background-repeat:repeat-x;border-bottom:1px solid transparent">urlencoded</span><span style="margin:0px;padding:0px">)?</span></span><span style="margin:0px;padding:0px;font-size:11pt;line-height:18.3458px;font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,sans-serif"> </span></p><p lang="EN-US" style="margin:0px;padding:0px;vertical-align:baseline;font-kerning:none;background-color:transparent;color:windowtext"><span style="margin:0px;padding:0px;font-size:11pt;line-height:18.3458px;font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,sans-serif"><br></span></p><p lang="EN-US" style="margin:0px;padding:0px;vertical-align:baseline;font-kerning:none;background-color:transparent;color:windowtext"><span style="margin:0px;padding:0px;font-size:11pt;line-height:18.3458px;font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,sans-serif">All the best,</span></p><p lang="EN-US" style="margin:0px;padding:0px;vertical-align:baseline;font-kerning:none;background-color:transparent;color:windowtext"><span style="margin:0px;padding:0px;font-size:11pt;line-height:18.3458px;font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,sans-serif">Andrii</span></p><p lang="EN-US" style="margin:0px;padding:0px;vertical-align:baseline;font-kerning:none;background-color:transparent;color:windowtext"><br></p></div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 13, 2025 at 6:57 AM Brian Campbell via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@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"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Feb 1, 2025 at 4:20 AM Dick Hardt <<a href="mailto:dick.hardt@gmail.com" target="_blank">dick.hardt@gmail.com</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"><div dir="ltr">Brian<div><br></div><div>Let me summarize what I think your "not positive feedback" is:<br><br></div><div>You don't think related specs "hit the mark" -- but you don't want another spec because it will "crowd the landscape and confuse everyone". <br></div><div><br></div><div>Did I get that right? </div></div></div></blockquote><div><br></div><div>As a seemingly manipulative oversimplification and mischaracterization, I suppose so. Or maybe just a misunderstanding. But I guess the answer is actually no, you did not get it right. <br></div><div> </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"><div dir="ltr"><div><br></div><div>What is your proposal for how to "hit the mark"?  Or are you suggesting we should not try to "hit the mark"?</div></div></div></blockquote><div><br></div><div>The value of not doing some things is very underappreciated.<br></div><div> </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"><div dir="ltr"><div><br></div><div><div>Do you have any critiques of the draft itself? </div></div></div></div></blockquote><div><br></div><div>I did read an earlier draft of the draft over the holidays but found the prospect of articulating feedback rather daunting. Which is me struggling for a polite way to say that I found it to be not very good, concerningly so in some areas. </div><div><br></div><div>Remember also, of course, that there's absolutely no obligation on me (or anyone) to volunteer my time and expertise towards this. <br></div><div><br></div><div> </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"><div dir="ltr"><div><div><br></div><div>/Dick</div><div><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 31, 2025 at 9:34 PM Brian Campbell <<a href="mailto:bcampbell@pingidentity.com" target="_blank">bcampbell@pingidentity.com</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"><div>During the WG call yesterday there was some discussion of this OpenID Provider Commands proposal and I was asked to put a few sentences about my feedback on the mailing list so that<br>it'd be on record. Aaron did a nice job with the thankless job of minute taking in that meeting <a href="https://lists.openid.net/pipermail/openid-specs-ab/2025-January/010577.html" target="_blank">https://lists.openid.net/pipermail/openid-specs-ab/2025-January/010577.html</a> and his parahpahsing of my words and the conversations seems totally sufficient for that purpose. So I'm copying relevant parts here:<br></div><div><br></div><div><br>Dick: ...  In discussions with people I've gotten a fair amount of positive<br>feedback.<br>...<br>Brian: You've also had not positive feedback to the idea. I have mixed<br>feelings about this, I don't think that SCIM or SCIM Events or RISC/CAEP<br>really hit the mark, so I have some sympathy for trying to produce the same<br>results in a simpler way. But I am similarly concerned that this is yet<br>another attempt at the same problem that will further crowd the landscape<br>and confuse everyone. This is both a note of support and pushback. Logout<br>is another area that has failed us all.<br><br>Dick: My understanding of your feedback was worried about there being<br>another protocol. The SAML people also told us we didn't need OpenID<br>Connect, but it's widely deployed because it solves things simpler.<br><br>Brian: I don't think the equivalency between SAML and OpenID Connect. That<br>said, I'd love to see something people actually use instead of the ongoing<br>hype about all the problems that RISC/CAEP will solve for us.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 15, 2025 at 5:30 AM Dick Hardt via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@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"><div dir="ltr">Hello WG (and chairs)<br><br>Karl (cc'ed) and I have been working on a new protocol that complements OpenID Connect for an OP to centrally manage account lifecycles at RPs. We have also defined an Unauthorize Command which undoes whatever actions an RP did in a previous OpenID Connect login -- useful if an OP suspects an account or device had been compromised -- instructs an RP to "kill all the sessions and tokens"<div><br></div><div>We contribute the IP in the attached HTML and Markdown files to the OpenID Foundation per the Foundations IPR. </div><div><br></div><div>We have a FAQ as a note at the top, that I am including below for your convenience.</div><div><br></div><div>We hope this work is of interest to others in the WG, and that together we can improve the security posture of implementers.</div><div><br></div><div>/Dick & Karl<br><br><p id="m_-7044449213207251389m_3873057257117440426m_-2112666820615236994m_-5971293250114633603m_-7423541532824848064m_1354848426895667131m_448710232303741924m_2097881123700523078m_-3528561374763180747m_-3250992085103549817gmail-section-1-1.2" style="padding:0px;margin:0px 0px 1em;color:rgb(17,17,17);font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px"><b>1. How does SCIM compare to OpenID Provider (OP) Commands?</b><a href="#m_-7044449213207251389_m_3873057257117440426_m_-2112666820615236994_m_-5971293250114633603_m_-7423541532824848064_m_1354848426895667131_m_448710232303741924_m_2097881123700523078_m_-3528561374763180747_m_-3250992085103549817_section-1-1.2" style="text-decoration-line:none;color:rgb(102,102,102)"></a></p><p id="m_-7044449213207251389m_3873057257117440426m_-2112666820615236994m_-5971293250114633603m_-7423541532824848064m_1354848426895667131m_448710232303741924m_2097881123700523078m_-3528561374763180747m_-3250992085103549817gmail-section-1-1.3" style="padding:0px;margin:0px 0px 1em;color:rgb(17,17,17);font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px">The SCIM protocol is a general purpose protocol for a client to manage resources at a server. When the SCIM protocol is used between an IdP and an RP, the schema is defined by the RP. The resources managed are in the context of the RP Tenant in a multi-tenant RP. Any extensions to the schema are defined by the RP. This provided an interoperable protocol to manage RP resources. OpenID Provider Commands are an extension of a user Account created by OpenID Connect. It uses the same identity Claims that the OP issues for the user. It uses the same token Claims, and is verified the same way. OpenID Provider Commands are issued in the context of the OP Tenant in a multi-tenant OP.<a href="#m_-7044449213207251389_m_3873057257117440426_m_-2112666820615236994_m_-5971293250114633603_m_-7423541532824848064_m_1354848426895667131_m_448710232303741924_m_2097881123700523078_m_-3528561374763180747_m_-3250992085103549817_section-1-1.3" style="text-decoration-line:none;color:rgb(102,102,102)"></a></p><p id="m_-7044449213207251389m_3873057257117440426m_-2112666820615236994m_-5971293250114633603m_-7423541532824848064m_1354848426895667131m_448710232303741924m_2097881123700523078m_-3528561374763180747m_-3250992085103549817gmail-section-1-1.4" style="padding:0px;margin:0px 0px 1em;color:rgb(17,17,17);font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px"><b>2. How do Shared Signals / RISC compare to OpenID Provider Commands?</b><a href="#m_-7044449213207251389_m_3873057257117440426_m_-2112666820615236994_m_-5971293250114633603_m_-7423541532824848064_m_1354848426895667131_m_448710232303741924_m_2097881123700523078_m_-3528561374763180747_m_-3250992085103549817_section-1-1.4" style="text-decoration-line:none;color:rgb(102,102,102)"></a></p><p id="m_-7044449213207251389m_3873057257117440426m_-2112666820615236994m_-5971293250114633603m_-7423541532824848064m_1354848426895667131m_448710232303741924m_2097881123700523078m_-3528561374763180747m_-3250992085103549817gmail-section-1-1.5" style="padding:0px;margin:0px 0px 1em;color:rgb(17,17,17);font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px">Shared Signals and RISC are events that one party is sharing with another party. The actions a receiving party takes upon receiving a signal are intentionally not defined. The actions taken by the RP when receiving an OpenID Provider Command is specified. This gives an OP control over the Account at the RP.<a href="#m_-7044449213207251389_m_3873057257117440426_m_-2112666820615236994_m_-5971293250114633603_m_-7423541532824848064_m_1354848426895667131_m_448710232303741924_m_2097881123700523078_m_-3528561374763180747_m_-3250992085103549817_section-1-1.5" style="text-decoration-line:none;color:rgb(102,102,102)"></a></p><p id="m_-7044449213207251389m_3873057257117440426m_-2112666820615236994m_-5971293250114633603m_-7423541532824848064m_1354848426895667131m_448710232303741924m_2097881123700523078m_-3528561374763180747m_-3250992085103549817gmail-section-1-1.6" style="padding:0px;margin:0px 0px 1em;color:rgb(17,17,17);font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px"><b>3. Are OpenID Provider Commands a replacement for SCIM, Shared Signals, or RISC?</b><a href="#m_-7044449213207251389_m_3873057257117440426_m_-2112666820615236994_m_-5971293250114633603_m_-7423541532824848064_m_1354848426895667131_m_448710232303741924_m_2097881123700523078_m_-3528561374763180747_m_-3250992085103549817_section-1-1.6" style="text-decoration-line:none;color:rgb(102,102,102)"></a></p><p id="m_-7044449213207251389m_3873057257117440426m_-2112666820615236994m_-5971293250114633603m_-7423541532824848064m_1354848426895667131m_448710232303741924m_2097881123700523078m_-3528561374763180747m_-3250992085103549817gmail-section-1-1.7" style="padding:0px;margin:0px 0px 1em;color:rgb(17,17,17);font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px">No. These standards are deployed by organizations that have complex requirements, and these standards meet there needs. Most OP / RPs do not deploy any of these standards, as the implementation complexity is not warranted. OpenID Provider Commands are designed to build on OpenID Connect, allowing RPs using OpenID Connect an easy path to offer OPs a standard API for security and lifecycle operations.<a href="#m_-7044449213207251389_m_3873057257117440426_m_-2112666820615236994_m_-5971293250114633603_m_-7423541532824848064_m_1354848426895667131_m_448710232303741924_m_2097881123700523078_m_-3528561374763180747_m_-3250992085103549817_section-1-1.7" style="text-decoration-line:none;color:rgb(102,102,102)"></a></p><p id="m_-7044449213207251389m_3873057257117440426m_-2112666820615236994m_-5971293250114633603m_-7423541532824848064m_1354848426895667131m_448710232303741924m_2097881123700523078m_-3528561374763180747m_-3250992085103549817gmail-section-1-1.8" style="padding:0px;margin:0px 0px 1em;color:rgb(17,17,17);font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px"><b>4. Why are there only groups? Why not roles and entitlements?</b><a href="#m_-7044449213207251389_m_3873057257117440426_m_-2112666820615236994_m_-5971293250114633603_m_-7423541532824848064_m_1354848426895667131_m_448710232303741924_m_2097881123700523078_m_-3528561374763180747_m_-3250992085103549817_section-1-1.8" style="text-decoration-line:none;color:rgb(102,102,102)"></a></p><p id="m_-7044449213207251389m_3873057257117440426m_-2112666820615236994m_-5971293250114633603m_-7423541532824848064m_1354848426895667131m_448710232303741924m_2097881123700523078m_-3528561374763180747m_-3250992085103549817gmail-section-1-1.9" style="padding:0px;margin:0px;color:rgb(17,17,17);font-family:"Noto Sans",Arial,Helvetica,sans-serif;font-size:14px">OpenID Provider Commands are used to project the Tenant data managed centrally by the OP. Groups are a common term used by OPs to manage a collection of Accounts. The terms roles and entitlements tend to be RP specific. Generally, groups from the OP will be mapped to roles and/or entitlements that are RP specific, at the RP.<br><br></p></div></div></div>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></div>

<br>
<i style="margin:0px;padding:0px;border:0px;outline:0px;vertical-align:baseline;background:rgb(255,255,255);font-family:proxima-nova-zendesk,system-ui,-apple-system,system-ui,"Segoe UI",Roboto,Oxygen-Sans,Ubuntu,Cantarell,"Helvetica Neue",Arial,sans-serif;color:rgb(85,85,85)"><span style="margin:0px;padding:0px;border:0px;outline:0px;vertical-align:baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ubuntu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"><font size="2">CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.</font></span></i></blockquote></div>
</blockquote></div></div>
</div>
</div>
</div>
</div>
</div>

<br>
<i style="margin:0px;padding:0px;border:0px;outline:0px;vertical-align:baseline;background:rgb(255,255,255);font-family:proxima-nova-zendesk,system-ui,-apple-system,system-ui,"Segoe UI",Roboto,Oxygen-Sans,Ubuntu,Cantarell,"Helvetica Neue",Arial,sans-serif;color:rgb(85,85,85)"><span style="margin:0px;padding:0px;border:0px;outline:0px;vertical-align:baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ubuntu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"><font size="2">CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.</font></span></i>_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></div></div>
</blockquote></div>