[Openid-specs-ab] About ID Tokens being access tokens

[Andreas Åkre Solberg]

On 29. aug. 2011, at 23:38, John Bradley wrote:

> As far as I know the token endpoint trades code for a access and refresh token,  or a refresh token for an access token.

Yes.

> There is no scope parameter for the token endpoint only the authorization one.

There is. See OAuth section 6.

However, and as Nov commented, I did a mistake by including the scope parameter in the initial request to the token endpoint. It seems that when you are replacing the code for an access token, the scope is not listed as a legal parameter.

The initial authorization request MUST include all scopes that the client intends to use; in order for the provider to ask the user for permission when it has the user present (front-channel).

When the provider issues a token the first time; it may select which scope the token has; typically it can be a 'openid-session' token, or a 'openid-userdata' token. Notice that in real life deployment I would assume that clients would ask for other scopes as well; and the provider may select to issue individual tokens or multi-purpose tokens.


If the client receives a token that is valid in a subset of the scopes in the authorization request, it should use the refresh token to obtain tokens for the remaining scopes. OAuth section 6. 


> I think there is a basic requirement to be able to get the id_token to the RP via the redirect response, so it can start rendering a page before it makes the subsequent calls to the token and user-info endpoints.

I assume contacting the user info endpoint also add latency. Have you considered also pushing the user data JWT in the response to the code? This will save latency, and make the user info service and the check session service much more consistent; also it will move you further away from OAuth. 

If you would like to be more true to OAuth, and at the same time would like to save latency, there also are alternatives: you could make the OP issue an short-lived access token with multiple scopes (both openid-session and openid-userdata), and the client can optionally use the refresh token to obtain a long-lived single-scope openid-userdata access token that may used for offline user data updates, and de-provisioning. In addition you could merge the check info and user info endpoints to a single OpenID Connect Service Endpoint, that would support delivering both user data and session data, if requested and an appropriate scoped access token were used. 


I fully understand that the timing is probably the worst to propose a major spec revision - I wish I joined the list a year ago. The problem is that the more I think of it, the more obvious it becomes to me that being more inline with Oauth would make a lot of things a lot simpler, and I think I would run into sleeping troubles if I had refrained from expressing the ideas - so I hope you apologize me... Discussing, and arguing pro and con the current spec is also a way for me to better understand the spec and the reasoning behind it. Understanding the spec and the reasoning behind it is crucial for me to continue my work.

Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110830/04c3abdf/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4448 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110830/04c3abdf/attachment.p7s>