<div dir="ltr">Thanks for relaying this, Jeff. WIMSE is nodding in the right direction but we need even more support for the PEP/PDP pattern. I've been linking back to NIST ABAC 800-162 and ZT 800-207 in my latest presentations to remind people of the usefulness of the architecture but it's clearly not always enough.</div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, Oct 20, 2025 at 2:41 AM Lombardo, Jeff 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 class="msg-519472023354036940">
<div lang="FR-CA" style="overflow-wrap: break-word;">
<div class="m_-519472023354036940WordSection1">
<p class="MsoNormal"><span style="font-size:11pt">FYI<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
<div>
<p class="MsoNormal"><b><span style="font-size:10pt;font-family:"Amazon Ember Heavy",sans-serif">Jean-François “<span style="color:rgb(233,113,50)">Jeff</span>” Lombardo</span></b><span> </span><span style="font-size:10pt;font-family:"Amazon Ember Light",sans-serif">|<span style="color:gray">
</span><span style="color:rgb(233,113,50)">Amazon Web Services</span></span><span style="font-size:10pt;font-family:"Amazon Ember Light",sans-serif;color:rgb(233,113,50)"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:4pt;font-family:"Amazon Ember Light",sans-serif;color:gray"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:10pt;font-family:"Amazon Ember Light",sans-serif;color:gray">Architecte Principal de Solutions, Spécialiste de Sécurité<br>
Principal Solution Architect, Security Specialist<br>
Montréal, Canada<br>
<br>
<u></u><u></u></span></p>
<p class="MsoNormal"><i><span style="font-size:10pt;font-family:"Amazon Ember Light",sans-serif;color:gray">Commentaires à propos de notre échange?
</span></i><i><span lang="EN-US" style="font-size:10pt;font-family:"Amazon Ember Light",sans-serif;color:gray">Exprimez-vous
</span></i><span><a href="https://urldefense.com/v3/__https:/feedback.aws.amazon.com/?ea=jeffsec&fn=Jean*20Francois&ln=Lombardo__;JQ!!Pe07N362zA!0k9CkAV8Djpw_8EfIAKrbhP3TQrJr0oMnznlUgBJ3V3NoEk6hihx7dNHnQuejn6SSH2CP8Iow3G-tTzppHeg$" target="_blank"><i><span lang="EN-US" style="font-size:10pt;font-family:"Amazon Ember Light",sans-serif;color:rgb(70,120,134)">ici</span></i></a></span><i><span lang="EN-US" style="font-size:10pt;font-family:"Amazon Ember Light",sans-serif;color:gray">.<u></u><u></u></span></i></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:4pt;font-family:"Amazon Ember Light",sans-serif;color:gray"><u></u> <u></u></span></p>
<p class="MsoNormal"><i><span lang="EN-US" style="font-size:10pt;font-family:"Amazon Ember Light",sans-serif;color:gray">Thoughts on our interaction? Provide feedback
</span></i><span><a href="https://urldefense.com/v3/__https:/feedback.aws.amazon.com/?ea=jeffsec&fn=Jean*20Francois&ln=Lombardo__;JQ!!Pe07N362zA!0k9CkAV8Djpw_8EfIAKrbhP3TQrJr0oMnznlUgBJ3V3NoEk6hihx7dNHnQuejn6SSH2CP8Iow3G-tTzppHeg$" target="_blank"><i><span lang="EN-US" style="font-size:10pt;font-family:"Amazon Ember Light",sans-serif;color:rgb(70,120,134)">here</span></i></a></span><i><span lang="EN-US" style="font-size:10pt;font-family:"Amazon Ember Light",sans-serif;color:gray">.<u></u><u></u></span></i></p>
</div>
<p class="MsoNormal"><span lang="EN-CA" style="font-size:11pt"><u></u> <u></u></span></p>
<div>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:11pt;font-family:Calibri,sans-serif">From:</span></b><span lang="EN-US" style="font-size:11pt;font-family:Calibri,sans-serif"> Yaron Sheffer <<a href="mailto:yaronf.ietf@gmail.com" target="_blank">yaronf.ietf@gmail.com</a>>
<br>
<b>Sent:</b> October 19, 2025 5:51 AM<br>
<b>To:</b> LUCIA CABANILLAS RODRIGUEZ <<a href="mailto:lucia.cabanillasrodriguez@telefonica.com" target="_blank">lucia.cabanillasrodriguez@telefonica.com</a>>; <a href="mailto:wimse@ietf.org" target="_blank">wimse@ietf.org</a><br>
<b>Subject:</b> [EXT] [WIMSE] Re: [Wimse] Authorization - some ideas<u></u><u></u></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<table 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:1.5pt solid rgb(237,125,49);padding:0cm 5.4pt;height:15.25pt">
<p><strong><span style="font-family:Aptos,sans-serif;color:black;background:rgb(255,255,153)">CAUTION</span></strong><span style="color:black;background:rgb(255,255,153)">: 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><u></u><u></u></p>
</td>
</tr>
</tbody>
</table>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<table 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:1.5pt solid rgb(237,125,49);padding:0cm 5.4pt;height:15.25pt">
<p><strong><span style="font-family:Aptos,sans-serif;color:black;background:rgb(255,255,153)">AVERTISSEMENT</span></strong><span style="color:black;background:rgb(255,255,153)">: Ce courrier électronique provient d’un expéditeur externe. Ne cliquez sur aucun lien et n’ouvrez
aucune pièce jointe si vous ne pouvez pas confirmer l’identité de l’expéditeur et si vous n’êtes pas certain que le contenu ne présente aucun risque.</span><u></u><u></u></p>
</td>
</tr>
</tbody>
</table>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal"><span style="color:black">Hi <span style="background:white">
Lucía</span>,<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">Process-wise, this discussion (and diagram) should actually be moved from the s2s draft into the WIMSE Architecture draft.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">And to your point, I think we just wanted to keep options open around authz. In very small deployments there may not be any explicit authz at all - everybody that presents a valid token/signature is trusted. In
such deployments the PEP is trivial and there’s no PDP.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">We have not had deep discussion of authorization at all, and AFAICT David’s message down this thread actually goes into more depth than the WG or the author team has ever had.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">Thanks,<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"> Yaron<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"><u></u> <u></u></span></p>
</div>
<div id="m_-519472023354036940mail-editor-reference-message-container">
<div style="border-right:none currentcolor;border-bottom:none currentcolor;border-left:none currentcolor;border-top:1pt solid currentcolor;padding:3pt 0cm 0cm">
<p class="MsoNormal" style="margin-bottom:12pt"><b><span style="color:black">From:
</span></b><span style="color:black">LUCIA CABANILLAS RODRIGUEZ <<a href="mailto:lucia.cabanillasrodriguez@telefonica.com" target="_blank">lucia.cabanillasrodriguez@telefonica.com</a>><br>
<b>Date: </b>Tuesday, 14 October 2025 at 12:20<br>
<b>To: </b><a href="mailto:wimse@ietf.org" target="_blank">wimse@ietf.org</a> <<a href="mailto:wimse@ietf.org" target="_blank">wimse@ietf.org</a>><br>
<b>Subject: </b>[WIMSE] Re: [Wimse] Authorization - some ideas<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">Hello everyone,<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">I hope this message finds you well.<u></u><u></u></span></p>
</div>
<p class="m_-519472023354036940ms-outlook-mobile-reference-message"><span style="color:black">I have a question regarding Section 1.2 of draft-ietf-wimse-s2s-protocol-06, where it is stated that the PDP (Policy Decision Point) is optional and may only be deployed when policy management
is centralized.</span><u></u><u></u></p>
<p class="m_-519472023354036940ms-outlook-mobile-reference-message"><span style="color:black">From an architectural and security perspective, I was wondering about the rationale behind making the PDP optional. In most policy-based frameworks, the PDP plays a crucial role in ensuring
that each action or message passing through a PEP is validated against defined policies, for example, checking protocol compliance, enforcing contextual constraints, or verifying trust requirements before any operation proceeds. Even the identity server could
query the PDP beforehand to verify certain conditions or ensure that access or message exchanges comply with established policies.</span><u></u><u></u></p>
<p class="m_-519472023354036940ms-outlook-mobile-reference-message"><span style="color:black">Additionally, I might have missed some earlier discussion on this topic, but I would also like to understand whether a distributed PDP model (rather than a centralized one) has been considered,
as this could preserve policy consistency while maintaining scalability and avoiding single points of failure.</span><u></u><u></u></p>
<p class="m_-519472023354036940ms-outlook-mobile-reference-message"><span style="color:black">Thank you very much for the clarification, and apologies if this has already been discussed in a previous thread.</span><u></u><u></u></p>
<div style="margin-top:12pt;margin-bottom:12pt">
<p class="MsoNormal"><span style="color:black">Kind regards,<u></u><u></u></span></p>
</div>
<p class="m_-519472023354036940ms-outlook-mobile-reference-message"><span style="color:black">Lucía</span><u></u><u></u></p>
<div id="m_-519472023354036940mail-editor-reference-message-container">
<div style="border-right:none currentcolor;border-bottom:none currentcolor;border-left:none currentcolor;border-top:1pt solid currentcolor;padding:3pt 0cm 0cm">
<p class="MsoNormal" style="margin-bottom:12pt"><b><span style="color:black">De:
</span></b><span style="color:black">David Brossard <<a href="mailto:david.brossard@gmail.com" target="_blank">david.brossard@gmail.com</a>><br>
<b>Fecha: </b>miércoles, 1 de octubre de 2025, 12:04<br>
<b>Para: </b><a href="mailto:wimse@ietf.org" target="_blank">wimse@ietf.org</a> <<a href="mailto:wimse@ietf.org" target="_blank">wimse@ietf.org</a>><br>
<b>Asunto: </b>[Wimse] Authorization - some ideas<u></u><u></u></span></p>
</div>
<div style="border:1pt solid rgb(156,101,0);padding:2pt">
<p class="MsoNormal" style="line-height:12pt;background:rgb(255,235,156)"><b><span style="font-size:10pt;font-family:Calibri,sans-serif;color:rgb(156,101,0)">AVISO/WARNING:</span></b><span style="font-size:10pt;font-family:Calibri,sans-serif;color:black"> Este correo
electrónico se originó desde fuera de la organización. No haga clic en enlaces ni abra archivos adjuntos a menos que reconozca al remitente y sepa que el contenido es seguro / This email has been originated from outside of the organization. Do not click links
or open attachments unless you recognize the sender and know the content is safe.</span><span style="font-size:10pt;font-family:Calibri,sans-serif"><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Hi everyone,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I saw the recording of the interim meeting last week (<a href="https://www.youtube.com/watch?time_continue=1929&v=BqPBEfhMOUM" target="_blank">video</a>) and wanted to chime in.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">First of all, I think I agree with what Joseph Saloway says on the call. And of course largely with Pieter and Justin: authorization is an orthogonal concern and we shouldn't reinvent the wheel. Let's go get authorization frameworks and
patterns where they live.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Secondly, I think we need to clearly distinguish between different types of access control/authorization. If we do this, it'll help distinguish between an OAuth-based (or biased) approach to authZ vs. an "ABAC" approach to authorization.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">In my mind, OAuth is great for access delegation (I grant Twitter the right to post on my wall). UMA is great for user delegation. OAuth RAR is great to scope down what clients can do (e.g. the OpenBanking payment examples). All these approaches
tend to be user-centric (though I suppose they don't have to be) and all these approaches tend to rely on the RP knowing what to do with the tokens/claims/scopes. In other words, authorization is still left in the hands of the app being protected (or workload
in WIMSE).<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">This is where ABAC comes into play (and granted, comparing OAuth, a standard/technology, to a framework is skewed at best). When I say ABAC, by the way, I'm referring to the NIST 800-162 definition or even the Zero Trust NIST 800-207 definition
i.e.<u></u><u></u></p>
</div>
<ul type="disc">
<li class="MsoNormal">
externalized authorization outside the app and inside a PDP<u></u><u></u></li><li class="MsoNormal">
runtime authorization: decisions are made at access time, not login, not session, not creation <u></u><u></u></li></ul>
<div>
<p class="MsoNormal">How ABAC is implemented is irrelevant (whether Graph or policies and if so, which policies).<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">So my two cents: yes of course WIMSE needs a clean decoupling and that decoupling can only happen IMHO via a PEP/PDP Architecture<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">This is in fact very much in line with the current draft that includes the picture below. Perhaps, my comment would be that the PEP could sit in front of workloads, gateway-style (Kong, Istio, you name it - there could be workload-friendly
proxies). And of course, shameless plug, step (4) could be OpenID AuthZEN.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<pre><span style="font-family:Consolas;color:rgb(33,37,41)"> +------------+ +------------+<u></u><u></u></span></pre>
<pre><span style="font-family:Consolas;color:rgb(33,37,41)"> | | (1) | |<u></u><u></u></span></pre>
<pre><span style="font-family:Consolas;color:rgb(33,37,41)"> | |<=============>| |<u></u><u></u></span></pre>
<pre><span style="font-family:Consolas;color:rgb(33,37,41)"> | | | |<u></u><u></u></span></pre>
<pre><span style="font-family:Consolas;color:rgb(33,37,41)"> | Workload A | (3) | Workload B |<u></u><u></u></span></pre>
<pre><span style="font-family:Consolas;color:rgb(33,37,41)"> | |==============>| |<u></u><u></u></span></pre>
<pre><span style="font-family:Consolas;color:rgb(33,37,41)"> | | | |<u></u><u></u></span></pre>
<pre><span style="font-family:Consolas;color:rgb(33,37,41)"> | | (5) | +--------+<u></u><u></u></span></pre>
<pre><span style="font-family:Consolas;color:rgb(33,37,41)"> | |<==============| | PEP |<u></u><u></u></span></pre>
<pre><span style="font-family:Consolas;color:rgb(33,37,41)"> +------------+ +---+--------+<u></u><u></u></span></pre>
<pre><span style="font-family:Consolas;color:rgb(33,37,41)"> ^ ^ ^<u></u><u></u></span></pre>
<pre><span style="font-family:Consolas;color:rgb(33,37,41)"> | (2) | |<u></u><u></u></span></pre>
<pre><span style="font-family:Consolas;color:rgb(33,37,41)"> (2) | +----------------------+ | (4)<u></u><u></u></span></pre>
<pre><span style="font-family:Consolas;color:rgb(33,37,41)"> | | |<u></u><u></u></span></pre>
<pre><span style="font-family:Consolas;color:rgb(33,37,41)"> v v v<u></u><u></u></span></pre>
<pre><span style="font-family:Consolas;color:rgb(33,37,41)"> +------------+ +------------+<u></u><u></u></span></pre>
<pre><span style="font-family:Consolas;color:rgb(33,37,41)"> | | | |<u></u><u></u></span></pre>
<pre><span style="font-family:Consolas;color:rgb(33,37,41)"> | Identity | | PDP |<u></u><u></u></span></pre>
<pre><span style="font-family:Consolas;color:rgb(33,37,41)"> | Server | | (optional) |<u></u><u></u></span></pre>
<pre><span style="font-family:Consolas;color:rgb(33,37,41)"> | | | |<u></u><u></u></span></pre>
<pre><span style="font-family:Consolas;color:rgb(33,37,41)"> +------------+ +------------+<u></u><u></u></span></pre>
</div>
<div>
<pre><span style="font-family:Consolas;color:rgb(33,37,41)"><u></u> <u></u></span></pre>
</div>
<div>
<pre><span style="font-family:Consolas;color:rgb(33,37,41)"><u></u> <u></u></span></pre>
</div>
<div>
<pre><span style="font-family:Arial,sans-serif;color:rgb(34,34,34)">So, what does WIMSE need to do? <u></u><u></u></span></pre>
</div>
<pre style="margin-left:36pt"><u></u><span style="font-family:Symbol;color:rgb(33,37,41)"><span>·<span style="font:7pt "Times New Roman""> </span></span></span><u></u><span style="font-family:Arial,sans-serif;color:rgb(34,34,34)">Define use cases: what are the authz requirements we envisage? This will also help clarify the other questions on this mailing list re. identifiers and their granularity.</span><span style="font-family:Consolas;color:rgb(33,37,41)"><u></u><u></u></span></pre>
<pre style="margin-left:36pt"><u></u><span style="font-family:Symbol;color:rgb(33,37,41)"><span>·<span style="font:7pt "Times New Roman""> </span></span></span><u></u><span style="font-family:Arial,sans-serif;color:rgb(34,34,34)">Suggest profiles for other standards e..g. the AuthZEN Profile of WIMSE</span><span style="font-family:Consolas;color:rgb(33,37,41)"><u></u><u></u></span></pre>
<pre style="margin-left:36pt"><u></u><span style="font-family:Symbol;color:rgb(33,37,41)"><span>·<span style="font:7pt "Times New Roman""> </span></span></span><u></u><span style="font-family:Arial,sans-serif;color:rgb(34,34,34)">Suggest policies: using ALFA, Rego or Cedar, what does a sample policy look like?</span><span style="font-family:Consolas;color:rgb(33,37,41)"><u></u><u></u></span></pre>
<div>
<pre><span style="font-family:Arial,sans-serif">All of these need NOT be in the core spec but rather in a profile so long as the architecture is in the core spec (which it currently is).<u></u><u></u></span></pre>
</div>
<div>
<pre><span style="font-family:Arial,sans-serif"><u></u> <u></u></span></pre>
</div>
<div>
<pre><span style="font-family:Arial,sans-serif">Yaron also draws a parallel with MCP and even more so A2A. I've started seeing those use cases. The MCP use cases are not much different from traditional entreprise access control use cases (an employee can view data in their branch - typical mandatory access control).<u></u><u></u></span></pre>
</div>
<div>
<pre><span style="font-family:Arial,sans-serif"><u></u> <u></u></span></pre>
</div>
<div>
<pre><span style="font-family:Arial,sans-serif">A2A (and I think WIMSE as well) brings about another type of use case which blends both the mandatory type of access control and the access delegation type of access control. For instance, can agent A book travel using agent B on behalf of Bob the end user? Bob had previously delegated authority/access to agent A so it can book a trip up to $2,000 and only within the EU.<u></u><u></u></span></pre>
</div>
<div>
<pre><span style="font-family:Arial,sans-serif"><u></u> <u></u></span></pre>
</div>
<div>
<pre><span style="font-family:Arial,sans-serif">Will we see similar use cases here?<u></u><u></u></span></pre>
</div>
<div>
<pre><span style="font-family:Arial,sans-serif"><u></u> <u></u></span></pre>
</div>
<div>
<pre><span style="font-family:Arial,sans-serif">To summarize, I'd suggest the WIMSE spec follow an architecture that aligns well with ABAC if only for the sake of "zero trust". I am excited to see authorization is a hot topic so I'll strive to attend the regular calls.<u></u><u></u></span></pre>
</div>
<div>
<pre><span style="font-family:Arial,sans-serif"><u></u> <u></u></span></pre>
</div>
<div>
<pre><span style="font-family:Arial,sans-serif">Thanks,<u></u><u></u></span></pre>
</div>
<div>
<pre><span style="font-family:Arial,sans-serif">David<u></u><u></u></span></pre>
</div>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="2" width="100%" align="center">
</div>
<div>
<p class="MsoNormal"><span style="font-size:7.5pt;font-family:Arial,sans-serif;color:gray"><br>
Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la
lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.<br>
<br>
The information contained in this transmission is confidential and privileged information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.<br>
<br>
Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a
leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição</span><u></u><u></u></p>
</div>
</div>
</div>
</div>
</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>
</div></blockquote></div><div><br clear="all"></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">---<br>David Brossard<br><a href="http://www.linkedin.com/in/davidbrossard" target="_blank">http://www.linkedin.com/in/davidbrossard</a><br><a href="http://twitter.com/davidjbrossard" target="_blank">http://twitter.com/davidjbrossard</a><br><a href="http://about.me/brossard" target="_blank">http://about.me/brossard</a><br>---<br>Stay safe on the Internet: <a href="https://www.capefearnetworks.com/wp-content/uploads/2017/05/Internet-Fraud-Prevention-Tips-IC3.pdf" target="_blank">IC3 Prevention Tips</a><br>Prenez vos précautions sur Internet: <a href="https://cyber.gouv.fr/bonnes-pratiques-protegez-vous" target="_blank">https://cyber.gouv.fr/bonnes-pratiques-protegez-vous</a></div></div>