[Openid-specs-ab] Spec call notes 23-Aug-11

Edmund Jay ejay at mgi1.com
Tue Aug 23 22:50:32 UTC 2011

Spec call notes 23-Aug-11

John Bradley
Pam Dingle
Nat Sakimura
Johnny Bufu
Edmund Jay
Breno de Medeiros (joined later)

- Issue tracking system
- Check session endpoint
- Issue #27 in tracking system
- Messages and Standards spec

[Issue Tracker]
Issue tracking systme created at http://hg.openid.net/connect/issues
Account is required to edit issues
Inform Nat of your account to get permisssions
Nat sent out a message to the list regarding how to use issue tracker :

[Check Session Endpoint]
John had discussion with Breno.

ID Token needs to contain a fingerprint/hash of the code or access token.

Check Session endpoint is an OAuth protected resource which accepts 
an ID Token as an access token with an OPTIONAL Access token or code parameter.

Google concluded that they need a hash of the code/access token in the ID token 
correlate the issued code and ID Token so as to prevent cut and paste attacks.
Makes it possible for smart clients to validate the ID Token and code are 

Facebook is doing something similar with signed requests.
Signed request contains a hash of the code as explained to Breno, since 
documentation is not deterministic. Make it easier for FB compliance.

Johnny proposes to define OpenID Token type that is a JSON that contains
multiple tokens for various endpoints.
Smart clients can extract tokens whereas "dumb" ones can use token as is.
Can be optimized by sending full or lite token depending on the type of client,
but OAuth does not define request to indicate client type yet.

Johnny will write a proposal to the mailing list.

[Issue 27 in Issue Tracker]
- About adding id_token to the response.
John has fixed it in latest draft, but has not updated tracker.

[response_type paramater]
response_type parameter will now support id_token as one of the request values

ID Token will always be returned in the fragment when sent to the client's
redirect_uri and also from Token endpoint if requested.

[More ID Token]
Breno joined to provide more history and information on why ID Token needs to 
a hash of the access token or code

Google considered 4 designs.
a) access token == id_token
b) id_token contains access token
c) id_token contains fingerprint/hash of access token
d) individual id_token and access token with no relationship

a) has been ruled out because mitigation is needed in cases of non-SSL use 

   Access token will be leaked.
b) people will keep id_token in a cookie to communicate with server. It will 

   vulnerability reports and NPR issues with OAuth 2.0
d) also ruled out. Does not have any specific issues, but feels uncomfortable 
with the
   idea due to long history of problems from people expecting 2 things to be 

Left with option c) which is similar to Facebook's signed request format since
they have deployment experience in non-SSL use cases which could be common 

ID Token will contain hash of the access token in token flow and
hash of the code in code flow.

Discussed problem of hash being longer than code
Breno suggested truncating hash to half it's length according to NIST trucation 
since code/tokens should not have collision problems.

Hash should only be issued when server is issuing token/code + id_token to the 
same user at
the same time

Johnny asked for uses cases of when to use id_token + code
Response : Mainly for latency reasons, clients don't want to wait for RPC calls 
before rendering
something to the end user. Front end can update UI as new data comes in.

Breno suggesed that clients should use SSL to avoid security issues.
Since non-SSL uses cases could be pretty common, maybe Lite spec should
document flow that works in non-SSL cases.
Token flow is risky and possibilty exists that user-agents will send access 

back to client server in non-SSL mode

Code flow has less chance to leak access tokens
John will write Lite spec with code flow only

Breno will write a proposal regarding fingerprint/hash in id_token to mailing 

[Misc issues]
WG needs to add links to all specs in OpenID landing page.
Nat will add latest spec versions to svn
Need feedback on Messages and Standard specs. Post issues to Issues Tracker.

Allen Tom posted to the list regarding adding size query parameters to the
profile picture URL in userinfo schema.
This could make things more complicated.
Instead UserInfo could return 3 profile picture URLs at the cost of increased 
Edmund will check with Google on what's best solution.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110823/b5f8ff46/attachment.html>

More information about the Openid-specs-ab mailing list