Hi Dirk, If you eradicated access token secrets in favor of signing with client secrets, how would installed apps, where the client secret is worthless and usually blank, authenticate/sign their own requests?
-- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre On Thu, May 20, 2010 at 4:39 PM, Dirk Balfanz <balf...@google.com> wrote: > 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 > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
