Thanks David and others for putting this proposal together!
I have some questions/comments after reading through the document...
1. Identifiers: For the RP, it seems that user_id is the identifier to
use when storing data about the user (well more correctly the
provider:user_id pair). The OP could generate at least 3 types of
user_id identifiers (public, pseudonymous, temporary). If the RP stores
the data based on the OP provided user_id, then I can see some problems
for delegation. When it comes to identity federation, having a
consistent identifier to represent the user is critical.
2. The current OpenID check_immediate functionality allows for the RP
determine if the user at the browser is currently logged into a
particular OP. However, the current proposal requires the RP to send the
user_id parameter in "check_immediate" mode. Is it OK for the user_id
parameter to be blank?
3. OpenID+OAuth Hybrid: It was unclear to me from the proposal whether
the OpenID Connect Response included an OAuth 2 access token (and
refresh_token?) or not. It seems like this is an easy addition, though
I'd like to see the tokens included in the signature.
4. In order for the RP to verify the OpenID Connect response, it has to
perform discovery on the returned user_id. This means the RP must be
able to retrieve the XRD/JRD for the provided user_id (webfinger for
acct scheme) and normal LRDD for URL ids. It seems like it might be nice
if for URL based ids, a GET on the URL would return the XRD/JRD (with
?format=json).
5. Personally, I'm not crazy about putting processing endpoints in
/.well-known. I'd much rather advertise the LRDD endpoint in the
domain's host-meta which the RP can cache. (It turns out that getting
/.well-known/host-meta deployed has been much harder than I expected.
This might just be a function of large providers and more complex
network topologies.) Additionally, is it acceptable for the RP to follow
redirects (301, 302, 307) on the LRDD request?
6. The user_info API allows for returning data (such as email) that
might request explicit user consent. The RP can ask the user to give
consent by specifying email in the scope parameter. However, what is the
expected server response if the user did not give consent to email but
did authenticate and wants to establish the relationship with the RP.
When the RP asks for email in the user_info API, should the server send
back the public data and not the email?
7. Number 6 brings up the issue of dynamic scope adjustment. This is
something that I think is critical not only for OpenID but also for
OAuth. If the RP needs a particular scope and doesn't yet have it, it
should be able to re-auth asking for that scope (the user shouldn't have
to re-enter their credentials; just approve the new "permission").
Thanks,
George
On 5/15/10 7:57 PM, David Recordon wrote:
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
