[Openid-specs-ab] Idea for discussion.

[Mike Jones]

At the in-person working group meeting, based on input from implementers, the working group rejected this proposal.  The feeling was that the different responses have different uses and different lifetimes, and merging these things together actually complicates the model and implementations.

The consensus was that have an education issue - not a protocol issue.

				-- Mike

-----Original Message-----
From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of John Bradley
Sent: Tuesday, February 28, 2012 4:01 PM
To: openid-specs-ab at lists.openid.net
Subject: [Openid-specs-ab] Idea for discussion.

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