Sorry that my connection did not work and could not join. <div><br></div><div>Several questions inline: <br><br><div class="gmail_quote">On Tue, Oct 23, 2012 at 9:52 AM, Mike Jones <span dir="ltr"><<a href="mailto:Michael.Jones@microsoft.com" target="_blank">Michael.Jones@microsoft.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





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

<br>_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Nat Sakimura (=nat)<div>Chairman, OpenID Foundation<br><a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>@_nat_en</div><br>

</div>