<div dir="ltr">Hello Jeff, really sorry for the typo in the name. </div><br><div class="gmail_quote"><div dir="ltr">On Sun, Aug 5, 2018 at 12:21 AM SureshAtt <<a href="mailto:suresh.attanayake@gmail.com">suresh.attanayake@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello Jett and Nat,<div><br></div><div>Thank you very much for your replies. However I’m quite not sure how I can apply the proposed solutions in this case. Maybe I should elaborate the scenario: </div><div><br></div><div>use case: </div><div><ol><li>User visit the web application first time => trigger an OIDC flow and authenticate the user to the application.</li><li>User bookmarks a page in the application.</li><li>User visits the application again later (few days maybe) using the bookmark => User is automatically signed in (without the redirect to OP) </li></ol>restrictions: </div><div><ol><li>Application is a web application of type SPA. </li><li>Applications is hosted in a different network than the OP is or any other application is. </li><li>Application is required to have a valid access token to consume external APIs for its functionalities. </li><li>OP is supporting only the standard grant types. </li><li>OP doesn’t provide any other endpoints/protocols for user authentication other than OIDC. </li><li>Users of the applications are customers coming from internet using their personal devices which can be of any type. </li></ol>I think above restrictions are not that uncommon for SPAs using OIDC for user authentication. And due to above restrictions I am not sure if the proposed solutions (Kerberos/IWA) can be used in this case, or is there any other alternative? </div><div><br></div><div>If restriction #1 was not there, then the use case can be easily covered with a server backend using the code flow and a remember me cookie </div><div><ol><li>Sign in user using OIDC if remember me cookie is not present. Store the resulting refresh token in server side. </li><li>When user visit next time, detect and validate the remember me cookie and then refresh the access token. </li></ol><ul><ul><li>Access token can have a shorter lifetime to cover the server session lifetime (30 mins). The token refresh can be used detect if user still exists in the system and also to enforce revocation of user consent. </li></ul></ul></div><div>But in the case of a SPA, getting new access token without a browser redirect is the challenge. This is why I read the specification again for the hybrid flow to understand if it handles a similar use case and then I ended up with those questions I asked in my initial email. But after your clarification about the hybrid flow, for me it’s clear that it is not possible for a SPA to get a new access token without a browser redirect. <br></div><div><br></div><div>I think the use case is still valid, however it seems a SPA cannot cover this use case with above restrictions with OIDC. Or do you think otherwise?<br></div><div><br></div><div>Thanks & regards,</div><div>Suresh Attanayake</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Aug 2, 2018 at 3:58 PM Jeff LOMBARDO <<a href="mailto:jeff.lombardo@gmail.com" target="_blank">jeff.lombardo@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">Hi all,<div dir="auto"><br></div><div dir="auto">Thanks Nat to follow-up. Sorry I did not take time to answer you earlier Suresh.</div><div dir="auto"><br></div><div dir="auto">Yes for Customers it applies too. Generally that's what happens with Social OP. So you should be able to enforce it for yours even if it is a private OP.</div><div dir="auto"><br></div><div dir="auto">Jeff</div></div><br><div class="gmail_quote"><div dir="ltr">Le jeu. 2 août 2018 09:52, Nat Sakimura <<a href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Suresh,<br><div><br></div><div>Jeff's comment also applies to consumers. He was just citing an employee case but there is no difference for that matter. </div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Jul 31, 2018 at 4:42 AM SureshAtt via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" rel="noreferrer" target="_blank">openid-specs-ab@lists.openid.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span style="font-size:small;text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Hello Jeff,</span><div style="font-size:small;text-decoration-style:initial;text-decoration-color:initial"><br></div><div style="font-size:small;text-decoration-style:initial;text-decoration-color:initial">In this case users are the end customers, so basically those are B2C web applications. </div><div style="font-size:small;text-decoration-style:initial;text-decoration-color:initial"><br></div><div style="font-size:small;text-decoration-style:initial;text-decoration-color:initial">-Suresh</div><br></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Jul 30, 2018 at 9:33 PM Jeff LOMBARDO <<a href="mailto:jeff.lombardo@gmail.com" rel="noreferrer" target="_blank">jeff.lombardo@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Suresh,<div><br></div><div>What end user typology are we talking about here? Most of the time the "I don't want to have my user to sign-in again" is solved through transparent authentication / WebSSO, not long applicative session... For example, if we are talking about Employee on Managed devices, a Kerberos / IWA on the first mile on the OP sign-in page should solve your case.</div><div><br></div><div>My poor two cents.</div><div><br></div><div>JF</div></div><br><div class="gmail_quote"><div dir="ltr">Le lun. 30 juill. 2018, à 07 h 38, SureshAtt via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" rel="noreferrer" target="_blank">openid-specs-ab@lists.openid.net</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Brock,<div><br></div><div>In our organization I came across with couple SPA having the requirement that they want to prevent the redirect to IdP after user's first log in. That is somehow a keep-me-signed-in like behavior. Ofcouse it is stright forward if the client was confidential. However, since the requirement showed up couple of times, I questioned my understanding of the hybrid flow. Therfore I ended up with the questions above. </div><div><br></div><div>Thanks,</div><div>Suresh Attanayake</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Jul 30, 2018 at 3:19 AM Brock Allen <<a href="mailto:brockallen@gmail.com" rel="noreferrer" target="_blank">brockallen@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id="m_-3220266287463394569m_1948346191454798162m_5445775290930773993m_-8761421397450796694m_117454678944084194m_-1338789362470504925m_8541441923793798215m_-3313988555234404736__MailbirdStyleContent" style="font-size:10pt;font-family:Lucida Console;color:#000000">
Suresh --<div><br></div><div>Can you elaborate on your scenarios where a SPA (client-side browser based application) would need to maintain access tokens longer than the user's browser session?</div><div><br></div><div>I'm very curious. <span style="font-size:10pt;line-height:1.5">Thanks.</span></div><div><div><br></div><div class="m_-3220266287463394569m_1948346191454798162m_5445775290930773993m_-8761421397450796694m_117454678944084194m_-1338789362470504925m_8541441923793798215m_-3313988555234404736mb_sig"><span style="font-family:Lucida Console">-Brock</span><div><br></div></div><blockquote class="m_-3220266287463394569m_1948346191454798162m_5445775290930773993m_-8761421397450796694m_117454678944084194m_-1338789362470504925m_8541441923793798215m_-3313988555234404736history_container" type="cite" style="border-left-style:solid;border-width:1px;margin-top:20px;margin-left:0px;padding-left:10px">
<p style="color:#aaaaaa;margin-top:10px">On 7/29/2018 6:38:29 PM, SureshAtt via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" rel="noreferrer" target="_blank">openid-specs-ab@lists.openid.net</a>> wrote:</p><div dir="ltr">Hello Nat and David,<div><br></div><div>Thanks a lot for your replies. As David mentioned there is already a need for SPA to get longer access to user resources and I have seen different project solves this problem in different ways (ex: using iframes). This led me to think if hybrid flow was desinged to handle this issue as well using refresh tokens, but now I am clear it is not. </div><div><br></div><div>Thanks & regards,</div><div>Suresh Attanayake</div></div><br><div class="gmail_quote"><div dir="ltr">On Sun, Jul 29, 2018 at 7:39 AM Nat Sakimura <<a href="mailto:sakimura@gmail.com" rel="noreferrer" target="_blank">sakimura@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks. <div><br></div><div>I made a reply with too much haste as I was about to go out then but the point is this: </div><div><br></div><div>As 10.4 of RFC6749 states: </div><div><br></div><div><pre class="m_-3220266287463394569m_1948346191454798162m_5445775290930773993m_-8761421397450796694m_117454678944084194m_-1338789362470504925m_8541441923793798215m_-3313988555234404736m_-8999032792951005369gmail-newpage" style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0);text-decoration-style:initial;text-decoration-color:initial"> The authorization server MUST maintain
the binding between a refresh token and the client to whom it was
issued. </pre><pre class="m_-3220266287463394569m_1948346191454798162m_5445775290930773993m_-8761421397450796694m_117454678944084194m_-1338789362470504925m_8541441923793798215m_-3313988555234404736m_-8999032792951005369gmail-newpage" style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0);text-decoration-style:initial;text-decoration-color:initial"><br></pre><pre class="m_-3220266287463394569m_1948346191454798162m_5445775290930773993m_-8761421397450796694m_117454678944084194m_-1338789362470504925m_8541441923793798215m_-3313988555234404736m_-8999032792951005369gmail-newpage" style="margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0);text-decoration-style:initial;text-decoration-color:initial">The most common and safe way of achieve it is to have </pre><pre class="m_-3220266287463394569m_1948346191454798162m_5445775290930773993m_-8761421397450796694m_117454678944084194m_-1338789362470504925m_8541441923793798215m_-3313988555234404736m_-8999032792951005369gmail-newpage" style="margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0);text-decoration-style:initial;text-decoration-color:initial">the client authenticate to the authorization server. </pre><pre class="m_-3220266287463394569m_1948346191454798162m_5445775290930773993m_-8761421397450796694m_117454678944084194m_-1338789362470504925m_8541441923793798215m_-3313988555234404736m_-8999032792951005369gmail-newpage" style="margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0);text-decoration-style:initial;text-decoration-color:initial">Thus, the client has to be a confidential client, </pre><pre class="m_-3220266287463394569m_1948346191454798162m_5445775290930773993m_-8761421397450796694m_117454678944084194m_-1338789362470504925m_8541441923793798215m_-3313988555234404736m_-8999032792951005369gmail-newpage" style="margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0);text-decoration-style:initial;text-decoration-color:initial">i.e., the client that can keep the confidentiality of its key so that </pre><pre class="m_-3220266287463394569m_1948346191454798162m_5445775290930773993m_-8761421397450796694m_117454678944084194m_-1338789362470504925m_8541441923793798215m_-3313988555234404736m_-8999032792951005369gmail-newpage" style="margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0);text-decoration-style:initial;text-decoration-color:initial">it can use a sender constrained tokens) </pre><pre class="m_-3220266287463394569m_1948346191454798162m_5445775290930773993m_-8761421397450796694m_117454678944084194m_-1338789362470504925m_8541441923793798215m_-3313988555234404736m_-8999032792951005369gmail-newpage" style="margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0);text-decoration-style:initial;text-decoration-color:initial">effectively. </pre><pre class="m_-3220266287463394569m_1948346191454798162m_5445775290930773993m_-8761421397450796694m_117454678944084194m_-1338789362470504925m_8541441923793798215m_-3313988555234404736m_-8999032792951005369gmail-newpage" style="margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0);text-decoration-style:initial;text-decoration-color:initial"><br></pre><pre class="m_-3220266287463394569m_1948346191454798162m_5445775290930773993m_-8761421397450796694m_117454678944084194m_-1338789362470504925m_8541441923793798215m_-3313988555234404736m_-8999032792951005369gmail-newpage" style="margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0);text-decoration-style:initial;text-decoration-color:initial">(Note: RFC6749 does not define confidential client. </pre><pre class="m_-3220266287463394569m_1948346191454798162m_5445775290930773993m_-8761421397450796694m_117454678944084194m_-1338789362470504925m_8541441923793798215m_-3313988555234404736m_-8999032792951005369gmail-newpage" style="margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0);text-decoration-style:initial;text-decoration-color:initial">Public client is defined slightly better but it still is sloppy like </pre><pre class="m_-3220266287463394569m_1948346191454798162m_5445775290930773993m_-8761421397450796694m_117454678944084194m_-1338789362470504925m_8541441923793798215m_-3313988555234404736m_-8999032792951005369gmail-newpage" style="margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0);text-decoration-style:initial;text-decoration-color:initial">native applications are public client -- well, what if they did a dynamic registration </pre><pre class="m_-3220266287463394569m_1948346191454798162m_5445775290930773993m_-8761421397450796694m_117454678944084194m_-1338789362470504925m_8541441923793798215m_-3313988555234404736m_-8999032792951005369gmail-newpage" style="margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0);text-decoration-style:initial;text-decoration-color:initial">to get a per-client secret? IMHO, these should be fixed.)</pre><pre class="m_-3220266287463394569m_1948346191454798162m_5445775290930773993m_-8761421397450796694m_117454678944084194m_-1338789362470504925m_8541441923793798215m_-3313988555234404736m_-8999032792951005369gmail-newpage" style="margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0);text-decoration-style:initial;text-decoration-color:initial"><br></pre><pre class="m_-3220266287463394569m_1948346191454798162m_5445775290930773993m_-8761421397450796694m_117454678944084194m_-1338789362470504925m_8541441923793798215m_-3313988555234404736m_-8999032792951005369gmail-newpage" style="margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0);text-decoration-style:initial;text-decoration-color:initial">So, getting back to <span style="color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;white-space:normal;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Suresh's question, it is the intent of the authors not to allow the Javascript </span></pre><pre class="m_-3220266287463394569m_1948346191454798162m_5445775290930773993m_-8761421397450796694m_117454678944084194m_-1338789362470504925m_8541441923793798215m_-3313988555234404736m_-8999032792951005369gmail-newpage" style="margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0);text-decoration-style:initial;text-decoration-color:initial"><span style="color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;white-space:normal;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">clients on a web browser to get refresh token. If the client is effectively a confidential client </span></pre><pre class="m_-3220266287463394569m_1948346191454798162m_5445775290930773993m_-8761421397450796694m_117454678944084194m_-1338789362470504925m_8541441923793798215m_-3313988555234404736m_-8999032792951005369gmail-newpage" style="margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0);text-decoration-style:initial;text-decoration-color:initial"><span style="color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;white-space:normal;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">e.g., by using Token Binding, then, it in principle should be able to make use of a </span></pre><pre class="m_-3220266287463394569m_1948346191454798162m_5445775290930773993m_-8761421397450796694m_117454678944084194m_-1338789362470504925m_8541441923793798215m_-3313988555234404736m_-8999032792951005369gmail-newpage" style="margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0);text-decoration-style:initial;text-decoration-color:initial"><span style="color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;white-space:normal;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Token Bound refresh token, although, it kinds of infringes on RFC6749. </span></pre><pre class="m_-3220266287463394569m_1948346191454798162m_5445775290930773993m_-8761421397450796694m_117454678944084194m_-1338789362470504925m_8541441923793798215m_-3313988555234404736m_-8999032792951005369gmail-newpage" style="margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0);text-decoration-style:initial;text-decoration-color:initial"><span style="color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;white-space:normal;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">I suppose the OAuth Token Binding spec should update that bit. </span></pre><pre class="m_-3220266287463394569m_1948346191454798162m_5445775290930773993m_-8761421397450796694m_117454678944084194m_-1338789362470504925m_8541441923793798215m_-3313988555234404736m_-8999032792951005369gmail-newpage" style="margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0);text-decoration-style:initial;text-decoration-color:initial"><span style="color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;white-space:normal;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><br></span></pre><pre class="m_-3220266287463394569m_1948346191454798162m_5445775290930773993m_-8761421397450796694m_117454678944084194m_-1338789362470504925m_8541441923793798215m_-3313988555234404736m_-8999032792951005369gmail-newpage" style="margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0);text-decoration-style:initial;text-decoration-color:initial"><span style="color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;white-space:normal;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Best, </span></pre><pre class="m_-3220266287463394569m_1948346191454798162m_5445775290930773993m_-8761421397450796694m_117454678944084194m_-1338789362470504925m_8541441923793798215m_-3313988555234404736m_-8999032792951005369gmail-newpage" style="margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0);text-decoration-style:initial;text-decoration-color:initial"><span style="color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;white-space:normal;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><br></span></pre><pre class="m_-3220266287463394569m_1948346191454798162m_5445775290930773993m_-8761421397450796694m_117454678944084194m_-1338789362470504925m_8541441923793798215m_-3313988555234404736m_-8999032792951005369gmail-newpage" style="margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0);text-decoration-style:initial;text-decoration-color:initial"><span style="color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;white-space:normal;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Nat Sakimura</span></pre><pre class="m_-3220266287463394569m_1948346191454798162m_5445775290930773993m_-8761421397450796694m_117454678944084194m_-1338789362470504925m_8541441923793798215m_-3313988555234404736m_-8999032792951005369gmail-newpage" style="margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0);text-decoration-style:initial;text-decoration-color:initial"><br></pre><pre class="m_-3220266287463394569m_1948346191454798162m_5445775290930773993m_-8761421397450796694m_117454678944084194m_-1338789362470504925m_8541441923793798215m_-3313988555234404736m_-8999032792951005369gmail-newpage" style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0);text-decoration-style:initial;text-decoration-color:initial"><br></pre><pre class="m_-3220266287463394569m_1948346191454798162m_5445775290930773993m_-8761421397450796694m_117454678944084194m_-1338789362470504925m_8541441923793798215m_-3313988555234404736m_-8999032792951005369gmail-newpage" style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0);text-decoration-style:initial;text-decoration-color:initial"><br></pre><pre class="m_-3220266287463394569m_1948346191454798162m_5445775290930773993m_-8761421397450796694m_117454678944084194m_-1338789362470504925m_8541441923793798215m_-3313988555234404736m_-8999032792951005369gmail-newpage" style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0);text-decoration-style:initial;text-decoration-color:initial"><br></pre><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Sun, Jul 29, 2018 at 12:36 PM David Waite <<a href="mailto:david@alkaline-solutions.com" rel="noreferrer" target="_blank">david@alkaline-solutions.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> On Jul 28, 2018, at 6:32 PM, Nat Sakimura via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" rel="noreferrer" target="_blank">openid-specs-ab@lists.openid.net</a>> wrote:<br>
<br>
<snip><br>
> A public client cannot get refresh token. <br>
> Assuming that you mean "a client working within a browser using JavaScript" by "a JavaScript Client" since it is a public client, it cannot get a refresh token. <br>
<br>
I’m not familiar with this restriction, my understanding is that it is valid and in fact not uncommon for public clients to get and use refresh tokens. RFC 6749 for example does not state such a restriction, and even language around differing behavior with confidential clients vs public clients:<br>
<br>
"Because refresh tokens are typically long-lasting credentials used to<br>
request additional access tokens, the refresh token is bound to the<br>
client to which it was issued. If the client type is confidential or<br>
the client was issued client credentials (or assigned other<br>
authentication requirements), the client MUST authenticate with the<br>
authorization server as described in Section 3.2.1”<br>
<br>
There are quite legitimate reasons for public clients to have refresh tokens, and quite a few mobile apps which already are using refresh tokens.<br>
<br>
With SPA clients for instance, it allows you to extend access without hidden Iframe tricks (and thus could be a workaround to ITP 2.0 blocking state access on XHR / frames / non-interactive redirects, and such forms of cross-domain access causing IDPs to be flagged as trackers)<br>
<br>
-DW</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="m_-3220266287463394569m_1948346191454798162m_5445775290930773993m_-8761421397450796694m_117454678944084194m_-1338789362470504925m_8541441923793798215m_-3313988555234404736m_-8999032792951005369gmail_signature" data-smartmail="gmail_signature">Nat Sakimura (=nat)<div>Chairman, OpenID Foundation<br><a href="http://nat.sakimura.org/" rel="noreferrer" target="_blank">http://nat.sakimura.org/</a><br>@_nat_en</div></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="m_-3220266287463394569m_1948346191454798162m_5445775290930773993m_-8761421397450796694m_117454678944084194m_-1338789362470504925m_8541441923793798215m_-3313988555234404736gmail_signature" data-smartmail="gmail_signature">Suresh Attanayake<br><br>Blog : <a href="http://sureshatt.blogspot.com/" rel="noreferrer" target="_blank">http://sureshatt.blogspot.com/</a> <div>Web : <a href="http://www.ssoarcade.com/" rel="noreferrer" target="_blank">http://www.ssoarcade.com/</a><br>LinkedIn : <a href="http://www.linkedin.com/pub/suresh-attanayake/16/165/181" rel="noreferrer" target="_blank">http://www.linkedin.com/pub/suresh-attanayake/16/165/181</a> <br>Twitter : <a href="http://twitter.com/sureshatt" rel="noreferrer" target="_blank">http://twitter.com/sureshatt</a> <br></div><div>Facebook : <a href="https://www.facebook.com/IdentityWorld" rel="noreferrer" target="_blank">https://www.facebook.com/IdentityWorld</a></div></div>
_______________________________________________
Openid-specs-ab mailing list
<a href="mailto:Openid-specs-ab@lists.openid.net" rel="noreferrer" target="_blank">Openid-specs-ab@lists.openid.net</a>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</blockquote>
</div></div></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="m_-3220266287463394569m_1948346191454798162m_5445775290930773993m_-8761421397450796694m_117454678944084194m_-1338789362470504925m_8541441923793798215gmail_signature" data-smartmail="gmail_signature">Suresh Attanayake<br><br>Blog : <a href="http://sureshatt.blogspot.com/" rel="noreferrer" target="_blank">http://sureshatt.blogspot.com/</a> <div>Web : <a href="http://www.ssoarcade.com/" rel="noreferrer" target="_blank">http://www.ssoarcade.com/</a><br>LinkedIn : <a href="http://www.linkedin.com/pub/suresh-attanayake/16/165/181" rel="noreferrer" target="_blank">http://www.linkedin.com/pub/suresh-attanayake/16/165/181</a> <br>Twitter : <a href="http://twitter.com/sureshatt" rel="noreferrer" target="_blank">http://twitter.com/sureshatt</a> <br></div><div>Facebook : <a href="https://www.facebook.com/IdentityWorld" rel="noreferrer" target="_blank">https://www.facebook.com/IdentityWorld</a></div></div>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" rel="noreferrer" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="m_-3220266287463394569m_1948346191454798162m_5445775290930773993m_-8761421397450796694gmail_signature" data-smartmail="gmail_signature">Suresh Attanayake<br><br>Blog : <a href="http://sureshatt.blogspot.com/" rel="noreferrer" target="_blank">http://sureshatt.blogspot.com/</a> <div>Web : <a href="http://www.ssoarcade.com/" rel="noreferrer" target="_blank">http://www.ssoarcade.com/</a><br>LinkedIn : <a href="http://www.linkedin.com/pub/suresh-attanayake/16/165/181" rel="noreferrer" target="_blank">http://www.linkedin.com/pub/suresh-attanayake/16/165/181</a> <br>Twitter : <a href="http://twitter.com/sureshatt" rel="noreferrer" target="_blank">http://twitter.com/sureshatt</a> <br></div><div>Facebook : <a href="https://www.facebook.com/IdentityWorld" rel="noreferrer" target="_blank">https://www.facebook.com/IdentityWorld</a></div></div>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" rel="noreferrer" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="m_-3220266287463394569m_1948346191454798162m_5445775290930773993gmail_signature" data-smartmail="gmail_signature">Nat Sakimura (=nat)<div>Chairman, OpenID Foundation<br><a href="http://nat.sakimura.org/" rel="noreferrer" target="_blank">http://nat.sakimura.org/</a><br>@_nat_en</div></div>
</blockquote></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="m_-3220266287463394569gmail_signature" data-smartmail="gmail_signature">Suresh Attanayake<br><br>Blog : <a href="http://sureshatt.blogspot.com/" target="_blank">http://sureshatt.blogspot.com/</a> <div>Web : <a href="http://www.ssoarcade.com/" target="_blank">http://www.ssoarcade.com/</a><br>LinkedIn : <a href="http://www.linkedin.com/pub/suresh-attanayake/16/165/181" target="_blank">http://www.linkedin.com/pub/suresh-attanayake/16/165/181</a> <br>Twitter : <a href="http://twitter.com/sureshatt" target="_blank">http://twitter.com/sureshatt</a> <br></div><div>Facebook : <a href="https://www.facebook.com/IdentityWorld" target="_blank">https://www.facebook.com/IdentityWorld</a></div></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Suresh Attanayake<br><br>Blog : <a href="http://sureshatt.blogspot.com/" target="_blank">http://sureshatt.blogspot.com/</a> <div>Web : <a href="http://www.ssoarcade.com/" target="_blank">http://www.ssoarcade.com/</a><br>LinkedIn : <a href="http://www.linkedin.com/pub/suresh-attanayake/16/165/181" target="_blank">http://www.linkedin.com/pub/suresh-attanayake/16/165/181</a> <br>Twitter : <a href="http://twitter.com/sureshatt" target="_blank">http://twitter.com/sureshatt</a> <br></div><div>Facebook : <a href="https://www.facebook.com/IdentityWorld" target="_blank">https://www.facebook.com/IdentityWorld</a></div></div>