<div dir="ltr">I agree with Mike here. I think the language came from the reasonable assumption that a shared secret is only shared between two parties. But what delineates a party and/or how they might use a token isn't totally clear. I think leaving it unspecified is preferable at this point. <br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Oct 25, 2013 at 3:04 PM, Mike Jones <span dir="ltr"><<a href="mailto:Michael.Jones@microsoft.com" target="_blank">Michael.Jones@microsoft.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="blue" vlink="purple" lang="EN-US">
<div>
<p class="MsoNormal"><span style="color:#1f497d">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></p>
<p class="MsoNormal"><span style="color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d">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></p>
<p class="MsoNormal"><span style="color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d">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></p>
<p class="MsoNormal"><span style="color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d"> -- Mike<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d"><u></u> <u></u></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"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Torsten Lodderstedt [mailto:<a href="mailto:torsten@lodderstedt.net" target="_blank">torsten@lodderstedt.net</a>]
<br>
<b>Sent:</b> Friday, October 25, 2013 1:59 PM<br>
<b>To:</b> John Bradley<br>
<b>Cc:</b> Mike Jones; <a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a><br>
<b>Subject:</b> Re: [Openid-specs-ab] Questions about multiple audiences for ID Tokens using MAC algorithms<u></u><u></u></span></p>
</div>
</div><div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
Am 25.10.2013 um 21:40 schrieb John Bradley <<a href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>>:<u></u><u></u></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal">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></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal">I think this is only possible for id tokens issued via code grant type, right?<u></u><u></u></p>
<div>
<p class="MsoNormal"><br>
<br>
<u></u><u></u></p>
<div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">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></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
On Oct 24, 2013, at 10:32 PM, Torsten Lodderstedt <<a href="mailto:torsten@lodderstedt.net" target="_blank">torsten@lodderstedt.net</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:12.0pt;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.
<br>
<br>
Wrt 5. Yes, we should tighten it.<br>
<br>
Regards,<br>
Torsten.<u></u><u></u></span></p>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman","serif""><br>
<br>
Mike Jones <<a href="mailto:Michael.Jones@microsoft.com" target="_blank">Michael.Jones@microsoft.com</a>> schrieb:<u></u><u></u></span></p>
<p class="MsoNormal"><a href="http://openid.bitbucket.org/openid-connect-core-1_0.html#IDTokenValidation" 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></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Verdana","sans-serif"" lang="EN">7. If the
</span><tt><span style="font-size:10.0pt" lang="EN">alg</span></tt><span style="font-size:10.0pt;font-family:"Verdana","sans-serif"" lang="EN"> parameter of the JWT header is a MAC based algorithm such as
</span><tt><span style="font-size:10.0pt" lang="EN">HS256</span></tt><span style="font-size:10.0pt;font-family:"Verdana","sans-serif"" lang="EN">,
</span><tt><span style="font-size:10.0pt" lang="EN">HS384</span></tt><span style="font-size:10.0pt;font-family:"Verdana","sans-serif"" lang="EN">, or
</span><tt><span style="font-size:10.0pt" lang="EN">HS512</span></tt><span style="font-size:10.0pt;font-family:"Verdana","sans-serif"" lang="EN">, the octets of the UTF-8 representation of the
</span><tt><span style="font-size:10.0pt" lang="EN">client_secret</span></tt><span style="font-size:10.0pt;font-family:"Verdana","sans-serif"" lang="EN"> corresponding to the
</span><tt><span style="font-size:10.0pt" lang="EN">client_id</span></tt><span style="font-size:10.0pt;font-family:"Verdana","sans-serif"" lang="EN"> contained in the
</span><tt><span style="font-size:10.0pt" lang="EN">aud</span></tt><span style="font-size:10.0pt;font-family:"Verdana","sans-serif"" lang="EN"> (audience) Claim are used as the key to validate the signature.
<span style="background:yellow">Multiple audiences are not supported for MAC based algorithms.</span></span><u></u><u></u></p>
<p> <u></u><u></u></p>
<p class="MsoNormal">George wrote:<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:.5in">“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></p>
<p> <u></u><u></u></p>
<p class="MsoNormal">These questions arise:<u></u><u></u></p>
<p><u></u><span>1.<span style="font:7.0pt "Times New Roman"">
</span></span><u></u>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></p>
<p><u></u><span>2.<span style="font:7.0pt "Times New Roman"">
</span></span><u></u>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></p>
<p><u></u><span>3.<span style="font:7.0pt "Times New Roman"">
</span></span><u></u>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></p>
<p><u></u><span>4.<span style="font:7.0pt "Times New Roman"">
</span></span><u></u>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></p>
<p><u></u><span>5.<span style="font:7.0pt "Times New Roman"">
</span></span><u></u>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></p>
<p> <u></u><u></u></p>
<p class="MsoNormal"> -- Mike<u></u><u></u></p>
<p> <u></u><u></u></p>
<pre style="text-align:center"><hr align="center" size="2" width="100%"></pre>
<pre><br>Openid-specs-ab mailing list<br><a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">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><u></u><u></u></pre>
</div>
</div>
</blockquote>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman","serif"">_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">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><u></u><u></u></span></p>
</div>
</blockquote>
</div>
</div>
</div></div></div>
</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>