On Tue, May 18, 2010 at 1:08 PM, Torsten Lodderstedt < [email protected]> wrote:
> In my opionion, your proposal offers an interesting (and simplified) > approach to user authentication and attribute providing. > > I have some questions/comments regarding its usage of OAuth 2.0: > > 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. > 2) The usage of the standard parameter "scope" to indicate the "openid > mode" of the OAuth AS surprises me. In my understanding, a client uses this > parameter to request permissions to be bound to tokens. So it controls what > a client is entitled to do when accessing a protected resource using such a > token. In the context of OpenId connect, the "scope" parameter additionally > controls whether the AS responds with additional response parameters > (user_id, signature, issued_at) to the client. It appears to me you packed > two features into one parameter. > Sure, that's a fair assessment. > 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. > 3) Why is a signature needed to protect the access token response from the > server? The proposal says: > > "The client SHOULD then verify the signature. Doing so confirms the binding > between the given access token and user identifier in addition to the > response coming from the expected server." > > Since HTTPS is a MUST on the token endpoint, the authorization server is > authenticated during HTTPS handshake. So what is the extra security gain > here? Or is it just needed in user agent flow? The respective FAQ also did > not explain the reason to me. > This bit of the spec has been a bit in limbo. My first draft forced validation of the signature but Google really wanted no crypto on the client and instead make a HTTPS request to the user info API to verify the identifier assertion. As this point the signature allows the client to more quickly determine that the assertion is valid without making the user info request. It can also be dropped directly into a cookie if the client doesn't want to do it's own session management. --David regards, > Torsten. > > David Recordon schrieb: > >> The past few months I've had a bunch of one on one conversations with a >> lot of different people – including many of folks on this list – about ways >> to build a future version of OpenID on top of OAuth 2.0. Back in March when >> I wrote a draft of OAuth 2.0 I mentioned it as one of my future goals as >> well (http://daveman692.livejournal.com/349384.html). >> >> Basically moving us to where there's a true technology stack of TCP/IP -> >> HTTP -> SSL -> OAuth 2.0 -> OpenID -> (all sorts of awesome APIs). Not just >> modernizing the technology, but also focusing on solving a few of the key >> "product" issues we hear time and time again. >> >> I took the past few days to write down a lot of these ideas and glue them >> together. Talked with Chris Messina who thought it was an interesting idea >> and decided to dub it "OpenID Connect" (see >> http://factoryjoe.com/blog/2010/01/04/openid-connect/). And thanks to >> Eran Hammer-Lahav and Joseph Smarr for some help writing bits of it! >> >> So, a modest proposal that I hope gets the conversation going again. >> http://openidconnect.com/ >> >> --David >> ------------------------------------------------------------------------ >> >> >> _______________________________________________ >> specs mailing list >> [email protected] >> http://lists.openid.net/mailman/listinfo/openid-specs >> >> > >
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
