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

Edmund Jay ejay at mgi1.com
Fri Aug 26 01:19:56 UTC 2011

 Spec call notes 25-Aug-11

George Fletcher
Nat Sakimura
Andreas Åkre Solberg
John Bradley
Mov Matake
Mike Jones
Johnny Bufu

ID Token
Profile Picture Size in UserInfo
secret_type parameter in Token endpint

[ID Token]

1) Using ID Token as Access Token

After the last call, it was decided that the check session endpoint 
will accept an ID Token as an access token in the authorization header. 
It will also accept optional access token or code in POST parameters.

The current specs call for sending "Bearer ID_Token" in authorization header.
Mov runs into the problem of not being able to distinguish between an ID Token
and a regular "bearer" access token in middleware (Ruby RACK).

Mov would like to define a new token type for use as authorization header in the
check session endpoint.

George points out that using ID Token which is not an access token would lead to 


Defining new type would be time consuming at this point.

Conclusion :
Check Session endpoint is NOT an OAuth protected endpoint.
ID Token, Access Token, Code will be sent as POST parameters.

2) Putting hash of access token/code in ID Token

Breno would like to put the hash of the access token or code in the
ID Token when both are requested at the same time to bind them to
each other so as to prevent attacks.

Breno was not available for discussion.

Awaiting more input from Breno.
Will discuss in next call if possible.

[Profile Picture Size]
Previously, Allen Tom brough out the issue of being able to request
different profile picture sizes using query parameters in the request.

The Userinfo endpoint does not support query parameter support.

An alternative is to add "small", "medium", "large" profile pictures 
to the UserInfo endpoint schema.

John offered the following options:
a) new scope for requesting picture sizes
b) RP makes explicit claim request
c) Expand schema to include "small", "medium", and "large"

Edmund asked Breno for opinion. Awaiting reply.

Need more input from Providers before making changes.
Specs will remain unchanged for now.

[Implementation Status for September OpenID Interop]

Following people are working on implementations:
    Ito-san in Japan
    NRI (will not support distribute/aggregated claims)
    Andres is doing research/learning implementation in javascript with JWT/ID 
    His team will implement with Python.

    Johnny - a) Janrain will support sign-in with OpenID Connect provider in 
Engage product
                 b) Enhance provider support to enable people' user database as 
             Awaiting for stable specs and OAuth 2.0 Java library.

Attending InterOp:
NRI will be sending 1 engineer
Johnny Bufu 
Someone from Google
Mov, remotely if possible
NIH, possibly depending on Andrew Arnot
Andres said Rolan(sp?) will attend, but most likely will not have implementation 

[Parameter secret_type in Token Endpoint]
Andres said there is not enough information regarding the secret_type parameter 
in the Redirect Binding Spec.

Edmund pointed out that Redirect Binding spec contains client_secret parameter 
in the 

Token endpoint, but the current Messages & Standard spec refers client 

to the OAuth 2.0 specs. 

John points out that OAuth 2.0 does not address asymmetric client secrets and 
the secret_type parameter was intended to address such.

John suggests having an extension and do an asymmetric key profile for OpenID 

Edmund, John, Mike, and Andres to discuss offline.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110825/9157f5c3/attachment.html>

More information about the Openid-specs-ab mailing list