<div dir="ltr">Regarding the motivation for a back-channel session cleanup mechanism:<div><br></div><div>1) The iframe based polling mechanism is useful, namely in SPA apps, however it imposes additional requirements. Namely, it requires additional coordination between the browser-side and the server-side of the "client" - the browser side must inform the server-side of the session status change. In my perspective, it is fundamental to ensure session cleanup on the server-side. Also, as Todd mentioned, the browser-side of the app may not always be active.</div>
<div><br></div><div>2) One of the scenarios for our OP is currently based on Shibboleth, where this back-channel cleanup is common. Namely, the OP will be receiving back-channel cleanup notifications from a upstream Shibboleth IdP and will have to propagate these down to the OIDC RPs. Since this process is occurring on the back-channel, it is not even possible to update the browser state (e.g. via the session cookie).</div>
<div><br></div><div>Makes sense?</div><div><br></div><div>Thanks</div><div>Pedro</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Mar 13, 2014 at 8:11 PM, George Fletcher <span dir="ltr"><<a href="mailto:gffletch@aol.com" target="_blank">gffletch@aol.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <font face="Helvetica, Arial, sans-serif">So I'm to blame for the
      confusion... see the other email I just sent:)<br>
      <br>
      As for browsers and JS. Basically, yes, the browser does not run
      JS from historical pages so the problem comes when the user
      navigates the same browser window from RP "A" to RP "B" and then
      logs out. If the user had two tabs open, one for RP "A" and one
      for RP "B", then the JS solution will work just fine.<br>
      <br>
      Thanks,<br>
      George<br>
      <br>
    </font><div><div class="h5">
    <div>On 3/13/14 3:53 PM, Todd W Lainhart
      wrote:<br>
    </div>
    <blockquote type="cite"><font face="sans-serif">> </font><font color="#004080" face="Calibri">Your
        example seems to indicate that JavaScript code in pages present
        in the
        browser history doesn’t get to run unless the page is the
        displayed page.
         Is that correct?</font>
      <br>
      <br>
      <font face="sans-serif">I'm also not an expert, but
        that's my
        understanding.<br>
      </font>
      <br>
      <font face="sans-serif">> </font><font color="#004080" face="Calibri">Do
        you have any sense why this issue also prompted discussions on
        non-opaque
        access tokens and introspection?</font>
      <br>
      <br>
      <font face="sans-serif">I don't.  That's something that
        George/Justin brought up.  Went over my head.</font>
      <table style="border-collapse:collapse" width="223">
        <tbody>
          <tr height="8">
            <td style="border-style:solid;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px" bgcolor="white" width="223"><font size="1" face="Verdana"><b><br>
                  <br>
                  <br>
                  Todd Lainhart<br>
                  Rational software<br>
                  IBM Corporation<br>
                  550 King Street, Littleton, MA 01460-1250</b></font><font size="1" face="Arial"><b><br>
                  <a href="tel:1-978-899-4705" value="+19788994705" target="_blank">1-978-899-4705</a><br>
                  2-276-4705 (T/L)<br>
                  <a href="mailto:lainhart@us.ibm.com" target="_blank">lainhart@us.ibm.com</a></b></font></td>
          </tr>
        </tbody>
      </table>
      <br>
      <br>
      <br>
      <br>
      <br>
      <font color="#5f5f5f" size="1" face="sans-serif">From:      
         </font><font size="1" face="sans-serif">Mike Jones
        <a href="mailto:Michael.Jones@microsoft.com" target="_blank"><Michael.Jones@microsoft.com></a></font>
      <br>
      <font color="#5f5f5f" size="1" face="sans-serif">To:      
         </font><font size="1" face="sans-serif">Todd W
        Lainhart/Lexington/IBM@IBMUS,
      </font>
      <br>
      <font color="#5f5f5f" size="1" face="sans-serif">Cc:      
         </font><font size="1" face="sans-serif">George Fletcher
        <a href="mailto:gffletch@aol.com" target="_blank"><gffletch@aol.com></a>,
        Justin Richer <a href="mailto:jricher@mitre.org" target="_blank"><jricher@mitre.org></a>,
        <a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">"openid-specs-ab@lists.openid.net"</a>
        <a href="mailto:openid-specs-ab@lists.openid.net" target="_blank"><openid-specs-ab@lists.openid.net></a>,
        <a href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank">"openid-specs-ab-bounces@lists.openid.net"</a>
        <a href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank"><openid-specs-ab-bounces@lists.openid.net></a>, Pedro Felix
        <a href="mailto:pmhsfelix@gmail.com" target="_blank"><pmhsfelix@gmail.com></a></font>
      <br>
      <font color="#5f5f5f" size="1" face="sans-serif">Date:      
         </font><font size="1" face="sans-serif">03/13/2014 03:26 PM</font>
      <br>
      <font color="#5f5f5f" size="1" face="sans-serif">Subject:    
           </font><font size="1" face="sans-serif">RE: [Openid-specs-ab]
        Session cleanup via back-channel</font>
      <br>
      <hr noshade>
      <br>
      <br>
      <br>
      <font color="#004080" face="Calibri">Thanks for the
        concrete example,
        Todd.  That’s useful.  Your example seems to indicate that
        JavaScript
        code in pages present in the browser history doesn’t get to run
        unless
        the page is the displayed page.  Is that correct?  And is the
        answer the same for all browsers or is it different for
        different browsers?
         (I’m not an expert in browser implementation details, so I’m
        openly
        asking this, hoping that someone on the thread does have this
        expertise.)</font>
      <br>
      <font color="#004080" face="Calibri"> </font>
      <br>
      <font color="#004080" face="Calibri">Do you have any
        sense why
        this issue also prompted discussions on non-opaque access tokens
        and introspection?</font>
      <br>
      <font color="#004080" face="Calibri"> </font>
      <br>
      <font color="#004080" face="Calibri">       
                             
                             
                    -- Mike</font>
      <br>
      <font color="#004080" face="Calibri"> </font>
      <br>
      <font face="Tahoma"><b>From:</b> Todd W Lainhart [</font><a href="mailto:lainhart@us.ibm.com" target="_blank"><font face="Tahoma">mailto:lainhart@us.ibm.com</font></a><font face="Tahoma">]
        <b><br>
          Sent:</b> Thursday, March 13, 2014 12:12 PM<b><br>
          To:</b> Mike Jones<b><br>
          Cc:</b> George Fletcher; Justin Richer;
        <a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>;
        <a href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank">openid-specs-ab-bounces@lists.openid.net</a>; Pedro Felix<b><br>
          Subject:</b> Re: [Openid-specs-ab] Session cleanup via
        back-channel</font>
      <br>
      <font size="3" face="Times New Roman"> </font>
      <br>
      <font face="Arial">> </font><font color="#004080" face="Calibri"> Am
        I correct or wrong that this is the same issue?</font><font size="3" face="Times New Roman">
        <br>
      </font><font face="Arial"><br>
        It is the same issue.  My sense at the time it was closed was
        that
        folks on the call didn't want to hold up the specs for this, and
        so Nat
        proposed the extension route, with the observation that the
        topic had been
        raised before.  I'm also recalling that maybe the Googlers had
        something
        to say about this.</font><font size="3" face="Times New Roman">
        <br>
      </font><font face="Arial"><br>
        > </font><font color="#004080" face="Calibri">is
        there a reason
        that RPs can’t learn of the OP-initiated logout via the
        JavaScript session
        state changed notification already in the spec?</font><font size="3" face="Times New Roman">
        <br>
      </font><font face="Arial"><br>
        I'm not speaking for Pedro, but I'll give you an example (but
        real) scenario
        that prompted #916.  Browser is viewing the protected resources
        of
        RP "A" (a session has already been started).  Bob clicks
        a link on the page which now shows the representation of a
        protected resource
        from RP "B".  Bob selects "logout", which directs
        "B" to the end_session endpoint.  Ideally, "A"
        would get notified of the session end so that it can drop
        resources that
        it was associating to Bob.</font><font size="3" face="Times New
        Roman"> </font>
      <p>
        </p><table style="border-collapse:collapse" width="224">
          <tbody>
            <tr height="8">
              <td style="border-style:solid;border-color:#000000;border-width:1px 1px 1px 1px;padding:0px 0px" bgcolor="white" width="222"><font size="1" face="Verdana"><b><br>
                    <br>
                    <br>
                    Todd Lainhart<br>
                    Rational software<br>
                    IBM Corporation<br>
                    550 King Street, Littleton, MA 01460-1250</b></font><font size="1" face="Arial"><b><br>
                    <a href="tel:1-978-899-4705" value="+19788994705" target="_blank">1-978-899-4705</a><br>
                    2-276-4705 (T/L)</b></font><font color="blue" size="1" face="Arial"><b><u><br>
                    </u></b></font><a href="mailto:lainhart@us.ibm.com" target="_blank"><font color="blue" size="1" face="Arial"><b><u>lainhart@us.ibm.com</u></b></font></a></td>
            </tr>
          </tbody>
        </table>
        <br>
        <font size="3" face="Times New Roman"><br>
          <br>
          <br>
          <br>
        </font><font color="#5f5f5f" size="1" face="Arial"><br>
          From:        </font><font size="1" face="Arial">Mike
          Jones <</font><a href="mailto:Michael.Jones@microsoft.com" target="_blank"><font color="blue" size="1" face="Arial"><u>Michael.Jones@microsoft.com</u></font></a><font size="1" face="Arial">></font><font size="3" face="Times
          New Roman">
        </font><font color="#5f5f5f" size="1" face="Arial"><br>
          To:        </font><font size="1" face="Arial">George
          Fletcher <</font><a href="mailto:gffletch@aol.com" target="_blank"><font color="blue" size="1" face="Arial"><u>gffletch@aol.com</u></font></a><font size="1" face="Arial">>,
          Pedro Felix <</font><a href="mailto:pmhsfelix@gmail.com" target="_blank"><font color="blue" size="1" face="Arial"><u>pmhsfelix@gmail.com</u></font></a><font size="1" face="Arial">>,
          Justin Richer <</font><a href="mailto:jricher@mitre.org" target="_blank"><font color="blue" size="1" face="Arial"><u>jricher@mitre.org</u></font></a><font size="1" face="Arial">>,
        </font><font color="#5f5f5f" size="1" face="Arial"><br>
          Cc:        </font><font size="1" face="Arial">"</font><a href="mailto:openid-specs-ab@lists.openid.net" target="_blank"><font color="blue" size="1" face="Arial"><u>openid-specs-ab@lists.openid.net</u></font></a><font size="1" face="Arial">"
          <</font><a href="mailto:openid-specs-ab@lists.openid.net" target="_blank"><font color="blue" size="1" face="Arial"><u>openid-specs-ab@lists.openid.net</u></font></a><font size="1" face="Arial">></font><font size="3" face="Times
          New Roman">
        </font><font color="#5f5f5f" size="1" face="Arial"><br>
          Date:        </font><font size="1" face="Arial">03/13/2014
          02:47 PM</font><font size="3" face="Times New Roman"> </font><font color="#5f5f5f" size="1" face="Arial"><br>
          Subject:        </font><font size="1" face="Arial">Re:
          [Openid-specs-ab] Session cleanup via back-channel</font><font size="3" face="Times New Roman">
        </font><font color="#5f5f5f" size="1" face="Arial"><br>
          Sent by:        </font><a href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank"><font color="blue" size="1" face="Arial"><u>openid-specs-ab-bounces@lists.openid.net</u></font></a><font size="3" face="Times New Roman">
        </font>
      <p></p>
      <div align="center">
        <hr noshade></div>
      <br>
      <font size="3" face="Times New Roman"><br>
        <br>
      </font><font color="#004080" face="Calibri"><br>
        Maybe I’m confused, but this issue seems like a duplicate of </font><a href="https://bitbucket.org/openid/connect/issue/916" target="_blank"><font color="blue" face="Calibri"><u>https://bitbucket.org/openid/connect/issue/916</u></font></a><font color="#004080" face="Calibri">,
        which we’d previously discussed and decided not to fix.  Am I
        correct
        or wrong that this is the same issue?</font><font size="3" face="Times New Roman">
      </font><font color="#004080" face="Calibri"><br>
      </font><font size="3" face="Times New Roman"> </font><font color="#004080" face="Calibri"><br>
        Responding to Pedro’s point “</font><font size="3" face="Times
        New Roman">2)
        The OP propagate this cleanup notification to the downstream
        RPs, also
        via back-channel (a back-channel to front-channel is not
        possible)</font><font color="#004080" face="Calibri">”
        – is there a reason that RPs can’t learn of the OP-initiated
        logout via
        the JavaScript session state changed notification already in the
        spec?
         I realize that requiring JavaScript might not be your preferred
        mechanism,
        but we’ve also tried not to have multiple ways to do the same
        thing, unless
        there’s a good reason to do so.  I’m open-minded about this, but
        would like to hear what the arguments for the additional
        mechanism are,
        and if they’re different than those discussed with issue #916.</font><font size="3" face="Times New Roman">
      </font><font color="#004080" face="Calibri"><br>
      </font><font size="3" face="Times New Roman"> </font><font color="#004080" face="Calibri"><br>
        I’m also confused about the talk of structured access tokens.
         How
        do structured access tokens relate to logout?  And why would we
        consider
        changing access tokens from being opaque to structured?
         Requiring
        specific structure would break many OAuth and OpenID Connect
        implementations.</font><font size="3" face="Times New Roman">
      </font><font color="#004080" face="Calibri"><br>
      </font><font size="3" face="Times New Roman"> </font><font color="#004080" face="Calibri"><br>
        I’m also confused why introspection is being discussed again.
         We
        deleted the Check ID Endpoint, which did introspection on ID
        Tokens in
        May 2012 in response to developer feedback about not wanting to
        have to
        support two ways of doing the same thing.  See </font><a href="https://bitbucket.org/openid/connect/issue/570" target="_blank"><font color="blue" face="Calibri"><u>https://bitbucket.org/openid/connect/issue/570</u></font></a><font color="#004080" face="Calibri">.
         Why is this being discussed again, now that the specs are
        final?</font><font size="3" face="Times New Roman">
      </font><font color="#004080" face="Calibri"><br>
      </font><font size="3" face="Times New Roman"> </font><font color="#004080" face="Calibri"><br>
        I guess call me confused today…</font><font size="3" face="Times
        New Roman">
      </font><font color="#004080" face="Calibri"><br>
      </font><font size="3" face="Times New Roman"> </font><font color="#004080" face="Calibri"><br>
                           
                             
                             --
        Mike</font><font size="3" face="Times New Roman"> </font><font color="#004080" face="Calibri"><br>
      </font><font size="3" face="Times New Roman"> </font><font face="Tahoma"><b><br>
          From:</b> </font><a href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank"><font color="blue" face="Tahoma"><u>openid-specs-ab-bounces@lists.openid.net</u></font></a><font face="Tahoma">
        [</font><a href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank"><font color="blue" face="Tahoma"><u>mailto:openid-specs-ab-bounces@lists.openid.net</u></font></a><font face="Tahoma">]
        <b>On Behalf Of </b>George Fletcher<b><br>
          Sent:</b> Thursday, March 13, 2014 8:19 AM<b><br>
          To:</b> Pedro Felix; Justin Richer<b><br>
          Cc:</b> </font><a href="mailto:openid-specs-ab@lists.openid.net" target="_blank"><font color="blue" face="Tahoma"><u>openid-specs-ab@lists.openid.net</u></font></a><font face="Tahoma"><b><br>
          Subject:</b> Re: [Openid-specs-ab] Session cleanup via
        back-channel</font><font size="3" face="Times New Roman">
        <br>
         </font><font size="3" face="Arial"><br>
        Hi Pedro,<br>
        <br>
        Sorry for confusing the thread. I was responding to Nat's point
        about structured
        headers. It's not really relevant to the issue you are
        addressing. As for
        requirements for the back-channel call, you can add a document
        on the wiki,
        or file a new issue on the site as an enhancement for the
        working group
        to address and then put in the ticket all the current
        requirements. Others
        can then comment on the ticket and the working group can track
        it.<br>
        <br>
        Note, that for this back-channel capability to be relevant to an
        RP, the
        RP must support the concept of "server side" sessions (or
        maintain
        a "black list" of revoked sessions). This doesn't tend to be
        capabilities that most RPs support.<br>
        <br>
        Thanks,<br>
        George</font><font size="3" face="Times New Roman"> <br>
        On 3/13/14 11:12 AM, Pedro Felix wrote: <br>
        1) Since I'm rather new in this group, what would be the best
        way to continue
        this discussion? In this email thread? By trying to produce a
        requirements
        doc on the wiki? <br>
        Most probably, I will be working on an implementation of this
        feature in
        the near future. <br>
         <br>
        2) Picking up on Justin's reply: an approach would be to also
        use the "aud"
        and the "sub" to identify the session to cleanup. I don't like
        the idea of requiring a round-trip to the introspection endpoint
        in order
        to check the token purpose. Makes sense? <br>
         <br>
        Thanks <br>
        Pedro <br>
         <br>
        On Thu, Mar 13, 2014 at 2:12 PM, Justin Richer <</font><a href="mailto:jricher@mitre.org" target="_blank"><font color="blue" size="3" face="Times New
          Roman"><u>jricher@mitre.org</u></font></a><font size="3" face="Times New Roman">>
        wrote: <br>
        A number of our apps use this combined approach -- the server
        sends out
        a signed JWT that the client can check the "iss" field and
        signature,
        then (if it cares to do so) the client does introspection with
        the server
        at "iss" to see if the token's still valid and what it's good
        for.</font><font color="#8f8f8f" size="3" face="Times New Roman"><br>
        <br>
        -- Justin</font><font size="3" face="Times New Roman"> <br>
         <br>
        On 03/13/2014 09:48 AM, George Fletcher wrote: </font><font size="3" face="Arial"><br>
        On the "structured token" side of things I remember having a
        discussion about this at IIW (a few back) and I thought someone
        and written
        something up. It was needed in a number of cases that were using
        the token
        introspection endpoint as a way to identifier the authorization
        server
        to send the token to for introspection. I can't find my notes on
        the conversation
        but maybe someone else remembers?<br>
        <br>
        I think conceptually it was as simple as a non-signed JWT
        containing iss
        and token fields. Obviously, the rest of JOSE could be applied
        for signed
        or encrypted tokens.<br>
        <br>
        Thanks,<br>
        George</font><font size="3" face="Times New Roman"> <br>
        On 3/12/14 9:02 PM, n-sakimura wrote: <br>
        Let's just write up requirements on the WG wiki (@bitbucket). <br>
        Once we agree on the requirements, it should be straight forward
        to turn
        it into a spec. <br>
        <br>
        On the side note, perhaps it is actually for OAuth WG, but it
        would be
        nice to spec out the structured (access) token. it could be
        pseudo opaque
        as well as long as you can find the authorization server from
        the token
        but we at least need to be able to find out the iss. <br>
        <br>
        Nat <br>
        <br>
        (2014/03/13 3:58), John Bradley wrote: <br>
        <br>
        We have discussed creating a backchannel push method for the IdP
        to notify
        the RP. <br>
        <br>
        So far noting is written up.  I have a bad feeling that it might
        be
        me that needs to create the first draft. <br>
        <br>
        John B. <br>
        <br>
        On Mar 12, 2014, at 3:54 PM, Pedro Felix </font><a href="mailto:pmhsfelix@gmail.com" target="_blank"><font color="blue" size="3" face="Times New
          Roman"><u><pmhsfelix@gmail.com></u></font></a><font size="3" face="Times New Roman">
        wrote: <br>
        <br>
        <br>
        Hi, <br>
        <br>
        I've a scenario where a OIDC OP is acting as a bridge between
        upstream
        IdPs using non-OIDC protocols (e.g Shibboleth) and downstream
        RPs using
        OIDC. <br>
        In this scenario I have the following requirements <br>
         1) The upstream IdP notifies the OP of a session termination
        via
        back-channel <br>
         2) The OP propagate this cleanup notification to the downstream
        RPs, also via back-channel (a back-channel to front-channel is
        not possible)
        <br>
        <br>
        Unfortunately, the OIDC session management spec does not provide
        any way
        to perform this back-channel cleanup, however I remember reading
        some meeting
        notes about this possibility. <br>
        <br>
        Is there anything that can be shared? I would like to align our
        solution
        with what is being developed by this working group. <br>
        <br>
        Thanks <br>
        Pedro <br>
        _______________________________________________ <br>
        Openid-specs-ab mailing list </font><font color="blue" size="3" face="Times New Roman"><u><br>
        </u></font><a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank"><font color="blue" size="3" face="Times New Roman"><u>Openid-specs-ab@lists.openid.net</u></font></a><font size="3" face="Times New Roman">
      </font><font color="blue" size="3" face="Times New Roman"><u><br>
        </u></font><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank"><font color="blue" size="3" face="Times New
          Roman"><u>http://lists.openid.net/mailman/listinfo/openid-specs-ab</u></font></a><font size="3" face="Times New Roman">
        <br>
        <br>
        <br>
        <br>
        _______________________________________________ <br>
        Openid-specs-ab mailing list </font><font color="blue" size="3" face="Times New Roman"><u><br>
        </u></font><a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank"><font color="blue" size="3" face="Times New Roman"><u>Openid-specs-ab@lists.openid.net</u></font></a><font size="3" face="Times New Roman">
      </font><font color="blue" size="3" face="Times New Roman"><u><br>
        </u></font><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank"><font color="blue" size="3" face="Times New
          Roman"><u>http://lists.openid.net/mailman/listinfo/openid-specs-ab</u></font></a><font size="3" face="Times New Roman">
        <br>
         <br>
         <br>
        -- </font><font color="blue" size="3" face="Times New Roman"><u><br>
        </u></font><a href="http://connect.me/gffletch" target="_blank"><img src="cid:part21.00000709.06090702@aol.com" alt="George
          Fletcher"></a><font size="3" face="Times New Roman"><br>
        <br>
      </font><font face="Courier New"><br>
        _______________________________________________</font><font size="3" face="Times New Roman">
      </font><font face="Courier New"><br>
        Openid-specs-ab mailing list</font><font size="3" face="Times
        New Roman">
      </font><font color="blue" size="3" face="Times New Roman"><u><br>
        </u></font><a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank"><font color="blue" face="Courier New"><u>Openid-specs-ab@lists.openid.net</u></font></a><font size="3" face="Times New Roman">
      </font><font color="blue" size="3" face="Times New Roman"><u><br>
        </u></font><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank"><font color="blue" face="Courier New"><u>http://lists.openid.net/mailman/listinfo/openid-specs-ab</u></font></a><font size="3" face="Times New Roman">
        <br>
         <br>
        <br>
        _______________________________________________<br>
        Openid-specs-ab mailing list</font><font color="blue" size="3" face="Times New Roman"><u><br>
        </u></font><a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank"><font color="blue" size="3" face="Times New Roman"><u>Openid-specs-ab@lists.openid.net</u></font></a><font color="blue" size="3" face="Times New Roman"><u><br>

        </u></font><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank"><font color="blue" size="3" face="Times New
          Roman"><u>http://lists.openid.net/mailman/listinfo/openid-specs-ab</u></font></a><font size="3" face="Times New Roman">
        <br>
         <br>
         <br>
        -- </font><font color="blue" size="3" face="Times New Roman"><u><br>
        </u></font><a href="http://connect.me/gffletch" target="_blank"><img src="cid:part27.06010701.05080502@aol.com" alt="George
          Fletcher"></a><font face="Courier New">_______________________________________________<br>
        Openid-specs-ab mailing list</font><font color="blue" face="Courier New"><u><br>
        </u></font><a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank"><font color="blue" face="Courier New"><u>Openid-specs-ab@lists.openid.net</u></font></a><font color="blue" size="3" face="Times New Roman"><u><br>

        </u></font><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank"><font color="blue" face="Courier New"><u>http://lists.openid.net/mailman/listinfo/openid-specs-ab</u></font></a>
      <br>
    </blockquote>
    <br>
    </div></div><span class="HOEnZb"><font color="#888888"><div>-- <br>
      <a href="http://connect.me/gffletch" title="View full card on
        Connect.Me" target="_blank"><img src="cid:part31.00060908.07020005@aol.com" alt="George Fletcher" width="359" height="113"></a></div>
  </font></span></div>

</blockquote></div><br></div>