<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">Connect Working Group Meeting at Google 22-Oct-12<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Attendees:<o:p></o:p></p>
<p class="MsoNormal">Tim Bray - Google identity team - developer facing<o:p></o:p></p>
<p class="MsoNormal">Naveen Agarwal - Google identity tem<o:p></o:p></p>
<p class="MsoNormal">Mike Jones - Microsoft identity standards and policy team<o:p></o:p></p>
<p class="MsoNormal">Brian Campbell - Ping Identity<o:p></o:p></p>
<p class="MsoNormal">Chuck Mortimore - Salesforce<o:p></o:p></p>
<p class="MsoNormal">George Fletcher - AOL<o:p></o:p></p>
<p class="MsoNormal">Adam Dawes - Google identity team<o:p></o:p></p>
<p class="MsoNormal">Breno de Medeiros - Google identity team<o:p></o:p></p>
<p class="MsoNormal">Chunlei Niu - Google identity team<o:p></o:p></p>
<p class="MsoNormal">Axel Nennker - Deutsche Telekom<o:p></o:p></p>
<p class="MsoNormal">Andreas Leicher - Novalyst IT<o:p></o:p></p>
<p class="MsoNormal">Mike Schwartz - Gluu<o:p></o:p></p>
<p class="MsoNormal">Scott Kern - Identity at Verizon<o:p></o:p></p>
<p class="MsoNormal">John Elkaim- BlueID<o:p></o:p></p>
<p class="MsoNormal">Alex Chong - Verizon<o:p></o:p></p>
<p class="MsoNormal">Brian Berliner - Symantec, personal<o:p></o:p></p>
<p class="MsoNormal">Morteza Ansari<o:p></o:p></p>
<p class="MsoNormal">Edmund Jay - Illumila<o:p></o:p></p>
<p class="MsoNormal">Tom Brown<o:p></o:p></p>
<p class="MsoNormal">Greg Keegstra - Janrain<o:p></o:p></p>
<p class="MsoNormal">Lucy Lynch - Internet Society<o:p></o:p></p>
<p class="MsoNormal">Amanda Anganes - Mitre<o:p></o:p></p>
<p class="MsoNormal">Justin Richer - Mitre<o:p></o:p></p>
<p class="MsoNormal">Johnny Bufu - Janrain<o:p></o:p></p>
<p class="MsoNormal">Don Thibeau - OpenID Foundation executive director<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">IPR Reminder<o:p></o:p></p>
<p class="MsoNormal">Introductions<o:p></o:p></p>
<p class="MsoNormal">Agenda Discussion<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Session Management<o:p></o:p></p>
<p class="MsoNormal">               Session management open issues<o:p></o:p></p>
<p class="MsoNormal">                              #650 Session - Dependency on Third Party Cookies<o:p></o:p></p>
<p class="MsoNormal">                                             Agreed that no means to fix this, short of new browser technology<o:p></o:p></p>
<p class="MsoNormal">                              #605 Session Sec 2 - op_logout_url description<o:p></o:p></p>
<p class="MsoNormal">                                             Needs clarification in the spec<o:p></o:p></p>
<p class="MsoNormal">                              #634 Session 5 - Re-redirection to RP after the OP logout, or no redirection logout<o:p></o:p></p>
<p class="MsoNormal">                                             Agreed that need continue URL, including possibility of continuing if user chooses not to logout<o:p></o:p></p>
<p class="MsoNormal">                              #635 Session - 4.1 Format of hash and salt<o:p></o:p></p>
<p class="MsoNormal">                                             Lots of discussion - to be continued at IIW<o:p></o:p></p>
<p class="MsoNormal">               Breno gave an overview of Session Management<o:p></o:p></p>
<p class="MsoNormal">               They want all validation to occur within the OP frame<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">#595: Discovery 2 - No means of discovery without web server for domain<o:p></o:p></p>
<p class="MsoNormal">               Possibilities:<o:p></o:p></p>
<p class="MsoNormal">                              DNS based solution<o:p></o:p></p>
<p class="MsoNormal">                                             Can be hard for administrators to do<o:p></o:p></p>
<p class="MsoNormal">                                             Can be hard for clients to use - DNS lookup may not be available<o:p></o:p></p>
<p class="MsoNormal">                                             A lot of DNS registrars don't expose SRV records<o:p></o:p></p>
<p class="MsoNormal">                                             Agreement that this is not a viable solution<o:p></o:p></p>
<p class="MsoNormal">                              Broker aggregator<o:p></o:p></p>
<p class="MsoNormal">                                             Delegate to trusted third party<o:p></o:p></p>
<p class="MsoNormal">                                             Somewhat analogous to Account Chooser<o:p></o:p></p>
<p class="MsoNormal">                              Domain prefix<o:p></o:p></p>
<p class="MsoNormal">                                             simple-web-discovery.example.com or<o:p></o:p></p>
<p class="MsoNormal">                                             simple-web-discovery.well-known.example.com<o:p></o:p></p>
<p class="MsoNormal">                                             Agreed that we should publish a SWD draft with this approach<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">#604: All - Create a MTI section<o:p></o:p></p>
<p class="MsoNormal">               OpenID request object for claims requests MTI<o:p></o:p></p>
<p class="MsoNormal">               RSA signing mandatory to implement<o:p></o:p></p>
<p class="MsoNormal">               Johnny said that this effectively makes discovery MTI<o:p></o:p></p>
<p class="MsoNormal">                              John Bradley said that cert could be communicated out of band<o:p></o:p></p>
<p class="MsoNormal">               Justin and Tim said that discovery and registration are needed for "cold boot" case<o:p></o:p></p>
<p class="MsoNormal">               Discussion moved to the distinction between the "open" case and the "cold" case<o:p></o:p></p>
<p class="MsoNormal">               We agreed that the userinfo endpoint is required for the open cases and optional for the closed case<o:p></o:p></p>
<p class="MsoNormal">               Breno said that we may want a discovery error saying that static registration is required<o:p></o:p></p>
<p class="MsoNormal">               People didn't think that requiring signing the userinfo response<o:p></o:p></p>
<p class="MsoNormal">               OPs can ignore acr if they don't understand it<o:p></o:p></p>
<p class="MsoNormal">               preferred_locales is MTI, in the sense that it must not throw an exception<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">#633: Messages - 4.2 JWK and X509 format support<o:p></o:p></p>
<p class="MsoNormal">               OPs must support X.509<o:p></o:p></p>
<p class="MsoNormal">               We should work with JOSE to ensure that self-signed certs are supported<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">#601: Standard - No way of doing IdP initiated login defined<o:p></o:p></p>
<p class="MsoNormal">               Justin proposed a flow that adds an OP -> RP message that then starts the normal login flow<o:p></o:p></p>
<p class="MsoNormal">                              Breno said that that mitigates session fixation attacks but not XSRF attacks<o:p></o:p></p>
<p class="MsoNormal">               John proposed to just send a response message (like SAML)<o:p></o:p></p>
<p class="MsoNormal">                              It would have a special state value saying that this is an IdP-initiated login<o:p></o:p></p>
<p class="MsoNormal">               Breno pointed out that the security details matter<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">#668: Messages,Multi Response - Cope with bloating id_token_hint in self-issued cases<o:p></o:p></p>
<p class="MsoNormal">               People still don't like having another OAuth response_type<o:p></o:p></p>
<p class="MsoNormal">                              They thought that multiple id_token response types was worse<o:p></o:p></p>
<p class="MsoNormal">               Chuck suggested a profile for push messaging to the phone to retrieve claims<o:p></o:p></p>
<p class="MsoNormal">               People agreed that the current solution is at least a local maximum, and to leave it as-is<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">#636: JWT - intermediate audience claim<o:p></o:p></p>
<p class="MsoNormal">               Breno proposed a requested audience parameter<o:p></o:p></p>
<p class="MsoNormal">               Google's ID tokens contain an audience and a client_id<o:p></o:p></p>
<p class="MsoNormal">                              The requested audience is used to request a different audience than the client_id<o:p></o:p></p>
<p class="MsoNormal">               This is rooted in the fact that most providers require the client_id for web and mobile clients to be different<o:p></o:p></p>
<p class="MsoNormal">                              Breno suggested we may need rules for when it's safe to accept an ID token issued to a mobile client<o:p></o:p></p>
<p class="MsoNormal">               John asserted that this is a bad pattern<o:p></o:p></p>
<p class="MsoNormal">               We will discuss this more at IIW<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">#539: Messages - 0. Add scope for offline access<o:p></o:p></p>
<p class="MsoNormal">               We adopted George's proposal<o:p></o:p></p>
<p class="MsoNormal">               We invite continued review<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">#656: Discovery - 4.2 Provider Configuration File does not specify what optional parameters the server accepts<o:p></o:p></p>
<p class="MsoNormal">               We do want optional functionality to be discoverable<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">#653: Registration - 2.1 policy_url SHOULD be displayed?<o:p></o:p></p>
<p class="MsoNormal">               Justin added that if you can't trust the source of the privacy URL, it doesn't add any value<o:p></o:p></p>
<p class="MsoNormal">               We will leave this a SHOULD<o:p></o:p></p>
<p class="MsoNormal">               Naveen said that the policy URL should be different from the terms of service URL<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">#628: Discovery 3.2 - need a strict JSON structure<o:p></o:p></p>
<p class="MsoNormal">               This pertains to the different layers of MTI<o:p></o:p></p>
<p class="MsoNormal">                              In the "open" case, some parameters will be required<o:p></o:p></p>
<p class="MsoNormal">                              Chuck suggested different terminology than "open"<o:p></o:p></p>
<p class="MsoNormal">                                             Amanda suggested possibly "dynamic"<o:p></o:p></p>
<p class="MsoNormal">                                             Lucy suggested "negotiated"<o:p></o:p></p>
<p class="MsoNormal">                                             John suggested "out-of-band"<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">#667: Registration - Restructuring<o:p></o:p></p>
<p class="MsoNormal">               This seems OK<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Sessions to hold at IIW:<o:p></o:p></p>
<p class="MsoNormal">               Session management parameters<o:p></o:p></p>
<p class="MsoNormal">               On-behalf-of / delegation<o:p></o:p></p>
<p class="MsoNormal">               Hybrid applications (mobile applications with a web back end)<o:p></o:p></p>
<p class="MsoNormal">               Intermediate audience claim / multi-level application security<o:p></o:p></p>
<p class="MsoNormal">               IdP initiated login<o:p></o:p></p>
</div>
</body>
</html>