[OpenID] opposing the very logic arguing against "the processing of redirects" during SP discovery (and SP proxying)

[Peter Williams]

In http://openid.net/pipermail/security/2007-February/000241.html, the topic of SP discovery was introduced by Allen:-

"First of all, anyone can craft valid Auth Requests using spoofed values
for openid.return_to and openid.realm. This has very nasty consequences
for sites running redirect servers for click tracking purposes, such as
these:

http://x.go.com/cgi/x.pl?goto=http://www.jyte.com
http://www.aol.com/ams/clickThruRedirect.adp?1,2,http://www.jyte.com

A rogue RP could mask its identity and claim to be go.com or aol.com by
hiding behind these redirect servers. []
[]

The best way to resolve this issue is to define a way for the OP to
verify that the return_to URL is actually a valid OpenID endpoint, and
to also verify its association.

I propose that an RP's return_to url expose an interface to allow it to
identify itself as an OpenID 2.0 endpoint, and to also identify its
association with the OP. Obviously, OPs must not follow redirects when
interrogating the RP's endpoint."

I'm playing with the constructs provided by XRI, enabling an IDP to address the above topic more fully. O reflection, I'm really not sure that the method described above is the "best", on consideration of the full set of issues. The method as described does respond to a well defined problem, which is well characterized in terms of needs. If we refine the problem statement a little more and reflect on alternative methods, we may derive some additional requirements. To this end, lets focus on the trusted resolution set of constructs from XRI2.

We can reflect on resolution methods generally, before delving into XRI. PKI was deemed overly complex and was indeed complication, But then, it aimed for automated machine-processing of security services - with no human involvement. The discovery elements of OpenID that invoke resolution methods do not attempt the same. It is thus simpler, in contrast. OpenID2 assumes that a human user must be checking the return_to address, supporting an OP that is semi-automated at best. From the analysis of the introduction to the prolbem, it is the very human component of this processing that may be "spoofed" by any RP which chooses to retain proxying state in its visible name - a feature that allowing the use of RP-side redirect servers and other forms of reverse resolution.

We can now summarize what security mechanisms are available to the OpenID solution designer in the area of resolution. They are several. First, OpenID2 allows an OP to optionally discover the SP's XRDS, and optionally require trusted resolution be used of those authorities advertising the capability. And, second, OpenID2 allows an RP to cite a specifically _multi_ authority URI (one day it will be a "std" URI), potentially constraining this set to include only those that advertise trusted resolution capabilities. When the XRI endpoint offered by the RP cannot return a trusted XRD in its XRDS response, thirdly, it can return an incomplete XRDS whose implied continuation references must be handled by the OP "suitably". Fourth, a suitable action in this case is to use an alternative cache of XRDs, use non-conforming SAML assertions in XRDs obtained via global resolution, or otherwise lessen the secure name resolution requirements.

Considering together now the problem and the constructs of trusted resolution, the issues for an OP may be presented in four categories. First, the law category: the "laws" guiding OpenID Auth do not carry forward to SP proxing; and are thus limited to the presentation of a positive OpenID assertion to the first authority in the multi-authority RP name. Second, SP gatewaying category: dynamic proxying of attributes received by an SP to another is explicitely authorized by the OP using "additional laws", providng that the other is the second (or nth) authority in the multi-authority XRI supplied by the RP. Third, the originator control category:  the willingness of the OP to release the initial SP, in knowledge that it will be passed on to others, is contingent on its acceptance of the results of trusted resolution (or acceptance of risk of relying on XRDs obtained by less trusted means). Finally, the multi-protocol category: the OP will authorized that communications between SPs need NOT necessarily leverage OpenID Auth. They may be OpenID extensions (like AX), a per-vendor-OpenID extension, or a non OpenID protocol that translates OpenID Claims into another standard or bearer.

Peter.