David, I've noticed the use case you describe doesn't actually work at a many RP's. For example if I go to livejournal.com and just put in just my IDP pip.verisignlabs.com I get an error.
It looks like the RPs assume the leftmost part of an OpenID URL is the identifier and everything else is the IDP address. Is this a bug in the RPs? Though not quite sure how an RP would know to how to parse an OpenID URL if it did not always assume the identifier was included in the URL... Roxana Bradescu | VeriSign Innovation | [EMAIL PROTECTED] -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Recordon Sent: Friday, November 16, 2007 9:01 AM To: Trevor Johns Cc: [email protected] Subject: Re: [security] Validating openid.identity in authenticationresponses .On Nov 16, 2007, at 7:10 AM, Trevor Johns wrote: > There was a question on IRC a few nights ago that I couldn't answer > and has since been bugging me. I was hoping somebody here would be > able to clarify this for me... > > In reply to an authentication request (either via checkid_immediate or > checkid_setup), an OpenID provider includes the identifier that has > been verified as the value for openid.identity. However, what if that > identity doesn't match what was sent in the original authentication > request? This is actually desired functionality to allow for "directed identity". The use case here is that an End User might type their OP Identifier such as "http://aol.com"; to start the discovery process. Then while at the OP, they could potentially create a new OpenID Identifier on the fly or might only have one which is where this can also serve as a convenience feature. > Obviously there needs to be some validation here, otherwise a provider > could make claims about identities on other domains. However, what > about the less dangerous requests, such as returning an different > identity within the provider's authoritative domain? Yes, if you take a look at Section 11 Verifying Assertions (http://openid.net/specs/openid-authentication-2_0-12.html#verification ) you'll see that the Relying Party must verify that the verify that the OP is authoritative for the Claimed Identifier in the response. Hope that helps! --David > And if that's not > allowed, then what is the purpose of including openid.identity at all, > considering that the return_to URL in combination with a nonce (which > is required for secure operation anyway) would be sufficient to ensure > the provider's signature isn't reused maliciously for other > identities? > > -- > Trevor Johns > http://tjohns.net > > _______________________________________________ > security mailing list > [email protected] > http://openid.net/mailman/listinfo/security _______________________________________________ security mailing list [email protected] http://openid.net/mailman/listinfo/security _______________________________________________ security mailing list [email protected] http://openid.net/mailman/listinfo/security
