Hi John,<div><br></div><div>Your idea for a dynamic XRDS at the OP that manages to pass a parameter to the OP endpoint is very interesting. It sounds like it might work. :)</div><div><br></div><div>If the OP were to send an assertion that included a user component in the claimed identifier that was actually significant, I would fear that most RPs would ignore it and thereby allow identity spoofing. Perhaps OpenID 2.1 can clarify this.<br clear="all">
--<br>Andrew Arnott<br>"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - Voltaire<br>
<br><br><div class="gmail_quote">2009/3/23 John Panzer <span dir="ltr"><<a href="mailto:jpanzer@acm.org">jpanzer@acm.org</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Mon, Mar 23, 2009 at 10:10 PM, Andrew Arnott <<a href="mailto:andrewarnott@gmail.com">andrewarnott@gmail.com</a>> wrote:<br>
> The user part is never sent to the OP, regardless of the RP's<br>
> implementation. Discovery is performed with an HTTP GET on either<br>
> <a href="mailto:user@domain.com">user@domain.com</a> or <a href="http://domain.com" target="_blank">domain.com</a>.<br>
<br>
</div>Not clear on whether OpenID normalization requires stripping the user@<br>
part, but notionally <a href="http://user@domain.com/" target="_blank">user@domain.com/</a> is a valid URI and could be used<br>
for discovery.<br>
<div class="im"><br>
Discovery results in the OP endpoint URI and<br>
> an identifier_select claimed identifier. The RP then redirects the user,<br>
> not to <a href="http://domain.com" target="_blank">domain.com</a>, but to the OP endpoint, which could be anywhere, and<br>
> certainly does NOT include the user@ portion because the redirect is<br>
> determined by the OP's advertised OP endpoint via their XRDS document.<br>
<br>
</div>The XRDS document could be generated dynamically based on the $USER<br>
variable, thus incorporating the data as an argument to the OP<br>
endpoint. This would of course rule out a static XRDS file.<br>
<div class="im"><br>
> So the OP never sees user1@ or user2@. The RP has no way to correlate<br>
> user1@ to a user account or a claimed identifier on the OP, and the RP never<br>
> sees user2@ because the claimed identifier is not in the form of an email<br>
> address. :)<br>
<br>
</div>What stops the OP from sending back a URI <a href="http://user2" target="_blank">http://user2</a>@<a href="http://example.org/" target="_blank">example.org/</a>?<br>
<br>
I am not advocating for any of this, just pushing the boundaries a bit.<br>
<div><div></div><div class="h5"><br>
<br>
><br>
> On Mon, Mar 23, 2009 at 6:26 PM, John Panzer <<a href="mailto:jpanzer@acm.org">jpanzer@acm.org</a>> wrote:<br>
>><br>
>> On Mon, Mar 23, 2009 at 11:06 AM, SitG Admin<br>
>> <<a href="mailto:sysadmin@shadowsinthegarden.com">sysadmin@shadowsinthegarden.com</a>> wrote:<br>
>> >> Of course, a user can also enter some other email address in the same<br>
>> >> domain and have it quietly switch on him when he logs in.<br>
>><br>
>> Stupid question: Seems to me that the OP can deal with this, assuming<br>
>> that it does get the "user" part of the "<a href="mailto:user@domain.com">user@domain.com</a>" URL.<br>
>> According to the HTTP spec, it should, and at least JSP frameworks<br>
>> were able to pick up on this last time I checked. (It's equivalent to<br>
>> HTTP Basic auth, but without sending a password, which gives you an<br>
>> empty password.) This could be used for pre-filling forms, or for<br>
>> selecting the "right" identity from a set already pre-authenticated at<br>
>> the OP, or just for warning the user "you said X, about to change that<br>
>> to Y, click OK to continue".<br>
>> _______________________________________________<br>
>> general mailing list<br>
>> <a href="mailto:general@openid.net">general@openid.net</a><br>
>> <a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
><br>
><br>
</div></div></blockquote></div><br></div>