<div dir="ltr">
















<div style="border:none;border-bottom:double windowtext 2.25pt;padding:0mm 0mm 1.0pt 0mm">

<p class="MsoNormal" style="border:none;padding:0mm">AB/Connect WG Call Note
(2015-08-06)</p>

</div><p class="MsoNormal">Attending: Nat, Brian, Mike, John</p><p class="MsoNormal"> </p><div style="border:none;border-bottom:solid windowtext 1.0pt;padding:0mm 0mm 1.0pt 0mm">

<p class="MsoListParagraph" style="margin-left:18.0pt;border:none;padding:0mm"><span style="mso-fareast-font-family:Century;mso-fareast-theme-font:minor-latin;
mso-bidi-font-family:Century;mso-bidi-theme-font:minor-latin"><span style="mso-list:Ignore">1.<span style="font:7.0pt "Times New Roman"">   
</span></span></span>Issues</p>

</div><p class="MsoNormal">#973: Core 2/ 3.1.3.7 – azp claim underspecified. </p><p class="MsoNormal">Discussed about the semantics of azp. </p><p class="MsoNormal">The difference between current description text of aud and
azp </p><p class="MsoNormal">is way too subtle. The intention of the azp was that it is
not the </p><p class="MsoNormal">requesting party nor consuming party but it is the party who
is </p><p class="MsoNormal">presenting/exercising the token. </p><p class="MsoNormal">In Google’s model, Google Play Store gets the token using </p><p class="MsoNormal">refresh token, and hands the token to the app so that the
app </p><p class="MsoNormal">can use it. The requesting party of the token in this case
is </p><p class="MsoNormal">Google Play store, while the authorized presenting party
(azp) is </p><p class="MsoNormal">the app. </p><p class="MsoNormal"> </p><p class="MsoNormal">Brian and Nat has independently asked the current use of azp
</p><p class="MsoNormal">at Google recently and still waiting for the answer. </p><p class="MsoNormal"> </p><p class="MsoNormal">It was first introduced in <span style="font-size:10.0pt;font-family:Times"><a href="https://bitbucket.org/openid/connect/issues/636/jwt-intermediate-audience-claim" title="#636: JWT - intermediate audience claim"><span style="font-size:10.5pt;font-family:Arial;color:#3572b0;background:whitesmoke;text-decoration:none">#636: JWT - intermediate audience claim</span></a></span></p><p class="MsoNormal">and the the claim name was decided to be azp by the </p><p class="MsoNormal">Dec. 20, 2012 call. </p><p class="MsoNormal"> </p><p class="MsoNormal">WG decided to table this issue and do some study on the call
note and come back to it. </p><p class="MsoNormal"> </p><p class="MsoNormal" align="left" style="text-align:left"><span style="font-size:10.0pt;font-family:Times"><a href="https://bitbucket.org/openid/connect/issues/968/inconsistent-treatment-of-id_token_hint" title="#968: inconsistent treatment of id_token_hint"><span style="font-size:10.5pt;font-family:Arial;color:#3572b0;background:whitesmoke;text-decoration:none">#968: inconsistent treatment of id_token_hint</span></a></span></p><p class="MsoNormal">This issue was file by Brian. The WG discussed about this
back in Tuesday call and found out that the seeming inconsistency comes from
the fact that paragraphs are talking about two different cases: </p><p class="MsoNormal">- Interactive case; and </p><p class="MsoNormal">- prompt=none case. </p><p class="MsoNormal">Brian agreed to it. Mike will propose a new language. </p><p class="MsoNormal"> </p><p class="MsoNormal" align="left" style="text-align:left"><span style="font-size:10.0pt;font-family:Times"><a href="https://bitbucket.org/openid/connect/issues/966/error-code-claims_not_supported-should" title="#966: Error code claims_not_supported should have been defined"><span style="font-size:10.5pt;font-family:Arial;color:#3572b0;background:whitesmoke;text-decoration:none">#966: Error code claims_not_supported
should have been defined</span></a></span><span style="font-size:10.5pt;font-family:Arial;color:#333333;background:whitesmoke"> </span><span style="font-size:10.0pt;font-family:Times"> </span></p><p class="MsoNormal">This bug report was asking for error code for claims not
supported. </p><p class="MsoNormal">However, the decision of the WG back then was to return
something reasonable rather than returning an error. This is why an error code
was not assigned to this. It was intentional. </p><p class="MsoNormal"> </p><p class="MsoNormal">The issue was closed as invalid. </p><p class="MsoNormal"> </p><p class="MsoNormal">RP Certification: Roland working on bugs. </p><p class="MsoNormal">WG decided that it would be a good idea to automatically
send the bug ticket to Roland’s team, instead of having Roland forward them. </p><p class="MsoNormal">Mike will dig out their ML address. We will figure out how
to configure the issue tracker. </p><p class="MsoNormal"> </p><div style="border:none;border-bottom:solid windowtext 1.0pt;padding:0mm 0mm 1.0pt 0mm">

<p class="MsoListParagraph" style="margin-left:18.0pt;border:none;padding:0mm"><span style="mso-fareast-font-family:Century;mso-fareast-theme-font:minor-latin;
mso-bidi-font-family:Century;mso-bidi-theme-font:minor-latin"><span style="mso-list:Ignore">2.<span style="font:7.0pt "Times New Roman"">   
</span></span></span>AOB</p>

</div><p class="MsoNormal">JP Conference Info: As it has been noted, the estimated
delivery time of the initial site is at the end of the week. </p><p class="MsoNormal">Okinawa conference information has already been sent to the
Board. </p><p class="MsoNormal">










































































































</p><p class="MsoNormal">It is co-hosted by WEF. Invitation Only. Pretty high level. Probably
non technical. </p>
</div>