<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Sec 11.2 is not the best example of clear wording in the spec.</div><div><br></div>Yes If the assertion by the OP is different from the discovered information by anything other than the addition of a fragment to the claimed_id the RP MUST perform discovery on the claimed_id. <div><br></div><div>The new discovered information must match:</div><div>1. "Claimed Identifier" MUST EQUAL openid.claimed_id (less fragment) </div><div>2a If "OP-Local Identifier" (<LocalID> is present in discovered information then "OP-Local Identifier" MUST EQUAL openid.identity, </div><div>2b If "OP-Local Identifier" (<LocalID> is NOT present in discovered information then openid.claimed_id MUST EQUAL openid.identity,</div><div>3 "OP Endpoint URL" MUST EQUAL openid.op_endpoint</div><div>4 "Protocol Version" MUST EQUAL openid.ns</div><div><br></div><div>I have seen RP libs that perform none of this verification. They interop just fine. They just open themselves up to some relatively simple attacks.</div><div><br></div><div>As an example if I delegate may URI to a OP that performs "Identity Select" and they don't assert a new claimed ID only a new openid.identiy in there positive assertion unless the RP performs validation of the discovered information anyone can log into my account at that RP id they have any account at the OP.</div><div><br></div><div>RPs must check all 4 of the above items against the originally discovered information. If ANY of them have changed then discovery needs to be performed again against the openid.claimed_id and that information verified by the above rules.</div><div><br></div><div>If the assertion comes back with the original openid.claimed_id, openid.ns, and openid.op_endpoint but a different openid.identiy the RP should immediately reject the assertion, something bad is happening.</div><div><br></div><div>Sorry for the boring explanation this is an easy thing for a RP to get wrong.</div><div><br></div><div>John Bradley</div><div><br><div><div>On 9-Apr-09, at 12:08 PM, Andrew Arnott wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_quote">On Thu, Apr 9, 2009 at 11:51 AM, John Bradley <span dir="ltr"><<a href="mailto:john.bradley@wingaa.com">john.bradley@wingaa.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> The only identifier that the RP should discover is the claimed_id. If in the returned assertion by the OP the claimed_id and the openid.identity are not equal (less hash) the openid.identiy must be the <LocalID> in the discovered information.<br> </blockquote></div><br><div>John, even if the claimed_id and the openid.identity are equal, the openid.identity must still "match" the discovered information, even if that information is implied by the absence of a LocalID tag. For instance, if LocalID is present with a value of "andrew", but the OP sends an assertion with an openid.identity that is equal to my claimed_id (which would necessarily not just be "andrew"), that is still a mismatch and the RP should not honor that assertion, even though openid.identity and openid.claimed_id are equal to each other. At least that's my reading.</div> </blockquote></div><br></div></body></html>