xoauth_signature_publickey / xoauth_public_key

[Eiji Kitamura]

Hi,

As I pointed out in shindig mailing list before, oauth params in
Shindig is still not compliant with spec.

xoauth_public_key in spec, xoauth_signature_publickey in shindig.
https://issues.apache.org/jira/browse/SHINDIG-609

This is going to be a big confusion if we don't settle before the
release of shindig 1.0. (I'm not quite sure about schedule for
releasing shindig 1.0)

I don't know how many of non-shindig containers out there but, I would
suggest to align spec itself to shindig code,
since there's already been a few containers using shindig out there
(iGoogle, Orkut, hi5, friendster etc.).

Is there any other things we should take into account?

Eiji,

[Scott Seely]

Shindig has been a great place to prove out concepts, but it should not be something that we use to align the spec. MySpace also implements OpenSocial and comsumes a small amount of Shindig code (mostly just enum values, field name constants, and gadget client JS). I think we have seen some value in being able to think of OpenSocial in broader terms than documenting an implementation.

[Louis Ryan]

Eiji

Can you file a bug with Shindig to resolve this.  http://issues.apache.org/jira/browse/SHINDIG

Thx

-Luis

[Krishna Sankar (ksankar)]

Usually the spec has the precedence unless all the implementations
revolt. Agreed that we need to converge. Propose a change and if it gets
approved, then that is the way we can go.

Cheers
<k/>
P.S : BTW, what was the logic for the 3 or so changes ?

[Eiji Kitamura]

> Shindig has been a great place to prove out concepts, but it should not be something that we use to align the spec. MySpace also implements OpenSocial and comsumes a small amount of Shindig code (mostly just enum values, field name constants, and gadget client JS). I think we have seen some value in being able to think of OpenSocial in broader terms than documenting an implementation.

You are correct. Spec should go first, then implementation.
But the more app developers implement apps with wrong params, the
situation will get worse. We should either fix shindig or align spec
to shindig ASAP.

To fix shindig code should not be a big deal. Some lines of code to
change (and maybe some other sub-effects).

But the problem is, iGoogle, orkut, hi5, friendster, etc are already
live with current shindig code and there might be numbers of
application developers who are already using wrong params. If we fix
shindig code, each container owners must notify them that params have
been changed.
If people are sure that this is not a problem, let's fix shindig.

On the otherhand, xoauth_public_key is not implemented in MySpace
because MySpace is not supporting RSA-SHA1 for OAuth and it's used
only when signature method needs public key(tell me if I'm wrong).
I don't know how many other non-shindig opensocial container
implementations out there but, they all should be looking at spec
changes on opensocial.org. The situation is already where "someone has
to align to some one else". I'd suggest to take the least effort.

could this thread be a spec proposal?

[Brian Eaton]

On Mon, Dec 8, 2008 at 9:02 PM, Eiji Kitamura <age...@gmail.com> wrote:
> But the problem is, iGoogle, orkut, hi5, friendster, etc are already
> live with current shindig code and there might be numbers of
> application developers who are already using wrong params. If we fix
> shindig code, each container owners must notify them that params have
> been changed.
> If people are sure that this is not a problem, let's fix shindig.

Has any container actually implemented that spec proposal?

I suspect we're not seeing container revolt, we're seeing container apathy.

[Krishna Sankar (ksankar)]

Eiji,

I looked at this closely today. It is not a question of the least
effort, it is about the right logic behind the methods.

a) *id (spec) vs *_id (Shindig)

Should be *_id. Usually two words are separated by an
underscore. So opensocial_owner_id, opensocial_viewer_id and
opensocial_app_id make sense.

Even on the spec[1], the xoauth_requestor_id has this scheme !

So change the relevant spec. Is it just [1] ?

b) xoauth_public_key (spec) vs xoauth_signature_publickey (Shindig)

Should be xoauth_public_key because that is what it is - the
public key of the consumer and is congruent to the usage elsewhere,
IMHO.

So change Shindig.


c) xoauth_app_url (spec) vs opensocial_app_url (Shindig)

This, I think, is easy. Should be xoauth_app_url because that is
the general one.

So change Shindig.

I am sure this could cause some headache, but we need to have a systemic
and logical approach. This is why we also need multiple independent
implementations and some conformance efforts. But we are in a fast
moving eco system and so growing pains are natural.

I have also added an entry in JIRA

Cheers
<k/>
[1]
https://sites.google.com/site/oauthgoog/2leggedoauth/2opensocialrestapi

