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
