Messages 2.1.2.1, etc. - Questioning the ID Token model

Yaron Goland writes the following, which questions the ID Token model. While we may not make changes in response to this bug, it IS a question we need a good answer to - possibly in rationale in the specs, because other smart people will be thinking and asking the same things.

====

            What the heck is an ID token and why does anyone ever need one? It seems to me that claims can be returned in the response outside of a token, just as response parameters. If the connection isn't trusted (e.g. it's relayed through the browser) then a request to the end user endpoint is in order. But the whole model here seems really broken. I need to create a blog article really pointing this out to people. What's being suggested here is just cruelly complex.

            The introduction of ID Tokens, the distinction between claims and user info, it's all hopelessly silly complex. Please stop it. A much simpler approach is:

            1) There are only claims. The client wants information about the resource owner. That's it. It's all claims. There are no claims vs user info. Just claims.

            2) There are no ID Tokens. The only question is - should claims be returned as response parameters or should the equivalent of an authorization code be returned to allow the client to get the claims from a trusted endpoint rather than relayed through the browser. That's it.

            With these two changes we can radically simplify the whole protocol. Get rid of a bunch of optional crap. And make the whole thing much easier to deal with.

            I know it's late in the process but just look at this hulking mess we are trying to slop on people. It's stupidly complex and all it will do is just make the equivalent of me in a year or two go to the equivalent of IIW saying "Wow, the open ID connect thing is really big and clunky, can't we do something simpler?"

            My suggestion is that there is a nice short sweet little spec that just says "here is how to ask for claims". Then there is a second spec that says "here is how to ask for permissions and claims at the same time." This would let us do fun things like completely get rid of the check_id endpoint. Since there are no ID_tokens. And the UserInfo endpoint would just take an authorization code as an argument and return all approved claims. So no user info algorithms supported, for example.

Comments (11)