Ah! Thanks, Breno. That's the part of the spec I didn't tie together. That makes sense. <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">On Thu, Apr 9, 2009 at 11:57 AM, Breno de Medeiros <span dir="ltr"><<a href="mailto:breno@google.com">breno@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Actually, the OpenID terminology implies that openid.identity must be<br>
an http(s) URI or XRI. See:<br>
<br>
==quote<br>
Section 2: Terminology<br>
<br>
Identifier:<br>
An Identifier is either a "http" or "https" URI, (commonly<br>
referred to as a "URL" within this document), or an XRI (Reed, D. and<br>
D. McAlpin, “Extensible Resource Identifier (XRI) Syntax V2.0,” .)<br>
[XRI_Syntax_2.0]. This document defines various kinds of Identifiers,<br>
designed for use in different contexts.<br>
<br>
==/quote<br>
<br>
and later ...<br>
<br>
==quote<br>
<br>
OP-Local Identifier:<br>
An alternate Identifier for an end user that is local to a<br>
particular OP and thus not necessarily under the end user's control.<br>
<br>
==/quote<br>
<br>
<br>
So if the spec writers intended that openid.identity could be<br>
anything, that is not what the spec actually says.<br>
<div><div></div><div class="h5"><br>
<br>
On Thu, Apr 9, 2009 at 11:51 AM, John Bradley <<a href="mailto:john.bradley@wingaa.com">john.bradley@wingaa.com</a>> wrote:<br>
> Yes that has come up in the XRD 1.0 work.<br>
><br>
> The <LocalID> is a string and can be a XRI, URI, e-mail or any other thing<br>
> that the OP uses to identify the user.<br>
><br>
> In most cases that is a URL or a XRI but it could be anything.<br>
><br>
> Delegation is a term that carried over from openID 1.0 and probably is not<br>
> accurate any more.<br>
><br>
> The provider you are asserting is your provider.<br>
><br>
> If for some reason you provider knows you by some identifier other than the<br>
> claimed_id then you can use the local_id to send an arbitrary string in the<br>
> openid.identity.<br>
><br>
> The only identifier that the RP should discover is the claimed_id. If in<br>
> the returned assertion by the OP the claimed_id and the openid.identity are<br>
> not equal (less hash) the openid.identiy must be the <LocalID> in the<br>
> discovered information.<br>
><br>
> RP's not properly verifying that is an issue where someone delegates to a OP<br>
> doing "Identifier Select". (By issue I mean gaping security hole)<br>
><br>
> That is a RP problem that can only occur when the User delegates there<br>
> identity.<br>
><br>
> Someone delegating a URI to a iName would be entering a XRI like =jbradley<br>
> as the <LocalID>.<br>
><br>
> It is also possible that someone delegating might not include the scheme ie<br>
> <a href="http://ve7jtb.pip.verisignlabs.com" target="_blank">ve7jtb.pip.verisignlabs.com</a> as the <LocalID> that should work.<br>
><br>
> John Bradley<br>
><br>
> On 9-Apr-09, at 11:27 AM, Andrew Arnott wrote:<br>
><br>
>> No where in the OpenID 1.x or 2.0 spec (that I can find) is the user's<br>
>> LocalID (openid.identity) mandated to be a URI. Yes, it's a "local<br>
>> identifier", but the OP might choose to let that be simply the local<br>
>> username like "andrew". In this case, the OP hosted identity page might<br>
>> include something like this:<br>
>><br>
>> <link rel="openid2.provider" href="<a href="http://provider/opendpoint" target="_blank">http://provider/opendpoint</a>"><br>
>> <link rel="openid2.local_id" href="andrew"><br>
>><br>
>> So this looks like delegation because a local_id is given, but in this<br>
>> case it's not. It just causes the RP to customize the openid.identity<br>
>> parameter to be 'andrew', which the OP will use to look up the username that<br>
>> should control the claimed_id.<br>
>><br>
>> The reason I bring this up is because I've seen many libraries assume that<br>
>> local_id is a URI and treat it as such. I've even heard ideas of performing<br>
>> discovery on the local_id. Now, there's no reason to perform discovery on<br>
>> the local_id... only the claimed_id needs to be discovered.<br>
>><br>
>> I don't even know if any OP out there uses non-URIs for local_id's. But<br>
>> since it's not a contradiction in the OpenID 1.1 or 2.0 specs, I think that<br>
>> the 2.1 spec should call out EITHER that it MUST be a URI (and indicate<br>
>> whether discovery is required to succeed) OR that it CAN be any string at<br>
>> all that the OP is expecting.<br>
>><br>
>> --<br>
>> Andrew Arnott<br>
>> "I [may] not agree with what you have to say, but I'll defend to the death<br>
>> your right to say it." - Voltaire<br>
><br>
</div></div>> _______________________________________________<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>
<font color="#888888"><br>
<br>
<br>
--<br>
--Breno<br>
<br>
+1 (650) 214-1007 desk<br>
+1 (408) 212-0135 (Grand Central)<br>
MTV-41-3 : 383-A<br>
PST (GMT-8) / PDT(GMT-7)<br>
</font></blockquote></div><br>