<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">OpenID Connect Meeting at ForgeRock 27-Feb-14<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Allan Foster<o:p></o:p></p>
<p class="MsoNormal">Chuck Mortimore<o:p></o:p></p>
<p class="MsoNormal">Caleb Baker<o:p></o:p></p>
<p class="MsoNormal">Roland Hedberg<o:p></o:p></p>
<p class="MsoNormal">Mike Jones<o:p></o:p></p>
<p class="MsoNormal">Pamela Dingle<o:p></o:p></p>
<p class="MsoNormal">Chuck Mortimore<o:p></o:p></p>
<p class="MsoNormal">Greg Keegstra<o:p></o:p></p>
<p class="MsoNormal">Garyl Erickson<o:p></o:p></p>
<p class="MsoNormal">Naveen Agarwal<o:p></o:p></p>
<p class="MsoNormal">Guibin Kong<o:p></o:p></p>
<p class="MsoNormal">Breno de Medeiros<o:p></o:p></p>
<p class="MsoNormal">Justin Richer<o:p></o:p></p>
<p class="MsoNormal">Todd Lainhart<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"> Testing/Certification<o:p></o:p></p>
<p class="MsoNormal"> Public Interops and Demos<o:p></o:p></p>
<p class="MsoNormal"> Session Management<o:p></o:p></p>
<p class="MsoNormal"> Transition from OpenID 2.0 to OpenID Connect<o:p></o:p></p>
<p class="MsoNormal"> Dynamic Registration<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Testing/Certification:<o:p></o:p></p>
<p class="MsoNormal"> Roland does have resources available to maintain and improve the test suite<o:p></o:p></p>
<p class="MsoNormal"> He is already having parts of it rewritten and re-hosting it himself<o:p></o:p></p>
<p class="MsoNormal"> Roland plans to add additional negative tests<o:p></o:p></p>
<p class="MsoNormal"> Mike knows of several minor inconsistencies with the final specs that need to be corrected<o:p></o:p></p>
<p class="MsoNormal"> Roland will deploy a version that lets unmodified IdP pages with JavaScript be used<o:p></o:p></p>
<p class="MsoNormal"> This will let production OPs be tested - at the cost of the tester having to log in a number of times<o:p></o:p></p>
<p class="MsoNormal"> It was agreed that we can use the test suite as a basis for self-certification<o:p></o:p></p>
<p class="MsoNormal"> Roland can be at IIW and we can do in-person testing there<o:p></o:p></p>
<p class="MsoNormal"> Mike will propose a few self-certification profiles<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Public Interops and Demos:<o:p></o:p></p>
<p class="MsoNormal"> Chuck asked whether we wanted to have public interops and demos<o:p></o:p></p>
<p class="MsoNormal"> Public demos and interops are great forcing functions<o:p></o:p></p>
<p class="MsoNormal"> They generates positive press<o:p></o:p></p>
<p class="MsoNormal"> IIW May 6-8 is a good place to do actual interop work<o:p></o:p></p>
<p class="MsoNormal"> EIC is the week after IIW - we could make noise about interop then<o:p></o:p></p>
<p class="MsoNormal"> Public stuff should describe scenarios / stories, such as:<o:p></o:p></p>
<p class="MsoNormal"> RP SSO<o:p></o:p></p>
<p class="MsoNormal"> Mobile device using Connect for Authentication<o:p></o:p></p>
<p class="MsoNormal"> Chuck could get an app running that can use multiple OPs<o:p></o:p></p>
<p class="MsoNormal"> CIS July 19-22 we could announce initial self-certification results<o:p></o:p></p>
<p class="MsoNormal"> Pat Patterson and Chuck are doing some OpenID Connect presentations in the next few weeks<o:p></o:p></p>
<p class="MsoNormal"> Pam wants us to have some video presentations<o:p></o:p></p>
<p class="MsoNormal"> Naveen said that there's an easy way to get an ID Token and Code from the Android account manager<o:p></o:p></p>
<p class="MsoNormal"> He said that we could demonstrate that<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"> We discussed issue #915 - Session 4.2 - Computation of OP session_state in the IdP requires origin URI<o:p></o:p></p>
<p class="MsoNormal"> Google can register multiple origins<o:p></o:p></p>
<p class="MsoNormal"> Just like multiple redirect URIs<o:p></o:p></p>
<p class="MsoNormal"> As a result, the origin has to be supplied dynamically<o:p></o:p></p>
<p class="MsoNormal"> The session state value needs to be a function of the origin it will be checked from<o:p></o:p></p>
<p class="MsoNormal"> One possibility is another parameter expressing a cookie domain<o:p></o:p></p>
<p class="MsoNormal"> Based on feedback from Google developers<o:p></o:p></p>
<p class="MsoNormal"> The proposal to register one js_origin_uri is insufficiently flexible when clients have multiple redirect_uris<o:p></o:p></p>
<p class="MsoNormal"> Breno would prefer that we reuse the dynamic redirect_uri to determine the origin rather than the js_origin_uri parameter<o:p></o:p></p>
<p class="MsoNormal"> Breno is discussing another parameter in HTTP set cookie configuration format - RFC 6265<o:p></o:p></p>
<p class="MsoNormal"> Example:<o:p></o:p></p>
<p class="MsoNormal"> redirect_uri=https://login.yahoo.com/openidconnect<o:p></o:p></p>
<p class="MsoNormal"> Want session state to also be valid at http://photos.yahoo.com<o:p></o:p></p>
<p class="MsoNormal"> Domain: .yahoo.com, not secure<o:p></o:p></p>
<p class="MsoNormal"> "secure", "login.yahoo.com"<o:p></o:p></p>
<p class="MsoNormal"> "", ".yahoo.com"<o:p></o:p></p>
<p class="MsoNormal"> OP needs to know ahead of time where cookie would be set<o:p></o:p></p>
<p class="MsoNormal"> Chuck said that cookie policy is far more expressive than we want/need here<o:p></o:p></p>
<p class="MsoNormal"> Breno doesn't want to invent a new security concept<o:p></o:p></p>
<p class="MsoNormal"> We need the domain part and the secure/insecure part but not the other parts<o:p></o:p></p>
<p class="MsoNormal"> Pam asked whether this information would passed dynamically or at registration time<o:p></o:p></p>
<p class="MsoNormal"> Breno confirmed with his security people that using postMessage to convey one bit isn't a security problem<o:p></o:p></p>
<p class="MsoNormal"> "changed" versus "unchanged"<o:p></o:p></p>
<p class="MsoNormal"> Naveen reviewed some of Google's reasons for token caching<o:p></o:p></p>
<p class="MsoNormal"> They are planning to have a GetToken JavaScript API call<o:p></o:p></p>
<p class="MsoNormal"> We agreed that caching is still fluid and out of scope for the current Session Management work<o:p></o:p></p>
<p class="MsoNormal"> We could later do this in another spec<o:p></o:p></p>
<p class="MsoNormal"> Token caching provides more responsiveness to simply written RPs by avoiding network traffic, when possible<o:p></o:p></p>
<p class="MsoNormal"> However, the caching API might not want to or need to do the polling that the current spec does<o:p></o:p></p>
<p class="MsoNormal"> Having widgets have different Client IDs at different sites could be problematic for caching<o:p></o:p></p>
<p class="MsoNormal"> Guibin presented Google's design thoughts about caching<o:p></o:p></p>
<p class="MsoNormal"> It has parameters like crossTabs, crossDomains, crossClients, etc.<o:p></o:p></p>
<p class="MsoNormal"> monitorClient(clientId)<o:p></o:p></p>
<p class="MsoNormal"> fetchTokenResponse(clientId, request, forceRefresh, identifier)<o:p></o:p></p>
<p class="MsoNormal"> Monitor Session State<o:p></o:p></p>
<p class="MsoNormal"> Do we need additional parameters on logout for the multi-logout case?<o:p></o:p></p>
<p class="MsoNormal"> Breno: We might be able to encode all the information needed in the session_state<o:p></o:p></p>
<p class="MsoNormal"> Google currently passes an auth_user parameter, but they think they can get rid of that<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Transition from OpenID 2.0 to OpenID Connect:<o:p></o:p></p>
<p class="MsoNormal"> http://googledevelopers.blogspot.com/2014/02/welcome-openid-connect.html has pointers to info<o:p></o:p></p>
<p class="MsoNormal"> https://developers.google.com/accounts/docs/OpenID#openid-connect describes Google's current migration approach<o:p></o:p></p>
<p class="MsoNormal"> See "Migrating to OAuth 2.0 login (OpenID Connect)"<o:p></o:p></p>
<p class="MsoNormal"> Use an openid.realm parameter in an OpenID Connect request<o:p></o:p></p>
<p class="MsoNormal"> The realm is returned in the ID Token, which includes an OpenID 2.0 identifier<o:p></o:p></p>
<p class="MsoNormal"> Nat is concerned that Google's current approach would allow a rogue OP to assert another OP's openid.realm<o:p></o:p></p>
<p class="MsoNormal"> The RP would have to do discovery to prevent this<o:p></o:p></p>
<p class="MsoNormal"> Or the OpenID 2.0 discovery document could publish the OpenID Connect issuer public key<o:p></o:p></p>
<p class="MsoNormal"> Nat asked about a batch update operation<o:p></o:p></p>
<p class="MsoNormal"> Specifying a list of OpenID 2.0 verified identifiers and returning the OpenID Connect identifiers<o:p></o:p></p>
<p class="MsoNormal"> More work is needed on recommendations for transitioning<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Dynamic Registration:<o:p></o:p></p>
<p class="MsoNormal"> Google uses the Client ID to tie the client to a developer to prevent abuse<o:p></o:p></p>
<p class="MsoNormal"> The developer is identified by a Google account<o:p></o:p></p>
<p class="MsoNormal"> The account creation machinery tries to prevent bogus account creation<o:p></o:p></p>
<p class="MsoNormal"> IMAP clients are a key use case<o:p></o:p></p>
<p class="MsoNormal"> Google wants the IMAP client to be issued an instance ID tied to the user<o:p></o:p></p>
<p class="MsoNormal"> They don't want a shared Client ID for all instances of the mail client<o:p></o:p></p>
</div>
</body>
</html>