[Openid-specs-ab] Reducing server state

[Frank Cornelis]

Hi,


Identity Providers in general keep two types of state. One is about the 
different relying parties (Clients), the other is about the ongoing 
authentication sessions.
Older authentication protocols like SAML Browser POST and WS-Federation 
(web passive) not really use the later one.
However, more modern authentication protocols like OpenID and OpenID 
Connect keep some authentication session state.
OpenID for example uses associations, whereas OpenID Connect uses a 
bunch of different tokens.
Lately I've been investigating how to reduce this type of server state.
For OpenID one can easily encode all required authentication session 
state within the handle itself.
An implementation of this mechanism is given at:
http://code.google.com/p/openid4java/issues/detail?id=193
http://code.google.com/p/eid-idp/source/browse/trunk/eid-idp-protocol-openid/src/main/java/be/fedict/eid/idp/protocol/openid/StatelessServerAssociationStore.java
Such a mechanism is interesting for large scale deployments where you 
want to minimize the require state that the different (load-balanced) 
identity provider instances need to share with each other.
Basically we're using AES for confidentiality and an HMAC for integrity 
verification.

I also had a look at OpenID Connect to see if something similar would be 
possible.
As a first step (when using Dynamic Client Registration) you can easily 
encode client_secret, expires_at and registration_access_token (the bare 
minimum I guess) within the client_id in a similar way as proposed for 
OpenID.
Next comes the Browser POST towards the Authorization Endpoint. The 
result of this operation is that the end-user gets authenticated. Thus 
at this point the identity provider _somehow_ gets hold of all required 
attributes of the end-user.
Here you would want to encode all these results within the returned code 
parameter. However the Authorization Endpoint responses with a web 
browser redirect. This limits the size of the code parameter. If a 
browser POST would be allowed here, you could encode all attributes/data 
within the code parameter. However, AFAIK, the OAuth spec does not 
foresee such type of response. Can someone confirm this?
Furthermore the usage of the 'code' token has some semantics (use only 
once by the Client) that is impossible to represent via the proposed 
mechanism.
Is there any work ongoing related to the 'reduction of server state' for 
large scale OpenID Connect deployments?
I want to minimize the amount of such server-side state to prevent 
bottlenecks (database for sharing all the different tokens among the IdP 
instances).


Kind Regards,
Frank.