This is a possible workaround, however it¹s entirely likely that the state (or internal artifact to use Breno¹s term) would need to be replicated across datacenters since the host that saved the state (the OP¹s HTTPS endpoint) could be different than the one that reads the state (on the OP¹s HTTP endpoint).
For example, some ISPs proxy HTTP connections, but not HTTPS which will result in different IP addresses to be used to request HTTP and HTTPS. Depending on the OP¹s infrastructure, the two requests could be served from different datacenters which is tricky to support if the data needs to be replicated nearly instantaneously. At least in Yahoo¹s case, we do have some workarounds to support this scenario for instance supporting OAuth¹s Request Token requires this (and caused us a lot of grief). Although we can support this internal artifact implementation, it would be preferable to shrink AX responses (at least for commonly used attributes) and longer term, to natively define an Artifact binding to OpenID. Allen On 1/22/10 11:18 AM, "Andrew Arnott" <[email protected]> wrote: > I agree with Allen, although to resurrect an old idea I once suggested, Yahoo > could observe that the return_to URL is HTTP only and do its own stateful > redirect (with an artifact payload to itself) to HTTP before doing the POST to > the RP, which would: > 1. use POST instead of GET > 2. avoid the SSL warning to users > 3. do so without any changes to the spec or RPs > The cost of course is that the redirect within Yahoo is stateful, which may > not scale as well as their current implementation. > > Of this isn't a Yahoo-specific problem, of course, but since the example came > up...
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
