> -----Original Message-----
> From: Luke Shepard [mailto:lshep...@facebook.com]
> Sent: Tuesday, September 28, 2010 9:16 AM

> As far as the charter: this workgroup has had a focus on building an
> interoperable, easy-to-use, developer-friendly standard that is actually used.
> With the goal of market adoption, we should strive to codify those practices
> that will people will use. Bearer tokens are already widely adopted -
> Facebook, Twitter, Google, Microsoft, and others are already using this.

Sure. I have no disagreement with this. However, while these companies have 
many resources to make educated decisions about their security architecture, 
this is not the case for most startups and smaller companies. The challenge is 
always finding the right balance between interop, security, and usability. We 
don't want to scare people away from using the protocol, but we do want to make 
sure they really understand the security tradeoff proposed. I am willing to bet 
less than 10% of those who read the 1.0a specification read the security 
consideration section.

> While I understand that there are some security considerations, on balance,
> these companies have chosen that it's an acceptable tradeoff.

And that's clearly their decision to make. I disagree with these tradeoffs and 
have expressed that. I am not trying to make them change their mind. But while 
you are focused solely on building a product today, I am focused on the future. 
I cannot put my name on a specification that I strongly believe will promote a 
practice I am opposed to, even if it is widely deployed today. By offering an 
equally accessible alternative, I hope some will make a different choice.

> In the interest
> of interoperability, doesn't it make sense to include the way that many
> people are going to use it in the spec?

Yes, but nothing is lost by breaking it into two documents. We can keep 
debating this until we reach consensus (which is likely never), or we can 
'agree to disagree' by putting everything we agree on in one document, and 
everything we don't in another. By employing a modular approach, you get what 
you need, and I get the ability to offer an alternative - both presented 
equally. It is this equality that I care most about.
 
> Anyway, by defining a default parameter, aren't we already admitting that
> the spec isn't complete without bearer tokens anyway?

The specification describing how to obtain a token is clearly incomplete 
without another document telling you how to use the token you obtained. I would 
rather not have a default value at all, and require the parameter present with 
every token response. I am willing to define a default scheme value to keep 
this proposal at zero implementation impact. From a protocol architecture 
perspective, it would be much better not to have a default value. This is 
another compromise, and if it becomes an argument for not splitting the 
documents, I will drop my support for a default value.

At the end, I doubt most Facebook, Google, Microsoft, or Salesforce developers 
will bother to ever read the RFC. They will read the API documentation provided 
by each company. Some library developers will read it, but I hope they will 
read all the parts to provide a comprehensive support for bearer tokens, signed 
tokens, signed requests, common assertions, etc.

I think splitting the current spec into two documents is a reasonable 
compromise with some useful side benefits. This is a carefully balanced 
proposal which I hope will get us moving forward quickly. The time for trying 
to come up with a plan for a single document has passed. We are not going to 
agree on what such a single document includes.

EHL



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to