[Openid-specs-ab] Comment on Messages

[Andreas Åkre Solberg]

On 6. sep.2011, at 20:32, John Bradley wrote:

> In a number of cases I expect that the OP will generate a JWT as the access token.
> MAC tokens are mostly about being able to save the access token as a cookie.  I don't know that they add much.

It is also of interest in use cases where HTTPS is not required. [1]

[1]: http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-00#section-1.1

> I am OK with leaving it open to extension.  Though I a proper proof key mechanism for JWT is probably the way to go..

As long as the JWT is issued by the provider, and used by the client unmodified, I'd say that some of the problems with bearer tokens cannot be fixed.


I think that one of the most awsome features of OpenID Connect is that it can be intereoperable with existing OAuth servers. Say that I already have a provider that issues an access token to use a third party api to gain access to the data of the user; OpenID Connect can in an elegant way be added to that API; adding authentication and session management; with backward compatibility.

When adding extensions and building a layer on top of OAuth you probably cannot guarantee interoperability with other Oauth extensions etc; but I would say that we can do some modifications to decrease the chances of conflict.

One of these things would be to not restrict the access token type. An OpenID Connect provider may seemlessly integrate with an existing OAuth provider in two ways: it can start issuing multi-scoped access tokens that can be used for the already existing purpose (in example uploading photos) and the same token can be used for accessing user data. Alternatively the provider can use a separate scope (making the existing access token independent from OIC). If the same access token should be used for multiple purposes, there might be a need for accessing an unprotected (no TLS) and therefore 'mac'. Backward compatibility could also be a reason for choosing 'mac'. There also may be cooler token types added in the future that is better suited for delegation to third parties.

I also think the spec should consider the use case where the 'Access Token Response' is returning a subset of the issued scopes in the authrorization request; and in particular if the 'openid' scope is not included in the first response. This might be a case when OIC is used with OAuth providers that supports many scopes. Right now, this use cases is unclear, which may cause interoperability issues.

Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110907/2d6475da/attachment.html>