ve7jtb at ve7jtb.com
Tue Jul 26 17:20:59 UTC 2011
In discussions with potential implementers at IETF an issue around the id_token and the introspection endpoint has come up.
DT amongst others want a stateless Introspection endpoint.
If we require that the introspection endpoint can always return the info from the id_token that requires them to include the id_token info in every access token.
That has problems, including conflating the separation of authentication and attributes.
I agree that it is not clean, though may be the pragmatic solution.
One other option we could consider is leaving the format of the id_token undefined at least in the Lite spec. We would always ask for "token id_token" or "code id_token".
Facebook can use webkeys or something else if they like for the id_token, but the introspection endpoint would always introspect into the standard JSON format.
That makes the introspection endpoint more logically consistent in that it would aways tell you about the token used. It could then be used to look at what scopes etc. are in the access token. That wouldn't work if we overload the access token to pretend to be the id_token.
So the question is, can we find a way to always return an id_token.
Can someone from Facebook comment on if in the token (implicit) flow, returning an id_token + access token is a reasonable thing. I think it is something that you do now.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4767 bytes
Desc: not available
More information about the Openid-specs-ab