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.
_______________________________________________
specs mailing list
[email protected]
http://lists.openid.net/mailman/listinfo/openid-specs
