[Openid-specs-ab] Idea for discussion.

[Nat Sakimura]

So, I threw this idea to some real implementers (meaning with real
services) in Japan.
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.

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.

One real use case that I was referred to was the TV set-top box use case.
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.)

There can be other cases like that.

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.

I think this is the capability that we do not want to loose.


=nat



On Wed, Feb 29, 2012 at 9:00 AM, John Bradley <ve7jtb at ve7jtb.com> wrote:

> 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
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120229/68f51873/attachment.html>