<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@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;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
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;}
p
        {mso-style-priority:99;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
tt
        {mso-style-priority:99;
        font-family:"Courier New";}
span.EmailStyle19
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri","sans-serif";}
@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]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Thanks for bringing this up, Brian.  Could you file this as an issue against the “errata” deliverable and the core spec at
<a href="https://bitbucket.org/openid/connect/issues?status=new&status=open">https://bitbucket.org/openid/connect/issues?status=new&status=open</a>?  We should talk about this on tomorrow morning’s working group call.  After you do, I’ll add the following as
 a comment on the 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">I think the problematic language is “the Client” in the statement below:<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">If an azp (authorized party) Claim is present, the Client SHOULD verify that its client_id is the Claim Value.<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"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">The problem is that the azp Client can be different than the requesting client.  It’s the azp Client that needs to do this validation step, not the requesting
 client.  Do people agree with this?<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>
<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""> Openid-specs-ab [mailto:openid-specs-ab-bounces@lists.openid.net]
<b>On Behalf Of </b>Brian Campbell<br>
<b>Sent:</b> Wednesday, August 05, 2015 10:11 AM<br>
<b>To:</b> <openid-specs-ab@lists.openid.net><br>
<b>Subject:</b> [Openid-specs-ab] aud & azp<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">I find the text around azp and aud to be rather unclear and I think there's a potential item for errata in it somewhere.<o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt">From the definition of <a href="https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ftools.ietf.org%2fhtml%2frfc7519%23section-4.1.3&data=01%7c01%7cMichael.Jones%40microsoft.com%7ca97947375f324b13278508d29db9ea16%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=UgVDJXRprGpK9ESVc5UcfRhoeVyqF4FqAreai1hKE%2b8%3d">
"aud" in JWT</a> and its use in <a href="https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fopenid.net%2fspecs%2fopenid-connect-core-1_0.html%23IDToken&data=01%7c01%7cMichael.Jones%40microsoft.com%7ca97947375f324b13278508d29db9ea16%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=UqyFRA5dyeXsDvmbmwVJeZWrboUbFWN%2bR9OpJpvIG0c%3d">
Connect's ID Token</a> (relevant spec text is copied below), it seems that that the client id of the client/RP that made the authentication request has to be one of the values, or the only value, of the "aud" claim in the ID Token. That's logical and consistent
 and provides reliable and interoperable guidance to implementers about producing and consuming the ID Token. I think that the client id of the RP/client that made the authentication request should always be represented in the aud of the returned ID Token.
<o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt">The text around "azp" in the <a href="https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fopenid.net%2fspecs%2fopenid-connect-core-1_0.html%23IDToken&data=01%7c01%7cMichael.Jones%40microsoft.com%7ca97947375f324b13278508d29db9ea16%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=UqyFRA5dyeXsDvmbmwVJeZWrboUbFWN%2bR9OpJpvIG0c%3d">
ID Token section</a> and the <a href="https://na01.safelinks.protection.outlook.com/?url=+http%3a%2f%2fopenid.net%2fspecs%2fopenid-connect-core-1_0.html%23IDTokenValidation&data=01%7c01%7cMichael.Jones%40microsoft.com%7ca97947375f324b13278508d29db9ea16%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=LrFoSF%2bqjC75ilCneT3yFXJ30Nu8nu%2fbsj5LiEKJkus%3d">
ID Token Validation section</a> seems to maybe suggest something different, however. Like perhaps that the client id of the RP/client that made the authentication request could, in some totally unspecified circumstance, be the value of the azp claim and that
 the aud would not identify that client as an intended recipient. Am I misinterpreting things? I hope so because that seems like it'd be fragile from an interop perspective and is certainly more cumbersome for general JWT libraries to support.
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<p class="MsoNormal"><br>
from <a href="https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ftools.ietf.org%2fhtml%2frfc7519%23section-4.1.3&data=01%7c01%7cMichael.Jones%40microsoft.com%7ca97947375f324b13278508d29db9ea16%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=UgVDJXRprGpK9ESVc5UcfRhoeVyqF4FqAreai1hKE%2b8%3d">
http://tools.ietf.org/html/rfc7519#section-4.1.3</a><br>
<br>
 4.1.3.  "aud" (Audience) Claim<br>
