proposal: s/AuthorizationType.AUTHENTICATED/AuthorizationType.OAUTH/

[Dirk Balfanz]

I propose to change gadgets.io.AuthorizationType.AUTHENTICATED to
gadgets.io.AuthorizationType.OAUTH.

Here are a few reasons:

- It's hard to remember the difference between "SIGNED" and
"AUTHENTICATED". If "AUTHENTICATED" somehow authenticates my fetches,
then what does "SIGNED" do? Signing is a common way to authenticate
messages. Very confusing.

- Assuming that the gadgets.io.AuthorizationType enumeration lists
(despite its name) different ways to authenticate [1], then having
"AUTHENTICATED" as an authentication type doesn't make any sense.

- If in version 2.0 of opensocial we want to support a cool newfangled
authentication scheme NEWAUTH, then it would be kind of lame to to be
stuck with an enum of (NONE, SIGNED, AUTHENTICATED, NEWAUTH).

What say you?

Dirk.

[1] If it was really about authorization I would expect its values to
be something like ACL, CAPABILITY, ATTRIBUTE_CERT, etc.

[Brian Eaton]

On Wed, Apr 2, 2008 at 9:10 AM, Dirk Balfanz <dirk.b...@gmail.com> wrote:
> I propose to change gadgets.io.AuthorizationType.AUTHENTICATED to
> gadgets.io.AuthorizationType.OAUTH.

+1

I think this change should be made unless someone has specific
objections. There are no existing deployments of full OAuth support
that are dependent on the old value. The rest of the OAuth portion of
the spec is changing because it was too vague to implement, so it
makes sense to make this change at the same time. Now that we have a
better idea of how OAuth for opensocial will actually work, we should
get the spec in sync with reality.

Cheers,
Brian

[Louis Ryan]

+1

[Kevin Brown]

+ 1

--
~Kevin

[Chakradhar Nanga]

Hi Brian,

>> Now that we have a better idea of how OAuth for opensocial will
actually work

Is this documented/discussed some place? If so, can you please point me
to it?

Thanks
Chak

[Brian Eaton]

On Tue, Apr 8, 2008 at 6:33 AM, Chakradhar Nanga <cna...@myspace.com> wrote:
> >> Now that we have a better idea of how OAuth for opensocial will
> actually work
>
> Is this documented/discussed some place? If so, can you please point me
> to it?

We've discussed bits and pieces on the shindig-dev mailing list. For
a summary of the protocol, check out http://oauth.net and read the
appendix to the OAuth specification.

The trick with OAuth for gadgets is that gadgets can't keep secrets
very well, they need help from the server. The server needs to run
the OAuth protocol on behalf of the gadget.

If you want to see a demo, here are some instructions:

1) Download the OAuth java code:
svn co http://oauth.googlecode.com/svn/code/java oauth

2) Build the OAuth java code
cd oauth
mvn install

3) Start the OAuth example service provider
cd example/oauth-provider
mvn jetty:run-war

4) In another window, download the Shindig code:
svn co http://svn.apache.org/repos/asf/incubator/shindig/trunk shindig

5) Build Shindig and start up the sample container:
cd shindig/java/gadgets
mvn jetty:run-war

6) Open up a browser and visit
http://localhost:8080/gadgets/files/samplecontainer/samplecontainer.html

7) Change the "Displaying gadget" field to
http://localhost:8080/gadgets/files/samplecontainer/examples/oauth.xml

8) Click "reset all". You may need to do this twice due a bug in the
sample container.

9) Click the "Personalize this gadget" link. A popup will take you to
the OAuth provider sample page.

10) Enter a user id (any value is fine)

11) Go ahead and close the window, then click the "I've approved
access" window in the sample container page.

12) Shindig will show you the user id you specified to the sample provider.

[Kevin Brown]

I have to take back my +1 here, because I wasn't thinking.

