<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body 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>
<br>
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>
<br>
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>
<br>
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>
<br>
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>
<br>
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>
<br>
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").<br>
<br>
Thanks,<br>
George<br>
<br>
<br>
On 5/15/10 7:57 PM, David Recordon wrote:
<blockquote
cite="mid:AANLkTimSyTg7Sk34MVWJNJ9cV2ZsKkrod24GNBzOj0tY@mail.gmail.com"
type="cite">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 moz-do-not-send="true"
href="http://daveman692.livejournal.com/349384.html">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
moz-do-not-send="true"
href="http://factoryjoe.com/blog/2010/01/04/openid-connect/">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 moz-do-not-send="true" href="http://openidconnect.com/">http://openidconnect.com/</a></div>
<div>
<div><br>
</div>
<div>--David</div>
</div>
</div>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
specs mailing list
<a class="moz-txt-link-abbreviated" href="mailto:specs@lists.openid.net">specs@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs">http://lists.openid.net/mailman/listinfo/openid-specs</a>
</pre>
</blockquote>
</body>
</html>