<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 21-Sep-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">Edmund Jay<o:p></o:p></p>
<p class="MsoNormal">William Denniss<o:p></o:p></p>
<p class="MsoNormal">John Bradley<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Nat Sakimura<o:p></o:p></p>
<p class="MsoNormal">Brian Campbell<o:p></o:p></p>
<p class="MsoNormal">Nov Matake<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"> HTTP-Based Logout<o:p></o:p></p>
<p class="MsoNormal"> Session ID in Back-Channel Logout<o:p></o:p></p>
<p class="MsoNormal"> Session ID in HTTP-Based Logout<o:p></o:p></p>
<p class="MsoNormal"> New Issues<o:p></o:p></p>
<p class="MsoNormal"> Fast Identity Verification<o:p></o:p></p>
<p class="MsoNormal"> Workshop before IIW<o:p></o:p></p>
<p class="MsoNormal"> Tokyo workshop after IETF 94 Yokohama<o:p></o:p></p>
<p class="MsoNormal"> Certification<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">HTTP-Based Logout<o:p></o:p></p>
<p class="MsoNormal"> Mike described a request from Microsoft developers to be able to have multiple logout URLs for HTTP-based logout<o:p></o:p></p>
<p class="MsoNormal"> Just like you can have multiple redirect URIs<o:p></o:p></p>
<p class="MsoNormal"> Mike described two possible approaches:<o:p></o:p></p>
<p class="MsoNormal"> either having parallel arrays - one logout URL per redirect URI<o:p></o:p></p>
<p class="MsoNormal"> or reusing the redirect_uri value with a logout query parameter<o:p></o:p></p>
<p class="MsoNormal"> William talked about Google having related Client IDs, which share approval state<o:p></o:p></p>
<p class="MsoNormal"> So the front channel logout spec would work fine for them as-is<o:p></o:p></p>
<p class="MsoNormal"> John talked about the principle of pushing complexity to the server<o:p></o:p></p>
<p class="MsoNormal"> No adding client semantics to overload an endpoint<o:p></o:p></p>
<p class="MsoNormal"> Mike will ask the developers about having multiple client IDs instead<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Session ID in Back-Channel Logout<o:p></o:p></p>
<p class="MsoNormal"> It gives you an identifier for the user agent, which you don't have on the back-channel<o:p></o:p></p>
<p class="MsoNormal"> John says that it may or may not be a correlation handle<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Session ID in HTTP-Based Logout<o:p></o:p></p>
<p class="MsoNormal"> Mike: Do we want to pass an optional logout token instead of an optional session ID?<o:p></o:p></p>
<p class="MsoNormal"> This would make the back-channel and front-channel approaches more alike<o:p></o:p></p>
<p class="MsoNormal"> John is worried about size issues in this approach on the front-channel<o:p></o:p></p>
<p class="MsoNormal"> Mike: The current approach doesn't pass an issuer & subject, which you probably actually want<o:p></o:p></p>
<p class="MsoNormal"> Mike will send e-mail asking people to compare the two approaches<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">New Issues<o:p></o:p></p>
<p class="MsoNormal"> #983 - Create Backchannel Logout spec<o:p></o:p></p>
<p class="MsoNormal"> We should close this as a duplicate of issue #922<o:p></o:p></p>
<p class="MsoNormal"> #984 - Create a document explaining "single logout" semantics<o:p></o:p></p>
<p class="MsoNormal"> A volunteer to write this is needed<o:p></o:p></p>
<p class="MsoNormal"> William is willing to review and collaborate<o:p></o:p></p>
<p class="MsoNormal"> #985 - Use Bearer in token_type in Implicit Flow response example<o:p></o:p></p>
<p class="MsoNormal"> http://tools.ietf.org/html/rfc6749#section-4.2.2 says that the identifier is case-insensitive.<o:p></o:p></p>
<p class="MsoNormal"> So this is fine as-is. We should discuss further whether to change the example or not.<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"> This is about an attacker getting someone to do discovery on a bad discovery document<o:p></o:p></p>
<p class="MsoNormal"> The bad document might use a legitimate site for dynamic client registration<o:p></o:p></p>
<p class="MsoNormal"> The attacker then has the code and credentials to get a token at the good site<o:p></o:p></p>
<p class="MsoNormal"> We have to do something so that people know they have registered at the right place<o:p></o:p></p>
<p class="MsoNormal"> You don't current get the issuer identifier back from Registration<o:p></o:p></p>
<p class="MsoNormal"> John thinks we have to fix this in Registration<o:p></o:p></p>
<p class="MsoNormal"> It's a kind of fixation attack, which leads to a man-in-the-middle<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Fast Identity Verification<o:p></o:p></p>
<p class="MsoNormal"> William told us that FastIDV is an optimization Google is using for OpenID Connect<o:p></o:p></p>
<p class="MsoNormal"> It's designed to avoid double consent if the user has already typed their e-mail address<o:p></o:p></p>
<p class="MsoNormal"> It's more subtle than it at first appears<o:p></o:p></p>
<p class="MsoNormal"> For instance, not allow use with prompt=none<o:p></o:p></p>
<p class="MsoNormal"> There is no new parameter<o:p></o:p></p>
<p class="MsoNormal"> If certain conditions are true, they give the request special treatment<o:p></o:p></p>
<p class="MsoNormal"> William wrote a draft documenting FastIDV: https://wdenniss.com/fastidv<o:p></o:p></p>
<p class="MsoNormal"> Conditions when FastIDV applies are in Section 4.1 - https://wdenniss.com/fastidv#rfc.section.4.1<o:p></o:p></p>
<p class="MsoNormal"> The effect is to skip an interactive dialog when the conditions are true<o:p></o:p></p>
<p class="MsoNormal"> If there's interest, it could become a specification or a deployment guide<o:p></o:p></p>
<p class="MsoNormal"> Section 5 does specify new discovery values<o:p></o:p></p>
<p class="MsoNormal"> John stated that this is clearly the right working group<o:p></o:p></p>
<p class="MsoNormal"> Mike suggested that William e-mail a copy of the spec as a contribution to the working group and ask for feedback<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"> http://www.eventbrite.com/e/openid-foundation-workshop-before-fall-2015-iiw-meeting-tickets-17960843366<o:p></o:p></p>
<p class="MsoNormal"> It is currently listed as sold out - we need to talk with Don and Symantec about that<o:p></o:p></p>
<p class="MsoNormal"> We believe that Adam has a conflict, and if so, couldn't do the RISC presentation<o:p></o:p></p>
<p class="MsoNormal"> The NAPPS session should talk about possible reorganization of NAPPS<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Tokyo workshop after IETF 94 Yokohama<o:p></o:p></p>
<p class="MsoNormal"> We don't have any updates on the workshop<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, but there will be an English registration 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"> Session proposals are due by the end of the month<o:p></o:p></p>
<p class="MsoNormal"> People should submit them soon so the timeslots aren't taken by other things<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"> Edmund reported that there are a few more issues<o:p></o:p></p>
<p class="MsoNormal"> Mostly about locating signature and encryption keys<o:p></o:p></p>
<p class="MsoNormal"> There are issues files in the tracker for these<o:p></o:p></p>
<p class="MsoNormal"> https://bitbucket.org/openid/certification/issues?status=new&status=open<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>