<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=us-ascii">
<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;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-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;}
span.EmailStyle17
        {mso-style-type:personal-compose;
        font-family:"Calibri","sans-serif";
        color:windowtext;}
.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">Spec call notes 31-Aug-15<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Mike Jones<o:p></o:p></p>
<p class="MsoNormal">John Bradley<o:p></o:p></p>
<p class="MsoNormal">Edmund Jay<o:p></o:p></p>
<p class="MsoNormal">Nat Sakimura<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Agenda<o:p></o:p></p>
<p class="MsoNormal">                Errata and Issues<o:p></o:p></p>
<p class="MsoNormal">                Workshop before IIW<o:p></o:p></p>
<p class="MsoNormal">                Workshop after IETF 94 Yokohama<o:p></o:p></p>
<p class="MsoNormal">                Certification<o:p></o:p></p>
<p class="MsoNormal">                Next Call<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Errata and Issues<o:p></o:p></p>
<p class="MsoNormal">                #968 - Inconsistent treatment of id_token_hint<o:p></o:p></p>
<p class="MsoNormal">                                Mike will apply the proposed resolution and then have people review the result<o:p></o:p></p>
<p class="MsoNormal">                #970 - Core - 2 - ID Token acr claim incorrectly specifies the level 0 of assurance<o:p></o:p></p>
<p class="MsoNormal">                                John still needs to take a stab at new wording saying what "0" meant historically<o:p></o:p></p>
<p class="MsoNormal">                #973 - Core 2 / 3.1.3.7 - azp claim underspecified and overreaching<o:p></o:p></p>
<p class="MsoNormal">                                We got data on what Google is actually doing with "azp"<o:p></o:p></p>
<p class="MsoNormal">                                Notably, it is not used in an OpenID Connect protocol flow<o:p></o:p></p>
<p class="MsoNormal">                                Brian's comment "Rather Connect should strive for something that's consistent and easily comprehensible" seems dead on<o:p></o:p></p>
<p class="MsoNormal">                                Mike will take a stab at slightly revised wording following Brian's suggestions<o:p></o:p></p>
<p class="MsoNormal">                                John suggests that RPs reject tokens with "azp" unless they understand what is going on<o:p></o:p></p>
<p class="MsoNormal">                #974 - Deprecated algorithm RSA1_5 used in spec examples and self-issued<o:p></o:p></p>
<p class="MsoNormal">                                We should clearly change the examples<o:p></o:p></p>
<p class="MsoNormal">                                Self-issued is a more intricate issue<o:p></o:p></p>
<p class="MsoNormal">                                Mike suggests that we're probably better off deprecating singing and encrypting with the same key<o:p></o:p></p>
<p class="MsoNormal">                                John says that encrypting to the client is an edge case<o:p></o:p></p>
<p class="MsoNormal">                                                You can only do this upon the second interaction with the provider!<o:p></o:p></p>
<p class="MsoNormal">                #975 - Do we add additional related specifications?<o:p></o:p></p>
<p class="MsoNormal">                                Mike will do<o:p></o:p></p>
<p class="MsoNormal">                #976 - Unregistered openid2_realm and openid2_id<o:p></o:p></p>
<p class="MsoNormal">                                Mike will prepare text that registers these values.<o:p></o:p></p>
<p class="MsoNormal">                #977 - How to handle an unsupported response_mode?<o:p></o:p></p>
<p class="MsoNormal">                                John pointed out that if you don't support the response_mode, you can't even return error and error_description<o:p></o:p></p>
<p class="MsoNormal">                                Therefore, we'll return 400.<o:p></o:p></p>
<p class="MsoNormal">                #978 - URL for errata<o:p></o:p></p>
<p class="MsoNormal">                                Mike documented our existing practice in the bug<o:p></o:p></p>
<p class="MsoNormal">                                We should probably make a blog post saying how other specs can reference current versions and specific versions, as makes sense in their use cases.<o:p></o:p></p>
<p class="MsoNormal">                                We could explicitly put language about URLs for the current and this versions in the spec, like the W3C does<o:p></o:p></p>
<p class="MsoNormal">                #979 - Discovery / Security Considerations: CSRF attack on user input identifier<o:p></o:p></p>
<p class="MsoNormal">                                We need to work out how to prevent MITM attacks against Dynamic Registration<o:p></o:p></p>
<p class="MsoNormal">                                The attack is getting someone to talk to a bad token endpoint<o:p></o:p></p>
<p class="MsoNormal">                                You don't know that you've registered at the right endpoint when you register<o:p></o:p></p>
<p class="MsoNormal">                                This issue clearly needs discussion on the mailing list.<o:p></o:p></p>
<p class="MsoNormal">                                One possible fix is to have registration return the token endpoint URL for a cross-check<o:p></o:p></p>
<p class="MsoNormal">                                Mike points out that in multi-tenant environment, the issuer will vary by tenant<o:p></o:p></p>
<p class="MsoNormal">                                We may want to look at how we're using the JWT token profile<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">                See the "Discovery Endpoint CORS support?" e-mail thread<o:p></o:p></p>
<p class="MsoNormal">                                Mike will file an issue about this<o:p></o:p></p>
<p class="MsoNormal">                                You need CORS support for JavaScript clients<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">                People should add any other errata issues to the tracker at<o:p></o:p></p>
<p class="MsoNormal">                                https://bitbucket.org/openid/connect/issues?status=new&status=open<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Workshop before IIW<o:p></o:p></p>
<p class="MsoNormal">                People are registering<o:p></o:p></p>
<p class="MsoNormal">                http://www.eventbrite.com/e/openid-foundation-workshop-before-fall-2015-iiw-meeting-tickets-17960843366<o:p></o:p></p>
<p class="MsoNormal">                Nat needs to be removed from the agenda since he won't be able to attend<o:p></o:p></p>
<p class="MsoNormal">                Roland will be there and will do live RP test demonstrations<o:p></o:p></p>
<p class="MsoNormal">                Mike will ask Don if "HMG Cabinet Office Chairs" is correct for HEART<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Workshop after IETF 94 Yokohama<o:p></o:p></p>
<p class="MsoNormal">                http://www.eventbrite.com/e/openid-summit-tokyo-2015-tickets-18111127871<o:p></o:p></p>
<p class="MsoNormal">                Registration is not yet open for that<o:p></o:p></p>
<p class="MsoNormal">                Registrations may actually happen on a different Japanese page<o:p></o:p></p>
<p class="MsoNormal">                Nat translated the Japanese event page to English at http://j.mp/cfp_oid15<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Certification<o:p></o:p></p>
<p class="MsoNormal">                Roland fixed some RP certification bugs but his WebFinger responses use https://localhost:8080/<o:p></o:p></p>
<p class="MsoNormal">                Edmund has reported this to Roland<o:p></o:p></p>
<p class="MsoNormal">                Roland is officially back from vacation tomorrow (Tuesday)<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Next Call<o:p></o:p></p>
<p class="MsoNormal">                On Thursday September 3rd at the European-Friendly time of 7am Pacific this week<o:p></o:p></p>
<p class="MsoNormal">                We are cancelling the Monday September 7th call, which falls on the US Labor Day holiday<o:p></o:p></p>
</div>
</body>
</html>