|-----Original Message-----
|From: opensocial-an...@googlegroups.com [mailto:opensocial-
|and-gadg...@googlegroups.com] On Behalf Of Eiji Kitamura
|Sent: Monday, December 08, 2008 9:02 PM
|To: opensocial-an...@googlegroups.com; shindig-
|d...@incubator.apache.org
|Subject: [opensocial-and-gadgets-spec] Re: xoauth_signature_publickey /
|xoauth_public_key
|
|

[Eiji Kitamura]

Brian,

> Has any container actually implemented that spec proposal?
> I suspect we're not seeing container revolt, we're seeing container apathy.

I'm fine if the spec incompliancy is not a big problem to app
developers past and future.
Let's change Shindig then.


Krishna,

Thanks for detailed look and analysis.

> a) *id (spec) vs *_id (Shindig)
>
> Should be *_id. Usually two words are separated by an
> underscore. So opensocial_owner_id, opensocial_viewer_id and
> opensocial_app_id make sense.
>
> Even on the spec[1], the xoauth_requestor_id has this scheme !
>
> So change the relevant spec. Is it just [1] ?

The spec problem I pointed out on the issue was taken from oauthgoog
site, which Kevin Brown told me we should not refer to.

> oauthgoog is wrong, and shouldn't be consulted for anything since it is
> *NOT* official documentation for OpenSocial. Only what's on
> http://opensocial.org is authoritative. The code.google.com copy is often
> out of date as well, so I wouldn't even use that. Please only ever consult
> opensocial.org for the official word on the standard.

Looking at opensocial.org, the spec looks good to me.
http://www.opensocial.org/Technical-Resources/opensocial-spec-v08/gadgets-reference08#gadgets.io.makeRequest

> b) xoauth_public_key (spec) vs xoauth_signature_publickey (Shindig)
>
> Should be xoauth_public_key because that is what it is - the
> public key of the consumer and is congruent to the usage elsewhere,
> IMHO.
>
> So change Shindig.
>
> c) xoauth_app_url (spec) vs opensocial_app_url (Shindig)
>
> This, I think, is easy. Should be xoauth_app_url because that is
> the general one.
>
> So change Shindig.

Again, if the spec incompliancy is not a big deal to app developers, I'm fine.
Let's fix shindig. I can work on PHP version.


Thanks again for your reply and effort!
Eiji,

[Krishna Sankar (ksankar)]

Eiji,

I looked at this closely today. It is not a question of the least
effort, it is about the right logic behind the methods.

a) *id (spec) vs *_id (Shindig)

Should be *_id. Usually two words are separated by an
underscore. So opensocial_owner_id, opensocial_viewer_id and
opensocial_app_id make sense.

Even on the spec[1], the xoauth_requestor_id has this scheme !

So change the relevant spec. Is it just [1] ?

b) xoauth_public_key (spec) vs xoauth_signature_publickey (Shindig)

Should be xoauth_public_key because that is what it is - the
public key of the consumer and is congruent to the usage elsewhere,
IMHO.

So change Shindig.


c) xoauth_app_url (spec) vs opensocial_app_url (Shindig)

This, I think, is easy. Should be xoauth_app_url because that is
the general one.

So change Shindig.

I am sure this could cause some headache, but we need to have a systemic
and logical approach. This is why we also need multiple independent
implementations and some conformance efforts. But we are in a fast
moving eco system and so growing pains are natural.

I have also added an entry in JIRA

Cheers
<k/>
[1]
https://sites.google.com/site/oauthgoog/2leggedoauth/2opensocialrestapi


|-----Original Message-----
|From: opensocial-an...@googlegroups.com [mailto:opensocial-
|and-gadg...@googlegroups.com] On Behalf Of Eiji Kitamura
|Sent: Monday, December 08, 2008 9:02 PM
|To: opensocial-an...@googlegroups.com; shindig-
|d...@incubator.apache.org
|Subject: [opensocial-and-gadgets-spec] Re: xoauth_signature_publickey /
|xoauth_public_key
|
|

[Brian Eaton]

On Mon, Dec 8, 2008 at 9:02 PM, Eiji Kitamura <age...@gmail.com> wrote:

> But the problem is, iGoogle, orkut, hi5, friendster, etc are already
> live with current shindig code and there might be numbers of
> application developers who are already using wrong params. If we fix
> shindig code, each container owners must notify them that params have
> been changed.
> If people are sure that this is not a problem, let's fix shindig.

Has any container actually implemented that spec proposal?