Re: [OAUTH-WG] Looking for a compromise on signatures and other open issues

[Luke Shepard <[e-mail]>]

Okay, I'm fine with proceeding down this path. My takeaway is that I don't care really where signatures live, but we definitely need a threat analysis and security considerations document dealing with how and in what contexts to use bearer tokens.

On Sep 28, 2010, at 10:08 AM, Eran Hammer-Lahav wrote:
From: Luke Shepard [mailto:[e-mail]]

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