<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&nbsp;different&nbsp;from the&nbsp;discovered&nbsp;information by anything other than the&nbsp;addition&nbsp;of a fragment to the claimed_id the RP MUST perform discovery on the claimed_id.&nbsp;<div><br></div><div>The new&nbsp;discovered&nbsp;information must match:</div><div>1. "Claimed Identifier" MUST EQUAL &nbsp;openid.claimed_id (less fragment)&nbsp;</div><div>2a &nbsp;If "OP-Local Identifier" (&lt;LocalID&gt; is present in&nbsp;discovered&nbsp;information&nbsp;then &nbsp;"OP-Local Identifier"&nbsp;MUST EQUAL&nbsp;openid.identity,&nbsp;</div><div>2b &nbsp;If "OP-Local Identifier" (&lt;LocalID&gt; is NOT present in&nbsp;discovered&nbsp;information&nbsp;then &nbsp;openid.claimed_id&nbsp;MUST EQUAL&nbsp;openid.identity,</div><div>3 &nbsp; &nbsp;"OP Endpoint URL"&nbsp;MUST EQUAL&nbsp;openid.op_endpoint</div><div>4 &nbsp; &nbsp;"Protocol Version" &nbsp;MUST EQUAL&nbsp;openid.ns</div><div><br></div><div>I have seen RP libs that perform none of this verification. &nbsp; They interop just fine. &nbsp;They just open themselves up to some&nbsp;relatively&nbsp;simple attacks.</div><div><br></div><div>As an example if I delegate may URI to a OP that performs "Identity Select" &nbsp;and they don't assert a new claimed ID only a new openid.identiy in there positive&nbsp;assertion&nbsp;unless the RP performs validation of the&nbsp;discovered&nbsp;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&nbsp;discovered&nbsp;information. &nbsp;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&nbsp;assertion&nbsp;comes back with the original openid.claimed_id, openid.ns, and openid.op_endpoint but a&nbsp;different&nbsp;openid.identiy the RP should&nbsp;immediately&nbsp;reject the&nbsp;assertion, something bad is happening.</div><div><br></div><div>Sorry for the&nbsp;boring&nbsp;explanation&nbsp;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">&lt;<a href="mailto:john.bradley@wingaa.com">john.bradley@wingaa.com</a>&gt;</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. &nbsp;If in the returned assertion by the OP the claimed_id and the openid.identity are not equal (less hash) &nbsp;the openid.identiy must be the &lt;LocalID&gt; 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. &nbsp;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. &nbsp;At least that's my reading.</div> </blockquote></div><br></div></body></html>