Relying a question from joseph since i'm coming short on this one:
Looks like the java OAuth code only handles "two-legged oauth" where the client app has a consumer key, but it specifies which user to operate on via this extra xoauth_requestor_id and it's up to the container to trust and honor that. I'm sure that's useful in some situations, but I'd also think that in most cases, the OAuth token itself would store data about which user authorized it, and then during the OAuth validation, you'd pull out that userId and use it for the SecurityToken. But the OAuthLookupService interface in shindig-java doesn't expose things that way, so there's no way to discover the userId from the oauth token itself. Similarly, this whole phase ignores the /userid/@all part of the URL, which is also providing context. In the java code, it bails out if you don't provide an xoauth_requestor_id, and I think that's too limiting, but I didn't want to make the PHP code deviate until I talked to someone about this (but not sure who would be best).
