<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <font face="Helvetica, Arial, sans-serif">Hi Mike,<br>
      <br>
      Sorry for causing the confusion. In Nat's email he addressed two
      different (and unrelated topics).<br>
      <br>
      1. Requirements for the IdP-to-RP session logout notification<br>
      <br>
      2. Need for some guidance around structured tokens<br>
      <br>
      These are two orthogonal topics. I addressed the second item in
      this thread (rather than starting a new one) and that I think is
      what caused the confusion.<br>
      <br>
      Thanks,<br>
      George<br>
      <br>
    </font>
    <div class="moz-cite-prefix">On 3/13/14 2:46 PM, Mike Jones wrote:<br>
    </div>
    <blockquote
cite="mid:4E1F6AAD24975D4BA5B16804296739439A0E125E@TK5EX14MBXC286.redmond.corp.microsoft.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <meta name="Generator" content="Microsoft Word 14 (filtered
        medium)">
      <!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]-->
      <style><!--
/* Font Definitions */
@font-face
        {font-family:Helvetica;
        panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
        {font-family:Helvetica;
        panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
        {font-family:Consolas;
        panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";
        color:black;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
pre
        {mso-style-priority:99;
        mso-style-link:"HTML Preformatted Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:10.0pt;
        font-family:"Courier New";
        color:black;}
span.hoenzb
        {mso-style-name:hoenzb;}
span.HTMLPreformattedChar
        {mso-style-name:"HTML Preformatted Char";
        mso-style-priority:99;
        mso-style-link:"HTML Preformatted";
        font-family:Consolas;
        color:black;}
span.EmailStyle20
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
      <div class="WordSection1">
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Maybe
            I’m confused, but this issue seems like a duplicate of
            <a moz-do-not-send="true"
              href="https://bitbucket.org/openid/connect/issue/916">https://bitbucket.org/openid/connect/issue/916</a>,
            which we’d previously discussed and decided not to fix.  Am
            I correct or wrong that this is the same issue?<o:p></o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Responding
            to Pedro’s point “</span>2) The OP propagate this cleanup
          notification to the downstream RPs, also via back-channel (a
          back-channel to front-channel is not possible)<span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">”
            – 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.<o:p></o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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.<o:p></o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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
            <a moz-do-not-send="true"
              href="https://bitbucket.org/openid/connect/issue/570">https://bitbucket.org/openid/connect/issue/570</a>. 
            Why is this being discussed again, now that the specs are
            final?<o:p></o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I
            guess call me confused today…<o:p></o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">                                                               
            -- Mike<o:p></o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
        <div>
          <div style="border:none;border-top:solid #B5C4DF
            1.0pt;padding:3.0pt 0in 0in 0in">
            <p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">
                <a class="moz-txt-link-abbreviated" href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a>
                [<a class="moz-txt-link-freetext" href="mailto:openid-specs-ab-bounces@lists.openid.net">mailto:openid-specs-ab-bounces@lists.openid.net</a>]
                <b>On Behalf Of </b>George Fletcher<br>
                <b>Sent:</b> Thursday, March 13, 2014 8:19 AM<br>
                <b>To:</b> Pedro Felix; Justin Richer<br>
                <b>Cc:</b> <a class="moz-txt-link-abbreviated" href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a><br>
                <b>Subject:</b> Re: [Openid-specs-ab] Session cleanup
                via back-channel<o:p></o:p></span></p>
          </div>
        </div>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal" style="margin-bottom:12.0pt"><span
            style="font-family:"Helvetica","sans-serif"">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</span><o:p></o:p></p>
        <div>
          <p class="MsoNormal">On 3/13/14 11:12 AM, Pedro Felix wrote:<o:p></o:p></p>
        </div>
        <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
          <div>
            <p class="MsoNormal">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?
              <o:p></o:p></p>
            <div>
              <p class="MsoNormal">Most probably, I will be working on
                an implementation of this feature in the near future.<o:p></o:p></p>
              <div>
                <p class="MsoNormal"><o:p> </o:p></p>
              </div>
              <div>
                <p class="MsoNormal">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?<o:p></o:p></p>
              </div>
            </div>
            <div>
              <p class="MsoNormal"><o:p> </o:p></p>
            </div>
            <div>
              <p class="MsoNormal">Thanks<o:p></o:p></p>
            </div>
            <div>
              <p class="MsoNormal">Pedro<o:p></o:p></p>
            </div>
            <div>
              <p class="MsoNormal"><o:p> </o:p></p>
              <div>
                <p class="MsoNormal">On Thu, Mar 13, 2014 at 2:12 PM,
                  Justin Richer <<a moz-do-not-send="true"
                    href="mailto:jricher@mitre.org" target="_blank">jricher@mitre.org</a>>
                  wrote:<o:p></o:p></p>
                <div>
                  <p class="MsoNormal">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.<span
                      style="color:#888888"><br>
                      <br>
                      <span class="hoenzb"> -- Justin</span></span> <o:p></o:p></p>
                  <div>
                    <div>
                      <p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
                      <div>
                        <p class="MsoNormal">On 03/13/2014 09:48 AM,
                          George Fletcher wrote:<o:p></o:p></p>
                      </div>
                      <blockquote
                        style="margin-top:5.0pt;margin-bottom:5.0pt">
                        <p class="MsoNormal"
                          style="margin-bottom:12.0pt"><span
                            style="font-family:"Helvetica","sans-serif"">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</span><o:p></o:p></p>
                        <div>
                          <p class="MsoNormal">On 3/12/14 9:02 PM,
                            n-sakimura wrote:<o:p></o:p></p>
                        </div>
                        <blockquote
                          style="margin-top:5.0pt;margin-bottom:5.0pt">
                          <p class="MsoNormal">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>
                            <o:p></o:p></p>
                          <p class="MsoNormal">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 <a
                              moz-do-not-send="true"
                              href="mailto:pmhsfelix@gmail.com"
                              target="_blank">
                              <pmhsfelix@gmail.com></a> wrote: <br>
                            <br>
                            <br>
                            <o:p></o:p></p>
                          <p class="MsoNormal">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 <br>
                            <a moz-do-not-send="true"
                              href="mailto:Openid-specs-ab@lists.openid.net"
                              target="_blank">Openid-specs-ab@lists.openid.net</a>
                            <br>
                            <a moz-do-not-send="true"
                              href="http://lists.openid.net/mailman/listinfo/openid-specs-ab"
                              target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
                            <o:p></o:p></p>
                          <p class="MsoNormal"
                            style="margin-bottom:12.0pt"><br>
                            <br>
                            <br>
                            _______________________________________________
                            <br>
                            Openid-specs-ab mailing list <br>
                            <a moz-do-not-send="true"
                              href="mailto:Openid-specs-ab@lists.openid.net"
                              target="_blank">Openid-specs-ab@lists.openid.net</a>
                            <br>
                            <a moz-do-not-send="true"
                              href="http://lists.openid.net/mailman/listinfo/openid-specs-ab"
                              target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
                            <o:p></o:p></p>
                          <p class="MsoNormal"
                            style="margin-bottom:12.0pt"><o:p> </o:p></p>
                        </blockquote>
                        <p class="MsoNormal"><o:p> </o:p></p>
                        <div>
                          <p class="MsoNormal">-- <br>
                            <a moz-do-not-send="true"
                              href="http://connect.me/gffletch"
                              target="_blank" title="View full card on
                              Connect.Me"><span
                                style="text-decoration:none"><img
                                  id="_x0000_i1025"
                                  src="cid:part9.04030903.06050302@aol.com"
                                  alt="George Fletcher" border="0"
                                  width="359" height="113"></span></a><o:p></o:p></p>
                        </div>
                        <p class="MsoNormal"><br>
                          <br>
                          <o:p></o:p></p>
                        <pre>_______________________________________________<o:p></o:p></pre>
                        <pre>Openid-specs-ab mailing list<o:p></o:p></pre>
                        <pre><a moz-do-not-send="true" href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><o:p></o:p></pre>
                        <pre><a moz-do-not-send="true" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><o:p></o:p></pre>
                      </blockquote>
                      <p class="MsoNormal"><o:p> </o:p></p>
                    </div>
                  </div>
                </div>
                <p class="MsoNormal" style="margin-bottom:12.0pt"><br>
                  _______________________________________________<br>
                  Openid-specs-ab mailing list<br>
                  <a moz-do-not-send="true"
                    href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
                  <a moz-do-not-send="true"
                    href="http://lists.openid.net/mailman/listinfo/openid-specs-ab"
                    target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><o:p></o:p></p>
              </div>
              <p class="MsoNormal"><o:p> </o:p></p>
            </div>
          </div>
        </blockquote>
        <p class="MsoNormal"><o:p> </o:p></p>
        <div>
          <p class="MsoNormal">-- <br>
            <a moz-do-not-send="true" href="http://connect.me/gffletch"
              title="View full card on Connect.Me"><span
                style="text-decoration:none"><img id="_x0000_i1026"
                  src="cid:part15.00040400.01060300@aol.com" alt="George
                  Fletcher" border="0" width="359" height="113"></span></a><o:p></o:p></p>
        </div>
      </div>
    </blockquote>
    <br>
    <div class="moz-signature">-- <br>
      <a href="http://connect.me/gffletch" title="View full card on
        Connect.Me"><img src="cid:part17.04090103.07000407@aol.com"
          alt="George Fletcher" width="359" height="113"></a></div>
  </body>
</html>