On Sun, May 16, 2010 at 10:08 AM, George Fletcher <[email protected]> wrote:
> 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. > For the client the user identifier is what should be used to store data (as you said). The user identifier is always globally unique and discoverable. For example, "https://david.example-server.com/"; or " acct:[email protected] <acct%[email protected]>". Given that the server is generating HTTPS URLs or acct URIs, it has control over how public, pseudonymous, or temporary they are just like OpenID 2.0. The one requirement is that performing discovery on the user identifier points back to the server's token endpoint that issued it. I don't think I'm fully understanding your question though. :-\ > 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? > Yes, it can be blank. Google is pushing for this as a way for clients to not have to verify the returned signature, but rather have it happen server side. I don't really mind making clients verify the signature given that we removed the complex part of doing so. > 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. > Yes, the entire OpenID Connect request and response is directly part of an OAuth 2.0 request or response. I clarified the language in http://openidconnect.com/#response. > 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). > The discovery process is actually the same for URLs and acct URIs because of this new idea of a LRDD processor that's hosted server side. Thus the client extracts the domain and makes one request to https://example-server.com/.well-known/lrdd?format=json&uri=https%3A%2F%2Fdavid.example-server.com%2F . I actually really like this idea of making the user identifier a useful API itself. I think we could replace the separate user info API with making an OAuth 2.0 request to the user identifier and I like your idea of having that return discovery information at the same time. You'd still need a layer of discovery for acct URIs, but I think that's acceptable. Or we only support HTTPs URLs as user identifiers, but allow users to type in email addresses to get the process started. > 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? > Let's talk about this more at IIW. The design goal was reducing discovery to a single HTTP 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? > If the client asked for email and it wasn't granted, the email key wouldn't show up in the User Info API response. > 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"). > This feels like a server-side implementation detail (at least the not re-entering their credentials part of it)? I think there's been a discussion on the OAuth IETF list about upgrading and downgrading scopes, maybe jump into that there? Thanks for the great questions! --David > 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