<br>
   The "aud" (audience) claim identifies the recipients that the JWT is<br>
   intended for.  Each principal intended to process the JWT MUST<br>
   identify itself with a value in the audience claim.  If the principal<br>
   processing the claim does not identify itself with a value in the<br>
   "aud" claim when this claim is present, then the JWT MUST be<br>
   rejected.  In the general case, the "aud" value is an array of case-<br>
   sensitive strings, each containing a StringOrURI value.  In the<br>
   special case when the JWT has one audience, the "aud" value MAY be a<br>
   single case-sensitive string containing a StringOrURI value.  The<br>
   interpretation of audience values is generally application specific.<br>
   Use of this claim is OPTIONAL.<br>
<br>
<br>
from <a href="https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fopenid.net%2fspecs%2fopenid-connect-core-1_0.html%23IDToken&data=01%7c01%7cMichael.Jones%40microsoft.com%7ca97947375f324b13278508d29db9ea16%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=UqyFRA5dyeXsDvmbmwVJeZWrboUbFWN%2bR9OpJpvIG0c%3d">
http://openid.net/specs/openid-connect-core-1_0.html#IDToken</a><o:p></o:p></p>
<p class="MsoNormal">  ...  <o:p></o:p></p>
<p class="MsoNormal">  aud<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">REQUIRED. Audience(s) that this ID Token is intended for. It MUST contain the OAuth 2.0
<tt><span style="font-size:10.0pt">client_id</span></tt> of the Relying Party as an audience value. It MAY also contain identifiers for other audiences. In the general case, the
<tt><span style="font-size:10.0pt">aud</span></tt> value is an array of case sensitive strings. In the common special case when there is one audience, the
<tt><span style="font-size:10.0pt">aud</span></tt> value MAY be a single case sensitive string.
<o:p></o:p></p>
<p>  ...<o:p></o:p></p>
<p class="MsoNormal">  azp<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">OPTIONAL. Authorized party - the party to which the ID Token was issued. If present, it MUST contain the OAuth 2.0 Client ID of this party. This Claim is only needed when the ID Token has a single audience value
 and that audience is different than the authorized party. It MAY be included even when the authorized party is the same as the sole audience. The
<tt><span style="font-size:10.0pt">azp</span></tt> value is a case sensitive string containing a StringOrURI value.
<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">  ...<br>
<br>
from <a href="https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fopenid.net%2fspecs%2fopenid-connect-core-1_0.html%23IDTokenValidation&data=01%7c01%7cMichael.Jones%40microsoft.com%7ca97947375f324b13278508d29db9ea16%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ko0MzMkFxNMQmWPYs%2fPYGgMvPE2m%2bhuj4vIUBIwyz1M%3d">
http://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation</a><br>
<br>
  Clients MUST validate the ID Token in the Token Response in the following manner:
<o:p></o:p></p>
<div style="margin-left:30.0pt">
<p class="MsoNormal" style="margin-bottom:12.0pt">...<br>
4. If the ID Token contains multiple audiences, the Client SHOULD verify that an azp Claim is present.<br>
...<br>
5. If an azp (authorized party) Claim is present, the Client SHOULD verify that its client_id is the Claim Value.<br>
...<br>
8 If the JWT alg Header Parameter uses a MAC based algorithm such as HS256, HS384, or HS512, the octets of the UTF-8 representation of the client_secret corresponding to the client_id contained in the aud (audience) Claim are used as the key to validate the
 signature. For MAC based algorithms, the behavior is unspecified if the aud is multi-valued or if an azp value is present that is different than the aud value.<br>
The current time MUST be before the time represented by the exp Claim. <br>
<br>
<br>
<br>
<o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>