There is currently absolutely no way to upgrade gadgets.io. It's a core, implicit feature. You could use the upgraded version *if* the developer explicitly required the opensocial-0.8 feature, but that's very difficult to implement correctly for a container, and confusing as hell for developers. You could also introduce an explicit "io-2.0" feature, but what happens when io changes in such a way that it's no longer compatible with the implicit dependencies of other things? Yeah, it's a big mess.

Future versions of "the spec" (and I'm not just talking about the versioned opensocial-0.x feature, I'm talking about the whole thing) need to be reworked to take this into consideration. Anything other than developing a new schema is likely just a bandaid fix.

Implicit dependencies are bad.

On Wed, Apr 2, 2008 at 9:10 AM, Dirk Balfanz <dirk.b...@gmail.com> wrote:

--
~Kevin

[Brian Eaton]

I'm not 100% sure I follow. As far as I can tell, there is absolutely
no way to implement OAuth without changes to gadgets.io.

[Chak Nanga]

Great -thanks Brian

Chak

[Kevin Brown]

On Tue, Apr 8, 2008 at 10:34 AM, Brian Eaton <bea...@google.com> wrote:

I'm not 100% sure I follow.  As far as I can tell, there is absolutely
no way to implement OAuth without changes to gadgets.io.

I'm aware of this, which is why I pointed it out. Implicit dependencies are evil.

It's been rightly pointed out that this is actually a compatible change, so I suspect actually changing it isn't a big deal. However, an actual change to gadgets.io that resulted in a backwards compatibility issue would be impossible to support under the current implicit model.
 

--
~Kevin

[Dirk Balfanz]

> I suspect actually changing it isn't a big deal. However, an actual change
> to gadgets.io that resulted in a backwards compatibility issue would be
> impossible to support under the current implicit model.

Right. But this isn't a change that breaks backwards compatibility,
since nobody had implemented this part of the spec - so nobody was
using it.

So I can see a couple of ways going forward:

(1) we get it right in the 0.8 version of the spec
(2) we retroactively change the 0.7 spec

I'm voting for (2), for the following reason: nobody has used this
functionality yet. If we go for (1), we have to support two versions
of the API; if we go with (2), we only have to support one.

Dirk.

[et...@google.com]

agreed

--
~Kevin

[Cassie]

Okay, so we have the following options:

1. Do nothing, we are all just so deliriously happy.
2. Retroactively change the 0.7 spec so that AUTHENTICATED -> OAUTH
3. Change the spec in 0.8 so that AUTHENTICATED -> OAUTH (and decide
whether or not this means we need to keep an alias around)

Opinions thus far:
2. Dirk Balfanz, Kevin Brown
2 or 3. Brian Eaton and Louis Ryan

Alright, please chime in so that we can make a decision on this one.
(Especially if we go the retroactive route)
Thanks!

- Cassie

[Chris Chabot]

As long as we are confident enough about the fact that no one is using
it, i am in favor of #2.

[Lane LiaBraaten]

+1 for option 3.  Retroactively changing the v0.7 spec sounds like a bad precedent to set.  If no one is using AUTHENTICATED let's just rip it out in v0.8 (rather than deprecating or creating an alias).

-Lane

[Dirk Balfanz]

Correct me if I'm wrong on the opensocial versions - I haven't followed them closely.

Right now, we're implementing v0.7 of the spec. Right now, no one is using the OAuth part. The OAuth part has been added to the codebase, though, so in a few weeks time we may actually start seeing people use the OAuth stuff.

So for 0.8, if we're lucky, still no one will have used it and we can just rip it out of the spec. If people _have_ started using it (how will we know?), then we're stuck with the alias. That's why I wanted to change it before people start using it.

Anyway - when is v 0.8 due?

Dirk.

[Kevin Brown]

This attribute is *not* anywhere in the opensocial spec (any version), because it's a part of gadgets.io. gadgets.io is an implicit feature, always present. Either we can change it now, or we can't ever change it. We'd need a single version of the entire "spec" for this.

--
~Kevin

[Dirk Balfanz]

Ok, it looks like everybody agrees it needs to be changed. If it's now or never, this means it has to be now. How do we go about changing it?

Dirk.