[OpenID] OpenID 2.1 clarification on use of LocalID

John Bradley john.bradley at wingaa.com
Thu Apr 9 19:56:12 UTC 2009


Sec 11.2 is not the best example of clear wording in the spec.

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.

The new discovered information must match:
1. "Claimed Identifier" MUST EQUAL  openid.claimed_id (less fragment)
2a  If "OP-Local Identifier" (<LocalID> is present in discovered  
information then  "OP-Local Identifier" MUST EQUAL openid.identity,
2b  If "OP-Local Identifier" (<LocalID> is NOT present in discovered  
information then  openid.claimed_id MUST EQUAL openid.identity,
3    "OP Endpoint URL" MUST EQUAL openid.op_endpoint
4    "Protocol Version"  MUST EQUAL openid.ns

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.

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.

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.

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.

Sorry for the boring explanation this is an easy thing for a RP to get  
wrong.

John Bradley

On 9-Apr-09, at 12:08 PM, Andrew Arnott wrote:

> On Thu, Apr 9, 2009 at 11:51 AM, John Bradley  
> <john.bradley at wingaa.com> wrote:
> 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.
>
> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090409/7f1ca9a8/attachment.htm>


More information about the general mailing list