[OpenID] CheckIDRequest with Big AX

Martin Atkins mart at degeneration.co.uk
Tue Dec 30 23:34:56 UTC 2008


Peter Williams wrote:
> 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".
> 

I think my understanding of the situation was not complete.

It sounds like what Pat is trying to do is have a non-human "user" 
authenticate with OpenID.

In order to do this today, the software that is in the role of "user" 
must act somewhat as a human user would. If the non-human user is using 
a specially-designed OP, the OP could simply omit all UI or replace it 
with machine-readable data that would be functionally equivalent.

However, the "user" must still know how to interact with the *RP*, and 
there currently is no standard way to do the RP UI, so you'd need to use 
heuristics similar to those used by OpenID form-filling products like 
Sxipper.

The user-agent (which, in this case, is presumably just a library or 
service used by the non-human user) will need to be able to have the 
capabilities that the spec expects a user-agent to have, which include 
the ability to load an HTML page and run the JavaScript therein to the 
extent that forms can be submitted.

Of course, if the RP and the OP are both under your control you can make 
them do things that your non-human user and user-agent can understand, 
but if your "user" can only log in to specialized RPs with a specialized 
OP, it's far less useful. Experimenting with this could be used to 
design a way to make this use-case work, however; I think it's just a 
variation of the problem of how non-human users can "log in" to sites 
that use traditional forms-based authentication.

If I'm still not understanding what you're trying to do please let me 
know. :)

Cheers,
Martin




More information about the general mailing list