Building identity on top of OAuth 2.0?

[Torsten Lodderstedt]

Am 19.05.2010 08:23, schrieb David Recordon:
>
>
>     1) In your proposal there are two services providing user data,
>     the OAuth authorization server and the user data service. Why this
>     redundancy? Wouldn't the user data service suffice?
>
>
> The model brought forth in WRAP and now preserved in OAuth 2.0 has a 
> separation between the authorization server and one or more protected 
> resources. I thus view the user info API as one of these protected 
> resources.
>
> From conversations at IIW, I'm thinking about removing the separate 
> user info API endpoint and instead making each user identifier a 
> protected resource. Thus you fetch 
> https://server.example.com/wo1k1nklas with no access token and get 
> public data. Fetch it with an access token from the OpenID response 
> and you get protected information.
>
> This removes an endpoint and makes the identifier itself quite useful.
>

Sounds good, so you are going to RESTify this part?

>     Why not split it? What about using another parameter, say
>     "openid_mode", to activate the extended behavior of the OAuth
>     authorization server? Then, the scope parameter could exclusively
>     be used to determine the permissions of the client on the user
>     data service. For example, the set of attributes accessible to the
>     client could be requested that way.
>
>
> OAuth 2.0 already has a `type` parameter which is used to 
> differentiate between the different flows. Given that we're 
> piggybacking on those flows, we don't want to overload that parameter. 
> Having both `type` and `mode` feels redundant when `scope` is designed 
> for the client to tell the server it wants more data access.
>
> Given that the client is asking for user information in addition to 
> the identifier, it seemed reasonable that would be an additional 
> scope. Scope is also already the mechanism servers use to determine 
> the consent UI shown to the user.

I still feel uncomfortable with this "overload" of semantics. So far the 
scope determines properties of a token not the behavior of the 
authorization server. In my experience, weak semantics causes more 
trouble than additional parameters with a clear semantics. I mean, you 
propose a significant extension to the services offered by an OAuth 
authorization server. It has never before attested identities. So 
introducing another flag (choose any name) seems appropriate to me. 
Another way would be to introduce a generic name scheme, where every 
standard flow may be turned into an OpenId Connect flow just be adding a 
suffix, e.g. web_server(_with_id) :-).

Another question arose:

"Clients can optionally include a client_id parameter and MUST if they 
do not verify the signature within the response. If this parameter is 
included and the access token was issued to a different client, the 
server MUST return an error."

Seems you want to prevent token theft? But the proposed design forces a 
deployment to share client ids between authorization server and 
protected resource - one of patterns of OAuth 1.0a most people wanted to 
get rid of with OAuth 2.0. What about using token secrets instead?

regards,
Torsten.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20100519/75465063/attachment.htm>