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?
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.
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.
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.
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
