On Tue, Nov 4, 2008 at 2:57 AM, Chris Chabot <[EMAIL PROTECTED]> wrote: > 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).
My 2 cents: we don't understand all of the use cases for inbound three-legged OAuth involved in OpenSocial, which is why the code caters pretty exclusively to the two-legged case. Three-legged OAuth typically involves: - registration of consumers - delegation of limited authority (sometimes called 'scopes'). What scopes should we support? Does that even need to be defined in Shindig? - an approval UI, where a user is asked if the delegation is acceptable - a revocation/management UI, where a user can view and revoke delegations. Which of those things should we implement in Shindig vs leaving to the container? What SPIs do we need to define? Do scopes need to be defined at the opensocial spec level, or can they be container dependent? How soon do we need to make those decisions?
