So, I threw this idea to some real implementers (meaning with real services) in Japan.  <div>Of course, there are not much "real services" in terms of OpenID Connect, so it is from the OAuth implementations, but there are use cases where "code" is being typed in. </div>
<div><br></div><div>One of the advantage of the "code" is that it is one time only, and in most cases, the use of code is time restricted as well as authenticated. Thus, making it 6 digit number so that one can type in is kind of ok. </div>
<div><br></div><div>One real use case that I was referred to was the TV set-top box use case. </div><div>The TV shows QR code and the smart phone reads it, authenticates, and shows the code. Then, the user types that code into the TV set-top box with remote control key pads (with only numeric keys.) </div>
<div><br></div><div>There can be other cases like that. </div><div><br></div><div>Precisely because of this reason, Yahoo! Japan seems to have been sticking to "opaque" short "code" even though they are notorious for introducing structure to the tokens so that most things can be stateless and secure. </div>
<div><br></div><div>I think this is the capability that we do not want to loose. </div><div><br></div><div><br></div><div>=nat</div><div><br></div><div> <br><br><div class="gmail_quote">On Wed, Feb 29, 2012 at 9:00 AM, John Bradley <span dir="ltr"><<a href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>

This reduces flexibility,  but also reduces the number of code paths that need to be built and tested.<br>
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.<br>
We wanted to discuss this on the list prior to our face to face meeting Friday.<br>
This is the proposal:<br>
What if we reduced the number of response_types to:<br>
1 code<br>
2 token<br>
3 code token<br>
4 token id_token (this could also go if we want to be extream).<br>
<br>
And we eliminated all of the special token endpoint logic of returning id_tokens.<br>
<br>
<br>
I was thinking we have a restriction of not messing with access_tokens,  however there is not necessarily the same restriction on code.<br>
<br>
What if code is always a signed id_token with a code claim.<br>
<br>
The token endpoint takes it and verifies it as is.<br>
<br>
Googles security concern about code swapping goes away.<br>
<br>
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.<br>
<br>
If the client validates the id_token before sending it to the token endpoint that would stop the attack.<br>
<br>
You can still have a check_id endpoint, a client would send code or id_token.<br>
<br>
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.<br>
<br>
If you want to really squeeze it down than we could drop "token id_token" and just use "token code".<br>
<br>
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.<br>
<br>
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).<br>
<br>
For you to think about.<br>
<span class="HOEnZb"><font color="#888888"><br>
John</font></span><br>_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Nat Sakimura (=nat)<div>Chairman, OpenID Foundation<br><a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>@_nat_en</div><br>

</div>