<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> Spec call notes 25-Aug-11<br><br>George Fletcher<br>Nat Sakimura<br>Andreas Åkre Solberg<br>John Bradley<br>Mov Matake<br>Johnny<br>Mike Jones<br>Johnny Bufu<br><br><br>[Agenda]<br>ID Token<br>Profile Picture Size in UserInfo<br>secret_type parameter in Token endpint<br><br><br>[ID Token]<br><br>1) Using ID Token as Access Token<br><br>After the last call, it was decided that the check session endpoint <br>will accept an ID Token as an access token in the authorization header. <br>It will also accept optional access token or code in POST parameters.<br><br>The current specs call for sending "Bearer ID_Token" in authorization header.<br>Mov runs into the problem of not being able to distinguish between an ID Token<br>and a regular "bearer" access token in middleware (Ruby
RACK).<br><br>Mov would like to define a new token type for use as authorization header in the<br>check session endpoint.<br><br>George points out that using ID Token which is not an access token would lead to <br>confusion.<br><br>Defining new type would be time consuming at this point.<br><br>Conclusion :<br>Check Session endpoint is NOT an OAuth protected endpoint.<br>ID Token, Access Token, Code will be sent as POST parameters.<br><br>2) Putting hash of access token/code in ID Token<br><br>Breno would like to put the hash of the access token or code in the<br>ID Token when both are requested at the same time to bind them to<br>each other so as to prevent attacks.<br><br>Breno was not available for discussion.<br><br>Awaiting more input from Breno.<br>Will discuss in next call if possible.<br><br><br>[Profile Picture Size]<br>Previously, Allen Tom brough out the issue of being able to request<br>different profile picture sizes using query parameters
in the request.<br><br>The Userinfo endpoint does not support query parameter support.<br><br>An alternative is to add "small", "medium", "large" profile pictures <br>to the UserInfo endpoint schema.<br><br>John offered the following options:<br>a) new scope for requesting picture sizes<br>b) RP makes explicit claim request<br>c) Expand schema to include "small", "medium", and "large"<br><br>Edmund asked Breno for opinion. Awaiting reply.<br><br>Need more input from Providers before making changes.<br>Specs will remain unchanged for now.<br><br><br>[Implementation Status for September OpenID Interop]<br><br>Following people are working on implementations:<br> Mov<br> Ito-san in Japan<br> NRI (will not support distribute/aggregated claims)<br> <br> Andres is doing research/learning implementation in javascript with JWT/ID Token.<br> His team will
implement with Python.<br><br> Johnny - a) Janrain will support sign-in with OpenID Connect provider in Engage product<br> b) Enhance provider support to enable people' user database as providers.<br> Awaiting for stable specs and OAuth 2.0 Java library.<br><br><br>Attending InterOp:<br>NRI will be sending 1 engineer<br>Johnny Bufu <br>Someone from Google<br>Mov, remotely if possible<br>NIH, possibly depending on Andrew Arnot<br>Andres said Rolan(sp?) will attend, but most likely will not have implementation ready<br><br><br>[Parameter secret_type in Token Endpoint]<br>Andres said there is not enough information regarding the secret_type parameter <br>in the Redirect Binding Spec.<br><br>Edmund pointed out that Redirect Binding spec contains client_secret parameter in the
<br>Token endpoint, but the current Messages & Standard spec refers client authentication <br>to the OAuth 2.0 specs. <br><br>John points out that OAuth 2.0 does not address asymmetric client secrets and <br>the secret_type parameter was intended to address such.<br><br>John suggests having an extension and do an asymmetric key profile for OpenID Connect.<br><br>Edmund, John, Mike, and Andres to discuss offline.<br><br></div>
</div></body></html>