<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:tahoma,new york,times,serif;font-size:10pt;color:#000000;"><div><span class="cgSelectable" style="cursor:pointer;" title="View all emails with this subject">Spec call notes 23-Aug-11<br><br><br>John Bradley<br>Pam Dingle<br>Nat Sakimura<br>Johnny Bufu<br>Edmund Jay<br>Breno de Medeiros (joined later)<br><br>[Agenda]<br>- Issue tracking system<br>- Check session endpoint<br>- Issue #27 in tracking system<br>- Messages and Standards spec<br><br><br>[Issue Tracker]<br><span>Issue tracking systme created at <a target="_blank" href="http://hg.openid.net/connect/issues">http://hg.openid.net/connect/issues</a></span><br>Account is required to edit issues<br>Inform Nat of your account to get permisssions<br>Nat sent out a message to the list regarding how to use issue tracker :<br><span><a target="_blank"
href="http://confluence.atlassian.com/display/BITBUCKET/Setting+Up+the+Bitbucket+Issues+Service">http://confluence.atlassian.com/display/BITBUCKET/Setting+Up+the+Bitbucket+Issues+Service</a></span><br><br><br><br>[Check Session Endpoint]<br>John had discussion with Breno.<br><br>ID Token needs to contain a fingerprint/hash of the code or access token.<br><br>Check Session endpoint is an OAuth protected resource which accepts <br>an ID Token as an access token with an OPTIONAL Access token or code parameter.<br><br>Google concluded that they need a hash of the code/access token in the ID token to<br>correlate the issued code and ID Token so as to prevent cut and paste attacks.<br>Makes it possible for smart clients to validate the ID Token and code are related.<br><br>Facebook is doing something similar with signed requests.<br>Signed request contains a hash of the code as explained to Breno, since <br>documentation is not deterministic. Make it easier
for FB compliance.<br><br>Johnny proposes to define OpenID Token type that is a JSON that contains<br>multiple tokens for various endpoints.<br>Smart clients can extract tokens whereas "dumb" ones can use token as is.<br>Can be optimized by sending full or lite token depending on the type of client,<br>but OAuth does not define request to indicate client type yet.<br><br>Johnny will write a proposal to the mailing list.<br><br><br>[Issue 27 in Issue Tracker]<br>- About adding id_token to the response.<br>John has fixed it in latest draft, but has not updated tracker.<br><br><br>[response_type paramater]<br>response_type parameter will now support id_token as one of the request values<br><br>ID Token will always be returned in the fragment when sent to the client's<br>redirect_uri and also from Token endpoint if requested.<br><br><br>[More ID Token]<br>Breno joined to provide more history and information on why ID Token needs to contain<br>a hash of the
access token or code<br><br>Google considered 4 designs.<br>a) access token == id_token<br>b) id_token contains access token<br>c) id_token contains fingerprint/hash of access token<br>d) individual id_token and access token with no relationship<br><br>a) has been ruled out because mitigation is needed in cases of non-SSL use cases. <br> Access token will be leaked.<br>b) people will keep id_token in a cookie to communicate with server. It will cause <br> vulnerability reports and NPR issues with OAuth 2.0<br>d) also ruled out. Does not have any specific issues, but feels uncomfortable with the<br> idea due to long history of problems from people expecting 2 things to be related.<br><br>Left with option c) which is similar to Facebook's signed request format since<br>they have deployment experience in non-SSL use cases which could be common <br><br>ID Token will contain hash of the access token in token flow
and<br>hash of the code in code flow.<br><br>Discussed problem of hash being longer than code<br>Breno suggested truncating hash to half it's length according to NIST trucation mode<br>since code/tokens should not have collision problems.<br><br>Hash should only be issued when server is issuing token/code + id_token to the same user at<br>the same time<br><br>Johnny asked for uses cases of when to use id_token + code<br>Response : Mainly for latency reasons, clients don't want to wait for RPC calls before rendering<br>something to the end user. Front end can update UI as new data comes in.<br><br><br>Breno suggesed that clients should use SSL to avoid security issues.<br>Since non-SSL uses cases could be pretty common, maybe Lite spec should<br>document flow that works in non-SSL cases.<br>Token flow is risky and possibilty exists that user-agents will send access token <br>back to client server in non-SSL mode<br><br>Code flow has less chance to leak
access tokens<br>John will write Lite spec with code flow only<br><br>Breno will write a proposal regarding fingerprint/hash in id_token to mailing list.<br><br><br>[Misc issues]<br>WG needs to add links to all specs in OpenID landing page.<br>Nat will add latest spec versions to svn<br>Need feedback on Messages and Standard specs. Post issues to Issues Tracker.<br><br>Allen Tom posted to the list regarding adding size query parameters to the<br>profile picture URL in userinfo schema.<br>This could make things more complicated.<br>Instead UserInfo could return 3 profile picture URLs at the cost of increased size.<br>Edmund will check with Google on what's best solution.<br><br><br></span></div>
</div></body></html>