[OpenID] CheckIDRequest with Big AX

Peter Williams pwilliams at rapattoni.com
Tue Dec 30 23:23:09 UTC 2008


Pat

To communicate with the OP, is your SP app returning HTML to the browser, whose javascript auto-posts the check_immediate REQ message over to the OP?

If you are, any request for a particular content type (e.g. json) to be returned to you would have to happen in the REQ fields in the checkid_immediate() openid message (to be interoperable). I'm not sure there is any such request field.

It's likely if you auto-posted the request thru the browser to the OP, the OP will auto-post a (largish) RESP back through the browser relay to the SP.

If the browser is indeed properly in the comm's loop (just as a relaying system doing 2 auto-posts), by the time the relaying-browser has interpreted the javascript to autopost the intermediate-form content over to your SP, your consumer servlet should be receiving a clean POST block.

I think folks maybe concerned that you may not be using the browser correctly as a message "relaying" device. The nature of the security model of checkid_immediate is such that the browser-based foreground channel MUST be involved (to be conforming). There is still no unanimity one the question that the human need not be interactively involved, tho.

ARGUABLY, if the SP thread on the webserver can 100% impersonate the user/browser properly, it could act in an essentially non-conforming manner BUT expect to successfully interact with an OP to get a RESP - when directly communicating with the OP's endpoint (avoiding the browser relay). Obviously, the OP could still quite properly send an autopost-format form as RESP, since in a conforming system one would expect a browser relay to be involved. As the SP is impersonating the user, it can obviously decode either of the RESP encodings, much as a browser would when acting as relay.

This all reminds me of a secure payment protocol called SET (which assumed a plugin in the browser). As that proved to be very hard to deploy/adopt, vendors eventually started offering server-side SET, where the webserver would impersonate the users and perform the client protocol remotely. Drove the original standard designers (including me) nuts, till it "worked" and worked "effectively".


> -----Original Message-----
> From: general-bounces at openid.net [mailto:general-bounces at openid.net] On
> Behalf Of Pat Cappelaere
> Sent: Tuesday, December 30, 2008 2:41 PM
> To: Martin Atkins
> Cc: general at openid.net List
> Subject: Re: [OpenID] CheckIDRequest with Big AX
>
> Martin,
>
> I have been able to coerce my OP to do almost what I needed.
> I submitted my consumer openid, did the discovery and forced a POST
> checkid_immediate with AX.
>
> The server responded with the data I wanted but in the wrong output
> format.  It did not detect that I had done a POST and tried to
> returned to me the body of that stupid intermediate form thinking that
> it would overflow a GET.  But close.
>
> So, could I suggest an additional attribute that could tell the OP
> what my preferred output format might be: xml, json... when in non-
> browser mode?
>
> example: openid.format= xml | json
>
> Pat.
>
> On Dec 30, 2008, at 4:57 PM, Martin Atkins wrote:
>
> > Pat Cappelaere wrote:
> >> Dick,
> >>
> >> So I can only do a "checkid_immediate" request with AX as long as
> the
> >> AX request is not tool large?
> >> Isn't it limiting?
> >>
> >
> > checkid_immediate still expects the user to be in the loop, since the
> > provider will often need to verify cookies.
> >
> > Likewise, checkid_immediate can (in theory, at least) be done via a
> > form-initiated POST request if the request is too large for a GET.
> >
> > _______________________________________________
> > general mailing list
> > general at openid.net
> > http://openid.net/mailman/listinfo/general
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general



More information about the general mailing list