[Openid-specs-ab] Idea for discussion.

[John Bradley]

In looking at the interop feedback and the proposal from Google to have a hash of code included in the id_token,  I have taken a look at dramatically reducing the number of response_type.
This reduces flexibility,  but also reduces the number of code paths that need to be built and tested.
In talking to a number of people we have decided that this at least warrants discussion.  It would need some significant spec reworking,  but is probably not a big change to existing code.  
We wanted to discuss this on the list prior to our face to face meeting Friday.
This is the proposal:
What if we reduced the number of response_types to:
1 code
2 token
3 code token
4 token id_token (this could also go if we want to be extream).

And we eliminated all of the special token endpoint logic of returning id_tokens.


I was thinking we have a restriction of not messing with access_tokens,  however there is not necessarily the same restriction on code.

What if code is always a signed id_token with a code claim.

The token endpoint takes it and verifies it as is.

Googles security concern about code swapping goes away.

In looking at the Pomcor document they have a Denial of Service attack that is possible because the client has no way to validate code before submitting it.

If the client validates the id_token before sending it to the token endpoint that would stop the attack.

You can still have a check_id endpoint, a client would send code or id_token.

In the above response types it is only 'code token' and ' token id_token'  where a hash of token would be included in the id_token.

If you want to really squeeze it down than we could drop "token id_token" and just use "token code".

The code claim can just be a timestamp or sequence number to prevent replay given that it is now signed so guessing is no longer possible as an attack.

It is simpler,  but may open too big a can of worms at this point.  This would not change the current Basic client profile at all (aside from adding the token hash to the id_token).

For you to think about.

John
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4767 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120228/0c5354c6/attachment.p7s>