[OpenID] CheckIDRequest with Big AX

Martin Atkins mart at degeneration.co.uk
Tue Dec 30 22:27:16 UTC 2008


Peter Williams wrote:
> http://openid.net/specs/openid-authentication-2_0.html#anchor28
> 
> Concerning cookies:
> 
> "Methods of identifying authorized end users and obtaining approval to return an OpenID Authentication assertion are beyond the scope of this specification. See Section 15.1.2.1 (Rogue Relying Party Proxying) for OpenID Provider security considerations."
> 
> Thus, if one is an IPS doing core protocol analysis, one can _objectively_ infer nothing about what checkid "expects".
> 
> On the topic of "interaction with users" there is very specify counsel, on checked_immediate no less!
> 
> "openid.mode
> Value: "checkid_immediate" or "checkid_setup"
> 
> Note: If the Relying Party wishes the end user to be able to interact with the OP, "checkid_setup" should be used"
> 
> I know you folks wrote the material, but some of us have to read it (and then anally do what it actually says). I also have a intrusion-class IPS signature designed to detect when checkid_immediate is used as part of HTML-based session sequence (which ups the risk score, since the behavior is contrary to the intent of the message).
> 
> When I read the above, it meant you use checkid_immediate when you want to ensure that there is NO UI interruption of the user (essentially providing the same control as SAML2's isPassive=true).
> 
> 

I was not completely accurate in my previous message.

What I meant to say was that checkid_immediate expects the user's 
*browser* to be in the loop. In other words, it's an indirect message 
rather than a direct message as described in the specification.

While you're correct that the specification does not specifically 
require cookies, checkid_immediate was specified as an indirect message 
so that mechanisms such as cookies could be used to identify the user.

The use-case for checkid_immediate, which may or may not be the same as 
for SAML2's isPassive (I'm no SAML expert), is to allow consumers to do 
the "redirect dance" out of view of the user, for example in an iframe. 
It is not intended for direct RP-to-OP requests.




More information about the general mailing list