On Fri, May 21, 2010 at 9:15 PM, John Panzer <jpan...@google.com> wrote:
> Dirk: How would sub-delegation of an access token work in your > proposal? In other words I hand my AT to a sub-contractor. Who may > call on Apis that do not require a signature from them; or they may, > and therefore need their own relationship with the service. But it's > up to the service and could depend in the API and access needed. > Seems like separation of concerns makes this easier. > Yes, my proposal allows the PR to decide whether or not they allow such sub-delegation. You could imagine servers that don't care - whoever shows up with the bearer token has access. You could imagine servers that don't allow sub-delegation at all - and they would use this signature scheme as a way to enforce it. And you could imagine servers somewhere in the middle - they accept tokens from a sub-delegatee as long as the original Client has told the Server that they're sub-delegating to that particular sub-delegatee. Only the first of those is possible with token-secret-signatures. All three are possible with client-secret signatures. Dirk. > > On Friday, May 21, 2010, Dirk Balfanz <balf...@google.com> wrote: > > 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> > 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 [oauth-boun...@ietf.org] On Behalf Of Dirk > Balfanz [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. > > > > > > > > > > -- > -- > John Panzer / Google > jpan...@google.com / abstractioneer.org / @jpanzer >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
