Building identity on top of OAuth 2.0?

[George Fletcher]

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
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>    
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20100516/219a8911/attachment.htm>