<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">It works fine if the RP performs the discovery on the returned claimed_id and makes certain that if the openid.identity is not == openid.clamed_id it is in the discovered information as the <LocalID><div><br></div><div>The user supplied value is only used for the first discovery. The second discovery if there is one uses the returned.clamed_id. </div><div>If the calimed_id doesn't change then you don't need a second discovery because you already have the discovery info.</div><div><br></div><div>So logically if the claimed_id that is returned by the OP is the same one that is sent, (as it would be for delegation) if ANY of the other three parameters are changed in the assertion from the OP, that assertion must be rejected. </div><div><div><br></div><div>I have found RPs that were only checking for the openid.claimed_id changing.</div><div><br></div><div>This allowed me to get a OP to assert a claimed_id for a delegated ID while logging in with any valid ID at the OP.</div><div><br></div><div>Checking the values in the returned assertion against the discovery information is critical. </div><div><br></div><div>FYI Google and Yahoo are treating the combination of delegation and directed identity differently. </div><div><br></div><div>John Bradley</div><div><br><div><div>On 9-Apr-09, at 4:40 PM, Peter Williams wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><br><br><blockquote type="cite">-----Original Message-----<br></blockquote><blockquote type="cite">From: <a href="mailto:general-bounces@openid.net">general-bounces@openid.net</a> [<a href="mailto:general-bounces@openid.net">mailto:general-bounces@openid.net</a>] On<br></blockquote><blockquote type="cite">Behalf Of John Bradley<br></blockquote><blockquote type="cite">Sent: Thursday, April 09, 2009 11:51 AM<br></blockquote><blockquote type="cite">To: Andrew Arnott<br></blockquote><blockquote type="cite">Cc: openid General<br></blockquote><blockquote type="cite">Subject: Re: [OpenID] OpenID 2.1 clarification on use of LocalID<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Yes that has come up in the XRD 1.0 work.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">The <LocalID> is a string and can be a XRI, URI, e-mail or any other<br></blockquote><blockquote type="cite">thing that the OP uses to identify the user.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">In most cases that is a URL or a XRI but it could be anything.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Delegation is a term that carried over from openID 1.0 and probably is<br></blockquote><blockquote type="cite">not accurate any more.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">The provider you are asserting is your provider.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">If for some reason you provider knows you by some identifier other<br></blockquote><blockquote type="cite">than the claimed_id then you can use the local_id to send an arbitrary<br></blockquote><blockquote type="cite">string in the openid.identity.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">The only identifier that the RP should discover is the claimed_id. If<br></blockquote><blockquote type="cite">in the returned assertion by the OP the claimed_id and the<br></blockquote><blockquote type="cite">openid.identity are not equal (less hash) the openid.identiy must be<br></blockquote><blockquote type="cite">the <LocalID> in the discovered information.<br></blockquote><br>Nah.<br><br>If the values are not equal, the RP must perform discovery on the value supplied. This requirement provides the openid 1.1 delegation semantics, expressed now through localid (whose value is supplied from the initial XRD discovery).<br><br>We went through this ad nauseum during the review of openid2.0. It works fine for delegation through directed identity mode, too.<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite">RP's not properly verifying that is an issue where someone delegates<br></blockquote><blockquote type="cite">to a OP doing "Identifier Select". (By issue I mean gaping security<br></blockquote><blockquote type="cite">hole)<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">That is a RP problem that can only occur when the User delegates there<br></blockquote><blockquote type="cite">identity.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Someone delegating a URI to a iName would be entering a XRI like<br></blockquote><blockquote type="cite">=jbradley as the <LocalID>.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">It is also possible that someone delegating might not include the<br></blockquote><blockquote type="cite">scheme ie ve7jtb.pip.verisignlabs.com as the <LocalID> that should<br></blockquote><blockquote type="cite">work.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">John Bradley<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">On 9-Apr-09, at 11:27 AM, Andrew Arnott wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">No where in the OpenID 1.x or 2.0 spec (that I can find) is the<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">user's LocalID (openid.identity) mandated to be a URI. Yes, it's a<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">"local identifier", but the OP might choose to let that be simply<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">the local username like "andrew". In this case, the OP hosted<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">identity page might include something like this:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><link rel="openid2.provider" href="<a href="http://provider/opendpoint">http://provider/opendpoint</a>"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><link rel="openid2.local_id" href="andrew"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">So this looks like delegation because a local_id is given, but in<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">this case it's not. It just causes the RP to customize the<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">openid.identity parameter to be 'andrew', which the OP will use to<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">look up the username that should control the claimed_id.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">The reason I bring this up is because I've seen many libraries<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">assume that local_id is a URI and treat it as such. I've even heard<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">ideas of performing discovery on the local_id. Now, there's no<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">reason to perform discovery on the local_id... only the claimed_id<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">needs to be discovered.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I don't even know if any OP out there uses non-URIs for local_id's.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">But since it's not a contradiction in the OpenID 1.1 or 2.0 specs, I<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">think that the 2.1 spec should call out EITHER that it MUST be a URI<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">(and indicate whether discovery is required to succeed) OR that it<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">CAN be any string at all that the OP is expecting.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">--<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Andrew Arnott<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">"I [may] not agree with what you have to say, but I'll defend to the<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">death your right to say it." - Voltaire<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">general mailing list<br></blockquote><blockquote type="cite"><a href="mailto:general@openid.net">general@openid.net</a><br></blockquote><blockquote type="cite"><a href="http://openid.net/mailman/listinfo/general">http://openid.net/mailman/listinfo/general</a><br></blockquote></div></blockquote></div><br></div></div></body></html>