[OpenID] [LIKELY_SPAM]Re: [LIKELY_SPAM]Re: [LIKELY_SPAM]Re: Combining Google & Yahoo user experience research

[Peter Williams]

This is not as bizarre as it sounds. The basic pattern  (though SAML has no delegation notion to worry about) is what the Shibboleth IDP always does (apparently) with SAML equivalents to OpenID2 messages: receive a request solicitation, and (formally) ignore it by sending back an unsolicited response. It cannot send back a SAML solicited response (openid positive assertion), apparently.

This is done, apparently, on the grounds that it allows for stateless consumers/SPs (that therefore have no means to check the round trip nonces, or participate in stateful use cases of SAML etc).

I find it all very dubious (and I'm somewhat suspicious, buts that's just my nature as a security engineer trained a certain way in secure protocol design). There are Specs that have hundreds of words addressing of solicited responses, tiny mentions and conformance rules about requiring support for unsolicited responses/assertions, and folks DO actually apply unsolicited responses to a request for a solicited response/assertion.


-----Original Message-----
From: Martin Atkins [mailto:mart at degeneration.co.uk]
Sent: Wednesday, October 22, 2008 4:29 PM
To: Chris Messina
Cc: Peter Williams; OpenID List
Subject: Re: [LIKELY_SPAM]Re: [OpenID] [LIKELY_SPAM]Re: [LIKELY_SPAM]Re: Combining Google & Yahoo user experience research

Chris Messina wrote:
> I'm unclear what you're saying -- security isn't my first language.
>
> I'm only pointing out a behavior that's already observable in the wild
> -- where you provide one identifier and Yahoo essentially discards the
> whole thing and only looks at the domain and uses identifier select.
>
> This may not be ideal or what's expected, but it's a practice that exists.
>

Indeed, and it is in fact allowed by the OpenID 2.0 spec if you
interpret it as the following, rather bizarre, interaction:

  * RP requests verification of http://id1.example.com/
  * OP ignores that request, but then...
  * OP sends RP an "unsolicited positive assertion" for
http://id2.example.com/ .

Section 10 of the 2.0 spec says that RPs SHOULD accept unsolicited
positive assertions.

In practice, most RPs respond to an unsolicited positive assertion the
same way as a solicited one, but depending on the use-case this might
not make sense.

While I don't dispute that it's correct per spec, I think it does make
for a confusing user experience if there's already an active session for
the "wrong" account, and it also causes trouble for users of delegation
since if Yahoo! verifies the wrong identifier the delegation will be
wrong and the RP's OpenID library will (or rather, should) treat it as
an invalid assertion.