On Thu, May 20, 2010 at 7:35 PM, Allen Tom <a...@yahoo-inc.com> wrote:
> Hi Dirk- > > We at Yahoo would be very much against using the client secret for signing > requests to Protected Resources, since this would require that the client > secret be distributed to the PR endpoints. For security reasons, one of the > design goals for WRAP was to keep the client secret a secret between only > the AS and the Client – deliberately separating the authentication of the > client (on the AS) from the serving of the protected resource. > I understand - and I'm not taking that away: you still have access tokens, which are the short-lived secrets that you expose to your PR endpoints. Yahoo! would presumably rely on SSL for request integrity instead, or use "Request Authentication" only with public-key signatures. > > From your post, it’s not quite clear what the disadvantage is with using > the Access Token secret for generating signatures. > Well, there is the problem that the spec itself is a bit awkward right now with the access tokens-vs.-bearer tokens language all over the place. There are things in there that I think are unnecessary, like secret type, access token secret, etc. (the access token itself is supposed to be that secret). Then, there is the issue of "re-factoring" the spec. The access token serves the function of delegated authorization. I give you an access token, now you have certain privileges that I delegated to you. We decided to use this "capability" model for OAuth instead of ACLs, and I think it proves powerful. So what's signing for, then? It's for authenticating who is currently using the access token, which has some use cases that I'm trying to call out in my proposal. But that's a different function, so it should be served by a separate mechanism (frankly, I'd be happy if that was in a completely different spec, but I think that train has left the station). Finally, why client secret (or client private key) instead of token secret? Because I believe that actually better reflects what the signing is for - authenticating who is currently using the token. Two of the three use cases I outlined above can't be met with access token secrets: Access token secrets are known to the Server infrastructure, and therefore you don't get non-repudiation and end-to-end integrity, you only get protection from leaked access tokens. Does this make sense? Dirk. > > (forgive me if this was already discussed today - I was *very* zonked out > after 3 days of IIW) > > Thanks > Allen > > > > > On 5/20/10 5:44 PM, "David Recordon" <record...@gmail.com> wrote: > > We're able to use the client secret for signing requests instead of a token > secret, but my understanding is that this exists because of deployers who do > not wish for their protected resources to have access to client secrets. > > --David > > > 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 > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
