On Sun, May 16, 2010 at 10:08 AM, George Fletcher <span dir="ltr"><<a href="mailto:gffletch@aol.com">gffletch@aol.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div bgcolor="#ffffff" text="#000000">
<font face="Helvetica, Arial, sans-serif">Thanks David and others for
putting this proposal together!<br>
<br>
I have some questions/comments after reading through the document...<br>
<br>
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).</font> 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.<br></div></blockquote><div><br></div><div>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, "<a href="https://david.example-server.com/">https://david.example-server.com/</a>" or "<a href="mailto:acct%3Adavid@example-server.com">acct:david@example-server.com</a>". 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.</div>
<div><br></div><div>I don't think I'm fully understanding your question though. :-\</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div bgcolor="#ffffff" text="#000000">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?<br></div></blockquote><div><br></div><div>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.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div bgcolor="#ffffff" text="#000000">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.<br></div></blockquote><div><br></div><div>Yes, the entire OpenID Connect request and response is directly part of an OAuth 2.0 request or response. I clarified the language in <a href="http://openidconnect.com/#response">http://openidconnect.com/#response</a>.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div bgcolor="#ffffff" text="#000000">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).<br></div></blockquote><div><br></div><div>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 <a href="https://example-server.com/.well-known/lrdd?format=json&uri=https%3A%2F%2Fdavid.example-server.com%2F">https://example-server.com/.well-known/lrdd?format=json&uri=https%3A%2F%2Fdavid.example-server.com%2F</a>.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div bgcolor="#ffffff" text="#000000">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?<br></div></blockquote><div><br></div><div>Let's talk about this more at IIW. The design goal was reducing discovery to a single HTTP request.</div><div><br></div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div bgcolor="#ffffff" text="#000000">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?<br></div></blockquote><div><br></div><div>If the client asked for email and it wasn't granted, the email key wouldn't show up in the User Info API response.</div><div>
<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div bgcolor="#ffffff" text="#000000">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").</div></blockquote><div><br></div><div>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?</div>
<div><br></div><div>Thanks for the great questions!</div><div><br></div><div>--David</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div bgcolor="#ffffff" text="#000000">
Thanks,<br>
George<div><div></div><div class="h5"><br>
<br>
<br>
On 5/15/10 7:57 PM, David Recordon wrote:
</div></div><blockquote type="cite"><div><div></div><div class="h5">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 (<a href="http://daveman692.livejournal.com/349384.html" target="_blank">http://daveman692.livejournal.com/349384.html</a>).
<div><br>
</div>
<div>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.
<div><br>
</div>
<div>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 <a href="http://factoryjoe.com/blog/2010/01/04/openid-connect/" target="_blank">http://factoryjoe.com/blog/2010/01/04/openid-connect/</a>).
And thanks to Eran Hammer-Lahav and Joseph Smarr for some help writing
bits of it!</div>
<div><br>
</div>
<div>So, a modest proposal that I hope gets the conversation going
again. <a href="http://openidconnect.com/" target="_blank">http://openidconnect.com/</a></div>
<div>
<div><br>
</div>
<div>--David</div>
</div>
</div>
</div></div><pre><fieldset></fieldset>
_______________________________________________
specs mailing list
<div class="im"><a href="mailto:specs@lists.openid.net" target="_blank">specs@lists.openid.net</a>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs</a>
</div></pre>
</blockquote>
</div>
</blockquote></div><br>