I like the idea of simplifying the core spec, but the devil is in the details.
In practice it seems onerous to ask the AS and the PR to know both the key used to sign the token as well as the key used to sign the request (regardless of if the request signing key is the same as the client_secret). I'm also not sure the bearer token / access token language works even with the existing section 5.3. As Dirk points out, choosing to "sign" the request is independent of the AS issued token. Does anyone think it is necessary to keep the bearer / access token language as is? FWIW, I'm in favor of moving the request signing into a companion spec. From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Dirk Balfanz Sent: Friday, May 21, 2010 1:29 PM To: Richer, Justin P. Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 2 That would be fine with me, but I think people really like to have signatures as a part of core OAuth. I don't feel strongly about it either way. One nit-pick, though: the other spec (which, in my proposal, is simply a new section in the OAuth spec), wouldn't be about "signed tokens". The way I see it, there should be only one kind of token - you can't use it to sign things, you simply include it in your requests. Whether those requests come in the clear, over SSL, or are otherwise signed, is a different question. The token shouldn't have anything to do with request signing: In the case of SSL, for example, the requests are signed (using a shared secret negotiated during the SSL handshake), but the token has nothing to do with that signature. In the case where we don't use SSL, yet still want to sign the requests, the same should be true: the signature on the request should have nothing to do with the token - the token and the signature serve two different purposes. Fortunately, we have a secret we can use for the signature: the OAuth client secret (and hopefully, in a future rev of the spec, the client private key) - so it makes sense to make this request signing be at least a companion spec to OAuth, if not a section of the spec itself. Dirk. On Fri, May 21, 2010 at 11:27 AM, Richer, Justin P. <jric...@mitre.org<mailto:jric...@mitre.org>> wrote: I have a slightly more radical proposal. What if we factor out the signed token use case into a parallel spec? The OAuth 2.0 Signed Token spec, given the same attention by the group and all that like Eran was talking about yesterday. What this would take is taking out all reference to signing and making core OAuth just about bare tokens, then have a separate spec that details what to call your shared secret parameters, how to get them, and how to sign with them. This makes the core spec a lot simpler (as detailed below) but makes the overall use case of using signed tokens more complicated to follow, as it'd be split in two. -- justin ________________________________________ From: oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org> [oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>] On Behalf Of Dirk Balfanz [balf...@google.com<mailto:balf...@google.com>] Sent: Thursday, May 20, 2010 7:39 PM To: OAuth WG Subject: [OAUTH-WG] proposal for factoring out request signing in OAuth 2 Hi guys, at today's interim meeting, we were discussing Brian Eaton's proposal for OAuth signatures. He was proposing a mechanism that would (1) do away with base string canonicalization, (2) allow for symmetric and public keys, and (3) allow for extensibility. He got homework from the group to prove the feasibility of his proposal by showing a couple of implementations. In this post, I would like to introduce another improvement of the OAuth 2 signing mechanism, one which is orthogonal to Brian's proposal (i.e., it would work both with the signing mechanism in the current spec, as well as with Brian's signature mechanism). The goal of my proposal is twofold: - it simplifies the spec. It will become more readable and therefore easier to implement - it separates out the mechanisms for delegated authorization and for integrity protection into two independent pieces, which can be put together by Servers and/or Clients like LEGO blocks. Summary: - use the client secret instead of the token secret for signing PR access requests. Long version of the proposal: - remove all references to access tokens that are not bearer tokens from the spec. - stop calling the access tokens "bearer tokens". Call them just "access tokens". - remove all references to token secrets from the spec - remove all parts of the spec that are of the kind "if bearer_token then X, else Y", and replace them with X. - delete section 5.3 - add a section called "Request Authentication" that goes something like this: "Servers may require that requests be authenticated by the Client, so that presentation of the access token alone is not sufficient to access a Protected Resource. This has several use cases, including, but not limited to, the following: - Non-repudiation: high-security deployments may require that requests be authenticated (signed) in a non-repudiateable way[1] - Access to protected resources is not protected by SSL, so that access tokens may leak. - End-to-end-integrity: even if SSL _is_ used, network infrastructure may strip SSL protection before the request reaches the protected resource. The protected resource, however, may require end-to-end integrity. If the Server requires that the Client authenticate PR access requests, then the Client uses the following mechanism to sign their HTTP requests: [...]" Then, we basically drop the old Section 5.3 here (except we use the client secret instead of the access token secret). Eventually, instead of Section 5.3, we may have Brian's new signature scheme section here, which would add the option of public-key crypto[1], etc. What do you guys think? Dirk. [1] Technically speaking, the goal of non-repudiation can only be achieved once we have public-key crypto.
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
