<div dir="ltr">Hold on, you said “mulitple 'aud' values”.  In the same ID Token... is that allowed?!?</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Oct 28, 2013 at 12:52 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">Thanks for the
      clarifications! What about combining what John and Mike said into
      something like...<br>
      <br>
      ID Tokens containing a 'azp' value SHOULD be signed with an
      asymmetric key. The verification steps for ID Tokens signed with a
      MAC based algorithm containing either mulitple 'aud' values and/or
      an 'azp' value are unspecified and out-of-scope for this document.<br>
      <br>
      Thanks,<br>
      George<br>
      <br>
    </font><div><div class="h5">
    <div>On 10/28/13 2:33 PM, John Bradley
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      I think the point of signing is so that the audience can verify
      it.  In the case that the azp is different from the audience the
      azp the token should be treated as opaque to the azp party.
      <div>I appreciate that clients may do content sniffing as they do
        in SAML in some cases.</div>
      <div><br>
      </div>
      <div>In general it is best for the AS to use a asymmetric
        signature all the time to get around these issues.</div>
      <div><br>
      </div>
      <div>The simple rule for symmetric keys is you is the one shared
        with the audience,  the use of azp should not impact that.  </div>
      <div>If that is to confusing I am OK with saying tokens containing
        azp MUST be signed with a asymmetric key and forget this corner
        case.</div>
      <div><br>
      </div>
      <div>I don't consider a token with azp one that necessarily has
        multiple audiences.  It is possible to have two or more
        audiences where one is also the azp, that defiantly needs
        asymmetric signing.</div>
      <div><br>
      </div>
      <div>John B.</div>
      <div><br>
      </div>
      <div>
        <div>
          <div>On Oct 25, 2013, at 6:04 PM, Mike Jones <<a href="mailto:Michael.Jones@microsoft.com" target="_blank">Michael.Jones@microsoft.com</a>>
            wrote:</div>
          <br>
          <blockquote type="cite">
            <div link="blue" vlink="purple" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" lang="EN-US">

              <div>
                <div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="color:rgb(31,73,125)">John, your reply didn’t answer
                    the question about which Client ID would be used if
                    the “aud” and “azp” values refer to different
                    parties.  I could see arguments for either.<u></u><u></u></span></div>
                <div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="color:rgb(31,73,125)"> </span></div>
                <div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="color:rgb(31,73,125)">Partly for that reason, I’m prone
                    to have us say that the behavior is unspecified if a
                    MAC algorithm is used and the “aud” is multi-valued
                    or if an “azp” value is present that is different
                    than the “aud” value.<u></u><u></u></span></div>
                <div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="color:rgb(31,73,125)"> </span></div>
                <div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="color:rgb(31,73,125)">That would leave the door open to
                    specify it later, but avoids us making important
                    decisions about use cases we have no experience with
                    now.<u></u><u></u></span></div>
                <div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="color:rgb(31,73,125)"> </span></div>
                <div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="color:rgb(31,73,125)">                                                               
                    -- Mike<u></u><u></u></span></div>
                <div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="color:rgb(31,73,125)"> </span></div>
                <div>
                  <div style="border-style:solid none none;border-top-color:rgb(181,196,223);border-top-width:1pt;padding:3pt 0in 0in">
                    <div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><b><span style="font-size:10pt;font-family:Tahoma,sans-serif">From:</span></b><span style="font-size:10pt;font-family:Tahoma,sans-serif"><span> </span>Torsten
                        Lodderstedt [<a href="mailto:torsten@lodderstedt.net" target="_blank">mailto:torsten@lodderstedt.net</a>]<span> </span><br>
                        <b>Sent:</b><span> </span>Friday,
                        October 25, 2013 1:59 PM<br>
                        <b>To:</b><span> </span>John
                        Bradley<br>
                        <b>Cc:</b><span> </span>Mike
                        Jones; <a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a><br>
                        <b>Subject:</b><span> </span>Re:
                        [Openid-specs-ab] Questions about multiple
                        audiences for ID Tokens using MAC algorithms<u></u><u></u></span></div>
                  </div>
                </div>
                <div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div>
                <div>
                  <div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div>
                </div>
                <div>
                  <p class="MsoNormal" style="margin:0in 0in 12pt;font-size:11pt;font-family:Calibri,sans-serif"><br>
                    Am 25.10.2013 um 21:40 schrieb John Bradley <<a href="mailto:ve7jtb@ve7jtb.com" style="color:purple;text-decoration:underline" target="_blank">ve7jtb@ve7jtb.com</a>>:<u></u><u></u></p>
                </div>
                <blockquote style="margin-top:5pt;margin-bottom:5pt">
                  <div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">A token with a
                    single audience that is different from the AZP is
                    fine to integrity protect with mac as long as there
                    the AZP is not expected to validate the token.  <u></u><u></u></div>
                </blockquote>
                <div>
                  <div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div>
                </div>
                <div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">I think this is
                  only possible for id tokens issued via code grant
                  type, right?<u></u><u></u></div>
                <div>
                  <div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><br>
                    <br>
                    <u></u><u></u></div>
                  <div>
                    <div>
                      <div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div>
                    </div>
                    <div>
                      <div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">I
                        personally think symmetric key management argues
                        that it is not scalable.  However we should not
                        preclude that use.   <br>
                        <br>
                        Sent from my iPhone<u></u><u></u></div>
                    </div>
                    <div>
                      <p class="MsoNormal" style="margin:0in 0in 12pt;font-size:11pt;font-family:Calibri,sans-serif"><br>
                        On Oct 24, 2013, at 10:32 PM, Torsten
                        Lodderstedt <<a href="mailto:torsten@lodderstedt.net" style="color:purple;text-decoration:underline" target="_blank">torsten@lodderstedt.net</a>>
                        wrote:<u></u><u></u></p>
                    </div>
                    <blockquote style="margin-top:5pt;margin-bottom:5pt">
                      <p class="MsoNormal" style="margin:0in 0in 12pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-size:12pt;font-family:'Times New Roman',serif">Hi
                          all,<br>
                          <br>
                          MAC as symmetric alg only makes sense (from a
                          security perspective) for two parties. I
                          consider sharing a symmetric key among more
                          than two parties a bad design. So in my
                          opinion this restriction makes sense.<span> </span><br>
                          <br>
                          Wrt 5. Yes, we should tighten it.<br>
                          <br>
                          Regards,<br>
                          Torsten.<u></u><u></u></span></p>
                      <div>
                        <div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span><br>
                            <br>
                            Mike Jones <<a href="mailto:Michael.Jones@microsoft.com" style="color:purple;text-decoration:underline" target="_blank">Michael.Jones@microsoft.com</a>>
                            schrieb:<u></u><u></u></span></div>
                        <div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><a href="http://openid.bitbucket.org/openid-connect-core-1_0.html#IDTokenValidation" style="color:purple;text-decoration:underline" target="_blank">http://openid.bitbucket.org/openid-connect-core-1_0.html#IDTokenValidation</a>contains
                          this text that George asked about in his
                          review:<u></u><u></u></div>
                        <div style="margin:0in 0in 0.0001pt 0.5in;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-size:10pt;font-family:Verdana,sans-serif" lang="EN">7. 
                            If the<span> </span></span><tt style="font-family:'Courier New';color:rgb(0,51,102)"><span style="font-size:10pt" lang="EN">alg</span></tt><span style="font-size:10pt;font-family:Verdana,sans-serif" lang="EN"><span> </span>parameter
                            of the JWT header is a MAC based algorithm
                            such as<span> </span></span><tt style="font-family:'Courier New';color:rgb(0,51,102)"><span style="font-size:10pt" lang="EN">HS256</span></tt><span style="font-size:10pt;font-family:Verdana,sans-serif" lang="EN">,<span> </span></span><tt style="font-family:'Courier New';color:rgb(0,51,102)"><span style="font-size:10pt" lang="EN">HS384</span></tt><span style="font-size:10pt;font-family:Verdana,sans-serif" lang="EN">, or<span> </span></span><tt style="font-family:'Courier New';color:rgb(0,51,102)"><span style="font-size:10pt" lang="EN">HS512</span></tt><span style="font-size:10pt;font-family:Verdana,sans-serif" lang="EN">, the octets
                            of the UTF-8 representation of the<span> </span></span><tt style="font-family:'Courier New';color:rgb(0,51,102)"><span style="font-size:10pt" lang="EN">client_secret</span></tt><span style="font-size:10pt;font-family:Verdana,sans-serif" lang="EN"><span> </span>corresponding
                            to the<span> </span></span><tt style="font-family:'Courier New';color:rgb(0,51,102)"><span style="font-size:10pt" lang="EN">client_id</span></tt><span style="font-size:10pt;font-family:Verdana,sans-serif" lang="EN"><span> </span>contained
                            in the</span><tt style="font-family:'Courier New';color:rgb(0,51,102)"><span style="font-size:10pt" lang="EN">aud</span></tt><span style="font-size:10pt;font-family:Verdana,sans-serif" lang="EN"><span> </span>(audience)
                            Claim are used as the key to validate the
                            signature.<span style="background-color:yellow;background-repeat:initial initial">Multiple audiences are not
                              supported for MAC based algorithms.</span></span><u></u><u></u></div>
                        <p> <u></u><u></u></p>
                        <div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">George
                          wrote:<u></u><u></u></div>
                        <div style="margin:0in 0in 0.0001pt 0.5in;font-size:11pt;font-family:Calibri,sans-serif">“Why not? Wouldn't the secret
                          associated with the azp work for the client to
                          validate the id_token?  If we want
                          interoperability across the use of audience
                          and azp we are going to need to describe how
                          it works in an extension document. It is not
                          clear from this spec how it is to work and I
                          was on most of the calls:)”<u></u><u></u></div>
                        <p> <u></u><u></u></p>
                        <div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">These
                          questions arise:<u></u><u></u></div>
                        <div style="margin:0in 0in 0.0001pt 0.5in;font-size:11pt;font-family:Calibri,sans-serif"><span>1.<span style="font-style:normal;font-variant:normal;font-weight:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'">      <span> </span></span></span>Does
                          anyone remember the history behind the
                          highlighted sentence?  I’m pretty sure that
                          this was written before we had an “azp” claim.<u></u><u></u></div>
                        <div style="margin:0in 0in 0.0001pt 0.5in;font-size:11pt;font-family:Calibri,sans-serif"><span>2.<span style="font-style:normal;font-variant:normal;font-weight:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'">      <span> </span></span></span>If
                          there’s an “azp” claim and an “aud” claim and
                          the values are different, which Client Secret
                          would be the right one to use as the key
                          value?  (George seems to be suggesting that
                          it’s the one associated with the Client ID in
                          the “azp” value.)<u></u><u></u></div>
                        <div style="margin:0in 0in 0.0001pt 0.5in;font-size:11pt;font-family:Calibri,sans-serif"><span>3.<span style="font-style:normal;font-variant:normal;font-weight:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'">      <span> </span></span></span>If
                          we did want to relax the restriction
                          prohibiting multiple audiences, which value
                          would be used for the key?  And would all the
                          parties that need to valid the ID Token
                          signature actually have access to this value?<u></u><u></u></div>
                        <div style="margin:0in 0in 0.0001pt 0.5in;font-size:11pt;font-family:Calibri,sans-serif"><span>4.<span style="font-style:normal;font-variant:normal;font-weight:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'">      <span> </span></span></span>Or
                          should we leave the text above as-is for now,
                          and deal with this case as an extension later,
                          if a need for it ever comes up?<u></u><u></u></div>
                        <div style="margin:0in 0in 0.0001pt 0.5in;font-size:11pt;font-family:Calibri,sans-serif"><span>5.<span style="font-style:normal;font-variant:normal;font-weight:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'">      <span> </span></span></span>If
                          we’re not defining how multi-valued audiences
                          would work with MAC signatures for now, should
                          we also tighten this be requiring that any
                          “azp” value that is include have the same
                          value as the single-valued audience value?<u></u><u></u></div>
                        <p> <u></u><u></u></p>
                        <div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">                                                           
                          -- Mike<u></u><u></u></div>
                        <p> <u></u><u></u></p>
                        <pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:'Courier New';text-align:center"><hr size="2" width="100%" align="center"></pre>
                        <pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:'Courier New'">Openid-specs-ab mailing list
<a href="mailto:Openid-specs-ab@lists.openid.net" style="color:purple;text-decoration:underline" target="_blank">Openid-specs-ab@lists.openid.net</a>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" style="color:purple;text-decoration:underline" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><u></u><u></u></pre>
                      </div>
                    </blockquote>
                    <blockquote style="margin-top:5pt;margin-bottom:5pt">
                      <div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span>_______________________________________________<br>
                          Openid-specs-ab mailing list<br>
                          <a href="mailto:Openid-specs-ab@lists.openid.net" style="color:purple;text-decoration:underline" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
                          <a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" style="color:purple;text-decoration:underline" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a></span></div>

                    </blockquote>
                  </div>
                </div>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      <pre>_______________________________________________
Openid-specs-ab mailing list
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
    </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:part12.08070007.02000203@aol.com" alt="George Fletcher" height="113" width="359"></a></div>
  </font></span></div>

<br>_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
<br></blockquote></div><br></div>