Subject: [OAUTH-WG] New service provider that supports OAuth 2.0

From: Allen Tom <[email-masked]>
Date: Wed, 21 Apr 2010 12:01:27 -0700

Well that was fast!

http://developers.facebook.com/docs/authentication/

Allen

---

From: Leah Culver <[email-masked]>
Date: Wed, 21 Apr 2010 12:26:20 -0700

Nice!

On Wed, Apr 21, 2010 at 12:01 PM, Allen Tom <[email-masked]> wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Brian Eaton <[email-masked]>
Date: Wed, 21 Apr 2010 13:00:30 -0700

+1.

---

From: Greg Brail <[email-masked]>
Date: Wed, 21 Apr 2010 16:05:54 -0400

New service provider that supports OAuth 2.0

Whoa, it was!

So, does anyone know what Facebook is planning to do when the spec changes,
which I assume it's going to keep doing for a while?

I mean, the part of the spec that they're describing on the page has been
pretty stable, but if I were building an app for the Facebook platform I'd
be wondering.

*From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
*Allen Tom
*Sent:* Wednesday, April 21, 2010 3:01 PM
*To:* OAuth WG
*Subject:* [OAUTH-WG] New service provider that supports OAuth 2.0

Well that was fast!

Allen

---

From: Justin Richer <[email-masked]>
Date: Fri, 23 Apr 2010 10:55:08 -0400

I was surprised that this announcement didn't garner more commentary
from the list here, as this decision worries me a little bit. There are
a lot of components of the OAuth protocol that aren't stabilized into a
real standard yet, and I'm worried that the Facebook implementation of
"OAuth 2.0" will become the de-facto standard before the IETF group can
come up with something final. 

Is Facebook committed to tracking the spec in its development? If so,
where does that put developers that need to change their libraries as
the underlying spec changes? If not, where does that leave the official
OAuth spec?

I will say that I am absolutely *thrilled* to see Facebook at the table,
and Luke and David have done some great work here. I am ecstatic that
Facebook is pushing away from a proprietary stack into an open standard
at all. Even so, I can't help but fear that we'll end up in a situation
where the largest vendor's extensions and quirks become better supported
than the real standard, like with HTML and CSS.

 -- Justin

On Wed, 2010-04-21 at 16:05 -0400, Greg Brail wrote:
> Whoa, it was!
> 
>  
> 
> So, does anyone know what Facebook is planning to do when the spec
> changes, which I assume it's going to keep doing for a while? 
> 
>  
> 
> I mean, the part of the spec that they're describing on the page has
> been pretty stable, but if I were building an app for the Facebook
> platform I'd be wondering.
> 
>  
> 
> From:[email-masked] [mailto:[email-masked]] On Behalf
> Of Allen Tom
> Sent: Wednesday, April 21, 2010 3:01 PM
> To: OAuth WG
> Subject: [OAUTH-WG] New service provider that supports OAuth 2.0
> 
> 
>  
> 
> Well that was fast!
>

---

From: Luke Shepard <[email-masked]>
Date: Fri, 23 Apr 2010 10:03:42 -0700

Hey Justin, al-

I'll send a more complete email this afternoon with the details of the Facebook OAuth deployment. For now I just wanted to respond to your questions:

>  Is Facebook committed to tracking the spec in its development

Yes. Our main focus right now is stability and bug fixing for what we just launched, but as the working group releases drafts we will participate and upgrade accordingly. We have been very vocal on the list the past month, mostly because we wanted to get the core areas right before we launched. I'm pretty happy with where we are as a starting point.

>  If so where does that put developers that need to change their libraries?

Now that it's in the wild, we must support backwards compatibility so we don't break existing apps. For that reason, we will likely support only a subset of the spec for some time. The parts that are still churning quite a bit (desktop flows, signatures, etc) we will probably not launch until they have stabilized, but the flows we do support (web server, user agent, client credentials) we will maintain backwards compatibility.

>   I can't help but fear that we'll end up in situation where the largest vendor's extensions become better supported than the real standard

I agree that this is a risk, but we are doing everything we can to mitigate it. The version of OAuth we pushed on Wednesday is up to date as of Eran's Monday draft - I think that should be taken as a sign of honest good faith to stay in sync here. There will no doubt be some churn as the spec evolves. I promise to try to raise any issues we see early so that if Facebook ends up not supporting some piece of the spec, the reasons are obvious.

I think the real way to prevent that is to have multiple interoperable implementations by different vendors so that library makers can test across platforms.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Justin Richer
Sent: Friday, April 23, 2010 7:55 AM
To: Greg Brail
Cc: OAuth WG
Subject: Re: [OAUTH-WG] New service provider that supports OAuth 2.0

 -- Justin

---

From: Raffi Krikorian <[email-masked]>
Date: Fri, 23 Apr 2010 10:06:24 -0700

just as a counter - twitter is taking a more paced stance.  our @anywhere is
built upon the oauth2 draft from a few weeks ago, and we're going to be
spending a portion of next week catching it up to the current draft.  its my
personal goal to open the endpoint up so that developers can start to use
oauth2 in the wild, however, i'm trying to balance that with minimizing
churn.

On Fri, Apr 23, 2010 at 10:03 AM, Luke Shepard <[email-masked]>wrote:

> Hey Justin, al-
>
> I'll send a more complete email this afternoon with the details of the
> Facebook OAuth deployment. For now I just wanted to respond to your
> questions:
>
> Yes. Our main focus right now is stability and bug fixing for what we just
> launched, but as the working group releases drafts we will participate and
> upgrade accordingly. We have been very vocal on the list the past month,
> mostly because we wanted to get the core areas right before we launched. I'm
> pretty happy with where we are as a starting point.
>
> Now that it's in the wild, we must support backwards compatibility so we
> don't break existing apps. For that reason, we will likely support only a
> subset of the spec for some time. The parts that are still churning quite a
> bit (desktop flows, signatures, etc) we will probably not launch until they
> have stabilized, but the flows we do support (web server, user agent, client
> credentials) we will maintain backwards compatibility.
>
> >   I can't help but fear that we'll end up in situation where the largest
> vendor's extensions become better supported than the real standard
>
> I agree that this is a risk, but we are doing everything we can to mitigate
> it. The version of OAuth we pushed on Wednesday is up to date as of Eran's
> Monday draft - I think that should be taken as a sign of honest good faith
> to stay in sync here. There will no doubt be some churn as the spec evolves.
> I promise to try to raise any issues we see early so that if Facebook ends
> up not supporting some piece of the spec, the reasons are obvious.
>
> I think the real way to prevent that is to have multiple interoperable
> implementations by different vendors so that library makers can test across
> platforms.
>
>
> > From:[email-masked] <[email-masked]> [mailto:
> [email-masked]] On Behalf
> > Of Allen Tom

-- 
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi

---

From: Brian Eaton <[email-masked]>
Date: Fri, 23 Apr 2010 10:07:13 -0700

On Fri, Apr 23, 2010 at 10:03 AM, Luke Shepard <[email-masked]> wrote:
> I agree that this is a risk, but we are doing everything we can to mitigate it. The version of OAuth we
> pushed on Wednesday is up to date as of Eran's Monday draft - I think that should be taken as a
> sign of honest good faith to stay in sync here. There will no doubt be some churn as the spec evolves.
> I promise to try to raise any issues we see early so that if Facebook ends up not supporting some
> piece of the spec, the reasons are obvious.

This is going to be really critical to making sure that we have a
mature OAuth 2.0 spec.  Thanks.