I also agree with the observation about consensus being based on
individual voices.
I don't think it's accurate to say that signatures are a generic
security mechanism. As I would think we learned from OAuth 1.0[a], it
can actually be pretty subtle to define how signatures are used in a
given context.
I doubt that a spec that only includes a "bearer token" model will not
have enough of a security story to get past SECDIR and IESG review,
especially without some careful thinking about when TLS is required
and how it is negotiated (for example, you may need something like
HSTS [1]).
On the other hand, it seems like a sensible compromise approach to re-
use the signature scheme from OAuth 1.0a. If there is interest in
some other type of signing scheme, then of course the cost of this
approach is having some sort of versioning / negotiation for signature
algorithms. But this may already be necessary to distinguish between
signed requests and bearer-token requests.
--Richard
[1] <http://tools.ietf.org/html/draft-hodges-strict-transport-sec>
On Sep 23, 2010, at 9:30 PM, Dick Hardt wrote:
I agree with your point that consensus is based on individual voices.
I agree with Eric's points that signatures are a generic security
mechanism and that signatures should be in a separate spec.
-- Dick
On 2010-09-23, at 6:11 PM, Eran Hammer-Lahav wrote:
It is pretty clear from the recent public response that a core
specification without signatures is going to be viewed as weak and
insecure. This has been my position for over a year, and if it
wasn’t clear, I am going to continue expressing it.
We have enough interest to get a basic signature support in the
core specification, one that is not driven by enterprise use cases,
complex identity solutions, or large distributed systems. Given the
recent Twitter migration to OAuth 1.0a proved that with a big
enough carrot (or stick, depending on your view), developers figure
it out. I believe that an OAuth 1.0a style signature can be easily
developed and added to the core specification as an optional feature.
This is not new. This was agreed upon at the Anaheim meeting. I
took the signature language out of the draft in order to focus the
discussion on the other components. Now that –10 is pretty solid
(normative language-wise), it is time to bring it back in.
Draft –11 will include a signature proposal, even if that means a
short delay.
The arguments about delaying the core spec are meritless, given
that a growing number of companies are releasing OAuth 2.0 APIs
using the latest stable draft. We can easily do a WGLC for the
current stable components, and add signatures without changing
those. This working group does not make technical and architectural
decisions based on the timeline needs of any company. We do what is
best for the web and we take as much time as necessary.
As an aside, while companies can certainly express their corporate
position on matters, this is a working group of individuals, and
consensus is based solely on individual voices.
EHL
On 9/23/10 5:30 PM, "Eric Sachs" <esa...@google.com> wrote:
Google wanted to re-state our long standing opinions on HTTP
signature mechanisms in the OAuth2 spec. The short version is that
standards for signing parts of an HTTP request have value in use-
cases other than OAuth2, and thus they should be defined outside
the spec, and just referenced from the spec similar to how we
reference other Internet security building blocks like SSL. Those
signature standards are likely to in turn reference optional
mechanisms for key rotation and discovery, as well as reference
different crypto schemes like HMAC or RSA.
There are already people in the identity community working on specs
that are related to OAuth2, but which have value in other use-
cases. For example, there are people working on defining standards
around token formats, signing blobs of different types (such as a
token and/or HTTP request), key discovery/rotation, and consumer-
key namespaces across vendors. Dirk Balfanz from Google recently
sent out updated drafts of some of those specs, and they also
leverage specs that John Panzer from Google has worked on for Magic
Signatures, as well as input from people in the community who are
not at Google.
However even though Google is working on those specs, we still
believe it is a mistake to delay the OAuth2 core spec standard to
wait on broad agreement for a "signature proposal," just as it
would be a mistake to delay the OAuth2 core spec to wait on the
standards efforts around token formats, token signing, key
discovery/rotation, consumer-key naming, etc.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth